100% found this document useful (1 vote)
119 views6 pages

Introduction of CAN FD Into The Next Generation of Vehicle E/E Architectures

This document discusses how CAN FD will fit into next generation vehicle E/E architectures. It notes that automakers are introducing CAN FD as vehicle networks grow more complex with connected, autonomous, electric, and shared vehicles. CAN FD can help meet increasing bandwidth demands better than traditional CAN. The document outlines an example multi-domain vehicle architecture with Ethernet as the backbone network and CAN FD, FlexRay, and LIN within domains. It explores how Ethernet and new communication concepts in AUTOSAR enable CAN FD and Ethernet for automotive use cases.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
119 views6 pages

Introduction of CAN FD Into The Next Generation of Vehicle E/E Architectures

This document discusses how CAN FD will fit into next generation vehicle E/E architectures. It notes that automakers are introducing CAN FD as vehicle networks grow more complex with connected, autonomous, electric, and shared vehicles. CAN FD can help meet increasing bandwidth demands better than traditional CAN. The document outlines an example multi-domain vehicle architecture with Ethernet as the backbone network and CAN FD, FlexRay, and LIN within domains. It explores how Ethernet and new communication concepts in AUTOSAR enable CAN FD and Ethernet for automotive use cases.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

iCC 2017 CAN in Automation

Introduction of CAN FD into the next generation


of vehicle E/E architectures
Dr. M. Schreiner , L. Donat, S. Köngeter, Daimler AG

Automakers are about to introduce CAN FD into the next generation of vehicle E/E
architectures. This paper will give an overview about general trends and technologies in
the next generation of vehicle architectures. It will be shown how CAN FD fits into these
new architectures and where, how and why it is used there. The way CAN FD interacts
with other communication systems will be discussed. An insight into the everyday
implications one has to deal with while integrating CAN FD from the architecture,
software and hardware point of view will be given. Finally the paper will conclude with
an outlook what to expect from CAN FD in future.

Introduction comparable the mobile phone industry when


smartphones were introduced.
In 1991 Mercedes-Benz launched the first
CAN network in a passenger car (Mercedes Autonomous driving: more and more driving
S-Class series W140) with 5 CAN nodes assistance systems will be introduced finally
and only one year later CAN was also leading to autonomously driving vehicles.
deployed in a truck (Mercedes-Benz This will also turn the dream of accident free
SK – “Schwere  Klasse”). The first CAN driving into reality.
applications enabled new concepts in the
vehicles’ powertrain and chassis domain. Shared vehicles: structural changes in urban
Soon CAN spread to all other domains of the areas but also in many peoples’ societies
vehicle, e.g. body, telematics and comfort. suggest new usage and mobility concepts.
CAN was a key enabling technology that These will be pushed by connected and
made driving safer, more comfortable and autonomous driving technology.
more efficient.
Electric driving: saving our planet’s climate,
freeing megacities from pollution or a
driving experience with unprecedented
acceleration – there are many reasons why
cars’ powertrain will be more and more
electric in future.

It is evident that these changes have a strong


and demanding impact on future vehicle E/E
architectures and on in vehicle networking
technology. In the following it will be shown
how such architectures could look like and
Figure 1: Vision of future mobility how and why CAN FD is one of the key
technologies meeting future requirements.
Today automobile industry is on the verge
of several dramatic changes in which four The benefit of CAN FD for future vehicle
trends are standing out: architectures

Connected driving: in future all vehicles will At the time when CAN FD was introduced
be connected online enabling amazing new by BOSCH in 2012 [1] researchers have
services and applications – a revolution already been working on the next big

05-1
iCC 2017 CAN in Automation

thing for in-vehicle networking: automotive up to 254 byte per frame, however it is used
Ether-net [2]. Virtually the introduction of in practice with much smaller frames due
automotive Ethernet pushed the intro- to its predefined cyclic operation manner.)
duction of CAN  FD as a consequence. The Ethernet however was originally developed
future requirements have mainly two effects for completely different applications – local
on the vehicle’s E/E architecture: growing and wide area networks with focus on
complexity and the demand for much higher transferring large data packets. Typical
bandwidth in some parts of the network. This Ethernet related communication principles
can be handled best by means of structuring like switching of data packets, virtual LANs,
the architecture into different domains (e.g. TCP, IP etc. have been established for this
body, chassis - ADAS, powertrain and purpose. Sensor and actuator systems
telematics). Figure 2 shows an exemplary have not been on the scope of Ethernet in
automotive E/E architecture structured into the beginning. However as Ethernet is a
four domains interconnected by an Ethernet structured system according to the ISO/OSI
backbone network. Theoretically this model it could be enabled for automotive use
backbone structure could also be realized cases by adopted hardware (100BASE-T1)
using another bus system, however only and extended communication concepts
Ethernet can cope with the amount of data like SOME/IP (scalable service-oriented
that is currently being anticipated for future middleware over IP), DoIP (diagnosis
use cases. over IP) while existing concepts like IEEE
1722 (AVB) and IEEE 1588 (precision time
diagnosis
protocol) have been extended.
body chassis powertrain telematics These concepts are included in the
AUTOSAR software standard [3] which
controller
controller controller controller

is the basis for all current vehicle ECUs.


Another communication concept which was
introduced with Ethernet into AUTOSAR is
IPDU multiplexing [4]. The purpose of this
feature is to cluster multiple PDUs (these
might be coming from different applications)
body chassis powertrain telematic
dynamically into one Ethernet frame and to
wrap these into a header structure indicating
Ethernet FlexRay
CAN(FD)
identifier and size of the PDUs. The Ethernet
LIN
frame itself which has a very large payload
Figure 2: multi domain architecture with field in comparison to classical CAN or
Ethernet backbone structure [8]. FlexRay messages can be regarded as
a transport container. Only this additional
Apart from the backbone Ethernet structure step makes Ethernet efficient and flexible
there are also requirements inside the for automotive use cases maintaining an
domains themselves that imply the usage efficient header to payload ratio.
of further Ethernet sub-networks inside the Apart from this, the future trends described
domains, as indicated in figure 2 e.g. inside in the introduction of this paper bring about
the telematics domain. requirements to secure communication in
This intensive usage of automotive Ethernet terms of safety and authentication e.g. for
brings about the necessity to introduce new functional safety of ADAS systems or to
communication concepts [2]. Automotive prevent remote attacks on vehicles. These
networking by now mainly requires sensor requirements are also addressed by dedi-
actuator busses where small messages are cated additional communication concepts
exchanged with low latency and high cycle in AUTOSAR. The most important of these
repetition time. The protocol overhead in are SecOC [5] (secure on-board communi-
systems like classical CAN, LIN or FlexRay cation) which provides mechanisms
is designed to be low and the maximum to protect authenticity and integrity of
PDU size (protocol data unit) is typically data) and E2E [6] (end to end
limited to 8 byte. (FlexRay might be using protection – different profiles exist) to

05-2
iCC 2017 CAN in Automation

protect safety critical communication Practical application of CAN FD


in terms of fault of the communication
channel, e.g. bit errors. All these While developing the next generation of
mechanisms imply a considerable protocol the vehicle E/E architecture many classical
overhead (headers, CRCs, signatures CAN networks will be migrated completely
etc.) compared to the data that has to to CAN FD. However approximately half of
be transferred. the CAN FD networks that will be introduced
Automotive Ethernet can cope with are due to new applications that did not
these requirements as it offers plenty of exist in previous architectures. This means
bandwidth and nearly unlimited payload per that CAN  FD is not just a replacement for
message (up to 1500 byte) in comparison existing classical CAN networks it also
to the typical 8 byte payload of systems directly captures new applications. Even
like LIN or classical CAN. Hence at the though there will be automotive Ethernet
first glance automotive Ethernet seemed with several nodes in the next generation
to divide in-vehicle networking technology of the vehicle E/E architecture a growth of
into two worlds: a new Ethernet based part CAN interfaces can be observed as well
with plenty of bandwidth and payload per which indicates that CAN is still a growing
message featuring modern communication technology [9]. This growth however is
concepts and an old world consisting of mainly observed for CAN  FD components.
classical CAN and LIN stuck at 8 byte per With regard to the distribution of CAN  FD
message, comparably low communication over the different domains it can be stated,
speed and very limited possibilities in terms that there’s no typical domain or use case
of modern communication concepts. for CAN FD which approves that CAN FD is
This separation was overcome with the a very universal system like classical CAN is
introduction of the new CAN  FD protocol today. Actually CAN FD can be found in any
[7,8]. An increase of the data transfer by domain of the next vehicle E/E architecture
a factor of up to four and especially an generation. The same is true with respect
increase of the payload length by a factor to communication speed. It will be used in
of 8 enabled CAN technology to keep up large networks with many nodes at
with the new communication concepts comparably low communication speed (e.g.
while maintaining its main advantages: 250 kbps/500 kbps) as well as in small
CAN  FD is like classical CAN a flexible networks with few nodes and high
bus that is easy to handle at a decent communication speed (e.g. 500 kbps/
price ratio dedicated for a large scope 2 Mbps). And for some applications a
of applications. A selection of the new value in-between is optimum (e.g.
communication concepts (especially IPDU 500 kbps / 1 Mbps). This scaling of different
multiplexing, see figure 3, SecOC and communication speeds however is mainly
E2E protection) developed for Ethernet due to the physical limitations of the
will also be adopted to CAN  FD which is CAN  FD physical layer.
only sensible due to the availability of an From the network designer’s point of view
extended payload of 64 byte. Hence many one single communication speed would
CAN nodes can be switched over to the have been preferable but this trade-
world of new communication concepts but off is necessary to match the different
anyhow continue using CAN technology. requirements with the given CAN  FD
physical layer. It has been shown [10] that
CAN- e.g. a communication speed of 500 kbps/
2 Mbps is only possible in limited physical
ID

topologies.
PDU
Header 1
PDU 1 (8 Byte) PDU
Header 2
PDU 2 (8 Byte) …
PDU
Header n
PDU n (8 Byte) Finally it has to be mentioned, that classical
CAN has not yet died out. It will still be part of
PDU-ID: 24-bit Adressierung für PDU
future vehicle E/E architectures, especially
PDU-ID length
PDU-Length: 8-bit PDU Länge for carry-over components and use cases
that do not yet require new communication
Figure 3: IPDU multiplexing for CAN  FD concepts introduced with automotive

05-3
iCC 2017 CAN in Automation

Ethernet technology. However a decline of are typically free from any reflections yielded
classical CAN in favour of CAN FD is obvious. a substantial amount of asymmetry. The
In the long run it can be anticipated that there reason for this was found out when analysing
will only be CAN FD components left besides the topology shown in figure 4.
some historic remains (e.g. diagnostic CAN).
120Ω 120Ω
Implications of CAN FD – from the ECU1 ECU2 ECU3 ECU4
everyday business of an OEM

Size of topologies – In the beginning there vary 1m .. 10m vary 1m .. 10m vary 1m .. 10m

were high expectations about the achievable


vary ZL 80 .. 150Ω vary ZL 80 .. 150Ω vary ZL 80 .. 150Ω

data rate of CAN FD. BOSCH was showing Figure 4: Line topology for 2 Mbit/s CAN FD
a demonstration with 10 Mbit/s and more
[11]. So in the beginning even 8 Mbit/s have The analysis result given in figure 5 shows a
been under discussion for standardization. Monte Carlo method analysis of this topology
The assumption was, that the arbitration with varying characteristic line impedance
process would be the main limiting factor and line length as given in figure 4.
for CAN communication speed in general.
But after intensive investigations on failure loopback ECU2 TX_ECU2 →RX_ECU1

mechanisms it soon became clear the

CANH - CANL
CANH - CANL

asymmetric distortion of the CAN signal on


the physical layer is the limiting factor of
CAN FD networks in the data phase [10].
TX_ECU2 →RX_ECU3 TX_ECU2 →RX_ECU4
The definition of the transceivers’ maximum
allowable asymmetry by ISO11898-2:2016

CANH - CANL
CANH - CANL

and the research by BOSCH about the


maximum allowable asymmetry of received
signals in CAN FD networks (“phase margin”)
are today the basis to assess CAN networks Figure 5: Montecarlo analysis of line
[12]. In an intensive analysis about the topology @ 2 Mbit/s
phase margin characteristics of different
topologies it became clear, that with today’s This simulation result neglects the frequency
CAN physical layer the freedom in topology dependent attenuation intentionally in order
creation is very limited if the network should to point out the effect more clearly. There
work at 2 Mbit/s in the data phase [10]. Even are substantial reflections at the 120 Ohm
though 5 Mbit/s have been defined by ISO terminations on both sides of the bus as
this speed is currently not feasible under line impedance and termination do not
automotive conditions. Referring to this a match, which results in signal distortion at
further improvement of the CAN physical the edges of the CAN signal. Especially
layer (especially for transceivers specified at the dominant to recessive edge is affected
5 Mbit/s) would be desirable. as the signal distortion exceeds the
CAN cables – During the investigations to switching threshold of the CAN receiver at
optimize the CAN FD topologies [10] it also 500/900 mV; see dashed lines in figure 5.
turned out, that the cable characteristics The effects at the recessive to dominant
become more and more important with edge however happen on a higher voltage
rising communication speed. In the past level not touching the switching thresholds –
little attention was spent on the electric the result is asymmetry. If the transmission
characteristics of CAN cables. These line characteristic impedance is fixed to
had to meet the thermal and mechanical 120 Ohm the reflections will be removed
requirements and apart from that primarily completely, as can be expected.
they had to be cheap, whereas electrical There are different possibilities to solve
characteristics have not been specified in the this issue. The first is to control the cable
past. When using arbitrary CAN cables it was characteristic and force the cable to have
found that even optimal line topologies which 120 Ohm. However this implies that the

05-4
iCC 2017 CAN in Automation

thickness of the insulation material has to be In ISO11898-2:2016 this issue was addressed
increased. Especially for the widely used cable by adding an optional “CAN activity filter time”
type FLRY-A with 0,35 mm² cross section of 1,8 µs, i.e. a dominant phase of 1,8 µs
this means that these do not fit to standard would be enough to wake the bus. This will
automotive connectors anymore, especially ensure safe wake up with any CAN or CAN
those connectors that are sealed in the engine FD frame using 500 kbit/s arbitration speed or
compartment and the outside of the vehicle are less and any speed in the data phase. Since
affected. The second possibility would be to transceivers supporting this feature have not
lower the CAN termination in the end nodes to yet penetrated the market special measures
100 Ohm which is quite close to typical FLRY- have to be taken by the OEM to ensure safe
A-2x0,35 mm² cables. New CAN transceivers wakeup. There are several possibilities:
according to ISO11898-2:2016 are able to 1. Generally limit the ID range in order
optionally drive up to 45 Ohm load. However to ensure that there’s always three
in the end all possible solutions to this issue consecutive dominant bits in any ID used.
require some trade-offs. 2. Use classical CAN messages for bus
Wake up function – The possibility to wake wake-up.
up CAN nodes over the network has been 3. Use dedicated CAN FD messages for bus
introduced a long time ago (ISO11898-5) wake-up with at least three consecutive
and this technology is widely used today. dominant bits in the ID field.
However when using the CAN FD protocol in 4. Use dedicated CAN FD messages for bus
the network some of the assumptions made wake-up with at least three consecutive
for ISO11898-5 are not valid anymore. In a dominant bits in the data field. Transmit
CAN FD message with 500/2000 kbps it is these frames with arbitration speed in the
not ensured that there is a dominant phase data phase, i.e. BRS = dominant.
of at least 5 µs as a transceiver according to Some more options may exist. All of them
ISO11898-5 requires to wake up (cf. “CAN implicate trade-offs. The first solution is
activity filter time”). In the classical CAN easy to implement but it restricts the usable
protocol this was always ensured by the ID range a lot. All other solutions require
consecutive RTR, IDE, FDF bits for 11-bit ID a special priority treatment of the wake-up
frames and the RTR, FDF, r0 bits for 29-bit message in the ECUs’ software stack. It
ID frames. For CAN FD frames this is not has to be ensured that this is really the first
the case, as can be seen from table 1. For message which is put into the transmit buffer
CAN FD frames with 29-bit IDs there are of the CAN controller in an ECU that intends
constellations even without any two dominant to wake-up the bus. If this is not ensured
consecutive bits in the control field. another message might be sent first and the
network will get stuck without waking up.
Table 1: worst case CAN and CAN FD wake
up timing values Expectations for CAN FD in future
consecutive dom. @ It has been shown that the introduction of
frame
dom. bits 500 kbit/s
CAN FD was the right innovation at the right
classical frame time. CAN FD perfectly complements the
RTR IDE FDF 6 µs
11-bit ID newly introduced Ethernet core networking
classical frame structure of future vehicle architectures.
RTR FDF r0 6 µs
29-bit ID The increased communication speed but
FD frame especially the increased payload field
ID18 RRS IDE 6 µs enable CAN FD technology to keep up with
even ID, 11-bit ID
FD frame future communication mechanisms and
RRS IDE 4 µs networking concepts that came along with
odd ID, 11-bit ID
automotive Ethernet technology.
FD frame
ID0 RRS 4 µs During the development process several
even ID, 29-bit ID
shortcomings of CAN FD were detected
FD frame which mainly affect the physical layer. Some
n/a 2 µs
odd ID, 29-bit ID of these have already been addressed by

05-5
iCC 2017 CAN in Automation

ISO11898-2:2016 and it’s only a question [10] CAN FD System Design – Marc Schreiner,
of market penetration to solve these (e.g. CAN in Automation iCC 2015, Vienna, Austria.
wake-up). Others still require the further [11] CAN FD CAN with Flexible Data-rate, BOSCH
improvement of the CAN physical layer. Automotive Electronics, CiA CAN FD TechDay
The final goal should be to achieve 5Mbit/s Detroit, Oct. 2012
in the data phase over networks that are [12] Robustness of a CAN  FD Bus System – About
comparable in terms of flexibility and Oscillator Tolerance and Edge Deviations – A.
dimensioning to classical 500 kbit/s CAN Mutter, iCC 2013 Paris
networks. This could be achieved by means [13] CiA 601-4 version 1.0.0 CAN FD Node and
of technologies that especially improve the system design – Part 4: Ringing suppression,
signal integrity of the dominant to recessive CiA 2015-12-18
edge. One approach could be the so
called “ringing suppression technology” as
proposed in CiA601-4 [13].
CAN FD with communication speed above
5 Mbit/s is doubtful. On the one hand there’s
currently no physical layer available for
this, on the other hand the bit time settings
and the required clock speed become
more and more inappropriate with increas-
ing communication speed. Eventually
10 BASE-T1 Ethernet, a cheap extension to
100 BASE-T1, is expected to put a natural
limit to CAN FD expansion for higher speed.

References
[1] CAN with Flexible Data-Rate - Florian
Hartwich, CAN in Automation, iCC 2012,
Neustadt an der Weinstraße.
[2] Automotive Ethernet, K. Matheus and Th.
Königseder, Cambridge University Press
2015, ISBN978-1-107-05728-9
[3] AUTOSAR (AUTomotive Open System
Architecture), http://www.AUTOSAR.org/
[4] Specification of I-PDU Multiplexer, AUTOSAR
Standard 4.2.2, document 182, http://www.
AUTOSAR.org/ Dr. Marc Schreiner
[5] Specification of Module Secure Onboard Daimler AG – Research and Development
Communication, AUTOSAR Standard 4.2.2, Wilhelm-Runge-Straße 11
document 654, http://www.AUTOSAR.org/ DE-89081 Ulm
[6] Specification of SW-C End-to-End [email protected]
Communication Protection Library, AUTOSAR
Standard 4.2.2, document 428, http://www. Lukas Donat
AUTOSAR.org/ Daimler AG – Research and Development
[7] Safeguarding CAN FD for applications in Bela-Barenyi-Str. 1
trucks - M. Schreiner, H. Leier, M. Zerzawy, T. DE-71063 Sindelfingen
Dunke and J. Dorner, CAN newsletter 3/2013. [email protected]
[8] CAN FD from an OEM point of view, M.
Schreiner, H. Mahmoud, M. Huber S. Koç, Sebastian Köngeter
J. Waldmann, CAN in Automation, iCC 2013 Daimler AG – Research and Development
Paris and CAN Newsletter 2/2014. Bela-Barenyi-Str. 1
[9] Automotive Ethernet - An Independent View, DE-71063 Sindelfingen
Ian Riches, StrategyAnalytics 2011 [email protected]

05-6

You might also like