High Dependability Computing Program Modeling Dependability The Unified Model of Dependabil

High Dependability Computing Program Modeling DependabilityThe Unified Model of DependabilityVictor BasiliPaolo DonzelliSima AsgariComputer Science DepartmentUniversity of MarylandCollege Park, Maryland 20742Technical Report CS-TR-4601 - UMIACS-TR-2004-43June 2004AbstractIndividuals and organizations increasingly use sophisticated software systems from which they demand great reliance. “Reliance” is contextually subjective and depends on the particular stakeholder’s needs; therefore, in different circumstances, the stakeholders will focus on different properties of such systems, e.g., continuity, availability, performance, real-time response, ability to avoid catastrophic failures, capability of resisting adverse conditions, and prevention of deliberate privacy intrusions. The concept of dependability enables these various concerns to be subsumed within a single conceptual framework.Achieving dependability is a major challenge, which has spawned many efforts both at national and international levels. This work is part of the High Dependability Computing Program (HDCP), a five-year cooperative research agreement between NASA and various universities and research centers to increase NASA’s ability to engineer highly dependable software systems.HDCP brings together, under the common goal of improving systems dependability, a large and heterogeneous group of actors, from industry and academia alike, with various perspectives, and different (sometimes even conflicting) needs. Thus, the polysemous nature of the concept of dependability, while unifying so many different efforts, brings also the risk of creating confusion, making the task of developing dependable systems even more difficult.From this perspective, the Unified Model of Dependability (UMD) aims to establish a common language for discussing a variety of dependability attributes, and to make them measurable. To capture stakeholders’ dependability needs and perspectives, UMD takes into account different aspects of a dependability attribute, including the affected system functionalities, the acceptable manifestation of a specific failure (hazard) or class of failures (hazards), the external events (adverse conditions, attacks, etc.) that can create an unreliable system, and the expected system reaction to mitigate failures (hazards) impact over the stakeholders.By providing a structured approach to eliciting and organizing both functional and non-functional dependability requirements, UMD helps the stakeholders to better express their needs, understand interactions among the dependability attributes, and set the corresponding values.In order to illustrate the features and capabilities of UMD, an Air Traffic Control System is used as case study.Table of Contents1 Introduction (4)2 The Unified Model of Dependability (UMD) (6)2.1 Identifying the building blocks of dependability (6)2.2 “Robustness” of UMD (10)2.3 UMD to capture stakeholders dependability needs (14)dependability (16)2.4 Measuring2.5 Enhancing UMD: capturing the “System Reaction” (17)2.6 The UMD Tool (19)3 Applying UMD to build a System Dependability Model (19)3.1 The case study – TSAFE (19)Gathering (21)3.2 DataAnalysis (24)3.3 Data4 Formalizing the UMD application process (28)4.1 The single-stakeholder scenario (28)4.2 The multiple-stakeholder scenario (29)5 Conclusions and future work (30)6 References (31)Appendix A – Description of the UMD Tool (33)1 IntroductionIndividuals and organizations increasingly use sophisticated software systems from which they demand great reliance. “Reliance” is contextually subjective and depends on the particular users’ needs, therefore, in different circumstances, stakeholders will focus on different properties of such systems, e.g., availability, performance, real-time response, ability to avoid catastrophic failures, capability of resisting adverse conditions, and prevention of deliberate intrusions, as well as different levels of adherence to such properties. The concept of dependability enables these various concerns to be subsumed within a single conceptual framework. The International Federation for Information Processing (IFIP) WG-10.4 [7] defines dependability as the trustworthiness of a computing system that allows reliance to be justifiably placed on the services it delivers.Achieving systems dependability is a major challenge, and it has spawned many efforts at the national and international level, such as the European Dependability Initiative [14], the US Government strategy “Trust in cyberspace” [15], or the Critical Infrastructures improvement and protection initiatives adopted by various countries [10,16]. This work is part of the High Dependability Computing Program (HDCP), a five-year cooperative research agreement between NASA and various universities and research centers1, to increase NASA’s ability to engineer highly dependable software systems. The Program involves: a) understanding NASA’s dependability problems; b) developing new engineering practices and technologies to address such problems; c) empirically assessing (and iteratively improving) the capabilities of new practices and technologies, using realistic testbeds; d) transferring technologies to technology users with clear indications about their effectiveness under varying conditions.HDCP brings together, under the common goal of improving systems dependability, a large and heterogeneous group of actors, from government and academia alike, with various perspectives, and different (sometimes even conflicting) needs. First, there are the actors directly involved in using, building, and developing systems or technologies: • The system users, who are concerned mainly about the final system’s behavior, and who need to understand whether or not, and to what extent, they can depend upon a system to achieve their goals.• The system developers (or technology users), who need to know which processes and or technologies should be selected to meet the system users’ needs in the most efficient and effective way.• The technology researchers/developers, who focus on specific means to develop dependable systems [1].• The empiricists, whose role is to help the users define dependability needs, support the developers in selecting the right approaches, and provide empirical evidence of the technology’s ability to meet those needs. The empirical researchers act as “observers” to support the transfer of knowledge (needs, opportunities, technologies’ capabilities and limits) among the other actors.1 The universities and research centers involved in HDCP are: Carnegie Mellon, University of Maryland, Fraunhofer Center Maryland, University of Southern California, Massachusetts Institute of Technology, University of Washington, University of Wisconsin, and many othersThe success of the program depends on the synergic collaboration of all these actors. It would be valuable to have a common and operational definition of dependability that allows:• The system users to express their needs (i.e. build a precise dependability model of the required system), in such a way that can be understood, and eventually addressed by the others;• The system developers to clearly compare what they are delivering with what requested by the users;• The technology researchers/developers to make explicit their goals in terms of the impact of their technology over dependability;• The empirical researchers to measure, and make explicit what is achievable and what has been achieved. For example, the gap between users’ demands and developers’ products, or between technology developers’ claims and actual technologies performances. This means to be able to identify the “good” practices and support their transfer.Many definitions of dependability have been provided in the literature, see for example [1,7,8,9,11]. However, they are mostly general and qualitative. It may not be possible to find a common and operational definition of dependability. To be operational, in fact, a definition needs to be strictly related to the specific context it refers to (the project and its stakeholders). For this reason, we have adopted an alternative approach. Rather than stating yet another definition of dependability, we are identifying a framework for modeling dependability that the different actors could adopt as a common language, enabling them to communicate and understand each other’s needs.Figure 1. A framework to foster cooperationThis paper is organized as follows. Section 2 introduces the Unified Model of Dependability (UMD), by illustrating its underlying concepts. It discusses its robustness, and shows how UMD can be used to capture the users’ dependability needs (or more precisely the stakeholders’ needs [18]), to build dependability models of individualsystems. A comparison with related work is also provided. Section 3 shows how the UMD can be customized to a specific context/project to obtain a system dependability model that can be used as operational dependability definition. A case study is used for illustration. Section 4 formalizes the process for applying UMD in both a single and a multi-stakeholder scenario. Finally, Section 4 provides an outline of the future work.2 The Unified Model of Dependability (UMD)This Section introduces UMD, by illustrating the underlying theory, and discusses its robustness. It also provides a comparison with related works.2.1 Identifying the building blocks of dependabilityDependability involves many different attributes, and each attribute can be defined in a variety of ways. In order to begin our analysis for identifying the building blocks of dependability, around which we build UMD, let us consider a standard sub-set of such attributes: reliability, accuracy, performance, availability, survivability, security, maintainability, and safety. It is important to note that this choice is purely arbitrary, and any other set could have been adopted, as in the following we will show that our results are independent from the selected set. For each of these attributes different definitions are available in literature. In the following we have randomly chosen some of them from [1,4,9,13]:o Reliability is an index of how often the system or part of it fails.o Accuracy is the ability of the system to provide data within the desired range and with the required precision.o Performance is a static or dynamic system’s capability (response time, throughput) defined in terms of an acceptable range.o Availability is the degree to which a system or component is operational and accessible when required for use.o Survivability is the ability of a system to provide essential services in the presence of adverse conditions that can occasionally happen within its operational environment(e.g., exceptional weather conditions, un-natural load peaks, etc.).o Security is the system’s capability to resist attacks intentionally carried on against the system (e.g., logical breaches, data accesses, denial of service attacks, etc.).o Maintainability is the ability of the system to undergo repairs and modifications.o Safety is the absence of catastrophic consequences on the user(s) and the environment.Based on the above definitions, we observe that dependability can be viewed as an index of the issues that the system can cause to the users. In other terms, given two similar systems, the one that causes fewer, and less severe issues is the one that is more dependable for the users. By carefully reading the above definitions, we can also recognize that an issue may derive from the misbehavior of the system (e.g., the system fails, or is not available at a given time, or is not able to survive external adverse conditions), or because the system creates a situation that could lead to catastrophic consequences for the users or the environment (see definition of safety). For this reasons, we distinguish between two kinds of issues:• Failure: any departure of the system behavior from the user’s expectations.• Hazard: a state of the system that can lead to catastrophic consequences for the user(s) and the environment.Note that the concepts of hazard and failure are not exclusive, but overlap: a failure may be also a hazard (i.e. a failure can lead to an accident), whereas a hazard can occur without a failure occurring. Given the chosen set of dependability attributes, then, we can further distinguish failures into different failure types:• Accuracy failure: the departure of the system behavior from providing data within the desired range and with the required precision;• Performance failure: the departure of the system behavior from providing the desired static or dynamic capability (response time, throughput);• Other failure: any failure that cannot be classified as accuracy or performance failure.In addition, having availability among the chosen dependability attributes, we can also distinguish failures according to their impact upon availability. For example, we can distinguish between:• Stopping failure is any failure that makes the system unavailable.• Non-Stopping failure is any failure that does not make the system unavailable.It is worth noting that the above classifications in terms of Failures Types (accuracy, performance, other) and Failure impact over availability (stopping, non-stopping) are orthogonal.The same observations can be repeated for the hazards. Based on the above definition of safety, in fact, we can distinguish different hazards types:• User(s) Hazard: a state of the system that can lead to catastrophic consequences for the user(s);• Environment Hazard: a state of the system that can lead to catastrophic consequences for the environment.Finally, from the above definitions (see for example reliability), we can also observe that the issues caused to the users by a system could result from the misbehavior of the whole system or of part of it, for example, a service or component. Thus, we can characterize an issue in terms of the part of the system that it affects. We distinguish the scope:• The system, i.e., the whole system;• A service, i.e., a functionality delivered by the system, as perceived by the users (a human or another interacting system).From this initial analysis, thus, it results that some concepts are common across the different definitions, however, with different degrees of commonality and independence from the chosen set of attributes. The concept of issue (with the more elementary ones of failure and hazard) and the concept of scope are common across all the attributes and independent from the initial set. Each dependability attribute can in fact be defined in terms of some kind of issues affecting the whole system or part of it. The characterizations of failure, hazard and scope, instead, depend on the set of dependability attributes taken into account. For example, the distinction of failures into accuracy, performance and other failures is the result of the chosen sub-set of dependability attributes. Similarly, the idea of classifying failures according to their impact on availability results from having availability among the considered attributes. In this case,in particular, the choice of distinguishing only between stopping and non-stopping failures is purely arbitrary. A finer distinction (e.g., stopping, partly stopping, and non-stopping) could be adopted in order to be able to model gradual services degradations. The emerging concepts and their relationships are pictured in Figure 2. This structure represents the common backbone of the different dependability attributes definitions taken into account, and thus, it provides an initial structure for our framework. In Figure 2, to distinguish the UMD concepts with higher commonality and independence (i.e. issue, failure, hazard and scope) from the ones with lower commonality and independence (i.e., the characterizations), the latter are shown on a darker background. In the following, we refer to them as UMD Hardware component ; and as UMD Software component , respectively. scope issuecharacterization:- Type - Whole System - Servicecharacterization:- Type- User(s) hazard - Environment hazard characterization:- Type- Accuracy failure- Performance failure- Other failure - Availability impact- Stopping- Non-StoppingFAILUREHAZARDFigure 2. The “emerging” UMDBy using the concepts of UMD, all the dependability attributes definitions taken into account can be reformulated. For example, we can define availability as the index of all the stopping failures, of any type (accuracy, performance, or others) (ISSUE) affecting the system or a service (SCOPE), where the definitions of stopping failures, and of accuracy, performance and other failures are the ones given above. Similarly, the definitions of the others dependability attributes introduced above become:o Reliability: index of all the failures (ISSUE) affecting the system or a service (SCOPE).o Accuracy: index of the accuracy failures (ISSUE) affecting the system or a service (SCOPE).o Performance: index of the performance failures (ISSUE) affecting the system or a service (SCOPE).o Availability: index of the stopping failures (ISSUE) affecting the system or a service (SCOPE).o Survivability: index of all the failures (ISSUE) affecting the system or a service (SCOPE), due to adverse conditions that can occasionally happen within its operational environment (e.g., exceptional weather conditions, un-natural load peaks, etc.).due to attacks intentionally carried on against the system (e.g., logical breaches, data accesses, denial of service attacks, etc.).o Maintainability 2: index of all the failures (ISSUE) affecting the system or a service (SCOPE), due to actions intentionally carried on to improve the system (e.g., repairs, upgrades).o Safety: index of the hazards (ISSUE) created by the system or a service (SCOPE).At this point, we can start from these new definitions for refining our analysis. We recognize that some failures (see the definitions of survivability, security, and maintainability) are the results of some external events. Due to our choice of the initial set of dependability attributes, we can distinguish three main e xternal events types:• Adverse condition: any external event that may have an actual or potential harmful effect on the system or a service (e.g., extreme weather conditions, un-natural load peaks, etc.);• Attack: any intentional action carried on against the system or a service (e.g., logical breaches, data accesses, denial of service attacks, etc.);• Update: any action intentionally carried on to change the system or a service (e.g., repairs, upgrades.). event scope issue characterization:- Type - Whole System - Service characterization:- Type- Adverse Condition - Attack- Upgradescharacterization:- Type- User(s) hazard - Environment hazardcharacterization:- Type - Accuracy failure - Performance failure- Other failure- Availability impact- Stopping- Non-StoppingFAILURE HAZARDFigure 3: The “evolving” UMD Thus, the concept of external event emerges as another common item across the different definitions. Each dependability attribute can in fact be defined in terms of some kind of issues affecting the whole system or part of it (the scope), due or not due to some external events. Figure 3 extends the framework introduced in Figure 2, by encompassing the new concept of eventBy using the new framework, the definitions of the dependability attributes become:2 Note that with this new definition of maintainability we cover only partially the initial one. While the original definition encompasses, for example, the capability of the system of being repaired and/or upgraded within the expected budget and time, the new definition focuses only upon the easiness of the maintenance process, taking into account the possible issues caused by repairs and upgrades. UMD, however, also allows for the expression of the desired system behavior during maintenance, as will be illustrated in the Section “Capturing System reaction”.(SCOPE), which are due or not due to external events (EVENT).o Accuracy: index of the accuracy failures (ISSUE) affecting the system or a service (SCOPE), which are due or not due to external events (EVENT).o Performance: index of the performance failures (ISSUE) affecting the system or a service (SCOPE), which are due or not due to external events (EVENT).o Availability: index of the stopping failures (ISSUE) affecting the system or a service (SCOPE), which are due or not due to external events (EVENT).o Survivability: index of all the failures (ISSUE) affecting the system or a service (SCOPE), due to adverse conditions (EVENT).o Security: index of all the failures (ISSUE) affecting the system or a service (SCOPE), due to attacks (EVENT).o Maintainability: index of all the failures (ISSUE) affecting the system or a service (SCOPE), due to upgrades (EVENT).o Safety: index of the hazards (ISSUE) created by the system or a service (SCOPE), which are due or not due to external events (EVENT).It is important to note that these definitions reflect only some of the possibilities. In fact, while we have defined accuracy as “an index of the accuracy failures, affecting the system or a service, which are due or not due to external events”, it would have been also possible to define it as “an index of the accuracy failures, affecting the system or a service, which are not due to external events”, clearly stating that accuracy failures due to external events are not to be considered as part of the accuracy of the system. This is also true for the other definitions. Thus, by reformulating the definitions around the identified framework, we have obtained definitions more precise than the original ones (where some aspects were left implicit). Put another way, the framework not only provides a guide to define the different attributes, but also helps to make explicit options that could have been neglected otherwise.2.2 “Robustness” of UMDIn order to see if UMD can really be adopted on a larger scale, that is, determine whether it can encompass the many available definitions of dependability and its attributes, we will verify the capability of the framework to accommodate: a) different definitions of the dependability attributes already taken into account; b) other dependability attributes not included into the initial set.Let us start by considering different possible definitions for the same dependability attributes. In the following, for each definition found in literature (Literature Definition – LD), we will provide corresponding definition expressed by using the framework (Framework Definition – FD), together with the necessary framework adjustments and extensions (FA).o LD: Reliability is the continuity of correct service (a service is correct when implements the system function) [Laprie01].FD: Reliability is index of all the failures (ISSUE) affecting the system or a service (SCOPE), which are due or not due to external events (EVENT).FA: noneo LD: Availability is the capability to maximize the function of time that the system will provide stakeholder-desired levels of service with respect to a system’s operational profile (probability distribution of transaction frequencies, task complexities, workload volumes, others) [Boehm03].FD: Availability: index of the stopping failures (ISSUE) affecting the system or a service (SCOPE), with respect to a system’s operational profile, which are due or not due to external events (EVENT).FA: The adjustments concern the Software component of the Framework:Stopping failures are defined as failures preventing the system from providing the stakeholder-desired levels of service.The system’s operational profile (probability distribution of transaction frequencies, task complexities, workload volumes, others) is added asfurther Scope characterization.o LD: Availability is the ability of the system to provide service at any given time. It is the probability of being operational, under given use condition, at a given instant in time [Melhart00].FD: Availability: index of the stopping failures (ISSUE) affecting the system or a service (SCOPE), under given use condition, which are due or not due to external events (EVENT).FA: The adjustments and extensions concern the Software component of the Framework:Use condition is added as further Scope characterization.o LD: Accuracy is the capability to minimize the difference between delivered computational results and the real world quantities that they represent [Boehm03].FD: Accuracy is an index of the accuracy failures (ISSUE) affecting the system or a service (SCOPE), which are due or not due to external events (EVENT)FA: The adjustments and extensions concern the Software component of the Framework:Accuracy failures are defined as differences between delivered computational results and the real world quantities that they represent.o LD: Survivability is the capability of the system to minimize the expected value of the information, property, human life and health losses due to natural causes [Boehm03].FD: Survivability: index of all hazards (ISSUE) resulting from the system or a service (SCOPE), due to adverse conditions (EVENT).FA: The adjustments and extensions concern the Software component of the Framework:Hazards are defined as system states that can lead to information, property, human life and health losses.Adverse conditions are defined as all natural causes.o LD: Survivability is the capability of the system to accomplish its mission despite a man-made hostile environment, i.e. the power of the system to detect and withstand an attack [Melhart00].FD: Survivability: index of all the failures (ISSUE) affecting the system or a service (SCOPE), due to adverse conditions (EVENT).FA: The adjustments and extensions concern the Software component of the Framework:Adverse conditions are defined as any man-made hostile factor.o LD: Security is the capability of the system to minimize the expected value of the information, property, human life and health losses due to adversarial causes [Boehm03].FD: Security: index of all hazards (ISSUE) resulting from the system or a service (SCOPE), due to attacks (EVENT).FA: The adjustments and extensions concern the Software component of the Framework:Hazards are defined as system states that can lead to information, property, human life and health losses.Attacks are defined as adversarial causes.o LD: Performance is concerned with quantifiable attributes of the system, such as response time (how quickly the system reacts to a user input), throughput (how much work the system can accomplish within a specified amount of time), availability (the degree to witch a system or component is operational or accessible when required for use), and accuracy [Bruegge04].FD: Performance: index of the performance failures (ISSUE) affecting the system ora service (SCOPE), which are due or not due to external events (EVENT).FA: The adjustments and extensions concern the Software component of the Framework:Performance failures are defined as response time failures, throughput failures, stopping failures, and accuracy failures.o LD: Safety is the ability of the system to deliver service under given use conditions with no catastrophic effect [Melhar00].FD: Safety: index of the hazards (ISSUE) created by the system or a service (SCOPE), under given use conditions, which are due or not due to external events (EVENT).FA: The adjustments and extensions concern the Software component of the Framework:Hazards are defined as system states that can lead to catastrophic effects.Use condition is added as further Scope characterization.o LD: Safety is the capability of the system to minimize the expected value of human life and health losses due to natural and adversarial causes [Boehm03].。