autosar compatible hypervisors for supporting cross ... · application of rta-hvr for a secure...

1 Public | ETAS/ERS-PD1 | 30/09/2015 | © ETAS GmbH 2015. All rights reserved, also regarding any disposal, exploitation, reproduction,

editing, distribution, as well as in the event of applications for industrial property rights.

AUTOSAR Compatible Hypervisors for Supporting Cross-

Company Workflows and Enhanced Safety and Security

Requirements

Stuart Mitchell



Contents

AUTOSAR Hypervisors for Safety and Security

AUTOSAR and the ECU workflow

• Integration – An AUTOSAR Success Story

Hypervisor Introduction

• What is it? Why is it necessary?

Hypervisors for Integration

• Intra- and Inter-company,

• Safety and Security



Current System – Function per ECU


Subsystem 1

Subsystem 2

Subsystem 3

Subsystem 4

− Current model

places one

functional

sub-system

per ECU

− Expensive

due to many

ECUs

− Good for

safety and

security



Integration – Multiple Functions per ECU


Subsystem 1

Subsystem 2

Subsystem 3

Subsystem 4

− Larger ECUs

reduce

complexity of

vehicle and

hence cost

− Multiple

functional

sub-systems

per ECU

− Reduced

safety and

security



− Reduce complexity of vehicle

topology

− Reduce ECU count

− Need more powerful ECUs

− Multicore

− Functional integration is an AUTOSAR

success story

− Aggregate SWCs on ECU

− Reconfigure and regenerate

MCAL / BSW / RTE

− AUTOSAR provides mechanisms to

protect against unsafe and

insecure systems

Functional Integration



Subsystem 1

Subsystem 2

Subsystem 3

Subsystem 4



− But there can be problems

− Integrating ASW from multiple vendors

− No single team: Who is responsible?

− SW Sharing

− Who is liable when ECU fails?

− How to retain security barriers of a

multiple ECU system?

− How do multiple vendors protect IP?

− Debugging

− Who performs root cause analysis?

what? why? who?

− Long round trip time to get fix

− Can different RTE/BSW configurations

trigger/mask bugs in ASW?

Functional Integration – An AUTOSAR Success Story





System integration using Hypervisors


Hypervisor for Workflow

Hypervisor

− Hypervisors

− Different software providers (e.g. OEM

and Tier 1) to develop SW stacks

separately

− Integrate with low effort.

− Each VM becomes a virtual ECU

− No need to share IP on the same

virtual ECU

− Temporal and Spatial separation for

safety and security

− Integration and validation of each virtual

ECU can be performed without the need to

coordinate with other software providers

− If a virtual ECU fails it’s clear which one failed and, therefore which supplier is

responsible.



Hypervisor based Cross-Company Workflow


Hypervisor for Workflow

Hypervisor

Hypervisor

Hypervisor

Hypervisor

Supplier 1

Supplier 2

Integrator Integrator



Abstract Architecture


What is a Hypervisor?

Virtual Machine Virtual Machine

Hypervisor

Own IO

Own IO

CPU MPU

CPU MPU

Shared IO

Own IO

Own IO

MPU abstraction

Exceptions

VM-VM Comms VDE

Shared IO VDE

Services

Direct IO Fast

Safe, secure inter-VM comms

Virtual Device Emulator (VDE) for

HW Arbitration

IO via HV Slow

ECU “image”.



Automotive Domain-specific Requirements


Hypervisors – the current state

Smal

l Sys

tem

s • Low interrupt latency

• Small footprint

• Hard Real-Time

• MPU

• Static config.

• Debug support

Larg

e Sy

stem

s • Peripheral support

• Feature download

• Soft Real-Time

• MMU

• Dynamic confign

All

Syst

ems • Certification

• Boot loader

• Safety

• Security

• Portability

• Multicore

− Contradictory requirements

− Resolve via configuration

− Configuration allows some

requirements to be removed.

− E.g. Diagnostics might

be configurable.

− How many of these

requirements are supported

by current commercial

hypervisors?

− Very few.



− RTA-HVR – A Real-Time Automotive

Hypervisor

− „Bare Metal“ Hypervisor: Runs

directly on underlying hardware

− Para-virtualisation: Guest OS

and MCALs make system calls via

the hypervisor

− Safety and Security: Makes use

of the native MMU/MPU and

supports resource sharing

between virtual machines (VM)

− Static build-time

configuration: Maps VMs to

cores for real-time

Architecture of a Real-Time, Safety-Critical Automotive Hypervisor


RTA-HVR : A Hypervisor for AUTOSAR

MMU: Memory Management Unit MPU: Memory Protection Unit

OS: Operating System MCAL: Microcontroller Abstraction Layer

Virtual Machine Virtual Machine

Hypervisor

Own IO

Own IO

CPU MPU

CPU MPU

Shared IO

Own IO

Own IO

MPU abstraction

Exceptions

VM-VM Comms VDE

Shared IO VDE

Services



− Configuration using ARXML

− Familiar tools

− Proven robust cooperation

model

− Same code generators

− Support Integration of SW from

multiple vendors

− Single team responsible for each stage

− Liability clear

− Hypervisor ensures safety and security

− IP protection

− Freedom from interference – e.g. temporal properties of other VECUs

− Debugging

− Isolated and Simplified (quicker) round trip for fix

Advantages of a Hypervisor Approach


Hypervisors – AUTOSAR Integration

Hypervisor

Hypervisor

Hypervisor

Hypervisor

Supplier 1

Supplier 2




Application of RTA-HVR for a Secure Computing Platform

RTE

Application Software

Drivers

I/O

Security Software

MCAL

Com

munic

ations

and d

iagnost

ics

Mem

ory

OS

HSM

Secu

rity

Serv

ices

I/O

MCAL

Com

munic

ations

and d

iagnost

ics

Mem

ory

OS

Syst

em

Serv

ices

RTE

Application Software

Drivers

I/O

MCAL

Com

munic

ations

and d

iagnost

ics

Mem

ory

OS

Syst

em

Serv

ices

RTA-Hypervisor

Security Domain

− Provides dedicated security services

− Crypto services

− Secure Boot

− Access to HSM

− Communication Stack with Firewalling

Virtualized software

− Para-virtualized OS within VM

− SW Stacks can be individually developed, configured and updated

Hypervisor

− Compatible to Automotive microcontrollers

− Enables privileged security domain

− Offers virtual machines behaving like a full computing system

Automotive ECU Hardware

− Standard ECU HW

− Support of Automotive HSMs (Bosch HSM)

Core 2 Core 1




RTA-HVR

Now 2016 2017 2018+

RTA-OS

• Separation at application SW level

• IP sharing

• High integration

• AR safety & security

• Automotive µCs

• Multi-core

RTA-HVR v1.0

• Full separation of SW stacks

• SW Stacks can be independently integrated/tested

• Full safety & security separation between SW stacks

• Automotive µCs

• Static configuration of one partition/core

RTA-HVR v2.0

• Integration of dedicated security functionality

• Support more automotive µCs

• Static configuration of multiple partitions per processing core

RTA-HVR v3.0

• Support integration RT safety critical vehicle functions with intensive processing

• Support for µPs with many processing cores

• Static and dynamic configuration of >1 partitions per core



− AUTOSAR has achieved its aim

− Abstraction to control complexity

− Support functional integration on ECUs

− But it’s perhaps been too successful!

− Applied to many use cases not originally foreseen

− Virtualization means we can support integration

− Keep what’s good

− But prevent new failure modes

− Automotive domain specific requirements

− ETAS has developed Type-1 Hypervisor to meet

the needs of AUTOSAR

Summary




Vielen Dank

Thank you

Merci

有難うございました

감사합니다

谢谢

धन्यवाद

Спасибо

Obrigado

Cảm ơn

Dr. Simon Burton Director Global Embedded Software

Services

[email protected] www.etas.com

ETAS GmbH, ETAS/ESC

Postfach 30 02 20

Borsigstraße 14

70469 Stuttgart

Germany

Telefone +49 711 3423-2590

Mobile +49 172 5 34 02 79

Dr. Stuart Mitchell Senior Software Engineer

ETAS/ERS-PD1

[email protected] www.etas.com

ETAS Ltd

Bacchus House

Link Business Park

Osbaldwick Link Rd

York, YO10 3JB

United Kingdom

Telephone +44 1904 562586

autosar compatible hypervisors for supporting cross ... · application of rta-hvr for a secure...

Documents