A HOLISTIC APPROACH TO VEHICLE

SYSTEM DESIGN

BY: HANS-JUERGEN MANTSCH, MENTOR GRAPHICS CORPORATION

ABSTRACT
This paper describes an approach to vehicle system design that uses
standardized, hierarchical functions as a single level to describe electrical,
electronic, and software content. Domain-specific implementation levels are
then generated in a synthesis process, and evaluated using suitable metrics.
The focus is on rapid, iterative optimization and on cross-domain architecture
evaluation and validation.

W H I T E P A P E R

E L E C T R I C A L & W I R E H A R N E S S D E S I G N

w w w . m e n t o r . c o m
A Holistic Approach to Vehicle System Design

FUNCTION-BASED SYSTEM ENGINEERING

Functional approaches to describing and developing system architectures are often based on domain-
specific languages derived from UML, such as EAST-ADL or SysML. At the same time, the technical
content description (components of the system) appears in various forms and levels of abstraction (for
example feature, activity, sequence, and/or status diagrams), and then suitably mapped for
implementation.

Figure 1: SysML diagram types (taxonomy), source Wikipedia.

This approach requires considerable effort and is less suited to architecture evaluation than to detailed
documentation. Indeed, to be able to make meaningful technical and financial evaluations of the overall
system architecture, each of the individual levels must be specified until a high degree of detail is
achieved. In the subsequent mapping, the effort increases as the square of the level of detail: the
number of artifacts within the individual levels, for example.

If the calculation of the corresponding metrics is not sufficiently agile, evaluation of a change in function
allocation – for example of a software component on a particular control unit – cannot take place soon
enough to provide truly meaningful results for each individual choice to be evaluated.

Overall, this significantly hampers architecture studies. The provision of the necessary data and
calculations of the desired metrics can, in certain circumstances, take more time than planned for the
entire project!

FUNCTIONAL MODELING
The alternative approach described here uses standardized, hierarchical function models combined on a
single level to describe the technical content of system architecture. In this context, standardized means
that individual functions can be separated from their eventual implementation as a hardware, driver, or
software component. Instead of distributing the models across various, in some cases redundant, levels
the individual domain-specific descriptions can be combined within a single functional abstraction,
thereby eliminating the lengthy mapping process. Communication between individual functions is via
signals that can be standardized as either software, electrical, or bus signals. All artifacts can be linked
with a set of rules from a detailed options/variants model. The component models for hardware,

w w w. m e nto r. co m /e l e c t r i c a l
2
A Holistic Approach to Vehicle System Design

software, and electrical and network communication can thereby be integrated, and their semantic
dependencies checked and validated concurrently using design rules checks.

In this way it is possible to capture the technical, variant-driven content of the downstream
implementation domains (hardware, software, network, and electrical) as early as the functional
abstraction level, and to validate this content across all variants.

Figure 2: Domain-specific processes and upstream functional architecture design.

Figure 3: Functional design.

w w w. m e nto r. co m /e l e c t r i c a l
3
A Holistic Approach to Vehicle System Design

To illustrate this approach, figure 3 shows a number of functional blocks. Software functions (SW), driver
components (D), sensors (S), and actuators (A) are described and displayed within a single abstraction
level. The signals between functions are shown according to their required implementation in the colors
red (SW), green (electrical signals on a PCB), orange (electrical signals in a wiring harness), and blue
(signals on a network).

In figure 4 the individual type allocations correspond to implementation requirements for the
downstream platform. If a function is of the software type, this means that the function is treated as a
SW component in the downstream allocation to a platform: it should be allocated to a control unit and
not to a purely electrical component. Note also that some of the functions and signals are optional,
corresponding with the options/variants model.

Figure 4: Function diagram with various functions, option allocations and references on external function blocks or signals.

Functions can be organized hierarchically, and function signals can both reference their originating
functions (if from an external functional design), and be made available across platforms and projects via
a signal library.

LOGICAL PLATFORM
If the functional designs are captured as described, the downstream implementations (hardware and
software, serial bus systems, and electrical distribution) can be created automatically, always respecting
option/variant relationships.

To do so, first a logical platform is defined. This can be derived from a 3D model in the form of a physical
topology, but can also start as an abstract logical network topology. Via the allocation of individual
functional components to an options/variants model, a logical platform can encompass (in the example
of automotive engineering) an individual car, a range of cars, or all possible derivatives of a car platform
including the variation in software, electrical systems, network, and hardware. The same principle applies
to trucks, offroad vehicles, aircraft and complex electromechanical machines such as industrial printers
and medical equipment. Indeed, an extended system-of-systems such as an air defense system can be
modeled in this way.

w w w. m e nto r. co m /e l e c t r i c a l
4
A Holistic Approach to Vehicle System Design

Figure 5: Diagram with various software-type functions.

The individual nodes of the platform are standardized as resources: electronic control units (ECUs) or line
replaceable units (LRUs), electric assemblies, and electricity or earth conductors. They can be coupled
electrically or via bus systems (CAN, LIN, Flexray, Ethernet, ARINC 429 etc), or indeed by optical or radio
connections. These communication pathways are referred to as carriers.

Figure 6: Platform architecture with the standardized function containers (resources) and connection pathways (carriers).

w w w. m e nto r. co m /e l e c t r i c a l
5
A Holistic Approach to Vehicle System Design

SYNTHESIS
Functions are then allocated into the logical platform. This can be done manually or automatically using
rules. While doing so the functions are interrogated as to their type. For example, a software
component is created from a function of the SW type, and then allocated to a control unit. The signals
passing between functions are assigned to carriers as software, electrical, or network signals within the
logical platform.

The resulting synthesis is the integrated implementation across the four domain types (hardware,
software, network communication, and electrical) of the functional description. Semantic consistency
can be analyzed in real time using design rule checks, and any necessary warnings or error messages
generated.

Figure 7: Rules for allocating functions.

Figure 8: Rules for allocating functions and signals.

Figure 9: Sample diagram of synthesis implementation.

w w w. m e nto r. co m /e l e c t r i c a l
6
A Holistic Approach to Vehicle System Design

METRICS
As early as this synthesis process, metrics for technical evaluation can be calculated. These metrics can
be configured to show a wide variety of information. For example, for multiplex networks interesting
metrics include load, tolerance, and overhead. For the electrical domain they include the number of
wires, splices & connectors, wire lengths, and bundle diameter. For control units they include device
weight, CPU load, requirements for RAM, ROM, FLASH/EEPROM, PCB area & volume power, and thermal
dissipation. The metrics are calculated from parameters attached to functions, resources, and carriers:
these parameters will often be well known from previous implementations.

If a value is above a particular level, for example if the forecast requirement for RAM goes beyond the
budget provided by the microprocessor, alerts will be issued via the design rule checks or directly into
the platform architect’s graphical display. This helps the engineer ensure the design is feasible.

Furthermore, not just technical metrics can be calculated. By extending the calculations project goals
such as cost, weight, headroom, reliability or re-use can also be reckoned.

Figure 10: Example metrics: object count, CPU utilization, network load, and task scheduling.

EVALUATION AND OPTIMIZATION

Because evaluation using these metrics is done in real time, ie when design decisions or changes are
made, this process is ideally suited to evaluating alternative implementations (“architectures”), or indeed
revised functional content. Changes are immediately reflected into the metrics, and alternative
strategies can then be studied. Issues of optimum functional partitioning, electrical optimization, cost,
and runtime optimization can thus be addressed iteratively and interactively.

After the final evaluation, the results of the logical platform synthesis are fed into the downstream,
detailed design process in each domain-specific format such as ARXML, FIBEX, or KBL. The results of the
architecture study phase can thus be re-used as implementation suggestions.for future platforms. In the
case of an integrated design environment, data can of course be passed directly to the appropriate
applications.

w w w. m e nto r. co m /e l e c t r i c a l
7
A Holistic Approach to Vehicle System Design

Figure 11: Comparison of different expansion & optimization stages in terms of the object count,
technical evaluation, CPU, and network traffic measurements.

TYING IT TOGETHER
The approach described in this paper uses the functional abstraction to consolidate the various E/E
domains at a single level. This in turn allows rapid evaluation of implementation alternatives, while
preparing data for use in detailed design.

For such architecture evaluation & validation, existing approaches based on UML or SysML-like meta-
models are less suitable, because of the technical effort and knowledge needed. The related complexity
allows virtually no scope for achieving the adequate or necessary level of detail for a comprehensive
evaluation in the available time.

w w w. m e nto r. co m /e l e c t r i c a l
8
A Holistic Approach to Vehicle System Design

Commercial software based on the principles described in this paper is available within Mentor Graphics®
Capital® product suite.

Figure 12: Functional architecture design & assessment, and resulting implementation proposals for downstream design flow

By contrast, the approach described uses a functional abstraction in which the implementation-related
data and artifacts are combined into standardized, functional models, instead of distributing them across
different, in some cases redundant levels.

As early as during the automated allocation to logical platforms, the models can be iteratively validated
for feasibility of implementation and safeguarded with corresponding technical and commercial metrics.
The result of the architecture process is implementation suggestions for the downstream development
processes for software, network, electrical systems, and hardware.

For the latest product information, call us or visit: w w w . m e n t o r . c o m

©2015 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may
be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.
Corporate Headquarters Silicon Valley Europe Pacific Rim Japan
Mentor Graphics Mentor Graphics Mentor Graphics Mentor Graphics Taiwan Mentor Graphics Japan
Corporation Corporation Deutschland GmbH Room 1001, 10F, Co., Ltd.
8005 S.W. Boeckman Road 46871 Bayside Parkway Arnulfstrasse 201 International Trade Building Gotenyama Garden
Wilsonville, Oregon Fremont California 94538 USA 80634 Munich No. 333, Section 1, Keelung Road 7-35, Kita-Shinagawa 4-chome
97070-7777 Phone: 510-354-7400 Germany Taipei, Taiwan, ROC Shinagawa-Ku, Tokyo 140 -0001
Phone: 503-685-7000 Fax: 510-354-7467 Phone: +49.89.57096.0 Phone: 886-2-87252000 Japan
Fax: 503-685-1204 Fax: +49.89.57096.400 Fax: 886-2-27576027 Phone: 81-3-5488-3033
North American Fax: 81-3-5488-3004
Sales and Product Support Center
MF 10-15 MISC9952-w
Information Phone: 800-547-4303
Phone: 800-547-3000