On Static WCET Analysis Vs. Run-time Monitoring of Execution Time

1. On Static WCET Analysis Vs. Run-time Monitoring of Execution Time Charles D. Cavanaugh, Ph.D. The Center for Advanced Computer Studies University of Louisiana at Lafayette

2. Introduction • Safety critical and mission critical software • Input, process, output • Ex. Air-traffic control • Workload varies dynamically • Can allocate resource for maximum expected input size • Questions regarding resource allocation • How to process more tracks than anticipated? • How to get better utilization?

3. 747 29 400 270 F100 07 250 180 S80 07 200 000 Filtering Decision Making Radar Example • Air traffic control display subsystem • R-T display of radar, correlated data Displays DANGER F100 07 250 180 F100 07 250 180 747 29 400 270 747 29 400 270 S80 07 200 000 S80 07 200 000

5. Overview • Model and approach • Diagnosis algorithm • Conclusions and future work

6. System Model and Approach • Path – d.a.g. of connected programs, Pi • Computational subpath – executing program ai,j,k • Communication subpath – connection between two programs (ai,j,k, ai,j+1,k)

7. System Model and Approach • Observed time – path or subpath’s operating time OBS(Pi, c) • Required time – specified bound on time REQ(Pi) • Profiled time – mean execution or communication time with no other apps running or communicating • CPROF(ai,j,k, |Pi.DS(ai,j,k, c)|, HOST(ai,j,k)) • CMPROF(ai,j,k, ai,j+1,k, |Pi.DS(ai,j,k, ai,j+1,k, c)|, COMMPATH(ai,j,k, ai,j+1,k)) • May vary dynamically with workload

8. System Model and Approach • Poor health – path or subpath’s operating time exceeding specified bounds • OBS(Pi, c) exceeds REQ(Pi) because subpath latencies OBS(ai,j,k, c) and OBS(ai,j,k, ai,j+1,k, c) sum to more than REQ(Pi) • Quality of service – operating time falling within specified bounds

9. System Model and Approach • Workload – amount of data a path or subpath processes • Queueing delay or contention – time delay caused by other programs executing or communicating • Difference between observed time and profiled time without contention

10. Diagnosis Algorithm • Monitors computational and communication subpaths • Identifies unhealthy subpaths • Distinguishes the cause of poor health • Recommends actions to improve health

11. Component OBS CPROF|CMPROF|CCMTOT QDOBS Sensing Path P 1.2s CCMTOT=0.8s 0.4s Evaluate Sensor Filter & Decide F 0.5s CPROF=0.4s 0.1s Device Sensor (F,ED) 0.5s CMPROF=0.3s 0.2s Comp. Filter Manager Subpath Comm. ED 0.2s CPROF=0.1s 0.1s Subpath Example Table 2. Example latency, profiled time, queuing delay

12. Sensing Path Evaluate Sensor Filter & Decide Device Sensor Comp. Filter Manager Subpath Comm. Subpath Example Table 3. Example latency, profiled time, queuing delay

13. Conclusions and Future Work • System model • Observed time • Profiled time • Contention • Examples • Diagnosis algorithm • Future work • Incorporate into ATC simulator • Enhance profiling accuracy

14. Diagnosis Algorithm (1) IF observed time > required time THEN (2) IF path’s maximum slack < 0 THEN (3) LET s = subpath having the least maximum slack. (4) IF s is a compuational subpath THEN (5) IF s is scalable THEN LET action = copy s ELSE LET action = move s. (6) IF s is a communication subpath THEN (7) LET action = combine endpoints of s.

15. Diagnosis Algorithm (8) ELSE IF path’s queuing delay > path’s maximum slack THEN (9) LET s = subpath having the least maximum slack or the greatest queuing delay. (10) IF s is a compuational subpath THEN (11) IF s has the greatest queuing delay THEN LET action = move s. (14) IF s is a communication subpath THEN LET action = combine endpoints of s.