1. 1 Description and Schedulability Analysis of the Software Architecture of an Automated Vehicle Control System Stavros Tripakis VERIMAG EMSOFT’02

2. 2 PATH’s automated (computerized) vehicle control projects platooningdockingsnowplowingtrucking

3. 3 PATH’s automated (computerized) vehicle control projects Started in 1994. Different applications: –Platoons –Snow-plows –Trucks –Docking –… Public demo of platooning application in San Diego, 1997.

4. 4 Computerized vehicle control Photo of the car’s trunk HOW DOES IT WORK? HOW CORRECTLY DOES IT WORK?

5. 5 Hardware

6. 6 Question How does the software architecture work ?

7. 7 Contributions Understanding the software architecture (reverse-engineering by reading the code written by PATH staff). Building a model of the architecture for the platoon application. Schedulability analysis (based on existing real-time scheduling theory). Some conclusions.

8. 8 Outline The software architecture A model for the platoon application Schedulability analysis of the platoon application Conclusions

9. 9 Outline The software architecture –Publish/Subscribe A model for the platoon application –Set of periodic tasks –Each task is a chain of sub-tasks Schedulability analysis of the platoon application –So-called “HKL (Harbour, Klein, Lehoczky) analysis” –Extension of rate-monotonic analysis to chain-tasks

10. 10 The software architecture A set of processes running on QNX. A distinguished database process stores all variables of importance. A set of data I/O processes read/write data from/to the sensors/actuators, storing it to/taking it from the database. A set of (user-defined) controller processes compute variables from other variables.

11. 11 The software architecture Device drivers Data I/O Controllers Database

12. 12 The software architecture

13. 13 The software architecture Device drivers Data I/O Controllers Database

14. 14 The software architecture

15. 15 A publish/subscribe architecture One writer for each variable (practice). Readers can access variable in two ways: –Read it directly, or –Set a “trigger” for it (subscribe): every time the variable is written, the database will notify all subscribers for that variable. –Subscribers perform blocking receive, waiting for the notification.

16. 16 Advantages of the architecture Genericity: variables and client processes are defined per application. Dynamic creation of variables/processes is possible. Modularity: one process need not know of another (only interface with database and variable names need to be known). Integration: different providers can supply different processes as executables, source code not needed.

17. 17 Advantages of the architecture Asynchrony: different processes may run at different speeds. Synchrony could also be implemented with triggers. Event/Time-triggered: no difference.

18. 18 Conclusion 1 The P/S architecture has advantages that many other current proposals do not have.

19. 19 Software architecture of the platoon application

20. 20 A model (oriented towards schedulability analysis) –Fixed number of tasks. –Each task has a fixed period. –Each task is a sequence of sub-tasks (chain). –Each sub-task has a fixed execution time and a fixed priority. –Pre-emptive scheduling based on priorities.

21. 21 The lateral control task and chain

22. 22 Tasks and chains in the platoon application (total: 11)

23. 23 Schedulability analysis Goal: –Check that tasks meet their deadlines (deadline = period). Steps: –Estimate execution times. –Perform so-called HKL analysis.

24. 24 Estimating execution times By averaging many experiments.

25. 25 Harbour-Klein-Lehoczky (HKL) schedulability analysis Extension of Liu-Layland’s “completion time test” from simple tasks to chains. –For a task A, compute its worst-case completion time: C(A). –Verify that C(A)  deadline(A). –Repeat for all tasks.

26. 26 Harbour-Klein-Lehoczky (HKL) schedulability analysis Given a task A with minimum priority P of its sub-tasks (that’s the worst-case blocking point): –For each other task B, build the profile of B w.r.t. A: it is a finite word over {H,L} (“Higher or equal”, “Lower”). Example: –P = 10 –B = [5, 15, 20, 20], profile: L H H H –C = [5, 10, 5], profile: L H L

27. 27 Harbour-Klein-Lehoczky (HKL) schedulability analysis Profiles can be classified in 4 types, e.g.: –Type 1: H+ (all higher or equal) –Type 2: (H+ L+)+ (start higher, end lower) For each type i, you compute the worst-case blocking time B(i) that A may suffer from tasks of type i. Then, you compute C(A) based on B(i), using a recursive formula.

28. 28 HKL analysis of the platoon application model Computed completion times by hand. (tedious, error-prone: tools available?) Found that the deadline of the “lateral input” task can be missed. Can this really happen? If it happens, so what?

29. 29 Can this really happen? HKL analysis is exact: –if C(A) > D(A) then there is at least one case (of initial task phases and “bad-luck scheduling”) where eventually the deadline of A is missed. However, it assumes: –Correct estimation of execution times. –Simpler scheduling rules than in reality (e.g., round-robin of equal-priority processes in QNX).

30. 30 Even if it happens, so what? In real platoon drives, no problem has been experienced. What is the impact to vehicle control of a task missing its deadline, say, once every 100 times ?

31. 31 A deficiency of the worst-case model Tasks {(1,2), (2,3)} are not schedulable: – CPU utilization >1. Tasks {(?), ()} are not schedulable either, however:

32. 32 Rtscheduling apories An example of RMA not schedulable, with CPU util < 1. The paper of harmonic => RMA schedulable iff util=1. Is worst-case when phases are 0? Are HKL results for any initial phasing? (must be, otherwise just do a simulation).

33. 33 Conclusion 2 Accurate estimation of execution times is crucial for schedulability analysis techniques (non-robustness).

34. 34 Conclusion 3 It is not clear how meaningful the results of worst-case schedulability analysis are for control applications.

35. 35 Summary of our conclusions The P/S architecture has advantages that many other current proposals do not have. Accurate estimation of execution times is crucial for schedulability analysis. It is not clear how meaningful the results of worst-case schedulability analysis are for control applications.

36. 36 Now what? Can the analysis be done automatically? –Calculation easy, once chains and ET are defined. –Much harder to find out the chains and ET… –Also hard to go low-level (e.g., handle real QNX scheduling rules). Can the process priorities be synthesized? Another analysis (probabilistic?) that takes into account realistic control requirements. –C.f. G. Buttazzo’s invited talk at FTRTFT’02.

37. 37 … and some criticism to the P/S architecture Is the architecture too flexible? Should it be restricted? For what purpose and at what expense? Is it not formal enough? Not sure how important such criticisms are (e.g., to PATH engineers).

38. 38 Thanks to... Paul Kretz of PATH Raj Rajkumar of CMU Anonymous reviewer …

39. 39 Questions ?