Using Architectural Properties to Model and Measure System-Wide Graceful Degradation

Transcription

1 Research CMU Institute for Software Research School of Computer Science 2002 Using Architectural Properties to Model and Measure System-Wide Graceful Degradation Philip Koopman Charles Shelton Follow this and additional works at: This Working Paper is brought to you for free and open access by the School of Computer Science at Research CMU. It has been accepted for inclusion in Institute for Software Research by an authorized administrator of Research CMU. For more information, please contact research-showcase@andrew.cmu.edu.

2 Using Architectural Properties to Model and Measure System-Wide Graceful Degradation Charles P. Shelton ECE Department Pittsburgh, PA, USA Philip Koopman ECE Department Pittsburgh, PA, USA ABSTRACT 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 initial work on a component-based 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 example distributed embedded control system and report on initial results. 1. INTRODUCTION De pend abil ity is a term that cov ers many sys tem prop er ties such as reliability, availability, safety, main tain abil ity, and se cu rity [4]. Sys tem de pend abil ity is especially important for embedded com - puter con trol sys tems, which per vade ev ery day life and can have se - vere con se quences for failure. These sys tems increasingly im ple ment a significant portion of their func tion al ity in software, making soft ware dependability a ma jor is sue. Graceful degradation may be a vi a ble approach to achiev ing better software dependability. If a software sys tem can gracefully degrade automatically when faults are de tected, then in di vid ual soft ware component fail ures will not cause com plete system fail ure. Rather, component fail ures will re move the func tion al ity derived from that com po nent, while still pre serv ing the operation of the rest of the system. Specifying and achiev ing system-wide grace ful degrada - tion is a dif fi cult re search prob lem. Cur rent approaches require specifying ev ery system fail ure mode ahead of time, and designing a specific response for each such mode (e.g., [2]). This is im prac ti - cal for a com plex software system, es pe cially a fine grained distrib - uted em bed ded system with hun dreds or thou sands of soft ware and hardware components. In or der to eval u ate and improve system-wide grace ful deg ra da tion, we pres ent a com po nent-based sys tem model that pro vides a means for evaluating and pre dict ing how well a system should gracefully degrade, as well as how graceful degradation in flu ences de pend - abil ity properties. We base the model on us ing the sys tem s inter - face definitions and component con nec tions to group the sys tem s components into subsystems. We hypothesize that the soft ware ar - chitecture, responsible for the overall organization of and connec - tions among components, can facilitate the system s ability to im plic itly provide the property of graceful deg ra da tion, without specifying a response to each pos si ble fail ure mode at de sign time. We de fine a fail ure mode to be a set of system components failing con cur rently. By us ing the model to mea sure how gracefully a sys - tem degrades, we predict that we can identify what ar chi tec tural prop er ties facilitate and im pede system-wide graceful degradation. Related to our con cept of grace ful deg ra da tion is the term sur viv - ability. Sur viv abil ity is another prop erty of dependability that has been pro posed to ex plic itly de fine how systems will degrade func - tion al ity in the pres ence of fail ures [3]. Our work differs from sur - viv abil ity specifications in that we are interested in building implicit graceful deg ra da tion into sys tems with out specifying fail - ure scenarios a pri ori, and hav ing the sys tem do the right thing in the presence of component fail ures. Also, we are fo cus ing on dis - tributed em bed ded sys tems rather than on large-scale critical infra - structure information sys tems. The re main der of this pa per is organized as follows. Sec tion 2 de - scribes our ini tial system model and key assumptions. Section 3 de - scribes our rep re sen ta tive dis trib uted embedded system and its ar chi tec ture, and ap plies our model to this architecture. Sec tion 4 in cludes discussion about the model s predictions, and how they compare to ini tial fault injection tests we ran with a simulated ver - sion of the con trol sys tem. Sec tion 5 wraps up with con clu sions and future work. 2. SYSTEM MODEL As a first step, we are con cen trat ing on software ar chi tec ture at a high level of ab strac tion. Our sys tem model initially fo cuses on the func tion al ity components of the system: soft ware, sen sors, and ac tu a tors. We make the ini tial assumptions that individual soft ware components each have their own pro cess ing elements, that there is enough network band width to transmit all needed sen sor val ues, and that there are enough system re sources to sat isfy real-time re - quire ments. These system aspects will all in flu ence sys tem-wide grace ful deg ra da tion, but we are planning to in clude them in the model at later stages. We con sider a sys tem as a set of soft ware, sensor, and ac tu a tor com - ponents. We use the interfaces among components to de fine a set of sys tem vari ables through which all components com mu ni cate. These variables can represent any com mu ni ca tion struc ture in the

3 software implementation. Actuators receive in put vari ables and out put to the environment, while sen sors receive in put from the en - vironment and out put sys tem variables. We as sume that compo - nents can ei ther be in one of two states: work ing or failed. Working means that the component has enough re sources to out put its spec i - fied sys tem vari ables. Failed means the component can not pro duce its specified out puts. The fault model for our system uses the tra di tional fail-fast, fail si - lent as sump tion. All faults are man i fested as the loss of system vari - able communication among com po nents. Com po nents ei ther provide their out put variables or do not. Thus, fail ures can be de - tected when com po nents do not provide their out puts when spec i - fied. This does not ac count for more complex types of fail ures such as providing invalid but syn tac ti cally cor rect in for ma tion, and as - sumes component fail ures can be quickly de tected. Fault detection and prop a ga tion issues are challenging research ar eas in and of them selves, and are out side the scope of this work. Ad di tionally, since soft ware component fail ure rates are difficult to iden tify, we make an ini tial assumption that all components have approximately equal fail ure rates. A key con cept in our model is the no tion of utility. Util ity is a mea - sure of how much ben e fit can be gained from the en tire sys tem, a certain subsystem, or an in di vid ual com po nent. For the en tire sys - tem, the overall utility is determined by a non lin ear function of its individual sub sys tem util i ties. Each subsystem s utility is deter - mined by a non lin ear func tion of its in di vid ual component util i ties. For in di vid ual components, we de fine a component s utility to be 1 when work ing and 0 when failed. We as sume that if all components are work ing the system will be at its maximum util ity, and if all components are failed, the sys tem will have an overall utility of zero. Thus, a sys tem grace fully de grades if in di vid ual component and sub sys tem fail ures re duce sys tem utility grad u ally. In our model, we initially con cen trate on mea sur ing whether the system has zero or positive overall util ity by iden ti fy ing how resis - tant critical sub sys tems are to component fail ures. De ter mining the functions that quan ti ta tively mea sure how work ing com po nents im - prove subsystem and sys tem utility val ues is a challenging problem. However, with out know ing these func tions we can initially make a dis tinc tion between a sys tem that is work ing and has positive but not necessarily maximum utility, and a failed system that has zero util ity. In or der to make this distinction we must have a clear defini - tion of what working means for the en tire system. In other words, we must specify what fea tures of the sys tem are nec es sary for the system to com plete its primary functions. In most cases, this is not all the fea tures avail able in the system. For example, the primary func tion of a car is to provide transportation. Critical fea tures nec - essary for the car to continue work ing include engine and transmis - sion con trol, brakes, and steering. The power windows, emis sions control, air conditioning, and ra dio provide auxiliary func tion al ity not nec es sary for the car to com plete its primary task, and can be lost with out caus ing a cat a strophic fail ure. The system can have many dif fer ent com po nent con fig u ra tions based on which components are work ing or failed. If n is the num - ber of com po nents in the system, then there are 2 n dif fer ent con fig u - rations that can be considered. The sys tem s component configuration de ter mines the util ity of all its sub sys tems, and thus the utility of the en tire sys tem. An ide al gracefully degrading sys - tem is one where a large frac tion of these 2 n configurations result in a sys tem with overall pos i tive utility; i.e., the sys tem can tolerate mul ti ple com bi na tions of component fail ures and still provide use - ful func tion al ity. Our first metric for grace ful deg ra da tion is the system s re sis tance to com plete failure (zero system util ity). We determine this value by look ing at how many con fig u ra tions re sult in a system with pos i - tive utility. The ratio of log 2 [num ber of valid com po nent configura - tions] / n gives a mea sure of how many con fig u ra tions will provide utility rel a tive to the total num ber of system con fig u ra tions. This value is 0 (only one valid configuration) for a brittle sys tem, and 1 for a perfect sys tem where any com po nent configuration can pro - vide some utility (ig nor ing the trivial configuration of zero compo - nents that results in no system at all). Clearly, if we had to con sider the utility of ev ery possible compo - nent con fig u ra tion individually, then specifying graceful degrada - tion be comes exponentially difficult as the num ber of components in creases. However, we can use the system s software architecture, which de fines system software com po nents, in put and out put inter - faces, and con nec tions among components, to group components into sub sys tems according to the sys tem variables they pro vide, and thus re duce complexity. We define these sub sys tems in our component model as feature sub - sets. A fea ture subset 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 subsets) that work to - gether to provide a set of output vari ables. Fea ture sub sets may or may not be dis joint and can share components across dif fer ent sub - sets. Fea ture sub sets have util ity val ues based on which of their components are working, and con trib ute to overall sys tem utility. A feature subset is critical if its func tion al ity is re quired by the sys tem; i.e., the total sys tem utility is zero whenever any critical feature sub - set has zero util ity. Thus, the system will have positive util ity if and only if all of its crit i cal fea ture sub sets have pos i tive util ity. If we view the sys tem as a set of feature sub sets rather than in di vid ual components, then we should only need to consider valid component configurations of critical fea ture subsets rather than con fig u ra tions of all system com po nents to determine how well the sys tem grace - fully de grades. In addition to group ing com po nents into fea ture subsets, we de fine a set of dependency re la tion ships between feature subsets and their components. A fea ture subset may have strong dependence on some of its com po nents, weak dependence on others, and some of its components may be completely op tional. A fea ture subset strongly de pends on one of its components if the loss of that compo - nent re sults in the feature sub set s hav ing zero util ity. A fea ture sub - set weakly de pends on one of its com po nents if the loss of that component re duces the fea ture sub set s utility to zero in some, but not all, con fig u ra tions in which that component was working. For ex am ple, if there are two com po nents that out put a re quired sys tem variable, loss of both will re sult in the fea ture sub set hav ing zero util ity, but loss of only one or the other will not. If a component is op tional to a feature subset, then it may pro vide enhancements to the feature subset s utility, but is not critical to the operation of the feature subset. Ev ery valid component configuration of the fea ture sub set where that component is work ing still provides positive (but pos si bly lower) utility when that component is broken. These de - pendency re la tion ships can also ex ist among in di vid ual compo - nents as well, based on their in put and output in ter faces. A component that re quires a certain sys tem vari able as an in put will de pend on the components that provide it as an out put. We can use this model to de velop a space of sys tems with varying degrees of graceful deg ra da tion. At one end of the spec trum, we have extremely brittle systems that are not capable of any grace - ful deg ra da tion at all. In these systems, any one component fail ure will result in a com plete system failure. In our model, this would be a system where ev ery component is within a critical fea ture subset,

4 Table 1. Sensors, Actuators, and Software Components in the Elevator Architecture Sensor Type # Output Vari able Ac tu a tor Type # Input Variable Soft ware Com po nent # Output Vari able DriveSpeed 1 DriveSpeed Drive Motor 1 DriveMotor Drive Control 1 DriveMotor CarPosition 1 CarPosition Motor 1 Motor Control 1 Motor AtFloor f AtFloor[f] Emergency Brake 1 EmergencyBrake Safety 1 EmergencyBrake HoistwayLimit 2 HoistwayLimit[d] Car Lanterns 2 CarLantern[d] Dispatcher 1 DesiredFloor Closed 1 Closed Car Position Indicator 1 CarPositionIndicator Vir tualatfloor f AtFloor Opened 1 Opened Car Button Lights f CarLight[f] Lantern Control 2 CarLantern[d] Reversal 1 Reversal Hall Button Lights 2f-2 HallLight[f,d] Car Po si tion In di ca tor Control 1 CarPositionIndicator Car Buttons f CarCall[f] Car But ton Control f CarLight[f] Hall Buttons 2f-2 HallCall[f,d] Hall But ton Control 2f-2 HallLight[f,d] and each fea ture subset strongly de pends on all of its com po nents. Therefore, ev ery component must be func tion ing to have pos i tive system util ity. Sim i larly, any mod u lar re dun dant system can be represented as a col lec tion of several crit i cal feature subsets, where each fea ture sub - set con tains multiple cop ies of a component plus a voter. The valid configurations that provide pos i tive util ity for each fea ture subset are those that contain the voter plus one or more component copies. This redundant sys tem can tol er ate multiple fail ures across many feature subsets, but can not tol er ate the fail ure of any one voter or all the component copies in any one feature subset. At the other end of the spectrum, an ideal gracefully degrading sys - tem is one where any com bi na tion of component fail ures will still leave a system with positive utility. In our model, this system would be one where none of its fea ture sub sets would be la beled as critical, and ev ery com po nent would be completely op tional to each fea ture sub set in which it was a member. The system would con tinue to have positive utility until ev ery com po nent failed. 3. EXAMPLE SYSTEM: A DISTRIBUTED ELEVATOR CONTROL SYSTEM To il lus trate how we can ap ply our sys tem model to a control sys - tem, we will use a model of a relatively complex distributed eleva - tor control system. The com plete de tails of the model have been pub lished in [6], but we will de scribe a portion of the system and the software ar chi tec ture here for clar ity. The gen eral requirement for an el e va tor is that it must safely trans - port peo ple among floors in a build ing. The control sys tem has a set of sen sors (door opened/closed, elevator speed, button sen sors, etc.) for de ter min ing the cur rent en vi ron ment and pas sen ger requests, a set of actuators (door motor, drive motor, emergency brake, lights, etc.) for performing tasks and informing pas sen gers about sys tem state, and a set of soft ware ob jects (door controller, drive controller, dispatcher, etc.) that im ple ment the control logic to per form the ele - va tor s func tions. Table 1 summarizes the list of sen sors, actuators, and soft ware com - ponents in the elevator control system. In the table, f rep re sents the number of floors in the el e va tor s building, and d rep re sents a choice of two directions, up or down. For example, there are f floor sen sors and f car button sen sors (one for each floor), two hoistway limit sensors (the up sen sor is at the top of the hoistway, and the down sen sor is at the bottom), and 2f - 2 hall but ton sensors (two per floor in each di rec tion, ex cept for the top and bot tom floors, which only have one but ton). In the ta ble each sensor has a spec i - fied out put vari able, and each ac tu a tor has a specified in put vari - able. The soft ware components have sev eral in puts and a few out puts. There are a total of f components in the sys tem. The system s soft ware ar chi tec ture de fines each component s input and out put interface, as well as con nec tions among components, which can be used to construct the system s feature subsets. Fig ure 1 shows the crit i cal fea ture sub sets of the system, and the de pend en - cies between the fea ture subsets and components. Each ar row in the figure represents a sys tem vari able being communicated between components. In an elevator control system, the only critical func - tions of the elevator are that it must be able to ser vice all floors, open and close the doors, and en sure the safety of the passengers. All other functionality, such as re spond ing to pas sen ger re quests, pro - vid ing pas sen ger feed back, and minimizing wait time and travel time, are enhancements over the ba sic elevator re quire ments. Therefore, the critical fea ture subsets for this system are only the feature subsets that are required to operate the drive motor, door motor, and emergency brake ac tu a tors. The soft ware components are de signed to have a default behavior 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 Control and Drive Control com po nents can lis - ten to each other s com mand out put variables in addition to the Drive Speed and Closed sen sors to synchronize their behavior (open the doors more quickly after the car stops), but only the sensor val ues are necessary for cor rect be hav ior. Likewise, the Drive Con - trol component has a de fault behavior that stops the elevator at ev - ery floor, but if the DesiredFloor vari able is avail able from 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 Control compo - 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 arrives. We also enumerated the other non-crit i cal fea ture subsets in the ele - vator system such as the var i ous passenger feed back lights in the el - evator, but we omit them here for the sake of brevity. 4. ANALYSIS In or der to de rive the grace ful deg ra da tion met ric for our elevator control system, we need only con sider the critical fea ture sub sets and the components upon which they depend. There fore, all config - u ra tions con tain ing enough components to provide work ing Drive

5 Emergency Brake Drive Motor Motor Safety Component Safety Drive Control Component Drive Control Control Component Control Desired Floor Drive Control Drive Speed Hoistway Closed Limits Drive Speed Closed Subset Software Component Sensor Actuator Strong Dependence (Necessary for all configurations) Weak Dependence (Necessary for some configurations) Optional (Provides non-critical utility enhancement) Car Position Control Sensors Desired Floor Car Drive Position Speed Drive Speed Virtual Components Closed Opened Reversal Figure 1. Critical Subsets in the Elevator Control System Car Buttons Car Button Sensors Hall Buttons Hall Button Sensors Diagram uses multiple identical components in different places for clarity. Components/ subsets with the same name actually represent only one component or feature subset in the system. Optional feature subsets not shown: Car Button Lights, Hall Button Lights, Car Position Indicator, Car Lanterns Con trol, Con trol, Safety, and AtFloor feature subsets are valid, and can con tain any ar bi trary com bi na tion of other optional system components. There are 1 + 9f optional system components (which can be arranged in f different ar bi trary com bi na tions), leav ing f crit i cal com po nents (components within critical fea - ture sub sets) that have con fig u ra tions that require ex am in ing (and f component com bi na tions left to con sider in di vid u ally). By ex am in ing the critical fea ture subsets, we can see that they are strongly dependent on the Drive Speed, Closed, Opened, Re ver sal, and Hoistway Limits sen sors, the Drive Con trol, Con trol, and Safety soft ware components, and the Drive Mo - tor, Motor, and Emergency Brake ac tu a tors. Any valid con - fig u ra tion must have all of these twelve components present. Therefore, we can restrict the number of con fig u ra tions we cal cu - late by not considering any con fig u ra tions in which these compo - nents are bro ken. This leaves 1 + 2f components (the Car Po si tion sensor, the AtFloor sen sors, and the VirtualAtFloor soft ware com po nents) in the AtFloor fea ture subset to be considered. By ex am in ing the critical feature subsets, we have sys tem at i cally reduced the graceful degra - da tion cal cu la tion from con sid er ing f com bi na tions to f com bi na tions. Now we can determine the num ber of valid con fig u - rations for the AtFloor fea ture by not ing that all floors must be ser - viced by the elevator. Therefore, on each floor there must be a work ing AtFloor sensor or a work ing VirtualAtFloor component with a work ing Car Po si tion sen sor. If the Car Po si tion sensor breaks, then all AtFloor sen sors must work. Since all the AtFloor sensors must work in this situation, they are fixed and have one con - fig u ra tion. However, the VirtualAtFloor components can ei ther work or not work since their fail ure will not affect the avail abil ity of the AtFloor sys tem variables, making 2 f valid com bi na tions for the various VirtualAtFloor components. If the Car Position sensor works, then one or both AtFloor sensor and VirtualAtFloor compo - nent must work for each floor, so the only invalid 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, making 3 f valid com bi na tions out of the possible 2 2f. Thus there are 2 f + 3 f valid com bi na tions of compo - nents in the AtFloor fea ture subset. Multiplying this with the num ber of com bi na tions of optional com - ponents results in a total of (2 f + 3 f )( f ) valid component con fig - urations. Taking the base 2 log of this and di vid ing it by the total number of system components ( f) gives us our grace ful deg - ra da tion met ric. If we calculate this value for an elevator that serves seven floors, we get For com par i son, we also con sider an el e va tor sys tem that does not con tain any VirtualAtFloor software components. The VirtualAtFloor com po nents improved the system s ability to grace - fully de grade be cause they pro vided a way to com pen sate for AtFloor sensor fail ures by us ing in for ma tion provided by other sys - tem sen sors to syn thesize AtFloor sen sor values. There fore, if we re move the VirtualAtFloor components, the re sul tant system should also receive a lower graceful deg ra da tion value. In our model, the re moval of the VirtualAtFloor components re - duces the AtFloor fea ture sub set to be ing strongly de pend ent on all of the AtFloor sensors. There fore there is only one valid configura - tion for the AtFloor fea ture sub set in which ev ery AtFloor sensor must work. Since this is a critical feature subset, all valid sys tem configurations must con tain a work ing AtFloor fea ture subset. Ad - di tionally, the Car Po si tion sen sor be comes an op tional sys tem com - ponent be cause the AtFloor feature sub set no lon ger de pends on it. This re sults in there be ing only f valid system con fig u ra tions since most of the components in the critical fea ture sub sets must work and only the op tional components can have multiple valid con fig u ra tions. The total num ber of sys tem components is also re - duced by the re moval of the f VirtualAtFloor components, leaving f total system components. For a seven-floor elevator, this re sults in a graceful deg ra da tion score of The graceful deg ra da tion metric pro vides a con crete comparison among sim i lar systems. We can quan ti ta tively as sess how add ing or subtracting components to the system affects its ability to grace fully degrade. However, this metric may be misleading when comparing two systems that are substantially dif fer ent in terms of functionality and num ber and type of system com po nents. We have developed a discrete event sim u la tor that implements our el e va tor architecture, and have run some initial fault injection ex -

6 per i ments to eval u ate whether the im ple mented system actually grace fully degrades. So far, ev ery test we have run with one of the pos si ble valid con fig u ra tions was able to successfully deliver all pas sen gers to their destination floors, including a test that fail ed all components but the crit i cal ones and the AtFloor sen sors. 5. CONCLUSIONS AND FUTURE WORK We have dem on strated a com po nent-based sys tem model that can provide in sight into how well a sys tem will per form graceful degra - da tion in the presence of multiple component fail ures. We de vel - oped an ini tial metric for graceful deg ra da tion that indicates how many com bi na tions of component fail ures can be tol er ated by ex - am in ing critical subsystem con fig u ra tions rather than considering ev ery pos si ble sys tem component configuration. In some ini tial ex - per i ments on a sim u lated im ple men ta tion of the example control system stud ied, we found that the ar chi tec ture described was resis - tant to cer tain com bi na tions of component failures, as pre dicted by the model. We did not incorporate fail ure re cov ery scenarios for ev ery pos si ble combination of com po nent fail ures, but rather built the soft ware components to the architectural spec i fi ca tion. The in di vid ual com - ponents were designed to ig nore optional in put variables when they were not avail able and fol low a default be hav ior. This is a fun da - men tally dif fer ent approach to system-wide grace ful degradation than specifying all pos si ble fail ure combinations to be handled ahead of time. Properties of the soft ware ar chi tec ture such as the component inter - faces and the iden ti fi ca tion and partitioning of critical system func - tion al ity from the rest of the system seem to be key to achieving system-wide graceful deg ra da tion. The model we developed il lus - trates how well a system can grace fully degrade by us ing the soft - ware ar chi tec ture s com po nent connections to decompose the system. We are also ex plor ing how to use an architectural de scrip - tion language such as Acme [1] to provide rig or ous component in - terface specifications and facilitate de vel op ment of our sys tem model. For this par tic u lar system, it is relatively easy to calculate the possi - ble valid con fig u ra tions by ex am in ing the soft ware ar chi tec ture without the model. However, the model pro vides a sys tem atic frame work for partitioning the system based on its soft ware ar chi - tec ture, and we hypothesize that it will be useful in evaluating any ar chi tec tural spec i fi ca tion that has a well-de fined component inter - face. This frame work al lows us to mea sure the grace ful deg ra da tion prop er ties of in di vid ual fea ture sub sets with respect to their compo - nents as well. The ar chi tec ture and model also identify a set of crit i - cal system components within the crit i cal feature sub sets that must continue to op er ate to provide any sys tem functionality. This can be used to determine on which sys tem components to spend effort en - sur ing component re li abil ity through redundancy and other fault tol er ance mea sures. Our next step is to extend this model to incorporate the al lo ca tion of the soft ware com po nents to hard ware units. In a distributed system, components that com mu ni cate via the network are strongly de pend - ent on the network for their required in put vari ables, mak ing the net work a sin gle point of failure. Also, software com po nents are strongly de pend ent on the hard ware node on which they are hosted. These con straints will surely in flu ence a sys tem s abil ity to grace - fully degrade (hard ware fail ures might re move multiple compo - nents si mul ta neously), but may be ameliorated by sys tem-wide reconfiguration as pro posed in [5]. Ad di tionally, we want to fur ther develop the con cept of system utility to not only dis tin guish be - tween when the system is bro ken or not bro ken, but also differ - ent levels of func tion al ity avail able in dif fer ent sys tem con fig u ra tions. We have iden ti fied which con fig u ra tions result in sys tems with pos i tive util ity, but we also need to quan ti ta tively de - termine which of those con fig u ra tions have higher utility than oth - ers. This will be based on de ter min ing which fea tures are more useful than oth ers based on mea sures such as per for mance and func - tion al ity. 6. ACKNOWLEDGMENTS This work was sup ported by the Gen eral Mo tors Satellite Research Lab at, and Lu cent Tech nol ogies. Thanks to Beth Latronico, Bill Nace, Orna Raz, and Yang Wang for their help in de vel op ing the ideas pre sented. 7. REFERENCES [1] Garlan, D., Monroe, R.T., Wile, D., Acme: Architectural Description of Component-Based Systems, Foundations of Component-Based Systems, Leavens, G.T., Sitaraman, M. (eds), Cambridge University Press, 2000, pp [2] Herlihy, M. P., Wing, J. M., Specifying Graceful Degradation, IEEE Transactions on Parallel and Distributed Systems, vol.2, no.1, pp , [3] Knight, J.C., Sullivan, K.J., "On the Definition of Survivability," University of Virginia, Department of Computer Science, Technical Report CS-TR-33-00, [4] Laprie, J.-C., "Dependability of Computer Systems: Concepts, Limits, Im prove ments", Pro ceed ings of the Sixth In ter na tional Symposium on Software Reliability Engineering, Toulouse, France, Oct. 1995, pp [5] Nace, W., Koopman, P., A Product Family Approach to Graceful Degradation, Distributed and Parallel Embedded Systems (DIPES), October [6] Shelton, C., Koopman, P., Developing a Software Architecture for Graceful Degradation in an Elevator Control System, Workshop on Reliability in Embedded Systems (in conjunction with Symposium on Reliable Distributed Systems/SRDS-2001), October 2001, New Orleans, LA.