REFLECTING RTOS MODEL DURING WCET TIMING ANALYSIS: MSP430/FREERTOS CASE STUDY

Transcription

1 cta Electrotechnca et Informatca, Vol. 12, No. 4, 2012, 17 29, DOI: /v REFLECTING RTOS MODEL DURING WCET TIMING NLYSIS: MSP430/FREERTOS CSE STUDY Josef STRNDEL, Peter RJNOH rno Unversty of Technology, Faculty of Informaton Technology, IT4Innovatons Centre of Excellence, ozetechova 2, rno, Czech Republc, and strnadel/ndex.php.en STRCT The determnaton of the executon tme upper bound, commonly called Worst-Case Executon Tme (WCET), s a necessary step n the development and valdaton process for real-tme systems. The WCET analyss technques can be classfed as statc or dynamc. Whle a hgh-level language code suffces for the statc technques, for a precse WCET analyss a target archtecture or ts authentc smulator able to run the fnal machne-level code of an analyzed applcaton s needed by the dynamc technques. In the paper, we have decded not only to present a novel hybrd tmng analyss technque, but also to show ts practcal applcablty n the area of WCET analyss over partcular embedded archtecture (MSP430) and real-tme operatng system (FreeRTOS). Novelty of the presented method can be seen n the fact the operatng system model s reflected durng the analyss n order to facltate the process of dervatng schedulablty test formulas, create detal tas/stac analyss etc. pplcablty of the method was tested usng the MSPsm smulator of the MSP430 archtecture. Keywords: analyss, assembly, compler, FreeRTOS, model, MSPsm, MSP430, operatng system, profler, real tme, response tme, smulator, worst case, executon tme 1. INTRODUCTION Many systems exst, whch need to satsfy strngent constrants beng derved from systems they control. In order to analyze and verfy propertes of such systems even n early system-lfe phases, the systems are modeled by means of approprate modelng technques abstractng from certan non-essental propertes, but based on further propertes mportant from tme crtcalty pont of vew. The paper s dedcated to systems, whose operatonal correctness s based on both the correctness and tmelness of the outputs [1, 2, 9]. Such a system,.e., that s able to produce the rght response to gven stmul on tme, s called a real-tme (RT) system. The paper s organzed as follows: Frst, approaches to modelng RT systems are ntroduced (secton 1.1) wth specal attenton payed to the mplementaton of RT systems by means of tass runnng over the real-tme operatng system (RTOS) ernel. t the end of the secton, mportance of the schedulablty tests (secton 1.2) and executon tme analyss needs are emphaszed (secton 1.3). In the secton 2 common prncples and problems related to tmng analyss (T) technques are summarzed followed by the motvaton and goals of our research 2.3. Lacs of the actual methods can be seen n the fact they do not reflect target RTOS durng the analyss. s a result, they mae the dervaton of mechansms such as schedulablty test more dffcult and hard to automate. In the paper, the method reflectng the fact s presented and at the end of the paper t s shown how the results can be utlzed to derve the test for gven schedulng mechansm and target resources (RTOS, platform and ts smulator enrched about RTOS model). In secton 3 a prncple of the proposed T method s descrbed. In secton 4, partcular resources utlzed for mplementaton and expermental verfcaton of the proposed method are summarzed. Expermental results w.r.t. the method are summarzed n secton 5. Secton 6 concludes the paper Real-Tme System Model ascs Traddonally, an RT system s modeled as a set of RT tass, each havng assgned a set of parameters abstractng of an mplementaton of tass and contanng constrants posed on tas executon. Defnton 1.1. Let Γ = τ 1,τ 2,...,τ n denote the set of RT tass (representng partal functonalty of the RT system) wth partcular paramaters and Φ = φ 1, φ 2,..., φ m the set of computatonal resources the tas can be executed on. Each tas s typcally asocated wth an event. If an event occurs, the tas s released n order to react to the event. ecause events can be of varous prortes and can have varous constrants assgned, there must be an arbter called a scheduler mang a decson about whch tass wll partcular system resources be assgned to and n whch order. The result of the decsons s called a schedule. Defnton 1.2. Gven Γ and Φ, a schedule s defned as a dstrbuton of executons of tass from Γ among computatonal resources from Φ followed by orderng the executons n tme. Durng the dstrbuton, many crtera can be taen nto account, e.g., prortes. The scheduler decsons are based on the actual state of the RT system, events stmulatng the RT system, and parameters of tass n the RT system. RT tas parameters are gven by a gven tas model and can be dvded nto the two groups: prmary and secondary [2]. s the prmary parameters do not change durng the tas run tme they are also called statc. Lst of typcal prmary parameters follows (rather than descrbed n detal, some are lustrated n Fg. 1a): release (arrval, ready) tme of the tas, r worst-case exec. tme (WCET) of the tas, C relatve deadlne of the tas, D absolute deadlne of the tas, d = r + D relatve laxty tme, L = D C

2 18 Reflectng RTOS Model Durng WCET Tmng nalyss: MSP430/FreeRTOS Case Study r 0 s t e d 0 r 1 T D C C(t) D(t) L L R a) b) Fg. 1 Illustraton to a) RT tas parameters and b) extended verson of a formula for R enumeraton tas nvocaton perod, T ; defned for perodc tass Contrary to the prmary parameters, secondary parameters can change at the run tme or ther values are nown even n the run tme n order to reflect behavor of the correspondng tass, they are often called dynamc. Some of the typcal parameters are (for ther llustraton, see Fg. 1a): tas executon start-tme, s tas executon end-tme, e response tme of the tas, R = e r tme to mss the deadlne of the tas, measured n tme t, D(t) = d t remanng executon tme of the tas, measured n tme t, C(t) actual laxty tme of the tas, measured n tme t, L(t) = D(t) C(t) actual CPU load factor of the tas, measured n tme t, CH(t) = C(t) D(t) Defnton 1.3. Gven Γ and Φ, a schedule s called feasble all the tass from Γ are executed on resources from Φ before the tass mss ther deadlnes. I.e., n each t n the schedule, followng condton must be fulflled for a tas τ Γ runnng on a resource φ Φ: C τ,φ (t) D τ,φ (t). Defnton 1.4. Γ s called schedulable on Φ a feasble schedule exsts for Γ, Φ. Defnton 1.5. The schedulng problem s defned as the problem of fndng a feasble schedule for a gven Γ and Φ. Probably the most mportant parameter wthn the RT tas model s d,.e., the tme n whch the tas executon must be completed to prevent from an unpredctable behavor of the system havng more or less consequences to the envronment. Thus, the scheduler s requred to mae ts decsons wth a respect to the parameter. The decsons have to be made n O(n) or O(c) tme n the deal case hereat the schedulng problem s NP-complete n general 1. Defnton 1.6. Let a schedulng mechansm s denoted by ξ. n algorthm that s able to say Γ s schedulable on Φ by means of a gven ξ s called a schedulablty test Schedulablty Tests The most precse schedulablty tests 2 are based on evaluatng R,.e., response tme, for each τ Γ. To be schedulable on Φ, for each τ Γ t must hold: R D,.e., each τ must be able to meet ts deadlne when scheduled by means of gven ξ. The bg dsadvantage of response tme analyss based tests s the fact ξ have to be theoretcally analyzed n detal together wth target platform archtecture and operatng system before correspondng formulas can be derved. If the dervaton s too dffcult or mposble, suffcent or necessary condtons can be deduced. ut, they do not guarantee Γ s schedulable ff the condtons are met. s an example let suffcent, but not necessary condton for testng schedulablty of RM mechansm be presented [10]: n =1 C T n(2 1 n 1) For the condton and RM mechansm (that s optmal over the class of RT tas sets fullfllng condton τ Γ : D = T ), Γs can be found whch do not met the condton, but are schedulable. Response-tme based schedulablty tests for RM mechansm can be derved from followng recurrent relaton [8]: R +1 = C + C j (1) T j hp() j 1 ctually, many schedulng mechansms exsts [1,2,4,8,9], whch are able to schedule Γs under certan constrants e.g.: statc prorty assgnment based rate monotonc (RM), deadlne monotonc (DM) or dynamc prorty assgnment based earlest deadlne frst (EDF), least laxty frst (LLF) whch are able to guarantee schedulablty only for Γs composed of RT tass wth strctly lmted parameters (D T, Γ s CPU utlzaton Φ etc.) 2.e., those representng both suffcent and necessary condton

3 cta Electrotechnca et Informatca, Vol. 12, No. 4, where R s a value of R n th teraton of the relaton and hp() s a set of tass wth prortes hgher than prorty of tas. In the ntal teraton ( = 0), R s set to C. fterwards, R +1 s enumerated untl t hols R +1 = R (.e., the tas wll met ts deadlne) or untl R +1 > D (.e., the tas wll mss ts deadlne, so Γ the tas belongs to s not schedulable on Φ by means of RM) [18]. Meanng of the formula s as follows: worst-case response tme (R ) of a tas (τ ) s gven by tas s worst-case executon tme (C ) and and by sum of the worst-case executon tmes of all tass (τ j ) whch wll be executed durng the run tme of τ. Low-prorty tas τ wll be preempted by such hgh-prorty tass and ts response tme wll be delayed about tme needed for executon of the hgher-prorty tass. In order to get more precse analyss of response tmes, the basc formula should be extended about further elements descreasng abstracton level of the formula 3. The extended formula could loo le: R +1 = C + 2C sw j hp() + j alltass + J j + T tc T j + J j + T tc T j T tc C tc + (C j + 2C sw ) (2) C queue For detal descrpton of the parameters used to extend the formula see, e.g., [4, 8] Reasons for Executon Tme nalyss lthough prncples of schedulng mechansms and related schedulably analyss are dfferent, they all try to schedule tass wth near d before tass wth far d n order to guarantee no tas deadlne wll be mssed. It s evdent that for parameters of each τ Γ to be run n unprocessor envronment, t must hold C D,.e., deadlne must be set up n such a way t cannot be exceeded durng the tas executon. On top of t, for perodcal tass t must also hold D T,.e., perod must be set up n such a way that a new nstance of a tas cannot be called before the deadlne for prevous nstance of the tas s over; the whole condton can be wrtten as C D T. From the above mentoned, the followng can be concluded: efore the crucal RT tas parameters such as D and T can be set up, the C (.e., WCET) value must be precsed for each of the RT tass. The shortest executon tme s called the best-case executon tme (CET) and the longest tme s called the worstcase executon tme (WCET). In most cases the state space s too large to exhaustvely explore all possble executons and thereby determne the exact CETs and WCETs. So, t s not possble to obtan bounds on executon tmes for all programs n general. Otherwse, one could solve the haltng problem. However, real-tme systems only use a restrcted form of programmng, whch guarantees that programs always termnate; recurson s not allowed or s explctly bounded. relable guarantee based on the worstcase executon tme of a tas could easly be gven f the worst-case nput for the tas were nown [20]. 2. TIMING NLYSIS Today, n most parts of ndustry a common method utlzed to estmate executon-tme bounds s to measure the end-to-end executon tme of the tas for a subset of the possble executons (test cases). Ths determnes the mnmal observed and maxmal observed executon tmes. In general, they overestmate the CET and underestmate the WCET, so they are not safe for hard RT systems. Ths method s often called a dynamc tmng analyss. Newer measurement-based approaches mae more detaled measurements of executon tmes of several tas portons frst to combne them later to estmate CET/WCET values wth a smaller error. Surely, the bounds can be precsely computed only by methods that consder all possble tas executons. Those methods use a tas abstracton to mae the T process feasble. ut, the abstracton loses nformaton, so the computed WCET bound usually overestmates the exact WCET and vce versa for the CET. The crtera for evaluatng T methods are [20]: safety does t produce bounds or estmates? precson are the bounds or estmates close to the exact values? efore bascs of T technques wll be presented, t should be emphaszed that T results could be precse only f the analyss s done over partcular data/control paths allowed durng executon of partcular machne code of the tas generated for partcular hardware. In relaton to that, many problems must be dealt wth some of the most mportant are mentoned below: Problems related to data dependency n a program flow: tas to be analyzed attans ts WCET on one or more of ts vald executon paths. If the nput and the ntal state leadng to the worst-case executon path were nown, the problem would be easy to solve. ut, the worst-case nput and ntal state are not nown n general because they are hard to determne. superset of the set of all tas executon paths s usually descrbed by means of control-flow graph, CFG [19]. However, CFG can contan nput-data dependent paths that would never be executed because of nput-data lmtatons or exstence of contradctory condtons. The other problem can appear f bounds 3 Devaton of analyzed response tmes from real response tmes can be mnmzed f the formula s extended, e.g., about followng elements: (blocng tme of τ,.e., maxmal tme for whch τ can be n not-ready state), J (jtter tme of τ,.e., maxmal dfference between two release tmes of τ ), C sw (context-swtch tme), T tc (tme resoluton of a scheduler tc), C tc (tme needed to servce a scheduller tc) or C queue (tme needed to change state of a tas to ready)

4 20 Reflectng RTOS Model Durng WCET Tmng nalyss: MSP430/FreeRTOS Case Study on the teratons of the loops or on the depth of recursve functons are unnown. Problems related to the mpact mplyng from modern archtecture prncples: Even the abovementoned problems are solved, accuracy of the results s questonable f tass are to be executed on a platform equpped wth ppelnes, branch predctors, cache memores, speculatve executon unts etc. Those modern components can brng nto beng several problems such as executon nstructons n a dfferent order (due to prefetchng, loop optmzatons, speculatve executons etc.) or contextdependency of the executons (e.g., due to varous cache or ppelne contents). On top of ths, t s ntutvely supposed the latter executons of the same tas would always lead to the same or shorter executon tme, e.g., due to cache hts. ut, t was observed that t can also happen the latter executons may, n fact, lead to a longer executon tme, e.g., because of mspredctons durng the speculatve executon. Ths phenomenon s called a tmng anomaly [11]. In the mentoned case, t s necessary to nvaldate all results acheved durng executon of wrong-drected nstructons, whch leads to clean-up of ppelne, cache etc. an extended executon of rght-drected nstructons. The mportant concluson can be made at ths pont: the assumpton that the global WCET of the tas equals to sum of the local WCETs s ncorrect n general, but t can be correct for the partcular platform Statc Tmng analyss Technques Ths class of methods does not rely on executng a tas code on a real hardware or on a smulator, but rather t taes the code tself, combnes t wth some more or less abstract model of the system wth the goal to obtan upper bounds based n the combnaton [7,12]. Typcally, the methods are composed of the followng steps: control-flow graph (CFG) creaton [19]: durng the step (also called a frontend), the tas source code s transformed nto the CFG descrbng a relaton between vertces called basc blocs, each of them representng maxmal sequence of non-loop/non-branch nstructons. The relaton s expressed by means of edges representng loops or branches n the code. oth the vertces and the edges can be evaluated by an extra nformaton such as maxmal number of loop teratons, value boundares etc. control-flow analyss (CF) [20]: n the step, CFG s analyzed n order to remove subgraphs, whch do not represent vald executon path of the code. (The effort s to elmnate so much nvald paths as possble, because each such a path can potentally contrbute to underestmaton of CET or to overestmaton of WCET, low-level analyss [20]: n the step, both compler and platform attrbutes are analyzed (compler optons, platform ppelnes, memory access mechansms, branch predctors, caches etc.); the platform behavor s typcally aproxmated rather than modeled precsely, evaluaton of bounds: on bass of facts about a code flow and a platform model, one of the followng methods s typcally utlzed to evaluate the bounds [3, 15, 16]: syntax-tree based, path-based or mplct path enumeraton vsualzaton and statstcs. Detal descrpton of the above-mentoned steps and related methods s out of scope of the paper. Instead of, dynamc T technques are brefly descrbed n the next Dynamc Tmng analyss Technques These methods attac some parts of the T problem by executng a tas on a gven hardware/smulator for a set of nputs to measure the executon tme of the tas [20, 21]. It should be noted that f the subset do not contan the worst case then the end-to-end measurements of a subset of all possble executons are able to produce estmates/dstrbutons, but not exact executon tme bounds. On contrary, even one executon would be enough f the worst-case nput were nown. Other approaches measure the executon tmes of code segments, typcally of CFG basc blocs [19, 20]. The measured executon tmes are then combned and analyzed, usually by some form of bound calculaton, to produce WCET/CET estmates. Thus, measurement replaces the processor-behavour analyss common for the statc methods. Ths soluton would nclude all possble paths, but would stll produce unsafe results f the measured basc bloc tmes were unsafe or f only a subset of nput states (contexts) s consdered. Dynamc technques can measure executon-tme bounds for processors wth smple tmng behavour and and collect and analyze multple measurements to provde a pcture of the varablty of executon tmes. There are multple ways n whch measurement can be performed [20]. The smplest approach s by extra nstrumentaton code that collects a tmestamp or CPU cycle counter (avalable n most processors). Mxed HW/SW nstrumentaton technques requre external hardware to collect tmngs of lghtweght nstrumentaton code. Fully transparent (non-ntrusve) measurement mechansms are possble usng logc analyzers. lso hardware tracng mechansms le the NEXUS standard, ETM tracng mechansm n RM or DM nterface n Freescale products are non-ntrusve, but don t necessarly produce exact tmngs. Measurements can also be performed from the output of processor smulators or even VHDL smulators. Let the followng dynamc technques be descrbed n detal [14]: code tracng: specal trace nstructons are put to the code to capture the state of a system n the context of the actual code flow. g advantage of the approach can be seen n the smplcty: trace functons can be put to the code beng analyzed; so, no

5 cta Electrotechnca et Informatca, Vol. 12, No. 4, extra requrements are posed on the target smulator/platform (for lustraton, see Fg. 2a wth tracng nstructons INSTR 02 to INSTR 02 D). The analyss can be done over the smulated platform (f a smulator s avalable) or over the real platform. ut, the man dsadvantage of the approach mples from the fact each trace nstructon becomes a part of the code and thus, t surely mpacts the executon. code smulaton: a smulator wth ntegrated tracng or wth a support of trace ponts s requred to utlze the technque (see Fg. 2b). Man advantage of the technque can be seen n a full control over the dynamc analyss e.g., smulaton can be stopped for certan amount of tme n order to change parameters of the smulaton, trace program flow, read from or wrte to memory places (e.g., to change a context), let the smulator perform defned actons (the run tme value or context s stored nto a fle etc.) f certan condtons are met (e.g., f an address s accessed) etc. before the smulaton contnues. Rather than the real run tme, the logcal run tme (evaluated by the smulator accordng to nstructon flow, perpheral access tmes, nterrupt related latences etc.) s taen as a bass for all measurements. The bg dsadvantage of the technque can be seen n the fact t s practcally applcable only to systems, whch can be smulated n an authentc way. Durng experments related to the paper, such a smulator was avalable, so t was utlzed for the purpose Our Research: Motvaton and Goals On bass of the above-mentoned nformaton about actual T technques, especally followng can be concluded: T technque cannot be ndependent of the target platform, statc T technques are sutable to preprocess the hgh-level source-code, to detect basc programmng constructs n the code, to analyze the program flow and to produce bound estmates, dynamc T technques are sutable for measurement of bounds n the run/smulaton tme over the target platform, so the anomales can be elmnated and both safe and precse bounds can be produced, exstng T technques abstract from an RTOS model, so ther results are not drectly applcable for analyss of hgh-level RTOS parts such as queue management, nterrupt system, resources utlzaton, context-swtch overhead, stac utlzaton etc. However, the creaton of the schedulablty test formulas depends just on the hgh-level analyss f the RTOS model s reflected, the creaton can be automated. Otherwse, the formulas must be created manually. ecause exstng T technques dealng wth analyss of RT systems have focused to enumeraton of tas s C parameter only, we have decded to desgn a method, whch can be utlzed also for detal analyss of an RTOS tass are supposed to run on. Such nd of analyss s needed especally f schedulablty tests are to be derved for gven schedulng mechansms and target platforms. ecause the nd of analyss s not present n any of actual solutons, we have decded to present that the method can be constructed f mplementatonal detals related to partcular RTOS are nvolved n the analyss. To tae advantages of exstng statc and dynamc approaches, t was decded proposed T method wll be hybrd and wll be composed of a statc part used for code preprocessng and of a dynamc part used to measure bounds. For the purpose of dynamc analyss, code smulaton method was selected because t offers the most nformaton about the analyzed system and full control over the analyss. 3. PROPOSED METHOD In the secton, prncple of proposed T method bult over RTOS model extenson of a target archtecture smulator wll be descrbed Inputs and Outputs There are several nputs to the method: source-codes usually wrtten n a hgh-level language (e.g., C) of an applcaton to be analyzed. The code s necessary especally for an automated detecton of basc programmng constructs (f-then-else, swtchcase, for, whle etc.) annotatons,.e., nformaton about subjects of analyss and about types of analyss to be performed over the subjects, varable ntervals, loop bounds etc. The nformaton can be automatcally extracted from the source-codes or adjusted manually by a user. executable bnary fle,.e., a machne-level code that s supposed to be run on a target platform; typcally, the code s completed wth extra debuggng nformaton n order to offer more nformaton for further analyss purposes. On a bass of the code, behavor of the system can be smulated together wth the T done accordng to nformatons extracted from source codes and annotatons. fter analyss s completed, requested outputs (related to executon statstcs related to observed peces of code) are produced by the RangeProfler module (able to perform T of a code stored wthn partcular memory space) and the MultStacMontor module (able to perform analyss related to stac utlzaton durng run of the applcaton) see secton 4.4, page Prncple The below-mentoned steps desctbe prncple of the method n an llustratve way rather than presentng the method n an exhaustve form. Overall complexty of the method can be easly derved from the descrpton of the steps.

6 22 Reflectng RTOS Model Durng WCET Tmng nalyss: MSP430/FreeRTOS Case Study Fg. 2 Typcal approaches to dynamc tmng analyss: a) code tracng, b) code smulaton Step 1 Constructs detecton: efore T can start, basc programmng construct (e.g., f-then-else, swtch-case, for, whle, functon calls n C language) must be detected together wth basc blocs (the longest contnual sequences of nstructons wth no branches and cycles ncluded). The detecton can be done, e.g., on bass of a syntax-tree analyss. Step 2 Range proflng: fter the constructs are detected, T can be performed over the constructs. In the next, prncple of the analyss s outlned by means of typcal representatves of the constructs (let t be mentoned that the range proflng of the constructs s done n a recursve manner, so the followng lst of steps s to be get unordered rather than ordered the steps are performed f t s applcable durng the recurson process): 2 asc blocs: range profle s created for each basc bloc n a followng way: Start of the profle s specfed by an address of the frst nstructon wthn the bloc (proflng starts f PC s loaded wth the address) and end of the profle s specfed by an address followng after the address of the last nstructon n the bloc (proflng ends f PC s loaded wth the address,.e., the nstructon placed on the address s not nvolved n the analyss process). elow, the stuaton s lustrated so: s a basc bloc beng profled, s a basc bloc followng, s s executontme beng measured. 2 f and swtch constructs: Many varants of the constructs exsts, so creaton of profles wll be llustrated only over elementary f varant n order to show basc prncple. For f varant of the construct, at least two range profles are created (supposng both the condton and condtoned bloc are formed by a basc blocs): the frst one (used to measure executon tme of the condton tself) starts at an address the condtonal command starts (proflng starts f PC s loaded wth the address) and ends at an address the condtoned bloc starts (proflng ends f PC s loaded wth the address). The second one (used to measure executon tme of the condtoned bloc) starts at an address the condtoned bloc starts and ends at an address followng after the address of the last nstructon n the bloc. If the condton or the condtoned bloc are not formed of basc blocs, correspondng profle (used for or evaluaton) must be created by recurrent applcaton of rules formng step 2 of the method. le, profles for more complex f constructs (e.g., f-then-else) or swtch constructs can be created for llustraton, see the below-mentoned fgure. IF a) T3 IF ELSE b) T4 T3 SWITCH CSE: CSE: 2C for construct: The construct conssts of an ntal part, condton part, acton part and of a bloc to be executed durng each teraton of the cycle. ecause the contruct s more complex than the yet mentoned, let a creaton of range profles (at least 4 profles are needed) for a for cycle be llustrated by means of an example of a partcular cycle mplemented n vlstinsert functon wthn FreeRTOS nterface [6]: The ntal part (startng at 54be address) s executed just once, before the condton s enumerated frst tme. The condton (enumerated by cmp nstructon) starts at address 54cc and s followed by a jump to the condtoned bloc (nstructon jmp at 54d2 address) startng at 54d4, followed by an acton (f the condton was met) or to the end of cycle (.e., after the address followng the last nstructon of the cycle) -.e., to 54e0 (f the condton was not met). Jmp placed at 54de maes a jump to next teraton of c) T4

7 cta Electrotechnca et Informatca, Vol. 12, No. 4, the cycle. ll nstructons etc. are related to MSP430 famly of mcrocontrollers [17]. ;address nstructon ;(hex) opcode name operands operand addr. ; ;nt 54be: mov 2(r4), 4(r4) ;0x0002(r4), ;0x0004(r4) 54c2: c4: 1f mov 4(r4), r15 ;0x0004(r4) 54c8: 1f 4f mov 2(r15), r15 ;0x0002(r15) ;cond 54cc: a4 9f (r4) ;0x0006(r4) 54d0: jz $+4 ;abs 0x54d4 54d2: 06 3c jmp $+14 ;abs 0x54e0 ;condtoned bloc (body) ;act 54d4: 1f mov 4(r4), r15 ;0x0004(r4) 54d8: 94 4f mov 2(r15), 4(r4) ;0x0002(r15), ;0x0004(r4) 54dc: de: f2 3f jmp $-26 ;abs 0x54c4 54e0:... Followng the above-mentoned example llustratng structure of partcular for cycle, range profle related to for cycle can be ntutvely constructed as depcted n the followng fgure (n the fgure, both C-syntax representaton of the cycle (a) and compler-generated code of the cycle (b) are presented): represents executon tme needed for ntalzaton (nvolved only once), tme for condton enumeraton (nvolved before new teraton starts,.e., enumerated at least once), T3 tme needed for condtoned bloc and acton executon (nvolved each tmes condton s met). T4 tme needed for for ext f the condton s not met (nvolved after the last teraton s executed,.e., at least once). The fnal executon-tme of for construct equals to + + (T3 + ) + T4, where s an upper bound of cycle teratons. Problem wth enumeratng can arse, e.g., f depends on a value to be receved n the run tme from external sources or f the loop s nfnte. The frst problem can be solved by settng to the upper bound of an teraton-varable data type (whch can result to overestmaton of WCET and to problems related to selecton of proper target platform and schedulng mechansms), whle the second problem can solved by settng to a specal value (e.g., 1) used to ndcate nfnty of the loop. le n case of other types of constructs, f non-basc blocs are nvolved n the for-cycle declaraton, range profles must be created by recurrent applcaton of rules formng step 2 of the method. FOR ( INIT ; COND ; CT ) a) T4 INIT COND CT 2D whle constructs: Range profles for whle constructs are created n smlar way as those for for constructs, wth dame problems related to the profles. Followng tmes are avaluated by (at least 3) profles: condton enumeraton tme, condtoned bloc executon tme, T3 tme needed to ext the loop. The fnal executon-tme of whle construct equals to + +T3, where s an upper b) T3 bound of cycle teratons. le n case of other types of constructs, the number of profles can ncrease f non-basc blocs are nvolved n the cycle declaraton. In such a case, range profles must be created by recurrent applcaton of rules formng step 2 of the method. WHILE T3 a) DO WHILE 2E functon calls: s the last example, prncples related to creaton of range profles for functons and ther calls wll be presented. Each functon typcally conssts of 3 parts: a prologue, a body and an eplogue. Prologue and eplogue parts reflect the fact that certan overhead s needed f a functon s called (context storage durng functon call, argument-passng overhead, local-stac preparaton overhead, jump to functon body etc.) and after the functon s fnshed (stac-cleanup overhead, return-value storage, context recovery etc.). Thus, executon-tme related to functon call and executon of ts body s composed of at least followng 3 tmes:, (, T3),.e., tme needed for prologue (functon body, eplogue) executon. The fnal executontme related to fucton call and executon equals to + + T3. ut, ale n case of other types of constructs, the number of profles can ncrease f nonbasc blocs are nvolved n the prologue, eplogue or prologue of the functon. In such a case, range profles must be created by recurrent applcaton of rules formng step 2 of the method. F(...); T3 VOID F(...) The above-mentoned rules for creaton of range profles can be appled to any part of a code. s t can be nduced from the examples, tmes beng enumerated for one branch of the code are summarzed n order to get executon length of the branch. WCET of branched code equals to executon tme that s maxmal over the set of code branches. In Fg. 3, CFG related to vlstinsert functon mplemented n FreeRTOS s presented, completed wth executon tmes analyzed for partcular constructs used n the functon. In the CFG, followng symbols are utlzed: STRT (CFG start), (basc bloc), COND (enumeraton of a condton statement), FOR INIT (for ntalzaton), FOR COND, WHILE COND, DOWHILE COND (enumeraton of a condton for cycle constructs) END (CFG end). On the bass of the CFG and evaluton of ts nodes by means of executon tmes, the longest path (representng WCET of the functon) through the CFG can be found. The path s represented by edges drawn by contnuous lnes whle shorter paths are represented by dash lnes. b) T3

8 24 Reflectng RTOS Model Durng WCET Tmng nalyss: MSP430/FreeRTOS Case Study 4. CSE STUDY In order to demonstrate practcal applcablty of proposed method, we have decded to realze a set of experments over the real resources beng utlzed n practce: partcular RTOS (FreeRTOS [6]) runnng on partcular mcrocontroller (MSP430F168 [17]). In the next, basc nformaton about the resources s presented. lthough the experments are related only to MSP430F168, the method s genarally applcable to varous mplementatons based on MSP430 famly members. lso, the method s not lmted only to FreeRTOS f the profler s completed wth a model related to a dfferent RTOS, the results of the method can be utlzed to derve schedulablty tests for the RTOS FreeRTOS FreeRTOS [6] s smple, open-source RTOS desgned for mplementaton of embedded applcatons. It s wrtten manly n C, wth mnmum low-level code wrtten n assembly. Its ernel has modular structure and s confgurable by means of smple plan-text confguraton fle named FreeRTOSConfg.h. In the fle, parameters (preempton on/off, system tc frequency, number of prorty levels, mnmal stac sze for tass etc.) of the ernel requred for target applcaton can be setup n order to ensure requred performance and avalablty of requred OS servces and to prevent from wastng of computatonal resources by functonaltes unused n the applcaton. FreeR- TOS can be easly ported to many target platforms and ts ports can be utlzed for mplementaton of commercal (OpenRTOS) and safety-crtcal applcatons (SafeRTOS). Detal descrpton of FreeRTOS s out of scope ths paper and can be found n [6] let only followng nformaton related to FreeRTOS be presented: Followng schedulable enttes are supported: tass and co-routnes. The applcaton can be desgned usng tass, co-routnes, or a mxture of both. Tass and co-routnes dffer maly n a way they wor wth ther context: whle a tas executes wthn ts own context wth no concdental dependency on other tass wthn the system, co-routnes share a sngle stac, so there s no context-swtch overhead related to coroutnes. Multple tass can exsts wth the same prorty assgned. Tass of the same prorty are organzed n a double-lned lst. Co-routnes are organzed nto a double-lned lst common to all co-routnes. FreeRTOS scheduler s able to schedule tass and/or co-routnes n a preemptve or non-preemptve way. ut, t holds that CPU s always assgned to a tas/coroutne that has the hghest prorty among all ready tass and co-routnes. If preemptve mechansm s turned on, enttes stored n the same ready lst are scheduled usng a round-robn manner Target Platform: MSP430F168 Mcrocontroller MSP430F168 s a product of Texas Instruments company [17] and s desgned for constructon of extremely low-power applcatons. MSP430 s a lowendan archtecture and nvolves 16-bt RISC CPU, 16 regsters, 2 K RM and 48 K FLSH memory and many perpherals typcal for embedded applcatons (1 watchdog, 2 tmers, analog comparator, DM controller, 8-channel 12-bt DC and DC modules, 2 USRT modules, JTG nterface 6 general-purpose 8-bt nput/output ports etc.). On top of the common modules, there s one 16x16-bt hardware multpler mplemented n MSP430, whch operates n parallel wth the CPU. ecause nstructon set of MSP430 conssts of 27 fxedexecuton tme nstructons, there are no advanced components e.g., cache, branch predctors present n MSP430 s archtecture and an authentc MSP430 smulator wth ntegrated tracng and proflng support s avalable, MSP430 was evaluated as a sutable platform for testng our method Smulator: MSPsm MSPsm [13] s an open-source nstructon-set level MSP430 smulator wrtten n Java. s an nput, bnary fle n executable and lnable format (ELF) produced, e.g., by a C compler s taen. MSPsm can be easly extended to smulate varous perpherals, so t can be utlzed to smulate behavor of the whole platform based on MSP430. In MSPsm dstrbuton pacage, followng modules are smulated: CPU, basc cloc module, tmers, US- RT, GPIOs, hardware multpler, D modules, watchdog. The most mportant part of the smulator s a smulator core mplemented n MSP430Core class. There are several goals related to the core: t maes a connecton among basc components wthn MSP430 archtecture (memory, modules, perpherals etc.), t s used to nterpret nstructons and to computng logcal tme. Smulaton can be stopped, performed n sngle-step or contnuous mode. Speed of the smulaton can be set up by means of speed-up factor. There are many other functonaltes offered by orgnal MSPsm nterface (e.g., CPUMontor, Profler, SmEventLstener). From T pont of vew, especally followng s mplemented: nstruments for readng symbols and debuggng nformaton from ELF, access to CPU regsters, access to data stored n memory cells, watchponts used for detect an access to a partcular symbol, address or regster, stac trace used to access the stac, profler used to wor wth proflng data, breaponts used for debuggng or nstruments used to get MSP430 s state after an nstructon s smulated. However, for the purpose of RTOS tmng analyss, some mportant functonalty s mssng n the orgnal MSPsm 4, e.g., support for multtas systems and for modelng partcular operatng systems. Mssng the functonaltes maes analyss of certan system propertes (tmeanalyss related to tas context swtches, stacs, nterrupt- 4 of course, t s because the smulator was developped for dfferent purpose for smulaton of embedded sensor networ ES/Sy devces based on MSP430 runnng no operatng system

9 cta Electrotechnca et Informatca, Vol. 12, No. 4, STRT vlstinsert vod vlstinsert(xlst *pxlst, xlstitem *pxnewlstitem) (27) volatle xlstitem *pxiterator; porttctype xvalueofinserton; xvalueofinserton = pxnewlstitem->xitemvalue; COND (6) f (xvalueofinserton == portmx_dely) pxiterator = pxlst->xlstend.pxprevous; C C (11) D FOR INIT (7) else for (pxiterator = (xlstitem *) &(pxlst->xlstend); D pxiterator->pxnext->xitemvalue < xvalueofinserton; E E FOR COND (14) F (11) pxiterator = pxiterator->pxnext) F G (42) pxnewlstitem->pxnext = pxiterator->pxnext; pxnewlstitem->pxnext->pxprevous = (volatle xlstitem *) pxnewlstitem; pxnewlstitem->pxprevous = pxiterator; pxiterator->pxnext = (volatle xlstitem *) pxnewlstitem; G H COND (28) f ( (pxnewlstitem->pxnext!= &pxlst->xlstend) && (pxnewlstitem->xitemvalue == pxnewlstitem->pxnext->xitemvalue) ) H I (12) N (11) pxnewlstitem->pxroundrobn = pxnewlstitem->pxnext; I J FOR INIT (6) for (pxiterator = pxnewlstitem; J K FOR COND (13) pxiterator->pxnext->xitemvalue == xvalueofinserton; K L (11) M (11) pxiterator = pxiterator->pxnext) pxiterator->pxroundrobn = pxnewlstitem; L M else pxnewlstitem->pxroundrobn = pxnewlstitem; N O (14) pxnewlstitem->pvcontaner = (vod *) pxlst; (pxlst->uxnumberofitems)++; O P (8) P END Fg. 3 CFG of vlstinsert functon routne servces, queue management, shared resources etc.) dffcult. Thus, t was necessary to extend MSPsm frst n order to prepare t to expermental part of the wor. On top of t, the smulator was extended about necessary model of FITt platform [5] equpped wth MSP430 MCU, Xlnx Spartan3 FPG, 8x8Mbt DRM etc. selected for fnal mplementaton. In order to be correct, n Fg. 4 t s

10 26 Reflectng RTOS Model Durng WCET Tmng nalyss: MSP430/FreeRTOS Case Study Fg. 4 MSPsm extenson orgnal (whte boxes) and added parts (grey boxes) depcted whch parts wthn extended MSPsm archtecture are orgnal and whch ones were added to the archtecture for our purpose. Thus, t can be sad MSPsm was sgnfcantly extended to be utlzed for the T of RTOSes. Detal descrpton of the extensons s out of scope of the paper, but let at least the followng be mentoned: MultProfleControl and MultProfle classes mplement proflng functonaltes related to tas creaton, deleton, actual state, context-swtch etc..e., to varous functon calls n multtas envronment. Tracer, TracerControl and TracerControlFeedbac classes extend the functon-call related functonaltes about those related to generaton, redrecton and capture of events (assocated wth PC value, access to memory places, enablng/dsablng nterrupts, startng/extng nterrupt servce routnes etc.) and ther tme-stamps. Tracer, Profler and MultProfler nterfaces are mplemented by MultTracer class, whch also collect nformaton about catched events and dstrbute the nformaton to correspondng TraceLstener objects RTOS model over MSPsm model In our case, the nformaton can be send to an OSModel object mplementng model of partcular RTOS consstng of a tas model and a schedulng-polcy model; OSCommand s used to mplement a reacton to an event and/or to a RangeProfler object mplementng module for collectng statstcs about prevously specfed pece of a code 5. For the code, especally followng nformaton s collected automatcally by the object: a) how many tmes the code was executed, b) last (L), average () and the worst (W) executon tme of the code ncludng all latences le context swtches etc., c) same as b, but wth latences excluded, d) L//W number of nterrupts occured durng executon of the code etc Stac Montorng n Multtas Envronment esdes T, we have decded to enrch the MSPsm about dynamc montorng of local stacs belongng to partcular tass runnng n multtas envronment. Ths functonalty s mplemented n MultStacMontor for each tas wthn the system, followng nformaton s collected: a) stac start address, b) stac sze, c) actual and d) actual, mnmal and maxmal stac capacty occuped durng executon of the tas. The nformaton can contrbute to more precse analyss of memory requrements leadng to safe-stac desgn preventng stac to overflow/underflow n the run tme. 5. RESULTS SUMMRY In the secton, t wll be shown how results produced by proposed T method can be utlzed WCET Results There are many functons mplemented n FreeRTOS nterface, but presentaton of results related to all of them would occupy a lot of space of the paper. So, we have decded to present only subset of the results. ecause the most frequent operatons of an RTOS are those related to 5 The pece of code s specfed by means of addresses specfyng begnnng and end of the pece of code. The addresses can be got, e.g., from dssassembled executable or by means of lneaddr command of an extended MSPsm run over the source codes of the applcaton

11 cta Electrotechnca et Informatca, Vol. 12, No. 4, context-swtchng and schedulng polcy as well as operatons over lsts of tass and operatons over tass, t was decded subset of results related to representatves of the operatons wll be presented only. ecause the operatons can be easly deduced from ther names, descrptons of the operatons s spped n the followng text. Tme-complexty of the operatons s ntroduced as a functon of n (number of tass wthn an RT system) and m (number of tcs all tass were n suspended state,.e., tme measured between vtassuspendll and vtasresumell). In Tab. 1 the results are presented. In the tables, n represents the number of tass n the system whle m represents the number of OS tme tcs durng whch all tass were suspended Dervaton of Response-Tme ased Schedulablty Test On page 19, a formula (2) was presented llustratng how basc formula (1) can be extended n order to acheve more precse results durng response tme (R ) analyss of tass (τ ) from gven Γ to be scheduled on Φ by means of ξ,.e., RM mechansm Formula Modfcaton ccordng to FreeRTOS ecause the presented formulas abstract from the mplementaton of partcular RTOS, t s necessary to modfy them f response tmes are to be enumerated precsely accordng to a real mplementaton. E.g., f FreeRTOS s supposed as an mplementatonal RTOS then C sw related terms can be counted n C tc because each tc of FreeRTOStmer leads to a context-swtch. So, the formula (2) can be smplfed to the form: R +1 = C + + j hp() j alltass + J j + T tc T j + J j + T tc T j C j + (3) C queue + C tc T tc Furthermore n FreeRTOS tas perods (T s) can be set-up as multples of tmer-tc perods (T tc ). If the condton s met for all τ Γ, the formula can be yet smplfed to the form: R +1 = C + + C j + (4) T j hp() j R C queue + C tc +C tc +C yeld j alltass T j T tc fter the removal of correspondng terms, the end of the formula (4) was completed by term C tc +C yeld, whch reflects overhead needed for context-swtch before tas start and overhead needed for context-swtch after tas end for llustraton, see Fg T TICK Y TICK PRIO X X 1 2 Z w C TICK C YIELD Fg. 5 Illustraton to parameters for R enumeraton of FreeRTOS tass Enumeraton of Terms nvolved n the Formula If the formula (4) s to be utlzed n practce, partcular terms (.e., C, C j, T j,, C queue, C tc, T tc, C yeld ) nvolved n the formula must be enumerated frst. Some of the terms (C, C j, T j ) are related to partcular tass τ, τ j or reflect preempton overhead of a hgh-prorty tas τ by lower-prorty tass ( ) whle remanng (C queue, C tc, T tc, C yeld ) represent Γ-ndependent overheads gven by RTOS ernel mplementaton. elow, t wll be outlned how the values can be get: C (C j ) the values equal to WCET values of partcular tass τ (τ j ). In secton 3, t was shown how the values can be get by means of range profles created over programmng constructs wthn tass codes. fter the values are set, D (D j ) can be adjusted n such a way t holds C D (C j D j ), T j the value s set n such a way that t must hold D j T j, to be able to set up the value, nformaton about all lower-prorty tass,.e., l p() = τ j τ j s of lower prorty than τ τ, τ j access the same crtcal secton must be avalable together wth nformaton about tme for whch each τ j access the secton (for each such a resource and τ j, e.g., ex- 6 n the fgure, followng symbols are utlzed: X represents tme needed for executon of hgher-prorty tass, Y represents overheads related to tmer-tc,.e., context-swtch overhead and overhead related to placement of tass nto ready-queue, Z represents tme needed for executon of tass havng no mpact to executon of a tas beng observed because the tas s n a not-ready state

12 28 Reflectng RTOS Model Durng WCET Tmng nalyss: MSP430/FreeRTOS Case Study Table 1 WCETs for selected FreeRTOS calls FreeRTOS functon WCET (n CPU cycles) vlstintalse 71 vlstintalseitem 36 vlstinsertend 103 vlstinsert 49n vlstremove 21n vtasdelay 91mn n mn + 99m + 486n vtasdelayuntl 91mn n mn + 99m + 486n prvchecdelayedtass 91n n + 30 vtassuspend 63n vtasresume 70n vtassuspendll 30 xtasresumell 91mn n mn + 99m + 416n xtasistassuspended 100 portenter CRITICL 5 portexit CRITICL 15 vportyeld 230 prvddtastoreadyqueue 49n vtasswtchcontext 131 vtasincrementtc 91n n + 82 portsve CONTEXT 49 portrestore CONTEXT 41 ecuton tme between portenter CRITICL and portexit CRITICL calls must be measured executon tmes related to the calls can be found n Tab. 1 are to be nvolved n C of a callng tas). If the nformaton s avalable, s set to the maxmal access tme to the resources measured over l p(), C queue the value (49n + 151) equals to WCET of prvddtastoreadyqueue() functon call, whch can be found n Tab. 1 C tc the value s gven by mplementaton of FreeRTOS tc-servce routne. y default, the code of the routne s as follows: C yeld the value s constant (230) for gven FreeRTOS mplementaton and t can be found n Tab. 1 n vportyeld row. It was produced after analyss of correspondng routne: vod vportyeld( vod ) asm volatle ( "push r2" ); _DINT(); portsve_context(); vtasswtchcontext(); portrestore_context(); T tc nterrupt (TIMER0_VECTOR) prvtcisr( vod ) portsve_context(); vtasincrementtc(); vtasswtchcontext(); portrestore_context(); So, C tc equals to the sum of the WCETs of partal functon calls formng body of the routne. In Tab. 1, t can be found partal values are as follows: 49 (portsve CONTEXT()), 91n n + 82 (vtasincrementtc()), 131 (vtasswtchcontext()), 41 (portrest- ORE CONTEXT()). I.e., the sum s dependent on total number of tass runnng n FreeRTOS that s n n = 91n n + 303, the value represents FreeRTOS tmer perod specfed n the number of CPU cycles. So, the value can be enumerated by confgcpu CLOCK HZ (by default, set to ) and confgtick RTE HZ (by default, set to 100) parameters defned n FreeRTOSConfg.h. I.e., one FreeRTOS tc taes con fgcpu CLOCK HZ con f gt ICK RT E HZ = = CPU cycles, 6. CONCLUSION In the paper, novel hybrd method for tmng analyss of RT systems controlled by an RTOS was presented, wth descrptons manly related, but not lmted to WCET analyss. The same prncples can be utlzed for CET analyss f requred however, usually the nd of analyss s not necessary for RT systems, so the paper was focused only to the foremost. Novelty of the method les n the fact OS model s reflected durng the analyss. y the reflecton, more detal results about analyzed system can be produced than t s typcal for actual methods dealng only wth technques leadng to safe and precse enumeraton of WCET/CET values. ut, because they abstract from RTOS the system s supposed to run on, they cannot produce certan results valuable especally from practcal pont of vew, e.g., results related to nterrupt processng overheads, context-swtch overheads, management of tas queues, utlzaton of shared resources and stac etc. It was shown how the results can be utlzed for dervaton of a schedulablty test for RM schedulng mechansm. Practcal applcablty of the method was demonstrated usng MSP430 archtecture runnng RT system controlled by FreeRTOS.

13 cta Electrotechnca et Informatca, Vol. 12, No. 4, CKNOWLEDGEMENT Ths wor has been partally the Research Plan No. MSM (Securty-Orented Research n Informaton Technology), the UT FIT-S and the IT4Innovatons Centre of Excellence CZ.1.05/1.1.00/ projects. REFERENCES [1] CHENG,. M. K.: Real-Tme Systems, Schedulng, nalyss, and Verfcaton. John Wley & Sons, [2] COTTET, F. DELCROIX, J. KISER, C. MMMERI, Z.: Schedulng n Real-Tme Systems. John Wley & Sons, [3] ERMEDHL,. STPPERT, F. ENGLOM, J.: Clustered worst-case executon-tme calculaton. IEEE Transactons on Computers, 54(9): , [4] FIDGE, C. J.: Real-Tme Schedulablty Tests for Preemptve Multtasng. Real-Tme Systems, 14:61 93, [5] FITt: hardware/software co-desgn based educatonal platform. valable on: ccessed on March 29, [6] FreeRTOS.org project. valable on: ccessed on June 24, [7] HRDY, D. LESGE,. PUUT, I.: Scalable Fxed-Pont Free Instructon Cache nalyss. In: Proceedngs of the 32nd IEEE Real-Tme Systems Symposum (RTSS), IEEE CS, , [8] JOSEPH, M.: Real-tme Systems Specfcaton, Verfcaton and nalyss. Prentce Hall, [9] LPLNTE, P..: Real-Tme Systems Desgn and nalyss. John Wley & Sons, [10] LIU, C. L. LYLND, J.: Schedulng algorthms for multprogrammng n a hard real-tme envronment. Journal of the CM, 20(1):46 61, [11] LUNDQVIST, T. STENSTROM, P.: Tmng nomales n Dynamcally Scheduled Mcroprocessors. In Proceedngs of the 20th IEEE Real-Tme Systems Symposum (RTSS). pp , [12] LV, M. GUN, N. DENG, Q. YU, G. YI, W.: Statc worst-case executon tme analyss of the uc/os-ii real-tme ernel. Front. Comput. Sc. Chna, 4(1): 17 27, [13] MSPsm - a Java-based smulator of MSP430 sensor networ platforms. valable on: ccessed on June 5, [14] RJNOH, P.: nalyss of real-tme operatng system ernels runnng on FITt. Master s thess, Faculty of Informaton Technology, rno Unversty of Technology, rno, [15] SNDELL, D.: Evaluatng statc worst-case executon-tme analyss for a commercal real-tme operatng system. Master s thess, Mälardalen Unversty, Sweden, July [16] SNDELL, S. ERMEDHL,. GUSTFS- SON, J. et al.: Statc tmng analyss of real-tme operatng system code. In 1st Internatonal Symposum on Leveragng pplcatons of Formal Methods, [17] Texas Instruments. valable on: ccessed on June 10, [18] TINDELL, K. HNSSON, H.: Real tme systems and fxed prorty schedulng. Department of Computer Systems, Uppsala Unversty, [19] WENZEL, I. RIEDER,. KIRNER, R. PUSCHNER, P.: utomatc Tmng Model Generaton by CFG Parttonng and Model Checng. In Proceedngs of Desgn, utomaton and Test n Europe (DTE). Munch, pp , [20] WILHELM, R. ENGLOM, J. ERMEDHL,. et al.: The worst-case executon tme problem overvew of methods and survey of tools. CM Transactons on Embedded Computng Systems, 5(3):1 53, [21] ZOLD, M. KIRNER, R.: Compler Support for Measurement-based Tmng nalyss. Proceedngs of the 11th Internatonal Worshop on Worst-Case Executon Tme nalyss (WCET 11). OCG, 10 p., Receved prl 24, 2012, accepted December 17, 2012 IOGRPHIES Josef Strnadel receved the MSc. degree n computer scence and electrcal engneerng at the Faculty of Electrcal Engneerng and Computer Scence (FEE), rno Unversty of Technology (UT), Czech Republc, n 2000 and the PhD. degree n nformaton technology at the Faculty of Informaton Technology (FIT) of UT, n Now he wors as an assstant professor at FIT UT. Hs man research nterests are related to dependablty of embedded and real-tme systems. Peter Rajnoha receved the MSc. degree n nformaton technology at the Faculty of Informaton Technology (FIT), rno Unversty of Technology (UT), Czech Republc, n Hs man research nterests are related to mplementaton and analyss of operatng systems. Snce 2008, he wors n a development department of Redhat company and solves problems related to Lnux devce-mapper and correspondng subsystems.