embedding software fit for the ecus of tomorrow...embedding software fit for the ecus of tomorrow by...

V0.1 | 2019-06-06

12th Vector UK Conference – 25th June 2019

Embedding Software Fit for the ECUs of Tomorrow

By Stephen Waldron, Local Product Line Manager, Vector GB

2

E/E Complexity and Software Quantity is Growing Fast

Embedding Software Fit for the ECUs of Tomorrow – Vector UK Conference 25.06.2019

1975 1985 1995 2005 2015

80% of automotive innovations are based on software

Electronic fuel injection

Cruise control

Gearbox control

Traction control

Anti lock brakes

Airbags

Electronic stability control

Active body control

Adaptive gearbox control

Adaptive cruise control

Emergency call

Adaptive headlights

Active steering

Curve warning

Stop and Go

Lane keeping assistance

Automated parking

Collision mitigation

Hybrid powertrain

Road trains

Electronic Brake Control

Telediagnostics

Car-2-car communication

Software updates

Gearbox control

Traction control

Anti lock brakes


Cruise control

Airbags

Electronic stability control

Active body control

Adaptive gearbox control

Adaptive cruise control

Emergency call

Gearbox control

Traction control

Anti lock brakes


Cruise controlElectronic fuel injection

Cruise control

3

Tony Seba - Clean Disruption: https://www.youtube.com/watch?v=2b3ttqYDwF0&feature=share

Automotive “Mega-Trends”


Automated

Electrified

Connected

Shared

https://www.youtube.com/watch?v=2b3ttqYDwF0&feature=share

4

What’s Under The Bonnet?


1990 2005 2020

Single electronic systems

Complex electronics system within

the vehicle

Complex electronics network between

vehicles and infrastructure

1 ECU 5 ECUs 25 ECUs 50 ECUs 100 ECUs

CAN MOST LIN FlexRay Eth/IP

4 bit 8 bit 16 bit 32 bit 64 bit

5

Evolution of the E&E Architecture – AUTOSAR Classic in Today’s Vehicle


Networked ECU Architecture Domain Controller Architecture

Functions integrated per domain

Multiple application software suppliers per ECU

Complex networking and gatewaying of data signals

ECUs implement dedicated function

One supplier per ECU

Limited amount of data signals shared between ECUs

Integrated AUTOSAR

Classic Systems

Standalone AUTOSAR

Classic Systems

6

What’s Under The Bonnet?


1990 2005 2020

Single electronic systems

Complex electronics system within

the vehicle

Complex electronics network between

vehicles and infrastructure

1 ECU 5 ECUs 25 ECUs 50 ECUs 100 ECUs

CAN MOST LIN FlexRay Eth/IP

4 bit 8 bit 16 bit 32 bit 64 bitMulti-Core

Less?

SOME/IP

7

What has AUTOSAR done for us?

Standardised software (BSW) across carlines, but also OEM boundaries

Standardised workflow (process) and data exchange formats between OEM and Tier-1 Supplier

Brought new features> FlexRay/Ethernet

> Safety (ISO 26262)

> Security

Managed complexity

Improved reuse

Lowered like-for-like costs

…but what hasn’t it done?

Building a Car, with AUTOSAR…


Instrument Cluster

Stability Control

Steering

Lighting

8

…and then there was AUTOSAR Adaptive


High performance ECUs hosting applications for future use-cases

(e.g. ADAS etc.)

Cohesive interoperability with Classic AUTOSAR

ECUs

Applications installed and started

during runtime

Applications running in a POSIX environment (e.g. Linux, QNX, Integrity, PikeOS)

9

Evolution of the E&E Architecture – Zonal Architecture & Central Computing Platform


Zone

Classic MICROSAR

Sensor and Actuator ECUs

Classic MICROSAR

Domain Controller ECUs

Domain Controllersignal and service oriented

Central Compute Platformservice oriented comms.

ECUsignal oriented only

Central Compute Node

Cross-domain functions

Mixed comms technologies

Central point of innovation

Same HW platform for all car-lines and generations

Your App Here!

10

AUTOSAR Classic Platform

AUTOSAR Classic and Adaptive


AUTOSAR Adaptive Platform

All modules completely specified

Developed in C

Whole stack compiled and linked in one piece

Configuration built statically

Signal-based communications

Less modules, with only API specification

Developed in C++

Services as POSIX processes, separately installable

Configuration loaded from manifest files

Service oriented communication (SOME/IP)

Application Layer

Runtime Environment

Memory Services

Communication Services

I/O Hardware Abstraction

Complex Drivers

I/O DriversCommunication

DriversMemory Drivers

Microcontroller Drivers

Onboard Device Abstraction

Communication Hardware

Abstraction

Memory Hardware

Abstraction

System Services

Microcontroller

Application Software

Component

AUTOSAR Interface

ActuatorSoftware

Component

AUTOSAR Interface

Sensor Software

Component

AUTOSAR Interface

ApplicationSoftware

Component

AUTOSAR Interface

Adaptive AUTOSAR Foundation

Adaptive AUTOSAR Services

(Virtual) Machine / Hardware

Update Configuration Management

Service

Security Management

Service

Diagnostics

ServiceTime

Management

API

Execution Management

API

Operating System

API

Persistency

API

Bootloader

Platform Health

Management

API

Logging and Tracing

API

Hardware Acceleration

API

Communication Management

API

SWC SWC SWC

ARA ARA ARA

AUTOSAR Runtime Environment

for Adaptive Applications

11

But what about Safety and Security?


12

Safety PlatformSafety Concept

Functional Safety in High-Performance Computing


Redundancy(redundant data)

Partitioning

Safe Basic Software

Redundancy

Voting Schemes

…

Enhancingdriver actions

Taking overdriver decision

Fail-Safe

Fail-Operational

HW

Basic Software(incl. OS)

Application Application

Lock-Step Cores

Watchdog

MPU/MMU

ECC Memory

…

HW mechanisms

Watchdog

Logical Supervision

End2End Protection

Safe OS

Memory Partitioning

…

SW mechanisms

Core Core

13

High Performance Basic Software Today: Safety OS


Typical Software Architecture Today

Application> Must deal with limitations of HW

> Functionality spited into mixed-critical parts

> Complex application architecture

Safety OS> Designed for safety

> Reduced functionality

> Less dynamic ecosystem

Safety Controller (SC)> Provides ASIL D runtime environment

> Performs monitoring and critical functional tasks

HP Processor (ASIL B)

HP Core

HP Core

…HP Core

HP Core

Adaptive MICROSAR(ASIL D)

Safety OS(ASIL D)

Application(ASIL B)

Application(QM)

Application(QM)

Application(ASIL D)

SC (ASIL D)

Core

ClassicMICROSAR(ASIL D)

Core

ASIL D ASIL B QM

14

High Performance Basic Software Tomorrow: Diverse Redundancy


Architecture with Diverse HP Processors

Application> HP applications with ASIL D possible

> Software to manage redundancy required

Diverse High Performance (HP) Processor> Random failure-rate solved via redundancy

> Systematic failure avoidance solved via diversity

ASIL D

Increased complexity and cost

Safety Controller (SC)> Still needed?

> Yes: Safety requirements are not all the same

> E.g.: High precision timing

> Fulfills non-safety requirements (e.g. boot time)

Safety Concept> High performance controller supports ASIL D

> Fail-operational demands reliability (as opposed to shutdown into fail-safe)

One option: Hybrid redundancy with functional degradation via safety controller

Or: Safety Controller for fail-operation, HP Processor for fail-safe

ClassicMICROSAR(ASIL D)

SC (ASIL D)

CoreCore

ASIL D ASIL D QM

HP Processor (ASIL B(D))HP

Core… HP

Core

Application(ASIL D)

Application(ASIL D)

Application(QM)

Application(ASIL D)

Application(QM)

Linux/Other(QM)


Hypervisor (e.g. PikeOS)(ASIL D)

Safety OS(ASIL D)

Linux/Other(QM)


Hypervisor (e.g. PikeOS)(ASIL D)

Safety OS(ASIL D)

HP Processor (ASIL B(D))HP

Core… HP

Core

ASIL D QM

15

Why does a Car need Cybersecurity?


Hackers remotely kill a Jeep at 70mph

http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway

16

Five Steps to Compromise an ECU


1.Remote Access

2.Access to

in-vehicle network

3.Bridge domain

boundaries

4.Access to

target ECU

5.Manipulate ECU orvehicle behavior

1www.freepik.com/www.flaticon.com

1

ADASDC

InfoDC

TCUPower

DC

ChassisDC Body

DC

DC:

Dom

ain

Contr

oller;

TCU

: Tele

matic C

ontr

ol U

nit;

ECU

: Ele

ctr

onic

Contr

ol U

nit

Defensebarriers

If the attackerhas physical

vehicle access,step one to

three may notbe necessary

http://www.freepik.com/www.flaticon.com

17

Securing the E/E Architecture – Defense in Depth (1.)


Secure vehicle-external interfaces

TLS, IPsec

Prevent/restrict remote access

Firewalling

White-listing (inbound/outbound traffic)

ADASDC

InfoDC

PowerDC

ChassisDC

TCU

BodyDC

E/E

: Ele

ctr

ic/E

lectr

onic

; TLS:

Tra

nsport

Layer

Securi

ty;

IPsec:

Inte

rnet

Pro

tocol Securi

ty

18



ADASDC

InfoDC

Isolation of execution context

OS, Hypervisor

Prevent/restrict access to in-vehicle networks

Firewalling

White-listing

Policing

Minimum rights

PowerDC

ChassisDC

TCU

BodyDC

OS:

Opera

ting S

yste

m

19



ADASDC

InfoDC

E/E architecture design

Security development process

Domain isolation

Message forwarding/routing

Ethernet: VLANs

ChassisDC

PowerDC

TCU

BodyDC

VLAN

: Vir

tual Local Are

a N

etw

ork

20



ADASDC

InfoDC

Secure messaging

SecOC, TLS, IPsec

Restrict/limit access to single ECUs

Firewalling

White-listing

ChassisDC

PowerDC

TCU

Secure time

Time synchronization

BodyDC

SecO

C:

Secure

Onboard

Com

munic

ation

21



ADASDC

InfoDCChassis

DC

PowerDC

TCU

BodyDC

Secure firmware

Boot/update

Secure ECU hardware and software

Secure diagnostics

Policing, SEM

Key management Root of trust

Crypto, HSM

SEM

: Securi

ty E

vent

Mem

ory

; H

SM

: H

ard

ware

Securi

ty M

odule

22

AUTOSAR Adaptive the Next Generation of AUTOSAR Basic Software


ADAS

Infotainment

source: fotolia

Connectivity

Dynamic Software Platform

High performance ECUs hosting applications for future use-cases

(e.g. ADAS etc.)

Adaptive MICROSAR the Safe and Secure Basic Software solution up to ASIL D

Cohesive interoperability with Classic AUTOSAR

ECUs

Applications installed and started

during runtime

Applications running in a POSIX environment

(Linux, QNX, Integrity, PikeOS)

23

Tooling: DaVinci Adaptive IDE


1. Assistants for various tasks like creation of SOME/IP deployment

2. Easy to understand DSL to represent ARXML models. With linting support

3. Auto-completion for references and model elements

4. Built-in CFG-5 generators. Direct modelling feedback and resolution suggestions

5. Cheat Sheets guide through the process of service creation

1

2

3

4

5

24

Vector’s Adaptive MICROSAR Roadmap


Adaptive MICROSAR R3:

Production Release(QM)

2018 2019 2020

Adaptive MICROSARR5:

Production Release(ASIL D)

Adaptive MICROSAR R1:

Development Release

PikeOS/MICROSAR Integration

Development Release


Production Release (ASIL D)


Production Release(QM)

Adaptive MICROSAR development started in 2015

Adaptive MICROSAR already used in many evaluation & prototyping projects

Adaptive MICROSAR soon to be used in the first series production projects

25 © 2018. Vector GB Limited. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V0.1 | 2019-06-06

Author:Stephen WaldronVector UK

Your questions are welcome!

http://www.vector.com/

embedding software fit for the ecus of tomorrow...embedding software fit for the ecus of tomorrow by...

Documents