Towards Test-Driven Model Development in Production Systems

Engineering

Felix Rinker

1,2 a

, Laura Waltersdorfer

1,2 b

and Stefan Bifﬂ

2 c

Christian Doppler Laboratory for Security and Quality Improvement in the Production System Lifecycle (CDL-SQI),

Technische Universit

at Wien, Austria

Institute of Information Systems Engineering, Technische Universit

at Wien, Austria

Keywords:

Test-Driven Model Engineering, Production Systems Engineering, Meta-Model Engineering, Testing

Pipeline, Test-Driven Model Development, Experience Report.

Abstract:

The correct representation of discipline-speciﬁc and cross-speciﬁc knowledge in manufacturing contexts is

becoming more important due to inter-disciplinary dependencies and overall higher system complexity. How-

ever, domain experts do seldom have sufﬁcient technical and theoretical knowledge or adequate tool support

required for productive and effective model engineering and validation. Furthermore, increasing competi-

tion and faster product lifecycle require the need for parallel collaborative engineering efforts from different

workgroups. Thus, test-driven modeling, similar to test-driven software engineering can support the model

engineering process to produce high-quality meta and instance models by incorporating consistency and se-

mantic checks during the model engineering. We present a conceptual framework for model transformation

with testing and debugging capabilities for production system engineering use cases supporting the mod-

eling of discipline-speciﬁc AutomationML instance models. An exemplary workﬂow is presented and dis-

cussed. Debug output for the models is generated to support non-technical engineers in the error detection of

discipline-speciﬁc models. For future work user-friendly test deﬁnition is in planning.

1 INTRODUCTION

Model Engineering has become an increasingly im-

portant activity for the development of cyber-physical

production systems (Berardinelli et al., 2016): Lo-

cal models are used to integrate discipline-speciﬁc

views (e.g. mechanical, electric or pneumatic) and

their concepts into a holistic model, that represents the

concrete plant instance. In later development steps,

software is used to increase the throughput and efﬁ-

ciency of such systems, while enabling security and

safety. However, if the validity of the common en-

gineering model (the integrated model on all local

models) is not tested, the dependent code can lead to

semantic issues and inconsistencies over time. One

approach to prevent such issues is to apply model-

and software-based methods, so-called virtual engi-

neering: The aim is simulate the real world behav-

ior of all integrated components to reduce defects, er-

rors in the design and to ensure physical requirements

https://orcid.org/0000-0002-6409-8639

https://orcid.org/0000-0002-6932-5036

https://orcid.org/0000-0002-3413-7780

(Ko

sturiak and Gregor, 1999). The major challenge

however, is that for such consistency checks and sim-

ulations, all local models have to be transformed and

integrated into the holistic view. Currently, simulation

engineers estimate values and have to manually trans-

form values and check for validity. Advanced mod-

eling frameworks, such as Eclipse Modeling Frame-

work (EMF), are complex and non-intuitive for users

with little previous experiences in model-based engi-

neering domain. Furthermore, applications are lim-

ited to the Eclipse Software Ecosystem.

Another industrial use case for the common en-

gineering model is the automation engineer, writing

control code for components, such as conveyors or

robot arms to enable efﬁcient production. In order to

get such an integrated view and the holistic system

design for validation and veriﬁcation, inputs from all

relevant involved engineering disciplines are needed.

Regarding data exchange, software also impacted the

manufacturing domain heavily: Paper plans used for

planing and modeling of production systems were

over time replaced by exchanging digital artifacts, de-

scribing the different views needed for planning pro-

duction systems (Madsen and Munck, 2017): For ex-

Rinker, F., Waltersdorfer, L. and Bifﬂ, S.

Towards Test-Driven Model Development in Production Systems Engineering.

DOI: 10.5220/0009425302130219

In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 1, pages 213-219

ISBN: 978-989-758-423-7

213

ample, the mechanical view describes the layout of

plants, the electrical plan describes the wiring and

power supply and the ﬂuidics, describing the differ-

ent liquids required for the system. In 2009, Ebert

describes that the complexity of embedded systems

grows nearly exponentially (Ebert and Jones, 2009),

since the combination of hardware and software adds

another layer to the overall complexity of such sys-

tems.

However, proprietary formats, heterogeneous

views and non-suitable tools common to production

system engineering can lead to inconsistent nam-

ing and tagging of concepts or also hinder semantic

or project-independent consistency (Feldmann et al.,

2019). Best practices or industry guidelines (for ex-

ample (Verein Deutscher Ingenieure, 2009; Sch

uller

et al., 2019)) are not adhered due to the unstruc-

tured process of describing domain-speciﬁc knowl-

edge (Bifﬂ et al., 2019a). However, the adherence

to such standards and granular semantic and syntactic

checking for underlying engineering models would be

an essential step towards increasing the quality and

correctness of engineering output.

To alleviate some of these shortcomings, the au-

thors in (Munck and Madsen, 2015), propose Test-

Driven Modeling (TDM) analogue to Test-Driven De-

velopment (TDD), to ensure increased quality of en-

gineering models. TDD is a well-established method

from Software Engineering (SE) to improve the over-

all quality of the development process by incorpo-

rating continuous testing of speciﬁc test use cases

throughout the writing of software code.

This paper presents an conceptual framework for

lightweight testing and debugging framework for Au-

tomationML (AML) engineering models, to prove the

suitability and functioning of test-driven model engi-

neering for domain-speciﬁc models and describe our

lessons learned from a prototypical application.

Instead of manual integration of local views and

the tedious ﬁnding of errors, the automation of test

reports has the potential to increase consistency and

ﬂexibility of instance models and prevent common

pitfalls, such as non-unique ids or missing, non-

retrievable links. The lightweight integration of

Service-oriented architecture (SOA) (Krafzig et al.,

2005) ensures adaptability and lower integration ef-

forts. Furthermore, our approach can add ﬂexibility

to the modeling process by introducing an iterative

process, enabling stakeholders to add additional dis-

ciplines and thus, additional complexity to the mod-

els.

The remainder of this paper is structured as fol-

lows: Section 2 presents related work on model-

based approaches, domain-speciﬁc model engineer-

ing in production systems engineering and test-driven

(model) development. Section 3 presents identiﬁed

challenges in model development and engineering in

production systems engineering. In Section 4, we in-

troduce the solution approach and present preliminary

results of the test-driven model development. We dis-

cuss our ﬁndings and related limitations in Section 5.

Section 6 summarizes and identiﬁes future work.

2 RELATED WORK

This section gives an overview about related work on

model-based approaches, domain-speciﬁc model en-

gineering and TDD.

2.1 Model-based Approaches

Model-based approaches are said to improve modu-

larity, reusability of components and technology ﬂex-

ibility (Brambilla et al., 2017). The goal is to specify

and design domain models, from which technical doc-

umentation or software code can be generated. Enter-

prise modeling is an essential research topic for im-

proving model quality and an organizations ability to

get value from them (Sandkuhl et al., 2014).

Object Management Group (OMG) has deﬁned

the Meta Object Facility (MOF)

standard for model-

driven engineering, is an architecture for classiﬁca-

tion of models. Tools for model-based approaches

are established in the software engineering: EMF

Java-based, is one of the most popular tool sup-

port, providing a plethora of plug-ins and supported

methods. Notable examples are ATLAS Transforma-

tion Language (ATL)

, a model transformation lan-

guage, Xtext

, open source framework for developing

discipline-speciﬁc languages and Sirius

, as a graphi-

cal modeling software tool.

However, in engineering contexts, the quality and

extensiveness of domain models vary: Apart from

domain-speciﬁc tools, spreadsheets are common tools

and popular formats are Portable Document Format

(PDF) and Comma Separated Value (CSV) for de-

signing (data) models and for encoding of essential

information for other stakeholders due to their min-

imal and easy start-up. These tools are not tailored

for the description of engineering knowledge due to

growing complexity of production systems and such

MOF: https://www.omg.org/mof

EMF: https://www.eclipse.org/modeling/emf

ATL: https://www.eclipse.org/atl

Xtext: https://www.eclipse.org/Xtext

Sirius: https://www.eclipse.org/sirius

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

214

environments can pose signiﬁcant challenges (Mad-

sen and Munck, 2017). Uniﬁed Modeling Language

(UML), as a popular general-purpose modeling lan-

guage in software engineering has been proven to be

applicable for automated production systems as well

as SysML (Vogel-Heuser, 2014). Another challenge

in the production systems engineering context is the

heterogeneity of tools and views, which AML aims

to bridge by providing a data format designed for en-

gineering data exchange (Drath et al., 2008). How-

ever, there are still multiple challenges associated to

model-based approaches in the industry: Integrated

views on the local views, linking support for common

concepts and inconsistency management are major is-

sues (Feldmann et al., 2019).

2.2 Domain-speciﬁc Model Engineering

in Production Systems Engineering

With the digitization of the manufacturing domain

and increasing world wide competition, the need for

modeling engineering in production systems engi-

neering is increasing (Berardinelli et al., 2016). How-

ever, a well-known problem is that although domain

experts have extensive domain-speciﬁc knowledge in-

side their minds based on years of experiences and

through multiple cases seen in their career, they of-

ten cannot explicitly model this essential informa-

tion in correct and effective ways. Unfortunately, do-

main experts are seldom modeling experts, and are

not aware about the importance of adhering to for-

mal constraints and formalization of modeling con-

cepts (L

opez-Fern

andez et al., 2015), which are nec-

essary for automatic testing, consistency checks and

more. Traceabilty of design decisions is a major fac-

tor for sustainable engineering knowledge documen-

tation (Kathrein et al., 2019). Thus, domain experts

require the assistance of tools or also engineers to

construct suitable models.

Domain-speciﬁc models used for software engi-

neering are described in domain-speciﬁc modeling

languages, which is suitable for the concepts and ap-

plication. Meta-models are usually required to design

instance models of real world scenarios and to check

for consistency according to the constraints (L

opez-

Fern

andez et al., 2015).

In Figure 1, the manual (meta)-modeling process

common to production systems engineering is illus-

trated: Different disciplines, plant, mechanical, ﬂu-

idic and electric planning are working in parallel on

various artifacts, also called local models, describing

his discipline-speciﬁc view and concepts. The other

stakeholders then need to extract the information into

their local models and incorporate the changes by oth-

ers to see if the changes affected their own local con-

cepts (L

uder et al., 2019). Stakeholders, who need an

integrated view on the system, such as project man-

agers, simulation and automation engineers, need in-

tegrated models, incorporating all relevant disciplines

and their dependencies (L

uder et al., 2019).

For the further validation and consistency check-

ing, artifacts need to be sent around and are manually

analyzed. Since such artefacts and models can be big

and are hard to read for humans due to nested struc-

ture and no automated tests, errors are highly proba-

ble.

2.3 Test-Driven (Model) Development

The main paradigm of TDD is to write tests before

composing software code (Astels, 2003). This way,

TDD can increase the quality of output of the software

engineering process dramatically: Advantages are in-

creased efﬁcacy and feedback, catching defects and

bugs in early phases and shipping maintainable and

tested code (Williams et al., 2003) (Erdogmus et al.,

2005). Microsoft showed increased productivity of

development teams by applying TDD methodology

even taking in account extra upfront effort (Bhat and

Nagappan, 2006).

The methodology can also be applied to modeling

as described by Zhang (Zhang, 2004). Munck et Mad-

sen propose a test-driven model-based systems engi-

neering method to test architecture and behavior of

models in (Munck and Madsen, 2015). In (Munck

and Madsen, 2017) they also report on their expe-

riences utilizing formal veriﬁcation, simulations and

forecasting to support and enable the development

of cloud-based complex medical systems. (Zolotas

et al., 2017) shows that the error rate with constraint

testing can be dramatically reduced for certain errors

in comparison to manual checking.

Work Group

Plant Planner

Work Group

Mechanical

Engineer

Work Group

Software

Engineer

Work Group

Electrical

Engineer

Figure 1: Manual meta-modeling process.

Towards Test-Driven Model Development in Production Systems Engineering

215

3 RESEARCH METHODOLOGY

Vogel-Heuser et al. have applied the concept of tech-

nical debt to the production systems domain (Vogel-

Heuser et al., 2015): Technical debt is a concept from

software engineering, to quantify and model design

and implementation shortcomings from industry or

other standards in technical environments due to time

constraints or other reasons. Bifﬂ et al. have analyzed

technical debt in the data exchange of production sys-

tems engineering (Bifﬂ et al., 2019a) within the con-

text of a case study. The applicability of technical

debt in the industrial domain motivates the transition

of software engineering methods (in our case TDD) to

the production system engineering domain to manage

the negative effects and increased costs from accumu-

lated technical debt.

In the context of technical debt management

and transfer of software engineering methods to

the production system domain (Vogel-Heuser et al.,

2015), we designed a conceptual and prototypical ap-

proach to implement test-driven model development

for the production systems context. We present our

lightweight framework for testing and debugging en-

gineering domain models in AML: The context was

an improvement initiative with a company partner, in

the manufacturing domain to improve the engineering

data management process and data model lifecycle.

Through multiple workshops, we elicited stakeholder

needs on domain-speciﬁc models and the workings

of data exchange in production systems engineering

(Bifﬂ et al., 2019b).

4 SOLUTION APPROACH

In this section we discuss our solution approach,

a testing pipeline for instance models of domain-

speciﬁc instance models of engineering disciplines

common to the production systems engineering do-

main.

4.1 Context and Architecture

The basic use case for our conceptual test-driven

model development approach is the project conﬁgu-

ration for a production systems engineering project.

This provides the initial structure of a project, and an

initial data provision from the customer speciﬁcation

and functional view. A work cell or entire plant is

planned or re-conﬁgured according to this structure.

We have three roles representing traditional engi-

neering disciplines in such project, also introduced in

Figure 1: Plant planner providing the general struc-

ture of the cell or plant, mechanical engineer responsi-

ble for the mechanic components, ﬂuidic engineer re-

sponsible for all kind of liquids and electric engineer

designing wiring and power supply. In later phases

of this design process, virtual and software engineers

take the common engineering model as baseline for

their simulation and control code.

Similar to the process of constructing meta-

models in (L

opez-Fern

andez et al., 2015), in our con-

text one of our authors was the engineer and con-

structed a meta-model for the production systems do-

main in collaboration with a domain expert. The do-

main expert is an consultant for our research project,

with extensive experience in industrial projects and

research in academia. Over the course of eight

months, both stakeholders were iteratively design-

ing the architecture and testing pipeline, adapting

it to real-world requirements provided by partner

company stakeholders during the industry research

project. Within the context of this project, tests were

added when errors became evident and hindered the

progress.

In Figure 2, our testing pipeline is illustrated: The

overall architecture is based on service-orientated ar-

chitecture to build data exchange models to enable en-

gineering data exchange in production systems engi-

neering between different disciplines.

A meta-metamodel is described in a YAML Ain’t

Markup Language (YAML) ﬁle, a data serialization

language, which provides the general structure for the

project context. According to the MOF hierarchy,

this represents layer M3. Based on this conﬁgura-

tion context, user models, AML-1 and AML-2 tem-

plates are generated automatically. AML-2 instance

models would be the representation of the real world

according to single disciplines, for example the elec-

trical ﬂoor plan. AML-1 models are the integrated

view, which provide a holistic overview over all rele-

vant disciplines. The templates provide the structure

how the models can be modeled, which disciplines

can be integrated and they are veriﬁed in the next step.

Veriﬁcation tests that take place here, are of semantic

and syntactic nature. The successful passing of the

veriﬁcation tests means that the templates are well-

formed within the context of AML. In case of seman-

tic or syntactic errors, an report is generated to im-

prove bug tracking and ﬁxing of errors. In case, no

errors were detected, the transformer then populates

the AML-2 template with data based on both AML-1

and AML-2 templates, and on data provided by the

engineering discipline-speciﬁc tools. After the tem-

plate has been ﬁlled, another set of tests is conducted

to validate parameters, relationships and dependen-

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

216

Project Generator

AML Transformer

Conﬁg YAML

AML1_Template

AML2_Template

AML1_Template

AML2_Template

Verify

Result

AML2

OK?

Error

Report

Yes

Testﬁle Testﬁle Conﬁg

Test

Testﬁle Constraints

Result

OK?

Valid

AML2

Error

Report

Figure 2: Architecture of proposed testing pipeline.

cies based on previously given constraints and tests

put into a constraints testﬁle. An example for such a

constraint can be that the speed of a conveyor must

not exceed a certain limit depending on the product.

The result is either a valid AML-2 model, that is well-

formed according to the meta-metamodel or an error

report with bug output for further adaptations.

4.2 Debug Output and Used

Technologies

In listing 1, an example for debug output is depicted.

The output shows several messages, explaining the

processing of propagation of links throughout the dif-

ferent components of the models. Errors are shown in

red, in our case the ﬁrst element that was linked to a

sub concept was not retrievable by the system.

Advantages of debug output and the overall

methodology are that project-dependent changes can

be made traceable and retrievable if change logs or er-

ror reports are versioned. Furthermore, the integrated

view is validated and tested based on self-designed

tests to verify the correctness and adherence to cer-

tain constraints. Thus, this approach can support en-

gineers to produce faster, reliable models for produc-

tion systems engineering. The manual error detection,

which tends to be cumbersome for non-technical do-

main experts, can be supported by automated test re-

ports, which can be then resolved line by line.

YAML, a successor of Extensible Markup Lan-

guage (XML), is a human-readable description lan-

guage, making it easier for non-technical domain ex-

perts to read the models. AML as a new standard in

the production system domain has extensive potential

to simplify and support the heterogeneous data land-

scape common for this domain. The usage of this

standard might enable the future implementation of

other AML and tool interfaces. The decision to not

use Ecore, and EMF, popular for model engineering

is the independence from the Eclipse workspace. Fur-

thermore, EMF offers more features than needed for

our use case, and we wanted to keep the complexity

low within the project.

5 DISCUSSION

The use case starting with only three disciplines is re-

alistic to the set-up phase of real, industrial produc-

tion system engineering projects. However, one limi-

tation of our approach is that the simple use case was

only simulated with the example set up and no addi-

tional disciplines were added to the context during the

project until now.

Nevertheless, the advantage of our approach is

that in future, additional disciplines could be added

relatively easy throughout the process: In case of

changes to the meta-model and additional instance

models, the previously passed tests have to be re-run

according to the TDD paradigm. This way, checks

are conducted again and ensure the consistency and

validity of the local and the integrated models in the

new context although changes have been committed.

Another limitation is the limited set of test so far, only

detected errors were so far implemented into the test-

ing pipeline.

Noteworthy, is also that up time effort is certainly

Towards Test-Driven Model Development in Production Systems Engineering

217

DE BUG - Foun d p r o p agat i o n ma p pin g ' aml :/ / A M L 1Pro j e c t # t his . F u nctionV i e w @ F u n c tionVie w I D ' fo r ' S i m u lation V i e w @MUK '

DE BUG - E x trac t ed M a ppi n g P ath : th is . F u n c t i onView@ F u n c t i o nViewID

DE BUG - Foun d S u b Conc e p t ' Func t i onVie w ' in C onc e pt ' K 2 0 _ 5 0 _D_15_ B E 1 0 _ MKL '

E R R O R - C oul d not f ind Att r i bute ' F u nctio n V i ewID ' in Sub C o ncep t ' F uncti o n View '

E R R O R - E rro r r e s olvi n g at t r ibut e ' F uncti o n V iewID ' fo r pat h ' t his . Funct i o nView ' in e leme n t ' K20_ 5 0 _ D _ 15_BE1 0 _ M K L '

E R R O R - E rro r p r o cess i n g at t r ibut e pa th 'am l :// A M L 1Proj e c t # t his . F u n ctionVi e w @ F u n c tionView I D '

DE BUG - Foun d p r o p agat i o n ma p pin g ' aml :/ / A M L 1Pro j e c t # t his . F unction V i e w @ D e script i o n ' fo r ' S i m u l ationV i e w @ R E MARK '

DE BUG - E x trac t ed M a ppi n g P ath : th is . F u n c t ionVie w @ D e s c r iption

DE BUG - Foun d S u b Conc e p t ' Func t i onVie w ' in C onc e pt ' K 2 0 _ 5 0 _D_15_ B E 1 0 _ MKL '

DE BUG - Foun d A t t ribu t e ' Des c r i ptio n ' in E lem e nt ' F u n ction V i ew '

DE BUG - Foun d p r o p agat i o n ma p pin g

Listing 1: Debug output.

increased for the setup of the testing pipeline: Do-

main experts and engineers have to collaborate and

externalize implicit knowledge into meta-metamodel,

the domain-speciﬁc language templates and the con-

straints test ﬁles. However, during our improvement

initiative we already observed positive beneﬁts as eas-

ier bug tracking and error reporting, as well as the

reduction of common mistakes such as non-unique

identiﬁers or missing subconcepts. We assume that

similar to (Bhat and Nagappan, 2006), the additional

set up effort is similar in such a specialized domain

as production systems engineering as in the industrial

case studies. However, the beneﬁts of such a TDD

approach can increase the productivity of domain ex-

perts and technical stakeholders immensely. Meta-

and domain models can be adapted and still be vali-

dated and debugged against previously designed tests.

6 CONCLUSION AND FUTURE

WORK

Consistency and traceability are major issues in the

production systems engineering domain and in the

representation of engineering knowledge and exper-

tise. Due to various disciplines and the diverging tool

and format landscape, consistency and other checks

are tedious and error-prone, if conducted manually.

Domain experts often are not modeling experts, and

therefore are not able to test their domain models

systematically. Thus, we have presented a testing

pipeline to support discipline-speciﬁc model engi-

neering in the production systems engineering do-

main. Through an iterative process with a domain ex-

perts, an industrial use case and an experienced model

engineer, we designed an appropriate architecture and

models, showing real-world application of test-driven

model engineering methodology. The error reports

simpliﬁed the communication with the domain expert

to convey issues in the models, and also the resolving

of such issues. Although, we used speciﬁc technolo-

gies, our service architecture can be used as a base

model for other applications and prototypes in this

ﬁeld. The results are promising to extend the appli-

cation of our approach and to measure its impact with

industrial partners in the future. For future work, the

extension to additional disciplines and other models

need to be done. Furthermore, the usability of our

solution should be also extended, since the conﬁgu-

ration and implementation is currently done via bash

scripts and the implementation of new tests only avail-

able to experienced engineers.

ACKNOWLEDGEMENTS

The ﬁnancial support by the Christian Doppler Re-

search Association, the Austrian Federal Ministry for

Digital & Economic Affairs and the National Foun-

dation for Research, Technology and Development is

gratefully acknowledged.

REFERENCES

Astels, D. (2003). Test driven development: A practical

guide. Prentice Hall Professional Technical Refer-

ence.

Berardinelli, L., Bifﬂ, S., L

uder, A., M

atzler, E., May-

erhofer, T., Wimmer, M., and Wolny, S. (2016).

Cross-disciplinary engineering with AutomationML

and SysML. at-Automatisierungstechnik, 64(4):253–

269.

Bhat, T. and Nagappan, N. (2006). Evaluating the efﬁcacy

of test-driven development: industrial case studies.

In Proceedings of the 2006 ACM/IEEE international

symposium on Empirical software engineering, pages

356–363. ACM.

Bifﬂ, S., Ekaputra, F., L

uder, A., Pauly, J., Rinker, F.,

Waltersdorfer, L., and Winkler, D. (2019a). Techni-

cal Debt Analysis in Parallel Multi-Disciplinary Sys-

tems Engineering. In 2019 45th Euromicro Confer-

ence on Software Engineering and Advanced Appli-

cations (SEAA), pages 342–346. IEEE.

Bifﬂ, S., L

uder, A., Rinker, F., and Waltersdorfer, L.

(2019b). Efﬁcient engineering data exchange in multi-

disciplinary systems engineering. In International

Conference on Advanced Information Systems Engi-

neering, pages 17–31. Springer.

Brambilla, M., Cabot, J., and Wimmer, M. (2017). Model-

driven software engineering in practice. Synthesis

Lectures on Software Engineering, 3(1):1–207.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

218

Drath, R., L

uder, A., Peschke, J., and Hundt, L. (2008). Au-

tomationML - the glue for seamless automation en-

gineering. In 2008 IEEE International Conference

on Emerging Technologies and Factory Automation,

pages 616–623.

Ebert, C. and Jones, C. (2009). Embedded software: Facts,

Figures, and Future. Computer, 42(4):42–52.

Erdogmus, H., Morisio, M., and Torchiano, M. (2005). On

the effectiveness of the test-ﬁrst approach to program-

ming. IEEE Transactions on software Engineering,

31(3):226–237.

Feldmann, S., Kernschmidt, K., Wimmer, M., and Vogel-

Heuser, B. (2019). Managing inter-model inconsis-

tencies in model-based systems engineering: Appli-

cation in automated production systems engineering.

Journal of Systems and Software, 153:105–134.

Kathrein, L., L

uder, A., Meixner, K., Winkler, D., and

Bifﬂ, S. (2019). Product/ion-aware analysis of multi-

disciplinary systems engineering processes. In 21th

International Conference on Enterprise Information

Systems (ICEIS 2019).

sturiak, J. and Gregor, M. (1999). Simulation in pro-

duction system life cycle. Computers in Industry,

38(2):159–172.

Krafzig, D., Banke, K., and Slama, D. (2005). Enter-

prise SOA: service-oriented architecture best prac-

tices. Prentice Hall Professional.

opez-Fern

andez, J. J., Cuadrado, J. S., Guerra, E.,

and De Lara, J. (2015). Example-driven meta-

model development. Software & Systems Modeling,

14(4):1323–1347.

uder, A., Pauly, J.-L., Rinker, F., and Bifﬂ, S. (2019).

Data Exchange Logistics in Engineering Networks

Exploiting Automated Data Integration. In 2019 24th

IEEE International Conference on Emerging Tech-

nologies and Factory Automation (ETFA), pages 657–

664. IEEE.

Madsen, J. and Munck, A. (2017). A systematic and practi-

cal method for selecting systems engineering tools. In

2017 Annual IEEE International Systems Conference

(SysCon), pages 1–8. IEEE.

Munck, A. and Madsen, J. (2015). Test-driven modeling

of embedded systems. In 2015 Nordic Circuits and

Systems Conference (NORCAS): NORCHIP & Inter-

national Symposium on System-on-Chip (SoC), pages

1–4. IEEE.

Munck, A. and Madsen, J. (2017). Test-driven model-

ing and development of cloud-enabled cyber-physical

smart systems. In 2017 Annual IEEE International

Systems Conference (SysCon), pages 1–8. IEEE.

Sandkuhl, K., Stirna, J., Persson, A., and Wißotzki, M.

(2014). Enterprise modeling. Tackling Business Chal-

lenges with the 4EM Method. Springer, 309.

Sch

uller, A., Modersohn, A., Kawohl, M., and Wrede, J.

(2019). Der Digitale Zwilling in der Prozessindustrie.

atp magazin, 61(1-2):70–81.

Verein Deutscher Ingenieure (2009). VDI Richtlinie 3695:

Engineering von Anlagen-Evaluieren und Optimieren

des Engineerings. VDI-Verlag, D

usseldorf.

Vogel-Heuser, B. (2014). Usability Experiments to Evalu-

ate UML/SysML-Based Model Driven Software En-

gineering Notations for Logic Control in Manufactur-

ing Automation. Journal of Software Engineering and

Applications, 07:943–973.

Vogel-Heuser, B., R

osch, S., Martini, A., and Tichy, M.

(2015). Technical debt in automated production sys-

tems. In 2015 IEEE 7th International Workshop

on Managing Technical Debt (MTD), pages 49–52.

IEEE.

Williams, L., Maximilien, E. M., and Vouk, M. (2003).

Test-driven development as a defect-reduction prac-

tice. In 14th International Symposium on Software Re-

liability Engineering, 2003. ISSRE 2003., pages 34–

45. IEEE.

Zhang, Y. (2004). Test-driven modeling for model-driven

development. Ieee Software, 21(5):80–86.

Zolotas, A., Claris

o, R., Matragkas, N., Kolovos, D. S., and

Paige, R. F. (2017). Constraint programming for type

inference in ﬂexible model-driven engineering. Com-

puter Languages, Systems & Structures, 49:216–230.

Towards Test-Driven Model Development in Production Systems Engineering

219