Communication Patterns in Safety Critical Systems for ADAS & Autonomous Vehicles Thorsten Wilmer Tech AD Berlin, 5. March 2018

Transcription

1 Communication Patterns in Safety Critical Systems for ADAS & Autonomous Vehicles Thorsten Wilmer Tech AD Berlin, 5. March 2018

2 Agenda Motivation Introduction of Safety Components Introduction to ARMv8 Operating System Configurations Safety Operating System for ARMv8 2

3 Motivation: DriveCore Visteon s Autonomous Driving Platform

4 ADAS to Autonomous Roadmap Function Forward Driving Side/Rear Parking L1 L2 L3 L4 L5 Adaptive Cruise Control Lane Keeping Assist Lane Change Assist Cross Traffic Alert Surround View ACC with LKA Advanced Emergency Braking Traffic Jam Assist Parallel Park Highway Pilot Parking Assist Highway Pilot City Pilot Valet Parking Auto Pilot L3+ System Requirements System performs Environmental monitoring Radar, Camera & LIDAR sensors Late fusion of sensor data ADAS Environment monitoring by human Autonomous Driving Environment monitoring increasingly by system Scalable centralized computing Machine learning algorithms Autonomous driving technology requires centralized processing of sensor data 4

5 Rapid Changes in Sensor & Processing Landscape Camera Radar Lidar Processors Increased Resolution up to 12 MP, frame rate up to 60 fps 24GHz to 600 GHz 2-D to 3-D Mechanical to solid state Higher resolution at <$250 CPU to GPU Emerging AI processors Higher resolution, higher framerates, increased sensitivity allows more detailed recognition CPU/GPU capabilities rapidly increasing More data volume forces higher processing power 5 New AI specific processors expected in near future

6 DriveCore Technology Platform In Vehicle System Development Tool Chain Perception Path Planning Actuation Level 5 CNN algorithms RL algorithms Vehicle Integration Level 4 Level 3 Scalable & modular computing hardware Runtime Compute Camera, Radar, Lidar, Ultrasonic From Level 3 to Level 4 Studio Simulated environment for algorithm development Simulation of real sensors Enable open collaboration with 3 rd party providers Patented advanced thermal management Software middleware abstracts h/w for AI algorithms PC-based dev toolchain for 3 rd party algorithm & app development 6

7 DriveCore Technology Platform In Vehicle System Development Tool Chain Perception Path Planning Actuation Level 5 CNN algorithms RL algorithms Vehicle Integration Level 4 Level 3 Runtime Compute Camera, Radar, Lidar, Ultrasonic Studio Simulated environment for algorithm development Simulation of real sensors Enable open collaboration with 3 rd party providers Scalable & modular computing hardware From Level 3 to Level 4 Patented advanced thermal management Software middleware abstracts h/w for AI algorithms What are typical Communication Patterns? PC-based dev toolchain for 3 rd party algorithm & app development 7

8 DriveCore Technology Platform In Vehicle System Development Tool Chain Perception Path Planning Actuation Level 5 CNN algorithms RL algorithms Vehicle Integration Level 4 Level 3 Runtime Compute Camera, Radar, Lidar, Ultrasonic Studio Simulated environment for algorithm development Simulation of real sensors Enable open collaboration with 3 rd party providers Scalable & modular computing hardware From Level 3 to Level 4 Patented advanced thermal management Software middleware abstracts h/w for AI algorithms How does Linux fit? PC-based dev toolchain for 3 rd party algorithm & app development 8

9 DriveCore Technology Platform In Vehicle System Development Tool Chain Perception Path Planning Actuation Level 5 CNN algorithms RL algorithms Vehicle Integration Level 4 Level 3 Runtime Compute Camera, Radar, Lidar, Ultrasonic Studio Simulated environment for algorithm development Simulation of real sensors Enable open collaboration with 3 rd party providers Scalable & modular computing hardware From Level 3 to Level 4 Patented advanced thermal management Software middleware abstracts h/w for AI algorithms Can the Hardware be utilized better? PC-based dev toolchain for 3 rd party algorithm & app development 9

10 Introduction of Safety Components 10

11 Redundancies On All Levels Two front cameras Lidar, radar and camera Redundant ECUs Redundant SoCs Redundant virtual partitions Redundant SWC ECC and repetition of messages Repetition of the execution Plausibility checks HW ECC on busses HW lock step Tipple voting gates ECU Resilient System Design 11

12 Typical Communication Pattern Voter State Output Input A State Voter Voter Voter State Output State A State Voter State Voter State++ Input Output Voter A Voter Sate++ State State++ Output 12

13 Safety Components Single threaded components Stateless Worst case execution time prediction & measurement Periodic functions S/R ports only 13

14 Safety Tasks: Periodic Read - Think - Write Set of active tasks Periodic task functions Memory protection between tasks Preemptive task switcher Fixed schedule for active task set Read / calculate / output SW lock step tasks compare output to vote Secure/safety cores have highest bus priority Safety components have same priority Worst case execution time for each task 14

15 Rate Monotonic Scheduling wastes Time Typical Execution is faster than Worst Case execution 15

16 Introduction to ARMv8 16

17 ARMv8 Exception Levels and System Architecture Non-secure Secure App App App App App App EL1 OS 1 OS 2 Trusted OS EL2 Hypervisor EL3 TLB Secure Monitor MMU EL1 Micro Code Translation and Cache TLB MMU EL2 D-Cache L2 Cache I-Cache Bus Protection Other Bus Master Internal System Bus 17

18 Freedom from Interference Interference Temporal Interference Interrupt disabled Wrong priorities Bus availability Cache contents Translation lookaside buffer Spatial Interference Memory not protected DMA into safety RAM mmap the same memory or device Logic Interference Wrong instructions Wrong microcode Countermeasure Temporal Countermeasure NMI for safety Highest priority for ASIL less priorities Bus periodization Clear the cache after scheduling Clear TLB after scheduling Spatial Countermeasure Use secure memory for safety, bus protection Bus protection BSP safety certified Logic Countermeasure Verify before execute before failure Avoid CPUs with microcode 18

19 Classic Safety Microkernel Set-up QM ASIL Security EL0 App App BSP EL1 Safety OS EL2 EL3 Startup Security not used If it is used it should be compliant to ISO26262 EL3 startup code configures Bus protection Core 1 Core 2 QM Applications Non root No direct mmap Lower priority ASIL Applications Root All drivers mmap allowed No QM drivers 19

20 Safety OS and Linux in Parallel QM ASIL Security EL0 EL1 App Linux BSP App Safety OS BSP EL2 EL3 Hypervisor Startup Core 1 Core 2 No BSP on safety OS required Drivers part of Linux Safety OS & Startup SHM communication to Linux Configure bus protection Share the SoC Share the assigned memory Drivers for secure peripherals 20

21 Safety Linux and Linux in Parallel QM ASIL Security EL0 EL1 EL2 App Linux App BSP SIL2Linux Hypervisor SIL2Linux Add missing work products FMEA Strip down functionality EL3 Startup Req Core 1 Core 2 FMEA Architecture Linux 21

22 Safety Operating System on ARMv8 22

23 Safety OS Requirements Rate Monotonic Periodic scheduling of execution sets Strict memory protection Re-execution of components possible Highest interrupt priority Uninterrupted execution of component Clear cache and TLB before execution of component (WCET) Support functions (watchdog, signature checks, start/stop of components) Boot and device support as needed Protect against side channel attacks 23

24 What about interrupts first serviced in EL3? 24

25 Use Secure World as Safety OS Non-secure Secure EL0 App App App BSP App App EL1 OS 1 OS 2 Safety OS EL2 EL3 Hypervisor Secure Monitor Core 1 Core 2 25 Safety OS can run on any core Highest priority Secure domain supported by internal busses* Remaining CPU time can be consumed by other OS Secure monitor used in many platforms already Less HW dependencies

26 Solution Space for EL3 Buy or write an EL3/Secure Safety OS qualified for ISO26262 Qualify existing EL3 code for ISO26262 o Same problem as SIL2Linux, but less code Modify existing non-secure safety OS to work in secure domain o Not covered by existing certification Do not use EL3 other than during startup to configure bus protection unit o Runtime verification? 26

27 Takeaways Redundancies on all levels Linux could be used isolated or in the SIL2Linux way A Dedicated Safety OS exploiting the Security features of the Hardware Mixing Rate Monotonic Scheduling with Priority based Scheduling maximizes Hardware utilization 27

28 28

29 Measure UDP Round Trip Time Start Timer at 200 MHz FM4 No OS Send & Poll for response Ethernet Cable Send UDP Frame imx6 QNX or Linux Poll for Reply Frame Reply UDP Frame Read out Timer Link: 29

30 round trip time [µs] UDP Round Trip Time Sample Linux without QNX without QNX Linux Linux QNX 5 max outlier 5 max outlier Min 77.6 µs µs 77.6 µs µs Max µs µs 90.3 µs µs Median 84.3 µs µs 84.3 µs µs StdDev 3.3 µs 22.8 µs 2.3 µs 1.4 µs QNX s StdDev would be better without outliers 30