AUTOBEST: A microkernel-based system (not only) for automotive applications. Marc Bommert, Alexander Züpke, Robert Kaiser.

Transcription

1 AUTOBEST: A microkernel-based system (not only) for automotive applications Marc Bommert, Alexander Züpke, Robert Kaiser vorname.name@hs-rm.de

2 Outline Motivation AUTOSAR ARINC 653 AUTOBEST Architecture Certification Research Status + Outlook 2

3 Motivation Safety requirements for shared resources IEC An E/E/PE* safety-related system will usually implement more than one safety function. If the safety integrity requirements for these safety functions differ, unless there is sufficient independence of implementation between them, the requirements applicable to the highest relevant safety integrity level shall apply to the entire E/E/PE safety-related system. ISO Freedom of interference * E/E/PE: electrical / electronic / programmable electronic 3

4 Motivation Mixed-criticality system Partitioning P1 P2 P3 P4 ARINC 653 (Avionics) Spatial Partitioning most critical critical less critical least critical Time Partitioning Does this fit into a car as well? Kernel 4

5 Motivation Independent partitions Isolation P1 P2 P3 P4 (Limited) interference most critical critical less critical least critical Degraded mode Is this possible on today's ECUs with limited resources? Kernel 5

6 Motivation Requirements Different kind of partitions AUTOSAR partitions P1 P2 P3 P4 ARINC 653 partitions POSIX partitions most critical critical less critical least critical Static configuration Partitioning / MPU Partition Scheduling Tasks, Events, Alarms,... Goal: save as much RAM as possible! Kernel 6

7 AUTOSAR 7

8 AUTOSAR Automotive Software Stack Component Architecture Vendor neutral Design driven development Tools... Most components are outside the kernel Use existing 3 rd party components where possible Source: 8

9 AUTOSAR Automotive Software Stack Component Architecture Vendor neutral Design driven development Tools... Most components are outside the kernel Use existing 3 rd party components where possible Source: 9

10 ARINC

11 ARINC 653 Avionics OS Standard Part 1 - Required Services Part 2 - Extended Services Part 3 - Conformity Test Spec. Part 4 - Subset Services Multicore Services? Driven by IMA (Integrated Modular Avionics) SWaP (Size, Weight, and Power) Source: 11

12 AUTOBEST Architecture 12

13 AUTOBEST Architecture Observation: OSEK and ARINC 653 have a lot of similar design patterns: Tasks Processes 4 Task States Static Initialization Initialization at Startup Priority based FIFO scheduling Synchronization using Priority Ceiling Protocols Application Modes Partition States No conflicting requirements! Use a common microkernel architecture 13

14 AUTOBEST Architecture Special Features OSEK / AUTOSAR Counters + Alarms Schedule Tables Interrupt Handling Interrupts are partitioned Interrupt handler are mapped to high priority tasks DisableInterrupts() raise priority to partition maximum 14

15 AUTOBEST Architecture Special Features ARINC 653 Partition Communication Queueing- and Sampling-Ports 64-bit Nanosecond Timeout API Health Monitoring Strict Error handling Partitioning API Start & Shutdown of other partitions Privileged system calls 15

16 AUTOBEST Architecture Component Architecture AUTOSAR Application ARINC 653 Application AUTOSAR Library ARINC 653 Library Configuration Configuration user mode supervisor mode Architecture Layer Kernel Component Configuration Board Component Processor 16

17 AUTOBEST Architecture Device Drivers Low-level AUTOSAR components like MCAL need adaption: Put some parts into kernel, others in user space Pragmatic approach: put performance critical drivers (CAN) into kernel put highly complex drivers (EEPROM) in dedicated partitions 17

18 Certification 18

19 Certification Documented Software Design Process Focus on Traceability Multiple levels of Requirements High Level Interfaces Component APIs Internal Design Requirement-based Testing Analyses: Coverage, Timing,... Reviews Processes, Requirements, Design, Code, Tests,... 19

20 Certification AUTOSAR: typically highly configurable SW Integration becomes problematic #ifdefs lead to a large configuration set Did you really test every combination??? AUTOBEST Kernel: (almost) no #ifdefs all features enabled by default Configuration on binary data Binary component re-use! Simplify re-certification and software testing 20

21 Research 21

22 Research Topics Engineering challenges Make it safe Make it fast? Low memory consumption Research challenges Techniques to mitigate costs of partitioning Interrupt-Handling Strict Temporal Isolation Bounded Interference on Multicore 22

23 Implementation 23

24 Implementation Implementation in C99 with GNU extensions Compiler: GCC Supported Architectures: ARM v7 Cortex-R4: Texas Instruments TMS570 Cortex-A8: BeagleBone Black (for testing) QEMU PowerPC e200 MPC5646c (Bolero3M) QEMU 24

25 Status + Outlook Current Status / Done (October 2014): Full OSEK API + AUTOSAR extensions Full ARINC 653 Part 1 Supplement 3 support Resource partitioning + MPU support 11,900+ LOC C + asm for kernel and architectures specific code 7,700+ LOC Perl + C# code for tools Work in progress: Multicore Support Infineon AURIX 25

26 Thank you for your attention! Questions? 26