See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/281492332

A Novel Approach on Virtual Systems Prototyping Based on a Validated,

Hierarchical, Modular Library

Conference Paper · February 2013

CITATIONS READS

8 1,101

5 authors, including:

Stefan-Alexander Schneider Herbert Palm

Hochschule für angewandte Wissenschaften Kempten Munich University of Applied Sciences
215 PUBLICATIONS 223 CITATIONS 34 PUBLICATIONS 362 CITATIONS

SEE PROFILE SEE PROFILE

Jörg Holzmann
Ostbayerische Technische Hochschule Amberg-Weiden
5 PUBLICATIONS 38 CITATIONS

SEE PROFILE

All content following this page was uploaded by Stefan-Alexander Schneider on 12 September 2015.

The user has requested enhancement of the downloaded file.

 A Novel Approach on Virtual Systems Prototyping Based
on a Validated, Hierarchical, Modular Library

Prof.Dr. Herbert Palm, Jörg Holzmann,

University of Applied Sciences, Lothstrasse 64, 80335 Munich, Germany
palm@ee.hm.edu
holzmann@ee.hm.edu

Robert Klein, Dr. Stefan-Alexander Schneider

BMW AG, Petuelring 130, 80788 Munich, Germany
stefan-alexander.schneider@bmw.de

Prof.Dr. Dieter Gerling

Universitaet der Bundeswehr Muenchen, Werner-Heisenberg-Weg 39, 85577 Neubiberg, Germany
Dieter.Gerling@unibw.de

Abstract

Development of highly innovative systems requires adaptation of standard processes in order to reflect
its specific characteristics. Unknown “best solutions” with respect to system requirements or their
efficacy at development start is one of those most common characteristics in innovation projects. In
those cases adequate tailoring or revision of system development processes may increase quality of
the technical solution while at the same time reducing the involved project risks and costs. This paper
describes a novel methodology to establish Virtual Prototyping for multi-domain system development
by Design Space Exploration (DSE) based on Virtual Systems Prototyping (VSP). VSP comprises four
elementary steps to systematically build up the space of potential solutions. It offers a structural and
dynamic insight view to validate performance indicators against a set of requirements. Our approach
allows choosing the “best solution” within the design phase while simultaneously providing a high
confidence level of its efficacy prior to implementation. VSP, therefore, is a powerful instrument for
increasing the quality confidence level of innovative systems while reducing risk and cost of their
implementation. VSP complements the method of prototyping on system design level inherently by a
tool chain based on a multi-domain validated, hierarchical and modular library. The set of tool
supported process steps makes DSE based on VSP a valuable methodology for effectively and
efficiently developing innovative systems. The authors demonstrate their new approach on the basis of
an automotive example in the context of novel fully-electric powertrain car architectures.

1) Macro Procedural Models: V-Model for Systems Development

System developments usually follow a reference model providing a template sequence of generic
activities. Two kinds of reference models have been established: a) Procedural models and b) Phase
models. While procedural models describe the logical (conditional) sequence of activities, phase
models, in addition, reveal a directed time path. From that point of view phase models may be
considered as instantiated procedural models.

Driven by German Government and independently by Hughes Aircraft the V-Model [1] has been
established since early 1980s as one of the most common procedural reference models for system
development. A sample representation of the V-Model is shown in figure 1. From a Systems
Engineering point of view the V-Model includes two basic principles: A system is supposed to be
designed “top-down” within its hierarchical structure while it has to be implemented “bottom-up”.
 Figure 1: The V-Model

Referring to the nature of any procedural model the referenced generic activities follow a logical rather
than any timely sequence. Loops, therefore, are allowed, for instance when working results as
achieved during component design trigger changes of the hierarchically upward module design.

2) Phase Models as derived from Procedural Models

When asking for the timely sequence of activities within a development the underlying procedural
model has to be transferred into a corresponding phase model. Phase models instantiate macro
procedural models by a specified content and a time-ordered sequence. As the number of individual
activities may grow significantly it is common practice to cluster activities based on specific interim
results. Standard macro elements as a cluster of micro elements are listed in table 1. Milestones,
thereby, mark significant events or results, respectively ( i.e. major decisions and/or deliverables). A
phase model may consist of only one single macro phase (typically “System Build”), thereby defining a
“Single-Phase Model”. Consequently, a sequence of more than one macro phase forms a “Multi-
Phase Model”. Figure 2 illustrates schematically how the V-Model may be instantiated by Single- or
Multi-Phase Implementations.

Macro element Result (defining milestone) Comment

System Build - System Version Vn.m Built to go-live

- Knowledge of basic solution alternatives Hierarchical structure:

Study
- Decision on solution alternative to follow Pre-Study, Main Study,..

Prototype - Realization of a subset of system aspects ”real “ or “virtual”

Pilot - Realization within an artificial environment Allows risk reduction

Table 1: Macro Elements clustering activity sequence sets

A Single-Phase Implementation of the V-Model obviously corresponds to the shortest path of a

sequence activity from top-left to top-right without any loops. Based on this linear activity flow we may
also call the Single-Phase Implementation a “Waterfall-Approach” [2]. This Waterfall-Approach,
however, is linked to a significant drawback: The maximum system feedback time between definition
of a system and knowledge about features and behavior of its realization (if possible at all).
Only at the very end of a Waterfall-Approach development process a system can be validated against
system level requirements of the design phase. As a consequence, we recommend a Single-Phase

Figure 2: Single vs. Multi-Phase Implementation

Implementation of the V-Model only in those cases where the following prerequisites are met:

 All requirements are known and stable

 The best solution approach may easily be picked amongst alternatives that are all known
 The chosen solution to be realized is known and proven to work (on all hierarchical levels)
 Building the entire system is expected to be a “first-time-right”

Under the listed prerequisites a Waterfall-Approach offers the advantage of the shortest possible way
from a problem to its solution within a V-Model approach. Adding phases may be considered a trade-
off between reducing risk of failure versus increasing time and cost requirements. Considering the
value of an additional loop it should be kept in mind that severeness of a failure strongly depends on
its occurrence-to-observation stage of the development gap. “Cost to extract defects” as a function of
a system’s life cycle phase has been investigated by the INCOSE (International Council of Systems
Engineering) and is shown in figure 3 (according to [3]). It clearly indicates the value of an “as early as
possible preventive risk reduction” in system developments.

Figure 3: Benefits of avoiding failures according to [3]

Multi-Phase Models allow reducing system development risks by providing feedback loops. Loops may
provide information on solution alternatives and their capabilities. They allow the clarification and
stabilization of requirements. Loops offer the ability of incremental learning in cycles and to define and
reduce the risk of a “go-life”. These benefits have to be considered versus increasing overall
development time and effort. Table 2 shows macro elements and their specific benefit.

Macro element Useful if .. Comment

.. a full system version is required and/or Sequencing leads to spiral

System Build
.. learning cycles are required model [4]

Pick the best instead of

Study .. best solution approach is not obvious the “first that comes
along” solution

.. proof of concept is missing and/or Applicable during design

Prototype
.. requirements are unclear or unstable or implementation branch

Pilot .. risk of “first-time-right” implementation is too high Allows risk reduction

Table 2: Macro elements versus their useful integration within a V-Model.

3) System development in the context of disruptive innovations

Incremental, evolutionary system changes usually allow reuse of an existing technology base. In
contrast, major changes of system requirements often require a fundamental change of the underlying
base. Development processes for this kind of disruptive innovations usually reveal the following
characteristics:

 A part of the solution space (set of potential solutions) is unknown due to a missing proof of
concept
 The best solution approach cannot be immediately identified, typically even not on top system level

Reflecting table 2 for this context the application of Virtual Prototyping [5] [6] in combination with a Pre-
Study [7] is suggested. The combination of these two macro elements allows a significant risk
reduction at the earliest possible stage of a V-Process based development:

 Identification of all potential solutions as part of the pre-study will ensure not to miss the best one
 System feedback as part of the Virtual Prototyping will ensure a proof of concept

Besides the question of which sequence of generic actions (method) has to be applied a
corresponding tool (technique or technology) supporting the method needs to be identified. The
combination of method and tool/technology will be referred to as “methodology”.

Aerospace industry certainly is more than many other industry segments driven by requirements of
disruptive innovation. New products require fundamentally improved or even new features and
behavior. Technology changes between new generations frequently reveal major rather than minor
steps. In this area of aerospace system development the methodology of “Design Space Evaluation”
(DSE) has emerged addressing all of the characteristics mentioned above. The methodology is
described in detail elsewhere ( [8]) but its basic process steps may be briefly mentioned and reflected
in figure 4:

0) Definition of major top-level requirements

1) Systematic built-up of potential solutions (indicated as yellow dots in figure 4)
2) Selection of those potential solutions meeting top-level requirements (blue circle in figure 4)
3) Trade-off quantification of selected solutions based on Virtual Prototyping (xy-graph in figure 4)
The following chapter will elaborate in more detail how the sequence of DSE process steps may be
integrated into a V-Model to form a Pre-Study (revealing the best suited solution within a
systematically built-up set of potential solutions) with integrated Virtual Prototyping (providing a proof-
of concept for the selected best solution prior to implementation).

Figure 4: Principles of VSP and DSE

4) Systematic Approach of VSP

The methodology of Design Space Exploration (DSE) based on Virtual Systems Prototyping (VSP) is
not limited to any special technology or engineering domain. The automotive example chosen in the
following course of this paper, therefore, is of exemplary character only serving clarification of its use.

Battery electric vehicles (BEV) are based on fundamentally new and disruptive technologies in the
automotive industry. Vehicles based on an electrified power train offer a wide range of architectural
alternatives compared to combustion cars. Only a few of these alternatives have been realized so far.
The total amount of potential solutions that are able to proof their concept is low. Given an application
scenario (“use cases” and requirements) for a new car development engineers are confronted with a
huge set of unknown solutions. When applying our newly proposed DSE based VSP methodology to
the V-Model four basic steps have to be followed as indicated in figure 5 and described in the
following.

Figure 5: The 4 major steps of VSP

Step 0: Definition of top-level requirements

Step 0 reflects top-level requirements based on specific use-cases and related top level expectations.
In our example, a user requests a zero emission urban car (referring to the system use case) with
maximum energy efficiency and reasonable acceleration behavior. The user may decide upon
important quantifiable performance parameters such as energy consumption per km and time to
speed-up from zero to 100 km/h.

Step 1: Building up the Design Space

Step 1 systematically builds up the set of potential solutions (also called “design space”).
In our example, without loss of generality, we limit ourselves to Battery Electric Vehicles (BEVs) and
have to look at potential architectural solutions for their power train. A BEV power train may consist of
one, two, three or four engines. It may integrate a motor within a wheel, close to a wheel or centrally.
Energy may be provided by a high-energy storage (e.g. Lithium-Ion battery), a high-density storage
(e.g. Supercaps) or a combination of both. Torque may be provided to wheels by a fixed, discretely
variable or continuously variable transmission. Other top-level architectural alternatives may be built
up accordingly. A top-level architectural alternative may be any combination of the architectural
aspect variants mentioned. An appropriate tool to reflect them all is the Morphological Matrix (often
referred to as “Zwicky-Box”) [9] shown in table 3. Each line of the matrix shows an architectural
aspect while columns indicate options of it. Table 3 shows the 108 top-level architectural alternatives
of our example.

Option
Architectural Aspect Option 1 Option 2 Option 3
4

Number of engines 1 2 3 4

Engine integration In-wheel Close-to-wheel Centrally -

Energy storage High-energy High-power Combination -

Transmission fixed Discretely variable Continuously variable -

Table 3: Zwicky Matrix of the BEV power train example indicating 108 architectural top-level alternatives

Step 2: Modeling & simulating potential solutions

Step 2 analyses relevant features of individual alternatives based on Virtual Systems Prototyping
(VSP). In our example we evaluate key performance indicators as defined in step 0, specifically
acceleration time and energy consumption.

The example shows typical VSP challenges that arise from their multi-domain character. Most tools for
virtual prototyping are domain-specific, focusing on selected aspects (as relevant within the according
domain) and are limited to a specific frequency range. Modeling and simulation of a multi-domain
system, however, requires concurrency of all involved domains. Therefore, system prototyping
requires overcoming of all multi-domain related challenges. Table 4 lists our solution approaches at
technology level. Specifically, we would like to emphasize our approach of using Co-Simulation to
integrate models implemented in different languages and their domain-specific authoring tools
accordingly. This solution allows us to keep the strengths of all integrated languages [10] [11] and
tools. An integration tool combines all models used and - in the case of our automotive example –
adds a driver and an exterior environment.
 Multi-Domain VSP challenge Solution approach chosen in this paper

Authoring tools and languages are domain-
specific and heterogeneous
Divergence of models (esp. component models)
 Different frequency ranges
 Not runtime-optimized
 Too complex for top level simulation
No integration capability due to…
 Missing standardized interface
 Non-consistent models
Range of validity is unknown on…
 Component level
 Architecture level
Keep strength of authoring tools and create Co-
Simulation environment
Library elements of (controllable)
 Co-simulation using own solver
 Component level runtime-optimization
 Hierarchic behavior clustering
Exchangeability and flexibility due to…
 Use of standardized
Functional Mock-up Interface (FMI) [12]
 Definition and guidance of interfaces
through model templates and object-
oriented class structure
Only validated elements are used
 Validity range (confidence) marked
 Watchdog on architectural level

Table 4: VSPs solutions for Virtual Prototyping

Figure 6 illustrates our top level template of the library for BEV power train VSP to demonstrate the
aspect of “Definition and guidance of interfaces through model templates and object-oriented class
structure”. Individual sub-systems, such as front or rear axle drive, energy storage etc. reveal a
hierarchic sub-structure underneath. The template structure allows and corresponds to the systematic
build-up of the system design space as required for DSE and reflects the V-Model hierarchy.

Figure 6: Top level template of the library for BEV power train VSP

Step 3: Validating & identifying the “best solution”

Step 3 quantifies potential solutions against each other with respect to requirement trade-offs by
simulation and evaluation of all design space elements. When the design space has been built-up as
described in step 1 based on a Zwicky Matrix the underlying simulation runs may also be automated.
Figure 7 describes our tool chain for automatically building up models according to the design space,
simulating them and evaluating key performance indicators.
Figure 7: Tool chain for automatically building up models, simulating them and evaluating key performance indicators.

When all required simulation runs are finalized designers and product engineers may visualize
performance indicator trade-offs between potential solutions. There are numerous ways for
representing these trade-offs. A standard representation of DSE is shown in Figure 8. Individual
solutions are marked by a bullet. Axes represent key indicators. Without loss of generality we
restricted this example to two parameters while the evaluation tool (AVL Cameo) allows up to 30
dimensions to be handled. This seems well sufficient for any top-level system architecture trade-off
decision. In our 2-dimensional sample we can clearly mark (blue dashed line) a so-called “pareto
front”. Solutions corresponding to dots on this “pareto front” [13] are well superior to any other vertical
or horizontal solution but represent a trade-off, in our case energy efficiency versus acceleration time.

Figure 8: Result of the DSE based VSP optimization indicating a pronounced pareto front.

5) Conclusion

In this paper we proposed a novel methodology to establish Virtual Prototyping for multi-domain
system development by Design Space Exploration (DSE) based on Virtual Systems Prototyping
(VSP). The method allows to systematically build up the space of potential solutions (design space)
and offers a structural and dynamic insight view to quantify performance indicator trade-offs. This
allows choosing the “best solution” within the design phase while simultaneously providing a high
confidence level of its efficacy prior to implementation. Based on an automotive example we
demonstrated DSE based on VSP to be a powerful instrument for increasing the quality confidence
level of innovative systems while reducing risk and cost of their implementation. On a tool base we
proposed a novel approach to overcome multi-domain modeling and simulation challenges as required
to systematically support DSE based VSP. The tool chain has been proven to work successfully. The
methodology is not restricted to the selected automotive industry segment and may become a
standard element in all V-Model based system developments based on disruptive innovation.

6) Acknowledgements

The authors would like to mention and thank Eliane Fourgeau from Dassault Systemes, Johannes
Gerl from Modelon, Bernhard Schick from IPG and Dr. Hans-Michael Kögeler from AVL for their tool
and tool related consulting support.

7) References

[1] B. Boehm, „Guidelines for verifying and validating software requirements and design
specifications,“ EURO IFIP 79, p. 711–719, 1979.

[2] B. Boehm, Software Engineering Economics, Englewood Cliffs: Prentice Hall, 1981.

[3] SE Handbook Working Group, Systems Engineering Handbook - A Guide for System Life Cycle
Processes and Activities V3.2.2, International Council on Systems Engineering (INCOSE), 2011.

[4] B. Boehm, „A Spiral Model of Software Development and Enhancement,“ IEEE Computer, pp. 61-
72, 1988.

[5] L. Prowse-Fosler, Virtual Systems Prototyping Ensures Reusable Design Platforms, Vast Systems,
2005.

[6] S.-A. Schneider, B. Schick and H. Palm, "Virtualization, Integration and Simulation in the Context
of Vehicle Systems Engineering," Embedded World 2012 Exhibition & Conference Proceedings,
2012.

[7] Haberfellner, Nagel, Becker, Büchel and v. Massow, Systems Engineering, 11. Auflage, Verlag
Industrielle Organisation, 2002.

[8] W. K. Hofstetter, A Framework for the Architecting of Aerospace Systems Portfolios with
Commonality, Massachusetts: Massachusetts Institute of Technology, Dept. of Aeronautics and
Astronautics, 2009.

[9] F. Zwicky, Discovery, Invention, Research - Through the Morphological Approach, Toronto: The
Macmillian Company, 1969.

[10] P. Fritzson, Principles of Object-Oriented Modeling andSimulation with Modelica 2.1, IEEE Press,
2004.
 [11] H. Tummescheit, Design and Implementation of Object-Oriented Model Libraries using
Modelica, Lund: Dissertation, Lund Institute of Technology, 2002.

[12] Blochwitz und e. al, „The Functional Mockup Interface for Tool independent Exchange of
Simulation Models,“ in 8th International Modelica Conference , 2011.

[13] L. T. Eckart Zitzler, „Multiobjective Evolutionary Algorithms: A Comparative Case Study and the
Strength Pareto Approach,“ IEEE Transactions on Evolutionary Computation, Vol 3, No 4,
November 1999.

View publication stats