Making Full Use of Multi-Core ECUs with AUTOSAR Basic ......There is no “one fits all” architecture. 5 Motivation for Multi-Core u AUTOSAR Standard: SWC-Split ... u Provision of

V0.1 | 2018-09-07

Webinar

Making Full Use of Multi-Core ECUs with AUTOSARBasic Software Distribution

2

u Motivation for Multi-Core

AUTOSAR Standard: SWC-Split

MICROSAR Extension: BSW-Split

BSW-Split: Technical Challenges

BSW-Split: Implementation

Summary

Agenda

3

Motivation I

Motivation for Multi-Core

u There are many motivations for multi-core systems. E.g.

u Speedup: A computational problem can be calculated in shorter time> Speedup is realized by parallelization of the problem

> Some problems are easy to parallelize, some are not

u Workload distribution: Assignment of independent (sub-) problems to different cores> Each computational problem will require the same execution time

> In total, several problems can be calculated in parallel

4

Motivation II


u There are many motivations for multi-core systems

u Improved system responsiveness: Distribution of time critical processes to different cores> Cores can take over special roles such as interrupt handler or

background job worker

> Low-priority housekeeping does not interfere with high priority job processing

u Others…

u Different motivations lead to different software architectures

u Motivations often overlap

There is no “one fits all” architecture

5


u AUTOSAR Standard: SWC-Split




Summary

Agenda

6

AUTOSAR Multi-Core Paradigm


Enable the application SWC to realize project specific multi-core use cases

u The application SWC can use any core of an AUTOSAR multi-core system

u Great degree of freedom for application deployment

u The AUTOSAR OS manages the cores and provides

u Inter-core communication

u Inter-core scheduling control

u Data consistency mechanisms (Spinlocks, IOC)

u The AUTOSAR base software provides its services on all cores

u Diagnostic

u (Bus) Communication

u Watchdog

u ECU management

u …

AUTOSAR

Core 1 Core 1 Core 2

7

AUTOSAR BSW Stack


u Only limited degree of freedom for BSW deployment

u AUTOSAR describes three possibilities:

u Mapping of:u I/O drivers

u I/O hardware abstraction

u Complex drivers (CDD)

u Mapping of u Mode- and state management

u Provision of communication service satellites

u BSW services which realize the master-satellite pattern

u The master resides in the BSW partition

u The satellites are mapped to different partitions

u Functional scope of the satellites is implementation specific AUTOSAR Architecture 4.3.0 ©AUTOSAR

8



u MICROSAR Extension: BSW-Split



Summary

Agenda

9

Background


u In modern ECUs CPU load caused by the Base Software can be significant

u Typical drivers are

u High communication load (e.g. Ethernet, CanFD)

u Advanced communication use cases (e.g. Service oriented, secured)

u BSW service utilization due to larger applications

u AUTOSAR classic architecture is fine grained

u Many different modules

u Relatively small modules

Many contributors to overall BSW CPU load

10

Causes


u In BSW modules, there are up to three different causes for CPU load

u Cyclic main functions

u Executed in task context

u May call neighboring modules

u Interrupt service routines

u Executed in interrupt context

u Executed cyclic or sporadic


BSW Module

BSW Module

11

Conclusion


u In BSW modules, there are up to three different causes for CPU load

u Interface implementation

u Executed in task or interrupt context


Relocation of a BSW module ideally addresses all of its entities

u To relocate as much CPU load as possible

u To avoid concurrent access to the module’s data

u To avoid inter-module calls of second degree

BSW Module

12

Consequences


u AUTOSAR SWC-Split is not always sufficient

u BSW-Split is sensible for specific BSW modules and specific use cases

u MICROSAR provides BSW-Split as standard feature and extension to AUTOSAR

u BSW-Split allows relocation of non-multi-core BSW modules

u Relocation is achieved by using tailored, multi-core capable BSW modules (Dem, EcuM, PduR…)

MICROSAR

Core 1 Core 2 Core 1 Core 2

13




u BSW-Split: Technical Challenges


Summary

Agenda

14

Naïve Approach


u Goal: Distribution of BSW load

u Consequence: Relocation of modules with significant contribution to the CPU load (utilization)

u CPU utilization (𝑢) is calculated as the sum of execution times (∆ 𝑡_𝑚𝑜𝑑) of a module during a specific timespan (∆𝑡)

𝑢 =σ𝑘=0𝑛 ∆𝑡_𝑚𝑜𝑑𝑘

∆𝑡u Influencing factors are

> Individual execution times

> Invocation frequency (𝑛

∆𝑡)

u Deduction: Relocate modules which have a

u high execution time or

u rather small execution time but run frequently

u That simple?

15

Challenge 1: Context Change


u Starting situation: Relocation of complete modules to maximize effect on CPU load

> Interfaces

> Main functions

> Service Routines

> Data

u Challenge: Context change to different core on invocation of a API

SWC

RTE

SWC SWC

Core 1 Core 2

Upper Layer

Lower Layer

Relocated

ModuleBSW

16

Challenge 1: Context Change - Realizations


u Solution: There are two fundamentally different approaches

u Event driven invocation

> The caller passes an event to the remote core which activates e.g. a task

> The task executes a worker, which calls the interface function

u Data driven invocation

> The caller serializes the interface invocation request in a queue

> A worker on the remote core reads from the queue, de-serializes the request and calls the interface

LL_Module Proxy Worker Rel_Module


17

Challenge 1: Context Change - Consequences


u Both variants add execution time overhead

u On the caller-core (notification / serialization)

u On the called core (worker execution, task scheduling, deserialization)

u Deduction (revisited): Relocate modules which have

u high execution time or

u rather small execution time but run frequently and

u a positive net effect of relocated execution time vs. overhead

u In other words: There is not much sense in relocating a small execution time which causes overhead that is larger


Overhead

18

Challenge 2: Data Lifetime


u Starting situation: Relocated BSW module is executed in a different core context

u Challenge: Data lifetime

u Some data is only available during specific contexts. E.g. Buffers in µC peripherals

u Example CAN reception:

1. Data resides in mailbox

2. Pointer is passed to the interface

3. Interface (its proxy) triggers upper layer on a different core

4. The pointer is passed to the UL on the different core

5. Interface returns

6. Driver releases buffer!

7. UL is being executed

u Solution: Data must be buffered by proxy

u Consumes memory

u Consumes execution time

Requires efficient implementation

DriverInterface+Proxy

Release Buffer

19

Challenge 3: Synchronous vs. Asynchronous


u Starting situation: Context changes are asynchronous to achieve best performance

u Realization of a Fire-and-Forget behavior

u Challenges

u Return values/out parameters are required immediately

u Sequences might get broken due to parallel processing

u Solutions

u Provision of core-local multi-core capable BSW-modules which allow invocation without context switch

u Implementation of cross-core context-switch with synchronous behavior

u Implementation of “special solutions” (E.g. Assumptions on return values, limitations…)

20





u BSW-Split: Implementation

Summary

Agenda

21

Intro


u BSW-Split requires

u Thorough analysis of the considered modules

u Deep knowledge of the BSW stack and its internal interactions and sequences

u Proxy / Worker functionality for context switch

u MICROSAR BSW-Split provides

u A predefined set of modules for relocation

u Additional functionality to support the relocation performance efficiently

u Supporting documentation for the distribution

u MICROSAR BSW-Split achieves

u CPU load distribution

u Improved responsiveness by relocating long-running interrupt service routines

22

Overview


u Multi-core BSW-Split allows relocation of communication bus cluster

u Relocation of individual channels is not supported

u Relocation affects all bus relevant BSW modules

u Currently supported

u Ethernet

u Rationale

u Execution times of whole modules comparably high

> Potential to distribute considerable load

> Good ratio between overhead and distributed load

u Favorable interfaces to other BSW modules

u Favorable communication behavior of Ethernet

Syste

m S

erv

ices

SWC

RTE

SWC SWC

Core 2

Mem

ory

Serv

ices

Com

munic

ation

Serv

ices

Syste

m S

erv

ices

Com

munic

ation

Serv

ices

CAN

Fle

xRay

Eth

ern

et

OS App. 2

Core 1

OS App. 1

23

Architecture


u Relocation of complete bus clusters

u Example for Ethernet:

u Driver, Interface

u Socket Adaptor (SoAd)

u Service Discovery (Sd)

u Network and state management (UdpNM, EthSM)

u Switch driver

u …

u PduR as router between cores for

u Interface PDUs

u Transport Protocol PDUs

u Interfaces to neighboring BSW modules either

u Unchanged for multi-core capable BSW modules

u Via proxy / worker pattern

SoAd<Bus>If

OS App. 1 OS App. 2

Core 1 Core 2

PduR

Com/LdCom

TcpIp

EthIf

...

...

SD

/NM

/SD

...

24

Architecture Benefits


u Efficient handling of PDU interfaces between SoAd and PduR

u PDU interfaces are data-oriented

u Data can be transferred efficiently

u Minimized impact for non-PDU interfaces

u Direct API invocation of neighboring modules supported by multi-core BSW for

> Dem, Det, BswM (Upcoming), ComM (Upcoming), XCP (Upcoming)

u Usage of synchronous proxy / worker pattern as user implemented wrappers for

> NvM, User callouts

u No impact on relocated modules

u Tightly coupled modules remain on one core

25

Implementation - PduR


u Every core handles one or more communication interfaces

u PduR was enhanced to route the following objects between cores

u Transmit-requests (PDUs)

u Rx-Indications (PDUs)

u Tx-Confirmations

u Objects are only exchanged between cores if target bus is mapped to different core

u Minimizes performance penalty for core-local communication

u All inter core communication is handled deferred in main function context

u PduR provides cyclic main functions on cores with bus clusters

OS App. 1 OS App. 2

Core 1 Core 2

PduR

26

Implementation - PduR Data Exchange


u All elements to be exchanged between cores are buffered in PduR

u Rationale: Data availability in upper/lower layer module is not guaranteed during deferred processing

u No additional buffer required if routing path already requires buffering (e.g. buffered gateway routings)

u PduR distinguishes between two fundamental types of communication

u Type I:

> Unbuffered interface PDU API forwarding

> Unbuffered interface PDU API gateway routing

u Type II:

> TP PDUs

> Buffered PDUs

> Trigger transmit PDUs

27

Implementation – PduR Communication Types


u Type I

u Usage of unidirectional FiFio queues in PduR

u Queue-size configurable

u One queue per core-to-core communication path and direction

u Spinlock-free implementation

u Type II

u Usage of the standard PduR buffers

u Data consistency ensured with Spinlocks

> Custom locks for minimized API execution time

> Individual locks per routing path to avoid spinning

OS App. 1 OS App. 2

Core 1 Core 2

PduRW

R

Type I

OS App. 1 OS App. 2

Core 1 Core 2

W

Type II

28

Configuration I


u Tool-assisted configuration

u Manual configuration for

> General settings

> Architecture defining parameters

u Automated configuration for

> Routing path configuration

u New configuration options in PduR (manually set):

u Deferred Reception/Transmission

> Enables main function based forwarding and routing

u Main Function Period

> Influences delay of cross-core routing paths

u Multicore Queue Size

> Size of the queues for Type I communication

u Support Multicore

> Enables/disables multi-core support in general

29

Configuration II


u New configuration options in PduR:

u BSW module Application assignment

> Determines between which modules the PduR must realize cross-core communication

u Lock Ref (set automatically)

> Exclusive Area implementation of the routing path

u Multicore Routing Path (set automatically)

> Determines if the routing path is cross-core

30






u Summary

Agenda

31

Summary

u MICROSAR BSW-Split provides preselected distribution of BSW modules

u No replacement for application SWC distribution

u Effect on CPU-load highly project dependent

> Type of communication (Type I, Type II)

> Amount of communication ( Resulting CPU load in communication stack)

u Motivation

u Workload distribution

u Improved system responsiveness

u Speedup

u Provides efficient implementation for the performance critical interfaces

u Chance for “communication-heavy” ECUs which cannot fit BSW onto one core

u Especially when Ethernet has a major contribution to the BSW load

32 © 2018. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V0.1 | 2018-09-07

Author:Zeeb, AlexanderVector Germany

For more information about Vectorand our products please visit

www.vector.com

http://www.vector.com/

Documents

Making Full Use of Multi-Core ECUs with AUTOSAR Basic ......There is no “one fits all” architecture. 5 Motivation for Multi-Core u AUTOSAR Standard: SWC-Split ... u Provision of