interaction between autosar and non-autosar systems on top ... · 2 introduction pierre-antoine...
TRANSCRIPT
Interaction between AUTOSAR and non-AUTOSAR Systems on top of a Hypervisor
Pierre-Antoine Bernard Ι 7th AUTOSAR Open Conference Ι Detroit, October 23rd 2014
2
Introduction
Pierre-Antoine Bernard Senior Software Engineer
OpenSynergy is a global provider of software solutions for embedded automotive systems. • Located in Germany (Berlin – Headquarter) and United States (American Fork, UT)
• Provider of a software platform based on a hypervisor (virtualization)
3
Virtualization
RTE
BSW
Application Layer
Multi-core SoC
Hypervisor
Interaction between AUTOSAR and non-AUTOSAR Systems on top of a Hypervisor
4
Pricing pressure requires multiple functions integrated on a single ECU
amount of AUTOSAR and non-AUTOSAR software-based functions
number of ECUs
cost per function
time
Challenge: Software Integration
Virtualization
5
AUTOSAR 4.x
Major concepts have been introduced in AUTOSAR 4.x to address the challenge of software integration:
• Memory Partitioning
• Multi-core Architectures
• Enhanced BSW Allocation
• Dual MCU
RTE
Application Layer
Multi-core MCU
BSW …
… EcuPartition 1 EcuPartition n
ECU
MCU MCU
6
AUTOSAR vs non-AUTOSAR
• Modular software architecture
• Scalability to different vehicle and platform variants
• Support of different functional domains (no infotainment)
• Support of applicable automotive international standards
• Fulfillment of strong security and safety requirements
• Modular infotainment architecture
• Reuse of available open source software components
• Robust development environment
• Highly customizable systems
• Challenge to meet safety and security automotive requirements
7
Virtualization
Virtualization extends the AUTOSAR concepts by making possible the integration of AUTOSAR and non-AUTOSAR systems on a single ECU and still satisfying automotive requirements:
• Real-Time
• Fast Boot
• Security
• Safety
• Certification
RTE
BSW
Application Layer
Multi-core SoC
Hypervisor
Bar
e-m
etal
adaptive
8
Virtualization – Use Case
Telematic Unit (TU)
RTE
BSW
Application Layer
Multi-core SoC
Hypervisor
GPS LTE
CAN
GPS
9
Virtualization – Use Case
Infotainment Head Unit (HU)
Instrument Cluster (IC)
RTE
BSW
Application Layer
Multi-core SoC
Hypervisor
RTOS OpenGL
CAN
IC HU
10
Hypervisor
Multi-core SoC
Hypervisor
VM 1 VM 2 VM 3
4 vCPU 1 vCPU 2 vCPU
The Hypervisor is an abstraction layer between hardware and virtual machines (VM) acting as the underlying technology for the virtualization technology. Dedicated CPU cores can be assigned to VMs or CPU cores can be shared between VMs (vCPU concept).
I/O I/O
The Hypervisor is responsible for isolating the hardware resources between the VMs and for controlling access to I/O.
11
Hypervisor – Communication Primitives
SoC
VM 1
Application
Supervisor mode
User mode
Hypervisor mode
VM 2
Application
Hypervisor
User mode
Supervisor mode
Shar
ed
Mem
ory
SoC with virtualization extensions
SoC without virtualization extensions
Hypercall System call
The Hypervisor runs in the highest privileged CPU mode and provides communication primitives for the communication between VMs.
12
Hypervisor – Communication Layers
Synchronous Messaging Hypercall or System call to the
hypervisor
Shared Memory Read/write access to shared memory area
Hypervisor Communication
Primitives
Virtual Device Service Provide virtual device emulation to the VMs
Data Channel Service Provide data communication channels between the VMs
Virtual Ethernet Device Connect multiple VMs to a virtual Ethernet network
Communication Framework Provide high level signal communication services
Communication Services
Communication Concepts
Communication Layer Inter-VM Communication Method
13
Communication Concepts
Multi-core SoC
Hypervisor
Guest VM Guest VM Virtual device
emulation
VM 1 VM 2 Service VM
I/O
Device emulation with
I/O access
Service VM
Virtual Device Service
Data Channel Service
Virtual device emulation makes possible the reuse of a communication stack (CAN, Ethernet) within a VM to ease the software integration.
Driver Driver
Shar
ed
Mem
ory
15
Example – Ethernet – SOME/IP
Multi-core SoC
Hypervisor
EthIf
ARP IP ICMP
UDP TCP DHCP
DNS
SoAd
Eth EthTrcv
SD
BswM
PduR
Com
RTE
Application Layer
OS
SOME/IP
Vir
tual
Eth
ern
et N
etw
ork
Application
Ethernet Driver
Communication Stack
SOME/IP
Linux
…
16
Example – CAN – SocketCAN
Multi-core SoC
Hypervisor
CanIf
CanTP
Can CanTrcv
PduR
Com
RTE
Application Layer
OS V
irtu
al C
AN
Bu
s
CAN Driver
Communication Stack
Application
Linux
…
17
Example – CDD – Signal Communication
Multi-core SoC
Hypervisor
CanIf
CanTP
Can CanTrcv
PduR
Com
RTE
Application Layer
OS
Data Channel Driver
Application
Linux
CDD
I/O
Shar
ed
Mem
ory
CDD library
CAN
Signal based communication with low data overhead is required for an efficient communication (Automotive Communication Framework).
…
18
Example – IOC – Inter-VM Communication
RTE
Application Layer
Multi-core MCU
EcuPartition 1 EcuPartition 2
IOC
RTE
Application Layer
Multi-core SoC
VM non-AUTOSAR
IOC
Hypervisor
Guest Extension
The scope of the IOC (Inter-OsApplication Communicator) module can be extended to the scope of inter-VM communication (vendor extension).
19
Thank you!
RTE
BSW
Application Layer
Multi-core SoC
Hypervisor
20
OpenSynergy GmbH
Rotherstraße 20 D-10245 Berlin Germany
Phone +49 30 60 98 54 0-0 E-Mail [email protected]
All material copyright © OpenSynergy 2014 OpenSynergy GmbH
Starnberger Str. 22 D-82131 Gauting / Munich Germany
Phone + 49 89 8934 13-33 E-Mail [email protected]
OpenSynergy, Inc. (USA)
765 East 340 South Suite 106 American Fork, Utah 84003
Phone +1 619 96 21 725 E-Mail [email protected]
Contact