Adaptive AUTOSAR. Ready for Next Generation ECUs V

Transcription

1 Adaptive AUTOSAR Ready for Next Generation ECUs V

2 Introduction Being Prepared for the Next-Generation of ECUs Additional, high performance ECUs hosting applications for upcoming use cases With Adaptive MICROSAR, Vector is providing a complete basic software solution Seamless interoperability with classic AUTOSAR ECUs Infotainment ADAS source: fotolia Applications installed and started during runtime Connectivity Development of applications in the ecosystem of POSIXbased OS (Linux, PikeOS, QNX, Integrity, ) Dynamic Software Platform 2

3 Introduction Drivers for Adaptive AUTOSAR Infotainment Highly Automated Driving source: fotolia 2D/3D accel. support in POSIX systems Image- and preprocessing of Camera/Radar/LIDAR Video Codecs, Streaming support, multi-media library, etc Sensor Fusion and Machine Learning Connectivity Dynamic Software Platform Car-2-X (LTE, WiFi, GPS, etc.) App-Store for automotive applications Multimedia (USB, SD-Card, NFC, etc.) Installation and update over the air 3

4 Introduction Use Cases for POSIX/Virtualization in Automotive Systems Core 1 (MSR 1) IPC MCU MEM Mini-Hypervisor Core 2 (MSR 2) IPC Applications as Driver ECU MCU 1 (POSIX) MCU 2 (MSR) IPC SPI/ETH POSIX besides MSR (previously used set-up) IPC Consolidation of existing ECUs Core 1 (POSIX) MCU Core 1 or 2 (MSR) Process 1 (nat. POSIX) IPC MCU MEM POSIX POSIX besides MSR (current QM set-up) Process 2(MSR) IPC OS Process 1 (ADAPTIVE) MCU Process 2 (ADAPTIVE) IPC MEM Hypervisor POSIX besides MSR (current safety set-up) IPC Middleware POSIX Adaptive Autosar (upcoming perspective) 4

5 Agenda Introduction Fundamentals ara::com ara::em ara::diag ara::per Roadmap 5

6 Fundamentals AUTOSAR Product Comparison AUTOSAR Classic Platform - CP AUTOSAR Adaptive Platform - AP Application Software Component AUTOSAR Interface Actuator Software Component AUTOSAR Interface Application Layer Sensor Software Component AUTOSAR Interface Application Software Component AUTOSAR Interface SWC SWC AUTOSAR SWC Runtime Environment ARA ARA for Adaptive Applications ARA Runtime Environment Adaptive AUTOSAR Services Memory Services Onboard Device Abstraction Microcontroller Drivers Memory Services Memory Hardware Abstraction Memory Drivers Communication Services Communication Hardware Abstraction Communication Drivers I/O Hardware Abstraction I/O Drivers Complex Drivers Time Management Operating System Bootloader Execution Management Persistency Platform Health Management Software Configuration Management Service Logging and Traceing Adaptive AUTOSAR Foundation Security Management Hardware Acceleration Service Service Diagnostics Communication Management Microcontroller (Virtual) Machine / Hardware All modules completely specified Less modules, only specification Developed in C Developed in C++ Whole stack compiled and linked in one piece Services as POSIX processes, separately installable Will still remain in the current focus Service oriented communication (SOME/IP) Configuration compiled in Configuration loaded from manifest files 6

7 Fundamentals AUTOSAR Product Comparison AUTOSAR Classic Platform - CP AUTOSAR Adaptive Platform - AP Application Software Component AUTOSAR Interface Actuator Software Component AUTOSAR Interface Application Layer Sensor Software Component AUTOSAR Interface Application Software Component AUTOSAR Interface SWC SWC AUTOSAR SWC Runtime Environment ARA ARA for Adaptive Applications ARA Runtime Environment Adaptive AUTOSAR Services Memory Services Onboard Device Abstraction Microcontroller Drivers Memory Services Memory Hardware Abstraction Memory Drivers Communication Services Communication Hardware Abstraction Communication Drivers I/O Hardware Abstraction I/O Drivers Complex Drivers Time Management Operating System Bootloader Execution Management Persistency Platform Health Management Service Software Configuration Management Logging and Traceing Adaptive AUTOSAR Foundation Service Security Management Hardware Acceleration Service Diagnostics Communication Management Microcontroller (Virtual) Machine / Hardware Real Time Requirements Safety Critical Computing Power 7

8 Fundamentals Adaptive Architecture Applications App1 POSIX Process ara::com ara::em ara::pers App2 POSIX Process ara::com ara::em ara::pers Middleware ara::com SOMEIPd Service Discovery Platform ara::com ara::em ara::pers ara::com ara::em ara::pers ara::em SCM Service Diagnostic Service EM (Execution Manager) Persistency BSD Socket BSD Socket for DoIP POSIX OS 8

9 Thread Thread Thread Fundamentals Adaptive Applications Manifest Instance Configuration INIT: RUN: SHUTDOWN: PSE51 C++ Stdlib POSIX OS App1 POSIX Process ara::com Adaptive AUTOSAR Services Direct Adaptive AUTOSAR Foundation Application > Multi-threaded > Execution states > Manifest contains platform related information (recovery action, dependencies to services or libraries) > Instance config contains application specific static information (variant, options, ) Interfaces > ara::com for communication with adaptive services (basic services and user applications) > PSE51 is the usable OS subset > The Adaptive AUTOSAR Foundation clusters (Execution Management, Persistency, etc.) are available via direct s 9

10 Fundamentals Adaptive Implementation VMs with prototype implementation (Based on YOCTO) Currently supported platforms Renesas R.Car H3 (Arm) ST Telemaco3P (Arm) Minnowboard (Intel) More in preparation Set of example services based on code in AUTOSAR GIT Additional services in development Tool supported service specification 10

11 Fundamentals Adaptive MICROSAR Development Environment Test your ECU directly in QEMU Implement your services using preconfigured Eclipse Adaptive MICROSAR source included Preconfigured Yocto build environment Furthermore included: > 2 Day training at Vector for 1 Person > Application Developer Guide > Tooling for creating service interfaces > Generators for proxies and skeletons 11

12 Authoring Tool Generators Compiler Software Configuration Management Fundamentals Tools and Workflow Service Description (ARXML) AppSWCTypes Port Port Port ServiceInterface SOME/IP Config Application Code Proxies / Skeletons SOME/IP Serializer E2E Serializer Logic libara libsomeip Deploy Package /opt/myapp/ BIN./bin/myApp Application Manifest./etc/MANIFEST.arxml Vehicle Installed APP BIN Application Manifest (JSON) Instance Manifest(s) (JSON) EM Installed APP BIN Application Manifest (JSON) Instance Manifest(s) (JSON) ComServer POSIX IPC Instance Manifest(s)./etc/instance1.arxml./etc/instance2.arxml Diag POSIX IPC SOMEIPd BSD Sock Generated Static 12

13 Agenda Introduction Fundamentals ara::com ara::em ara::diag ara::per Roadmap 13

14 ara::com Method Calls Communication initiated by the service consumer Bidirectional data flow N:1 communication: method can be called by multiple consumers Provider controls how parallel method calls are handled (serial, full parallel) ECU 1 (1) Call method as you would call a function: (3) Method implementation called: ReturnType ECU 2 SWC1 Proxy f = Proxy.method(arg, ) f is the handle for the call Skeleton::Method(arg, ) { } return return_value; SWC2 Skeleton SW ara::com (5) Call result can be obtained using f.get() ara::com SOME/IP SOME/IP (2) Method call transmitted (4) Call result transmitted 15

15 ara::com Sending Events Communication initiated by the service provider Unidirectional data flow from provider to consumers 1:n communication Consumer controls buffering strategy of events Event has a value only in the instant that it occurs SWC1 ECU 1 Proxy (3) Event stored in invisible buffer (4) User calls event.update() Predefined number of events moved to visible buffer (1) skeleton.event.send(value) SWC2 ECU 2 Skeleton SW ara::com ara::com SOME/IP SOME/IP (2) Event containing value 16

16 Agenda Introduction Fundamentals ara::com ara::em ara::diag ara::per Roadmap 17

17 ara::em Execution Management Overview OS launches Execution Manager (EM) (PID1, init ) EM inspects system for installed applications E.g., scan filesystem in /opt/ for application manifests EM runs startup applications (fork(), exec()) e.g., bring up IP stack Startup EM consults Machine State Manager to determine desired machine state Machine state defines set of applications desired to run EM starts/stops applications to reach desired machine state (fork(), exec(), signal(sigterm)) EM configures scheduling parameters & resource limits Configuration data obtained from application manifest EM monitors for machine state changes or process termination ECU running 18

18 ara::em Connecting the ExecutionManager to Applications - Example Communication via (library with IPC included) Functionality provided by EM for applications to report application state (e.g kinitializing, krunning, kshuttingdown) for Machine State Manager to > Register as MSM > Request machine state > Get current machine state 19

19 Agenda Introduction Fundamentals ara::com ara::em ara::diag ara::per Roadmap 20

20 ara::diag Diagnostic Manager - Overview No fundamental changes to exiting diagnostic workflows (like development, production, workshop, ) due to Adaptive Platform Main Tasks ISO (UDSonIP) Including fault-memory (DTC) handling Including transport layers (i.e. DoIP ISO x) Application (Software Components) Diagnostic Coding Callbacks Diagnostic Measurements Callbacks Diagnostic Routines ara::com Diagnostic Monitor Diagnostic Monitor Diagnostic Monitor Faults Configurable via AUTOSAR Diagnostic Extract (DEXT) Diagnostic Manager ARA service Uses ara::com interfaces Diagnostic Request Diagnostic Response Tester 21

21 references ara::diag Configuration workflow (DEXT) CANdela Studio DEXT Diagnostic Design PREEvision MANIFEST (Design) System Design 22

22 Agenda Introduction Fundamentals ara::com ara::em ara::diag ara::per Roadmap 24

23 ara::per Functional Overview In AUTOSAR Adaptive the Persistency cluster provides a library based implementation to access non-volatile memory to Adaptive Applications so that data can be stored non volatilely. Application Key-Value Storage Multiple values stored in one storage location Addressing of single values by using a key as identifier Multiple storage locations/databases can be used Database format not specified by AUTOSAR ara::per KvsType ara::per KeyValueStorage ara::per KvsType ara::per arafstream Stream Storage Raw access to storage locations/files Used for access to files in any format derived from C++ Standard Library std::fstream classes Key-Value Storage Location Stream Storage Location 25

24 Agenda Introduction Fundamentals ara::com ara::em ara::diag ara::per Roadmap 28

25 Roadmap Planned Adaptive Roadmap ASR Release 17-03: > Execution Management > Communication/ Middleware > DLT > Diagnostics > Persistency ASR Release 17-10: > Platform Health Management > RESTful Services > Signal based communication > Security Features > Time Synchronization > E2E Protection (Draft) > Package Management (Draft) ASR Release 18-03: > Container Support > Package Management > E2E Protection > SW-Lockstep > FR + LIN Bus > Crypto Hardware > Network Management ASR Release 18-10: > TBD Deliveries based on Adaptive AUTOSAR Code Adaptive MICROSAR R1: Adaptive MICROSAR R2: Adaptive MICROSAR R4: Vector Adaptive modules replace community source parts gradually as development is progressing Development Release Production Release (QM) Production Release (Safe) 30

26 For more information about Vector and our products please visit Author: Dr. Markus Oertel Vector Germany Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V