Real Time Software PROBLEM SETTING. Real Time Systems. Real Time Systems. Who is Who in Timed Systems. Real Time Systems

Size: px

Start display at page:

Download "Real Time Software PROBLEM SETTING. Real Time Systems. Real Time Systems. Who is Who in Timed Systems. Real Time Systems"

Elaine Merryl McKenzie
5 years ago
Views:

1 Schedulability Analysis of Timed Systems with contributions from PROBLEM SETTING Tobias Amnell, Elena Fersma, John Håkansson, Pavel Kracal, Leonid Mokrushine, Christer Nordström, Paul Pettersson and Anders Wall 1 2 Real Time Systems Real Time Systems Application software Application software Sensors Task Task Task Task Sensors Real Time Software Task Task Task Task Scheduler (Resource management) Scheduler (Resource management) RTOS RTOS Actuators Hardware Actuators Hardware 3 4 Real Time Systems Who is Who in Timed Systems Sensors Actuators Application software? Task Task Task Task Scheduler (Resource management) RTOS Hardware Real Time Scheduling [RTSS...] Task models, Schedulability analysis Real time operating systems Automata/logic-based methods [CAV, TACAS...] (Timed) Automata, Petri Nets, Process Algebras... Modelling, Model checking... (Real-Time) Programming Languages [...] Esterel, Signal, Lustre, Ada

2 Classic Real Time Scheduling Rate-Monotonic Scheduling Periodic tasks P1 P2 Pn P1...Pn arrive at fixed rates Fixed Prioirity Order: higher frequency => higher priority Always run the task with highest priority (FPS) Schedulability can be checked by solving (or UB test): Scheduler/RTOS Ri= Bi + Ci + j HP(i) Ri/Tj *Cj If Ri <= Di for all tasks Pi, the system is schedulable well-developed techniques e.g. Rate-Monotonic Scheduling 7 8 Arrival Rates (of Tasks): Periodic In real life P1 P1 P1 P1 P time tasks may share many resources (not only CPU time) tasks may have complex control stuctures and interactions tasks may not be that regular (often non-periodic) P2 P2 P2 P time P3 P3 P3 P3 P3 P3 P3 P3 P time 9 10 Task Arrival Patterns: Timed Traces The ABB Robot Controller Precise moves x:=0 x>3 a x<4 b Welding program A B C D Commands High-level instructions Requests (3.3, a) (3.4, b), (6.5, a), (3.6, a) (3.9, b), (3.14, a) ( , b) ABB robot controller ( loc) Real time tasks A,B,C,D Read inputs from channels write output to channels Task priority order D>C>B>A (FPS) Buffer overflow/underflow, WCRT 11 12

3 Automata-Based Approaches Networks of Real-Time Components Sensors Application software Task Task Task Task State Machines e.g. Timed automata Scheduler (Resource management) RTOS b? a? c? e! f! h? g! p! s? o! Actuators Hardware Automata-based Approaches Problems to solve A controller = a set of timed automata accepting events trigger tasks Pi s P1 P8 P1 P20 A1 A2 Am P6 P2 Scheduler/RTOS Schedulability analysis: check (A1 A2... An Scheduler) satisfies K A scheduler is given e.g. FPS, RMS, EDF etc K is a requirement specifying e.g. safety Schedule synthesis: find X such that (A1 A2... An X) satisfies K How to schedule tasks/automata? Worst-case response times? OUTLINE A Model for Timed Systems [1998] Timed automata with tasks Schedulability and Decidability [TACAS 02,04] Timed automata with bounded subtraction More Efficient Algoritms [TCS 06, IC 07] Schedulability analysis using 2 clocks (similar to Rate-Monotonic Scheduling) TIMES Demo Current/Ongoing Work Implemented in the TIMES tool The MODEL (Timed Automata with Tasks) 17 18

4 Timed Automata with Tasks Tasks = Executable Programs (e.g. C, Java) Events Discrete Transitions Timing constraints Clocks / Guards / Resets Complex arrival rates Tasks Asynchronous execution WCET, Deadline Scheduling policy Precedence constraints Resource constraints Task Task (C,D) (C,D) x<3 a! x:=0 Task parameters: C: WCET D: Relative Deadline (other parameters for schedulling e.g. Priority) Task Interface: Task P { v 1 := F 1 (v 1...v n )... v n := F n (v 1...v n ) } 19 (a set of variables updated) 20 Example: periodic tasks Timed Automata with Tasks (Example) start c:=0 P C<=100 c=100 c:=0 c: clock P: task start P (1,7) Q x>10 a y:=0 (3,9) x:=0 b y<=50 f r y=>2 R (2,2) Processor 1 (event handler) Initially, P in the queue Run-to-Completion/Stablization Whenever a available and x>10, Q is put in the queue Then Whenever b available and y<=50, P is put in the queue Whenever f available, R is put in the queue. Processor 2 (task handler) Schedule and Compute tasks in the queue P P Q Q Q R Timed Automata withtasks The Execution Platform Assume a set of tasks Pr A timed automaton with tasks is a tuple:<n,n 0,T,M> <N,n 0,T> is a standard timed automaton N is a set of nodes n0 is the initial node T N x (B(C) x Act x 2 C ) x N is the set of edges C is a set of clocks Act is a set of actions B(C) is the set of clock constraints e.g. X <10 etc M: N 2 Pr is a mapping which assigns each node a set of tasks Thread 1 Task Releases A 1 A n (the plant) Task Queue P 3 P 2 P 1 P 2 Thread 3 Thread 2: Scheduling Policy 23 24

States/Configurations of automata A state is a triple: (m, u, q) Location (node) clock assignment (valuation) task queue Run of TAT Idle P (Idle, x=0, []) 0.1 (Idle, x=0.

5 States/Configurations of automata A state is a triple: (m, u, q) Location (node) clock assignment (valuation) task queue Run of TAT Idle P (Idle, x=0, []) 0.1 (Idle, x=0.1, []) (RelP, x=0, [P(2,8)]) 1.5 (RelP, x=1.5, [P(0.5,6.5)]) (RelQ, x=1.5, [P(0.5,6.5),Q(2,20)]) 1.5 (RelQ, x=3, [Q(1,18.5)]) (Idle, x=3, [Q(1,18.5)]) (RelP, x=0, [P(2,8),Q(1,18.5)]) 2 (RelP, x=2, [Q(1,16.5)]) Q Sch and Run Semantics (as transition systems) Sch is a function sorting task queues according to a given scheduler e.g FPS,EDF,FIFO etc Example: EDF [ P(2, 10), Q(4, 7) ] = [Q(4, 7), P(2, 10)] Run is a function corresponding to running the first task of the queue for a given amount of time. Examples: Run(0.5, [Q(4, 7), P(2, 10)]) = [Q(3.5, 6.5), P(2, 9.5)] Run(5, [Q(4, 7), P(2, 10)]) = [P(1, 5)] States: <m,u,q> m is a location u is a clock assignment (valuation) q is a queue of tasks (ready to run) Transitions: g a r 1. (m,u,q) a (n, r(u), Sch[M(n)::q]) if m n & g(u) 2. (m,u,q) d (m, u+d, Run(d,q)) where d is a real 27 OBS: q is growing (by actions) and shrinking (by delays) 28 Zenoness = Non-Schedulability start x:=0 P x<=1 P=(2,3) SCHEDULABILITY Zeno: many P s may arrive within 1 time unit! P(2,3) P(2,3) P(2,3) P(2,3) P(2,3)... But after 2 copies, the queue will be non-schedulable 29 30

6 Schedulability of automata a state is a triple: (m, u, q) location clock assignment task queue A state is schedulable if q is schedulable An automaton is schedulable if all reachable states are 31 Schedulability of Automata Assume a scheduler Sch: A state (m,u,q) is schedulable with Sch if Sch(q)= [P 1 (c 1,d 1 )P 2 (c 2,d 2 ) P n (c n,d n )] and (c 1 + +c i )<=d i for all i<=n (i.e. all deadlines met) An automaton is schedulable with Sch if all its reachable states are schedulable An automaton is schedulable with a class of scheduling policies if it is schedulable with every Sch in the class. 32 Schedulability Analysis (Non-preemptive scheduling) FACT [1998] DECIDABILITY For Non-preemptive schedulers, the schedulability of an automaton can be checked by reachability analysis on ordinary timed automata Proof ideas (1): Size of schedulable queues is bounded The maximal number of instances of P i in a schedulable queue is bounded by Mi = Di/Ci The maximal size of schedulable queues is bounded by M1 + M2+...+Mn To code the queue/scheduler, for each task instance, use 2 clocks: c i remembers the computing time d i remembers the deadline (c i,d i ) Proof ideas (2): The scheduler as an automaton released_p2? c 2:=0 released_p1? d 1 :=0 c 2=C2 c 1 :=0 START d 2 :=0 P2 is running P2 is running P1 is running... P1=(C1,D1) P2=(C2,D2) d2>d2 d2>d2 or d1>d1 d1>d1 Error 35 36

7 The scheduler automaton Proof Ideas (3) Start Schedule c k =C k (Pk finished) S k := Running (if Dk<=Di for all i) c k:=0 d i :=0 released_pi? Pk is running d j :=0 released_pj? Modify the original automaton M: adding release! to inform the scheduler X<10 X<10 released_p i! z:=0 z:=0 P i P i M M SCHEDULER d i >D i (if Pi is released) Error 37 Check reachability of the error state for M SCHEDULER 38 How about preemptive scheduling? Decidability Result [TACAS 2002] We may try the same ideas Use clocks to remember computing times and deadlines BUT a running task may be stopped to run a more urgent task Thus we need stop-watches to remember accumulated computing times Then the schedulability problem is undecidable? FACT For Preemptive schedulers, the schedulability of an automaton can be checked by reachability analysis on Bounded Substraction Timed Automata (BSA). This is wrong!! NOTE Reachability for BSA is decidable Preemptive EDF is optimal; thus the general schedulability checking problem is decidable Timed automata with subtraction i.e. Subtraction Automata, [McManis and Varaiya, CAV94] Subtraction automata are timed automata extended with subtraction on clocks That is, in addition to reset x:=0, it is also allowed to update a clock x with X:= X-n where n is a natural number x:=0 y:=y-10 x>10 y>10 x:=x-1 41 Bounded Subtraction Automata A subtraction automaton is bounded if its clocks are non-negative and bounded with a maximal constant (or subtraction is only allowed in the bounded zone). N x u Bounded area allowed for subtraction e.g. x:=x-1 v u(x-1) v(x-1) M u~v implies u(x-1) ~ v(x-1) FACT: Location Reachability checking is decidable! y 42

8 Proof ideas (no stop but subtraction :-) Schedulability Checking as a reachability problem for Bounded Subtraction Automata released_p2? released_p1? c 2:=0 c 1:=0 c 1=C1 c 2:=c 2-C1 cm:=cm-c1 for all Pm preempted earlier P2 is running P1 is running P2 is running Model the scheduler as a subtraction automaton Do not stop the computing clock c 2 when a new task P1 is released Let c 2 for P2 (preempted) run until the task P1 (with higher priority) finishes, then perform c 2:=c 2-C1 (note: C1 is the computing time for P1) Proof ideas (clocks are bounded): released_p2? released_p1? c 1=C1 cm:=cm-c1 for all Pm preempted earlier c 2:=0 c 1:=0 c 2:=c 2-C1 P2 is running P1 is running P2 is running d2>d2 or dm>dm for any preempted Pm d1>d1 or dm>dm for any preempted Pm d2>d2 or dm>dm for any preempted Pm END of proof c 2 can never be negative. c 2 is bounded by D2. Error Schedulability analysis using DBM s Complexity y 4<= 4<= x <=7 <=7 2<= 2<= y <=4 <=4 x x:=x-4 y 0<= 0<= x <=3 <=3 2<= 2<= y <=4 <=4 x #clocks (needed) = 2 x #instances (maximal number of schedulable task instances) = 2 x Σ i Di/Ci This is a huge number in the worst case But the run-time complexity is not so bad! Subtraction on Clocks, added to DBM-library (UPPAAL) 47 48

9 It works anyway!!! WE CAN DO BETTER! [TACAS 03, TCS 06] #active tasks in the queue is normally small, and the run-time complexity is only related to #active clocks If Too many active tasks in the queue (i.e. Too many active clocks), the check will stop sooner and report non-schedulable For fixed priority scheduling strategies (FPS), we need only 2 clocks (and ordinary timed automata)! AND the analysis can be done symbolically! Main Idea The 2-CLOCK ENCODING (for fixed-priority scheduling strategies) Check the schedulability of tasks one by one according to priority order (highest priority first) This is similar to response time analysis in RMS To code the queue/scheduler, we need: Intuition of the encoding: Ri = Ci + Σ pri(pj)>pri(pi) Cj 1 integer variable for Pi: r denotes the response time as in RMS (the total computing time needed before Pi finishes) 2 clocks for Pi: c remembers the accumulated computing time (so much has been computed so far) d remembers the deadline Assume: priority(pj) > priority(pi) and Pi is analyzed Pi released: Pi finished: r:=r+ci c=r, d:=0 c<r,d=di: error!! d<=di time First release of Pj (or Pi) c:=0,r:=cj (or r:=ci) Pj released r:=r+cj When Pi finishes, r = Ri 53 54

10 The FPS scheduler : analyzing Pi The FPS scheduler : analyzing Pi (we need the boundedness) Release_j? r:=r+cj Release_j? r:=r+cj Release_j? r:=r+cj c=m c:=0 r:=r-m Release_j? r:=r+cj c=m c:=0 r:= r-m Waiting for Pi Release_i? d:=0 r:=r+ci Check Pi Waiting for Pi Release_i? d:=0 r:=r+ci Check Pi c=r c:=0,r:=cj Release_j? c=r d<=di c<r,d=di c=r c:=0,r:=cj Release_j? c=r d<=di c<r,d=di Initial Error Initial Error Note that it is not clear that c and r are bounded! 55 OBS: r-c is the only interesting info, so M can be any integer! Let M=Ci 56 c and r are bounded SUMMARY: Decidability c is bounded by M r is bounded by rmax + Ci Where rmax is the maximal value of r from previous analysis for all tasks Pj with higher priority For Non-preemptive schedulers, the problem can be solved using standard TA. For preemptive schedulers, the problem can be solved using BSA (Bounded Substraction Automata). So the scheduler is a standard TA END For fixed-priority schedulers, the problem can be solved using TA with only 2 extra clocks similar to the classic RMA technique (Rate-Monotonic Analysis) Undecidability Conclusions/Remarks Unfortunately, the problem will be undecidable if the following conditions hold together: 1. Preemptive scheduling 2. Interval computation times 3. Feedback i.e. the finishing time of tasks may influence the release times of new tasks. Unification of model-checking, real time scheduling, and synchronous programming: a unified model for timed systems (can express complex temporal and resource constraints). The first decidability result (and efficient algorithms) for preemptive scheduling in dense time models: The analysis is symbolic (using DBM s in the UPPAAL tool) Implementation: TIMES 59 60

T TIMES demo An Overview of TIMES Analysis System Specification System Analysis Editor Analyser Control structure Scheduler Analyser Yes, schedulable Extended Timed Automata Scheduling strategy EDF,

11 T TIMES demo An Overview of TIMES Analysis System Specification System Analysis Editor Analyser Control structure Scheduler Analyser Yes, schedulable Extended Timed Automata Scheduling strategy EDF, FIXED, etc. XML Scheduler generator Uppaal Verifier Simulator Controller Synthesizer No, not schedulable Execution Trace Optimal Schedule Task parameters Table, Task Code Task Code Library Code Generator Code 61 Modeling Synthesis 62 The INPUT LANGUAGE is very much like guarded commands Tasks = Executable Programs (e.g. C, Java) OBS: guard and update may contain data variables (integer, array) guard a! update task guard, update: synchronous computation which takes no time - we adopt the synchronous hypothesis [CONCUR 04] Task Type Synchronous or Asynchronous Non-Periodic (triggered by events) or Periodic Task parameters: C, D etc C: Computing time and D: Relative Deadline other parameters for schedulling e.g. priority, period Task Interface (variables updated atomically ) Xi :=Fi(X1...Xn) Tasks may have shared variables with automata with other tasks (priority ceiling protocols) Tasks with precedence constraints task: asynchronous computation whch takes time Functionality/Features of TIMES GUI modeling: automata with asynchronous tasks editing, task library, visualization etc Simulation symbolic execution as MSC s and Gant Charts Verification all you do with UPPAAL Schedulability analysis Code Generation Code Generation in TIMES Run Time Systems Event Handler, OS interrupt processing system or Polling Task scheduler, generated from task parameters Application Tasks = threads (or processes) Already there! (written in C) Current version of TIMES support LegoOS 65 66

12 TIMES Demo 67

plant OUTLINE The Same Goal: Reliable Controllers Who is Who in Real Time Systems

plant OUTLINE The Same Goal: Reliable Controllers Who is Who in Real Time Systems OUTLINE Introduction Lecture 1: Motivation, examples, problems to solve Modeling and Verication of Timed Systems Lecture 2: Timed automata, and timed automata in UAAL Lecture 3: Symbolic verification: