1 / 6 

Ethernet and CAN FD – Enablers for new Communication Paradigms

Vector Congress 2014-11-27 V1.0 | 2014-11-23

2/15

Agenda



Introduction

New Communication Paradigm for CAN FD New Communication Paradigms for Ethernet Effects on the Database Summary

3/15 Introduction

Signal- and PDU-based Communication

CAN, LIN and FlexRay are the dominant automotive network technologies  DBC Communication matrix is statically defined in a database  Sender and receiver relations per bus/network   LDF FIBEX S R R R AR Sys. Desc. 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 PDU Frame

4/15 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) Head Head 1 1 2 3 2 4 5 3 6 7 4 8 5 Tail 6 7 8 Tail   CAN FD Head 1 2 3 4 5 6 7 8 … 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)

5/15 New Communication Paradigm for CAN FD

Possible Scenario for CAN FD Introduction

Existing CAN network Gateway Bus load limit reached for classic CAN   CAN 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

6/15 New Communication Paradigm for CAN FD

New Paradigm: Dynamic Multi-PDU-to-Frame Mapping

CAN CAN PDU1 PDU2 Gateway PDU4 H H H CAN FD H PDU1  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 Still an easy change

7/15 New Communication Paradigm for CAN FD

New Paradigm: Dynamic Multi-PDU-to-Frame Mapping

The feature was added in AUTOSAR 4.2.1  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) 5. S Application RTE COM / LDCOM 4. PDUR 1. CAN Stack 2. FR Stack 3. ETH Stack 1 2 3 4 IPDUM

8/15 New Communication Paradigms for Ethernet

Network Topologies

CAN (FD) S FlexRay R R R S R R  Bus  Broadcast > Intelligent receiver  Active star  Broadcast > Intelligent receiver S S Ethernet R  Fully switched network (point-to-point)   Unicast > Intelligent sender Multicast and broadcast > Intelligent receiver S R R

9/15 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 2. 3. S 1. Application RTE COM / LDCOM PDUR 5. 1 2 2 3 3 SOAD (incl. Ethernet Stack) 4. 4. R R R

10/15 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  Service Discovery    What is a service? > > 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 C Offer service Call method Get return values S Offer service Subscribe to event group Get notifications

11/15 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 > Number of recognized objects varies during operation  A static PDU layout has to consider the worst case scenario > In most cases, a lot of “empty” signals are transmitted  Scalable Service-Oriented Middleware over IP (SOME/IP)  (De-)Serialization of signals during runtime > > > 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 Signals DB Structured data struct uint32 val1 float32 val2 int8 arr[1..9] uint8 val3 PDU SOME/IP PDU (Byte stream) val1_1 val1_2 val1_3 val1_4 val2_1 val2_2 val2_3 val2_4 arr len arr_1 arr_2 val3_1

12/15 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. RTE S SW-C 3. 4. SOMEIPXF BSWM LDCOM SD 2. PDUR 5. SOAD (incl. Ethernet Stack) 6. 1. Service Discovery communication to handle service offer and event group subscription (interaction with SW-C over BSWM) 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

13/15 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 > Service Discovery > > > SOME/IP > “Signal” definition by application (SW-C) interfaces (Sender/Receiver and Client/Server interfaces) > 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 Dynamic length PDU including one dynamic length signal  There is no other database format offering the same possibilities as the AUTOSAR System Description > FIBEX 4.1 was specified with focus on Ethernet and service-oriented communication but the trend goes towards the more comprehensive AUTOSAR System Description

14/15 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 Soon incl. Mode 2 and dynamic Multi-PDU-to-Frame mapping Tools for analysis, simulation, diagnostics, measurement and calibration Consulting ETH ETHXCP UDPNM SD DOIP SOAD TCPIP ETHSM ETHTSYN ETHIF V2G DNS EXI HTTP SCC TLS XML Sec. AVB 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