the road from gpu-powered prototypes to production...

2018-03-26

The road from GPU-powered prototypes to production ECUs

2018-03-26 | GTC 2018 | Public | © Elektrobit Automotive GmbH 2018.All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.


Photo: Hamburger Abendblatt /Daimler AG

Since Years:

• Up to 100 small ECUs (Electronic control unit) serving a dedicated function like window lifter or climate control

• Several and highly specialized communication channels between ECUs(CAN, CANFD, FlexRay, LIN, Ethernet)

1:1 relation between functionality and embedded device is standard

Status Quo – Cars as computers with wheels


Today:

• Multi-core processors in use on ECUs serving multiple functions

• Software for ECUs is statically configured and flashed with a single image containing all applications and basic software

Challenge:Integration of software of several parties cross company


Status Quo – AUTOSAR Standard enabling work split


Decouple application software from hardware

Standardize software interfaces

Standardize configuration concepts

Design the complete vehicle application software over all ECUs

Hardware

Software

Conventional, before AUTOSAR

Application Software

Hardware

AUTOSAR

standardized

HW-specific

AUTOSAR


• Basic software and services

• Tooling for standardized configuration

• Single- and multi-core operating systems

• Functional Safety solutionsISO 26262 certified up to ASIL-D

• Embedded Security solutions

• Certifiable, e.g. Onboard Diagnostics

• Automotive Ethernet software

Solutions for Classic AUTOSAR ECUs

Status Quo – Vehicle infrastructure



GPUs only in use in the infotainment domain!


Status Quo – Today’s Vehicle infrastructure



Copyright: IBM

How can we achieve the next level of mobility?


Software over-the-air-updates

• New vehicles features

• Updates and patches

• Silent testing

• Security


Requirements and challenges

Dynamic deployment

Remote analytics and diagnostics

Dependable systems

Developer oriented, target independent environment

• User-driven updates

• Network accessible sensors & actuators

• Car as a sensor

• Remote diagnostics

• Fleet campaigns

• Environment independent software

• Easy qualification and deployment

• Small, encapsulated and exchangeable software services (mircoservice)

• Safety

• Security

• Availability

• Reliability

• Maintainability


• Mix of:classic microcontrollers andpowerful “cellphone” processors

• Mix of:classic automotive networksand cloud connectivity

• Mix of:safety-relevant functionsand apps installed bythe user

Possible next generation vehicle infrastructure architecture


UIComputing

Cluster

Cental HAD Cluster(s)

Smart Antenna

Gateway IO Concentrators, Actors, Sensors

SmartSensors

SmartSensors

Steering

Braking Battery

EngineBack-end System

Gigabit Ethernet

Reliable ECU

Performance ECU

IO Concentrators

Back-end Server


Trajectory Control

Longitudinal Control

Lateral Control

Positioning

Object Fusion

Grid Fusion

Behavior

Road and Lane Fusion

Vehicle Database

Fun

ctio

n S

pe

cifi

c V

iew

s

Ve

hic

le A

bst

ract

ion

-Se

nso

rs

Ve

hic

le A

bst

ract

ion

-A

ctu

ato

rs

MotionManagement

Safety Management

Behavior

Behavior

Situative Behavior ArbitrationSensorData Fusion

HMI Management

SituationAnalysis

SituationAnalysis

SituationAnalysis

PathPlanning

PathPlanning

PathPlanning

Sensor fusion system requirements spanning across


Grid Fusion


Grid Fusion in action


Bayes based Grid Fusion

– Traditional occupancy fusion

– Storing probability of occupancy

– Needs less memory due to smaller state vector

Demster-Shafer based Grid Fusion

State of the art occupancy fusion

Storing evidence of occupancy/free

Various sensor models

Use-case: free space detection, path planning

Height Map

Storing height value and confidence

Processes 3D data

Use-case: ramp/hole detection, preprocessing for other fusion algorithms


Trajectory Control


Lateral Control

Positioning

Object Fusion

Grid Fusion

Behavior


Vehicle Database

Fun

ctio

n S

pe

cifi

c V

iew

s

Ve

hic

le A

bst

ract

ion

-Se

nso

rs

Ve

hic

le A

bst

ract

ion

-A

ctu

ato

rs

MotionManagement

Safety Management

Behavior

Behavior


HMI Management

SituationAnalysis

SituationAnalysis

SituationAnalysis

PathPlanning

PathPlanning

PathPlanning

Sensor fusion system


Scalable, standardized interfaces

Scalableinputs

Grid Fusion

Algorithm core

Interface 1high volumefor central ECU use

Interface 2mid volumefor FlexRay / Ethernet

Interface 3low volumefor CAN

SonarSensor Interface

SonarSensor Adapter

LidarSensor Interface

LidarSensor Adapter

RadarSensor Interface

RadarSensor Adapter

For such application we need (parallel) computing power!


Trajectory Control


Lateral Control

Positioning

Object Fusion

Grid Fusion

Behavior


Vehicle Database

Fun

ctio

n S

pe

cifi

c V

iew

s

Ve

hic

le A

bst

ract

ion

-Se

nso

rs

Ve

hic

le A

bst

ract

ion

-A

ctu

ato

rs

MotionManagement

Safety Management

Behavior

Behavior


HMI Management

SituationAnalysis

SituationAnalysis

SituationAnalysis

PathPlanning

PathPlanning

PathPlanning

Sensor fusion system


Scalable, standardized interfaces

Scalableinputs

Grid Fusion

Algorithm core

Interface 1high volumefor central ECU use

Interface 2mid volumefor FlexRay / Ethernet

Interface 3low volumefor CAN

SonarSensor Interface

SonarSensor Adapter

LidarSensor Interface

LidarSensor Adapter

RadarSensor Interface

RadarSensor Adapter

How to achieve system abstraction?


Adaptive AUTOSAR Basis

Adaptive AUTOSAR Services

Next generation of standardized basic software Adaptive AUTOSAR


(Virtual) Machine / Hardware

Application ApplicationApplicationApplication Application

Communication

Management

API

Operating system

API

Platform Health

Management

API

Execution

Management

API

Persistency

API

Time

Management

API

Logging and

Tracing

API

Software

Configuration

Management

Service

Security

Management

Service

Diagnostics

Service

Bootloader

ara::comCommunication API


Possible high performance controller architecture for SOP in 2019


AUTOSAR OS

Adaptive AUTOSARQM

App App

MCU

Classic AUTOSAR

Automotive-grade Hypervisor

Adaptive AUTOSARSafety

App

LINUX OS LINUX OS

Classic AUTOSAR Safety

App

Safety Cores

Safety OS

Performance Cores and HW accelerators

Performance Partitions for Vehicle & Consumer Functions Safety Partition

SecurityTEE

App

HSM

Trusted OS

Security Partition


App

Safety Core

Safety OS

Safety

Safety Core

1oo2


Worksplit in automotive supply chain


16

AUTOSAR OS

Adaptive AUTOSARQM

App App

MCU

Classic AUTOSAR



App

POSIX OS POSIX OS


App

Safety Cores

Safety OS



SecurityTEE

App

HSM

Trusted OS

Security Partition

MCAL (Drivers) MCAL (Drivers) DriversDriversDrivers

Function development: SW supplierFunction integration: Tier 1

Interface Definition: OEMNetwork deployment: OEM

Middleware development: Basic software supplierMiddleware configuration: Tier 1

Driver development: Hardware supplierDriver integration: Tier 1

OS development: OS supplierOS configuration integration: Tier 1

Hypervisor development: Hypervisor supplierResource partitioning: Tier 1


Standardization in AUTOSAR


17

AUTOSAR OS

Adaptive AUTOSARQM

App App

MCU

Classic AUTOSAR



App

POSIX OS POSIX OS


App

Safety Cores

Safety OS



SecurityTEE

App

HSM

Trusted OS

Security Partition


Software component descriptionSoftware component configuration

Standardized APIsStandardized network configuration

Standardized functionality and configuration

Standardized APIsStandardized configuration

Classic AUTOSAR:Standardized functionality and configuration


How to use GPUs for automotive applications?


AUTOSAR OS

Adaptive AUTOSARQM

App App

MCU

Classic AUTOSAR



App

POSIX OS POSIX OS


App

Safety Cores

Safety OS



SecurityTEE

App

HSM

Trusted OS

Security Partition


How to grant access to GPUs as hardware accelerators to• Multiple independently developed applications• Applications that are developed without focus on specific HW architecture• Applications that reside in different hypervisor partitions

How to provide reasonable freedom from interference between those applications

Integrating GPUs in software infrastructure



Current integration in (most) prototypes


20

AUTOSAR OS

Adaptive AUTOSARQM

App App

MCU

Classic AUTOSAR



App

POSIX OS POSIX OS


App

Safety Cores

Safety OS



SecurityTEE

App

HSM

Trusted OS

Security Partition



Current integration in (most) prototypes


21

Adaptive AUTOSARQM

App

MCU

POSIX OS


App

Safety Cores

Safety OS



MCAL (Drivers)Drivers

GPU Library+

Driver

• Application becomes hardware-dependent

• Applications must explicitly share the GPU –application dependencies

• No integration into Health Monitoring

It actually works!


Adaptive AUTOSAR Basis

Adaptive AUTOSAR Services

Standardized basic software – Adaptive AUTOSAR


(Virtual) Machine / Hardware

Application ApplicationApplicationApplication Application

Communication

Management

API

Hardware

Acceleration

API

Operating system

API

Platform Health

Management

API

Execution

Management

API

Persistency

API

Time

Management

API

Logging and

Tracing

API

Software

Configuration

Management

Service

Security

Management

Service

Diagnostics

Service

Bootloader

ara::comCommunication API

Goal:• Uncouple application design

from the hardware it is deployed upon

Functionality to be included:• Libraries for using GPUs for

ADAS applications• E.g. Tensorflow,

Parallel STL, OpenCV• Build on top of e.g.

CUDA, SYCL

Likely not standardized before 03/2019


Sharing a GPU across virtual machines


GPU-Drv

VM VM

vGPU

GPU-Drv

Performance Controller

User Space

Hypervisor

Hardware

vGPU

GPU-Drv

GPU

Emulation Passthrough

VM VM


GPU-Drv

GPU

Driver in Guest

VM VM


GPU-Drv

GPU

vGPU

GPU Virtualization

VM VM


GPUMngmt

GPU

GPU-Drv

GPU-Drv


What have we achieved so far:

• Standardization of APIs and abstraction from hardware

– Allows to develop applications independent of ECU projects

• Enabling GPU virtualization

– Allows sharing hardware resources in a more efficient manner

Integration should work. Now let’s make things safe and secure.

Are we done yet?



Vehicles affected(Milion)

Vehicles affected(Per day)

Recalls(Total)

Vehiclessold

(Million)

Recalls per sold

vehicle

2014 51.0 139,726 779 16.45 3.1

2015 51.2 140,274 868 17.39 2.9

2016 53.2 145,753 927 17.46 3.0

• Software-related recalls have gone from less than 5 % in 2011 to 15 % by end of 20151

roughly 7.68 Million software related car recalls in 2015

• Software vendors are liable for their products in the automotive sector

The reality: Automotive recalls in the US


1Stout Risius Ross (SSR), Automotive Warranty & Recall Report 2016

Data courtesy of NHTSA


• Quality- and verification driven

• Common standard: Automotive SPICE v3.1 for development processes

• In addition: most OEMs have further standards

• Process assessments are regularly performed by customers:OEM -> Tier-1 -> Tier-2 -> ...

• A Tier-1 is fully liable for the complete product, including the software

Software development for automotive (ASPICE)



Functional Safety according to ISO 26262


27

Functional Safety Concept

2) Management of Functional Safety

Safety Management during Item Development

3) Concept Phase

8) Supporting Processes

7) Production and

Operation

5) Hardware Development

System Dev. Initiation

System Requirements

4) System Development

Observation

Service

Production

Item Definition

Start Safety Lifecycle

System Design

Safety Management after SOPOverall Safety Management

Release

Item Integration, Test

InitiationInitiation

HW Design

HW Integration and Testing

HW Failure Rate

Hazard & Risk Analysis

Validation & Safety Assessment

SW Safety Requirements

SW Design

SW Integration and Testing

SW Unit Testing

SW Unit Design & Implementation

Verification of SW Safety Requirem.

9) ASIL-oriented and Safety-oriented Analysis

Distributed Development

Mgmt. of Safety Requirements

Configuration Management

Requirement Decomposition

Change Management

Verification

Coexistence of Elements

Qualification of SW Comp.

Qualification of HW Comp.

Proven in Use Argumentation

Analysis of dependent Failures

Documentation

Qualification of SW Tools

Safety Analysis

HSI

HW Architectural Metrics

HW Safety Requirements

1)

Vocabu-

lary

6) Software Development

10)

Guide-

line

ISO 26262 has• 10 parts• 500 pages• 43 Chapters• 600 Requirements• 100 Work Products• 180 Methods

Only the parts 1-9are normative


Functional Safety Requirements (ISO 26262)


28

Safety Requirements

Automotive Safety Integrity Level ASILASIL = Severity x Exposure x Controllability

Functional Description Hazard & Risk Analysis




29

Drive in the city@35mph

Collide with pedestrian@35mph

Safety Requirements






30



Safety Requirements




Hazard and Risk Assessment in a nutshell


31

C1 C2 C3

S1

E1 QM QM QM

E2 QM QM QM

E3 QM QM A

E4 QM A B

S2

E1 QM QM QM

E2 QM QM A

E3 QM A B

E4 A B C

S3

E1 QM QM A

E2 QM A B

E3 A B C

E4 B C D

HazardPotential source of harm, caused by malfunctioning behavior of the itemExample: Not detecting a pedestrian on the street

Operational situationScenario that can occur during a vehicle's life, in which the hazard creates a considerable riskExample: Driving at speed > 35 mph on a street operating with an activated Highway Chauffeur

Possible avoidance actions Things that the driver or other involved person are able to do in order to avoid the harmExample: Driver immediately brakes with full power

Controllability (C0-C3)Probability that one of the involved persons is able to avoid the harmExample: Normally not controllable => C3

Exposure (E0-E4)Probability of the operational scenarioExample: High probability => E4

Severity (S0-S3)Impact of the harmExample: Life-threatening injuries => S3




32



Safety RequirementsSeverity 3: Severe injuries expected.Exposure 4: Pedestrians in car‘s path likely. = ASIL-DControllability 3: Driver is sleeping.ASIL = Severity x Exposure x Controllability



• Redundant channels (e.g.: 1oo2D)

• 3 Layer safety solution (E-Gas concept)

• Safety parts fully certified up to ASIL-D

Strategies to achieve safety for highly automated driving


Performance MCU Safety MCU

EB tresos AutoCore

Performance MCU 1/2

Diagnostic Functions

CAN

SW-CASIL D

TimE

AdaptiveCore

Channel 1/2

MCAL

Program Flow monitoring

Protected communication

Ethernet | SPI

Linux

Safety RTE

Safety OS

Safety E2E

Communication Management

Platform Health Management

Safety Island

EB tresos AutoCore

TimESafety

OS


• The standard is being worked on:ISO/SAE 21434 – Cybersecurity Engineering

• Contains general requirements, will probably include requirements for software updates

• Publication: end of 2019

Projects with an SOP in 2019 / 2020 need to take it into account.

Cybersecurity engineering




ECU

In-vehicle network

External interface

End-to-end security

35

Hardware enhanced cryptography

Embedded security mechanisms

Cyber security fleet monitoring (IDS)

Cyber security analysis & response

Security solutions

Software update over-the-air

EB Argus



36

Summary

EB extended the safety product portfolio to fulfill the requirements of high performance ECUs

Application Software

Hardware

AUTOSAR

EB & Argus are offering an end-to-end-security solution for the future vehicle architecture

Enabling standardized GPU virtualizationAllows sharing hardware resources in a efficient way

Standardization of Middleware to develop application independent for high performance ECUs



EB tresos solution for NVIDIA DRIVE PX 2 Visit our booth at the GTC

#532

37

Adaptive & Classic AUTOSAR for DrivePX planned to be available at October 2018!

• Integrating technologies from NVIDIA, Infineon (safety processor) and EB

• The EB software provides seamless integration capability of Linux and AUTOSAR applications

[email protected]

Questions?


the road from gpu-powered prototypes to production...

Documents