An assessment analysis of network protocols used in automotive industry
D. Piromalis, N. Vasilakis, K. Geroulis, K. Delivorias, D. Tseles
Abstract
This paper presents a study of current communication protocols used in the automotive
industry. This domain has special requirements to the communication protocol.
The aim of this study is to examine and evaluate the different technologies used.
Due to that, the study is divided into three parts including the analysis of each protocol, the
communication requirements and the comparison of the protocols.
A major evaluation criterion was the protocols’ correspondence to the Open Systems
Interconnection Reference Model (OSI/RM).
1 Introduction
The past four decades have witnessed an exponential increase in the number and
sophistication of electronic systems in vehicles. Today, the cost of electronics in luxury
vehicles can amount to more than 23 percent of the total manufacturing cost.
Just as LANs connect computers, control networks connect a vehicle’s electronic equipment.
These networks facilitate the sharing of information and resources among the distributed
applications.
Today modern cars already contain a multiplicity of controllers that are increasingly
networked together by various bus communication systems with very different properties.
Automotive communication networks have access to several crucial components of the
vehicle, like breaks, airbags, and the engine control.
2 Protocols
In the following, we give a short technical description of each protocol. Further readings can
be found in [1],[2],[3],[4],[5],[6].
Controller Area Network (CAN)
The all-round Controller Area Network, developed in the early 1980s, is an event-triggered
controller network for serial communication with data rates up to one MBit/s. Its multi-master
architecture allows redundant networks, which are able to operate even if some of their nodes
are defect. CAN messages do not have a recipient address, but are classified over their
respective identifier. Therefore, CAN controllers broadcast their messages to all connected
nodes and all receiving nodes decide independently if they process the message. CAN uses
the decentralized, reliable, priority driven CSMA/CD (Carrier Sense Multiple Access /
Collision Detection) access control method to guarantee every time the transmission of the
top priority message always first. In order to employ CAN also in the environment of strong
electromagnetic fields, CAN offers an error mechanism that detects transfer errors, interrupts
and indicates the erroneous transmissions with an error flag and initiates the retransmission of
the affected message. Furthermore, it contains mechanisms for automatic fault localization
including disconnection of the faulty controller.
1
Time-triggered CAN (TTCAN)
As an extension of the CAN protocol, time-triggered CAN has a session layer on top of the
existing data link and physical layers. The protocol implements a hybrid, time triggered,
TDMA schedule, which also accommodates event-triggered communications. The ISO task
force responsible for the development of TTCAN, which includes many of the major
automotive and semiconductor manufacturers, developed the protocol.
TTCAN’s intended uses include engine management systems and transmission and chassis
controls with scope for X-by-wire applications.
Time-Triggered Protocol (TTP)
TTP is "time triggered" as opposed to "event triggered" so all nodes on the network have a
common concept of time, through roughly synchronized clocks. All activities are carried out
at certain points in time, decided at system design time, rather than network activities being
triggered by external events, as in a CSMA protocol such as CAN. As TTP is a TDMA
protocol, latency is deterministic. There is a bus guardian that guarantees that no node can
monopolize communication media outside its transmission slot, so the network should be safe
from "babbling idiots".
The network appears to be peer-to-peer, as each node has its own controller and bus guardian.
TTCAN’s intended uses include engine management systems and transmission and chassis
controls with scope for X-by-wire applications.
Local Interconnect Network (LIN)
The UART (Universal Asynchronous Receiver Transmitter) based LIN (Local Interconnect
Network) is a single-wire sub network for low-cost, serial communication between smart
sensors and actuators with typical data rates up to 20 kBit/s. It is intended to be used from the
year 2001 on everywhere in a car, where the bandwidth and versatility of a CAN network is
not required. A single master controls the hence collision-free communication with up to 16
slaves, optionally including time synchronization for nodes without a stabilized time base.
LIN is similarly to CAN a receiver-selective bus system. Incorrect transferred LIN messages
are detected and discarded by the means of parity bits and a checksum. Beside the normal
operation mode, LIN nodes provide also a sleep mode with lower power consumption,
controlled by special sleep respectively wake-up message.
Flexray
FlexRay is a deterministic and error-tolerant high-speed bus, which meets the demands for
future safety-relevant high-speed automotive networks. With its data rate of up to 10 MBit/s
(redundant single channel mode) FlexRay is targeting applications such as Drive-by-Wire and
Powertrain. The flexible, expandable FlexRay network consists of up to 64, point-to-point or
over a classical bus structure connected, nodes. As physical transmission medium both optical
fibers and copper lines are suitable.
FlexRay is similarly to CAN a receiver-selective bus system and uses the cyclic TDMA
(Time Division Multiple Access) method for the priority driven control of asynchronous and
synchronous transmission of non-time-critical respectively time-critical data via freely
configurable, static and dynamic time segments. Its error tolerance is achieved by channel
redundancy, a protocol checksum and an independent instance (bus guardian) that detects and
handles logical errors.
Byteflight
2
A flexible time-division multiple-access (TDMA) protocol for safety-related applications,
Byteflight can be used with devices such as air bags and seat-belt tensioners. Because of its
flexibility, Byteflight can also be used for body and convenience functions, such as central
locking, seat motion control, and power windows. BMW, ELMOS, Infineon, Motorola, and
Tyco EC collaborated in its development. Although not specifically designed for X-by-wire
applications, Byteflight is a very high performance network with many of the features
necessary for X-by-wire.
MOST
The ISO/OSI standardized MOST (Media Oriented System Transport) serial high-speed bus
became the basis for present and future automotive multimedia networks for transmitting
audio, video, voice, and control data via fiber optic cables. The peer-to-peer network connects
via plug-and-play up to 64 nodes in ring, star or bus topology. MOST offers, similarly to
FlexRay, two freely configurable, static and dynamic time segments for the synchronous (up
to 24 MBit/s) and asynchronous (up to 14 MBit/s) data transmission, as well as a small
control channel.
The control channel allows MOST devices to request and release one of the configurable 60
data channels. Unlike most automotive bus systems, MOST messages include always a clear
sender and receiver address. Access control during synchronous and asynchronous
transmission is realized via TDM (Time Division Multiplex) respectively CSMA/CA. The
error management is handled by an internal MOST system service, which detects errors over
parity bits, status flags and checksums and disconnects erroneous nodes if necessary.
Intelligent Transport System Data Bus (IDB)
The IDB Forum manages the IDB-C and IDB-1394 buses and standard interfaces for OEMs
that develop aftermarket and portable devices.
Based on the CAN bus, IDBC is geared toward devices with data rates of 250 Kbps.
IDB-1394 (based on the IEEE-1394 FireWire™ standard) is designed for high speed
multimedia applications. IDB-1394 is a 400 Mbps network using fiber-optic technology.
Applications include DVD and CD changers, displays, and audio/video systems.
IDB-1394 also allows 1394-portable consumer electronic devices to connect and interoperate
with an in-vehicle network. Zayante Inc., for example, supplies 1394 physical layer devices
for the consumer market. A recent joint demonstration with the Ford Motor Company
included plug and play connections of a digital video camera and a Sony PlayStation™ 2
game console, as well as two video displays and a DVD player.
Digital Data Bus (D2B)
The Digital Data Bus is a networking protocol for multimedia data communication that
integrates digital audio, video, and other high-data-rate synchronous or asynchronous signals.
It can run as fast as 11.2 Mbps and be built around either SmartWire™ unshielded twisted
pair cable or a single optical fiber.
This communication network is being driven by C&C Electronics in the UK and has industry
acceptance from Jaguar and Mercedes-Benz. The D2B optical multimedia system is designed
to evolve in line with new technologies while remaining backwards compatible. D2B optical
is based on an open architecture that simplifies expansion, because changes to the cable
harness are not required when adding a new device or function to the optical ring. The bus
uses just one polymer optical fiber to handle the in-car multimedia data and control
information. This gives better reliability, fewer external components and connectors, and a
significant reduction in overall system weight.
3
3 Communication requirements
The requirements on automotive communications very much depend on the subsystems using
the automotive network. Today several different field bus technologies are used to address
various communication requirements, which include fault tolerance, determinism, bandwidth,
flexibility and security.
• Fault tolerance - When the system does not behave as its specification it is caused by faults,
errors and failures. When a failure occurs, this is caused by an error in the system. An error is
an unintended state, or part of a state, of the system. The cause of an error is a fault. Hence, a
fault can cause an error which might result in a failure. Fault tolerant (typically safety-critical)
communication systems are built so they are tolerant to defective circuits, line failures etc.,
and constructed using redundant hard and software architectures. Moreover, they should
provide error containment, by using, for example, bus guardians to prevent the existence of
babbling idiots.
• Determinism - A deterministic communication system provides guarantees in terms of
timeliness, i.e., it makes it possible to know the transmission time of a message. Deterministic
communication requires correct reception of messages. Many safety critical automotive
systems and subsystems also have strong real-time requirements which need determinism, i.e.
messages have to be sent at predefined time instants (or within precise time intervals) to fulfill
the intended subsystem functionality. An example is an airbag system, as the airbag has to be
inflated at exactly the correct time in order to function properly, not too early nor too late.
• Bandwidth - High bandwidth is also required in many automotive subsystems. However,
there is a trade-off between required bandwidth, the cost of providing such a bandwidth and
the level of subsystem integration that is possible to achieve with a single shared
communication bus. In many cases it is more desirable selecting a cheaper communication
bus with lower bandwidth due to strong requirements on cost. However, the latest automotive
communication technologies provide high bandwidth allowing for the latest automotive
subsystems working together with high degree of system integration.
• Flexibility - Flexibility can be seen as, for example, the ability to handle event- and timetriggered messages, the possibility to cope with varying load and/or number of message flows
on the network, scalability and extensibility of the network. In Time Division Multiple Access
(TDMA) networks, all message transmissions must be predetermined offline, while in Carrier
Sense Multiple Access (CDMA) networks message transmissions are resolved online. The
latter is often considered more flexible than the former. Some networking technologies allow
a combination of TDMA and CSMA message transmissions.
• Security - When the communication is reachable from outside the automotive system by,
e.g., diagnostics tools, wireless connections and telematics, it is important to ensure the
security of the system, i.e., no authorized accesses to the system have to be possible.
4 Comparison
The communication requirements of an automotive protocol and thus of an automotive
network were highlighted above. This study’s scope was to compare the automotive protocols
4
according to those requirements but also to examine their correspondence to the OSI
Reference Model.
4.1 Automotive protocols and OSI/RM
Modern computer networks are designed in a highly structured way. To reduce their design
complexity, most networks are organized as a series of layers, each one built upon its
predecessor.
The OSI Reference Model is based on a proposal developed by the International Organization
for Standardization (ISO). The model is called ISO OSI (Open Systems Interconnection)
Reference Model because it deals with connecting open systems - that is, systems that are
open for communication with other systems.
The OSI model has seven layers. The principles that were applied to arrive at the seven layers
are as follows:
1. A layer should be created where a different
of abstraction is needed.
level
2. Each layer should perform a well defined
function.
3. The function of each layer should be
chosen with an eye toward defining
internationally standardized protocols.
4. The layer boundaries should be chosen to
minimize the information flow across the
interfaces.
5. The number of layers should be large
enough that distinct functions need not be
thrown together in the same layer out of
necessity, and small enough that the
architecture does not become unwieldy.
The CAN protocol itself implements most of the lower two layers of this reference model.
The communication medium portion of the model was purposely left out of the Bosch CAN
specification to enable system designers to adapt and optimize the communication protocol on
multiple media for maximum flexibility (twisted pair, single wire, optically isolated, RF, IR,
etc.).
With this flexibility, however, comes the possibility of interoperability concerns.
To ease some of these concerns, the International Standards Organization and Society of
Automotive Engineers (SAE) have defined some protocols based on CAN that include the
Media Dependant Interface definition such that all of the lower two layers are specified.
ISO11898 is a standard for high-speed applications, ISO11519 is a standard for low-speed
applications, and J1939 (from SAE) is targeted for truck and bus applications. All three of
these protocols specify a 5V differential electrical bus as the physical interface. The rest of the
5
layers of the ISO/OSI protocol stack are left to be implemented by the system software
developer.
Higher Layer Protocols (HLPs) are generally used to implement the upper five layers of the
OSI Reference Model.
HLPs are used to:
1) standardize startup procedures including bit rates used,
2) distribute addresses among participating nodes or types of messages,
3) determine the structure of the messages, and
4) provide system-level error handling routines.
This is by no means a full list of the functions HLPs perform, however it does describe some
of their basic functionality.
Protocols
OSI layers
CAN
TTCAN
TTP
LIN
FlexRay
Byteflight
MOST
◦
◦
×
◦
√
◦
√
Presentation
◦
◦
×
◦
◦
◦
◦
Session
◦*
◦
×
◦
◦
◦
◦
Transport
◦
◦
×
◦
√
◦
◦
Network
◦
◦
×
√
◦
◦
◦
Data Link
√
√
×
√
√
√
√
Physical
√
√
×
√
√
√
√
Most of the protocols used in the automotive industry, like CAN, mostly use the two or three
layers of OSI/RM (see table 4.1)
Application
Physical Layer
Dual - wire
√
: used layers
×
: unused layers
◦
: open for developer
* :
Dual - wire
Optical Fiber
Dual - wire
Single - wire Optical Fiber
Optical Fiber
Optical Fiber
Dual - wire
for applications with demands of data synchronization, an extension of the CAN
protocol
Table 4.1 Protocols’ correspondence to OSI/RM
4.2 Bandwidth
6
As mentioned in the communication requirements, there is a trade-off between required
bandwidth and the cost of providing such a bandwidth.
The protocols used in safety critical systems provide a higher bandwidth from those used for
example for automatic door locking.
4.3 Broadcast messages
The most noticeable common feature of these protocols seems to be that messages are
broadcast so all receivers receive the message and can act upon it if they are interested.
Broadcast messages immediately introduce a problem in using SDL to model network
message passing, as an SDL "signal" is sent to a specific recipient, though it may be broadcast
in the sense of being sent by all available paths, in much the way that an Ethernet message is
sent to every node on the network, but is addressed to a specific receiver. In CAN, for
example, the transmitter will not know which nodes are interested in the message, it
broadcasts it to all and sundry, similarly to a radio broadcast, the message being identified by
its source, not its recipient. An SDL signal can have its sender identified.
Of course, in the context of a subsystem, we might be able to dodge this issue, by simply
modeling the message being sent from the subsystem's (only) sender to its (only) receiver, but
this fails to model the protocol, and also fails to address situations where the system has
several receivers of the same message, such as separate ECUs for each lamp cluster.
4.4 Undetected errors
7
According to Comparison CAN vs. Byteight vs. TTP/C [10], CAN, Byteight and TTP/C all use a CRC
and all have a hamming distance of 6, so the probability of an undetected error is more or less equal in
each case.
This makes the probability of an undetected error vanishingly small, but of course if a fault in a sensor,
say, causes it to send an incorrect reading, this will be transmitted accurately and so will lead to
incorrect behavior. This is, of course, not a fault with the network.
Some older protocols (such as UBP) use a checksum rather than a CRC, which makes an undetected
error less unlikely. The probability is still low and, in view of these protocols' obsolescence the
difference can probably be ignored.
Of course a detected error will lead to the message being retransmitted which will result in a delay in
its correct reception, especially if it needs to contend for network access again (as in CAN).
4.5 CSMA and TDMA
The most obvious way of grouping the various protocols is by access control. CAN is CSMA/CD, so
messages will be interrupted if they lose arbitration, while TTP/C and Flexray are TDMA, so there
will be no collisions to resolve, if the network is working correctly.
Modeling interruptions in CAN looks to be potentially the most difficult problem to solve in modeling
these networks, as it is non deterministic. It seems plausible to argue that modeling messages coming
from different concurrently running sources is impossible on a single processor computer, as even
running concurrent processes means that the models of some sources will stop while another process
has the CPU. Another approach might be to model late messages statistically. This is possible, once
the source priorities are known. If the frequency with which each source sends (or tries to send) a
message is also known, then the network loading can also be established and the statistical likelihood
of an interrupt can be arrived at. Another problem that arises from modeling collisions, whether by
modeling different terminals' behaviors or statistically, is the possibility that the configuration of the
network is not known at the time of running the simulation. It seems possible that this might arise if a
simulation of a subsystem is to be undertaken early in the design lifecycle of the vehicle. There seems
to be no useful way of avoiding this difficulty.
As the TDMA protocols are more deterministic, it seems reasonable to suppose that they will be easier
to model. Therefore it should be possible to adapt a modeling approach that is capable of simulating a
CSMA protocol for a TDMA one. The main difficulty seems to be the need to model time in some
suitable way, but if we are to model message delays, we must model time anyway.
On the other hand, as a TDMA protocol needs some global concept of time, they introduce a new
class of failures concerning loss of this idea, for example a TTCAN "time master" failing to send a
time reference message. All such protocols will have some fault tolerance in this area, but it might
well be that these behaviors need modeling.
Applications
CAN
TTCAN
TTP
LIN
FlexRay
Byteflight
MOST
Chassis
Air – bags
Powertrain
Body and
Comfort
X – by - wire
Multimedia/
infotainment
Wireless /
Telematics
Diagnostics
YES
YES
YES
YES
NO
YES
SOME
NO
SOME
NO
NO
NO
NO
SOME
NO
YES
YES
NO
NO
NO
YES
NO
NO
YES
NO
NO
NO
SOME
YES
YES
NO
YES
YES
NO
NO
NO
NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
NO
YES
SOME
SOME
SOME
SOME
SOME
SOME
Requirement
Fault Tolerant
Determinism
Bandwidth
CAN
SOME
YES
SOME
TTCAN
SOME
YES
SOME
TTP
YES
YES
YES
LIN
NO
YES
FlexRay
YES
YES
YES
Byteflight
YES
YES
YES
MOST
NO
SOME
YES
8
Flexibility
Security
Property
Bit Rate
Cost
YES
NO
YES
NO
SOME
NO
YES
NO
YES
NO
YES
NO
YES
SOME
1Mbps
L/M
1Mbps
L
25Mbps
H
20Kbps
L
10Mbps
M
10Mbps
M
25Mbps
H
References
[1] http://www.can cia.org/can/ttcan/
[2] www.tzm.de/en/FlexRay/FlexRay_Introduction.html
[3] www.byteflight.com/presentations/index.html
[4] www.vector cantech.com/va_most_us,,4165.html
[5] www.lin-subbus.org/
[6] http://www.tttech.com/
[7] www.cs.umd.edu/class/spring2002/cmsc818m/doc/0220/expanding.pdf
[8] www.aber.ac.uk/compsci/Research/mbsg/fmeaprojects/SoftFMEAtechreports
/systems/protocols.pdf
[9] David Bradbury Simulation of a Time Triggered Protocol, Supervised by Agathe
Mercaron, available at : www.liafa.jussieu.fr/~merceron/pub/Thesis091100.pdf
[10] TTTech Computerthchnik AG. Comparison CAN vs Byteight vs TTP/C.
9