The Adaptive Platform for Future Use Cases

Transcription

1 The Adaptive Platform for Future Use Cases Vector Congress Stuttgart, V

2 Agenda Introduction Adaptive AUTOSAR Architecture Use Cases and Requirements Adaptive AUTOSAR at Vector Conclusion 2

3 Introduction At a glance E/E development of following years will be influenced heavily by mega trends like connectivity, electrifications and automated driving The use cases introduced by these mega trends will have benefits for both, customers and OEMs New players on the market increase the pressure on OEMs to develop and introduced these use cases very soon Successful and efficient development of these use cases is not possible using existing software architectures Adaptive AUTOSAR is a new architecture to allow implementation of these use cases 3

4 Introduction Automotive Megatrends Automated Driving Connectivity (IoT) Electrification Sophisticated sensors Infotainment Start/Stop Sensor fusion Cloud Services Sailing Security V2X Hybrid Safety Security Multi Voltage Highly complex algorithms OTA Update Charger communication High definition maps Remote Diagnostics Map updates Automotive APP Store 4

5 Introduction New Platform Requirements The new platform has to fulfill Existing requirements Changed requirements New requirements Good Hardware Abstraction Multi/Many Core support Safety Interoperability with Classic Libraries for high File handling performance computing Adaptive Platform Update of Software Connection to non- AUTOSAR Services Service Oriented Architecture Realtime Common Methodology for Classic and Adaptive New Programming Model Security Diagnostics Easy configuration Faster Development Cycles 5

6 Introduction Definition of Adaptive AUTOSAR As a partner of the Automotive industry AUTOSAR saw the necessity to define a new platform It was clear that future cars will have heterogenous architectures The existing architectures had to be complemented by another one Adaptive AUTOSAR Deeply Embedded Architecture Dynamic Architecture Infotainment Architecture 6

7 Agenda Introduction Adaptive AUTOSAR Architecture Use Cases and Requirements Adaptive AUTOSAR at Vector Conclusion 7

8 Adaptive AUTOSAR Architecture Agenda Brief introduction to the Adaptive architecture What does the Adaptive platform mean for application developers? Explanation how the Adaptive platform handles different use cases 8

9 Adaptive AUTOSAR Architecture Layered Architecture Hardware/VM Adaptive Applications Adaptive AUTOSAR Foundation Adaptive AUTOSAR Foundation Adaptive AUTOSAR Services Operating System (POSIX based) Execution Management Persistency Management Software Configuration Management Adaptive AUTOSAR Services Security Management Diagnostics Adaptive Applications Bootloader Platform Health Management Logging and Tracing Hardware Acceleration Communications Hardware / Virtual Machine 9

10 Adaptive AUTOSAR Architecture Changes for Application Developers Applications are processes Applications Single- or multi threaded App1 Manifest App2 Manifest The configuration is no longer static at compile time POSIX Process ara::com ara::em ara::pers POSIX Process ara::com ara::em ara::pers Manifest files provide configuration information Middleware ara::com SOMEIPd Service Discovery Shared Memory Manifests are arxml files Configuration is done at runtime C++ is the main language POSIX Operating System Platform ara::com ara::em ara::pers SCM Service BSD Socket ara::com ara::em ara::pers Diagnostic Service POSIX OS BSD Socket for DoIP ara::em Emd (Execution Manager Deamon) Persistency 10

11 Agenda Introduction Adaptive AUTOSAR Architecture Use Cases and Requirements Adaptive AUTOSAR at Vector Conclusion 11

12 Use Cases and Requirements Agenda The architecture will be described in more detail based on the following use cases and requirements Hardware Abstraction Software Update Service Oriented Communication Classic/Adaptive Interoperability System Design 12

13 Use Cases and Requirements Abstraction of the Target Hardware The future use cases have requirements against the hardware Very high computational power Huge among of memory (RAM and ROM) Support of Hardware Acceleration Adaptive AUTOSAR Foundation POSIX OS BL Exec Persist Health Adaptive Applications Adaptive AUTOSAR Services SW Conf Security Diag Logging Tracing HW Accel Comm High Speed Interfaces 64Bit CPU 64Bit CPU RAM The Adaptive platform must provide an efficient abstraction of the hardware to the application Interfaces GPU Eth 64Bit CPU 64Bit CPU ROM 13

14 Use Cases and Requirements Abstraction of the Target Hardware The abstraction of the hardware is the job of an operating system Adaptive AUTOSAR goes one step further and abstracts also further parts of the hardware The Persistency Management takes care about an interface to non-volatile memory for the application Use of Hardware acceleration (e.g. GPU) is controlled by the Hardware Acceleration Management Excursus: PSE-51 14

15 Use Cases and Requirements Excursus: What is POSIX? POSIX - Portable Operating System Interface Standardized interface between applications and operating system > E.g. pthread_create, etc. There are four POSIX profiles PSE51: 287 APIs, small embedded system, no MMU, no file system PSE52: 626 APIs, special purpose controllers, no MMU, simplified file system PSE53: 754 APIs, large embedded system, with file system, with an MMU PSE54: 912 APIs, large real-time system with all the features Adaptive AUTOSAR allows PSE-51 only! What if the OS supports higher POSIX profiles? 15

16 Use Cases and Requirements Update, Upgrade and Relocation of Applications Connectivity allows update of software functions in ECUs Function V1.1 Deployment of new functions is also possible Initial deployment during production Driver buys applications in an Automotive App-Store ECU 1 Function V1.0 update Function V1.0 These mechanisms allow also relocation of software functions among differents ECUs move ECU 2 Function V1.0 add Function V1.0 16

17 Use Cases and Requirements Update and Relocation of Applications The Adaptive Software Configuration Management handles deployment of applications Manifests are deployed with the actual application and describe their properties Manifests are arxml files Adaptive AUTOSAR foundation modules read the manifest files during deployment and update their configurations Deployment package Applications can access manifest informations through Adaptive foundation services Adaptive Application ara::com ara::em ara::pers + Manifest 17

18 Use Cases and Requirements Service Oriented Communication Flexible deployment of applications requires flexible communication Hardwired communication paths cannot be used any longer Server Service consumer must be able to find service providers at runtime and subscribe to them Cient Adaptive AUTOSAR uses a service oriented communication paradigm The actual implementation of servers is not specified but a means to allows service offers and subscriptions This is implemented using SOME-IP Server Cient 18

19 Use Cases and Requirements Interoperability with the Classic Platform Software functions will be distributed among Adaptive and Classic ECUs High level parts of those functions will be located in Adaptive ECUs Deeply Embedded parts of Software functions will run on Classic AUTOSAR ECUs Both worlds are coupled via communication busses Interoperability is required on the communication bus M Eth-Switch Steering Sensor ECU ADAS ECU HW-Interfacing Intense Computation 19

20 Use Cases and Requirements System Architecture System architecture shall take both, Adaptive and Classic into account Abstract System Design Speed (m/s) This is what the AUTOSAR methodology does During the first stages of system architecture Virtual Function Bus Speed (uint16) development Software function are not mapped to the Adaptive or Classic Platform <<adaptive>> <<adaptive>> <<classic>> While this is a huge benefit for system architects, care Implementation has to be taken if new features are introduced to the Adaptive Standard Manifest Code ECUC Code Manifest Code 20

21 Agenda Introduction Adaptive AUTOSAR Architecture Use Cases and Requirements Adaptive AUTOSAR at Vector Conclusion 21

22 Adaptive AUTOSAR at Vector Adaptive AUTOSAR Development at Vector Development of a Vector Adaptive Stack including the required tooling Not bound to a specific target operating system Demonstrator Development Adaptive Demonstrator with BMW (Linux) ICAS Demonstrator with VW (Linux) Support for Linux, QNX, Integrity, PikeOS, etc. Development of a Vector Adaptive Stack Specification of Adaptive Platform WP-A WP-A3 WP-X TF-AP 22

23 Adaptive AUTOSAR at Vector Roadmap ASR Release 17.3: > Execution Management > Communication/Mi ddleware > DLT > Diagnostics > Operating System > Persistency ASR Release 17.10: > Filesystem > Package Management > HW Acceleration > Signal based communication > Safety and Platform Health Management > Security Features ASR Release 18.03: > SW-Lockstep > FR + LIN Bus > Crypto Hardware ASR Release 18.10: > Vehicle API > Container Support MICROSAR Adaptive 18.06: Beta Version of serial production release Based on Feature set MICROSAR Adaptive 19.01: Beta Version of serial production release Based on Feature set MICROSAR Adaptive 19.06: Final Version of serial production release Based on Feature set 23

24 Agenda Introduction Adaptive AUTOSAR Architecture Use Cases and Requirements Adaptive AUTOSAR at Vector Conclusion 24

25 Conclusion Conclusion The new Adaptive Platform complements the existing Classic Platform The Classic Platform will be still necessary to implement deeply embedded functionalities while the Adaptive Platform will run high level parts of functions Implementing a new Architecture was the right decision to handle future use cases Vector will continue to contribute to AUTOSAR and provide implementations and tools for Classic and Adaptive AUTOSAR 25

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