| DEX (D003):— task_set | Date: 2006/06/14 12:04:07 Revision: 1.25 |
This DEX enables the transmission of a task specification.
The task specification DEX deals with information required to maintain the product in order to sustain or regain an acceptable product state. A task specification does not plan, schedule, or record what is done.
It is usual for the task specification to be derived from a formal analysis process such as Logistic Support Analysis (LSA).
A task specification is initially prepared during the latter stages of the detail design and development phases and is continuously assessed and adjusted throughout the lifetime of a system or product.
A task specification includes one or more of the following:
A task specification is uniquely identified within a given context, such as an organization or a product. A task specification may evolve over time, and progression codes, such as variant and version numbers, may be applied to distinguish the various stages of evolution.
A task specification is also referenced by a task name, however, a task name may not be unique within a given context.
Identification of the product to which the task specification applies.
The product in focus may be either a part, a slot on a part, or an element in a breakdown structure.
List of zones where the task is performed.
List of access points to be removed/opened to perform the task.
A reference to a defined removal route.
Specification of the expected result.
The validity of a task may be constrained to a specific context. These conditions are refered to as applicability and effectivity.
Applicability of a task is defined for the product in general, and can be defined in terms of:
Effectivity of a task is defined for a specific customer, and can be defined in terms of:
The task specification is categorized according to classifications systems applicable within a given application context.
Task type codes and task category codes are examples of task specification categorizations.
Identification of resources required to execute the task. Required resources may include:
Each required resource may be quantified on the basis of estimations, calculations, measurements, experience etc. Quantities may be defined as time, number, count etc. Each quantity may also be characterized against aggregation level - that is, whether or not it includes the resources required for sub-tasks and/or pre- and post-condition tasks.
Resource requirements may also depend on the operational environment and support level.
Hazardous material codes may be applied to spares, expendables and consumables.
Spares, expendables and consumables may have a replacement indicator, that is, whether or not it is mandatory to replace a mounted item with the spare, expendable or consumable.
An identified required resource may have references to alternative or substitute resources.
Identification of intended support levels at which the task may be executed. A support level might be identified either by:
Determines whether the task requires that the product in focus has to be removed from its top item. The top item is the platform on which the product in focus is fitted (unless the product in focus is itself the top item).
EXAMPLE The top item for an aircraft engine is the aircraft. The top item for a bell is the bicycle it is fitted to.
Summary of reason for the existence of a task. This may include a reference to identified support drivers, and possible concequences of not executing the task.
A task trigger describes the conditions which may cause a task to be executed. These codition may be dependent upon operational environment and support solution etc.
A task trigger may be scheduled or event based.
Examples of scheduled task triggers include:
NOTE The frequency of scheduled task triggers may change over time, e.g. the first two services are executed every 500 km, thereafter every 1000 km.
Examples of event based task triggers include:
Task trigger applicability may be expressed in terms including:
A task specification may be subdivided into task steps. Each of those task steps may in turn be subdivided into subtasks. Any task step may also refer to another task specification that describes the task step to be performed.
An examle of task structure is pre condition-, core-, and post condition task steps. Each of those task steps may in turn refer to other task specifications. This is illustated in figure 1 below.
Specification of how to carry out the core task step may contain one or more of the following:
A core task step may be further subdivided into task steps (subtasks), where each taks step may contain the same information that has been described for the core task step above.
There may also be relationsships between the task steps such as sequencing (task step flow).
A task step may have a defined applicability/effectivity, e.g. based on a modification of the product. There might also be alternative task steps.
A task pre condition is a specification of a product and/or environmental state that has to be fulfilled before starting the task step under consideration. A task step pre condition may result in a requirement to execute one or more pre condition tasks (see section "Pre and post condition tasks" below).
A task post condition is a specification of a product and/or environmental state that has to be fulfilled after the finalization of the task step under consideration. A task step post condition may result in a requirement to execute one or more post condition tasks (see section "Pre and post condition tasks" below).
A pre condition task step may be defined as a task that has to completed prior to the commencement of the core task step. Where there are multiple pre condition task steps, there may be relationships (e.g. sequence) between them. A pre condition task step may describe how to remove the part from its physical location. Pre condition task steps may either be described within the task specification under consideration, or be referenced as another task specification describing the pre condition task step. Each pre condition task step may have a defined applicability, e.g. environmental, operating state or product context.
A post condition task step is a task that has to be executed after the finalization of the core task step. Where there are multiple post condition task steps, there may be relationships (e.g. sequence) between them. Post condition task steps may either be described within the task specification under consideration, or be referenced as another task specification describing the post condition task step. Each post condition task step may have a defined applicability, e.g. environmental, operating state or product context.
Warnings and/or cautions provided in order to ensure legal, health and safety issues are adressed.
Legal, health and safety advisories may also include references to documents.
Defined legal, health and safety advisories may have a limited applicability/effectivity.
Elapsed time is the time it takes to perform the task. Elapsed time may be defined as:
These may be further specialized into:
Task elapsed time may have a defined applicability/effectivity.
There is also a requirement to be able to add a note to a defined elapsed time
References to related documents, i.e. documents related to the task, but not part of the task such as design documents or training materials.
References to other task specifications which could be executed at the same time as the task under consideration.
EXAMPLE For example, the removal of an engine gives an opportunity to inspect other equipment in the same enclosure.
A note provides the user with information that is helpful but does not belong to the immediate subject.
Specification of reporting requirement on the execution of the task, including:
Task specification administrative information includes:
NOTE Ownership here means the right to create new versions of the task specifications, and the right to change the status of existing versions. There is also other forms of ownerships such as copyright and intellectual property.
This section is a detailed description on how to implement a task specification in PLCS, using defined PLCS capabilities and PLCS reference data.
This implementation may be further tailored by specific parties by extending the reference data defined in the PLCS reference data library.
The implementation details are organized in accordance with the section 'Task specification Information Content' above.
An overview of the capabilities used by this DEX is shown in figure 3 below.
This section is based on the guidelines described in the capability C015: representing_task.
A task specification shall allways be represented as a combination of Task_method and Task_method_version. In the usage phase there shall always be a Task_element to contain the detailed description of the task being specified.
NOTE A Task_method_version may represent either a version or a variant of the task specification.
Both the task specification and its version are identified through the usage of Identification_assignment being assigned to the Task_method and the Task_method_version respectively. Guidelines on how to represent an identifier is given in the capability C001: assigning_identifiers.
NOTE In situations where there is no explicit version control of a Task_method, the identifier for the Task_method_version shall be se to '0' and be without an assigning organization.
A task specification may also be referenced by a task name. A task name is represented as an Identification_assignment being assigned to the Task_method. Guidelined on how to represent a name is given in the capability C001: assigning_identifiers.
The following reference data guidelines shall be applied for identification and versioning of a task specification:
NOTE TO BE REMOVED: S1000D. Classify Task_method_id as "Information_code", Task_method_version_id as "Information_code_variant" and Task_method_name as "Information_name" (3.9.5.1).
This section is based on the guidelines described in the capability C015: representing_task.
The product in focus, to which the task specification (Task_method_version) is being assigned, may be represented as either a Part, an Attachment_slot or as a Breakdown_element.
NOTE The product in focus will be passed by reference and its details must be known by the recieving system, prior to the exchange of the task specification.
The product in focus shall be referenced through its view definition and version. This enables task specifications to be developed in parallel with the development of the product itself. Assigning task specifications to the Part_view_definition, Attachment_slot_definition and Breakdown_element_definition respectively, enables different versions of a task specification to be assigned to the product in focus during its different life cycle stages.
NOTE A task specification may vary according to the life cycle stages of the product.
NOTE A task specification that depends upon the products position in an end product, shall be controlled by effectivity and not by different view definitions.
The task specification (Task_method_version) is assigned using Task_method_version_assignment.
This section is based on the guidelines described in the capability
referencing_part_or_slot![[warning:]](../../../../images/dex/warning.gif){kind=small}
Error C1: Capability referencing_part_or_slot not in dex_index.xml
.
The following information is required to uniquely identify a Part as the product in focus to which the task specification (Task_method_version) is being assigned:
In order to reference a Part as the product in focus the following reference data shall be applied:
This section is based on the guidelines described in the capability
referencing_part_or_slotError C1: Capability referencing_part_or_slot not in dex_index.xml
.
The following information is required to uniquely identify an Attachment_slot as the product in focus to which the task (Task_method_version) is being assigned:
In order to reference a Attachment_slot as the product in focus, the following reference data shall be applied:
Breakdown element as the product in focus
This section is based on the guidelines described in the capability
referencing_product_breakdown_elementError C1: Capability referencing_product_breakdown_element not in dex_index.xml
.
The following information is required to uniquely identify a Breakdown_element as the product in focus to which the task (Task_method_version) is being assigned:
NOTE The breakdown context is optional and may be left out if the Breakdown_element is uniquely identified by its id and version.
In order to reference a Breakdown_element as the product in focus the following reference data shall be applied:
NOTE TO BE REMOVED: S1000D Use referencing_breakdown_element_view where Breakdown_id = 'MOdel_identification_code', Breakdown_version_id = 'System_difference_code', Breakdown_element_id = 'Standard_numbering_system' plus 'Disassembly_code' and Breakdown_element_version_id = 'Disassembly_code_variant'. The name of the Breakdown_element (hardware or function) is given as techname in each data module ('Technical_name' in chapter 3.9.5.1).
This section is based on the guidelines described in the capability
referencing_product_breakdown_elementError C1: Capability referencing_product_breakdown_element not in dex_index.xml
.
A zone is represented as Zone_element, Zone_element_version and a Zone_element_definition along with its Zone_breakdown_context.
The Zone_element is assigned to the product in focus to which the task specification is assigned. The reference is established by the In_zone entity.
NOTE The view definition of the product in focus to which the zone is being assigned, should be another view definition than the one that has the task specification assigned to it. This is required in order to e.g. enable a part to occur in many positions in an assembly structure and still use a generic task specification.
The following reference data shall be applied:
NOTE The assignment of identifiers to Zone_breakdown and Zone_breakdown_version are optional in order to allow for situations where the zonal breakdown isn't explicitly defined.
This section is based on the guidelines described in the capabilities
referencing_product_breakdown_elementError C1: Capability referencing_product_breakdown_element not in dex_index.xml
and
referencing_part_or_slotError C1: Capability referencing_part_or_slot not in dex_index.xml
.
Access points may be represented as either Breakdown_elements in a Product breakdown, or Parts in an Assembly structure, along with their respective version, view definition and view definition context.
The access point is assigned to the product in focus to which the task specification is assigned. However, the representation of the assignment of the access point is dependent upon how the product in focus is represented. The following alternatives exists:
NOTE The view definition of the product in focus to which the access point is being related, should be another view definition than the one that has the task specification assigned to it. This is required in order to e.g. enable a part to occur in many positions in an assembly structure and still use a generic task specification.
NOTE An alternative would have been to use Product_based_location_identification. However a Product_based_location_identification can not refer to a view definition of a part, i.e. can not refer to a specific part in an assembly structure. An issue might be raised against the PLCS data model.
The following reference data shall be applied:
NOTE The assignment of identifiers to Breakdown and Breakdown_version are optional in order to allow for situations where the Breakdown isn't explicitly defined.
This section is based on the guidelines described in the capability
referencing_documentsError C1: Capability referencing_documents not in dex_index.xml
.
A reference to a defined removal route is represented as a Document_version being assigned to a view definition of the product in focus (i.e. Part_view_definition or Breakdown_element_definition).
NOTE The view definition of the product in focus to which the removal route is being related, should be another view definition than the one that has the task specification assigned to it. This is required in order to e.g. enable a part to occur in many positions in an assembly structure and still use a generic task specification.
The Document representing the removal route shall be identified by its "Document_identification_code" (urn:plcs:rdl:std:Document_identification_code) and optionally by "Document_name" (urn:plcs:rdl:std:Document_name) (or subclasses thereof). The Document_version is identified by its "Version_identification_code" (urn:plcs:rdl:std:Version_identification_code), or subclass thereof.
NOTE The identification of the Document_version is optional.
The Document_assignment needs to be classified in order to distinguish between documents being assigned in different roles. In this case shall the Document_assignment be classified as "Removal_route_reference" (urn:plcs:rdl:std:Removal_route_reference).
The following reference data shall be applied:
This section is based on the guidelines described in the capability C015: representing_task.
Specification of the expected result is represented as Task_objective. The description of the objective shall be represented as text, using the capability C095: assigning_descriptor.
NOTE This DEX does not define any further classifications of the Task_objective.
The following reference data shall be applied:
This section is based on the guidelines described in the capability C006: assigning_effectivity.
NOTE Effectivity and applicability are both represented as Effectivity, and there is no explicit separation between the two. The rest of this section will therefore just use the term 'Effectivity'.
There are basically two types of task effectivities:
Task specification effectivity (applicability) is represented as an Effectivity being assigned to the Task_method_version_assignment using Effectivity_assignment. A textual description of the effectivity can be provided as a descriptor, as described in the capability C095: assigning_descriptor.
NOTE Figure 11. Attributes and their values are not shown for Dated_effectivity and Time_interval_effectivity respectively. For more information look at the capability C006: assigning_effectivity.
The following reference data shall be applied:
Effectivity domain representation
The representation of the second case will require an additional Effectivity_assignment that associates the defined Effectivity with the entity that represents the effectivity domain. The Effectivity_assignment assiged to the entity representing the effectivity domain shall be classified as "Effectivity_domain" (urn:plcs:rdl:std:Effectivity_domain) or subclass thereof.
The following reference data shall be applied:
NOTE Effectivity domains used to define task applicability, as defined under the 'Information content' section above, includes; product version, product configuration, position in product, and environment.
NOTE Effectivity domains used to define task effectivity, as defined under the 'Information content' section above, includes; customer contract, support solution, serialized item, and, lot/batch of serialized items.
Product version as the effectivity domain
Task applicability defined in terms of a specific version of a product, is represented by refererencing a Part_version and its Part as the effectivity domain.
NOTE
Referencing a
Part_version
is based on the guidelines described in the capability
referencing_part_or_slotError C1: Capability referencing_part_or_slot not in dex_index.xml
.
The following reference data shall be applied:
Product configuration as the effectivity domain
Task applicability defined in terms of a specific configuration of a product, is represented by refererencing a Product_configuration as the effectivity domain.
NOTE
Referencing a
Product_configuration
is based on the guidelines described in the capability
referencing_product_configurationError C1: Capability referencing_product_configuration not in dex_index.xml
.
NOTE The identification of Product_concept is optonal.
The following reference data shall be applied:
Position in an assembly as the effectivity domain
Task applicability defined in terms of a specific position in an assembly, is represented by refererencing a Next_assembly_usage as the effectivity domain.
NOTE
Referencing a specific position in an assembly
(i.e. a Next_assembly_usage)
is based on the guidelines described in the capability
referencing_part_or_slotError C1: Capability referencing_part_or_slot not in dex_index.xml
.
The following reference data shall be applied:
Reference data required to identify the respective part in the assembly structure, but not shown in figure above:
Position in a breakdown structure as the effectivity domain
Task applicability defined in terms of a specific position in a breakdown structure, is represented by refererencing a Breakdown_element_realization as the effectivity domain.
NOTE
Referencing a specific position in a product breakdown
is based on the guidelines described in the capability
referencing_product_breakdown_elementError C1: Capability referencing_product_breakdown_element not in dex_index.xml
.
The following reference data shall be applied:
Reference data required to identify the part and the breakdown element respectively, but not shown in figure above:
Environment as the effectivity domain
Task applicability defined in terms of a typical environment, is represented as a State_definition defining the effectivity domain.
NOTE Fore more information on how to represent typical and actual environments, see the capabilities C043: representing_environment_typical and C044: representing_environment_actual respectively.
NOTE Referencing a State_definition is based on the guidelines described in the capability C007: representing_state_type.
NOTE There might be other State definitions, appart from typical environment, that are required to define task applicability / effectivity such as operational_phase etc.
The following reference data shall be applied:
Customer contract as the effectivity domain
Task effectivity defined in terms of a specific customer contract, is represented as a Contract defining the effectivity domain.
NOTE
Referencing a
State_definition
is based on the guidelines described in the capability
referencing_contractError C1: Capability referencing_contract not in dex_index.xml
.
The following reference data shall be applied:
Support solution as the effectivity domain
Task effectivity defined in terms of a specific support solution, is represented as an Organization or an Organization_type defining the effectivity domain.
NOTE
Referencing a
Organization
is based on the guidelines described in the capability
referencing_person_organizationError C1: Capability referencing_person_organization not in dex_index.xml
, and referencing an
Organization_type
is based on the guidelines described in the capability
referencing_person_organization_typicalError C1: Capability referencing_person_organization_typical not in dex_index.xml
.
NOTE Task effectivity defined as Organization_type is represented by assigning Organization_type to the Organization via a Organization_organization_type_relationship. The Effectivity_assignment representing the "Effectivity_domain" (urn:plcs:rdl:std:Effectivity_domain) shall be assigned to the Organization. The Organization shall not be identified, and the Organization_type shall be identified by either a "Organization_type_identification_code" (urn:plcs:rdl:std:Organization_type_identification_code) or a "Organization_type_name" (urn:plcs:rdl:std:Organization_type_name) (or subclasses thereof).
The following reference data shall be applied:
Serialized item as the effectivity domain
Task effectivity defined in terms of a serialized item, is represented as a Product_as_individual defining the effectivity domain.
NOTE
Referencing a
Product_as_individual
is based on the guidelines described in the capability
referencing_product_as_individualError C1: Capability referencing_product_as_individual not in dex_index.xml
.
The following reference data shall be applied:
Lot/batch of serialized items as the effectivity domain
Task effectivity defined in terms of a lot/batch of serialized items, is represented as a Product_group defining the effectivity domain.
NOTE
Referencing a
Product_group
is based on the guidelines described in the capability
???Error C1: Capability ??? not in dex_index.xml
.
Reference data used:
NOTE ADD EFFECTIVITY RELATED TO A SPECIFIC ATTRIBUTE OF THE PRODUCT IN FOCUS E.G. VALUE_LIMIT LESS THAN 1000 KM
NOTE ADD EFFECTIVITY COMBINATIONS LIKE AND
This section is based on the guidelines described in the capabilities C010: assigning_reference_data and C093: assigning_codes. Which capability to use dependes on whether the categorizes/classes being used are defined within a reference data library or not
Task category/classification is represented as either a External_class or as a Class, depending on whether the category/classification is defined within an external reference data library or not. If the category/classification being applied is defined within an reference data library, then shall the category/classification be represented as an External_class as descibed in the capability C010: assigning_reference_data. If not, then shall the category/classification being applied be represented as a Class as descibed in the capability C093: assigning_codes.
The following reference data shall be applied for instansiation of task categorization and classification:
NOTE This DEX does not define any further classifications of the Task_method_version.
This section is based on the guidelines described in the capability C052: representing_resource.
Resources required by the task overall are represented as either Required_resource_by_resource_item or Required_resource_by_specification being assigned to the Task_method_version using Required_resource_assignment.
A required resource defined in terms of a particular item, such as a parts kit, is represented as Required_resource_by_resource_item, and shall be classified according to the role of the resource in this specific context. Valid classes are:
Where a requirement may be fulfilled by a number of different things, the required resource is described by it characteristics, e.g. a power supply or an internet connection. These are represented as Required_resource_by_specification and shall be classified according to the role of the required resource in this specific context. Valid classes are:
The simplest case of a resource requirement specification is represented by C095: assigning_descriptor, classified as "Description" (urn:plcs:rdl:std:Description), to the Required_resource_by_specification.
Quantification of a required resource is represented as a property as described in the capabilities C078: assigning_resource_properties and C079: representing_properties_numerically respectively. The Resource_property entity shall be classifed as "Quantity" (urn:plcs:rdl:std:Quantity), or subclass thereof.
NOTE Do not use the quantity attribute of Required_resource_by_resource_item and Required_resource_by_specification respectively.
The Required_resource_assignment may be classified according to aggegation level of the required resource. Examples of reference data used to define the resource quantity aggregation levels are:
Representation of required material resource
Material resources shall be represented as one or more Parts and related Part_versions. The Resource_item. resource_items attribute shall be associated with the Part_version of the respective Part. The Part and the Part_version shall be identified by "Part_identification_code" (urn:plcs:rdl:std:Part_identification_code) and "Version_identification_code" (urn:plcs:rdl:std:Version_identification_code) respectively (or subclasses thereof).
"Required_material_resource" (urn:plcs:rdl:std:Required_material_resource) may be specialized. Examples of such subclasses in PLCS RDL are:
Representation of required human resource
Required human resources may be represented somewhat differently based on whether the required human resource is defined as:
Required human resource defined by personnel type
A required human resource defined in terms of a personnel type is represented as a Type_of_person and is identified either by a "Type_of_person_identification_code" (urn:plcs:rdl:std:Type_of_person_identification_code) (or subclass thereof) or a "Type_of_person_name" (urn:plcs:rdl:std:Type_of_person_name) (or subclass thereof).
The Required_resource_by_resource_item shall be classified as "Required_personell_type" (urn:plcs:rdl:std:Required_personell_type).
A required human resource defined in terms of personnel skill is represented as a Type_of_person associated with one or many instances of Experience_type. Each instance of Experience_type represents a required skill. The text describing the required skill is represented as a descriptor being assigned to the respective instance of Experience_type.
The Required_resource_by_resource_item shall be classified as "Required_personell_skill" (urn:plcs:rdl:std:Required_personell_skill) (or subclass thereof).
NOTE An PLCS entity without an identifier is to be interpreted as a reference to a generic instance of the entity type. E.g. in figure above, Type_of_person shall be read as "A Type_of_person with a defined skill".
NOTE Skill can also be defined as a combination of personell type and personell skill, e.g. a welder (Type_of_person_name) with 5 years experience from automobile workshops (Experience_type description).
Personnel qualification / training
A required human resource defined in terms of personnel qualification/training is represented as a Type_of_person associated with one or many instances of Qualification_type. Each instance of Qualification_type represents a required qualification/training. The text describing the required qualification/training is represented as a descriptor being assigned to the respective insyance of Qualification_type. A type of qualification may also have an identification and/or a name. Both identifiers and names are represented as described in the C001: assigning_identifiers and shall be classified as "Qualification_type_identification_code" (urn:plcs:rdl:std:Qualification_type_identification_code) and "Qualification_type_name" (urn:plcs:rdl:std:Qualification_type_name) respectively (or subclasses thereof).
The Required_resource_by_resource_item shall be classified as "Required_personell_qualification" (urn:plcs:rdl:std:Required_personell_qualification).
NOTE Figure 24 shows how qualification can be defined as a combination of personell type and personell qualification e.g. a welder (Type_of_person_name) with a specific certificate (Qualification_identification_code).
NOTE An PLCS entity without an identifier is to be interpreted as a reference to a generic instance of the entity type. E.g. if the Type_of_person in figure 22 was without any identification it should have been read as "A Type_of_person with a defined qualification".
Alternative and substitute resources
Alternative and substitute resources can be represented as multiple Required_resource_by_resource_items along with a Required_resource_relationship classified as "Required_resource_alternative" (urn:plcs:rdl:std:Required_resource_alternative) and "Required_resource_substitute" (urn:plcs:rdl:std:Required_resource_substitute) respectively.
NOTE One Required_resource_relationship is required per alternative / substitute.
Resource requirements that depends upon operational environment, support level etc is represented as an Effectivity being assigned to the Required_resource_assignment. Resource effectivities are represented in the same way that has been described under section Task effectivity above. The only difference is that the Effectivity_assignment being classified as "Effectivity_target" (urn:plcs:rdl:std:Effectivity_target) is assigned to the Required_resource_assignment.
Additional information on hazardous material is provided as classification (codes) being assigned to a Part_view_definition of the respective material resource being represented as a Part.
Hazardous classification is represented as either a External_class or as a Class, depending on whether the relevant hazardous classes are defined within an external reference data library or not. If the the hazardous classes being applied are defined within an reference data library, then shall the hazardous classification be represented as an External_class as descibed in the capability C010: assigning_reference_data. If not, shall the hazardous classification being applied be represented as a Class as descibed in the capability C093: assigning_codes.
The following reference data shall be applied for instansiation of hazardous classification.
The following subclasses of "Material_hazardous_classification" (urn:plcs:rdl:std:Material_hazardous_classification) are defined within PLCS:
Required material resources may also be classified based on replacement indicator, i.e. whether it is mandatory or optional to replace a mounted item with the material resource. This represented as a classification of the Next_assembly_usage in which the Part representing the material resource is located.
Replacement indicator classification is represented as either a External_class or as a Class, depending on whether the replacement indicator classes are defined within an external reference data library or not. If the replacement indicator classes being applied are defined within a reference data library, then shall the replacement indicator classes be represented as External_class as descibed in the capability C010: assigning_reference_data. If not, shall the replacement indicator classes be represented as Class as descibed in the capability C093: assigning_codes.
The following reference data shall be applied for instansiation of replacement indicator classification:
The following subclasses of "Disassembly_replacement_classification" (urn:plcs:rdl:std:Disassembly_replacement_classification) are defined within PLCS:
Support level defined by typical organization or level of maintenance
Support level defined as a typical organization or by level of maintenance is represented as a Required_resource_by_resource_item relating to an Organization_type as the Resource_item.
The Required_resource_assignment shall be assigned to the Task_method_version_assignment representing the relationship between the task specification and the product in focus. This enables one task specification to have different support levels assigned to it for different environments or operational scenarions etc.
Reference data used:
EXAMPLE The id attribute of the assigning_identification template assigning the "Organization_type_name" (urn:plcs:rdl:std:Organization_type_name) to the Organization_type, may be populated as "First_line_maintenance", "Second_line_maintenance" etc.
Support level defined by specific organization
Support level defined as a specific organization is represented as a Required_resource_by_resource_item relating to an Organization as the Resource_item.
Reference data used:
The top item is the platform on which the product-in-focus is fitted (unless the product-in-focus is itself the top item).
EXAMPLE The top item for an aircraft engine is the aircraft. The top item for a bell is the bicycle it is fitted to.
The representation of whether a task requires that the product in focus has to be removed from its top item is done through classification of the Task_method_version_assignment representing the "Applicable_to" (urn:plcs:rdl:std:Applicable_to) relationship between the Task_method_version and the product in focus.
The on/off top item classification is done using the capability C010: assigning_reference_data.
The following subclasses of "On_plattform_classification" (urn:plcs:rdl:std:On_plattform_classification) are defined within PLCS:
The representation of task justification is based on the capability C058: representing_justification.
The reason for the existence of a task is represented as Justification being assigned to the Task_method. The Justification_assignment assigning the Justification to the Task_method shall be classified as "Task_justification" (urn:plcs:rdl:std:Task_justification) or subclass thereof.
Justification as textual description
The simples case of task justification is represented as a textual description using the Justification. description attribute.
Reference data used:
Task justified by an identified failure mode as the support driver
Task justified by an identified failure mode is represented by a Justification_support_assignment relating the Justification to a State_definition representing the defined failure mode in e.g. a FMECA (Failure Modes and Criticality and Effects Analysis) See D002: fault_states.
Reference data used:
Task justified by an identified failure mode consequence as the support driver
Task justified by an identified failure mode consequence is represented by a Justification_support_assignment relating the Justification to a State_definition representing the defined failure mode consequence in e.g. a FMECA (Failure Modes and Criticality and Effects Analysis) See D002: fault_states.
Reference data used:
The representation of task triggers is based on the capability C026: representing_condition.
A task trigger definies the condition when to perform an activity according to the task specification. The trigger is represented as a Condition being assigned to the Task_method_version_assignment representing the "Applicable_to" (urn:plcs:rdl:std:Applicable_to) relationship between the Task_method_version and the product in focus. The Condition_assignment shall be classified as "Trigger" (urn:plcs:rdl:std:Trigger) or subclass thereof.
The periodicity, state etc that activates the trigger are represented as the Condition_parameter.
Periodicities defined as intervals (duration or number of events) are represented as Independent_property, Independent_property_representation together with Value_with_unit, and Unit.
The Independent_property shall be classified as "Periodicity" (urn:plcs:rdl:std:Periodicity) or subclass thereof.
The Unit shall be classified according to the unit of measure being used. Examples of reference data are:
Error RDL1: The class Days does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xmlThe Condition shall be classified as "Computable_condition" (urn:plcs:rdl:std:Computable_condition).
NOTE The capability C084: representing_property_value_ranges describes how to represent values other then Value_with_unit such as e.g. Value_with_tolerances. The Units shall be classified according to the unit of measure being used. Examples of reference data is given above.
Triggers described as text have a somewhat different representation. Firstly, the Condition shall be classified as "Text_based_condition" (urn:plcs:rdl:std:Text_based_condition), which implies that the condition is not computable. Secondly, the value of the condition shall be represented as a description being assigned to the Condition (as described in the capability C095: assigning_descriptor).
Triggers that are initiated as the result of a state transition shall be using State_definition as the Condition_parameter. The State_definition shall be classified in accordance with the defined state that triggers the task.
NOTE A better way to represent this would have been to use State_transition_definition as the Condition_parameter. However, this is not allowed in the existing vesrion of ISO 10303-239 PLCS. This has been raised as an issue against the module State characterized.
Alternative task trigger conditions shall be using Condition_relationship as the Condition_parameter. The Condition being assigned to the Task_method_version_assignment shall be classified as "Compound_condition" (urn:plcs:rdl:std:Compound_condition) and The Condition_relationship shall be classified as "OR" (urn:plcs:rdl:std:OR). The Conditions that defines the respective trigger condition shall be represented as described above, including the classification of whether the conditions are described as text or whether they are computable.
Task trigger applicability shall be represented as a Condition_relationship, where Condition_relationship. relating_condition attribute refers to the condition describing the trigger, and the Condition_relationship. related_condition attribute describes the applicability.
The Condition being assigned to the Task_method_version_assignment shall be classified as "Condition_with_applicability" (urn:plcs:rdl:std:Condition_with_applicability) and the Condition_relationship shall be classified as "Condition_applicability" (urn:plcs:rdl:std:Condition_applicability). The Condition that defines the trigger condition shall be represented as described above, including the classification of whether the conditions are described as text or whether they are computable. The the Condition representing the applicability definition referencing to other entities shall be classified as "Computable_condition" (urn:plcs:rdl:std:Computable_condition).
Applicability domains that is defined by other entities in the model shall be represented as the Condition_parameter. parameter. Valid applicability domains are:
NOTE For more detailed representations of applicability / effectivity domains see section 'Task effectivity/applicability' above.
NOTE A better way to represent trigger applicability would have been to use Effectivity_assignment assigned to the Condition_assignment representing the trigger assigned to the Task_method_version_assignment. However, this is not allowed in the existing version of ISO 10303-239 PLCS. This has been raised as an issue against the module Condition characterized.
NOTE Add description on how to represent that the frequency of scheduled task triggers may change over time, e.g. the first two services are executed every 500 km, thereafter every 1000 km.
An applicability described as text is represented using "Description" (urn:plcs:rdl:std:Description) as described in the capability C095: assigning_descriptor. The "Description" (urn:plcs:rdl:std:Description) shall be assigned to the Condition representing the "Applicability" (urn:plcs:rdl:std:Applicability).
The Condition shall also be classified as "Text_based_condition" (urn:plcs:rdl:std:Text_based_condition).
Examples of event based task triggers are:
This section is based on the guidelines described in the capability C088: representing_task_structure.
Task specifications including pre-, core- and post-condition tasks shall always use Task_element_sequence to organize the respective task step. Each task step is represented as a member of the Task_element_sequence. elements attribute.
Pre and post condition task(s) are always represented as Decision_point which determines whether the pre/post condition task needs to be performed. If the evaluation of the condition is TRUE then shall the defined task be carried out. The task specification is represented as a subtype of Task_element. The following subtypes of Task_element are valid for the representation of pre and post condition tasks respectively.
The subclass of Decision_point representing the pre and post condition task(s) skall be classified as "Pre_condition_task" (urn:plcs:rdl:std:Pre_condition_task) and "Post_condition_task" (urn:plcs:rdl:std:Post_condition_task) respectively.
The figure below illustrates references to external task specifications as the pre and post condition tasks.
The figure below illustrates how to represent a textual description of the pre and post condition task specifications, as part of the task specification under consideration.
NOTE
Pre conditions tasks may describe, or refer to, descriptions on how to remove the
product in focus from its physical location. A complete description of the removal route
may be defined as a separate task being invoked by the pre condition task. A reference to a document
describing the removal route is represented as a
Document
being assigned to the pre condition task in the role of
"Document_reference"
(urn:plcs:rdl:std:Document_reference). For more information on assigning documents
see the capability referencing_documentsError C1: Capability referencing_documents not in dex_index.xml
.
This section is based on the guidelines described in the capability C088: representing_task_structure.
Tasks that includes pre and post conditions that has to be fulfilled in order to start/end a task shall be represented as a Task_element_sequence. The first element in the sequence contains the pre condition and the specfication of the task that shall be performed when the pre condition is fulfilled. This is represented as a pair of Decision_point and Task_element. The second element in the sequence contains the post condition. This is represented as a pair of Decision_point and End_task.
Product and/or environmental states that has to be fulfilled before starting/ending the task under consideration are represented as Condition(s) being referenced by the respective Decision_point.
The conditions defining the required states are represented as State_definition. This can represent both environmental states, operating states and product states.
The figure below illustrates pre and post conditions of the core task, where the core task is described as text.
NOTE Pre and post conditions also applies to pre and post condition tasks.
In figure 43 above, the pre and post conditons are applied to the core task (Task_element_sequence classified as "Core_task" (urn:plcs:rdl:std:Core_task)). The Decision_points are classifed as "Pre_condition" (urn:plcs:rdl:std:Pre_condition) and "Post_condition" (urn:plcs:rdl:std:Post_condition) respectively.
Pre and post condition applicability
Each pre and post condition may have a defined applicability, e.g. environmental, operating state or product context.
Pre and post condition applicability are represented as Effectivity being assigned to the respective Decision_point. Pre and post condition applicability are represented in the same way that has been described under section Task effectivity above. The only difference is that the Effectivity_assignment being classified as "Effectivity_target" (urn:plcs:rdl:std:Effectivity_target) is assigned to the Decision_point.
Warnings and/or cautions provided in order to ensure legal, health and safety issues are represented as Advisory_task_step included in the Task_element_sequence or Concurrent_elements representing the pre, core or post task.
The Advisory_task_step shall be classified according to the type of safety advisior. Examples of classes are:
The text containing the description of the legal, health and safety advisor is represented as a descriptor, as described in the capability C095: assigning_descriptor The descriptor shall be of class "Description" (urn:plcs:rdl:std:Description).
NOTE ADD references to documents. Task references just deals with Task references.
NOTE ADD applicability/effectivity of safety advisor
Elapsed times for execution of the task are represented as properties being assigned to the Task_method_version_assignment representing the "Applicable_to" (urn:plcs:rdl:std:Applicable_to) relationship between the Task_method_version and the product in focus.
The Assigned_property shall be classified as "Task_elapsed_time" (urn:plcs:rdl:std:Task_elapsed_time) or subclass thereof, such as:
The Unit shall be classified according to the unit of measure being used. Expected reference data are:
Error RDL1: The class Days does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xmlThe Assigned_property may also be classified based on the method by which the property has been set. Expected reference data are:
Task elapsed time may have a defined applicability/effectivity.
NOTE ADD the possibility to add a note to the elapsed time
References to related documents are represented as Document_version being assigned to the Task_method_version that represents the task specification.
The Document is identified by its "Document_identification_code" (urn:plcs:rdl:std:Document_identification_code) and optionally by "Document_name" (urn:plcs:rdl:std:Document_name) (or subclasses thereof). The Document_version is identified by its "Progression_identification_code" (urn:plcs:rdl:std:Progression_identification_code), or subclass thereof.
The Document_assignment needs to be classified in order to distinguish between documents being assigned in different roles. In this case shall the Document_assignment be classified as "Document_reference" (urn:plcs:rdl:std:Document_reference).
References to other task specifications which could be executed at the same time as the task under consideration are represented as Task_method_version_relationship classified as "Opportunistic_task" (urn:plcs:rdl:std:Opportunistic_task).
The opportunistic task is identified through its version ( "Version_identification_code" (urn:plcs:rdl:std:Version_identification_code), "Variant_identification_code" (urn:plcs:rdl:std:Variant_identification_code)), or subclasses thereof) and its task identification ( "Task_method_identification_code" (urn:plcs:rdl:std:Task_method_identification_code), "Task_method_name" (urn:plcs:rdl:std:Task_method_name) or subclasses thereof).
This section is based on the capability C095: assigning_descriptor.
A note shall be represented as a descriptor being assigned to the Task_method_version in the role of "Note" (urn:plcs:rdl:std:Note).
Specification of reporting requirement on the execution of the task, including:
Detailed specification on how to carry out the task containing:
NOTE ADD task step applicability/effectivity e.g. based on a modification of the product. There might also be alternative task steps.
Task specification administrative information includes:
NOTE Ownership means the right to create new versions of the task specifications, and the right to change the status of existing versions. There is also other forms of ownerships such as copyright and intellectual property.