Model Based Development MBD

Current methods of automotive embedded system development lead to

Long turnaround time, since the complete behavior can only be tested in the integration
phase.
Lack of continuity between requirements definition, system design, and distributed system
implementation; typically involving different people and with little formalized communication.
Suboptimal solutions: The organizational structures still mirror the mechanical architecture,
and because of a current lack of a systems-level engineering approach for embedded systems
design. (MBD is in place but not in ES development for automotive ES)

The net effect is that systems integration today is a key problem in automotive embedded
systems development. To improve this, model-based development (MBD) is strongly pushed in
both industry and research.

Model-based development is about using computerized models to support communication,

documentation, analysis, and synthesis, as part of the system development.
The models thus form the basis for the interactions between the teams of the organization,
information flow within and between development phases, and for the design decisions made.

A comprehensive framework for MBD

The framework allows formal models, design models, as well as conceptual models as with a

documented syntax and semantics, where the models syntax and semantics must be sufficiently

formal to allow computerized manipulation and some level of automated analysis.

Benefits:

Models are cognitive tools that assist developers in the reasoning and decision-making required
in the design process.

The use of models can help to reduce the system complexity as perceived by developers by
raising the level of abstraction and providing dedicated views with which systems are described.

MBD supports reuse of earlier efforts

Automation of certain design steps

Prediction of system properties.

Role of MBD in automotive systems development:

To aid in managing system complexity

Three aspects of complexity: process complexity, product complexity, and organization

complexity.

The development process faces several challenging, conflicting, and changing requirements.

For example consider, the development of an active safety system providing braking assistance
to the driver.

1. The development has to consider requirements on driver comfort, safety, reliability, and
performance along with a tight hardware cost budget and constraints imposed by existing
functions, components/platforms, technologies, and mechanical design.
2. The different requirements are typically linked to several stakeholders, requiring the
establishment of a mutual understanding and trade-offs.
3. The development further involves the coordination and use of several technologies, tools,
and activities from multiple domains. Integration among these is essential but challenged
by different development speeds (hardware vs. software), tools that do not easily
interoperate, distributed information, and tasks that are distributed over different
organizational entities.
4. The technical heterogeneity of automotive embedded systems also brings along
complexity. The system behaviors are generally nontrivial to predict because of the many
types of entities and interactions, and the resulting large state space of the system. The
organization aspect is concerned with the integration of resources (humans, tools,
information, etc.) from different engineering teams and organizations.

MBD helps in communication, documentation, analysis, and synthesis of designs.

The principal means with which this is achieved include the following:
 Abstraction: Modeling provides the means to define entities and aspects that are useful for

design, such as classes of functions (information generalization), failure modes (quality- or

aspect-specific abstractions), virtual structures (partwhole structural composition), transfer

functions and state machines (abstract behavioral entities), and dependencies (allocation,
refinement)

The definition of such abstract concepts helps in defining simplified, or rather more adequate,
descriptions of the complex real-world in which non useful details are eliminated and where
important aspects are highlighted.

Formalization, parameterization, and structuring: In order for a model to have a well-defined

meaning, and be amenable to analysis and computer manipulation, it must be described using a
well-defined syntax and semantics, determining which models are valid in the context of the
modeling language, their representation, and meaning. The mappings and relations between
several adopted modeling formalisms also need to be formalized.

The concept of parameterization facilitates reuse and enables instantiation of already existing
models, where different concrete numerical values are assigned to model variables in order to
adapt the model for a particular purpose.

Prediction: Through various model analysis techniques it is possible to determine properties of

models. These properties may be directly computable based on the model properties (e.g.,
moment of inertia and logic invariants) or also depend on the model context such as model inputs
or assumptions of the platform and other components (e.g., end-to-end response times and the
relation between faults and hazards).

Visualization:Modeling, through abstraction and formalization, provides means to visualize the

system structure. By means of prediction, for example, through simulation, the system behavior
can also be visualized (animated), improving the understanding of what the system is (structure),
and what it does (behavior).
 Refinement: The usage of successive models, that are related through added detail and by

including more aspects, is supported through the earlier means including abstraction,
formalization, structuring, and prediction.

Traceability: Abstraction, formalization, and structuring provide the means to support

traceability of design information. Together with prediction, this also enables investigation of
implications of changes, supporting change management.

Automation: The possibilities for automation follow from the other means combined with

computer support, enabling automation of all the previously mentioned development activities.
Examples include automated initiation of communication to a certain designer/stakeholder upon
completion of a development (sub) activity, updates of dependent models when changes have
been made in a related model for managing consistency and automated refinement. It can be seen
that automation for some of the activities requires models not only of the product, but also of the

process the development activities.

Driving factors for MBD

Advantages of MBD
Dependencies of MBD