m.eng. marc weber - vector: software · m.eng. marc weber product management ... ethernet switch...

V2.01.01 | 2015-05-08

Webinar: The AUTOSAR Ethernet Stack and its Use Cases

ModeratorOverview

M.Eng. Marc WeberProduct Management Engineer

Embedded Ethernet Software Stack

2/49

Ethernet@Automotive webinar seriesOverview

Part 2: The AUTOSAR Ethernet Stack and its Use Cases> Moderator: Marc Weber

> Tuesday, May 26th, 2015 (DE) - Tuesday, June 2nd, 2015 (EN)

Part 3: Introduction of Audio/Video Bridging over Ethernet in vehicles> Moderator: Bernd Jesse

> Wednesday, June 10th, 2015 (DE) - Friday, June 12th, 2015 (EN)

Part 1: Introduction to Ethernet and IP in automotive vehicles> Moderator: Jan Bossert

> Wednesday, May 6th, 2015 (EN) – Wednesday, May 13th, 2015 (DE)

3/49

Ethernet in AutomotiveOverview

Ethernet and TCP/IP technologies have made their way into the vehicle and they are expected to expand into new application areas

Automotive OEMs and suppliers are facing diverse challenges here

4/49

Time synchronization

Traffic shaping

Audio/Video data transmission and reception

Please refer to Embedded Solution AVB

Ethernet in Automotive – How?Overview

Service Discovery

SOME/IP

UDP Network Management

Signal- and PDU-based communication

DoIP incl. flashbootloader

XCP on Ethernet incl. XCP Routing

Mirroring

Smart Charge Communication according to ISO and DIN standards

Customer-specific functions

Ethernet – MICROSAR.ETH Vehicle-to-Grid – MICROSAR.V2G

Audio/Video Bridging – MICROSAR.AVB

5/49

Network CharacteristicsOverview

S

R

R

S

R

R

R

S R

S

R

S

R

CAN (FD)

Bus

Broadcast

FlexRay

Active Star

Broadcast

Ethernet

Fully switched network(point-to-point)

Unicast

Multicast and broadcast

6/49

Overview 2

AUTOSAR and MICROSAR Software Architecture 8

MICROSAR.ETH – In-Vehicle Ethernet Communication 16

MICROSAR.ETH – Diagnostics 24

MICROSAR.ETH – Measurement and Calibration 33

Outlook: MICROSAR.V2G 38

Outlook: MICROSAR.AVB 41

Summary 45

Agenda

7/49

OverviewAUTOSAR and MICROSAR Software Architecture

RTE

OS

SYS

CAN

COM

LIN FR ETH V2G1

AVB1

IO LIBS

ComplexDriver

MCAL

OS DIAG MEM

AMD

BSWM

COMM

CSM (CRY)

DET

ECUM

STBM

WGDIF

WGDM

DCM

DEM

FIM

EA

FEE

MEMIF

NVM

DBG

DLT

COM IPDUM NMLDCOM

J1939TP

CANXCP

CANTP

CANNM

CANSM

CANIF

LINXCP1

LINTP

LINNM

LINSM

LINIF

FRXCP

FRTP

FRARTP

FRNM

FRSM

FRIF

ETHXCP

SOAD

TCPIP

ETHSM

ETHIF

DNS

EXI

HTTP

SCC

TLS

XML Security

IOHWAB CAL (CPL)

CRC

E2E

AVTP

BMCA

PTP

FRTRCV

LINTRCVCANTRCV

DRVEXT2

ETHTRCV

XCP1

ADCDRV

CANDRV

CORTST

DIODRV

EEPDRV

ETHDRV

FLSDRV

FLSTST

FRDRV

GPTDRV

ICUDRV

IICDRV1

LINDRV

MCUDRV

PORTDRV

SHEDRV1

RAMTST

PMWDRV

SPIDRV

WDGDRV

3rd Party SoftwareVector Standard Software

Microcontroller

1 Available extensions for AUTOSAR2 Includes EXTADC, EEPEXT, FLSEXT, ETHSWTEXT and WDGEXT

EXT

SCHM

J1939DCM

J1939NM

J1939RM

DOIP

SD

UDPNM

OCUDRV

TM

RTM1

PDUR

COMXF E2EXFSOMEIPXF

ETHSWT

SECOC

CANTSYN

FRTSYN

ETHTSYN

8/49

Ethernet Communication StackAUTOSAR and MICROSAR Software Architecture

ETH – Ethernet Driver

Uniform API to access all Ethernet controllers of the same type

ETHTRCV – Ethernet Transceiver Driver

Uniform API to access all Ethernet transceivers of the same type

ETHSWT – Ethernet Switch Driver

Configuration of Ethernet switches – e.g. Virtual Local Area Networks (VLANs) and routing tables

Uniform API to access all Ethernet switches of the same type (ETHSWTEXT for external switches which are configured e.g. via SPI)

ETHTRCVETH

ETHSWT

9/49


ETHIF – Ethernet Interface

Hardware independent interface to access all Ethernet drivers and transceiver drivers

Handling of different VLANs

ETHSM – Ethernet State Manager

Enabling and disabling of Ethernet controller and transceiver to switch on or off communication

ETHTRCVETH

ETHIF

ETHSM

COMM

ETHSWT

10/49


TCPIP – TCP/IP stack

IPv4/v6 – Internet Protocol version 4/6 IPv4 and IPv6 can be used in parallel

ARP – Address Resolution Protocol (IPv4)

NDP – Neighbor Discovery Protocol (IPv6)

ICMPv4/v6 – Internet Control Message Protocol version 4/6

UDP – User Datagram Protocol

TCP – Transmission Control Protocol

DHCPv4/v6 – Dynamic Host Configuration Protocol version 4/6 DHCPv4 server and client, DHCPv6 client

SOAD – Socket Adaptor

Transformation of socket-based into AUTOSAR PDU-oriented communication

ETHIF

PDUR

ETHSM

SOAD

TCPIPIPv4, ARP, ICMPv4IPv6, NDP, ICMPv6

UDP, TCP, DHCPv4, DHCPv6

COMM

ETHTRCVETH

ETHSWT

11/49

Supported Hardware (further hardware supported on request)

AUTOSAR and MICROSAR Software Architecture

Microcontrollers / Ethernet controllers

MPC (FEC and ENET)

TriCore, Aurix

V850, RH850

Jacinto 6

VTT (Simulating an Ethernet controller within a CANoe DLL)

Ethernet transceivers

BroadR-Reach: BCM89810, TJA1100, Generic (all MII transceivers)

100BASE-TX/1000BASE-T: DP83848, Generic (all MII transceivers)

VTT (Simulating an Ethernet transceiver within a CANoe DLL)

Ethernet switches

External: BCM89501, BCM89200

Internal: MPC57xx, Jacinto 6

12/49

Ethernet SwitchesAUTOSAR and MICROSAR Software Architecture

Automotive Ethernet switches offer different configuration possibilities

VLAN

Forwarding tables

Queuing mechanisms

…

AUTOSAR architecture fits to all known Ethernet switch architectures

PHY

MAC

PHY

µC

MAC

PHY

Switch Engine

MAC

PHY

µC

Switch Engine

PHY

MAC

PHY

µC

MAC MAC MAC

Switch

SPI(config.only)

13/49

MICROSAR vs. Open Source SoftwareAUTOSAR and MICROSAR Software Architecture

Why to prefer the MICROSAR TCP/IP stack over an open source solution?

Defined warranty (contains no open source software)

Optimized resource consumption in RAM, ROM and runtime Not required features can be switched off Optimized RAM and ROM usage based on the configuration No dynamic memory allocation for predictable behavior

Flexible configuration of the TCP/IP stack – e.g. use different time-out values than specified in RFCs, which are adapted to automotive use cases

Developed according to automotive standards MISRA compliance Using AUTOSAR methodology (e.g. memory mapping)

Internal test suite and verification by Fraunhofer ESK Munich (IPv6/TCP)

Very good support Very good knowledge about every detail within the TCP/IP stack Fast and flexible bugfixing

Customer specific extensions/modifications possible

14/49

Overview 2







Summary 45

Agenda

15/49

Service Discovery (SD)MICROSAR.ETH – In-Vehicle Ethernet Communication

Service-oriented communication scheme instead of a classical signal-oriented approach

What is a “Service”? A Service can contain “Methods” which can be called by other ECUs,

this mechanism is known as Remote Procedure Call (RPC) A Service can contain “Events” to which other ECUs can subscribe to be

informed about changes or updates There are Service providers (servers) and Service consumers (clients)

What is the purpose of Service Discovery? A provider announces the availability and implicitly the location of a

Service via Service Discovery to other ECUs A consumer knows the availability of a Service, can call Methods and

can subscribe to offered Event groups

Service Discovery was first specified in AUTOSAR 4.1.1

16/49

Service Discovery (SD)MICROSAR.ETH – In-Vehicle Ethernet Communication

Advantages

Avoid sending of invalid signals Save bandwidth

Avoid sending multi- and broadcasts but use unicast Save bandwidth on alternative

communication paths (use advantage of Ethernet as a switched network)

Reduce CPU load

Dynamic relocation of Services possible

Modes

Announce on startup

Query/Announce

Publish/Subscribe

Offer service

Call method

Get return values (if available)

Offer service

Call method

Get return values (if available)

Query service

Offer service

Subscribe to event group

Get notifications automatically

Client Server

17/49

Scalable Service-Oriented Middleware over IP (SOME/IP)MICROSAR.ETH – In-Vehicle Ethernet Communication

SOME/IP is an automotive serialization protocol

Definition of a header format which supports RPCs, i.e. calling a function on a remote server ECU like it would be executed on the own ECU

Definition how application data shall be serialized to the on-the-wire payload

Support of basic data types, complex data types (e.g. C-struct), static and dynamic array data types

Independent on endianness

Designed for AUTOSAR and non-AUTOSAR ECUs

struct

uint32 val1

float32 val2

val1_1

val1_2

val1_3

val1_4

val2_1

val2_2

val2_3

val2_4

Structured data

length arr

arr_1

(arr_2)

(arr_3)

uint8 arr[1..3]

Byte stream

18/49

Scalable Service-Oriented Middleware over IP (SOME/IP)MICROSAR.ETH – In-Vehicle Ethernet Communication

SOME/IP does not require Service Discovery and vice versa; however, they are designed to work together

Methods calls can be performed via SOME/IP messages

Event notifications can be sent via SOME/IP messages

Service Discovery messages like ‘Offer’ and ‘Query’ use the SOME/IP header

SOME/IP was specified by BMW

Auxiliary document in AUTOSAR 4.1.1

SOME/IP transformer in AUTOSAR 4.2.1

Send serialized parameters(uint8[]) to server

Send serialized return value(uint8[]) to client

Client Server

Server_Add(1, 2);Serialize(1, 2);

Deserialize(uint8[]);Add(1, 2);

Serialize(3);

Deserialize(uint8[]);Server_Add_Result(3);

19/49

Signal-/PDU-based communicationMICROSAR.ETH – In-Vehicle Ethernet Communication

Signals PDU Frame

Mapping of Signals onto a PDU and a PDU onto a frame

Similar to classical communication on CAN

Transmission and reception of multiple PDUs in one Ethernet frame to save resources

Fan-out mechanism allows to transmit one PDU to several destinations via unicast

Location of a PDU within a frame is dynamic

Socket Adaptor adds and removes a small header to differentiate between PDUs which comprises a PDU identifier and a length field

Different frame triggering mechanisms available

PDU Frame (UDP packet)Header Header Header

20/49

UDP Network Management (UDPNM)MICROSAR.ETH – In-Vehicle Ethernet Communication

Coordination of the transition between normal operation and bus-sleep mode of an Ethernet network

Periodic broadcast messages are sent by nodes which want to keep the NM-cluster awake

No master node

Node detection (detect all present nodes in a network)

Ready sleep detection (detect if all nodes in a network are ready for bus-sleep mode)

Partial Networking support added with AUTOSAR 4.1.1

Similar to network management on CAN

Limitation on wake-up handling

Only TJA1100 supports wake-up based on Ethernet communication Currently proprietary solution

21/49

Software ArchitectureMICROSAR.ETH – In-Vehicle Ethernet Communication

SOAD

ETHIF

ETHSM



COMM SD

RTE

BSWM

SD – Service Discovery

Management of service states

Configuring communication paths over the Socket Adaptor e.g. disable routing if service is not available

SOMEIPXF – SOME/IP Transformer

Data serialization and deserialization

Since AUTOSAR 4.2.1 specified as RTE transformer (MICROSAR.COM)

Large Data COM (LDCOM) should be used to save resources

UDPNM – UDP Network Management

Coordinated shut down of Ethernet ECUs

Connection to NMIF is not shown in the figure

RTE SOMEIPXF

LDCOMCOM

PDUR

UDPNM

ETHTRCVETH

ETHSWT

22/49

Overview 2







Summary 45

Agenda

23/49

Diagnostics over Internet Protocol (DoIP)MICROSAR.ETH – Diagnostics

Use cases

Diagnostics (repair shop, legislator)

ECU re-programmingManufacturer: End of line programmingRepair shop: Software update

Advantages

High-speed access to vehicle ECUs

Gateway to existing bus systems Parallel flash download

Ethernet, TCP/IP as well-known technology

New possibility for production andrepair shop infrastructure (WLAN)

Eth UDSIPDoIP Diag. Message TCP DoIP Eth……

Engineering

test equipmentHandheldscan-tool

Ethernet switch & WLAN access point

24/49


EthernetEthernet

3

DoIPGateway

CAN

ECU

421

External Test Equipment

In-vehicle Test

Equipment

Switch

ECU

FlexRay

DoIP Node

Ethernet…

Ethernet

Ethernet / VLAN1 Ethernet / VLAN2

VLAN1,VLAN2

ISO 13400

Diagnostics of all DoIP Nodes, DoIP Gateways and ECUs behind the DoIPGateways (addressing via logical DoIP address)

VLAN2(VLAN1), VLAN2

Use VLANs to encapsulate vehicle-internal from vehicle–external communication

Possibly re-configure the switch during runtime to make DoIP Nodes visible to the external test equipment – after successful tester authentication, otherwise the DoIPGateway has to route messages

25/49


Architecture: External test equipment has direct access to all Ethernet ECUs

Full Ethernet bandwidth available (also during flashing)

No bottleneck; reduced resource needs of the DoIP Gateways

All Ethernet ECUs are DoIP Nodes or DoIP Gateways and can be diagnosed via DoIP also without the central DoIP Gateway

No proprietary protocol necessary

Diagnostic tester has to manage multiple TCP/IP connections simultaneously, if parallel Ethernet-flashing is required

Knowledge about the vehicle architecture necessary within the diagnostic tester (e.g. which ECU is behind which DoIP Gateway, if multiple Gateways are present)

Possibly more complex TCP/IP stack for vehicle-internal Ethernet ECUs; combination of IPv4/IPv6 and dual-stack may be necessary

Security mechanisms on each DoIP Node and DoIP Gateway (e.g. diagnostic tester authentication) or switch re-configuration during runtime (more complex process)

26/49


DoIP Node

Ethernet,DoIP

3

DoIPGateway

ECU

421

External Test Equipment

In-vehicle Test

Equipment

Switch

ECU

…Ethernet VLAN1,

VLAN2

Ethernet,

Ethernet,Plain UDS

e.g. DoIP subset

ISO 13400 does not specify DoIP-to-DoIP routing

VLAN1-to-VLAN2 conversion on the same Ethernet port is also routing

There are different possible solutions

1. Use plain UDS over TCP/IP without additional protocol or AUTOSAR Socket Adaptor PDU Header Option (recommended)

2. Use subset of DoIP or other OEM-specific protocol

3. DoIP Gateway implements a diagnostic tester (emulation)

Ethernet / VLAN1 Ethernet / VLAN2

27/49


Architecture: All diagnostic communication is routed over the DoIP Gateway

Tester needs to manage only one TCP connection (simple tester)

All security mechanisms can be encapsulated within the DoIP Gateway (e.g. tester authentication)

More simple TCP/IP stack possible for vehicle-internal Ethernet ECUs; OEM could decide to use IPv4 or IPv6 for all vehicle-internal communication –DoIP Gateway may implements IPv4/IPv6 dual stack and performs a network address translation (NAT)

Only for “Use plain UDS over TCP/IP without additional protocol”

No OEM specific implementation necessary

Only for “DoIP Gateway implements a diagnostic tester (emulation)”

All Ethernet ECUs are DoIP Nodes or DoIP Gateways and can be diagnosed via DoIP also without the central DoIP Gateway

28/49


Architecture: All diagnostic communication is routed over the DoIP Gateway

High resource needs (computing power) of the DoIP Gateway, sincelots of data has to be processed (especially while flashing Ethernet ECUs)

Only for “Use plain UDS over TCP/IP without additional protocol”

In case of cascading gateways, a different addressing scheme must be used behind the DoIP Gateway e.g. the AUTOSAR Socket Adaptor PDU Header Option (+ because it is simple and already standardized)

Ethernet ECUs cannot be diagnosed via DoIP without the DoIP Gateway (could be a development use case)

Only for “Use subset of DoIP or other OEM-specific protocol”

Protocol is not specified and requires an OEM-specific implementation in the DoIP Gateway as well as in the Ethernet ECUs

Ethernet ECUs cannot be diagnosed via DoIP without the DoIP Gateway (could be a development use case)

Only for “DoIP Gateway implements a diagnostic tester (emulation)”

An embedded diagnostics tester is not specified in AUTOSAR and requires an OEM specific implementation – but only in DoIP Gateways

29/49

Ethernet FlashbootloaderMICROSAR.ETH – Diagnostics

Use cases

Fast ECU (re-)programming over Ethernet via DoIP End-of-line (EOL) ECU programming After-sales ECU re-programming ECU development

Properties

Independent application which remainspermanently in the ECU

The FBL is based on the MICROSAR.ETH BSW modules, but the source code cannot be shared between FBL and normal application

Because of the special flash driver, theFBL is a hardware dependent application

ECUs with Ethernetflashbootloader

Vehicle access viaEthernet (DoIP)

Diagnostic testere.g. PC-based

30/49

Software ArchitectureMICROSAR.ETH – Diagnostics

DOIP

DOIP – Diagnostics over Internet Protocol

Implementation of ISO 13400-2

The handling of the DoIP protocol was specified as Socket Adaptor plug-in in AUTOSAR 4.0.x and became a separate module in AUTOSAR 4.1.x

Flashbootloader

Communication (COMM and PDUR) wrapper

Flash/EEPROM driver

FBL security module

FBL diagnostics

FBL application

PDUR

DCM

RTE

Application

SOAD

ETHIF

ETHSM



ETHTRCVETH

ETHSWT

Flash-bootloader

COMM

31/49

Overview 2







Summary 45

Agenda

32/49

Universal Measurement and Calibration Protocol (XCP)MICROSAR.ETH – Measurement and Calibration

Use cases

Measurement, calibration, bypassing and ECU re-programming

The XCP protocol is split into transport and protocol layer

The protocol layer is identical for all network technologies

The transport layer is specific for each network technology (different header and trailer data on CAN, FlexRay, Ethernet, USB etc.)

ASAM AE MCD-1 XCP V1.1.0

ASAM AE MCD-1 XCP V1.2.0 only adds CAN-FD as new transport layer, no functional changes

Eth XCP P.IPXCP on Ethernet UDP/TCP XCP H. Eth

XCP H. = XCP Header (transport layer specific)

XCP P. = XCP Packet (protocol layer)

……

33/49

XCP RoutingMICROSAR.ETH – Measurement and Calibration

Due to its different transport layers, XCP has no native support for routing Vector has developed a solution for XCP routing (Ethernet to CAN and

FlexRay) together with an OEM

3

XCP GatewayXCP Slave

CAN

ECUXCP Slave

421

CANapeXCP Master

Switch

ECUXCP Slave

FlexRay

…Ethernet

ECUXCP Slave

Ethernet

Ethernet

34/49

MirroringMICROSAR.ETH – Measurement and Calibration

How can vehicle internal bus traffic be logged and analyzed if Ethernet is the only access point to the vehicle and without additional logging equipment?

Solution: Mirroring of CAN/LIN/FlexRay bus traffic to Ethernet Mirroring of complete communication Simultaneous mirroring of all connected

busses possible Multiple CAN/LIN/FlexRay messages

are packed in one Ethernet packet Additional information is added to

the mirrored messages Mirror functionality can be switched

on/off e.g. by a diagnostic command Implementation as CDD above the

Socket Adaptor with direct accessto bus drivers

Analysis of mirrored data in CANoe

CAN 1

CAN 2

FlexRay

LIN 1

LIN 2

Gateway

DataLogger

Ethernet

35/49

Software ArchitectureMICROSAR.ETH – Measurement and Calibration

COMM

ETHXCP ETHXCP – XCP on Ethernet

Ethernet specific transport layer of ASAM AE MCD-1 XCP V1.1.0

SOAD – Socket Adaptor

Vector specific extensions to the AUTOSAR specification to support XCP routing and Mirroring

MIRROR – Mirroring

Complex Driver above the Socket Adaptor with direct access to communication drivers

MIRROR

SOAD

ETHIF

ETHSM



ETHTRCVETH

ETHSWT

36/49

Overview 2







Summary 45

Agenda

37/49

Smart Charge Communication (SCC)Outlook: MICROSAR.V2G

When and how to charge an electric vehicle?

ISO 15118 AC and DC charging Profile: Plug and Charge (PnC) – charging in a public environment Profile: External Identification Means (EIM) – “simple” charging Value Added Services (VAS)

DIN 70121 DC charging (similar to ISO DC EIM – no encryption, no payment)

Customer Specific Functions

If the vehicle is connected to the Internet e.g. via a charge spot, additional web-services may be available or implemented by using e.g. HTTP

38/49

Software ArchitectureOutlook: MICROSAR.V2G

TLS

TLS – Transport Layer Security

Encryption and decryption of TCP streams

SCC – Smart Charge Communication

Vehicle-to-Grid Transport Protocol (V2GTP)

Efficient XML Interchange (EXI) and XML Security are separate modules

DNSv4/v6 – Domain Name Service Resolver

Resolution of URLs into IP addresses

HTTP – Hypertext Transfer Protocol

String-based communication with a server

Customer functions may also be implemented by Vector

COM

SCCV2GTP,

SCC, EXI, XML Sec.

RTE

DNSv4/v6

HTTP

Customer Functions

COM

RTE

COMM

ETHIF

ETHSM



ETHTRCVETH

ETHSWT

39/49

Overview 2







Summary 45

Agenda

40/49

Audio/Video Bridging (AVB)Outlook: MICROSAR.AVB

Transport audio and video streams (or safety critical data)

Through standard Ethernet network technology

With simple cabling

Fast and in real-time

Well synchronized and prioritized

Right

Left

Front Rear

Endpoint

t = 0

Head Unit(Bridge)

41/49

Audio/Video Bridging (AVB)Outlook: MICROSAR.AVB

Bridging & management

Introduction and overview:IEEE 802.1BA – Audio Video Bridging Systems

Time synchronization:IEEE 802.1AS – Timing and Synchronization for Time-Sensitive Applications

Traffic shaping:IEEE 802.1Qav – Forwarding and Queuing Enhancements for Time-Sensitive Streams

Stream management:IEEE 802.1Qat – Stream Reservation Protocol (SRP)

Audio/Video data transmission and reception

Audio/Video Transport Protocol (AVTP):IEEE 1722(a) – Layer 2 Transport Protocol for Time Sensitive Applications

42/49

Software ArchitectureOutlook: MICROSAR.AVB

ETHSM

COMM

ETHTSYN – Ethernet Time Synchronization Time synchronization between Ethernet

ECUs Implements the Generalized Precision

Time Protocol (gPTP) – IEEE 802.1AS Specified since AUTOSAR 4.2 Is part of MICROSAR.ETH but because it

implements gPTP, it is explained in more detail within the Embedded Solution AVB

AVTP – Audio/Video Transport Protocol

Transmission and reception of audio and video streams – IEEE 1722(a)

ETHTSYN / PTP

STBM

RTE

AVTP

Appl.

ETHIF

ETHTRCVETH

ETHSWT

43/49

Overview 2







Summary 45

Agenda

44/49

Automotive Ethernet Use CasesSummary

Use Case 3.x 4.x

Service Discovery (SD) -

Scalable Service-Oriented Middleware over IP (SOME/IP) -

Signal-/PDU-based communication -

UDP Network Management (UDPNM) -

Diagnostics over IP (DoIP)

Flashbootloader

Universal Measurement and Calibration Protocol (XCP) -

XCP Routing -

Mirroring -

Smart Charge Communication (SCC)

Audio/Video Bridging (AVB) - /

() Supported AUTOSAR use case

() Supported use case (Vector extension to AUTOSAR)

Which use cases are supported in which MICROSAR version?

Currently not supported use cases are implemented on request

45/49

Overall MICROSAR Ethernet ArchitectureSummary

MICROSAR.ETH is the basis of MICROSAR.V2G and MICROSAR.AVB

All clusters and use cases can run in parallel

Figure does not show the flashbootloader

PDUR



ETHIF

ETHSM

UDPNM

TLS

Customer Functions

ETHXCP

LDCOM

SDCDD

CDD

CDD

DOIPCOMM

BSWM

AVTP

Application

SOAD

COM

RTE

MIRROR

SOMEIPXF

ETHTSYN

STBM

SCCV2GTP,

SCC, EXI, XML Sec.HTTP

DNSv4/v6

ETHSWT

ETH ETHTRCV

46/49

ECU Configuration Flow for MICROSAR.ETHSummary

Software Component Description files

.xml Embedded Coder

TargetLink

.cdd/.odx

CANdela Diagnostic Data Other AUTOSAR tools

System Description / ECU Extract of System Description

AUTOSAR 4.1.x / 4.2.xContains system information which are needed for the ECU

DaVinci Developer

DaVinci Configurator Pro 5Configuration of RTE + BSW

ECU ConfigurationDescription

.xml

Base ECUC Generation

Editing and

Generation

.c .hBSW module configuration header and code filesRTE header and code filesSWC header files

.XML

47/49

Vector Ethernet SolutionSummary

Ethernet and TCP/IP in Vehicles

Ethernet and TCP/IP technologies have made their way into the vehicle and they are expected to expand into new application areas

Automotive OEMs and suppliers are facing diverse challenges here

Vector supports you in meeting these challenges with professional tools, embedded software and services

CANalyzer/CANoeDevelopment, Simulation,

Analysis and Test

vFlashRe-

programming

IndigoTest vehicle /

ECU diagnostics

VN5610Network Interface

Ethernet

DoIP

ECU

Vehicle

DoIP

MICROSARAUTOSAR

Basic Software

VC121UniversalController

CANapeMeasurement & Calibration

XCP on Ethernet /XCP routing

ChargeSpot

Charge Spot Software

48/49

© 2015. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V2.01.01 | 2015-05-08

For more information about Vectorand our products please visit

www.vector.com

Marc WeberVector Informatik GmbH

Author:

m.eng. marc weber - vector: software · m.eng. marc weber product management ... ethernet switch...

Documents