Embedded Control Systems Design/Automotive

The Wikibook of

Embedded Control Systems Design

Contents
Introduction
System requirements
Design process
Hardware
Autosar
Present Problems
The Autosar Standard
Terminology
Analysis of the Standard
Reusability
Safety
Design in Autosar
Component based design
The four fundamental "concerns" of system design
Influence on system complexity
Practical Aspects
OEM’s
Suppliers

The future
References

Introduction
For the design of embedded automotive systems, the entire vehicle system is usually split up into four different functional areas,
which could be separated during the design phase:

Chassis
Drive-train
Body
Telematics
Each of these areas will have different priorities and requirements and these areas will usually also be covered by different design
teams. It is important to point out that whereas these areas where completely separated in the past, new functions and legislations are
forcing these different areas to communicate with each other. The design requirements for these areas are very different and it is
crucial to make the distinction between the requirements due to legislation and those due to competition. A lot of the demands for the
drive-train and body (passive safety) areas will be due to legislation, and can thus be considered as hard constraint. Many of the
requirements for chassis and telematics on the other hand are due to manufacturer
-competition and offer more design-freedom.

System requirements
This section will not elaborate on the different functional requirements of all the different vehicle-systems. Rather an overview of the
most important system level requirements of the vehicle will be given and how this affects the requirements of the embedded control
systems:

Safety
The demand for safety will impose some important functional and non-functional constraints on the embedded systems of the drive-
train and chassis. These demands aren’t usually driven by legislation but by competition between manufacturers.

Hard real-time constraints: it is imperative that all safety related systems comply to real-time constraints.
Systems like ABS should be able to react within mere milliseconds to ensure a timely intervention. This not only
puts a constraint on the processors-speed, but also on the speed of the communication system used throughout
the car, because these systems often rely oninput signals from other systems and need to send outputs to
different systems as well (e.g.ESC-system must communicate with engine management).
Fault-detection: every sub-system of a safety-critical function should be capable of auto-diagnosing of its function
and should be able to switch to a safe shutdown condition in case of failure. Obviously also the communication
system should be able to perform data-transfer checks. Legislation dictates that if a fault is detected, this should
also be shown to the driver (MIL Malfunction Indicator Lamp) and be stored in the fault-memory of the controller .
Redundancy: critical sensors, like the throttle in drive-by-wire systems, should have redundancy to minimize
malfunction probability.
Reset-time? Start-up-time?
Cost
As in all industries manufacturing cost is also very important in automotive.

Emissions / fuel-economy
The main driver behind emissions-constraints has always been legislation, even though more recently fuel-economy has become an
increasingly more important sales-argument. A very important aspect of this legislation is the On-board diagnostics (OBD), which
monitors the engine-system continuously to ensure compliance with emission-laws in everyday use. Some of the most important
demands for the drive-train-system are:

Monitoring of emission-related electrical components (e.g. short-circuits) and storage of fault (OBD 1).
Monitoring of system functionality (e.g. plausibility check of sensor-signals) (OBD 2)
Components used to monitor emission-related components of which af fect diagnosis must be monitored. (OBD
2)
Monitoring frequency is usually prescribed by law .
Malfunctioning must be displayed to the driver by MILs (Malfunction Indication Light).
Time to market
Drive for shorter time to market pushes the system development towards more interchangeable components. This is currently very
difficult because there are no clear communication standards. Bus-communication systems have made it a lot easier to introduce new
functionalities into existing systems.

Passenger comfort
Passenger comfort is also very important in automotive due to competitive reasons. These requirements mostly apply to systems in
the interior and telematics area. This gives also some constraints on the embedded systems:

Soft real-time constraints: many non-critical systems (e.g. electric windows, electric mirrors...) have prescribed
timing constraints, but violating these constraints doesn’t have serious ef
fect. A lot of these systems for example
have to react within 100ms, with is the limit of delays a human can perceive.
Design process
Embedded systems in automotive usually follow a model-driven design workflow (as introduced in section
The design process ).

Functional requirements should generally be taken into account during the functional design stage. This also includes fail-safe modes.

The timing constraints should be taken into account during the implementation stage. It is very important to make sure the hardware
is capable of reaching the timing constraints, but is not to performant either. Also the demands for the communication-speed should
be taken into account during this phase. If the communication-speed is very critical it might even be necessary to include a detailed
model of the communication network in the original vehicle model. All the monitoring functions for hardware malfunctioning can
only be designed during this stage as well. Crucial functions that have to meet real-time constraints will usually require their own
hardware to assure real-time operation, so this is a constraint that should be taken into account from the start of the design. This
might be very difficult in practice.

A very important design-phase is the configuration of the communication between the different vehicle-systems. Due to the ever
increasing amount of signals and lack of standardization this is currently very time-consuming. The AUTOSAR standard is meant to
strongly facilitate this stage.

Hardware
Originally, cars were equipped with single signal cables. As electronic systems increased in number and complexity, this approach
was no longer acceptable due to cost, weight and complexity
. This is why manufactures have switched to bus-systems (e.g. CAN-bus)
for in-car communication between the different systems. There are usually several buses in one vehicle, each system adapted to the
speed demands of particular system-groups. More information on these bus-systems can be found in the chapter on
field-buses.

Most functionalities are currently programmed in a microcontroller with program memory (EPROM or flash ). Due to the wide array
of functionalities, there is a wide range of sensors in modern cars. Sensors on safety-critical components (like ESP-sensor) are
required to have internal self-monitoring functions as well.

Autosar

Present Problems
Current vehicular systems are characterized by proprietary solutions: applications in different vehicular systems use other interfaces
or other communication standards. This leads to suppliers that develop and maintain separate software for each system instead of
using the same software on every system and dealing with compatibility issues of communication, function and signal definitions.

OEMs have the task of integrating the different systems and guaranteeing the deterministic functioning of the integrated system. This
task is often burdened by the different diagnostic services for applications of different suppliers. With the growth in the number of
embedded control systems and the degree of interaction, further proliferation of proprietary solutions will require more resources and
it will become more difficult to guarantee the deterministic functioning of the integrated system.

There is also a trend to more flexibility for the customers; customers want to chose from different options. This leads to many small
variations of one basic vehicular system, which requires a lot of design effort in modern systems with a low level of modularity and
implementation-flexibility.

To cope with these problems, automobile manufacturers, suppliers and tool developers have joined forces to develop a new standard.
This project is named Autosar, which is an acronym for AUTomotive Open System Architecture. On the Wikipedia article of
Autosar, the goals and technical information of Autosar are explained.

The Autosar Standard

The Autosar standard is meant to be a breakthrough that should allow a paradigm shift in vehicular system design and should lead to
improvement of functionalities and higher safety
.

Terminology
The Autosar project introduces its own terminology, which shall be used throughout the rest of this text. More information can be
found on the Wikipedia article of Autosar.

Autosar Methodology: a 4-step methodology that can be used to create the vehicular system architecture starting from the design-
model.

Basic software: Standardized software that doesn’t has any functionalities that are noticeable to the end-user but offers hardware-
dependent and hardware-independent services.

Runtime environment: implementation of the possible communication paths on a software level.

Application software: The software that implements the actual functionalities, which are noticeable for the end-users.

Analysis of the Standard

Reusability
The Autosar project has chosen to standardize the communication and the non-functional software, such as the runtime environment
and the basic software. The functional software, namely the application software, is only standardized by its interfaces.

This has several implications:

OEMs can build a vehicular system by choosing the best soft- and hardware for each specific application, without
having compatibility problems. This means that the integration cost decreases. In addition, maintenance is easier to
execute because the diagnostic services can be standardized for all application instead of being supplier dependent.
Suppliers can still compete on implementation of the application software components. This should lead to better
components. Also because of the clear interfaces, suppliers can build, debug, and maintain one version of their
application software for all the different vehicular systems, which reduces proliferation of software. Due to the clear
interfaces, there is also more option to partition development between suppliers or between teams of a supplier .
Hardware suppliers can still compete on the best hardware, only the basic software necessary to use the hardware
will be standardized, but there will be options to protect specific software (for example special software to cancel
non-linear effect of actuators).
New companies can easily enter the market because of the clear set domains. A company should only be an expert
on his domain.

Safety
y measures are included.[1]
To raise the safety of a vehicular system designed according to the Autosar standards, several safet

Safety Integrity Functions, which are safety measures to be present in AUT OSAR, independent of the application
context. These functions support the correct execution of application functions and safety functions. In general, the
functions are related to protection of resources, monitoring, and self-testing. Extra safety measures of this category
need to be taken due to the change insystem complexity. For example, if two applications can use the same
resources and share memory, it will be necessary to build in some safety; for example to prevent write access to
data segments of other applications.[2]
Support of Safety Functions that are dependent on the application context. This means the support of typical safety
functions of systems from the different applications, like a fast reset for critical applications.
General Safety Requirements like local detection of faults without propagation.
Safety features can automatically be added to all vehicular software, which is a big advantage over the existing approach to vehicular
software design.

The clear set of standards and interfaces reduces the chance of faults due to wrong interaction between applications.
Design in Autosar

Component based design

The Autosar project introduces the concept of component based software design in vehicular software design. This is a necessary
change due to the growing complexity of the vehicular systems, which leads to a need for teamwork.

In component-based design, it is clear what each component should do, so the design can easily be divided over
different teams. In addition, the interfaces arestandardized which guarantees consistency in data exchange.
The meta-model simplifies teamwork. The formal description of the vehicular systems makes sure that the structure
of the information can clearly be visualized and that consistency of the information is guaranteed.
Component-based software design facilitates the use of model-based design. Thus the use of model-based design,
which is a current standard in vehicular system design, can be expanded.
Component-based design shifts automotive software development from an ECU-based approach to a function-based
approach and makes it possible to write application software independent of the used ECU.

The four fundamental "concerns" of system design

Due to the increasing complexity of vehicular systems, there is a need to explicitly control the interaction process instead of implicit
definition of the interaction embedded in the different subsystems itself.

In this context, the concept of the four fundamental "concerns" of system design is introduced. These represent the different layers in
the interaction-process.

Explicit layers facilitate the design of vehicular systems due to the better overview of the interaction process. Especially changes in
the vehicular system, which requires changes in coordination, are more straightforward.

Communication depends on the used protocols, interfaces and agreements about data exchange formats. This is
specified in the standard.
Computation depends on the application software components.
Configuration is dependent on the system designer and the used tool-chains for the methodology . The system
designer designs the physical topology of the ECU-network and decides which applications he wants to add to the
vehicular system. When following the methodology , the optimization algorithm in the selected tool-chain determines
the distribution of the different application over the different ECU’s.
Coordination is specified in the runtime environment. The runtime environment is the implementation of the
configuration, has the possibility to manage both inter- and intra-ECU communication and can call the ferent dif
applications to handle communication at their communication ports.
The application software only affects the computation step and is therefore not aware of the computation and configuration layers.
This makes it possible to create application software that is unaware of the number of interaction partners. In this way, there is a clear
separation between the communication and functionality
.

The explicit control of interaction makes it possible to add applications to the vehicular system without the need to change some of
the application software that interacts with the new application. The necessary changes are situated in the run time environment,
which is automatically adjusted in the ECU-configuration step when using the Autosar methodology
.

Influence on system complexity

The AUTOSAR-standards also change the complexity of the vehicular system. Modern vehicle are of the type distributed hardware
distributed software.

AUTOSAR sees the system as different applications running on one virtual platform. The standards make it possible to translate the
virtual platform to a real implementation on the different ECU’s, where it is possible that some applications run on the same ECU.
This methodology paves the way for a shift to systems with distributed hardware – central software.

This new model of a vehicle system has some implications for thesafety.
The sharing of ECU’s is also necessary from a practical point of view. The number of embedded control systems in vehicles keeps
rising, but the number of ECU’s in vehicles is reaching a limit. The cost is too high and the space in vehicles is limited. With
Virtualization tools, as provided by AUTOSAR, there are possibilities to strictly separate functions on an ECU without loss of safety.
s.[3]
This can open the path to less (but more powerful) ECU’

Practical Aspects

OEM’s
The Autosar standardization is a severe change in approach of a vehicular system design. This makes it difficult to adapt an existing
vehicular system to an Autosar compatible architecture. According to the roll out plan of the Autosar Core Partners, the OEM’s will
not switch to an Autosar compatible system in one day, but they will start with the integration of one Autosar compatible ECU for
one of the big subsystems (verwijzing) in a classically designed E/E-architecture. In this way, experience can be built, then an entire
subsystem and eventually the entire vehicular-system can become Autosar compatible.[4]

Suppliers
The lack of existing Autosar compatible vehicular systems makes it difficult for suppliers to test new components that are supposed
to be Autosar compatible. To tackle this problem, some companies group together in projects to generate an Autosar compatible test
bench where the different companies can test their soft- and hardware. An example is the SWAP-project, where eight Swedish
[5]
companies with the necessary and complementing competence to design a professional test bench, have joined forces.

The future
Looking further in the future, these trends seem to continue. Cybercars or driverless cars for example need to know the state of the
whole vehicle to control the vehicle in an optimal way
. This can only happen when there is central software.

In the far future, there might be a trend toward communication between cars and between cars and road infrastructure.

An example is a fleet of cybercars. A fleet of such vehicles forms a managed transportation system, for passengers or goods, on a
network of roads with on-demand and door-to-door capability.[6] This kind of system belongs to the class of ‘distributed hardware –
central software’. The fleet problems concern essentially the following elements:[7] - vehicle allocation to a particular demand, -
vehicle relocation after a trip, - deadlock avoidance, - demand management and fare collection, - distributed versus central
management, - communication architecture.

Instead of a fleet of cars which are controlled by a central management system, one can imagine that there will also be a quest for
autonomous cars who only communicate with their surroundings and possible a central system to gather traffic information. This car
can then decide autonomous what action he should undertake.

Experiments in this area are currently conducted by Mercedes-Benz. Their engineers are working on a system called "Interactive
Vehicle Communication" which allows cars to communicate with one another. The current status of their research is shown in their
concept car "ESF". The exchange of data between different cars is via 'ad hoc' networks that are formed between vehicles over short
distances. These WLAN require no extra external infrastructure. Transmission occurs at a frequency of 5.9 GHz over a distance of up
to 500 metres. Of course this distance is expanded if dif
ferent cars are communicating with each other and messages are passed on.

Currently there is a project in Frankfurt called "simTD".[8] Different German car manufacturers are taking part in this test where up
to 400 cars are communicating with each other
. The main purpose of this test is to improve safety on the road.

References
1. Autosar Safety Approach - By Johannesen P
. - Convergence 2006, Detroit, Michigan, October 16–18, 2006 - SAE
Paper 2006-21-0044.
 2. http://www.vector-
worldwide.com/portal/medien/cmc/press/PSC/T rendsEmbedded_AutomobilElektronik_200602_PressArticle_EN.pdf
(01-04-2009)
3. http://www.etas.com/data/presentations/BoCSE2007_AUTOSAR_Abstract_Maier_2007-03.pdf(01-04-2009)
4. The standard for global Cooperation in Automotive SW Development - By Moessinger J. - TIokyo,
T July 23, 2008 -
Available on www.Autosar.org (http://www.autosar.org) (21-12-2008).
5. SWAP: Design of an AUTOSAR Open Laboratory Test Bench - By Hiller M., Sivencrona H. and Sandberg A.
6. http://www.cybercars.org/ (01-04-2009)
7. http://www.cybercars.org/technologies.html#spec (01-04-2009)
8. http://www.simtd.de/ (02-03-2010)

Embedded Control Systems Design

Retrieved from "https://en.wikibooks.org/w/index.php?

title=Embedded_Control_Systems_Design/Automotive&oldid=3341760
"

This page was last edited on 10 December 2017, at 04:29.

Text is available under theCreative Commons Attribution-ShareAlike License.

; additional terms may apply. By using this
site, you agree to the Terms of Use and Privacy Policy.