 Ethernet and CAN FD – Enablers for new Communication Paradigms
Vector Congress 2014-11-27
1/6
V1.0 | 2014-11-23
Agenda

Introduction
New Communication Paradigm for CAN FD
New Communication Paradigms for Ethernet
Effects on the Database
Summary
2/15
Introduction
Signal- and PDU-based Communication
CAN, LIN and FlexRay are the dominant automotive network technologies

Communication matrix is statically defined in a database
 Sender and receiver relations per bus/network


R
FIBEX
R
Signals, PDUs and frames (classically all with static length)
Mapping of signals onto PDUs and mapping of PDUs onto frames
>
Meaningful mapping of signals onto PDUs is already a complex task (max. 8 bytes payload for CAN)
Signals
3/15
R
LDF
AR
Sys.
Desc.
CAN
S
DBC
PDU
Frame
New Communication Paradigm for CAN FD
CAN FD (Flexible Data Rate)
CAN FD is an improved CAN protocol


Higher bit rates for data bytes (Mode 1)
 Arbitration-Phase – same bit rate as classic CAN
 Data-Phase – bit rate up to ~8 Mbit/s (theoretical value)
CAN
Head
CAN FD
Head
4/15
1
2
2
3
3
4
5
4
6
5
7
8
7
8
6
7
8
Tail
Tail
Up to 64 bytes of payload per frame (Mode 2)
CAN FD

1
Head
1
2
3
4
5
6
…
58
59
60
61
62
63
64
Tail
Definition of long PDUs with corresponding signal mappings is still possible
 Creation of communication matrix becomes more complex (up to 64 instead of 8 bytes payload)
New Communication Paradigm for CAN FD
Possible Scenario for CAN FD Introduction
Existing CAN network
CAN
CAN
5/15
Gateway
Bus load limit reached for classic CAN
CAN FD

Requirements for the replacement of CAN by CAN FD
 Use the benefit of CAN FD as much as possible (64 bytes payload)
 Modify the existing communication matrix as less as possible
 Don’t make the gateway much more complex than before

New paradigm: Dynamic Multi-PDU-to-Frame mapping
 Reuse already defined (CAN) PDUs
 Transmit multiple (CAN) PDUs in one CAN FD frame
New Communication Paradigm for CAN FD
New Paradigm: Dynamic Multi-PDU-to-Frame Mapping
PDU1
PDU2
Gateway
CAN
CAN
HPDU2
PDU1
PDU2 PDU4
PDU2
H PDU4
PDU3
H
PDU3
PDU1 H
PDU4
PDU1
CAN FD
PDU4
PDU3
ECU (e.g. gateway) collects PDUs and transmits them in one CAN FD frame

The order of PDUs within the frame is arbitrary to use the available bandwidth efficiently
 Requires additional header information
 Different frame triggerings maybe necessary

6/15
Still an easy change
New Communication Paradigm for CAN FD
New Paradigm: Dynamic Multi-PDU-to-Frame Mapping
The feature was added in AUTOSAR 4.2.1



7/15
S
Realized in the IPDU Multiplexer (IpduM)
 Network independent
 Contained PDU-to-Container PDU mapping
Different Container PDU (frame) triggerings
 Container PDU threshold exceeded
 Container PDU timeout
 Contained PDU timeout
 High-priority Contained PDU
 First Contained PDU triggers
Two different header formats
 4 bytes header (3 bytes ID, 1 byte length)
 8 bytes header (4 bytes ID, 4 bytes length)
Application
4.
RTE
COM / LDCOM
1
5.
PDUR
2
3
4
Container PDU
IPDUM
1.
2.
3.
CAN
Stack
FR
Stack
ETH
Stack
New Communication Paradigms for Ethernet
Network Topologies
CAN (FD)
FlexRay
S
R
R
S
S
R
R

Ethernet
S
R
R
Bus
 Broadcast
>
Intelligent
receiver

Active star
 Broadcast
>
Intelligent
receiver
S

Fully switched
network
(point-to-point)
 Unicast
>

Multicast and broadcast
>
8/15
Intelligent sender
Intelligent receiver
R
R
New Communication Paradigms for Ethernet
New Paradigm: Dynamic Multi-PDU-to-Frame Mapping
Ethernet comes along with …

… up to 1500 bytes of payload per frame

… the possibility of unicast communication

New paradigm: Dynamic Multi-PDU-to-Frame mapping
 Assemble frames with receiver-specific
content if unicast communication is used
>
>

Efficient usage of the bandwidth
Reduce processer load at receivers
Realization in AUTOSAR by the
Socket Adaptor (SoAd) module
>
IpduM can be used as well but SoAd
offers more options with respect to dynamic
configuration of communication paths
S
1.
Application
RTE
2.
3.
COM / LDCOM
PDUR
1
5.
2
Socket 1
1
2
3
4.
R
Socket 2
2
3
Socket 3
SOAD
(incl. Ethernet Stack)
9/15
R
4.
R
New Communication Paradigms for Ethernet
New Paradigm: Service-Oriented Communication (1)
Build up communication relationships during runtime


Don’t send meaningless data and send data only when
there is a need
 Reduce bandwidth usage
 Save processing resources at sender and receiver side
The location of the sender shall be flexible
 Variant handling
C
S
Offer service
Call method
Get return values
Offer service

Service Discovery
 What is a service?
>
>


10/15
Methods: Remote Procedure Calls
Events: Publish/Subscribe, get notifications automatically
Service provider (server): Announce the availability and
location of an offered service (broadcast)
Service consumer (client): Subscribe to event groups to
get notifications
Subscribe to event group
Get notifications
New Communication Paradigms for Ethernet
New Paradigm: Service-Oriented Communication (2)
Data serialization

Today, signals are “serialized” statically to fit the
PDU layout specified in the database

Especially in the ADAS domain, there are more and
more data elements of dynamic length
 E.g. object data of a complex sensor
>

Signals
PDU
Number of recognized objects varies during operation
A static PDU layout has to consider the worst case scenario
>
DB
In most cases, a lot of “empty” signals are transmitted
PDU
(Byte stream)
Structured data
struct

Scalable Service-Oriented Middleware over IP (SOME/IP)
 (De-)Serialization of signals during runtime
>
>
>
11/15
Signals and PDUs of dynamic length
Don’t specify all signals and the PDU layout in a database
Transmit only the relevant and currently available data elements
>
Save bandwidth
>
Save computing resources
uint32 val1
float32 val2
int8 arr[1..9]
uint8 val3
SOME/IP
val1_1
val1_2
val1_3
val1_4
val2_1
val2_2
val2_3
val2_4
arr len
arr_1
arr_2
val3_1
New Communication Paradigms for Ethernet
New Paradigm: Service-Oriented Communication
Realization of Service Discovery and SOME/IP in AUTOSAR 4.2.1

Example: Server sends event notification
1. Service Discovery communication to handle service offer
and event group subscription (interaction with SW-C over BSWM)
S
SW-C
1.
3.
RTE
4. SOMEIPXF
BSWM
LDCOM
SD
2.
PDUR
5.
SOAD
(incl. Ethernet Stack) 6.
12/15
2. Service Discovery configures communication paths in the
Socket Adaptor (PDU-to-Frame/Socket mapping)
3. Software Component (SW-C) sends signals (structured data)
4. Structured data is serialized in the RTE transformer (SOMEIPXF)
and SOME/IP header information is added
5. Socket Adaptor adds second part of SOME/IP header
information (PDU header for dynamic Multi-PDU-to-Frame mapping)
6. Socket Adaptor decides when to send a frame, based on the
different frame triggering options
Effects on the Database
AUTOSAR System Description
AUTOSAR 4.2.1
 Dynamic Multi-PDU-to-Frame mapping
1. General approach for IpduM
2. Ethernet-specific in the Socket Adaptor (extensions for service-oriented communication)

Service-oriented communication
>
>

There is no other database format offering the same possibilities as the AUTOSAR System
Description
>
13/15
Service Discovery
> Definition of the service content (methods and events) is spread over the System Template
> Uses the dynamic Multi-PDU-to-Frame mapping of the Socket Adaptor
SOME/IP
> “Signal” definition by application (SW-C) interfaces (Sender/Receiver and Client/Server interfaces)
> Dynamic length PDU including one dynamic length signal
FIBEX 4.1 was specified with focus on Ethernet and service-oriented communication but the trend goes
towards the more comprehensive AUTOSAR System Description
Summary
Ethernet and CAN FD – Enablers for new Communication Paradigms
Ethernet and CAN FD come along with new challenges

New communication paradigms are introduced to get the whole benefit of the new technologies
1. Dynamic Multi-PDU-to-Frame mapping
2. Service-oriented communication (currently for Ethernet, in future also for CAN FD?)
>
>
Build up communication paths during runtime: Service Discovery
Data serialization: SOME/IP
Vector is ready to support you in meeting these new challenges!

MICROSAR – AUTOSAR Basic Software
 Ethernet stack incl. the AUTOSAR 4.2.1 features and more
 CAN FD ready CAN stack
>
14/15
Soon incl. Mode 2 and dynamic Multi-PDU-to-Frame mapping

Tools for analysis, simulation, diagnostics,
measurement and calibration

Consulting
ETH
V2G
AVB
ETHXCP
UDPNM
SD
DOIP
SOAD
TCPIP
ETHSM
ETHTSYN
ETHIF
DNS
EXI
HTTP
SCC
TLS
XML Sec.
AVTP
BMCA
PTP
Your questions are welcome!
Author:
Marc Weber
Vector Informatik GmbH
© 2014. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2014-11-23