Business overview

This section provides a business level overview of this capability.

The representation of a Part defines the design of a Part, whether it is designed to be independent or a component of a larger product or assembly. Parts need to identified because through life, they may need to be replaced for example, due to wear, life expectancy, failure rate, substitution, upgrade, variant or be removed for example, through mission requirements, 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 Part must be able to be uniquely identified so that it's usage in all Products that contain parts, such as assemblies, and other products can be recorded across both versions and variations of those products. A Part may however have several identities, separated by type of ID, organization, and applicability dates. 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 information about the product can be enabled.

Versions of a part are represented through Part_version. A Part must have at least one version, but may have any number of versions. Versions of a Part must also be uniquely identified within the scope of type of ID, organization and applicability dates. Relationships between versions of a part, e.g. sequential or parallel versions, are represented through a Product_version_relationship.

A part may have different views depending on who is interested in the part (an engineer in the detailed design phase, a production planner in production, a logistician in support system design, a mechanics in support, etc.). For the different users in the different phases of the life cycle, a specific view of the product may be created, which enables each user of the data to view the information which is significant to them. The different views of a Part is represented by Part_view_definition in a context of "life cycle stage" and "application domain".

A version of a part may have several views defined for different contexts. The view is the main information carrier for a part. Properties and documents are assigned to the view of the version of the part, and this is also the place where part structures are defined, such as part assemblies. This has the implication that the views of a part determines what properties and documents are applicable in a specific context, and the part structure may differ between different views and contexts.

Figure 1 shows the a schematic and simplified drawing of how a Part is represented in PLCS. It consists of the identified Part, two Part_version instances with version IDs, the first with one View definition for design, the second with two View definitions: one for design and the other for support. The information connected to each View definition may differ, between versions and depending on view definition context. Thus, the design view of version 1 have other documents assigned than version 2, and the two views of version 2 have significantly different information assigned, the support version has some properties identical to the design view, but also a task method with a defined fault state and required resources.

Figure 1 —   Schematic drawing of the representation of a Part

PLCS makes a distinction between the design of something, it's planned production and realization as an artifact. An instance of Part is used to represent the design (as documented in this capability). An instance of Product_as_planned represents a proposed or planned artifact. It is identified by e.g. its serial number. An instance of Product_as_realized represents an artifact that results from a process and is also identified by e.g. a serial number. Instances of Product_as_planned and Product_as_realized products are related to the Part design. The planned and realized product entities are described in capability C045: representing_product_as_individual.

Information model overview

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

The Express-G schema entities used to represent a Part are shown in the figure below.

Figure 2 —  Express-G entities for Part Representation

NOTE    The use of colour in the diagram is to attempt to group the entities at various levels in the model. Those in light-green are the generic entities that represent a Product. Those entities in shades of blue represent the information for a Part. Those in light-yellow indicate relationships. Gray entities are provided for backward compatibility and are used for specific product categorization. These colours are used elsewhere within this capability as an aid-memoire in navigating the model.

The representation of a Part is achieved through a number of related entities, of which the following three constitutes the core.

• Part, subtype of Product, which provides the identification, name and classification of the Part
• Part_version, subtype of Product_version, which provides version identification and management of Parts, and
• Part_view_definition, subtype of Product_view_definition, which provides the definition of a Part within a specific context (view).

Apart from the above, the following entities are provided by AP239.

• The View_definition_context defines the context in which the part definition (properties, documents, structures, etc) is valid.
• The Product_relationship enables the establishment of arbitrary relationships between Parts. The use of Product_relationship is deprecated in favour of Product_version_relationship.
• The Product_version_relationship provides the mechanism to establish the version history of the Part through the relationships established between different Part_versions. A version relationship must be classified using any subclass of the external reference data "Part version" (urn:plcs:rdl:std:Part version), e.g. [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_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
  , [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
  . When a Part has more than two Part_versions, a Product_version_relationship must be provided in order to understand their relation.

  NOTE    It is not enough to use incremental numbering in the Part_version identifiers, since version numbers may differ depending on business rules. The only way to safely represent the relationship between different Part_versions is to use the Product_version_relationship entity.

  The Supplied_part_relationship is provided for compatibility reasons with PDM schema for renumbering of vendor parts. But since multiple identifiers can be assigned to parts in PLCS, it should not be used. Use multiple identifiers on the same Part_version instead (see C001: assigning_identifiers.

• The Product_category, linked to the Part (Product) via a Product_category_assignment, allows distinctions between different types of Product.

  NOTE    Product_category is provided by AP239 for backward compatibility with earlier schemas, and should not be used for general classification of Parts. Instead, use external reference data, as described in Part classification

• The Alternate_product_relationship and Alternate_part_relationship may be used to identify Products and Parts that are interchangeable in all occurrences.

  NOTE    This is not the same as substitute products and parts, which are context dependent (see C003: representing_assembly_structure).

The Representation of Parts

Part

A Part is a type of Product that collects the definitional information of the versions of either a part (defined as a discrete object that may come into existence as a consequence of a manufacturing process) or of a non-countable material (defined as a material the components of which cannot be counted or do not need to be counted).

NOTE    A part may contain components, which may be parts or non-countable materials.

NOTE    Oil, Helium and sand are examples of non-countable material.

It is assumed that a Part is a representation of the design of a part and hence, does not represent an actual physical object that is or was existing in the real world.

NOTE    Actual physical objects are represented as Product_as_individual, and are described in capability C045: representing_product_as_individual.

Identification and name of Part

Parts are identified using entity Identification_assignment as described in C001: assigning_identifiers, and is classified as "Part identification code" (urn:plcs:rdl:std:Part identification code) or one of its subclasses. ISO 10303-239 PLCS treats the identifier as a string. It does not impose any encoding of information in the identifier. The attribute id is set to "/IGNORE". Since an identifier always exists in a context of an organization owning the identifier, an instance of Part may have multiple identifiers, belonging to different organizations. Any of those identifiers can be used to identify or reference the Part, and as identifiers they have equal significance.

The name of a Part is assigned using Identification_assignment as described in C001: assigning_identifiers. The name is classified as "Part name" (urn:plcs:rdl:std:Part name) or one of its subclasses. The attribute name is set to "/IGNORE", and should not be used. Since an name assigned in this way always exists in a context of an organization owning the name, an instance of Part may have multiple names, belonging to different organizations.

Categories of Part

In PLCS, the schema has a rule which requires that all Parts exist in at least one Product_category. This means that each Part should therefore, have as a mimimum, a category assigned to it whose name attribute is set to "part", "raw material" or "tool". This categorization information provides a level of compatibility with the PDM Schema and the basic capability to distinguish between parts and other products. Other, additional categories such as detail, assembly, or standard parts should be identified through separate classification assignments using external reference data and described in more detail later on.

Attributes ignored

The attributes of an instance of Part should all be set to "/IGNORE". The information is instead assigned to Part as follows:

• Part identification and name is assigned as described in C001: assigning_identifiers. Multiple identifiers and names may be assigned.
• Part description is assigned as described in C095: assigning_descriptor.

See Figure 2 for an Express-G overview. Figure 3 below shows an example of an instantiated Part "Gasket", its identification and name, and assigned Product_category.

Figure 3 —  An identified and named instance of Part belonging to Product_catgory "part"

NOTE    The above diagram is incomplete, Part_versions of the Part is not shown.

Part_version

The Part_version entity represents the identification of a specific version of the base part identification (e.g. an iteration of a design).

NOTE    A variant of a design should be represented by product concept and configuration (see C063: representing_product_configuration).

A particular Part_version is always related to exactly one part. The Part_version collects all information among all associated disciplines and life-cycle view definitions. Each instance of part is required to have at least one associated instance of Part_version. See Figure 2 for an Express-G overview.

Part version identification

A Part_version is identified using entity Identification_assignment as described in C001: assigning_identifiers, and is classified as "Part version identification code" (urn:plcs:rdl:std:Part version identification code) or one of its subclasses. The attribute id is set to "/IGNORE".

Part version relationships

Version information may represent a design revision or iteration in a design cycle of a part and the relationships between versions are represented through instances of Product_version_relationship.

Using Product_version_relationship the set of Part_version entities associated with a base Part may be related together to represent the revision history of that Part.

NOTE    The relationship is between two distinct instances of Part_version with a common base Part

The type of relationship between versions is defined through external reference data assigned to the Product_version_relationship. There are three pre-defined types of relationships between product versions used to represent the version history:

• Sequential relationship: the relating Product_version is the preceding version and the related Product_version is the subsequent following version. Both versions must be associated with the same Part. A Product_version may have at most one preceding and one subsequent following version. EXAMPLE 1 'Rev. 1.1' and 'rev. 1.2' are subordinates of 'version 1'.

  A sequential relationship is represented by a Product_version_relationship classified 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
  

• Derivation relationship: the instance defines a deriving relationship where the related Product_version is based on the relating Product_version, which is an earlier version of the same or of a different Product.

  The relating_version is the preceding Product_version and the related_version is the subsequent Product_version.

  A derived relationship is represented by a Product_version_relationship classified 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
  

• Hierarchical relationship: the related Product_version is a sub version of the relating Product_version (sometimes referred to as an iteration). Both versions must be associated with the same Part. Each Product_version may have at most one super version (the "relating_view" or parent in the hierarchy). A Product_version may have an arbitrary number of sub versions (the "related_view" or children in the hierarchy). Product_versions related by hierarchical relationships may not define cyclic relationships.

  A hierarchical relationship is represented by a Product_version_relationship classified 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
  

Attributes ignored

The attributes of instances of Product_version should be set to "/IGNORE". The information is instead assigned to Part as follows:

• Part_version identification is assigned as described in C001: assigning_identifiers. Multiple identifiers may be assigned.
• Part_version description is assigned as described in C095: assigning_descriptor.

Figure 4 —  Example instance diagram showing a sequential relationship between two Part_versions

Part_view_definition

The Part_view_definition entity represents the identification of a particular view of a version of a Part relevant for the requirements of particular life-cycle stages and application domains, thereby defining the Part_version for that view. It is possible to have many Part_view_definitions (views) instantiated related to one Part_version instance. See Figure 2 for an Express-G overview.

The Part_view_definition entity enables the establishment of many important relationships. Part_view_definition is the central element to link product information to Parts, e.g., assembly structure, properties (including shape), and external descriptions of the product via documents.

All Part_version entities should always have at least one associated Part_view_definition, except in the case of supplied product identification and version history information.

NOTE    These situations (exceptions) are described in greater detail in capability C003: representing_assembly_structure.

The attributes of instances of Part_view_definition should be set to "/IGNORE". The information is instead assigned as follows:

• Part_view_definition identification and name are assigned as described in C001: assigning_identifiers. Multiple identifiers may be assigned, but none is required.
• Additional characterization of the Part_view_definition may be assigned as a descriptor, described in C095: assigning_descriptor.

All Part_view_definitions must be founded in a View_definition_context (see below). This is done through the Part_view_definition's inherited attribute initial_context.

Even though AP239 allows the definition of additional contexts for a Part_view_definition, it is recommended that any Part_view_definition is only related to one, single View_definition_context (as the initial context), and that no additional contexts is instantiated. Instead of defining an additional context for a Part_view_definition, a new Part_view_definition is created (copied) with the new context related as the initial context.

NOTE    This recommendation has to do with change management. It is not uncommon that part defining information (e.g. structures, properties and documents) that was first believed to be identical between contexts (which would cause the "additional context" relationship to be instantiated) later on is revised, changed or restructured in one context but not in the other. To make that change, the additional context has to be removed, and a new Part_view_definition must be created for that context. Instead, by instantiating two (or more) separate Part_view_definitions, with the same part defining information, but each with only one (initial) context, such changes are possible from the start and becomes traceable.

View_definition_context

For the complete, unambiguous representation and identification of Parts, PLCS requires additional context information.

Each Part can be viewed in different application contexts, such as a design view and a manifacturing view. Each view is represented by an instance of Part_view_definition and the context of the view is represented by an instance of View_definition_context. See Figure 2 for an Express-G overview.

The meaning of the context is provided by classifying the View_definition_context using external reference data.

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

Application domain

The Application_domain is the general application domain that defined (or use) 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 "Application domain" and the "Life cycle stage" could have been represented by string values stored in the View_definition_context attributes, application_domain and life_cycle_stage. However, the recommended approach is to use 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 using external reference data (see C010: assigning_reference_data) 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).

The optional attribute description is also set to "/IGNORE". A description of the View_definition_context may be assigned as described in C095: assigning_descriptor.

Figure 5 —  Complete instantiation example for Part representation

NOTE    The above diagram shows an instantiated Part with two Part_versions in a sequential relationship. The first Part_version has an instantiated Part_view_definition in context of Development life cycle stage and Design domain, the second Part_version has two instantiations of Part_view_definition, one in the same context as the first version, the other in context of Support life cycle stage and Maintenance domain.

A data set or exchange file should only contain one instance of View_definition_context for each context, i.e. there should not be two instances of View_definition_context having identical external classes for the combination of the Life_cycle_stage and Application_domain aspects. The application context is fully defined using these two aspects, and it is pointless to have it duplicated.

A Part_version must only have one Part_view_definition instantiated for a specific context. It does not make sense to have two different definitions of a version within the same context. Therefore, if a data set contains more than one instance of Part_view_definition related to the same instance of View_definition_context, they should be considered as partial instantiations and merged into one instance.

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: Part Classification (Optional)

A Part may be classified, e.g. as "Supplied_part", "Software", "Mechanical_part", "Electrical_part", etc.

Classification is assigned using external reference data, and is described in Capability C010: assigning_reference_data. Parts should be classified using a subtype of external reference data class "Part" (urn:plcs:rdl:std:Part).

Characterization: Assignment of additional identifiers (Optional)

A Part, a Part_version, and a Part_view_definition may be given additional identifiers. Identifiers are assigned in a given role, such as "Owner of" (urn:plcs:rdl:std:Owner of), or "Creator of" (urn:plcs:rdl:std:Creator of), and the identifier is considered unique within the context of the given Organization (see further Capability C001: assigning_identifiers).

This is very useful when organizations want to use their specific identifier, or when ithe identifier may change over time. Since a name in PLCS is an identification, it is also very useful when a product requires both an identification code and a name. Both the identification code and the name is assigned using the same mechanisms.

Characterization: Assigning Descriptors (Optional)

A Descriptor (a descriptive text string) can be assigned to a Part, a Part_version, and to a Part_view_definition. It should always be classified as "Description" (urn:plcs:rdl:std:Description).

The assignment of descriptors is described in the capability C095: assigning_descriptor.

Characterization: Assigning Documents (Optional)

Documents can be assigned to a Part_view_definition. Documents are assigned in a given role, such as "Definition", "Specification", or "Description". The role of the assignment is represented by classifying the assignment using a subclass of external reference data class "Document" (urn:plcs:rdl:std:Document). Specific reference data classes may be defined in business specific external reference data

The assignment of documents is described in the capability C005: representing_documents.

Characterization: Assigning Properties (Optional)

Properties of a Part can be associated with a given view, i.e. Part_view_definition. The use of properties for products is described in C076: assigning_product_properties and C079: representing_properties_numerically C080: representing_properties_textually

Characterization: Assigning an Organization (Optional)

An organization can be assigned to a Part, a Part_version, and to a Part_view_definition. The organization must be assigned in a given role, such as "Owner of" (urn:plcs:rdl:std:Owner of) or "Creator of" (urn:plcs:rdl:std:Creator of). The class must be a subclass of "Organization or person in organization assignment" (urn:plcs:rdl:std:Organization or person in organization assignment). Further classes may be defined in business specific external reference data.

The assignment of an organization is described in C094: assigning_organization

Characterization: Assigning Date and Time (Optional)

Dates and Time can be assigned to a Part, a Part_version, and to a Part_view_definition. The date or date and time must be assigned in a given role, such as "Date actual creation" (urn:plcs:rdl:std:Date actual creation) or "Date planned release" (urn:plcs:rdl:std:Date planned release).

NOTE    Time is classified using the same reference data as Dates, i.e. an assigned time (a date plus hours, minutes and seconds, and time zone) may be classified as "Date actual creation" (urn:plcs:rdl:std:Date actual creation).

The role of the date assignment is represented by classifying the assignment by the use of external reference data (see C010: assigning_reference_data). The reference data class must be a subclass of "Date or date time assignment" (urn:plcs:rdl:std:Date or date time assignment).

NOTE    Dates are also assigned to approvals (see below), so when an approval is assigned to an item, there will be a date set for the approval. There is no need to assign a specific date as well.

The assignment of date and time is described in the capability C036: assigning_date_time. Since Time is more accurate than a calendar date, the assignment of time is recommended.

Characterization: Assigning Approvals (Optional)

An approval may be assigned to a Part, a Part_version, and to a Part_view_definition.

Approvals are always accompanied by an approval status, as defined in external reference data, and by a date or time for the approval, as well as the approving person or organization. Approvals are assigned as described in capability C019: assigning_approvals.

Additional Usage Guidance

No versioning of Parts

If an organization does not version parts, it is recommended that the identification of the Part_version 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 part_version for the part is possible.

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

For such organizations, some of the version relationships described above, under Part version, are no longer applicable, and relationships between Parts may be more appropriate, e.g. a Part may be derived from another part. The Product_relationship entity may be used to describe such relationships.

Part_versions without a Part_view_definition

In general, each Part_version is recommended to have an associated Part_view_definition representing the view definition for the Part_version. In restricted cases, a Part_version without a definition may be used to enhance information about another related, fully defined version. In two specific cases a Part_version may be exchanged without an associated Part_view_definition:

• Where a supplied item is identified the supplier Part_version may not have an associated Part_view_definition.
• When version history (sequence relationship) is represented - only the most recent version is required to have an assigned Part_view_definition. If there is no Part_view_definition associated with the previous versions, only basic information about the sequence of previous versions is exchanged as additional information about the current Part_version that is the focus of the data exchange.

NOTE    These situations are described in greater detail in capability C003: representing_assembly_structure.

Product_category_hierarchy

The purpose of the Product_category_hierarchy entity is to establishe a category-subcategory relationship between two Product_category entities.

However, the Product_category is used solely for backward compatibility with earlier schemas, and should only be used to categorize a Part as one of "part", "raw material" or "tool".

Any other categorization or classification of Part should be instantiated using external reference data, as described in C010: assigning_reference_data.

Therefore, it is recommeded that Product_category_hierarchy is never used.

Alternate Parts

STEP designates alternate and substitute parts differently. Alternate parts are interchangeable in all occurrences whereas substitutes are interchangeable only in a particular usage. Alternate parts are defined through the Alternate_part_relationship entity. See Figure 2 for an Express-G overview.

An Alternate_product_relationship is an association between two instances of Product. It specifies that any version of the alternate_product, may be used in place of any version of the base_product. The alternate product is interchangeable with the base part in any/all uses - it is a context independent alternate that is form, fit, and function equivalent in any use. The relationship established by the Alternate_product_relationship is not symmetric: if B is an alternate product for A, A is not implied to be an alternate product for B.

An Alternate_part_relationship is a type of Alternate_product_relationship where the alternate and base products are parts.

All attributes should be set to "/IGNORE". The rationale for the part interchange (e.g. any use, first available, etc.) should, if it is known, be assigned to the Alternate_part_relationship using a subclass of "Alternate part relationship" (urn:plcs:rdl:std:Alternate part relationship) external reference data, as described in C010: assigning_reference_data.

If a product is an alternate for another product, it is understood that there is no interest to keep track of which product, the base or any alternates specified, is used as a particular instance of the base product within a product structure.

An organization may track design changes for a base part, and establish effectivity conditions for the use of that base part in various assemblies to be manufactured. The use of an alternate product implies that an organization does not specify any particular version of the alternate product nor establish effectivities relating to it.

An Alternate_product_relationship may relate products of any kind, provided both related instances of Product identify products of the same kind, for example part-part or document-document.

An Alternate_product_relationship for which the base_product is an assembly implies that the entire product structure of the alternate_product may be used in place of the base_product and its product structure.

Supplied Part Identification

AP239 provides an entity Supplied_part_relationship for backward compatibility with earlier STEP models, e.g. PDM schema. Due to the fact that PLCS allows for multiple identification it is no longer required.

Processors should be able to read and resolve two Part_versions that are related through a Supplied_part_relationship. The two Part_version may be collapsed into one Part_version with two identifiers assigned as described in C001: assigning_identifiers, or they may be maintained as separate versions, but for all practical purposes they should be considered as one version with two identifiers belonging to two different organizations.

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

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 representing_part

Figure 2 —  The graphical representation of the representing_part template

Figure 3 —  Entities instantiated by representing_part template

Figure 4 —  Example instantiation of representing_part template

Figure 5 —  Characterizations for representing_part template

This section specifies the template representing_alternate_part_relationship.

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 representing_alternate_part_relationship

Figure 2 —  The graphical representation of the representing_alternate_part_relationship template

Figure 3 —  Entities instantiated by representing_alternate_part_relationship template

          #1 = PART('/IGNORE','/IGNORE','/IGNORE');
          #2 = PART('/IGNORE','/IGNORE','/IGNORE');
          #3 = ALTERNATE_PART_RELATIONSHIP('/IGNORE','/IGNORE',#1,#2,'/IGNORE');
        

Figure 4 —  Instantiation of representing_alternate_part_relationship template

This section specifies the template referencing_part.

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_part

Figure 2 —  The graphical representation of the referencing_part template

Figure 3 —  Entities instantiated by referencing_part template

Figure 4 —  Instantiation of referencing_part template

This section specifies the template representing_product_relationship.

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 representing_product_relationship

Figure 2 —  The graphical representation of the representing_product_relationship template

Figure 3 —  Entities instantiated by representing_product_relationship template

          #1 = BREAKDOWN_ELEMENT('/IGNORE','/IGNORE','/IGNORE');
          #2 = BREAKDOWN_ELEMENT('/IGNORE','/IGNORE','/IGNORE');
          #3 = PRODUCT_RELATIONSHIP('/IGNORE','/IGNORE',#1,#2);
          #5 = CLASSIFICATION_ASSIGNMENT(#6,(#3),'/IGNORE');
          #6 = EXTERNAL_CLASS('/NULL','Access_point','/IGNORE',#7);
          #7 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample','/IGNORE');
        

Figure 4 —  Instantiation of representing_product_relationship template

Related capabilities

This capability "Representing Parts" is related to the following capabilities:

• C003: representing_assembly_structure
• C004: representing_breakdown_structure
• C045: representing_product_as_individual
• C063: representing_product_configuration

Dependent capabilities

This capability "Representing Parts" is dependent on the following capabilities:

• C001: assigning_identifiers
• C010: assigning_reference_data

Model reference data

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

© OASIS 2010 — All rights reserved