Business overview

This section provides a business level overview of this capability.

This capability describes how to represent the state that something is in.

A state in this context represents a mode of being of something, such as a Product_as_realized. These may be possible states that it can be in, or actual states that it is observed to be in or is predicted to be in at some time in the future.

Examples of states are a particular failure state, an approval state, a progress state, such as 'in-work'.

Information model overview

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

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

NOTE    The EXPRESS-G is not complete. For the complete EXPRESS see the modules: State observed, State definition and State characterized.

Figure 1 —  EXPRESS-G for observed states

States

A state in this context represents a mode of being of something, such as a Product_as_realized or Activity_actual. These may be possible states that it can be in, or actual states that it is observed to be in or is predicted to be in at some time in the future.

Applied state assignment

An State_observed can be assigned to something indicating that the target of the assignment is in the observed state. This is done by using the Applied_state_assignment. The State_role linked through the role attribute describes the purpose of the assignment. In all cases the assignment is stating that the target is in the observed state (State_observed). Consequently the State_role should be instantiated to ensure a valid instantiation, but the name set to '/IGNORE'.

Possible states

Possible states are defined states that something, such as a Product_as_realized could possibly be in. Common state definitions are the normal operating states of the product or recognized fault states. Normally a set of possible states are defined for a product. For example a FME(C)A will define a set of fault states that a product may be in.

A possible or defined state is represented by State_definition and described in the capability C007: representing_state_type.

NOTE    The defined states are represented by reference data.

Observed states

An observed state is the identification of a defined state in which something, such as a Product_as_realized is observed to be in.

An observed state is represented by the entity State_observed. The EXPRESS-G for the state observed model is shown in Figure 1 above and explained in the following sections.

Observed to defined states

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 that is equal to the state defined by the State_definition.

Classification of Observed states

A State_observed is an occurrence of a State_definition, therefore any classification of State_observed should be provided by classifying the State_definition of which it is occurrence.

Identification of Observed states

Characterization of Observed states

An observed state is a record of the observation that something, such as a Product_as_realized, is in a given state. The person who observed the state and the date on which the observation was made, can be recorded. The date on which the observation was made is represented by assigning a Calendar_date or Date_time to the State_observed by Date_or_date_time_assignment as described in the capability C036: assigning_date_time.

NOTE    The Date_or_date_time_assignment is classified as "Date actual observation" (urn:plcs:rdl:std:Date actual observation).

The Person and organization who made the observation that something, such as a Product_as_realized, is in a given state, can be represented by assigning a Person_in_organization to the State_observed by Organization_or_person_in_organization_assignment as described in the capability C016: representing_person_organization.

NOTE    The Organization_or_person_in_organization_assignment is classified as "Observer of" (urn:plcs:rdl:std:Observer of).

An instance diagram showing a bike in the observed state "being ridden" is given in Figure 2. The diagram also shows the person who made the observation about the state and the date when the observation was made and the fact that the State_observed (#1) "at sea" was an assessment.

Figure 2 —  An observed state of a Bike - being ridden

Confirmation of Observed states

A State_observed can be confirmed as being the state as defined (State_definition) by evaluating the conditions that were used to define the State_definition. This leads to an assertion that the State_observed corresponds to the State_definition. The representation of a condition is described in the capability C026: representing_condition. The representation of an evaluated condition is described in the capability C048: representing_condition_evaluated.

An instance diagram showing an assertion that a ship is in the observed state "at sea" is given in Figure 3. The definition of the state, State_definition (#3), is provided by a condition, Condition (#12), that has two parameters as input, Condition_parameter (#13) and Condition_parameter (#14). Condition_parameter (#14) indicates that some test equipment is used to determine that the ship is at sea. Condition_parameter (#13) indicates that the condition is based on the part, ship. The assertion that the ship is at sea is represented by the State_assertion (#10). A record of how the assertion was made is provided by the Condition_evaluation (#24) that is assigned to the State_assertion (#10).

Figure 3 —  A observed state confirmed

Properties can also be used as condition parameters to confirm that something, such as a Product_as_realized, is in an State_observed which corresponds to the State_definition.

Predicted States

Predicted states are predictions that something, such as a Product_as_realized, will be in a given state at some time in the future. These may be operating states of the product or fault states.

NOTE    A predicted state is the predicted occurrence of a defined state at some time in the future. It should not be confused with a possible or defined state.

A Predicted state is represented by the entity State_predicted.

An instance diagram showing this example is given in Figure 4.

Figure 4 —  A observed state confirmed

State transitions

There are a number of entities that can be used to record the fact that something, such as a Product_as_realized, moved from one state to another:

• State_relationship - defines a relationship between two states;
• State_transition - defines a transition between two states;
• Sequence_of_state - defines a sequence of two states;
• Composition_of_state - defines that two or more State entities act as parts to compose a whole;
• State_cause_effect - defines define a causal relationship between two state definitions.

An instance diagram showing the fact that a ship went from the state "At sea" to the state "In dock" is given in Figure 5.

Figure 5 —  Observed state transition

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_assessed_state.

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_assessed_state

Figure 2 —   The graphical representation of assigning_assessed_state template

Figure 3 —  Entities instantiated by assigning_assessed_state template

Figure 4 —  Instantiation of assigning_assessed_state template

Figure 5 —  Characterizations for assigning_assessed_state

The following characterizations may apply:

Characterization Assigning dates

NOTE   this characterization is optional.

Dates and times can be associated with the assignment of an assessed state in a given role by using the template assigning_time.

Figure 6 —  Characterization by date and time of assigning_assessed_state template

Several dates can be assigned to the template assigning_assessed_state, however two dates and times are commonly assigned to these being the date and times on which the state was assessed and the date and time when the state was observed.

The date and time on which the state was assessed is represented by using the template assigning_time to assign a date and time to State_assessment. The date assignment is classified as: "Date actual assessment" (urn:plcs:rdl:std:Date actual assessment) to indicate that it is the date and time when the state was assessed. This is illustrated in Figure 6.

The date and time on which the state was observed is represented by using the template assigning_time to assign a date and time to State_observed. The date assignment is classified as: "Date actual observation" (urn:plcs:rdl:std:Date actual observation) to indicate that it is the date and time when the state was observed. This is illustrated in Figure 6.

Characterization Assigning person

NOTE   this characterization is optional.

People can be associated with the assignment of an assessed state in a given role by using the template assigning_person_in_organization to assign a person to either a State_observed or a State_assessment.

Figure 7 —  Characterization by person of assigning_assessed_state template

Several roles can be assigned to an assessed state. Two common roles in which people are assigned to the assignment of an assessed state are as an "Assessor of" the state and as an "Observer of" the state.

The person who assessed the state is represented by using the template assigning_person_in_organization to assign a person to State_assessment. The assignment of the person (Organization_or_person_in_organization_assignment) is classified as: "Assessor of" (urn:plcs:rdl:std:Assessor of) to indicate that it is this person who has assessed the state. This is illustrated in Figure 7.

The person who observed the state is represented by using the template assigning_person_in_organization to assign a person to State_observed. The assignment of the person (Organization_or_person_in_organization_assignment) is classified as: "Observer of" (urn:plcs:rdl:std:Observer of) to indicate that it is this person who has observed the state. This is illustrated in Figure 7.

Characterization Assigning Identification

NOTE   this characterization is optional.

Identifiers can be associated with the assignment of an assessed state by using the template assigning_identification to assign an identifier to a State_observed.

Figure 8 —  Characterization by identifier of assigning_assessed_state template

An example of the use of an identifier could be to identify the fault that is the reason for a repair activity.

This section specifies the template assigning_asserted_state.

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_asserted_state

Figure 2 —   The graphical representation of assigning_asserted_state template

Figure 3 —  Entities instantiated by assigning_asserted_state template

Figure 4 —  Instantiation of template

Figure 5 —  Characterizations for assigning_asserted_state

The following characterizations may apply:

Characterization Assigning times

NOTE   this characterization is optional.

Dates and times can be associated with the assignment of an asserted state in a given role by using the template assigning_time.

Figure 6 —  Characterization by date of assigning_asserted_state template

Several dates can be assigned to the template assigning_asserted_state, however two dates and times are commonly assigned these being the date and time on which the state was asserted and the date and time when the state was observed.

The date and time on which the state was asserted is represented by using the template assigning_time to assign a date and time to State_assertion. The date assignment is classified as: "Date actual assertion" (urn:plcs:rdl:std:Date actual assertion) to indicate that it is the date when the state was asserted. This is illustrated in Figure 6.

The date and time on which the state was observed is represented by using the template assigning_time to assign a date and time to State_observed. The date assignment is classified as: "Date actual observation" (urn:plcs:rdl:std:Date actual observation) to indicate that it is the date when the state was observed. This is illustrated in Figure 6.

Characterization Assigning person

NOTE   this characterization is optional.

People can be associated with the assignment of an asserted state in a given role by using the template assigning_person_in_organization to assign a person to either a State_observed or a State_assertion .

Figure 7 —  Characterization by person of assigning_asserted_state template

Several roles can be assigned to an asserted state. Two common roles in which people are assigned to the assignment of an asserted state are as an "Assessor of" the state and as an "Observer of" the state.

The person who asserted the state is represented by using the template assigning_person_in_organization to assign a person to State_assertion. The assignment of the person (Organization_or_person_in_organization_assignment) is classified as: "Asserter of" (urn:plcs:rdl:std:Asserter of) to indicate that it is this person who has asserted the state. This is illustrated in Figure 7.

The person who observed the state is represented by using the template assigning_person_in_organization to assign a person to State_observed. The assignment of the person (Organization_or_person_in_organization_assignment) is classified as: "Observer of" (urn:plcs:rdl:std:Observer of) to indicate that it is this person who has observed the state. This is illustrated in Figure 7.

Characterization Assigning Identification

NOTE   this characterization is optional.

Identifiers can be associated with the assignment of an asserted state by using the template assigning_identification to assign an identifier to a State_observed.

Figure 8 —  Characterization by identifier of assigning_asserted_state template

An example of the use of an identifier could be to identify the fault that is the reason for a repair activity.

Related capabilities

This capability "Representing an observed state" is related to the following capabilities:

• 
  Error C1: Capability referencing_documents not in dex_index.xml
  
• 
  Error C1: Capability referencing_activity not in dex_index.xml
  
• C076: assigning_product_properties
• C048: representing_condition_evaluated
• C026: representing_condition

Dependent capabilities

This capability "Representing an observed state" is dependent on the following capabilities:

• C036: assigning_date_time
• C001: assigning_identifiers
• C010: assigning_reference_data
• C016: representing_person_organization
• 
  Error C1: Capability referencing_product_as_individual not in dex_index.xml
  
• C007: representing_state_type

Model reference data

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

© OASIS 2010 — All rights reserved