Software dependability modeling using an industry-standard architecture description language

Sof tw are Dependabilit y Modelin g Using An Industr y-St andard A r chitect ure Descripti on Language Ana-Elena Rugina 1,* , Peter H. Feiler 2 , Karama Kanoun 1 and Mohamed Kaâniche 1 1: LAAS–CN RS, Univers ity of Toulouse, T oulouse (Franc e) 2: Software Engineering Institute, Carneg ie Mellon Un iversity, Pittsburg h, PA (U. S.A.) *: Contact a uthor, now with EADS ASTRI UM, Ana-Elen a.Rugina@a strium .eads.net, 31 Av. des Cosm onautes, 314 02 Toulous e cedex 4, Fr ance A b stract: Perform ing dependability evaluation along with other analyses at architectura l l evel allows both m aking architectur al tradeoff s and predicting the effects of ar chitectural decisions on the dependab ility of an appli cation. This pap er gives guidelines for build ing architectura l dependabilit y model s fo r sof tware s ystems using the AADL ( Architecture An a lysis and D esign Language). It presents reusable model ing patterns for fault-toleran t applicat ions and s hows how the presented patt erns can be used in the context of a subs ystem of a real-life applic ation. Keywords: AADL, fault tol erance, reuse, patterns 1. Introdu ction Modeling software architec tures has proved to be useful for promoting reuse and ev olution of large applications using extens ively com ponents-off - the-shelf (COTS). In addition, perf orm ing several analyses of qualit y attributes such as dependabilit y and perform ance on a c ommon architectural model is particularly interesting, as this allows m aking architec tural tradeoffs [1]. The AADL (Arch itecture Analysis and Design Language) [2] is a textual an d graphical language that provides precis e e xecution sem antics f or modeling the arch itecture of sof tware system s and their target pl atform . It h as rece ived a n increasing interest f rom the embedded safety- critical ind ustry (e.g., H oneywell, Rockwe ll Co llins, Lockheed Martin, the European Space Agency, Astrium, Airbus) during the last years. T he A ADL is characterized b y all the properties that an architecture description l an guage (ADL) should provide (com position, abstraction, reusabilit y, configurat ion, heterogene ity, anal ysis) [3]. In this paper , we f ocus on ar chitecture-b ased dependabilit y m odeling and evaluation using t he AADL. O ur work aim s a t helping engineers using the AADL for other purposes (e.g., f or perform ance analys es), to integr ate depen dability m odeling in their develo pment process. W e provide guidance on using the AADL language f or m odeling be haviors of f ault-tolerant software s ystem s, an d show t hat the deve lopment of pa tterns is ver y usef ul to facilitate the modeli ng of fault tolerance behavior and to enhance t he reusabilit y o f the m odels. W e define a fault tolerance pattern as a reusable model d escr ibing a fault tolerance strateg y at the architectur al l evel. To be used in a particular system , a pattern m ust be instantiated and custo mized if nec essary. The use of patterns an d, more generally, dependabilit y m odeling at a rchitectural level favors the reduct ion of recurr ent de pendabilit y m odeling work and the understandab ility of the dependabilit y m odel (thus r eflecting t he m odularity of the architect ure) [4] and allo ws the designer to reason about fault tolerance and t o assign exceptional behavior responsibilities among components [5]. At the sam e tim e, dependabilit y measures (i.e., availabilit y, reliabilit y, safety) can be evaluated based on the AADL model. T his al lows pr edicting t he eff ects o f particular architectur al decisions on the dependabilit y of the system [6] . Other a nalyses (e.g., r elated to perform ance) m ay be perform ed on th e sam e AADL m odel, which allo ws understandi ng the tradeoff between the b enefits of a certain fault tolerance pattern and its im pact on the applicat ion’s perf ormance [7]. From a practical po int of view, th e A ADL m odel must be t ransform ed into a stoc hastic m odel s uch as a Mark ov chain [8] or a Ge neralized Stochastic Petri net [9], t o obta in depen dabilit y m easur es such as reliabil ity, availabi lity, etc. In this paper we f ocus on t he u se of p atterns to facilitate the AADL m odel construction. The paper is organized as follows. Sectio n 2 surveys r elated work . Secti on 3 out lines t he m ain concepts of the AADL and its support for dependabilit y modelin g. Se ction 4 gives guidance, resulting f rom our experience, on bu ilding dependabilit y m odels for fault-tolerant sof tware system s using t he AADL. Section 5 prese nts AADL f ault t olerance patterns for three d uplex software system s ( i.e., d ual-redundant s ystems) , differing by their error detec tion m echanisms. Section 6 i llustrates the us e of patterns to m odel a real-life application and shows e xam ples of dependabilit y anal y s is res ults of interest f or software engine ers. Fina lly, concl usions and perspectives are presented in Section 7. 2. Related w ork Software archite cture m odeling f or dependabil ity analysis and ev aluation h as received a gro wing interest during the last two decades. Earl y approaches have f ocused on t he developm ent of analytical models to analyze the sensit ivity o f t he application r eliabilit y to t he sof tware structure a nd the relia bilities of its com ponents (see e.g., [ 10, 11] and th e sur vey presente d in [12]). More recently, the em ergence of com ponent-base d software engin eering appr oaches and architect ure description languages ( ADLs) led t o the proliferation of r esearch activities on sof tware architectures and methodologies allowing the analysis and evaluation of performance- and dependabilit y-related characteristics. Significant eff orts have been f ocus ed on the Un ified Modeling L anguage (UML) 1 . In particular, a number of recent papers consider the transform ation of UML specifications (enriched e.g., with timing constraints and dependab ilit y related inform ation) in to different types of analytical models (e.g., Petri nets [13 , 14], dynamic fault trees [15 ]) use d to obtain dependabilit y or perform ance m easures. 1 http://www.uml.org Besides UML, various ADLs have r ecentl y received increas ing attention fr om industry and academ ia. A c lassificat ion of s oftware architecture description languages inclu ding a cr itical an alysis of their modelin g c apabilit ies (i n p articu lar compared to UML) is pre sented in [16]. Am ong ADLs, the A ADL/MetaH 2 provides ad vanced support f or analyzing qualit y attributes . It also has substantial s upport for m odeling rec onfigurable architectures. These characteristics led to its serious consi deration in the em bedded saf ety- critical ind ustry [17]. The AADL a llows describing s eparate ly the analysis-relate d inf ormation t hat m ay be plugged into the ar chitectural model. T his feature enhances the reusa bility and the re adability of the AADL architectural m odel that c an be u sed as is for s everal anal yses (formal v erificat ion [18], scheduling an d mem ory requirem ents [19], resource allocat ion w ith t he O pen Source AADL Tool Environm ent (OSAT E) 3 , researc h of deadlock s and un-initialized v ariables with the Ocarina toolse t 4 ). The reusability of the AADL m odel is a lso enhanced by the u se of a set of fault t olerance patterns. The h ot stan dby r edundanc y pattern presented in [7] has been a source of inspiration for t he three patterns pre sented in this paper. The pattern presented in [7] aims at easing the understandi ng of the functional architecture by clearl y showing what is r eplicated a nd what t he active system components are. Our patterns additionall y include a cust omizable la yer of dependabilit y-related inf orma tion (error/f ailure and recover y beha vior) a nd of dynam ics necessar y fo r evaluating dependabil ity measures. The pro posed patterns c an b e us ed in the context of the iterat ive dependenc y-driven m odeling approach pres ented in [20]. Our work complements other existing initia tives that in vestigated the deve lopm ent of fault tolerance pa tterns b ased on o bject-orient ed approaches and UML ([21-23]) or other lang uages ([24]). 2 MetaH i s a prototype of t he A ADL developed by Honeywell under US G overnment s ponsorsh ip (DARPA and others) to prove the concept. 3 http://www .aadl.info/OpenSourceAADLTool Environment.html 4 http://ocarina.enst . fr 3. Ov erview of th e AADL langua ge In t he AADL, s ystem s are compos ite compone nts modeled as h ierarchical c ollections of int eracting application c ompone nts (pro cesses, threads, subprogram s, data) and a set of compute pla tform components (process ors, m em ory , bus es, devices). T he applicat ion com ponents are bound to th e c omp ute platf orm. Dynamic aspects of system architectur es are captured w ith the AAD L operational mode concept. Dif ferent operational modes of a sy stem or s ystem component represent different system configurations a nd connection topologi es, as well as d ifferent sets of propert y values. Each AADL s ystem component has t wo l e vels of description: the c omponent type an d the component impleme ntation . The component t ype describes how the environm ent sees that component (i.e., its proper ties and features). Examples of features are in and o ut ports that represent directiona l ac cess points to the component. T he AADL d efines three t ypes of ports: e vent, data, and event data (m odeling respectivel y flows of contr ol, data, and control an d data). O ne or m ore component implem entations can be associated with the same component t ype, match ing diff erent c omponent i m plementation structures in terms of subcom ponents, connections and o peration al mo des. An A ADL arc hitectura l m odel can be annotate d with dependability-related i nform ation (s uch as faults, failure m odes and repair ac tions, error propagation, etc.) thro ugh the stand ardized Error Model A nnex [25]. AADL error models allow modeling com plex and realistic c om ponents’ behaviors i n t he presence of faults, as shown in [26]. G eneric error m odels are def ined in l ibraries and are as sociated with a pplication com ponents, compute pla tform components, as well as the connections between them . W hen a generic error model is ass ociated with a com ponent, it can be custom ized if necessar y by setting compo nent- specific values for t he arrival rate or the probabilit y of occ urrence f or error events and error propagat ions declared in the error m odel. Error m odels consist of two parts: the err or model type an d the err or model implementation . The error m odel t ype declar es a set of error states , error events (inherent t o the com ponent) and error propagations 5 . These items c an be 5 Note that error states can model error-free states, error events can model repair events a nd error custom ized when the error m odel is associated with a specific com ponent. Occurrence proper ties specif y the arri val rate or t he occurre nce probabilit y of events an d propagations. T he error m odel implem entation declares error transitions between states, triggered b y events and propagatio ns declared in the e rror m odel type. Figure 1 shows an error m odel of a component that may f ail and that is restarted to regain its error f ree state. The com ponent cannot be influenced b y propagations c oming from its environme nt, as it d oes not dec lare in propagat ions. An out pr opagation is us ed to indicate notification o f dependent com ponents when the com ponent f ails.     error model independent features Error_Fre e: initial error stat e ; Failed: e rror state ; Fail: err or event { Occurrence => poisson λ }; Restart: error event { Occurrence => poisson µ }; FailedVis ible: out error propa gation { Occurrence => fixed p}; end indepen dent;             error model implementation independent .general transitions Error_Fre e-[Fail]->Failed; Failed-[R estart]->Error_Free; Failed-[ o ut FailedVisible]->Fa iled; end indepen dent.general; Figure 1. Tw o-state error model Interactions bet ween the e rror mo dels of dif ferent components are determ ined b y i nteractions between components of t he architectural m odel through connec tions and bindings. F or ex ample, if a component has an outgoing port conn ection to another com ponent, th en its out pr opagatio n f or that p ort g ets m apped to the nam e-m atching in propagat ion declared in the err or model of t he receiving component. In some cases , it is propagations can m odel all kinds of notifications. In this paper we refer to error states , error events , error propagations and error transitions without the qual ifying term error in contexts where the meaning is unambiguous. desirable to m odel how erro r propa gations f rom multiple sourc es are handl ed. This is m odeled b y specif ying filters and mask ing conditions for propagations, using Guard properties associated with features. T he interest ed reader can refer to [26] fo r an extensi ve l ist of gen eric r eusable error models and Guard properti es. 4. Guidelines for modeling dependabilit y In ord er to analyze t he dependab ility of an application at architectura l level, it is nec essary t o enrich the architectural model with dependabilit y- related information relevant to the targeted meas ure(s). Gener ally, dependa bility m odels include f ault ass umptions, stochastic param eters for the s ystem, description o f recovery and f ault tolerance mechanism s, and characterist ics of phases in a p hased-m ission s ystem. An AADL user describes a s ystem’s architecture in the AADL an d annotat es t his arc hitectural m odel with error m odels containing releva nt depend ability- related inform ation. Section 4.1 discusses the role of AADL operational modes and mode transitions. Section 4.2 disc usses the use of operationa l m odes versus err or s tates. Sec tion 4.3 pre sents mechanism s f or r epresenting t he logic connect ing error states to operational mode s. 4.1. W hat operational modes are good f or An operatio nal mo de 6 is an operatio nal state of an AADL com ponent. Exactly one m ode is the ini t ial mode. A component is in one m ode at a ti m e. Mode t ransitions model d ynamic operational behavior, i.e., switch ing between conf igurations of subcom ponents an d c onnections. Mo de-specific propert y values characteri ze qualit y attributes for each operatio nal mode. A mode transition m ay b e triggered by: (1) a n out (or in out ) event port of a subcom ponent of the com ponent declar ing the modes; (2) an in ( or in out) event port of the component itse lf; (3) a loc al event port 7 . A m ode transition is tr iggered by an y event that arrives thro ugh t he port nam ed in the m ode transition. A mode transition m a y list multiple event ports as its trigger c ondition. In such a case, an event through any of the ports triggers the transition (an or log ic is assu med). For 6 We will further refer to op erational modes simply a s modes. 7 The errata docu ment to th e AADL s tandard pro vides the ability t o declare such local ports, representing a call to a pre-declared Raise_Even t subprogram in a thread. dependabilit y analyses, more advanced event- based m ode transition condit ions (reflecting e.g. voting prot ocols) c an be s pecified through Guard_Event an d Guard_Transition pr operties, as pres ented in Section 4 .3. T he s tate m achine form ed b y modes and m ode transitions in a system o r sy stem c omponent im plementation m ust be deterministic. 4.2. Operati onal modes vs. error states Modes of operati on in p has ed-m ission s y stem s, as well as fault-t olerant configur ations are m odeled by AADL m odes. Operational modes in phased-miss ion systems m odel configurations representat ive of different phases i n a mission. F or exam ple, in the case of an aircr aft m odel, one m ay dist inguish b etween the tak eoff, c ruise and landing phases . During each phases , the system would have a particular configurat ion with active components and connections . Also, diff erent types of faults m ay aff ect the system in different phases. Mode-specific fault-tolerant s ystem c onfigurati ons reflect the fault tolerance st rategy chosen for the system or f or particular par ts of the system . For exam ple, a f ault-tolerant system form ed of three components ma y have a nom inal o perationa l m ode corresponding to a tripl e-redundanc y configurat ion and anoth er degrad ed op erational m ode corresponding to a d uplex conf iguration. Usually, p hased-m ission systems also need m odes to repres ent fault t olerance m echanism s. In the AADL, this nesting o f m odes is captured by phased-m ission modes in a compon ent, which is a s ubcompo nent of a syst em c omponent whose m odes represent alternati ve co nfiguration of its redundant s ubcomp onents. The diff erence bet ween m odes and error states lies prim arily i n th eir sem antics. Error states r esult from occurrences of err or events (faults, re pair events) while m odes represent operation al states of the s ystem that ma y be totally independe nt of the occurrence of error ev ents. 4.3. Connec ting error states to m odes The AADL a llo ws us t o m odel logica l error sta tes separate of the operat ional m ode of the runni ng application. It a lso a llows c onnecting logical error states and op erational m odes by translating logical err or s tates into actions (under the f orm of architectura l events) o n the r unning s ystem through Guard_Event prop erties. Guard_Event properties map error state c onfigurati ons into architectural events that are sent through ports and t hus may affect the behavior of r eceiving components by trigger ing m ode t ransitions. An architectural e vent arriving through a port will uncondition ally trigger a m ode transition. Sometim es o ne m a y need to constrai n a m ode transition in a s ystem component to re flect specific conditions s uch a s a voting p rot ocol to decide on fault han dling. This c an be ach ieved through the use of Guard_Transition p roperties associated with m ode transitions an d specif ying mode transition logic expr essions overriding the default or cond ition o n events arriving t hrough ports name d in the mode tran sition. Guard_Event and Guard_Transition pr operties can be used a s a dvanced dec ision m echanism s that drive reconf iguration stra tegies. 5. Fault to lerance pattern s In th is se ction, we cons ider a f ault-tolerant du plex system that uses the hot standb y r edundanc y scheme. W e present succ essively, in sections 5.1, 5.2 and 5.3, patterns f or three arc hitectural implem entations of this system . Section 5.4 gives concluding rem ark s. Each of the three models contains t wo ident ical active com ponents, Comp 1 and C omp2 , m odeled as threads. Both t hreads proces s the event and data inp ut stream r eceived b y the redu ndant system through th e port sys Input but on ly one component’s output is m ade visi ble as output of the redu ndant s ystem through the out event data port sy s O utput . The three patterns dif fer in t erms of their error detec tion m echanisms , as follows. The f irst pattern m odels the error d etection by intermediate ch eckpoints bet ween the t wo components. The direction of the data f low is fr om the p rimar y com ponent to the one th at is i n standby. T he redundan t system has tw o operational modes, one in w hich Comp1 is the primar y and another one in which Co mp2 is the primar y. The component i n standb y monitors the check points sent by t he pri mary a nd dec ides t o take over and change the o perational m ode of the system , if it detects a failur e. In the s econd pattern, the error detection is achieved b y a separate m onitoring and c ontrol component, Controller . T he outp uts of both ac tive components are co nnected t o the o utput of the system , sy sOutput , but onl y on e component provides the outp ut at a give n instant in tim e. This is mo deled b y t wo m odes as sociated w ith eac h active c omp onent. On ly th e c omponent in m ode primary sends data to the output of the s ys t em . The Control ler initiates th e m ode transitions. The third pattern m odels erro r detection by m utual observation of out puts. The outputs of both active components are c onnected to the output of the system . Each of the two active components m onitors the output of its sibling and deci des whether to pr ovide the o utput or not. In th e f irst p attern (dete ction b y i ntermed iate check points), m odes ar e represented at the system ’s level. In the two ot her patterns, m odes are represe nted at the com ponent le vel. Each of the three patterns is formed o f an AADL architectura l mo del an d of error m odel a nnex subclauses t hat assoc iate the d ependabilit y- related inform ation to th e com ponents of the architectura l m odel. T hese subclauses m ay be further ref ined during the developm ent cycle to detail the interna l behav ior of com ponents a nd component-s pecific occ urrence of pr opagations. 5.1. Detection by interm ediate check points Figure 2 sho ws t h e AADL ar chitectural model for this s ystem implem entation, using t h e AADL graphical n otation. Figure 2: Det ection b y checkpoints (graph ical) The sys tem ha s two op erational modes. In mode Comp1Pri mary , Comp1 ’s output is m ade visible as out put of the s ystem . In m ode Comp 2Primary , Comp2 ’s o utput is m ade visible as o utput of the system . T hus, the connection f rom Comp1 to the out event data port sys Output of the system is active in mode Co mp1Primary while the connection fr om Comp2 to the out event dat a port sys O u tput of the system is active in m ode Comp2Pri mary. Based on the i nput from the other c om ponent an d on its own st ate, a com ponent in st andb y c an decide to take ov er b y i nitiating a m ode transit ion. Thus, the t ransition from Comp1Primary to Comp2Primary is triggere d b y the out event port IAmPrim of Comp2 . If both com ponents fail success ively a nd if their failur es are detect able, the first one res tarted beco mes the primary . For this pattern , we s how the com plete AADL architectural model of the system and th e error model an nex subclause associated wit h its components in F igure 3. thread soft ware features Snd: out data port ; Receive: in data port ; Input: in event data port ; Output: o ut event data port ; IAmPrim: out event port ; end softwar e; thread impl ementation software.gen eric annex Error _Model {** Model => in dependent.general; Guard_Event => (Receive[Fa iledVisible] and self [E rror_Free]) applie s to IAmPrim; **}; end softwar e.generic; system HotS tandBy features sysInput: in event data port ; sysOutput : out event data port ; end HotStan dBy; system impl ementation HotStandBy.c heckpoints subcomponen ts Comp1: th read software.generic; Comp2: th read software.generic; connections data port Comp1.Snd->Comp2.Recei ve in modes Co mp1Primary; data port Comp2.Snd->Comp1.Recei ve in modes Co mp2Primary; event dat a port sysInput->Comp1. Input; event dat a port sysInput->Comp2. Input; event dat a port Comp1.Output->sy sOutput in modes Co mp1Primary; event dat a port Comp2.Output->sy sOutput in modes Co mp2Primary; modes Comp1Prim ary: initial mode ; Comp2Prim ary: mode ; Comp1Prim ary -[Comp2.IAmPrim]->C omp2Primary; Comp2Prim ary -[Comp1.IAmPrim]->C omp1Primary; end HotStan dBy.checkpoints; Figure 3. Detection by check points (textual) The threads h a ve t he same c omponent type a nd implem entation, g iven i n the upper part of Figure 3. T he lower part shows the com ponent type and im plementation of the s ystem. Guard_Event p r operties specify th e mode switching c onditions. T he system m ust switch from Comp1Primary to Comp2Pr imary when Comp2 detect s the fai lure of Comp1 or when bo th components failed a nd Co mp2 was res tarted fi rst (i.e., Co mp2 is Error_Fr ee and Co mp1 sen ds t he out propagation FailedVisible ). 5.2. Detection by a separ ate controller The s y stem m odeled in Fi gure 4 c ons ists of two identical act ive threads ( Comp1 a nd Comp 2 ) and one controller co mponent ( Controller ) . Each of the active com ponents can be in one of two m odes: primary an d standby . W hen a component is in pr imary m ode, it provides the service expected f rom the redundan t s ystem. The Controller m onitors th e t wo c omponents. If it detects the fail ure of the one in primary m ode, it initiates a mode switch in each component, so that the one that is Erro r_Free c ontinues to provide th e s ervice. Also, if it detects the f ailure of both c ompon ents, it waits until o ne of them becom es o peratio nal an d o r ders it to go t o primary m ode. Figure 4: S eparate contro ller (graphic al) Figure 5 s ho ws the textual A ADL architectural m odels and err or m odel annex su bcla uses of the component that i s init ially i n primary m ode (upper part of t he f igure) and o f th e controller (lo wer part of the f igure). thread soft ware features InStandby : in event port ; BePrim: i n event port ; Input: in event data port ; Output: o ut event data port ; toControl ler: out event port ; end softwar e; thread impl ementation software.pri mary modes primary: initial mode; standby: mode; primary-[ InStandBy]->standby; standby-[ BePrim]->primary; annex Error _Model {** Model => in dependent.general; Occurrence => fixed 0.9 applies to e rror FailedVisible; Occurrence => poisson 1e-3 applies to error Fail; **}; end softwar e.primary; system cont roller features fromC1, f romC2: in event port ; Prim1, Pr im2: out event port ; end control ler; system impl ementation controller.g eneric annex Error _Model {** Model => in dependent.general; Occurrence => poisson 1e-6 applies to error Fail; Guard_Event => fromC1[F ailedVisible] and fromC2[E rror_Free] and self [Err or_Free] applies to Prim2; Guard_Event => fromC2[F ailedVisible] and fromC1[E rror_Free] and self [Err or_Free] applies to Prim1; **}; end control ler.generic; Figure 5. Separat e contro ller (textual) 5.3. Detection by mutual obser vation Figure 6 shows t he arc hitectural m odel of this system . Each of the t wo a ctive com ponents can be in on e of these three m odes: pr imary , standby and r eboot . Initially, one c omponent is in primary mode while the other one is in standby . W hen a component is in pr imary m ode, it pr ovides th e service expected f rom the redundant s ystem. The two c om ponents obser ve each ot her’s outpu ts. Based on th ese ob servations and on its own state, each com ponent dec ides whether i t m ust be t he s ender of output. W hen a f ailure occur s in a c omponent, t he com ponent goes to r eboot m ode. If the failed component was in p rimary m ode, the other com ponent should tak e over so that the servic e ex pect ed continues to be provided. If both components fail one af ter the other, the fir st one restarted becomes the primary . In the two previous p atterns, t he m ode tra nsitions of a co m ponent or system are co ntrolled b y its subcom ponents or by a separate c ontrol ler. In t his pattern, we use self -managing com ponents that control their own m ode transitions. This is m odeled by local event ports ( represented as dotted ovals) triggering the m ode transitions. Figure 6. Mutu al observati on (graphic al) The two com ponents’ arc hitectural m odels are identical except f or their initial m odes, i .e., on e is initiall y in primary mode while the other one is in standby m ode. T hus, F igure 7 shows on ly t he textual AADL architectural mo del of the component th at i s init ially in primary m ode and its assoc iated error m odel annex subclause . In Figure 7, Guard_Event properties are assoc iated w i th all internal ports (expresse d by self .ev entname ) n am ed in m ode transitions. For exam ple, the first declared Guard_Event propert y specif ies that t he component moves to reboot m ode when it fails. 5.4. Concludi ng rem arks In sections 5.1, 5. 2 and 5.3, we ass ume that all components ( C omp1 , Comp2 , C ontroller ) have the s ame behavior in the prese nce of f aults (represente d by the error m odel of Figure 1). More c omplex behavior can be considered f or each c omponent, by cus tom izing the patterns. This is achieved by c hanging the Model propert y in the error m odel a n nex subclause associate d with a particu lar com ponent. Other patterns, m odeling different fault tolerance schemes and i mpacting th e dependabilit y of the system , are presented in [26]. thread soft ware features Input: in event data port ; Output: o ut event data port ; fromRepli ca: in event data port ; end softwar e; thread impl ementation software.pri mary modes primary: initial mode; standby, reboot: mode ; primary-[ self .IFailed]->reboot; standby-[ self .IFailed]->reboot; reboot-[ s elf .IPrim]->primary; reboot-[ s elf .IStandby]->standby; standby-[ self .IPrim]->primary; annex Error _Model {** Model => ind ependent.general; Occurrence = > fixed 0.9 applies t o error FailedVisib le; Guard_Event => self [Failed] applies t o self .IFailed; Guard_Event => fromReplica[ FailedVisible] and self [Error _Free] applies t o self .IPrim; Guard_Event => fromReplica[ Error_Free] and self [Error_Fr ee] applies t o self .IStandby; **}; end softwar e.primary; Figure 7. Mutual observatio n (textual) 6. Application example W e i llustrat e the use of AADL architec tural patterns for de pendabilit y analyses on a saf ety- critical s ubsystem of t he French Air T raffic Control System. This s ystem has been studied in [27] using genera lized s tochastic Petri n ets (G SPN) for com paring c andidate architecture so lutions, with r espec t to a vailability. The contribution of this paper is to sho w how to m odel i t us ing the AADL fault tolerance pa tterns. The subs ystem is formed of two fault-t olerant distributed software u nits that are i n charg e of processing respec tively f light pla ns ( FPunit) a nd radar d ata (RDunit). Two processors can host these units. T he subsystem must be highly available. W e c onsider two cand idate arc hitectures for this subs y s tem, refe rred to a s Configuration1 and Configuration2 . Both of them use two proces sors. The two com ponents of eac h fault-toleran t subs y s tem are bound to separate processors. The dif ference between the two configuration s lies only i n the bindings of RDun it thr eads to process ors. In Configuration1 , the thread th at initiall y delivers t he s ervice ( C omp1 ) is bound to Processor2 while Com p2 is bound to Processor1 . In Co nfiguration 2 , the bindings are the oth er w a y round (i.e., C omp1 is bound to Processor 1 while Comp2 is bound to Proces sor2 ). The thread that delivers the s ervice in the FPunit exchan ges data with the RDunit. Con nections between threads bound to separat e processors are boun d to a bus whose failur e causes the f ailure of the R Dunit. Figure 8 pr esents both c andidate architectures using t he A ADL grap hical notation. For t he s ake of clarity, we show the t hread bindi ng configurat ions in Figure 8-a and the bus and the connection bind ings t o the bus in Figu re 8- b. W e assum e that t he error detection is achieved through interm ediate chec kpoints (patt ern 5.1). The m odeling ef fort is l im ited. W e need to instantiate t he chosen pa tter n, to connect togeth er the two instances a nd to bind the threads to process ors. Besi des t hese rather s im ple actions, we nee d to associat e an error model annex subclause with the bus connecting the t wo process ors. The er ror m odel annex subcla uses m ay be f urther customized, to cons ider particular reconfigurat ion strategies . The AADL m odels of the two candidate architectures pres ented in Figur e 8 are transfo rmed into GSPN that are no t sho wn in this paper d ue to space lim itations ( see [9] for details about the tra nsform ation process ). Figure 9 g ives, as an example of resu lt obtained from the GSPN process ing, the unavailabi lity of the t wo cand idate architectures. The varying param eter λ c is the occurrenc e rate of a bus failure. λ c  10 -6 /h corresponds to a red undant bus. For Configuration1 , t he impact of this par ameter is impor tant wh en λ c  10 -5 /h. Configur ation2 is m uch less inf luenced by λ c , as in Nomi nal m ode, the comm unication bet ween th e two u nits does not go through the bus. Fro m a pra ctical p oint of view, if λ c  10 -5 /h, Configuration2 is recommended. Otherwise the t wo candidate arch itectures are equivalent, f rom the availability viewpoin t. (a) (b) Figure 8: Mod els of Air T raffic Control System candidate architec tures Figure 9: Unavaila bility 7. Conclusion Performing several dependabilit y and performanc e-related analyses on a s am e architectural m odel is particularl y interesting for software e ngineers as having qualitative an d quantitative in f orm ation about a candidate architecture allo ws mak ing architectura l tradeoffs . The AADL (Arch itecture Analysis and Design Language) is a m ature indus try-standard well suited to add ress qualit y attr ibutes. T his p aper illustrated i ts use for d ependabi lity m odeling of fault-tolerant systems . Model reusa bilit y is an essential issue in the c ontext of com plex safet y - critical evolvable applic ations. W e presented patterns f or m odeling f ault-tolerant a pplications and w e s howed tha t the y enhance the reus abilit y and the un derstandab ility of the model. Finall y, we showed a pattern- based example used for evaluating the availability of t wo candidate architectures f or a subs ystem of the French Air Traffic Control System . Future extensions of this work include the construction of a librar y of AADL architect ural patterns, an d of er ror models to e xpress comm on dependencies in dependable applic ations (i.e., restoration a nd reconf iguration strateg ies). 8. Acknow ledgements This work results from a cooperation between LAAS-CNRS and th e Software Engineeri ng Institute ( SEI), initiated during the visit of Ana- Elena Rugina at the SEI. It has been p artially financed by the ReSIST Network of E xc ellence (Resilience for Surviva bility in I ST, IST -26764) and the Euro pean Socia l Fund.                9. References [1] R. Kazman, et al., "Experience with Perfo rming Architecture T radeoff Analy s is," 21st Int. Co nf. on Software Engineering Los Angel es, CA, USA, 1999. [2] SAE-AS5506, "SAE Architecture Analysis and Design La nguage (AADL)," International S ociety of Automotive Engineers, Warrenda le, PA, USA November 2004. [3] M. Sh aw and D. Ga rlan, "Charac teristics of Higher-Level Languages for Sof tware Architecture," Carnegie Mellon Unive rsity Tech nical Report CMU-CS- 94-210, 1994. [4] J.-C. Laprie and K. Kanoun, "Handbook of Software Reliability and S ystem Reliability," in Software Reliability Engineering , M. R. Lyu, Ed.: Co mputing McGraw-Hill, 1996, pp. 27-69. [5] R. de Lemos, "Idealised Fault Tolerant Architectural Element," Int. Con f . on Depen da ble Systems and Networks, Work shop on Architecting Dependable Systems, Philadelph ia, PA, USA, 2006. [6] M. H . Klein, et a l., "Att ribute-Based Architecture Styles," 1st W orking IFIP Conf. on Soft ware Architecture, San Antonio, TX, USA, 199 9. [7] P. H . Feiler, et al., "Pa ttern-Based Analysis of an Embedded Real-time System Architecture," 18th IFIP W orld C omputer Congress, ADL W orkshop, Toulouse, France, 2004. [8] P. Binns a nd S. Vestal, "F ormalizing Soft ware Architectures fo r Embedded S ystems," 1st Int. W ork sho p on Embed ded Software, Tahoe City, CA, USA, 2001. [9] A. E . Ru gina, K. Kano un, and M . Kaâniche, "A System Dependabiliy Modeling Framewor k using AADL and GSPNs," in A rc hitecting De pendable Systems 4th Volume , R. de Lemos, C . Gac ek, and A. Romanovsky, Eds.: Springer-Verlag, 2007. [10] J .-C. Laprie, et al., "Architectu ral Iss ues i n Software Fault Tolerance," in Software Fault Tolerance , M. R. Lyu, E d. : J ohn W iley &Sons Ltd., 1995, p p. 47- 80. [11] J . Becht a Dugan and M. R. Lyu, " Dependability Modeling for Faul t-Tolerant Software and Systems," in Software Fault Tolerance , M. R. Lyu, Ed.: J ohn W iley & Sons Ltd., 1995, pp. 47-80. [12] K . Goseva Popstojanova and K. Trivedi, "Architecture-based Ap proach to Reliability Assess ment of Software Systems," Per for mance Evaluation , vol. 45, pp. 179-204, 2001. [13] A . Bond avalli, et al., "Dependability Analysis in the Early Phas es of UML B ased System Des ign," In t. Journal of Computer Systems - Scien ce & Engineering , vol. 16, pp. 265-275, 2001. [14] S . Bern ardi, S. Donatelli, and J. Mersegue r, "From UML Sequence Diagrams and Statecharts to Analysable Petri Net M odels," 3rd Int. Workshop on Software and Performance, Rome, Italy, 2002. [15] G. J. Pa i and J. Bec hta Duga n, "Automatic Synthesis of D ynamic F ault Tree s from UML System Mod els," 13th Int. Sym pos ium on Sof tware Reliability Engineering, Annapolis, USA, 2002. [16] N. Medvidovic and R. N. Taylor, "A classification and comparison framework for Softwa re Architecture Description La nguages," IEEE Trans actions on Soft w are Engineering , vol. 26, pp. 7 0-93, 2000. [17] J.-P. Bla nquart, A. Rossignol, and D. Thomas, "Toward Model-Based Engineering for Space Embedded Systems a nd S oftware," 3rd European Congress on Embedded Real Time Soft ware, Toulouse, France , 2006. [18] J.-M. Farines, et al., "The Cotre project: rigorous softwa re development f or real time s ystems in avionics," 27t h IFAC/IFIP/IEEE Workshop on Real Time Programming, Zielona G ora, Poland, 2003. [19] F. Sin ghoff, et al., " Scheduling and M emory Requirements Analysis with AADL," SI G Ada Int. Co nf . on Ada, Atlanta , GE, USA, 2005. [20] A. E . Rugina, K. Kanoun, and M. Kaâniche, "An Architecture-base d De pen dabili t y Modeling Framewo rk using AADL," 10th IASTED Int. Conf. on Software Engineering and Ap plications, Dal las, U.S.A., 2006. [21] N. Is lam and M . Devarakonda , "An Es sential Design Pattern for Fault-Tolerant Distributed State Sharing," Communications of the ACM , vol. 39, pp. 65- 74, 1996. [22] M. Tichy, D . Schilling, and H. G iese, "Design of Self-Managin g Dependable Systems with UML and Fault To lerance Patterns," Workshop on Self-healing Systems, 1st S IGSOFT W orkshop on Se lf-managed Systems, Newp ort Beach, CA, USA, 2004. [23] D. M. Beder, et a l., " An Application of Fault Toleranc e Patterns and Co ordinated Atomic Actions t o a Prob lem in Railway Scheduling," ACM SIGO PS Ope rating Systems Review , vol. 34, pp. 21-31, 2000. [24] C. K ehren, et al., "Architecture Patterns for Safe Design," presented at In t. Complex and Saf e S ystems Engineering, Arcachon, France, 2004. [25] SAE-AS5506/1, "SAE Architecture Analysis and Design Language (AADL) Annex Volume 1, Annex E: Error Mo del Annex," International Society of Automotive Engineers, War rendale, PA 2004. [26] P. H . Feiler a nd A . E. Rugina, "Dependa bility Mod eling with t he Architecture Analysis and Des ign Language ," Carnegie Mell on Soft ware Engineer ing Institute, Pittsburgh, PA, US A CMU /SEI-2006-TN-035, 2006. [27] K. Kanoun, et al., "Avail abil ity o f CAUTRA, a Subse t of the French Air Traffic Con trol S ystem," IEEE Transact ions on Computers , v ol. 48, pp . 528-535, 1999.