Flexible Speciﬁcation of STEP Application Protocol Extensions and

Automatic Derivation of Tool Capabilities

Thorsten Koch

, Jörg Holtmann

and Timo Lindemann

Software Engineering, Fraunhofer IEM, Paderborn, Germany

Emmet Software Labs GmbH & Co. KG, Bad Salzuﬂen, 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-speciﬁc needs.

However, extending STEP moreover requires extending several capabilities of all involved tools, causing high

development effort. This effort prevents the project-speciﬁc 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 ﬂexible speciﬁcation 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 ﬁnally 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 Speciﬁcation 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

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-speciﬁc 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

speciﬁcation, 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 fulﬁll 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 ﬁxedness of the STEP extension mechanism

leads to a tool chain as exemplary sketched in Fig-

ure 2. Beyond the speciﬁcation 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, ofﬁce

documents via mail, or electronic data interchange—

EDI—formats (Min, 2000)). In the example in Fig-

ure 2, Supplier A speciﬁes 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 ﬂexible speciﬁcation of STEP extensions.

This particularly includes the automatic derivation of

the required capabilities of two involved tools for the

speciﬁcation, 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 deﬁnition throughout the

entire life-cycle of a product. Furthermore, STEP

provides a system independent and computer inter-

pretable ﬁle 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 deﬁnition, STEP deﬁnes so-called

application protocols (ISO, 1994). An application

protocol is a data model tailored to the speciﬁc 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

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 deﬁned in the EXPRESS information mod-

eling language (ISO, 2004). EXPRESS is part of the

ISO 10303 and has been deﬁned to model geome-

try information. EXPRESS consists of language el-

ements that allow unambiguous data deﬁnition and

speciﬁcation of constraints on the deﬁned data. The

most important EXPRESS element is the entity data

type, which deﬁnes 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 deﬁnes two different ﬁle formats for the ex-

change of product data: physical ﬁle (ISO, 2002) and

XML ﬁle (ISO, 2007). Whereas the XML ﬁle is an

XML encoding for the product data deﬁned by an ap-

plication protocol, the physical ﬁle is a purely ASCII

encoding for product data. In the scope of this paper,

we use the physical ﬁle 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 ﬁle.

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 ﬁle 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 ﬁles.

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 deﬁned 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 Speciﬁcation of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities

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 deﬁned

in EXPRESS.

1 TYPE l ab el = STRING;

2 END_TYPE;

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;

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 ﬁle

of Crane component of Pick&Place Unit. As men-

tioned before, a physical ﬁle is a pure ASCII encoded

ﬁle with a simple structure. Each line of a physical

ﬁle encompasses an identiﬁer encoded "‘#id"’ and a

key-value par encoding the actual product informa-

tion. For example, in Line 1 of Listing 2, the product

is deﬁned. The entity has the identiﬁer #86, the id and

name HT_L1600. The identiﬁer is also used to en-

code cross-references between different entities. For

example, the entity product contains a reference to the

identiﬁer #91.

Listing 2: Exemplary excerpt of a STEP AP214 ﬁle.

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 ﬂexible speciﬁcation 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 Speciﬁcation 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 speciﬁc 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 speciﬁed 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 speciﬁcation 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 speciﬁed 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 speciﬁed by means of BPMN data

objects (document icons), and persistent models that

are subject to update and retrieval operations are spec-

iﬁed 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 ﬁrst 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

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

Automatic exchange of product information

Interpretation of the additional

technical information

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 fulﬁlls

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 ofﬁcially deﬁned

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 speciﬁc 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 satisﬁes the requirements on the

speciﬁcation of a component’s power consumption.

Listing 3: STEP extension for the speciﬁcation 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-

ﬁned 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 sufﬁcient 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 speciﬁcation of the admissi-

ble payload of a Crane component, the OEM deﬁnes

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 speciﬁed 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 speciﬁcation 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 Speciﬁcation of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities

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-Workﬂow. In the ﬁrst 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-speciﬁc STEP AP. This Project-speciﬁc

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-

speciﬁc 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-Workﬂow

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 speciﬁca-

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 ﬁle (cf. Section 2).

Concluding the introduction of the model-driven

process, we obtain the speciﬁcation capabilities of ge-

ometrical and additional technical product informa-

tion by deﬁning ﬂexible STEP extension. The OEM

is enabled to describe a central data model by select-

ing an existing STEP application protocol as basis and

by deﬁning and/or selecting STEP extensions to en-

rich this STEP application protocol. The resulting

project-speciﬁc 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 speciﬁcation,

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 ﬁles 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 deﬁne 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

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

http://www.eclipse.org/xtend/

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

emof

instanceof

EXPRESS

Grammar

(recreated)

derives

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 workﬂow 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 ﬁles that

correspond to the deﬁned grammar.

As mentioned in Section 2, a STEP application

protocol is deﬁned by means of the EXPRESS infor-

mation modeling language. Thus, after deﬁning 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 deﬁnes 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 speciﬁed in a STEP application protocol

(cf. STEP Grammar in Figure 6). Furthermore, the

STEP Grammar deﬁnes the structure of the STEP Text

File following the structure deﬁned for STEP physical

ﬁles (cf. Section 2). As depicted in Figure 6, after the

execution of the Xtext workﬂow, we derive a meta-

model for STEP ﬁles that reﬂects the product infor-

mation deﬁned 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 speciﬁcation 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 ﬁrst activity M2M-Transformation, the se-

lected Base STEP AP and the two selected STEP ex-

tensions are merged into an Project-speciﬁc 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-speciﬁc STEP AP. If a naming conﬂict 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-speciﬁc 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 fulﬁlls the requirements of the

ISO 10303-21 for the structure of the ﬁnal STEP

File. Listing 5 depicts an excerpt for the result-

ing Xtext grammar for the STEP extension shown

in Figure 4. The Xtext grammar deﬁnes the entity

power_consumption, encompassing an ID, a desc, and

as shown in Listing 3 a value, and a unit. In the ﬁ-

nal STEP File, the ID corresponds to the line number

and acts as an identiﬁer. 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 workﬂow of the Xtext framework

is executed and as a result, we derive the central

Flexible Speciﬁcation of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities

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-Speciﬁc STEP Model in Fig-

ure 7). Furthermore, we derive an Project-speciﬁc

STEP Parse that reads STEP ﬁles 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

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 deﬁne two evaluation hypotheses for our case

study. The ﬁrst 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 deﬁne 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 ﬁles in reasonable

time. For the evaluation of H2, we deﬁne a re-

sponse variable for measuring the number of STEP

ﬁles used as input for the parser (response variable

H2.inputSize). That is, we determine the number of

ﬁles that are correctly processed without an excep-

tion (H2.outputSize), and the time needed for pro-

cessing each ﬁle (H2.outputTime). To draw conclu-

sion of the processing time, we also determine the

time needed to process the same ﬁles in SolidWorks

(H2.SolidWorksTime). We used a typical ofﬁce com-

puter

for all test runs.

4.3 Validating the Hypothesis

For the validation of the ﬁrst evaluation hypothesis

H1, we executed the model-driven approach several

times with different input conﬁgurations. 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 ﬁles, we used free available CAD examples

(http://www.steptools.com). This leads to 20 ﬁles cor-

responding to the STEP AP214 and 44 ﬁles corre-

sponding to the STEP AP203. The determination of

the number of correctly parsed ﬁles 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-

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 Speciﬁcation of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities

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. ﬁrst 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 fulﬁlled. The results for H2 show

that the generated parser for the STEP AP214 and

STEP AP203 is able to read original STEP ﬁles, 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 signiﬁcant slower than the process-

ing of SolidWorks. Thus, we consider H2 as fulﬁlled.

Concluding the case study, the fulﬁlled 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 fulﬁllment

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 superﬁcial metric and, therefore,

might not reﬂect the actual development effort. Espe-

cially for small extensions like the deﬁnition 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 deﬁnes 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 inﬂexibility 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

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 ﬁles) (# of correctly parsed ﬁles) (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 speciﬁcation 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-

speciﬁc 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 ﬂexible speciﬁcation 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 speciﬁed STEP application protocol

extensions. For another thing, we derive a plugin for

the CAD tool SolidWorks for the speciﬁcation and the

export tool capability on the supplier side. Further-

more, our approach supports reusing once speciﬁed

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 signiﬁcantly 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-speciﬁc needs.

Moreover, the possibility of reusing extensions re-

duces the effort on the actual speciﬁcation of the par-

ticular STEP application protocol extensions if an ex-

Flexible Speciﬁcation of STEP Application Protocol Extensions and Automatic Derivation of Tool Capabilities

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-

iﬁcation 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 Pﬂeeger, 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 Speciﬁ-

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