A Historical Perspective and Review
Uploaded by
Xiaoying LiuA Historical Perspective and Review
Uploaded by
Xiaoying LiuIn-vehicle communication networks - a historical
∗
perspective and review
1 2
Nicolas Navet , Françoise Simonot-Lion
August 31, 2013
1: University of Luxembourg, FSTC/LASSY, 6 rue Coudenhove-Kalergi,
L-1359 Luxembourg
2: LORIA - Université de Lorraine, Campus Scienti que, BP 239
54506 Vandoeuvre-lès-Nancy - France
Contact author: Nicolas Navet (nicolas.navet@uni.lu)
Abstract
The use of networks for communications between the Electronic
Control Units (ECU) of a vehicle in production cars dates from the
beginning of the 90s. The speci c requirements of the dierent car
domains have led to the development of a large number of automo-
tive networks such as LIN, CAN, CAN FD, FlexRay, MOST, auto-
motive Ethernet AVB, etc.. This report rst introduces the context
of in-vehicle embedded systems and, in particular, the requirements
imposed on the communication systems. Then, a review of the most
widely used, as well as the emerging automotive networks is given.
Next, the current eorts of the automotive industry on middleware
technologies which may be of great help in mastering the heterogeneity,
are reviewed, with a special focus on the proposals of the AUTOSAR
consortium. Finally, we highlight future trends in the development of
automotive communication systems.
∗
This technical report is an updated version of two earlier review papers on automotive
networks: N. Navet, Y.-Q. Song, F. Simonot-Lion, C. Wilwert, "Trends in Automotive
Communication Systems", Proceedings of the IEEE, special issue on Industrial Commu-
nications Systems, vol 96, nº6, pp1204-1223, June 2005 [66]. An updated version of this
IEEE Proceedings then appeared as chapter 4 in The Automotive Embedded Systems
Handbook in 2008 [62].
1
Contents
1 Automotive communication systems: characteristics and
constraints 3
1.1 From point-to-point to multiplexed communications . . 3
1.2 Car domains and their evolution . . . . . . . . . . . . . 4
1.3 Event-triggered versus Time-triggered . . . . . . . . . . 6
1.4 Dierent networks for dierent requirements . . . . . . . 7
1.5 New challenges for in-vehicle communication systems . . 8
1.5.1 Real-time processing of large data quantities . . 8
1.5.2 Reducing electrical energy consumption . . . . . 9
1.5.3 Security issues . . . . . . . . . . . . . . . . . . . 9
2 In-car embedded networks 10
2.1 The CAN network . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 The CAN protocol . . . . . . . . . . . . . . . . . 11
2.1.2 CAN's use in today's automobiles . . . . . . . . 15
2.1.3 Other priority buses: VAN and J1850 . . . . . . 17
2.1.4 CAN FD: a high speed CAN network . . . . . . 17
2.2 Time-Triggered networks . . . . . . . . . . . . . . . . . . 18
2.2.1 The FlexRay Protocol . . . . . . . . . . . . . . . 19
2.2.2 The TTCAN protocol . . . . . . . . . . . . . . . 21
2.3 Low-cost automotive networks . . . . . . . . . . . . . . . 22
2.3.1 The LIN network . . . . . . . . . . . . . . . . . . 23
2.3.2 The TTP/A network . . . . . . . . . . . . . . . . 25
2.3.3 The PSI5 and SENT networks . . . . . . . . . . 25
2.4 Multimedia and infotainment networks . . . . . . . . . . 25
2.4.1 The MOST network . . . . . . . . . . . . . . . . 26
2.4.2 The 1394 Automotive network . . . . . . . . . . 26
2.5 Automotive Ethernet . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Motivation and use-cases for Ethernet . . . . . . 27
2.5.2 BroadR-Reach physical layer . . . . . . . . . . . 28
2.5.3 Ethernet AVB . . . . . . . . . . . . . . . . . . . 28
2.5.4 TTEthernet . . . . . . . . . . . . . . . . . . . . . 29
3 Automotive middleware 29
3.1 Objectives of an embedded middleware . . . . . . . . . . 29
3.2 Former propositions of middleware . . . . . . . . . . . . 31
3.3 AUTOSAR - a standard for the automotive industry . . 32
3.3.1 The reference model . . . . . . . . . . . . . . . . 32
3.3.2 The communication services . . . . . . . . . . . . 33
3.3.3 The end-to-end communication protection library 37
4 Conclusions and discussion 38
2
1 Automotive communication systems: character-
istics and constraints
1.1 From point-to-point to multiplexed communications
Since the 1970s, one observes an exponential increase in the number of
electronic systems that have gradually replaced those that are purely me-
chanical or hydraulic. The growing performance and reliability of hardware
components and the possibilities brought by software technologies enabled
implementing complex functions that improve the comfort of the vehicle's
occupants as well as their safety. In particular, one of the main purposes of
electronic systems is to assist the driver to control the vehicle through func-
tions related to the steering, traction ( i.e., control of the driving torque) or
braking such as the ABS (Anti-lock Braking System), ESP (Electronic Sta-
bility Program), EPS (Electric Power Steering), active suspensions or engine
control. Another reason for using electronic systems is to control devices
in the body of a vehicle such as lights, wipers, doors, windows as well as
entertainment and communication equipments (e.g., radio, DVD, hand-free
phones, navigation systems). More recently appeared a large set of Advanced
Driver Assistance Systems (ADAS), often camera based, such as brake and
park assistance, lane departure detection, night vision assistance with pedes-
trian recognition or suspension proactively scanning the road surface [55].
In the future, vehicles will become entities of large intelligent transportation
systems [51], involving cooperation mechanisms [50] through car-to-car and
car-to-infrastructure communications.
In the early days of automotive electronics, each new function was imple-
mented as a stand-alone Electronic Control Unit (ECU), which is a subsys-
tem composed of a micro-controller and a set of sensors and actuators. This
approach quickly proved to be insu cient with the need for functions to be
distributed over several ECUs and the need for information exchanges among
functions. For example, the vehicle speed estimated by the engine controller
or by wheel rotation sensors, has to be known in order to adapt the steering
eort, to control the suspension or simply to choose the right wiping speed.
In today's luxury cars, up to 2500 signals (i.e., elementary information such
as the speed of the vehicle) are exchanged by up to 70 ECUs [1]. Until
the beginning of the 90s, data was exchanged through point-to-point links
between ECUs. However this strategy, which required an amount of com-
munication channels of the order of n2 where n is the number of ECUs ( i.e.,
if each node is interconnected with all the others, the number of links grows
in the square of n), was unable to cope with the increasing use of ECUs due
to the problems of weight, cost, complexity and reliability induced by the
wires and the connectors. These issues motivated the use of networks where
the communications are multiplexed over a shared medium, which conse-
3
quently required de ning rules - protocols - for managing communications
and, in particular, for granting bus access. It was mentioned in a 1998 press
release (quoted in [45]) that the replacement of a wiring harness with LANs
in the four doors of a BMW reduced the weight by 15 kilograms. In the
mid-1980s, the third part supplier Robert Bosch developed Controller Area
Network (CAN) which was rst integrated in Mercedes production cars in
the early 1990s. CAN has become today the most widely used network in
automotive systems, and already in 2004 the number of CAN nodes sold per
year was estimated [38] to be around 400 millions (all application elds).
Other communication networks, providing dierent services, are now being
integrated in automotive applications. A description of the major networks
is given in section 2.
1.2 Car domains and their evolution
As all the functions embedded in cars do not have the same performance or
safety needs, dierent Quality of Services (e.g. response time, jitter, band-
width, redundant communication channels for tolerating transmission errors,
e ciency of the error detection mechanisms, etc.) are expected from the
communication systems. Typically, an in-car embedded system is divided
into several functional domains that correspond to dierent features and
constraints. Two of them are concerned speci cally with real-time control
and safety of the vehicle's behavior: the powertrain ( i.e. control of engine
and transmission) and the chassis ( i.e., control of suspension, steering and
braking) domains. The third, the body, mostly implements comfort func-
tions. The telematics (i.e. integration of wireless communications, vehicle
monitoring systems and location devices), multimedia and Human Ma-
chine Interface (HMI) domains take advantage of the continuous progress
in the eld of multimedia and mobile communications. Finally, an emerg-
ing domain is concerned with the safety of the occupant and with functions
providing driver assistance.
The main function of the powertrain domain is controlling the engine. This
domain is increasingly constrained by stringent regulations, such as EURO
5 in force at the time of writing in Europe, for the protection of environment
(e.g., emissions of particulate matter) and energy e ciency. The powertrain
function is realized through several complex control laws with sampling pe-
riods of a magnitude of some milliseconds (due to the rotation speed of the
engine) and implemented in micro-controllers with high computing power. In
order to cope with the diversity of critical tasks to be treated, multi-tasking is
required and stringent time constraints are imposed on the scheduling of the
tasks (see [58] for typical automotive scheduling solutions). Furthermore,
frequent data exchanges with other car domains, such as the chassis (e.g.
ESP, ABS) and the body (e.g. dashboard, climate control), are required.
4
The chassis domain gathers functions such as ABS, ESP, ASC (Automatic
Stability Control), 4WD (4 Wheel Drive), which control the chassis com-
ponents according to steering/braking solicitations and driving conditions
(ground surface, wind, etc). Communication requirements for this domain
are quite similar to those for the powertrain but, because they have a stronger
impact on the vehicle's stability, agility and dynamics, the chassis functions
are more critical from a safety standpoint. Furthermore, the X-by-Wire
technology, currently used for avionic systems, is now slowly being intro-
duced to execute steering or braking functions. X-by-Wire is a generic term
referring to the replacement of mechanical or hydraulic systems by fully
electrical/electronic ones, which led and still leads to new design methods
for developing them safely [100] and, in particular, for mastering the inter-
ferences between functions [4]. Chassis and powertrain functions operate
mainly as closed-loop control systems and their implementation is moving
towards a time-triggered approach [82, 44, 76, 72], which facilitates com-
posability (i.e. ability to integrate individually developed components) and
deterministic real-time behavior of the system.
Dashboard, wipers, lights, doors, windows, seats, mirrors, climate control are
increasingly controlled by software-based systems that make up the body
domain. This domain is characterized by numerous functions that necessi-
tate many exchanges of small pieces of information among themselves. Not
all nodes require a large bandwidth, such as the one oered by CAN; this
lead to the design of low-cost networks, such as LIN (see section 2), or more
recently, PSI5 and SENT. On LIN, only one node, termed the master, pos-
sesses an accurate clock and drives the communication by polling the other
nodes - the slaves - periodically. The mixture of dierent communication
needs inside the body domain leads to a hierarchical network architecture
where integrated mechatronic sub-systems based on low-cost networks are
interconnected through a CAN backbone. The activation of body functions
is mainly triggered by the driver and passengers' solicitations (e.g. opening
a window, locking doors, etc).
Telematics functions are becoming more and more numerous: hand-free
phones, car radio, CD, DVD, in-car navigation systems, rear seat entertain-
ment, remote vehicle diagnostic, stolen vehicle tracking, etc. These functions
require a lot of data to be exchanged within the vehicle but also with the
external world through the use of wireless technology (see, for instance, [81]).
Here, the emphasis shifts from messages and tasks subject to stringent dead-
line constraints to multimedia data streams, bandwidth sharing, multimedia
quality of service where preserving the integrity ( i.e., ensuring that infor-
mation will not be accidentally or maliciously altered) and con dentiality of
information is crucial. HMI aims to provide Human Machine Interfaces that
are easy to use and that limit the risk of driver inattention [19].
Electronic-based systems for ensuring the safety of the occupants are in-
5
creasingly embedded in vehicles. Examples of such systems are: impact and
roll-over sensors, deployment of airbags and belt pretensioners, tyre pressure
monitoring, Adaptive Cruise Control (or ACC - the car's speed is adjusted
to maintain a safe distance with the car ahead), lane departure warning sys-
tem, collision avoidance, driver intent and driver drowsiness detection, night
vision assistance. These functions form an emerging domain usually referred
to as active and passive safety.
1.3 Event-triggered versus Time-triggered
One of the main objectives of the design step of an in-vehicle embedded
system is to ensure a proper execution of the vehicle functions, with a pre-
de ned level of safety, in the normal functioning mode but also when some
components fail (e.g., reboot of an ECU) or when the environment of the
vehicle creates perturbations (e.g., EMI causing frames to be corrupted).
Networks play a central role in maintaining the embedded systems in a safe
state since most critical functions are now distributed and need to commu-
nicate. Thus, the dierent communication systems have to be analysed in
regard to this objective; in particular, messages transmitted on the bus must
meet their real-time constraints, which mainly consist of bounded response
times and bounded jitters.
There are two main paradigms for communications in automotive systems:
time-triggered and event-triggered. Event-triggered means that messages
are transmitted to signal the occurrence of signi cant events (e.g., a door
has been closed). In this case, the system possesses the ability to take into
account, as quickly as possible, any asynchronous events such as an alarm.
The communication protocol must de ne a policy to grant access to the
bus in order to avoid collisions; for instance, the strategy used in CAN (see
2.1.1) is to assign a priority to each frame and to give the bus access to
the highest priority frame. Event-triggered communication is very e cient
in terms of bandwidth usage since only necessary messages are transmit-
ted. Furthermore, the evolution of the system without redesigning existing
nodes is generally possible which is important in the automotive industry
where incremental design is a usual practice. However, verifying that tem-
poral constraints are met is not obvious and the detection of node failures is
problematic.
When communications are time-triggered, frames are transmitted at pre-
determined points in time, which is well-suited for the periodic transmission
of messages as it it required in distributed control loops. Each frame is sched-
uled for transmission during one pre-de ned interval of time, usually termed
a slot, and the schedule repeats itself inde nitely. This medium access strat-
egy is referred to as TDMA (Time Division Multiple Access). As the frame
scheduling is statically de ned, the temporal behavior is fully predictable;
6
thus, it is easy to check whether the timing constraints expressed on data
exchanges are met. Another interesting property of time-triggered protocols
is that missing messages are immediately identi ed; this can serve to detect,
in a short and bounded amount of time, nodes that are presumably no longer
operational. The rst downside is the ine ciency in terms of network uti-
lization and response times by comparison with the transmission of aperiodic
messages (i.e. messages that are not transmitted in a periodic manner). A
second drawback of time-triggered protocols is the lack of exibility even if
dierent schedules (corresponding to dierent functioning modes of the appli-
cation) can be de ned and switching from one mode to another is possible at
run-time. Finally, the unplanned addition of a new transmitting node on the
network induces changes in the message schedule and, thus, may necessitate
the update of all other nodes. TTP/C [95] is a purely time-triggered network
but there are networks, such as TTCAN [37], FTT-CAN [18], FlexRay [11]
or TTEthernet [94], that can support a combination of both time-triggered
and event-triggered transmissions. This capability to convey both types of
tra c ts in well with the automotive context since data for control loops
as well as alarms and events have to be transmitted.
Several comparisons have been done between event-triggered and time-triggered
approaches, the reader can refer to [42, 1, 18] for good starting points.
1.4 Dierent networks for dierent requirements
The steadily increasing need for bandwidth
1 and the diversi cation of per-
2
formance, costs and dependability requirements lead to a diversi cation of
the networks used throughout the car. In 1994, the Society for Automotive
Engineers (SAE) de ned a classi cation for automotive communication pro-
tocols [88, 87, 13] based on data transmission speed and functions that are
distributed over the network. Class A networks have a data rate lower than
10 Kbit/s and are used to transmit simple control data with low-cost tech-
nology. They are mainly integrated in the body domain (seat control, door
lock, lighting, trunk release, rain sensor, etc.). Examples of class A networks
are LIN [79, 48] and TTP/A [27]. Class B networks are dedicated to support-
ing data exchanges between ECUs in order to reduce the number of sensors
by sharing information. They operate from 10 Kbit/s to 125 Kbit/s. The
J1850 [89] and low-speed CAN [33] are the main representatives of this class.
Applications that need high speed real-time communications require class C
1
For instance, in [4], the average bandwidth needed for the engine and the chassis
control was estimated to reach 1500kbit/s in 2008 while it was 765kbit/s in 2004 and
122kbit/s in 1994.
2
Dependability is usually de ned as the ability to deliver a service that can justi ably
be trusted, see [3] for more details.
7
networks (speed of 125Kbit/s to 1Mbit/s) or class D networks
3 (speed over
1Mb/s). Class C networks, such as high-speed CAN [35], are used for the
powertrain and currently for the chassis domains, while class D networks
are devoted to multimedia data (e.g., MOST [59]) and safety critical ap-
plications that need predictability and fault-tolerance (e.g., TTP/C [95] or
FlexRay [11] networks) or serve as gateways between sub-systems (see the
use of FlexRay at BMW in [85] and [39]).
It is common, in today's vehicles, that the electronic architecture includes
four, ve or more dierent types of networks interconnected by gateways.
For example, the rst-generation Volvo XC90 [38] embeds up to 40 ECUs in-
terconnected by a LIN bus, a MOST bus, a low-speed CAN and a high-speed
CAN. More recent high-end cars have much more complex architectures, such
as the BMW 7 series launched in 2008 (see [39]), which implements four CAN
buses, a FlexRay bus, a MOST bus, several LIN buses, an Ethernet bus and
wireless interfaces. The architecture is organized around a central gateway
connecting most of the data buses, and providing external connections for
diagnostic and large data transfer (code upload, navigational maps, etc).
1.5 New challenges for in-vehicle communication systems
We discuss here three main evolutions that will probably profoundly shape
future automotive communication networks and architectures.
1.5.1 Real-time processing of large data quantities
The rst trend is the requirement for an increasing number of functions to
process, at a high rate, large quantities of data, for instance produced by
video and infrared cameras. A good example of such functions is a pedes-
trian detection system with auto-brake, which relies on image recognition
and machine learning algorithms, and has to work at the highest possible
vehicle speed. In the case of the pedestrian detection system introduced
in 2010 in Volvo's S60, a collision with a pedestrian can be avoided at up
to 35km/h [98]. This system has to analyse the ow of images and pro-
vide, on time, a deterministic verdict about whether there is a pedestrian
in front of the car, and then possibly activate braking if the driver fails to
respond in time. Such systems, often belonging to the active and passive
safety car domain, require powerful computational resources. This is one of
the rationale for the introduction of multicore architectures in automotive
embedded systems [58]. Furthermore, these functions are often implemented
on a distributed architecture, and usually require sensor fusion, so that the
3
Class D is not formally de ned but it is generally considered that networks over 1Mb/s
belong to class D. This SAE classi cation is outdated today but was often refered to in
the past.
8
underlying communication architecture has to provide a strong and guaran-
teed temporal quality of service. Another driver for increasing data streams
are of course infotainment systems, consider for example a rear-set video
system in HD quality.
1.5.2 Reducing electrical energy consumption
Energy e ciency is now a major concern when designing new embedded
electronic architectures, while it was for the last 10 years a concern for ac-
tuators mainly. A reason is that, by regulation, the average CO2 emission
per passenger car sold in the EU must fall below the 95g/km threshold from
2020 onwards. Similar regulations will come into force in many countries
outside EU, for instance in China or in the USA [102]. At the same time, it
is estimated [8] that, between 2002 and 2012, the average power requirement
for the automotive electronics was multiplied by 4 and reaches now 3kW.
This lead to the introduction of two main strategies to achieve better energy
e ciency: ECU degradation and partial networking. ECU degradation is
the ability to switch o or reduce the execution rate of software modules,
shutdown some I/O ports, or even put a complete CPU into idle mode. These
low-power features are already supported in AUTOSAR. Partial networking
means putting temporarily into sleep mode a group of nodes, or some entire
network, when they do not need to be operational. For example, a parking
assistance system that cannot be used above 20km/h can be deactivated
at higher speeds. Many control modules in the body of the vehicle (seats,
mirror, door, etc) can remain in sleep mode most of the time [8]. Then, the
nodes are waken up when needed through speci c messages. Audi estimates
for instance that the potential savings of partial networking would be around
2.6g CO2/km [97, 8].
Partial networking has been an ongoing work in the automotive industry
since 2008 [47], already fully supported in AUTOSAR for CAN. A working
group of carmakers and semiconductor manufacturers was set up in 2010 to
develop a speci cation for CAN transceivers with wake-up capability [97, 8].
The outcomes of this working group have been submitted for standardisation
as ISO 11898-6, an extension to the existing CAN standard (ISO 11898).
Several components supporting partial networking are commercially avail-
able [102] and a rst implementation in a car has been announced for 2013
or 2014 [47].
1.5.3 Security issues
The last issue to be dealt with is the security of communication, and more
generally security of the embedded systems. If safety has always been a
matter of concern for automotive embedded systems, security issues have
9
been in our view largely overlooked. The need for more security is driven
by the ever increasing connectivity between the car and the external world,
which includes not only telematics services and internet access, but also
upcoming vehicle-to-vehicle or vehicle-to-infrastructure communication.
As demonstrated in [43], some existing security mechanisms, for instance to
control ECU reprogramming, are weak and many current automotive systems
usually do not resist to attacks, sometimes even relatively unsophisticated
ones according to [43]. With a physical access to the vehicle, through a
connection to the standard OBD-II port, the authors were for instance able
to re ash ECUs, even critical ones controlling the engine and the brakes.
The authors were also able to remotely compromise the security of the car,
by injecting malicious code, and ultimately monitor and control the car re-
motely over the Internet [43]. Obviously such security breaches could have
catastrophic consequences, especially with ADAS systems and future intel-
ligent transportation systems requiring cooperation between vehicles. One
may even imagine a scenario where an infected vehicle would contaminate
other vehicles.
The technical answer to this security challenge will probably encompass a
spectrum of solutions [43], ranging from cryptography (support for embed-
ding a cryptographic module is available in AUTOSAR since release 4.0 [7]),
message authentication mechanisms, security breach detection systems, etc.
These functionalities will require additional bandwidth, and, for instance,
CAN FD (see 2.1.4) would probably be better suited than normal CAN to
ful l these needs. The use of virtualization technologies [63] will also increase
security because it enables to isolate functions or sub-systems running on
the same ECUs having dierent security requirements, while enabling them
to share information in a controlled manner. Typically, virtualization would
help to prevent infotainment applications, that are connected to the external
world through wireless connections, from accessing the internal communica-
tion buses.
2 In-car embedded networks
The dierent performance requirements throughout a vehicle, as well as the
competition among companies, have led to the design of a large number of
communication networks. The aim of this section is to give a description of
the most representative networks for each main domain of utilization.
10
2.1 The CAN network
To ensure at run-time the freshness
4 of the exchanged data and the timely
delivery of commands to actuators, it is crucial that the Medium Access Con-
trol (MAC) protocol is able to ensure bounded response times for frames. An
e cient and conceptually simple MAC scheme that possesses this capability
is the granting of bus access according to the priority of the messages (the
reader can refer to [93, 67, 14, 56] for how to compute bound on response
times for priority buses). To this end, each message is assigned an identi er,
unique to the whole system. This serves two purposes: giving priority for
transmission (the lower the numerical value, the greater the priority) and
allowing message ltering upon reception. Beside CAN two other repre-
sentatives of such priority buses are VAN and J1850, they will be brie y
presented in 2.1.3.
2.1.1 The CAN protocol
CAN (Controller Area Network) is without a doubt the most widely used
in-vehicle network. It was designed by Bosch in the mid 80's for multiplexing
communication between ECUs in vehicles and thus for decreasing the overall
wire harness: length of wires and number of dedicated wires (e.g. the number
of wires has been reduced by 40%, from 635 to 370, in the Peugeot 307 that
embeds two CAN buses with regard to the non-multiplexed Peugeot 306 [52]).
Furthermore, it allows to share sensors among ECUs.
CAN on a twisted pair of copper wires became an ISO standard in 1994 [33,
35] and is now a de-facto standard in Europe for data transmission in au-
tomotive applications, due to its low cost, its robustness and the bounded
communication delays (see [38]). In today's car, CAN is used as an SAE
class C network for real-time control in the powertrain and chassis domains
(at 250 or 500KBit/s), but it also serves as an SAE class B network for the
electronics in the body domain, usually at a data rate of 125Kbit/s.
On CAN, data, possibly segmented in several frames, may be transmitted
periodically, aperiodically or on-demand ( i.e. client-server paradigm). A
CAN frame is labeled by an identi er, transmitted within the frame (see
Figures 1 and 2), whose numerical value determines the frame priority. There
are two versions of the CAN protocol diering in the size of the identi er:
CAN 2.0A (or standard CAN) with an 11 bit identi er and CAN 2.0B (or
extended CAN) with a 29 bit identi er. For in-vehicle communications,
4
The freshness property is veri ed if data has been produced recently enough to be
safely consumed: the dierence between the time when the data is used and its production
time must be always smaller than a speci ed value. The delay experienced by a data is
made up of the network latency, plus the latencies on the sending and receiving ends which
can be large especially if the application tasks are not synchronized with the transmissions
on the network (see [25]).
11
only CAN 2.0A is used since it provides a su cient number of identi ers
(i.e. the number of distinct frames exchanged over one CAN network is
lower than 211 ).
CAN uses Non-Return-to-Zero (NRZ) bit representation with a bit stu ng
of length 5. In order not to lose the bit time (i.e., the time between the
emission of two successive bits of the same frame), stations need to resyn-
chronize periodically and this procedure requires edges on the signal. Bit
stu ng is an encoding method that enables resynchronization when using
Non-Return-to-Zero (NRZ) bit representation where the signal level on the
bus can remain constant over a longer period of time (e.g. transmission of
'000000..'). Edges are inserted into the outgoing bit stream in such a way
to avoid the transmission of more than a maximum number of consecutive
equal-level bits (5 for CAN). The receiver will apply the inverse procedure
and de-stu the frame. CAN requires the physical layer to implement the
logical and operator: if at least one node is transmitting the 0 bit level
on the bus, then the bus is in that state regardless if other nodes have trans-
mitted the 1 bit level. For this reason, 0 is termed the dominant bit value
while 1 is the recessive bit value.
The standard CAN data frame (CAN 2.0A, see Figure 1) can contain up
to 8 bytes of data for an overall size of, at most, 135bits, including all the
protocol overheads such as the stu bits. The sections of the frames are:
the header eld (see Figure 2), which contains the identi er of the
frame, the Remote Transmission Request bit that distinguishes be-
tween data frame (RTR set to 0) and data request frame (RTR set to
1) and the Data Length Code (DLC) used to inform of the number of
bytes of the data eld,
the data eld having a maximum length of 8 bytes,
the 15 bit Cyclic Redundancy Check (CRC) eld which ensures the
integrity of the data transmitted,
the Acknowledgment eld (Ack). On CAN, the acknowledgment scheme
solely enables the sender to know that at least one station, but not nec-
essarily the intended recipient, has received the frame correctly,
the End-of-Frame (EOF) eld and the intermission frame space which
is the minimum number of bits separating consecutive messages.
Any CAN node may start a transmission when the bus is idle. Possible
con icts are resolved by a priority-based arbitration process, which is said
non-destructive in the sense that, in case of simultaneous transmissions, the
highest priority frame will be sent despite the contention with lower priority
frames. The arbitration is determined by the arbitration elds (identi er plus
12
SOF : Start Of Frame
EOF : End Of Frame
Ack : Acknowledgement
Inter : Intermission
SOF Header Application data CRC field Ack EOF Inter
... idle idle ...
18 bits 0..8 bytes 15 bits 3bits 7 bits 3bits
Standard CAN (2.0A)
1 bit
Figure 1: Format of the CAN 2.0A data frame
0 : data frame
1 : request frame
Identifier DLC
1
R
0 or 1 T 0 or 1
R
0
11 bits 3 bits 4 bits
Figure 2: Format of the header eld of the CAN 2.0A data frame
RTR bit) of the contending nodes. An example illustrating CAN arbitration
is shown on Figure 3. If one node transmits a recessive bit on the bus while
another transmits a dominant bit, the resulting bus level is dominant due
to the and operator realized by the physical layer. Therefore, the node
transmitting a recessive bit will observe a dominant bit on the bus and then
will immediately stop transmitting. Since the identi er is transmitted most
signi cant bit rst, the node with the numerically lowest identi er eld will
gain access to the bus. A node that has lost the arbitration will wait until
the bus becomes free again before trying to retransmit its frame.
CAN arbitration procedure relies on the fact that a sending node monitors
the bus while transmitting. The signal must be able to propagate to the most
remote node and return back before the bit value is decided. This requires
the bit time to be at least twice as long as the propagation delay which limits
the data rate: for instance, 1Mbit/s is feasible on a 40 meter bus at maximum
while 250Kbit/s can be achieved over 250 meters. To alleviate the data rate
limit, and extend the lifespan of CAN further, car manufacturers are starting
to optimize the bandwidth usage by implementing tra c shaping strategies
that are very bene cial in terms of response times (see, for instance, [24]).
CAN has several mechanisms for error detection. For instance, it is checked
that the CRC transmitted in the frame is identical to the CRC computed
at the receiver end, that the structure of the frame is valid and that no bit-
stu ng error occurred. Each station which detects an error sends an "error
ag" which is a particular type of frame composed of 6 consecutive dominant
bits that allows all the stations on the bus to be aware of the transmission
error. The corrupted frame automatically re-enters into the next arbitration
13
SOF
arbitration field
Node 1 1 1 0 0 1 0 0 0 0 0 0
Node 2 1 1 0 1 1 0 0 0 0 0 0
Bus 1 1 0 0 1 0 0 0 0 0 0
Level
t
the
arbitration
phase
starts only node
1 remains
Figure 3: CAN arbitration phase with two nodes starting transmitting si-
multaneously. Node 2 detects that a frame with a higher priority than its
own is being transmitted when it monitors a level 0 (i.e. dominant level) on
the bus while it has sent a bit with a level 1 (i.e. recessive level). Afterwards,
Node 2 immediately stops transmitting.
phase, which might lead it to miss its deadline due to the additional delay.
The error recovery time, de ned as the time from detecting an error until
the possible start of a new frame, is 17 to 31 bit times. CAN possesses some
fault-con nement mechanisms aimed at identifying permanent failures due
to hardware dysfunctioning at the level of the micro-controller, communica-
tion controller or physical layer. The scheme is based on error counters that
are increased and decreased according to particular events (e.g., successful
reception of a frame, reception of a corrupted frame, etc.). The relevance
of the algorithms involved is questionable (see [22]) but the main limitation
is that a node has to diagnose itself, which can lead to the non-detection
of some critical errors. For instance, a faulty oscillator can cause a node
to transmit continuously a dominant bit, which is one manifestation of the
babbling idiot fault, see [74]. Furthermore, other faults such as the parti-
tioning of the network into several sub-networks may prevent all nodes from
communicating due to bad signal re ection at the extremities. Without ad-
ditional fault-tolerance facilities, CAN is not well suited for safety-critical
applications. For instance, a single node can perturb the functioning of the
whole network by sending messages outside their speci cation ( i.e. length
and period of the frames). Many mechanisms were proposed for increasing
the dependability of CAN-based networks (see [74] for an excellent survey),
but if each proposal solves a particular problem, they have not necessar-
ily been conceived to be combined. Furthermore, the fault-hypotheses used
14
in the design of theses mechanisms are not necessarily the same and the
interactions between them remain to be studied in a formal way.
The CAN standard only de nes the physical layer and Data Link layer
(DLL). Several higher level protocols have been proposed, for instance, for
standardizing startup procedures, implementing data segmentation or send-
ing periodic messages (see OSEK/VDX and AUTOSAR in 3). Other higher-
level protocols standardize the content of messages in order to ease the inter-
operability between ECUs. This is the case for J1939 which is widely used,
for instance, in Scania's trucks and buses [99].
2.1.2 CAN's use in today's automobiles
There is now more than 20 years of experience in automotive CAN applica-
tions, and CAN has certainly proven very successful as a robust, cost eective
and all-around network technology. But the use of CAN in vehicles is evolv-
ing, in particular because of more complex and heterogeneous architectures
with FlexRay or Ethernet networks, and because of recent needs like hybrid,
electric propulsion or driver assistance that involves more stringent real-
time constraints. Besides, there are other new requirements on CAN: more
ne-grained ECU mode management for energy savings [8, 102], multi-ECU
splitted functions and huge software downloads. In parallel, safety issues
request more and more mechanisms to protect against potential failures and
provide end-to-end integrity (see 3.3 and [2]).
Increased bandwidth requirements. The robustness and performance
of the CAN technology, as well as the new possibilities brought by distributed
software functions, have lead engineers to use more and more bandwidth
in order to improve existing Electrical and Electronic (EE) functions and
introduce new ones. This trend has never ceased, and along with topology
and functional domain constraints, has led to the use of several CAN clusters
within a car, sometimes more than 4 or 5 [64, 39]. Also, the data rates of
the CAN buses are now higher (e.g., 250kbit/s for a body network when it
used to be 125kbits/) and the bus load level has increased (e.g., greater than
50%).
More complex architectures. At the beginning of CAN, just a few
ECUs were connected while today there are thousands of signals exchanged
by several tens of ECUs, with some signals having timing constraints below
5ms. Besides, the architectures are becoming complex because of gateways
between the CAN buses or between a CAN bus and another networking
technology (typically FlexRay). The use of several CAN clusters raises also
technical issues regarding for instance fault-handling, diagnosis timing re-
sponse, wake-up and sleep synchronization. And, whatever is done, there is
15
an overlap between the data sent on the buses connected to a gateway, which
induces a signi cant waste a bandwidth. To face the EE architecture com-
plexity, and be able to push the limits of CAN, car makers have established
rigorous development processes. Besides, there are now several well-suited
COTS toolsets available on the market to help them with the optimization
and veri cation using simulation (possibly with fault-injection), schedulabil-
ity analysis and trace analysis (see [64] for the use of RealTime-at-Work's
tools).
Optimizing CAN networks. When CAN was introduced, the bus load
levels were limited, typically much less than 30% (see [65] for a typical set of
messages of the years 1995-2000). Optimizing CAN networks, which includes
reaching higher load levels, has now become an industrial requirement for
several reasons:
It helps to master the complexity of the architectures,
It reduces the hardware costs, weight, space, consumption, etc,
It facilitates an incremental design process,
It may avoid the industrial risk, the costs and the time to master new
technologies such as FlexRay,
It leads to better communication performances and helps to match
the bandwidth needs. Sometimes, a 60%-loaded CAN network can
be more e cient that two 40% CAN networks interconnected by a
gateway causing delays and high jitters.
The rst obvious way to optimize a CAN network is to keep the amount
of data transmitted to a minimum, speci cally limit the transmission fre-
quency of the frames. This requires a rigorous identi cation and traceability
of the temporal constraints. Given a set of signals or frames, and their as-
sociated temporal constraints (freshness, jitters, etc), they are in addition a
few con guration strategies than can be used:
1. Desynchronize the stream of frames by using osets. The reader may
refer to [26] for comprehensive experiments on the large gains achieved
using osets,
2. Reassign the priorities of the frames, so that the priority order better
re ects the timing constraints,
3. Re-consider the frame-packing, that is the allocation of the signals
to the frames and choice of the frame periods, so as to minimize the
bandwidth usage while meeting timing constraints (see [83]),
16
4. Optimize the ECU communication stacks so as to remove all imple-
mentation choices that cause a departure from the ideal CAN behavior
(see [64]).
However, because there is less margin for error, using complex CAN-based
architectures at high load levels involves more detailed supplier speci cations
on the one hand, and, on the other hand, to spend more time and eort in
the integration/validation phase.
2.1.3 Other priority buses: VAN and J1850
The J1850 [89] is an SAE class B priority bus that was adopted in the USA
for communications with non-stringent real-time requirements, such as the
control of body electronics or diagnostics. Two variants of the J1850 are
de ned: a 10.4Kbit/s single-wire version and 41.6Kbit/s two-wire version.
For quite a long time, the trend in new designs seems to be the replacement
of J1850 by CAN or a low-cost network such as LIN (see 2.3.1).
In the 90s, another competing technology was the French Vehicle Area Net-
work (VAN, see [34]) which is very similar to CAN (e.g., frame format, data
rate) but possesses some additional or dierent features that are advanta-
geous from a technical point of view (e.g., no need for bit-stu ng, in-frame
response: a node being asked for data answers in the same frame that con-
tained the request). VAN was used for years in production cars by the French
carmaker PSA Peugeot-Citroën in the body domain (e.g, for the 206 model)
but, as it was not adopted by the market, it was abandoned in favor of CAN.
2.1.4 CAN FD: a high speed CAN network
CAN FD is a new protocol that was presented for the rst time by Robert
Bosch GmbH at the International CAN Conference in 2012 [30] that com-
bines CAN's core features with a higher data rate and larger data payloads.
The data eld length can be up to 64 bytes long: from 0 to 8 bytes, then above
8 bytes, the possible values are 12, 16, 20, 24, 32, 48 and 64 bytes. Techni-
cally, two bit rates are used successively in the transmission of a CAN FD
frame: one lower for the arbitration phase, as required by the CAN bitwise
arbitration (see 2.2.2), and a higher one used immediately after the arbi-
tration for the transfer of the data payload and related elds (e.g., DLC,
CRC). The bit rate for this data part of the frame transmission can be freely
chosen (e.g., 10MBit/s are mentioned in [30]) but in practice it will depend
much on the topology of the network and the e ciency of the transceivers.
It is not clear at the time of writing what is the kind of data rate, and thus
the speedup with regard to standard CAN, that can be achieved in typical
automotive applications and this will largely determine the acceptance of
17
CAN FD. The target mentioned in [30] is an average data rate of 2.5MBit/s
with existing CAN transceivers.
Four main use-cases are identi ed for CAN FD in [49]: faster software down-
load (end-of-production line or maintenance), avoiding segmentation of long
messages (and possibly securing normal CAN messages with message authen-
tication information), oering higher-bandwidth to car domains requiring it
(e.g., powertrain [49]), and enabling faster communication on long CAN
buses (e.g., in trucks and buses). An important advantage of CAN FD is
that there is an easy migration path from CAN systems to CAN FD systems
since existing CAN application software can basically remains unchanged,
the changes taking place in the communication layers and their con gura-
tion. Following FPGA's implementations, microcontrollers with CAN FD
are already available (e.g., [20]) and the protocol has been submitted as ISO
11898-7 for international standardization.
2.2 Time-Triggered networks
Among communication networks, as discussed before, one distinguishes time-
triggered networks where activities are driven by the progress of time and
event-triggered once where activities are driven by the occurrence of events.
Both types of communication have advantages but one considers that, in
general, dependability is much easier to ensure using a time-triggered bus
(refer, for instance, to [82] for a discussion on this topic). This explains that
mainly time-triggered communication systems are being considered for use
in the most critical applications such as X-by-Wire systems. In this category,
multi-access protocols based on TDMA (Time Division Multiple Access) are
particularly well suited; they provide deterministic access to the medium
(the order of the transmissions is de ned statically at the design time), and
thus bounded response times. Moreover, their regular message transmissions
can be used as "heartbeats" for detecting station failures. The three TDMA
based networks that could serve as gateways or for supporting safety critical
applications are TTP/C (see [95]), FlexRay (see 2.2.1) and TTEthernet
(see 2.5.4). FlexRay, which was backed by the world's automotive industry,
is becoming a standard technology in the industry, though without gaining
broad acceptance, and is already in use in production cars since 2006 (see [85,
28]). TTCAN (see 2.2.2) was, before the advent of FlexRay, considered for
use and is brie y discussed in this section. In the following, we choose not
to discuss further TTP/C which, to the best of our knowledge, is no more
considered for vehicles but is used in aircrafts. However, the important
experience and know-how gained over the years with TTP/C, in particular
regarding its fault-tolerance features (see [23]) and their formal validation
(see [73]), is certainly bene cial to FlexRay and any Ethernet-based protocols
such as TTEthernet (see 2.5.4) or even AVB (see 2.5.3).
18
2.2.1 The FlexRay Protocol
A consortium of major companies from the automotive eld developed the
FlexRay protocol. The core members of the consortium, now disbanded, were
BMW, Bosch, Daimler, General Motors, NXP Semiconductors, Freescale
Semiconductor and Volkswagen. The rst publicly available speci cation of
the FlexRay Protocol was released in 2004, the current version of the speci-
cation is now available as a set of ISO standards issued in 2013 (ISO 17458
part 1 to 5), based on the 3.0.1 release from the FlexRay consortium [11].
FlexRay did not gain very wide acceptance yet, since most car manufactur-
ers still rely on CAN-based architectures, but it has been used since 2006 in
some production cars by BMW and Audi. For instance, the latest series 5
from BMW implements up to 17 FlexRay nodes [28].
The FlexRay network is very exible with regard to topology and transmis-
sion support redundancy. It can be con gured as a bus, a star or multi-star.
It is not mandatory that each station possesses replicated channels nor a bus
guardian. At the MAC level, FlexRay de nes a communication cycle as the
concatenation of a time-triggered (or static) window and an event triggered
(or dynamic) window. In each communication window, size of which is set
statically at design time, two distinct protocols are applied. The communi-
cation cycles are executed periodically. The time-triggered window uses a
TDMA MAC protocol; the main dierence with TTP/C is that a station in
FlexRay might possess several slots in the time-triggered window, but the
size of all the slots is identical (see Figure 4). In the event-triggered part of
the communication cycle, the protocol is FTDMA (Flexible Time Division
Multiple Access): the time is divided into so-called mini-slots, each station
possesses
5 a given number of mini-slots (not necessarily consecutive) and it
can start the transmission of a frame inside each of its own mini-slots. A
mini-slot remains idle if the station has nothing to transmit which actually
induces a loss of bandwidth (see [10] for a discussion on that topic). An
example of a dynamic window is shown in Figure 5: on channel B, frames
have been transmitted in mini-slots n n+2
and while mini-slot n+1 has
not been used. It is noteworthy that frame n + 4 is not received simultane-
ously on channels A and B since, in the dynamic window, transmissions are
independent in both channels.
The FlexRay MAC protocol is more exible than the TTP/C MAC since in
the static window nodes are assigned as many slots as necessary (up to 2047
overall) and since the frames are only transmitted if necessary in the dynamic
part of the communication cycle. In a similar way as with TTP/C, the struc-
ture of the communication cycle is statically stored in the nodes, however,
unlike TTP/C, mode changes with a dierent communication schedule for
5
Dierent nodes can send frames in the same slot but in dierent cycles, this is called
slot multiplexing and it is only possible only in the dynamic segment.
19
TDMA FTDMA
Static Window Dynamic Window
Node A Node B Node A Node C Node A NodeD Node A Node B
Static Static Static Static Static Static Static Static ...
Slot Slot Slot Slot Slot Slot Slot Slot
MiniSlots
Figure 4: Example of a FlexRay communication cycle with 4 nodes A, B, C
and D
MiniSlot
Frame ID n+1 Frame ID n+4
Channel A
n n+1 n+2 n+3 n+4 n+5 n+6 n+7
n n+1 n+2 n+3 n+4
Channel B
Frame ID n Frame ID n+2 Frame ID n+4
Slot Counter
Figure 5: Example of message scheduling in the dynamic segment of the
FlexRay communication cycle
each mode are not possible.
The FlexRay frame consists of 3 parts : the header, the payload segment
containing up to 254 bytes of data and the CRC of 24 bits. The header
of 5 bytes includes the identi er of the frame and the length of the data
payload. The use of identi ers allows to move a software component, which
sends a frame X, from one ECU to another ECU without changing anything
in the nodes that consume frame X. It has to be noted that this is no more
possible when signals produced by distinct components are packed into the
same frame for the purpose of saving bandwidth (i.e., which is refer to as
frame-packing or PDU-multiplexing - see [83] for this problem addressed on
CAN).
From the dependability point of view, the FlexRay standard solely speci es
a bus guardian (optional), passive and active star coupler (optional) and the
clock synchronization algorithms. Other features, such as mode management
facilities or a membership service, will have to be implemented in software
or hardware layers on top of FlexRay (see, for instance, [5] for a membership
service protocol that could be used along with FlexRay). This will allow
to conceive and implement exactly the services that are needed with the
drawback that correct and e cient implementations might be more di cult
to achieve in a layer above the communication controller.
In the FlexRay speci cation, it is argued that the protocol provides scal-
able dependability i.e., the ability to operate in con gurations that provide
various degrees of fault tolerance. Indeed, the protocol allows for mixing
20
links with single and dual transmission supports on the same network, sub-
networks of nodes without bus-guardians or with dierent fault-tolerance
capability with regards to clock synchronization, etc. In the automotive
context where critical and non-critical functions co-exist and interoperate,
this exibility can prove to be e cient in terms of cost and re-use of existing
components. The reader interested in more information about FlexRay can
refer to [86, 11], and to [77, 25, 103] for how to con gure the communication
cycle.
2.2.2 The TTCAN protocol
TTCAN (Time Triggered Controller Area Network - see [37]) is a commu-
nication protocol developed by Robert Bosch GmbH on top of the CAN
physical and data-link layers. TTCAN uses the CAN standard but, in addi-
tion, requires that the controllers have the possibility to disable automatic
retransmission of frames upon transmission errors and to provide the up-
per layers with the point in time at which the rst bit of a frame was sent
or received. The bus topology of the network, the characteristics of the
transmission support, the frame format, as well as the maximum data rate -
1Mbits/s - are imposed by the CAN protocol. Channel redundancy is pos-
sible (see [57] for a proposal), but not standardized and no bus guardian is
implemented in the node. The key idea was to propose, as with FlexRay, a
exible time-triggered/event-triggered protocol. As illustrated in Figure 6,
TTCAN de nes a basic cycle (the equivalent of the FlexRay communication
cycle) as the concatenation of one or several time-triggered (or "exclusive")
windows and one event-triggered (or "arbitrating") window. Exclusive win-
dows are devoted to time triggered transmissions (i.e., periodic messages)
while the arbitrating window is ruled by the standard CAN protocol: trans-
missions are dynamic and bus access is granted according to the priority
of the frames. Several basic cycles, that dier by their organization in ex-
clusive and arbitrating windows and by the messages sent inside exclusive
windows, can be de ned. The list of successive basic cycles is called the
system matrix, which is executed in loops. Interestingly, the protocol en-
ables the master node ( i.e. the node that initiates the basic cycle through
the transmission of the "reference message") to stop functioning in TTCAN
mode and to resume in standard CAN mode. Later, the master node can
switch back to TTCAN mode by sending a reference message.
TTCAN is built on a well-mastered and low-cost technology, CAN, but,
as de ned by the standard, does not provide important dependability ser-
vices such as the bus guardian, membership service and reliable acknowledg-
ment (see [74]). It is, of course, possible to implement some of these mech-
anisms at the application or middleware level but with reduced e ciency.
About 10 years ago, it was thought that carmakers could be interested in
21
CAN standard
TDMA
arbitration
Basic Cycle
Reference Exclusive Exclusive Arbitration Free Exclusive Reference Exclusive
Message Window Window Window Window Window Message Window ...
master node Time windows for
transmission messages
Figure 6: Example of a TTCAN Basic Cycle
using TTCAN during a transition period until FlexRay technology is fully
mature but this was not really the case and TTCAN has not been used in
production cars to the best of our knowledge.
2.3 Low-cost automotive networks
Several eldbus networks have been developed to ful ll the need for low-speed
/ low-cost communication inside mechatronic based sub-systems generally
made of an ECU and its set of sensors and actuators. Two representatives
of such networks are LIN and TTP/A. The low-cost objective is achieved
not only because of the simplicity of the communication controllers but also
because the requirements set on the micro-controllers driving the communi-
cation are reduced (i.e., low computational power, small amount of memory,
low-cost oscillator). Typical applications involving these networks include
controlling doors (e.g., door locks, opening/closing windows) or controlling
seats (e.g., seat position motors, occupancy control). Besides cost considera-
tions, a hierarchical communication architecture, including a backbone such
as CAN and several sub-networks such as LIN, enables reducing the total
tra c load on the backbone.
Both LIN and TTP/A are master/slave networks where a single master node,
the only node that has to possess a precise and stable time base, coordinates
the communication on the bus: a slave is only allowed to send a message when
it is polled. More precisely, the dialogue begins with the transmission by the
master of a command frame that contains the identi er of the message
whose transmission is requested. The command frame is then followed by a
data frame that contains the requested message sent by one of the slaves
or by the master itself (i.e., the message can be produced by the master).
This paragraph also presents the SENT and PSI5 networks which are other
more recent low-cost alternatives to CAN.
22
Frame slot
Frame
Inter-
Response frame
Header space Response space
...
Break Sync Protected Data 1 Data 2 Data N Checksum
identifier
Figure 7: Format of the LIN frame. A frame is transmitted during its frame
slot which corresponds to an entry of the schedule table
2.3.1 The LIN network
LIN (Local Interconnect Network, see [48, 79]) is a low cost serial commu-
nication system used as SAE class A network, where the needs in terms
of communication do not require the implementation of higher-bandwidth
multiplexing networks such as CAN. LIN is developed by a set of major
companies from the automotive industry (e.g., Daimler, Volkswagen, BMW
and Volvo) and is widely used in production cars.
The LIN speci cation package (LIN version 2.2A [48]) includes not only the
speci cation of the transmission protocol (physical and data link layers) for
master-slave communications but also the speci cation of a diagnostic proto-
col on top of the data link layer. A language for describing the capability of a
node (e.g., bit-rates that can be used, characteristics of the frames published
and subscribed by the node, etc.) and for describing the whole network is
provided (e.g., nodes on the network, table of the transmissions' schedule,
etc.). These description language facilitates the automatic generation of the
network con guration by software tools.
A LIN cluster consists of one master node and several slave nodes con-
nected to a common bus. For achieving a low-cost implementation, the
physical layer is de ned as a single wire with a data rate limited to 20Kbit/s
due to EMI limitations. The master node decides when and which frame
shall be transmitted according to the schedule table. The schedule table is
a key element in LIN; it contains the list of frames that are to be sent and
their associated frame-slots thus ensuring determinism in the transmission
order. At the moment a frame is scheduled for transmission, the master
sends a header (a kind of transmission request or command frame) inviting
a slave node to send its data in response. Any node interested can read a
data frame transmitted on the bus. As in CAN, each message has to be
identi ed: 64 distinct message identi ers are available. Figure 7 depicts the
LIN frame format and the time period, termed a frame slot, during which
a frame is transmitted.
The header of the frame that contains an identi er is broadcast by the master
23
node and the slave node that possesses this identi er inserts the data in the
response eld. The break symbol is used to signal the beginning of a frame.
It contains at least 13 dominant bits (logical value 0) followed by one recessive
bit (logical value 1) as a break delimiter. The rest of the frame is made of
byte elds delimited by one start bit (value 0) and one stop bit (value 1),
thus resulting in a 10-bit stream per byte. The sync byte has a xed value
(which corresponds to a bit stream of alternatively 0 and 1), it allows slave
nodes to detect the beginning of a new frame and be synchronized at the
start of the identi er eld. The so-called protected identi er is composed
of two sub- elds: the rst 6 bits are used to encode the identi er and the
last two bits, the identi er parity. The data eld can contain up to 8 bytes
of data. A checksum is calculated over the protected identi er and the data
eld. Parity bits and checksum enable the receiver of a frame to detect bits
that have been inverted during transmission.
LIN de nes ve dierent frame types: unconditional, event-triggered, spo-
radic, diagnostic and user-de ned. Frames of the latter type are assigned
a speci c identi er value and are intended to be used in an application-
speci c way that is not described in the speci cation. The rst three types
of frames are used to convey signals. Unconditional frames are the usual
type of frames used in the master-slave dialog and are always sent in their
frame-slots. Sporadic frames are frames sent by the master, only if at least
one signal composing the frame has been updated. Usually, multiple spo-
radic frames are assigned to the same frame-slot and the higher priority
frame that has an updated signal is transmitted. An event-triggered frame
is used by the master willing to obtain a list of several signals from dierent
nodes. A slave will only answer the master if the signals it produces have
been updated, thus resulting in bandwidth savings if updates do not take
place very often. If more than one slave answers, a collision will occur. The
master resolves the collision by requesting all signals in the list one by one.
A typical example of the use of the event-triggered transfer given in [48] is
the doors' knob monitoring in a central locking system. As it is rare that
multiple passengers simultaneously press a knob, instead of polling each of
the four doors, a single event-triggered frame can be used. Of course, in the
rare event when more than one slave responds, a collision will occur. The
master will then resolve the collision by sending one by one the individual
identi ers of the list during the successive frame slots reserved for polling
the list. Finally, diagnostic frames have a xed size of 8 bytes, xed value
identi ers for both the master's request and the slave answers and always
contain diagnostic or con guration data whose interpretation is de ned in
the speci cation.
It is also worth noting that LIN oers services to send nodes into a sleep mode
(through a special diagnostic frame termed go-to-sleep-command) and to
wake them up, which is convenient since optimizing energy consumption,
24
especially when the engine is not running, is a real matter of concern in the
automotive context.
2.3.2 The TTP/A network
As TTP/C, TTP/A [27] was initially invented at the Vienna University of
Technology. TTP/A pursues the same aims and shares the main design
principles as LIN and it oers, at the communication controller level, some
similar functionalities, in particular, in the areas of plug-and-play capabilities
and on-line diagnostics services. TTP/A implements the classic master-slave
dialogue, termed master-slave round, where the slave answers the master's
request with a data frame having a xed length data payload of 4 bytes. The
Multi-partner rounds enable several slaves to send up to an overall amount
of 62 bytes of data after a single command frame. A broadcast round is
a special master-slave round in which the slaves do not send data; it is, for
instance, used to implement sleep / wake-up services. The data rate on a
single wire transmission support is, as for LIN, equal to 20Kbit/s, but other
transmission supports enabling higher data rates are possible. To our best
knowledge, TTP/A is not currently in use in production cars.
2.3.3 The PSI5 and SENT networks
PSI5 (Peripheral Sensor Interface, see http://www.psi5.org) is another low-
cost bus that was originally developed for communication between ECUs and
airbags, but is now considered for use with any kinds of sensors. It provides
125kbit/s communication and needs only two wires for both data commu-
nication and sensor power supply. When used in bus mode with several
sensors on the bus, as opposed to the point-to-point mode, the communi-
cation is organized in a time-triggered manner according to a TDMA-based
MAC protocol, each sensor sending in a prede ned time slot.
Another competing technology is SENT (Single-Edge Nibble Transmission),
normalized as SAE J2716, which provides one-way communication, but it
can be complemented by the SPC protocol (Short PWM code, see [6]) which
adds functionalities such as bi-directional communication.
2.4 Multimedia and infotainment networks
Several protocols have been adapted or speci cally conceived for transmitting
the large amount of data needed by multimedia and infotainment applica-
tions increasingly available in cars. Two prominent protocols in this category
are MOST and 1394 Automotive (formerly known as IDB-1394) that are
discussed below. Another technology, not speci cally developed for the au-
tomotive domain, though that is currently broadly used for infotainment and
25
automotive cameras, is LVDS (Low-Voltage Dierential Signaling) which en-
ables communication at 655Mbit/s and above [54] over twisted pair copper
cables. In the near future, it is very likely that Ethernet-based networks,
probably compliant with the IEEE 802.1 AVB QoS standard (see 2.5.3),
will be used to transport the high data volumes needed by multimedia and
infotainment applications [28, 91].
2.4.1 The MOST network
MOST (Media Oriented System Transport, see [59]) is a multimedia network,
development of which was initiated in 1998 by the MOST Cooperation (a
consortium of carmakers and component suppliers). MOST provides point-
to-point audio and video data transfer with dierent possible data rates.
MOST supports end-user applications like radios, GPS navigation, video
displays and entertainment systems. MOST's physical layer has been so far
a Polymer Optical Fiber (POF) transmission support which provides a better
resilience to EMI and higher transmission rates than classical cooper wires,
but a new coaxial standard has been introduced recently [41]. It was esti-
mated in 2008 [53] that around 50 model series, for example from BMW and
Daimler, implement a MOST network (e.g., MOST25 at 25Mbit/s at Daim-
ler, see [46]). MOST has now become a de-facto standard for transporting
audio and video streams within vehicles (see [60, 61]).
The third revision of MOST [59] has introduced the support of a channel that
can transport standard Ethernet frames and is thus well suited to transmit
IP tra c. These features, along with the higher bandwidth provided by
MOST150 introduced in 2007, are already taken advantage of in some new
vehicle projects [46] to provide access to internet services and web browsing,
and independent access to audio and video sources from all seats with a single
bus. In [41], the MOST consortium announces its intention to develop a next
generation of the protocol, with a target bandwidth of 5Gbit/s, that would
be suited as well for ADAS requiring the transmission of uncompressed video
streams, competing thus with automotive Ethernet solutions.
2.4.2 The 1394 Automotive network
1394 Automotive is an automotive version of IEEE-1394 (FireWire) for in-
vehicle multimedia and telematics applications that is developed by the 1394
Trade Association (see http://www.1394ta.org). The system architecture
of 1394 Automotive permits existing IEEE-1394 consumer electronics devices
to interoperate with embedded automotive grade devices. 1394 Automotive
is advertised to support a data rate of 800Mbps [92, 84] over several physical
layers including twisted pair or POF. Thanks to its large bandwidth and the
interoperability with existing IEEE-1394 consumer electronic devices, 1394
26
Automotive was at some time considered a serious competitor for MOST
technology but, despite a few early implementations at Renault and Nis-
san, as far as we know the protocol did not reach wide acceptance in the
automotive market.
2.5 Automotive Ethernet
At the time of writing, the question is not if, but when Ethernet will be-
come a standard technology in cars [101, 28, 96]. For instance, Continental
expects to start series production of Ethernet-capable control units as soon
as in 2015 [12]. The introduction of Ethernet will however be gradual, and
Ethernet is probably going to ful l dierent use-cases over time. This para-
graph discusses these use-cases and the main Ethernet technologies that are
considered for use.
2.5.1 Motivation and use-cases for Ethernet
The rst motivation for Ethernet is that it is a low-cost and mature technol-
ogy that oers much more bandwidth that what is available today, which is
of interest for infotainment and active safety especially [29]. From the user
perspective, as well as from an economic point of view, the re-use of non
automotive-speci c networking technologies such as Ethernet can be bene -
cial. However, automotive speci c requirements must be taken into account:
e.g., the need for partial networking and power over Ethernet to reduce the
wiring, provision of speci c QoS, robustness to severe environmental condi-
tions (e.g., EMI, heat, etc).
In [29], the authors describe a plausible roadmap for the use of Ethernet.
First generation Ethernet network, based on 100BASE-TX physical layer,
will be for diagnostics (using ISO 13400 standard) and code upload (as al-
ready done since 2008, see [39]). The second generation Ethernet network,
from 2015 onwards, will support infotainment and camera-based ADAS us-
ing Ethernet AVB (see 2.5.3) and BroadR-Reach physical layer (see 2.5.2).
At the third stage, from 2020 onwards, gigabit Ethernet should become the
backbone interconnecting most other networks, and replacing thus today's
gateways (see section 4). This communication architecture will bene t from
the ability of Ethernet switches to handle ports having dierent speeds. The
backbone will have to support various kinds of tra c with dierent QoS re-
quirements, and thus require QoS policies that may be oered, according to
the authors of [29], by a second generation of AVB protocols. A new physi-
cal layer derived from today's 100Mbit/s BroadR-Reach will be needed, and
Time-Triggered transmissions would be available.
27
2.5.2 BroadR-Reach physical layer
BroadR-Reach is a 100MBit/s physical layer over low-cost unshielded cop-
per wires that is being developed by the OPEN Alliance SIG consortium
(see http://www.opensig.org/). This consortium, that already counts 140
member companies with many of the carmakers along with Robert Bosch
and Continental, aims at establishing BroadR-Reach as the standard for the
automotive Ethernet physical layer, with Gb/s speed in its roadmap [32].
For that purpose, BroadR-Reach was designed to meet the automotive re-
quirements in terms of cost, power saving modes, robustness to environmen-
tal conditions, etc. One clear advantage of BroadR-Reach over standard
100BASE-TX Fast Ethernet is that it only requires a single pair of copper
cables. At the time of writing, the Broad-R-Reach speci cation is close to
being nal [101].
2.5.3 Ethernet AVB
IEEE 802.1 Audio/Video Bridging (AVB) is a set of standards aimed at
providing low-latency streaming services on 802.3 Ethernet. The develop-
ment and adoption of AVB is promoted by the AVnu Alliance consortium
(see http://www.avnu.org/) which counts several car manufacturers and
automotive suppliers among its members.
IEEE 802.1AS is a synchronization protocol that builds on IEEE 1588 Preci-
sion Time Protocol to enable sub-microsecond time synchronization between
nodes. IEEE 802.1Qav speci es a leaky-bucket Credit Based tra c Shaper
(CBS). 802.1Qat is an end-to-end bandwidth reservation protocol. Finally,
802.1BA speci es default parameters and pro les that manufacturers of AVB
equipments can use. AVB de nes three classes of tra c: Stream Reserva-
tion (SR) Class-A with a guaranteed latency of 2ms maximum, SR Class-B
with a guaranteed 50ms maximum latency, and best eort for the rest of the
tra c. At most, 75% of the bandwidth can be reserved for SR Class-A and
SR Class-B streams.
Experiments in [91] suggest that AVB would be an excellent option for in-
car multimedia streams, with the advantage that it enables to dynamically
register data ows and can be used with higher level protocols for handling
audio/video streams such as IEEE 1733. To the best of our knowledge, there
is not clear cut answer yet about the suitability of the current AVB standard
for the transmission of critical control data. In October 2012, AVnu Alliance
has announced the formation of the AVB Gen2 Council with the aims to
improve AVB functionality in areas such as time-sensitive transmission and
fault tolerance. This new speci cation is currently in development within
the IEEE (Audio/Video Bridging Task Group).
28
2.5.4 TTEthernet
TTEthernet [94] is a time-triggered switched Ethernet protocol, promoted by
the TTA-Group (see http://www.ttagroup.org/), that was standardized
as SAE AS6802 in 2011. TTEthernet natively supports mixed-criticality
temporal requirements as it de nes 3 types of tra c streams: time-triggered
(with o ine con gurated transmission schedule), rate constrained (i.e., the
maximum workload is bounded) and best eort. Upper bounds on the jitters
and latencies can be derived for both the time-triggered and rate constrained
tra c. The temporal QoS in terms of jitters is better for the time-triggered
tra c but sending and receiving must be done at pre-de ned points in time.
Conceptually, the Rate-constrained tra c model is similar to Virtual links
in AFDX, and SR-Class A and B in AVB.
TTEthernet is designed to be operational in cross-domain critical applica-
tions, up to highest criticality level such as DO178 DAL-A in aeronautics,
and thus possesses a wide range of fault-tolerant mechanisms. Besides, the
time-triggered tra c oers a temporal QoS that cannot be matched by the
current version of AVB. These features could be needed for some future au-
tomotive applications. Another idea currently investigated [101, 91] is the
integration of AVB and TTEthernet, which the aim to come up with an
e cient solution for all common automotive Ethernet use-cases.
3 Automotive middleware
3.1 Objectives of an embedded middleware
The design of automotive electronic systems has to take into account several
constraints. First, nowadays, the performance, quality and safety of a vehicle
depend on functions that are mainly implemented in software (for example,
the engine control, body electronics, ADAS, etc.) and moreover depend on
a tight cooperation between these functions. For example, the control of the
engine is done according to requests from the driver (speeding up, slowing
down as transmitted by the throttle position sensor or the brake pedal) and
requirements from other embedded functions such as climate control, ESP
or brake assist. Second, in-vehicle embedded systems are produced through
a complex cooperative multi-partner development process shared between
OEMs and suppliers. Therefore, in order to increase the e ciency of the
production of components and their integration, two important problems
have to be solved: 1) the portability of components from one Electronic
Control Unit to another one enabling some exibility in the architecture de-
sign, and 2) the reuse of components between platforms which is a keypoint
for car manufacturers. Thus the cooperative development process raises the
problem of interoperability of components. A classic approach for easing the
29
integration of software components is to implement a middleware layer that
provides application programs with common services and a common inter-
face. In particular, the common interface allows the design of an application
disregarding the hardware platform and the distribution, and therefore en-
ables the designer focusing on the development and the validation of the
software components and the software architecture that realize a function.
Among the set of common services usually provided by a middleware, those
that related to the communication between several application components
are crucial. They have to meet several objectives:
Hide the distribution through the availability of services and interfaces
that are the same for intra-ECU, inter-ECU, inter-domain communi-
cations whatever the underlying protocols,
Hide the heterogeneity of the platform by providing an interface in-
dependent of the underlying protocols, of the CPU architecture (e.g.,
8/16/32 bits, endianness), of the Operating Systems, etc.
Provide high-level services in order to shorten the development time
and increase quality through the re-use of validated services ( e.g., peri-
odic transmission, working mode management such as partial network-
ing, etc.). A good example of such a function is the frame-packing
(sometimes also called signal multiplexing) that enables application
components to exchange signals (e.g. the number of revolutions per
minute, the speed of the vehicle, the state of a light, etc.) while, at run-
time, frames are transmitted over the network; so, the frame-packing
service of a middleware consists in packing the signals into frames and
sending the frames at the right points in time for ensuring the deadline
constraint on each signal it contains,
Ensure QoS properties required by the application, in particular, it can
be necessary to improve the QoS provided by the lower-level protocols
as, for example, by furnishing an additional CRC (Cyclic Redundancy
Code), transparent to the application, if the Hamming distance of the
CRC speci ed by the network protocol is not su cient in regard to the
dependability objectives (cf. the end-to-end communication protection
library of AUTOSAR in 3.3.3). Other examples are the correction of
bugs in lower level protocols such as the inconsistent message du-
plicate of CAN (see [75]), the provision of a reliable acknowledgment
service or message authentication mechanism on CAN, the status in-
formation on the data consumed by the application components (e.g.,
data was refreshed since last reading, its freshness constraint was not
respected, etc.) or ltering mechanisms (e.g., notify the application for
each k reception or when the data value has changed in a signi cant
way).
30
Note that a more advanced features would be to come up with adaptive com-
munication services, thanks to algorithms that would modify at run-time the
parameters of the communication protocols (e.g., priorities, transmission fre-
quencies, etc.) according to the current requirements of the application (e.g.,
inner-city driving or highway driving) or changing environmental conditions
(e.g., EMI level). For the time being, to the best of our knowledge, such fea-
tures exist in series automotive embedded systems only for low-power modes
(see 1.5, see also [104] for a research work in the direction of more adaptive
communication systems). In fact, this point requires a coordinated approach
for the design of function (as the de nition of control law parameters, the
identi cation of the parameters acting on the robustness of the function,
etc.) and the deployment of the software architecture that implements the
function (speci cally the communication parameters). By increasing the ef-
ciency and the robustness of the application, such an adaptive strategy
would certainly ease the re-usability.
3.2 Former propositions of middleware
Some proprietary middleware (MW) were developed by several carmakers
in order to support the integration of ECUs and software modules provided
by their third-party suppliers. For instance, the TITUS/DBKOM commu-
nication stack, was a proprietary middleware (MW) of Daimler that stan-
dardizes the cooperation between components according to a client/server
model. Volcano [9, 80] is a commercial product of Mentor Graphics, initially
developed in tight cooperation with Volvo. The Volcano Target Package
(VTP) consists of a communication layer and a set of o-line con guration
tools for application distributed on CAN and LIN. It is aimed at providing
the mapping of signals into frames under network bandwidth optimization
and ensure a predictable and deterministic real time communication system
thanks to schedulability analysis techniques (see [93, 9]). To the best of our
knowledge, there are no publicly available technically precise descriptions of
both TITUS and Volcano.
A rst step to de ne a standard for in-car embedded middleware was started
by the OSEK/VDX consortium (http://www.osek-vdx.org). In particular,
two speci cations are of particular interest in the context of this chapter: the
OSEK/VDX Communication layer [70] and the Fault-Tolerant Communica-
tion layer [68]. The rst one speci es a communication layer [70] that de nes
common software interfaces and common behavior for internal and external
communications between application components. How signals are packed
into a frame is statically de ned o-line and the OSEK/VDX Communi-
cation layer automatically realizes the packing / unpacking at run-time as
well as the handling of queued or unqueued messages at the receiver side.
OSEK/VDX Communication runs on top of a transport layer (e.g., [36])
31
that takes care mainly of possible segmentation of frames and it can operate
on any OS compliant with OSEK/VDX OS services for tasks, events and
interrupt management (see [71]).
OSEK/VDX Communication is not intended to be used on top of a Time-
Triggered (TT) network, as for example TTP/C or FlexRay. For this pur-
pose, there is OSEK/VDX FTCom speci cation (Fault-Tolerant Communi-
cation, see [68]) whose main role is to manage the redundancy of data needed
to achieve fault-tolerance (i.e., the same information can be produced by a
set of replicated nodes) by presenting only one copy of data to the receiving
application according to the strategy speci ed by the designer. Two other
important services of OSEK/VDX FTCom, already oered by OSEK/VDX
Communication, are to manage the packing/unpacking of messages [83], and
to provide message ltering mechanisms for passing only signi cant data to
the application. OSEK/VDX FTCom was developed to run on top of a time-
triggered operating system (OS) such as OSEK Time [69]. OSEK/VDX is
no more under active development and has been superseded by AUTOSAR.
3.3 AUTOSAR - a standard for the automotive industry
From 2001 to 2004, the ITEA European project EAST-EEA aimed at the
speci cation of an automotive MW for the automotive industry. To the
best of our knowledge, this was the rst important initiative targeting the
speci cation of both the services to be ensured by the middleware and the
architecture of the middleware itself in terms of components and architec-
ture of components. Similar objectives are guiding the work done in the
AUTOSAR consortium, see http://www.autosar.org and [17, 21, 40], that
gathers most the key players in the automotive industry. The speci cations
produced by the consortium become quickly de-facto standards for the co-
operative development of in-vehicle embedded systems (see, for instance, the
migration to AUTOSAR at PSA Peugeot-Citröen [16]).
3.3.1 The reference model
AUTOSAR speci es the software architecture embedded in an ECU. More
precisely, it provides a reference model which is comprised of three main
parts:
the application layer,
the basic software (middleware software components),
and the Run Time Environment (RTE) that provides standardized
software interfaces to the application software.
32
Figure 8: AUTOSAR reference architecture
One of AUTOSAR's main objective is to improve the quality and the re-
liability of embedded systems. By using a well suited abstraction, the ref-
erence model supports the separation between software and hardware, it
eases the mastering of the complexity, allows the portability of application
software components and therefore the exibility for product modi cation,
upgrade and update, as well as the scalability of solutions within and across
product lines. Besides, AUTOSAR ensures a smooth integration process of
components provided by dierent companies while protecting the industrial
properties of each actor involved. The AUTOSAR reference architecture is
schematically illustrated in gure 8. An important issue is the automatic
generation of an AUTOSAR middleware that has to be done from the basic
software components, generally provided by suppliers, and the speci cation
of the application itself (description of applicative-level tasks, signals sent or
received, events, alarms, etc.). The challenge is to realize such a generation
so that the deployment of the middleware layer can be optimized for each
ECU.
3.3.2 The communication services
One of the main objectives of the AUTOSAR middleware is to hide the
characteristic of the hardware platform as well as the distribution of the ap-
plication software components. Thus the inter- or intra-ECU communication
33
Figure 9: Communication software components and architecture
34
services are of major importance and are thoroughly described in the docu-
ments provided by the AUTOSAR consortium (see gure 9 for an overview
of the dierent modules). The role of these services is crucial for the behav-
ioral and temporal properties of an embedded and distributed application.
So, their design, their generation and con guration have to be precisely mas-
tered and the veri cation of timing properties becomes an important activity.
The problem is complex because, as for the formerly mentioned middleware,
the objects (e.g., signals, frames, I-PDU, etc.) that are handled by services
at one level are not the same objects that are handled by services at another
level. Nevertheless each object is strongly dependent of one or several ob-
jects handled by services belonging to neighboring levels. The AUTOSAR
standard proposes two communication models:
sender-receiver used for passing information between two application
software components (belonging to the same task, to two distinct tasks
on the same ECU or to two remote tasks),
client-server that supports function invocation.
Two communication modes are supported for the sender-receiver commu-
nication model:
the explicit mode is speci ed by a component that makes explicit
calls to the AUTOSAR middleware for sending or receiving data,
the implicit mode means that the reading (resp. writing) of data
is automatically done by the middleware before the invocation (resp.
after the end of execution ) of a component consuming (resp. pro-
ducing) the data without any explicit call to AUTOSAR services; this
is away to protect eectively the data between application software
components and middleware services.
AUTOSAR identi es three main objects regarding the communication: sig-
nal exchanged between software components at application level, I-PDU (In-
teraction Layer Protocol Data Unit) that consists of a group of one or several
signals, and the N-PDU (Data Link Layer Protocol Data Unit) that will ac-
tually be transmitted on the network. Precisely AUTOSAR de nes:
signals at application level that are speci ed by a length and a type.
Conceptually a signal is exchanged between application software com-
ponents through ports disregarding the distribution of this component.
The application needs to precise a Transfer Property parameter that
will impact the behavior of the transmission and whose value can be
triggered (each time the signal is provided to the middleware by the
application, it has to be transmitted on the network) or pending
35
(the actual transmission of a signal on the network depends only on
the emission rule of the frame that contains the signal). Furthermore,
when specifying a signal, the designer has to indicate if it is a data, an
event or a mode. For data transmission, incoming data are not queued
on the receiver side while for event exchanges, signals are queued on
the receiver side and therefore, for each transmission of the signal, a
new value will be made available to the application. The handling of
buers or queues is done by the RTE.
I-PDU are built by the AUTOSAR COM component. Each I-PDU
is made of one or several signals and is passed via the PDU Router
to the communication interfaces. The maximum length of an I-PDU
depends on the maximum length of the L-PDU (i.e., Data Link Layer
PDU) of the underlying communication interface: for CAN and LIN
the maximum L-PDU length is 8 bytes while for FlexRay the maxi-
mum L-PDU length is 254 bytes. AUTOSAR COM ensures a local
transmission when both components are located on the same ECU, or
by building suited objects and triggering the appropriate services of
the lower layers when the components are remote. This scheme en-
ables the portability of components and hide their distribution. The
transformation from signals to I-PDU and from I-PDU to signals is
done according to an o-line generated con guration. Each I-PDU is
characterized by a behavioral parameter, termed Transmission Mode
whose possible value is direct indicates (the sending of the I-PDU is
done as soon as a triggered signal contained in this I-PDU is sent at
application layer), periodic means (the sending of the I-PDU is done
only periodically), mixed (the rules imposed by the triggered signals
contained in the I-PDU are taken into account, and additionally the
I-PDU is sent periodically if it contains at least one pending signal)
or none (for I-PDUs whose emission rules depend on the underly-
ing network protocol, as e.g., FlexRay; no transmission is initiated by
AUTOSAR COM in this mode).
an N-PDU is built by the basic components CAN TP (Transport Pro-
tocol) or FlexRay TP. It consists of the data payload of the frame that
will be transmitted on the network and protocol control information.
Note that the use of a transport layer is not mandatory and I-PDUs
can be transmitted directly to the lower layers (see gure 9).
The RTE (Run Time Environment) implements the AUTOSAR middleware
interface and the corresponding services. In particular, when using the
sender/receiver implicit /explicit communica-
model, the RTE handles the
tion modes and the fact that the communication involves events (queued) or
data (unqueued). The AUTOSAR COM component is responsible for sev-
eral functions: on the sender side, it ensures the transmission and noti es the
36
application about its outcome (success or error). In particular, AUTOSAR
COM can inform the application if the transmission of an I-PDU did not
take place before a speci ed deadline (i.e., deadline monitoring). On the
receiver side, it also noti es the application (success or error of a reception)
and supports the ltering mechanism for signals (dispatching each signal of a
received I-PDU to the application or to a gateway). Both at the sending and
receiving end, the endianness conversion is taken in charge. An important
role of the COM component is to pack/unpack signals into/from I-PDU s.
Note that, as the maximal length of an I-PDU depends on the underlying
networks, the design of a COM component has to take into account the net-
works and therefore it is not fully independent of the hardware architecture.
The COM component has also to determine the points in time where to send
the I-PDUs. This is based on the attributes Transmission Mode of an I-PDU
and on the attribute Transfer Property of each signal that it contains.
The COM component is generated o-line on the basis of the knowledge of
the signals, the I-PDUs and the allocation of application software compo-
nents on the ECUs. The AUTOSAR PDU Router (see gure 9), according
to the con guration, dispatches each I-PDU to the right network communi-
cation stack. This basic component is statically generated o-line as soon
as the allocation of software components and the operational architecture
is known. Other basic software components of the communication stack
are responsible for the segmenting/reassembling of I-PDU(s) when needed
(FlexRay TP, CAN TP) or for providing an interface to the communication
drivers (FlexRay Interface, CAN Interface, LIN Interface).
3.3.3 The end-to-end communication protection library
In order to support safer communications between application software com-
ponents, the AUTOSAR standard speci es the End-to-End Communication
Protection Library [2]. The speci ed End-to-End mechanisms aim to ensure
that safety-critical data exchanges (up to ASIL D safety level) can be pro-
tected against faults that may occur at runtime during the transmission of
the data: faults aecting the hardware (e.g., bit- ipping due to EMI in the
sending communication stack) or software faults due to the incorrect devel-
opment of a component of the communication stack. In particular, the E2E
protection mechanisms allow:
to attach, on the sender side, speci c control data to data that are to
be sent to the RTE,
to verify, on the receiver side, through the control data, the correction
of the data received from the RTE,
to report, when it occurs, that received data are faulty. In this case,
the fault has to be handled by the receiver software components.
37
The E2E library is implemented as a set of functions that can be invoked
at two levels: by application software components (thanks to a wrapping
technique) or from the COM component. These functions are stateless and
have to report synchronously a verdict ( i.e., the success of the exchange or the
detected errors) to their calling component. The end-to-end communication
protection is based on a standardization of mechanisms under the concept
of E2E pro le. Each pro le can have several variants. So the instantiation
of one pro le for a speci c information exchange consists in the choice of a
variant and therefore the setting of the corresponding con guration options.
Each pro le oers all or a subset of the following data protection mechanisms:
checking the integrity of an exchanged data. This is done by an addi-
tional CRC computed by a function belonging to the E2E library,
checking the systematic transmission of a data thanks to a Sequence
Counter. The Sequence Counter is incremented upon each transmis-
sion of the data, allowing thus the receiver to verify that no instance
of the data has been lost,
checking, from the receiver side, if a sender is transmitting a data as
expected. For this purpose, an Alive Counter is used, it is incremented
upon each transmission of the data and the receiver can verify that the
counter has been incremented,
to check if the received data is the one that is expected. This mech-
anism is based on the de nition of a data ID that is not transmitted
with the data but that is used in the computation of the CRC,
nally, to verify that the data is sent and/or received on time. Two
mechanisms are provided for this purpose: receiver communication
timeout and sender acknowledgment timeout.
The CRC and the counters are integrated into a E2E header, which is an
additional control eld transmitted along with the data payload. When
a faulty transmission is detected, the error is then reported to the calling
component.
4 Conclusions and discussion
In our view, the development of in-vehicle embedded communications can
be schematically subdivided into 4 main successive periods:
communication through point-to-point links - until the beginning of
the 90s,
CAN-based architectures as de-facto standard - until 2006,
38
the advent of AUTOSAR and FlexRay - until 2010,
the emergence of automotive Ethernet and security concerns since then.
One may imagine that the next stage will be when the car will become an IP
node in the world wide web ([28], see also [31]), integrated into global data
infrastructures enabling a more e cient type of collaborative mobility [78]
relying on interactions between users and infrastructure operators.
Over the years, the technologies needed for the interoperability between ap-
plications located on dierent ECUs and sub-networks have been improved.
With AUTOSAR, we are now close to the desirable characteristics listed in
section 3. However, if the traditional partitioning of automotive applications
into several distinct functional domains with their own characteristics and
requirements has proven useful in mastering the complexity, it lead to the
development of several independent sub-systems with their speci c architec-
tures, networks and software technologies. Some di culties arise from this
partitioning since more and more cross-domain data exchanges are needed.
The current practice is to transfer data between dierent domains through
a central gateway (see, for example, [39]). This subsystem is recognized as
being critical in the vehicle: it constitutes a single point of failure, its de-
sign is overly complex and ensuring a guaranteed QoS through gateways is
di cult and require a careful design (see, for instance, [90] and [15]). In
the future, the interconnection between vehicle subdomains could be more
e ciently ensured by an Ethernet backbone [29], instead of a gateway. This
backbone will have to support various tra c with dierent QoS requirements
on the same network, which will require to implement QoS policies such as
bandwidth reservation.
A perhaps more di cult challenge ahead of us is security: automotive sys-
tems must be designed to be more resilient to security attacks. This entails
nding the technical solutions, but also the new cooperation schemes be-
tween all the automotive stakeholders, that will permit to achieve the right
trade-o for the automotive domain, between costs/overhead and security
level.
These issues will certainly require more research and development work but
the current state of technological maturity in security, network hardware
components, communication protocols and middleware engineering is such
that in our view everything is at hand to succeed in building safe, secure
and cost-optimized embedded communication architectures for the next car
generations.
References
[1] A. Albert. Comparison of event-triggered and time-triggered concepts
with regards to distributed control systems. In Proceedings of Embed-
39
ded World 2004, Nürnberg, February 2004.
[2] AUTOSAR. Speci cation of SW-C end-to-end communication protec-
tion library, v3.0.0. Available at http://www.autosar.org, 2013.
[3] A. Avizienis, J. Laprie, and B. Randell. Fundamental concepts of de-
pendability. In Proceedings of the 3rd Information Survivability Work-
shop, pages 712, 2000.
[4] M. Ayoubi, T. Demmeler, H. Le er, and P. Köhn. X-by-Wire function-
ality, performance and infrastructure. In Proceedings of Convergence
2004, Detroit, Michigan, 2004.
[5] R. Barbosa and J. Karlsson. Formal speci cation and veri cation of
a protocol for consistent diagnosis in real-time embedded systems. In
Third IEEE International Symposium on Industrial Embedded Systems
(SIES'2008), June 2008.
[6] L. Beaurenaut. Short PWM Code: A step towards smarter automotive
sensors. In Advanced Microsystems for Automotive Applications 2009,
pages 383395. Springer, 2009.
[7] S. Bunzel. Autosar architecture expands safety and security appli-
cations. EETimes, available at http://www.eetimes.com/, February
2011.
[8] C. Butzkamm and D. Bollati. Partial Networking for CAN bus sys-
tems: Any saved gram CO2 /km is essential to meet stricter EU regu-
lations. In 13th International CAN Conference (iCC2012), Hambach,
Germany, March 5-6 2012.
[9] L. Casparsson, A. Rajnak, K. Tindell, and P. Malmberg. Volcano -
a revolution in on-board communications. Technical Report 98-12-10,
Volvo, 1999.
[10] G. Cena and A. Valenzano. Performance analysis of Byte ight net-
works. In Proceedings of the 2004 IEEE Workshop of Factory Commu-
nication Systems (WFCS 2004), pages 157166, September 2004.
[11] FlexRay Consortium. FlexRay communications system - protocol spec-
i cation - version 3.0.1, December 2010.
[12] Continental. Continental shows Ethernet test setup. Press Release,
January 2012.
[13] Intel Corporation. Introduction to in-vehicle networking. Available at
http://support.intel.com/design/auto/autolxbk.htm, 2008.
40
[14] R. Davis, A. Burns, R.J. Bril, and J.J. Lukkien. Controller Area Net-
work (CAN) schedulability analysis: Refuted, revisited and revised.
Real-Time Systems, 35(3):239272, April 2007.
[15] R. Davis and N. Navet. Tra c shaping to reduce jitter in Controller
Area Network (CAN). SIGBED Rev., 9(4):3740, November 2012.
[16] P.H. Dezaux. Migration strategy of in-house automotive real-time
applicative software in AUTOSAR standard. In Proceedings of the
4th European Congress Embedded Real Time Software (ERTS 2008),
Toulouse, France, 2008.
[17] H. Fennel, S. Bunzel, H.Heinecke, J. Bielefeld, S. Fürstand K.P.
Schnelle, W. Grote, N. Maldenerand, T. Weber, F. Wohlgemuth,
J. Ruh, L. Lundh, T. Sandén, P. Heitkämper, R. Rimkus, J. Le our,
A. Gilberg, U. Virnich, S. Voget, K. Nishikawa, K. Kajio, K. Lange,
T. Scharnhorst, and B. Kunkel. Achievements and exploitation of the
AUTOSAR development partnership. In Convergence 2006, Detroit,
USA, October 2006.
[18] J. Ferreira, P. Pedreiras, L. Almeida, and J.A. Fonseca. The FTT-
CAN protocol for exibility in safety-critical systems. IEEE Micro,
Special Issue on Critical Embedded Automotive Networks, 22(4):4655,
July-August 2002.
[19] Ford Motor Company. Ford to study in-vehicle electronic devices
with advanced simulators. Available at url http://media.ford.com/
article_display.cfm?article_id=7010, 2001.
[20] Freescale Semiconductor. New Freescale microcontrollers help stream-
line automotive body electronics networks and reduce vehicle weight.
Press Release available on Reuters.com, March 18 2013.
[21] S. Fürst. AUTOSAR for Safety-Related Systems: Objectives, Ap-
proach and Status. In 2nd IEE Conference on Automotive Electronics,
London, UK, March 2006. IEE.
[22] B. Gaujal and N. Navet. Fault con nement mechanisms on CAN: Anal-
ysis and improvements. IEEE Transactions on Vehicular Technology,
54(3):11031113, May 2005.
[23] B. Gaujal and N. Navet. Maximizing the robustness of TDMA net-
works with applications to TTP/C. Real-Time Systems, 31(1-3):531,
December 2005.
[24] M. Grenier, L. Havet, and N. Navet. The Automotive Embedded Sys-
tems Handbook, chapter Scheduling frames with osets in automo-
41
tive systems: a major performance boost, pages 14.114.15. CRC
Press/Taylor and Francis, December 2008.
[25] M. Grenier, L. Havet, and N. Navet. Con guring the communication
on FlexRay: the case of the static segment. In ERTS Embedded Real
Time Software 2008, 2008.
[26] M. Grenier, L. Havet, and N. Navet. Pushing the limits of CAN -
scheduling frames with osets provides a major performance boost.
InProc. of the 4th European Congress Embedded Real Time Software
(ERTS 2008), Toulouse, France, January 29 - February 1 2008.
[27] H. Kopetz et al. Speci cation of the TTP/A Protocol. University of
Technology Vienna, September 2002.
[28] C. Hammerschmidt. Beyond FlexRay: BMW airs Ethernet plan.
EETimes, available at http://www.eetimes.com/document.asp?doc_
id=1256700, May 2013.
[29] P. Hank, T. Suermann, and S. Müller. Automotive Ethernet, a holistic
approach for a next generation in-vehicle networking standard. In
Advanced Microsystems for Automotive Applications 2012, pages 79
89. Springer, 2012.
CAN with Flexible Data-Rate. In 13th International
[30] F. Hartwich.
CAN Conference (iCC2012), Hambach, Germany, March 5-6 2012.
[31] P. Hoschka. W3C launched work on Web and automotive. In ERCIM
News, ISSN 0926-4981, number 94, Special theme on Intelligent Cars,
page 5. ERCIM-EEIG, July 2013.
[32] C. Humig. Next generation automotive network architecture based on
Ethernet. Slides presented at the 3rd International Conference Chassis
Electri cation, May 2012.
[33] International Standard Organization.ISO 11519-2, Road Vehicles -
Low Speed serial data communication - Part 2: Low Speed Controller
Area Network. ISO, 1994.
[34] International Standard Organization.ISO 11519-3, Road Vehicles -
Low Speed serial data communication - Part 3: Vehicle area network
(VAN). ISO, 1994.
[35] International Standard Organization.ISO 11898, Road Vehicles - In-
terchange of Digital Information - Controller Area Network for high-
speed Communication. ISO, 1994.
15765-2, Road Vehicles - Diag-
[36] International Standard Organization.
nostics on CAN - Part 2: Network Layer Services. ISO, 1999.
42
[37] International Standard Organization. 11898-4, Road Vehicles - Con-
troller Area Network (CAN) - Part 4: Time-Triggered Communication.
ISO, 2000.
[38] K.H. Johansson, M. Törngren, and L. Nielsen. Handbook of Networked
and Embedded Control Systems, chapter Vehicle Applications of Con-
troller Area Network, pages 741765. Birkhäuser Boston, 2005.
[39] H. Kellermann, G. Németh, J. Kostelezky, K. Barbehön, F. El-Dwaik,
and L. Hochmuth. Electrical and electronic system architecture.
ATZextra worldwide, 13(8):3037, 2008.
[40] F. Kirschke-Biller, S. Fürst, S. Lupp, S. Bunzel, S. Schmerler,
R. Rimkus, A. Gilberg, K. Nishikawa, and A. Titze. A worldwide
standard current developments roll out and outlook. In 15th Interna-
tional VDI Congress Electronic Systems for Vehicles 2011, 2011.
[41] R. Klos. MOST in future automotive connectivity. EETimes, available
at http://www.automotive-eetimes.com/, May 2013.
[42] P. Koopman. Critical embedded automotive networks. IEEE Micro,
Special Issue on Critical Embedded Automotive Networks, 22(4):1418,
July-August 2002.
[43] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Check-
oway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage.
Experimental security analysis of a modern automobile. In IEEE Sym-
posium on Security and Privacy (SP2010), pages 447462, 2010.
[44] M. Krug and A. V. Schedl. New demands for in-vehicle networks. In
Proceedings of the 23rd EUROMICRO Conference'97, pages 601605,
Budapest, Hungary, July 1997.
[45] G. Leen and D. Heernan. Expanding automotive electronic systems.
IEEE Computer, 35(1), January 2002.
[46] A Leonhardi, S. Wachter, M. Bösinger, and T. Pech. MOST150's
new features in a series project. EETimes, available at http://www.
automotive-eetimes.com/, May 2011.
[47] T. Liebetrau, U. Kelling, T. Otter, and M. Hel. Energy saving in
automotive E/E architectures. In neon White Paper, December 2012.
[48] LIN Consortium. LIN Speci cation Package, revision 2.2A, December
2010. Available at http://www.lin-subbus.org/.
[49] T. Lindenkreuz. CAN FD - CAN with exible data rate. Slides pre-
sented at Vector Congress 2012, May 2012.
43
[50] Z. Lokaj, T. Zelinka, and M. Srotyr. Cooperative systems for car safety
improvement. In ERCIM News, ISSN 0926-4981, number 94, Special
theme on Intelligent Cars, pages 910. ERCIM-EEIG, July 2013.
[51] J. Machan and C. Laugier. Intelligent vehicles as an integral part of
ERCIM News, ISSN 0926-4981, num-
intelligent transport systems. In
ber 94, Special theme on Intelligent Cars, pages 67. ERCIM-EEIG,
July 2013.
[52] Y. Martin. L'argus de l'automobile, 3969:2223, March 2005.
[53] E. Mayer. Serial bus systems in the automobile - part 5: MOST for
transmission of multimedia data. Summary of Networking Compe-
tence, February 2008. Published by Vector Informatik GmbH.
[54] K. McCrory. Tech tutorial: LVDS oers e cient data transmission for
automotive applications. EETimes, available at http://www.eetimes.
com/, April 2006.
[55] Mercedes-Benz. The new Mercedes-Benz S-Class. Press Release, May
2013.
[56] P. Meumeu-Yomsi, D. Bertrand, N. Navet, and R. Davis. Controller
9th IEEE
Area Network (CAN): Response time analysis with osets. In
International Workshop on Factory Communication System (WFCS
2012), Lemgo/Detmold, Germany, May 21-24 2012.
[57] B. Müller, T. Führer, F. Hartwich, R. Hugel, and H. Weiler. Fault
tolerant TTCAN networks. In Proceedings of the 8th International
CAN Conference (iCC), Las Vegas, Nevada, 2002.
[58] A. Monot, N. Navet, B. Bavoux, and F. Simonot-Lion. Multisource
software on multicore automotive ECUs - combining runnable sequenc-
ing with task scheduling. IEEE Transactions on Industrial Electronics,
59(10):39343942, 2012.
[59] MOST Cooperation. MOST Speci cation Revision 3.0 E2, July 2010.
Available at http://www.mostcooperation.com.
[60] H. Muyshondt. Consumer and automotive electronics converge:
Part 1 - Ethernet, USB, and MOST. Available at http://www.
automotivedesignline.com/, February 2007.
[61] H. Muyshondt. Consumer and automotive electronics converge:
Part 2 - a MOST implementation. Available at http://www.
automotivedesignline.com/, March 2007.
44
[62] F. Simonot-Lion N. Navet. The Automotive Embedded Systems Hand-
book, chapter A Review of Embedded Automotive Protocols, pages
4.14.31. Industrial Information Technology series. CRC Press/Taylor
and Francis, December 2008.
[63] N. Navet, B. Delord, and M. Baumeister. Virtualization in automotive
embedded systems: an outlook. Slides presented at RTS Embedded
Systems 2010 (RTS'2010), March 2010.
[64] N. Navet and H. Perrault. CAN in automotive applications: a look
forward. In 13th International CAN Conference (iCC2012), Hambach,
Germany, March 5-6 2012.
[65] N. Navet, Y. Song, and F. Simonot. Worst-case deadline failure proba-
bility in real-time applications distributed over CAN (Controller Area
Network). Journal of Systems Architecture, 46(7):607617, 2000.
[66] N. Navet, Y. Song, F. Simonot-Lion, and C. Wilwert. Trends in auto-
motive communication systems. Proceedings of the IEEE, 93(6):1204
1223, 2005.
[67] N. Navet and Y.-Q. Song. Validation of real-time in-vehicle applica-
tions. Computers in Industry, 46(2):107122, November 2001.
[68] OSEK Consortium. OSEK/VDX Fault-Tolerant Communication, Ver-
sion 1.0, July 2001. Available at http://www.osek-vdx.org/.
[69] OSEK Consortium. OSEK/VDX time triggered operating system, Ver-
sion 1.0, July 2001. Available at http://www.osek-vdx.org/.
[70] OSEK Consortium. OSEK/VDX Communication, Version 3.0.3, July
2004. Available at http://www.osek-vdx.org/.
[71] OSEK Consortium. OSEK/VDX Operating System, Version 2.2.3,
February 2005. Available at http://www.osek-vdx.org/.
[72] M. Peteratzinger, F. Steiner, and R. Schuermans. Use of XCP on
FlexRay at BMW. Translated reprint from HANSER Automotive
9/2006, available at url http://www.vector.com, 2006.
[73] H. Pfeifer. The Automotive Embedded Systems Handbook, chapter For-
mal Methods in the Automotive Domain: The Case of TTA, pages
15.115.27. CRC Press/Taylor and Francis, December 2008.
[74] J. Pimentel, J. Proenza, L. Almeida, G. Rodriguez-Navas, M. Bar-
ranco, and J. Ferreira. The Automotive Embedded Systems Handbook,
chapter Dependable Automotive CAN Networks, pages 6.16.41. CRC
Press/Taylor and Francis, 2008.
45
[75] L.M. Pinho and F. Vasques. Reliable real-time communication in CAN
networks. IEEE Transactions on Computers, 52(12):15941607, 2003.
[76] S. Poledna, W. Ettlmayr, and M. Novak. Communication bus for
automotive applications. In Proceedings of the 27th European Solid-
State Circuits Conference, Villach, Austria, September 2001.
[77] T. Pop, P. Pop, P. Eles, and Z. Peng. Bus access optimisation for
FlexRay-based distributed embedded systems. In Proceedings of the
conference on Design, Automation and Test in Europe (DATE '07),
pages 5156, San Jose, CA, USA, 2007.
[78] I. Radusch. Collaborative mobility - beyond communicating vehicles.
In ERCIM News, ISSN 0926-4981, number 94, Special theme on Intel-
ligent Cars, page 4. ERCIM-EEIG, July 2013.
[79] A. Rajnák. The Industrial Communication Technology Handbook,
chapter The LIN Standard, pages 31.131.13. CRC Press, January
2005. R. Zurawski editor, ISBN 0-8493-3077-7.
[80] A. Rajnák and M. Ramnefors. The Volcano communication concept.
In Proceedings of Convergence 2002, Detroit, Michigan, 2002.
[81] K. Ramaswamy and J. Cooper. Delivering multimedia content to auto-
mobiles using wireless networks. In Proceedings of Convergence 2004,
Detroit, Michigan, 2004.
[82] J. Rushby. A comparison of bus architectures for safety-critical embed-
ded systems. Technical Report NASA/CR-2003-212161, NASA, March
2003.
[83] R. Saket and N. Navet. Frame packing algorithms for automotive
applications. Journal of Embedded Computing, 2:93102, 2006.
[84] W. Saleem. 1394 Automotive network enables powerful, cost-e cient
in-vehicle networks for infotainment, navigation, cameras. EETimes,
available at http://www.eetimes.com/, May 2009.
[85] A. Schedl. Goals and architecture of FlexRay at BMW. Slides pre-
sented at the Vector FlexRay Symposium, March 2007.
[86] B. Schätz, C. Kühnel, and M. Gonschorek. The Automotive Embedded
Systems Handbook, chapter The FlexRay Protocol, pages 5.15.22. In-
dustrial Information Technology series. CRC Press/Taylor and Francis,
December 2008.
[87] Society of Automotive Engineers. J2056/1 class C application require-
ments classi cations. In SAE Handbook. SAE, 1994.
46
[88] Society of Automotive Engineers. J2056/2 survey of known protocols.
In SAE Handbook, volume 2. SAE, 1994.
[89] Society of Automotive Engineers. Class B data communications net-
work interface - SAE J1850 standard - rev. nov96, 1996.
[90] J. Sommer and R. Blind. Optimized resource dimensioning in an em-
bedded CAN-CAN gateway. In IEEE Second International Symposium
on Industrial Embedded Systems (SIES'2007), pages 5562, July 2007.
[91] T. Steinbach, H-T. Lim, F. Korf, T.C. Schmidt, D. Herrscher, and
A. Wolisz. Tomorrow's in-car interconnect? A competitive evaluation
of IEEE 802.1 AVB and Time-Triggered Ethernet (AS6802). In IEEE
Vehicular Technology Conference (VTC Fall), pages 15, 2012.
[92] R. Tewell, Z. Freeman, and M. Bassler. The 1394 auto network bus
for all high-bandwidth, high-speed communications and infotainment.
Slides presented at SAE 2010 World Congress (session AE305), April
2010.
[93] K. Tindell, A. Burns, and A.J. Wellings. Calculating Controller Area
Network (CAN) message response times. Control Engineering Practice,
3(8):11631169, 1995.
[94] TTTech Computertechnik AG. TTEthernet - a powerful network so-
lution for multiple purpose. Marketing whitepaper, 2013.
[95] TTTech Computertechnik GmbH. Time-Triggered Protocol TTP/C,
High-Level Speci cation Document, Protocol Version 1.1, November
2003. Available at http://www.ttagroup.org.
[96] S. Tuohy, M. Glavin, E. Jones, M.M. Trivedi, and L. Kilmartin. Next
generation wired intra-vehicle networks, a review. In IEEE Intelligent
Vehicles Symposium, Gold Coast, Australia, June 2013.
[97] A. Vollmer. Deutsche OEMs setzen standards. all-electronics.de, avail-
able at http://www.all-electronics.de/texte/anzeigen/42481/
Deutsche-OEMs-setzen-Standards, June 2011.
[98] Volvo. Volvo unveils innovative safety technology - pedestrian detection
with full auto brake debuts on the all-new Volvo S60. Press Release
available at https://www.media.volvocars.com/, March 2 2010.
[99] M. Waern. Evaluation of protocols for automotive systems. Master's
thesis, KTH Machine Design, Stockholm, 2003.
[100] C. Wilwert, N. Navet, Y.-Q. Song, and F. Simonot-Lion. The Industrial
Communication Technology Handbook, chapter Design of Automotive
47
X-by-Wire Systems. CRC Press, January 2005. R. Zurawski editor,
ISBN 0-8493-3077-7.
[101] J. Yoshida. NXP: 3 phases of Automotive Ethernet. EETimes, avail-
able at http://www.eetimes.com/document.asp?doc_id=1319225,
August 2013.
[102] H. Zeltwanger. Partial networking reduces CO2 emissions. CAN
Newsletter 4/2011, December 2011.
[103] H. Zeng, M. Di Natale, A. Ghosal, and A. L. Sangiovanni-Vincentelli.
Schedule optimization of time-triggered systems communicating over
the FlexRay static segment. IEEE Trans. Industrial Informatics,
7(1):117, 2011.
[104] T. Ziermann, J. Teich, and Z. Salcic. DynOAA - dynamic oset adap-
tation algorithm for improving response times of CAN systems. In
DATE, pages 269272, 2011.
48
Index
100BASE-TX, 28 middleware, 29, 3133
1394 Automotive, 25, 26 MOST, 8, 25, 26
Advanced Driver Assistance Systems Nissan, 26
(ADAS), 3, 10, 26, 27 Non-Return-to-Zero (NRZ), 11
AFDX, 29
OPEN Alliance SIG, 27
AUTOSAR, 9, 10, 15, 32, 33, 35, 37,
OSEK/VDX, 15, 31
38
AVB, 18, 25, 2729 partial networking, 9, 27, 30
AVB Gen2 Council, 28 point-to-point communication, 3, 38
AVnu Alliance, 28 powertrain domain, 4
PSA, 17, 32
BMW, 4, 8, 19, 26
PSI5, 5, 25
BroadR-Reach, 27
QoS, 25, 27, 29, 39
CAN, 49, 11, 15, 3638
CAN 2.0A, 11 Renault, 26
CAN 2.0B, 11 Robert Bosch, 4, 17, 21, 27
CAN FD, 10, 17
SAE AS6802, 28
chassis domain, 5
SAE classi cation, 7
collaborative mobility, 39
SAE J2716, 25
COTS toolsets, 15
schedulability analysis, 16, 31
Daimler, 26, 31 scheduling frames with osets, 16
security, 9, 10, 38
ECU degradation, 9 SENT, 5, 25
end-to-end communication protection simulation, 16
library, 30, 37 SPC protocol, 25
Ethernet, 8, 2628, 38, 39
TDMA, 6, 18, 19
FlexRay, 8, 15, 18, 31, 36, 38 time-triggered, 6, 18, 19, 21, 25, 28,
frame-packing, 16, 20 32
FTT-CAN, 7 trace analysis, 16
functional domains, 4 TTCAN, 7, 18, 21, 22
TTEthernet, 7, 18, 28
gateway, 8, 15, 16, 18, 39 TTP/A, 7, 22, 25
TTP/C, 7, 18, 19, 31
ISO 11898-6, 9
VAN, 11, 17
J1850, 7, 11, 17 virtualization, 10
J1939, 15 Volvo, 8, 31
LIN, 5, 7, 8, 17, 22, 36, 37 X-by-Wire, 5, 18
49
You might also like
- Chapter 04 Embedded Systems Application and Domain SpecificNo ratings yetChapter 04 Embedded Systems Application and Domain Specific7 pages
- Review of Electrical and Electronic Architectures For Autonomous Vehicles: Topologies, Networking and SimulatorsNo ratings yetReview of Electrical and Electronic Architectures For Autonomous Vehicles: Topologies, Networking and Simulators20 pages
- Automotive Networking: Course Learning Objectives (Clos)No ratings yetAutomotive Networking: Course Learning Objectives (Clos)54 pages
- Inter Vehicle Communication Seminar Presentation40% (5)Inter Vehicle Communication Seminar Presentation41 pages
- Presented by N.Spandana N.Mani Madhuri: Ramachandra College of Engg E.C.E Department100% (3)Presented by N.Spandana N.Mani Madhuri: Ramachandra College of Engg E.C.E Department16 pages
- Introduction of CAN FD Into The Next Generation of Vehicle E/E Architectures100% (1)Introduction of CAN FD Into The Next Generation of Vehicle E/E Architectures6 pages
- Automotive Network Architecture For Ecus Communications: April 2009No ratings yetAutomotive Network Architecture For Ecus Communications: April 200927 pages
- Session 1 Notes - Automotive NetworkingNo ratings yetSession 1 Notes - Automotive Networking48 pages
- Embedded Control Systems Design/AutomotiveNo ratings yetEmbedded Control Systems Design/Automotive7 pages
- Politecnico Di Torino Porto Institutional Repository: (Article) Connected Car: Technologies, Issues, Future TrendsNo ratings yetPolitecnico Di Torino Porto Institutional Repository: (Article) Connected Car: Technologies, Issues, Future Trends37 pages
- R R R R R: Connected Car: Technologies, Issues, Future TrendsNo ratings yetR R R R R: Connected Car: Technologies, Issues, Future Trends36 pages
- A Survey of Autonomous Vehicles: Enabling Communication Technologies and ChallengesNo ratings yetA Survey of Autonomous Vehicles: Enabling Communication Technologies and Challenges49 pages
- AI-Based Intrusion Detection Systems For In-VehicleNo ratings yetAI-Based Intrusion Detection Systems For In-Vehicle40 pages
- Network Bandwidth Optimization of Ethernet-Based Streaming Applications in Automotive Embedded SystemsNo ratings yetNetwork Bandwidth Optimization of Ethernet-Based Streaming Applications in Automotive Embedded Systems6 pages
- Sensor Networks On The Car State of The Art and Future ChallengesNo ratings yetSensor Networks On The Car State of The Art and Future Challenges6 pages
- 06 Hideki Goto - Toyota JasPar IndustryNo ratings yet06 Hideki Goto - Toyota JasPar Industry18 pages
- Electronic Design FocusOnAutoCommunicationsEbook PDFNo ratings yetElectronic Design FocusOnAutoCommunicationsEbook PDF24 pages
- Embedded System in Automobiles: Department of Electrical and Electronics EngineeringNo ratings yetEmbedded System in Automobiles: Department of Electrical and Electronics Engineering26 pages
- Approaches For In-Vehicle Communication - An Analysis and OutlookNo ratings yetApproaches For In-Vehicle Communication - An Analysis and Outlook17 pages
- Extracting Controller Area Network Data For Reliable Car CommunicationsNo ratings yetExtracting Controller Area Network Data For Reliable Car Communications6 pages
- Examsgrade API 580 Exam Questions AnswersNo ratings yetExamsgrade API 580 Exam Questions Answers7 pages
- Is 2102 Part 2 1993 ISO 2768 2 1989 General Tolerances Part 2 Geometrical Tolerances For Features Without Individual Tolerance Indications100% (1)Is 2102 Part 2 1993 ISO 2768 2 1989 General Tolerances Part 2 Geometrical Tolerances For Features Without Individual Tolerance Indications24 pages
- Typical Wiring Diagram: Deep Sea Electronics 053-085 Issue 3No ratings yetTypical Wiring Diagram: Deep Sea Electronics 053-085 Issue 32 pages
- Controlled Power, LLC 38kV Metal Clad Switchgear Guide SpecificationNo ratings yetControlled Power, LLC 38kV Metal Clad Switchgear Guide Specification17 pages
- Online Ship Control System Using Supervisory Control and Data Acquisition (Scada)No ratings yetOnline Ship Control System Using Supervisory Control and Data Acquisition (Scada)5 pages
- FAQ On The Options Available in The Troubleshooting Menu in Fusion ApplicationNo ratings yetFAQ On The Options Available in The Troubleshooting Menu in Fusion Application6 pages
- Semiconductor Dry Etch Systems Market - Forecasts From 2024 To 2029No ratings yetSemiconductor Dry Etch Systems Market - Forecasts From 2024 To 20298 pages
- Blockchain-Based Merchant Payment System: 1) Background/ Problem StatementNo ratings yetBlockchain-Based Merchant Payment System: 1) Background/ Problem Statement9 pages
- Courier Tracking System Project ShowcaseNo ratings yetCourier Tracking System Project Showcase2 pages
- CAN Protocol Essentials: Definitive Reference for Developers and EngineersFrom EverandCAN Protocol Essentials: Definitive Reference for Developers and EngineersNo ratings yet