Using Architectural Properties to Model and Measure Graceful Degradation

. System-wide graceful degradation may be a viable approach to improving dependability in computer systems. In order to evaluate and improve system-wide graceful degradation we present a system model that will explicitly define graceful degradation as a system property, and measure how well a system gracefully degrades in the presence of multiple combinations of component failures. The system’s software architecture plays a major role in this model, because the interface and component specifications embody the architecture’s abstraction principle. We use the architecture to group components into subsystems that enable reasoning about overall system utility. We apply this model to an extensive example of a distributed embedded control system architecture to specify the relative utility of all valid system configurations. We then simulate working system configurations and compare their ability to provide functionality to the utility measures predicted by our model.


Introduction
De pend abil ity is a term that cov ers many sys tem prop er ties such as re li abil ity, avail abil ity, safety, main tain abil ity, and se cu rity [1].Sys tem de pend abil ity is es pe cially im por tant for em bed ded com puter con trol sys tems, which per vade ev ery day life and can have se vere con se quences for fail ure.These sys tems in creas ingly im ple ment a sig nif i cant por tion of their func tion al ity in soft ware, mak ing soft ware de pend abil ity a ma jor is sue.
Grace ful deg ra da tion may be a vi a ble ap proach to achiev ing better soft ware de pend abil ity.If a soft ware sys tem can grace fully de grade au to mat i cally when faults are de tected, then in di vid ual soft ware com po nent fail ures will not cause com plete sys tem fail ure.Rather, com po nent fail ures will re move the func tion al ity de rived from that com po nent, while still pre serv ing the op er a tion of the rest of the sys tem.Spec ifying and achiev ing sys tem-wide grace ful deg ra da tion is a dif fi cult re search prob lem.Cur rent ap proaches re quire spec i fy ing ev ery sys tem fail ure mode ahead of time, and de sign ing a spe cific re sponse for each such mode.This is im prac ti cal for a com plex soft ware sys tem, es pe cially a fine grained dis trib uted em bed ded sys tem with tens or hundreds of soft ware and hard ware com po nents.
In tu itively, the term grace ful deg ra da tion means that a sys tem tol er ates fail ures by re duc ing func tion al ity or per for mance, rather than shut ting down com pletely.An ideal grace fully de grad ing sys tem is par ti tioned so that fail ures in non-crit i cal sub sys tems do not af fect crit i cal sub sys tems, is struc tured so that in di vid ual com po nent fail ures have a lim ited im pact on sys tem func tion al ity, and is built with just enough re dun dancy so that likely fail ures can be tol er ated with out loss of crit i cal func tion al ity.
In or der to eval u ate and im prove sys tem-wide grace ful deg ra da tion, we pres ent a sys tem model that enables scalable specification and analysis of graceful degradation.We base the model on us ing the sys tem's in ter face def i ni tions and com po nent con nec tions to group the sys tem's com po nents into sub sys tems.We hy poth e size that the soft ware ar chi tec ture, re spon si ble for the over all or ga ni za tion of and con nec tions among com po nents, can fa cil i tate the sys tem's abil ity to im plic itly pro vide grace ful deg ra da tion, with out de sign ing a spe cific re sponse to every pos si ble fail ure mode at de sign time.We de fine a fail ure mode to be a set of sys tem com po nents fail ing con cur rently.By us ing the model to mea sure how grace fully a sys tem de grades, we pre dict that we can iden tify what ar chi tec tural prop er ties fa cil i tate and im pede sys tem-wide grace ful deg ra da tion.
We dem on strate the use ful ness of our model by ap ply ing it to a rep re sen ta tive dis trib uted em bed ded sys tem and show ing how we can achieve scal able anal y sis of grace ful degradation.Our ex am ple sys tem is a grace fully degrading el e va tor con trol sys tem that was de signed by an el e va tor en gi neer and im ple mented in a dis crete event sim u la tor (an ear lier ver sion of this system was pre sented in [2]).We use the sim u la tor to per form fault in jec tion ex per i ments by fail ing nodes dur ing the sys tem's op er a tion to ob serve how well the sys tem grace fully de grades, and com pare the re sults to the pre dic tions of our model.
The rest of the paper is organized as follows.Section 2 identifies the problem of specifying graceful degradation and how our model is scalable.Section 3 provides a description of the key features of our model.Section 4 details our elevator control system architecture in terms of the defined components and interfaces.Section 5 shows how we applied our system model for graceful degradation to the elevator architecture to specify the system utility function.Section 6 describes a preliminary fault injection experiment we performed to validate the model.Section 7 describes previous related work.Finally, section 8 ends with conclusions and future work.

Specifying Graceful Degradation
For grace ful deg ra da tion to be pos si ble, it must be pos si ble to de fine the sys tem's state as "work ing" with other than com plete func tion al ity.In many sys tems, a sub stan tial por tion of the sys tem is built to op ti mize prop er ties such as per for mance, avail abil ity, and us abil ity.We must be able to de fine the min i mum func tion al ity re quired for pri mary mis sions, and treat op ti mized func tion al ity as a de sir able, but op tional, en hance ment.For ex am ple, much of a car's en gine con trol soft ware is de voted to emis sion con trol and fuel ef fi ciency, but loss of emis sion sen sors should not strand a car at the side of the road.
Spec ifying and de sign ing sys tem-wide grace ful deg ra da tion is not triv ial.Grace ful deg ra da tion mech a nisms must han dle not only in di vid ual com po nent fail ures, but also com bi na tions of com po nent fail ures.Cur rent grace ful deg ra da tion tech niques em pha size add ing com po nent re dun dancy to pre serve per fect op er a tion when fail ures oc cur, or de sign ing sev eral re dun dant backup sys tems that must be tested and cer ti fied sep a rately to pro vide a sub set of sys tem func tion al ity with re duced hard ware re sources.These tech niques have a high cost in both ad di tional hard ware re sources and com plex ity of sys tem de sign, and might not use sys tem re sources ef fi ciently.
We de fine grace ful deg ra da tion in terms of sys tem util ity: a mea sure of the sys tem's abil ity to pro vide its spec i fied functional and non-functional ca pa bil i ties.A sys tem that has all of its com po nents func tion ing prop erly has max i mum util ity.A sys tem de grades grace fully if in di vid ual com po nent fail ures re duce sys tem util ity pro por tion ally to the se ver ity of ag gre gate fail ures.Util ity is not all or noth ing; the sys tem pro vides a set of fea tures, and ide ally the loss of one fea ture should not hin der the sys tem's abil ity to pro vide the re main ing fea tures.It should be pos si ble to lose a sig nif i cant num ber of com po nents be fore sys tem util ity falls to zero.
We fo cus our anal y sis on dis trib uted em bed ded com puter sys tems.Dis trib uted em bed ded sys tems are usu ally re source con strained, and thus can not af ford much hard ware re dun dancy.How ever, they have high de pend abil ity re quire ments (due to the fact that they must re act to and con trol their phys i cal en vi ron ment), and have be come in creas ingly soft ware-in ten sive.These sys tems typ i cally con sist of mul ti ple com pute nodes con nected via a po ten tially re dun dant real-time fault tol er ant net work.Each com pute node may be con nected to sev eral sen sors and ac tu a tors, and may host mul ti ple soft ware com po nents.Soft ware com po nents pro vide func tion al ity by read ing sen sor val ues, com mu ni cat ing with each other via the net work, and pro duc ing ac tu a tor com mand val ues to pro vide their spec i fied be hav ior.
This work is a part of the RoSES (Ro bust Self-Con fig uring Em bedded Sys tems) pro ject and builds on the idea of a con fig u ra tion space that forms a prod uct fam ily ar chi tec ture [3].Each point in the space rep re sents a dif fer ent con fig u ra tion of hard ware and soft ware com po nents that pro vides a cer tain util ity.Re moval or ad di tion of a com po nent to a sys tem con fig u ra tion moves the sys tem to an other point in the con fig u ra tion space with a dif fer ent level of util ity.For each pos si ble hard ware con fig u ra tion, there are sev eral soft ware con fig u ra tions that pro vide pos i tive sys tem util ity.Our model fo cuses on spec i fy ing the rel a tive util ity of all pos si ble soft ware com po nent con fig u ra tions for a fixed hard ware con fig u ra tion.For a sys tem with N soft ware com po nents, the com plex ity of spec i fy ing a com plete sys tem util ity func tion is nor mally O(2 N ).Our model ex ploits the sys tem's de com po si tion into sub sys tems to re duce this com plex ity to O(2 k ), where k is the num ber of com po nents within a sin gle sub sys tem.When we have a com plete util ity func tion for all pos si ble soft ware con fig u ra tions, we can use tech niques de scribed in [4] to an a lyze the util ity of sys tem hard ware con fig u ra tions to de ter mine the best al lo ca tion of soft ware com po nents to hard ware nodes.

System Model
Sys tem util ity is a key con cept in our model for com par ing sys tem con fig u ra tions.Util ity is a mea sure of how much ben e fit can be gained from us ing a sys tem.Over all sys tem util ity may be a com bi na tion of func tion al ity, per for mance, and de pend abil ity prop er ties.If we spec ify the rel a tive util ity val ues of each of the 2 N pos si ble con fig u ra tions of N soft ware com po nents, sen sors, and ac tu a tors, then we can de ter mine how well a sys tem grace fully de grades based on the util ity dif fer ences among dif fer ent soft ware con fig u ra tions.
Our model en ables com plete def i ni tion of the sys tem util ity func tion with out hav ing to eval u ate the rel a tive util ity of all 2 N pos si ble con fig u ra tions.Our soft ware data flow model en ables scal able sys tem util ity anal y sis by par ti tion ing the sys tem into sub sys tems and iden ti fy ing the de pend en cies among soft ware com po nents.Our sys tem util ity model is based on the sys tem's soft ware con fig u ra tions, and is pri mar ily con cerned with how sys tem func tion al ity changes when soft ware com po nents fail.
The fault model for our sys tem uses the tra di tional fail-fast, fail-si lent as sump tion on a com po nent ba sis, which is best prac tice for this class of sys tem.We as sume that com po nents can ei ther be in one of two states: work ing or failed.Working means that the com po nent has enough re sources to out put its spec i fied sys tem vari ables.Failed means the com po nent can not pro duce its spec i fied out puts.In di vid ual com po nents are de signed to shut down when they de tect an un re cov er able er ror, which en ables the rest of the sys tem to quickly de tect the com po nent's fail ure, and pre vents an er ror from prop a gat ing through the rest of the sys tem.All faults in our model thus man i fest as the loss of out puts from failed com po nents.Soft ware com po nents ei ther pro vide their out puts to the sys tem or do not.Hard ware com po nent fail ures cause loss of all soft ware com po nents hosted on that pro cess ing el e ment.Net work or com mu ni ca tion fail ures can be mod eled as a loss of com mu ni ca tion be tween dis trib uted soft ware com po nents.
Section 3.1 describes our system data flow graph, section 3.2 details how we perform our utility analysis, and section 3.3 identifies some of the key assumptions of our model.

Data Flow Graph and Feature Subset Definitions
We con sider a sys tem as a set of soft ware, sen sor, and ac tu a tor com po nents.We construct our system model as a directed data flow graph in which the vertices represent system components (sensors, actuators, and software components), and the edges represent the communication among components via their input and output interfaces.We use these in ter faces to de fine a set of sys tem vari ables that represent an abstraction of all component interaction.These vari ables can rep re sent any com mu ni ca tion struc ture in the soft ware im ple men ta tion.Ac tu a tors re ceive in put vari ables from the system and out put them to the en vi ron ment, while sen sors in put variables from the en vi ron ment to the system.Our data flow graph can be derived directly from the system's software architecture, which specifies the system's components and interfaces, as well as component organization and dependencies.
We then partition the data flow graph into subgraphs that represent logical subsystems that we term feature subsets.These feature subsets form the basis for how we decompose the system utility analysis.A fea ture sub set is a set of com po nents (soft ware com po nents, sen sors, ac tu a tors, and pos si bly other fea ture sub sets) that work to gether to pro vide a set of out put vari ables or op er ate a sys tem actuator.Fea ture sub sets may or may not be dis joint and can share com po nents across dif fer ent sub sets.Fea ture sub sets also capture the hi er ar chi cal decomposition of the soft ware sys tem, as "higher level" fea ture sub sets con tain "lower level" fea ture sub sets as com po nents, which fur ther encapsulate other soft ware, sen sor, and ac tu a tor com po nents.
The fea ture sub set data flow graphs can also rep re sent de pend ency re la tion ships among com po nents.Each com po nent might not re quire all of its in puts to pro vide par tial func tion al ity.For ex am ple, in an elevator the door con trol lers can use the in puts from the passenger request but tons to more ef fi ciently open and close the doors based on pas sen ger input, but this is an en hance ment to nor mal door op er a tion that sim ply waits a spec i fied pe riod be fore open ing and clos ing the doors.If the door con trol lers no lon ger re ceived these but ton in puts, they could still func tion cor rectly.
We an no tate our fea ture sub set graph edges with a set of de pend ency re la tion ships among com po nents.These re la tion ships are de ter mined by each com po nent's de pend ence on its in put vari ables, which might be strong, weak, or op tional.If a com po nent is de pend ent on one of its in puts, it will have a de pend ency re la tion ship with all com po nents that out put that sys tem vari able.A com po nent strongly de pends on one of its in puts (and thus the com po nents that pro duce it) if the loss of that in put re sults in the loss of the com po nent's abil ity to pro vide its out puts.A com po nent weakly de pends on one of its in puts if the in put is re quired for at least one con fig u ra tion, but not re quired for at least one other con fig u ra tion.If an in put is op tional to the com po nent, then it may pro vide en hance ments to the com po nent's func tion al ity, but is not crit i cal to the ba sic op er a tion of the com po nent.

Utility Model
Our util ity model ex ploits the sys tem de com po si tion cap tured in the soft ware data flow view to re duce the com plex ity of spec i fy ing a sys tem util ity func tion for all pos si ble soft ware con fig u ra tions.Rather than man u ally rank the rel a tive util ity of all 2 N pos si ble soft ware con fig u ra tions of N com po nents, we re strict util ity eval u a tions to the com po nent con fig u ra tions within in di vid ual fea ture sub sets.We spec ify each in di vid ual com po nent's util ity value to be 1 if it is pres ent in a con fig u ra tion (and pro vid ing its out puts), and 0 when the com po nent is failed and there fore not in the con fig u ra tion.
We also make a dis tinc tion be tween valid and in valid sys tem con fig u ra tions.A valid con fig u ra tion pro vides some pos i tive sys tem util ity, and an in valid con fig u ra tion pro vides zero util ity.For grace ful deg ra da tion we are in ter ested in the util ity dif fer ences among valid sys tem con fig u ra tions, as the sys tem is still con sid ered "work ing" un til its util ity is zero.In gen eral, there are many "triv i ally" in valid sys tem con fig u ra tions.A sys tem con fig u ra tion that strongly de pends upon a com po nent that is failed pro vides zero util ity re gard less of what other com po nents are pres ent.For ex am ple, any sys tem con fig u ra tion in which the el e va tor's drive mo tor has failed can not pro vide its ba sic sys tem func tion al ity and is invalid, so ex am in ing the rest of the sys tem's com po nent con fig u ra tion is un nec es sary.How ever, there is still a set of mul ti ple valid con fig u ra tions that must be ranked for sys tem util ity, and we use our sub system def i ni tions to spec ify the util ity of these sys tem con fig u ra tions.
If we re strict our anal y sis to in di vid ual fea ture sub set com po nent con fig u ra tions, we only need to rank the rel a tive util ity val ues of all valid con fig u ra tions within each fea ture sub set.For feature subsets with a maximum of k << N components, this is a much more feasible task.We only need to manually rank at most the utilities of 2 k possible configurations for each feature subset Additionally, we can sig nif i cantly re duce the num ber of con fig u ra tions we must con sider by using component dependencies to de ter mine the valid and in valid con fig u ra tions of each fea ture sub set.
We can then de ter mine over all sys tem util ity by examining the sys tem con fig u ra tions of the "top level" fea ture sub sets that provide outputs to system actuators.All other fea ture sub sets utility evaluations are en cap su lated within these sub sys tems that pro vide ex ter nal sys tem func tion al ity.We can com pletely spec ify the sys tem util ity func tion without manually specifying the relative utility values of all 2 N possible system component configurations, but rather specifying the utilities of 2 k feature subset configurations for each feature subset in the system.
We can use this model to de velop a space of sys tems with vary ing de grees of grace ful deg ra da tion.At one end of the spec trum, we have ex tremely "brit tle" sys tems that are not ca pa ble of any grace ful deg ra da tion at all.In these sys tems, any one com po nent fail ure will re sult in a com plete sys tem fail ure.In our model, this would be a sys tem where ev ery com po nent is a mem ber of at least one required fea ture sub set, and each fea ture sub set strongly de pends on all of its com po nents.There fore, ev ery com po nent must be func tion ing to have pos i tive sys tem util ity.
Sim i larly, any mod u lar re dun dant sys tem can be rep re sented as a col lec tion of sev eral fea ture sub sets, where each fea ture sub set con tains mul ti ple cop ies of a com po nent plus a voter.The valid con fig u ra tions that pro vide pos i tive util ity for each fea ture sub set are those that con tain the voter plus one or more com po nent cop ies.This re dun dant sys tem can tol er ate mul ti ple fail ures across many fea ture sub sets, but can not tol er ate the fail ure of any one voter or all the com po nent cop ies in any one fea ture sub set.
At the other end of the spec trum, an ideal grace fully de grad ing sys tem is one where any com bi na tion of com po nent fail ures will still leave a sys tem with pos i tive util ity.In our model, this sys tem would be one where none of its fea ture sub sets would be la beled as re quired for ba sic func tion al ity, and ev ery com po nent would be com pletely op tional to each fea ture sub set in which it was a mem ber.The sys tem would con tinue to have pos i tive util ity un til ev ery com po nent failed.

Assumptions of Our Model
Our model is never any worse than hav ing to con sider 2 N sys tem con fig u ra tions of N com po nents, and in typ i cal cases will be a sig nif i cant im prove ment.We have made sev eral as sump tions with re gard to how these soft ware sys tems are de signed.First, we as sume that the pa ram e ters of the util ity func tion for each fea ture sub set con fig u ra tion are in de pend ent of the con fig u ra tion of any other fea ture sub set in the sys tem.We only de fine dif fer ent util ity func tions for dif fer ent fea ture sub set con fig u ra tions, in which a con fig u ra tion spec i fies whether a com po nent is pres ent and work ing (pro vid ing pos i tive util ity) or ab sent and failed (pro vid ing zero util ity).
When a fea ture sub set is treated as a com po nent in a higher-level fea ture sub set, that com po nent can po ten tially have dif fer ent util ity val ues based on its cur rent con fig u ra tion, rather than just 1 for work ing and 0 for failed as with in di vid ual soft ware com po nents, sen sors, and ac tu a tors.This could po ten tially mean that in or der to de fine the higher-level fea ture sub set's util ity func tion, we would have to de fine a dif fer ent util ity func tion for ev ery pos si ble util ity value for ev ery fea ture sub set con tained as a com po nent in the higher-level fea ture sub set.How ever, this is only nec es sary if the en cap su lated fea ture sub sets are strongly cou pled within higher level fea ture sub sets.Be cause sys tem ar chi tects gen er ally at tempt to de cou ple sub sys tems, we as sume that en cap su lated fea ture sub sets are not strongly cou pled.If some sub sys tems are strongly cou pled, one could ap ply multi-at trib ute util ity the ory [5] to deal with the added sys tem com plex ity within the model.
We also as sume that the sys tem is "well-de signed" such that com bi na tions of com po nents do not in ter act neg a tively with re spect to fea ture sub set or sys tem util ity.In other words, when a com po nent has zero util ity, it con trib utes zero util ity to the sys tem or fea ture sub set, but when a com po nent has some pos i tive util ity, it con trib utes at least zero or pos i tive util ity to the sys tem or fea ture sub set, and never has an in ter ac tion with the rest of the sys tem that re sults in an over all loss of util ity.Thus, work ing com po nents can en hance but never re duce sys tem util ity.We as sume that if we ob serve a sit u a tion in which a com po nent con trib utes neg a tive util ity to the sys tem, we can in ten tion ally de ac ti vate that com po nent so that it con trib utes zero util ity in stead.
Our util ity model only deals with soft ware sys tem con fig u ra tions, and we do not di rectly ac count for hard ware re dun dancy as a sys tem util ity at trib ute.How ever, in gen eral hard ware re dun dancy mech a nisms will not af fect sys tem func tion al ity, but rather hard ware sys tem re li abil ity or avail abil ity.To an a lyze trade offs be tween sys tem func tion al ity and de pend abil ity, we could again ap ply multi-at trib ute util ity the ory to judge the rel a tive value of the soft ware con fig u ra tion's util ity and the hard ware con fig u ra tion's re li abil ity and avail abil ity to the sys tem's over all util ity.This anal y sis may in clude fac tors such as sys tem re source costs and hard ware and soft ware fail ure rates.

Example System: A Distributed Elevator Control System
To il lus trate how we can ap ply our sys tem model to a real sys tem, we use a design of a rel a tively com plex dis trib uted el e va tor con trol sys tem.This sys tem was de signed by an el e va tor en gi neer (the sec ond au thor) and has been im ple mented in a dis crete event sim u la tor writ ten in Java.This el e va tor sys tem has been used as the course pro ject in the dis trib uted em bed ded sys tems class at Car ne gie Mellon Uni ver sity for sev eral se mes ters.Since we have a com plete ar chi tec tural spec i fi ca tion as well as an im ple men ta tion, we can di rectly ob serve how prop er ties of the system ar chi tec ture af fect the sys tem's abil ity to grace fully de grade by per form ing fault in jec tion ex per i ments in the sim u la tion.
Our view of the el e va tor sys tem is a set of sen sors, ac tu a tors and soft ware com po nents that are al lo cated to the var i ous hard ware nodes in the dis trib uted sys tem.The nodes are con nected by a real-time fault tol er ant broad cast net work.All net work mes sages can be re ceived by any node in the sys tem.Since all com mu ni ca tion among com po nents is via this broad cast net work, all com po nent com mu ni ca tion in ter faces map to a set of net work mes sage types.
Our el e va tor sys tem ar chi tec ture is highly dis trib uted and de cen tral ized, and is based on the mes sage in ter faces that sys tem com po nents use to com mu ni cate.Sys tem in puts come from "smart" sen sors that have a pro cess ing node em bed ded in the sens ing de vice.
These sen sors con vert their raw sen sor val ues to mes sages that are broad cast on the net work.The soft ware con trol sys tem, im ple mented as a set of dis trib uted soft ware com po nents, re ceives these mes sages and pro duces out put mes sages that pro vide com mands to the ac tu a tors to pro vide the sys tem's func tion al ity.
The el e va tor con sists of a sin gle car in a hoistway with ac cess to a set num ber of floors f.The car has two in de pend ent left and right doors and door mo tors, a drive that can ac cel er ate the car to two speeds (fast and slow) in the hoistway, an emer gency stop brake for safety, and var i ous but tons and lights for de ter min ing pas sen ger re quests, and pro vid ing feed back to the pas sen gers.Since the sen sors and ac tu a tors map di rectly to the mes sage in ter faces among com po nents, we list all the pos si ble in ter face mes sage types along with their send ers and re ceiv ers be low to de fine the com po nents and in ter faces of the sys tem ar chi tec ture.In the fol low ing no ta tion, the val ues within the "[]" brack ets rep re sent the stan dard rep li ca tion of an ar ray of sen sors or ac tu a tors, and the val ues within the "()" pa ren the ses rep re sent the val ues the sen sor or ac tu a tor can out put.For ex am ple, the Hall call mes sage type maps to an ar ray of sen sors for the up and down but tons on each floor out side the el e va tor that is f (the num ber of floors the el e va tor ser vices) by d (the di rec tion of the but ton; Up or Down) wide, and each but ton sen sor can ei ther have a value v of True (pressed) or False (not pressed).Un less oth er wise noted, "f" rep re sents the num ber of floors the el e va tor ser vices, "d" rep re sents a vari able that in di cates a di rec tion of ei ther Up or Down, "j" is a vari able that is a value of ei ther Left or Right (for the left and right el e va tor doors), and "v" de notes a value that can be ei ther True or False.
The sen sor mes sage types avail able in the sys tem in clude: • AtFloor[f](v): Out put of AtFloor sen sors that sense when the car is near a floor.
• CarCall[f](v): Out put of car call but ton sen sors lo cated in the car.
• CarLevelPosition(x): Out put of car po si tion sen sor that tracks where the car is in the hoistway.HallLight[f,d](v): Com mands for hall call but ton lights in side the hall call but tons to in di cate when pas sen gers want the el e va tor on a cer tain floor.• EmergencyBrake(v): Emer gency stop brake that should be ac ti vated when ever the sys tem state be comes un safe and the el e va tor must be shut down to pre vent a cat a strophic failure.For each ac tu a tor, there is a soft ware con trol ler ob ject that pro duces the com mands for that ac tu a tor.The drive con trol ler com mands the drive ac tu a tor to move the el e va tor based on the DesiredFloor in put it re ceives from the dis patcher soft ware ob ject.The left and right door con trol lers op er ate their re spec tive door mo tors.The safety mon i tor soft ware mon i tors the el e va tor sys tem sen sors to en sure safe op er a tion and ac ti vate the emer gency brake when nec es sary.The var i ous soft ware ob jects for the but tons and lights de ter mine when to ac ti vate the lights to in di cate ap pro pri ate feed back to the pas sen gers.Ad di tionally, since the AtFloor sen sors are a crit i cal re source for the el e va tor sys tem, we have re dun dant "vir tual" AtFloor soft ware com po nents that can syn the size AtFloor mes sages based on data from the car po si tion and el e va tor drive speed sen sors.If some of the phys i cal AtFloor sen sors fail, these soft ware sen sors can be used as back ups.The el e va tor con trol sys tem con sists of 8 + 4f sen sors, 5 + 3f ac tu a tors, and 6 + 4f soft ware com po nents, for a to tal of 19 + 11f com po nents in the sys tem.Fig ure 1 il lus trates how these sys tem com po nents are al lo cated to hard ware nodes in the el e va tor's dis trib uted con trol sys tem.
In our ex per i ments, we sim u lated an el e va tor with seven floors, mean ing that there were a to tal of 96 com po nents in the sys tem.To spec ify how well the sys tem grace fully de grades with re spect to all pos si ble com bi na tions of com po nent fail ures, the tra di tional ap proach would re quire a man ual rank ing of the util ity of all 2 96 = 7.92 * 10 28 pos si ble sys tem con fig u ra tions.Our model ex ploits the in for ma tion avail able from the sys tem ar chi tec ture to over come this ex po nen tial dif fi culty.

Specifying the Elevator Control System
We can use the component and interface specifications of the elevator control system to apply our system model for graceful degradation.We will not reproduce the entire  system data flow graph here, but rather show the subgraphs for each feature subset we identified and how we performed our analysis using these subsystem definitions.

Elevator Feature Subsets
In the el e va tor sys tem, there are sev eral func tional sub sys tems that map to fea ture sub sets.The pri mary con trol sys tems in the el e va tor op er ate the drive and the door mo tors.Their fea ture sub sets are de fined by the in puts and out puts of the drive con trol ler, and left and right door con trol ler soft ware ob jects.Fig ure 2 dis plays these fea ture sub sets and the de pend ency re la tion ships among their com po nents.In the di a grams we an no tated the out put vari ables of each fea ture sub set.The left and right door con trol fea ture sub sets are nearly iden ti cal with the ex cep tion of which door sen sors and ac tu a tors they con tain, so only the left door con trol fea ture sub set is shown in de tail.
These fea ture sub sets are re spon si ble for con trol ling the drive and door ac tu a tors, but they also out put their com mand vari ables over the net work to the rest of the sys tem.This al lows subsystems to loosely co or di nate their op er a tion with out be ing strongly  cou pled and de pend ent on each other.For ex am ple, the Door Con trol lers must re ceive in puts from the Drive Speed sen sor in or der to safely op er ate the door only when the el e va tor is not mov ing.How ever, the Door Con trol ler can also use the com mand out put from the Drive Con trol fea ture subset to an tic i pate when the el e va tor will stop based on the com mand sent from the Drive Con trol fea ture sub set, thus al low ing more ef fi cient door op er a tion via sending the door open command slightly be fore the el e va tor is level with the des ti na tion floor.The Drive Con trol fea ture sub set en cap su lates all of its com po nents, so that it is rep re sented as a sin gle com po nent that out puts the Drive com mand sys tem vari able in the Left and Right Door Con trol fea ture sub sets.Like wise the Door Con trol fea ture sub set en cap su lates all of the com po nents in the Left and Right Door Con trol fea ture sub sets.
These fea ture sub sets also con tain sev eral iden ti cal com po nents, such as the Drive Speed and AtFloor sen sors.These com po nents do not rep re sent mul ti ple cop ies of the same com po nent in the soft ware data flow view, but rather that these fea ture sub sets over lap and share some of their com po nents.
The fea ture sub set graphs show de pend en cies among com po nents, but not whether in di vid ual com po nents are rep li cated for mul ti ple sub sys tems.There may be mul ti ple re dun dant sen sors in stalled in the sys tem, but the in for ma tion about how com po nents are al lo cated to hard ware would be vis i ble in the hard ware ar chi tec ture and is or thogo nal to the soft ware data flow view of our sys tem model.We de fined sev eral other fea ture sub sets for our el e va tor sys tem in ad di tion to the Door Con trol and Drive Con trol fea ture sub sets.The Safety Mon i tor soft ware com po nent and its in puts and out puts de fines the Safety Mon i tor fea ture sub set.The Safety Mon i tor fea ture sub set is re spon si ble for de tect ing when the el e va tor sys tem state be comes un safe, such as the doors open ing while the el e va tor is mov ing, the doors fail ing to re verse di rec tion if they bump into a pas sen ger while clos ing, or the el e va tor crash ing into the top or bot tom of the hoistway.In any un safe sit u a tion, the Safety Mon i tor must trig ger the Emer gency Brake ac tu a tor that shuts down the el e va tor sys tem to pre vent a cat a strophic fail ure.Fig ure 3 shows the Safety Mon i tor fea ture sub set along with some of the sen sors from which it re ceives in puts.The Safety Mon i tor must re ceive in puts from both the Door and Drive Con trol fea ture sub sets to en sure that their com mands are con sis tent with the el e va tor's ac tual op er a tion de ter mined from the drive speed and door sen sors.
The Door Con trol, Drive Con trol, and Safety Mon i tor fea ture sub sets rep re sent the crit i cal el e va tor sub sys tems that pro vide an el e va tor's ba sic func tion al ity.An ef fi cient el e va tor should also re spond to pas sen ger re quests to move peo ple quickly to their des ti na tion floors.The Drive Con trol ler lis tens to the DesiredFloor sys tem vari able to de ter mine its next des ti na tion, and this vari able is the out put of the De sired Floor fea ture sub set.The De sired Floor fea ture sub set con tains the Dis patcher soft ware com po nent that im ple ments the al go rithm for de ter min ing the next floor at which the el e va tor should stop.The Dis patcher re ceives in puts from the Car Call and Hall Call but tons to de ter mine pas sen ger in tent and com pute the el e va tor's next des ti na tion.The Car Call and Hall Call but tons in turn form their own fea ture sub sets that pro vide the but ton sen sor mes sages to the rest of the sys tem, but also con trol the but ton lights to pro vide ap pro pri ate pas sen ger feed back.Fig ures 4 and 5 show the fea ture sub set def i ni tions for the De sired Floor, Car Call and Hall Call fea ture sub sets.The fea ture sub sets for the Car Call and Hall Call but tons are sim i larly defined for each floor since each Car Call and Hall Call soft ware con trol ler have sim i lar in put and out put in ter faces.Each Car Call and Hall Call con trol ler out puts the value of its re spec tive sen sor on the net work for the rest of the sys tem, but only sends the com mand mes sages for its but ton light to its ac tu a tor.
In or der to en cour age peo ple to move quickly in the el e va tor, the Car Lan tern and Car Po si tion In di ca tor lights pro vide feed back to let the pas sen gers know the el e va tor's cur rent trav el ing di rec tion, and the el e va tor's next floor des ti na tion.Fig ure 6 dis plays the fea ture sub sets for the Car Po si tion In di ca tor and up and down Car Lan tern light sub sys tems.These fea tures are not es sen tial for the el e va tor's ba sic op er a tion, but pro vide in for ma tion to the pas sen gers to help them use the el e va tor more ef fi ciently.
One es sen tial sub sys tem that is re quired by all of the other ma jor el e va tor sub sys tems is the AtFloor Sen sors fea ture sub set.Nearly ev ery fea ture sub set strongly de pends on AtFloor sen sor in for ma tion to pro vide func tion al ity.For ex am ple, the Drive Con trol and Door Con trol fea ture sub sets need the AtFloor sen sor in for ma tion to cor rectly op er ate the drive and door mo tors.Since this is such a crit i cal fea ture in the el e va tor sys tem, our el e va tor de sign also has re dun dant soft ware com po nents.The Vir tual AtFloor soft ware com po nents can syn the size AtFloor sen sor mes sages from the Car Po si tion and Drive Speed sen sors when the phys i cal AtFloor sen sors fail.Thus they are in cluded in the AtFloor sen sor fea ture sub set graphs.Fig ure 7 shows the AtFloor fea ture sub set de scrip tion for the el e va tor sys tem in our model.

Utility Analysis
The el e va tor sys tem has a to tal of 19 + 11f sys tem com po nents, mean ing there are 2 will not af fect the avail abil ity of the AtFloor sys tem vari ables, mak ing 2 f valid com bi na tions for the var i ous VirtualAtFloor com po nents.If the Car Po si tion sen sor works, then one or both AtFloor sen sor and VirtualAtFloor com po nent must work for each floor, so the only in valid com bi na tions are when both have failed for at least one floor.This means there are 3 valid com bi na tions per floor, mak ing 3 f valid com bi na tions out of the pos si ble 2 2f .Thus there are 2 f + 3 f valid com bi na tions of com po nents in the AtFloor fea ture sub set.The to tal num ber of pos si ble valid sys tem com po nent con fig u ra tions af ter elim i nat ing all con fig u ra tions that will al ways have util ity zero is (2 f + 3 f )(2 1 + 9f ).For our el e va tor with seven floors this is ap prox i mately 4.27 * 10 22 con fig u ra tions that still must be man u ally ranked.This is a sig nif i cant re duc tion from the 7.92 * 10 28 to tal pos si ble sys tem con fig u ra tions, but still in trac ta ble for spec i fy ing sys tem-wide grace ful deg ra da tion.How ever, we can ex ploit the struc ture of the sys tem de sign cap tured in the fea ture sub set def i ni tions to re duce the num ber of con fig u ra tions we must rank to com pletely spec ify the sys tem util ity func tion.We have de fined 16 + 4f dis tinct fea ture sub sets in the el e va tor sys tem.If f is small, the larg est fea ture sub sets are the left and right door con trol fea ture sub sets, with 11 com po nents each.Thus we must rank a max i mum of 2 11 = 2048 con fig u ra tions in any one fea ture sub set.
Since we can de ter mine the valid and in valid con fig u ra tions in each fea ture sub set by ex am in ing the com po nent de pend en cies, we can sig nif i cantly re duce the num ber of con fig u ra tions we must con sider in each fea ture sub set.For ex am ple, in the left and right door con trol fea ture sub sets, 7 of the 11 com po nents are re quired for the fea ture sub set to pro vide util ity, mean ing we only need to con sider the 16 pos si ble con fig u ra tions of the 4 op tional com po nents.If f is large, the num ber of con fig u ra tions in fea ture sub sets that con tain f com po nents (AtFloor, Car Call, and Hall Call Up/Down) will dom i nate.How ever, these fea ture sub sets con tain com po nents that are largely or thogo nal since each com po nent's func tion al ity is re stricted to a dif fer ent floor.There fore we can sim plify the util ity spec i fi ca tion of these fea ture sub sets to a lin ear com bi na tion of the util ity val ues of their com po nents, re quir ing only that we spec ify f weights for each com po nent util ity in the fea ture sub set.Ta ble 1 sum ma rizes the num ber of valid con fig u ra tions that must be as signed util ity val ues in each fea ture sub set for a to tal of 33 + 53f fea ture sub set con fig u ra tions that must be con sid ered across the en tire el e va tor sys tem.For our seven floor el e va tor, this to tals 404 valid fea ture sub set com po nent con fig u ra tions for the en tire sys tem.
We can then de ter mine over all sys tem util ity by com pos ing the sys tem con fig u ra tions of the "top level" fea ture sub sets that pro vide sys tem func tion al ity.In the el e va tor sys tem, these fea ture sub sets are the Drive Con trol, Door Con trol, Safety Mon i tor, Car Call, Hall, Call, Car Lan tern, and Car Po si tion In di ca tor fea ture sub sets.All other fea ture sub sets are en cap su lated within these seven sub sys tems that pro vide ex ter nal sys tem func tion al ity.Since the Drive Con trol, Door Con trol, and Safety Mon i tor fea ture sub sets must be pres ent to pro vide min i mum el e va tor func tion al ity, that leaves only 2 4

Experimental Validation
If our model ac cu rately pre dicts the rel a tive util ity of all sys tem con fig u ra tions, we can as sess how well the sys tem grace fully de grades by ob serv ing how sys tem util ity changes when the sys tem con fig u ra tion changes as com po nents fail.To val i date our model, we per formed some pre lim i nary fault in jec tion ex per i ments on a sim u lated el e va tor im ple men ta tion.A dis crete event sim u la tor sim u lates a real time net work with mes sage de lay that de liv ers broad cast pe ri odic mes sages be tween sys tem com po nents.Each soft ware com po nent, sen sor, and ac tu a tor is a soft ware ob ject that im ple ments its mes sage in put and out put in ter face to pro vide func tion al ity.Sen sor and ac tu a tor ob jects in ter act with the pas sen ger ob jects that rep re sent peo ple us ing the el e va tor.Each sim u la tion ex per i ment spec i fies a pas sen ger pro file that in di cates how many pas sen gers at tempt to use the sys tem, when they first ar rive to use the el e va tor, what floor they start at, and their in tended des ti na tion.We can spec ify which el e va tor sys tem con fig u ra tion to sim u late by set ting which com po nents are failed at the start of the sim u la tion.
In gen eral, sys tem util ity should be a mea sure of how well the sys tem ful fills its re quire ments, and could in cor po rate many sys tem prop er ties such as per for mance, func tion al ity, and de pend abil ity.An el e va tor sys tem's pri mary func tion is to ef fi ciently trans port peo ple to their des ti na tions, min i miz ing how long pas sen gers must wait for and ride in the el e va tor.There fore, in our sim u la tion ex per i ments, we use the el e va tor's av er age per for mance per pas sen ger as a proxy for mea sur ing sys tem util ity.We track how long it takes for each pas sen ger to reach their des ti na tion, from the time they first ar rive to use the el e va tor to the time they step off the el e va tor at their in tended floor.We se lected a small sub set of the pos si ble valid el e va tor sys tem con fig u ra tions, and ran two pas sen ger pro files on each sys tem con fig u ra tion.The con fig u ra tions we se lected for eval u a tion in cluded the con fig u ra tion in which only the min i mum re quired com po nents for ba sic op er a tion were pres ent, as well as the con fig u ra tion in which all of the com po nents were work ing.We also picked sev eral con fig u ra tions in which dif fer ent sub sets of Car Call and Hall Call but tons were failed so that the el e va tor could not re ceive all pas sen ger re quests.One en cour ag ing re sult of our ex per i ment is that ev ery valid con fig u ra tion we tested even tu ally de liv ered all pas sen gers to their des ti na tion re gard less of which set of sys tem com po nents were failed.
We mea sured the av er age per for mance of each sys tem con fig u ra tion and com pared it to its sys tem util ity as pre dicted by our model.If our model ac cu rately pre dicted sys tem util ity, we should see con fig u ra tions that have higher util ity mea sures achieve better av er age per for mance.Fig ure 8 graphs the util ity of the tested sys tem con fig u ra tions ver sus the el e va tor per for mance per pas sen ger.The sys tem con fig u ra tions on the hor i zon tal axis are or dered by util ity, so the per for mance mea sures should be monotonically in creas ing.The graphs show a gen eral trend of in creas ing per for mance, but it is not monotonically in creas ing.
How ever, el e va tor per for mance can be largely af fected by how fre quently pas sen gers ar rive and how the dis patcher deals with a loss of but ton in puts.Our dis patcher al go rithm would pe ri od i cally send the el e va tor to visit floors for which it was not re ceiv ing but ton in for ma tion in or der to en sure that all pas sen gers even tu ally get de liv ered to their des ti na tion.Thus, some times el e va tor per for mance would suf fer to en sure that no pas sen gers were stranded.The fact that none of the sys tem con fig u ra tions tested suf fered a com plete sys tem fail ure and de liv ered all pas sen gers in di cates that the sys tem can grace fully de grade in the pres ence of mul ti ple com po nent fail ures.
This experiment was limited because we were only able to test a small number of configurations on two passenger profiles.We plan to extend this experimental validation with a wider range of different passenger profiles, as well as test many more different system configurations.We also plan to run these experiments with variants of the elevator architecture that are designed with different degrees of graceful degradation mechanisms.

Related Work
Pre vi ous work on for mally de fin ing grace ful deg ra da tion for com puter sys tems was pre sented in [6].That work pro posed con struct ing a lat tice of sys tem con straints that iden ti fies what tasks the sys tem can ac com plish based on which con straints it can sat isfy.A sys tem that works per fectly sat is fies all con straints, and a sys tem that en coun ters fail ures might sat isfy a looser set of con straints and still pro vide func tion al ity, but is de graded with re spect to some sys tem prop er ties.The dif fi culty with this model is that in or der to spec ify the re lax ation lat tice, it is nec es sary to spec ify not only ev ery sys tem con straint, but also how con straints are re laxed in the pres ence of fail ures.It fur ther re quires de ter min ing how con straints in ter act and de vel op ing a re cov ery scheme for ev ery pos si ble com bi na tion of fail ures in or der to move be tween points in the lat tice.Be cause all com bi na tions of com po nent fail ures must be con sid ered, spec i fy ing and achiev ing grace ful deg ra da tion is ex po nen tially com plex with the num ber of sys tem com po nents.Our model for spec i fy ing grace ful deg ra da tion over comes this dif fi culty by en cap su lat ing util ity eval u a tions within in di vid ual sub sys tem con fig u ra tions rather than eval u at ing the sys tem as a whole in a sin gle step.Other work on grace ful deg ra da tion has fo cused on de vel op ing for mal def i ni tions [7,8], but has not ad dressed how to ap ply these def i ni tions to real sys tem spec i fi ca tions, nor how to over come the prob lem of ex po nen tial com plex ity for spec i fy ing fail ure modes and re cov ery mech a nisms.
Cur rent in dus try prac tice for deal ing with faults and fail ures in em bed ded sys tems fo cuses on the tra di tional ap proaches of fault tol er ance and fault con tain ment [9].Soft ware sub sys tems are phys i cally sep a rated into dif fer ent hard ware mod ules.Ad di tionally, sys tem re sources, such as sen sors and ac tu a tors, that may be com monly used are rep li cated for each sub sys tem.That ap proach pro vides as sur ance that faults will not prop a gate be tween sub sys tems since they are phys i cally par ti tioned, and fault tol er ance is achieved by rep li cat ing re sources and sub sys tems.Typically, fail ures are dealt with by hav ing sep a rate backup sub sys tems avail able rather than shed ding func tion al ity when re sources are lost.This ap proach is a re stricted form of grace ful deg ra da tion, in that it tol er ates the loss of a fi nite set of com po nents be fore suf fer ing a com plete sys tem fail ure.How ever, this meth od ol ogy is costly be cause of its high level of re dun dancy.
A prom is ing ap proach to achiev ing sys tem de pend abil ity is NASA's Mis sion Data Sys tem (MDS) ar chi tec ture [10,11].This sys tem ar chi tec ture is be ing de signed for un manned au ton o mous space flight sys tems that must com plete mis sions with lim ited hu man over sight.Their ar chi tec ture fo cuses on de sign ing soft ware sys tems that have spe cific goals based on well de fined state vari ables.The soft ware is de com posed based on the subgoals it must com plete to sat isfy its pri mary goal.The soft ware is not con strained to a par tic u lar se quence of be hav ior, but rather must de ter mine the best course of ac tion based on its goals.The po ten tial dif fi cul ties with this ap proach in clude the ef fort re quired to de com pose goals into subgoals, and con flict res o lu tion among subgoals at run time.Our frame work dif fers from MDS in that we spe cif i cally fo cus on be hav ior-based sub sys tems and the co or di na tion among them through sys tem com mu ni ca tion in ter faces.
Sur viv abil ity and performability are re lated to our con cept of grace ful deg ra da tion.Sur viv abil ity is a prop erty of de pend abil ity that has been pro posed to de fine ex plic itly how sys tems de grade func tion al ity in the pres ence of fail ures [12].Performability is a uni fied mea sure of both per for mance and re li abil ity that tracks how sys tem per for mance de grades in the pres ence of faults [13].Our work dif fers from sur viv abil ity in that we are in ter ested in build ing im plicit grace ful deg ra da tion into sys tems with out spec i fy ing all fail ure sce nar ios and re cov ery modes a pri ori.Also, we fo cus on dis trib uted em bed ded sys tems rather than on large-scale crit i cal in fra struc ture in for ma tion sys tems.Performability re lates sys tem per for mance and re li abil ity, but our con cept of grace ful deg ra da tion ad dresses how sys tem func tion al ity can change to cope with com po nent fail ures.Mil i tary sys tems have long used sim i lar no tions to pro vide grace ful deg ra da tion (for ex am ple, in ship board com bat sys tems), but had scalability lim its and were typ i cally lim ited to a dozen or so spe cif i cally en gi neered con fig u ra tions.
Our sys tem model pro vides a scal able ap proach to de ter min ing how well a sys tem grace fully de grades.Since in di vid ual com po nent fail ures sim ply trans form the sys tem from one con fig u ra tion to an other, we can eval u ate how well the sys tem grace fully de grades by ob serv ing the util ity dif fer ences among valid sys tem con fig u ra tions.By ex ploit ing the fact that sys tems are de com posed into sub sys tems of com po nents, we can re duce the com plex ity of de ter min ing the util ity func tion for all pos si ble sys tem con fig u ra tions from O(2 N ) to O(2 k ), where N is the to tal num ber of soft ware com po nents, sen sors, and ac tu a tors in the sys tem, and k is the max i mum num ber of com po nents in any one sub sys tem.Data de pend ency re la tion ships among com po nents en able ef fi cient elim i na tion of in valid con fig u ra tions from our anal y sis.In the el e va tor sys tem, we used our sys tem model to gen er ate a com plete sys tem util ity func tion for all 4.27 * 10 22 valid sys tem con fig u ra tions by only ex am in ing 420 sub sys tem con fig u ra tions.
Our model con sists of a soft ware data flow graph for de ter min ing de pend ency re la tion ships among soft ware com po nents, sen sors, and ac tu a tors, and a util ity model that pro vides a frame work for com par ing the rel a tive util ity of sys tem con fig u ra tions.Since fea ture sub set def i ni tions are based on com po nent in put and out put in ter faces, they can be au to mat i cally gen er ated from the soft ware ar chi tec ture specification.We al low mul ti ple fea ture sub sets that re quire the same in put sys tem vari able from an other com po nent to share that com po nent.Fea ture sub sets are in gen eral not dis joint, and a com po nent or fea ture sub set en cap su lated in one high-level fea ture sub set may be long to sev eral other fea ture sub sets.This al lows us to de cou ple sub sys tem util ity anal y ses within our model, even if the sys tem it self does not com pletely en cap su late its sub sys tems into a strict hi er ar chy.
For grace ful deg ra da tion in the el e va tor sys tem we de signed the soft ware com po nents to have a de fault be hav ior based on their re quired in puts, and to treat op tional in puts as "ad vice" to im prove func tion al ity when those in puts are avail able.For ex am ple, the Door Con trol and Drive Con trol com po nents can lis ten to each other's com mand out put vari ables in ad di tion to the Drive Speed and Door Closed sen sors to syn chro nize their be hav ior (open the doors more quickly af ter the car stops), but only the sen sor val ues are nec es sary for cor rect be hav ior.Like wise, the Drive Con trol com po nent has a de fault be hav ior that stops the el e va tor at ev ery floor, but if the De sired Floor sys tem variable is avail able from the out put of the Dis patcher com po nent, then it can use that value to skip floors that do not have any pend ing re quests.Also, the Door Con trol com po nent nor mally opens the door for a spec i fied dwell time, but can re spond to but ton presses to re open the doors if a pas sen ger ar rives.
We did not ex plic itly design fail ure re cov ery sce nar ios for ev ery pos si ble com bi na tion of com po nent fail ures in the system, but rather built the in di vid ual soft ware com po nents to be ro bust to a loss of sys tem in puts.The in di vid ual com po nents were de signed to ig nore op tional in put vari ables when they were not avail able and fol low a de fault be hav ior.This is a fun da men tally dif fer ent ap proach to sys tem-wide grace ful deg ra da tion than spec i fy ing all pos si ble fail ure com bi na tions to be han dled ahead of time.Prop erties of the soft ware ar chi tec ture such as the com po nent in ter faces and the iden ti fi ca tion and par ti tion ing of crit i cal sys tem func tion al ity from the rest of the sys tem seem to be key to achiev ing sys tem-wide grace ful deg ra da tion.The model we de vel oped il lus trates how well a sys tem can grace fully de grade by us ing the soft ware ar chi tec ture's com po nent con nec tions to de com pose the sys tem.
In pre lim i nary ex per i ments on a sim u lated im ple men ta tion of the el e va tor con trol sys tem ar chi tec ture we de signed, we found that the sys tem was re sis tant to mul ti ple com bi na tions of com po nent fail ures, as pre dicted by the model.We val i dated the util ity es ti mates we gen er ated with our model by mea sur ing the el e va tor per for mance of a set of sys tem con fig u ra tions that had var i ous com bi na tions of com po nent fail ures.Since gen eral sys tem util ity en com passes both func tion al ity and de pend abil ity re quire ments, the per for mance of these con fig u ra tions did not ex actly match what our model pre dicted.How ever, ev ery sys tem con fig u ra tion tested de liv ered all pas sen gers to their des ti na tions in both sim u la tion tests, sat is fy ing the min i mum el e va tor sys tem re quire ments de spite a loss of sys tem func tion al ity.Fu ture work will in clude running a more comprehensive set of simulation tests for this elevator system, as well as comparing the graceful degradation ability of different elevator architectural designs, and iden ti fy ing how we can spec ify the pa ram e ters of our sys tem model to more ac cu rately mea sure sys tem util ity at trib utes and thus more closely rep re sent the ac tual func tion al ity and per for mance of sys tem configurations.
x = {distance value from bot tom of hoistway} • DoorClosed[j](v): Out put of door closed sen sors that will be True when the door is fully closed.• DoorOpen[j](v): Out put of door open sen sors that will be True when the door is fully open.• DoorReversal[j](v): Out put of door re ver sal sen sors that will be True when door senses an ob struc tion in the door way.• HallCall[f,d](v): Out put of hall call but ton sen sors that are lo cated in hall way out side the el e va tor on each floor.Note that there are a to tal of 2f -2 rather than 2f hall call but tons since the top floor only has a down but ton and the bot tom floor only has an up but ton.• HoistwayLimit[d](v): Out put of safety limit sen sors in the hoistway that will be True when the car has over run ei ther the top or bot tom hoistway lim its.• DriveSpeed(s,d): Out put of the main drive speed sen sor.s = {speed value}, d = {Up, Down, Stop} The ac tu a tor com mand messages avail able in the sys tem are: • DesiredFloor(f, d): Com mand from the el e va tor dis patcher al go rithm indicating the next floor des ti na tion.d = {Up, Down, Stop} (This is not an ac tu a tor in put, but rather an in ter nal vari able in the con trol sys tem sent from the dis patcher to the drive controller) • DoorMotor[j](m): Door mo tor com mands for each door.m = {Open, Close, Stop} • Drive(s, d): Com mands for 2-speed main el e va tor drive.s = {Fast, Slow, Stop}, d = {Up, Down, Stop} • CarLantern[d](v): Com mands to con trol the car lan tern lights; Up/Down lights on the car doorframe used by pas sen gers to de ter mine the el e va tor's cur rent trav el ing di rec tion.• CarLight[f](v): Com mands to con trol the car call but ton lights in side the car call but tons to in di cate when a floor has been se lected.• CarPositionIndicator(f): Com mands for po si tion in di ca tor light in the car that tells us ers what floor the car is ap proach ing.•

Figure 2 .
Figure 2. Feature Subset Graphs of the Door and Drive Control Subsystems

Figure 3 .
Figure 3. Feature Subset Graphs of the Safety Monitor Subsystem = 16 pos si ble con fig u ra tions of the other four fea ture sub sets in the sys tem.Once we spec ify the rel a tive util i ties of these 16 con fig u ra tions in ad di tion to the 404 to tal fea ture sub set con fig u ra tions, we can com pletely spec ify the sys tem util ity func tion.We have greatly re duced the num ber of con fig u ra tions we must eval u ate from 4.27 * 10 22 sys tem com po nent con fig u ra tions to 420 fea ture sub set con fig u ra tions to as sess the sys tem's abil ity to grace fully de grade.

and Lights {1 … f} Car Call Button Sensors,, Controllers, and Lights Dispatcher Controller {1 … f} Virtual AtFloor Controllers {1 … f} AtFloor Sensors Sensor Software Component Actuator Hardware Node Network Connection Figure
1. Hardware View of the Elevator Control System

Subset Boundary Sensor Software Component Feature Subset Actuator Weak Dependence Optional Strong Dependence
19 + 11fpos si ble sys tem con fig u ra tions.The sys tem can pro vide ba sic func tion al ity if the min i mum com po nents nec es sary to op er ate the drive mo tor, door mo tors, and main tain safety are pres ent.Thus these 17 com po nents (Drive Con trol ler soft ware, drive speed sen sor, drive mo tor, Left and Right Door Con trol ler com po nents, left and right door mo tors, all door sen sors, Safety Mon i tor soft ware, hoistway limit sen sors, emer gency brake ac tu a tor) are fixed and must be pres ent in ev ery valid con fig u ra tion.All other com po nents (such as the but ton lights and sen sors and pas sen ger feed back lights) can be con sid ered op tional and pres ent in any con fig u ra tion.There are 1 + 9f op tional com po nents that can have 2 1 + 9f pos si ble con fig u ra tions.Enough com po nents to pro vide work ing AtFloor fea ture sub sets for each floor must be pres ent as well.There fore, on each floor there must be a work ing AtFloor sen sor or a work ing VirtualAtFloor com po nent with a work ing Car Po si tion sen sor.If the Car Po si tion sen sor breaks, then all AtFloor sen sors must work.Since all the AtFloor sen sors must work in this sit u a tion, they are fixed and have one con fig u ra tion.How ever, the VirtualAtFloor com po nents can ei ther work or not work since their fail ure

Table 1 .
Valid Configurations in each Feature Subset

Configuration Utility Values Elevator Performance 1/(Average Pass. Travel Time (s)) Figure 8. Utility
vs. Average Performance for Selected Elevator System Configurations