Research Article

Definition of a system model for model‑based development

Hannes Hick1 · Matthias Bajzek1 · Clemens Faustmann1

© The Author(s) 2019  OPEN

Abstract
The term ‘system model’ is used in many different domains, fields of application and in various forms with different mean-
ings. One of model-based systems engineering’s targets is the generation of a system model, which is used to describe
complex system aspects across multiple views of disciplines and technical domains. Often a system model generated with
systems modeling language is used as a central placed model in development. Besides, there are practical approaches,
where models generated with other languages are also sometimes called system models. The scope of this paper is a
generic definition of the term ‘system model’ and its interactions with other types of models in a model-based develop-
ment ecosystem. Based on the analysis of the actual situation, a concept for the definition of system models is presented,
which enables the use of multiple system models and which helps to understand the interactions with other types of
models. For better comprehension of a system model’s role in development, a three dimensional cube for visualization of
system models and specific models is presented. Coupled with the definition of the term, interactions to other approaches
like product lifecycle management and the vision of a single source of truth for development are investigated and discussed.

Keywords System model · Model-based systems engineering · Model-based development · Discipline specific model ·
Domain specific model

1 Introduction developer, lifecycle considerations and much more. Fol-

lowing the path of technology legislative regulations and
Trends are showing a continuously increasing complex- the resulting reduction of emission until the approach of
ity of development of socio-technical systems [11, 26]. In green vehicle leads to actual increasing degree of electrifi-
parallel, development resources, time and cost have to cation of passenger cars. This results in new functionalities
be in balance while rising system quality, safety, reliabil- which have to be developed, as briefly shown in Fig. 1. Fur-
ity and durability as well as trust in the system [19]. This thermore, services such as autonomous driving functions,
leads to approaches such as systems engineering to man- and infotainment systems, etc. rapidly increase the system
age complexity, to work effectively and efficiently. Systems complexity. To satisfy customer needs, the number of vehi-
engineering combines best practices, and integrates them cle variants offered by original equipment manufacturers
into development processes to ensure an interdisciplinary (OEMs) is increasing, while at the same time development
collaborative, structured and connected development [13, and production time need to be decreased. To cope with
20, 28]. these contradictory requirements, today’s vehicle devel-
A consideration of the automotive domain shows the opment strongly relies on a massive supplier network.
rising complexity exemplary in many different areas from Furthermore, there is a rising number of suppliers which
technologies of the system to organizational matters, have to be managed. In parallel, due to integration of new
development approaches, involved stakeholders and technologies in modern vehicles, there is a high number of

* Matthias Bajzek, matthias.bajzek@tugraz.at; Hannes Hick, hannes.hick@tugraz.at; Clemens Faustmann, clemens.faustmann@tugraz.at |

1
Institute of Machine Components and Methods of Development, Graz University of Technology, Inffeldgasse 21b/II, 8010 Graz, Austria.

SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0

Received: 25 February 2019 / Accepted: 9 August 2019 / Published online: 23 August 2019

Vol.:(0123456789)
Research Article SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0

Fig. 1  Trend of increasing

system complexity in the auto-
motive domain

different teams and disciplines involved in development. of this paper and are therefore not further described
OEMs and other developers have to master these and here. Nevertheless, they are important to understand
many more challenges to deliver a well-working system the motivation behind the use of system models in
[12]. development.
Increasing system complexity leads to many terms A model-based approach is especially beneficial if its
used in development, resulting in different meanings and core idea is pervasively persecuted over the whole devel-
interpretations by developers. This paper focuses on an opment process to provide traceability and consistency
approach for definition of the term ‘system model’, gener- of information [4]. Therefore, suitable models on several
ated and used in development. This should conduct fur- levels of abstraction and for various purposes have to be
ther research and development based on the presented defined. According to Stachowiak [25], a model is a rep-
results. resentation of an object or system in reality and is char-
‘System model’ is a popular and common term used in acterized by three attributes—mapping, reduction and
various forms. A clear and consequently used definition is pragmatic property—described in detail in the following.
not available and may not be possible due to application Furthermore, the term ‘model’ is narrowed by focusing on
of system models in different industry domains. Increasing designated types of models, more precisely on computer
system complexity and development effort lead to a fre- generated digital models. Moreover, only semi-formal and
quent use of the term ‘system model’, which fundamental formal models [18] are considered. The limitation on these
idea is an interdisciplinary view on the system to support selected kinds of models is necessary to provide process-
the understanding of the whole system and the following ability and reusability.
development activities. To describe an applicable system Model-based systems engineering (MBSE) incorporates
model, it is necessary to define the purpose and context additional targets from systems engineering while focus-
for its usage. For the right use and understanding of the ing on some main concepts of MBE [3]. Defined targets
term it is also important to know the fundamental ideas of a MBSE approach are model-based consistency from
and concepts the idea of a system model is based on. system development until detail part development by
For better understanding of the term, the area of generation of a system model and central repository(ies)
application is investigated. The core idea of model- [4]. This paper focuses on the definition of such a system
based engineering (MBE) is to support the development model not only in context of MBSE but for the wider con-
process by using semi-formal and formal models [18] text of MBE. Nevertheless, the definition of the system
instead of written informal documents [9]. The intentions model should enable a proper application of it in MBSE but
behind the use of models in development cover various should not reduce the usability to a MBSE approach. By
aspects e.g., clear interpretation, reusability, merging of defining a system model only in context of MBSE, essential
information from different sources and a possibility to aspects of the general MBE are missing, and as result some
better describe the reality [4, 7]. Therefore, the principles important aspects of the system model may not be consid-
of model-based engineering constitute the context for ered. In addition, the link between central repository(ies)
a system model. The targets of MBE are not the focus and system models is briefly described.

Vol:.(1234567890)
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0 Research Article

In current practical approaches, commonly used sys- is sometimes seen as an overall provider and integra-
tem model definitions either strongly rely on the princi- tor, which represents some kind of single source of truth
ples provided by the System Modeling Language SysML— thinking.
requirements, structure, behavior, parametrics—[10] or are
seen as a visionary framework acting like a central model
and repository, which is linked to all other models in devel- 3.1 Divergent definitions of system models
opment and further provides data management activities.
The implications of these views on a system model will be By analyzing the current state, it becomes obvious that
described in the next section and a new approach of how there exist many different definitions of the term ‘system
to define the term ‘system model’, based on these percep- model’. There are several identified reasons for that.
tions, is presented. The term ‘system model’ is used in face-to-face com-
Starting with an analysis of the as-is situation, how munication, often resulting in a loss of exact meaning
the term ‘system model’ is currently used, interpretations due to human language uncertainty and multiple possi-
and implementations of system models are discussed. ble interpretations. Transferring these basic thoughts to
Following, necessary requirements for defining the term technical development, further different interpretations
are investigated. Furthermore, an approach of defining a of the term ‘system model’ are in use. It is important to
system model in context of model-based development is develop a framework, which enables common under-
presented which should contribute to further research and standing of system models to support interdisciplinary
development activities in this topic and should enable a communication.
reasonable use of the term. There are many disciplines and technical domains in
engineering and development in general, which use the
term ‘system model’ in their own kind of way. For instance,
2 General intent in software engineering, a system model is used for docu-
mentation of different perspectives and should enable
It is the main objective of this paper to enhance the discus- discussions among stakeholders and engineers [24]. In
sion about what system models are or could be in develop- the automotive industry system models are used on dif-
ments of socio-technical systems. Nevertheless, it is not ferent levels of development (vehicle system, powertrain
the objective to describe the general process of generat- system, engine system, etc.) and different degrees of tech-
ing these kind of models. The findings presented in this nical detail (different system maturity). Furthermore, sys-
paper should be an enabler to further implement model- tem models are often used to document requirements,
based development approaches by classifying, structur- structure, behavior, and verification & validation [1]. Other
ing and connecting models, which are used to develop sources see the system model as combination of several
a system. As the context for the developed concepts is models and repositories, which is able to act as one sin-
stated in the introduction, no further concretization of a gle model and central repository [29]. This triggers the
certain technical system is done in this paper, in order to demand for data management tasks, but often the respon-
provide a common starting ground for different possible sibilities for that are not clearly defined.
applications. In future research, the concepts are applied Another reason is the obvious disparity of purposes of
on a specific technical development use case to exemplary system models. To address information in the early phase
show the adaptation to specific needs and to evaluate the system design in the V-model [27], which can be e.g., sys-
practical usability. tem requirements or system architecture, SysML may be
an appropriate implementation of a system model [30].
Further, if the purpose is to establish and manage infor-
3 Inconsistent as‑is situation mation exchange between different disciplines, e.g., from
project management, through system development until
It is necessary to understand the background of production, the demand for a central system model acting
approaches which include the use of system models, as as single source of truth is a logical consequence.
there are many different definitions of the term ‘system In conclusion, two main views on what a system model
model’. As development targets can be quite diver- can be are established. One of them is a strict limitation
gent, system models are used in different abstraction of the system model to the principles defined by SysML.
degrees, on different levels of detail and for a variety The other one is some kind of vision of a system model,
of different purposes. On the one hand, many of them which is the connector, provider and integrator of product
lead to an implementation in SysML as interpretation of relevant information and which acts like a central model
a system model. On the other hand, the system model providing also management activities.

Vol.:(0123456789)
Research Article SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0

3.2 System models as defined with SysML with the PLM approach. To successfully create an added
value for development activities the strengths of both
In many approaches the system model is reduced to the concepts have to be combined and the boundaries
four pillars that describe the contents of the system rep- between them need to be defined.
resentation in SysML. These four pillars include require- However, the task to provide a single source of truth—a
ments, structure, behavior and parametrics [10, 21]. By central repository—might not be possible because of the
concentrating only on these predefined principles, the increasing complexity, interdisciplinarity and amount of
solution of how a system model could look like automati- specific data and needs in state of the art and future pro-
cally leads to a SysML implementation. By doing so, poten- jects. A look back in history to concepts like the engineer-
tially beneficial parts of a system model are not further ing backbone [6] shows that a central data storage (reposi-
considered (e.g., verification and associated test cases). tory) over the whole lifecycle is an enormous challenge
However, this approach also provides advantages, as there and this conclusion leaded to the need for connected
exists a semi-formalized modeling language that enables tailored repositories. Many department specific reposito-
stakeholder communication by uniform notations, seman- ries appeared due to specific requirements. Now, PLM as
tics and syntax. Nevertheless, SysML is just one way of how approach tries to connect these repositories. Same way of
to model a system. thinking transferred to the system models, there can’t be
a central model which collects and provides information
3.3 Single source of truth thinking all over the development.

A single source-, single point-, or sole source of truth repre-

sents an entity which contains every kind of constantly
updated information about the system under develop- 4 New comprehension of system models
ment to enable 100% traceability and consistency. Interest-
ing to note is that many concepts, such as a central model, This section provides the definition of the term ‘system
claim to be the single source of truth in development. model’, starting with the identification of general require-
In some approaches, the system model is positioned ments. Derived from the problematic as-is situation, the
in the center of development. Therefore, it has to con- definition of a system model needs to be clearly under-
tain and manage all information about the system under standable and it must be possible to transfer the definition
development and has to be connected to all other kinds to a real development process. Due to various applications
of models in use. To overcome the shortages of a central in many different industries, the system model should be
system model approach using SysML, new concepts for an able to be used in all of them. This would lead to an uni-
overall system model, e.g., the total system model (TSM) versal definition with no practical relevance. Therefore, it
[2], were developed. The aim of such concepts is to cope has to be clearly outlined, that a system model needs to
with the incredibly sophisticated task to connect all tech- be tailored to the field of application, the industry domain
nical domains (and tools) within a development process. and to organizational requirements (available methods
It has to be discussed which purposes a system model and IT-tools, engineer’s skills, etc.).
has, and which tasks are already fulfilled by other con- For the development of complex socio-technical sys-
cepts or tools. In this context, product lifecycle manage- tems digital models are in use, which are created on
ment (PLM) has to be mentioned. PLM is an approach computers. This type of models is processable and com-
which aims to integrate and process all product related puterized and can be used to describe a system under
information and tasks over the whole lifecycle of the development with a certain amount of information, which
product. The challenges an PLM approach faces are data is stored in databases/repositories.
management, the organization and integration of differ- This type of model is used to increase the consistency
ent kinds of information. It should be mentioned that of the system description, which is possible in a computer-
PLM is an approach/vision, not a realized in a single sys- based language, resulting in increasing development effi-
tem and not a purchasable as a single IT-tool [22]. PLM’s ciency by a more structured development, right definition
target is to provide product relevant data whenever it of interfaces etc. Furthermore, models support the explo-
is needed. Therefore, PLM requires structured and con- ration in design space to find a better, more performant
nected data management systems to provide a consist- and less expensive solution, as well as verification and
ent information flow, and to enable better handling of validation (V&V) activities. Beside this, models are used
complex systems [23]. Understanding the targets of PLM, for (semi)-automatic documentation of system. These and
it can be concluded that a system model might not have many more benefits show the importance of models used
the same purpose and has to be carefully harmonized in development [28].

Vol:.(1234567890)
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0 Research Article

4.1 Requirements for a system model hides the methods which are necessary for transferring
the reality into a model, modeling the model (modeling
There are basic requirements, every kind of model should methods), filling the model with information, providing
be able to fulfil. Two concepts used to proof the quality of possibility for exchange, etc. Methods for doing that are
models are model verification and validation. While model not focus of this paper, but are the key element to pro-
validation confirms, that the model corresponds to a real vide an effective and efficient development.
system, model verification ensures that a model has been To really create an added value, a feasible system
implemented correctly. The correctness of a model implies model implementation must be possible. A central
three attributes, according to Madni and Sievers [18]: model as single source of truth is not a realistic concept
for complex systems under development (with the cur-
• Completeness: All relevant elements, relationships and rent technologies and solutions) and is therefore seen
parameters are sufficiently specified as a vision. Often a practicable system model definition
• Consistency: Common concepts and definitions are needs to be more than a SysML model contains. Based
implemented consistently into the model on SysML’s unified notations, syntax and semantics, it can
• Traceability: Concepts are derived from common stand- be used to generate a common view and understand-
ards, requirements or guidelines ing of the system in an abstract way, enabling internal
general system discussions and providing a platform for
These generic requirements have to be fulfilled by all stakeholder (internal and external) interactions.
kind of models. As pointed out earlier, the focus is on So, already existing understandings of system models
semi-formal and formal models which provide the pos- have to be incorporated or evolved in a new definition.
sibility of continuing simulation. To characterize mod- There has to be noted, that it is useful to refuse the idea of
els even further, more categories of models have to be only one system model. In complex and time-consuming
mentioned. Therefore, differentiation between qualita- system development projects it is simply not possible to
tive and quantitative models is usual. Further, models create one system model which coordinates every disci-
are sometimes seen as abstract or detailed models, pline and fulfill their specific needs within the develop-
depending on the amount of content they provide. ment process. State of the art development has to be more
Depending on relevance to simulation, characteristic flexible than ever and many stakeholders and occurring
values i.e., fidelity, resolution, accuracy, uncertainty data/information from external suppliers, partners and
are of relevance. For the following definition of the sys- customers as well as company internal data must be man-
tem model a differentiation between the terms ‘model’, aged. Due to different operating areas and tasks system
‘simulation’ and ‘repository’ is necessary. Figure 2 shows models have to fulfill e.g., stakeholder interaction, system
the principle that not every model is created to be used concept and design (descriptive, analytical) fast system
for an ongoing simulation (processing/manipulation of verification (benchmarking, analytical, numerical), infor-
the model in a defined environment). Both, the model mation backbone, interface management, etc., the use of
itself and the simulation, deliver information needed in multiple system models in development project is senseful
development, which is stored in repositories. This figure and has to be possible with a definition of a system model.

Fig. 2  Model, simulation and

repository(ies)

Vol.:(0123456789)
Research Article SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0

Therefore, it is reasonable to define what the contents Due to the huge number of models with different targets
of a system model can be. As other contributors deducted, and purposes the resulting framework for the definition of
every discipline has its own view on the system und these models implies that there can’t exist only one system
defines the system model by using different sets of infor- model in a whole development project.
mation [14]. According to Zafirov, a set of modeling con- This statement is further pursued with the follow-
cepts can be defined, that incorporates the various views ing thinking. Systems engineering principles support
of different disciplines. These are requirements, structure, the translation of a problem into a solution. In this case
behavior, parameter, context, validation and verification the definition of systems, subsystems and parts, as well
[31]. A system model may contain this information, but as top-down (rough to detail) are taken up. The system
should not be limited to it, as the enumerated kinds of under development is structured in different levels, and is
information are closely related with SysML as the modeling considered by multiple disciplines (mechanics, electrics/
language to be used. electronics, software, etc.) and technical domains (require-
ment, structure, behavior, V&V, etc.). At least for every com-
4.2 Definition of the term system model bination (part—mechanics—behavior, subsystem—elec-
trics/electronics—structure, etc.) one model has to exist in
To conclude an appropriate definition, a brief considera- a model-based development approach. Considering the
tion of the two terms ‘system’ and ‘model’ is done. A system role of the system model, it follows that the intention of
is defined as follows: it is to combine multiple views (subsystem—mechanics
and electrics/electronics—structure, etc.). As there exists
[…] a system is sometimes considered as a product
a huge number of views (for each combination), the idea
or as the services it provides. […] in practice, the
of one single system model combining them all, does not
interpretation of its meaning is frequently clarified by
seem to be feasible. This leads to the statement that there
the use of an associative noun, e.g., aircraft system.
can’t exist only one unique system model. In theory one
Alternatively, the word “system” is substituted sim-
system model, which connects all these submodels may
ply by a context-dependent synonym, e.g., aircraft,
be feasible, but a practical realization is not in sight.
though this potentially obscures a system principles
The one and only system model in a development project
perspective. […] a complete system includes all of
is just a conceptual idea, a way of thinking, an engineering
the associated equipment, facilities, material, com-
vision.
puter programs, firmware, technical documentation,
Current realizations of system models in practical
services and personnel required for operations and
approaches prove that this is the case. Notwithstand-
support to the degree necessary for self-sufficient
ing, centralized thinking is good and necessary. Thinking
use in its intended environment. [15]
of one overall system model above all other models as
According to Stachowiak [25], a model is always a gen- single source of truth supports the understanding of the
eralized abstraction of reality and is defined by three need to collect, distribute and manage information in a
properties: better way. The following sections provide a detailed view
on how these conclusions are incorporated in a system
• Mapping property: Models represent natural or artifi- model definition.
cial things, which can be models themselves.
• Reduction property: In general, models do not cover all 4.3 The bigger picture
attributes from the origin, they are reduced to the ones
which are necessary for the creator or observer. A commonly used procedural model for development is
• Pragmatic property: Models are not a direct link to their the V-model. It provides multiple views: Interdisciplinary
origin, rather they have a replacement function and discipline specific; system design, implementation
and integration [5]. These are typically global considera-
Based on the previous described definitions, the term ‘sys- tions, but cascading these views on system, subsystem and
tem model’ is further characterized. It is not just a simple part level is also common [16], whereby a part can also be
combination of the definitions of ‘systems’ and ‘models’. a system, depending on the local point of view.
Referring to the fundamental idea of Aristotle: “The whole Transferring this way of thinking to system models and
is more than the sum of its parts”. So, the term ‘system their position in the V-model, this leads to a global place-
model’ represents more than just a simple combination ment of system models in the upper half of the V-model.
of these two terms. Setting up a definition of a system Discipline specific and technical domain specific mod-
model which is applicable in development, a clear state- els—in the following referred to as specific models—are
ment, based on the described requirements, is necessary. placed globally at the bottom half. This principle can be

Vol:.(1234567890)
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0 Research Article

cascaded into several levels if needed and shows that the have to be used to a certain extent. However, to define the
local system models can also be placed in lower levels. multiple views and areas incorporated within system mod-
For example, considering the vehicle as system, one of its els, three dimensions are introduced. The general dimen-
subsystems is the powertrain and parts of the powertrain sions are in this case tailored and further narrowed down
would be the engine, transmission, etc. From this it follows for a model-based engineering approach.
that the engine appears as part or system, depending on
the point of view. The same principle leads to the conclu- • Breadth: There are many disciplines involved in the
sion that there exists an overall vehicle V-model, but also in development of a system (e.g., mechanics, electrics/
parallel a powertrain V-model as well as an engine V-model electronics, software, etc.). These disciplines are repre-
etc. However, this means a system model is not fixed to sented by this axis.
one specific level, rather it is possible to have system mod- • Width: This dimension describes involved technical
els on different levels as well as multiple system models on domains in development (e.g., requirement, structure,
the same level. Depending on the point of view and the behavior, verification & validation, etc.).
development task, it might be useful to have, for exam- • Depth: Due to the reason that the dimensions
ple, a system model representing an engine as well as a described before are available in different degrees of
system model for the whole vehicle. Figure 3, illustrates detail and on several levels of the system structure, a
this way of thinking applied to the V-model according to third dimension is needed, which describes the depth
VDI 2206 [27]. of the model.
The system model is a combination of multiple views.
Therefore, a distinction between system models and These three dimensions can be visualized as a cube. Each
specific models is needed, emphasizing the divergent dimension defines one side of the cube (x—breadth, y—
focuses of each model type. This is based on the concepts width, z—depth), see Fig. 4a. Considering the ‘cube’ and
of Friedenthal and Moore [10], who distinguished system its placement in the V-model, the ‘cube’ is valid for the
models and analytical models because of their differences global and local V-model, as described earlier. Depending
regarding scope and fidelity. Enhancing this idea, system on the field of application, operating area, global or local,
models incorporate multiple views in breadth and width— the terms used for each dimension has to be specified if
focusing on at least two technical domains or disciplines. necessary (e.g., mechanic to thermal, mechanics, hydraulic,
The focus of specific models is to represent the view of a etc.). System models as well as specific models can extend
single discipline on a single technical domain and targets over several levels.
to provide more depth than a system model. E.g., if the The system model is typically placed at the upper half of
view of mechanical engineering on structure is worked the presented cube, see Fig. 4b. Several meaningful com-
out with CAD, resulting in a structural model of the system binations are imaginable, resulting in multiple possible
under consideration, this represents a specific model. Both system models. One exemplary system model covers the
types of models provide benefits for the development and technical domains requirements, structure, behavior, and

Fig. 3  a Global V-model, b V-model on different levels and placement of system models (SM) and specific models (xSM) [27]

Vol.:(0123456789)
Research Article SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0

Fig. 4  a General dimensions and structure of the ‘cube’, b multidimensional placement of the system model

another domain as views of multiple disciplines on system to the cube shown above for models in development. For
level. This system model represents the view described instance, if it is of interest to extract the view of the disci-
with of SysML. Another system model is a combination pline mechanics, a slice operation would reduce the visible
of structure, behavior and electrics/electronics, software, information to the perspectives a mechanical engineer
with quasi less breadth and width, but therefore more might have on a system on different technical domains
included levels. Multiple system models with different and levels of detail. This leads to a system model as it incor-
combinations for diverse purposes and targets can exist porates several technical domains. Another system model
in parallel. Depending on the kind of information needed, can be the result of a dice operation, which reduces all
system models can embody more or less views. three dimensions, e.g., representing the views of mechani-
The system model enables breadth and width by includ- cal and electrical engineers on the same subsystem and its
ing several discipline and technical domains, but as result components described with requirements and structure
less depth. Combined views allow system relevant state- information. This can be visualized as a new, smaller cube
ments, represent important aspects of the system, provide within the original one. To generate a specific model, the
common understanding of the system etc. Another kind dimensions breadth and width, discipline and technical
of models, specific models, provide depth, i.e., technical domain, are each reduced to one aspect while the dimen-
detail of one view, in contrast to system models. Both, sys- sion level is left open as it is the focus of specific models
tem models and specific models, support decision making to provide depth. This visually leads to a pillar within the
for engineers and other responsible persons. original cube. These slice and dice operations show that
multiple system models within the development exist and
4.4 Generation of model types from the cube can be interpreted meaningfully.
It cannot be ruled out, that there exists double informa-
To enhance understanding of this multidimensional tion between the numerous specific models and system
model, it is helpful to use an analogy from data manage- model. It is possible that the models have overlapping
ment. It is a common way to store and manage data in zones. Friedenthal and Moore [10] refer to this as overlap-
multidimensional structures which are often visualized ping truth and state that the information used in multi-
by data cubes. The dimensions are hierarchical structured ple models has to be kept updated and consistent. Due
by a so-called classification scheme to further detail each to the huge number of models with different targets, it is
dimension [8]. To navigate in this multidimensional space likely that overlapping zones occur. Therefore, interfaces
and to execute data analyses, standardized operations between models as well as interfaces between reposito-
are available to filter the required data. The ones most fre- ries are necessary to provide information consistency and
quently used are slice and dice, which can be transferred traceability.

Vol:.(1234567890)
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0 Research Article

Due to increasing system complexity the number of used overview of all the used models, their information which is
models in development is heavily growing. It is impossible, needed to generate the model, its outputs, their links, the
neither effective to avoid the natural overlapping zones of use of same information for different models, and many
models and multiple existence of information. This shows the other topics get essential for development of the trans-
importance of standardized interfaces to enable connected mission system.
development. By starting to generate the ‘cube’ stakeholder needs
and expectations are analyzed. The result of the analy-
4.5 Transmission case study sis provides a rough view of which ‘information’ has to
be delivered to the stakeholders in order to hand-in the
The ‘cube’ provides the possibility to visualize required developed transmission system later. Based on that, and in
and available models in system development, by consid- combination with the company’s expertise of mechatronic
ering which models cover which views such as geometric system development the necessary involved development
or electric view on the system. It provides a possibility to disciplines are defined. Furthermore, the logical V-model
identify which aspects of a system are already modeled or the transmission development process provides a first
and which systems aspects are still not understood explic- definition of necessary technical domains to develop the
itly. In order to implement the ‘cube’ as proposed in the system. The identified disciplines use models at different
previous sections, it is necessary to follow a certain pro- levels in system hierarchy as well as for describing the sys-
cedure to classify and structure models over the develop- tem with several different technical domains.
ment process (as well as over time): Table 1 provides a brief, non-exhaustive, overview of
used models. For this case study the dimensions and views
• Analysis of information which describes the system, are identically defined and used as in Fig. 4. Depending
• Definition of dimensions and views to classify this infor- on required detail the dimensions and views can be split,
mation, and such as mechanics into strength, kinematic and geometry.
• Classify models according to defined dimensions and Methods and tools which are necessary to generate the
views. models as well as use the modeled content are not con-
sidered in this case study.
By considering a development approach of a mechatronic The listed models provide an overview of used models
system, many different models with different purposes at in transmission development, which is not a complete list
different time periods are used to develop the system. of all possible models. Furthermore, some questions arise:
For example, an automotive dual clutch transmission for
passenger cars represents a mechatronic system. Models • Which model is used to describe a certain aspect of a
are used in all phases of transmission development, from system?
requirements definition based on stakeholder (especially • Are there overlapping areas (same kind of information
customer) targets and expectations, through its require- in different models)?
ments engineering, specification and early verification & • Describe the models all relevant aspects of the system?
validation activities (virtual simulation), the implementa- • Which information is used within a model?
tion (prototyping and coding) until verification & valida- • How are models linked to each other?
tion activities with the physical existing hardware (hard-
ware-in-the-loop, test bed). Knowing which model is used to describe a certain aspect
During development, many different technical disci- of the system, what information is used in which model,
plines are involved such as mechanics, controls, thermal, as well as how the models are linked and interact in which
electrics/electronics, and others. All of them use specific way is difficult. To support the investigation of this open
models to describe details of the transmission system questions, a classification and structuring scheme is rec-
(as described before the term system model and specific ommended. Therefore Table 1 not only provides a list of
model vary depending on point of view in system hier- models but also the allocation of models to disciplines and
archy. As well, subsystems and parts of the transmission technical domains. The visualization of the table provides
can be described with system models too, but this is not the possibility to support to answer the listed questions
further investigated in this case study). Furthermore, mod- above. Figure 5 shows the ‘cube’ filled with some of mod-
els are used to describe different technical domains of the els in Table 1. The ‘cube’ provides a fast overview of all the
system, subsystem and its parts, such as the transmission used models, their orientation (system model, specific
requirements, its structure, or behavior. In parallel, system model) and placement.
models are used to describe the system by combining all/ After this ‘cube’ is generated it can be used to sup-
some of the discipline and technical domain views. An port the development e.g., by performing analyses. One

Vol.:(0123456789)
Vol:.(1234567890)
Research Article

Table 1  Overview of used models for development of a transmission (non-exhaustive), alphabetically listed
Type of model Discipline Technical domain Note

2D/3D mechanical computer-aided design (M-CAD) model Mechanics Structure Geometry of the transmission and material definition
Computational fluid dynamics (CFD) model Mechanics, electrics/electronics Behavior Thermal, cooling and lubrication aspects of the transmis-
sion, as model for further calculations
Design failure mode and effect analysis (D-FMEA) model Mechanics Structure Possible risks and their effects of the mechanical structure
e.g., gear fracture, incl. their relationships and prioritization
Electrical computer-aided design (E-CAD) model Electrics/electronics Structure, (behavior) Circuit design, PCB-design, chip design, and simulation
(depends on tool)
Finite element analysis (FEA) model Mechanics Behavior Model used for the following simulation, used to investigate
e.g., fatigue strengths of housing, shaft and gears
Kinematic model Mechanics, electrics/electronics Behavior Investigation of the movements and interactions e.g., of
actuators for gear shifting
Mechanical requirements model Mechanics Requirements Similar models for other disciplines (electrics/electronics,
software), but not further listed in this case study
Multi-physical simulation model Mechanics, electrics/electronics, software Structure, behavior E.g., to describe the behavior of the clutches, to optimize the
shift strategy. Continued with simulation as analysis and
verification. The characteristic diagrams are embedded in
transmission control unit
Noise, vibration, harshness (NVH) model Mechanics Behavior Investigation and optimization of NVH effects e.g., of trans-
mission under high load and speed
Preliminary design model Mechanic Structure, behavior Model which describes and optimizes the parameters of the
transmission design
Systems modeling language (SysML) model Mechanics, electrics/electronics, software Structure, behavior Consideration of the transmission system as a whole (inter-
faces, subsystems and parts, relationships, functions, etc.)
often requirements are not modeled with SysML
System requirements model Mechanics, electrics/electronics, software Requirements System requirements of the transmission
Test case model Mechanics, electrics/electronics, software Behavior E.g., to investigate the performance of the transmission on
the testbed, test cases describe which load points have to
be performed
Unified modeling language (UML) model Software Structure, behavior E.g., description of software functions for the transmission
control unit
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0 Research Article

Fig. 5  Cube filled with models

used in transmission develop-
ment

analysis is the identification of gaps (e.g., based on miss- case study models used in transmission development. The
ing verification requirements), empty spaces in the ‘cube’ ‘cube’ is a possibility to visualize the number of used mod-
where no model is used (e.g., should the SysML model els as well as to differentiate between system models and
also be present at subsystem and part level? Why the UML specific models. Further research activities are necessary
model is not used at system level?). Now it has to be inves- to answer the additional listed questions.
tigated why for this empty space no model is used. Some
general questions have to be answered in that case: Is this
view on the system important? What are the reasons for
5 Discussion and conclusion
that? Do methods and tools exist to generate this model?
This ‘cube’ and how it is used in this case study repre-
This section provides a briefly discussed integration of
sents a suggestion for a graphical representation of the
system models in a model-based development approach.
models in the model-based development approach pro-
To understand the position of system models as well as
vides first answer to handle the high number of models in
the role of associated management activities, some basic
development and also shows the challenges and possibili-
principles are shown in a very generic way. Of course, they
ties for further investigations.
have to be tailored to the development environment of
the organization. When tailoring the concepts to a prac-
• Which methods are necessary to generate the models?
tical approach, detailed methods, exchange formats,
• Which inputs and outputs the models have?
specific definition of interfaces between models, etc. get
• Are all the models necessary?
essential, but these are not discussed in this paper.
• Which models are depending from each other?
• Which information is exchanged between the models?
• Which models provide system statements and which 5.1 System model definition
inputs the need from other models?
• etc. To distinguish system models from specific models, the
scope of the model has to be analyzed. The scope of sys-
Another purpose for this ‘cube’ is process and organiza- tem models is to provide breadth and width and therefore
tional orientated. By considering the process and organiza- they incorporate multiple views of at least two technical
tional aspect additional questions such as who is respon- domains or disciplines. On the contrary, specific models
sible for the model, who uses the model in which phase, provide depth by detailing the view of a single discipline
how the information contained in models is updated, and on a single technical domain. System models have the
many others occur. However, these and many other ques- objective to consider and analyze systems as a whole (e.g.,
tions show the importance of classification and structur- behavior of the whole system which is the result of mul-
ing of models used in development, and especially for this tiple subsystems and components acting together) while

Vol.:(0123456789)
Research Article SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0

specific models describe one certain aspect of a system [18]. To achieve an appropriate degree of completeness,
in detail. a multidimensional combination of disciplines, technical
One key conclusion of this paper is the refusal of the domains and levels is used to integrate the system mod-
idea that only one system model for the whole develop- els in a wider context. Furthermore, relevant elements are
ment of complex systems can exist. Centralized thinking properly defined for the purpose of model-based devel-
provides a possibility to better understand and manage opment and the interrelations with other approaches,
the complexity of system development. Nevertheless, especially PLM, are described. To provide consistency,
the feasibility of a practical implementation of a system acknowledged definitions for used terms are considered.
model which is able to act as a central hub for informa- Also, common interpretations of a system model are dis-
tion and communication is depending on development cussed and the SysML view on a system model is incorpo-
complexity and project size. Therefore, there exist multiple rated within the definition. To achieve traceability, stand-
‘central hubs’, used at different phases (horizontal) in the ards established by ISO 15288 [15] and VDI 2206 [27] are
project at different places in the system hierarchy (verti- included and requirements for a system model definition
cal). Single solutions (one system model as central hub, were derived from an analysis of the as-is situation. The
generated and used with a single IT-tool) which perfectly context for the system model is defined by the targets
ensure the horizontal and vertical distribution of infor- and principle of model-based engineering, where also
mation are confronted with massive challenges, and may the main purpose for a system model definition is derived
not fulfil the expectations (usability, content, etc.). Also, from. The most essential idea of model-based develop-
the management of such a model and its tool and the ment should be supported by the use of applicable mod-
included system model would be demanding and requires els, including the defined system model approach.
massive engineer skills (because of model size, number of
views, etc.). With today’s methods and tools, this model 5.2 Application of the model classification scheme
would be enormous, unmanageable and would not deliver
added value for the development considering required To classify several models in development, a scheme was
time and resource efforts in mind. Due to this, the term introduced. This multidimensional scheme (in this case
‘system model’ is interpreted as combination of a limited presented in as three dimensional grid) has the objective
amount of different views, resulting in the fact that there to classify and order system information and associated
doesn’t exist only one system model. These system mod- models. Therefore, dimensions have to be defined (dis-
els are able to provide the required flexibility and other cipline—technical domain—level), which can be visual-
benefits for development project while being realizable. ized as multi-dimensional system cube. This principal
This emphasizes the importance of connected develop- classification scheme for models has to be adapted to its
ment, which clearly has to be tailored to the organizational application which can be done by defining the dimensions
environment. Models described using SysML represent accordingly.
commonly implemented system models. The tools used
for generation of system models with SysML often doesn’t 5.3 Model‑based development context
include functions to perform management activities e.g.,
change management, release management, but that is A huge number of models (system models and spe-
part of PLM anyway. SysML has a different purpose and cific models) is used in development and therefore also
targets (common understanding of the system, base for the generated amount of information is immense. As
discussions, stakeholder interactions, etc.). Further, even described in the section before, models have natural over-
if management activities are carried out in parallel to a lapping zones (same information used in different mod-
centralized SysML model, it is the language which can’t els), which cannot be avoided. This results in the need for
handle all system development relevant aspects and infor- defined interfaces.
mation. Therefore, tailored system models should be used, Another view on the term ‘models’ (system models
which include not all views but instead incorporate the and specific models), simulations and results show the
views needed for a defined development target. However, interfaces and relationships within development, see
an application of SysML is also one possibility for a system Fig. 6. This figure pursues the idea presented in Fig. 2
model, but not the only one. It can be visualized as slice and expands the principal structure for multiple mod-
in the described ‘cube’, with the focus on higher (abstract) els, simulations and repositories in place. Depending on
levels. targets and purpose, multiple models (system models
The presented system model definition, together with and specific models) can exist in parallel. If an ongoing
the ‘cube’ as visualization, is checked regarding the require- simulation is necessary it can be executed based on an
ments for every model described by Madni and Sievers existing model. Therefore, it is expanded by showing

Vol:.(1234567890)
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0 Research Article

Fig. 6  Model-based development

the links with other models, simulations and results Figure 6 provides a generic overview of interfaces between
(which can be models itself ). These links are necessary models, simulations, results and their repositories. These
to provide information for each element which opens generic interfaces have to be tailored to the specific envi-
up opportunities to gain massive benefits from the con- ronment of the organization. Therefore, required infor-
nected development (e.g., up-to-date data, reusability of mation exchange and overlapping models have to be
information, resorting to several sources of information, identified. Relevant information is then being forwarded
etc.). On the one side this is done to achieve effective- to standardized interfaces for data exchange and is also
ness and efficiency in development by reusing already used by methods to generate models, execute simulation,
existing up-to-date information and furthermore it ena- etc. Nevertheless, it is important to emphasize that not
bles traceability and consistency. On the other side this all information is needed everywhere. The challenges to
is also an important contribution to support engineers in connect models, simulation and results, as well as their
making daily decisions by providing the required system repositories, is huge. Maybe an even bigger challenge is
information in form of models. to provide effective and efficient management processes
To achieve the mentioned targets with a model-based and activities for this, to really make a model-based devel-
development approach, applicable management pro- opment approach feasible. Especially the coordination of
cesses and activities are required. Therefore, key factors different approaches like process management, data man-
for successfully implemented model-based development agement etc. is important. With this in mind, the impor-
are model management, simulation management and tance and impact of a PLM approach becomes clear and
data management. The MBE approach requires interfaces shows the essential role of PLM in development.
and relations:

• Interfaces between models are essential to allow reuse 6 Outlook

of already existing information in other models. This
points to the previously explained overlapping areas of These definitions regarding system models should con-
models, which have to be kept up-to-date. These links duct further research and discussions. In future investi-
provide also the possibility to use synergies between gations, these findings have to be reviewed by analyzing
different models. specific use cases and also interdependencies with other
• In many workflows, different simulations need to be approaches like PLM have to be evaluated. Especially
jointed. This co-simulation is also represented by a link the generation and evolution of system models out of
between several simulations. emerging data and information seems to be of interest.
• To allow the exchange of data and information, the Methods for example, alter the system model by adding
repositories need to be connected. more or better information. This filling process of the

Vol.:(0123456789)
Research Article SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0

system model by methods and the resulting evolution of Open Access This article is distributed under the terms of the Crea-
a system model over time have to be further examined. tive Commons Attribution 4.0 International License (http://creati​ veco​
mmons​.org/licen​ses/by/4.0/), which permits unrestricted use, distri-
Furthermore, the triangle model, methods and tools as bution, and reproduction in any medium, provided you give appro-
to be considered to describe and optimized its interplay, priate credit to the original author(s) and the source, provide a link to
the exchange of information, etc. Well defined methods the Creative Commons license, and indicate if changes were made.
(method landscape) can be the enable for a well defined
toolchain to generated and use the model and increase
the quality of the development. The triangle is an ena- References
bler for consistency and traceability, but demands high
resources and efforts to gain these benefits. 1. Albers A, Müller-Glaser K, Schyr C, Kühl M (2007) Model-based
powertrain development. In: Integrated tool chain from design
The popular term digital twin, which is seen as a vir- to validation. ATZ 02I2007, pp 15–17
tual and digital equivalent of a product or system [17], 2. Bajaj M, Zwemer D, Yntema R, Phung A, Kumar A, Dwivedi A,
and the link to (system) models have to be considered Waikar M (2016) MBSE ++—foundations for extended model-
in detail. Two scenarios, representing different point of based systems engineering across system lifecycle. In: 26th
annual INCOSE international symposium. Intercax LLC, Atlanta
views, are identified. An existing digital twin, as result 3. Dori D (2016) Model-based systems engineering with OPM and
from previous development activities, is used to collect SysML. Springer, New York
production and in-use data and is on the contrary also 4. Dvorak D (2013) Model-centric engineering, part 1, an introduc-
delivering data back to development. This should lead tion to model-based systems engineering. http://nesca​cadem​
y.nasa.gov/revie​w/downl​oadfi​le.php?file=SEWG_MBSE_Modul​
to a more efficient development, decreasing develop- e_1_v20.pptx&id=251&distr​=Publi​c. Accessed 08 11 2018
ment and production efforts in parallel to increasing 5. Eigner M (2014) Einleitung—Modellbasierte virtuelle Produk-
quality and availability of the product. Furthermore, to tentwicklung. In: Eigner M, Roubanov D, Zafirov R (eds) Modell-
provide customer services, approaches such as predic- basierte virtuelle Produktentwicklung. Hanser, Munich
6. Eigner M, Stelzer R (eds) (2009) Product lifecycle management.
tive maintenance should be supported. The other view In: Ein Leitfaden für product development und life cycle man-
describes the generation of the digital twin, which is not agement, 2nd edn. Springer, Heidelberg
already existing. It can be interpreted as a derivation of 7. Estefan JA (2008) Survey of model-based systems engineering
a well-working PLM system (in first instance, which uses (MBSE) methodologies. Jet Propulsion Laboratory, INCOSE MBSE
Initiative
the information and relationships from the models) to 8. Farkisch K (2011) Data-Warehouse-Systeme kompakt, Aufbau,
one product with its own serial number. This means a Architektur, Grundfunktionen. Springer, Heidelberg
digital twin can be understood as merged information 9. Fernandez L, Moreno G (2016) MBSE for engineering students.
which is available in a PLM system, but which is then In: 26th Annual INCOSE international symposium (IS 2016)
10. Friedenthal S, Moore A (2012) A practical guide to SysML. The
derived from the PLM system. To manage increasing sys- systems modeling language. Elsevier, Amsterdam
tem complexity as well as to obtain customer satisfac- 11. Gausemeier J, Czaja A, Wiederkehr O, Dumitrescu R, Tschirner C,
tion, model-based development is necessary to increase Steffen D (2013) Studie: systems engineering in der industriellen
development efficiency. Therefore (system) models are Praxis. Tag des Systems Engineering
12. Grebe DU, Fischer R (2018) Entwicklungen für die Mobilität in
an essential base, but further investigations about the einer digitalisierten Welt. ATZ Jubiläumsausgabe 120:86–94
link of system models and digital twin have to be done. 13. Haberfellner R, de Weck O, Fricke E, Vössner S (2015) Systems
In conclusion, the use of multiple system models pro- engineering. Grundlagen und Anwendung, 13th edn. Orell füssli
vides benefits and is a way to cope with the inadequacies Verlag, Zurich
14. Holt J, Perry S, Brownsword M (2016) Foundations for model-
of a central model. The placement of system models and based systems engineering. From patterns to models. In: IET
specific models in a three-dimensional grid, is visualized as Professional Applications of Computing Series. The Institution
cube. With this classification scheme, the model landscape of Engineering and Technology
can be analyzed to identify, for example, overlapping areas 15. ISO:15288 (2015) Systems and software engineering—system
life cycle processes, 1st edn. International Organization for
of models. Standardization, Geneva
16. Kossiakoff A, Sweet W, Seymour S, Biemer S (2011) Systems engi-
Acknowledgements Open access funding provided by Graz Uni- neering principles and practice, 2nd edn. Wiley, New York
versity of Technology. This study was carried out without funding. 17. Lindemann U (2016) Handbuch Produktentwicklung. Carl
Authors are grateful to the Graz University of Technology for provid- Hanser Verlag, Munich
ing the infrastructure. 18. Madni A, Sievers M (2018) Model-based systems engineering:
motivation, current status and research opportunities. Syst Eng
Compliance with ethical standards 21:172–190
19. Maier W, Rechtin E (2009) The art of systems architecting, 3rd
edn. Taylor & Francis Group, London
Conflict of interest On behalf of all authors, the corresponding au- 20. NASA (2016) Systems engineering handbook, 2nd edn. National
thor states that there is no conflict of interest. Aeronautics and Space Administration, Washington

Vol:.(1234567890)
SN Applied Sciences (2019) 1:1074 | https://doi.org/10.1007/s42452-019-1069-0 Research Article

21. OMG (2017) OMG systems modeling language. Version 1.5. An 29. Weilkiens T (2014) Systems engineering mit SysML/UML. In:
OMG Systems Modeling Language Publication, Needham, MA Anforderungen, Analyse, Architektur, 3 edn. dpunkt.verlag,
22. Peschke F (2017) Product lifecycle management (PLM). In: Heidelberg
Kamiske G (ed) Pocket power. Hanser, Munich 30. Weilkiens T, Lamm J, Roth S, Walker M (2016) Model-based sys-
23. Rudolf S, Schrey E (2015) Product lifecycle management— tem architecture. In: Sage A (eds) Wiley Series in Systems Engi-
Herausforderungen einer ganzheitlichen IT-Unterstützung der neering and Management. Wiley, New York
Geschäftsprozesse. Complex Manag J 8–12 31. Zafirov R (2014) Modellbildung und Spezifikation. In: Eigner M,
24. Sommerville I (2011) Software engineering, 9th edn. Addison- Roubanov D, Zafirov R (eds) Modellbasierte virtuelle Produk-
Wesley, Boston tentwicklung. Hanser, Munich
25. Stachowiak H (1973) Allgemeine modelltheorie. Springer, Wien
26. Ulrich H, Probst G (1988) Anleitung zum ganzheitlichen Denken Publisher’s Note Springer Nature remains neutral with regard to
und Handeln. Ein Brevier für Führungskräfte. Haupt Verlag, Bern jurisdictional claims in published maps and institutional affiliations.
27. VDI2206 (2004) Design methodology for mechatronic systems.
Verein Deutscher Ingenieure, Berlin
28. Walden D, Roedler G, Forsberg K, Hamelin K, Shortell T (2015)
INCOSE systems engineering handbook. A guide for system life
cycle, 4th edn. Wiley, Hoboken

Vol.:(0123456789)