Pattern-Based Modeling and Analysis of Failsafe Fault-Tolerance in UML∗ Ali Ebnenasir† Betty H.C. Cheng Department of Computer Science Computer Science and Engineering Department Michigan Technological University Michigan State University Houghton MI 49931 U.S.A. East Lansing MI 48824 U.S.A. [email protected] [email protected] Abstract would potentially crosscut all components of the concep- In order to facilitate incremental modeling and analysis tual model of an existing system. As such, developers need of fault-tolerant embedded systems, we introduce an object rigorous techniques and reusable artifacts for adding fault- analysis pattern, called the detector pattern, that provides tolerance concerns to conceptual models. This paper in- a reusable strategy for capturing the requirements of fail- troduces a pattern-based approach for adding failsafe fault- safe fault-tolerance in an existing conceptual model, where tolerance to an existing conceptual model (in UML [7]), a failsafe system satisfies its safety requirements even when where a failsafe fault-tolerant system is expected to meet faults occur. We also present a method that (i) uses the de- its safety requirements even when faults occur. tector pattern to help create a behavioral model of a fail- Numerous approaches exist to support fault-tolerance safe fault-tolerant system in UML, (ii) generates and model [1,5,14,30,32,33] and to analyze system safety in the pres- checks formal models of UML state diagrams of the fault- ence of failures [6, 23, 27], most of which (i) rely on a spe- tolerant system, and (iii) visualizes the model checking re- cific fault-tolerance design/implementation mechanism; (ii) sults in terms of the UML diagrams to facilitate model re- do not emphasize on reuse in analysis phases, and (iii) lack finement. We demonstrate our analysis method in the con- sufficient support for formal analysis of the potential inter- text of an industrial automotive application. ferences between fault-tolerance and functional concerns. For example, Saridakis [32] presents a set of design patterns Keywords: Requirements Analysis, Fault-Tolerance, based on existing recovery mechanisms [14,30]. Bondavalli Formal Methods, Detector, UML et al. [6] translate UML structural and behavioral diagrams to Stochastic Petri Nets in order to provide quantitative pre- 1 Introduction dictions for system dependability/reliability. Leveson and The complexity of developing fault-tolerant systems is, Stolzy [27] present a formal framework based on Timed in part, due to the crosscutting and evolving nature of fault- Petri Nets to model and analyze fault-tolerance in real-time tolerance requirements. Since it is difficult to anticipate all systems. The UML profile for fault-tolerance [1] and sev- types of faults2 at early stages of development, it is better to eral aspect-oriented approaches [18, 34] use redundancy of have techniques that enable existing analysis artifacts to be services [33] to mask faults, which is sometimes impracti- revised once a new type of fault is detected. Such a revision cal and costly [2]. Approaches based on safety cases [23] present a framework for goal-based failure analysis and sys- ∗This work was partially sponsored by NSF grants EIA-0000433, EIA- tematic specification of lessons and recommendations for 0130724, CDA-9700732, CCR-9901017, CNS-0551622, CCF-0541131, post-failure corrections of safety-critical systems. Further- NSF CAREER CCR-0092724, ONR grant N00014-011-0744, DARPA Grant OSURS01-C-1901, Siemens Corporate Research, a grant from the more, some existing analysis methods for fault-tolerance Michigan State University’s Quality Fund, and a grant from Michigan [22, 31] assume that a specific fault-tolerance design mech- Technological University. † anism (e.g., exception handling, redundancy) will be used The work presented here was performed largely while this author was and specify analysis requirements within those design con- a postdoctoral researcher at Michigan State University with support from NSF and ONR. straints, which may overly constrain and preclude useful 1Email: [email protected], [email protected] fault-tolerance solutions. (For example, it is difficult to Tel: +1-906-487-4372, Fax: +1-906-487-2283 specify and model self-stabilization [9] solely based on ex- ception handling.) While all aforementioned approaches 2A fault-type is a representation of the hypothesized cause of an error. An error is characterized by a (set of) state(s) from where failures may present useful and important techniques for modeling and occur. A failure is a behavioral deviation from system specifications [4]. analyzing fault-tolerance concerns, three important features distinguish our approach from existing work: (1) provid- framework [28] to generate formal specifications of faults, ing reusable modeling artifacts for incremental modeling of fault-tolerance and functional concerns in the Promela mod- fault-tolerance; (2) ensuring the fault-tolerance of the mod- eling language [21]. Subsequently, we use the Spin model eling elements added for fault-tolerance purposes, and (3) checker [21] to detect inconsistencies between the detec- facilitating automated reasoning (coupled with visualiza- tor pattern instances and the functional model of the FIS. tion) in analyzing the mutual impact of fault-tolerance and The automated analysis with the Spin model checker cou- functional concerns. pled with a new visualization tool, called Theseus [20], that We introduce an object analysis pattern, called the de- animates counterexample traces enables a roundtrip engi- tector pattern, that provides a reusable strategy for elicit- neering process for modeling and analyzing failsafe FTSs. ing and specifying the requirements of error detection in We demonstrate our approach by modeling and analyz- UML object models for embedded systems. Our focus ing an adaptive cruise control (ACC) system in UML. We on capturing error detection requirements is an extension have also validated our approach for several other examples of Arora and Kulkarni’s [3] results where they show that from industry [12], including a diesel filter system for re- detection is necessary and sufficient for developing a rich ducing soot from diesel truck exhaust. The remainder of class of failsafe fault-tolerant systems. As such, the de- this paper is organized as follows. Section 2 introduces an tector pattern is intended to provide a generic artifact in approach to modeling faults in UML state diagrams. Sec- model-driven development of failsafe systems. Object anal- tion 3 discusses the relation between failsafe fault-tolerance ysis patterns apply a similar approach to that used by de- and error detection. Section 4 presents the detector pattern. sign patterns [19], but instead of focusing on design they Section 5 focuses on formal analysis of UML models of address the construction of the conceptual model of a sys- FTSs using Spin [21]. Finally, Section 6 gives concluding tem [10]. Patterns for the analysis stage of software devel- remarks and discusses future work. opment are not new (see [17,24]). For example, Fowler [17] 2 Modeling presents a method for characterizing recurring ideas in busi- In this section, we present the basic concepts of model- ness modeling as reusable analysis patterns. Konrad et al. ing FISs, faults, and failsafe fault-tolerance in UML. We re- [24] present domain-specific object analysis patterns for an- iterate the definitions of faults and fault-tolerance from [2]. alyzing the conceptual models of embedded systems. The The motivation behind using UML is two-fold. First, UML proposed detector pattern in this paper provides a reusable is the de facto standard for object-oriented modeling. Sec- building block for the construction of the conceptual models ond, UML state diagrams enable us to capture any form of failsafe systems. of fault-tolerance that can be expressed in a state machine- Our pattern-based method comprises fault modeling, based formalism. fault-tolerance modeling, and automated analysis of the UML Models. We use conventional UML nota- UML models of fault-tolerant embedded systems. Specif- tions [7] to represent the UML-based conceptual models of ically, to construct the UML model of a Fault-Tolerant FISs (respectively, FTSs). Since our focus is on modeling System (FTS), we start with the UML model of its fault- and analyzing fault-tolerant embedded systems, we follow intolerant version, where a Fault-Intolerant System (FIS) Douglass [10] in using UML class diagrams to model struc- meets its functional requirements in the absence of faults tural constraints of (software and hardware components of) (i.e., when no faults occur) and provides no guarantees in embedded systems during the object analysis phase. We use the presence of faults (i.e., when faults occur). Then we state diagrams to capture high-level behavioral information model faults in the UML model of the FIS to produce a of UML object models. The combination of class and state model with faults. We use the notion of state perturbation to diagrams yields an object analysis model. model different types of faults in UML state diagrams [2,9]. Depending on the semantics of object interactions, the Next, we specify error states that are reached due to the oc- complexity of automatic analysis of a FTS varies from poly- currence of faults. Subsequently, we add instances of the nomial (in a shared memory model [25]) to undecidable (in detector pattern to the model with faults to capture the re- an asynchronous message-passing model [16]). To facilitate quirements of error detection and to generate a candidate an automated analysis method with a manageable complex- UML model of a failsafe FTS. To create a valid UML model ity, in this paper, we consider a high atomicity model where of the failsafe FTS, we have to ensure that the candidate transitions of UML state diagrams are executed atomically, UML model is interference-free. That is, in the absence and any instance of message passing between two objects of faults, the candidate model meets all functional require- takes place in an atomic step.