Product Basics

From WikiSTEP

Jump to: navigation, search


Main entity Product

As a standard for product data representation, the focal point of the STEP Integrated Resources is the product entity data type. This data type serves two purposes:

  • to identify a product as being of interest, and give it an id, name and a description
  • to characterize the context in which the product and its associated data exist and are valid
TYPE identifier = STRING; END_TYPE;

ENTITY product;
  id : identifier;
  name : label;
  description : OPTIONAL text;
  frame_of_reference : SET [1:?] OF product_context;

Every product must have an id, a name and optionally a description. For the attribute frame_of_reference see below.

  • the id is a string of type <<identifier>>, which is for the purpose of identification only. It is advisable to not provide a natural-language meaning. All product instances in a STEP data set should have unique ids, even if STEP is not formally enforcing this always. For the case when a product has different ids in different organizations see below on product identification
  • the name is a string of type label, which is an alphanumeric string that is human-interpretable and shall have a natural-language meaning. For translations into other languages see below.
  • the optional decription is a string of type text, which is an alphanumeric string intended to be read and understood by a human being. It is for information purposes only and therefore has no computer interpretable meaning. For translations into other languages see below.

Part 41 is very vague on what is a product and what is not. Over time more and more things were handled as product. See below on #Product Category for clarification of the principle kinds of supported product.

Product Context

This clause is on identifying the application context and the application protocol in which a product is used. The provided information is somehow redundant to the header information of the implementation methods STEP-File, STEP-XML and SDAI. Nevertheless post-processors should always generate this information. Pre-processors may safely ignore it. Especially for modular APs this information is no longer really relevant, but needed to fulfil formal rules and to ensure compatibility with older implementations.

Product context.png

The relevant EXPRESS definitions are:

 TYPE year_number = INTEGER; END_TYPE
 ENTITY application_protocol_definition;
   status : label;
   application_interpreted_model_schema_name : label;
   application_protocol_year : year_number;
   application : application_context;
 ENTITY application_context;
   application : label;
    context_elements : SET [1:?] OF application_context_element FOR frame_of_reference;

 ENTITY application_context_element
   SUPERTYPE OF (ONEOF (..., product_context, ...));
   name : label;
   frame_of_reference : application_context;
 ENTITY product_context
   SUBTYPE OF (application_context_element);
   discipline_type : label;

 RULE application_protocol_definition_required FOR
   WR1: SIZEOF( QUERY( ac <* application_context |
     apd.application_interpreted_model_schema_name = 'automotive_design')) > 0) )) > 0;   
Example AP214 dataset:
#1=APPLICATION_CONTEXT('mechanical design');
#8=PRODUCT('A4000030000','Power train',$,(#3));

Part 41 defines that an application_context is a context in which product data is defined and has meaning. An application_context represents various types of information that relate to product data and may affect the meaning and usage of that data. In practice this is not so much relevant for a product/product_concept, but as we will see further down it has a significant impact for a product_definition/product_definition_context. For the only string attribute application implementations may choose their own values or choose form this list of pre-defined values (AP214):

  • 'assembly study'
  • 'digital mock-up'
  • 'electrical design'
  • 'mechanical design'
  • 'preliminary design'
  • 'process planning'

Entity application_protocol_definition allows to identify for which AP(s) a product is created and exchanged. It defines the status and the schema name of the AP as text, the edition year of the AP as an integer, and points to the application_context it supports.

  • AP214 has a rule application_protocol_definition_required to ensure the existence of an application_protocol_definition instance with the name 'automotive_design'. Other APs (but not everyone) have similar rules. It is good practise to always have exactly one instance of application_protocol_definition for the AP for which the data-set is valid; in typical exchange scenarious this is exactly one.
  • The application_protocol_year shall indicate the year of publication of the used AP version at ISO. Technical Corrigendas are not covered here.
  • status shall indicate the state of the standard. In most cases this is 'INTERNATIONAL STANDARD', but during the development phase it may also be 'DRAFT INTERNATIONAL STANDARD'

The purpose of entity product_context is to capture the life cycle independent information about a product. There are no predefined strings for the attributes name and discipline_type. Old AP203ed1 from 1994 enforces to populate the specific subtpe mechanical_context with attribute discipline_type set to 'mechanical'.

Product Category

Part 41 says in a very generic way that a product_category identifies a type of product. With the subtype product_related_product_category a product_category can be assigned to one or several products. And with product_category_relationship a hieracy of product categories can be established. Where rule wr1 ensures that the graph of product categories, established by product_category_relationship is acyclic. It is also important to mention here that a product_category_relationship does not imply that a super-category is related to a product by a sub-category which is a product_related_product_category. In other words the definitions of these entities do not imply a mathematical member-of and sub-class relationship.

With the evolvement of STEP the generic functionality on the product category entities where more and more constraint. Today all major APs allow only a few specific types such as 'part', 'document' and 'physically realized product'. For all other purposes such as grouping products to be of type 'computer' or 'table' the entities class and classification_assignments has to be used.

Product category.png
 ENTITY product_category;
   name : label;
   description : OPTIONAL text;

 ENTITY product_related_product_category
   SUBTYPE OF (product_category);
   products : SET [1:?] OF product;
 ENTITY product_category_relationship;
   name : label;
   description : OPTIONAL text;
   category : product_category;
   sub_category : product_category;
   WR1: acyclic_product_category_relationship (SELF, [SELF.sub_category]);
 -- AP214
 RULE product_requires_category FOR (product, product_related_product_category);
   WR1 : SIZEOF( QUERY( p <* product | SIZEOF( 
     ) = 0 )) = 0;

AP214 and other modern APs have a changed rule product_requires_product_category and the mapping enforces that for an Item respectivly Part(in modules) the category name 'part', 'tool' or 'raw material' to use.

Today for a product representing a Part it is agreed that product_requires_product_category with name 'part' must be present. Here a typical example from a CAD system which tries to fit with old and new rules on AP203 and 214 and also the PDM schema:


Meanwhile it is advisable to no longer generate instances for the supertype product_category and product_category_relationship. The above example would then look just like this:


See also

Product Classification

Product Versions

Product Identification

Multilingual Products

Personal tools