CC8 Recommended Practices

Transcription

CC8 Recommended Practices
Specification and Configuration /
Product Coding /
Documents and Transformation Matrices
Authors:
Version:
Date:
Dr. Manfred Fischer,
Dr. Markus Sachers
1.3
December 2002
CC8 Recommended Practices, Version 1.2 Review!
0
Table of Contents
0
TABLE OF CONTENTS........................................................................................................................2
1
INTRODUCTION...................................................................................................................................4
2
SCOPE ....................................................................................................................................................6
3
GLOSSARY ............................................................................................................................................6
4
SUPPORTED EXCHANGE SCENARIOS ............................................................................................9
4.1
4.2
COMPLETE PRODUCT STRUCTURE EXCHANGE ...........................................................................................9
SIMPLIFIED PRODUCT STRUCTURE EXCHANGE ........................................................................................ 13
5
DOCUMENTS AND TRANSFORMATION MATRICES.................................................................. 16
6
LIST OF RELEVANT CC8 ENTITIES............................................................................................... 18
7
DESCRIPTION OF ENTITY APPLICATION (RECOMMENDED PRACTICES) ......................... 23
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
7.22
7.23
7.24
7.25
7.26
7.27
ALTERNATIVE_SOLUTION ..................................................................................................................... 23
CLASS_CATEGORY_ASSOCIATION ......................................................................................................... 24
CLASS_CONDITION_ASSOCIATION ......................................................................................................... 25
CLASS_INCLUSION_ASSOCIATION.......................................................................................................... 27
CLASS_SPECIFICATION_ASSOCIATION.................................................................................................... 28
CLASS_STRUCTURE_RELATIONSHIP ....................................................................................................... 30
COMPLEX_PRODUCT............................................................................................................................. 31
COMPONENT_PLACEMENT .................................................................................................................... 32
CONFIGURATION .................................................................................................................................. 34
GENERAL_ITEM_DEFINITION_INSTANCE_RELATIONSHIP ........................................................................ 37
ITEM_INSTANCE ................................................................................................................................... 38
PRODUCT_CLASS.................................................................................................................................. 40
PRODUCT_CLASS_RELATIONSHIP .......................................................................................................... 43
PRODUCT_COMPONENT ........................................................................................................................ 44
PRODUCT_CONSTITUENT ...................................................................................................................... 46
PRODUCT_FUNCTION............................................................................................................................ 46
PRODUCT_STRUCTURE_RELATIONSHIP .................................................................................................. 47
QUANTIFIED_INSTANCE ........................................................................................................................ 49
SINGLE_INSTANCE ............................................................................................................................... 50
SELECTED_INSTANCE ........................................................................................................................... 50
SPECIFICATION..................................................................................................................................... 51
SPECIFICATION_CATEGORY .................................................................................................................. 53
SPECIFICATION_CATEGORY_HIERARCHY ............................................................................................... 54
SPECIFICATION_EXPRESSION ................................................................................................................. 54
SPECIFICATION_INCLUSION................................................................................................................... 56
TECHNICAL_SOLUTION ......................................................................................................................... 58
WORK MANAGEMENT AND EFFECTIVITY ENTITIES .................................................................................. 60
8
SUMMARY........................................................................................................................................... 61
9
EXAMPLES.......................................................................................................................................... 62
9.1
9.2
9.3
9.4
9.5
9.6
REPRESENTATIONS OF VARIANTS........................................................................................................... 62
FEATURE GROUPS AND FEATURES .......................................................................................................... 64
PRODUCT STRUCTURE OF PRODUCT CLASS LEVEL 3................................................................................. 65
ABSTRACT PRODUCT STRUCTURE – TECHNICAL SOLUTION – PART IDENTIFICATION DATA......................... 66
ABSTRACT PRODUCT STRUCTURE – PRODUCTS OF DIFFERENT PRODUCT CLASSES ..................................... 67
ABSTRACT PRODUCT STRUCTURE OF A FURTHEST PRE-CONFIGURED ABSTRACT PRODUCT CLASS ............... 68
Page 2 of 75
9.7
9.8
FUNCTIONAL VIEW – PRODUCT_FUNCTION ............................................................................................ 69
SPECIFICATIONS AND CONFIGURATION INFORMATION ............................................................................. 70
Page 3 of 75
1
Introduction
This paper reflects the work of the working group 1.3 (WG 13) of the PDMI2 project and the
continuing work of the project group “Specification and Configuration” within the ProSTEP
Association. These working groups deal with the representation of Bill of Material (BoM) and Product
Coding (PC) data applying AP 214 (DIS) , CC8i. Changes and extensions of the FDIS version are
added in this document. This work was performed on a regular bases within the PDMI2 project and
the ProSTEP Association and was directed to the following overall objectives:
1. Investigate the ability of the STEP AP214 CC8 data model to represent the Product Coding
2. Understand what information can be exchanged with AP214
3. Understand what level of quality can be achieved in the exchange of data
4. Understand what type of information needs to be transferred manually and what information can
be transferred automatically using STEP
5. Investigate whether/which overall agreements need to be taken between the STEP members, to
allow the STEP standard to be applied
There were very few pre-existing experiences regarding this conformance class and its application.
Therefore and as the above listed objectives suggest, the investigation about the application was
performed on basic level to discover if the users needs and requirements could be represented
appropriately.
In order to understand the companies requirements a representative number of instantiation
examples were prepared. These examples were mainly used to achieve a common understanding in
the group and to enable the participants to discuss their requirements in "one language" - STEP. The
examples themselves are neither complete nor perfect but were developed as far as necessary for
the above mentioned purpose.
Participants in the group came from the companies which are listed below (in varying compositions),
and were usually dealing with the companies internal BoM and PC systems.
•
•
•
•
•
•
•
•
•
•
•
•
•
BMW AG
DaimlerChrysler AG
Delphi Automotive Systems GmbH
Continental Teves AG & Co. oHG
Robert Bosch GmbH
Scania AB
Volkswagen AG
Volvo AB
Dr.Ing.h.c.Porsche AG
EDS/UG
Eigner+Partner GmbH
SAP AG
Steyr-Daimler-Puch Fahrzeugtechnik AG (SFT)
All systems of which data was instantiated and therefore represented by STEP are in-house
developments of the involved companies. The main purpose for these system developments were
the following two aspects:
•
Documentation of product structures and variants
i
*ISO 10303 STEP:Standard for the Exchange of Product Model Data ;
AP 214 Application Protocol 214: Core Data for Automotive Mechanical Design Processes;
CC8: Conformance Class 8 - Conformance Class for configuration controlled design without shape representation
Page 4 of 75
•
Purpose of evaluation of valid orders or technically feasible products
The Figure 1.1 below shows the environment of today´s BoM systems in the automotive industries.
CaxSystem
CaxSystem
Engineering
PC / BoM
Production
PC / BoM
ERP
System
Product Coding /
Bill of Materials
System
PDM
System
Design Phase
Production Phase
Product Life Cycle / Process Chain
.....
Figure 1.1: BoM Systems and environment
These systems cover in detail the following functionality:
•
•
•
•
•
•
•
Management of product classification
Management of product structures (variants and assemblies)
Management of configuration structures (rules etc.)
Management of changes
Management of effectivity
Management of Bill of Material
Evaluation of valid single vehicles
This document also involves results and experiences from the following projects or application
projects: PCI (BMW - Rover), DaimlerChrysler - SFT (PDMI2 Application Project) and TBB
(Integration truck manufacturers and truck body builders)
Principle approaches of Product Coding
In general two basic approaches to product coding exist (see Fig. 2).
Rule-based product coding systems define standard vehicles, which comprise the maximum amount
of components of one certain vehicle family. Additionally defined rules and options allow the
determination of particular components of single vehicles by specifications and specification
combinations.
Feature-based systems use feature families, which each comprises all possible variants of that
certain feature family. Within the product structure of a single vehicle exactly one variant of each
feature family is allowed to be chosen. The variants are defined mutually exclusive in one feature
family.
Page 5 of 75
Rule-based Product Coding
Feature-based Product Coding
feature families :
- body
"
standard/complete car
- engine
- window
!
options and rules
- ....
...
...
Specification of standard car together with explicite
rules for replacing standard options
Clear definition of the types of options/specifications
and implicite conditions
Fig. 1.2: Approaches to Product Coding
Transferring information from one approach to the other might probably cause a loss of information.
A specific adoption might be necessary in those cases. For this, STEP AP 214 provides the common
basis for concrete data exchange scenarios and projects.
2
Scope
In order to provide a practical recommendation for the application of objects of AP 214 CC8 a
specific application scenario to be addressed has been defined as the basis for the considerations
which lead to this document.
In order to develop a recommendation of how to apply AP 214 ARM objects for the exchange of Bill
of Material and Product Coding information, the mentioned work groups agreed to focus in its
consideration on the exchange of this type of information between OEMs and their suppliers. In this
exchange scenario this type of information is already exchanged today.
The purpose of this exchange is to communicate which parts and structures have changed in a
specific period of time to a supplier. These changes are the basis for the supplier to control his
development activities for the client. This also involves information about which changes are of
interest for the supplier (which are the relevant variants of the product).
As more and more supplier develop systems for their customers, which usually can be used for a
number of different variants of a product, this type of information becomes more and more important.
In long terms there will also be a feedback of Product Coding information from the suppliers side.
The described recommendations should apply to first and second (or further) row suppliers.
3
Glossary
Due to the complexity of specification and configuration of variant products the various terms used in
this area are used with variuus different semantics. In this section the main terms are explained in the
way the project group members do understand them.
Page 6 of 75
•
Product:
A product can be sold to a customer. Examples for products are passenger cars, commercial
vehicles/trucks, busses, or engines or components of these products (gear boxes, chassis, engines,
cabs, axles, ...). The recommended 4th product class level („furthest pre-configured product class“,
see chapter “Product_class”) represents such a product.
•
Product class:
A product class is the identification of a set of similar products to be offered to the market. Product
classes can be related to each other within a hierarchical structure.
•
Abstract product structure:
Synonyms for this term are: Logical product structure, Generic product structure, Conceptual product
structure.
Abstract product structures are based on abstract/logical/generic/conceptual product components or
functions, which each serves as a „placeholder“ for one or more representations of physical
components (technical solutions). Abstract product structures usually contain configuration
information (specifications and configuration rules).
•
Component:
A component is an object within a product structure that is part of a product. Components can
represent abstract components (e.g. „chassis“, „interior“, AP214 objects “product_component” or
“product_function”), or physical components like non-variant explicit assemblies or parts (“items”).
Example: An engine can be a product (if it is sold to a customer „as-is“), or a component (if it is
assembled in a vehicle).
•
Product structure:
A product structure can contain abstract components, assemblies and parts (also software) of a
product or component. It can be expressed through various representations (e.g. through structured
trees or non-structured lists). A product structure can also contain configuration information
(specifications and configuration rules).
•
Bill of Material (BoM):
Bill of material in general is a term for all kind of part lists (including also software, lubricants etc.)
which may be structured in different contexts. In addition, the Bill of Material can also contain
abstract components (but does not need to). It can be expressed through various representations
(e.g. through structured trees or non-structured lists).
The difference between a product structure and a Bill of material is, that a Bill of material has to
contain parts of any kind. This is the current meaning of the expression Bill of material. The group
sees, that in future the “Bill of Material” will increasingly get a broader meaning (“Virtual Car”
processes, DMU). The meanings of product structure and Bill of Material will melt in the future.
A Bill of material may include means of configuration control.
The so called „Maximum BoM“ of a product contains all parts of which the product could consist (e.g.
a „150% BoM“). The BoM of a feasible product can be generated through evaluating the configuration
information within the „Maximum BoM“.
•
Product Coding:
Product Coding provides specification and configuration mechanisms being used to describe variant
product structures in all phases of the product life-cycle.
Page 7 of 75
•
Explicit assembly/product structure:
An explicit assembly/product structure contains all non-variant sub-assemblies and parts of a product
or component.
•
Specification:
A specification defines a characteristic of a class of products. It also can be a statement, which is
used to build rules, feature groups or packages.
•
Configuration:
A configuration is a part/product structure that represents a valid product variant. The instances of
the parts in a specific configuration can be physically composed to a valid manufacturable product.
The term configuration is also used to define the valid set of specifications, which determines a
specific instance of a product that can be sold to a customer.
A specific configuration of a vehicle is the result of an evaluation process of the configuration
information of an abstract product structure or a „150% BoM“ to an explicit manufacturable product
using rules and specifications. For representing the configuration information, in AP214 the
“configuration” object is used to associate product classifying objects with rules and product structure
in order to determine which objects are valid in the context of a certain product class (configuration
information).
•
Variant:
A variant generally is one of potentially more solutions for a technical requirement, function or
product component, which fulfills defined requirements in a certain way.
In AP214, a variant is defined as an alternative solution for an abstract product component or product
function. A variant is a technical solution, that fulfills the functional requirements of a function or
abstract product component in a certain way. The abstract product component includes all variants.
Example for variants, that are a technical solutions: The 3 parts „Part no.: W-345.3 (Wheel, 15-inch,
Aluminum)“, „Part no.: W-122.5 (Wheel, 12-inch, Steel)“ and „Part no.: W-777.9 (Wheel, 14-inch,
Steel)“ are variants for the abstract component „Wheel“.
Within the Project Group, the term „variant“ was interpreted in a broader sense than in AP214. A
variant can also be:
a) A product class:
Example: The vehicle variant „Middle Class Car, 2.0L Engine“ is represented by a product class of
level 3, named „Middle Class Car, 2.0L Engine“. It is a variant of the vehicle/product class „Middle
Class Car“ of product class level 2 („platform“).
b) An abstract product component as a complete vehicle:
Example: The vehicle variant „Middle Class Car, 2.0L Engine“ can be build as the variants
„Convertible“, „Limousine“ or „Combi“. Each of these variants are represented as single abstract
product components, which are linked to the product class „Middle Class Car, 2.0L Engine“ and which
are the root element of an abstract product structure tree.
c) An abstract product component as a component of a vehicle:
Example: The abstract product component „brake cylinder“ of a truck can be realized by the variants
„brake cylinder, single“, „brake cylinder, double“ or „brake cylinder, special“. Each of these variants
can themselves be realized by various technical or supplier solutions.
Page 8 of 75
To set the oftenly used terms “variant” and “alternative (solution)” in relation, the project group used
the following diagram as reference representation (Remark: There are no inheritance mechanisms or
other implicit meanings related to the similar wording in object oriented modelling associated to the
wording “Parent/Child”):
Parent object
Variant of
Child object
Variant of
Alternative
Variant of
Alternative
Child object
Child object
Figure 3.1: Variants and Alternatives
4
Supported exchange scenarios
This chapter specifies different scenarios for the exchange of product structures as well as the
handling of documents related to components of product structures as a necassary extension for
Digital Mock-Up (DMU) applications.
There are basically two different kinds of product structure exchange.
#
Complete exchange (complex scenarios 1 and 2)
#
Simplified exchange (“simple” approach with scenarios 3, 4, and 5)
4.1
Complete product structure exchange
There are two scenarios of complete product structure exchange in the scope of this document
possible (see also examples under section 8.8):
#
Exchange of a complete product structure (e.g. "Maximum BoM")
#
Exchange of a complete product
(e.g. single BoM, e.g. for a model, engine, gear box etc. without variants)
Scenario 1: Exchange of a complete product structure including configuration information
(e.g. "Maximum BoM"):
This case is expected to occur mainly as the first provision of BoM data to a supplier, who is
developing variant systems for an OEM. The provided data will be changed and updated by the OEM
and the supplier as a development project is progressing. Two general conditions are valid:
Page 9 of 75
•
Information, which specific components have to be changed by the supplier, can be
provided using work management information integrated in the product structure or using a
separate information channel (paper, e-mail, ...).
•
The vehicle manufacturer is responsible for the identification of all components and parts.
The suppliers are obliged to use those identifications when communicating with the
manufacturer.
The extend of information being exchanged can be classified into three types:
(a) "Maximum BoM" of one or more product classes including information about general
availability of specifications:
•
The „Maximum BoM“ includes all relevant product components, alternative solutions and
item instances (parts, assemblies) without any configuration information.
•
The kind of availability of specific specifications or specification expressions belonging to a
product class is not further specified.
(b) “Maximum BoM" of one or more product classes including specific information about the
types of specifications:
•
item instances (parts, assemblies) without any configuration information.
•
product class is specified using the appropriate types of availability (see chapters 6.3, 6.5).
(c) "Maximum BoM" including configuration information for the valid usage of product
components or technical solutions:
•
item instances (parts, assemblies) with all necessary configuration information (configuration
objects included).
•
product class is specified using the appropriate types of availability (see chapters 6.3, 6.5).
Page 10 of 75
Figure 4.1: Principle elements of AP214 CC8 for Exchange scenario 1
- Abstract product structure
- Specifications
- Configuration rules
- Work management data
- Effectivity data
- Project information
- Contract
Selection
of product and
structure
relevant for
project
Provision of
product
structure
relevant for
project
Reception
of product
structure
Processing of
product
structure
Product structure
- Complete
product structure
with configuration
data
(e.g. „Maximum BoM“)
- Work management
data
- Effectivity data
Figure 4.2: Exchange scenario 1
Page 11 of 75
Scenario 2: Exchange of a complete product
(single BoM, e.g. for a model, engine, gear box etc. without variants):
This case applies to the exchange of a specific model, a specific customer order or a prototype. It is
expected to occur mainly as the first provision of BoM data to a supplier, who is developing variant
systems for an OEM. The following preconditions are valid:
•
The single BoM includes all relevant product components, alternative solutions and item
instances
(parts,
assemblies)
and
configuration
information
(configurations,
specifications/expressions, specification categories) of one specific product (prototype,
customer order).
•
Only one variant for each product component is included, which is the valid variant for this
specific product.
•
The vehicle manufacturer is responsible for the identification of all components and parts.
The suppliers are obliged to use those identifications when communicating with the
manufacturer.
Page 12 of 75
- Abstract product structure
- Specifications
- Configuration rules
- Work management data
- Effectivity data
Selection
of product and
structure
by evaluating
the appropriate
configuration
rules
- Customer order
or
- Prototype information
- Contract
Provision of
product
structure
(and
appropriate
configuration
data)
Reception
of product
structure
Processing of
product
structure
- Complete
product structure
(with configuration
data) for
one single product
- Work
management data
- Effectivity data
Figure 4.4: Exchange scenario 2
4.2
Simplified product structure exchange
The exchange of complete BoM as well as a complete product is not necessary in any case:
•
Only a limited subset of specifications and configuration rules is necessary
•
It is not necessary that the receiver does understand the configuration mechanisms of the
sender in detail
•
The sender prepares the relevant data in a simple representation and has to re-identify it
when importing this data
There are three kinds of scenario of product structure exchange missing particular elements of
complete BoM specification in the sense above:
#
Exchange of a complete BoM
- including abstract product components and
- including simplified configuration information
#
Exchange of a complete BoM
- without abstract product components and
- including simplified configuration information
#
Exchange of a complete product‘s explicit product structure (assembly structure)
- including informal specification/identification information
These simplified scenarios were discussed in Joint Workshops with the Joint Project Group Odette /
VDA / ProSTEP “Recommendation for Assembly Data Exchange”. As a result three new process
moduls were specified:
•
Variant Assembly Structures (PM-VAS)
•
Specification Controlled Structures (DM-SCS)
Page 13 of 75
•
Effectivity Controlled Structures (DM-ECS)
Scenario 3 was classified as a simplification of scenario 1 and scenarios 4 and 5 as simplifications of
scenario 2. The scenario 4 - thought as a ‘short cut mechanism’ – will not be supported explictly.
Scenario 3: Exchange of a complete BoM including abstract product components and
including simplified configuration information:
•
developing variant systems for an OEM.
•
Abstract product components are included.
•
The configuration information is solely provided as textual (string-based) information
through the provision of specification specifically created for this purpose. These
specifications usually are not managed by the configuration processes of the sender and are
not stored persistently within PC/BoM or PDM systems.
•
The specifications are attached to the appropriate technical solutions of the product
structure.
Scenario 4: Exchange of a complete BoM without abstract product components and including
simplified configuration information
•
developing variant systems for an OEM.
•
Abstract product components are included.
•
The configuration information is solely provided as textual (string-based) information
through the provision of specification specifically created for this purpose. These
specifications usually are not managed by the configuration processes of the sender and are
not stored persistently within PC/BoM or PDM systems.
Page 14 of 75
•
The specifications are attached to the appropriate technical solutions of the product
structure.
The simple data includes:
•
No specification expressions or inclusions (no system interpretable rules)
•
No complex semantics of specification categories or specification types --> only
configuration type ‚usage‘
•
The only „CC8“ elements are: specification, specification_category (optional),
class_specification_association (not shown in figure 4.5), configuration
•
Product structures are solely represented using „CC6“ elements
Scenario 5: Exchange of a complete product‘s explicit product structure (assembly structure)
including informal specification/identification information
•
This case applies to the exchange of a specific model, a specific customer order or a
prototype of a certain product class.
•
The assembly structure includes only those assemblies and parts, which build the
manufacturable product of a certain product class. No abstract product components are
included. 2 possibilities are provided:
a) Including specifications: Those specifications which lead to this product are included as a
„simple list“, attached to the associated product class, without detailed configuration information.
b) Including identification number instead of specifications: No specifications are included,
instead a single identification number is provided.
•
Examples for products are: vehicle model, engine, gear box, chassis, ...
Page 15 of 75
Figure 4.7: Principle elements of AP214 CC8 for Exchange scenario 5a
AP214 construct for specific configured poduct (Scenario 5a):
•
List of specifications which lead to a specific explicit product structure
•
List is associated to product class
•
The assembly ‚A1‘ (containing the explicit product structure) results when evaluating the
product class using the specifications ‚Spec A‘ and ‚Spec B‘:
The coherence between abstract product structure, explicit product structure and
document/geometric model structure is very strong. E.g. for DMU applications it is necessary to
define configured structures including geometry and positioning information (see Figure 5.1).
Figure 4.8: Principle elements of AP214 CC8 for Exchange scenario 5b
AP214 construct for specific configured manufacturable poduct (Scenario 5b):
5
•
An identifier exists for a specific product identification of a product class
•
The appropriate specifications are not relevant
•
The shown item version ‚B2‘ is an instance of the product class identified by identification
number ‚AB12345C‘
Documents and transformation matrices
An important application area of configured product structures ist Digital Mock-Up (DMU). It implies
explicit product structure, configured product structure, document structure, and transformation
information.
Therefore explicit assembly structures may be related by documents enclosing geometry models for
the related parts, assemblies and/or sub-assemblies. These documents can be connected with each
other representing the document structure for the appropriated assembly structure.
Page 16 of 75
Note: The DMU scenario uses Entities of the AP214 CC06. Recommendations can be found in the
PDM Usage Guide (see Webpage ProSTEP of Association, PDM-IF).
Note: The correlation between assembly structure and document structure must not be a 1:1
relationship of their components.
The document structure may include transformation matrices as positioning information for each
relationship between two components.
Figure 5.1:
Three types of structures for assembly representation
(Abstract products, Explicit assemblies, Documents)
In order to integrate placements of abstract product components by transformation matrices the entity
Component_placement (see 7.8) can be used (see Figure 5.2). It specifies the relationship between
two Product_component’s added by placement information.
•
A Component_placement is the information pertaining to the placement of a
Product_component, which is defined in its own Cartesian_coordinate_space, in the
coordinate space of a reference Product_component.
•
An example for the use of a Component_placement is the placement of the
Product_component 'steering wheel' dependent on left hand versus right hand steering in
different countries.
Note: The Component_placement does not define a placement for all variants of the placed_
component in the context of 'reference_product_component'.
Page 17 of 75
Figure 5.2: Transformation matrices on abstract component level
For the application of Component_placement no actual use case was discussed within the work
group.
Example Scenario:
Exchange of design reference coordinate systems and provision of
detailed technical solution placements
Note: Currently no application case analysed.
1. OEM provides product component with reference coordinate system and specifications as
„input“ to supplier
2. Supplier develops concrete solutions
3. Supplier sends designed solutions with correct placement and specifications as „output“ to
OEM
This Scenario is an
structures.
ADD-ON
to anyone of the above scenarios for the exchange of configured product
In the following sections the recommendations of entity application will - where necessary - refer to
the above defined scenarios 1 and 2. Any other scenario specified in this chapter represents a
specialization (scenario 3 – 5) or an add-on (example scenario) to them.
6
List of relevant CC8 Entities
Note: In chapter and those passages which are taken from the STEP standards are represented in
cursive letters
The AP 214 Conformance Class 8 covers the following Units of Functionality (UoFs):
•
•
•
•
•
•
•
•
external_reference_mechanism (E1)
Item_property (PR1)
product_management_data (S1)
item_definition_structure (S3)
effectivity (S4)
work_management (S5)
classification (S6)
specification_control (S7)
The work of the project group was concentrated on UoF S7, specification control. All other UoFs are
also in scope of considerations of CC6, a AP 214 conformance class for which a number of analysis
work and implementations are available and which therefore were not in the main scope of the work
groups’ activities. Where necessary the existing agreement in overlapping areas of CC6 and CC8
were considered.
Page 18 of 75
However on the ARM - AIM mapping for a number of entities used in CC8 and CC6 may differ in
comparison to that in only CC6. This results from the application of these entities in connection with
UoF S7.
In order to enable a better understanding of the detailed description (see chapter 7) of the AP 214
CC8 subset recommended practices, the relevant entities in S7 are briefly described below. The most
important entities for the described application scenario are those indicated in the last row by being
subject to work group examples.
UoF S7 Entity
Description
alternative_solution An Alternative_solution is the identification of one of potentially
many mutually exclusive implementations of a Product_function
or of a Product_component.
E.g. it identifies a particular engine (e.g. 2 l Diesel) which is
implemented to realise the abstract engine in the product
structure, which is represented by a product_component.
class_category_
A Class_category_association is the association of a
association
Specification_category with a Product_class.
Additionally, this assignment specifies if the usage of one or
more Specification objects belonging to this
Specification_category, is mandatory or optional for all products
of that Product_class
class_condition_
A Class_condition_association is the association of a
association
Specification_expression with a Product_class. This association
can include the information that a particular
Specification_expression is valid for all products of that
Product_class.
This object usually is used to interconnect product classifying
objects with rules, which determine the specific characteristics
of individual products.
class_inclusion_
A Class_inclusion_association is the assignment of a
association
Specification_inclusion to a Product_class. This object is
applied to associate a product classifying object with an object
which is used to include rules or characteristics in a set (e.g.
package)
class_specification A Class_specification_association is an association of a
_
Specification with a Product_class. This Specification serves as
association
a potential characteristic of all products belonging to the
Product_class.
class_structure_
A Class_structure_relationship is an association between a
relationship
Product_class object and either a Product_component or
Product_function object. This relationship is used to represent
the interconnection of product classifying objects and the
logical, abstract product structure.
collected_item_
A Collected_item_association is a mechanism to associate
association
Item_instance objects with a Collection_definition.
This object was not used in the work group examples.
collected_definition A Collection_definition is the definition of an Item_version that
serves as a collector for Item_instance objects that are
mounted in the same vehicle but may not be assembled
together. This object was not used in the work group examples.
Subject to
project
group
examples
yes
yes
yes
yes
yes
yes
no
no
Page 19 of 75
complex_product
complex_product_
relationship
component_
placement
configuration
descriptive_
specification
design_
constraint
Abstract super-type of Product_function, Product_component,
or Alternative_solution. It is an object with the capability that it
can be realized by, decomposed into or specialized as
Product_constituent objects in a functional, logical, or physical
way. (This object was not used itself in the work group
examples, but only its sub-types)
A Complex_product_relationship is a relationship between two
Complex_product objects.
A Component_placement is the information pertaining to the
placement of a Product_component, which is defined in its own
Cartesian_coordinate_space, in the coordinate space of a
reference Product_component. An example for the use of a
Component_placement is the placement of the
Product_component 'steering wheel' dependent on left hand
versus right hand steering in different countries. This entity was
not included in AP214 (DIS), but was added in AP214 (FDIS).
A Configuration is the association of a
Class_condition_association or a
Class_specification_association object with a design or with a
process in order to define a valid usage of it in the context of a
certain Product_class. This object is used to associate product
classifying objects with rules and product structure in order to
determine which objects are valid.
A descriptive_specification is a text description of an object.
A Design_constraint is a requirement that has to be considered
in the design process of a Complex_product. This constraint
may be geometry based. This object was not used for the work
group examples.
design_constraint_ A Design_constraint_association is a mechanism to associate a
association
Design_constraint with an object that is subject to the constraint
indicated. This object was not used for the work group
examples.
design_constraint_ A Design_constraint_relationship is a relationship between two
relationship
Design_constraint objects. This object was not used for the
work group examples.
design_constraint_ Design_constraint_version is a particular version of a
version
Design_constraint. This object was not used for the work group
examples.
final_solution
A Final_solution is the specification of a set of additional
sensual characteristics that can be applied to an Item_instance
that represents a neutral part in order to finalize its definition.
An example is a chassis part with its final colour. This object
was not used for the work group examples
general_item_
A General_item_definition_instance_relationship is a
definition_
relationship between a Design_discipline_item_definition and an
instance_
Item_instance whose meaning is defined by the attribute
relationship
'relation_type'.
general_item_
A General_item_instance_relationship is a relationship between
instance_
two Item_instance objects whose meaning is defined by the
relationship
attribute 'relation_type'.
instance_placemen An Instance_placement is the information pertaining to the
t
placement of a Single_instance, which is defined in its own
Cartesian_coordinate_space, in the coordinate space of a
reference Product_component. This object was not used for the
work group examples.
(yes)
no
no
yes
no
no
no
no
no
no
yes
yes
no
Page 20 of 75
item_function_
association
An Item_function_association is a mechanism to relate a
Product_function and a Design_discipline_item_definition. This
object was not used for the work group examples.
item_instance
An Item_instance is the occurrence of an object that is defined
either by a Design_discipline_item_definition or by a
Product_identification. This object can e.g. be used to represent
the appearance of a part as a realisation of an abstract product
structure. In AP214 FDIS, this entity is only included in UoF S3.
item_instance_
An Item_instance_relationship is a relationship between two
relationship
Item_instance objects. Except if specified in a specialization of
this object, this relationship does not involve inheritance of data
between the two related objects. Each
Item_instance_relationship is a
General_item_instance_relationship, a
Same_time_machining_relationship, or a
Replaced_usage_relationship. This entity was not included in
UoF S7 (DIS), but was added in UoF S7 (FDIS).
physical_assembly A Physical_assembly_relationship is a mechanism to relate one
_
Physical_instance as a component to another
relationship
Physical_instance that plays the role of an assembly. This
object was not used for the work group examples.
physical_instance
A Physical_instance is the denomination of a physically realized
object. This object was not used for the work group examples.
physical_instance_ A Physical_instance_test_result is a mechanism to associate a
test_result
Physical_instance with measurements made on this
Physical_instance. NOTE: This object provides means to relate
the characteristics of a real object with a design intent. This
entity was not included in UoF S7 (DIS), but was added in UoF
S7 (FDIS).
product_class
Product_class is the identification of a set of similar products to
be offered to the market. In the work group this entity was used
to represent any product classifying object. This could e.g. be a
class of car models, engines or heavy trucks.
product_class_
A Product_class_relationship is a relationship between two
relationship
Product_class objects.
product_component A product_component is an element of a conceptual product
structure. This entity was used in the work group to represent
objects which were applied to structure products according to
logical, spatial or functional criteria. Examples could be
chassis, front vehicle or propulsion system.
product_constituent A Product_constituent is an object that may participate in the
functional, logical, or physical break-down or be an alternate
realization of a Complex_product. This object was not used
itself in the work group examples, but only its sub-types. In
AP214 FDIS, this entity is only included in UoF S3.
product_function
A Product_function is a behaviour or an action expected from a
product. Examples or breaking, stearing etc.
no
(yes)
no
no
no
no
yes
yes
yes
(yes)
yes
Page 21 of 75
product_
identification
A Product_identification identifies a manufacturable object, or
expected as so. A Product_identification is defined with respect
to the Product_class it is a member of. NOTE: The kind of
product that is to be manufactured from the data of the
Product_identification, is the kind of product that the
associated_product_class identifies a class of. NOTE: The
intent of Product_identification is the identification of one
manufacturable object whereas the intent of Product_class is
the gathering of products with similar characteristics.
EXAMPLE: A Product_identification that is associated with a
Product_class that identifies a family of Diesel engines is
intended to lead to the manufacture of a particular case of
Diesel engine, and the Product_identification that is associated
with a Product_class that identifies a car family will lead to the
manufacture of a car. Each Product_identification may be a
Product_specification. This entity was not included in UoF S7
(DIS), but was added in UoF S7 (FDIS).
product_
A Product_specification is a Product_identification for which
specification
one or more additional Specification objects enhance the
characterization provided for the associated Product_class. This
could be e.g. a pre-defined car model (special edition with
specific equipment) for which the colour is not defined and for
which only a limited set of colours is available. This object was
not applied in the work group examples.
product_structure_ A Product_structure_relationship is an association between a
relationship
Complex_product and a Product_constituent, in which the
Product_constituent is a functional, logical, or physical
component or a realization of the Complex_product. In the work
group this entity was mainly used to structure
product_component objects.
quantified_instance A Quantified_instance is the identification of the quantified
occurrence of an object that is defined either as a
Design_discipline_item_definition or as a Product_identification.
An example could be the occurrence of four equal wheels or a
certain quantity of engine oil in a bill of material. If this object is
applied to represent the occurrence of more than one part
these can not be placed In AP214 FDIS, this entity is only
included in UoF S3.
replaced_usage_
A Replaced_usage_relationship is a relationship between two
relationship
Item_instance objects where the relating Item_instance is
replaced by the related Item_instance. Each
Replaced_usage_relationship shall be referenced by an
Effectivity that defines the validity of the replacement. A
Replaced_usage_relationship is a type of
Item_instance_relationship. This entity was not included in UoF
S7 (DIS), but was added in UoF S7 (FDIS).
selected_instance
A Selected_instance is the instance of an Item whose quantity
depends on certain constraints. This object was not applied in
the work group examples. In AP214 FDIS, this entity is only
included in UoF S3.
single_instance
A Single_instance is one particular occurrence of an object that
is defined either as a Design_discipline_item_definition or as a
Product_identification. In AP214 FDIS, this entity is only
included in UoF S3.
specification
A specification defines a characteristic of a class of products. It
also can be a statement, which is used to build rules, feature
groups (specification_categories) or packages.
no
no
yes
yes
no
no
yes
yes
Page 22 of 75
specification_
category
specification_
category_hierarchy
specification_
expression
specification_
inclusion
specified_instance
supplier_solution
technical_solution
7
A Specification_category is the definition of a set of
Specification objects serving the same purpose.
This entity was used e.g. to represent feature groups. A feature
group is a set of product characteristics which can be applied to
solve the same technical purpose, e.g. set of engines, colours
etc..
Sometimes the characteristics within a feature group can be
mutually exclusive to each other. Often feature groups are
applied in combination with rules and specification_inclusions.
A Specification_category_hierarchy is used to build up
hierarchical structures of Specification_category objects. This
entity was not included in AP214 (DIS), but was added in
AP214 (FDIS).
A Specification_expression is a combination of Specification
objects formed by Boolean operations. This object is applied to
represent single parts of rules, which are used in BoM systems
alone and/or in combination with specification_categories
(feature groups) and specification_inclusions
A Specification_inclusion is the representation of the statement
that specifies that the application of a Specification or of a
Specification_expression implies the inclusion of an additional
Specification or Specification_expression.
This object is used to build a set of characteristics of different
types or rules, which could be used e.g. to represent packages
(e.g. sports package, elegance, special editions or technical
sets)
A Specified_instance is a mechanism to identify a certain
Item_instance in a multi level assembly structure that reuses
partial decompositions. E.g. a left wheel exists for front and for
rear axle. This object was not applied in the work group
examples.
A Supplier_solution is an alternative solution provided by a
particular supplier. This entity was not used in the work group
examples.
A Technical_solution is an alternative solution where the
functional requirements are fulfilled in a certain technical way.
This entity was applied to represent the realisation of an
abstract product structure by a single or different parts, e.g.
different batteries
yes
no
yes
yes
no
no
yes
Description of entity application (Recommended Practices)
Note: Below the application of the AP 214 ARM entities as agreed in the ProSTEP project group
“Specification and Configuration” is described. The following texts are mainly taken from the ISO AP
214 document and therefore underlay copyright. Where agreed and necessary (according to to the
project group) these texts are complemented by the recommendations of the project group. The
objective of all documentation below is the agreed application of AP 214 CC8. Therefore only those
entities will be listed which were actually considered in the investigation of the work group.
7.1
Alternative_solution
With respect to the application of this entity no special agreements were. In the work group mostly
the sub-types of Alternative_solution were used. Below the application requirements are listed:
An Alternative_solution may refer directly to the object to be implemented or to another
Alternative_solution object. In the latter case it serves as a refinement of the referenced
Alternative_solution.
Page 23 of 75
An Alternative_solution shall be instantiated only, if it is decomposed further into Product_component
or Product_function objects. An Alternative_solution is a type of Complex_product.
Each Alternative_solution may be a Technical_solution, a Supplier_solution, or a Final_solution.
The data associated with an Alternative_solution are the following:
•
base_element
7.1.1
base_element
The base_element specifies the object, for which the Alternative_solution provides a design
alternative. All Alternative_solution objects for the same base_element are mutually exclusive.
There shall be exactly one object that defines the base_element for an Alternative_solution.
7.1.2
ARM-AIM Mapping Alternative_solution
AP214-ARM Mapping / Rule
AP214-AIM Mapping / Rule
alternative_solution
(Create Entity) product_definition
product_definition.frame_of_reference ->
(Create Entity) product_definition_context
product_definition_context.name=‘alternative definition‘
product_definition
product_definition.formation ->
product_definition_formation
product_definition_formation.of_product ->
product
product.id
product_definition <product_definition_relationship.related_product_definition
(Create Entity) product_definition_relationship
{product_definition_relationship.name=‘solution alternative definition‘}
product_definition_relationship.relating_product_definition ->
product_definition
alternative_solution.id
alternative_solution.base_element
7.2
Class_category_association
This object can be used to represent the relationship between a class of products and a feature group
(as well referred to as family concept in this document, see also chapter “Specification_category”).
This object usually occurs in data derived from systems which support a feature group concept.
The application of this entity requires a receiving system which supports this feature group concept.
How this information can be translated into generally understandable information is at the preparation
point of this document not solved. The current agreements of the work group is to use this object as
recommended in AP 214.
The data associated with Class_category_association are the following:
•
associated_category;
•
associated_product_class;
•
mandatory.
NOTE In the case of a strict family concept for Specification_category objects this
Class_category_association specifies that the usage of exactly one Specification of this
Specification_category is mandatory for all products of that Product_class. If no strict family concept
for Specification_category objects is used, this Class_category_association specifies that the usage
of one or more Specification objects of this Specification_category is mandatory or optional for the
products of that Product_class.
Page 24 of 75
NOTE The assignment of a Specification_category to a Product_class does not replace the
association of single members of the Specification_category to the Product_class.
The data associated with a Class_category_association are the following:
•
•
•
mandatory
7.2.1
The associated_category specifies the Specification_category that is associated with the
Product_class. See Class_category_association to Specification_category for the application
assertion.
7.2.2
The associated_product_class specifies the Product_class for which the Specification_category is
valid. See Class_category_association to Product_class for the application assertion.
7.2.3
mandatory
The mandatory specifies whether one or more Specification objects of the associated
Specification_category have to be used or may be used (optional) for products within the referenced
Product_class. A value of 'true' indicates that the usage is mandatory.
EXAMPLE The specification category 'radio' may be associated 'optional' to the product class of a
car; the specification category 'engine' is an example for a 'mandatory' association.
7.2.4
ARM-AIM Mapping Class_category_association
class_category_association
.associated_product_class
.associated_category
class_category_associaton
.mandatory
(Create Entity) product_concept_feature_category_usage
product_concept_feature_category_usage.items[i] ->
product_class
product_concept_feature_category_usage.assigned_group ->
product_concept_feature_category
product_concept_feature_category_usage <role_association.item_with_role
(Create Entity) role_association
role_association.role ->
(Create Entity) object_role
object_role.name=‘optional category usage‘
if mandatory=‘true‘:
object_role.name=‘mandatory category usage‘
7.3
Class_condition_association
This object can be used to represent the relationship between a class of products and a rule (see also
chapter 7.23, specification_expression). This object usually occurs in data derived from systems
which support a rule based variant control concept.
The application of this entity requires a receiving system which supports this rule concept. Most BoM
systems in the automotive industries do understand rules, they do not always understand the same
Boolean expressions. How rule information can be translated into generally understandable
information is at the preparation point of this document not solved. The current agreements of the
work group is to use this object as recommended in AP 214.
Page 25 of 75
The meaning of this association is specified further by the attribute condition_type .
The data associated with a Class_condition_association are the following:
•
associated_condition;
•
•
condition_type;
•
description.
7.3.1
associated_condition
The associated_condition
Product_class.
specifies
the
Specification_expression
that
is
assigned to the
See Class_condition_association to Specification_expression for the application assertion.
7.3.2
associated_product_class
The associated_product_class specifies the Product_class for which the Specification_expression is
valid.
See Class_condition_association to Product_class for the application assertion.
7.3.3
condition_type
The condition_type specifies the meaning of the association.
The following values shall be used:
'design case': The Specification_expression specifies a condition when a given object has to be
designed and verified. This value of the condition_type is for information only and shall not be
interpreted when querying design cases or usage cases. For such a query, the value of the attribute
'configuration_type' of Configuration shall be evaluated;
NOTE: This value may be used to precise when a given Product_function or a given
Product_component has to be studied by the design department so that it provides solutions
appropriate for the case specified by 'associated_condition' and 'associated_product_class'.
'identification': The Specification_expression specifies a condition that enables to distinguish the
associated Product_class from other Product_class objects. This value is not applicable for a top level
node in a hierarchy of Product_class objects. This identification is part of the identification of all sub
classes of this Product_class;
'part usage': The Specification_expression specifies a condition for the usage of the components of
an Alternative_solution, the usage of an Item_instance or for the application of a Process_plan or a
Process_plan_operation_assignment in the products of the associated Product_class. In this case,
the Class_condition_association shall be referenced by at least one Configuration object;
´validity': The Specification_expression specifies a condition that is used to verify a
Product_specification for the associated Product_class. That means that the Specification_expression
evaluates to 'true' if the set of Specification objects is valid; otherwise it evaluates to 'false' with the
meaning that the specified object is invalid for the Product_class.
It is valid for all products belonging to the 'associated_product_class' in case of the condition types
'identification' and 'validity'.
Page 26 of 75
7.3.4
description
The description specifies additional information about the Class_condition_association. See
Class_condition_association to Multi_language_string for the application assertion. The description
need not be specified for a particular Class_condition_association.
If present, there shall be
Class_condition_association.
7.3.5
exactly
one
object
that
defines
the
description
for
a
ARM-AIM Mapping Class_condition_association
class_condition_association
(Create Entity) product_concept_feature_association
class_condition_association.associated_conditio product_concept_feature_association
n
product_concept_feature_association.feature ->
conditional_concept_feature.name = ‚expression‘
class_condition_association.associated_product product_concept_feature_association
_class
product_concept_feature_association.concept ->
product_class
class_condition_association.condition_type
product_concept_feature_association.name
7.4
Class_inclusion_association
This object can be used to represent the relationship between a class of products and packages of
product characteristics. This object can occur in data derived from systems which support a rule
based and or feature based variant control concept.
The application of this entity requires a receiving system which supports a package concept. How an
instance of a package and possible implicit semantics in the package can be translated into generally
understandable information is at the preparation point of this document not solved. The current
agreements of the work group is to use this object as recommended in AP 214.
This class_inclusion_association assignment contains the information
Specification_inclusion applies for all products of that Product_class.
that
a
particular
The data associated with a Class_inclusion_association are the following:
•
associated_inclusion;
•
•
description.
7.4.1
associated_inclusion
The associated_inclusion specifies the Specification_inclusion that is associated with the
Product_class.
See Class_inclusion_association to Specification_inclusion for the application assertion.
7.4.2
The associated_product_class specifies the Product_class for which the Specification_inclusion is
valid.
See Class_inclusion_association to Product_class for the application assertion.
Page 27 of 75
7.4.3
description
The description specifies additional information about the Class_inclusion_association. See
Class_inclusion_association to Multi_language_string for the application assertion. The description
need not be specified for a particular Class_inclusion_association. If present, there shall be exactly
one object that defines the description for a Class_inclusion_association.
7.4.4
ARM-AIM Mapping Class_inclusion_association
class_inclusion_association
class_inclusion_association.
associated_inclusion
(create new entity) product_concept_feature_association
product_concept_feature_association
product_concept_feature_association.feature ->
product_concept_feature =>
conditional_concept_feature =>
inclusion_product_concept_feature
product_concept_feature_association.concept ->
product_concept =>
product_class
product_concept_feature_association.description
class_inclusion_association.
class_inclusion_association. description
7.5
Class_specification_association
This entity is used to interconnect a class of products with its characteristics. These characteristics
describe potentially the products of that class and can also be those objects which are used to build
up rules, feature groups or packages. The outcome of the investigations of the work group was that
this entity can be applied as defined in AP 214.
The meaning of this association is specified further by the attribute association_type .
The data associated with a Class_specification_association are the following:
•
•
associated_specification;
•
association_type.
7.5.1
The associated_product_class specifies the Product_class for which the Specification is valid.
See Class_specification_association to Product_class for the application assertion.
It is recommended to use the following levels of product_class:
1. Enterprise / Company
2. Technical information / platform
3. Configuration information
4. Furthest pre-configured abstract product class
For more details, see chapter 7.12.
Page 28 of 75
7.5.2
associated_specification
The associated_specification specifies the Specification that is associated with the Product_class.
See Class_specification_association to Specification for the application assertion.
Specifications can in general be associated to all levels of product_classes. It must be assured that
the associated levels are also reflected by the correct product characteristics, represented by
specifications.
7.5.3
association_type
The association_type specifies the kind of availability of a particular Specification in a Product_class.
Where applicable the following values shall be used:
'availability': The Specification is a potential characteristic of any product belonging to a high level
Product_class. It is not specified if this is an option or a standard ;
If a system uses the association type ‘availability’, all available specifications should be associated to
product_class level 2. This is the level where also the maximum BoM is associated which therefore
should be reflected by the maximum of available specification.
'identification': The Specification is a characteristic that enables to distinguish the associated
Product_class from other Product_class objects. This is a kind of 'non replaceable standard'. This
value is not applicable for a top level node in a hierarchy of Product_class objects. This identification
is part of the identification of all sub classes of this Product_class ;
'non replaceable standard': The Specification is a characteristic of any product belonging to the
Product_class ;
'option': The Specification is a characteristic of a product if explicitly chosen. The Specification
replaces another Specification of the same specification category if the replaced Specification is
associated with the Product_class as 'replaceable standard' ;
'part usage': The Specification is a characteristic for the usage of the components of an
Alternative_solution, the usage of an Item_instance, or for the application of a Process_plan or a
Process_plan_operation_assignment in the products of the associated Product_class;
'replaceable standard': The Specification is a default characteristic of the products belonging to the
Product_class as long as no other specification of the same Specification_category is chosen .
7.5.4
ARM-AIM Mapping Class_specification_association
class_specification_association
class_specification_association.association_typ
e
class_specification_association.associated_prod
uct_class
class_specification_association.associated_spe
cification
class_specification_association.association_typ
e
class_specification_
association.associated_product_class
class_specification_
association.
associated_specification
(Create Entity) product_concept_feature_association
product_concept_feature_association.name=‘availability‘
product_concept_feature_association.concept
product_concept_feature_association.feature
product_concept_feature_association.name=‘availability‘
product_concept_feature_association.concept
product_concept_feature_association.feature
Page 29 of 75
7.6
Class_structure_relationship
As recommended from the work group 13 this entity defines the relationship between a class of
products and the abstract logical product structures. The logical product structures were represented
in the work group examples by hierarchies of product_components. Class_structure_relationship can
also be applied to point from a class of products to a functional structure of the products (represented
by product_function). There are the following recommendations from the project group with respect to
the application of this object.
For the first exchange scenario the Class_structure_relationship entity will be attached to the second
(in case of technical information) or to the third level (in case of product family) of a product_class
(see chapter 7.12). For the second case the Class_structure_relationship entity will be attached to
level four of the product_class entities. How data can be merged was not considered in the activities
of the project group.
The data associated with a Class_structure_relationship are the following:
•
description;
•
related;
•
relating;
•
relation_type.
7.6.1
description
The description specifies additional information about the Class_structure_relationship.
See Class_structure_relationship to Multi_language_string for the application assertion.
The description need not be specified for a particular Class_structure_relationship.
Class_structure_relationship.
7.6.2
exactly
one
object
that
defines
the
description
for
a
related
The related specifies the Product_component or Product_function object related by the
Class_structure_relationship.
NOTE The semantics of this attribute are defined by the attribute relation_type.
See Class_structure_relationship to Product_component and Class_structure_relationship to
Product_function for the application assertions.
There shall be exactly one object that the Class_structure_relationship is related to.
7.6.3
relating
The relating specifies the Product_class object related by the Class_structure_relationship.
NOTE The semantics of this attribute are defined by the attribute
Class_structure_relationship to Product_class for the application assertion.
relation_type.See
Page 30 of 75
7.6.4
4.2.69.4 relation_type
The relation_type specifies the meaning of the relationship.
'functionality': The related Product_function is an element of the functional structure of the relating
Product_class. This relation type shall only be used if the related object is a Product_function;
'realization': The related Product_component fulfils, partially or fully, the requirements identified with
the relating Product_class. This relation type shall only be used if the related object is a
Product_component.
7.6.5
ARM-AIM Mapping Class_structure_association
class_structure_relationship
class_structure_relationship.relating
(Create Entity) configuration_design
configuration_design
configuration_design.configuration ->
(Create Entity) configuration_item
configuration_item.item_concept ->
product_class
configuration_design
configuration_design.design ->
product_definition
configuration_design.name='realization'
class_structure_relationship.related
class_structure_relationship.relation_type
7.7
Complex_product
This entity was not used for the examples of the project group, but its sub-types. The mainly used
sub-types were Product_component and Alternative_solution. Therefore the recommendations
related to the application of these sub-types will be given in chapter 7.1 and chapter 7.14. No further
application recommendation to those in Ap 214 are given by the project group.
Each Complex_product is a Product_function, a Product_component, or an Alternative_solution.
The data associated with a Complex_product are the following:
•
id;
•
version_id.
7.7.1
id
The id specifies the identifier of the Complex_product. As within BoM systems an abstract object of
the product structure as well as a part can appear several times within the BoM, it is necessary to find
a unique identifier for the complex_product.id.
E.g. a product_component representing a variant module (e.g. variant assembly) could occur more
than once in a BoM, therefore using only the original id of the module for the id of the
product_component will lead to two or more product_component entities with the same id. This must
be avoided.
7.7.2
version_id
The version_id specifies the identification of a particular version of a Complex_product.
The version_id need not be specified for a particular Complex_product.
Page 31 of 75
7.7.3
ARM-AIM Mapping complex_product
complex_product
product_definition
7.8
Component_placement
Within the project group no
component_placement were made.
additional
recommendations
concerning
the
use
of
A Component_placement is the information pertaining to the placement of a Product_component,
which is defined in its own Cartesian_coordinate_space, in the coordinate space of a reference
Product_component.
An example for the use of a Component_placement is the placement of the Product_component
'steering wheel' dependent on left hand versus right hand steering in different countries.
The data associated with a Component_placement are the following:
•
placed_component;
•
placement;
•
reference_product_component.
7.8.1
placed_component
The placed_component specifies the Product_component that is positioned with respect to the
'reference_product_component'.
NOTE: The Component_placement does not define a placement for all variants of the
placed_component in the context of 'reference_product_component'.
The coordinate system that serves as a reference for the placement shall be specified by a
Model_property_association. the 'definition' of the Model_property_value shall be a General_property
with a 'property_type' of 'positioning'. The placement is only applicable for the placed_component and
Product_component or Item_instance objects that are explicitly placed in its coordinate space by
Component_placement or Instance_placement.
NOTE: The placement does not apply to variants of the placed_component, i.e., Alternative_solution
objects that refer to the placed_component as 'base_element'.
7.8.2
placement
The placement specifies the Geometric_model_relationship_with_transformation or the
Template_instance that defines the position of the 'placed_component' relatively to the
'reference_product_component'. In the case of Template_instance, the scale shall be omitted or set to
1.0.
7.8.3
reference_product_component
The reference_product_component specifies the high level Product_component that is defined in the
reference coordinate space. A Model_property_association shall be assigned to the
reference_product_component to define this reference coordinate space.
Page 32 of 75
Product_
component #1
Component_
placement #1.1
Product_
component #1.1
Product_
component #1.2
Steering wheel,
left hand
Steering wheel,
right hand
Component_
placement #1.2
Figure 7.1: Component_placement and Product_components
7.8.4
ARM-AIM Component_placement
Component_placement
(if component_placement.placement is a
geometric_model_relationship_with_transformation:
(Create entity) representation_relationship_with_transformation <=
representation_relationship
{representation_relationship.name = ‘component placement’})
(if component_placement.placement is a template_instance:
(Create entity) mapped_item)
representation_relationship_with_transformation <=
{representation_relationship.name = ‘component placement’}
representation_relationship.rep_1 ->)
mapped_item
mapped_item.mapping_source ->
(Create entity) representation_map
representation_map.mapped_representation ->)
(Create entity) representation <{representation.name = 'model property value'}
property_definition_representation.used_representation
(Create entity) property_definition_representation
property_definition_representation.definition ->
represented_definition
represented_definition = property_definition
(Create entity) property_definition
property_definition.definition ->
characterized_definition
characterized_definition = characterized_product_definition
(Create entity) characterized_product_definition
characterized_product_definition = product_definition
product_definition
{product_definition.frame_of_reference ->
product_definition_context <=
application_context_element
application_context_element.name = 'conceptual definition'}
{representation_relationship.name = ‘component placement’})
mapped_item
mapped_item.mapping_target ->
representation_item =>
geometric_representation_item =>
Component_placement.placed_component
Component_placement.placement
Page 33 of 75
Component_placement.
reference_product_component
7.9
(placement)
(cartesian_transformation_operator
(cartesian_transformation_operator.scl = 1.0)
(cartesian_transformation_operator.scl = $)))
{representation_relationship.name = ‘component placement’}
representation_relationship.rep_2 ->)
mapped_item <=
representation_item <representation.items[i])
(Create entity) representation <{representation.name = 'model property value'}
property_definition_representation.used_representation
(Create entity) property_definition_representation
property_definition_representation.definition ->
represented_definition
represented_definition = property_definition
(Create entity) property_definition
property_definition.definition ->
characterized_definition
characterized_definition = characterized_product_definition
(Create entity) characterized_product_definition
characterized_product_definition = product_definition
product_definition
{product_definition.frame_of_reference ->
application_context_element.name = 'conceptual definition'}
Configuration
This object connects those objects which are subject to configuration with configuration control
objects (Class_specification_association and Class_condition_association). The objects which can be
configured are the following:
Entity
Subject to project
group work
(ABS) Item_instance
yes
Process_plan
no
process_plan_operation_assignment
no
Alternative_solutions
yes
Product_components
yes
Product_function
no
A configuration may point to all levels of product_component or (ABS)item_instance instances. If
possible the configuration for the complete configuration mechanism (e.g. completely resolved rule)
should point to the technical_solution object which defines the leaf of a product_component tree. (see
also chapter 7.26) At any level in a product_component tree the configuration entity should carry the
Page 34 of 75
completely resolved configuration information of the higher product_components. See also Figure
below:
Product _
component 1
Cockpit
Product_
Rule: +Model Type X
component 2.1 + Left hand drive
Interior
Rule: +Model Type X
Abstract
Product
Structure
Seats
Product _
Rule: +Model Type X
component 2.2 + Left Hand Drive
Configuration x
Configuration x
Configuration x
Configuration x
Configuration x
Radio
Product _
Rule: +Model Type X
component 3.1 + Left hand drive
+ Customer choice
Basic radio
Technical _
solution 1
with tape player
Rule: +Model Type X
+ Left hand drive
+ Standard Radio
- Optional Radio
Technical _
solution 2
Radio with
tape player
and CD
Assembly
Structure
Rule: +Model Type X
+ Left hand drive
+ Optional Radio
- Standard Radio
Figure 7.2: Interconnection of configuration and variant product structure, related
configuration information (Rules)
NOTE The validity of the association may be limited by a time period through assigning an Effectivity
object to it.
NOTE The semantics of the kind of association is defined by the attributes configuration_type and
inheritance_type.
The data associated with a Configuration are the following:
•
configuration_type;
•
configured_element;
•
inheritance_type;
•
is_solution_for.
7.9.1
configuration_type
The configuration_type specifies the valid usage of a Configuration object that is applied to the
application object as configured_element.
'design': The object referenced as configured_element has to be designed and verified before it can
actually be used in a given context. This context is specified by the Class_condition_association and
Class_specification_association objects referenced as the is_solution_for.
This type of Configuration is applicable for Alternative_solution, Product_component,
Product_function, Process_plan, or Process_plan_operation_assignment objects;
Page 35 of 75
'usage': The object referenced as the configured_element is controlled by a Configuration. The
Class_condition_association and Class_specification_association objects specify the usage cases
and are referenced as the is_solution_for.
This type of Configuration is applicable for Alternative_solution, Item_instance, Process_plan, or
Process_plan_operation_assignment objects.
The value úsage´ is used for Configuration.configuration_type when a product_component is subject
of the configuration. This was agreed as in BoM systems ´design´ only applies in few cases and
úsage´ is the common case for the configuration.
7.9.2
configured_element
The configured_element specifies the application object that is controlled for its valid usage by the
Configuration.
See Configuration to Alternative_solution, Configuration to Item_instance, Configuration to
Process_plan,
Configuration
to
Process_plan_operation_assignment,
Configuration
to
Product_component, and Configuration to Product_function for the application assertions.
There shall be exactly one object that defines the configured_element for a Configuration.
7.9.3
inheritance_type
The inheritance_type specifies whether or not an inheritance scheme for the configuration information
in a hierarchical structure is applied to the application object referenced as the configured_element.
The levels within such a hierarchy are defined through Product_structure_relationship objects or the
attribute 'base_element' of Alternative_solution.
'exception': No inheritance scheme is applicable and all required configuration information must be
attached locally at the application object. The value indicates that the configuration information may
be inconsistent to the structural levels above it or that it is, on purpose, contradictory to it. Such a
condition implies that an inheritance scheme shall not continue beyond this point in the product
structure tree ;
EXAMPLE A situation where the inheritance_type 'exception' is applicable is a technical solution
released for an one particular customer without support in higher structure levels.
'inherited': A scheme for inheritance of configuration information applies. The complete configuration
information shall be collected from the different levels in the structure by evaluation of results. The
results shall be evaluated using the logical AND to combine configuration information starting at the
referenced configured_element and using the logical OR to combine alternatives. In addition, this
evaluation shall consider related effectivity information. 'inherited' only applies for objects for which
the same value of configuration_type is defined;
'local': No inheritance scheme is applicable and all required configuration information must be
attached locally at the application object. Nevertheless, any potentially inherited configuration
information of a higher level shall be consistent, i.e., be a subset of the locally defined configuration
information.
In order to exchange always complete sets of configuration information the project group examples
usually applied the value "local" for configuration.inheritance_type.
Page 36 of 75
7.9.4
is_solution_for
The is_solution_for specifies the characteristic or combination of characteristics for which the object
referenced as the configured_element provides a solution or which is needed to control a process
operation. These characteristics are defined by a Class_specification_association and combinations
of characteristics are defined by a Class_condition_association where the attribute 'condition type' is
'part usage'.
See
Configuration
to
Class_condition_association
and
Configuration
to
Class_specification_association for the application assertions. There shall be exactly one object that
the Configuration is_solution_for.
7.9.5
ARM-AIM Mapping Configuration
configuration
configuration.configurated_element
(Create Entity) configured_effectivity_assignment
configured_effectivity_assignment.items[] ->
product_definition
configured_effectivity_assignment <configured_effectivity_context_assignment.assigned_effectivity_assignment
(Create Entity) configured_effectivity_context_assignment
configured_effectivity_context_assignment.items[i] ->
configured_effectivity_assignment <role_association.item_with_role
object_role.name = 'usage'
configured_effectivity_assignment <role_association.item_with_role
role_association
object_role
object_role.description = 'local'
configuration.is_solution_for
configuration.configuration_type
configuration.inheritance_type
7.10
General_item_definition_instance_relationship
No special recommendations with respect to the application of this object can be given.
EXAMPLE The relationship between the definition (Design_discipline_item_definition) of a rubber
gasket and the instances (Item_instance) of the doors the gasket is used for, is an example for a
General_item_definition_instance_relationship. In this case the relationship gives information that the
length of the gasket depends on the actual shape of each door.
A General_item_definition_instance_relationship is a type of Item_definition_instance_relationship.
The data associated with a General_item_definition_instance_relationship are the following:
•
description;
•
relation_type.
7.10.1 description
The
description
specifies
additional
information
about
the
General_item_definition_instance_relationship. See General_item_definition_instance_relationship to
Multi_language_string for the application assertion.
The description need not be specified for a particular General_item_definition_instance_relationship.
Page 37 of 75
If present, there shall be exactly one
General_item_definition_instance_relationship.
object
that
defines
the
description
for
a
7.10.2 relation_type
The relation_type specifies the meaning of the relationship.
7.10.3 ARM-AIM Mapping General_item_definition_instance_relationship
General_item_definition_instance_relationship
(create entity) product_definition_relationship
General_item_definition_instance_relationship.d product_definition_relationship. description
escription
General_item_definition_instance_relationship.re product_definition_relationship.name
lation_type
7.11
Item_instance
The sub-types of Item_instance were used in all examples of the project group. The Item_instance
entity associates the occurrence of parts with the abstract product structure. With respect to its
application no additional recommendations to AP 214 are necessary.
An Item_instance shall be used,
Assembly_component_relationship.
at
least
once,
as
an Alternative_solution or
in an
EXAMPLE In the case of a car, the Item 'wheel' is defined once. Its Design_discipline_item_definition
carries all the information necessary to define the wheel (e.g., its shape) independent of its usage.
Additionally, there are 5 Item_instance objects for this wheel since there are 5 equal wheels used in a
car: Front-left, front-right, rear-left, rear-right, and spare wheel. Each of these instances may carry
additional information such as placement or function.
An Item_instance is a type of Product_constituent.
Each Item_instance is a Single_instance, a Quantified_instance, a Selected_instance, or a
Specified_instance.
The data associated with an Item_instance are the following:
•
definition;
•
description;
•
id.
7.11.1 definition
The definition specifies the Design_discipline_item_definition or the Product_identification that serves
as a definition for this particular occurrence. If an appropriate Design_discipline_item_definition is
available, this Design_discipline_item_definition shall be used as definition, otherwise a
Product_identification shall be referenced.
See Item_instance to Design_discipline_item_definition and Item_instance to Product_identification
for the application assertions.
There shall be exactly one object that defines the definition for an Item_instance.
Page 38 of 75
7.11.2 description
The description specifies additional information about the Item_instance.
See Item_instance to Multi_language_string for the application assertion.
The description need not be specified for a particular Item_instance.
If present, there shall be exactly one object that defines the description for an Item_instance.
7.11.3 id
The id specifies the identifier of the Item_instance.
7.11.4 ARM-AIM Mapping Item_instance
Item_instance
(Create entity) product_definition
application_context_element.name = 'part occurrence'
product_definition <(if item_instance is referenced by an assembly_component_relationship
as related:
[product_definition_occurrence_relationship.occurrence
(Create entity) product_definition_occurrence_relationship
product_definition_occurrence_relationship.occurrence_usage ->]
[product_definition_relationship.related_product_definition
(Create entity) product_definition_relationship
product_definition_relationship.name = 'definition usage'
product_definition <{product_definition.frame_of_reference ->
application_context_element.name = 'part definition'}
product_definition_relationship.related_product_definition
product_definition_relationship =>
product_definition_usage =>]
assembly_component_usage)
(if item_instance is not referenced by an
assembly_component_relationship as related:
product_definition_relationship.name = 'definition usage']
product_definition_relationship =>
product_definition_usage])
product_defintion <product_definiton_relationship.related_product_definiton
{product_definition_relationship.name = 'definition usage'}
product_definition
(if item_instance is referenced by an assembly_component_relationship
as related:
[product_definition.description]
[product_definition_relationship.description])
product_definition.description)
(if item_instance is referenced by an assembly_component_relationship
as related:
[product_definition.id]
[product_definition_relationship.id])
product_definition.id)
Item_instance.definition (->ddid)
Item_instance.description
Item_instance.id
Page 39 of 75
7.12
Product_class
Within the BoM and product configuration systems which were considered by the activities of the
project group the concepts for classifying products was one of the crucial points to manage product
variant. All systems classify products according to company internal view and policies and some
concepts are comparable, but usually were never alike.
With respect to the application of this entity the following recommendations and agreements were
made:
Number of levels:
The use of four levels of product_class is recommended:
1. Enterprise (Company): The highest level of the product_class instance in a file must always
represent the company. This is necessary as some systems have this class as a general starting
point. The id of this instance will be a unique identifier for the relevant company. This class
carries no variant control information but only characteristics (e.g. specification,
specification_category etc.) of that class.
2. Technical information / platform: This instance of the product_class reflects the level of a product
class in a BoM system which represents a main technical product base (e.g. project, platform,
engineering series etc.). In some cases this level carries a complete BoM ("Maximum BoM") for a
project, platform, engineering series etc. This level is in some cases called technical
documentation. This level carries only characteristics of this class level, no variant control
mechanisms are attached.
3. Configuration information / product family: This instance will be the one to which all variant
control mechanism are attached. For trucks configuration information (specifications,
specification_expression etc.) may be associated on level three and four. For cars this may only
be attached on level three.
4. Furthest pre-configured abstract product class: This instance of a product_class represents the
furthest configured class of a product, which is not yet a real product. E.g. this could be a
complete vehicle, engine, gear-box etc. which has not been evaluated against customer special
choices or a abstract vehicle, engine, gear-box etc. which could become a real one after the
associated BoM is evaluated. The purpose of this level of a product class instance is in any case
to reflect that level of product class of a BoM system which leads to the individual BoM for a
single product. This product class level will be particularly exchanged in the context of scenario
2, “Exchange of a single BoM”.
An example for cars see below:
Page 40 of 75
product_class#1
id=´STEP-Cars´
level_type=énterprise´
relating
product_class
_relationship#1
relation_type=´hierarchy´
related
relation_type=
´realization´
class_structure_
relationship#1
relating
product_class#2
related
id=ÁV999.000´
instance_
required=´true´
product_
component#1
id=´MC´
level_type=´platform
[technical documentation]
relating
description=
´STEP cars
middle class
vehicle´
product_class
_relationship#2
related
relation_type=
´realization´
relating
class_structure_
relationship#2
product_class#3
related
id=ÁV999.100´
instance_
required=´true´
product_
component#2
id=´MCL20´
level_type=´product family
[Configuration information
relating
description=
´STEP cars
middle class
limousine, 2l
engine´
product_class
_relationship#3
related
relation_type=
´realization´
relating
class_structure_
relationship#3
related
id=ÁV999.130´
instance_
required=´true´
product_
component#3
product_class#4
description=
´STEP cars
middle class
limousine, 2l
engine, standard
equipment, USA
marketing set´
id=´MCL20 st US´
level_type=´furthest
pre-configured
abstract product
class´
Figure 7.3: Example levels of product_class
Product_component entities can be attached by a class_structure_relationship from level two on but
not on level one (see chapter 7.6).
The structure of the product_class entities shall be hierarchical. Specification entities can be assigned
on all levels in order to represent characteristics, available choices etc. of that particular
Product_class, but only on level three (trucks: three and four) those specifications are to be assigned
which are used to build rules, feature groups or specification control in general.
In the case that more than four product class levels are managed in a Product Coding system, it is
recommended to proceed as follows:
1. The system internal product classes should be mapped onto the four levels described above. In
general, this is only possible if available valid specifications, specification_categories and
specification_expressions associated to different product classes of the same level are
compatible for one specific exchange file. Whether this is the case or not has to be evaluated in
each specific scenario.
Page 41 of 75
2. If it is not at all possible to use the four recommended levels the following rules are to be
considered:
(a)
The highest level of the product_class instance in a file must always represent the company
(level = ‘enterprise’).
(b)
In the context of scenario 2 the lowest level of product_class must always be the furthest
pre-configured abstract product class as recommended above.
The data associated with a Product_class are the following:
•
description;
•
id;
•
level_type;
•
name;
•
version_id.
7.12.1 description
The description specifies additional information about the Product_class.
See Product_class to Multi_language_string for the application assertion.
The description need not be specified for a particular Product_class.
If present, there shall be exactly one object that defines the description for a Product_class.
7.12.2 id
The id specifies the identifier of the Product_class that shall be unique.
NOTE The scope of the uniqueness is usually dependent on the form of implementation; it may be
e.g., a physical file or a data base.
7.12.3 level_type
The level_type specifies the level or category of this Product_class in a hierarchical structure of
Product_class objects.
It is recommended to use the following values:
•
énterprise´ for product-class level 1
•
´platform´ for product-class level 2
•
´product family´ for product-class level 3
•
´furthest pre-configured abstract product class´ for product-class level 4
7.12.4 name
The name specifies the word or group of words by which the Product_class is referred to.
See Product_class to Multi_language_string for the application assertion.
Page 42 of 75
The name need not be specified for a particular Product_class.
If present, there shall be exactly one object that defines the name for a Product_class.
7.12.5 version_id
The version_id specifies the identification of a particular version of a Product_class.
The version_id need not be specified for a particular Product_class.
7.12.6 ARM-AIM Mapping Product_class
product_class
product_class <=
product_concept
product_class <=
product_concept.id
product_class <=
characterized_object.name
product_class <=
product_concept.name
product_class <= product_concept.description
product_class.id
product_class.level_type
product_class.name
product_class.
description
7.13
Product_class_relationship
This entity is used to interconnect the different instances of the Product_class entity. No special
recommendation, besides see chapter 7.13.4, were made by the project group.
The data associated with a Product_class_relationship are the following:
•
description;
•
related;
•
relating;
•
relation_type.
7.13.1 description
The description specifies additional information about the Product_class_relationship.
See Product_class_relationship to Multi_language_string for the application assertion.
The description need not be specified for a particular Product_class_relationship.
If present, there shall
Product_class_relationship.
be
exactly
one
object
that
defines
the
description
for
a
7.13.2 related
The related specifies the
second
of
the
two
Product_class
objects
related
by
the
See Product_class_relationship to Product_class for the application assertion.
Page 43 of 75
7.13.3 relating
The relating specifies the
first
of
the
two
Product_class
objects
related
by
the
See Product_class_relationship to Product_class for the application assertion.
The relation_type specifies the meaning of the relationship. The work group 13 recommend for
exchange purposes to use for Product_class.relation_type 'hierarchy'.
'derivation': the Product_class_relationship defines a relationship where the related Product_class is
derived from the relating Product_class;
'hierarchy': the Product_class_relationship defines a relationship where the relating Product_class is
on a higher level in the hierarchy of Product_class objects than the related Product_class; 'version
sequence' was not used for the project group examples
NOTE The relationship does not imply inheritance of any kind between the application objects that are
related.
7.13.5 ARM-AIM Mapping Product_class_relationship
product_class_relationship
product_class_
relationship.relating
product_class_
relationship.related
product_class_
relationship.
relation_type
product_concept_relationship.
relating_product_concept
related_product_concept
(product_concept_relationship.name)
(product_concept_relationship.name=‘derivation‘)
(product_concept_relationship.name=‘hierarchy‘)
(product_concept_relationship.name=‘version sequence‘)
(product_concept_relationship.name=‘substitution‘)
7.14
Product_component
The Product_component entity was applied in the project group examples to represent the abstract
and/or specification controlled product structure which is managed within BoM systems. The highest
level of a product_component must always represent the associated Product_class (see chapter 7.6).
It must be stressed that some BoM systems do not support the product_component object at all.
When data is transferred to such systems there is a danger of data loss. For the addressed scenario
of the project group recommendations this problem is not of major importance, but in long terms
need some more agreement work. There are no further recommendations besides those of AP 214
and the above mentioned points with respect to the application of this entity.
Product_component is a type of a Complex_product and Product_constituent. The data associated
with a product_component are the following:
•
description
•
instance_required
•
is_influenced_by
Page 44 of 75
•
is_relevant_for
•
name
7.14.1 description
The description specifies additional information about the product_component. The description need
not be specified for a particular Product_component. If present, there shall be exactly one object that
defines the description for a Product_component.
7.14.2 instance_required
The instance_required specifies if the existance of a corresponding Item_instance is required for te
various Alternative_solution objects of that Product_component. A value of "true" indicates that the
corresponding Item_instnace is required.
7.14.3 is_influenced_by
The is_influenced_by specifies the Specification_category objects that impacts the design of a
solution for the Product_component in the context of the Product_class objects that are referred to by
the Class_category_association objects.
7.14.4 is_relevant_for
The is_relevant_for specifies the Application_context in which the Product_component has to be
considered.
7.14.5 name
The name specifies the word or group of words by which the Product_component is referred to.
7.14.6 ARM-AIM Mapping Product_component
product_component
[(Create Entity) product_definition_formation
(Create Entity) product
product_related_product_category.products[i]
product_related_product_category <=
product_category
product_category.name = 'conceptual product']
[product_definition_formation <product_definition.formation
(Create Entity) product_definition_context <=
application_context_element.name = 'conceptual definition’]
product
product.id
product
product.name
product_definition_formation <product_definition.formation
product_definition
product_definition.name
{(if product_component.instance_required is TRUE:
product_definition.name = 'instance required')
(if product_component.instance_required is FALSE:
product_definition.name = ‘no instance required')}
product_component.id
product_component.name
product_component.instance_required
Page 45 of 75
7.15
Product_constituent
A Product_constituent is an object that may participate in the functional, logical, or physical breakdown or be an alternate realization of a Complex_product. No special recommendation were made.
Each Product_constituent is a Product_component, a Product_function, or an Item_instance.
7.15.1 ARM-AIM Mapping Product_constituent
Product_constituent
(if product_constituent is an item_instance:
product_definition)
(if product_constituent is not an item_instance:
product_definition_formation)
7.16
Product_function
This object was applied by the project group to represent a functional view on product_components.
Product_components in different branches of a product component tree can belong to one common
product function (see example in section 8). Product_functions can also be composed to a product
function tree.
A Product_function is a behaviour or an action expected from a product.
EXAMPLE: The Product_function 'transportation' with sub-functions 'acceleration' and 'retardation' or
the Product_function 'illumination' with sub-functions 'exterior illumination' and 'interior illumination' are
examples for Product_function objects in a hierarchical structure.
A Product_function is a type of Complex_product and Product_constituent.
The data associated with a Product_function are the following:
•
description;
•
is_relevant_for;
•
name.
7.16.1 description
The description specifies additional information about the
Product_function.
The description need not be specified for a particular Product_function.
If present, there shall be exactly one object that defines the description for a Product_function.
7.16.2 is_relevant_for
The is_relevant_for specifies the Application_context objects in which the Product_function has to be
considered.
7.16.3 name
The name specifies the word or group of words by which the Product_function is referred to.
Page 46 of 75
The name need not be specified for a particular Product_function.
If present, there shall be exactly one object that defines the name for a Product_function.
7.16.4 ARM-AIM Mapping Product_function
product_function
[(Create Entity) product_definition_formation
product_related_product_category.products[i]
product_related_product_category <=
product_category
product_category.name = 'functionality']
[product_definition_formation <product_definition.formation
(Create Entity) product_definition_context <=
application_context_element.name = 'functional definition’]
product
product.id
product
product.name
product_definition_formation <product_definition.formation
product_definition
product_definition_context_association.definition
(Create Entity) product_definition_context_association
{product_definition_context_association.role ->
(Create Entity) product_definition_context_role
product_definition_context_role.name = 'application context’}
product_definition_context_association.frame_of_reference ->
product_definition_context
product_function.id
product_function.name
product_function.is_relevant_for
7.17
Product_structure_relationship
This object was applied by the project group to represent the relationship between objects of the
abstract and variant product structure. There are no additional recommendations with respect to its
application.
The data associated with a Product_structure_relationship are the following:
•
description;
•
related;
•
relating;
•
relation_type.
7.17.1 description
The description specifies additional information about the Product_structure_relationship.
See Product_structure_relationship to Multi_language_string for the application assertion.
The description need not be specified for a particular Product_structure_relationship.
Page 47 of 75
Product_structure_relationship.
exactly
one
object
that
defines
the
description
for
a
7.17.2 related
The related specifies the Product_constituent that is a functional, logical, or physical component or a
realization of the relating Complex_product.
See Product_structure_relationship to Product_constituent for the application assertion.
7.17.3 relating
The relating specifies the Complex_product that is decomposed functionally, logically, or physically
into or realized by the related Product_constituent.
See Product_structure_relationship to Complex_product for the application assertion.
The relation_type specifies the meaning of the relationship. Where applicable the following values
shall be used:
'decomposition': The related Product_constituent is one of potentially more components of the relating
Complex_product. This relation type shall only be used for Complex_product and Product_constituent
of the same type;
'functionality': The related Product_constituent is an element of the functional structure of the relating
Complex_product. This relation type shall only be used with a Complex_product of type
Alternative_solution or Product_component and with a Product_constituent of type Product_function ;
EXAMPLE The Product_function 'heat dissipation' may be considered as one of the functionalities to
be fulfilled by any technical solution for the Product_component 'braking system'.
'realization': The related Product_constituent is a means for fulfilling, either partially or fully, the
requirements identified with the relating Complex_product. This relation type shall be used only when
the Complex_product and the Product_constituent are of different types ;
EXAMPLE The Product_component 'braking system' may be considered as a means to realize the
Product_function 'braking'.
'specialization': The related Product_constituent fulfils the requirements of the relating
Complex_product in a more specific way than defined for the relating Complex_product. This relation
type shall only be used for Product_constituent and Complex_product of the same type.
7.17.5 ARM-AIM Mapping Product_structure_relationship
product_structure_relationship
product_structure_relationship.relating
product_definition
product_definition_relationship.related_product_definition ->
product_definition
product_definition_relationship.name=‘decomposition‘
product_structure_relationship.related
product_structure_relationship.relation_type
Page 48 of 75
7.18
Quantified_instance
This object was applied to represent a part occurrence in a BoM for which the quantity of the
occurrence is important.
EXAMPLE In a Technical_solution for the front left brake a certain screw is used four times.
There are no special recommendations given related to the application of this entity. With this object
parts can not be positioned.
A Quantified_instance is a type of Item_instance.
The data associated with a Quantified_instance are the following:
•
quantity
7.18.1 quantity
The quantity specifies a value and a unit specifying the quantity of occurrences.
If the quantity can not be expressed as a particular value, the concept of Selected_instance shall be
used instead to represent this instance.
NOTE The quantity may be specified as a count measure, as a mass measure, as a length measure,
as an area measure, or as a volume measure.
See Quantified_instance to Nominal_value for the application assertion.
7.18.2 ARM-AIM Mapping Quantified_instance
quantified_instance
[product_definition.frame_of_reference ->
product_definition_context.name=‘part occurrence‘]
[product_definition <name_attribute.named_item
(Create Entity) name_attribute
name_attribute.attribute_value='quantified instance']
product_definition.id
{product_definition_relationship.name='definition usage‘}
product_definition
product_definition <property_definition.definition
(Create Entity) property_definition <{property_definition.description=‘occurrence quantity‘}
property_definition_representation.definition
(Create Entity) property_definition_representation
property_definition_representation.used_representation ->
(Create Entity) representation
{representation.name='quantity'}
representation.items[i] ->
measure_representation_item
measure_representation_item.name = 'quantity measure'
quantified_instance.id
quantified_instance.definition
quantified_instance.quantity
Page 49 of 75
7.19
Single_instance
This object can be applied to represent a single occurrence of a part in a BoM.
NOTE A Single_instance may or may not be associated with placement information using an
Instance_placement.
EXAMPLE In a Technical_solution for the 'front left brake' a 'brake disk' is used and its position is
specified by a geometric Transformation.
A Single_instance is a type of Item_instance.
7.19.1 ARM-AIM Mapping Single_instance
single_instance
[product_definition.frame_of_reference ->
product_definition_context.name=‘part occurrence‘]
[product_definition <name_attribute.named_item
name_attribute.attribute_value='single instance']
product_definition.id
{product_definition_relationship.name='definition usage‘}
product_definition
single_instance.id
single_instance.definition
7.20
Selected_instance
A Selected_instance is the instance of an Item whose quantity depends on certain constraints.
This entity was not used in the project group examples, therefore no special recommendations can
be given.
EXAMPLE In a BOM where the exact amount of grease or glue can usually not be specified as a
quantity, the specification of this grease or glue are examples for Selected_instance objects.
EXAMPLE To minimize the concentricity error of a wheel, weights are attached to the rim; this set of
weights is a Selected_instance.
The quantity as well as the position of these weights depends on the concentricity behaviour of each
particular wheel as manufactured and tested.
A Selected_instance is a type of Item_instance.
The data associated with a Selected_instance are the following:
•
selected_quantity;
•
selection_control.
7.20.1 selected_quantity
The selected_quantity
Selected_instance.
specifies
the
number
of
occurrences
of
instances
foreseen
as
Page 50 of 75
NOTE If the quantity is to be specified as a minimum and/or a maximum, then Value_limit or
Value_range may be used
See Selected_instance to Value_with_unit for the application assertion.
7.20.2 selection_control
The selection_control specifies the constraint that has to be evaluated for the Selected_instance.
EXAMPLE 'as required for balance' and 'as required for lubrication' are examples for a
selection_control.
7.20.3 ARM-AIM Mapping Selected_instance
Selected_instance
product_defintion
7.21
Specification
This entity was applied in the project group examples to represent characteristics of product classes
and the smallest building blocks of rules, feature groups and packages. With respect to its application
no special recommendations need to be made.
NOTE A Specification may be a characteristic of the members of more than one Product_class using
Class_specification_association objects.
NOTE A Specification in combination with a Configuration may be used to define under which
conditions an Item is used for a product of a Product_class.
The data associated with a Specification are the following:
•
category;
•
description;
•
id;
•
name;
•
package;
•
version_id.
7.21.1 category
The category specifies the Specification_category that completes the semantics of the Specification.
See Specification to Specification_category for the application assertion.
In
case
no
specification_category
exists
in
the
native
system
specification_category.id=´/NULL´ could be instantiated to which all specifications point.
one
with
7.21.2 description
The description specifies additional information about the Specification.
Page 51 of 75
See Specification to Multi_language_string for the application assertion.
The description need not be specified for a particular Specification.
If present, there shall be exactly one object that defines the description for a Specification.
7.21.3 id
The id specifies the identifier of the Specification that shall be unique within the scope of a
Specification_category.
7.21.4 name
The name specifies the word or group of words by which the Specification is referred to.
See Specification to Multi_language_string for the application assertion.
The name need not be specified for a particular Specification.
If present, there shall be exactly one object that defines the name for a Specification.
7.21.5 package
The package specifies whether this Specification represents a package of Specification objects or
not. Such a Specification combines those Specification objects that shall be offered to the market as a
set. In the case where package is 'true', there shall be exactly one Specification_inclusion per
Product_class considered, that refers to this Specification as if_condition. The Specification objects
that are members of the package, shall be specified as included_specification.
NOTE Commercial packages may be defined by the marketing department.
NOTE Usually the members of a package belong to distinct Specification_category objects.
EXAMPLE A sports package contains sports seats, a special steering wheel, special tyres and
wheels. A winter package contains heated front seats, heated windshield washers, heated exterior
mirrors, and special tyres.
7.21.6 version_id
The version_id specifies the identification of a particular version of a Specification.
The version_id need not be specified for a particular Specification.
7.21.7 ARM-AIM Specification
specification
specification.id
specification.category
(Create Entity) product_concept_feature
product_concept_feature.id
product_concept_feature <applied_group_assignment.items[1]
(Create Entity) applied_group_assignment <{role_association.item_with_role
object_role.name = ‚specification category member‘}
applied_group_assignment.assigned_group ->
product_concept_feature_category
if specification.package=‘true‘ specification maps to
package_product_concept_feature, other wise see above
product_concept_feature.name
specification.package
specification.name
Page 52 of 75
7.22
Specification_category
Within the project group this entity was applied to represent groups of specifications. These groups
collect characteristics of a product class from which one (mutually exclusive) or more can be chosen.
Usually these groups of specifications collect characteristics of the same kind, e.g. engines, color or
special equipment.
With respect to its application no additional recommendations need to be made. Feature groups are
not always supported by BoM systems. E.g. Rule based systems sometimes can not manage this
type of data. Very often feature groups are combined with rules.
If this entity is applied, it must be understood and agreed if and how the receiving system will
understand these objects and a data loss can be avoided. Further investigations for a general
solution need to be made. For additional examples see chapter 8.
The data associated with a Specification_category are the following:
•
description;
•
id;
•
implicit_exclusive_condition.
7.22.1 description
The description specifies information about the Specification_category.
EXAMPLE The description 'trim' characterizes a Specification_category for Specification objects that
controls the quality and colour of the interior parts including e.g., inner door panels and upholstery.
Other examples are 'kind of drive', 'rear brake type', 'brake power regulator', 'radio equipment', or
'type of car body'.
See Specification_category to Multi_language_string for the application assertion.
There shall be exactly one object that defines the description for a Specification_category.
7.22.2 id
The id specifies the identifier of the Specification_category that shall be unique.
NOTE The scope of uniqueness is usually dependent on the form of implementation; it may be e.g., a
physical file or a data base.
7.22.3 implicit_exclusive_condition
The implicit_exclusive_condition specifies whether the Specification objects within the
Specification_category are mutually exclusive for the production of one particular product. A value of
'true' indicates that the referenced objects are mutually exclusive for the production of the particular
product.
EXAMPLE 'safety equipment' is an example for a non mutually exclusive Specification_category if
e.g. ABS and airbag are Specification objects in this category. 'engine' is an example for a
Specification_category with an implicit_exclusive_condition since usually only one engine can be
mounted for power supply.
NOTE More complex conditions can be handled using Specification_expression objects.
Page 53 of 75
7.22.4 ARM-AIM Specification_category
specification_category
specification_category.id
specification_category.description
specification_category.implicit_exclusion_conditi
on
(Create Entity) product_concept_feature_category
product_concept_feature_category.group.name
product_concept_feature_category.group.description
if specification_category.implicit_exclusion_condition=‘true‘
specification_category maps to
exclusive_product_concept_feature_category
7.23
Specification_category_hierarchy
A Specification_category_hierarchy
Specification_category objects.
is
used
to
build
up
hierarchical
structures
of
The data associated with a Specification_category_hierarchy are the following:
•
sub_category;
•
super_category.
7.23.1 sub_category
The sub_category is the lower level of Specification_category in Specification_category_hierarchy.
7.23.2 super_category
The super_category is the higher level of Specification_category in Specification_category_hierarchy.
7.23.3 ARM-AIM Specification_category_hierarchy
specification_category_hierarchy
(Create Entity) group_relationship
{group_relationship.name = ‘specification category hierarchy’}
group_relationship
group_relationship.related_group ->
(if specification_category.implicit_exclusion_condition is FALSE:
product_concept_feature_category)
(if specification_category.implicit_exclusion_condition is TRUE:
exclusive_product_concept_feature_category)
group_relationship
group_relationship.relating_group ->
(if specification_category.implicit_exclusion_condition is FALSE:
product_concept_feature_category)
(if specification_category.implicit_exclusion_condition is TRUE:
exclusive_product_concept_feature_category)
specification_category_hierarchy.
sub_category
specification_category_hierarchy.
super_category
7.24
This object was applied to build rules based on product class characteristics. The rules are based on
these characteristics and Boolean operations. This concept can be understood by mainly all BoM
systems (except for purely feature based systems). As this concept is understandable to most BoM
systems it should be tried to translate specification control mechanisms into Boolean expressions, if
possible.
No further special recommendations to AP 214 need to be given for the application of this object.
The data associated with a Specification_expression are the following:
Page 54 of 75
•
description;
•
id;
•
operand;
•
operation.
7.24.1 description
The description specifies additional information about the Specification_expression.
See Specification_expression to Multi_language_string for the application assertion.
The description need not be specified for a particular Specification_expression.
If present, there shall
Specification_expression.
be
exactly
one
object
that
defines
the
description
for
a
7.24.2 id
The id specifies the identifier of the Specification_expression.
The id need not be specified for a particular Specification_expression.
7.24.3 operand
The operand specifies the operands of the Boolean operation that are either Specification objects or
other Specification_expression objects.
See
to
Specification
Specification_expression for the application assertions.
and
to
There shall be at least one object that defines the operand for a Specification_expression.
7.24.4 operation
The operation specifies the kind of Boolean operation. Four kinds of operations are permitted:
'and': All of the identified Specification objects shall be used;
'or': A subset or all of the identified Specification objects shall be used;
'oneof': Exactly one of the identified Specification objects shall be used;
'not': The identified Specification shall not be used.
7.24.5 ARM-AIM Specification_expression
specification_expression
(Create Entity) conditional_concept_feature
conditional_concept_feature.condition ->
(Create Entity) concept_feature_relationship_with_condition
concept_feature_relationship_with_condition.conditional_operator ->
(Create Entity) concept_feature_operator
conditional_concept_feature
concept_feature_relationship_with_condition
concept_feature_relationship_with_condition.conditional_operator ->
concept feature operator
specification_expression.operation
Page 55 of 75
specification_expression.operand[1]
specification_expression.operand[2]
7.25
concept_feature_operator.name=‘and‘
concept_feature_relationship_with_condition
concept_feature_relationship.relating_product_concept_feature ->
...
Specification_inclusion
This object can be used to represent the package objects in BoM systems. The package mechanism
includes to a specification other specifications automatically. This can be for technical (e.g. air
condition includes bigger battery) or marketing reasons (e.g. sports package, special model
equipment).
The application and exchange of this object implies that the receiving system supports the package
approach. If this is not the case there is the danger of loosing the package information. With respect
to its application no further recommendations to AP 214 are given by the project group.
NOTE The Specification_inclusion is intended to complete the set of Specification objects for a
Product_specification in order to enable the manufacturing of the product on the basis of an initial set
of Specification objects defined e.g., by a customer order.
The data associated with a Specification_inclusion are the following:
•
description;
•
id;
•
if_condition;
•
included_specification.
7.25.1 description
The description specifies additional information about the Specification_inclusion.
See Specification_inclusion to Multi_language_string for the application assertion.
The description need not be specified for a particular Specification_inclusion.
If present, there shall be exactly one object that defines the description for a Specification_inclusion.
7.25.2 id
The id specifies the identifier of the Specification_inclusion. The id need not be specified for a
particular Specification_inclusion.
7.25.3 if_condition
The if_condition specifies the Specification or the Specification_expression that serves as the
condition for the inclusion.
See Specification_inclusion to Specification and Specification_inclusion to Specification_expression
Page 56 of 75
There shall be exactly one object that defines the if_condition for a Specification_inclusion.
7.25.4 included_specification
The included_specification specifies the Specification or the Specification_expression objects that are
to be included.
NOTE In the case where the included_specification is a Specification_expression that is, e.g., an OR
expression, there may be several alternatives for Specification objects being included.
NOTE In the case where more than one Specification is to be included a Specification_expression of
type AND shall be used.
NOTE In the case where the included_specification is a NOT expression, the object actually defines
an exclusion.
See Specification_inclusion to Specification and Specification_inclusion to Specification_expression
There shall be exactly one object that defines the included_specification for a Specification_inclusion.
The following figure shows an example: If the special package “Winter package” is chosen, the
special option “Seat heating” is automatically included, too.
level = 'product family'
id = 'Middle Clas s Cars'
product_class
c_c_a
c_s_a
speci fication_
category
specificati on
package
= 'TRUE'
name = 'Winter
package'
id = 'SPEC977'
'Special packages '
c_i_a
i f_condition
specification_
incl usi on
i ncluded_
speci fication
c_c_a
c_s_a
specifi cati on_
category
specifi cati on
package
= 'FALSE'
name = 'Seat heating'
id = 'SPEC012'
'Special options'
Figure 7.5: Example for a specification_inclusion (simplified, for abbreviations see section 8)
7.25.5 ARM-AIM Specification_inclusion
Specification_inclusion
(Create entity) inclusion_product_concept_feature <=
Page 57 of 75
Specification_inclusion.description
inclusion_product_concept_feature <=
conditional_concept_feature <=
product_concept_feature
product_concept_feature.description
Specification_inclusion.id
inclusion_product_concept_feature <=
conditional_concept_feature <=
product_concept_feature
product_concept_feature.id
Specification_inclusion.if_condition; (->
conditional_concept_feature (Supertype of inclusion_product_concept_feature)
specification, with specification.package = ´true´) conditional_concept_feature.condition ->
concept_feature_relationship_with_condition <=
concept_feature_relationship
(|product_concept_feature|)
(product_concept_feature =>
package_product_concept_feature)
Specification_inclusion.if_condition; (->
conditional_concept_feature (Supertype of inclusion_product_concept_feature)
specification_expression)
{concept_feature_relationship_with_condition
->
concept_feature_operator
concept_feature_operator.name = 'implication'}
|conditional_concept_feature|
Specification_inclusion.included_specification (- conditional_concept_feature (Supertype of inclusion_product_concept_feature)
> specification)
concept_feature_relationship_with_condition <=
(|product_concept_feature|)
(product_concept_feature =>
package_product_concept_feature)
Specification_inclusion.included_specification (- conditional_concept_feature (Supertype of inclusion_product_concept_feature)
> specification_expression)
|conditional_concept_feature|
7.26
Technical_solution
Within the project group’s examples this object was used to represent different technical approaches,
how a product component can be realized. In many cases the entity also marked the interconnection
between variant and non-variant product structure, but this is not always the case.
The project group agreed to recommend the application of this entity to be attached to the "leaf" of a
product component tree. See Figure below:
Page 58 of 75
Product_
component 1
Product_
Product_
Front Brake
component 2.2
component 2.1
Product_
component 3.1
Brake Disc
Technical_
solution 1
Product_
...
component 3.2
Brake Disc
16 inch
Abstract
Product
Structure
Front axle
Technical_
solution 2
Axle Assembly
Product_
...
component 3.3
Brake Disc
14 inch
Assembly
Structure
Figure 7.6: Interconnection of Abstract Product Structure and Assembly Structure by the
Technical_solution entity
There are no further recommendations to AP 214 by the project group for the application of this
entity.
A Technical_solution is a type of Alternative_solution.
The data associated with a Technical_solution are the following:
•
description
7.26.1 description
The description specifies additional information about the Technical_solution.
See Technical_solution to Multi_language_string for the application assertion.
There shall be exactly one object that defines the description for a Technical_solution.
7.26.2 ARM-AIM Technical_solution
technical_solution
(Create Entity) product_definition <name_attribute.named_item
name_attribute.attribute_value=‘technical‘
[product_definition
product_definition_context.application_context_element.name = ‚alternative
definition‘]
product_definition
(Create Entity) product_definition_formation
product.id
{product_definition_relationship.name = 'solution alternative definition‘}
product_definition
technical_solution.id
technical_solution.base_element
Page 59 of 75
7.27
Work management and effectivity entities
Within the project group the field of work management information and it’s association to product
structure and specification control information was discussed in a first approach. This approach
covers the limited scope of the association of work definition and effectivity information. This
recommendation is compatible to the appropriate recommendations of the PDM Usage Guide and is
an extension to it. The described entities in this chapter only represent that portion of all necessary
entities recommended in the PDM Usage Guide, which is directly related to the extensions.
The project group identified the application that the time-related effectivity of product structure
elements can be defined by the occurrence of certain events. These events are defined by certain
activities as parts of work management information (e.g. work orders, change orders).
To represent this in AP214 the following entities are used (according to the figure below):
• Activity:
An activity represents the work that is controlled by a work order, and defined as part of a work
order (see PDM Usage Guide). This is a definition of work that has either taken place, is taking
place, or is expected to take place in the future. As part of a complete set of entities to describe
specific work management information activities are associated to product structure elements via
activity_elements. In the context described here an activity represents in parallel an event that
influences the effectivity of an element in a product structure.
• Effectivity:
The effectivity entity supports the specification of a domain of applicability of product data.
Effectivity is a generic concept defining the valid use of the product data the effectivity is assigned
to. The effectivity entity specifies the start point and the end point of a period within which the
assigned element is effective (effectivity_indication = TRUE) or not effective
(effectivity_indication = FALSE).
• Event_reference:
The event_reference entity serves as the link between the effectivity entity and the two activity
entities that define the start point (start event) and end point (end event) of the appropriate
effective (or non-effective) period.
Page 60 of 75
id='ACT056'
activity
actual_start_date=08.11.99
id='ACT001'
activity
actual_start_date=01.10.99
id='ACT_START'
activity_
element
activity_
element
role='input'
role='output'
Scope of elements
BOOLEAN
event_type=
'actual start date'
event_type=
'actual start date'
effectivity_
indication = .TRUE.
effectivity_
assignment
role='actual'
event_
reference
end
start
effectivity
event_
reference
Figure 7.7: Interconnection of activity and effectivity entities through event_reference
In the project group’s example the scope of affected elements comprised the following entities:
product_class, product_function, product_component, product_structure_relationship, specification,
technical_solution, item_version, next_higher_assembly.
8
Summary
Due to the general importance of the topic configuration control the related STEP objects and models
can be applied in different scenarios: E.g. for Data exchange or as basic data models for
implementations. Today these data classes are already involved in the following processes:
•
The exchange of PC and BoM information is often the basis for communication of changes
between manufacturer and supplier who develop products simultaneously.
•
During the design phase PC is applied to document the variants of a product systematically.
•
Product Coding information is essential to document individual customer orders (Why is a
product build as it is? Which parts are why there?).
•
PC / BoM Systems interconnect the PDM and the ERP world. They interpret the design of a
product into a production order.
•
PC / BoM Systems create basic data for a number of down stream systems, e.g. procurement,
material planning, work planning etc.
But there are also a number of obstacles and open points with respect to the application and
exchange of STEP in these technical domain.
The simple representation of system data models do not apply due to the fact that different
companies use different STEP objects in different manners and to the involved semantic of
exchanged data, which is usually not the same (e.g. Product Classes in different companies)
Page 61 of 75
In order to exchange Product Coding / BoM data an agreement about a common reference model
and its application must be achieved. This document is a first approach to do so. Further Test
Scenarios must be defined and tried out, to come to a better understanding especially related to
implementation topics.
Product Coding Systems are productive systems upon which a number of down stream systems
depend. Therefore they are highly sensitive, communication on detail level is complicated. STEP
based representations of PC / BoM information can be fundamental for discussions on a neutral basis
with system vendors in the sensitive field requirements for standard PC / BoM solutions.
STEP based representations of PC / BoM information can also be a key to connect PDM with a
number of down-stream applications (such as ERP), a task which is currently in practice not solved.
As a matter of facts today there are a number of different product structures which are managed
along the product life cycle. A full life time support of one kernel product structure will involve the
realisation of functionality and data classes as described in this document.
And neutral representation of PC / BoM information can also be an essential module to describe
products for new technical applications (e.g. e-commerce, virtual enterprise etc.) as it describes the
back-ground of product characteristics.
9
Examples
The shown examples are simplified representations, what means, that not the complete set of
attributes and attribute names of the entities according to AP 214 are shown. For a complete
instantiation see the corresponding entity descriptions in section 6.
The following abbreviations for entity names are used:
p_s_r
: product_structure_relationship
p_c_r
: product_class_relationship
c_s_r
: class_structure_relationship
c_s_a
: class_specification_association
c_c_a
: class_condition_association
c_cat_a : class_category_association
c_i_a
: class_inclusion_association
ddid
: design_discipline_item_definition
9.1
Representations of variants
The following figures show ways for the representation of different types of variants (see also chapter
“Glossary”).
Page 62 of 75
a) Variants as product classes:
level='enterprise'
p_c_r
level='platform'
p_c_r
Enterprise XYZ'
product_class
'hierarchy'
'Middle Class Cars'
product_class
'hierarchy'
p_c_r
'hierarchy'
p_c_r
'hierarchy'
Variants of product class
„Middle Class Cars“
level=
'product family'
product_class
level=
'product family'
'Middle Class Cars,
Product Line SPORT'
product_class
level=
'product family'
'Middle Class Cars,
Product Line FAMILY'
product_class
'Middle Class Cars,
Product Line FUN CARS'
Fig. 9.1: Variants as product classes
b) Variants as product components (complete vehicles):
product_class
p_c_r
'hierarchy'
product_class
p_c_r
'realization'
product_component
'Complete vehicle:
2.0 Liter Limous ine'
c_s_r
'Middle Clas s Cars '
'hierarchy'
product_class
c_s_r
Enterprise XYZ'
'Middle Class Cars,
Limousine'
'realization'
product_component
'Complete vehicle:
3.0 Liter Limousine'
c_s_r
'realization'
product_component
'Com plete vehicle:
3.5 Liter Lim ousine'
Vehicle variants of product class „Middle Class Cars, 2.0L Engine“
Fig. 9.2: Variants as product components (complete vehicles)
Page 63 of 75
c) Variants as technical solutions and supplier solutions:
product_component
1
= Configuration information 1
p_s_r
'decomposition'
product_component
p_s_r
Variants of
product component
„brake cylinder“
1
Variants of
„brake cylinder,
single“
4
technical_solution
6
5
'brake cylinder,
single'
'complete vehicle'
'rear axle module'
'decomposition'
product_component
'brake cylinder'
technical_solution
'brake cylinder,
double'
2
3
...
supplier_solution
supplier_solution
supplier_solution
...
supplier_solution
...
supplier_solution
...
'brake cylinder,
special'
technical_solution
supplier_solution
...
...
supplier_solution
supplier_solution
supplier_solution
Fig. 9.3: Variants as technical solutions and supplier solutions
9.2
Feature groups and features
Definitions:
A Specification defines a characteristic of a class of products. It also can be a statement, which is
used to build rules, feature groups (specification_categories) or packages.
A Specification_category (feature group) is the definition of a set of Specification objects serving the
same purpose. This entity is used to represent feature groups. A feature group is a set of product
characteristics which can be applied to solve the same technical purpose, e.g. set of engines, colours
etc. Sometimes the characteristics within a feature group can be mutually exclusive to each other.
Often feature groups are applied in combination with rules and specification_inclusions.
The example shown in the figure means:
•
Product class „Personal cars“ includes a product component „PC-0000“, which is a complete
vehicle.
•
Product class „Personal cars“ includes the specification categories „Engine”, “Type“ and „No. of
Cylinders“.
•
The „implicit_exclusive_condition“ attributes of the specification categories are set to „TRUE“,
that means, the included specifications are mutually exclusive.
•
Product class „Personal cars“ includes 2 specific „AND“-rules.
•
The product component „P-1000“ (which is called „Engine“) can be realized using one of two
possible engine variants:
•
Engine „EN-123.77“ is used if the engine type is selected to „In-line engine“ and the number
of cylinders is selected to „4“
Page 64 of 75
•
Engine „EN-563.02“ is used if the engine type is selected to „V-engine“ and the number of
cylinders is selected to „8“
Abstract
Product structure
Personal car
PC-0000
Power train
P-0000
Body
B-0000
Interior
I-0000
Product class
„Personal cars“
„Engine“
Spec_cat_
hierarchy
Gear box
P-2000
...
Engine
P-1000
„Type“
„In-line engine“
EN-123.77
Technical
Solutions
EN-563.02
Configuration
#1
Configuration
#2
AND
implicit_exclusive_condition
=TRUE
AND
Configuration : Configuration information
„V-Motor“
AND
„Type“
„V-engine“
Spec_cat_
hierarchy
„No. of Cylinders“
4
6
: Specification („Feature“)
: Boolean operator
8
implicit_exclusive_condition
=TRUE
: Specification category („Feature group“)
(Remark: This is a simplified figure which does not contain AP214 compliant entities.)
Fig. 9.4: Specification information
9.3
Product structure of product class level 3
This example is assigned to exchange scenario 1. The figure shows an instantiation example with the
following characteristics:
•
All variants (alternative_solutions) of all product_components of the product class „MC-L“ are
included.
•
The maximum number of components of the complete vehicle identified by “MCL-STD” is
included.
•
All relevant configuration information is included to allow the evaluation of the product structure
to a valid BoM of a manufacturable product.
•
The example shows that the product_component “MCL-STD” consists of the
product_components “interior”, “chassis” and “engine”. Interior and chassis are further
decomposed into product_components. The engine can be realised by the two variants “diesel
engine” and “petrol engine”. The two specifications “ENG001” and “ENG002” are each associated
to product class “MC-L” by a class_specification_association with association_type=’part usage’,
which specify the valid usage of the two technical_solutions. (Remark: specification_categories
are not shown in the figure).
Page 65 of 75
level = 'enterprise'
id = 'STEP-Cars'
produc t_cl ass
'hierarchy'
p_c_r
level = 'platform'
['technical_documentation']
id = 'MC'
produc t_cl ass
'hierarchy'
p_c_r
id = 'MC-L'
produc t_cl ass
'realization'
c _s_r
product_component
p_s _r
id = 'MCL-STD'
description = 'Middle Class Limousine'
'decomposition'
product_component
'interior'
p_s _r
further
components...
p_s_r
p_s_r
'decomposition'
association_type=
'part usage'
c _s_a
product_component
'chassis'
name = 'DIESEL'
s pec ific ation id = 'ENG001'
p_s_r
further
c omponents ...
p_s_r
p_s_r
'decomposition'
product_component
c onfi guration
'engine'
technical_s olution
'diesel engine'
association_type=
'part usage'
c_s_a
spec ification
c onfiguration
technical _soluti on
'petrol engine'
name = 'PETROL'
id = 'ENG002'
Fig. 9.5: Example for a product structure
9.4
Abstract product structure – technical solution – part identification data
This example is assigned to exchange scenario 1. The figure shows an instantiation example with
•
A vehicle contains a rear axle module.
•
The rear axle module contains a brake cylinder.
Page 66 of 75
•
The brake cylinder component can be realized by a technical solution ‘brake cylinder, double’,
depending on an appropriate configuration.
•
The ‘brake cylinder, double’ is physically realized by a part called “Double Brake Cylinder” with
part id “BCD30986A”. This part occurs as a single instance with id “NO_123” in the BoM.
product_component
p_s_r
'decomposition'
product_component
p_s_r
technical_solution
single_instance
ddid
'rear axle module'
'decomposition'
product_component
p_s_r
name = 'complete vehicle'
id = 'HDT 123.456'
'brake cylinder'
'brake cylinder, double'
'realization'
id = 'NO_123'
item_
version
item
id = 'BCD30986A'
name = 'Double Brake Cylinder'
Fig. 9.6: Example for technical solutions and item data
9.5
Abstract product structure – products of different product classes
•
Enterprise “STEP-Products” provides 2 main product platforms: trucks and engines.
•
A complete truck of product family “Standard Trucks” includes an engine of product family
“Mobile Engines”.
Page 67 of 75
level = 'enterprise'
id = 'STEP-Products'
product_class
p_c_r
'hierarchy'
level = 'platform'
id = 'Trucks'
product_class
p_c_r
p_c_r
id = 'Standard Trucks'
c_s_r
'relating'
id = 'TR-ST-100'
description = 'Standard truck'
level = 'platform'
id = 'Engines'
'hierarchy'
id = 'Mobile Engines'
product_class
'realization'
product_component
'hierarchy'
product_class
'hierarchy'
product_class
c_s_r
p_c_r
'realization'
'related'
p_s_r
'decomposition'
product_component
id = 'EN-MO-890'
description = 'Mobile engine'
Fig. 9.7: Example for different product classes and components
9.6
Abstract product structure of a furthest pre-configured abstract product class
•
A complete BoM for the product type “HDT123.987” is given. The product structure had already
been evaluated against:
-
all specifications associated to the product class by class_specification_association objects
with attribute association_type of one of the values ‘replaceable standard’, ‘non replaceable
standard’ or ‘identification’ and
-
all specification_expressions associated to the product class by class_condition_association
objects with attribute condition_type of the value ‘identification’.
•
Only configuration information for special options or customer choices are included, which still
have to be evaluated to get the BoM of a manufacturable product.
•
Only product_components and technical_solutions valid for this pre-configured BoM are included.
•
The BoM was evaluated using the specifications “SPEC980”, “SPEC730” and “SPEC554”.
•
Additionally, the load options can still be chosen to “SPEC349”, name “standard load” (which is
the default option) or to “SPEC106”, name “extra load”. Depending on the choice the technical
solution “brake cylinder, double” or “brake cylinder, single” is identified as the valid variant for
product component “brake cylinder” within this specific furthest pre-configured product class for
the BoM of a manufacturable product. (Remark: Not all specification_categories are shown in the
figure).
Page 68 of 75
id = 'SPEC980'
id = 'SPEC730'
id = 'SPEC554'
spec ification
s pecification
specification
association_type=
'identification'
association_type=
'identification'
c_s_a
c_s_a
association_type=
'non replaceable standard'
level = 'furthest preconfigured
abstract product class'
id = 'HDT 123.456'
product_class
c_c at_a
association_type=
'part usage'
c_s_r
produc t_c omponent
name = 'extra load'
id = 'SPEC106'
id = 'load options'
association_type=
'part usage'
'realization'
c_s_a
specification
specification_
c ategory
c_s _a
p_s_r
name = 'complete truck'
id = 'HDT 123.456'
'decomposition'
produc t_c omponent
c_s_a
p_s_r
'rear axle module'
'decomposition'
spec ification
name = 'standard load'
id = 'SPEC349'
produc t_c omponent
'brake cylinder'
technical_solution
'brake cylinder,
double'
configuration
configuration_type=
'usage'
inheritance_type=
'local'
technical_solution
'brake cylinder,
single'
configuration
configuration_type=
'usage'
inheritance_type=
'local'
Fig. 9.8: Example for a product structure
9.7
Functional view – product_function
This example shows a functional view on product components in a product component tree. The
verbal description is the following:
•
A vehicle includes the product components “chassis” and “engine”.
•
The chassis includes the product component “brake cylinder”.
•
The “engine” includes the product component “exhaust brake”.
•
The two product components “brake cylinder” and “exhaust brake” are considered to realize the
product function “braking”.
Page 69 of 75
level = 'furthest
preconfigured
abstract product product_class
class'
id = 'HDT 123.456'
'realization'
c_s_r
'decomposition'
p_s_r
product_
component
p_s_r
product_component
product_
component
'decomposition'
p_s_r
'brake cylinder'
related
p_s_r
'decomposition'
p_s_r
'chassis'
product_
component
nam e = 'complete truck'
id = 'HDT 123.456'
'engine'
'decomposition'
product_
component
'exhaust brake'
related
p_s_r
'realization'
relating
'realization'
relating
product_
function
'braking'
Fig. 9.9: Example for a functional view
9.8
Specifications and configuration information
The examples in this chapter show the principle application of specifications, specification categories,
specification expressions and configuration objects and their association to product classes. They all
apply to exchange scenario 1. Besides, two general concepts of product coding, feature-based and
rule-based, are applied to main specification control constructs of AP214. In general, mixtures of
those concepts occur in practice.
To increase a clear arrangement of the diagrams the AP214 entities and links are shown in a
symbolic way. For the correct complete instantiation of these entities see the corresponding sections
under chapter 6.
Product_structure_relationship and class_structure_relationship entities are not shown in the
diagrams.
The link to item_instance, ddid, item_version and item instances below each technical_solution entity
(see example under 8.4) are not shown in the diagrams.
The following abbrevations and symbols are used:
A:
represents a class_category_association entity
S:
represents a class_specification_association entity
C:
represents a class_condition_association entity
spec_cat:
represents a specification_category entity
Page 70 of 75
spec:
represents a specification entity
spec_expr: represents a specification_expression entity
tech_sol:
represents a technical_solution entity
prod_comp: represents a product_component entity
conf:
represents a configuration entity
------:
dotted line: link to be continued to the product_class entity
9.8.1
"Pure" feature-based approach, no configuration information included
This example refers to exchange scenario 1, information extend types (a) and (b), and has the
(a) "Maximum BoM" including information about general availability of specifications:
•
To all spec_cat entities applies:
specification_category.implicit_exclusive_condition = TRUE
(This means, that the usage of exactly one specification out of each specification category is
mandatory.)
•
To all class_category_assocation entities (A) applies:
class_category_assocation.mandatory = TRUE
•
To all class_specification_assocation entities (S) applies:
class_specification_association.association_type = 'availability'
(b) "Maximum BoM" including specific information about the types of specifications:
•
•
•
To each 1 class_specification_association entity (S) in spec_cat 1 and spec_cat 3 applies:
class_specification_association.association_type = 'replaceable standard'
•
To the other class_specification_association entities (S) within the same specification
category applies:
class_specification_association.association_type = 'option'
•
To the class_specification_association entity (S) in spec_cat 2 applies:
class_specification_association.association_type = 'identification' or 'non replaceable
standard'
Page 71 of 75
product_c las s
A
prod_
c omp
S
s pec _
c at 1
S
s pec
A
s pec
s pec _
c at 2
tec h_
s ol 1
tech_
s ol 2
tec h_
s ol 3
S
tec h_
s ol 4
spec
tec h_
s ol 5
A
s pec _
c at 3
tec h_
s ol 6
S
spec
S
tec h_
s ol 7
s pec
tec h_
s ol 8
prod_
comp
prod_
c omp
prod_
c omp
prod_
c omp
prod_
c omp
prod_
comp
Fig. 9.10: Example overview about specification data objects (feature-based)
9.8.2
"Pure" feature-based approach, configuration information included
This example refers to exchange scenario 1, information extend type (c), and has the following
characteristics:
(c) "Maximum BoM" including configuration information for the valid usage of product_components
or technical_solutions:
•
•
•
To all class_specification_association entities (S) applies:
class_specification_association.association_type = 'part usage'
•
To all configuration entities applies:
configuration.configuration_type = 'usage'
Page 72 of 75
product_class
prod_
comp
prod_
comp
A
spec_
cat 1
conf
S
S
conf
tech_
sol 2
conf
tech_
sol 3
spec
spec
A
spec_
cat 3
S
spec
tech_
sol 1
conf
tech_
sol 4
conf
tech_
sol 5
conf
tech_
sol 6
conf
tech_
sol 7
S
spec
conf
tech_
sol 8
prod_
comp
prod_
comp
prod_
comp
prod_
comp
prod_
comp
Fig. 9.11: Example overview about specification data objects (feature-based)
9.8.3
"Pure" rule-based approach, no configuration information included
This example refers to exchange scenario 1, information extend types (a) and (b), and has the
(a) "Maximum BoM" including information about general availability of specifications:
•
To the spec_cat X entity applies:
specification_category.id = '/NULL'
(This is a dummy instance assuming that in a pure rule-based system no specification
categories are managed.)
specification_category.implicit_exclusive_condition = FALSE
•
To the class_category_assocation entity (A) applies:
class_category_assocation.mandatory = TRUE or FALSE
•
class_specification_association.association_type = 'availability'
•
To all class_condition_assocation entities (C) applies:
class_condition_assocation.condition_type = 'identification' or 'validity' or 'design case'
(b) "Maximum BoM" including specific information about the types of specifications:
•
Page 73 of 75
•
•
To all class_specification_association entities (S) applies:
class_specification_association.association_type = 'replaceable standard' or 'non replaceable
standard' or 'option' or 'identification' (under consideration of the value of the attribute
implicit_exclusive_condition of the appropriate specification_category)
•
For all class_condition_assocation entities (C) applies:
class_condition_assocation.condition_type = 'identification' or 'validity' or 'design case'
produc t_clas s
prod_
c omp
S
C
S
s pec _
exp
s pec
A
s pec
tech_
sol 2
C
spec _
cat X
S
S
tec h_
sol 1
s pec _
exp
s pec
tech_
sol 3
tech_
sol 4
prod_
c omp
prod_
c omp
prod_
comp
prod_
comp
spec
tec h_
s ol 5
C
S
s pec
S
spec
s pec_
ex p
tec h_
sol 6
tec h_
sol 7
tech_
sol 8
prod_
c omp
prod_
comp
Fig. 9.12: Example overview about specification data objects (rule-based)
9.8.4
"Pure" rule-based approach, configuration information included
This example refers to exchange scenario 1, information extend type (c), and has the following
characteristics:
(c) "Maximum BoM" including configuration information for the valid usage of product_components
or technical_solutions:
•
Page 74 of 75
•
•
class_specification_association.association_type = 'availability' or 'replaceable standard' or
'non replaceable standard' or 'option' or 'identification' (under consideration of the value of the
attribute implicit_exclusive_condition of the appropriate specification_category)
•
To all class_condition_assocation entities (C) applies:
class_condition_assocation.condition_type = 'part usage'
•
To spec_expr N applies:
specification_expression.operand[1] = 'not'
•
To all configuration entities applies:
configuration.configuration_type = 'usage'
product_c las s
prod_
c omp
S
C
S
s pec_
ex p
s pec
A
s pec
C
s pec _
c at X
S
S
s pec_
ex p
spec
c onf
tech_
sol 1
c onf
tec h_
s ol 2
c onf
tec h_
s ol 3
c onf
tec h_
s ol 4
prod_
c omp
prod_
c omp
prod_
c omp
prod_
comp
s pec
c onf
tech_
sol 5
C
S
spec
S
s pec
s pec _
ex p
c onf
tec h_
s ol 6
c onf
tec h_
s ol 7
C
s pec_
ex p N
c onf
tec h_
s ol 8
prod_
c omp
prod_
c omp
Fig. 9.13: Example overview about specification data objects (rule-based)
Page 75 of 75

CC8 Recommended Practices

Transcription

Similar documents

Visure Requirements

Jongert Trewes 67 GODEN WIND

Kitchen Designs Standard Specification

Software development

sovereign lady - Great Haywood Boat Sales

60ft Trad built by Colecraft £37,950.00

Fokker DRI Tri-plane - Airdrome Aeroplanes

Outline Specification Refurbished CB 90 H

Xitanium LED drivers – spot- and downlight SELV

- amarsons pipe tech me co llc