DEX (D008):— product_as

NOTE The diagram above illustrates those capabilities that have a bearing upon the definition of the product to be supported. They are collected into functional groups which relate the capabilities within. The diagram does not show the relationships between the capabilities within or across these functional groups. Each capability shows how they use others in an overview diagram within the Information Model section at the beginning of each capability.

NOTE A part may be refered to through it's design by the EXPRESS entity Part, though the actual occurence of a version of the product may also be referenced instead, as represented (for example,) by the EXPRESS entity Product_as_realized.

Information Management

Managing information relies upon identification and this is a recurring key concept within PLCS and this Dex.

Identification of the Design

The design of the artefact needs to be able to be identified. This is achieved through referencing the product structure design. The use of a reference assumes that the receiver of the information already has the information that represents the entity being referenced. These references can be broken down into several aspects:

The mechanisms for defining these are outlined in the figure below and detailed in referencing_part_or_slot

Error C1: Capability referencing_part_or_slot not in dex_index.xml
.

Where the design has yet to be provided, product_breakdown_for_support gives the functionality and guidance to generate this.

View of the Product as Individual

The representation of the individual product;

The Product_as_individual is a generic term given by PLCS to a product which is in the process of being realized and becoming an artefact rather than the subject of a design.

The Product_as_individual is conceived, designed, planned, fabricated or acquired, assembled, is in-service, retires, and is destroyed, recycled, or discarded. During its life cycle, almost anything about it may change:

Its structural configuration may change as replaceable units are removed and replaced in the context of maintenance activities.
Its usage role within the structure of another product may change, as it is removed and reassembled into a different actual assembly, in a different slot, possibly even a different design.
Its properties may change as it is maintained, or as it wears.
Owners and even part identifiers may be added or discarded, due to changes in processes, suppliers, or ownership.

The representation of a Product_as_individual, defines the actual occurrence of a Part whether it be designed to be independent or a component of a larger product or assembly. Individuals need to be identified because, through life, they may need to be replaced. For example, due to wear, life expectancy, failure rate, or part alternatives. They may also need to be removed or substituted for other parts through mission requirements, upgrades or due to variants from redesign or reconfiguration.

Without adequate identification, the owner cannot be certain of the configuration of a product, that correct spares are available, that timely maintenence is being carried out, or that the product will fulfill it's functional requirements.

Therefore, each Product_as_individual must be able to be uniquely identified so that it's usage in all Product can be recorded across both versions and variations of those products.

With adequate identification, the usual operations of the product might then be supported, for example, regular maintenance, condition based maintenance, usage reporting, failure reporting, part changes, function changes, replacements and the upkeep to both the product and the APSI can be enabled.

The AP239 approach to representing individuals has been detailed in capability representing_product_as_realized
Error C1: Capability representing_product_as_realized not in dex_index.xml
and comprises the following steps;

Representation of the Individual
Representation of the Identification of the Individual
Representation of the Context of the Individual

Representation and Identification of an Individual

The capability representing_product_as_realized
Error C1: Capability representing_product_as_realized not in dex_index.xml
(soon to be representing_product_as_individual) describes the representation of describes the representation of Product_as_individual.

The Product_as_individual is represented by two distinct entities in PLCS. The representation, identification and contexts of these are described below;

Product_as_planned:: The Product_as_planned represents a proposed or planned artefact. It is identified either by a serial number, a catalogue number (e.g. NSN) or potentially a line number depending upon the life cycle stage and availability of the product refered to. These numbers are not mutually exclusive and are represented by assigning an identifier with the appropriate classification, such as "Serial identification code" (urn:plcs:rdl:std:Serial identification code) to the Product_as_planned. (See C001: assigning_identifiers for further details on identification). The identification may be further characterized through the assignment of an organization (e.g. the OEM), and a date or date/time that maybe used to help accurately reference the individual at a later time. The Product_as_planned maybe related to the Part through the attribute "of_product".; The Product_view_definition entity represents the identification of a particular view on a version of the product base relevant for the requirements of particular life-cycle stages and application domains. Views may be based on application domain and/or life-cycle stage (e.g., design, manufacturing). It is possible to have many Product_view_definition views. All Product_version entities should always have at least one associated Product_view_definition as this is the central element to link product information e.g., assembly structure, properties (including shape), and external descriptions of the product via documents (except in the case of supplied product identification and version history information).; All STEP Product_view_definitions must be founded in a View_definition_context to identify the life-cycle stage from which the data is viewed. The value of the attribute Product_view_definition.initial_context is a View_definition_context that represents the 'primary' defining context for a view. In general this defining context is qualified by life-cycle (View_definition_context.life_cycle_stage) information. Multiple additional contexts can be associated with a single definition through the set of Product_view_definition.additional_contexts.

Error I1; The image filename: ../.\img\Ref to a Product as Planned.jpg contains whitespace

Figure 13 — Representation of a Product as Planned

The part number is assigned to the Part by an instance of Identification_assignment which is classified as [Part_code]
Error RDL1: The class Part_code does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
. If the proposed artefact has been made from a version of the design then it maybe related to the version (Part_version) by the relation entity Product_design_to_individual.

Error I1; The image filename: ../.\img\Relationship between a Part Design and a Product as Planned.jpg contains whitespace

Figure 14 — Relationship of a Product as Planned to a Version of the Design

Product_as_realized:: The Product_as_realized entity represents an artefact that results from a process. It is identified by its serial number which is represented by assigning an identifier classified as "Serial identification code" (urn:plcs:rdl:std:Serial identification code) to the Product_as_realized. (See C001: assigning_identifiers for further details on identification). The identification may be further characterized through the assignment of an organization (e.g. the OEM), and a date or date/time that maybe used to help accurately reference the individual at a later time. The Product_as_realized is related to Part through the attribute "of_product".; The Product_view_definition entity represents the identification of a particular view on a version of the product base relevant for the requirements of particular life-cycle stages and application domains. Views may be based on application domain and/or life-cycle stage (e.g., design, manufacturing). It is possible to have many Product_view_definition views. All Product_version entities should always have at least one associated Product_view_definition as this is the central element to link product information e.g., assembly structure, properties (including shape), and external descriptions of the product via documents (except in the case of supplied product identification and version history information).; All STEP Product_view_definitions must be founded in a View_definition_context to identify the life-cycle stage from which the data is viewed. The value of the attribute Product_view_definition.initial_context is a View_definition_context that represents the 'primary' defining context for a view. In general this defining context is qualified by life-cycle (View_definition_context.life_cycle_stage) information. Multiple additional contexts can be associated with a single definition through the set of Product_view_definition.additional_contexts.

Error I1; The image filename: ../.\img\Ref to a Product as Realized.jpg contains whitespace

Figure 15 — Representation of a Product as Realized

If the artefact is a result of the product as planned then it maybe related to the relevant version of the Product_as_planned by the relation entity Product_planned_to_realized.

If the artefact has been made from a version of the design then it may also be related to the version (Part_version) by the relation entity Product_design_to_individual.

Error I1; The image filename: ../.\img\Relationships between Versions of Part Design, Product as Planned and Product as Realized.jpg contains whitespace

Figure 16 — Relationships of a Product as Realized to a Version of the Product as Planned and of the Design

A more detailed description of the representation of individuals is provided in the capability referencing_product_as_realized
Error C1: Capability referencing_product_as_realized not in dex_index.xml
(soon to become representing_product_as_individual).

Referencing a Product as Individual

To refer to product individuals that have already been exchanged, only the individual and it's associated identification entities are required. This is depicted in Figure 1 for Product_as_planned and in Figure 3 for Product_as_realized individuals. It may not always be necessary to use the organization and/or date assigned, though for unique identification is will provide greater assurance. However, an additional classification of the individual is required to be set to the string value 'reference'. A description of the referencing of realized individuals is provided in capability referencing_product_as_realized
Error C1: Capability referencing_product_as_realized not in dex_index.xml
(soon to become referencing_product_as_individual).

The representation of the individual product's configuration definition

The Dex supports the definition of product concepts, which define products from a market or customer oriented viewpoint. As they are offered to the customers, these product concepts often define conceptual 'product models' which are available or delivered to the customer in different configurations or variations.

Configuration identification in this Dex is the identification of product concepts and their associated configurations, the composition of which is to be managed. If a configuration of a product concept is implemented by a certain design, or individual i.e., a particular part version or product as realized, this version can be associated with the configuration and managed using configuration effectivity.

NOTE Explicit representation of the configurations of a product concept is suitable for management of design as-planned manufacturing configurations, the traditional BOM inputs to manufacturing resource planning. These explicit configurations may also be suitable for management of other activities 'downstream' from the design phase, such as as-built and as-maintained configurations.

The representation of product configuration identification is described in the capability C063: representing_product_configuration and whilst closely related, the representation of configuration composition management is described in the capability C006: assigning_effectivity.

To refer to an individual's product configuration that may have already been exchanged, requires the identification of the Product_configuration and identification details of the the individual product and version linked to the configuration by the Item_design_association. An additional classification of the these two main entities is required and should be set to the string value 'reference' so that they are treated correctly.

Representing the Product As Individual Configuration

The products that are sold by an organization to its customers are often defined as variations or configurations of a common product model, referred to as product concept. This product concept is defined in a market context and can be seen as a logical container for all of its variations. In the PLCS Schema, product concept identification is the representation of these product concepts with their related market context.

A Product_concept represents a conceptual idea of a class of similar products that are offered to a Market. No design or manufacturing related product data can be attached to the Product_concept directly. The members of that product class are the different configurations that are available for the Product_concept. Within the PLCS Schema, these configurations are defined explicitly as Product_configurations, each of them being potentially related to Product_as_individuals that implement the particular configuration. A Product_concept will usually be referenced by at least one associated Product_configuration specifying a particular configuration. See the capability representing_product_as_realized_configuration
Error C1: Capability representing_product_as_realized_configuration not in dex_index.xml
(to become representing_product_as_individual_configuration) for more details.

EXAMPLE There might be a manufacturer of a personal computer system which is marketed to both the US and the European markets. The design may allow for two configurations; one for the US and one for Europe. The configuration is only different in that a different power supply is used depending upon which market the PC is assembled for. Another manufacturer may have a switchable PSU and may therefore, only need one configuration.

Error I1; The image filename: ../.\img\Rep of a Product as Planned in a Planned Configuration.jpg contains whitespace

Figure 17 — Representation of the Product as Planned in two Configurations of a PC

NOTE The relating_view of the next assembly usage entity is not shown - see the section on assembly below. The additional classification as a reference is not shown but will be coverd in a later section.

NOTE The identification of the Product_concept is provided in more detail in the C001: assigning_identifiers capability.

NOTE There might be several levels of product concepts defined in a company. The description of product concept structures and relationships is not supported by the current PLCS Schema, nor this Dex. It is therefore recommended to instantiate the lowest level product_concept that is offered to the customer.

The Product_configuration defines a manufacturable end item, or something that is conceived and expected as such. The association between a Product_configuration and a corresponding Product_as_individual (such as Product_as_realized or Product_as_planned) is established using an instance of Item_design_association. The valid use of component parts for planned units of manufacturing of a particular Product_configuration may be specified using configuration effectivity (see capability C006: assigning_effectivity) for details.

When a product is designed, it is first represented as a Product_concept. For example, a new bicycle will be initially represented as a Product_concept. Then a number of possible configurations of the product are identified and represented by a Product_configuration. For example, there may be many wheel designs, but two sets are chosen to accompany two product configurations of the bicycle concept. An ordinary bike (with normal wheels), then a racing bicycle fitted with racing wheels.

Before manufacture it will be represented by an assembly structure (represented by Product_as_planned) that can be configured in any of the two configuration options. See figure above for example). The possible configurations, represented by Product_configuration, are related to the Product_as_planned by Item_design_association.

Once the product has been manufactured it will be represented by another assembly structure (represented by Product_as_realized) that can be configured in any of the two configuration options. The possible configurations, represented by Product_configuration, are related to the Product_as_realized by Item_design_association.

The assembly structure represents all the valid possible assemblies for those configurations. These are represented by instances of Next_assembly_usage relating the views (Product_view_definition") of the components of the bicycle (instances of Product_as_planned or Product_as_realized - depending upon whether pre or post production).

The representation of product configuration identification is described in the capability C063: representing_product_configuration, (soon to become representing_product_as_individual_configuration) and whilst closely related, the representation of configuration composition management is described in the capability C006: assigning_effectivity.

A more detailed description of the representation of individuals is provided in the capability representing_product_as_realized_configuration
Error C1: Capability representing_product_as_realized_configuration not in dex_index.xml
(soon to become representing_product_as_individual_configuration).

Referencing an Individual within a Product Configuration

To refer to a product individual within a configuration, both the individual and the configuration need to be identified. However, an additional classification of the individual is required to be set to the string value 'reference'. A description of the referencing a product configuration is provided in capability referencing_product_configuration
Error C1: Capability referencing_product_configuration not in dex_index.xml
.

A relationship from the Product_as_planned or Product_as_realized to a Product_configuration is established via View_definition_usage (or any of its subtypes - e.g. next assembly usage) and Item_usage_effectivity to the Item_design_association representing the the relationship between the referenced Product_configuration and its associated Product_version(such as a Product_as_planned or Product_as_realized) or a Product_view_definition. The way a Product_configuration is referenced is described in the referencing_product_configuration
Error C1: Capability referencing_product_configuration not in dex_index.xml
capability.

The following figure shows the references to a configuration of planned individuals.

Error I1; The image filename: ../.\img\Ref to a Product as Planned in a Planned Configuration.jpg contains whitespace

Figure 18 — Referencing of the Product as Planned in a Planned Configuration

NOTE The two key entities are the product as planned and the product configuration instances along with their identification and classification. The organization and date time assignment information however, is required for unique identification. Also note that the identification and classification of the associated design part was carried out at an earlier date as shown by the date time assignment of #106.

NOTE That it is reasonable to assume that given the two references above, that the host system should be capable of tracing the link(s) between them to establish that the individual is part of the configuration.

NOTE To Tim - if this is not the case then all those entity instances between the two refered to above need to be provided. In theory, there may be many product view definitions that point to the part (#58 for example), and in addition there may be a number of view_definition_usage instances that also link to the configuration. Question being - is this important if only trying to identify that the individual is part of a configuration? Probably not - but worth point out perhaps?

The following figure shows the instances required to reference a specific version of a realized individual within a configuration

Error I1; The image filename: ../.\img\Ref to a Product as Realized within a Realized Configuration.jpg contains whitespace

Figure 19 — Referencing a Version of a Product as Realized in a Configuration

NOTE The two key entities are the product as realized and the product configuration instances along with their identification and classification. In this case, however, we are also referencing a specific version of the realized individual (denoted by #138). The organization and date time assignment information however, is required for unique identification.

NOTE To Tim - if this is not the case then all those entity instances between the two refered to above need to be provided. In theory, there may be many product view definitions that point to the part (#117 for example), and in addition there may be a number of view_definition_usage instances that also link to the configuration. Question being - is this important if only trying to identify that the individual is part of a configuration? Probably not - but worth point out perhaps?

Assigning effectivity

Effectivity is a key concept to control the valid use of product data. This Dex supports the association of effectivity information to different types of product data through the Item_usage_effectivity entity. This entity represents a tuple of; a resolved_configuration (an instance of Item_design_association - see above or representing_product_as_realized_configuration
Error C1: Capability representing_product_as_realized_configuration not in dex_index.xml
), an effectivity_domain (an instance of a type of Effectivity), and an item_usage_relationship (i.e. an instance of a type of View_definition_usage, such as Next_assembly_usage (see above or representing_product_as_realized_assembly
Error C1: Capability representing_product_as_realized_assembly not in dex_index.xml
).

The Effectivity entity supports the specification of a domain of applicability for product data. Effectivity is a generic concept defining the valid use of the product data to which the effectivity is assigned.

The subtypes of Effectivity include;

These subtypes restrict the domain of applicability of the associated product data to a date range, a particular lot or serial number range, or to a time interval respectively.

Hence, an instance of Item_usage_effectivity may associate a Product_configuration (through the Item_design_association), and a definition of the assembly (Next_assembly_usage through View_definition_usage) with a type of Effectivity.

Configuration effectivity allows attachment of effectivity information to occurrences of component parts in the context of a particular configuration item. This enables the specification of the valid use of a part occurrence in the context defined for a particular product configuration. This controls the constituent parts that are planned to be used for manufacturing end items of a particular product configuration within a dated time period or for a certain lot or serial number range of the end items.

Error I1; The image filename: ../.\img\Rep of a Product as Planned and Effectivity.jpg contains whitespace

Figure 20 — Representing Product as Panned individuals and (Dated) Effectivity

While configuration effectivity (as described above) is used to define the planned usage of components in the context of a particular product configuration, the Dex also allows assignment of general validity periods to product data that control the usage of these product data independent of any particular life cycle or context.

The validity period of Effectivity may be applied to different types of product data, potentially specifying an additional role in which the effectivity is assigned. The Effectivity_assignment entity defines a general mechanism to associate a general period of validity to some product data or activity.

The entity Effectivity_assignment refers to one or more items (instances) of product data to which the validity period is assigned. The types of product data to which an effectivity may be assigned are defined in the effectivity_item select type.

NOTE The assignment of effectivities is often done during the approval process, i.e, when releasing product data for the next stage of the development process, it gets effectivity information assigned to determine when and in which context these product data may be used.

The representation of the individual product's assembly definition

The assembly definition is represented using explicit hierarchical product structures (e.g. Next_assembly_usage) representing assemblies and the constituents of those assemblies. In the design stage this would involve consituents such as Parts, but in the process planning stage and as-built/in-service stages these are represented by Product_as_individuals (such as a Product_as_planned or Product_as_realized). Relationships between Product_view_definitions are the principle elements used to structure an explicit assembly configuration. The relationship itself represents a specific usage of the constituent definition within the immediate parent assembly definition. Mechanisms to represent quantity associated with this Assembly_component_relationship usage are not required at this stage since there is a specific occurrence for each individual used. Thus the quantity is the sum of the individuals provided.

Using Product_as_individuals (a type of Product_version), rather than a Parts provides the capability to identify and track the specific usage of component definitions in an assembly. This enforces a typcial tree-like hierarchy of instances through the normal parent-child relationships rather than the frequent graph-like structures that are possible at the design stage.

Hence different view definitions (Product_view_definitions) of the same Product_as_individual may participate in different explicit product structures. For example, as-built, in-service and as-maintained views of the same Product_as_realized may be different. This is in addition to differences with the planned assembly and manufacture structures using Product_as_planned instances.

In addition to these hierarchical assembly structures discussed above, capability representing_product_as_realized_assembly
Error C1: Capability representing_product_as_realized_assembly not in dex_index.xml
supports relationships between parts to characterize explicit alternates and substitutes for the assembly.

The Referencing of an Individual within an Assembly

The two figures below show how an individual can be referenced in the context of an assembly. This requires the identification of both the assembly and the individual. However, to clarify that these are only references rather than aother assembly being defined, an additional classification of the individual is required to be set to the string value 'reference'. A description of the referencing an assembly is provided in capability referencing_part_or_slot
Error C1: Capability referencing_part_or_slot not in dex_index.xml
.

The reference is a two-stage process. The first is to identify the root Product_as_individual which represents the top root node of the assembly being referenced. This may be a Product_as_planned or Product_as_realized. This individual will be the defined_version of a Product_view_definition instance.

The second stage is to trace the assembly hierarchy to locate the individual. This can be achieved through an instance of type Assembly_component_relationship (such as Next_assembly_usage, Promissory_usage or Component_upper_level_identification), which relates two instances of Product_view_definition together. The relating_view identifies the parent in the assembly, whereas the related_view identifies the child node in the assembly. The Product_view_definition of the child node has a defined_version which may be the Product_as_individual sought.

NOTE Depending on which Assembly_component_relationship is being used and since the Product_view_definition of the child node may itself be a parent in another parent-child relationship, this stage may need to be re-iterated in order to recurse down to the level in the hierarchy where the individual sought is located.

The following figure shows the reference of a planned individual within a simple, planned (promissory) assembly.

Error I1; The image filename: ../.\img\Ref to a Product as Planned in a Planned Assembly.jpg contains whitespace

Figure 21 — Referencing a Panned individual within an Assembly

The following figure shows the reference of a realized individual within a simple, realized (promissory) assembly.

Error I1; The image filename: ../.\img\Ref to a Product as Realized within a Realized Assembly.jpg contains whitespace

Figure 22 — Referencing a realized individual within an Assembly

The use of Slots in an Assembly

A slot represents the position in which a part is or can be attached to an assembly, when it is necessary to record the history of usage of that slot. It defines the concepts required to build the relationships which provide the structure for representing slots.

EXAMPLE A ship has four engines each attached at a mounting point in an engine room. These mounting points each has an associated slot, which are identified as slot 1, slot 2, slot 3, and slot 4. In normal usage only two main engines are are operating, the remaining two provide an operating enhancement if all four operate or a backup for the two main engines. The attached engines are tracked against their respective slots. If the ship does not have all of its engines installed, one or more slots are empty. An empty slot is subject to a different maintenance regime than an installed engine.

The representation of Slots

Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slots are subject to identification requirements as described within capability C001: assigning_identifiers. Hence, the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slotshould be referenced by an Identification_assignment, which acts as the focus for; a Classification_assignment (and External_class), an Organization_or_person_in_organization_assignment and a Date_or_date_time_assignment. In this respect, the model closely resembles that of Part described within capability C002: representing_parts.

Figure 23 — Representing a Slot

A
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot may have one or more versions (
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_version
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_version), and each may have one or more applicable view definitions (
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_definition).

A
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_version
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_version may exist in the form of a designed slot (
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_design
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_design), a planned slot (
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_planned
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_planned) or a realized slot (
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_realized
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_realized).

These versions correspond to the same PLCS approach to lifecycle management that are afforded to Parts, Product_as_planned and Product_as_realized described earlier in the busines section. The distinction between design, planned and realized products is also provided in capability representing_product_as_realized
Error C1: Capability representing_product_as_realized not in dex_index.xml
(shortly to become representing_product_as_individual).

Versions are identified through a version code (usually a number) while the original
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot can be identified through the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_version
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_version's
Error ER-6: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_version.of_product
is incorrectly specified. The attribute does not exist.
Note linkend is case sensitive.
of_product attribute.

The following figures show the representation of these three types of versions.

Figure 24 — Representing a design slot

NOTE Both slot and slot design are shown having the same date/time for the assignments. It is likely the the slot is defined at the time of representing the design.

Figure 25 — Representing a planned slot

NOTE Both slot and slot as planned are shown having different date/time for the assignments. It is likely that the date of design is earlier than that of the process plan.

Figure 26 — Representing a realized slot

NOTE Both slot and slot as realized are shown having different date/time for the assignments. It is likely that the date of design and planned versions is earlier than that of the realized/as-built.

The relationships
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_on_product
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_on_product and
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Product_in_slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Product_in_slot identify the slot attached to a product and which part has been fitted to the slot, respectively.

The
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_on_product
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_on_product relates a
Error ER-6: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_on_product.slot
is incorrectly specified. The attribute does not exist.
Note linkend is case sensitive.
slot on one hand to a
Error ER-6: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_on_product.product
is incorrectly specified. The attribute does not exist.
Note linkend is case sensitive.
product on the other. The former links to the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_definition described below, while the other should link to a type of Product_view_definition (or a subtype such as Part_view_definition).

A
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_definition is attached to a product through the relationship entity
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_on_product
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_on_product. The
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_definition has a
Error ER-6: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition.defined_version
is incorrectly specified. The attribute does not exist.
Note linkend is case sensitive.
defined_version attribute linking the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_version
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_version. This, in turn, has an attribute
Error ER-6: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_version.of_product
is incorrectly specified. The attribute does not exist.
Note linkend is case sensitive.
of_product which links to the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot.

Figure 27 — Representing the elements of a slot as planned

NOTE The same structure of elements are employed to represent both slot_design and slot_as_realized. These are not shown here. See capabiliity representing_slots for more details.

Since an assembly is built from relationships between Product_view_definitions and a
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_definition is a subtype of this, there is a mechanism to include
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slots within an assembly.

Figure 28 — Representing a slot as planned in an assembly containing instances of product as planned.

NOTE A complete assembly is not shown here - only the use of one contruct (promissory_usage) typically used in the representation of an assembly. Next_assembly_usage is another popular building block.

NOTE The slot in this case forms part of a simple assembly (through promissory_usage) and at the same time identifies the parent in the assembly as the product upon which the slot sits. A slot may be defined at any level in the assembly - not just the top level as shown here.

Representing a Part in a Slot

Representing a part or product that occupies a slot makes use of the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Product_in_slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Product_in_slot relationship which links a
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_definition with a Product. The following figure shows the representation of a Soundblaster PC card occupying the slot defined which is part of the PC assembly. It also shows the use of the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_on_product
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_on_product which identifies the top-level product on which the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot sits.

Figure 29 — Representing a Part in a Slot

Management of a Slot through life

If the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_planned
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_planned has been produced from a specific
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_design
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_design, then the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_design
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_design maybe related to the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_planned
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_planned by the relation entity
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_design_to_planned
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_design_to_planned.

Error I1; The image filename: ../.\img\Relationship between a Design Slot and a Planned Slot.jpg contains whitespace

Figure 30 — Relationship between a Design Slot and a Planned Slot.

If the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_realized
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_realized has been produced from a specific
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_planned
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_planned, then the they maybe related by the relation entity
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_planned_to_realized
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_planned_to_realized.

If the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_realized
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_realized has been made from a
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_design
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_design then it may also be related to that version of the design by the relation entity
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_design_to_realized
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_design_to_realized.

Error I1; The image filename: ../.\img\Relationships between Slot Design, Slot as Planned and Slot as Realized.jpg contains whitespace

Figure 31 — Relationships between Slot Design, Slot as Planned and Slot as Realized

In cases where it is necessary to identify specific versions, the identification assignment of each should be specified. The figure below shows this.

Error I1; The image filename: ../.\img\Identifying the Versions of the related Slot Design, Slot as Planned and Slot as Realized.jpg contains whitespace

Figure 32 — Identifying the Versions of the related Slot Design, Slot as Planned and Slot as Realized

The Referencing of Individual Slots

Referencing slots for the design was provided in an earlier section. The mechanism to refer to
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_planned
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_planned and
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_as_realized
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_as_realized is the same and is not repeated here.

The representation of breakdowns of individuals;

When defining the support solution, it may be necessary to represent a breakdown view of the product. A breakdown is a partitioning of a product into a set of related elements to support engineering, analysis and other activities that may be performed in relation to the product. These breakdowns are explicit, parent-child views that comprise the product elements.

These views may be represented through a Breakdown (that specifies the representation of various breakdowns of products), or through one of it's subtypes, such as; System_breakdown (for the representation of various breakdowns of a systems), Functional_breakdown (for the representation of various functional breakdowns of products), Physical_breakdown (for the representation of various physical breakdowns of products), Zone_breakdown (for the representation of various zonal breakdowns of products), or through a Hybrid_breakdown (for the representation of various hybrid breakdowns of products).

A product breakdown element is represented in the model as a Breakdown_element or any of its subtypes; Functional_element, Physical_element, System_element, or Zone_element - depending upon the type of breakdown being defined.

These views are complementary to the assembly structure and bill of materials views that are the primary focus for manufacturing (realization) of a product. Breakdowns may be of designs or realized individual products. For any product, more than one breakdown may exist to provide the support solution.

The AP239 PLCS approach to product breakdown (as defined within capability C004: representing_breakdown_structure) comprises the following;

the identification of a product or Product_as_individual (i.e. what is the product being broken down);
the representation and identification of the type of breakdown selected for the product or product version (i.e. the type of Breakdown and Breakdown_version or subtypes of these);
the representation and identification of the elements that comprise a breakdown (i.e. the constituents of the breakdown, e.g. the Breakdown_element and Breakdown_element_version or subtypes of these);
the representation and identification of the definitions of the Breakdown_elements within a specific Breakdown_context (i.e. the Breakdown_element_definition or subtype of this);
the representation and identification of parent-child relationships between breakdown elements (i.e. the Breakdown_element_usage - the breakdown structure);
the (optional) representation and identification of relationships between elements in different breakdowns (i.e. Breakdown_element_realization - the relationships between breakdown elements).

There are a number of aspects to note about the functionality of this model. Firstly, for any product individual (or design), there may be more than one type of breakdown. The second is that each breakdown may have more than one element as a constituent. Thirdly, the various in-built types of breakdowns made explicit by the model (i.e. functional, physical, zone and system), reflect the various life cycle stages applicable to many products, so those defined later in the life cycle will not necessarily be present early on. The model thus, provides the means to represent the product at various phases of the life cycle. This can then be exploited during subsequent phases where for example, physical elements may realize functional ones. Similarly, the physical elements may be realized by the assembly. Thus, since each breakdown may become a structure (tree-like), they may present orthogonal views on the same part or individual. One way to visualise this is as many product trees inter-connecting at various points across a network. However, they all have their own root according to the breakdown defined.

NOTE It is not expected, nor to be assumed that every node in one breakdown will correspond with that of one of more nodes in other breakdowns or assembly definitions. Indeed, the structuring of the information may well be different and should be expected to be so.

Figure 33 — Representing the Breakdown of the Electrical Power of the PC System PC-0023

NOTE The breakdown is a type of system breakdown for the electrical power for the PC. The context provided is for logistically significant items and the breakdown shows the PSU broken down into a fuse and a transformer. Identification is applied to system, system version, and to each element and element version. (The cexternal class and class library has been left off for readability. The realization of each definition is shown to be a product view definition of a planned individual (not shown for the fuse or transformer), which is a version of the product designed (part). The system element usage shows that the parent is the PSU with the serial number, whereas the child nodes are the fuse and the transformer.

See capability C004: representing_breakdown_structure for a detailed description on this and the other types of breakdowns.

Referencing a Breakdown Element

A Breakdown_element (or one of its subtypes) shall be referenced by its identifier. This identifier should be assigned in accordance with the capability C001: assigning_identifiers.

However, just providing a breakdown element identification does not guarantee a unique entry in e.g. a database system. In order to uniquely reference a breakdown element one also has to provide the context in which the breakdown element can be uniquely identified. This context have to include information about:

The Breakdown_element_version and Breakdown_element_definition of the Breakdown_element;
The Breakdown_context which is a reference to the breakdown definition (Breakdown_version and Breakdown);
A reference from the breakdown definition to the Product that the breakdown is a Breakdown_of.

The detailed approach to this referencing mechanism is defined within capability referencing_product_breakdown_element
Error C1: Capability referencing_product_breakdown_element not in dex_index.xml
.

Referencing a part or slot in a breakdown

A relationship from the Part or
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot to a breakdown is established using an instance of Breakdown_element_realization. The section above describes how the breakdown may consist of instances of Product_as_individual (i.e. Product_as_realized or Product_as_realized), through an instance of Product_view_definition.

For a Part this definition would have a defined version represented by a Part_version which would then allow the identification of the Part.

In the case of a
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot, a
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_definition
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_definition would be used in place of a Product_view_definition. The related
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot_version
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot_version would thence provide the link to the
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot. The contents of a
Error ER-7: The express_ref linkend
attachment_slot:arm:Attachment_slot_arm.Slot
is incorrectly specified.
The entity does not exist.
Note linkend is case sensitive.
Slot are discussed in the sections above. A reference the identification of breakdown element is established using the capability referencing_product_breakdown_element
Error C1: Capability referencing_product_breakdown_element not in dex_index.xml
.

Product State - reporting the status of an actual product

The concept of the state, or status, of a Product_as_realized may be used to record several different aspects of feedback as follows:

Properties of the Product

A property is the definition of a special quality and may reflect physics or arbitrary, user defined measurements. Properties may be assigned to parts, assemblies or to any other product.

The STEP approach is flexible, allowing new properties to be defined "on the fly". This can lead to problems of properties not be understood by receiving partners. Hence, the PLCS approach, and this Dex, uses the STEP property model, with the added requirement that all assigned properties must be classified using reference data. This retains the flexibility, but adds the semantic rigour required for unambiguous data exchange.

Documentation of the Product

Use of a (OASIS) Reference Data Library

Extensive use is made of Reference Data Libraries to allow industry specific terminology to be called in to characterise the basic model. This Dex has the ability to classify entities in an exchange file as belonging to a class, where the definition of the class is provided in class library that is not part of the data exchange. The class library is often referred to as a reference data library (RDL).

Reference data are terms and definitions that has to be mutually understood by all parties involved in a information exchange.

In OASIS PLCS, reference data is used to extend and to tailor the AP239 data model to suit different groups of users.

The reference data being applied has to be defined in an external source such as e.g. a database, a web-site or a published document. The source of the reference data should be stated in the id attribute of the External_class_library entity. The identification could be a URL, Document id or any other identifier that uniquely identifies the source. A complementary description of the source can provided using the External_class_library description attribute

The reference data being applied can either be stated by name using the External_class name attribute, or by a unique identifier in the External_class id attribute provided that the source uniquely identifies each reference data element.

The relationship between the reference data and the entity being described/classified is established using Classification_assignment.

Transmission of the product data

Information describing an exchange of information by the usage of this DEX is provided by the capability C014: messaging. This is used to communicate meta-data associated with a specific message, such as the intent of the sender, identification of the business process (if any) of which the message forms part, or status information relating to the message itself.

Although this DEX will be used to communicate information about the planned and/or realized product, it can also be used to exchange the assembly, breakdowns and documents, separately or together. In addition, variants or derivatives of a product may also be developed which may require only partial exchanges of the complete product. The assembly may be matured over time and different breakdown views may be adjusted accordingly. The alignment of breakdowns and assembly will, similarly, require subsequent adjustment.

The purpose of the communication may itself, be amplified by associated documents. These are described by the capability C005: representing_documents and referencing_documents

Error C1: Capability referencing_documents not in dex_index.xml
.

ISO 10303-239 Representation

Model Overview