Introduction of CAN FD Into The Next Generation of Vehicle E/E Architectures
Introduction of CAN FD Into The Next Generation of Vehicle E/E Architectures
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.
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
05-2
iCC 2017 CAN in Automation
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
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
CANH - CANL
CANH - CANL
CANH - CANL
CANH - CANL
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