| Capability (C032):— representing_activity | Date: 2008/02/07 12:34:21 Revision: 1.50 |
This section provides a business level overview of this capability.
An activity is an action that is undertaken by a product or person, or performed on a product by someone or something.
EXAMPLE Changing the oil in an engine is a maintenance activity performed by a person on an engine.
EXAMPLE An engine idling is an activity performed by an engine.
EXAMPLE Running an automated fault diagnostic system on an engine is an activity performed on an engine by the automated fault diagnostic equipment.
There are three basic constructs used for representing an activity:
NOTE Actual activities that have a very short duration, are often thought of as events. It is recommend that these are represented as Actual activities, rather than using Event.
NOTE A formal change process uses directed activities (Directed_activity) instead of the planned activity described here. This is described in capability C065: representing_work_order.
NOTE For the reporting of activities (Activity_actual) that are controlled by a formal change process, or that resulted in a product configuration change, use capability C064: representing_work_done instead.
The relationship between the activity constructs and the product design and an actual product is shown in Figure 1.
A Typical activity is defined by a textual description of what the activity involves - the approach to undertaking the activity. If the typical activity is a structured set of processes then it will be defined by tasks (Task_method). A Task_method is a specialization of a typical activity enabling the activity to be described as a sequence of tasks to be performed. Details of how to specify tasks are provided in the C015: representing_task.
The use of tasks to describe a typical activity and the relationship between the activity constructs and the product design and an actual product is shown in Figure 2.
The description of Scheme is not within the scope of this capability and is described in the capabilities C062: representing_scheme.
When specifying a typical activity that is to be done to a product, it is often necessary to indicate the resources that are required to perform the activity. These resources may be products or people.
EXAMPLE The following resources are required when changing a wheel on a car: a spare wheel, a jack, a wheel spanner, and a person suitably skilled in changing a wheel.
Once the activity has taken place, it is often necessary to record what resource was actually used to perform the activity.
EXAMPLE When I changed the wheel on my car, I used the spare wheel, the jack and a shifting spanner as a tyre spanner was not available.
The description of resources and the relationship to activities is out of scope for this capability and is described in C052: representing_resource and C085: representing_resource_as_realized.
This section provides an overview of the information model that supports this capability.
The EXPRESS-G for the activity model is shown in Figure 3, Figure ![[warning:]](../../../../images/dex/warning.gif){kind=small}
Error Fig 2: There is no figure with id f3b
below and explained in the following sections.
NOTE The EXPRESS-G is not complete. For the complete EXPRESS see the modules: Activity, Activity method, Activity as realized, Date time, Date time assignment, Product as individual, and Process property assignment.
A typical activity is the definition or specification of an activity that something or someone may undertake. It is represented by an Activity_method. The Activity_method should be classified as "Typical activity" (urn:plcs:rdl:std:Typical activity) to indicate that it represents a typical activity.
EXAMPLE The procedure for changing a tyre on a particular bicycle model is a typical activity.
EXAMPLE "Parcel delivery within city centre limits" is a typical activity
A typical activity is identified by assigning an identifier classified as "Activity method identification code" (urn:plcs:rdl:std:Activity method identification code) to the Activity_method using the template assigning_identification (See C001: assigning_identifiers for further details on identification).
A typical activity can be defined by a textual definition of what the activity involves. If the definition is a text string then this is assigned to the Activity_method as a description using the template assigning_descriptor. If the definition is a document, then the document can be assigned to the Activity_method using the template assigning_document. The document assignment is classified as "Definition assignment" (urn:plcs:rdl:std:Definition assignment). This is shown in Figure 3.
If the typical activity is defined by a process or set of processes, then the processes will be represented by Task_methods. The Task_methods are related to the typical activity, represented by the Activity_method, by an Activity_method_realization. This is described in the capability C015: representing_task
If the typical activity is to be scheduled by a Scheme, then the Activity_method representing the typical activity related to the Activity_method by an Activity_method_realization. This is described in the capability C062: representing_scheme.
NOTE Scheme, Scheme_entry, Task_element , Task_method, Task_method_version are all subtypes of Activity_method. Consequently, the typical activity could be defined directly by one of sub types. However, if these subtypes are required, then it is recommended that a single Activity_method is instantiated and linked to the Activity, and the Activity_method is then linked to the subtypes via an instance of Activity_method_realization.
A typical activity may be performed on a product.
EXAMPLE Changing the tyre is a typical activity that can be performed on a bicycle.
The fact that a typical activity can be performed on a product is represented by the Applied_activity_method_assignment relationship, classified as "Activity input" (urn:plcs:rdl:std:Activity input). The relationship relates the typical activity (Activity_method) to the product on which the activity is to be performed.
A number of resources, such as tools, skilled personnel, spare parts, may be required to perform the activity on the product. These resource are represented by instances of Required_resource which are related to the Activity_method by Required_resource_assignment. Information about how to represent resources is provided in C052: representing_resource.
The typical activity may result in by products or waste material. This is represented by an instance of Work_output related to the Activity_method by Work_output_assignment. This is represented by the template assigning_work_output.
EXAMPLE Servicing a car may involve changing the engine oil which needs to be disposed of. The oil is represented as an instance of Work_output.
The EXPRESS-G model illustrating this is shown in Figure 4. The diagram does not show the complete EXPRESS-G model.
An instance diagram showing an instantiation of a typical activity that can be performed on a Product_as_realized is shown in Figure 5.
A typical activity may be performed by a product.
EXAMPLE Being ridden is a typical activity that can be performed by a bicycle.
The fact that a typical activity can be performed by a Part or by a Product_as_realized is represented by using the Applied_activity_method_assignment relationship, classified as "Product usage" (urn:plcs:rdl:std:Product usage) to assign the typical activity (Activity_method) to a Product_as_realized or the version of the part that the Product_as_realized is built from: Part_version
The type of activity can be provided by classifying the Activity_method.
The EXPRESS-G modelling illustrating this is shown in Figure 4
An instance diagram showing an instantiation of a typical activity that can be performed on a Product_as_realized is shown in Figure 6.
A planned activity is an anticipated occurrence of a typical activity that something or someone may or may not undertake in the future.
EXAMPLE The fact that I plan to take my bicycle to the Bicycle repair shop on 2 June 2006 is a planned activity.
The activity is represented by an Activity. The typical activity, for which the activity is an occurrence, is represented by an Activity_method as described in the previous section. The Activity.chosen_method attribute is used to relate the Activity to the Activity_method of which it is an occurrence.
A planned activity is identified by assigning an identifier classified as "Activity identification code" (urn:plcs:rdl:std:Activity identification code) to the Activity. (See C001: assigning_identifiers for further details on identification).
A planned activity may be performed on a product. This is represented by using the assigning_activity template to instantiate a Applied_activity_assignment relationship, classified as "Activity input" (urn:plcs:rdl:std:Activity input)to relate the activity (Activity) to relate the product on which the activity is be performed. This may be a Product_as_realized, a Part or Part_version.
A number of resources, such as tools, skilled personnel, spare parts, may be required to perform the activity on the product. These resources are represented by instances of Required_resource which are related to the Activity by Required_resource_assignment. Information about how to represent resources is provided in C052: representing_resource.
The planned activity may result in by products or waste material. This is represented by an instance of Work_output related to the Activity by Work_output_assignment. This is represented by the template assigning_work_output.
EXAMPLE Servicing a car may involve changing the engine oil which needs to be disposed of. The oil is represented as an instance of Work_output.
The EXPRESS-G model illustrating this is shown in Figure 7. The diagram does not show the complete EXPRESS-G model.
An instance diagram showing the occurrence of a planned activity is shown in Figure 5.
A planned activity may be performed by a product.
The fact that the activity is something that the Product_as_realized may do is represented by using the assigning_activity template to instantiate an Applied_activity_assignment, classified as "Product usage" (urn:plcs:rdl:std:Product usage) to relate the activity (Activity) to the product Product_as_realized that is to perform the activity.
The definition of the activity performed by the product is provided by the Activity_method.
The EXPRESS-G model illustrating this is shown in Figure 7. The diagram does not show the complete EXPRESS-G model.
There are two aspects to the life cycle of a planned activity (Activity). The first is its approval status. The second is the state of the Activity.
The approval and state stages are dependent on the business processes deployed within an enterprise. An example is that an Activity may be approved as an acceptable activity, and have the state, "ready" indicating that the Activity is ready to be run.
The precise meaning of a state is represented by assigning reference data to the State as described in the capability C010: assigning_reference_data.
A planned activity is approved by assigning an Approval (using an Approval_assignment) as defined by the template assigning_approval.
There are two mechanisms for associating states with an Activity in the model. Namely by using State and State_definition as described in the capabilities C007: representing_state_type and C041: representing_state_observed, or by using Activity_status.
In order to only have a single approach to associating a state it is recommended to only use the template assigning_asserted_state as defined in the capability C041: representing_state_observed. The Activity_status is included for compatibility with the PDM Schema. If a PDM Schema file is read containing instances Activity_status they should be mapped to C041: representing_state_observed.
An actual activity is the occurrence of a typical activity that something or someone has engaged in. It is the record of an activity that has taken place.
EXAMPLE A record of the fact that Mr Bicyclerepairman changed the tyre on my bicycle on 1 June 2006 is an actual activity.
The actual activity is represented by an Activity_actual and identified by assigning an identifier classified as "Activity identification code" (urn:plcs:rdl:std:Activity identification code) to the Activity_actual using the template: assigning_identification (See C001: assigning_identifiers for further details on identification).
The typical activity, for which the actual activity is an occurrence, is represented by an Activity_method as described in the previous section. The Activity_actual.chosen_method attribute is used to relate the Activity_actual to the Activity_method of which it is an occurrence.
If the actual activity (Activity_actual) was an occurrence of an activity that was planned for (Activity) then the Activity_actual can be related back to the Activity by an Activity_happening relationship.
An actual activity may have been performed on a product. This is represented by using the assigning_activity template to instantiate a Applied_activity_assignment relationship, classified as "Activity input" (urn:plcs:rdl:std:Activity input)to relate the activity (Activity_happening) to the product on which the activity has been performed - the product in focus. This may be a Product_as_realized, a Part or Part_version.
Often the activity may affect a change to the product that results in a change in the product configuration status.
EXAMPLE A new part is fitted to a bicycle resulting in a change of version of the bicycle.
EXAMPLE In order to address a safety issue, the manufacturers of a bicycle have issued a technical bulletin requesting a modification be made to all bicycles of a particular model. The fact that this change has been made on an individual bicycle results in a new of version of the bicycle.
Where the activity undertaken has resulted in a change to the product configuration status, the activity is related to the product status both before and after the change has taken place.
The activity performed (Activity_happening) is related to the product status (version - Product_as_realized) before the change by using the assigning_activity template to instantiate an Applied_activity_assignment relationship, classified as "Activity input" (urn:plcs:rdl:std:Activity input), to relate the Activity_happening to the Product_as_realized. The activity performed is related to the product status after the change by using the assigning_activity template to instantiate another Applied_activity_assignment relationship, classified as "Activity output" (urn:plcs:rdl:std:Activity output), to relate the Activity_happening to the new Product_as_realized.
NOTE The decisions as to whether to the configuration status of product changes as a result of the activity performed on the product is determined by the business rules employed within an organization.
The actual activity may have resulted in by products or waste material. This is represented by an instance of Work_output related to the Activity_happening by Work_output_assignment. This is represented by the template assigning_work_output.
EXAMPLE Servicing a car may involve changing the engine oil which needs to be disposed of. The oil is represented as an instance of Work_output.
NOTE Any product that has its configuration status changed as the result of the activity should be related to the Activity_happening by the assigning_activity template as described above.
When an activity has been undertaken, a number of resources, such as tools, skilled personnel, spare parts may have been used to perform the activity on the product. It may be necessary to record this. These resources are represented by instances of Resource_as_realized which are related to the Activity by Resource_as_realized_assignment. Information about how to represent resources used is provided in C085: representing_resource_as_realized.
The EXPRESS-G model illustrating this is shown in Figure 9. The diagram does not show the complete EXPRESS-G model.
An instance diagram showing the occurrence of an actual activity that has been undertaken by an actual product is shown in Figure 6.
The fact that the actual activity is something that the Product_as_realized has done is represented by using a Applied_activity_assignment, classified as "Product usage" (urn:plcs:rdl:std:Product usage) to relate the Activity_actual to the Product_as_realized.
The only aspect to the life cycle of an actual activity is the state of the Activity_actual, which is typically used to indicate the level of completeness of the activity.
The state stages are dependent on the business processes deployed within an enterprise. An example is that an Activity_actual have the state, "ongoing" indicating that the Activity_actual is still being executed.
The precise meaning of a state is represented by assigning reference data to the State as described in the capability C010: assigning_reference_data.
There are two mechanisms for associating states with an Activity_actual in the model. Namely by using State and State_definition as described in the capabilities C007: representing_state_type and C041: representing_state_observed, or by using Activity_status.
In order to only have a single approach to associating a state it is recommended to only use C007: representing_state_type and C041: representing_state_observed. The Activity_status is included for compatibility with the PDM Schema. If a PDM Schema file is read containing instances Activity_status they should be mapped to C041: representing_state_observed.
There are many situations where an activity may be represented by decomposing it into a series of smaller activities. Furthermore, this set of activities may represent a sequence of activities.
EXAMPLE The activity "Changing a tyre on a car" is decomposed into "jacking the car", "undoing the wheel nuts", "removing the wheel", "attaching the spare wheel", "doing up the wheel nuts", "removing the jack". The activity "jacking the car" could be further decomposed to "attaching the jack to the car" and "raising the car with the jack".
Typical Activity decomposition and sequencing
The decomposition of a typical activity into a set of activities can be represented by
using Activity_method_relationship
to relate the large activity to the set of smaller activities. The relationship should be
classified as [Activity_decomposition]Error RDL1: The class Activity_decomposition does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.
NOTE If the set of activities represent a structured set of processes such as a linear sequence of activities, the typical activities should be defined by tasks (Task_method) as described in the C015: representing_task.
NOTE If a timed sequence of activities, a schedule, is required, then a Scheme should be used as described in C062: representing_scheme. If the sequence of activities represent a
Actual Activity decomposition and sequencing
The decomposition of the planned activities or activities that have taken place is
represented by using Activity_relationship to relate Activity or in the case of an activities that has
taken place, the Activity_happening, to
relate the large activity to the smaller activities. The relationship should be classified
as [Activity_decomposition]Error RDL1: The class Activity_decomposition does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.
There are two types of properties associated with activities:
The properties for an activity represent the properties that are intrinsic to the activity and are represented using Activity_property.
EXAMPLE The racing activity cost 300 pounds.
EXAMPLE The racing activity has lasted for 3 hours and has 4 hours to completion.
NOTE The use of properties is described in C077: assigning_process_properties and C079: representing_properties_numerically C080: representing_properties_textually
An instance diagram showing the assignment of properties to an Activity_actual is given in Figure 11.
Properties of a product as realized
The properties of the Product_as_realized that are a result of the activity are represented by Assigned_property. There are potentially many properties that can be associated with a Assigned_property. It is therefore necessary to identify the properties that have resulted from a given activity. This represented by the use of the justification relationships as shown in Figure 10.
EXAMPLE During the activity "Racing" the top speed was 50 KPH.
NOTE The use of properties is described in C076: assigning_product_properties and C079: representing_properties_numerically C080: representing_properties_textually.
An instance diagram showing the assignment of properties to a Product_as_realized is
given in Figure Error Fig 2: There is no figure with id f10
.
This has been raised as issue, RBN-6, against ISO 10303-239. The EXPRESS schema has been modified in DEXlib (Long form: dexlib/data/schemas/ap239_arm_lf.exp, short form: dexlib/data/schemas/ap239_arm_sf.exp). These changes will be made to ISO 10303-239 as a Technical Corrigendum at some stage.
Characterization of observed properties on product usage
It is necessary to record the person and organization that observed the property and the date and time that this observation was made.
The use of properties is described in C076: assigning_product_properties and C079: representing_properties_numerically C080: representing_properties_textually.
This section specifies how the information model can be further characterized by the assignment of additional information such as dates, approvals and people or organizations.
The following characterizations may apply.
A textual definition of what the activity involves expressed as a text string can be provided using the template assigning_descriptor to assign text to the Activity_method
A document can be used to provide the definition of a typical activity by using the template assigning_document to assign the document to the Activity_method. The document assignment is classified as "Definition assignment" (urn:plcs:rdl:std:Definition assignment). The parameters used are given in template table: Template @6(Figure 3)
| Template @6 (Figure 3): assigning_document | |||
|---|---|---|---|
| Description | The following parameters are set to represent the assignment of a document in the role of definition. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| doc_ass_role | Definition_assignment | The name of the External_class being used to determine the role of the assignment. | |
| doc_ar_ecl_id | urn:plcs:rdl:std | The id of the External_class_library that stores the External_class used to classify the Document_assignment. | |
| assigned_document | ? | The Document, Document_version, Document_definition or File which is assigned by the Document_assignment. | |
| is_assigned_to | ? | The entity to which the Document, Document_version, Document_definition or File is assigned. | |
Dates, such as the creation date, can be assigned to the typical activity, Activity_method by the templates assigning_calendar_date or assigning_time. The parameters used are given in template table: Template @6(Figure 3) (this shows the parameters for a calender date - the same class values are used for a time).
| Template @7 (Figure 3): assigning_calendar_date | |||
|---|---|---|---|
| Description | The following parameters are set to represent the date on which the typical activity was created. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| date_class_name | Date_actual_creation | The name of the class being used to classify the role date assignment, e.g. the start date. | |
| date_ecl_id | urn:plcs:rdl:std | The id of the External_class_library in which the @date_class_name is defined. | |
| year | ? | Calendar_date year_component | |
| month | ? | Calendar_date month_component | |
| day | ? | Calendar_date day_component | |
| items | ? | The items to which the date is assigned. | |
Approvals can be assigned to the typical activity, Activity_method by using the template assigning_approval.
People or organizations can be assigned to the typical activity, Activity_method, in a specified role, e.g. the people of organization who defined or owns the typical activity. The assignment is defined by the templates assigning_organization or assigning_person_in_organization. The roles of the assignment are defined by sub classes of: "Organization or person in organization assignment" (urn:plcs:rdl:std:Organization or person in organization assignment)
NOTE Types of people or organizations that are required to perform the activity should be associated as required resources, see capability C052: representing_resource.
A Location can be assigned to the typical activity, Activity_method by using the template assigning_location. This may be done where the activity has to be performed in a given a location, for example, certain maintenance on a ship's nuclear reactor may only be performed in a specified dock yard.
Dates, such as the planned start and end dates, can be assigned to the planned activity, Activity by the templates assigning_calendar_date or assigning_time. The parameters used in the templates are given in template table: Template @6(Figure 3) (this shows the parameters for a calender date - the same class values are used for a time).
| Template @18 (Figure 3): assigning_calendar_date | |||
|---|---|---|---|
| Description | The following parameters are set to represent the planned start and end dates of a planned activity. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| date_class_name | Date_planned_start, Date_planned_end | The name of the class being used to classify the role date assignment, e.g. the start date. | |
| date_ecl_id | urn:plcs:rdl:std | The id of the External_class_library in which the @date_class_name is defined. | |
| year | ? | Calendar_date year_component | |
| month | ? | Calendar_date month_component | |
| day | ? | Calendar_date day_component | |
| items | ? | The items to which the date is assigned. | |
Approvals can be assigned to the planned activity, Activity by using the template assigning_approval. See section Planned activity life cycle.
People or organizations can be assigned to the planned activity, Activity, in a specified role, e.g. the people of organization who defined or owns the typical activity.
NOTE Types of people or organizations that are required to perform the activity should be associated as required resources, see capability C052: representing_resource.
The assignment is defined by the templates assigning_organization or assigning_person_in_organization. The parameters used in the templates are given in template table: Template @19(Figure 3).
| Template @19 (Figure 3): assigning_organization | |||
|---|---|---|---|
| Description | The following parameters are set to represent the organization who is intended to undertake a planned activity. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| org_assgn_class_name | Executor_of | The name of the class being used to classify the assignment of the organization. (Organization_or_person_in_organization_assignment) This provides the role or reason for the assignment. For example 'Owner_of'. | |
| org_assgn_ecl_id | urn:plcs:rdl:std | The identifier of the External_class_library storing the definition of the class referenced by the parameter @org_assgn_class_name. | |
| org_id | ? | The name or identifier of the organization. | |
| org_id_class_name | ? | The name of the class being used to classify the identification (Identification_assignment) of the organization. This provides the role or reason for the identification. For example CAGE code. | |
| org_id_ecl_id | ? | The identifier of the External_class_library storing the definition of the class referenced by the parameter @org_id_class_name. | |
| items | ? | The items to which the organization is assigned | |
| Template @21 (Figure 3): assigning_person_in_organization | |||
|---|---|---|---|
| Description | The following parameters are set to represent the person who is intended to undertake a planned activity. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| person_role_class_name | Executor_of | The name of the class being used to classify the person assignment () This provides the role for the assignment. | |
| person_role_ecl_id | urn:plcs:rdl:std | The identifier of the External_class_library storing the definition of the class referenced by the parameter @person_role_class_name class. | |
| last_name | ? | the last name (surname) of the person doing the approval | |
| first_name | ? | The first element of the Person's list of forenames. This parameter is optional. | |
| middle_names | ? | The Person's other forenames. | |
| prefix_titles | ? | The text that specifies the Person's social or professional standing and appear before his or her names. This parameter is optional. | |
| suffix_titles | ? | The text that specifies the Person's social or professional standing and appear after his or her names. This parameter is optional. | |
| org_id | ? | The identifier or name of the organization. | |
| org_id_class_name | ? | The name of the class used to classify the identification (Identification_assignment) of the organization. This provides the role or reason for the identification. For example CAGE code. | |
| org_id_ecl_id | ? | The identifier of the External_class_library storing the definition of the class referenced by the parameter @org_id_class_name class. | |
| items | ? | The items to which the person is assigned | |
A Location can be assigned to the planned activity, Activity by using the template assigning_location. This represents where the activity is to be performed.
Dates, such as the actual start and end dates, can be assigned to the actual activity, Activity_actual by the templates assigning_calendar_date or assigning_time. The parameters used in the templates are given in template table: Template @6(Figure 3) (this shows the parameters for a calender date - the same class values are used for a time).
| Template @18 - activity_actual (Figure 3): assigning_calendar_date | |||
|---|---|---|---|
| Description | The following parameters are set to represent the actual start and end dates of an actual activity. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| date_class_name | Date_actual_start, Date_actual_end | The name of the class being used to classify the role date assignment, e.g. the start date. | |
| date_ecl_id | urn:plcs:rdl:std | The id of the External_class_library in which the @date_class_name is defined. | |
| year | ? | Calendar_date year_component | |
| month | ? | Calendar_date month_component | |
| day | ? | Calendar_date day_component | |
| items | ? | The items to which the date is assigned. | |
People or organizations can be assigned to the actual activity,
Activity_actual, indicating people or
organizations that undertook or reported the activity.
The assignment is defined by the templates
assigning_organization or
assigning_person_in_organization.
The parameters used in the templates are given in
Error template_table: template table referenced by figure_id=f3 instance=@19 - activity_actual does not exist
template table:
Template @19 - activity_actual(Figure 3).
| Template @19 (Figure 3): assigning_organization | |||
|---|---|---|---|
| Description | The following parameters are set to represent the planned start and end dates of a planned activity. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| org_assgn_class_name | Executor_of | The name of the class being used to classify the assignment of the organization. (Organization_or_person_in_organization_assignment) This provides the role or reason for the assignment. For example 'Owner_of'. | |
| org_assgn_ecl_id | urn:plcs:rdl:std | The identifier of the External_class_library storing the definition of the class referenced by the parameter @org_assgn_class_name. | |
| org_id | ? | The name or identifier of the organization. | |
| org_id_class_name | ? | The name of the class being used to classify the identification (Identification_assignment) of the organization. This provides the role or reason for the identification. For example CAGE code. | |
| org_id_ecl_id | ? | The identifier of the External_class_library storing the definition of the class referenced by the parameter @org_id_class_name. | |
| items | ? | The items to which the organization is assigned | |
| Template @21 - activity_actual (Figure 3): assigning_person_in_organization | |||
|---|---|---|---|
| Description | The following parameters are set to represent the planned start and end dates of a planned activity. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| person_role_class_name | Executor_of | The name of the class being used to classify the person assignment () This provides the role for the assignment. | |
| person_role_ecl_id | urn:plcs:rdl:std | The identifier of the External_class_library storing the definition of the class referenced by the parameter @person_role_class_name class. | |
| last_name | ? | the last name (surname) of the person doing the approval | |
| first_name | ? | The first element of the Person's list of forenames. This parameter is optional. | |
| middle_names | ? | The Person's other forenames. | |
| prefix_titles | ? | The text that specifies the Person's social or professional standing and appear before his or her names. This parameter is optional. | |
| suffix_titles | ? | The text that specifies the Person's social or professional standing and appear after his or her names. This parameter is optional. | |
| org_id | ? | The identifier or name of the organization. | |
| org_id_class_name | ? | The name of the class used to classify the identification (Identification_assignment) of the organization. This provides the role or reason for the identification. For example CAGE code. | |
| org_id_ecl_id | ? | The identifier of the External_class_library storing the definition of the class referenced by the parameter @org_id_class_name class. | |
| items | ? | The items to which the person is assigned | |
A Location can be assigned to the actual activity, Activity_actual by using the template assigning_location. This represents where the activity was to be performed.
| Template @22 - activity_actual (Figure 3): assigning_location | |||
|---|---|---|---|
| Description | The following parameters are set to represent the location of an activity. Template parameters not specified in the table are defined by the user. | ||
| Parameter name: | Parameter value: | Parameter description: | |
| la_class_name | Execution_at | The type of class used to classify the location assignment and so provide the role or reason for the assignment. | |
| la_ecl_id | urn:plcs:rdl:std | The id of the External_class_library storing the la_class_name class | |
| loc_id | ? | The location identifier being assigned. | |
| loc_id_class_name | ? | The name of the class used to classify the location identifier and so provide the role or reason for the location | |
| loc_id_ecl_id | ? | The id of the External_class_library storing the loc_id_class_name class | |
| loc_org_id | ? | The name or identifier of the organization responsible for the location representation | |
| loc_org_id_class_name | ? | The name of the class being used to classify the identification (Identification_assignment) of the organization responsible for the location representation | |
| loc_org_id_ecl_id | ? | The identifier of the External_class_library storing the definition of the class used to classify the organization identifier. | |
| entity_for_location | ? | The entities to which the location may be assigned | |
| alt_locn_rep | ? | The alternative representations to which the location may be assigned. It may be used together with this template by using the reference parameter ^location and its attribute alt_locn_rep: ^location.alt_locn_rep | |
The following sections define a set of templates for the capability, where a template is a specification of a set of entities that need to be instantiated to represent a given set of information.
This section specifies the template assigning_activity.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to assign an activity to something in a given role. For example, a maintenance activity that has been performed on a product is recorded by assigning an Activity_actual to a Product_as_realized.
target
is the parameter to which the
Applied_activity_assignment
is bound.
| Entity in path | Value | Inherited from |
| Applied_activity_assignment.role | '/IGNORE' | — |
This section specifies the template representing_typical_activity.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a typical activity that something or someone may undertake. A typical activity defines the approach to or method used for undertaking an activity.
For a typical activity that represents a structured set of processes, then the typical activity will be related to tasks which define the structured set of processes. For further details see: C015: representing_task. If the activities or tasks are to be scheduled, then the schedule is represented by a Scheme. For further details see: C062: representing_scheme.
The following templates are used to represent activities planned or undertaken in accordance with the typical activity. These activities are related back to the typical activity.
target
is the parameter to which the
Activity_method
is bound.
| Entity in path | Value | Inherited from |
| Activity_method.name | '/IGNORE' | — |
| Activity_method.purpose | '/IGNORE' | — |
| Activity_method.description | '/IGNORE' | — |
| Activity_method.consequence | '/IGNORE' | — |
NOTE this characterization is mandatory.
A typical activity must be specified in some way. There are several alternative routes to do this,
At least one of these alternatives must be used. See Figure 1 for an Express-G overview
A textual definition is represented by assigning a descriptor to the typical activity using the assigning_descriptor template.
A document describing the typical activity is assigned using template assigning_document with the Document_assignment classified as "Definition assignment" (urn:plcs:rdl:std:Definition assignment).
A structured set of processes or steps of a typical activity is represented using Activity_method_realization to relate e.g. a Task_method or Scheme to the Activity_method.
NOTE These alternatives are not mutually exclusive, they can be used at the same time.
NOTE this characterization is optional.
A product or a group of products can be assigned to the typical activity, classified as e.g. "activity input" and "product usage". See Figure 1 for an Express-G overview.
For a typical activity to be performed on a product or group of products, an Applied_activity_method_assignment, classified as "Activity input" (urn:plcs:rdl:std:Activity input), is used to relate the product to the activity as an "activity input".
This is done using template assigning_activity with the input parameter role_class_name given the value "Activity input" (urn:plcs:rdl:std:Activity input).
For a typical activity to be performed by a product, an Applied_activity_method_assignment, classified as "Product usage" (urn:plcs:rdl:std:Product usage), is used to relate the product to the activity as the product to be used ("product_usage").
This is done using template assigning_activity with the input parameter role_class_name given the value "Product usage" (urn:plcs:rdl:std:Product usage).
NOTE this characterization is optional.
A typical activity may be approved, e.g. approved for use. See Figure 1 for an Express-G overview.
An approval of the typical activity is represented by assigning a Approval to the Activity_method using the assigning_approval template.
NOTE The assignment of approvals is described the capability C019: assigning_approvals.
NOTE this characterization is optional.
A person or organization may be assigned to a typical activity, classified as e.g. "creator" or "owner" of the activity. See Figure 1 for an Express-G overview.
NOTE This characterization is not intended to assign persons or organizations as a resource to an activity. To assign types of persons or organizations as a resource to an activity, see characterization "assigning resources".
An organization is associated to a typical activity by using the template assigning_organization. The assignment of the organization (Organization_or_person_in_organization_assignment) must be classified, e.g. as "Owner_of".
A person in an organization is associated to a typical activity by using the template assigning_person_in_organization. The assignment of the person (Organization_or_person_in_organization_assignment) must be classified, e.g. as "Creator".
NOTE this characterization is optional.
Required resources, such as required type of person, required location, etc, may be assigned to a typical activity. See Figure 1 for an Express-G overview.
An required resource is associated to a typical activity by using Required_resource_assignment, classified appropriately.
NOTE this characterization is optional.
Properties, e.g. estimated duration, can be assigned to a typical activity. See Figure 1 for an Express-G overview.
A property is represented by Activity_property assigned to the Activity_method, using template assigning_process_property.
NOTE The assignment of process properties are described further in capability C077: assigning_process_properties.
This section specifies the template representing_planned_activity.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a specific activity that is planned to take place some time in the future but is not authorized by a work order i.e. directed.
NOTE This template is primarily intended to represent planned product usage in operational stages, but may also be used to represent activities planned to be done to a product that are not formally authorised by a Work_order.
Where the activity is work planned to be done on a product and authorised by a Work_order, the template representing_work_order should be used.
Where the activity is work that has been done to a product in response to a planned activity (a Directed_activity) that has been authorized by a Work_order, the template representing_work_done should be used.
Where the activity is a record of a usage of a product that has taken place, e.g. a sortie flown by an aircraft , the template representing_product_usage should be used.
Where the activity is a record of an activity that has taken place that is neither an authorized activity i.e. not authorized by a Work_order such as part of a directed change or technical bulletin, nor an activity performed by a product the more generic template representing_activity_actual should be used.
NOTE A planned activity may include reference to a specific product, but this is not included in the template.
target
is the parameter to which the
Activity
is bound.
| Entity in path | Value | Inherited from |
| Activity.id | '/IGNORE' | — |
| Activity.name | '/IGNORE' | — |
| Activity.description | '/IGNORE' | — |
NOTE this characterization is optional.
A planned activity may relate to a product that is going to be used in the activity, or on which the activity will be performed.
A product is assigned to an activity using template assigning_activity assigned to Activity. See Figure 1 for an Express-G overview.
NOTE this characterization is optional.
Classifications and codes may be assigned to a planned activity through external reference data. See Figure 1 for an Express-G overview.
A class of an Activity is represented using the template assigning_reference_data assigned to Activity.
A code of an Activity is represented by using the template assigning_code assigned to Activity.
NOTE this characterization is optional.
This template mandates the assignment of a start time for the actual activity. If the duration or end time of the Activity needs to be recorded, additional time may be assigned as well.
Additional time can be assigned to an Activity by using the template assigning_time. See Figure 1 for an Express-G overview.
A planned end date is commonly assigned to the template representing_planned_activity. The date and time assignment is classified as: "Date planned end" (urn:plcs:rdl:std:Date planned end) to indicate that it is the date (and time) when the usage of the product ended.
NOTE this characterization is optional.
Either an organization or person within an organization should be associated in a specified role with a planned activity. Depending on if it is a person in an organization or just the organization that is assigned, different templates are used. See also Figure 1.
An organization is associated to an activity by using the template assigning_organization.
The assignment of the organization (Organization_or_person_in_organization_assignment) must be classified, e.g. as 'Maintaining_organization', or 'Operating_organization'.
A person in an organization is associated to an activity by using the template assigning_person_in_organization.
The assignment of the person (Organization_or_person_in_organization_assignment) must be classified.
NOTE this characterization is optional.
If waste or by products are anticipated, such may be associated to the planned activity by using the template assigning_work_output. See Figure 1 for an Express-G overview.
NOTE this characterization is optional.
A location can be associated to the planned activity by using the template assigning_location.
The location may be expressed as a global location, an address-based location, an organization-based location, or as a location in a regional grid. See further Capability C049: assigning_location. See Figure 1 for an Express-G overview.
The assignment of the location (assigning_location) may be classified e.g. as 'Actual_start_location' or 'Actual_maintenance_location'.
NOTE this characterization is optional.
Approvals and states may be associated with a planned activity. See Figure 1 for an Express-G overview.
An approval is associated with the planned activity by using the template assigning_approval.
A state is associated with the planned activity by using the template assigning_asserted_state.
This section specifies the template representing_product_usage.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a record of the usage of a product, e.g. the use of an airplane for a specific mission or the use of a truck for a specific transportation. It represents an activity that has at least started and may have finished - an actual activity.
It can be used to record any information about a product usage, such as what product individual was used, who has reported the product usage, what typical activity was followed, and when the product was used. It is mandatory to assign an identifier or name to the activity, and a start or end time, and to relate it to a typical activity (method) as well as the product being used.
Where the activity reported on is an authorized activity undertaken on a product in response to a Work_order, such as a change to the product, the template representing_work_done should be used.
Where the activity reported on is a neither an authorized activity, nor an activity performed by a product the more generic template representing_activity_actual should be used.
NOTE This template is intended for tracking product usage (operation).
Where the activity is work planned to be done on a product and authorised by a Work_order, the template representing_work_order should be used.
Where the activity is planned to take place some time in the future but is not authorized by a work order i.e. directed, the template representing_planned_activity should be used.
Where the activity is work that has been done to a product in response to a planned activity (a Directed_activity) that has been authorized by a Work_order, the template representing_work_done should be used.
Where the activity is a record of an activity that has taken place that is neither an authorized activity i.e. not authorized by a Work_order such as part of a directed change or technical bulletin, nor an activity performed by a product the more generic template representing_activity_actual should be used.
Relations between the actual activity (product_usage) and a planned activity is instantiated through Activity_happening.
target
is the parameter to which the
Activity_actual
is bound.
| Entity in path | Value | Inherited from |
| Activity_actual.id | '/IGNORE' | Activity.id |
| Activity_actual.name | '/IGNORE' | Activity.name |
| Activity_actual.description | '/IGNORE' | Activity.description |
NOTE this characterization is optional.
Classifications and codes may be assigned to an actual activity through external reference data. See Figure 5 for an Express-G overview.
A class of an Activity_actual is represented using the template assigning_reference_data assigned to Activity_actual.
A code of an Activity_actual is represented by using the template assigning_code assigned to Activity_actual.
NOTE this characterization is optional.
An organization or person within an organization may be associated with an actual activity. See Figure 5 for an Express-G overview.
An organization is associated to an actual activity by using the template assigning_organization.
The assignment of the organization (Organization_or_person_in_organization_assignment) must be classified, e.g. as 'Maintaining_organization', or 'Operating_organization'.
A person in an organization is associated to an actual activity by using the template assigning_person_in_organization.
The assignment of the person (Organization_or_person_in_organization_assignment) must be classified.
NOTE this characterization is optional.
The state of an Activity_actual can be represented by assigning a State_observed to the Activity_actual using the assigning_asserted_state template.
NOTE The status should not be represented using Activity_status.
NOTE The assignment of a state is described by the template assigning_asserted_state.
See Figure 5 for an Express-G overview.
NOTE this characterization is optional.
A location can be associated to the actual activity by using the template assigning_location. See Figure 5 for an Express-G overview.
The location may be expressed as a global location, an address-based location, an organization-based location, or as a location in a regional grid. See further Capability C049: assigning_location.
The assignment of the location (assigning_location) may be classified e.g. as 'Actual_start_location' or 'Actual_maintenance_location'.
This section specifies the template representing_activity_actual.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a record of an activity that has at least started and may have finished - an actual activity.
It can be used to record any information about an actual activity, such as who has performed and/or reported the activity, what typical activity was followed, and when the activity was performed. It is mandatory to assign an identifier or name to the activity, and a start or end time, and to relate it to a typical activity (method).
This template should only be used for activities that are neither performed by a product, or activities, such as configuration change activities, that have been undertaken in response to an activity (a Directed_activity) that has been authorized by a Work_order.
Where the activity is work planned to be done on a product and authorised by a Work_order, the template representing_work_order should be used.
Where the activity is planned to take place some time in the future but is not authorized by a work order i.e. directed, the template representing_planned_activity should be used.
Where the activity is work that has been done to a product in response to a planned activity (a Directed_activity) that has been authorized by a Work_order, the template representing_work_done should be used.
Where the activity is a record of a usage of a product that has taken place, e.g. a sortie flown by an aircraft , the template representing_product_usage should be used.
Relations between the actual activity (product_usage) and a planned activity is instantiated through Activity_happening.
target
is the parameter to which the
Activity_actual
is bound.
| Entity in path | Value | Inherited from |
| Activity_actual.id | '/IGNORE' | Activity.id |
| Activity_actual.name | '/IGNORE' | Activity.name |
| Activity_actual.description | '/IGNORE' | Activity.description |
NOTE this characterization is optional.
Classifications and codes may be assigned to an actual activity through external reference data. See Figure 1 for an Express-G overview.
A class of an Activity_actual is represented using the template assigning_reference_data assigned to Activity_actual.
A code of an Activity_actual is represented by using the template assigning_code assigned to Activity_actual.
NOTE this characterization is optional.
An organization or person within an organization may be associated with an actual activity. See Figure 1 for an Express-G overview.
An organization is associated to an actual activity by using the template assigning_organization.
The assignment of the organization (Organization_or_person_in_organization_assignment) must be classified, e.g. as 'Maintaining_organization', or 'Operating_organization'.
A person in an organization is associated to an actual activity by using the template assigning_person_in_organization.
The assignment of the person (Organization_or_person_in_organization_assignment) must be classified.
NOTE this characterization is optional.
The state of an Activity_actual can be represented by assigning a State_observed to the Activity_actual using the assigning_asserted_state template.
NOTE The status should not be represented using Activity_status.
NOTE The assignment of a state is described by the template assigning_asserted_state.
See Figure 1 for an Express-G overview.
NOTE this characterization is optional.
A location can be associated to the actual activity by using the template assigning_location. See Figure 1 for an Express-G overview.
The location may be expressed as a global location, an address-based location, an organization-based location, or as a location in a regional grid. See further Capability C049: assigning_location.
The assignment of the location (assigning_location) may be classified e.g. as 'Actual_start_location' or 'Actual_maintenance_location'.
This section specifies the template assigning_work_output.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent the output from work that has been done.
NOTE The outputs referred to here are items that do not affect the configuration status of the product that have been worked on.
target
is the parameter to which the
Work_output_assignment
is bound.
target
is the parameter to which the
Work_output
is bound.
| Entity in path | Value | Inherited from |
| Work_output.name | '/IGNORE' | — |
| Work_output.description | '/IGNORE' | — |
NOTE this characterization is optional.
Identifiers can be associated with the work output by using the template assigning_identification to assign an identifier to a Work_output as shown in Figure 5.
NOTE this characterization is optional.
Quantities can be associated with the work output by using the template representing_quantity through the optional quantity attribute on Work_output as shown in Figure 5.
This section specifies the template representing_activity_method_realization.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a relationship between an activty method and a detailed description of its realization.
target
is the parameter to which the
Activity_method_realization
is bound.
| Entity in path | Value | Inherited from |
| Activity_method_realization.id | '/IGNORE' | — |
| Activity_method_realization.name | '/IGNORE' | — |
| Activity_method_realization.description | /IGNORE' | — |
This capability "Representing an activity" is related to the following capabilities:
Error C1: Capability referencing_task not in dex_index.xmlError C1: Capability referencing_scheme not in dex_index.xmlError C1: Capability referencing_documents not in dex_index.xmlThis capability "Representing an activity" is dependent on the following capabilities:
The following classes of reference data are required for this capability:
[Activity_decomposition]Error RDL1: The class Activity_decomposition does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xmlError RDL1: The class Execution_at does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xmlError RDL2: The class Organization_or_person_in_organization_assignment
is defined in more than one OWL file:© OASIS 2010 — All rights reserved