Parallel Scheduling for Cyber-Physical Systems: Analysis and Case Study on a Self-Driving Car

Transcription

1 Parallel Scheduling for Cyber-Physical Systems: Analysis and Case Study on a Self-Driving Car Junsung Kim, Hyoseung Kim, Karthik Lakshmanan and Raj Rajkumar Carnegie Mellon University Google

2 2 CMU s Autonomous Car (2007) Chevy Tahoe ( Boss ) Won the 2007 DARPA Urban o o o o Challenge Senses its environment Fuses sensor data to form a model of the real world Plans navigation paths Actuates steering wheel, brake, and accelerator However, Boss o o Was designed to win a competition Had almost no limitation on resources o o Plentiful sensors Ten server blades with additional embedded controllers

3 3 What are we up to now? Towards a consumer-friendly autonomous car Designed to be safety-critical from the ground up Use automotive-grade components Be cost-effective Be aesthetically pleasing Challenges in computing resource management Space constraints Cost constraints Reliability constraints Thermal constraints Timing constraints

4 Perception & World Modeling Motivation Stretch* Linux/RK Case Study Conclusion 4 Boss System Architecture Map RNDF Mission MDF Hardware Hardware Pose Planning Graph Mission Planning Velodyne Road Network Mission Plan Request Replan Mission State Down Looking SICK Horizontal SICK Vehicle Sensor CAN Bridge Applanix Perception & World Modelling Pose Static Map Road Map Dynamic Map World State Visibility Sensor Health Behavior-Labeled RNDF Behavior Generation Scenario Goal Planning State Pose Cameras Health Monitoring Vehicle Controller (DbW) Static Map Road Map Dynamic Map World State Visibility Vehicle Commands Motion Planning

5 5 Motion Planning on Boss Parallel threads Master thread Parallel threads calculate the cost of each possible path Master thread picks up the best path

6 6 Why Parallel Tasks? As computing demands go up, a single core is not sufficient For motion planning algorithm on Boss: ~180% Greater than 300% for unstructured environments For computer vision tasks within vehicle: ~230% For segmentation, feature extraction and tracking: ~150% Need to scale functionality Individual core speeds will likely remain stable Must be able to use more cores for a given task

7 Scheduling Parallel Tasks Timing constraints of CPU-hogging tasks can be guaranteed and performance improved by parallelization A B C A B C D A B Fork Master thread A B C Join Parallelizable segments A B A C B D Motivation Stretch* Linux/RK Case Study Conclusion 7

8 8 Task-Machine Mapping On Boss Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8 Node 9 Node 10 Local Planning CAN Interface Local Planning CAN Interface Perception Task for ARS300 Behavior Perception Task for SICK Sensor Fusion Perception Task for SICK Mission Planner Perception Task for IBEO Sensor Fusion GPS Task Sensor Fusion Perception Task Motion Planning Building Map Perception Task for Velodyne 10 boards each with a dual-core processor were used Motion planning was isolated in dual-core Node 7 due to its CPUhogging nature On Boss s Successor Modern multicore processors Generic Playback Goal: Autonomous driving tasks should meet their deadlines while meeting intensive computing demands using multiple cores.

9 9 Our Goals Support an arbitrary number of parallel threads Explicitly use the given number of processing cores Use a simple and practical scheduling algorithm like global DM Lakshmanan et al. Saifullah et al. Nelissen et al. Model Fork-join real-time task model with a constrained number of parallel threads Fork-join real-time task model with an arbitrary number of parallel threads Fork-join real-time task model with an arbitrary number of parallel threads Scheduling algorithm Partitioned DM Partitioned DM, Global EDF U-EDF, PD 2, LLREF, DP-Wrap, Cons Supporting arbitrary number of parallel threads Considering the number of processing cores Complex scheduling policies Forum RTSS 10 RTSS 11 ECRTS 12

10 10 Outline Motivation and Goals Parallel Scheduling using the Task Stretch* Transform Realizing Real-Time Parallel Scheduling on Linux Case Study Conclusion

11 11 Task Model T i C i 1 P i 2 C i 3 P i s i 1 C i s i m i 2 (v s ) m i s i 1 (vs ) A fork-join real-time task model for cyber-physical systems τ i : C i 1, P i 1, m i 2 v s, C i 3,, P i s i 1, mi s i 1 vs, C i s i, T i s i is the number of task segments for τ i. m i j (v s ) is the number of parallel threads, where 1 j s i. m i j (v s ) depends on a state vector of physical attributes v s. C i j and P i j are the worst-case execution times for sequential and parallel segments, respectively. T i is the period of τ i, and an implicit deadline is assumed.

12 12 Revisiting Motion Planning on Boss Parallel threads Master thread State vector ν s includes the road rules and the road shape, the current vehicle information, static obstacles, and dynamic obstacles. The motion planning algorithm runs at 10Hz (T i = 100ms).

13 How to Schedule Fork-Join Real-Time Tasks? It is known that a fork-join real-time task structure can cause significant loss in utilization. : 2, 6,4, 2,15 1,1 2,1 3,1 1,1 2,1 3,1 2,2 2,3 Quad-core Processor 2,2 2,3 2,4 time 0 5 τ 2 : 15,20 τ τ 2 2,4 time τ 2 Missing the deadline time Lakshmanan, Karthik, Shinpei Kato, and Ragunathan Rajkumar. "Scheduling parallel real-time tasks on multi-core processors." RTSS, 2010 Motivation Stretch* Linux/RK Case Study Conclusion 13

14 How to Schedule Fork-Join Real-Time Tasks? It is also known that it is helpful to maximize the utilization of the master thread by migrating some parallel threads. : 2, 6,4, 2,15 1,1 2,1 3,1 1,1 2,1 2,4 3,1 2,2 2,3 Quad-core Processor 2,2 2,3 time 0 5 τ 2 : 15,20 2, τ 2 2,4 τ 2 time time τ Lakshmanan, Karthik, Shinpei Kato, and Ragunathan Rajkumar. "Scheduling parallel real-time tasks on multi-core processors." RTSS, 2010 Motivation Stretch* Linux/RK Case Study Conclusion 14

15 15 Why does the # of Cores Matter? : ( 2, 3, 8, 2, 15) 1,1 2,1 3,1 On a quad-core processor On a dual-core processor 2,2 2,3 1,1 2,1 2,2 2,5 2,6 3,1 : ( 2, 3, 8, 2, 15) misses its deadline on a dual-core processor. 2,4 2,3 2,7 1,1 2,1 2,3 2,5 2,7 3,1 2,5 2,4 2,8 2,2 2,4 2,6 2,8 2,6 2, Minimum execution length Minimum execution length 2,8 0 5 time There exists a minimum execution length on m CPU cores for each fork-join real-time task.

16 16 Task Stretch* Transform : ( 2, 3, 8, 2, 15) 1,1 2,1 2,2 2,3 2,4 3,1 Distribute the parallel threads evenly Calculate the minimum execution length Calculate the slack Fill up the master thread and assign proper deadlines and offsets Minimum execution length Slack 2,5 1,1 2,1 2,5 3,1 2,6 2,2 2,6 2,7 2, time Quad-core Processor 2,3 2,7 2,4 ττ 2,4 2,

17 Slack Slack With Multiple Parallel Segments Slack must be distributed proportionally : ( 2, 3, 8, 2, 3,8, 2, 26),1 2,1 1 2,5 3,1 4,1 4,5 5,1 1,1 2,1 2,2 3,1 4,1 4,2 5,1 2,2 2,3 2,6 2,7 4,2 4,3 4,6 4,7 Slack 2,3 4,3 2,4 2,8 4,4 4,8 2,4 4, ,5 4,5 Minimum execution length 1,1 2,1 2,5 3,1 4,1 4,5 Slack 5,1 2,6 4,6 2,2 2,6 4,2 4,6 2,7 4,7 2,3 2,7 4,3 4,7 2,8 4,8 2,4 2,8 4,4 4, time Motivation Stretch* Linux/RK Case Study Conclusion 17

18 18 Resource Augmentation Bound Global Fork-Join Real-Time Scheduling Partitioned Deadline- Monotonic 3.73 EDF 5 (Saifullah et al.) Deadline-Monotonic 3.42 (Lakshmanan et al.) 4 (Saifullah et al.) Resource augmentation bound (Speed-up factor) If an optimal algorithm can schedule a fork-join task set on unitspeed processors, then task stretching with global deadline monotonic can schedule it on processors that are 3.73 times faster when each heavy task is assigned to its own processing core. A heavy task has a density >= 1 ν on a ν-speed processing core.

19 19 Derivation Sketch Leveraging Bertogna et al s Theorem A set of periodic or sporadic tasks with constrained deadlines is schedulable with Deadline-Monotonic priority assignment on m 2 processors if: λ sum m 2 1 λ max + λ max The sum of density The maximum density We found the bound for each C i λ sum T i η i λ max 1 M. Bertogna, M. Cirinei, and G. Lipari. New schedulability tests for real-time task sets scheduled by deadline monotonic on multiprocessors, OPODIS 2006.

20 20 Outline Motivation and Goals Parallel Scheduling using the Task Stretch* Transform Realizing Real-Time Parallel Scheduling on Linux Case Study Conclusion

21 Resource Kernel Goals Provide real-time tasks with Timely, Guaranteed, and Enforced access to system resources Decouple resource requirement specification from management Transparently manage resource to guarantee task requirements such as deadlines and provide spatial/temporal isolation Resource Reservation: a task can reserve a portion of system resources for its exclusive use Enforce the usage of resources such that abuse of resources by one task does not hurt other tasks Task τ1 Reserved CPU : 40% (2, 5) Enforcement Replenishment (Next Period) Task τ2 : 30% (3, 10) 0 5 Time Motivation Stretch* Linux/RK Case Study Conclusion 21

22 22 RK Abstraction for Parallel Tasks Task : a fork-join parallel task Eight parallel threads are given Generate a set of reserves using the Stretch* transform Resource Set for : ( 2, 3, 8, 2, 15) Core 1 Reserve: rsv1 (15, 15, 15) prio: 3 offset:0 1,1 2,1 2,5 τ 1 2,4 2,8 3,1 Core 2 Core 3 Reserve: rsv2 (6, 15, 13) Reserve: rsv3 (6, 15, 13) prio: 2 prio: 2 spawned (offset:2) 2,2 2,3 2,6 2,7 Core 4 Reserve: rsv4 (1, 15, 8) prio: 1 time τ 1 2,

23 23 Linux/RK Extensions for Parallel Tasks We integrated Linux/RK into the Boss software architecture Implemented on Ubuntu x64 C++ is used for the planning algorithm C is used for kernel module support The existing APIs are preserved New APIs are added to support our parallel task model

24 24 Outline Motivation and Goals Parallel Scheduling using the Task Stretch* Transform Parallel Scheduling on Linux/RK Case Study Conclusion

25 25 Path Planning on Boss Path sampling Speed profile Performance Metrics Curvature Velocity

26 26 Case Study: Test Track for Boss NW intersection (2) (4) (5) Parking lot 4-way intersection (1) (3) Boss starts here SE intersection

27 27 Vehicle Dynamics on Test Track Curvature Velocity (1) (2) (3) (4) (5) NW intersection (2) (4) (5) Parking lot 4-way intersection (1) (3) Boss starts here SE intersection

28 28 With Traditional Linux/RK Curvature Velocity Curvature (1) (2) (3) (4) (5) Velocity

29 29 With Lakshmanan s Task Model Curvature Velocity Curvature (1) (2) (3) (4) (5) Velocity

30 30 Demo Video Traditional RK Lakshmanan s Model with RK Proposed Model with RK

31 31 Outline Motivation and Goals Parallel Scheduling using the Task Stretch* Transform Realizing Real-Time Parallel Scheduling on Linux Case Study Conclusion

32 32 Summary and Contributions Generalized a fork-join real-time task model for compute-intensive multi-core cyber-physical systems Proposed the task stretch* transform Proved the resource augmentation bound of 3.73 for global DM with the proposed algorithm Implemented the proposed scheme on Linux/RK Integrated the Linux/RK implementation into our autonomous vehicle Improved the autonomous driving quality in terms of curvature and velocity profiles

33 33 Thank you and Questions?