A single Piece Part

From WikiSTEP

A part is a typical kind of product which we can buy or build and which has a part number. Parts may be single piece parts such as a screw or may be more complex such as a radio. But as long as we don't look to what is inside the radio we can still take it as a single piece part. STEP requires that all kinds of products and so parts as well comes with a version. Ideally the data model for Part and Part_version should look like this:

ENTITY Part;
  id : identifier;
  name : label;
  description : OPTIONAL text;
ENTITY;

ENTITY Part_version;
  id : identifier;
  description : OPTIONAL text;
  of_product : Part;
UNIQUE
  UR1 : id, of_product;
END_ENTITY;

The attributes for Part are:

• an id of type identifier: This string is typically composed of numbers and other characters and it's only purpose is that the part can be identified by it. These id's should not contain words from natural languages and they are not intended to be translated into other languages. However it may happen that different organizations uses different ids for the same part. We look to this at a later lesson.
• a name of type label: The type label is reserved for strings which have meaning to humans. Because of this a name may need to be translated into other languages to make sense there; there is another lesson on this. There may be several parts with the same name, but they should have different ids.
• an optional description of type text: Here additional textual information for human interpretation can be added.

A corresponding instantiation example for a part with name "Test part 1" and id "A0001" and version "1" would look like this.

#15=PART_VERSION('1',$,#16);
#16=PART('A0001','Test Part 1',$);

Of course there may be more instances of Part_version for the same Part, but STEP requires to have at least one. In the case that no real id is available for a single Part_version, an empty string might be used.

Unfortunately in reality STEP is not so simply and so we have to add some more stuff to satisfy the data model. We first show the ARM model and then the corresponding IR/MIM model.

ARM data model

The ARM model is to a big degree copying the MIM/IR structure and adding some simplifications. It introduces generic definitions for Product and Product_version and then make Part and Part_version subtypes of them. In addition an instance of type Part must have an assigned Product_category with name 'part' and optionally also 'raw material' or 'tool':

ENTITY Product_category;
  id : OPTIONAL STRING;
  name : STRING;
  description : OPTIONAL STRING;
END_ENTITY;

ENTITY Product_category_assignment;
  category : Product_category;
  products : SET [1:?] OF Product;
END_ENTITY; 

ENTITY Part
  SUBTYPE OF (Product);
WHERE
  WR1: SIZEOF(['part', 'raw material', 'tool']*types_of_product(SELF))=1;
END_ENTITY; 

ENTITY Product;
  id : STRING;
  name : OPTIONAL STRING;
  description : OPTIONAL STRING;
END_ENTITY; 

ENTITY Part_version
  SUBTYPE OF (Product_version);
  SELF\Product_version.of_product : Part;
END_ENTITY;

ENTITY Product_version;
  id : STRING;
  description : OPTIONAL STRING;
  of_product : Product;
END_ENTITY;

A complete ARM population would now look like this:

#15=PART_VERSION('1',$,#16);
#16=PART('A0001','Test Part 1',$);
#17=PRODUCT_CATEGORY($,'part',$);
#18=PRODUCT_CATEGORY_ASSIGNMENT(#18,(#16));

But please remember that ARM stands for Application Reference Model. It is not the model people are expected to implement. What has to be written in a STEP file must conform to the MIM, the Modular Integrated Model.

MIM/IR data model

The MIM in this area is directly using entities and types from the Integrated Resource (IR) part 41 of STEP Fundamentals of product description and support. In addition to the types introduced already above we have:

• application_protocol_definition to be able to define the STEP-AP (e.g. AP203) for which data is going to be exchanged or recorded in a database. This information is overlapping with the Express schema specification in a STEP-File and has also not so much use in the STEP modular architecture. But it is preserved for compatibility issues.
• application_context to identify the general context in which all the data is provided, e.g. 'mechanical design'
• application_context_element and its subtype product_context to provide specific context information for instances of type product
• product_category and its subtype product_related_product_category to say that a product if of type part

Note that upward compatible extensions that got introduces with the second edition part 41 and that are not relevant for this discussion here are replaced with "...".

TYPE identifier = STRING; END_TYPE;
TYPE label = STRING; END_TYPE;
TYPE text = STRING; END_TYPE; 

ENTITY application_protocol_definition;
  status : label;
  application_interpreted_model_schema_name : label;
  application_protocol_year : year_number;
  application : application_context;
END_ENTITY;

ENTITY application_context;
  application : label;
DERIVE
  ...
INVERSE
  context_elements : SET [1:?] OF application_context_element FOR frame_of_reference;
WHERE
  ...
END_ENTITY;

ENTITY application_context_element
  SUPERTYPE OF (ONEOF (library_context, product_concept_context, product_context, product_definition_context));
  name : label;
  frame_of_reference : application_context;
END_ENTITY;

ENTITY product_context
  SUBTYPE OF (application_context_element);
  discipline_type : label;
END_ENTITY;

ENTITY product;
  id : identifier;
  name : label;
  description : OPTIONAL text;
  frame_of_reference : SET [1:?] OF product_context;
END_ENTITY;
 
ENTITY product_definition_formation;
  id : identifier;
  description : OPTIONAL text;
  of_product : product;
UNIQUE
  UR1 : id, of_product;
END_ENTITY;

ENTITY product_category;
  name : label;
  description : OPTIONAL text;
DERIVE
  ...
WHERE
  ...
END_ENTITY;

ENTITY product_related_product_category
  SUBTYPE OF (product_category);
  products : SET [1:?] OF product;
END_ENTITY;

With this information an valid example MIM/IR data set may look like this:

#12=APPLICATION_CONTEXT('mechanical design');
#13=APPLICATION_PROTOCOL_DEFINITION('TS','ap203_configuration_controlled_3d_design_of_mechanical_parts_and_assemblies_mim',2005,#12);
#15=PRODUCT_DEFINITION_FORMATION('1',$,#16);
#16=PRODUCT('A0001','Test Part 1','',(#18));
#17=PRODUCT_RELATED_PRODUCT_CATEGORY('part',$,(#16));
#18=PRODUCT_CONTEXT('',#12,'');

The core information is given by the instances #15, #16 and #17.

• #17 say that #16 is a part
• #16 gives you the id and name (and optionally description) of the part
• #15 tells about version '1' of part #16

All the other information is not really relevant for typical data exchange scenarios and is only filled with template information. But it must be there to make the file STEP data set valid.

Please note that product_category.name is highly constraint with magic strings by ARM rules and ARM-to-MIM mapping. It is therefore better not used for other application specific purposes.