Business overview

This section provides a business level overview of this capability.

An Observation provides a mechanism for recording the relation of an observed fact to the thing to which it relates, and for linking the observation to any consequence that may result. It is intended to be used in two ways. Firstly, it provides a general mechanism to link the unexpected to the well defined world of the product and its design. Secondly, it provides a defined mechanism for reporting observations within the context of the standard, given that the set of observations required will vary between products and organizations.

For example, a crack may occur in the wall of a container. The Observation object allows for the recording of the fact that the crack has appeared. Subsequent inspections required by the organization may then be directed towards recording the size of the crack. Since a crack is not a design feature, such recording cannot be done directly in the design data for the container, nor do the design data standards allow for multiple historical observations

Basic observations

In basic observations, Observation is instantiated, but Observation_relationships are not instantiated.

Complex observations

In complex observations, a series of related Observations may be made as part of a series or as part of a decomposition in which increasing levels of detail are supplied.

Information model overview

This section provides an overview of the information model that supports this capability.

The information required to represent an observation is summarized in the EXPRESS-G diagram in Figure 1 below and in the following sections.

Figure 1 —  EXPRESS-G for an observation

Basic observations

For each basic observation, a single instance of Observation is created.

Figure 
Error Fig 2: There is no figure with id person_and_work_request_observation.
illustrates the representation of a Person (#7) making an Observation (#1) while undertaking a Work_order (#11). The observation was carried out using a particular piece of test equipment, represented by Product_as_realized (#6).

The description attribute of the Observation (#1) is used to describe the observation that has been made.

If the observation has been made about something, then that subject is referenced using an Observation_item. The reference provided by the Observation_item is in the context of the data, e.g. an Object Identifier in a Part 21 file.

NOTE 1   For simplicity, not all the entities have been shown in the diagram.

NOTE    The Observation can be classified. For example, if a fault observed has a safety implication, then observation would be classified as Safety critical.

Figure 2 —  Representation of a person making an observation during a work order

Once an observation has been made, the observer may require some work to be done as a result. In other words, there is a consequence of the observation. This is represented by a: Work_request. For example, if a mechanic notices during the routine service of a car, that a cam belt is worn, he will normally notify the customer and suggest that cam belt is replaced.

Figure 3 illustrates the representation of an Observation that results in an Observation_consequence.

NOTE 2   The Observation_consequence cannot be classified with reference data.

Figure 3 —  Representation of a observation resulting in a consequence

Complex observations

In a case where a series of observations are made or where a hierarchy of observations - representing, for example increasing levels of detail - is required multiple instances of Observation are created and related by instances of Observation_relationships.

When observations are broken down into a set of smaller observations, then the Observation_relationship is classified as [Observation_decomposition_relationship]
Error RDL1: The class Observation_decomposition_relationship does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

For example, an observation may be made that a car has overheated and a further observation made, that the oil pressure warning light is flashing and that there is a puddle of oil under the car. The first observation would be related to a the other two via an Observation_relationship is classified as [Observation_decomposition_relationship]
Error RDL1: The class Observation_decomposition_relationship does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

The Observation_relationship can also be classified as an [Observation_association]
Error RDL1: The class Observation_association does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, indicating that the relationship represents two observations that are associated or [Observation_sequence_relationship]
Error RDL1: The class Observation_sequence_relationship does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
indicating that the relationship represents a sequence of observations.

Figure 4 illustrates the representation of an observation hierarchy containing one parent Observation and two child Observations made in the context of a Work_order.

Figure 4 —  Representation of observation decomposition hierarchy

Model Characterization

This section specifies how the information model can be further characterized by the assignment of additional information such as dates, approvals and people or organizations.

The following characterizations may apply.

Characterization: Assigning approvals (Optional)

Approvals of observations are represented by the assignment of Approval objects to Observation objects using Approval_assignment objects.

NOTE 2   The assignment of approvals is described in the capability: C019: assigning_approvals.

Characterization: Assigning classifications (Optional)

The classification of observations or of relationships between observations is represented by the assignment of Class objects to Observation, and Observation objects using Approval_assignment objects.

Characterization: Assigning dates and times (Optional)

Dates and times of observations are represented by the assignment of Date_time objects or Calendar_date objects to Observation objects using Date_or_date_time_assignment objects.

NOTE 2   The assignment of date and times is described in the capability: C036: assigning_date_time.

Characterization: Assigning persons and organizations (Optional)

The ownership or responsibility for observations is represented by the assignment of Organization and Person_in_organization objects to Observation objects using Organization_or_person_in_organization_assignment objects.

Capability templates

The following sections define a set of templates for the capability, where a template is a specification of a set of entities that need to be instantiated to represent a given set of information.

This section specifies the template assigning_observation.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  An EXPRESS-G representation of the Information model for assigning_observation

Figure 2 —  The graphical representation of the assigning_observation template

Figure 3 —  Entities instantiated by assigning_observation template

Figure 4 —  Instantiation of assigning_observation template

Figure 5 —  Characterization of assigning_observation template

Dependent capabilities

This capability "representing observation" is dependent on the following capabilities:

• C036: assigning_date_time
• C010: assigning_reference_data
• C016: representing_person_organization

Model reference data

The following classes of reference data are required for this capability:

© OASIS 2010 — All rights reserved