Business overview

This section provides a business level overview of this capability.

A realized product is an actual or future artefact that results from a process, such as manufacturing.

In PLCS, a distinction is made between:

• the design of something; e.g. the specification, drawings, manufacturing details;

  EXAMPLE    The design of bicycle.

  The design is identified and modelled as Part.

• an artefact that is planned to be made or is being made from the design;

  EXAMPLE    The bicycle that has been ordered and scheduled for manufacture at a particular date.

  NOTE    Whilst the realized artefact has not been made, it is identified so that maintenance plans and facilities can be planned for it.

  The planned artefact is referred to as a planned product and modelled as a Product_as_planned.

• an artefact that has been made;

  EXAMPLE    The bicycle that has been delivered to a customer.

  The realized artefact is referred to and modelled as a Product_as_realized,

This distinction is summarized in Figure 1 which shows the Part design, identified by a part number, and the artifacts manufactured from that design, identified by serial numbers.

Figure 1 —  Relationship of a product design and an artefact

Throughout the life of an artefact, changes will be made to it. For example, a safety modification may be made to a car, or a new set of spark plugs installed. In order to track the evolution of these changes the artefacts will be represented by versions where a version represents the artefact after a given change or modification has been applied. These representation of versions is shown in Figure 2.

Figure 2 —  Version-ed parts

This capability describes the information required to represent the planned and realized artefacts. The representation of the design of the artefact is out of scope of this capability and is addressed in C002: representing_parts.

Information model overview

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

An abstraction of an EXPRESS-G diagram for the product as realized model is shown in Figure 3 below.

NOTE    This diagram is a summary of the information model.

Figure 3 —  Summary of product as realized

The key entities are:

Part:

The Part collects the information that is common to all versions of a part design and the artefacts resulting from that design. In particular the identification of the part by a part number is represented by assigning an identifier classified as "Part identification code" (urn:plcs:rdl:std:Part identification code) to the Part (See C001: assigning_identifiers for details). Further characterization of the part is described in C002: representing_parts.

Part_version:

The Part_version represents versions of the design of the part. The version is identified by assigning an identifier, classified as "Version identification code" (urn:plcs:rdl:std:Version identification code) to the Part_version. (See C001: assigning_identifiers for further details on identification).

Part_view_definition:

The Part_view_definition represents views of the design of the part.

Product_as_individual:

The Product_as_individual collects the information that is common to all versions of an individual artefact that has been made or is planned to be made.

If the artefact has been made from a known design, then the design is represented by a Part which is related to the artefact, the Product_as_individual, by a Product_design_to_individual relationship.

NOTE    It is possible but not recommended to relate a Breakdown_element as the design of a Product_as_individual. by a Product_design_to_individual relationship.

An artefact is identified by a subclass of "Product as individual identification code" (urn:plcs:rdl:std:Product as individual identification code), e.g. a serial number or batch code. A serial number is represented by an Identification_assignment classified as "Serial identification code" (urn:plcs:rdl:std:Serial identification code) that is assigned to the Product_as_individual. A batch number is instead classified as [Batch_identification_code]
Error RDL1: The class Batch_identification_code does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
(See C001: assigning_identifiers for further details on identification).

Product_as_planned:

The Product_as_planned represents a version or revision of a proposed or planned artefact. The version is related back to the serial numbered artefact (Product_as_individual) through the "of_product" attribute of the Product_as_planned and is identified by a version code. The version code is represented by assigning an identifier classified as "Version identification code" (urn:plcs:rdl:std:Version identification code) to the Product_as_planned. (See C001: assigning_identifiers for further details on identification).

If the proposed artefact is to be made from a design then it is related to the version of the design (Part_version) by the relation entity Product_design_version_to_individual.

Product_as_realized:

The Product_as_realized represents a version of an artefact that has been made. The version is related back to the serial numbered artefact (Product_as_individual) through the "of_product" attribute of the Product_as_realized and is identified by a version code. The version code is represented by assigning an identifier classified as "Version identification code" (urn:plcs:rdl:std:Version identification code) to the Product_as_realized. (See C001: assigning_identifiers for further details on identification).

If the artefact has been made from a design then it is related to the version of the design (Part_version) by the relation entity Product_design_version_to_individual.

Product_as_individual_view:

The Product_as_individual_view represents different views of the Product_as_planned or Product_as_realized

The type of view is represented by a View_definition_context that is classified.

A more detailed EXPRESS-G diagram for the product as realized model is shown in Figure 4 below and explained in the following sections.

NOTE    The EXPRESS-G is not complete.

Figure 4 —   EXPRESS-G

Identification of realized products

The diagram in Figure 5 shows the identification of a realized product. The realized product is represented by an instance of Product_as_realized. The identifier is represented by an instance of Identification_assignment (#5) classified as a "Version identification code" (urn:plcs:rdl:std:Version identification code). (See C001: assigning_identifiers for further details on identification).

The individual product for which this is a version, is represented by an instance of Product_as_individual. The identifier is represented by an instance of Identification_assignment (#13) classified as "Serial identification code" (urn:plcs:rdl:std:Serial identification code).

The part for which this is a realization occurrence is represented by an instance of Part. The part number is assigned by an instance of Identification_assignment (#6) classified as "Part identification code" (urn:plcs:rdl:std:Part identification code) (See C001: assigning_identifiers for further details on identification).

Figure 5 —  Identification of a realized product

Identification of planned product

The diagram in Figure 6 shows the identification of a planned product together with the realization of that planned product. The planned product is represented by an instance of Product_as_planned; the realized product is represented by an instance of Product_as_realized; and the relationship between the Product_as_planned and the Product_as_realized is represented by and instance of Product_planned_to_realized.

Figure 6 —  Identification of a planned product

Views of realized products

Each realized product can be viewed in different contexts, such as a design view and in-service view. Each view is represented by an instance of Product_as_individual_view and the context of the view is represented by an instance View_definition_context. The meaning of the context is provided by classifying the View_definition_context.

There are two aspects to the identification of the context. The "Application domain" and the "Life cycle stage".

Application domain

The Application_domain is the general application domain that defined the data.

EXAMPLE    'assembly study', 'digital mock-up', 'electrical design', 'mechanical design', 'preliminary design', 'process planning' are examples of application domains

Life cycle stage

The life cycle stage identifies a stage in the life of a product.

EXAMPLE    'design phase', 'production', 'recycling phase' are examples of life cycle stages.

The attributes application_domain and life_cycle_stage of entity View_definition_context should not be used. Instead, the values of "Application_domain" and "Life cycle stage" should be represented using classification. The attributes of each View_definition_context, application_domain and life_cycle_stage, are set to '/IGNORE', and each View_definition_context is classified as a subclass of "Application domain" (urn:plcs:rdl:std:Application domain) and a subclass of "Life cycle stage" (urn:plcs:rdl:std:Life cycle stage).

An example is shown below in Figure 7. It shows two "Application domain" (urn:plcs:rdl:std:Application domain) views of Bike. An [Electrical_design]
Error RDL1: The class Electrical_design does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
view, and a [Mechanical_design]
Error RDL1: The class Mechanical_design does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
view. Each view is in the "Support stage" (urn:plcs:rdl:std:Support stage) stage of the product life cycle.

The bike is represented by Product_as_individual (#8) and Product_as_realized (#7).

The mechanical support view of the bike is represented by Product_as_individual_view (#34) and an instance of View_definition_context (#25) that is classified as [Mechanical_design]
Error RDL1: The class Mechanical_design does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
by External_class (#32). The View_definition_context (#25) is also classified as "Support stage" (urn:plcs:rdl:std:Support stage) by External_class (#29).

The electrical support view of the bike is represented by Product_as_individual_view (#35) and an instance of View_definition_context (#26) that is classified as [Electrical_design]
Error RDL1: The class Electrical_design does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
by External_class (#31). The View_definition_context (#25) is also classified as "Support stage" (urn:plcs:rdl:std:Support stage) by External_class (#29).

Figure 7 —  Views of a realized product

Properties of realized products

Properties that are predicted or observed on a Product_as_realized can be associated with a given view. The use of properties is described in C076: assigning_product_properties, C079: representing_properties_numerically and C080: representing_properties_textually

Versions of realized products

When a modification is made to a Product_as_realized a new version is created. This is represented by creating a new instance of a Product_as_realized and relating it back to the previous Product_as_realized by a Product_version_relationship, classified using external reference data. This represents a version history.

There are three types of relationships between Product_as_realized used to represent the version history:

• Sequential relationship: This indicates that one version follows or is derived from the previous version of the same Product_as_individual. The relating_version is the preceding version (Product_as_realized) and the related_version is the subsequent version (Product_as_realized). Both versions must be associated with the same Product_as_individual. A Product_as_realized may have at most one preceding and one subsequent version.

  A sequential relationship is represented by a Product_version_relationship classified using external reference data as [Sequential_version_relationship]
  Error RDL1: The class Sequential_version_relationship does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  

• Hierarchical relationship: This indicates that one version is a sub version of the same Product_as_individual. The related_version version (Product_as_realized) is a sub version of the relating_version version (Product_as_realized). Both versions must be associated with the same Product_as_individual. Each Product_as_realized version may have at most one super version (parent in the hierarchy). A Product_as_realized version may have an arbitrary number of sub versions (children in the hierarchy). Product_as_realized versions related by hierarchical relationships may not define cyclic relationships.

  NOTE    For physical products, the hierarchical relationship may not be easy to understand or use, but for software products it is often used.

  A hierarchical relationship is represented by a Product_version_relationship classified using external reference data as [Hierarchical_version_relationship]
  Error RDL1: The class Hierarchical_version_relationship does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  

  EXAMPLE    'Rev. 1.1' and 'Rev. 1.2' are subordinates of 'version 1'.

• Derived relationship: This indicates that a version is derived from a version of a different Product_as_individual. The relating_version is the preceding version (Product_as_realized) and the related_version is the derived version (Product_as_realized). Each versions is associated with the different Product_as_individuals.

  A derived relationship is represented by a Product_version_relationship classified using external reference data as [Derived_version_relationship]
  Error RDL1: The class Derived_version_relationship does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  

The version code is provided assigning an identifier classified as "Version identification code" (urn:plcs:rdl:std:Version identification code) to the Product_as_realized. (See C001: assigning_identifiers for further details on identification).

An example of two versions of a bicycle is shown in Figure 8.

Figure 8 —  Versions a realized product

No versioning of Individual Products

Many organizations do not version individual products, i.e. they either change the identifier of the individual product after a major modification, or they simply do not keep a (digital) history of what has happened to the real product. For such organizations, it is recommended that the identification of the Product_as_realized is set to "/NULL", i.e. the attribute identifier of entity Identification_assignment contain the string "/NULL" (see C001: assigning_identifiers), to indicate that no version information is relevant or intended. In this case only a single product_as_realized for the product_as_individual is possible.

For such organizations, some of the version relationships described here are no longer applicable, and relationships between Product_as_individuals may be more appropriate, e.g. a Product_as_individual may be derived from another Product_as_individual. The Product_relationship entity may be used to describe such relationships, using the same external reference data classes.

If the value of the identification attribute for a Identification_assignment assigned to a Product_as_realized is the string '/NULL', postprocessors should use this as an indication that the sending system or business process does not support versioning of Product_as_individuals.

Relationship of realized products to the design

A realized product can be related back to the version of the design from which it was created. This is shown in Figure 9 which shows an actual bike, represented by an instance of Product_as_individual (#7) related to the design, represented by an instance of a Part (#9) by an instance of a Product_design_to_individual (#10); and an as built version of that individual a bike, represented by an instance of Product_as_realized (#8) related to the version of the design, represented by an instance of a Part_version (#23) by an instance of a Product_design_version_to_individual (#24)

Figure 9 —  Relationships of actual products to designs

NOTE    It is possible but not recommended to relate a Breakdown_element as the design of a Product_as_individual. by a Product_design_to_individual relationship.

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 a Person or Organization (Optional)

A person or organization can be assigned to Product_as_individual in a given role, such as "owner". This is represented by assigning a Person_in_organization or Organization (using the relationship Organization_or_person_in_organization_assignment) to the Product_as_individual. The role of the assignment is represented by classifying the assignment by the use of reference data (see C010: assigning_reference_data). In the case where the Product_as_individual Person_in_organization is the owner of the Product_as_individual the Organization_or_person_in_organization_assignment is classified as "Owner of" (urn:plcs:rdl:std:Owner of). Other possible classifications are:

• "Creator of" (urn:plcs:rdl:std:Creator of);
• "Operator of" (urn:plcs:rdl:std:Operator of).

NOTE    The assignment of a person or organization is described in the capability C016: representing_person_organization.

Characterization: Assigning Dates (Optional)

Dates can be assigned to Product_as_individual, Product_as_planned and Product_as_realized in a given role, such as "Date actual creation" (urn:plcs:rdl:std:Date actual creation). This is represented by using the relationship Date_or_date_time_assignment) to assign a date in a given role. The role of the assignment is represented by classifying the assignment by the use of reference data (see C010: assigning_reference_data.

NOTE    The assignment of dates is described the capability C036: assigning_date_time.

Characterization: Assigning documents (Optional)

Documents can be assigned to Product_as_individual_view in a given role, such as "maintenance instructions". This is represented by using the Document_assignment relationship as described in capability C005: representing_documents. The role of the assignment is represented by classifying the assignment by the use of reference data (see C010: assigning_reference_data.

Additional Usage Guidance

Issue: NN-1 by Nigel Newling (2005-11-17) [minor_technical, closed] - {Type = contents}
Make it clear in the text that the relation_type attribute on Product_version_relationship is not populated by the actual value but classified.

Comment: (Peter Bergström 2007-01-24)
Fixed in text and detailed Express-G diagram.

Product structures with individual products

An individual product may be broken down into its constituents, very much in the same way as type products (assemblies) can, and an individual product may be part of a product structure as a constituent (similar to parts). PLCS provides two different methods to do this.

The most flexible method to use for describing structures of individual products is to use a Breakdown of an individual product, where Breakdown_elements are used to represent the logical element in a structure. A Breakdown_element can then be realized as an individual product (or its version: Product_as_realized) through Breakdown_element_realization.

Breakdowns offer all abstraction levels needed to represent realization of logical concepts (breakdown_elements), "functional locations", slots, "virtual parts", and whatever a business domain may require in terms of representing different product structures and their interrelationships. It covers the requirements from early design stages and systems engineering, through design and manufacturing, the in-support phases, and recycling.

The use of Breakdowns, Breakdown_elements, and Breakdown_element_realizations to create structures of individual products is described in C004: representing_breakdown_structure.

An alternative method is to build a structure using instances of Next_assembly_usage and combine the individual products directly into an assembly (or possibly better: disassembly structure). This approach is fine when the scope of the structure is narrower, e.g. to create a single maintenance structure of a product, and where there are no requirements to integrate with other structures (e.g. breakdowns).

This approach is further described in C003: representing_assembly_structure.

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

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 Product_as_realized

Figure 2 —   The graphical representation of representing_product_as_realized template

Figure 3 —  Entities instantiated by representing_product_as_realized template

Figure 4 —  Instantiation of representing_product_as_realized template

Figure 5 —  Characterization by property, document and state of a real product

This section specifies the template referencing_product_as_realized.

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 referencing_product_as_realized

Figure 2 —  The graphical representation of the referencing_product_as_realized template

Figure 3 —  Entities instantiated by referencing_product_as_realized template

Figure 4 —  Instantiation of referencing_product_as_realized template

This section specifies the template referencing_product_as_individual.

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 referencing_product_as_individual

Figure 2 —  The graphical representation of the referencing_product_as_individual template

Figure 3 —  Entities instantiated by referencing_product_as_individual template

          #1 = PART('/IGNORE','/IGNORE','/IGNORE');
          #2 = PRODUCT_AS_INDIVIDUAL('/IGNORE','/IGNORE','/IGNORE');
          #3 = PRODUCT_DESIGN_TO_INDIVIDUAL(#1,#2);
          #5 = IDENTIFICATION_ASSIGNMENT('23465-481','/IGNORE',$,(#2));
          #7 = CLASSIFICATION_ASSIGNMENT(#9,(#5),'/IGNORE');
          #9 = EXTERNAL_CLASS('/NULL','Serial_number','/IGNORE',#10);
          #10 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample',$);
          #12 = ORGANIZATION('/IGNORE','/IGNORE');
          #14 = IDENTIFICATION_ASSIGNMENT('Bike Ltd','/IGNORE','/IGNORE',(#12));
          #16 = CLASSIFICATION_ASSIGNMENT(#18,(#14),'/IGNORE');
          #18 = EXTERNAL_CLASS('/NULL','Organization_name','/IGNORE',#19);
          #19 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std',$);
          #20 = ORGANIZATION_OR_PERSON_IN_ORGANIZATION_ASSIGNMENT(#12,'/IGNORE',(#5));
          #22 = CLASSIFICATION_ASSIGNMENT(#24,(#20),'/IGNORE');
          #24 = EXTERNAL_CLASS('/NULL','Owner_of','/IGNORE',#19);
        

Figure 4 —  Instantiation of referencing_product_as_individual template

This section specifies the template representing_product_as_realized_structure.

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

Error model_diag_1: Either delete A DESCRIPTION OF THE DIAGRAM or provide a description
A DESCRIPTION OF THE DIAGRAM

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

Error model_diag_1: Either delete A DESCRIPTION OF THE DIAGRAM or provide a description
A DESCRIPTION OF THE DIAGRAM

Figure 2 —  The graphical representation of the representing_product_as_realized_structure template

Figure 3 —  Entities instantiated by representing_product_as_realized_structure template

          #1 = TASK_METHOD($,$,$,$,());
          #2 = EXTERNAL_CLASS('/IGNORE','Safety_critical',$,#3);
          #3 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std',$);
          #4 = CLASSIFICATION_ASSIGNMENT(#2,(#1),'/IGNORE');
        

Figure 4 —  Instantiation of representing_product_as_realized_structure template

Figure 5 —  Characterizations for representing_product_as_realized_structure

Related capabilities

This capability "Representing an individual product" is related to the following capabilities:

• C003: representing_assembly_structure
• C004: representing_breakdown_structure
• C076: assigning_product_properties
• C079: representing_properties_numerically
• C080: representing_properties_textually
• C005: representing_documents
• C036: assigning_date_time

Dependent capabilities

This capability "Representing an individual product" is dependent on the following capabilities:

• C010: assigning_reference_data
• C001: assigning_identifiers
• C002: representing_parts

Model reference data

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

© OASIS 2010 — All rights reserved