PDM-UG: Product Master Identification
From WikiSTEP
This page belongs to the PDM Usage Guide.
Product master identification supports the ability to uniquely identify a part. The identification of products in the STEP PDM Schema consists of three important and structurally distinct concepts:
- Base Identification,
- Version Identification,
- View Definition.
The master base identification maintains information common to all product versions and disciplines and/or life-cycle views. It contains the base product number and name. The base number should not be subject to any encoding of information into a single complex parse able string.
There must be at least one version assigned to a product base identification. The version information may represent a design revision or iteration in a design cycle of a part. There may be more than one version associated with a product master. The set of versions associated with a base product may be related together to represent the version history of that product. The product version collects all information among all associated disciplines and life-cycle view definitions.
It is recommended that at least one view definition be assigned to each product version. There may be two exceptions to this general rule:
- Supplied product identification, in which case a supplied product may be represented by only product version;
- Version identification and when version history is represented, where only the most recent current version is required to have an associated view definition.
The product definition view collects information relevant from the perspective of a particular application domain or life-cycle stage. There may be more than one life-cycle view definition associated with a particular version of a product. This is especially important to enable different views on product assembly structures.
Contents |
The Instance Model: EXPRESS entities and attributes
The EXPRESS entities and attributes used to support the requirements of part master identification are illustrated in Diagram 1 below. The corresponding STEP exchange file encoding is given in Example 1.
Product
The product entity represents the product master base information. This entity collects all information that is common among the different versions and views of the product. The product number is strictly an identifier. It should not be used as a 'smart string' with some parse able internal coding scheme, e.g., to identify version or classification information.
The product number identifier must be unique within the scope of the business process of the information exchange. This is typically not a problem when the product data is only used within a single company. If the data is being assembled for an external use, the identification must be interpreted as unique within that broader domain. Processors may need to evaluate more than one string (i.e., product.id) to establish unique identification of a part; there may be a combination of parameters that make part identification unique. The associated organization entity with the role 'id owner' can be used to derive a uniqueness parameter if the product.id attribute is not unique within the domain of the business arrangement of the exchange.
Attributes
- The id attribute stores the unique base identifier for a product, the product number.
- The name attribute stores the nomenclature, or common name, of the product.
- The description attribute should contain an expanded name or description of the product.
- Context information is stored in the frame_of_reference attribute. All products in STEP must be founded in some product_context. This requirement is discussed in more detail in Product Context Information.
| ENTITY product | Attribute Population | Remarks |
| id | type: identifier = string product number identification | Unique within the scope provided by organization in role 'id owner' |
| name | type: label = string | |
| description | type: text = string | frame_of_reference | type: entity = product_context | SET [1:?] |
=== Preprocessor Recommendations === All preprocessors should use valid user (non-defaulted) data for the values assigned to the attributes id and name, as well as to the id of the organization related in the role ‘id owner’. In populating the id attribute, the identifier must be unique within the scope of the related organization or person_and_organization in the role 'id owner'.
=== Postprocessor Recommendations=== Postprocessors should provide user access to the values of the attributes id and name, as well as the id of the organization related in the role 'id owner'.
=== Related Entities === The PDM Schema requires that all products exist in at least one product_category, to provide type classification information. This type classification requirement is discussed in Product Type Classification.
It is strongly recommended that products have a related organization or person_and_organization that identifies responsibility for the original design of the part. The role of this assignment is identified as the ‘id owner’. This is the organization or person_and_organization that defines the part and assigns the part number. See Organization and Person for guidance on how to create the organization or person_and_organization entities.
In addition, the product may optionally be referenced by the following entities:
- applied_organization_assignment (or applied_person_and_organization_assignment) to represent the customer, or other associations of an organization to a product (see Organization and Person);
- product_related_product_category to classify a product with respect to specific criteria. One product_related_product_category is required to represent product type (see Product Type Classification).
Product definition formation
The product_definition_formation entity represents the identification of a specific version of the base product identification. A particular product_definition_formation is always related to exactly one product.
Each instance of product is required to have an associated instance of product_definition_formation. A single product entity may have more than one associated product_definition_formation. The set of these product_definition_formation entities represents the revision history of the product.
Attributes
- The id attribute uniquely identifies this version of the related product.
- The description attribute contains the reason for the creation of the version.
- The attribute of_product provides a link to the base product of which this entity represents a version.
| ENTITY product_definition_formation | Attribute Population | Remarks |
| id | type: identifier = string part version identification | Unique in relation to the specified of_product |
| description | type: text = string | OPTIONAL |
| of_product | type: entity = product |
===Preprocessor Recommendations=== If an organization does not version parts, it is recommended that the id attribute contain the string '/NULL' to indicate that no version information is relevant or intended. In this case only a single product_definition_formation for the part is possible. Some preprocessors have used an id value of '/ANY' to indicate that any existing revision of a component is valid for the parent assembly. This technique may reduce the amount of data sent in change packages, but it also reduces the ability to track the actual contents of parts lists at a particular change level.
===Postprocessor Recommendations=== If the value of the id attribute for a product_definition_formation is the string '/NULL', postprocessors should use this as an indication that the sending system or business process does not support versioning of parts. Postprocessors may also recognize an id value of '/ANY' as a generic revision of a part when it is involved as a component in an assembly. This has been used to indicate that any existing revision of the component is valid for use in the parent assembly.
===Related Entities=== In general, each product_definition_formation is recommended to have an associated product_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 view definition:
- When version history (sequence relationship) is represented - only the most recent version is required to have an assigned product_definition. If there is no product_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;
- Where a supplied item is identified using the alias relationship - the supplier part version may not have an associated product_definition.
In addition, a product_definition_formation may be optionally referenced by the following entities:
- product_definition_formation_relationship to associate two product versions with each other to characterize the version history;
- applied_organization_assignment (or applied_person_and_organization_assignment) to represent the update/modifier, customer, or other associations of an organization to a product version;
- applied_date_assignment (or applied_date_and_time_assignment) to represent various dates related to a product version;
- applied_approval_assignment to record the authorization status of a product version (see Approval);
- applied_security_classification_assignment to record a level of security clearance for a product version.
Product definition formation with specified source
The product_definition_formation_with_specified_source entity is a subtype of the entity product_definition_formation. This entity adds the attribute make_or_buy to indicate the source of the version - either 'made' or 'bought'. This entity is never used in the context of 'Document as Product', but it may be used in 'Part as Product' for compatibility with AP203. However, this make-versus-buy distinction can be ambiguous in the context of exchange - going down a supply chain, the sender is often 'bought' while the receiver is 'made', while in the other direction, the sender is 'made' and the receiver 'bought'. Because of this ambiguity the use of this entity is not generally recommended.
Attributes
- The make_or_buy attribute contains the source information.
| ENTITY product_definition_formation_ with_specified_source | Attribute Population | Remarks |
| id | Same as supertype. | Same as supertype. |
| description | Same as supertype. | Same as supertype. |
| of_product | Same as supertype. | Same as supertype. |
| make_or_buy | type : source (enumeration) | not recommended |
===Preprocessor Recommendations=== The use of this subtype is optional. It is not recommended in the general case. The source value is an enumerated type having possible values '.MADE.', '.BOUGHT.', or '.NOT KNOWN.'. '.MADE.' indicates the part is built within the company. '.BOUGHT.' indicates a vendor part, but this distinction can be unclear when the data is exchanged.
===Postprocessor Recommendations=== If this entity is encountered, the postprocessor should at a minimum process the information from the supertype entity product_definition_formation.
===Related Entities=== There are no specific related entities.
Product definition
The product_definition entity represents the identification of a particular view on a version of the product base identification relevant for the requirements of particular life-cycle stages and application domains. View may be based on application domain and/or life-cycle stage (e.g., design, manufacturing). A view collects product data for a specific task. It is possible to have many product_definition views for a part/version combination.
The product_definition entity enables the establishment of many important relationships. Product_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.
The use of product_definition entities is not strictly required by rules in the PDM Schema, but it is strongly recommended. All product_definition_formation entities should always have at least one associated product_definition, except in the case of supplied product identification and version history information.
Attributes
- The id attribute identifies which view of the product the particular instance represents.
- The description attribute specifies the word or group of words used to refer to the product_definition.
- The formation attribute links to the product_definition_formation of which this represents a view.
- Context information is stored in the frame_of_reference attribute. All STEP product_definitions must be founded in some product_definition_context that identifies the application domain and life-cycle stage from which the data is viewed (see Product Context Information).
| ENTITY product_definition | Attribute Population | Remarks |
| id | type: identifier = string | must be unique in relation with a specific product_version |
| description | type: text = string | OPTIONAL |
| formation | type: entity = product_definition_formation | reference to the associated product_definition_formation |
| frame_of_reference | type: entity = product_definition_context | reference to the associated product_definition_context (see 1.1.2.4) |
===Preprocessor Recommendations=== There is no standard mapping for the id attribute of product_definition, however the value should be unique relative to others related to the same product_definition_formation. Previous use of the id attribute on product_definition had sometimes 'overloaded' the unique identifier with informal life-cycle or organization information. This is not generally recommended for the PDM Schema - this attribute should contain a unique identifier for the part view definition - no additional semantics are associated with this attribute in the PDM Schema.
===Postprocessor Recommendations=== Previous use of the id attribute on product_definition had sometimes 'overloaded' the unique identifier with informal life-cycle or organization information, this should not be expected in general or required for postprocessing.
===Related Entities=== A product_definition may be referenced by the following entities:
- applied_identification_assignment to assign alias identifiers,
- product_definition_relationship to associate two product_definitions with each other to characterize various product structures,
- property_definition to associate general properties,
- configuration_design to associate configuration identification information,
- applied_organization_assignment (or applied_person_and_organization_assignment) (see Organization and Person),
- applied_date_assignment (or applied_date_and_time_assignment) to represent various dates related to a product_definition,
- applied_approval_assignment to record the authorization status of a product_definition (see Approval),
- applied_security_classification_assignment to record a level of security clearance for a product_definition,
- applied_document_reference to assign documents (external descriptions) to the product_definition.
The Instance Model: STEP exchange file format (ISO10303 Part 21 syntax)
#30 = PRODUCT_CONTEXT('', #20, '');
#40 = PRODUCT('part_id', 'part_name', 'part_description', (#30));
#60 = PRODUCT_DEFINITION_FORMATION('pversion_id','pversion_description', #40);
#80 = PRODUCT_DEFINITION('view_id', 'view_name', #60, #90);
#90 = PRODUCT_DEFINITION_CONTEXT('part definition', #20, );
