Verification by testing

Transcription

1 Real-Tme Systems Specfcaton Implementaton System models Executon-tme analyss Verfcaton Verfcaton by testng Dad? How do they know how much weght a brdge can handle? They drve bgger and bgger trucks over the brdge untl t collapses! Then they take the weght of the last truck and rebuld the brdge Oh, I guess Honey, f you I should have don't know the known that! answer, just SAY so! Free translaton from Swedsh by J. Jonsson 1

2 Verfcaton by testng Congratulatons, Bulder Bob! It seems to be strong enough ths tme. Let s open the brdge. So, s ths how brdges (or other mechancal constructons) are bult? Of course not! There are models (propertes of materals) and theores (laws of mechancs) nvolved to determne n advance that a constructon wll wthstand the predcted load. Verfcaton by models & theory So, why cannot computer systems be bult and verfed n advance usng models and theores? Well, they can usng system models and schedulablty analyss 2

3 Verfcaton How do we perform verfcaton (schedulablty analyss)? Introduce abstract models of system components: Task model (computaton requrements, tmng constrants) Processor model (resource capactes) Run-tme model (task states, dspatchng) Predct whether task executons wll meet constrants Make tmng-correct abstract system models Make sure that computaton requrements never exceed resource capactes Generate (partly or completely) run-tme schedule resultng from task executons and detect worst-case scenaros Verfcaton How do we facltate schedulablty analyss? Concurrent and reactve programmng paradgm Sutable schedulable entty (thread, method, ) Language constructs for expressng applcaton constrants for schedulable enttes (data types, annotatons, macros, ) WCET must be dervable for schedulable enttes (specal cauton wth usage of dynamc language constructs) Determnstc task executon Tme tables or statc/dynamc task prortes Preemptve task executon Run-tme protocols for access to shared resources (dynamc prorty adjustment and non-preemptable code sectons) 3

4 Desgnng a real-tme system New desgn! What Logcal should functon be done & When Temporal should functon t be done? Specfcaton How System should mplementaton t be done? Implementaton Can Abstract t be done system wth models the gven Schedulablty mplementaton? analyss Verfcaton Run-tme model The run-tme model expresses the state of a task: watng sgnal ready wat nterrupt runnng dspatch Runnng: Currently executng task Ready: Task that s avalable for executon Watng: Task that cannot execute because t s needs access to a resource other than the processor 4

5 Task model Implementaton Abstract model vod task1(object *self, nt p) { Acton1(); SEND(Perod1, Deadlne1, self, task1, p); } vod task2(object *self, nt p) { Acton2(); SEND(Perod2, Deadlne2, self, task2, p); } vod kckoff(object *self, nt p) { AFTER(Offset1, &app1, p); AFTER(Offset2, &app2, p); } man() { TINYTIMBER(&app_man, kckoff, 0); } τ 1 τ 2 τ = { C, T, D, O} τ = { C, T, D, O } Task model The task model expresses the tmng behavor of a task: The statc parameters descrbe characterstcs of a task that apply ndependent of other tasks. These parameters are derved from the specfcaton or the mplementaton of the system For example: perod, deadlne, WCET The dynamc parameters descrbe effects that occur durng the executon of a task. These parameters are a functon of the run-tme system and the characterstcs of other tasks For example: start tme, completon tme, response tme 5

6 Task model Statc task parameters: τ τ = { C, T, D, O} C :(undsturbed) WCET T : perod D O :(relatve) deadlne :(absolute) tme offset D 0 C t O T Task model Statc task parameters: C Task s worst-case executon tme (WCET) Represents the longest undsturbed executon tme for one teraton of the task Derved as a functon of the task s program code D Task s relatve deadlne (responsveness constrant) Represents the maxmum allowed tme wthn whch the task must complete ts executon Apples relatve to the tme when the task becomes executable Derved as a functon of the envronment (e.g., laws of nature, control theory,...) 6

7 Task model Statc task parameters: T Task s perodcty Represents how often the task should be repeated Each teraton of the task has the same WCET O Task s tme offset Represents the frst arrval tme of the task, e.g., the earlest tme nstant at whch the task becomes executable Apples relatve to a gven orgn of the system The arrval tme of the n:th teraton of a task then becomes A n = O + ( n 1) T Task model Dfferent types of tasks: Perodc tasks A perodc task arrves wth a tme nterval T Sporadc tasks A sporadc task arrves wth a tme nterval T Aperodc tasks An aperodc task has no guaranteed mnmum tme between two subsequent arrvals Hard real-tme systems can only contan perodc and sporadc tasks. 7

8 Executon-tme analyss Program (no nput data) Real-tme compler Compler + WCET analyss Code WCET for (=1; <=N; ++) { f (A > K) A = K-1; else A = K+1; f (A < K) A = K; else A = K-1; } 42 Executon-tme analyss Motvaton: Worst-case executon tme (WCET) s mportant snce t s a prerequste for (hard) schedulablty analyss resource needs should be estmated early n the desgn phase The executon tme of a task depends on program structure + nput data ntal system state temporal propertes of the system (OS + hardware) nternal and external system events Estmaton of WCET should consequently be made whle the program s compled! 8

9 Executon-tme analyss Requrements: WCET must be pessmstc but tght 0 Estmated WCET Real WCET < ε (ε small compared to real WCET) pessmstc: to make sure assumptons made n the schedulablty analyss of hard real-tme tasks also apply at run tme tght: to avod unnecessary waste of resources durng schedulng of hard real-tme tasks The computatonal complexty of the analyss method must be tractable Executon-tme analyss Executon tme estmated WCET real WCET Input data 9

10 A smple (yet challengng) example Derve WCET for the followng program: for (=1; <=N; ++) { f (A > K) A = K-1; (T1) else A = K+1; (E1) f (A < K) A = K; (T2) else A = K-1; (E2) } Issues to consder: Input data s unknown Iteraton bounds must be known to facltate analyss Path exploson 4^N paths n ths example Excluson of non-executable (false) paths T1 + E2 s a false path n the example A smpler (but non-trval) example Derve WCET for the followng statement: Issues to consder: A = A / B; Executon tme: affected by cache msses, ppelne conflcts, exceptons... depends on prevous and (!) subsequent nstructons also depends on (unknown) nput data Observatons: accurate estmaton of WCET must be based on a detaled tmng model of the system archtecture uncertantes are handled by makng worst-case assumptons 10

11 Formulaton of the WCET problem Gven a system (= program structure + system platform) fnd the program s worst-case executon tme for all possble nput data, ntal system states and (nternal and external) system events Fundamental ssues Issues n the analyss of program paths how to lmt WCET (f necessary, pessmstcally) how to elmnate false paths (n order to derve a tght WCET estmate) Issues n the analyss of temporal behavor everythng that takes tme must be modeled n a realstc fashon (or at least not optmstcally) accurate and effectve tmng model of the system platform (nfluence of, e.g., cache memores, ppelnng, ) consequences of system events at run tme (e.g.: exceptons, nterrupts, context swtches) 11

12 Path analyss A control flow graph (CFG) descrbes the structure of the program Tmng analyss problem: Fnd the longest executable path n the program s CFG CFG may not contan cycles Non-executable paths must be elmnated Path analyss Shaw s Tmng Schema (1989): for (=1; <=N; ++) { f (A > K) A = K-1; (T1) else A = K+1; (E1) f (A < K) A = K; (T2) else A = K-1; (E2) } The estmated WCET (WCETe) s the executon tme of the longest structural path through the program WCETe = N*(WCET(loop) + WCET(I1) + max(wcet(t1), WCET(E1)) + WCET(I2) + max(wcet(t2), WCET(E2))) 12

13 Methods for path analyss Branches (alternatve paths) ntroduces the followng set of problems: 1. Iteratons (loops, recursons ) 2. Alternatve (f-then-else, case ) Goal: Bound the number of teratons n a loop or recurson Elmnate non-executable (false) program paths Methods for path analyss The user annotates the program so that ts CFG only contans a lmted number of executable paths: Annotaton of loop bounds: Provde upper bounds on loop ndces and catch potental exceptons at run tme Elmnaton of false paths: Enumerate all possble paths and lst the set of false paths so that these can be avoded n the analyss Requres very detaled knowledge of the program s functon, but s therefore also very prone to errors! 13

14 Methods for path analyss Automated method: Statc analyss (embedded n compler): Derve upper bounds on loop ndces requres an explct loop ndex does not always work for complcated termnaton condtons Elmnate false paths symbolcally execute the program and do assert wth respect to the possble values that varables are able to assume Prelmnary methods are promsng but only for farly smple programs where the analyss s trval! Methods for path analyss The realty? Exstng methods mplctly assume that the executon tme of each language statement s constant and known Ths s a qute realstc assumpton for a mcro-controller that lacks ppelned executon lacks cache memores does not generate exceptons However, for modern processor archtectures (= RISC), these methods yeld very pessmstc results! 14

15 Tmng analyss for modern processors Modern processors have several advanced mechansms (e.g., ppelnng, cachng, branch predcton, out-oforder executon) that cause sgnfcant varaton n the executon tme of a processor nstructon. We must therefore estmate the executon tme for each executable path through the program and at the same tme account for these mechansms. Ths can be solved by parttonng the program code nto code blocks and analyze each block separately. Today, mature methods for tmng analyss only exst for ppelnng and cachng. Tmng analyss for modern processors Processor wth ppelne: IF ID EX M WB Sources of tme varatons: structural conflcts data conflcts branch conflcts ICACHE DCACHE Sources of tme varatons: cache msses 15

16 Tmng analyss of cache memory Issues: Not enough to nvestgate an solated code block mss/ht depends on prevous executons of the code Instructon cache behavor s predctable for each path known sequence of code Data cache behavor s more dffcult to analyze data addresses can depend on the program s nput data Tmng analyss of ppelne Issues: Not enough to nvestgate an solated code block conflcts may occur on the boundary between code blocks Ppelne behavor s predctable for each path known sequence of code 16

17 Methods for tmng analyss Extenson of Shaw s Tmng Schema Analyss s performed at code block level Mergng of paths at certan code locatons by estmatng the effects of worst-case stuatons (reduces path exploson) Data flow analyss: Analyss performed at code block level Propagaton of ppelne and cache states between blocks Integer Lnear Programmng Formulate an ILP problem as a functon of executon tme and number of executons at code block level Challenges So far, non-preemptve schedulng of program code has been assumed (whch s not always realstc). In realty, pseudo-parallel executon s typcally used, somethng whch requres preemptve executon. Preemptons wll affect system state (.e., cache contents wll change and ppelne wll be flushed) and must therefore be accounted for n the analyss. However, t s dffcult to account for these effects n the analyss of WCET, whch means that t must be handled at a hgher level (.e., n the schedulablty test). 17