a way for applicable formal specification of safety requirements by ...

More documents

Recommendations

Info

check the compliance of safety requirements in an UML system model by model checking. In prEN50129 temporal logic is characterised as suitable for direct expression of safety requirements and as basis for formal demonstration that the expressed properties are preserved in the different development steps. Gorski, 1986 is a basic contribution outlining the benefit of temporal logic for precise specification of safety requirements. For those reasons in the CENELEC standard EN50128 and in the generic standard for safety critical systems IEC61508 the use of formal specification is recommended at least for specifying the software parts of a system in case of high safety critical systems. It is highly recommended for the highest Safety Integrity Level. From the point of view of the German supervising authority (Eisenbahnbundesamt) there is the objective of using formal methods not only for the software parts but also for the modelling of the system (see Kammel et al. 2000). A reason for the insignificant dissemination of formal specification of safety requirements lies in the difficulty of using temporal logic. In Bitsch, 2001 papers are referenced, which confirm these difficulties. How can be guaranteed that the formal specification of a safety requirement is correct and that temporal logic has been used correctly? How can be checked that a safety requirement specified in temporal logic is interpreted correctly? This paper is focused on the formal specification of requirements in context to safety. In section 2 the difficulty of specifying safety requirements by using temporal logic is discussed in some more detail. After these fundamentals, in section 3 the idea of the safety pattern approach is explained to overcome the barriers of the difficulty of formal safety requirements specification. On that basis section 4 points out, how the application of the safety pattern approach can be supported by a software tool in form of a dialog system. In section 5 the application of the safety pattern approach is explained. Related works are discussed in section 6 and finally the paper concludes by naming the most important results and with a discussion on future works. 2. DIFFICULTY OF SPECIFYING SAFETY REQUIREMENTS FORMALLY Heitmeyer et al. 1998 reports from the case study of Dill et al. 1992 on model checking, where not only model failures are detected but also errors in the formally stated requirements in temporal logic. Despite the automation of model checking, developers still have to be able to specify formally the safety requirements in temporal logic (Dwyer et al. 1999). In IEC61508 temporal logic is described in the following way: “Temporal formulas are interpreted on sequences of states (behaviours). What constitutes a ‘state’ depends on the chosen level of description. It can refer to the whole system, a system component or the computer program.” For the understanding and the application of the approach of formal safety requirements specification presented in this paper, it is not necessary to be able to use or to understand temporal logic. But for background knowledge and for checking the correctness of the examples in this paper, in the following a short introduction into the most popular kind of temporal logic, which is CTL (Computation Tree Logic), is given. CTL formulas consist of particular propositions. Every proposition corresponds to variables in conditions, events, actions, states or configurations of the operational model. The propositions are related by standard connectives of propositional logic and CTL temporal connectives. Connectives of propositional logic 1 are and, or, xor, not, →, ↔. Every CTL temporal connective is a pair of symbols. The first symbol is a path quantifier. When calculating the state space there are many execution paths starting at the current state. The symbol is one of A and E. A means “along All paths” and E means “along at least (there Exists) one path”. The second pair is one of temporal modalities, which describes the order of propositions in time along an execution path. These are X, F, G, U or W, meaning “neXt state”, “some Future states”, “all future states 1 Meaning of propositional logic connectives: p q p and q p or q p xor q p → q p ↔ q 0 0 0 0 0 1 1 0 1 0 1 1 1 0 1 0 0 1 1 0 0 1 1 1 1 0 1 1
(Globally)”, “Until” and “Weak until” 2 , (see Huth & Ryan, 2000 and Villa et al.). In the following the difficulty of safety requirement specifications in CTL is shown by means of an example. A safety requirement for a pneumatic train door control could be: The execution of the close function of valve v3 is permitted only after receiving the close command. (1) shows the formal specification of this safety requirement. However, the problem is that (2) is also a possible formal specification. It depends on the interpretation of the word “after”, which of these possible formal formulas is the right one. A(not close_function_valve_v3 W (receive_close_command and not close_function_valve_v3)) A(not close_function_valve_v3 W (receive_close_command and not close_function_valve_v3)) and (AG (receive_close_command → (AX close_function_valve_v3 and AX AX AG not close_function_valve_v3)) xor AG not close_function_valve_v3) (1) (2) In (2) “after” has the meaning of “exactly after” in the sense of directly after or immediately after. In context to the example the meaning would be that until the close command is executed the execution of the close function is not permitted. In the chronological succession of actions the valve close function is not true in that time when “receiving the close command” becomes valid. In case that the safety requirement is related to a time triggered system the meaning is that the execution of the close function is only permitted in the state after the next time trigger. In case of an event triggered system then in between the temporal succession of the both actions it is not permitted that any other variable defined in the operational model (e.g. state, action or event variable) changes its value. In (1) “after” has the meaning of “strictly after”. In context to the example the meaning would be as in (2) that until the close command 2 In (p W q) with the temporal modality “Weak until” the proposition q does not have to be true in any state in difference to the formula (p U q) with the ordinary “Until”. In particular, if q is never true, then p needs to hold for all states of that path. is executed the execution of the close function is not permitted but in difference to (2) it is permitted any time after. This example shows that such kind of formal formulas like (1) or (2) are difficult to read, to understand and to write correctly especially for an engineer, who is not familiar with higher logic. It easily happens, that a formula is specified, which states something different than it should. To handle these difficulties, in IEC61508 and EN50128 it is necessarily required to specify in addition to formal specification also in natural language for reasons of clear understandability. But this is not a sufficient solution. The problem is that natural language permits ambiguous formulations. Therefore a possible consequence could be a specified safety requirement, which is interpreted differently with respect to the original intention of the formal specification. Moreover an equivalent specification of the original intention cannot be guaranteed. A solution to solve these problems of applicable precise specification and interpretation and of specification in a natural language terminology equivalent to formal specification is the safety pattern approach. This approach is explained in detail in the next section. 3. SAFETY PATTERNS – THE KEY TO FORMAL SPECIFICATION OF SAFETY REQUIREMENTS The core idea of the safety pattern approach is that the engineer applies pre-specified generic safety requirements for safety requirements specification (see Bitsch, 2001 and Bitsch & Göhner, 2002). These patterns contain only those temporal logic expressions, which are suitable for the different kinds of safety requirements. Because these patterns are used for the specification of safety requirements they are called safety patterns. They are listed in a catalogue of safety patterns. This catalogue contains 305 different safety patterns. In a first step the developer identifies the suitable safety pattern with the respective formal formula in this catalogue. The identification is supported by a structure of the safety patterns based on a semantic classification of different kinds of safety requirements. Bitsch, 2001 and Bitsch & Göhner, 2002 explain the classification and the principle of deriving safety patterns. In a second step the developer has to adapt the identified
Page 1: A WAY FOR APPLICABLE FORMAL SPECIFI
Page 5 and 6: Safety Pattern ds-wet-27 dynamic sa
Page 7 and 8: mode “strong guided dialog“ so
Page 9 and 10: is, the more it is difficult to con
Page 11: Safety Reliability and Security (U.

a way for applicable formal specification of safety requirements by ...

Create successful ePaper yourself

Delete template?

Save as template?