S-TEN/D3.1/clause 6 Core STEP data model and reference example
From WikiSTEP
Below you can see an extract of STEP data models to be used for the technical validation. The models are defined in STEP modules and integrated resources (IR) and are common for the modular APs:
- AP203 - Configuration controlled 3D design, TS and upcoming ed2 version
- AP210 - Electronic assembly, interconnect and packaging design
- AP236 - Furniture product data and project data
- AP239 - Product life cycle support
In addition it is also applicable for
- AP212 - Electrotechnical design and installation
- AP214 - Core data for automotive mechanical design processes
and other APs on the AIM level. These APs have different ARM definitions.
We consider this extracted model as a core throughout most STEP-APs. So by supporting this model in OWL means all listed APs are supported in the STEP-OWL mapping.
Contents |
Graphical presentation of used entities (Express-G)
The extracted model is a mixture of ARM and IR/MIM entities. ARM entities start with a capital letter and cover the product management area. AIM entities on the other hand start with lower case letters and are used here for the property and representation area. Please be aware that in a STEP-File you'll find only IR/MIM entities. All ARM entities are mapped to the IR/MIM in the STEP modules. We will refer to this mapping as needed.
Only entity attributes which relates to other entities are shown. All string attributes are suppressed, otherwise the diagram would be hardly readable. Several intermediate select datatypes are suppressed as well. For complex sub-supertype trees Part_view_definition and Part_view_definition_relationship) only some essential datatypes are shown.
Example STEP-File
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(
/* description */ ('Example for S-TEN project, D3.1 - Technological validation'),
/* implementation_level */ '2;1');
FILE_NAME(
/* name */ 'S-TEN_D31_example-1',
/* time_stamp */ '2007-01-04T18:10:41',
/* author */ ('Lothar Klein'),
/* organization */ ('LKSoft'),
/* preprocessor_version */ ' ',
/* originating_system */ 'IDA-STEP v1.4.3 build20051027-1703',
/* authorization */ 'Lothar Klein');
FILE_SCHEMA(('AUTOMOTIVE_DESIGN'));
ENDSEC;
DATA;
/* Person and Organization data */
#100=ORGANIZATION('VW','Volkswagen','company');
#101=PERSON('A0001','Doe','John',$,$,$);
#102=PERSON_AND_ORGANIZATION(#101,#100);
#103=NAME_ATTRIBUTE('technical director',#102);
#104=APPLIED_ORGANIZATION_ASSIGNMENT(#100,#105,(#310,#320));
#105=ORGANIZATION_ROLE('id owner');
/* Product specification */
#200=APPLICATION_CONTEXT(' ');
#201=PRODUCT_CONCEPT_CONTEXT('German car market',#200,' ');
#202=PRODUCT_CLASS('pc1','VW Beetle',' ',#201,'',$);
#203=PRODUCT_CLASS('pc2','VW Beetle CD',' ',#201,'',$);
#204=PRODUCT_CONCEPT_RELATIONSHIP('hierarchy',' ',#202,#203);
#220=CONFIGURATION_ITEM('pi1','VW Beetle \X2\2013\X0\ S_101',
'1200cc, sunroof, red paint, leather seats',#203,$);
#230=CONFIGURATION_DESIGN(#220,#311);
#231=NAME_ATTRIBUTE('product design',#230);
/* Parts general */
#300=APPLICATION_PROTOCOL_DEFINITION(' ','automotive_design',2007,#301);
#301=APPLICATION_CONTEXT('mechanical design');
#302=PRODUCT_CONTEXT(' ',#301,' ');
#303=PRODUCT_DEFINITION_CONTEXT('part definition',#301,'design');
#304=PRODUCT_DEFINITION_CONTEXT('assembly definition',#301,' ');
#305=PRODUCT_DEFINITION_CONTEXT_ROLE('part definition type',$);
#308=PRODUCT_RELATED_PRODUCT_CATEGORY('part',$,(#310,#320));
#309=PRODUCT_RELATED_PRODUCT_CATEGORY('assembly',$,(#310));
/* Part A0001 */
#310=PRODUCT('A0001','VW Beetle \X2\2013\X0\ P_101',$,(#302));
#311=PRODUCT_DEFINITION_FORMATION('1',$,#310);
#312=PRODUCT_DEFINITION('1',$,#311,#303);
#313=PRODUCT_DEFINITION_CONTEXT_ASSOCIATION(#312,#304,#305);
#314=PRODUCT_DEFINITION('2',$,#311,#303);
/* Part A0002 */
#320=PRODUCT('A0002','Engine-4/50KW-BX',$,(#302));
#321=PRODUCT_DEFINITION_FORMATION('1',$,#320);
#322=PRODUCT_DEFINITION('1',$,#321,#303);
#323=PRODUCT_DEFINITION_FORMATION('v2',$,#320);
#324=PRODUCT_DEFINITION('1',$,#323,#303);
#325=PRODUCT_DEFINITION_FORMATION_RELATIONSHIP(' ','sequence',$,#321,#323);
/* Assembly */
#400=NEXT_ASSEMBLY_USAGE_OCCURRENCE('SI0001',' ',$,#312,#322,$);
#401=PRODUCT_DEFINITION_OCCURRENCE_RELATIONSHIP(' ',$,#402,#400);
#402=PRODUCT_DEFINITION('SI0001',$,#321,#404);
#403=PRODUCT_DEFINITION_USAGE(' ','definition usage',$,#322,#402);
#404=PRODUCT_DEFINITION_CONTEXT('part occurrence',#301,' ');
/* Properties */
#500=(LENGTH_UNIT()NAMED_UNIT(*)SI_UNIT($,.METRE.));
#501=(MASS_UNIT()NAMED_UNIT(*)SI_UNIT(.KILO.,.GRAM.));
/* Property "overall length" */
#510=GENERAL_PROPERTY('','Overall length',$);
#511=GENERAL_PROPERTY_ASSOCIATION(' ',$,#510,#512);
#512=PROPERTY_DEFINITION('Overall length',$,#314);
#513=PROPERTY_DEFINITION_REPRESENTATION(#512,#515);
#514=REPRESENTATION_CONTEXT(' ',' ');
#515=REPRESENTATION(' ',(#516),#514);
#516=(LENGTH_MEASURE_WITH_UNIT()MEASURE_REPRESENTATION_ITEM()
MEASURE_WITH_UNIT(LENGTH_MEASURE(4.5),#500)REPRESENTATION_ITEM(' '));
/* Property "mass when empty" */
#520=GENERAL_PROPERTY('','mass when empty',$);
#521=GENERAL_PROPERTY_ASSOCIATION(' ',$,#520,#522);
#522=PROPERTY_DEFINITION('mass when empty',$,#314);
#523=PROPERTY_DEFINITION_REPRESENTATION(#522,#525);
#524=REPRESENTATION_CONTEXT(' ',' ');
#525=REPRESENTATION(' ',(#526),#524);
#526=(MASS_MEASURE_WITH_UNIT()MEASURE_REPRESENTATION_ITEM()
MEASURE_WITH_UNIT(MASS_MEASURE(750),#501)REPRESENTATION_ITEM(' '));
/* Rental car classification */
#600=CLASS_SYSTEM('Rental Car System',' ');
#601=CLASSIFICATION_ROLE('class system membership',$);
#602=APPLIED_CLASSIFICATION_ASSIGNMENT(#600,#601,(#610));
#610=CLASS('Bighorn car rental \X2\2013\X0\ B_101','compact, 2 door, 4 person, 2 luggage items');
#611=CLASSIFICATION_ROLE(' ',$);
#612=APPLIED_CLASSIFICATION_ASSIGNMENT(#610,#611,(#310));
#613=ID_ATTRIBUTE('Bighorn car rental',#610);
/* Product_as_individual */
#701=PRODUCT_DEFINITION_CONTEXT('physical occurrence',#301,' ');
#702=PRODUCT_RELATED_PRODUCT_CATEGORY('physically realized product',$,(#710,#780,#790));
/* Here the original state of my car as it was delivered with the original engine */
#710=PRODUCT('ABX123456789','my car',$,(#302));
#711=PRODUCT_DEFINITION_FORMATION('as-delivered',$,#710);
#712=PRODUCT_DEFINITION('1',$,#711,#701);
#713=PRODUCT_DEFINITION_RELATIONSHIP(' ','physical realization',$,#312,#712);
#714=ASSEMBLY_COMPONENT_USAGE(' ','physical occurrence usage',$,#712,#782, ' ');
#715=PRODUCT_DEFINITION_OCCURRENCE_RELATIONSHIP('physical realization',$,#402,#714);
/* The state after my car got a new engine. Now it no longer fits with the original state */
#721=PRODUCT_DEFINITION_FORMATION('after engine replacement',$,#710);
#722=PRODUCT_DEFINITION('1',$,#721,#701);
#724=ASSEMBLY_COMPONENT_USAGE(' ','physical occurrence usage',$,#722,#792, ' ');
#725=PRODUCT_DEFINITION_OCCURRENCE_RELATIONSHIP('physical realization',$,#402,#724);
#780=PRODUCT('STU4567890123',' ',$,(#302));
#781=PRODUCT_DEFINITION_FORMATION('1',$,#780);
#782=PRODUCT_DEFINITION('1',$,#781,#701);
#783=PRODUCT_DEFINITION_RELATIONSHIP(' ','physical realization',$,#322,#782);
#790=PRODUCT('XYZ987654321 ',' ',$,(#302));
#791=PRODUCT_DEFINITION_FORMATION('1',$,#790);
#792=PRODUCT_DEFINITION('1',$,#791,#701);
#793=PRODUCT_DEFINITION_RELATIONSHIP(' ','physical realization',$,#324,#792);
/* Property "mass when empty" */
#821=GENERAL_PROPERTY_ASSOCIATION(' ',$,#520,#822);
#822=PROPERTY_DEFINITION('mass when empty',$,#722);
#823=PROPERTY_DEFINITION_REPRESENTATION(#822,#825);
#824=REPRESENTATION_CONTEXT(' ',' ');
#825=REPRESENTATION(' ',(#826),#824);
#826=(MASS_MEASURE_WITH_UNIT()MEASURE_REPRESENTATION_ITEM()
MEASURE_WITH_UNIT(MASS_MEASURE(868),#501)REPRESENTATION_ITEM(' '));
ENDSEC;
END-ISO-10303-21;
Walk through the data-model along the given example
The core of the example was created with the application IDA-STEP Center. The following screenshot shows the root-tree listing most of the elements and an info-page for Part_view_definition (Item-instance in AP214) with the properties.
Product specification
There is a small hierarchy of two Product_classes, "pc1, VW Beetle" and the more specific CD one "pc2, VW Beetle CD". For pc2 a Product_configuration (= Product_identification in AP214) "pi1, VW Beetle – S_101" is defined. It has a description saying "1200cc, sunroof, red paint, leather seats". This should be covered by instances of Specification and Specification_category, but they are not (yet) available in IDA-STEP Center, used to create this example. So for now we go with Product_concept and Product_configuration, knowing that it should be Product_class and Product_specification respectively. The Product_configuration "pi1" is then assigned a design which is the Part_version "1" of Part "VW Beetle – P_101, A0001".
Parts, assembly and properties
This example comes with two example parts, "VW Beetle – P_101, A0001" and "Engine-4/50KW-BX, A0002".
The engine A0002 is available in the two versions "1" and "A". A relationship between these versions tell us that "A" is the successor of "1". Each version has a design view so that it can be used as a component in a higher level assembly, but there are no further properties defined for these versions.
The VW Beetle A001 has one version only but this one has two views "1" and "2". View "1" is an assembly view (see screenshot above) and there is exactly one component (Definition_based_part_occurrence) "SI0001" which is of type "Engine-4/50KW-BX, A0002". View "2" is a view with specification properties and there are two properties defined here, an "Overall length" of 4.5m and a "mass when empty" of 750 Kg.
The instance pattern to be used for even simple properties is quite complex. First we need to define the units, here these are SI unit for "metre" (m) and for "kilogram" (Kg). A particular value is given by instances of measure_representation_items which have to be combined with the base quantities length_measure_with_unit and mass_measure_with_unit. Because a measure_representation_items is a subtype of representation_item it has to be "founded" in a representation_context via a representation. For simple properties the representation_context has no particular semantic, so it has empty string values. The representation is then related to the property_definition which links to the products/parts. In addition we have to say that "overall length" and "mass when empty" are stand-alone concepts which can in principle be re-used many times. This is covered by general_property and general_property_association.
Classification
A Classification_system for a "Rental Car System" system is defined. For now it has only one class "Bighorn car rental – B_101". The part A0001 is defined to be a member of this class.
Physical individual
Lets have a particular car with the serial number in the vehicle identification number (= chassis number) ABX123456789 and which is of type "VW Beetle – P_101, A0001" and it has an engine with the identification number STU4567890123 which is of type Engine-4/50KW-BX, A0002 version 1. Later the engine is replaced by another one with the identification number XYZ987654321 which is of type "Engine-4/50KW-BX, A0002" version 2. With the new engine to car weight is measured to be 868 Kg.
Validation of the STEP example and observed problems
During the creation and validation of the example STEP file a couple of problems show up which require some extension and fixes of the standard.
SEDS 1195: Mapping of Product_as_individual not harmonized with AP214
Part and Clause where Issue Originates: ISO/TS 10303-1164:2004 Product as individual
Other Parts Affected by the Issue: -
Related Issues: -
Summary/Abstract/Keywords: Mapping is not harmonized with AP214
Problem Description: (A) A Product_as_individual_view (ARM) is equivalent to Physical_individual in the AP214 ARM. Unfortunately the mapping is totally different and I would consider even invalid. To my knowledge there is no other place in STEP where we create subtypes of product on the MIM/AIM level. Instead the kind of product is always defined by a product_related_product_category. Because the known implementations of AP239 and 236 are so far only on the ARM level it should not make any problem to fix and align the mapping and AIM with AP214.
(B) A further problem is that Product_design_version_to_individual is neither on the ARM nor on the MIM compatible with AP214 Physical_instance.is_realization_of.
B1: In AP214 the link is done via a product_definition_relationship while in the module is a product_definition_formation_relationship
B2: In AP214 the Physical_instance can only be related to either a Design_discipline_item_definition or to Product_identification while the modules allow any kind of Product_version.
B3: Both Product_design_to_individual and Product_design_version_to_individual are semantically rather week concepts. The definition is rather week and so a receiving system can't deduce that e.g. properties defined for the design (Part, Part_version) are also valid for the Product_as_individual/_version. For Physical_instance.is_realization_of a more rich semantic is defined by "... that collects the information defining the Physical_instance". So a receiving system can deduce that the properties defined for a part_view_definition/Design_disciple_item_definition are also valid for the Physical_instance_view and _version.
Conditions Under Which the Issue Was Discovered: Implementing parts of AP239 on the normative MIM level.
Proposed Solution (Optional): 1) Change the mapping of Product_as_individual to
product
{product <- product_related_product_category.products[i]
product_related_product_category <= product_category
product_category.name='physically realized product'}
and remove the mim subtype product_as_individual.
2) Remove the mim subtype product_as_individual_version and map the ARM entity Product_as_individual_version to product_definition_formation only.
3) For AP214 a "Physical_instance is the denomination of a physically realized object". To be in sync with the older AP214 we have consequently to remove the MIM subtype product_as_realized and use the generic supertype product_definition_formation instead. But AP214 don't know a Product_as_planned. So we can keep the more specific MIM subtype product_as_planned <= product_definition_formation (change/update supertype only).
4) To solve the problem (B) we propose to keep the current product_design_to_individual and product_design_version_to_individual for both ARM and MIM but to update the mapping according to the topics above and to restrict the attributes product_design and product_design_version to be of type Part and Part_version respectively.
5) In addition we must introduce the AP214 equivalent of physical_instance.is_realization_of as a new ARM entity. Proposal:
TYPE part_view_definition_or_product_configuration = SELECT (Part_view_definition, Product_configuration) END_TYPE; ENTITY Product_as_individual_view_realization; product_design : part_view_definition_or_product_configuration; individual_product : Product_as_individual_view; UNIQUE ur1 : individual_product; WHERE wr1 : xxx; END_ENTITY;
ur1 is to ensure that there can be at most one Product_as_individual_view_realization for a Product_as_individual_view. wr1 is to ensure that there are no product_design_to_individual and product_design_version_to_individual for the Product_as_individual_view referenced by individual_product.
Description: A Product_as_individual_view_realization relates a Part_view_definition or a Product_configuration that collects information to a defining Product_as_individual_view. In the case of a Part_view_definition all Assigned_attributes and the Item_shape if available are stated to be valid also for the Part_view_definition. In the case of a Product_configuration the information is given by the Specification if the subtype product_specification is used and by the Assigned_properties for the reference Product_concept if the subtype product_class is used.
Note: For Product_design_to_individual and Product_design_version_to_individual a receiving system can't be deduce the validity of any Assigned_property or Item_shape for the individual_product/_version.
This new entity might also be placed in a new module together with entities corresponding to the AP214 entities physical_assembly_relationship and physical_instance_test_result.
Additional Comment #1 From Lothar Klein 2007-01-30 07:12
Also the ARM entity Product_as_individual_view must map to a simple
product_definition on the MIM to not conflict with AP214. Proposal is to remove
in the MIM product_as_individual_view and update mapping accordingly.
SEDS 1196: Mapping of Physical_assembly_relationship.is_realization_of
Part and Clause where Issue Originates: ISO 10303-214, 5.1
Other Parts Affected by the Issue: -
Related Issues: -
Summary/Abstract/Keywords: -
Problem Description: Mapping of Physical_assembly_relationship.is_realization_of
Description: The current mapping of Physical_assembly_relationship.is_realization_of is not working as it should. Here the current mapping:
assembly_component_usage <=
product_definition_usage <=
product_definition_relationship
{product_definition_relationship.name = 'physical occurrence usage'}
product_definition_relationship.related_product_definition ->
product_definition <-
{product_definition.frame_of_reference ->
product_definition_context <=
application_context_element
application_context_element.name = 'physical occurrence'}
product_definition_relationship.related_product_definition
product_definition_relationship
{product_definition_relationship.name = 'physical realization'}
product_definition_relationship.relating_product_definition ->
product_definition
{product_definition.frame_of_reference ->
product_definition_context <=
application_context_element
application_context_element.name = 'part occurrence'}
We can see that the reference path follows product_definition_relationship.related_product_definition to a product_definition that is identical to the Physical_instance called out by the mapping of attribute physical_component. From here a second product_definition_relationship leads to the target product_definition for the Item_instance. With this mapping it is not possible to change the installation place of a physical_instance within another physical_instance to realize different Item_instance. E.g. we can't show that a physical_instance of a wheel was first mounted as the front-right wheel and later as the back-right wheel.
Proposed Solution (Optional): Change the mapping for the use of product_definition_occurrence_relationship instead of product_definition_relationship as it is given above:
assembly_component_usage <-
product_definition_occurrence_relationship.occurrence_usage
product_definition_occurrence_relationship
{product_definition_occurrence_relationship.name = 'physical realization'}
product_definition_occurrence_relationship.occurrence ->
product_definition
{product_definition.frame_of_reference ->
product_definition_context <=
application_context_element
application_context_element.name = 'part occurrence'}
This mapping is simpler and more direct compared with the original one. It directly reflects the ARM constraint and is also compatible with the S7 mapping of Item_instance.
This mapping has the advantage that .... (the official SEDS misses the end for unknown reasons)
New module Product_as_individual_assembly
To fully address SEDS #1195 and #1196 we created a new module within the STEP modular repository. The plan is to ballot is as part of AP203ed2 in mid 2007 and on success to include it in AP239 afterwards.
Here the proposed content for this module.
ARM:
SCHEMA Product_as_individual_assembly_arm;
USE FROM Part_occurrence_arm;
USE FROM Product_as_individual_arm;
TYPE part_view_definition_or_product_configuration = SELECT
(Part_view_definition, Product_configuration);
END_TYPE;
ENTITY Physical_assembly_relationship;
physical_component : Product_as_individual_view;
physical_assembly : Product_as_individual_view;
is_realization_of : Product_occurrence; --item_instance;
END_ENTITY;
ENTITY Product_as_individual_view_realization;
product_design : part_view_definition_or_product_configuration;
individual_product : Product_as_individual_view;
DERIVE
individual_product_version : Product_version := individual_product\Product_view_definition.defined_version;
UNIQUE
UR1 : individual_product;
WHERE
WR1 : NOT('PRODUCT_AS_INDIVIDUAL_ARM.PRODUCT_DESIGN_VERSION_TO_INDIVIDUAL' IN
TYPEOF(individual_product_version))
AND NOT('PRODUCT_AS_INDIVIDUAL_ARM.PRODUCT_DESIGN_TO_INDIVIDUAL' IN
TYPEOF(individual_product_version\Product_version.of_product));
END_ENTITY;
END_SCHEMA;
MIM:
SCHEMA Product_as_individual_assembly_mim; USE FROM Part_occurrence_mim; USE FROM Product_as_individual_mim; END_SCHEMA;
ARM to MIM mapping:
Physical_assembly_relationship
MIM element: assembly_component_usage
Source: ISO 10303-44
Reference path:
{assembly_component_usage <=
product_definition_usage <=
product_definition_relationship
product_definition_relationship.name = 'physical occurrence usage'}
Physical_assembly_relationship to Product_as_individual_view (as physical_component)
MIM element: PATH
Reference path:
assembly_component_usage <= product_definition_usage <= product_definition_relationship product_definition_relationship.related_product_definition -> product_definition
Physical_assembly_relationship to Product_as_individual_view (as physical_assembly)
MIM element: PATH
Reference path:
assembly_component_usage <= product_definition_usage <= product_definition_relationship product_definition_relationship.relating_product_definition -> product_definition
Physical_assembly_relationship to Product_occurrence (as is_realization_of)
MIM element: PATH
Reference path:
assembly_component_usage <-
product_definition_occurrence_relationship.occurrence_usage
product_definition_occurrence_relationship
{product_definition_occurrence_relationship.name = 'physical realization'}
product_definition_occurrence_relationship.occurrence ->
product_definition
Product_as_individual_view_realization
MIM element: (product_definition_relationship)(configuration_design)
Reference path:
(product_definition_relationship
{product_definition_relationship.name = 'physical realization'})
(configuration_design
{configuration_design.name = 'physical instance basis'})
Product_as_individual_view_realization to Part_view_definition (as product_design)
MIM element: PATH
Reference path:
product_definition_relationship
product_definition_relationship.relating_product_definition ->
product_definition
{product_definition.frame_of_reference ->
product_definition_context <=
application_context_element
application_context_element.name = 'part definition'}
Product_as_individual_view_realization to Product_configuration (as product_design)
MIM element: PATH
Reference path:
configuration_design configuration_design.configuration -> configuration_item
Product_as_individual_view_realization to part_view_definition_or_product_configuration (as product_design)
MIM element: PATH
Reference path:
(product_definition_relationship
product_definition_relationship.relating_product_definition ->
product_definition
{product_definition.frame_of_reference ->
product_definition_context <=
application_context_element
application_context_element.name = 'part definition'})
(configuration_design
configuration_design.configuration ->
configuration_item)
Product_as_individual_view_realization to Product_as_individual_view (as individual_product)
MIM element: PATH
Reference path:
(product_definition_relationship product_definition_relationship.related_product_definition -> product_definition) (configuration_design configuration_design.design -> configuration_design_item configuration_design_item = product_definition product_definition)
Validation result
The STEP file was finally validated with the JSDAI based validation application from LKSoft. We had to run this tool many times in an iterative loop till everything we could fixed was finally fixed. Here the result:
'Validate' program. Copyright 1999-2005, LKSoftWare GmbH
--- Exchange structure: S-TEN_D31_example-1.stp
--- Imported to the repository:
--- Reading time=4sec
count of instances in model "default": 87
#715=PRODUCT_DEFINITION_OCCURRENCE_RELATIONSHIP('physical realization',$,#402,#714);
Violation of where rule "wr3" in entity "product_definition_occurrence_relationship"
#725=PRODUCT_DEFINITION_OCCURRENCE_RELATIONSHIP('physical realization',$,#402,#724);
Violation of where rule "wr3" in entity "product_definition_occurrence_relationship"
count of global rules in schema instance "schema1": 0
count of erroneous instances: 2
count of violated global rules: 0
count of violated uniqueness rules: 0
--- Validation time=1sec
The remaining errors on instances #715 and #725 on where rule wr3 of product_definition_occurrence_relationship are caused due to the new usage of this entity to link the assembly structure of Product_as_individuals with the assembly structure of Part_view_definition/Assembly_definition. It has to be resolved as a part of SEDS #1196.
