Interaction between AUTOSAR and non-autosar Systems on top of a Hypervisor

Transcription

1 Interaction between AUTOSAR and non-autosar Systems on top of a 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) 2

3 Virtualization Interaction between AUTOSAR and non-autosar Systems on top of a BSW 3

4 Challenge: Software Integration amount of AUTOSAR and non-autosar software-based functions cost per function number of ECUs Virtualization time Pricing pressure requires multiple functions integrated on a single ECU 4

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 EcuPartition 1 EcuPartition n ECU BSW MCU MCU Multi-core MCU 5

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 6

7 Virtualization Bare-metal 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: adaptive Real-Time Fast Boot Security Safety Certification BSW 7

8 Virtualization Use Case GPS Telematic Unit (TU) GPS LTE BSW 8 CAN

9 Virtualization Use Case Instrument Cluster (IC) HU IC Infotainment Head Unit (HU) RTOS OpenGL BSW 9 CAN

10 The 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). The is responsible for isolating the hardware resources between the VMs and for controlling access to I/O. VM 1 VM 2 VM 3 2 vcpu 1 vcpu 4 vcpu I/O I/O 10

11 Communication Primitives Shared Memory The runs in the highest privileged CPU mode and provides communication primitives for the communication between VMs. User mode Application Application Hypercall Supervisor mode VM 1 VM 2 User mode System call mode SoC with virtualization extensions SoC Supervisor mode SoC without virtualization extensions 11

12 Communication Layers Communication Layer Inter-VM Communication Method Communication Services Virtual Ethernet Device Connect multiple VMs to a virtual Ethernet network Communication Framework Provide high level signal communication services Communication Concepts Virtual Device Service Provide virtual device emulation to the VMs Data Channel Service Provide data communication channels between the VMs Communication Primitives Synchronous Messaging Hypercall or System call to the hypervisor Shared Memory Read/write access to shared memory area 12

13 Communication Concepts Shared Memory Virtual device emulation makes possible the reuse of a communication stack (CAN, Ethernet) within a VM to ease the software integration. Service VM VM 1 VM 2 Service VM Device emulation with I/O access Guest VM Driver Guest VM Driver Virtual device emulation Virtual Device Service Data Channel Service I/O 13

14 Example Ethernet SOME/IP Virtual Ethernet Network Linux Application SOME/IP SOME/IP BswM SD Com PduR SoAd OS UDP DNS DHCP TCP Communication Stack Ethernet Driver ARP IP ICMP EthIf Eth EthTrcv 15

15 Example CAN SocketCAN Virtual CAN Bus Linux Application Com PduR Communication Stack CAN Driver OS Can CanTP CanIf CanTrcv 16

16 Example CDD Signal Communication Shared Memory Signal based communication with low data overhead is required for an efficient communication (Automotive Communication Framework). Application Linux CDD library Data Channel Driver CDD OS Can Com PduR CanTP CanIf CanTrcv I/O 17 CAN

17 Example IOC Inter-VM Communication The scope of the IOC (Inter-OsApplication Communicator) module can be extended to the scope of inter-vm communication (vendor extension). EcuPartition 1 EcuPartition 2 VM non-autosar IOC Multi-core MCU IOC Guest Extension 18

18 Thank you! BSW 19

19 Contact All material copyright OpenSynergy OpenSynergy GmbH Rotherstraße 20 D Berlin Germany Phone OpenSynergy GmbH Starnberger Str. 22 D Gauting / Munich Germany Phone bluetooth@opensynergy.com OpenSynergy, Inc. (USA) 765 East 340 South Suite 106 American Fork, Utah Phone bluetooth@opensynergy.com