Introduction

This section provides general guidance and background on the modelling constructs used in the DEXs. More detail is provided in the capabilities.

Overall approach

Product life cycle support implies holding information about products through their life. This leads to the need to manage change of that information over time. This has the following modelling consequences when compared to supporting the exchange of data sets that reflect a short period in time.

1. Use of explicit attributes of an entity, such as x.id where x is an entity data type and id is an identifier, is discouraged. For the example of x.id, assigning an identifier to x by means of an assignment entity is preferred as this allows for different identifiers over time to be recorded;
2. Allowance has to be made for holding multiple values of properties that have been used or apply over different time periods, such as where a new value is available based on experience rather than estimation. Not only is it necessary to be able to hold more than one value, for example, for a given property, it then becomes necessary to associate other data with these values, such as recording who provided the values and when. Where an entity has a value associated by an explicit attribute this is not possible;
3. The set of requirements for the model are not completely known and new requirements will arise during the period of its use and during the life time of a product for which the model is being used. Therefore many of the modules used allow for classification of entities, where such classification is used to augment the definitions provided in this part of ISO 10303 and the parts of ISO 10303 referenced by it.

Specific cases of these consequences are described in the following sections.

Use of classification

The domain covered by ISO 10303-239 is large and includes many specific requirements that have not been explicitly modelled in the information model. Instead of providing explicit subtypes for many of the entities, the entity has been made a target for Classification_assignment. Thus one or more classes can be associated with any instance of the entity concerned. These classes refine or augment the meaning of the entity. This is described further in the capability C010: assigning_reference_data.

For example, there are many different types of properties associated with components that are relevant to product life cycle support. The model allows the properties that can be associated with parts to be classified. Such classification is then used to specify the specific type of property. Any set of specific property types, such as mean time to failure, that could have been provided by explicit modelling in the model, is likely to be incomplete. Furthermore, as business practices change, different properties are likely to be required over time and these can be introduced by means of a new class.

Similarly, if it is required to make an assertion about something, this can be achieved by classification. For example, a Task_method that involves risk to the persons who carry out the method can be asserted to be safety critical by means of classification.

This approach relies on the use of a common set of classes between partners in a data exchange, together with a shared understanding of what each class means. It is anticipated that classes will be held in a shared class library.

Classification_assignment provides the principal mechanism for associating classes with items. However, an additional mechanism is provided for products, that is Product_category. See the Product categorization and Product identification modules. Product_category is used to distinguish between the different subtypes of Product defined in this part of ISO 10303. Examples are: Part, Requirement and Document. This approach is used by other ISO 10303 Application ProtocolApplication Protocol parts. More specific types of products, such as Oil filter as a type of Part should be specified by means of Classification_assignment, thus allowing the use of a class library via External_class.

General use of assignment entities

The information model defines a set of assignment entities. Examples include:

1. Activity_method_assignment;
2. Applied_activity_assignment;
3. Applied_state_assignment;
4. Applied_state_definition_assignment;
5. Selected_item_assignment.

Such entities have a role attribute that can be used to define the specific meaning of each assignment. Where such assignment entities have a role attribute of type STRING and the entity is also included in the classification_item select, classification is the preferred means by which to assert the meaning of the assignment. The role attribute is then instanced with the value set either to be an empty (zero-length) string or to be '/IGNORE'. The use of '/IGNORE' is recommended.

NOTE    In general, attribute values are set to '/IGNORE' when the information that could be held be the attribute is instead assigned to the instance of the entity.

Use of identification assignment

For historical reasons, the information model specified in ISO 10303-239 contains multiple identifier attributes, typically modelled as x.id where x is the entity name. This implies that there is only one identifier for the entity and either it does not change or the model does not allow for any means of recording change except by over-writing the value.

In practice, identifiers can change over time and also there may be more than one identifier that applies to something. The latter case typically arises where organizations assign their own identifiers to things. A consequence of this is that an identifier as a string of characters is not useful without knowing more. At a minimum it is necessary to know which organization is responsible for the identifier.

Therefore all requirements for identifiers are met using the basic structure shown in the Figure 1 below. See capability C001: assigning_identifiers for further details.

Note that both Organization_or_person_in_organization_assignment and Identification_assignment have role attributes that have been given the string '/IGNORE'. The respective roles are 'Id_owner' and, given that the thing being identified in the example is a Part, 'Part_type_code'. These are specified by using Classification_assignment.

A number of entities have a name attribute in addition to the id attribute. Where this is being used to assign a name, then the name should be treated as an identifier and assigned using Identification_assignment using the same basic structure shown in Figure 1 below. See capability C001: assigning_identifiers for further details.

Figure 1 —  Identification assignment example

Assignment of names

Assignment of descriptions

AP239 select matrix

A matrix showing all the population of all the EXPRESS selects in AP239 is available as an EXCEL spreadsheet(../../docs/ap239/ap239_select_matrix.xls).