Flexible Specification of STEP Application Protocol Extensions and
Automatic Derivation of Tool Capabilities
Thorsten Koch
1
, Jörg Holtmann
1
and Timo Lindemann
2
1
Software Engineering, Fraunhofer IEM, Paderborn, Germany
2
Emmet Software Labs GmbH & Co. KG, Bad Salzuflen, Germany
Keywords:
STEP, Model-driven Software Development, Meta-modeling, Model Transformation.
Abstract:
Original equipment manufacturers (OEMs) build mechatronic systems using components from several suppli-
ers in industry sectors like automation. The suppliers provide geometrical information via the standardized
exchange format STEP, such that the OEM is able to virtually layout the overall system. Beyond the geo-
metrical information, the OEM needs additional technical information for his development tasks. For that
reason, STEP provides an extension mechanism for extending and tailoring STEP to project-specific needs.
However, extending STEP moreover requires extending several capabilities of all involved tools, causing high
development effort. This effort prevents the project-specific utilization of the STEP extension mechanism
and forces the organizations to use awkward workarounds. In order to cope with this problem, we present a
model-driven approach enabling the flexible specification of STEP extensions and particularly the automatic
derivation of the required further capabilities for two involved tools. We illustrate and evaluate the approach
with an automation production system example.
1 INTRODUCTION
The development of mechatronic systems in indus-
try sectors like automation is characterized by com-
plex supply chains, where original equipment manu-
facturers (OEMs) build an overall system using phys-
ical components from several suppliers. An example
of such a system is depicted in Figure 1. The OEM
integrates this overall automation production system,
a so-called Pick & Place Unit (PPU) (Vogel-Heuser
et al., 2014). The PPU encompasses the four compo-
nents Stack, Ramp, Crane, and Stamp, which are de-
livered by suppliers. The Stack works as workpiece
input storage and the Ramp acts as workpiece out-
put storage. The Stamp is responsible for labeling the
workpieces, and the Crane is responsible for trans-
porting the workpieces by picking and placing them
between the different working positions. The Crane
transports workpieces from the Stack to the Stamp.
After the Stamp has processed a workpiece, the Crane
transports the workpiece finally to the Ramp.
Figure 2 sketches the exchange of the product in-
formation between the OEM and different suppliers
in the development process of a mechatronic system
like the PPU. In the course of integrating the overall
system, one of the most important development tasks
Figure 1: Pick & Place Unit as an example for a simple
automation production system (Vogel-Heuser et al., 2014).
of the OEM is to geometrically assemble the over-
all system based on the particular supplier compo-
nents. Prior to the actual production of the overall sys-
tem, this task is performed by means of a virtual ge-
ometric layout within computer-aided design (CAD)
tools. The suppliers geometrically design their par-
ticular components within CAD tools, too. Based on
these designs, they provide geometrical information
about their components via the standardized data ex-
change format STandard for the Exchange of Product
data (STEP) (ISO, 1994), such that the OEM is able to
virtually layout the overall system. This is indicated
through the arrows labeled STEP-based exchange of
Koch T., Holtmann J. and Lindemann T.
Flexible Specification of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities.
DOI: 10.5220/0006137400530064
In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 53-64
ISBN: 978-989-758-210-3
Copyright
c
2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
53
geometrical information in Figure 2, which sketches a
typical tool chain in a Supplier-OEM relationship.
Beyond the geometrical information, the OEM
needs additional technical information (e.g., the per-
missible payload of the Crane manufactured and de-
livered by Supplier A and the power consumption of
the Stamp from Supplier B in Figure 2) to perform his
development tasks. For that reason, STEP provides
an extension mechanism for extending and tailoring
STEP to project-specific needs. Typical applications
of the STEP extension mechanism have been reported
in (Usher, 1996; Zha and Du, 2002), for example.
However, extending STEP moreover requires ex-
tending the capabilities of all involved tools for the
specification, the data exchange, and the interpreta-
tion of the additional technical information. That is,
for one thing, all affected suppliers have to extend
their CAD tools such that they are able to specify and
export the additional information. For another thing,
the OEM has to extend his CAD tool such that he is
able to import and interpret the additional informa-
tion. These tool extensions have to be implemented
through plugins and application programming inter-
faces on the side of all involved organizations, which
causes a high implementation effort. Thus, the appli-
cation of the STEP extension mechanism is restricted
to static, one-off, and long-term tool chains, which
do not fulfill the needs of today’s and future dynamic
business processes (cf. the recommendations for im-
plementing the feature “digital end-to-end engineer-
ing” for dynamic value chains in the context of Indus-
try 4.0 (Industrie 4.0 Working Group, 2013)).
The fixedness of the STEP extension mechanism
leads to a tool chain as exemplary sketched in Fig-
ure 2. Beyond the specification of geometrical infor-
mation in CAD tools and the corresponding standard-
ized data exchange via unextended STEP, the sup-
pliers specify the respective additional technical in-
formation outside their CAD tools. This additional
information is awkwardly exported to the OEM via
different communication channels (e.g., phone, office
documents via mail, or electronic data interchange—
EDI—formats (Min, 2000)). In the example in Fig-
ure 2, Supplier A specifies the additional information
like the power consumption and the admissible pay-
load of his component in Excel sheets and exchanges
this information via telephone as indicated trough the
arrow Manual exchange via Telephone in Figure 2.
Supplier B documents the power consumption in a
Word document and exports the information via mail
as indicated trough the arrow Manual exchange via
Mail in Figure 2. Furthermore, the OEM faces the
challenge of component-wisely storing and group-
ing the geometrical as well as additional information
within a product data management (PDM) tool.
In order to cope with this problem, we present
in this paper a complex application of existing meta-
modeling and model transformation techniques that
enables the flexible specification of STEP extensions.
This particularly includes the automatic derivation of
the required capabilities of two involved tools for the
specification, the data exchange, and the interpreta-
tion of the additional technical information. The two
tools comprise a commercial-off-the-shelf CAD tool
on the supplier side and a self-developed central data
model on the OEM side. The central data model acts
as an alternative to a PDM tool, which only has the ca-
pability to component-wisely store arbitrary artifacts
(like CAD models and documents) but not to interpret
model-based information from different sources. We
illustrate the approach and conduct a case study with
the PPU example.
The remainder of this paper is structured as fol-
lows. In the next section, we introduce fundamen-
tals about STEP. Afterwards, we present our model-
driven approach in Section 3 and conduct a case study
in Section 4. Section 5 covers related work. Finally,
Section 6 concludes this paper with a summary and
an outlook on open future work.
2 ISO 10303 - STANDARD FOR
THE EXCHANGE OF PRODUCT
DATA (STEP)
The International Organization for Standardization
has published the ISO 10303 - STandard for the Ex-
change of Product data (STEP) (ISO, 1994) to address
the problem of exchanging product data between dif-
ferent systems. The overall objective of STEP is
to provide a mechanism that describes a complete
and unambiguous product definition throughout the
entire life-cycle of a product. Furthermore, STEP
provides a system independent and computer inter-
pretable file format for the exchange of product data
between different software tools, like computer-aided
design (CAD) or simulation tools (Kramer and Xu,
2009). However, STEP especially focuses on the rep-
resentation of geometrical information.
To realize the objective of a complete and unam-
biguous product definition, STEP defines so-called
application protocols (ISO, 1994). An application
protocol is a data model tailored to the specific needs
of an application area. In the scope of this paper, we
use the application protocol STEP AP214. Although
the STEP AP214 is originally designed for the auto-
MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development
54
Technical Engineer
CAD Engineer Geometrical Information
Geometrical Information
Technical Information
Power Consumption =
2000 W
… …
Power Consumption 1000 W
Admissible Payload 20 kg
… …
Technical Information
Supplier A
Supplier B
PDM System
Geometrical Information
Technical Information
Power Consumption =
2000 W
Geomtrical Information
… …
Power Consumption 1000 W
Admissible Payload 20 kg
… …
Technical Information
OEM
System Integrator
STEP-based exchange of geometrical information
Manual exchange via telephone
Technical Engineer
CAD Engineer
Figure 2: Overview of the exchange of product information between the OEM and different suppliers.
motive domain, it is broadly used in practice, since it
describes product information like sheet-metal parts
of the car body, mechanical parts of the engine, and
glass components. Thereby, the STEP AP214 is also
suitable for the exchange of product information in
the application of automation production systems.
In an application protocol, the description of prod-
uct data is defined in the EXPRESS information mod-
eling language (ISO, 2004). EXPRESS is part of the
ISO 10303 and has been defined to model geome-
try information. EXPRESS consists of language el-
ements that allow unambiguous data definition and
specification of constraints on the defined data. The
most important EXPRESS element is the entity data
type, which defines the objects of interest in the do-
main being modeled. The entity is characterized by its
attributes and constraints. The EXPRESS information
modeling language also supports various kinds of data
types, including simple types, aggregations types, and
constructed types (ISO, 2004).
STEP defines two different file formats for the ex-
change of product data: physical file (ISO, 2002) and
XML file (ISO, 2007). Whereas the XML file is an
XML encoding for the product data defined by an ap-
plication protocol, the physical file is a purely ASCII
encoding for product data. In the scope of this paper,
we use the physical file format, since it is mostly used
by exchange systems today to read and write STEP
data (Kramer and Xu, 2009).
Figure 3 depicts an overview of the relationship
between the EXPRESS information modeling lan-
guage, a STEP application protocol, and the ac-
tual product information contained in a STEP file.
The EXPRESS information modeling language has
been developed prior to the Meta Object Facility
(MOF) (OMG, 2015a) standard of the OMG. How-
ever, in terms of the MOF standard, the EXPRESS in-
formation modeling language is the meta-meta-model
used to specify STEP application protocols by means
of a grammar. The STEP application protocol is the
meta-model used to specify the structure of the prod-
uct information. The STEP file is the model con-
taining the actual product information following the
structure in the application protocol.
EXPRESS
STEP AP
instanceof
STEP File
instanceof
Figure 3: Overview of the relationship between EXPRESS,
STEP application protocols and STEP files.
In the remainder of this section, we use the run-
ning example of the PPU to illustrate the different
parts of the STEP standard. Therefore, Listing 1 de-
picts an excerpt of the STEP AP214 defined by means
of the EXPRESS information modeling language
showing the four entities product_context, product,
line, and cartesian_point. The product_context con-
tains the single attribute discipline_type of the type la-
Flexible Specification of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities
55
bel. The type label represents a STRING. The product
contains the attribute id, name and description; all of
type STRING. Furthermore, it contains a list of refer-
ences of product_contexts.
Listing 1: Exemplary excerpt of the STEP AP214 defined
in EXPRESS.
1 TYPE l ab el = STRING;
2 END_TYPE;
3
4 ENTITY p r o du c t _c o n te x t ;
5 di s c ipl i ne_ t y pe : la be l ;
6 END_ENTITY;
7
8 ENTITY p rod uc t ;
9 id :STRING;
10 nam e :STRING;
11 de s cri p ti o n :OPTIONAL STRING;
12 fra m e _o f _ ref e r en c e :SET [1 :? ] OF
pr o d uct _ con t e xt ;
13 END_ENTITY;
Listing 2 depicts an excerpt of the physical file
of Crane component of Pick&Place Unit. As men-
tioned before, a physical file is a pure ASCII encoded
file with a simple structure. Each line of a physical
file encompasses an identifier encoded "‘#id"’ and a
key-value par encoding the actual product informa-
tion. For example, in Line 1 of Listing 2, the product
is defined. The entity has the identifier #86, the id and
name HT_L1600. The identifier is also used to en-
code cross-references between different entities. For
example, the entity product contains a reference to the
identifier #91.
Listing 2: Exemplary excerpt of a STEP AP214 file.
1 # 86 = P RO DUC T ( HT _L 16 00 , HT _L 16 00 , ,( #91) );
2 # 91 = P ROD U C T_ C O NT E X T ( ,#93 , me ch an ic a l ) ;
3 FLEXIBLE SPECIFICATION OF
STEP EXTENSIONS
In this section, we present our model-driven approach
for the flexible specification of STEP extensions. Fig-
ure 4 depicts an overview of the approach encompass-
ing three main contributions for the OEM and his sup-
pliers to improve the problematic situation described
in Section 1. First, the OEM as well as his suppli-
ers are enabled to specify additional technical infor-
mation directly in their tools (cf. 1 Specification of
additional technical information in Figure 4). For this
purpose, we enable the OEM to specify a central data
model that can be tailored to the specific needs of
a particular development project. This central data
model contains all geometrical and technical informa-
tion and is also the main artifact of our approach from
which we derive the other parts using model-driven
techniques. Furthermore, we provide an extension to
the CAD tools of the suppliers based on the STEP ex-
tensions specified for the central data model. Second,
we are able to derive an automatic data exchange for
the involved tools (cf. Automatic exchange of product
information in Figure 4). Finally, the specification of
additional technical information as well as the auto-
matic data exchange result in a machine-readable and
processable representation of the product information
(cf. 3 Interpretation of the additional technical infor-
mation in Figure 4).
In the following section, we describe a system-
atic model-driven process to support the creation of
the central data model. Furthermore, we present the
technical details of the two process steps Automatic
Derivation of the Central Data Model and Data Import
and Generate CAD Extensions in the subsequent sec-
tions 3.2 and 3.3, respectively.
3.1 Process for the Creation of the
Central Data Model
Figure 5 depicts our model-driven process to support
the creation of the central data model. The process
is specified by means of the Business Process Model
and Notation (BPMN) (OMG, 2011). The main con-
tributions of this paper are emphasized in Figure 5
with gray tasks and artifacts. We visualize manual
steps by means of BPMN manual tasks (hand in the
upper left corner of the task). Steps that we could
automate are visualized by means of BPMN service
tasks (cogwheel in the upper left corner of the task).
Work results are specified by means of BPMN data
objects (document icons), and persistent models that
are subject to update and retrieval operations are spec-
ified by means of BPMN data stores (database icons).
In the following, we exemplarily perform and ex-
plain each process step depicted in Figure 5 referring
to the PPU as a running example. We design the
model-driven process in such a way that the OEM has
to perform it, but may need to discuss several aspects
with his suppliers.
In the first process step Analyze Requirements, the
OEM decides which information is necessary for the
current development project and should be stored in
the central data model. For the development of the
PPU, the OEM decides that the power consumption
of all used components and the admissible payload of
the Crane must be stored in the central data model be-
sides the regular geometrical information.
In the second process step Select Base Applica-
MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development
56
CAD Engineer
Supplier A
Supplier B
Central data model for project-specific
product information
OEM
System Integrator
STEP-based exchange of product information
CAD Engineer
STEP-based exchange of product
information
Product Information
#32456=power_consump
tion(2000,‘W');
Product Information
#32456=power_consump
tion(1000,‘W');
#32457=admissible_paylo
ad(20,‘kg‘);
Product Information
#32456=power_consump
tion(2000,‘W');
Product Information
#32456=power_consump
tion(1000,‘W');
#32457=admissible_paylo
ad(20,‘kg‘);
Specification of additional technical information
1
Automatic exchange of product information
2
Interpretation of the additional
technical information
3
Figure 4: Overview of our model-driven approach for the exchange of product information.
tion Protocol, the OEM selects an application protocol
from the STEP Application Protocol library that fulfills
most of the analyzed requirements and that acts as a
basis for the central data model. The library only con-
tains application protocols that are officially defined
in the ISO 10303. In our running example, the OEM
decides to use the STEP AP214 as the Base STEP AP.
As mentioned in Section 1, STEP usually does
not cover all product information that is needed for
the development of the overall system. Hence, the
OEM uses the next two process steps Create STEP
Extensions and Select STEP Extensions to enrich
the selected Base STEP AP with further descriptions
of product information. For this purpose, we en-
able the OEM to create new STEP extensions in an
EXPRESS-based textual editor and to store these ex-
tensions in a STEP Extension library. Furthermore,
we enable him to select existing STEP extensions
from the library that satisfy his specific needs.
In our running example, the STEP Exten-
sion library already contains several STEP exten-
sions. While reading through the descriptions of
these STEP extensions, the OEM noticed that the
STEP_EXTENSION POWER_CONSUMPTION depicted
in Listing 3 already satisfies the requirements on the
specification of a component’s power consumption.
Listing 3: STEP extension for the specification of a power
consumption.
1 SCHEMA S T E P_ E X TE N S IO N P O WER _ C ON S U MPT I O N ;
2 ENTITY p o we r _ co n s ump t i on ;
3 co m po n ent : p ro duc t ;
4 va lu e : NUMBER;
5 unit : U ni t ;
6 END_ENTITY;
7 END_SCHEMA;
The STEP_EXTENSION POWER_CONSUMPTION
only contains the entity power_consumption. This en-
tity refers to the entity product (cf. Section 2) de-
fined in the STEP AP214. Furthermore, the entity
power_consumption contains an attribute value of the
type NUMBER and a reference to a unit. As men-
tioned before, this application protocol is sufficient to
specify the description of a component’s power con-
sumption in a machine-readable manner. Thus, the
OEM decides to reuse this STEP extension. Since the
STEP Extension library does not contain a suitable
STEP extension for the specification of the admissi-
ble payload of a Crane component, the OEM defines
a new STEP extension STEP_EXTENSION ADMISSI-
BLE_PAYLOAD as depicted in Listing 4. The structure
is analogous to the previous STEP extension. After
the OEM has specified the STEP extension, he stores
it in the STEP Extensions library to enable its reuse
in further development projects.
Listing 4: STEP extension for the specification of an admis-
sible payload.
1 SCHEMA S T E P_ E X TE N S IO N A D M IS S I BLE _ P AY L O AD
2 ENTITY a d mi s s ibl e _ pa y l oad ;
3 co m po n ent : p ro duc t ;
4 va lu e : NUMBER;
5 unit : U ni t ;
6 END_ENTITY;
7 END_SCHEMA;
After the selection of the required STEP ex-
tensions, the automatic derivation process of the
Flexible Specification of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities
57
Automatic Derivation of the Central Data Model and Data Import
Central Data
Model
Project-specific
STEP-Grammar
Execute M2T-
Transformation
Execute
Derivation
Workflow
Central Data
Model Importer
Execute M2M-
Transformation
Project-specific
STEP AP
Generate CAD
Plugin
Analyze
Requirements
Create STEP
Extensions
Select STEP
Extensions
STEP
Extensions
Suitable
Extensions exist
Select Base
Application
Protocol
Base STEP AP
Selected
STEP Extensions
No Suitable
Extensions exist
STEP Application
Protocols
CAD Plugin
Figure 5: Overview of the model-driven process to support the creation of the central data model.
central data model (cf. Automatic Derivation of
the Central Data Model and Data Import in Fig-
ure 5) is executed. The automatic derivation pro-
cess encompasses three subprocesses: Execute M2M-
Transformation, Execute M2T-Transformation, and Ex-
ecute Derivation-Workflow. In the first subprocess,
Execute M2M-Transformation, the conceived model-
to-model transformation merges the Selected STEP
Extensions into the selected Base STEP AP to de-
rive a Project-specific STEP AP. This Project-specific
STEP AP contains the description of all product in-
formation that should be contained in the central
data model. In the subsequent subprocess Execute
M2T-Transformation, the OEM executes our devel-
oped model-to-text transformation to derive a Project-
specific STEP Grammar. This grammar enables the
automatic derivation of the central data model and the
corresponding import capabilities as described in the
subsequent section (cf. Execute Derivation-Workflow
in Figure 5).
Finally, the extensions to the CAD tools of the
supplier are generated in the process step Generate
CAD Plugin. These extensions enable the specifica-
tion of entities of the central data model within the
user interface of the CAD tool. Furthermore, it pro-
vides a mechanism to store the product information
and to export it to a physical file (cf. Section 2).
Concluding the introduction of the model-driven
process, we obtain the specification capabilities of ge-
ometrical and additional technical product informa-
tion by defining flexible STEP extension. The OEM
is enabled to describe a central data model by select-
ing an existing STEP application protocol as basis and
by defining and/or selecting STEP extensions to en-
rich this STEP application protocol. The resulting
project-specific STEP application protocol is further
used to automatically derive the required capabilities
for the data exchange between the OEM and his sup-
pliers. Furthermore, it is used to derive extensions
for existing CAD systems to enable the specification,
storage, and exchange of additional technical product
data needed in the development of mechatronic sys-
tems like the PPU.
3.2 Automatic Derivation of the Central
Data Model and the Data Import
In this section, we describe the realization of the pro-
cess step Automatic Derivation of the Central Data
Model and Data Import depicted in Figure 5. For
this purpose, we recreated and developed different
meta-models, models, and grammars as depicted in
Figure 6. Meta-models are depicted by means of
UML classes. Grammars are depicted by means of
UML classes with a small rectangle in the upper
right corner. Finally, we depicted text files as UML
classes with a document icon in the upper right cor-
ner and parser as UML classes with a circle in the
upper right corner. As the technology icons indi-
cate, we use the Eclipse Modeling Framework (Stein-
berg et al., 2008) to specify meta-models by means
of Ecore models, and the Xtext framework (Eysholdt
and Behrens, 2010) to define grammars. While us-
ing the Xtext framework, we are able to automati-
cally derive a parser for a particular grammar. Besides
the mentioned technologies, we use QVT-O (OMG,
2015a) and Xtend
1
to realize model-to-model and
model-to-text transformation, respectively.
As mentioned in Section 2, the EXPRESS in-
formation modeling language has been developed in
1
http://www.eclipse.org/xtend/
MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development
58
emof
instanceof
EXPRESS
Grammar
(recreated)
derives
instanceof
instanceof
STEP
Grammar
STEP
Text File
derives
EXPRESS
Text File
instanceof
derives
instanceof
derives
Legend:
meta-model
text filegrammar
parser
EXPRESS Parser
STEP Parser
EXPRESS
STEP AP
STEP Model
Figure 6: Overview of the developed meta-models and their
relationships.
the ISO 10303 prior to the Meta Object Facility
(MOF) (OMG, 2015a) standard of the OMG. Thus,
the EXPRESS information modeling language does
not comply to the OMG standard and modern model-
driven development techniques are not yet applicable.
For this reason, we developed our own MOF-
compliant meta-model of the EXPRESS information
modeling language based on the Eclipse Modeling
Framework and the Xtext framework. We used the
Xtext framework to recreate the concrete textual syn-
tax of the EXPRESS information modeling language
by means of a grammar (cf. EXPRESS Grammar in
Figure 6). While using the generation workflow of
the Xtext framework, we derive an Ecore-based meta-
model of the EXPRESS information modeling lan-
guage. Furthermore, we derive a EXPRESS parser
that reads textual STEP application protocol files that
correspond to the defined grammar.
As mentioned in Section 2, a STEP application
protocol is defined by means of the EXPRESS infor-
mation modeling language. Thus, after defining the
EXPRESS grammar and deriving its meta-model as
well as a corresponding parser, we are able to read
and write STEP application protocols. However, in
the current stage of our implementation, we are only
able to process the basic EXPRESS elements types
and entities. The processing of the remaining EX-
PRESS elements is left for future work.
A STEP application protocol only defines the
structure of the product information, and not the prod-
uct data itself. Hence, we apply the same technolo-
gies to create a grammar representing the product in-
formation specified in a STEP application protocol
(cf. STEP Grammar in Figure 6). Furthermore, the
STEP Grammar defines the structure of the STEP Text
File following the structure defined for STEP physical
files (cf. Section 2). As depicted in Figure 6, after the
execution of the Xtext workflow, we derive a meta-
model for STEP files that reflects the product infor-
mation defined in the STEP application protocol.
Figure 7 depicts the execution of the automatic
derivation process of the central data model for our
running example by means of a UML Activity Di-
agram. After the OEM has performed the process
step Select STEP Extensions depicted in Figure 5,
the specification of the central data model in our run-
ning example encompasses the STEP AP214 as Base
STEP AP, and the two extensions STEP_Extension
Power_Consumption: EXPRESS and STEP_Extension
Admissible_Payload: EXPRESS.
In the first activity M2M-Transformation, the se-
lected Base STEP AP and the two selected STEP ex-
tensions are merged into an Project-specific STEP AP
by using a model-to-model transformation realized
by a QVT-O in-place transformation. This model-to-
model transformation iterates over all entities in the
different :EXPRESS instances and merges them into
the Project-specific STEP AP. If a naming conflict oc-
curs or some references are not yet resolved, the trans-
formation resolves these issues.
After the execution of the merging activity, the
resulting Project-specific STEP AP is transformed
into an Xtext grammar by means of a model-to-
text transformation realized by Xtend (cf. M2T-
Transformation). The model-to-text transformation
also iterates over all entities and translates them into
a grammar that also fulfills the requirements of the
ISO 10303-21 for the structure of the final STEP
File. Listing 5 depicts an excerpt for the result-
ing Xtext grammar for the STEP extension shown
in Figure 4. The Xtext grammar defines the entity
power_consumption, encompassing an ID, a desc, and
as shown in Listing 3 a value, and a unit. In the fi-
nal STEP File, the ID corresponds to the line number
and acts as an identifier. The desc attribute indicates
which entity is currently parsed.
Listing 5: Excerpt of the Xtext grammar for the STEP ex-
tension shown in Listing 3.
1 po w er _ c ons u m pt i o n :
2 name = ID "="
3 desc =" p o we r _ con s u mp t i on "
4 "("
5 co m po n ent = [ pr o du c t | I D ] " ,"
6 va lu e = E D ou b le
7 ") "
8 " ,";
Finally, the workflow of the Xtext framework
is executed and as a result, we derive the central
Flexible Specification of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities
59
STEP EXTENSION
POWER_CONSUMPTION:EXPRESS
SCHEMA STEP EXTENSION POWER_CONSUMPTION;
ENTITY power_consumption;
component : product_definition;
value : Number;
unit : Unit;
END_ENTITY;
END_SCHEMA;
STEP AP 214 : EXPRESS
SCHEMA STEP AUTOMOTIVE_DESIGN;
ENTITY product_definition;
id : identifier;
description : OPTIONAL text;
formation : ;
frame_of_reference : ;
END_ENTITY;
END_SCHEMA;
STEP EXTENSION
ADMISSIBLE_PAYLOAD:EXPRESS
SCHEMA STEP_EXTENSION ADMISSIBLE_PAYLOAD;
ENTITY admissable_payload;
component : product;
value : Number;
unit : Unit;
END_ENTITY;
END_SCHEMA;
M2M-Merge Project-specific STEP AP: EXPRESS
SCHEMA Project-Specific STEP AP;
ENTITY product_definition;
id : identifier;
description : OPTIONAL text;
formation : ;
frame_of_reference : ;
END_ENTITY;
ENTITY power_consumption;
component : product_definition;
value : Number;
unit : Unit;
END_ENTITY;
ENTITY admissable_payload;
component : product_definition;
value : Number;
unit : Unit;
END_ENTITY;
END_SCHEMA;
M2T-Xtext
Project-Specific
Grammar
admissible_payload :
name=ID EQUAL_SIGN
desc= "admissible_payload"
LEFT_PARENTHESIS
component = [ product | ID ]
COMMA
value= EDouble
RIGHT_PARENTHESIS
";";
power_consumption :
name=ID EQUAL_SIGN
desc="power_consumption"
LEFT_PARENTHESIS
component = [ product | ID ]
COMMA
value= Edouble
RIGHT_PARENTHESIS
;";
Xtext-Workflow
Project-specific
STEP File : STEP Model
Project-specific
STEP Model : EXPRESS
-- example step excerpt of the crane component
#86=product('H-T_L1600 750-1000kg','H-T_L1600 750-
1000kg',' ',(#91));
#91=product_context(' ',#93,'mechanical');
#32456=power_consumption(1000,‘W');
#32457=admissible_payload(20,‘kg‘);
reads
Project-specific
STEP Parser: STEP Parser
Figure 7: Overview of the automatic derivation of the central data model and the data import.
data model (cf. Project-Specific STEP Model in Fig-
ure 7). Furthermore, we derive an Project-specific
STEP Parse that reads STEP files and creates data
models conforming to the central data model.
3.3 Automatic Derivation of the CAD
Plugin
In this section, we describe the realization of the pro-
cess step Automatic Derivation of the CAD Plugin de-
picted in Figure 5. The automatic derivation approach
has been prototypically implemented for the CAD
tool SolidWorks.
We started the development of the automatic
derivation approach with an examination of the plugin
mechanism of SolidWorks and implemented a refer-
ence plugin for an extended user-interface represent-
ing further technical product information and for ex-
changing this information.
After implementing the reference architecture, we
generalized the reference plugin, and divided the re-
sulting code into platform, individual, and repetitive
code. The platform code is provided by the CAD
tool SolidWorks to enable the development of plugins
using internal functionality of SolidWorks. We en-
capsulated the CAD tool dependent code by writing
a wrapper and refer to it as individual code. Finally,
the repetitive code is used to create an extended user-
interface and to create the storage functionality. Since
this code only uses operations provided by our own
individual code, the repetitive code is independent of
the used CAD tool.
In the next development step, we developed a
CAD plugin generator based on the individual code.
The CAD plugin generator uses the Selected STEP
Extensions as input and generates the required user-
interface elements for the additional technical infor-
mation. Furthermore, the CAD plugin generator also
generates the required code-fragments to support the
exchange of the additional information.
Figure 8 depicts the automatic derivation of the
MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development
60
CAD Plugin for our running example. The CAD
plugin generator uses the two Selected STEP Exten-
sions STEP_Extension Power_Consumption: EXPRESS
and STEP_Extension Admissible_Payload: EXPRESS and
produces the user-interface elements on the right.
4 CASE STUDY
In this section, we conduct a case study based on the
guidelines by (Kitchenham et al., 1995) for the eval-
uation of our approach. In our case study, we inves-
tigate the applicability and usefulness in practice of
our approach. We perform the case study based on
the running example in this paper and do not aim at
generalizing the case study conclusions to all possible
development projects using STEP for the exchange of
product information.
4.1 Case Study Context
The objective of our case study is to evaluate whether
our model-driven approach for the creation of a cen-
tral data model is applicable and useful for the OEM
and his suppliers, i.e., whether it reduces the manual
effort in deriving tool support for the overall infor-
mation exchange. For this purpose, we use the two
STEP extensions of the running example and differ-
ent STEP application protocols. We concentrate on
the investigation of the applicability and usefulness in
practice of our approach especially for the automatic
derivation of the central data model and the resulting
import capabilities, since the effort for extending the
user-interface of the CAD tool compared to the effort
of writing a correct parser is much smaller.
4.2 Setting the Hypothesis
We define two evaluation hypotheses for our case
study. The first evaluation hypothesis H1 is that our
model-driven approach for the exchange of product
information between the OEM and his suppliers pre-
sented in Section 3 reduces the manual effort in de-
riving tool support for the information exchange. For
the evaluation of H1, we define response variables
measuring the amounts of entities contained in the in-
put Base STEP AP including its extensions as well
as response variables measuring the code size and the
generation time of the parser output. That is, we de-
termine the number of entities contained in the se-
lected Base STEP AP plus the number of entities con-
tained in the used STEP extensions (response variable
H1.inputSize), the amount of lines of code generated
in particular for the parser of the central data model
(H1.outputSize), and the time needed for generating
the different code fragments (H1.outputTime).
The second evaluation hypothesis H2 is that our
model-driven approach for the exchange of prod-
uct information produces correct models and cor-
rect parser for existing STEP application proto-
cols like STEP AP214 and STEP AP203, and that
the parsers process their input files in reasonable
time. For the evaluation of H2, we define a re-
sponse variable for measuring the number of STEP
files used as input for the parser (response variable
H2.inputSize). That is, we determine the number of
files that are correctly processed without an excep-
tion (H2.outputSize), and the time needed for pro-
cessing each file (H2.outputTime). To draw conclu-
sion of the processing time, we also determine the
time needed to process the same files in SolidWorks
(H2.SolidWorksTime). We used a typical office com-
puter
2
for all test runs.
4.3 Validating the Hypothesis
For the validation of the first evaluation hypothesis
H1, we executed the model-driven approach several
times with different input configurations. First, we
used the STEP AP214 as Base STEP AP and the
STEP AP203 as Base STEP AP without any further
STEP extensions. Furthermore, we used the STEP ex-
tensions of the running example in combination with
the STEP AP214 and STEP AP203. Finally, we used
the STEP AP203 as an extension in combination with
STEP AP214 to draw conclusions about the scalabil-
ity of the approach. The determination of the number
of entities contained in the Base STEP AP as well as
in the used STEP extensions, the needed generation
time, and the lines of code for the parser yields the
results as listed in Table 1.
For the validation of the second evaluation hy-
pothesis H2, we used the STEP parser gener-
ated for STEP AP214 and STEP AP203. As in-
put files, we used free available CAD examples
(http://www.steptools.com). This leads to 20 files cor-
responding to the STEP AP214 and 44 files corre-
sponding to the STEP AP203. The determination of
the number of correctly parsed files and the needed
parsing time yields the results as listed in Table 2.
4.4 Analyzing the Results
The results for H1 show two aspects. First, depend-
ing on the number of entities used for the descrip-
2
Intel Core i7-4600U @2.10 GHZ, 8 GB DDR3 1066
MHz, 500 GB HDD, Windows 7 Pro 64 bit, Java JDK8u66,
Eclipse 4.5
Flexible Specification of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities
61
STEP EXTENSION
POWER_CONSUMPTION:EXPRESS
SCHEMA STEP EXTENSION
POWER_CONSUMPTION;
ENTITY power_consumption;
component : product;
value : Number;
unit : Unit;
END_ENTITY;
END_SCHEMA;
STEP EXTENSION
ADMISSIBLE_PAYLOAD:EXPRESS
SCHEMA STEP_EXTENSION
ADMISSIBLE_PAYLOAD;
ENTITY admissible_payload;
component : product;
value : Number;
unit : Unit;
END_ENTITY;
END_SCHEMA;
Plugin Generation
Figure 8: Overview of the automatic derivation of the CAD plugin.
tion of the central data model, the resulting parser en-
compasses a huge amount of source code. Without a
proper tool support, no software developer would be
able to produce the parser in the relatively short time.
For example, the execution of the model-driven ap-
proach uses overall 915 entities and generates 357775
lines of code within 12 minutes (cf. first row of Ta-
ble 1). Although the generation takes some time
to complete, this does not affect the applicability of
the approach, since the generation has be performed
only once in the whole development project. Sec-
ond, the model-driven approach scales with the num-
ber of entities used in the central data model. Thus,
we consider H1 as fulfilled. The results for H2 show
that the generated parser for the STEP AP214 and
STEP AP203 is able to read original STEP files, thus,
we conclude that our model-driven approach gener-
ates correct parsers. Furthermore, the comparison of
H2.outputTime and H2.SolidWorksTime shows that
our parser is not significant slower than the process-
ing of SolidWorks. Thus, we consider H2 as fulfilled.
Concluding the case study, the fulfilled hypotheses in-
dicate that our proposed model-driven approach re-
duces the manual effort in deriving tool-support for
the creation of a central data model and the corre-
sponding import/export capabilities. This gives rise
to the assumption that out approach is applicable and
useful in practice for the OEM and his suppliers.
The most important threats to validity are as fol-
lows: First, we only considered one development
example and thus cannot generalize the fulfillment
of the statements. Nevertheless, the example repre-
sents a typical development project and thus we do
not expect large deviations for other examples. Sec-
ond, the amount of lines of code generated by the
approach is only a superficial metric and, therefore,
might not reflect the actual development effort. Espe-
cially for small extensions like the definition of power
consumption, the conceptual complexity of our ap-
proach might exceed the effort for the manual exten-
sion and/or the manual exchange of this information
via another communication channel. However, the
manual extension has to be performed for each de-
velopment project.
5 RELATED WORK
STEP provides a standardized mechanism for repre-
senting and exchanging product data, and is therefore,
considered as a promising product modeling resource.
As mentioned in Section 1, the STEP extension mech-
anism has been used in several applications to de-
scribe or analyze a certain aspect of a system and to
exchange the corresponding product data. For exam-
ple, (Usher, 1996) presents an object-oriented product
model based on STEP AP224, which defines a stan-
dard set of machining features. The authors used their
object-oriented product model to support a computer-
aided process planning (CAPP) analysis. (Zha and
Du, 2002) present a product data exchange using a
STEP-based assembly model for the concurrent in-
tegrated design and assembly planning. Concluding
this paragraph, STEP is widely used in industry and
academic to organize product data in a standardized
representation. However, in contrast to our approach,
most approaches are tailored to one particular use
case and are not reusable or interoperable.
To overcome the inflexibility and interoperability,
a generic product modeling system has been proposed
in (Gu and Chan, 1995) and (Xie and Chen, 2009).
These two approaches belong to the most related ap-
proaches using STEP to provide a generic product
modeling system. However, in contrast to our ap-
proach, they do not use model-driven techniques to
realize their approach, and, thus, a lot of manual ef-
fort has be done for their practical realization.
Other work has focused on applying model-driven
development techniques to product data modeling in
the design of mechanical systems for the purpose
MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development
62
Table 1: Results of the analysis for H1.
Base STEP AP Number of H1.inputSize H1.outputSize H1.outputTime
STEP extensions (# of Entities) (LOC) (Generation Time)
STEP AP214 - 915 357775 12 minutes
STEP AP203 - 254 108144 2 minutes
STEP AP214 2 917 358237 16 minutes
STEP AP203 2 256 108626 3 minutes
STEP AP214 1 (STEP AP203) 1169 465101 20 minutes
Table 2: Results of the analysis for H2.
Base STEP AP H2.inputSize H2.outputSize H2.outputTime H2.SolidWorksTime
(# of files) (# of correctly parsed files) (parsing time) (parsing time Solid Works)
STEP AP214 20 20 57 seconds 48 seconds
STEP AP203 44 44 46 seconds 39 seconds
of collaboration and interoperability. For example,
(Iraqi Houssaini et al., 2012) present a model-driven
architecture for bringing together various product data
into a model-driven engineering environment. The
engineering environment is used to transform, share,
and export the product data enabling the collabora-
tion between different departments and companies in-
volved in the design of mechanical products. (Steel
et al., 2011) build a bridge between STEP/EXPRESS
and the Eclipse Modeling Framework. The bridge is
used to transform models based on the Industry Foun-
dation Classes (IFC), a standardized modeling lan-
guage, into a format suitable for a particular CAD
tool. Beyond the pure storing and sharing of STEP-
based product data in a model-driven environment
based on the Eclipse Modeling Framework, our ap-
proach enables the systematic extension of the STEP
standard to provide the exchange of additional tech-
nical product data. Furthermore, the OMG has pub-
lished a standard for a reference meta-model for the
EXPRESS information modeling language (OMG,
2015b). This meta-model has been devolved in the
so-called Mexico project. However, the standard only
focuses on the meta-model for the EXPRESS infor-
mation modeling language, and does not describe
how existing STEP application protocols can be trans-
formed to an instance of the reference model.
Finally, (Yildiz et al., 2014) present ongoing work
on a model-driven approach for the specification of
product information in the context of PDM. As in our
work, the authors state that the initial implementation
of a PDM tool, usually does not cover all information
needed by the user and that the required extensions
to a PDM tool are extensive to implement. Thus, they
propose a model-driven approach enabling companies
to specify their own business concepts for a PDM
tool, resulting in tool extensions to cover the addi-
tional information. Our approach and the approach of
Yildiz et al. mainly differ in their aim. We use project-
specific STEP extensions for the data exchange of
product information, whereas Yildiz et al. focus on
the extension of the storage capabilities of PDM tools
but do not consider data exchange. However, the
OEM typically applies a PDM tool with a plain arti-
fact storage mechanism nowadays, as sketched in the
introduction. Thus, a complementary combination of
both approaches would lead to a more holistic tool
chain, as we point out in the future work.
6 CONCLUSION AND FUTURE
WORK
In this paper, we presented a model-driven approach
for the flexible specification of STEP application pro-
tocol extensions. This particularly includes the au-
tomatic derivation of the required further capabilities
for two involved tools. For one thing, we derive a
central data model as well as a STEP parser for the
import and interpretation tool capability on the OEM
side based on the specified STEP application protocol
extensions. For another thing, we derive a plugin for
the CAD tool SolidWorks for the specification and the
export tool capability on the supplier side. Further-
more, our approach supports reusing once specified
STEP application protocol extensions. The approach
is generic in the sense that arbitrary STEP application
protocols can be extended.
The automatic derivation of the required tool ca-
pabilities significantly reduces the manual effort that
had to be spent on the whole tool chain otherwise.
Thereby, we enable the utilization of STEP appli-
cation protocol extensions for project-specific needs.
Moreover, the possibility of reusing extensions re-
duces the effort on the actual specification of the par-
ticular STEP application protocol extensions if an ex-
Flexible Specification of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities
63
tension was conceived in prior projects. The gener-
ality of the approach enables to handle other parts of
the STEP standard beyond the one that we exemplar-
ily extended in this paper.
The future work encompasses several aspects.
First, we want to improve the creation of STEP appli-
cation protocols to support the remaining EXPRESS
elements like where-clauses and rules in the resulting
Ecore-based meta-model by means of Object Con-
straint Language (OCL, (OMG, 2014)) expressions.
Second, we want to combine our model-driven ap-
proach with classical approaches from product line
engineering, like feature modeling, to enable the spec-
ification of geometrical and logical constraints in the
same formalism. Finally, we want to integrate our
central data model into PDM tools to improve their
plain artifact storage mechanism with the capability
to interpret model-based information.
ACKNOWLEDGEMENT
This research is partially funded by the Bundesmin-
isterium für Wirtschaft und Technologie (BMWi) un-
der the grant ZIM and is managed by the AiF Projekt
GmbH. Furthermore, this research is partially funded
by the German Federal Ministry of Education and Re-
search (BMBF) within the Leading-Edge Cluster “In-
telligent Technical Systems OstWestfalenLippe” (it’s
OWL) and is managed by the Project Management
Agency Karlsruhe (PTKA).
REFERENCES
Eysholdt, M. and Behrens, H. (2010). Xtext: Implement
your language faster than the quick and dirty way. In
OOPSLA’10, pages 307–309. ACM.
Gu, P. and Chan, K. (1995). Product modelling using step.
Computer-Aided Design, 27(3):163 – 179.
Industrie 4.0 Working Group (2013). Recommendations for
implementing the strategic initiative INDUSTRIE 4.0.
Final report.
Iraqi Houssaini, M., Kleiner, M., and Roucoules, L. (2012).
Tools interoperability in engineering design using
model-based engineering. In ASME 2012, pages 615–
623.
ISO (1994). ISO 10303-1:1994: Industrial automation sys-
tems and integration Product data representation
and exchange –Part 1: Overview and fundamental
principles.
ISO (2002). ISO 10303-21:2002: Industrial automation
systems and integration – Product data representation
and exchange Part 21: Implementation methods:
Clear text encoding of the exchange structure.
ISO (2004). ISO 10303-11:2004: Industrial automation
systems and integration – Product data representation
and exchange Part 11: Description methods: The
EXPRESS language reference manual.
ISO (2007). ISO 10303-28:2007: Industrial automation
systems and integration Product data representa-
tion and exchange Part 28: Implementation meth-
ods: XML representations of EXPRESS schemas and
data, using XML schemas.
Kitchenham, B., Pickard, L., and Pfleeger, S. L. (1995).
Case studies for method and tool evaluation. IEEE
Software, 12(4):52–62.
Kramer, T. and Xu, X. (2009). STEP in a Nutshell. In
Advanced Design and Manufacturing Based on STEP,
pages 1–22. Springer.
Min, H. (2000). Electronic data interchange in sup-
ply chain management. In Encyclopedia of Pro-
duction and Manufacturing Management, pages 177–
183. Springer.
OMG (2011). Business Process Model and Notation
(BPMN): Version 2.0.2.
OMG (2014). Object Constraint Language (OCL): Version
2.4.
OMG (2015a). Meta Object Facility (MOF) Core Specifi-
cation: Version 2.5.
OMG (2015b). Reference Metamodel for the EXPRESS In-
formation Modeling Language (EXPRESS): Version
1.1.
Steel, J., Duddy, K., and Drogemuller, R. (2011). A trans-
formation workbench for building information mod-
els. In ICMT 2011, pages 93–107. Springer.
Steinberg, D., Budinsky, F., Paternostro, M., and Merks,
E. (2008). EMF: Eclipse Modeling Framework.
Addison-Wesley, 2nd edition.
Usher, J. M. (1996). A STEP-based object-oriented product
model for process planning. Computers & Industrial
Engineering, 31(1-2):185–188.
Vogel-Heuser, B., Legat, C., Folmer, J., and Feldmann, S.
(2014). Researching evolution in industrial plant au-
tomation: Scenarios and documentation of the pick
and place unit. Technical report, Institute of Automa-
tion and Information Systems, Technische Universität
München.
Xie, Q. S. and Chen, W.-L. (2009). A Generic Prod-
uct Modelling Framework for Rapid Development of
Customised Products. In Advanced Design and Man-
ufacturing Based on STEP, pages 331–352. Springer.
Yildiz, O., Aouadi, N., Karkouch, A., Pernelle, P., Gzara,
L., and Tollenaere, M. (2014). MDA Based Tool for
PLM’ Models Building and Evolving. In APMS 2014,
pages 315–322. Springer.
Zha, X. and Du, H. (2002). A PDES/STEP-based model and
system for concurrent integrated design and assem-
bly planning. Computer-Aided Design, 34(14):1087
– 1110.
MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development
64