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 ?