View
215
Download
0
Category
Tags:
Preview:
Citation preview
1
Description and Schedulability Analysis of the Software Architecture of an
Automated Vehicle Control System
Stavros Tripakis
VERIMAG
EMSOFT’02
2
PATH’s automated (computerized) vehicle control projects
platooning
docking
snowplowing
trucking
5
Hardware
6
Question
• How does the software architecture work ?
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
Outline
• The software architecture
• A model for the platoon application
• Schedulability analysis of the platoon application
• Conclusions
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.
13
The software architecture
Device drivers
Data I/O
Controllers
Database
14
The software architecture
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
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
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
Conclusion 1
• The P/S architecture has advantages that many other current proposals do not have.
19
Software architecture of the platoon application
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
The lateral control task and chain
22
Tasks and chains in the platoon application (total: 11)
23
Schedulability analysis
• Goal:– Check that tasks meet their deadlines
(deadline = period).
• Steps:– Estimate execution times.– Perform so-called HKL analysis.
24
Estimating execution times• By averaging many experiments.
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
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
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
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
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
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 ?
33
Conclusion 2
• Accurate estimation of execution times is crucial for schedulability analysis techniques (non-robustness).
34
Conclusion 3
• It is not clear how meaningful the results of worst-case schedulability analysis are for control applications.
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
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.
38
Thanks to ...
• Paul Kretz of PATH
• Raj Rajkumar of CMU
• Anonymous reviewer
• …
39
Questions ?
Recommended