Adding Formal Specifications to Requirements Patterns - CiteSeerX

Adding Formal Specifications to Requirements Patterns∗ Sascha Konrad, Laura A. Campbell, Betty H.C. Cheng† Software Engineering and Network Systems Laboratory Department of Computer Science and Engineering Michigan State University East Lansing, Michigan 48824 USA Phone: +1 517 355 8344 Email: {konradsa,campb222,chengb}@cse.msu.edu ABSTRACT Embedded systems usually must achieve a higher level of robustness and reliability because they control real-world physical processes or devices upon which we depend, frequently, in a critical way. Consequently, methods for modeling and developing embedded systems and rigorously verifying behavior before committing to code are increasingly important. In order to use object-oriented development techniques and UML for embedded systems, we previously developed a framework for adding formal semantics to a collection of UML diagrams that enable the automated derivation of formal language specifications for those diagrams. Recently, we also identified a number of requirements patterns for use in the development of requirements and high-level design for embedded systems, and constructed a requirements pattern template. This paper describes how we have augmented the template to include requirements constraints that might be applicable when using a given pattern. With the ability to generate formal specifications from the UML diagrams, these constraints can be analyzed using existing model checkers. We also include a description of how the requirements patterns have been used to model and formally analyze an automotive embedded system.

nications systems. It is well-known that requirements modeling and analysis is one of the most difficult tasks in the software development process [13], but this problem is greatly exacerbated for embedded systems given the hardware constraints and the potentially complex control logic. Furthermore, embedded systems usually must achieve a higher level of robustness and reliability because they control real-world physical processes or devices upon which we depend, frequently, in a critical way. Consequently, methods for modeling and developing embedded systems and rigorously verifying behavior before committing to code are increasingly important. Recently, we identified a number of requirements patterns for use in the development of requirements and high-level design for embedded systems [11]. We constructed a requirements pattern template, much in the spirit of the template used by Gamma et al. [8] for design patterns. This template includes motivation, consequences, high-level goals, context information, constraints, and diagrams depicting templates for structure and behavior capture of the requirements patterns. This paper describes how we have augmented the Constraints field of the template to include formal specifications of properties that should be satisfied in the context of using a given pattern [1].

Keywords Model Checking, Embedded Systems, Requirements Patterns

Currently, much of the embedded systems industry use ad hoc development approaches [6]. Frequently, there are few, if any, intermediate steps between high-level, prose descriptions of requirements and code written in the target implementation language. We contend that object-oriented methods are one remedy to the development of embedded systems software. The gains are in part due to the often close correlation between real components in the physical system and software objects, although other factors such as data hiding, encapsulation, etc., also contribute. Recently, it appears that the Unified Modeling Language (UML) [2] could be a notation broad enough in scope to represent a variety of domains and gain widespread use. In addition, there appears to be interest from the embedded systems community in exploring how object-oriented modeling, specifically UML, can be used for embedded systems [6]. Our requirements patterns

1 INTRODUCTION As software has become increasingly prevalent, it has also become more complex. These characteristics are particularly applicable to the area of embedded systems. In addition, embedded systems are frequently found in high assurance systems, including automotive, medical, flight, and telecommu∗ This work has been supported in part by NSF grants EIA0000433, EIA-0130724, CDA-9700732, CDA-9617310, CCR-9633391, CCR-9901017, Department of the Navy, Office of Naval Research under Grant No. N00014-01-1-0744, and DARPA grant No. F30602-96-1-0298, managed by Air Force’s Rome Laboratories, Eaton Corporation, a Motorola doctoral fellowship, and in cooperation with Siemens Automotive and Detroit Diesel Corporation. † Please contact B. Cheng for all correspondences.

use the UML to model the structural and behavioral information, respectively using class diagrams and behavioral diagrams, such as sequence and state diagrams. In addition, we use UML use case diagrams to capture high-level user goals. In order to use object-oriented development techniques and UML for embedded systems, we have developed a framework [12] for adding formal semantics to a collection of UML diagrams that enable the automated derivation of formal language specifications for those diagrams. With the capability to generate formal specifications from the UML diagrams, developers can use the requirements patterns to assist in the development of models for requirements and then generate formal specifications to analyze their requirements. In addition, with the Constraints portion of the template, the developer can specify specific properties that the requirements model must satisfy. With the formalization capability, we are able to validate (using simulation) the behavior of the requirements as captured by the state diagrams [4]. The properties have been specified in LTL (Linear Temporal Logic) according to specification patterns developed by Dwyer et al. [7]. The result is that developers can accelerate the initial development of requirements models through the use of the requirements patterns, and then using our formalization work, they have a mechanism to rigorously check the requirements using simulation and model checking techniques. The remainder of this paper is organized as follows. Section 2 briefly describes how requirements patterns can be incorporated into our previous UML formalization work, and presents a classification scheme for our requirements patterns according to non-functional properties, with specific emphasis on safety and fault tolerance. Next, Section 3 describes how we have used specification patterns to construct specifications for these two non-functional properties for one of our requirements patterns. We illustrate how we used this requirements pattern to construct formal models of an automotive embedded system and to specify and model check safety and fault-tolerance properties. Finally, we give conclusions and discuss future work in Section 4. 2 FORMALIZED UML AND REQUIREMENTS PATTERNS Previously [10] we described how UML diagrams based on the structural and behavioral diagrams in the requirements patterns can be used to generate formal specifications using a formalization framework and tool suite; Hydra generates formal specifications from textual representations of UML diagrams, and M INERVA supports the graphical construction of UML diagrams and generates visualizations of the analysis results in terms of the UML diagrams [4, 12]. These formal specifications can be used to validate the UML diagrams through simulation using the SPIN model checker [9]. In addition, the properties that we added to the Constraints section of the requirements patterns can be “checked” against

the UML diagrams using the verification tools of SPIN. In order to develop a template to describe requirements patterns, the original design pattern template [8] has been modified in several aspects to address the needs of requirements engineering. Specifically it has been extended with Constraints, Behavior, and Requirement Patterns sections that contain specification-pattern-based [7] representations of properties of interest, sequence and state diagrams that illustrate sample behavior, and a list of related requirements patterns, respectively. The sections Implementation and Sample Code from the original template have been removed because they were too specific to software design and implementation. Finally, the Collaborations section contains a textual description of the general, rather than implementation-oriented, behavior that is possible among collaborators within a pattern. See [11] for details on the requirements pattern template. Thus far, we have identified patterns to describe requirements for the main elements of an embedded system, including the actuator-sensor-controller relationship, communication among embedded system elements, user interface, system monitoring, etc.; the complete set of requirements patterns and their descriptions are given elsewhere [11]. Due to space constraints, this paper focuses on the Fault Handler Pattern that is relevant to high assurance systems. It depicts how to integrate fault handling functionality into an embedded system. We show the relationships between the requirements patterns and non-functional properties in Figure 1 (shaded areas indicate the properties of interest for this paper); there are potentially many more non-functional properties. For the purposes of this workshop, this paper focuses on fault tolerance and safety properties. • Fault Tolerance: Maximize the ability to keep the system executing in the presence of defects through failure detection, damage assessment, fault recovery, and fault repair [13]. • Safety: Minimize the risk to persons or equipment [6].

3 SIMULATION AND MODEL CHECKING We use an Anti-lock Brake System (ABS) as a working example to demonstrate how the requirements patterns can be used to construct UML models for a high assurance system, where the models can be simulated and checked for adherence to requirements constraints. (A detailed description of this system can be found elsewhere [3].) We specifically focus the discussion on how the requirements patterns can be used as a foundation to verify safety and fault tolerance properties. Process for Using Requirements Patterns The following is a process for using the requirements pat-

rfo rm an Re ce lia b il ity Fa ult To le r Re an us ce ab i l ity Sa fet y Po rta b il ity Ex ten s ib ility Ma int a in ab Us ility ab ility

Pe

Controller Decompose Pattern Actuator-Sensor Pattern Watchdog Pattern Examiner Pattern Fault Handler Pattern Mask Pattern Moderator Pattern User Interface Pattern Channel Pattern Monitor-Actuator Pattern

X X

X X

X X

X

X

X

X X

X X

X X

X

X X X

X X X

X X

X X

X X

X

X X X

X

Figure 1: Pattern classification according to non-functional properties terns that enables simulation and model checking of the resulting system models. 1. Use the requirements patterns to construct a basic foundation for the system and refine the UML high-level structural and behavioral models of the system. 2. Use Hydra [4, 12] to generate a Promela model of the system from the UML diagrams. 3. Using M INERVA’s [4] visualization utilities to display simulator output within the context of the UML diagrams, simulate the model from the first step for validation purposes, and then refine the system model if errors are discovered. 4. Specify non-functional properties for the system by refining the specification patterns in the Constraints field of requirements patterns. 5. Determine which parts of the system are relevant to a given property to be checked, and introduce abstract representations for the remaining parts of the system where possible. For example, a composite state whose behavior is not directly being checked may be abstracted into a simple state that preserves the incoming and outgoing transitions. 6. Generate scenarios of the system that cover system stimuli relevant to the focused property and model them in the Environment class. 7. Use a model checker (e.g., SPIN [9]) to determine if the properties are satisfied. If errors are detected, then use M IN ERVA ’s [4] visualization utilities to display the counterexample in terms of the UML diagrams, and then refine the system model.

The result is an abstract system model that has been verified against the properties. This model can be used as a basis for the implementation of the system. Due to the state explosion problem inherent to model checking [5] (the voluminous state space usually needed may exhaust the still limited memory and computing power of today’s computers), the abstraction and model checking steps (Steps 5 and 7) may need to be repeated several times in order to cover the entire model. Especially when many scenarios (Step 6) are used,

it is usually not possible to check the system against all scenarios at once. Therefore, the verification has to be repeated with a smaller number of scenarios until all are checked. The remaining subsections in Section 3 discuss Steps 1 and 4–7 of the process as applied to the ABS example. Construction of UML Models For the ABS example, we applied the Fault Handler Requirements Pattern (included in the Appendix) to construct a basic foundation for the system model. In particular, the state diagram shown in Figure 8 in the Appendix influences the construction of the state diagram for the ComputingComponent of the ABS (not shown due to space constraints). In particular, the state diagram for the ComputingComponent of the ABS contains states analogous to Normal Behavior, Power Off, Reset, and Emergency Stop. FaultHandler Requirements Pattern Specifications Below are the generic specifications, given in LTL, that were extracted from the Fault Handler Requirements Pattern in the Appendix. They can be found in the Constraints field of the requirements pattern. All claims in the Fault Handler Requirements Pattern correspond to the Response Pattern by Dwyer et al. [7]. The keyword sent means that the given message was sent to the class, while in means that the class is in a given state. 1. Response Pattern: [](sent(FaultHandler.StoreError(Error)) -> "Start defined recovery action")

When an error message is sent to the fault handler it should process the error and, depending on the error classification, perform a predefined recovery action as a result of the error. This action can be anything from “Do nothing” to “Perform emergency shutdown of the system”. 2. Response Pattern: [](sent(FaultHandler.StoreError(Error)) -> "Store error in error log")

_SYSTEMCLASS_ ComputingComponent

ABS_Class_Diagram_model.dom

ready(): void

CurrentCarSpeed: int = 3000 BrakeValue: int = 0 UseBrakeSensor2: bool = 0

FaultHandler Error: int StoreError(int): void GetList(): void

1 handles faults 1

1 activates 1

Reset(): void PowerOn(): void ShutdownES(): void OK(): void FAIL(): void SetBrakeValue(int): void SetUseBrakeSensor2(bool): void 1

1 reads

1

Environment

1

reads

BrakeSensor1

1 starts/stops

ready(): void SetA1(): void SetA2(): void SetA3(): void SetA4(): void SetB1(): void SetB2(): void

1 BrakeSensor2

Brake1Value: int = 400 Brake1OperationState: bool = 1

Brake2Value: int = 400 Brake2OperationState: bool = 1

GetBrake1OperationState(): void SetBrake1OperationState(bool): void GetBrake1Value(): void

GetBrake2OperationState(): void SetBrake2OperationState(bool): void GetBrake2Value(): void

Figure 2: Abstracted Model Class Diagram When an error message is sent, it should be stored in an error log for easy system diagnostics. 3. Response Pattern: [](sent(FaultHandler.GetList()) -> "Return list of errors in error log")

If some device, for example a diagnostic device, requests the current error list, then it should be sent.

These three general claims in LTL describe constraints on the behavior of the fault handler. Parts of the LTL claims are given in natural language because they depend on the actual system in which the fault handler is implemented. Before the claims can be verified, such portions must be replaced by logical statements suitable for the system. These replacements are made during Step 4 (the refinement step) of the process for using requirements patterns. Two examples are given in the subsequent “Verification Results” subsection. System Abstraction Abstraction removes parts of the system model irrelevant to properties of interest in order to decrease the state space required to perform model checking. As part of Step 5 of the process for using requirements patterns, the system is analyzed to determine the necessary parts to perform model checking of the specific fault tolerance or safety properties refined in Step 4. For the ABS example (a detailed description of this system can be found elsewhere [3]), the wheel speed sensors and the output valve actuators for each wheel are removed because they increase the model’s complexity without being essential to check the specific fault tolerance and safety properties. Likewise the Watchdog and UserInterface el-

ements are excluded. The resulting class diagram of the system can be seen in Figure 2 (the notch in each class indicates that there is a corresponding state diagram). The SYSTEMCLASS is the class that is always by default executed first. It instantiates all other classes and then activates the Environment component. The ComputingComponent processes the inputs and produces the desired outputs. The FaultHandler class is the central fault handler of the system. BrakeSensor1 and BrakeSensor2 are sensors that read the brake pedal. There are two sensors for this task because one is a backup if the first one fails; both are the only sensors needed for the verification of our properties of interest. Except for the ComputingComponent, all other components are modeled very simply: they each consist of only one state. For each possible event that can be sent to these classes, a transition that performs the corresponding action handles the event. For example, the brake sensors send the brake value to the ComputingComponent in response to a “GetBrakeValue()” event. Figure 3 and Figure 4, respectively, show the state diagrams (after abstraction) for the FaultHandler and the ComputingComponent of the ABS system, the main objects of interest for the analysis discussed in this paper. We simplified the ComputingComponent state diagram by first removing the initialization functionality details and by also removing the element that actually detects skidding and opens the outlet valves for each wheel if necessary (recall that the wheel speed sensors and output valve actuators have been removed from the class diagram). The original initialization composite state was replaced by the

state Initialize with a “dummy” test that always sends an OK() message. The ComputeUsingBrakeSensor1 and ComputeUsingBrakeSensor2 states behave similarly; they reduce the speed value in every computation cycle by 300 which corresponds to three miles per hour, simulating a full brake of the car. (For brevity, the state entry actions corresponding to the dummy test and speed reduction are not shown in the diagram.)

[] / ^_SYSTEMCLASS_.ready

idle

StoreError(Error)[Error==x] / StartRecoveryActionX()

Figure 3: Abstracted Model for FaultHandler State Diagram These abstractions were performed in order to reduce the system complexity and thus decrease the state space needed to verify specific properties. This system is now at a reasonable size that allows us to perform model checking using the SPIN model checker [9]. The abstracted state diagram still enables us to test the system’s functionality as long as everything with which the claims are concerned can be found in the system. Scenario Definition Crucial for the analysis process is to cover all the states of the model that are relevant to the specific property. Therefore, different scenarios are used in our model checking approach; each scenario exercises a different portion of the state diagrams. To determine the scenarios needed, all possible input conditions have to be analyzed and a combination of each of these possible values has to be checked. In our approach, we use the Environment class to define different scenarios. Please refer to Figure 5 for an example state diagram of the Environment class. This state diagram shows the different scenarios that cover the system. For the ABS example, there are two steps in an execution path where alternate values may be selected at each step to generate a scenario; the first step sets the operational status of the brake sensors, while the second step sets the car speed. In the first step, four choices are possible: A1: Both brake sensors are working. A2: Brake sensor 1 is not working. A3: Brake sensor 2 is not working.

A4: Brake sensor 1 and 2 are not working. In the second step, two choices are possible: B1: Set car speed to 35 miles per hour. B2: Set car speed to 20 miles per hour. (Therefore the ABS system is not engaged because of the activation threshold of 24 miles per hour [3].) So the Environment class determines eight different scenarios in total for the system. When the properties can be successfully verified against each of these scenarios, we consider the system to be verified against the properties. SPIN supports non-determinism [9]. We are using this feature to thoroughly simulate and verify our models by covering all possible scenarios depicted in the Environment state diagram shown in Figure 5. During simulation, choices are made non-deterministically, and during the state space exploration (model checking), all possible choices are explored. The Promela code showing this non-deterministic selection coordinated by the SYSTEMCLASS can be seen in Figure 6. If for an if -condition more than one possible choice exists, then SPIN picks one non-deterministically. It is obvious that the if -conditions have the exact same conditions (left of the semicolon), so that non-deterministically one action (right of the semicolon) is chosen for Step A and one for Step B. Verification Results The following fault tolerance and safety claims were both made by instantiating Specification (1) from the Fault Handler Requirements Pattern for the ABS example. These claims were verified with SPIN against the Promela specifications generated from the abstracted UML diagrams for the ABS example. We used the exhaustive search method to verify our claims, which generates the entire state space and checks it for violations. • Fault Tolerance: Activate second brake sensor when the first one fails [](sent(FaultHandler.StoreError(110)) -> ComputingComponent.UseBrakeSensor2 == 1)

When the first brake sensor fails, the fault handler will be notified by the error code 110. It will then advise the computing component to use the second brake sensor to deliver the value of the brake pedal pressure applied by the driver of the car. For this situation, the fault handler sets the UseBrakeSensor2 value to true. The computing component will then use the second brake sensor. To verify this property without exceeding available memory, the eight scenarios described in the previous subsection had to be divided into different verification runs. The table below shows which scenarios were examined for each verification run (according to our two

ComputingComponent Compute

ShutdownES() ShutdownES()

Reset() Reset()

Reset()

CurrentCarSpeed=2410 && UseBrakeSensor2==0] / BrakeSensor1. GetBrake1OperationState()

Brake activated

OK()

CheckBrakeSensor1 [CurrentCarSpeed>=2410 && UseBrakeSensor2==1] / BrakeSensor2. GetBrake2OperationState()

ComputeUsingBrakeSensor1

ComputeUsingBrakeSensor2

OK()

CheckBrakeSensor2 FAIL / FaultHandler.StoreError(120)

Receive UseBrakeSensor2 Value

SetUseBrakeSensor2(UseBrakeSensor2) Idle

Figure 4: Abstracted Model for ComputingComponent State Diagram step-scenario generation as explained in the previous subsection), including the number of transitions and the amount of memory used. For example, in the first row, A1 & A2 for Step A and B1 & B2 for Step B means that four different scenarios can be generated by choosing one of A1 or A2 for Step A and one of B1 or B2 for Step B, and that SPIN covered all four scenarios in this verification run. Step A A1 & A2 A3 A4 A4

Step B B1 & B2 B1 & B2 B1 B2

Transitions 42,739,100 45,312,100 85,941,100 62,519,400

Memory 385 Mb 382 Mb 741 Mb 518 Mb

• Safety: Turn system off when unrecoverable error occurs [](sent(FaultHandler.StoreError(100) -> in(ComputingComponent.PowerOff)))

This property specifies that the system should be turned off in the case of a major, unrecoverable error, which has, in our system, the error code 100. After this error message is sent, the system should transition to the state PowerOff. When the system is turned off, the car has the standard mechanical brake functionality, but without skid prevention. Therefore, it is safe to turn the ABS off when a major error in the system occurs.

The table below shows which scenarios we examined for each verification run, including the number of transitions and the amount of memory used to verify the claim. Step A A1 & A2 & A3 A4 A4

Step B B1 & B2 B1 B2

Transitions 45,312,100 85,941,100 62,519,400

Memory 382 Mb 741 Mb 518 Mb

4 CONCLUSIONS Requirements patterns can be an effective mechanism for describing requirements of high assurance systems. Furthermore, by adding specification-pattern-based properties to the Constraints field of the requirements pattern template, developers have some guidance as to what kinds of properties can be checked for a given system when a particular pattern is applied. The specification patterns used in conjunction with requirements patterns enable even novice developers to easily formulate claims to check the system for specific constraints. Then using our formalization work and tool suite, developers have a mechanism to rigorously check the requirements using simulation and model checking techniques. As developers gain experience from continued application of the requirements patterns and their constraint specifications, an increasing number of claims can be partly or completely reused. Accordingly, the abstractions introduced for

SetA1 [] / ^BrakeSensor1.SetBrake1OperationState(1), ^BrakeSensor2.SetBrake2OperationState(1) SetA2 [] / ^BrakeSensor1.SetBrake1OperationState(1), ^BrakeSensor2.SetBrake2OperationState(0)

[] / ^_SYSTEMCLASS_.ready SetStepA

SetA3 [] / ^BrakeSensor1.SetBrake1OperationState(0), ^BrakeSensor2.SetBrake2OperationState(1) SetA4 [] / ^BrakeSensor1.SetBrake1OperationState(0), ^BrakeSensor2.SetBrake2OperationState(0)

SetB1 [] / ^ComputingComponent.SetCurrentSpeed(3500) JoinB [] / ^ComputingComponent. PowerOn

JoinA [] / ^_SYSTEMCLASS_.ready SetStepB

SetB2 [] / ^ComputingComponent.SetCurrentSpeed(2000)

End

Figure 5: State Diagram of the Environment Class several systems in a particular domain can also be reused for new systems in that domain, thus accelerating the process of model checking by giving abstraction techniques that have been demonstrated to work for a specific type of system. Currently, we are continuing to develop additional LTL properties to add to the Constraints field of the requirements patterns. We are also exploring additional heuristics for introducing abstractions for the UML models in order to keep the model checking capabilities manageable. REFERENCES [1] D. Berry. Adding specifications to requirements patterns. Private Communication, February 2002. IFIPWG2.9, Duck Key, Florida. [2] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addision-Wesley, 1999. [3] J. Bowers. Project specifications for anti-lock brake system, 2001. http://www.cse.msu.edu/˜cse470/F01/Projects/ABS/. [4] L. A. Campbell, B. H. C. Cheng, and W. E. McUmber. Automatically detecting and visualizing errors in UML diagrams. Requirements Engineering Journal, 2002. (accepted to appear). [5] W. Chan, R. Anderson, P. Beame, S. Burns, F. Modugno, D. Notkin, and J. Reese. Model checking large software specifications, 1998. [6] B. P. Douglass. Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns. Addison–Wesley, 1999. [7] M. B. Dwyer, G. S. Avrunin, and J. C. Corbett. Property specification patterns for finite-state verification. In Proceedings 2nd Workshop on Formal Methods in Software Engineering, pages 7–16, Clearwater Beach, FL, Mar. 1998. [8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.

[9] G. J. Holzmann. The Model Checker SPIN. IEEE Transactions on Software Engineering, 23(5), May 1997. [10] S. Konrad and B. H. Cheng. Requirements patterns for embedded systems. Technical Report MSU-CSE-02-4, Computer Science and Engineering, Michigan State University, East Lansing, Michigan, February 2002. [11] S. Konrad and B. H. C. Cheng. Requirements patterns for embedded systems. In Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE02), Essen, Germany, September 2002. (to appear). [12] W. E. McUmber and B. H. C. Cheng. A general framework for formalizing UML with formal languages. In Proceedings of IEEE International Conference on Software Engineering (ICSE01), Toronto, Canada, May 2001. [13] I. Sommerville. Software Engineering. Addison-Wesley, 1992.

A FAULT HANDLER REQUIREMENTS PATTERNS The appendix contains an abbreviated description of the Fault Handler Requirements Pattern. The names of requirements patterns are denoted in italics, and the elements of a requirements pattern are named in a san serif font, including class and state names.

Fault Handler: Behavioral Pattern Intent: How to integrate a fault handler into an embedded system. Motivation: Fault handling is essential for embedded systems. Embedded systems frequently need to determine what responses are necessary to recover from errors. Consider a flight control system in an airplane, where the system should never shut down completely in response

/* State SetStepA */ SetStepA: printf("in state _SYSTEMCLASS_.SetStepA\n"); atomic {if :: !t?[free] -> t!free :: else skip fi;} if :: _SYSTEMCLASS__q?ready -> t?free; Environment_q!SetA1; :: _SYSTEMCLASS__q?ready -> t?free; Environment_q!SetA2; :: _SYSTEMCLASS__q?ready -> t?free; Environment_q!SetA3; :: _SYSTEMCLASS__q?ready -> t?free; Environment_q!SetA4; fi; goto SetStepB; /* State SetStepB */ SetStepA: printf("in state _SYSTEMCLASS_.SetStepB\n"); atomic {if :: !t?[free] -> t!free :: else skip fi;} if :: _SYSTEMCLASS__q?ready -> t?free; Environment_q!SetB1; :: _SYSTEMCLASS__q?ready -> t?free; Environment_q!SetB2; fi; goto SystemClassEnd; /* State SystemClassEnd */ s9: printf("in state _SYSTEMCLASS_.SystemClassEnd\n"); atomic {if :: !t?[free] -> t!free :: else skip fi;} if :: skip -> false fi;

Figure 6: Promela Code of the Non-Deterministic Scenario Selection to an error. The system has to decide if the error is sufficiently severe to perform a partial shutdown and offer basic functionality, or if the error is not a threat and logging the error is sufficient. This fault handler must offer the possibility for other devices to read the error log. But it should also have access to the user interface to signal to the user that errors have occurred. An important function of the fault handler is to send the system into different states depending on the severity of the error. These mechanisms have to be implemented in the computing unit, for example, the operation for performing an emergency stop. If an error is reported to the fault handler justifying this action, then it will send this message to the ComputingComponent. Therefore this fault handler acts as a centralized coordinator for safety monitoring and hence control of system recovery. The following inputs are usually captured [6]: • Timeout message by the Watchdog or Examiner Pattern. • Assertions of software errors. • Built-in-tests (BITs) that run on a periodic or continuous basis. • Faults identified by monitors, such as that described for the Monitor-Actuator Pattern. The centralized safety control facilitates the verification and validation of the safety measures and eases the reuse of the fault handler in different systems.

Due to space constraints the problem frame diagram is not included [10]. Constraints: • Response Pattern: [](sent(FaultHandler.StoreError(Error)) -> "Start defined recovery action")

When an error message is sent to the fault handler it should process the error and, depending on the error classification, perform a predefined recovery action as a result of the error. This action can be anything from “Do nothing” to “Perform emergency shutdown of the system”. • Response Pattern: [](sent(FaultHandler.StoreError(Error)) -> "Store error in error log")

When an error message is sent, it should be stored in an error log for easy system diagnostics. • Response Pattern: [](sent(FaultHandler.GetList()) -> "Return list of errors in error log")

If some device, for example a diagnostic device, requests the current error list, it should be sent. Applicability: Fault Handler Pattern is applicable

• in any embedded system that does not have the need for distributed fault handling. Structure: The UML class diagram of the Fault Handler Pattern can be seen in Figure 7. The FaultHandler sends messages to the UserInterface to activate warning levels and sends the ComputingComponent into different safety states. For every safety state defined in the requirements, an operation in the ComputingComponent is needed. The safety states are listed in the Behavior Section. The FaultHandler also receives error messages from watchdogs and monitors, and decides if recovery devices should be activated or what other actions are required. The Device is representative for all possible devices in the system. These devices send error messages to the FaultHandler. These devices can be monitored by watchdogs and/or monitors. They also report error messages to the fault handler. Depending on the safety measures and policies, the fault handler decides what to do, for example, activating the FailSafeDevice. communicate 1

ComputingComponent

activates 1

FaultHandler

rts

1

0..*

sends erros to

po re

1

ac iv at e

1

• Protection Stop: Ceases operation immediately, but does not turn off power. This state is useful, for example, when a machine needs to be stopped, but a cooling aggregate should continue to operate to avoid overheating. • Partial Shutdown: The system only offers basic functionality; for example, medical devices may remain in a monitoring state. • Hold: No functionality is provided in this state, but safety actions are taken; for example, a rocket self-destructs in the case of abnormal functions. • Reset: In this state the system initializes itself. • Power Off: In this state, the system might be connected to a power supply, but is not yet activated. For example, a television set can operate in standby mode. Participants:

backs up 0..*

Device

FailSafeDevice

reports

1

monitors

• Production Stop: This state is useful, for example, when a human enters a hazardous area. The system should be able to complete its current task and secure the environment, but it should shutdown as soon as possible.

s

0..* 1

1

1

0..*

monitors

Watchdog

UserInterface

1

1

• Emergency Stop: Here the system turns off power immediately, regardless of the current condition. This state is simple, but it is shown in the state diagram to illustrate the differences between the three types of stop states.

1

• FaultHandler: Stores errors and decides which recovery actions are necessary. Contains safety measures and policies. • ComputingComponent: Component controlling the system.

0..*

Monitor

0..*

• UserInterface: Class offering functionality to notify user about errors. • Device: Device monitored by watchdog(s) and/or monitor(s).

Figure 7: Fault Handler Pattern

• Watchdog: Watchdog monitoring the device. • Monitor: Monitor monitoring device actuation.

Behavior: Figure 8 shows the state diagram of the ComputingComponent of the Fault Handler Pattern. The state diagram shows which states are possible and what messages activate them. Not all of the states are needed in every system, for example ABS systems generally do not have a partial shutdown state because the system constraints usually require that an inactive system should not affect the functioning of the brakes, although there is no longer skid prevention. Therefore, in this case, an emergency stop state where the ABS system shuts off power immediately is sufficient. These states have to be defined in the ComputingComponent. The FaultHandler decides, when an error occurs, which state is appropriate and sends to the ComputingComponent the appropriate message to activate the corresponding state. It also activates the user interface to notify the user of the system if needed. The definitions for the states are as follows [6]: • Normal Behavior: This state captures the system when no errors have occurred and it is working normally. • Manual/External: In this state, the system is not controlled by a central component but from the outside, either from the user or another system, such as a diagnostic device.

• FailSafeDevice: Device activated in case of failure of the main device. Collaborations: • The FaultHandler receives all error messages and stores them in an error list. • It also decides, depending on the safety measures and policies, if a fail-safe state should be entered, or whether the user interface or recovery device should be activated. • Watchdog and Monitor monitor the device. • FailSafeChannel is activated to recover from faults. Consequences: 1. Required safety states should be implemented in the component. 2. Only one fault handler should exist in the system and should handle all error messages to avoid inconsistent handling of faults [6].

Fault_Handler_Computing_Component_States.dom

Normal Behavior

Automatic()[]/

[Initialization OK]/Automatic()

Manual/External Control Manual()[]/ Hold()[]/ Error()[]/ Emergency Stop

Partial Shutdown

Hold PowerOff()[]/

ShutdownES[]/ ShutdownES()[]/

Reset()[]/

Production Stop ShutdownPdS[]/

do/complete current task

ShutdownPdS()[]/ Reset Reset()[]/

PowerOn()[]/

ShutdownPtS()[]/ ShutdownPtS[]/

Protection Stop

Reset()[]/ Power Off

PowerOff()[]/

[Initialization failed]/PowerOff() PowerOff()[]/ []/PowerOff() []/PowerOff()

Figure 8: UML State Diagram of the ComputingComponent in the Fault Handler Pattern 3. The fault handler becomes one of the most crucial parts in the system concerning safety issues, so the development and the testing should be thorough. 4. Hardware and software redundancies exist in the system, thus meaning higher system costs. 5. Overall safety of the system is usually significantly improved. Design Patterns: • Singleton Design Pattern [8]: Use this pattern to assure only one fault handler exists in the system. Also Known As: To be determined. Related Requirements Patterns: • Controller Decompose Pattern: This requirements pattern defines the need for a fault handler in an embedded system. • User Interface Pattern: This pattern can be used for the user interface described in the Fault Handler pattern.