D I G I TA L E B O O K

A N E E WO R L D R E S O U R C E

The changing automotive

industry landscape
This eBook describes the challenges that go into the WHAT‘S INSIDE
development of electrical and electronic (E/E)
architectures of today’s highly connected consumer 02 The changing automotive landscape

and off-road vehicles and how to simplify the design 09 Facing significant network architecture and
process. To support the next generation of automotive design challenges
products, manufacturers need modern solutions Deploying safe and secure automotive-grade
19
involving advanced electrical, network and software embedded software with V&V
engineering to help keep up with the complexity and
and more >>
shortening product development timelines.

SPONSORED BY
The changing automotive
industry landscape
Collaborating across functional domains
with an increase of E/E architecture,
networks and software
As the automotive industry evolves, the
pressure to develop more advanced E/E
architectures for today’s sophisticated, highly
connected, on and off-road vehicles is growing.
Connected vehicle features are seeing increased
adoption in all categories and segments, while
powerful smart features are becoming available
through the integration of underlying
functions. These advanced capabilities rely on
electrical wiring and electronic components to
function, driving an increase in the number and
sophistication of these components. At the
same time, automotive network design and
software development is becoming more
challenging. Network designers and software
shorter timelines for product development.
Otherwise, they run the risk of falling behind in
the push for advanced and attractive vehicles.
Assisting engineers with interdependent
requirements and technologies
Growing E/E content
A key challenge in modern automotive
architectural design is the decomposition of E/E
requirements from a high-level multi-domain
vehicle model. Multi-domain modelling at the top
level will cover mechanical, E/E, software, thermal
and other domains that make up the final vehicle.
Engineers can extract E/E aspects from this model
to drive the construction of an E/E architecture
and further processes downstream. Multi-bus gateway
Throughout this process, the various architecture
Topology
Modern vehicles are rarely developed from a
clean sheet. Even new market entrants that lack
legacy architectures to re-use, often purchase
electronic control units (ECUs) for less strategic
locations in the architecture. Most programs will
carry forward at least some of the elements or
philosophy of earlier architectures (figure 1).
The move from architectures with a central
gateway toward those with functional domains
connected by a backbone network to a world of
centralized compute with zonal outstations,
comes in stages. The topology often comes with
a baseline set of assumptions, which leaves
engineers to manage the optimization details
(figure 2). Examples could include:
Functional domain Zonal architecture with
controller architecture centralized compute

engineers must synthesize dozens of new engineers concerned with definition,

considerations to support the next generation
design and delivery of modern E/E
of automotive products, including vehicle
architectures must balance many
electrification, electronic complexity,
interdependent requirements.
government regulations, new business models
and automated driving. These requirements include:
Furthermore, cost and time pressures on • Topology
Functional domain
automotive original equipment manufacturers Gateway controller

(OEMs) and systems integrators are • Functional safety (FuSa) ECU

Centralized generic
compute LIN CAN FD
CAN Automotive ethernet/HDBase T
Sensor/actuator MOST A 2B
unrelenting. In fact, the pressure on OEMs and • Cyber security
Zonal controller
LVDS Automotive SerDes/GMSL

integrators to have the right products at the

right time has only increased. These companies
need modern solutions to keep up with the
combined pressures of vehicle complexity and
• Power modes
• Processor, network and gateway loadings
• Component and software re-use
Figure 1. An illustration of the main types of E/E architectural
philosophies. Multi-bus gateway architectures are giving way to
domain controller architectures and, eventually, zonal architec-tures
with centralized computing

2 SPONSORED BY
The changing automotive industry landscape
• Moving an ECU secondary network
connection between domain-focused
networks and a private link between a sub-
set of ECUs
• Upgrading an ECU to support a higher
baud rate network on one or more
connections
• Moving to a new domain to support
advanced or additional functions
Figure 2: Topology
optimization may
include moving
networks connec-
tions, upgrading
E/E Architecture topology decisions ECUs and more.
The transition from a central gateway to a
functional domain-oriented architecture is
typically easy at a topology and connectivity
level. Most ECUs are still connected to a
functional sub-network in either scenario.
However, to receive the benefits of a domain-
oriented architecture, functions need to be
hosted in the domain controllers. This reduces
the need to constantly add more processing
resources to most of the ECUs. Additional
benefits are received when this enables
consolidation of ECUs. Rather than adding more
ECUs, domain controllers are usually an
upgrade or new generation of one of the higher
power ECUs in each domain. The result is fewer
individual ECUs are needed over time with such
consolidation.
Functional Safety
FuSa requirements create multiple
considerations during E/E architecture
definition. Specific considerations will vary by
function, but most of the industry has adopted
the International Organization for
Standardization (ISO) 26262 as the standard for
FuSa (figure 3). ISO 26262 has two overarching
functional categories. Quality management
(QM) functions do not need to consider FuSa
requirements and only need to be developed to
normal quality standards. Other functions are
assigned an automotive safety integrity level
(ASIL), from A to D. ASIL functions are those
that have some potential to undermine the
Figure 3: Example
architecture that
incorporates ECU
constraints when
allocating functions.
Domain controller architecture
Sensor/Actuator
ECU
Functional Domain Controller
Optional fitment
FuSa capable
FuSa of a vehicle in the event of an unmitigated
failure. ASIL A is the most minor level and ASIL
D is the most significant.
3 SPONSORED BY
CO N T I N U E D
FuSa can be achieved in several ways. For
instance, functions in modern vehicles are
usually enabled by various components from
multiple domains. Some of these must be
allocated to hardware or software platforms
that are developed to a specific level of integrity
to ensure the safety of the function. Another
method is to add redundant parts to the
system. Instead of trying to enhance one sensor
system to support an ASIL D function, it is
easier to use two sensors of a lower integrity
level since they can still support an ASIL D
function (figure 4). However, two sensors may
Figure 4: The
combination of two
ASIL B(D) sensors
can support ASIL D
functions.
only allow for fail-safe functionality, which only
requires that the system remains safe in the
event of a failure.
To achieve the next level of FuSa, called fail-
operational and which requires systems to
remain functional despite a failure, a third
sensor, two higher-integrity sensors, another
redundant system or model-based calculation
that fuses data from other sources may be
necessary. An additional FuSa consideration
may be a redundant power supply for critical
components. Dual batteries, dual power circuits
and independent fusing all need to be
considered.
For higher levels of integrity, technological
redundancy becomes more important. This
entails the use of multiple technological
approaches to achieve the same function. A
The changing automotive industry landscape
prominent example is the array of sensor types
used to enable ADAS and self-driving features
in modern vehicles. Most use a combination of
radar, camera, LIDAR, sonar and other sensor
types, with multiple versions and devices of
each type installed on the vehicle (figure 5).
Each of these sensor types has different
strengths and weaknesses, such as range,
Long-range radar
LIDAR
Camera
Short-/medium-range radar
Ultrasound
Figure 5: Overlaying redundant sensors enables ADAS
and self-driving systems to achieve higher levels of
functional safety integrity.
weather tolerance, object detection and more.
The complete system can build up a dependable
and accurate understanding of its surroundings
by fusing data from each sensor type.
From these considerations, some rules and
guidelines for E/E architects can be derived that
cover both the development of the base
architecture and the allocation of functions to
that architecture (including how functions are
partitioned). One guideline could be to
decompose FuSa requirements where possible.
CO N T I N U E D
In a common use case, data gathered from
sensors with redundancy, either from a duplicate
or backup sensor, can be processed on an ECU of
a lower integrity level than needed by the whole
system if the redundant sensor and data
processing are separated. The system can
achieve its required safety integrity through the
combination of sub-systems and elements which
may not all individually delivery the full system
goals.
The result is the architect can allocate input,
processing, decision and action functions to
appropriate ECUs based on their attributes and
redundancies in the system. These FuSa
CYBERSECURITY
requirements constrain the architect’s options
for functional allocation. Yet, there are further
considerations. Want to learn more about multi-layered
Design tools need to include attributes for every approaches to connected vehicle security
function, signal, ECU and all other element and how to protect vehicle entry points as
types, with extensible properties to support well as in-vehicle networks? This white
architectural studies. The properties list can be paper covers several security strategies
expanded per the needs of the OEM and used for
including embedded firewalls,
trade studies using instant metrics and rules to
ensure designs meet the defined goals and authentication, secure communications,
encryption and digital certificates.
standards.
Cyber security White Paper: Modern automotive
FuSa and cyber security share some surface cybersecurity through secure
similarities: both concern the correct
communication, strong authentication
functionality of vehicle systems. But while FuSa
and flexible firewall
is mostly concerned with the reliability of
systems and the consequences of failures, cyber
security must account for malicious attacks CLICK HERE TO VIEW
against vehicle systems. As a result, cyber THE WHITE PAPER
security has distinct requirements aimed at
defending against such attacks.
Modern vehicles have multiple potential
vulnerabilities, known as attack surfaces.
4 SPONSORED BY
The changing automotive industry landscape CO N T I N U E D

Table 1: A summary of typical basic power modes. Table 2: An expanded summary typical for vehicles with electrified powertrains.1

Integrated Wi-Fi, cellular, Bluetooth®, on-board
diagnostics (OBD), universal serial bus (USB)
and other connection points all provide
potential routes to the vehicle communication
systems. Even network bus circuits have been
accessed as entry points, usually for theft
purposes. These attack surfaces can be
considered in architecting of the anti-theft
systems. Some systems can be made physically
inaccessible to malfeasants, while others may
use extra software authentication checks to
prevent unauthorized access. However, it is
strongly desirable to have both. The choices
made on cyber security and anti-theft systems
cascade requirements out to the 3D electrical
system design via the logical systems
containing security functions.
Design solutions that can link the 3D and
electrical worlds with rich data and can
differentiate the types of signals and their
physical manifestations, are vitally useful
throughout the concept stages to verify
designs.
Cyber security is achieved with a layered
approach. Some mechanisms are repeated at
key points in the architecture and different
mixtures of mechanisms are applied at each
level in the system. The placement of
firewalls, or connections of interfaces on ECUs
that feature firewalls, need to be considered
with respect to the various entry routes that
an attack can use to gain access to the
vehicle. ECUs hosting specific functions may
also be required to contain integrated
hardware security modules (HSM). It is
possible to emulate an HSM in software by
careful selection of the integrated circuit (IC)
at the heart of the ECU. This emulation is very
demanding of processing resources, so
hardware-based security measures are gaining
popularity. Data classified as cyber security
related can also be designed with specific
protections to add extra layers to the cyber
security system.
Like FuSa, software tools that use attributes and
properties enable designs to include security
functions and requirements. Design rule checks
(DRC) enable engineers to check the design
against defined rules and diagram styling
enables easy visual understanding and auditing
of those details.
Power modes
Modern road vehicles often have multiple power
modes, some visible to the user, others relatively
hidden. These reflect the functions active in the
vehicle and govern what is powered and/or

1. Table 2 shows a simple example. In practice, there is more to resolve, such as:
•S
 oftware updates that require selective update of target networks and ECUs.
•S
 oftware updates of charging ECUs require interlock and handover logic.
•*
 Regional differences in the nature of interactions between charging and powertrain activation.
•*
 *Some regions require blocking of powertrain activation while on charge. Others call for charging to be suspended in the event of powertrain activation.
Also, further refinement is needed for inductive charging where no disconnect is needed.

5 SPONSORED BY
The changing automotive industry landscape
awake. A vehicle with a traditional key will
usually have four positions on the ignition
switch, translating to four to six power modes,
from off, locked, to cranking (table 1).
Many OEMs use terms such as KL15 (also known
as Contact 15) and KL30 associated with tables 1
and 2, at the right and below. Derived from the
German Institute for Standardization (DIN)
72552, some OEMs use many more power
modes while others have their own specific
terminology. Some use several state tables that
merge. For example, a basic power mode with a
second state machine to handle the activation
and deactivation of the powertrain. This
arrangement is increasingly likely in an electric
vehicle, as the above basic table does not include
electric powertrain-specific power modes, such
as a charging mode.
Table 3: Examples of typical ECU processing types per functional domain.
In modern vehicles, functions need to be
hosted on ECUs that are powered up when the
function is needed. As a result, the functions
hosted on an ECU can influence when the ECU
needs to be powered. This second point is
increasingly important: if a function is needed
during charging of an electric vehicle, the ECU
that hosts the charging-related function will
need to remain reliable over a life up to 10
times longer than an ECU only used when the
vehicle is in motion.
This extends further when service and
diagnostic functions are considered, such as
software updates to the vehicle. Software over
the air (SOTA) updates will be increasingly
common, rather than the service center update
that has become practically universal in recent
years. Over the air updates require another
6 SPONSORED BY
CO N T I N U E D
partial awake mode. When the vehicle is
powered off or asleep, waking a domain or
network at a time will be enough to perform the
update. In other cases, such as vehicles that are
not plugged in to charge, downloading the
software in the background when the vehicle has
signal is a more cautious approach. At the start
or end of a drive-cycle, the vehicle can request
user permission to perform the update. The
architect needs to consider these low-power
mode states and which module will host
downloaded updates prior to deployment.
Processor, network and gateway loads
Another important architectural consideration is
the relative loadings on each ECU processor,
network or network branch and the gateways
between networks. As functions are allocated to
specific ECUs, their associated signals will place
additional load on the networks connected to the
ECU. If direct connections do not exist between
the signals’ respective sources and destinations,
then a gateway is needed to make the
connection. Each new gateway increases the
gateway load and the frequency signals must be
sent to deliver a given timing. Further, in a
functionally oriented domain architecture, it is
likely that the routing of status and mode
information signals may need to travel across the
network back-bone, potentially resulting in two
gateways. Cross-linking between networks is
increasingly undesirable as it makes functions
critical to cyber-security much harder to defend
as more routes around the architecture become
available for malicious actors to traverse.
Consequently, the E/E architect benefits from an
understanding of each of the functions planned
for the architecture when optimizing the
networks and domains that each ECU is
connected to.
The changing automotive industry landscape
As mentioned earlier, a design tool that enables
trade studies of multiple allocations and can
predict the consequences of each allocation can
save substantial time and support the delivery
of correct architectures the first time. When
considering functional allocations to ECUs, it is
important to consider the specific type of
processing in each ECU. The main processing
ECUs in each domain have differing
characteristics (table 3).
When functions are added to an architecture
during an update, they need to be split and
assigned appropriately to ECUs suitable for
running each type of function.
Image processing has very different needs for
decision making and control outputs. Image
and radar processing are soft real-time
processes, where the series of images are
processed into objects, cars, cyclists, road signs,
road markings, etc. Trajectories will also be
processed where relevant. Soft real-time
processes have a deadline by which time the
data must be processed to enable accurate
control decisions. The actual processing time
has variation, thus high-power compute results
in a more consistent delivery. Control and
output decisions, on the other hand, are often
hard real-time processes, requiring much less
processing power.
Hard real-time processes are extremely time-
sensitive and must be executed in a small-time
window in a regular processing period. This
kind of process may be scheduled at a high
frequency, but could also be triggered by an
engine crank angle, motor rotor position, etc.
Examples range from the control of fuel
CO N T I N U E D
injection on direct injection petrol and
diesel engines, to the control of active
suspension components, anti-roll (anti-
sway) bars, dampers and more.
Typical body functions, such as lowering
a window, can respond in milliseconds
and provide a satisfactory user
experience (UX). However, certain
functions can introduce an ASIL and
hard real-time requirement to these
body functions. For example, an anti-
trap function on an automatic window
close feature, uses a closed-loop control
with sensor feedback to stop and
reverse the motion of the automatic Figure 6.
window in the event of a detected
blockage, such as an arm or finger. With the
anti-trap function, the feature operation of the other inputs or outputs. Conversely, carry-over
windows is considered to include safety related and purchased ECUs bring in constraints that
functions. Therefore, consideration must be define how parts of the architecture can work.
given to the appropriate hosting of the
ECUs normally have a fixed count of I/O once in
automatic or one-touch window feature in
production. In development, they are
parts of the architecture with sufficient
constrained by the selected silicon, available
integrity and timing capability. In general, body
space on the PCB and by the desired
functions are highly distributed, using sensors
connectors. During development there may
and actuators placed around the cabin to build
also be scope to convert certain pins from
up sophisticated comfort and convenience
inputs to outputs, analog to digital or to data
features (figure 6).
buses. Opportunities for these conversions
Input/output (I/O) connectivity – ECU/sensor/ must be frozen at some stage. After this,
actuator connections can only be made to the I/O the
New custom ECUs are sometimes, cost ECU already has. It is often possible to process a
permitting, able to be specified exactly as sensor value in the ECU the sensor is connected
needed. More commonly, new ECUs are derived to and monitor for hardware faults and other
from a platform design, limiting the capabilities errors. The decision function(s) utilizing the
of the ECU and both the type and total number sensor data may be elsewhere on the vehicle
of connections to the vehicle networks and due to other requirements.
7 SPONSORED BY
The changing automotive industry landscape
Re-use
It is not practical to develop every vehicle from
a clean sheet. Re-usability of vehicle features,
functions and systems, which was once
desirable, is now essential. E/E architecture
optimization and effective systems design are
critical to maximizing re-usability, reducing the
number of vehicle variants and improving
companies’ ability to deliver the right vehicle
on time.
When a new or updated vehicle line is being
developed, there are typically constraints
established around the re-use of vehicle
content. Some of these constraints are firm,
while others need to be evaluated in
consideration of the relative costs associated.
Traditionally, ECUs sourced from tier 1 suppliers
have limited scope to add functions unless the
supplier is contracted to develop such
functions. OEMs are taking more responsibility
in developing some ECUs, software models and
sometimes full software. Today, this can even
extend to the hardware for strategic modules
and, in selected cases, as far as designing the
silicon.
When the architect considers where functions
can be allocated, the type of ECU, installed
software and its source are a consideration. It is
also important to consider if there are plans for
the ECU to have upgrades or enhancements
over its lifetime, to hardware and/or software
functions. Ideally, these considerations are
accounted for when the OEM is deciding which
ECUs are strategically important. This will help
provide the scope for functional allocations
over the life of the ECU and architecture.
CO N T I N U E D
Conclusion
The challenges facing OEMs developing E/E
systems are numerous, varied and only
increasing in complexity. These challenges
are particularly acute at the stage where E/E
architectures are being defined and
evaluated. There are many considerations
that E/E system architects must include
when developing, updating and optimizing
vehicle architectures. These can typically be
characterized as attributes or properties of
the function, ECU, signal, port and so on.
Therefore, it becomes necessary to use
advanced tools such as Capital™ Systems
Architect to plan and check the architecture
AUTOSAR
against a set of rules and guidelines defined
by the engineers. Capital is part of the
Why is AUTOSAR the leading solution for
Xcelerator portfolio, the comprehensive and
integrated portfolio of software and services automotive software platforms? How can
from Siemens Digital Industries Software. development teams benefit from a
Furthermore, with extensible rules, it is comprehensive AUTOSAR solution? Watch
desirable to automate assignments and this webinar to find out, and also be
allocations, according to the rules defined.
introduced to an overview of the features
Insight metrics enable trade-studies
and characteristics of VSTAR support
between topological changes, functional
allocations, signal assignments and more, including functional safety, cybersecurity,
supporting early optimizations of the E/E and advanced E/E architectures.
architecture before detailed design work
Webinar: Evolution of AUTOSAR
begins. Taking advantage of innovative tools
in automotive
enables engineers to verify architectural
decisions early. This is increasingly critical as
automotive competition becomes more CLICK HERE TO VIEW
intense and E/E architectures become more THE WEBINAR
important in delivering products that
delight consumers.
8 SPONSORED BY
Facing significant network
architecture and design challenges
Technological context
The E/E architectures used in the automotive
industry today are highly complex, with many
vehicle features delivered by functionality
distributed across multiple discrete ECUs.
Commonly, the ECUs, sensors and actuators are
not all directly connected and much of the data
communication takes place across networks,
with gateways over several networks. Modern
E/E architectures have become more formally
organized around functional domains,
increasingly with domain computers or
controllers acting as a centralized compute and
absorbing much of the higher-level functions
for that domain.
The next trend is the increasing use of service-
oriented architectures (SOA), enabled by
Ethernet networking. This enables principals
from the information technology (IT) domain to
be re-used in automotive applications. The
main evolution with such an architecture is the
move from thinking about discrete signals to
services, which often provide multiple related
signals. Functions now provide and subscribe to
services according to their functional needs.
Moving towards an SOA is happening in parallel
with changes to the physical architecture.
Computing power is increasingly centralized,
with domain ECUs being re-organized into a
zonal layout. Some OEMs and integrators opt
for high computing power in the zonal ECUs
that reside near the sensors and actuators,
while others aim to keep them in simple
gateways. Furthermore, moving away from
functional domains cascades high integrity
requirements into more ECUs across the
architecture.
The forces driving OEMs towards centralized or
zonal architectures are broader than only
reducing the ECU count in vehicles. These
architectures can streamline the functionality
scalability, with processing and memory
headroom only needing to be provisioned in
the central compute unit. Centralized or zonal
architectures can also help reduce harness mass
and lower bill-of-material (BoM) costs to the
Multi-bus gateway
architecture
Functional domain
Gateway controller
Centralized generic
ECU
compute
Sensor/actuator
Zonal controller
9 SPONSORED BY
OEM. It is worth noting that the speed of this
transition is variable across organizations,
regions and vehicle market sectors. Well-funded
OEMs known for selling premium passenger
cars are usually seen as the first movers, but
there are also regional variations and new
entrants that do not conform to the traditional
timelines of automotive companies and some
advanced vehicles in more specialist market
segments.
Usually, these design challenges can be
considered by the network designer in relative
independence. But, each design decision has an
impact on the full system. This impact should
be considered at the time of design, allowing
Functional domain Zonal architecture with
controller architecture centralized compute
Figure 7. Centralized versus zonal architectures.
LIN CAN FD
CAN Automotive ethernet/HDBase T
MOST A 2B
LVDS Automotive SerDes/GMSL
 Facing significant network architecture
and design challenges CONTINUED

system testing later in the process to confirm Besides the media functions that may be hosted With the cluster example, it is common for
correct behavior rather than uncover issues that in the infotainment portion of this system, displayed data coming from a specific control
require design iterations. there are many other pieces of critical ECU or sensor to potentially need some
information to convey to the driver, ranging smoothing or processing in the cluster.
The instrument cluster, central display(s) and
from vehicle speed and faults, through to Meanwhile, data from a domain controller or
heads-up display (HUD) are increasingly part of
driving modes, ice warnings, navigation mode function, such as a chassis mode for off-
one integrated system, an extension of the
directions, estimated range, etc. Some OEMs road or sport driving, may need to be more
driver information and infotainment systems.
refer to the cluster as a combination meter, as it heavily processed to resolve a status or adjust
However, there is often more information in the
reflects the history of bringing together what the context or highlighting of information to be
instrument cluster with FuSa considerations.
was once multiple instrumentation gauges, ready for presentation.
Therefore, several partitions are still required
warning lights and trip computer elements into
on the compute platforms that host these
one system. Modern domain consolidation is in
functions. These partitions may be separate Network load, gateway load
line with these historical examples, which
processors or separate cores. These systems
illustrates the pattern of functional growth In the days of controller area network (CAN) to
may have discrete LEDs, switches and other
after each consolidation. Every time functions CAN gateways, the network designer had a
peripherals connected to fully meet their
are consolidated, new functions are added in choice between gatewaying whole frames of
requirements. However, traditional automotive
new components or ECUs - from trip signals or each signal individually, re-packed
vehicle control switchgear is often connected to
computers, clocks, temperature gauges to ice into a new frame. This provided a simple trade-
a body controller or gateway.
warnings.

Gateway Gateway Figure 9. An example subset of signal flows.

Figure 8. An example
subset of ECUs in a
vehicle architecture.
Central Central
Propulsion Chassis Cluster Propulsion Chassis Cluster
display display

Rear seat Rear seat

Door Inverter Dampers Door Inverter Dampers
display display
Example signals
Motor power
Seat DCDC Anti-roll Amplifier Seat DCDC Anti-roll Amplifier
Battery charge
Chassis mode

Battery Air springs Battery Air springs

10 SPONSORED BY
Facing significant network architecture
and design challenges
off between more processing at the gateway or
less-efficient use of network bandwidth. That
compromise is still made today — AUTOSAR
provided protocol data units (PDUs) as a design
element to support gatewaying between
different network technologies. This
streamlines the gatewaying of PDUs, while
preserving the option of reading out individual
signals and repacking them in a new PDU.
This basic compromise is much more
complicated in detail. The designer may need to
consider how the gateway will trigger sending
the gatewayed data it is forwarding, which
influences the overall latency across the
system. In practice, this is often constrained by
re-using existing ECUs or frame and PDU
designs that support an integration with a
supplier across multiple vehicle programs.
However, some OEMs prefer using an existing
library of pre-designed network messages with
pre-defined frame packing to support ECU re-
use without changes. The use of a standardized
protocol, such as the Society of Automotive
Engineers (SAE) J1939 for heavy-duty and off-
highway vehicles, provides the ability to
connect vehicles and equipment of different
brands together reliably. Both approaches
reduce the scope for optimization by the
designer, but do not reduce the need to
consider the performance and behavior of the
design.
Networks designers follow design defined by
the respective OEM that consider many
technical details of the system. For example,
the prioritization or scheduling of each network
technology must be considered. The Local
Interconnect Network (LIN) and FlexRay are
CONTINUED
time triggered networks with a schedule.
Although, FlexRay’s dynamic segments give
some flexibility for event-driven data and
variations in payload size. CAN uses an
arbitration mechanism based on the frame ID.
This means that in most designed networks
there are frame ID ranges reserved for different
types of payloads. This includes both functional
and network management needed to run most
networks and occasional data such as service
and diagnostics. Higher priority is often
assigned to data that would affect vehicle
functions with variable jitter.
AUTOSAR AND
The use of a model-based design tool permits a HYPERVISOR
left-shift of network validation by
understanding the behavior of the network and
the consequences of design decisions in worst
Download this paper to understand an
case scenarios. Capital Networks software has
efficient way to reduce the cost of adding a
inbuilt models allowing the worst-case
consequences of design decisions to be dedicated micro-controller to each
predicted, confirming the validity of the design. platform. This paper describes types of
Rules for frame IDs, consistency of frame hypervisor available and their
packing and the correct configuration of characteristics, as well as a practical
gateways can all be checked and confirmed to
example involving AUTOSAR. Learn how a
be correct-by-design. Further generative
hypervisor can be used as a reliable
automation accelerates laborious task
completion, saving time and reducing manual solution for consolidating both
errors. infotainment and AUTOSAR applications on
the same ECU!
Ethernet and switches White Paper: Using Hypervisor for IVI
There is an increasing need to consider more and AUTOSAR Consolidation on an ECU
network technologies across the architecture.
Ethernet first appeared in the infotainment
system or diagnostics over intellectual property CLICK HERE TO VIEW
(IP) (DoIP) systems. Now, it is frequently THE WHITE PAPER
expanding across domains, forming a backbone
between the functional domain controllers. At
11 SPONSORED BY
Facing significant network architecture
and design challenges CONTINUED

Table 4. A quick reference guide to common automotive network technologies.

Network Max baud Max frame AUTOSAR Priority/

this point, Ethernet design, including switch Segregation Topology
rate payload support timing
configuration, may expand from a topic specific Physical
LIN 20 kbps 8 Bytes Y Schedule Linear
to the network traffic of a single domain to network
include more general vehicle data (for example, CAN 1 Mbps 8 Bytes Y Priority
Physical
Linear/Star
network
data passing between traditional networks and
Physical
Ethernet, benefitting from full system CAN-FD 8 Mbps 64 Bytes Y Priority
network
Linear/Star
considerations). In Physical
CAN-XL 10 Mbps 2048 Bytes Priority Linear/Star
development network
Initially, using Ethernet adds another set of
Physical Linear/Star/
network behaviors to consider and a more FlexRay 10 Mbps 254 Bytes Y Schedule
network Hybrid
complex set of standards and protocols. Physical
MOST25 25 Mbps 64 Bytes N Schedule Ring
However, these are more scalable than network
specialized automotive networks, with the 10Base-T1S 10 Mbps 1500 kB Y AVB/TSN VLAN Linear
same communication software used regardless 100Base-T1 100 Mbps 1500 kB Y AVB/TSN VLAN
Switched
flexible
of Ethernet physical layer type. This makes
Switched
updates easier over time. As Ethernet networks 1000Base-T1 1 Gbps 1500 kB Y AVB/TSN VLAN
flexible
can interoperate at multiple baud rates, it can
be used across a large section of the vehicle, Table 5. Audio Visual Bridging (AVB) was originally Table 6. Time Sensitive Networking (TSN) was developed from
reducing the technological complexity. Media created for audio/visual media streams. AVB as an expansion to include necessary elements to support
high integrity use cases of automotive.
Oriented Systems Transport (MOST) is already
AVB IEEE standard
fading from use and was never incorporated IEEE
Time Sync gPTP 802.1AS-2011
into AUTOSAR. FlexRay and high-baud-rate CAN TSN
Stream standard(s)
have an ever-reducing set of use-cases for Reservation reservation 802.1Qat Redundant Time
which they are the ideal solution. Only time will protocol gPTP 802.1AS-2020
Sync
show if 10Base-T1S or CAN-XL can fully take Credit based
Quality of service 802.1Qav Stream reservation
over for networks where a 10 megabits per shaper Reservation 802.1Qcc
enhancement
second (Mbps) network is utilized. Transport protocol AVTP 1722
Path control and
Transport protocol RTP over AVB 1733 Reservation 802.1Qca
Ethernet networks introduce additional reservation
configuration options for the network designer. Quality of service Time aware shaper 802.1Qbv
Protocols, methods and elements of different of bandwidth utilization) and even disabled. A 802.3br and
Quality of service Frame preemption
levels can be used to ensure that priority data, specific VLAN may be used to implement 802.1Qbu
signals and services are available in a timely software updates, which allows regulation of Cyclic queue
Quality of service 802.1Qch
manner while allowing multiple types of data the bandwidth utilized for specific functions, forwarding
on the same physical network. depending on the vehicle status or mode. Asynchronous
Quality of service 802.1Qcr
shaping
Meanwhile, virtual local area networks (VLANs) Audio visual bridging (AVB) was initially created
Frame replication
are used to segregate different types of data to add specific shaping or prioritization of audio Redundancy 802.1CB
and elimination
and enable these data types to be prioritized, and visual data flows on Ethernet networks.
Transport
limited (in terms This ensured that audio and visual data could AVTP 1722-2016
protocol

12 SPONSORED BY
Facing significant network architecture
and design challenges
be sent across the network without distortions
due to variable data rates. AVB was adopted by
early automotive Ethernet users, usually in
conjunction with scalable service-oriented
middleware over IP (SOME/IP) and service
discovery (SD), as a method to enable SOA
communication. Time sensitive networking
(TSN) is a development of AVB specifically for
functions and use-cases that have high integrity
requirements, such as automotive. TSN extends
some of the elements of AVB, while also adding
others that were not available before.
AUTOSAR has directly included or supported the
above technologies and standards as needed.
This has avoided the need to reinvent
technology that was originally developed for
specific purposes. Standards and functionality
needed by both classic and adaptive versions of
AUTOSAR are standardized in the Foundation
standard, enabling compatibility and
consistency.
Classic platform Adaptive platform
Foundation
Figure 10. The Foundation standard of AUTOSAR
provides functionality needed in both the Classic and
Adaptive platform versions.
In the instrument cluster example, any
information displayed to the driver must be
current (an adequate maximum age from the
original measurement or calculation), to
represent the actual state of the vehicle.
Examples include a fuel gauge or battery state
of charge reading or trip computer functions.
The charge or fuel level reading should not
CONTINUED
Gateway
Propulsion
Door Inverter Dampers
Seat DCDC Anti-roll
Battery Air springs
change quickly and can likely be updated once
per second, potentially with some damping. An
energy usage reading, such as a power gauge,
instantaneous fuel consumption or similar
graphic will need more frequent updates. These
elements of similar data will come from
different ECUs — one from a battery
management ECU or fuel tank sender and the
other from an inverter or powertrain control
ECU. Although, these are sometimes
consolidated.
Network design tools are vital to enabling the
correct implementation of these protocols and
standards, both traditional automotive
networks such as CAN, and those utilized in the
automotive industry like Ethernet. Model-based
design tools support consistent
implementations, predicting configuration
13
Figure 11. Apparently similar data
may come from different sources.
Central
Chassis Cluster
display
Rear seat
display
Example signals
Motor power
Amplifier
Battery charge
problems and mismatches across the full
architecture. Capital Networks facilitates the
consistent design of data signals, and
implementation of protocols across full
architectures, considering vehicle variants,
options, and the different technologies used.
Sophisticated design tools can model full E/E
architecture behavior, including timing,
bandwidth utilization and other performance
measures. These models can also consider the
characteristics of each technology, and the
prioritizations and allocations made for the
data types in use. Configuration of VLANs, the
assignment of the relevant subset of ECUs to
each, the audio visual bridging (AVB)/time
sensitive networking (TSN) priorities and more
can all be managed centrally in the system design,
ensuring consistent and correct implementations.
SPONSORED BY
Facing significant network architecture
and design challenges CONTINUED

Functional Safety: A networks perspective
Network designers have been designing with
FuSa in mind for many years now and in most
cases the mechanisms used are well understood.
The larger data elements and objects used with
higher levels of driver assistance and automation
have added updated mechanisms or schemas in
recent AUTOSAR releases.
The conventional approach with networks is to
treat them as quality measures (QM), as a
mechanism, which is defined in ISO 26262.
Where required elements are added to the
design to validate the data is being received
regularly and accurately. Increasing system
integrity requirements now demand redundant
routings for some data, but this is often a
system-level design consideration and will only
be encountered by the network designer as
additional design rules. For instance, a design
rule may prevent the routing signals A1 and A2
on the same networks from sender to receiver.
Data that carries a potential safety consequence
if incorrect or missing primarily receives end-to-
end (E2E) protection. A group of signals are
packaged in a common message or PDU and
treated as a single entity in terms of the
network bus, gateways and COM stacks. These
grouped signals have a cyclic redundancy check
(CRC) calculated for them, some form of
counter (alive, frame or other depending on the
scheme chosen) and a data ID. Although, other
methods can be used to overcheck the identity
of the group. These protection methods are
identified as schemas by AUTOSAR, which has
included common mechanisms used to provide
the protections, including the CRC calculations.
This allows OEMs and systems integrators to
shape their own design rules according to the
risks identified in their system design
methodology.
The network designer groups signals based on
the functional requirements identified in the
systems design phase and structures these
groups in the network design, or re-includes
the groups in the case of carry-over from
existing projects. Documentation
demonstrating that the design fulfills
requirements, rules and standards in place
supports auditing of the application of E2E
protections. These mechanisms are set by the
sender and used by the receiver to confirm
that the data is fresh, valid, and from the
correct sender. However, the integrated
protections are only designed to defend
against errors and faults and not targeted
malicious actions. Thus, the system design
must be robust enough to cope with correct
data occasionally being rejected or invalid
data being accepted, both infrequently and
usually as single occurrences. With over
thousands of hours of usage of millions of
vehicles, these infrequent events will occur
sporadically.

FUNCTIONAL SAFETY
Automotive megatrends of electrification, connectivity, and automation
have intensified the necessity for functional safety. Consumer
expectations for end-user vehicle functionality have also increased
demands on CPU performance. Watch this webinar for practical design
examples, including a system-level framework for partitioned
communication introduced into the AUTOSAR ECU systems.
Webinar: Architecting vehicles for functional safety compliance

CLICK HERE TO VIEW THE WEBINAR

14 SPONSORED BY
Facing significant network architecture
and design challenges
For E2E protection to be meaningful, the
sending and receiving ECU need to be designed
with appropriate FuSa considerations.
Protecting a signal which may have been sent
incorrectly due to software of inappropriate
integrity renders the protection meaningless
and a waste of bandwidth. Further, the frame
headers of most network types contain some
protections that will cause the data in the
frame to be rejected if a basic fault is detected.
Although, these usually are not considered to
be robust enough for application level data
checks, and are only suitable for bus level
errors.
The information presented to the driver is of
mixed criticality. Some elements are safety
related or legislated, requiring continuous
availability with sufficient accuracy. Other
elements of information are presented for the
comfort or convenience of the driver. The
simultaneous need to present both safety-
related and non-safety-related information
introduces requirements not just into the
processing and presenting of such data, but
also the networks design. Sometimes this
includes redundant information sources.
However, more commonly, the requirements
call for E2E signal protection, or even both.
Examples may include airbag warnings — if the
cluster or warning lamp system misses the data
from the airbag controller, it will put the
warning lamp on assuming there to be a fault.
In contrast, some of the data in a trip computer
function is for convenience only and can safely
not be shown when not available. Likewise,
other than damaging the impression of vehicle
quality, occasionally erroneous values may be
accepted by design.
CONTINUED
As with general network design, OEMs have
design rules and standards instructing the
network design engineers which protections to
use in which system design scenarios. Capital
Networks includes editors that assist with the
set up these safety mechanisms. The design
model enables consistency checks to guide the
designer toward problems and makes sure the
networks are correct-by-design and consistently
described in the software configuration outputs
for each ECU.
MCU SHORTAGE
Cyber security
There are similarities in the approaches taken
Multiple factors collided to create a global
with FuSa and cyber security — the base
technology is built upon and in terms of network microcontroller shortage that forced
design, signal protection elements are added. developers to redesign ECUs using
However, due to the need to mitigate malicious alternative Microcontrollers (MCUs) and
attacks, the mechanisms added need to be more find alternative solutions for designing and
sophisticated. These mechanisms may not
testing their software. This white paper
always meet the needs of the FuSa on their own
aims to share ways to arrive more easily
and OEMs must consider the risk when selecting
the mitigations to be used across a system or and effectively at software that is less
platform for potential threats and/or faults. ISO/ dependent on specific hard-to-get MCU
SAE 21434 is used to set out best practice hardware. Discover how to reduce the
principals and process when designing vehicle impact of the global microcontroller
systems in consideration of cyber security.
shortage on your ECU software
To satisfy FuSa, received data is checked to be development.
consistent and correct with what was sent, with
White Paper: Microcontroller Shortage
a limited check that the signal group is correct.
Cyber security includes additional checks to
authenticate the data is from the correct sender CLICK HERE TO VIEW
and sometimes (depending on the systems
THE WHITE PAPER
design) includes encryption of the data itself.
Although, use of all mechanisms on the same
data is infrequent.
15 SPONSORED BY
Facing significant network architecture
and design challenges
Introducing new challenges for the network
designer, modern vehicle systems can exchange
data such as phone numbers, addresses,
payment details and more. These types of data
are, or contain, personally identifiable
information (PII). This data needs to be
encrypted both during transmission and in
storage. Therefore, encryption keys are also
needed to write and read the data.
Meanwhile, data used to determine control
decisions with safety relevance needs to be
trustworthy. In some cases, the overall system
design may contain sufficient redundancy in
the sourcing or sensing of this data that full
protection is not needed on every element and
a fusion algorithm may be used to resolve
conflicts. It is also possible that this part of the
system design is constrained by the sourced
system components and network technology
available (bandwidth, maximum PDU size, etc).
Eliminating or reducing these constraints is a
primary driver to higher baud rate networks
with larger payloads per frame.
The control data coming from the decision
algorithm, which may be instructions on
control inputs for steering, acceleration,
braking and more, has a direct impact on
vehicle behavior. The system design must
assure that this data is correct and
authenticating control data at the target motor
or actuator is highly desirable. Possible
authentication mechanisms include a hashed
(#) version of the signal group that enables the
receiver to perform an additional keyed check
of the data. Control data may also include some
indicator for time, or a step counter. Counters
used in automotive networks for FuSa are often
CONTINUED
four or eight bits, while cyber security counters
can be extended to 16, 32 or more bits to
mitigate a replay attack. It is common to use
multiple protections, as per FuSa, to mitigate
different risks. Redundant copies or paths for
the data can help, however, determining which
data to trust when a conflict occurs is an
important design consideration.
These protections and others have a bigger
impact to both the network designer and the
architect than FuSa protections. With cyber
security, data sizes tend to be much larger,
consuming more bandwidth. The larger frame
sizes of higher baud rate networks such as
Ethernet, FlexRay, CAN flexible data-rate (FD),
or CAN extra load (XL) can support the greater
demands of cyber security, as opposed to
traditional CAN or LIN networks. An additional
firewall before a CAN or LIN network, with
health monitoring of the sub-systems from the
secure ECU, can provide additional protection
to vulnerable parts of the system.
VLANs can be used to segregate traffic types on
Ethernet and IP networks, allowing bandwidth
utilization limits to be set. This can help prevent
denial-of-service-type attacks from affecting
multiple systems and enables certain traffic
types to be turned off in various modes of
operation. For example, software updates can
be prevented while the vehicle is in motion.
Additionally, firewalls are increasingly deployed
at entry points to the vehicle, such as the
telematics and between the entry points and
ECUs hosting higher risk functions.
A further consideration is that FuSa can usually
be considered in relative isolation. In contrast,
16
cyber security protections manifest as built-up
layers of defense across the platform, its cloud
connections and more. Special care must be
taken to make sure all appropriate layers are in
place for systems determined to be at risk.
If we consider the cluster example, functions
that relay phone or navigation information onto
the driver display might contain PII. This data
should typically be encrypted so that it is not
readable from a data log without the correct
key. This data, however, usually does not
warrant protection from corruption so that
duplicate information is displayed to the driver.
The encryption of data containing PII may be
more important in markets with privacy
legislations, such as Europe’s GDPR protections,
but it is a good practice overall.
As described previously, the consequences of
this are additional design rules and standards
that must be followed by the network designer.
Capital Networks models the full vehicle E/E
architecture and can perform consistency
checks across the full system to make sure the
design is consistent and the cyber security
protections are complete, enabling correct-by-
design outputs.
Power modes
Traditionally, vehicle networks have been
designed to remain awake to ensure
functionality is available when needed. Under
this approach, special attention is paid to
designing robust shutdown procedures that
occur when the vehicle is in an appropriate
state. This method sustains safety-related
functions and backup functionality (for
SPONSORED BY
Facing significant network architecture
and design challenges
example, enabling parking brakes or maintaining
limited powertrain operation in the event of a
faulted network). However, for maximum energy
efficiency, it is desirable to shut down what is
not currently needed and what will not be
needed on shorter notice than the wake time of
the components that are asleep or powered
down.
Partial networks allow some networks to be shut
down when not needed. Pretended networking
is also used occasionally, where some ECUs go
into a low power mode, but continue to be
active on the networks. Power modes can get
more complicated. It is very important that
needed signals and data can be generated by
awake ECUs, using awake sensors and sent over
networks that are awake. Therefore, power
modes can quickly constrain the routing of
signals.
Returning to the cluster example, the user has an
expectation that certain data is visible in given
vehicle modes, such as charging a battery
electric vehicle. This data might be offered for
the convenience of the driver, but could also
have legal or safety considerations, such as the
current charging status, vehicle odometer or
parking brake status. If this data is not calculated
or stored in the cluster, it needs to be available
to be displayed. While this would have been
considered in the E/E architecture definition, it
still creates network routing and signal packing
requirements for the network designer.
Capital Networks includes editors that assist and
automate setup of these power saving modes,
with model-based consistency checks that
enable correct-by-design setup of mechanisms,
which can be very complicated to implement.
CONTINUED
Gateway
Propulsion
Door Inverter Dampers
Seat DCDC Anti-roll
Battery Air springs
Complexity
Finally, complexity must be considered at a full
system level as it is impacted by everything we
have discussed. Complexity means options and
variants. Most vehicle programs share a
common underlying E/E architecture across a
range of vehicles of different sizes and body
types, for different markets and more. A two-
door vehicle may use fewer door modules than
a four-door car and a low-specification car will
likely use fewer ECUs overall than a high
specification car that is driven by features
included in the vehicle. All of this is to be
considered in the design. Some signals must be
available on all variations, while others may
change source due to being calculated or
17
Figure 12. During some modes, such as vehicle charging, only a
sub-set of the full display information is needed and available.
Central
Chassis Cluster
display
Rear seat
display
Example signals
Motor power
Amplifier
Battery charge
measured differently for different vehicle types.
For instance, a vehicle speed algorithm will
consider different wheel slip behavior on two and
four-wheel-drive vehicles. The mechanisms
covered for FuSa and cyber security also need to
consider the relevant vehicle variations.
Capital Networks allows full consideration of
vehicle and ECU variants, using consistency checks
to ensure correct-by-design implementations.
Implementation files, AUTOSAR configurations or
others, can be shared with software teams and
suppliers appropriate to the ECU versions and
variants needed. Also, with the increasing size of
network architectures and data, generative design
will accelerate the completion of laborious tasks,
saving time and effort and reducing manual errors.
SPONSORED BY
Facing significant network architecture
and design challenges
Generative
Each of the day-to-day challenges and
decisions that occur during the network
design phase of E/E systems development
can have widespread, cross-domain effects
that are difficult to predict or even fully
understand. Connecting the many
disciplines enables designers to understand
the downstream impacts of their decisions
during development and is critical to
accelerating the vehicle development
process.
Networks design considers and implements
many elements vital to both assuring
correct vehicle functionality and protecting
the entire system from incorrect sub-
system behavior. It is important to select a
solution that consistently and correctly
generates the configurations and
documentation used in the development
and validation of each ECU making up the
full system. Capital Networks has been
developed to address the specific needs of
the design of vehicle networks. Bringing
together learnings from its predecessors,
which were used by multiple OEMs across
the world, and the AUTOSAR flow and
framework, which also includes many years
of industry learning, to offer the most
robust networks design solution.
The criticality of embedded software
development
Effectively designing, testing and deploying
on-board software is a key priority for
automotive companies across the world.
CONTINUED
By following a model-based approach in a
common environment for system and software
engineers, this process can be significantly
improved. There are several key tasks embedded
software engineers must accomplish:
• Create clear requirements and functional
definitions to improve downstream software
quality
• Develop accurate, verified software
architectures
• Design, simulate, implement and verify
software components AUTOSAR and
• Develop embedded software for automotive
ECUs that satisfy functional safety and Siemens
cybersecurity requirements
• Integrate AUTOSAR basic and application
AUTOSAR is the go-to standard to enable
software
the digital thread for development of
• Configure AUTOSAR embedded software and automotive embedded software and a
enable ECU flashing
key technology enabler for generative
• Simulate and verify embedded software software development. Read this blog
implementations
post by Henrik Olsen is Product Line
Capital‘s new embedded software development director for the Embedded Software
tools can help customers establish high quality solutions in the Integrated Electrical
software and adherence to the industry Systems segment in Siemens Digital
standards of safety and security. This is done by
Industries Software, to find out more
using a software architecture-driven flow,
integrating network design into the development about Siemen’s Premium Partner status
process and accelerating AUTOSAR-based virtual with AUTOSAR.
verification and deployment of software on an
ECU. This virtual verification approach has great
CLICK HERE TO VIEW
potential to positively impact the quality and
speed of embedded software development and THE BLOG POST
is the subject of the next section.
18 SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V
Workflow and verification Figure 13. The generative MDD/
XIL workflow produces correct
Development methodologies and verification systems using automation.
and validation (V&V) tools have advanced over
the past few decades. Today, the Model Driven
Development (MDD) methodology and X-in-
the-loop (XIL) verification are well-established
as an effective means to develop safe and
secure vehicle E/E subsystems. In the MDD
systems engineering process, or generative
workflow (figure 13), a model of the ECU is
tested against a model of the vehicle system’s
communication networks, sensors, actuators
and plant environment that surround the ECU:
the model-in-the-loop (MIL) level of
abstraction. Once the model is validated, C/C++
code is auto-generated from it and retested: the
software-in-the-loop (SIL) level of abstraction.
Eventually, the generated code is integrated
into ECU hardware and platform software
(firmware) and retested: the hardware-in-the- of the ECU hardware model can scale whereas the
loop (HIL) level of abstraction. HIL-level testing platform and application software remain the actual
can also be performed utilizing models of the code that deploys in the final vehicle (similar to HIL).
ECU hardware: the so-called virtual hardware- This facilitates testing final production software on a
in-the-loop (vHIL) level of abstraction. platform that is optimal for the verification intent. With
advanced MDD tools, integration can also be generative
The different abstraction levels of XIL
in the workflow.
configurations found across the MDD/XIL
workflow are summarized in (figure 14). The
range of accuracy (or fidelity) of the various XIL
Test benches and test automation
configurations can be quite wide. The vHIL
configuration that leverages virtual ECU There are two major elements in the MDD/XIL testing
simulation technology covers the broadest architecture: the test bench and the test automation Figure 14. Test automation software sequences the SUT and
range. In the vHIL configuration, the accuracy software that executes test cases (figure 15 next page). accesses data within it using interfaces exposed by test benches.

19 SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V CO N T I N U E D

Test bench
Testing an XIL system begins at the test bench.
The test bench is an abstraction that provides
the ability to execute a system under test (SUT)
and access the data in it. The SUT includes
ECUs, networks, mechatronic hardware and
other simulated parts of the system. Each type
of data or access requires a different interface
and the information is configured and managed
by different specialized tools from different
vendors. For automotive E/E subsystems, the primary data and accesses of
interest include:
• Signals and parameters in embedded software and simulation models
• Data from the diagnostic functionalities of ECUs
• Measurable variables and calibration data in automotive software
• Data controlling fault and error-injection in the SUT
• Signals encoded into messages communicated over an automotive network

Figure 15. An
overview of XIL
test bench
configurations.

20 SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V
Test automation software
To support the testing sequence or test case,
test automation software utilizes the interfaces
exposed by the test bench to access the data
and exercise the system’s functionality. The test
cases must have enough coverage to V&V all
aspects of the system that are applicable at
each phase of the MDD/XIL workflow.
Testing challenges
The idea of using computers to automatically
transform modeled functions into production
quality embedded C/C++ code was once
considered impractical, yet is now well-
established as the most effective way to
develop software. However, because of several
factors such as the tiered ecosystem where
several teams in different companies
collaborate over large process gaps, the sheer
complexities involved in developing modern E/E
systems and the slower pace of standardization
relative to the pace of new methodology
adoption, there are large disconnects between
V&V at the model level and V&V at the
implementation level.
It is clear this lack of test re-use is a significant
issue. A huge business ramification is a reduced
amount of V&V coverage if every test case is
not converted or adapted to each level of
abstraction. This causes issues in both
directions: production code is not exercised
against all important functional scenarios that
are validated at the model level and an
overreliance on expensive HIL equipment that
is not always available to every software
engineer.
CO N T I N U E D
Figure 16.
Shift-left test
A larger business issue is the and verification
problems not found early in a using a digital
twin to find
project when they are less
problems
expensive to fix. Even worse, earlier.
issues uncovered in the field
can be disastrous to the
business.
Factors that affect
test re-use
The main factors that
contribute to the lack of test
re-use include:
• Levels of abstraction of
the data and signals in the
test benches
• Modeling and
programming languages example, a signal might be encoded as a double
• Sequencing and control over the various precision software variable at the MIL level, yet it
specialized tools ultimately will be realized in a CAN network message
at the HIL level or as a calibrated 32-bit integer at the
• Means to stimulate and trace the SUT SIL level. How does a test case consistently access
• Lack of standardization data that changes in its data structure during a
project without any modifications?
If these factors are not addressed adequately,
equipment and tool dependent tests are
developed multiple times, often by different Different languages
people with varying skill sets.
In the systems engineering process, different
languages are used. A modeling language such as
Different levels of data abstraction Simulink, Simcenter™ Amesim™ software, the UML,
or Modelica might be used at the MIL level whereas a
A major challenge is when signals are programming language like C/C++ is typically used at
represented, encoded and interfaced at
the HIL level. How does a test case read and write
different levels of abstraction as the system is values in a SUT consistently during development as
re-integrated moving from MIL, SIL to HIL. For
the languages change?
21 SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V CO N T I N U E D

Different tools and simulators • Generate test artifacts automatically Issues with direct-coupled test
using MDD model transformations architecture
Many different tools and simulators are needed
to validate a modern ECU. Simcenter Amesim The business problems related to a lack of If the test automation software is directly
might be used in a MIL level testbench to standardization are: coupled to the test bench using a rigid
describe a plant model and Capital VSTAR interface, whether it is standard or not, test re-
• No ability to efficiently exchange test
Virtualizer could be used at the vHIL level. use is not possible across the MDD/XIL
cases and test benches between OEMs
Automated driving tests require environment workflow.
and suppliers
scenario tools like Simcenter Prescan™
Another drawback of direct-coupled test
software. Starting up an HIL rig is very different • Increased training costs because know-
architectures is that the verification apparatus
from launching a virtual ECU. These are just a how cannot be easily transferred
does not readily support a heterogeneous
few examples. How does a test case know how
• Prohibitive costs to switch between configuration where MIL-level test benches can
to configure, initialize and control the various
testing technologies and products be mixed with HIL and/or vHIL level test
tools used as a project progresses?
benches. These heterogeneous configurations
• Verification engineers cannot combine
are needed to efficiently test multi-ECU
the best test automation software with
systems, which are typically required to validate
Different means to simulate and trace the best test bench products
modern E/E systems for ADAS, ADS and AV.
Each tool has a different way to extract signals
and parameters, obtain data from diagnostic
Figure 17. Several
functionalities, measure variables and access
factors contribute to
calibration data, provide a means to control the challenges within
fault and error-injection and parse and extract the MDD/XIL workflow.
signals packed in automotive network
messages. How does a test case consistently
stimulate and trace data as test benches
change?
Lack of standards
Without standardization, test case re-use is
simply unattainable because there is no
standard way to:
• Communicate between test cases and test
benches
• Describe, configure and initialize test
benches
• Map and access data in test benches

22 SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V
MIL level workflow with direct-
coupling
The MIL level workflow that uses direct-
coupling starts with the development of
test cases that are rigidly connected to the
first MIL level test bench. Everything
appears good enough. However, when you
consider that different representations of
the system are possible at the MIL level,
you quickly discover rigid interfaces do not
support test re-use because the interfaces
do not match. For example, if an MIL level
system #1 is modeled using language #L1,
data type #D1 and tool #T1, its test bench
interface #I1 will not match the interface
#I2 for a MIL-level system #2 that uses
language #L2, data type #D2 and tool #T2.
XIL level workflow with direct-coupling
By examining the rest of the MDD/XIL workflow
with direct-coupled test benches and test
automation software, the problems expand
significantly due to many different languages,
levels of data abstraction and the number of
different specialized tools that must be
controlled (figure 16). It is most certain that
none of the downstream test benches will
expose interfaces that are compatible with the
original MIL level test benches.
In a direct-coupled test architecture, test
development must be performed multiple
times, most likely by different groups. This
means function development is more isolated
from ECU integration.
23
CO N T I N U E D
Standards that support test re-use
Open standards such as the Association for
Standardization of Automation and Measuring
Systems (ASAM) XIL and functional mockup
interface have emerged to support testing artifact
re-use and provide a common test automation
architecture that promotes interoperability
between testing tools from different vendors.
These standards are very effective at reducing
development and training costs. The standards are
more effective when combined with an MDD/XIL
workflow methodology that automatically
produces testing artifacts as normal by-products
of systems integration efforts using institutional
rules and model transformations.
Figure 18.
Interfaces across
the XIL-levels do
not match when
data, languages,
or tools change.
SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V
When used in the MDD/XIL generative workflow
as tool profiles, architecture standards such as
AUTOSAR can further maximize effectiveness
and quality. Several professional-grade
AUTOSAR runtime software and associated
development tool solutions exist from different
vendors.
ASAM XIL
ASAM XIL is an API standard for the
communication between test automation tools
and test benches. The standard started in 2009,
as an effort to standardize HIL and has
advanced to cover other test bench
configurations used in the MDD/XIL workflow.
XIL indicates the standard can be used for all in-
the-loop systems. The most recent release is
ASAM XIL version 2.1.0.
A beneficial contribution of ASAM XIL in terms
of business value is the ability to develop tests
early in the development process when issues
are least expensive to rectify. Other ASAM XIL
values include:
• Support for test case re-use by decoupling
test automation software from test
hardware
• Interoperability between different vendors
of test automation software and test
benches
• Significant reduction of testing efforts
• Longer term protection of testing
investments
• Common way to setup and initialize a test
bench
CO N T I N U E D
• Collection of time-aligned trace data and a
specification of its data format
• Ability to inject faults and errors into the
SUT
• Support for test event and triggering
Functional mockup interface (FMI)
FMI is an open tool independent standard that
is broadly supported by many tool vendors to
support model exchange and co-simulation of
dynamic models using a combination of XML
files and compiled C-code. The XML and C-code
is bundled in a functional mockup unit (FMU).
These FMUs are used during V&V to represent
the sensor, actuator and plant environment
surrounding a distributed E/E subsystem. FMI
has been driven by a European Union (EU)
Information Technology for European
Advancement (ITEA)2-funded project, called
MODELISAR.
ASAM XIL-MA
The FMI initiative cooperated with the ASAM
XIL initiative in the MODELISAR project. This
cooperation helped standardize the way
simulations are setup and executed to
accomplish the coupling of simulation tools
with testing tools across the MDD/XIL workflow.
The results were embodied in an internally
named result called FMI for applications. ASAM
and MODELISAR decided to join this part of
their activities to develop a single standard,
resulting in ASAM XIL-MA. The major goal of
ASAM XIL-MA is to allow test automation tools
24
to control simulation tools and access simulation
models executing in them. ASAM XIL-MA is
extracted from ASAM XIL and abstracts test
automation tools from test benches for this
purpose.
AUTOSAR
The AUTOSAR partnership is an alliance of OEM
manufacturers, tier 1 automotive suppliers,
semiconductor manufacturers, software and tool
suppliers. Considering the different automotive
E/E architectures in current and future markets,
the partnership establishes a defacto open
industry standard for an automotive software
architecture.
A contribution of AUTOSAR that facilitates test
re-use is the ability to describe architectures and
their configurations in automotive E/E systems to
provide the required formal model
transformation targets in the MDD/XIL
generative workflow.
A better test architecture
To combat the inherent testing challenges
described here, a test architecture centered on
standards and augmented with automated
model transformation in an MDD/XIL generative
workflow is key.
Mapping and configuration framework ASAM XIL
is architected into two major parts (figure 17):
1. A test bench for the simulation models, ECU
data (for example, parameters, variables and
diagnostics), electrical error simulation and the
automotive networks.
SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V
2. A mapping and configuration framework that
supports the mapping of units, data types or
variable identifiers, triggering, actions,
measurement, logging and other management
facilities and services related to communication
to the test bench such as initialization, ordering
and sequencing.
The test bench part of the architecture provides
standardized interfaces to the different types of
tools with specific test bench ports. These ports
offer standardized access to ECUs, including
interfaces for:
• Calibration
• Measurement
Figure 19. ASAM XIL provides a flexible standard test architecture.
CO N T I N U E D
• Model access
• Diagnostics
• Electric error simulation
• Automotive networks
The most challenging task of decoupling test
automation software from test benches is
facilitated by the ASAM XIL mapping
framework. It allows data in a test bench to
differ in value and type during the overall MDD/
XIL workflow. The framework isolates the
differences to different mappings of values
between the test cases and the test benches.
Examples include abstract identifiers to
25
concrete identifiers, physical units to physical
units and data types to data types. By providing
a new mapping for each different test bench,
the test case remains unchanged and can be re-
used directly across engineering phases.
The test bench ports are only supported in
ASAM XIL 2.0 for compatibility with ASAM HIL
and to provide functionality that is currently not
provided by the framework layer. The major
change in this area of ASAM XIL 2.0 is to
introduce port independence to test cases by
using an object-oriented access to variables on
the test bench and an abstraction of ports in
the framework layer. Based on these variable
objects, the framework also provides objects for
port-independent signal recording, signal
generation, event watching and triggering.
ASAM XIL thus effectively provides an adaption
layer between the test cases and the different
XIL test bench configurations in the MDD/XIL
workflow. This allows the verification engineer
to test any MIL, SIL, vHIL, or HIL test bench
configuration using the same test case by
inserting its corresponding mapping and
configuration counterpart between the test
case and the test bench (figure 20, next page).
Generative MDD/XIL workflow
Combining ASAM XIL, FMI and AUTOSAR
provide all the formal ingredients required for
automated model transformation to create a
generative MDD/XIL workflow. With the
addition of a set of institutional rules, it is
possible for automated tooling to take test case
descriptions, function models, environment
SPONSORED BY
 Deploying safe and secure automotive-
grade embedded software with V&V
Figure 20. Test cases are reusable across MDD/XIL configurations using ASAM XIL
mapping and configuration layers to adapt test bench interfaces.
models and architecture models that are
produced during normal system design efforts,
and generate the test benches, mappings and
configurations required for automated V&V
regression testing.
The workflow starts at the MIL level of
abstraction and generates test artifacts (figure
19). It is important to note that all the models
conform to some formal domain-specific meta-
model, and the map and configuration
descriptions correspond to the function and
environment model test benches for MIL level
testing.
After the function model is validated at the MIL
level, it is used as input for automatic
integration in an AUTOSAR-based platform
using another set of rules (figure 21). Note that
all models conform to some formal meta-
model. The additional map and configuration
descriptions correspond to the ECU test bench.
Figure 21. The MDD/XIL MIL-level workflow using
ASAM and FMI standards is straight-forward.
The test bench, map and configurations for the
environment model are re-used directly from
the MIL level test bench. FMI co-simulation is
used to connect and execute the environment
model and ECU simulation (for the case of
vHIL).
Results and conclusion
The test cases developed during design can be
re-used through to production ECU testing and
ultimately for automated regression V&V of
future software updates deployed into the field
(figure 23).
There are several valuable business benefits this
testing architecture and generative MDD/XIL
workflow affords:
• Problems are found earlier in car projects
when they are least expensive to fix
26
CO N T I N U E D
• Test cases are re-used across the entire MDD/XIL
work-flow, preserving testing investments
• Increased V&V coverage increases safety,
enhances security and finds problems before
they are deployed into the field
• An automated and generative MDD/XIL workflow
increases quality by using model transformations
that are correct-by-design and it reduces
development, which shortens time-to-market
• OEMs and suppliers can efficiently exchange test
cases and test benches, which saves cost and
time
• Decreased training costs because standards-
based know-how is more easily transferred
• Verification engineers can combine the best test
automation software with the best test bench
products because of standard interoperability –
and switching between testing solutions is much
less expensive
SPONSORED BY
Deploying safe and secure automotive-
grade embedded software with V&V CO N T I N U E D

Figure 22. The MDD/

XIL workflow reuses
tests across XIL-
Figure 23. A MDD/XIL
levels using formal
workflow that uses a
standards.
standard test architecture
supports test case reuse.

• Tests can include multiple levels of
abstraction in a heterogeneous
configuration – this is useful when
validating the distributed multi-core, multi-
ECU E/E systems found in modern ADAS,
ADS and AV vehicle systems
• Multiple, cross-discipline interface
requirements are satisfied with
standardized access: calibration,
measurement, diagnostics, networking,
tracing, stimulus and fault-injection
Future work
ACOSAR
The main goal of ACOSAR is to develop a non-
proprietary real-time (RT) co-simulation
interface. ACOSAR is an ongoing project. Real-
time testing, in particular mixing actual and
virtual testing components together, is an
important use case (co-simulation of RT and
non-RT systems). Because of the inherent need
for network protocols in such a configuration,
ACOSAR could potentially fill the gap of the
missing network protocol specifications within
FMI. It is considered that ACOSAR will provide a
so-called FMI for RT co-simulation.
System structure and parameterization
System structure and parameterization (SSP) is
a developing standard that should be usable in
all stages of the MDD/XIL workflow. The
standard’s effort is coordinated with the FMI
and ASAM standards. The goal of SSP is to
provide a standardized format to represent a
connected set of components.
These components for example, can be FMI-
based simulation models and ASAM testing
artifacts. This would provide for a more
complete automation and a standard way to
describe and parameterize test configurations if
the MDD/XIL workflow utilizes SSP as a standard
description format.
Going forward
The complexity of all E/E architecture domains
will continue to increase in the future.
Automotive manufacturers must deliver and
integrate numerous components that make up
highly complex, connected vehicle features to
keep up with today’s demands. The increasing
number and sophistication of these
components calls for advanced electrical,
network and software engineering solutions to
help keep up with the complexity and
shortening product development timelines.
Today, innovative electrical systems
engineering solutions can help automakers by
automating development processes, while
frontloading capabilities will help companies
accelerate vehicle development, spur
innovation and lower development costs.

27 SPONSORED BY
Siemens Digital Industries Software is driving transformation to enable a digital enterprise

where engineering, manufacturing and electronics design meet tomorrow. The Xcelerator™

portfolio, the comprehensive and integrated portfolio of software and services from Siemens

Digital Industries Software, helps companies of all sizes create and leverage a comprehensive

digital twin that provides organizations with new insights, opportunities and levels of

automation to drive innovation. For more information on Siemens Digital Industries Software

products and services, visit siemens.com/software or follow us on LinkedIn, Twitter, Facebook

and Instagram. Siemens Digital Industries Software – Where today meets tomorrow.

STAY CONNECTED
CLICK HERE TO VISIT OUR WEBSITE