from autosar adaptive to a safe level 4 adas platform · ad hoc software architecture automotive...

www.tttech.com

Christopher Helpa

Project Engineer

Functional Safety [email protected]

p p

From AUTOSAR Adaptive to a Safe Level 4 ADAS Platform

Contents

ADAS ECU - TTIntegration Platform Approach and Validation SupportExperience from Level 3 series projectsTTIntegration and AUTOSAR Adaptive The fail-operational Level 4 challengePutting it all together

2

ADAS Domain ECU Architecture –Scalable and Flexible Architecture

Eth

erne

t

Flex

Ray

CAN

FR CAN Deterministic

Ethernet Switch

AutomotiveµC

High-EndGeneral Purpose

µC

Image Processing

µC

SpecialµC

Eth

erne

t

Control,ASIL C/D Fusion,

ASIL B

Sensor processing,ASIL A/B, QM

Communication,Synchronisation

3

Ad Hoc Software Architecture

Automotive µC

AUTOSAR OSBSW

MCALGeneral Purpose µC Special µC

RTE

RTOS

MCAL

Linux

MCAL

SW

C 1

SW

C 2

SW

C 3

SW

C n

SW

C k

SW

C l… … …

▼ Different APIs, no SWC portability▼ Inhomogeneous basic services, tool and integration landscape▼ „Manual“ interface adaptation between SWCs

4

Integrated Software Architecture –Integration and Validation Support

Automotive µC

AutosarOS BSW

Middle-ware


RTE RTE

VxWorks Middle-ware

MCAL

RTE

Linux Middle-ware

MCAL

RTE

Deterministic Ethernet

SW

C 1

SW

C 2

SW

C 3

SW

C n

SW

C k

SW

C l… … …

Uniform basic services on all HostsSWCs can be moved between HostsIntegrated Tooling and SWC integration process

5

www.tttech.comConfidential Information – For Internal Use Only

PC-based SW-in-the-Loop Simulation (SIL)

Automotive µC

Autosar OSBSW

Middle-ware


RTE RTE

Safety RTOS Middle-ware

MCAL

RTE

Linux Middle-ware

MCAL

RTE

SW

C 1

SW

C 2

SW

C 3

SW

C n

SW

C k

SW

C l… … …

SW

C n

MW

Deterministic Ethernet Switch

Identical SWC-Code on PC and ECU – SWC only validated onceTiming accurate PC-Cosimulation (ADTF, Matlab/Simulink)

6

www.tttech.comConfidential Information – For Internal Use Only

Debugging & Tracing – Validation Support using Open Standards

Automotive µC

Autosar OSBSW

Middle-ware

MCALGeneral Purpose µC GPU

RTE RTE

Safety RTOS Middle-ware

MCAL

RTE

Linux Middle-ware

MCAL

RTE

SW

C 1

SW

C 2

SW

C 3

SW

C n

SW

C k

SW

C l… … …

Absolut observability with standard tooling without interference


IEEE TSN

IEEE 802.1 AS / gPTP synchronization

7

1. Integration of platform without configuring execution frames

2. Applications are integrated and tested individually by SWC suppliers without any timing restrictions

3. All applications are integrated by the SW-integrator on the platform; conflicts start immediately as it is not clear who is causing problems and why

4. Conflicts are reported back to functionSW suppliers, applications have to be modified to meet the system‘s timing restrictions

OS

Traditional Event-based MiddlewareTraditional Event-based MiddlewareOS OS OS

Core 1/2/3SoC

Core 1/2/3/4SoC

Core 1/2SoC

Core 1/2SoC

Event-triggered communication

OS

App1SWC

Traditional Event-based MiddlewareTraditional Event-based MiddlewareOS OS OS

Core 1/2/3SoC

Core 1/2/3/4SoC

Core 1/2SoC

Core 1/2SoC


OS

App1SWC

Traditional Event-based MiddlewareTraditional Event-based Middleware

App2SWC

App3SWC

App4SWC

App5SWC

App6SWC

OS OS OSCore 1/2/3

SoCCore 1/2/3/4

SoCCore 1/2

SoCCore 1/2

SoC


collision collision collision

Software Integration of ComplexReal-Time Systems

8

Modular Platform - Reduced Integration and Validation Efforts

9

1. Platform configuration and application scheduling

2. Single SWC test within configured schedule

3. SWCs are instantly running together (“composability”)

Iterations are avoided

Integration process massively accelerated

Insights from Serial Development

10

Eth

erne

t

Flex

Ray

CA

N

FR CA

N Deterministic Ethernet Switch

AutomotiveµC

High-EndGeneral Purpose

µC

Image processing

µC

SpecialµC

Eth

erne

t

Providing a clean platform architecture requires only very little HW-Overhead (Switch)

Automotive µC

Autosar OSBSW Middle-

ware

MCAL

General Purpose µC GPU

RTE RTE

VxWorks Middle-ware

MCAL

RTE

Linux Middle-ware

MCAL

RTE

Deterministisches Ethernet

S W C 1S W C 2S W C 3 S W C n S W C k S W C l

… … …Middleware features are intensively used(flexible SW allocation, PC co-simulation, debug features)

Iterations are avoided

Integration process massivelyacceleratedA clearly defined integration process is very

helpful for the work spilt between suppliers, dependencies and release organization

MW

Next Generation – Diverse Application Interfaces with AUTOSAR Adaptive

11

Automotive µC

Autosar OSBSW

Middle-ware

MCALPerformance SoC

RTE RTE

POSIX compatible OS (Linux, VxWorks)Middle-ware

MCAL

RTEAdaptive ASR stack

ara::com

SW

C 1

SW

C 2

SW

C 3

SW

C a

SW

C k

SW

C l… … …


Core 0 Core 3

SW

C j

SW

C b


12

Automotive µC

Autosar OSBSW

Middle-ware

MCALPerformance SoC

RTE RTE


MCAL


ara::com

… …


Core 0 Core 3

• For absolute determinism and highest safety requirements

• QM: Best Effort/Rate Constraint

• For “some” safety: • Dynamic behaviour

during development• Static configurations

for increased determinism and safety in the vehicle

SW

C 1

SW

C 2

SW

C 3

SW

C a

SW

C k

SW

C l

SW

C j

SW

C b

…


13

Automotive µC

Autosar OSBSW

Middle-ware

MCALPerformance SoC

RTE RTE


MCAL


ara::com

… …


Core 0 Core 3

• Enables mixed criticality network traffic (coexistence of best effort and safety related traffic)

SW

C 1

SW

C 2

SW

C 3

SW

C a

SW

C k

SW

C l

SW

C j

SW

C b

…

Automated Driving - System Classification by VDA

14

On the market today SOP 2017Planned for

2020 ffDelegation of responsibility from driver to the car.

Level 4 - Safety Requirements Level 4 automated driving requires ASIL D No high performance compute chips available for ASIL D High speed Level 4 automated driving required fault tolerance ASIL D

Embedded computing devices with ASIL D available

High performance computing devices possibly available with ASIL B (or C) but not ASIL D

15

Or Stop the car (avoiding obstacles)

The Fail-Operational Requirement

16

Level 4: “System can handle all situations automatically in the specific application case” [VDA] Even in the case of component failures!

Autonomous lane change to the side and stopping

Why is it Difficult?

17

Airplanes are fly-by-wire and fail-operational …… but they use triple or quad redundant diverse electronics

TTTech provides the fly-by-wire network for Embraer E-Jet E2 Family

And they have very strict software development requirements

Why is it Difficult?

18

• Boeing 777Flight Computer

• 3 x 3 Architecture• Hardware diversity• „Perfect“ Software –

No ASIL decomposition like mechanisms

TTTech provides the fly-by-wire network for Embraer E-Jet E2 Family

www.tttech.com

ISO 26262 Approach

19

Software• Processes more

strict for higher ASIL

Examples• Strict traceability• MC/DC test

coverage• Formal methods

Fault avoidance according to ASIL

Systematic Faults Random Faults

Hardware• Processes more

strict for higher ASIL

Examples• Formal reviews• Fault injection tests • Analysis

Hardware• Lower fault probability

for higher ASIL

Examples - self checking design• Dual core lockstep• ECC• Clock supervision

ASIL A

ASIL B

ASIL C

ASIL D

QM

ASIL: Automotive SafetyIntegrity Level

Design Corners For Random Hardware Faults

20

1oo2one out of two

A

B

2oo3two out of three

A

B

C

V

Components need to be fail-silent or self-checking (i.e., deliver correct result or no result at all)

Components can fail arbitrarilyThe voter becomes the critical element and a single point of failureComponents can be ASIL B (high performance) but the voter becomes ASIL D (embedded safety)

Solution Sketch Systematic Faults – Fail-operational ASIL-D and Diversity

21

ASIL B SWC 1’ASIL B SWC 1

ASIL B HW 2

ASIL B SWC 1’

ASIL D hardware

ASIL B SWC 1

ASIL B HW 1

Fail-operational ASIL D SWC

ASIL B HW 2ASIL B HW 1

diverse softwaresingle hardware

single softwarediverse hardware

diverse softwarediverse hardware

In most cases diversity is more costly and more effort compared to a single version with a higher ASIL levelUnfortunately many COTS SW/HW components are not available as ASIL DBut many COTS components are available from multiple suppliers (Operating Systems, SoCs etc.) No need to raise to fail-operational ASIL D due to diversity opportunityThe “right” compromise is clearly application specific

The New Problem for fail-operational Architectures : Example insufficient ASIL D Decomposition

Sender

E2E CommProtection

Comm Stack

AS

IL D

Fail-op ASIL D

Receiver App.

E2E Comm. Protection

Comm Stack

AS

IL D

Fail-op ASIL DQ

M

Bugs in QM components are detected but message is still unusable

ASIL D

System is only “QM” concerning availability of the software

QM

Fail-op ASIL D

Sender

E2E CommProtection

Comm Stack

Receiver App.

E2E Comm. Protection

Comm Stack

22

ASIL DMessage

ASIL DMessage

Fail-op ASIL DMessage

Fail-op QMMessage

Fail-op QMMessage

The Fail-Operational Challenge

23

Find the optimal architectural compromise for cost, safety and performance by selecting

the best suited hardware fault-tolerance mechanisms,the most appropriate ASIL decompositionconsidering diversity where necessary or beneficialbased on the best suited set of sensor and SoCsconsidering scalability

www.tttech.com

Fail-operational Redundancy Integration: Fail-operational as a Simple Add-in (1)

24

SoC 1

SoC 3ASIL D

SoC 2ASIL B(D) ASIL B(D)

Sensors

EthernetPartition A “Main Node”

ASIL D

SoC FASIL B(D)

CAN FDPartition B “Fallback Node”

ASIL B(D)

Integration Method: „Apply output from Partition A unless output is unusable - only then use output from Partition B“

High Integrity Main Node enables (fail-silent) ASIL D commands

Add-in Fallback Node as a flexible low cost architecture extension for fail-op systems

ASIL DFail-operational

Actuator

www.tttech.com

Random/Systematic HW Fault Solution: Partition Independence (1)

25

SoC 1 SoC F

SoC 3ASIL D

SoC 2


Actuator

ASIL B(D) ASIL B(D) ASIL B(D)Sensors

Ethernet CAN FD

Independent Fault-containment regions with electrical decoupling, diverse sensors anddiverse power supply

Partition A “Main Node” Partition B “Fallback Node”ASIL D ASIL B(D)

www.tttech.com

Random HW Fault Solution: Partition Independence (1)

26

„>1000FIT“ SoC

„>1000 FIT“ SoC

„<10 FIT“ SoC

ASIL D

„>1000 FIT“ SoC


Actuator

ASIL B(D) ASIL B(D) ASIL B(D)Sensors

Ethernet CAN FDPartition A “Main Node” Partition B “Fallback Node”

ASIL D ASIL B(D)

System architecture allows use of “high FIT” performance SoCs

www.tttech.com

Systematic Software Faults – Example Application Architecture Solution

27

Preprocessing1

Preprocessing3

Fusion 1 Fusion 3

FallbackTrajectoryPlanning

Preprocessing1‘/2

Fusion 2

Trajectory Planning

Safe Merge(ASIL D World View)

TTIntegration TTIntegration

TTIntegration

TTIntegration

Partition BPartition A

Fail-op ASIL D

Fail-op ASIL D

ASIL D

Fail-op ASIL DFail-op ASIL D

ASIL D

Sensors

actuators

SoC 2 SoC FSoC 1

SoC 3

ASIL B(D)

ASIL B(D)

ASIL B(D)

ASIL B(D) ASIL B(D)

ASIL B(D) ASIL B(D)

Platform Architecture for Level 4Automated Driving (1)

28

• Flexible combination of SoCs according to the necessary performance and ASIL level

• Flexibility to support different redundancy, and diversity schemes Communication Backbone (Deterministic Ethernet TSN, 1 Gbit/s)

Autosar OS

Multi-Core SoCSafety ASIL D

Multi-Core SoCPerformance

Multi-Core SoCSafety ASIL B …

Interface WrapperInterface Wrapper

App1SWC

TTIntegration MiddlewareTTIntegration Middleware

App2SWC

App3SWC

App4SWC

App5SWC

App6SWC

App7SWC

Multi-Core SoCSafety & Vision

App8SWC

ASIL D ASIL B QM ASIL B

RT-OS: VxWorks Autosar Adaptive

Rich OSLinux,

Autosar Adaptive

RT OSVision

Acceleration

Platform Architecture for Level 4Automated Driving (2)

29

• Flexible combination of different operating systems according to needed features and ASIL level

• Possibility for diverse operating systems use

Communication Backbone (Deterministic Ethernet TSN, 1 Gbit/s)

Autosar OS




Rich OSLinux,

Autosar AdaptiveRT-OS: VxWorks Autosar Adaptive


App1SWC


App2SWC

App3SWC

App4SWC

App5SWC

App6SWC

App7SWC


RT OSVision

Acceleration

App8SWC

ASIL D ASIL B QM ASIL B

Next Generation Platform Architecture (3)

30

• Flexible combination of SWCs with different ASIL levels

• Coexistence of fail-silent and fail-op SWCs without interference

• Diverse application interfaces (POSIX, AUTOSAR (Classic, Adaptive)

• Diverse and replicated SWCs will be supported

• Middleware will fulfill fail-op ASIL D

Communication Backbone (Deterministic Ethernet TSN, 1 Gbit/s)

Autosar OS





App1SWC


App2SWC

App3SWC

App4SWC

App5SWC

App6SWC

App7SWC


App8SWC

ASIL D ASIL C ASIL B ASIL A QMASIL D ASIL C QM

RT-OS: VxWorks Autosar Adaptive

Rich OSLinux,

Autosar Adaptive

RT OSVision

Acceleration

TTIntegration for fail-operational Level 4 Autonomous Driving

31

We do not know what the OEM’s Level 4 application will look like -But the next generation TTIntegration will support it by providing a flexible fail-operational ASIL D execution environment

Thank you for your attention

Copyright © TTTech Computertechnik AG. All rights reserved.

Vienna, Austria (Headquarters)Phone +43 1 585 34 [email protected]

USAPhone +1 978 933 [email protected]

JapanPhone +81 52 485 [email protected]

ChinaPhone +86 21 5015 [email protected]

www.tttech.com

from autosar adaptive to a safe level 4 adas platform · ad hoc software architecture automotive...

Documents