ISO 10303-239 Representation

The following sections provide a detailed description on how to represent an aviation maintenance feedback DEX using ISO 10303-239 PLCS. This is defined using PLCS capabilities, templates and PLCS reference data.

This definition may be further tailored by specific parties by extending the reference data defined in the PLCS reference data library.

The information to be exchanged by the Aviation Maintenance DEX has been summarised in Figure 6 in Aviation maintenance: Business Information Overview. A more detailed definition of the type of information that can be exchanged using the Aviation Maintenance DEX is provided by the UML class diagrams in Aviation maintenance - Business Information Requirements Figure 7 and Figure 8. A summary of how this information is represented in PLCS is provided in Figure 9 and expanded in subsequent sections.

Figure 9 —  Overview of PLCS constructs used to represent maintenance feedback information

Figure 9 shows:

Template: #0 representing_message - Message

The template representing_message is used to represent a message containing the meta data about the message. See Representing a message for details.

Template: #1 representing_product_as_realized - Product In Focus

The template representing_product_as_realized is used to represent the Product In Focus. See Representing a Product In Focus for details.

Template: #2 representing_product_usage - Activity performed by Product In Focus

The template representing_product_usage is used to represent an activity, such as a sortie or engine run, that has been performed by the Product In Focus. See Representing a Product In Focus usage activity for details.

Template: #3 assigning_observation - Symptom

The template assigning_observation is used to represent a symptom that was observed during the usage of the product, such as a sortie. See Representing state of a Product In Focus for details.

Template: #4 representing_work_request - Request for work

The template representing_work_request is used to represent a initial request for work - frequently initiated after a symptom has been observed. See Representing state of a Product In Focus for details.

Template: #5 representing_work_order - Maintenance work order

The template representing_work_order is used to represent the authority to undertake work - a maintenance work order. The work may be an engineering instruction to implement a modification, standard scheduled or unscheduled maintenance for which there is a defined task. The type of activity that is authorized, such as maintenance, installation, repair/overhual is provided by classifying the activity - see template #5a Type of directed activity assigning_reference_data. See Representing a maintenance work order for details.

Template: #6 assigning_asserted_state - Fault state

The template assigning_asserted_state is used to represent a fault that has been identified on a Product In Focus. If the fault is to be rectified by the maintenance work order, then it is related to the template #5 representing_work_order by the template assigning_activity. See Representing state of a Product In Focus for details.

Template: #7 representing_work_done - Record of work done

The template representing_work_done is used to represent the work or activity that has been undertaken on the Product In Focus. The work done is a record of the fact that the authorised work (template #5 representing_work_order) has been started. The type of activity that has been undertaken, such as maintenance, installation, repair/overhual is provided by classifying the activity - see template #7a Type of activity assigning_reference_data. See Representing a Product In Focus maintenance activity for details.

Template: #8 representing_typical_activity - Method used to do work

The template representing_typical_activity is used to represent the method used to undertake the activity. If this method is defined by a specified task, then it is related to the template #9 referencing_task. See Representing a Product In Focus maintenance activity for details.

Template: #9 referencing_task - Maintenance task

The template referencing_task is used to represent a standard maintenance task. A task for which there is a specification or set of procedures defined. See Representing a maintenance work order for details.

Template: #10 assigning_process_property - Maintenance activity properties

The template assigning_process_property is used to represent properties of the activity that has been undertaken on the Product In Focus, such the duration of the task. See Representing a Product In Focus maintenance activity for details.

Template: #11 assigning_person_in_organization - Person performing activity

The template assigning_person_in_organization is used to represent the person who undertook the activity. See Representing a Product In Focus maintenance activity for details.

Template: #12 assigning_asserted_state - Serviceability status

The template assigning_asserted_state is used to represent the serviceability state of the Product In Focus See Representing state of a Product In Focus for details.

Template: #13 assigning_product_property - Properties of the Product In Focus

The template assigning_product_property is used to represent properties of the Product In Focus such as life measurements. See Representing properties on a Product In Focus for details.

Template: #14 assigning_location - Location of the Product In Focus

The template assigning_location is used to represent the location of the Product In Focus. See Representing Product In Focus location for details.

Template: #15 representing_assembly_structure - Product In Focus installation history

The template representing_assembly_structure is used to represent the installation history of a Product In Focus. See Representing installation/removal position on an aircraft for details.

Template: #16 assigning_realized_resource - Parts consumed

The template assigning_realized_resource is used to represent the spare parts fitted and removed during a maintenance activity. See Representing resource: replaced parts for details.

Template: #17 assigning_realized_resource - Resources consumed

The template assigning_realized_resource is used to represent the hours taken by a particular trade, such as electrician, to do the work. See Representing resource: trades used for details.

The remainder of this section provides more details how the information summarized previously is represented using PLCS. It comprises the following:

• Representing a message
• Representing a maintenance work order
• Representing a Product In Focus maintenance activity
• Representing a Product In Focus
• Representing properties on a Product In Focus
• Representing resource: replaced parts
• Representing installation/removal position on an aircraft
• Representing a Product In Focus usage activity
• Representing state of a Product In Focus
• Representing Product In Focus location
• Representing related components
• Representing change of Part Number, Serial Number, and Stock Code / Stock Number
• Representing Inventory Gain and Loss
• Representing Task extensions

Each section contains a UML class diagram that provides an overview of the data to be exchanged, a description of the UML classes and then a definition of how that information is represented in PLCS. The information that is shown in UML class diagram is intended to provide guidance for the type of information that can be represented by the DEX. As different systems and business processes may not support or require the information the DEX does not mandate that all the information shown is exchanged.

NOTE    For each template, a table is provided detailing the values for each template parameter, Where the value is to be set by the sending system, value is shown with a ? at the start and end. E.g. ?org_id?.

Representing a message

Business information

Information will be extracted and packaged as a message which is then sent to a recipient.

The information associated with a message is summarized in the UML class diagram in Figure 10. This is a subset of the UML diagrams shown in Figure 8 in Aviation maintenance Business Information Requirements - Message and Figure 7 in Aviation maintenance Business Information Requirements - Information. This shows the meta data for message, and the activity being reported on in the message - the subclasses of Reportable_activity. The information associated with the activities is detailed in subsequent sections.

NOTE    The information shown in the UML class diagram in Figure 10 is intended to illustrate the type of information that can be represented by the DEX. It does not imply that all exchanges must contain this information.

Figure 10 —  UML class diagram representing a message

PLCS representation

The following section describes how ISO 10303-239 PLCS is used to represent a message. This is summarised in Figure 11 below.

Extracted information should be packaged as a message which is then sent to the recipient. The Message containing the reported activity is represented in ISO 10303-239 PLCS by template table: Template #1(Figure 11) which instantiates Message described in the capability C014: messaging. Message meta data is then assigned to the Message. If the person or organization who sent and received the message is required it is represented by assigning_person_in_organization as shown below in template table: Template #6(Figure 11) and assigning_organization as shown below in template table: Template #7(Figure 11). If the date extract of the data is required this is represented by assigning_time, as shown below in template table: Template #4(Figure 11), and described in the capability C036: assigning_date_time. If contract identification information is required this is represented by assigning_contract, as shown below in template table: Template #3(Figure 11), and described in the capability C083: representing_contract. If security information is required this is represented by assigning_security_classification, as shown below in template table: Template #5(Figure 11) , and described in the capability C089: representing_security.

In addition to the message meta data, the content of the message is identified. This is represented by linking the Message to the activities that are reported by the message via the Content_item_selected entity and message_content_item select. If the DEX is reporting on:

• an activity performed by the product, such as a sortie flown, then the message links to the representing_product_usage representing the activity, as shown in #8 of Figure 11;
• a request for work as result of a symptom being identified, then the message links to the representing_work_request representing the request for work, as shown in #9 of Figure 11;
• the raising of work order to undertake some work on the product, then the message links to the representing_work_order representing the work order, as shown in #10 of Figure 11;
• work that has been done to a product, such as a maintenance activity, then the message links to the representing_work_done representing the work undertaken, as shown in #2 of Figure 11;
• symptoms observed on a product, then the message links to the assigning_observation, as shown in #11 of Figure 11;
• an inventory gain/loss event, then the message links to Resource_event.

NOTE    When the message is reporting on work done, the work done will refer back to the work order. The linking of the message to the representing_work_order should only be done when the work order has been raised. When the work authorised by the work order has started or completed the linking should be to the representing_work_done.

The message content templates identified above will refer to, or be referenced by, other templates representing the rest of the message content. E.g the Product In Focus, properties on the Product In Focus etc.

The message is normally contains one business transaction. E.g. contains one work order. If however, the message is required to contain a number of business transactions, e.g. multiple work orders, then the additional content, e.g. work orders, is represented by instantiating multiple occurrences of the Content_item_selected item, instantiated by the template representing_message, and linking this to the message and content.

Figure 11 —  EXPRESS-G diagram for identifying a message and its envelope

The following templates are used in Figure 11 to represent a message:

Template #1 (Figure 11): representing_message Hide template parametersHide all template parametersShow all template parameters
Description	The package of data to be exchanged
Parameter name:	Parameter value:	Parameter description:
rep_msg_id	?rep_msg_id?	the identifier of the message
rep_msg_id_class_name	"Message identification code" (urn:plcs:rdl:std:Message identification code)	The name of the class being used to classify the identification (Identification_assignment) of the message. This provides the role or reason for the identification.
rep_msg_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the rep_msg_id_class_name.
rep_msg_id_owner	?rep_msg_id_owner?	The identifier or name of the organization that "owns" the message identifier.
rep_msg_id_owner_class_name	?rep_msg_id_owner_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
rep_msg_id_owner_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the cnt_org_id_class_name class items.
date_class_name	"Date actual extraction" (urn:plcs:rdl:std:Date actual extraction)	The name of the class being used to classify the role date assignment, e.g. the message sending date.
date_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the date_class_name class items.
year	?year?	The 'year' component of: the date the data was extracted from the source system.
month	?month?	The 'month' component of: the date the data was extracted from the source system .
day	?day?	The 'day' component of: the date the data was extracted from the source system. This can be in local time or UTC
hour	?hour?	The 'hour' component of: the date the data was extracted from the source system. This can be in local time or UTC.
minute	?minute?	The 'minute' component of: the date the data was extracted from the source system. This can be in local time or UTC.
second	?second?	The 'second' component of: the date the data was extracted from the source system. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
ap239_id_class_name	[AP239_version] Error RDL1: The class AP239_version does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml	The name of the class being used to classify the Message as a container of ISO 10303-239 data of a given version. The subclasses identify the version of ISO 10303-239 to which the data in the message conforms. A subclass of the following is to be used.
ap239_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the ap239_id_class_name class items.
dex_id_class_name	"AViation maintenance DEX version 1" (urn:plcs:rdl:std:AViation maintenance DEX version 1)	The name of the class being used to classify the Message as a container of an identified DEX. The subclasses define the DEX to which the data in the message conforms. A subclass of the following is to be used.
dex_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the dex_id_class_name class items.
content	Activity_actual	This is the activity that is represented as a Activity_actual which is part of template representing_work_done.

The templates used to describe the content of the message is detailed in subsequent sections. Namely:

• The use of template #8 representing_product_usage to represent an activity performed by the product is the same as template table: Template #1(Figure 39) described in Representing a Product In Focus usage activity;
• The use of template #9 representing_work_request to represent a request for work is the same as template table: Template #9(Figure 24) described in Representing state of a Product In Focus;
• The use of template #10 representing_work_order to represent the work order raised is the same as template table: Template #4(Figure 13) described in Representing a maintenance work order;
• work that has been done to a product, such as a maintenance activity, then the message links to The use of template #2 representing_work_done to represent the work undertaken is the same as template table: Template #3(Figure 13) described in Representing a maintenance work order.

Representing a maintenance work order

Business information

Maintenance activities that are performed on an aircraft normally require a level of authorization. This can be represented by a maintenance work order. The information that can be associated with a maintenance work order is summarized in the UML class diagram in Figure 12. This is a subset of the UML diagrams shown in Figure 8 in Aviation maintenance Business Information Requirements - Message and Figure 7 in Aviation maintenance Business Information Requirements - Information.

NOTE    The information shown in the UML class diagram in Figure 12 is intended to illustrate the type of information that can be represented by the DEX. It does not imply that all exchanges must contain this information.

Figure 12 —  UML model representing a maintenance work order

PLCS representation

The following section describes how ISO 10303-239 PLCS is used to represent a maintenance work order. This is summarised in Figure 13 below.

A work order is required to conduct work on an aircraft. Work orders are the authority to conduct an activity on a Product_In_Focus.

A work order is represented by an instance of Work_order which is defined as part of the template representing_work_order, as shown below in template table: Template #4(Figure 13).

The type of activity that is authorized, such as maintenance, installation, repair/overhual is provided by classifying the activity by using the template assigning_reference_data, as shown below in template table: Template #18(Figure 13).

The work order is normally raised against a particular Product In Focus, the item for which work is required. The Product In Focus is represented by the template representing_product_as_realized, as shown in #2 of Figure 13 and described in the capability C045: representing_product_as_individual. The work order is related to the representing_product_as_realized by an Applied_activity_assignment within template representing_work_order, as shown below in template table: Template #4(Figure 13). The work order may also be raised against the end item, the item to which the Product In Focus is fitted. The end item is represented by the template representing_product_as_realized, as shown in #9 of Figure 13, and related to the work order by the template assigning_activity, as shown below in template table: Template #1(Figure 13). The end item is related to the Product In Focus by the template representing_promissory_usage, as shown in #8 of Figure 13, and described in the capability C003: representing_assembly_structure. Representing a Product In Focus provides details of how a Product In Focus is represented.

A work order identifies the method by which the authorised activity is to be done - a standard maintenance task. This is a description of the work to be done or a more formal task specification. The informal description is represented by the template representing_typical_activity, as shown in #5 of Figure 13. Where a formal task specification is available, the template referencing_task, as shown in #17 of Figure 13, is used to identify the task. The task is related to the typical activity by the entity Activity_method_realization.

The work order can have a status which is represented by template assigning_asserted_state, as shown below in template table: Template #12(Figure 13), and described in the capability C041: representing_state_observed. The work order can record a date on which the authorized work was planned to start, a date it was planned to end and the date that the work was actually completed; these are represented by the template assigning_time, as respectively shown below in template table: Template #15(Figure 13), template table: Template #16(Figure 13), and template table: Template #13(Figure 13), and described in the capability C036: assigning_date_time. The organization that raises the work order can be record; this is represented by template assigning_organization, as shown below in template table: Template #19(Figure 13), and described in the capability C094: assigning_organization. The work order can record the organization that conducts the maintenance; this is represented by template assigning_organization, as shown below in template table: Template #10(Figure 13), and described in the capability C094: assigning_organization. The work order can record information about the type of organization that conducts the maintenance, e.g. the line of repair (first line, second line); this is represented by template assigning_reference_data, as shown below in template table: Template #11(Figure 13), and described in the capability C010: assigning_reference_data. The work order can record the description of the work order; this is represented by template assigning_descriptor, as shown below in template table: Template #14(Figure 13), and described in the capability C095: assigning_descriptor.

The relationship between two work orders or a work order and an engineering instruction is represented by Activity_relationship. This relates the authorised activity (Directed_activity) instantiated by the work order (template representing_work_order, as shown below in template table: Template #4(Figure 13)) to the authorised activity (Directed_activity) of the related work order or engineering instruction instantiated by the template referencing_work_order, as shown below in template table: Template #7(Figure 13) and template table: Template #6(Figure 13).

The activity identifying the work done on the Product In Focus that was authorised by the maintenance work order is represented by template representing_work_done, as shown below in template table: Template #3(Figure 13), and described in the capability C064: representing_work_done. Representing Product In Focus maintenance activity provides details of how to represent the work done.

Figure 13 —  EXPRESS-G diagram for work order

The following templates are used in Figure 13 to represent the maintenance work order:

The use of template #2 representing_product_as_realized in Figure 13 is identical to, and described in, template table: Template #1(Figure 18).

Template #4 (Figure 13): representing_work_order Hide template parametersHide all template parametersShow all template parameters
Description	The authority to perform the work.
Parameter name:	Parameter value:	Parameter description:
id	?id?	The identifier assigned to the work order
id_class_name	"Work order identification code" (urn:plcs:rdl:std:Work order identification code)	The name of the class used to classify the identifier and so provide the role or reason for the identification.
id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the @id_class_name class
org_id	?org_id?	The identifier of the organization that "owns" the identifier.
org_id_class_name	?org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the org_id_class_name class items.
date_class_name	"Work order issue date" (urn:plcs:rdl:std:Work order issue date)	The date the Work_order raised.
date_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the date_name class items.
year	?year?	the year component of the start date and time of the work order was raised
month	?month?	the month component of the start date and time of the work order was raised
day	?day?	the day component of the start date and time of the work order was raised. This can be in local time or UTC
hour	?hour?	the hour component of the start date and time of the work order was raised. This can be in local time or UTC
minute	?minute?	the minute component of the start date and time of the work order was raised. This can be in local time or UTC
second	?second?	the second component of the start date and time of the work order was raised. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
act_id	?act_id?	The version identifier assigned to the work order
act_id_class_name	"Activity identification code" (urn:plcs:rdl:std:Activity identification code)	The name of the class used to classify the identifier in parameter @act_idand so provide the role or reason for the identification.
act_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the @act_id_class_name class
act_org_id	?act_org_id?	The identifier of the organization that "owns" the version identifier.
act_org_id_class_name	?act_org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
act_org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the act_org_id_class_name class items.
appr_status	[Status_of_approval] Error RDL1: The class Status_of_approval does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml	The class name of the External_class corresponding to the approval status of the work order.
appr_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the act_org_id_class_name class items.
input	The Product_as_individual_view template instantiated in #2 of Figure 13.	The Product In Focus that is the subject of the work order, represented as Product_as_individual_view which is part of template representing_product_as_realized.
in_response_to	The Work_request template instantiated by template table: Template #6(Figure 13) or template table: Template #7(Figure 13).	The work request that caused the work order.
chosen_method	The Activity_method template instantiated by #5 of Figure 13.	The method used to do the work represented as Activity_method which is part of template representing_typical_activity.
appr_pers_org	The Person_in_organization template instantiated by template table: Template #4a(Figure 13). instantiated by representing_person_in_organization or instantiated by Organization representing_organization	The person or organization that approved the work order.

The use of template #5 representing_typical_activity in Figure 13 is identical to, and described in, template table: Template #1(Figure 15).

The use of template #8 representing_promissory_usage in Figure 13 is identical to, and described in, template table: Template #2(Figure 30).

The use of template #9 representing_product_as_realized in Figure 13 is identical to, and described in, template table: Template #1(Figure 18).

The use of template #17 referencing_task in Figure 13 is identical to, and described in, template table: Template #2(Figure 15).

Template #18 (Figure 13): assigning_reference_data Hide template parametersHide all template parametersShow all template parameters
Description	Type of directed activity
Parameter name:	Parameter value:	Parameter description:
class_name	[Maintenance_activity] Error RDL1: The class Maintenance_activity does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml	The name of the External_class being used.
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the definition for the class being used.
items	The Directed_activity template instantiated by template table: Template #4(Figure 13).	The authorized planned work represented as a Directed_activity which is part of template representing_work_order.

Representing Product In Focus maintenance activity

Business information

The Aviation maintenance DEX is used to report on a number of different maintenance activities performed on a Product In Focus. These are summarized in Aviation maintenance - Reportable activities. and include:

• Repair and Overhaul;
• Removal;
• Installation;
• Controlled exchange;
• Maintenance tasks.
• Lifing extensions;
• Scheduled tasks;
• Part number change information

The information necessary to record a maintenance activity performed on a Product In Focus can be summarized by the UML class diagram shown in Figure 14. This is a subset of the UML diagrams shown in Figure 8 in Aviation maintenance Business Information Requirements - Message and Figure 7 in Aviation maintenance Business Information Requirements - Information.

NOTE    The information shown in the UML class diagram in Figure 14 is intended to illustrate the type of information that can be represented by the DEX. It does not imply that all exchanges must contain this information.

Figure 14 —  Model representing Product In Focus maintenance activity

PLCS representation

The following section describes how ISO 10303-239 PLCS is used to represent a maintenance activity. This is summarised in Figure 15 below.

The maintenance activity is a record of an activity that has been carried out on a product. It is represented in ISO 10303-239 PLCS by an Activity_actual, which is part of template representing_work_done, as shown in #5 of Figure 15.

The type of activity that has been undertaken, such as maintenance, installation, repair/overhual is provided by classifying the Activity_actual by using template assigning_reference_data, as shown below in template table: Template #24(Figure 15).

The approval status of the activity, i.e. a record of who approved or signed off the work that has been completed, is given in template assigning_approval, as shown below in template table: Template #25(Figure 15).

The template representing_work_order, as shown in #3 of Figure 15, is used to represent a maintenance work order which is the authority to undertake the work. The template representing_typical_activity, as shown below in template table: Template #1(Figure 15) is used identify the method used to perform the activity. The template referencing_task, as shown below in template table: Template #2(Figure 15), can be used to identify the standard maintenance task that the method used to perform the activity was based on. A standard maintenance task is one where there is a set of procedures or a specification defined.

The Product In Focus that is the focus of the activity, and is input to the activity is represented by the template representing_product_as_realized, as shown in #4 of Figure 15. If the activity causes a change of identification of the item, such as changes to the part number or serial number then this is represented by another instance of the template #6 representing_product_as_realized, as shown in #6 of Figure 15 related to the template representing_work_done, as shown in #5 of Figure 15, via the template assigning_activity, as shown below in template table: Template #9(Figure 15).

The time and date when the maintenance activity was actually started is represented by template assigning_time, as shown below in template table: Template #12(Figure 15) and the time and date that the activity was reported, , as shown below in template table: Template #8(Figure 15). The person who completed the work is represented by the template assigning_person_in_organization, as shown below in template table: Template #23(Figure 15). The person who reported the work by, as shown in #7 of Figure 15.

NOTE    Where the organization, rather than the person in the organization is being recorded, use the template assigning_organization instead of assigning_person_in_organization.

The resources, such as spare parts and trades e.g. electrician used to perform the activity are represented by template assigning_realized_resource, as shown in #13 of Figure 15. The representation of resources is discussed further in Representing resource: replaced parts and Representing resource: trades used.

Properties such as the time taken to perform the activity can also be recorded, represented by templates #14, #16, #18, #20 assigning_process_property, as shown below in template table: Template #14(Figure 15), template table: Template #16(Figure 15), template table: Template #18(Figure 15), and template table: Template #20(Figure 15), and and templates process_property_numeric, as shown below in template table: Template #15(Figure 15), template table: Template #17(Figure 15), template table: Template #19(Figure 15), and template table: Template #21(Figure 15).

If any notes, remarks or comments are to be noted about the maintenance activity these are represented by template assigning_descriptor, as shown below in template table: Template #22(Figure 15).

The maintenance activity is described in template representing_work_done, as shown in #5 of Figure 15.

Figure 15 —  EXPRESS-G diagram for Product In Focus maintenance activity

The following templates are used in Figure 15 to represent a maintenance activity:

The use of template #3 representing_work_order in Figure 15 is identical to, and described in, template table: Template #4(Figure 13).

The use of template #4 representing_product_as_realized in Figure 15 is identical to, and described in, template table: Template #1(Figure 18) for the item that is the focus of the maintenance activity.

The use of template #5 representing_work_done in Figure 15 is identical to, and described in, template table: Template #3(Figure 13).

The use of template #6 representing_product_as_realized in Figure 15 is identical to, and described in, template table: Template #1(Figure 18) for the item that is the output of the maintenance activity when the identification information has changed, such as part number, serial number.

The use of template #13 assigning_realized_resource in Figure 15 is identical to, and described in, template table: Template #2(Figure 35).

Template #15 (Figure 15): process_property_numeric Hide template parametersHide all template parametersShow all template parameters
Description	Numeric property value and unit.
Parameter name:	Parameter value:	Parameter description:
value	?value?	the actual value of the time taken to complete the activity
unit	?unit?	Where unit is in hours use: [Hour] Error RDL1: The class Hour does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml Where unit is in minutes use: [Minute] Error RDL1: The class Minute does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in seconds use: [Second] Error RDL1: The class Second does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in days use: [Day] Error RDL1: The class Day does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in man hours use: [Man_hour] Error RDL1: The class Man_hour does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml .
unit_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the unit name referenced by the parameter @unit.
si_unit	?si_unit?	'true' if an SI unit, 'false' if not
context	'Numerical_representation_context'	The name of the class being used to classify the Representation_context of the property.
context_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @context.
property	The Activity_property entity instantiated by the template assigning_process_property template instantiated by template table: Template #14(Figure 15).	The target of the template, i.e. the Activity_property (or template assigning_process_property) to which the Activity_property_representation is related.

Template #17 (Figure 15): process_property_numeric Hide template parametersHide all template parametersShow all template parameters
Description	Numeric property value and unit.
Parameter name:	Parameter value:	Parameter description:
value	?value?	the expected value of the time taken to complete the activity
unit	?unit?	Where unit is in hours use: [Hour] Error RDL1: The class Hour does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in minutes use: [Minute] Error RDL1: The class Minute does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in seconds use: [Second] Error RDL1: The class Second does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in days use: [Day] Error RDL1: The class Day does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in man hours use: [Man_hour] Error RDL1: The class Man_hour does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml .
unit_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the unit name referenced by the parameter @unit.
si_unit	?si_unit?	'true' if an SI unit, 'false' if not
context	'Numerical_representation_context'	The name of the class being used to classify the Representation_context of the property.
context_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @context.
property	The Activity_property entity instantiated by the template assigning_process_property template instantiated by template table: Template #16(Figure 15).	The target of the template, i.e. the Activity_property (or template assigning_process_property) to which the Activity_property_representation is related.

Template #19 (Figure 15): process_property_numeric Hide template parametersHide all template parametersShow all template parameters
Description	Numeric property value and unit.
Parameter name:	Parameter value:	Parameter description:
value	?value?	the value of the time accomplished on the activity
unit	?unit?	Where unit is in hours use: [Hour] Error RDL1: The class Hour does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in minutes use: [Minute] Error RDL1: The class Minute does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in seconds use: [Second] Error RDL1: The class Second does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in days use: [Day] Error RDL1: The class Day does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml . Where unit is in man hours use: [Man_hour] Error RDL1: The class Man_hour does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml .
unit_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the unit name referenced by the parameter @unit.
si_unit	?si_unit?	'true' if an SI unit, 'false' if not
context	'Numerical_representation_context'	The name of the class being used to classify the Representation_context of the property.
context_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @context.
property	The Activity_property entity instantiated by the template assigning_process_property template instantiated by template table: Template #18(Figure 15).	The target of the template, i.e. the Activity_property (or template assigning_process_property) to which the Activity_property_representation is related.

Template #21 (Figure 15): process_property_numeric Hide template parametersHide all template parametersShow all template parameters
Description	Numeric property value and unit.
Parameter name:	Parameter value:	Parameter description:
value	?value?	The value of the percentage complete of the activity
unit	[Percentage] Error RDL1: The class Percentage does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml	The name of the unit in which the value is expressed, referenced through an External_class.
unit_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the unit name referenced by the parameter @unit.
si_unit	?si_unit?	'true' if an SI unit, 'false' if not
context	'Numerical_representation_context'	The name of the class being used to classify the Representation_context of the property.
context_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @context.
property	The Activity_property entity instantiated by the template assigning_process_property template instantiated by template table: Template #20(Figure 15).	The target of the template, i.e. the Activity_property (or template assigning_process_property) to which the Activity_property_representation is related.

Template #24 (Figure 15): assigning_reference_data Hide template parametersHide all template parametersShow all template parameters
Description	Type of activity done
Parameter name:	Parameter value:	Parameter description:
class_name	[Maintenance_activity] Error RDL1: The class Maintenance_activity does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml	The name of the External_class being used.
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the definition for the class being used.
items	The Activity_actual template instantiated in #5 of Figure 15.	The activity to which the activity type is assigned. This is the activity that is represented as a Activity_actual which is part of template representing_work_done.

Representing a Product In Focus

Business information

The subject of the activity that is referenced in the Aviation Maintenance messages is referred to as the Product In Focus. It is normally the aircraft or component on the aircraft on which the activity was undertaken.

The Product In Focus is identified by the part number, serial number and stock code / stock number of the organization that manufactured the part, as shown in Figure 16. This is a subset of the UML diagrams shown in Figure 5 in Aviation maintenance Business Information Requirements - Message and Figure 7 in Aviation maintenance Business Information Requirements - Information.

NOTE    The information shown in the UML class diagram in Figure 16 is intended to illustrate the type of information that can be represented by the DEX. It does not imply that all exchanges must contain this information.

Figure 16 —  UML model representing a Product_In_Focus

PLCS representation

The following section describes how ISO 10303-239 PLCS is used to represent a Product In Focus. This is summarised in Figure 17 and Figure 18 below. To clarify understanding Figure 17 shows the principal entities and templates used. Figure 18 shows the same information, but uses the the templates representing_product_as_realized and referencing_part which instantiate a number of the principal entities as indicated in Figure 17.

The Product In Focus is a physical product, therefore is represented in ISO 10303-239 PLCS by a Product_as_individual. This is described in the capability C045: representing_product_as_individual and instantiated by the template representing_product_as_realized, as shown below in template table: Template #1(Figure 18).

The serial number is the identification of the Product_as_individual and is represented by an Identification_assignment represented by template assigning_identification, as shown below in template table: Template #6(Figure 17) and classified as "Serial identification code" (urn:plcs:rdl:std:Serial identification code). In some systems, a serial number change reflects the fact a modification has been made to a Product In Focus. Consequently the dates that a serial number is valid for is represented by template assigning_dated_effectivity, as shown below in both #7 of Figure 17. and template table: Template #7(Figure 18).

Each Product_as_individual has a version, represented by a Product_as_realized.

The part number identifies the part type or design from which the Product In Focus was manufactured. In ISO 10303-239 PLCS the part type is represented by a Part and identified by a part number, and its version represented by a Part_version identified by a version. (For details see the capability C002: representing_parts) The part number identification is represented by template assigning_identification assigned to the Part and classified as a "Part identification code" (urn:plcs:rdl:std:Part identification code). The part version identification is represented by template assigning_identification assigned to the Part and classified as a "Version identification code" (urn:plcs:rdl:std:Version identification code). These entities are instantiated by the template referencing_partas shown below in template table: Template #0(Figure 18). The design is then related to the Product In Focus by the entity Product_design_version_to_individual.

When a modification is made to a Product In Focus, it is often in response to a change made to the part type or design, the Part. Depending on business practices, the design change may result in a new version of the part (Part_version), or a new Part, i.e. a new part number. The fact that the Product_as_individual is now related to the new part or version, hence has a new part number, is represented by instantiating another instance of Product_design_version_to_individual. The date s that a part number is valid for and hence the part design is represented by template assigning_dated_effectivity, as shown below in both #2 of Figure 17 and #2 of Figure 18, assigned to Product_design_version_to_individual. For further details on representing changes to part numbers, see Representing change of Part Number, Serial Number, and NSN: PLCS representation .

The part can have a description recorded and this is represented by template assigning_descriptor as shown below in both #5 of Figure 17 and #5 of Figure 18. An individual instance of a part can also have a description recorded and this is represented by template assigning_descriptor as shown below in both #13 of Figure 17 and template table: Template #13(Figure 18).

The Stock Code / Stock Number, e.g. NSN is a definition of the fit, form and function, or interchangeability of a part. There may be many parts that meet this definition. Therefore definition is represented as Resource_item that is identified by the Stock Code / Stock Number. The resource_items attribute lists all the parts that conform to the Stock Code / Stock Number definition. This is represented by the template representing_resource_item_realization as shown below in both #4 of Figure 17 and template table: Template #4(Figure 18).

The owning organization and the supplier organization are represented by assigning instances of template assigning_organization, as respectively shown below in both #11 of Figure 17 and template table: Template #11(Figure 18) and #12 of Figure 17 and template table: Template #12(Figure 18), to the Product_as_individual. The assignments are classified as either "Owner of" (urn:plcs:rdl:std:Owner of) and "Manufacturer of" (urn:plcs:rdl:std:Manufacturer of) to indicate that the organization is the owner or manufacturer of the part.

Template representing_work_done, as shown below in both #10 of Figure 17 and #10 of Figure 18 is used to show the activity that changed the Product_as_realized that was authorised by template representing_work_order, as shown below in both #9 of Figure 17 and #9 of Figure 18.

An EXPRESS-G diagram showing how the Product In Focus is identified is shown below.

Figure 17 —  EXPRESS-G diagram for identifying a Product In Focus

Figure 18 —  EXPRESS-G diagram for identifying a Product In Focus

The following templates are used in Figure 18 to represent a Product In Focus:

The use of template #9 representing_work_order in Figure 18 is identical to, and described in, template table: Template #4(Figure 13).

The use of template #10 representing_work_done in Figure 18 is identical to, and described in, template table: Template #3(Figure 13).

Representing properties on a Product In Focus

Business information

The messages can contain a number of properties of the Product In Focus, such as the aircraft hours, the hours since last repair.

The information necessary to record properties of the Product In Focus can be summarized by the UML class diagram shown in Figure 19. This is a subset of the UML diagrams shown in Figure 5 in Aviation maintenance Business Information Requirements - Message and Figure 7 in Aviation maintenance Business Information Requirements - Information.

NOTE    The information shown in the UML class diagram in Figure 19 is intended to illustrate the type of information that can be represented by the DEX. It does not imply that all exchanges must contain this information.

Figure 19 —  UML model representing the properties on a Product In Focus

PLCS representation

The following section describes how ISO 10303-239 PLCS is used to represent properties on a Product In Focus. This is summarised in Figure 20 and Figure 21 below. To clarify understanding Figure 20 shows the principal entities and templates used. Figure 21 shows the same information, but uses the the template representing_product_as_realized which instantiates a number of the principal entities as indicated in Figure 20.

The messages can contain a number of properties of the Product In Focus, such as the aircraft hours, number of take offs. These are represented as properties in ISO 10303-239 PLCS and are described in the capability C076: assigning_product_properties and detailed in the templates assigning_product_property, as shown below in both #3 of Figure 20 and template table: Template #3(Figure 21), and product_property_numeric, as shown below in both #4 of Figure 20 and template table: Template #4(Figure 21) and #8 of Figure 20 and template table: Template #8(Figure 21).

The template assigning_product_property, as shown below in both #3 of Figure 20 and template table: Template #3(Figure 21), is used to assign a named property to the product. The name of the property is provided by reference data. The template product_property_numeric, as shown below in both #4 of Figure 20 and template table: Template #4(Figure 21), used to represent the value of the property and its unit.

Where appropriate, the change to the property values, or increment can be exchanged. This is represented by using the template product_property_numeric, as shown below in both #8 of Figure 20 and template table: Template #8(Figure 21), to represent the previous value of the property and unit of the property. The value of the increment of the property since the last usage can be deduced from this. The relationship of #8 of Figure 20 and template table: Template #8(Figure 21), the previous property value, to #4 of Figure 20 and template table: Template #4(Figure 21), the new property value and unit is represented through template property_value_relationship, as shown below in both #9 of Figure 20 and template table: Template #9(Figure 21).

NOTE    When the value of a property is a range with a maximum and minimum value, e.g. maximum and minimum operating temperature, the template product_property_range should be used instead of product_property_numeric

The value type is represented by templates assigning_reference_data, as shown below in both #7 of Figure 20 and template table: Template #7(Figure 21) and #12 of Figure 20 and #12 of Figure 21. Typical value types are:

• life_meter_reading - the value measured on the meter recording the "life" consumed by the Product In Focus, where the life value is used to trigger a maintenance task;
• life_cumulative - the cumulative life consumed by the Product In Focus taking into account the changing of meters;
• measured - the value that has been measured but is not used for calculating life. E.g fuel consumed.

The organization measuring the property is represented by template assigning_organization, as shown below in both #6 of Figure 20 and template table: Template #6(Figure 21) and #11 of Figure 20 and #11 of Figure 21, and the date and time the property is measured is represented by template assigning_time, as shown below in both #5 of Figure 20 and template table: Template #5(Figure 21) and #10 of Figure 20 and #10 of Figure 21.

In ISO 10303-239 PLCS properties on a product are specified in a given context or view on a version of product, for example, the design cost properties would be represented in the design view. The context dependent view of a version Product_as_realized is represented by a Product_as_individual_view and an associated context represented by a View_definition_context. The context is classified according to the life cycle stage, represented by template assigning_reference_data, as shown below in both template table: Template #1(Figure 20) and #1 of Figure 21, and application domain represented by template assigning_reference_data, as shown below in both template table: Template #2(Figure 20) and #2 of Figure 21. For the messages the life cycle stage could be either:

• "Concept stage" (urn:plcs:rdl:std:Concept stage),
• "Development stage" (urn:plcs:rdl:std:Development stage),
• "Production stage" (urn:plcs:rdl:std:Production stage),
• "Retirement stage" (urn:plcs:rdl:std:Retirement stage),
• "Support stage" (urn:plcs:rdl:std:Support stage) or
• "Utilization stage" (urn:plcs:rdl:std:Utilization stage)

and the application domain is "Product life cycle support" (urn:plcs:rdl:std:Product life cycle support). Given that this DEX is most likely to be used during the operation of the product, it is recommend that "Utilization stage" (urn:plcs:rdl:std:Utilization stage) is used.

An EXPRESS-G diagram showing how properties on a Product In Focus are represented is shown below in Figure 20.

Figure 20 —  EXPRESS-G diagram for properties on a Product In Focus

Figure 21 —  EXPRESS-G diagram for properties on a Product In Focus

The following templates are used in Figure 21 to represent properties on a Product In Focus:

The use of template #0 representing_product_as_realized in Figure 21 is identical to, and described in, template table: Template #1(Figure 18).

Representing state of a Product In Focus

Business information

The Aviation Maintenance DEX enables the exchange of information about symptoms and faults that have been raised on an aircraft or modules and their serviceability state. The serviceability state is an indication as to whether the product can be used for its intended purpose. It is normally declared unserviceable if there are any outstanding maintenance activities due on the product, in particular, to address faults.

The information required to represent the various states of the Product In Focus can be summarized by the UML class diagram shown in Figure 22. This is a subset of the UML diagrams shown in Figure 5 in Aviation maintenance Business Information Requirements - Message and Figure 7 in Aviation maintenance Business Information Requirements - Information.

NOTE    The information shown in the UML class diagram in Figure 22 is intended to illustrate the type of information that can be represented by the DEX. It does not imply that all exchanges must contain this information.

Figure 22 —  UML class diagram representing different states of an asset

A basic process that can be supported is that a symptom is identified on a Product In Focus after it has been operated e.g. flown a sortie. This is an observation that the Product In Focus is not operating correctly. If appropriate, a request for further investigation is made, which is approved result in a work order being raised to investigate the symptom. This may result in a fault being identified. The fault is often a known condition for which there is a documented procedure for rectification. The fault is then either be deferred for resolution at a later date or rectified. If the fault is deferred, it may be stated that the Product In Focus can be operated with restrictions. Once the fault has been addressed, the work order is closed. This process is summarised in Figure 23.

NOTE    The use of the Aviation maintenance DEX does not enforce this process. It is intended to illustrate the type of process and information that can be represented using the DEX.

Figure 23 —  UML class diagram representing the state of an asset

PLCS representation

Symptoms

The following section describes how ISO 10303-239 PLCS is used to represent a symptom observed on a Product In Focus. This is summarised in Figure 24 below.

A symptom is an observation of unexpected product behaviour made by someone. Investigation may show that this may be a fault. In ISO 10303-239 PLCS, the symptom would be represented by the Observation made on the Product In Focus, represented by a Product_as_individual. (See Representing a Product In Focus ). The use of Observation is described in C025: representing_observation. The Observation is classified as a symptom by assigning template assigning_reference_data as shown below in template table: Template #0(Figure 24).

Once the symptom has been identified, it leads to a request for action - represented in ISO 10303-239 PLCS as a Work_request. The entity Affected_items_assignment is used to relate the Work_request to the Product In Focus (Product_as_individual) against which it has been raised. The fact that the symptom has given rise to a Work_request is represented by using the Observation_consequence to relate the Observation to the Work_request. The Work_request is then approved and leads to a Work_order. The use of Work_request and Work_order is described in C066: representing_work_request and C065: representing_work_order respectively.

An EXPRESS-G diagram showing how the symptom is represented is shown in Figure 24.

The symptom is represented by the template assigning_observation, as shown below in template table: Template #1(Figure 24). The fact that the symptom has been observed on a Product In Focus is represented by assigning the observation to a Product_as_realized represented by the template representing_product_as_realized, as shown below in #2 of Figure 24. (See Representing a Product In Focus for details on how to represent a Product In Focus). The symptom may also be identified during an activity being undertaken by the Product In Focus such as a sortie. The activity is represented by the template representing_product_usage, as shown below in template table: Template #3(Figure 24). (See Representing a Product In Focus usage activity for details on how to represent a products activity). The observation is therefore related to the the template representing_product_usage, as shown below in template table: Template #3(Figure 24). The symptom may have been observed during a maintenance activity, in which case the template representing_work_done should be used instead as described in Representing Product In Focus maintenance activity: PLCS representation.

The person who observed the symptom is represented by template assigning_person_in_organization, as shown below in template table: Template #4(Figure 24).

Often, the symptom is classified to provide further information about the type of symptom. For example:

NOTE    These are examples of symptom types, different applications and business processes may use different types.

• a symptom that has a perceived effect on flight safety, is represented by template assigning_reference_data, as shown below in template table: Template #5(Figure 24). For example a safety critical symptom.
• a symptom that occurs or is discovered during some activity is represented by template assigning_reference_data, as shown below in template table: Template #6(Figure 24),; For example a take off symptom.
• a symptom that was observed on a system is represented by template assigning_reference_data, as shown below in template table: Template #7(Figure 24). For example an engine symptom.

Once the symptom has been identified, it normally results in a Work_request that registers a request to investigate the symptom. This is represented by template representing_work_request, as shown below in template table: Template #9(Figure 24). The request then results in an order (a maintenance work order) to investigate and resolve the symptom. This is represented by a Work_order which is defined in the template representing_work_order, as shown below in #10 of Figure 24. At this stage the symptom may be confirmed as a fault, which is represented by a State_observed which is defined by template assigning_asserted_state, as shown below in #11 of Figure 24. This is described further in Representing state of a Product In Focus.

The maintenance work order can have a state assigned with it. This is represented by the template assigning_asserted_state, as shown below in #14 of Figure 24. The state can be used to represent whether the Fault is deferred on not. In other words, the work to rectify the fault has been deferred.

With faults foreseen by the manufacturer, a set of tasks are typically defined that specify how to rectify the fault. These tasks are defined by first identifying the method, represented by a Activity_method defined in template representing_typical_activity, as shown below in #15 of Figure 24. If the method is detailed as task or procedure it is represented by a Task_method defined in template referencing_task, as shown below in #12 of Figure 24.

Figure 24 —  EXPRESS-G diagram for representing a symptom

The following templates are used in Figure 24 to represent a symptom:

Template #1 (Figure 24): assigning_observation Show template parametersHide all template parametersShow all template parameters
Description	The identification of the symptom.

Template #1 (Figure 24): assigning_observation Hide template parametersHide all template parametersShow all template parameters
Description	The identification of the symptom.
Parameter name:	Parameter value:	Parameter description:
id	?id?	The identifier of the symptom
id_class_name	"Observation identification code" (urn:plcs:rdl:std:Observation identification code)	The name of the class used to classify the identifier and so provide the role or reason for the identification.
id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the id_class_name class
org_id	?org_id?	The identifier or name of the organization that "owns" the identifier.
org_id_class_name	?org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the org_id_class_name class items.
descr	?descr?	The description of the symptom
dsc_class_name	"Description" (urn:plcs:rdl:std:Description)	The name of the class used to classify the identifier and so provide the role or reason for the identification.
dsc_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the description class items.
date_class_name	"Date actual observation" (urn:plcs:rdl:std:Date actual observation)	The name of the class being used to classify the role date assignment, e.g. the date when the Observation was made.
date_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the date class items.
year	?year?	the year component of the date the symptom was first observed
month	?month?	the month component of the date the symptom was first observed
day	?day?	the day component of the date the symptom was first observed. This can be in local time or UTC
hour	?hour?	the hour component of the date the symptom was first observed. This can be in local time or UTC
minute	?minute?	The minute component of the date the symptom was first observed. This can be in local time or UTC
second	?second?	the second component of the date the symptom was first observed. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
applies_to	The Product_as_realized template instantiated by #2 of Figure 24.	The Product In Focus about which the symptom was raised.
related_records		Not used in this instance
observed_during	The Activity_actual template instantiated by template table: Template #3(Figure 24).	This is the activity that is represented as a Activity_actual which is part of template representing_product_usage.
observed_by	The Activity_actual template instantiated by template table: Template #9(Figure 24).	If the symptom is recorded by a piece of equipment, e.g. HUMS, then this should link to the Product_as_individual_view for that part, which is part of template representing_product_as_realized
in_context		Not used in this instance

Template #0 (Figure 24): assigning_reference_data Show template parametersHide all template parametersShow all template parameters
Description	Classifying the Observation a symptom.

Template #0 (Figure 24): assigning_reference_data Hide template parametersHide all template parametersShow all template parameters
Description	Classifying the Observation a symptom.
Parameter name:	Parameter value:	Parameter description:
class_name	"Symptom" (urn:plcs:rdl:std:Symptom)	The name of the External_class being used.
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the definition for the class being used.
items	The Observation template instantiated by template table: Template #1(Figure 24).	The items to which the External_class is assigned.

The use of template #2 The Product In Focus representing_product_as_realized in Figure 24 is identical to, and described in, template table: Template #1(Figure 18) .

Template #3 (Figure 24): representing_product_usage Show template parametersHide all template parametersShow all template parameters
Description	The identification of the activity that was being performed when the symptom was observed. E.g. Sortie

Template #3 (Figure 24): representing_product_usage Hide template parametersHide all template parametersShow all template parameters
Description	The identification of the activity that was being performed when the symptom was observed. E.g. Sortie
Parameter name:	Parameter value:	Parameter description:
id	?id?	The identifier of the activity
id_class_name	"Activity identification code" (urn:plcs:rdl:std:Activity identification code)	The name of the class being used to classify the identification (Identification_assignment) of the actual activity. This provides the role or reason for the identification.
id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @id_class_name class.
id_owner	?id_owner?	The identifier or name of the organization that "owns" the identifier.
id_owner_class_name	?id_owner_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
id_owner_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the org_id_class_name class items.
method	Activity_method	The typical activity of which this activity_actual is an instance, or other regulating method.
role	"Product usage" (urn:plcs:rdl:std:Product usage)	The class name of the External_class corresponding to the role of the activity assignment.
role_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the role class items.
items	The Product_as_individual_view template instantiated by #2 of Figure 24.	The product that is or was used in the activity, e.g. the airplane that was used for a specific mission, the truck that was used for a specific transport.
date_class_name	"Date actual start" (urn:plcs:rdl:std:Date actual start)	The name of the class being used to classify the date or time. Must be either a start or an end date or time.
date_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the date class items.
year	?year?	the year component of the date the activity started
month	?moth?	the month component of the date the activity started
day	?day?	the day component of the date the activity started. This can be in local time or UTC
hour	?hour?	the hour component of the date the activity started. This can be in local time or UTC
minute	?minute?	the minute component of the date the activity started. This can be in local time or UTC
second	?second?	the second component of the date the activity started. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC

NOTE    The symptom may also have been observed during a maintenance activity, in which case rather than using template representing_product_usage, as shown below in template table: Template #3(Figure 24), the templates representing_work_done should be used as described in template table: Template #3(Figure 13).

Template #4 (Figure 24): assigning_person_in_organization Show template parametersHide all template parametersShow all template parameters
Description	Identification of the person observing the symptom.

Template #4 (Figure 24): assigning_person_in_organization Hide template parametersHide all template parametersShow all template parameters
Description	Identification of the person observing the symptom.
Parameter name:	Parameter value:	Parameter description:
last_name	?last_name?	The last name of the person observing the symptom
first_name	?first_name?	The first name of the person observing the symptom; use "unknown" when the information is not known to the sending system
middle_names	?middle_names?	The middle name of the person observing the symptom; use "unknown" when the information is not known to the sending system
prefix_titles	?prefix_titles?	The prefix title of the person observing the symptom; use "unknown" when the information is not known to the sending system
suffix_titles	?suffix_titles?	The suffix title of the person observing the symptom; use "unknown" when the information is not known to the sending system
person_role_class_name	"Observer of" (urn:plcs:rdl:std:Observer 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.
org_id	?org_id?	The identifier of the organization in which the person observing the symptom work.
org_id_class_name	?org_id_class_name?	The name or code that identifies (Identification_assignment) an organization. For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @org_id_class_name class.
items	The Observation template instantiated by template table: Template #1(Figure 24).	The items to which the person is assigned

Template #5 (Figure 24): assigning_reference_data Show template parametersHide all template parametersShow all template parameters
Description	Symptom with perceived effect on flight safety

Template #5 (Figure 24): assigning_reference_data Hide template parametersHide all template parametersShow all template parameters
Description	Symptom with perceived effect on flight safety
Parameter name:	Parameter value:	Parameter description:
class_name	?class_name?	The code representing perceived effect on flight safety
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the definition for the class being used.
items	The Observation template instantiated by template table: Template #1(Figure 24).	The items to which the External_class is assigned.

Template #6 (Figure 24): assigning_reference_data Show template parametersHide all template parametersShow all template parameters
Description	Symptom occurring during an activity

Template #6 (Figure 24): assigning_reference_data Hide template parametersHide all template parametersShow all template parameters
Description	Symptom occurring during an activity
Parameter name:	Parameter value:	Parameter description:
class_name	?class_name?	The code representing when and how the symptom was discovered
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the definition for the class being used.
items	The Observation template instantiated by template table: Template #1(Figure 24).	The items to which the External_class is assigned.

Template #7 (Figure 24): assigning_reference_data Show template parametersHide all template parametersShow all template parameters
Description	A symptom that occurs on a particular class of system.

Template #7 (Figure 24): assigning_reference_data Hide template parametersHide all template parametersShow all template parameters
Description	A symptom that occurs on a particular class of system.
Parameter name:	Parameter value:	Parameter description:
class_name	?class_name?	The code representing the system on which the symptom was observed
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the definition for the class being used.
items	The State_assessment template instantiated by template table: Template #1(Figure 24).	The items to which the External_class is assigned.

Template #9 (Figure 24): representing_work_request Show template parametersHide all template parametersShow all template parameters
Description	The request to investigate the symptom.

Template #9 (Figure 24): representing_work_request Hide template parametersHide all template parametersShow all template parameters
Description	The request to investigate the symptom.
Parameter name:	Parameter value:	Parameter description:
id	?id?	The identifier assigned to the work request
id_class_name	"Work request identification code" (urn:plcs:rdl:std:Work request identification code)	The name of the class used to classify the identifier and so provide the role or reason for the identification.
id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the id_class_name class
org_id	?org_id?	The identifier or name of the organization that "owns" the identifier.
org_id_class_name	?org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the org_id_class_name class items.
version_id	?version_id?	The identifier of the version assigned to the work request
version_id_class_name	"Identifier type" (urn:plcs:rdl:std:Identifier type)	The name of the class used to classify the identifier and so provide the role or reason for the identification.
version_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the version_id_class_name class items.
version_org_id	?version_org_id?	The identifier or name of the organization that "owns" the version identifier.
version_org_id_class_name	?version_org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
version_org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the version_org_id_class_name class items.
date_class_name	"Work request issue date" (urn:plcs:rdl:std:Work request issue date)	The identification showing that the date is when the work_request is issued.
date_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the date class items.
year	?year?	the year component of the date the work_request is issued
month	?month?	the month component of the date the work_request is issued
day	?day?	the day component of the date the work_request is issued. This can be in local time or UTC
hour	?hour?	the hour component of the date the work_request is issued. This can be in local time or UTC
minute	?minute?	the minute component of the date the work_request is issued. This can be in local time or UTC
second	?second?	the second component of the date the work_request is issued. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
state_class_name	"State of work request" (urn:plcs:rdl:std:State of work request)	The class name of the External_class corresponding to the State_definition name.
state_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @state_class_name.
purpose	"Work request" (urn:plcs:rdl:std:Work request)	The name of the class in the reference data library (External_class) being used to define the purpose of the Work_request.
purp_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @purpose.

The use of template #10 "Maintenance work order addressing Fault" representing_work_order in Figure 24 is identical to, and described in, template table: Template #4(Figure 13).

The use of template #11 "Fault" assigning_asserted_state in Figure 24 is identical to, and described in, template table: Template #1(Figure 25).

The use of template #12 "Task/procedure performed to rectify fault" referencing_task in Figure 24 is identical to, and described in, template table: Template #19(Figure 25).

The use of template #13 "Work done to rectify fault" representing_work_done in Figure 24 is identical to, and described in, template table: Template #3(Figure 13).

The use of template #14 "State of work order" assigning_asserted_state in Figure 24 is identical to, and described in, template table: Template #18(Figure 25).

The use of template #15 "method used to rectify the fault" representing_typical_activity in Figure 24 is identical to, and described in, template table: Template #1(Figure 15).

The use of template #16 "Activity" assigning_activity in Figure 24 is identical to, and described in, template table: Template #11(Figure 25).

Faults and States

The following section describes how ISO 10303-239 PLCS is used to represent faults and states of a Product In Focus. This is summarised in Figure 25 below.

There can be a number of states of the Product In Focus and the next higher assembly, such as the fault state of the Product In Focus and the serviceability state.

In ISO 10303-239 PLCS a distinction is made between states that a product could possibly be in, the set of all fault states for example, and the actual state that a product is in. These are referred to defined states and observed states respectively and are represented by State_definition and State_observed.

An observed state is related to the defined state (State_definition), of which it is an occurrence, by State_assessment and State_assertion.

The State_assessment indicates that an assumption has been made that something, such as a Product_as_realized, is in a state (State_observed) that resembles the state defined by the State_definition.

The State_assertion is used to assert that, based on evidence such as measurements, something, such as a Product_as_realized, is in a state (State_observed) that is equal to the state defined by the State_definition.

The representations of defined and observed states are described in the capabilities C007: representing_state_type and C041: representing_state_observed. The representation of an assessed state is detailed in the template assigning_assessed_state and the representation of an asserted state is detailed in the template assigning_asserted_state.

An EXPRESS-G diagram showing how the state of the Product In Focus is identified is shown in Figure 25.

The template: representing_product_as_realized, as shown below in #2 of Figure 25, is used to represent the Product In Focus whose state is being identified. (See section Representing a Product In Focus for details on representing a Product In Focus.) The template: assigning_asserted_state, as shown below in template table: Template #22(Figure 25) is used to represent the serviceability status of the Product In Focus. In some applications the occurrence of the serviceability status may have a unique identifier, in which case the state is identified by the template assigning_identification, as shown below in template table: Template #14(Figure 25). This should not be confused with the code that is used to represent the state type, such as serviceable, unserviceable - these are represented by reference data and are set as parameters in the template assigning_asserted_state. In addition, the time when the Product In Focus entered into the given serviceability state and the time when it left is represented by the template assigning_time, , as shown below in template table: Template #16(Figure 25) and template table: Template #15(Figure 25) respectively.

The fault state of the Product In Focus is represented first by an assessed state, then once the fault has been confirmed though measurement for example, by an asserted state. This is represented by the templates assigning_assessed_state, as shown below in template table: Template #12(Figure 25), and template assigning_asserted_state,, as shown below in template table: Template #1(Figure 25) respectively. The fault code that identifies the type of fault, is represented by reference data and is set as parameters in the templates assigning_assessed_state and assigning_asserted_state. In some applications the occurrence of fault state may have a unique identifier, in which case the state is identified by the template assigning_identification, , as shown below in template table: Template #8(Figure 25) and template table: Template #4(Figure 25). This is just an identifier used to track the occurrence of the fault. It does not specify the type of fault - that is specified by the state definition.

A work order is often raised to address the fault. The work order is represented by the template representing_work_order, as shown below in #17 of Figure 25, and described in Representing a maintenance work order. The fault can be related to the work order by the template assigning_activity, e.g. template template table: Template #21(Figure 25) and template table: Template #11(Figure 25).

The dates when the fault was identified and rectified are given by the template assigning_time, as shown below in template table: Template #6(Figure 25), template table: Template #7(Figure 25), template table: Template #9(Figure 25), and template table: Template #10(Figure 25).

NOTE    The time that the fault was "asserted" is the time that the fault "assessment" phase ended, so template table: Template #6(Figure 25) and template table: Template #9(Figure 25) would have the same values.

A description of the fault can be provided by assigning a description to the state using assigning_descriptor. This is shown in template table: Template #3(Figure 25) and template table: Template #5(Figure 25).

Figure 25 —  EXPRESS-G diagram for state of a Product In Focus

The following templates are used in Figure 25 to represent a state of a Product In Focus:

Template #1 (Figure 25): assigning_asserted_state Show template parametersHide all template parametersShow all template parameters
Description	Fault confirmed by measurement.

Template #1 (Figure 25): assigning_asserted_state Hide template parametersHide all template parametersShow all template parameters
Description	Fault confirmed by measurement.
Parameter name:	Parameter value:	Parameter description:
state_class_name	"Failure mode state" (urn:plcs:rdl:std:Failure mode state)	The type of fault state
state_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @state_class_name.
assigned_to	The Product_as_individual_view template instantiated by #2 of Figure 25.	The activity, product, individual, task_method, etc to which the state is assigned

The use of template #2 representing_product_as_realized in Figure 25 is identical to, and described in, template table: Template #1(Figure 18) .

Template #3 (Figure 25): assigning_descriptor Show template parametersHide all template parametersShow all template parameters
Description	Description of fault.

Template #3 (Figure 25): assigning_descriptor Hide template parametersHide all template parametersShow all template parameters
Description	Description of fault.
Parameter name:	Parameter value:	Parameter description:
descr	?descr?	the description of the assessed fault
class_name	"Description" (urn:plcs:rdl:std:Description)	The name of the class (External_class) being used to determine type of descriptor.
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the class.
is_assigned_to	The State_observedtemplate instantiated by template table: Template #12(Figure 25).	The entity to which the Document_assignment is assigned.

Template #4 (Figure 25): assigning_identification Show template parametersHide all template parametersShow all template parameters
Description	Fault identifier.

Template #4 (Figure 25): assigning_identification Hide template parametersHide all template parametersShow all template parameters
Description	Fault identifier.
Parameter name:	Parameter value:	Parameter description:
id	?id?	The identifier of the asserted fault used to track the fault. NOTE    This does not represent the type of fault. The type is represented by reference data passed as a parameter to template #1 assigning_asserted_state
id_class_name	"Failure mode identification code" (urn:plcs:rdl:std:Failure mode identification code)	The name of the class used to classify the identifier (@id) and so provide the role or reason for the identification.
id_ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library storing the @id_class_name.
org_id	?org_id?	The identifier or name of the organization that "owns" the identifier.
org_id_class_name	?org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the org_id_class_name class items.
items	The State_observedtemplate instantiated by template table: Template #1(Figure 25).	The items to which the identification is assigned

Template #5 (Figure 25): assigning_descriptor Show template parametersHide all template parametersShow all template parameters
Description	Description of the fault.

Template #5 (Figure 25): assigning_descriptor Hide template parametersHide all template parametersShow all template parameters
Description	Description of the fault.
Parameter name:	Parameter value:	Parameter description:
descr	?descr?	the description of the asserted fault
class_name	"Description" (urn:plcs:rdl:std:Description)	The name of the class (External_class) being used to determine type of descriptor.
ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library that stores the class.
is_assigned_to	The State_observed template instantiated by template table: Template #1(Figure 25).	The entity to which the Document_assignment is assigned.

Template #6 (Figure 25): assigning_time Show template parametersHide all template parametersShow all template parameters
Description	Date fault asserted.

Template #6 (Figure 25): assigning_time Hide template parametersHide all template parametersShow all template parameters
Description	Date fault asserted.
Parameter name:	Parameter value:	Parameter description:
date_class_name	"Date actual assertion" (urn:plcs:rdl:std:Date actual assertion)	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 is defined.
year	?year?	the year component of the date the fault was first asserted
month	?month?	the month component of the date the fault was first asserted
day	?day?	the day component of the date the fault was first asserted. This can be in local time or UTC
hour	?hour?	the hour component of the date the fault was first asserted. This can be in local time or UTC
minute	?minute?	the minute component of the date the fault was first asserted. This can be in local time or UTC
second	?second?	the second component of the date the fault was first asserted. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
items	The State_assertion template instantiated by template table: Template #1(Figure 25).	The items to which the date is assigned.

Template #7 (Figure 25): assigning_time Show template parametersHide all template parametersShow all template parameters
Description	Date fault cleared.

Template #7 (Figure 25): assigning_time Hide template parametersHide all template parametersShow all template parameters
Description	Date fault cleared.
Parameter name:	Parameter value:	Parameter description:
date_class_name	"Date actual end" (urn:plcs:rdl:std: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 is defined.
year	?year?	the year component of the date the fault was cleared
month	?month?	the month component of the date the fault was cleared
day	?day?	the day component of the date the fault was cleared. This can be in local time or UTC
hour	?hour?	the hour component of the date the fault was cleared. This can be in local time or UTC
minute	?minute?	the minute component of the date the fault was cleared. This can be in local time or UTC
second	?second?	the second component of the date the fault was cleared. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
items	The State_assertiontemplate instantiated by template table: Template #1(Figure 25).	The items to which the date is assigned.

Template #8 (Figure 25): assigning_identification Show template parametersHide all template parametersShow all template parameters
Description	Fault identifier.

Template #8 (Figure 25): assigning_identification Hide template parametersHide all template parametersShow all template parameters
Description	Fault identifier.
Parameter name:	Parameter value:	Parameter description:
id	?id?	The identifier of the assessed fault. NOTE    This does not represent the type of fault. The type is represented by reference data passed as a parameter to template #12 assigning_assessed_state
id_class_name	"Failure identification code" (urn:plcs:rdl:std:Failure identification code)	The name of the class used to classify the identifier (@id) and so provide the role or reason for the identification.
id_ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library storing the @id_class_name.
org_id	?org_id?	The identifier or name of the organization that "owns" the identifier.
org_id_class_name	?org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the org_id_class_name class items.
items	The State_observed template instantiated by template table: Template #12(Figure 25).	The items to which the identification is assigned

Template #9 (Figure 25): assigning_time Show template parametersHide all template parametersShow all template parameters
Description	Date fault assessed.

Template #9 (Figure 25): assigning_time Hide template parametersHide all template parametersShow all template parameters
Description	Date fault assessed.
Parameter name:	Parameter value:	Parameter description:
date_class_name	"Date actual assessment" (urn:plcs:rdl:std:Date actual assessment)	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 is defined.
year	?year?	the year component of the date the fault was first assessed
month	?month?	the month component of the date the fault was first assessed
day	?day?	the day component of the date the fault was first assessed. This can be in local time or UTC
hour	?hour?	the hour component of the date the fault was first assessed. This can be in local time or UTC
minute	?minute?	the minute component of the date the fault was first assessed. This can be in local time or UTC
second	?second?	the second component of the date the fault was first assessed. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
items	The State_assessment template instantiated by template table: Template #12(Figure 25).	The items to which the date is assigned.

Template #10 (Figure 25): assigning_time Show template parametersHide all template parametersShow all template parameters
Description	Date assessed state ended.

Template #10 (Figure 25): assigning_time Hide template parametersHide all template parametersShow all template parameters
Description	Date assessed state ended.
Parameter name:	Parameter value:	Parameter description:
date_class_name	"Date actual end" (urn:plcs:rdl:std: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 is defined.
year	?year?	the year component of the date the assessed fault was cleared
month	?month?	the month component of the date the assessed fault was cleared
day	?day?	the day component of the date the assessed fault was cleared. This can be in local time or UTC
hour	?hour?	the hour component of the date the assessed fault was cleared. This can be in local time or UTC
minute	?minute?	the minute component of the date the assessed fault was cleared. This can be in local time or UTC
second	?second?	the second component of the date the assessed fault was cleared. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
items	The State_assessment template instantiated by template table: Template #12(Figure 25).	The items to which the date is assigned.

Template #11 (Figure 25): assigning_activity Show template parametersHide all template parametersShow all template parameters
Description	Activity

Template #11 (Figure 25): assigning_activity Hide template parametersHide all template parametersShow all template parameters
Description	Activity
Parameter name:	Parameter value:	Parameter description:
role_class_name	"Activity output" (urn:plcs:rdl:std:Activity output)	The class name of the External_class corresponding to the role of the assignment, e.g. "Activity input" (urn:plcs:rdl:std:Activity input), or "Activity output" (urn:plcs:rdl:std:Activity output).
role_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @role_class_name.
assigned_activity	The Directed_activity template instantiated by #17 of Figure 25.	This is the activity that is represented as a Directed_activity which is part of template representing_work_order.
items	The State_assessment template instantiated by template table: Template #12(Figure 25).	The activity, product, individual, task_method, etc that is being assigned to the activity.

Template #12 (Figure 25): assigning_assessed_state Show template parametersHide all template parametersShow all template parameters
Description	Hypothesized Fault. Not confirmed by measurement.

Template #12 (Figure 25): assigning_assessed_state Hide template parametersHide all template parametersShow all template parameters
Description	Hypothesized Fault. Not confirmed by measurement.
Parameter name:	Parameter value:	Parameter description:
state_class_name	"Failure mode state" (urn:plcs:rdl:std:Failure mode state)	The class name of the External_class corresponding to the State_definition name.
state_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @state_class_name.
assigned_to	The Product_as_individual_view template instantiated by #2 of Figure 25.	This is the Product In Focus that is represented as a Product_as_individual_view which is part of template representing_work_done.

The use of template #13 representing_work_done in Figure 25 is identical to, and described in, template table: Template #3(Figure 13).

Template #14 (Figure 25): assigning_identification Show template parametersHide all template parametersShow all template parameters
Description	Serviceability status identifier. NOTE    This does not represent the type of fault. The type is represented by reference data passed as a parameter to template #22 assigning_asserted_state

Template #14 (Figure 25): assigning_identification Hide template parametersHide all template parametersShow all template parameters
Description	Serviceability status identifier. NOTE    This does not represent the type of fault. The type is represented by reference data passed as a parameter to template #22 assigning_asserted_state
Parameter name:	Parameter value:	Parameter description:
id	?id?	The identifier of the asserted serviceability status
id_class_name	"State identification code" (urn:plcs:rdl:std:State identification code)	The name of the class used to classify the identifier (@id) and so provide the role or reason for the identification.
id_ecl_id	"urn:plcs:rdl:std"	The id of the External_class_library storing the @id_class_name.
org_id	?org_id?	The identifier or name of the organization that "owns" the identifier.
org_id_class_name	?org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the org_id_class_name class items.
items	The State_observed template instantiated by template table: Template #22(Figure 25).	The items to which the identification is assigned

Template #15 (Figure 25): assigning_time Show template parametersHide all template parametersShow all template parameters
Description	End date of status.

Template #15 (Figure 25): assigning_time Hide template parametersHide all template parametersShow all template parameters
Description	End date of status.
Parameter name:	Parameter value:	Parameter description:
date_class_name	"Date actual end" (urn:plcs:rdl:std: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 is defined.
year	?year?	the year component of the date the status ended
month	?month?	the month component of the date the status ended
day	?day?	the day component of the date the fault status ended. This can be in local time or UTC
hour	?hour?	the hour component of the date the fault status ended. This can be in local time or UTC
minute	?minute?	the minute component of the date the fault status ended. This can be in local time or UTC
second	?second?	the second component of the date the fault status ended. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
items	The State_assertion template instantiated by template table: Template #22(Figure 25).	The items to which the date is assigned.

Template #16 (Figure 25): assigning_time Show template parametersHide all template parametersShow all template parameters
Description	Start date of status.

Template #16 (Figure 25): assigning_time Hide template parametersHide all template parametersShow all template parameters
Description	Start date of status.
Parameter name:	Parameter value:	Parameter description:
date_class_name	"Date actual assertion" (urn:plcs:rdl:std:Date actual assertion)	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 is defined.
year	?year?	the year component of the date the status was first asserted
month	?month?	the month component of the date the status was first asserted
day	?day?	the day component of the date the status was first asserted. This can be in local time or UTC
hour	?hour?	the hour component of the date the status was first asserted. This can be in local time or UTC
minute	?minute?	the minute component of the date the status was first asserted. This can be in local time or UTC
second	?second?	the second component of the date the status was first asserted. This can be in local time or UTC
sense	?sense?	Three possible values 'exact' when the time is in UTC, 'behind' when the time is a local time behind UTC and 'ahead' when the time is a local time ahead of UTC
hour_offset	?hour_offset?	The hour offset from UTC, use 0 when the time is UTC
minute_offset	?minute_offset?	The minute offset from UTC, use 0 when the time is UTC
items	The State_assertion template instantiated by template table: Template #22(Figure 25).	The items to which the date is assigned.

The use of template #17 representing_work_order in Figure 25 is identical to, and described in, template table: Template #4(Figure 13).

Template #18 (Figure 25): assigning_asserted_state Show template parametersHide all template parametersShow all template parameters
Description	State of work order.

Template #18 (Figure 25): assigning_asserted_state Hide template parametersHide all template parametersShow all template parameters
Description	State of work order.
Parameter name:	Parameter value:	Parameter description:
state_class_name	"State of work order" (urn:plcs:rdl:std:State of work order)	The class name of the External_class corresponding to the State_definition name.
state_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @state_class_name.
assigned_to	The Directed_activity template instantiated by #17 of Figure 25.	This is the activity that is represented as a Directed_activity which is part of template representing_work_order.

Template #19 (Figure 25): referencing_task Show template parametersHide all template parametersShow all template parameters
Description	Task / Procedure performed to rectify fault

Template #19 (Figure 25): referencing_task Hide template parametersHide all template parametersShow all template parameters
Description	Task / Procedure performed to rectify fault
Parameter name:	Parameter value:	Parameter description:
task_id	?task_id?	The identifier of the task or procedure.
task_id_class_name	"Task method identification code" (urn:plcs:rdl:std:Task method identification code)	The class which specifies the role of the Identification_assignment as an identifier for the Task_method.
task_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @task_id_class_name.
task_org_id	?task_org_id?	The identifier of the organization that owns the task or procedure identifier.
task_org_id_class_name	?task_org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
task_org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @task_org_id_class_name.
task_ver_id	?task_ver_id?	The identifier of the version of the task or procedure
task_ver_id_class_name	"Version identification code" (urn:plcs:rdl:std:Version identification code)	The class which specifies the role of the Identification_assignment as a version identifier for the Task_method_version.
task_ver_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @task_ver_id_class_name.
task_ver_org_id	?task_org_id?	The identifier of the organization that owns the version of the task or procedure identifier.
task_ver_org_id_class_name	?task_ver_org_id_class_name?	For a name identifying an organization, use "Organization name" (urn:plcs:rdl:std:Organization name) For a code identifying an organization, use "Organization identification code" (urn:plcs:rdl:std:Organization identification code) For a CAGE code identifying an organization, use "CAGE code" (urn:plcs:rdl:std:CAGE code)
task_ver_org_id_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @task_ver_org_id_class_name.

The use of template #20 representing_typical_activity in Figure 25 is identical to, and described in, template table: Template #1(Figure 15).

Template #21 (Figure 25): assigning_activity Show template parametersHide all template parametersShow all template parameters
Description	Activity

Template #21 (Figure 25): assigning_activity Hide template parametersHide all template parametersShow all template parameters
Description	Activity
Parameter name:	Parameter value:	Parameter description:
role_class_name	"Activity output" (urn:plcs:rdl:std:Activity output)	The class name of the External_class corresponding to the role of the assignment, e.g. "Activity input" (urn:plcs:rdl:std:Activity input), or "Activity output" (urn:plcs:rdl:std:Activity output).
role_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @role_class_name.
assigned_activity	The Directed_activity template instantiated by #17 of Figure 25.	This is the activity that is represented as a Directed_activity which is part of template representing_work_order.
items	The State_assertion template instantiated by template table: Template #1(Figure 25).	The activity, product, individual, task_method, etc that is being assigned to the activity.

Template #22 (Figure 25): assigning_asserted_state Show template parametersHide all template parametersShow all template parameters
Description	Serviceability status of Product In Focus.

Template #22 (Figure 25): assigning_asserted_state Hide template parametersHide all template parametersShow all template parameters
Description	Serviceability status of Product In Focus.
Parameter name:	Parameter value:	Parameter description:
state_class_name	"State definition" (urn:plcs:rdl:std:State definition)	The class name of the External_class corresponding to the State_definition name.
state_ecl_id	"urn:plcs:rdl:std"	The identifier of the External_class_library storing the definition of the class referenced by the parameter @state_class_name.
assigned_to	The Product_as_individual_view template instantiated by #2 of Figure 25.	The activity, product, individual, task_method, etc to which the state is assigned