Stavros Tripakis VERIMAG EMSOFT’02

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

2. snowplowing platooning trucking docking PATH’s automated (computerized) vehicle control projects

3. Hardware

4. Question • How does the software architecture work ?

5. 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.

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

7. 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.

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

9. The software architecture

10. 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.

11. 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.

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

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

14. Software architecture of the platoon application

15. 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.

16. The lateral control task and chain

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

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

19. Estimating execution times • By averaging many experiments.

20. 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.

21. 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

22. 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.

23. 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?

24. 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).

25. 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 ?

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

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

28. 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.

29. 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.

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

31. Questions ?