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


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



Friedemann Bitsch

Universität Stuttgart, Germany, Institute of Industrial Automation and Software Engineering (IAS),

Adress: Pfaffenwaldring 47, D-70550 Stuttgart

Phone: +49 (0)711 685-7292, Fax: +49 (0)711 685-7302, E-mail: bitsch@ias.uni-stuttgart.de

Abstract: This paper is focused on a solution to solve difficulties of formal specification of safety

requirements according to CENELEC standards. A faulty or ambiguous specified safety requirement

may lead to the development of a railway system, which contain hazards for men and environment.

Formal specification languages had been developed for avoiding ambiguities. But experiences show that

such formal languages involve difficulties of correct application. These difficulties and hazards in

consequence can be met with the application of patterns for formal specification of safety requirements.

Such patterns are called safety patterns, enabling the developer to specify correctly, precisely and easily

interpretable safety requirements in an applicable way. This paper explains how the selection of the

suitable safety patterns is supported by the software tool SAPIS (Safety Pattern Instantiation System). A

dialog-based user interface guides the developer to characterise the needed safety requirements and to

formulate them correctly.

Keywords: safety requirements, formal specification, precise formulation, temporal logic, specification



When developing safe railway control systems

issues of functional safety have to be specified in

form of safety requirements. If a safety

requirement is formulated in an ambiguous way

or if it is misinterpreted by an engineer the

consequences could be fatal in such a way that

the system is not safe. For that reason the precise

and correct specification of safety requirements

is a very important prerequisite to guarantee safe

operation of such a system. Further benefit of

precise safety requirements specification is that it

enables a precise check if an operational system

or software model actually meets these safety

requirements. An applicable verification method

is model checking. It is a finite state verification

method allowing to perform automatically

formal checks of the operational model.

Algorithms pass through the complete state space

of the operational model of the software and

simultaneously the compliance of the specified

requirements is checked. For that purpose the

operational model has to be specified as a finite

state transition system, while the requirements

are typically specified in temporal logic (Dwyer

et al. 1999). It would be obvious to use formal

verification to check a model against an entire

requirements specification. But from an

economical point of view this would be too

expensive, because formal verification still

requires too much man power. Therefore the use

of formal verification is reasonable for safety

requirements, only.

In prEN50129 finite state machines are

described in the following way: “Many systems

can be described in terms of their states, their

inputs, and their actions. Thus when in a state S1,

on receiving input I a system might carry out

action A and move to state S2. By describing a

system’s actions for every input in every state we

can describe a system completely. The resulting

model of the system is called a finite state

machine. It is often drawn as a so-called state

transition diagram showing how the system

moves from one state to another [...].” Nowadays

a widespread notation for state machines are the

state transition diagrams of the Unified

Modelling Language (compare Arabestani &

Gayen, 2000). Preconditions are discussed and

approaches are referenced in Bitsch, 2002 to

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.


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.



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:
















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


(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


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)



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


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.




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

safety pattern to the respective safety

requirement in context to the operational model.

The result is a formally specified safety

requirement, which is an instance of a safety


In the catalogue every safety pattern is given

in the formal notations CTL (Computation Tree

Logic), LTL (Linear Time Temporal Logic) and

µ-Calculus. Furthermore the specification in

Temporal OCL (an extension of the Object

Constraint Language by temporal logic aspects,

compare Flake & Mueller, 2001) is in process. In

this way the developer is able to choose the

formalism required for the model checker

according to his preferences. For that reason the

expressive power of different variants of

temporal logic is considered in the safety

patterns approach. Every safety pattern is

explained in natural language, so that the

meaning of the safety patterns is easily to


Like explained before, IEC61508 and

EN50128 necessarily require for reasons of clear

understandability that in case of formal

specification there should be also a formulation

in natural language. For that reason safety

patterns do not only support formal specification

of safety requirements but also enable

specifications in a terminology of natural

language equivalent to the formal specification.

Every safety pattern contains a specification

template in a restricted terminology of natural

language. The meanings of the allowed

constructs and words being used for description

are fixed (see Bitsch & Göhner, 2002). That

means that a norm language for safety patterns is

used. A norm language sounds like a natural

language, but it is a strongly reduced form of

natural language. It is a connecting link between

natural languages and formal languages (Ortner,

1997 and Schienmann, 1997). By the fixed

assignment of a formal formulation and a

formulation in a restricted safety requirements

related terminology the equivalence of formal

specification and specification in words of

natural language is guaranteed. The demands of

the standards are fulfilled and simultaneously the

weakness of the standards is solved. In this way a

safety pattern can also be used to precisely

formulate a safety requirement in natural

language. Especially in teamwork, clearly

understandable and precisely formulated

specifications of safety requirements are a

precondition for the development of safe

automation systems. Besides in communication

with approval authorities the meaning of formal

safety requirements based on such a safety

pattern catalogue is easy to understand. Figure 1

shows an example of a safety pattern.

It is also in process to enlarge the data in

every safety pattern with graphical descriptions.

The graphical description contains typical

possible sequences of states and also different

examples of possible computation paths (see

Bitsch & Göhner, 2002).

Bitsch, 2002 showed the role and the benefit

of embedding the safety pattern approach in the

process of developing system requirements

specifications for railway systems. Also a

process is explained how to specify safety

requirements in context of the operational model

(see also Bitsch et al. 2000 and Moik, 2002) so

that safety requirements are formulated with

variables and sizes of the operational model.

We can note the following benefits of safety

patterns. Safety patterns support:

• to specify correctly safety requirements in

formal languages.

• to interpret correctly formal specifications.

• to specify safety requirements by using a

restricted terminology of natural language

corresponding to the formal specification.

• different tools for correctness checking.


The safety patterns are catalogued by means of

14 classification criteria. Every classification

criterion is decisive for the classification of a

safety pattern to one of two or more classes. E.g.

one criterion is temporal restriction of validity.

The decisive question is: What kind of temporal

validity restriction of a property is to be set? The

possible classes are duration of validity,

beginning of validity or beginning and duration

of validity (see Figure 2).

A certain combination of classes of different

classification criteria describes the different

properties of a certain safety pattern. Based on

this safety patterns classification scheme it is

possible to identify the appropriate safety pattern

for the safety requirement to be specified. Every

classification criterion can be used to

characterise a property of the safety requirement

to be specified. In this way the properties of the

searched safety pattern are identified and so the

searched safety pattern itself is identified.

Safety Pattern ds-wet-27

dynamic safety requirement without explicit time, concerning beginning of validity and

concerning permissibility of validity, safety pattern no. 27

Safety Pattern in Norm Language

Only strictly after that point in time when p is valid then it is permitted that q is valid .

Safety Pattern in Formal Languages


A((not q) W (p and (not q)))


(not q) W (p and (not q))


nu Z.((p and ( not q)) or (( not q) and [-]Z))

Temporal OCL 3 : inv: let requiredSequence = Sequence{not qConf, pConf}

in begin implies self@post→forAll(s:OclPath |

s→includes(requiredSequence) or s→excludes(qConf))

Explanation in Natural Language

A main characteristic of this safety pattern is that q may only occur strictly after p. The exact

point in time after p is irrelevant. The main thing is that q occurs strictly after p. That means q

must neither occur before p nor becomes true together with p. q may occur but it do not have to.

Example of Use


Level crossing in radio based operation

Conventional specification of the safety requirement

Only if the train has received the message “level-crossing-protected”, then it is permitted that the

train drives on the level crossing.

Safety requirement in norm language

Only strictly after that point in time when train.received_message_level-crossing_

protected is valid then it is permitted that train.train_drives_on_level-crossing is valid.

Safety requirement in formal language (CTL)

A( (not train.received_message_level-crossing_protected) W

(train.train_drives_on_level-crossing and

not train.received_message_level-crossing_protected)))

Fig. 1. Example of a safety pattern.

For developers using the safety pattern

concept it would be very hard to identify the

suitable safety pattern only on basis of a

document, in which the safety patterns are listed.

To keep overview on the different kinds of

classification criteria and of the respective

classes a tool support in form of a dialog system

is necessary. In this section the tool belonging to

the safety pattern approach is explained. This

software tool also helps to determine, which

criteria are relevant for the safety requirement to

be specified. It also supports the user to make

decisions in a meaningful sequential order. The

tool name is SAPIS (Safety Pattern Instantiation


By using different kinds of dialog modes the

dialog system is adaptable for users with

different background knowledge and experiences

related to the safety pattern approach. In

principle there are three possible modes of dialog

guidance. The first dialog mode is suitable for

new users. The second one is the experienced

user mode and the third dialog mode is the expert

mode. The use of the third dialog mode is the

less large-scale and the fastest one. But it can be

used effectively by those users only who know

the safety pattern classification very well. In the

following the different modes are explained:

1 st Strong guided dialog: In this dialog

mode the dialog steps are determined by the tool

SAPIS. The dialog takes place in form of a

question-answer-interaction. The dialog is

strongly controlled by the dialog system because

3 “pConf” describes the configuration, which is reached at the occurrence of the event p and “qConf” is the configuration, which is

valid at the execution of the action q. Configurations describe unambiguously every possible system state and in this way they also

represent certain events and actions.

the order of questions is fixed. At the beginning

of the dialog the user is able to choose one of

several question orders. That way the user is able

to check the result of a complete dialog by

comparing the identification of the suitable

safety pattern using different question orders.

2 nd Light guided dialog: In difference to the

1 st dialog mode the user sees in one window all

classification criteria with the classes belonging

to them. That means he does not see the

questions step-by-step but rather all criteria

appear together in a form he has to fill in.

Reading of questions is not necessary for

experienced users but would be time consuming.

Therefore, only the criteria and the classes are

displayed. The question of a certain criterion is

only displayed on inquiry. First the dialog is

controlled by a general order, which

classification decisions should be made before

which other ones. Second it is controlled through

the knowledge about which safety pattern class

excludes which other ones. Those classification

criteria which have already been decided and

those, which can not be decided yet are masked.

3 rd Open dialog: In this dialog mode all

possible question orders are considered. Like in

the second dialog mode the user has to fill in a

form, in which all classification criteria with the

possible classes are displayed in one window.

The user is able to choose at any point in time

any classification criterion he likes to answer.

The dialog is controlled by SAPIS only in this

way that the system has knowledge about which

safety pattern classes are excluded by which

other ones. In difference to dialog mode 2 it is

possible that by one decision also other criteria

might be implicitly decided, in case that the

decision for one criterion requires that other

criteria are decided before. For the userfriendliness

of SAPIS, it is important in the 3 rd

dialog mode that the user is able to identify the

appropriate safety pattern via any possible order

of classification criteria decisions. With the help

of the tool Cernato (navicon GmbH, 2002) it can

be checked if all these possibilities are

implemented in SAPIS. It is based on the

methods of the begrifflichen Wissensverarbeitung

(conceptual knowledge work) of Wille

et al. 2000. This tool enables a complete

graphical overview and analysis of data

dependencies, exceptions, mutuality, connections

and differences.

In all modes it is also possible to get further

more detailed information for every criterion and

its classes if the formulation of a question is not

sufficient for the user to decide for a class.

SAPIS is usable via Internet and is available at

the location which can be found in the reference

at Bitsch & Lovasi, 2002. The GUI runs in a web

browser on a client computer. The application

logic is located on a web server. This computer

or a third one is used as database server for the

safety pattern data. The following section

explains by means of an example of use how

SAPIS supports the precise and correct

specification of safety requirements.

class duration of validity: validity of a

proposition only until a certain point in time;








class beginning of validity: validity of a

proposition from a certain point in time on;



validity 1




class beginning & duration of validity: validity

of a proposition between two points in time;

[T 1 ,T 2 ]:


validity 1


T 1 T t


Fig. 2. Illustration of the classes of the

classification criterion temporal restriction of





The application of SAPIS will be demonstrated

by a brief example. For the safety requirement of

a one-way level crossing in radio based operation

there is the safety requirement:

If the train does receive the message

“level_crossing_not_protected“, then the train

has to stop before the level crossing.

To detect the suitable formal specification in

CTL first the safety requirement has to be

assigned to the correct classes of the different

criteria with the help of SAPIS. We choose the

mode “strong guided dialog“ so that the order of

the question is given. In the following the

relevant classification criteria , which have to be

decided are listed (a) with the questions

belonging to them (b). Then the decision for the

correct class the safety requirement belongs to is

explained (c):

1. a. Existence of a temporal logic

aspect in the safety requirement.

b. Does the safety requirement contain any

temporal logic aspect?

c. Yes, the possible message reception

and the stop of the train before the

level crossing are in a temporal

relation. Therefore the class dynamic

safety requirement has to be selected.

2. a. Type of time specification.

b. Does the safety requirement contain

any explicit time specification?

c. No, there is no temporal statement in

dependence on a system clock. For that

reason it is a safety requirement with

implicit time specification only.

3. a. Existence of temporal dependencies

between propositions.

b. Does the safety requirement contain

any temporal dependencies between

propositions or does it require a

reachability or an assurance of

reaching without temporal conditions?

c. There exists a temporal dependency

between ...

• if the train receives the message

“level_crossing_not_protected“ and

• that the train stops before the level


Therefore, the safety requirement belongs

to the class safety requirements with

temporal dependencies between


4. a. Temporal restriction of validity.

b. What kind of temporal validity restriction

of a property is to be set?

c. It is stated at which point in time the train

has to be stopped. So the correct class is

beginning of validity.

5. a. Frequency of validity in validity


b. What is the frequency of the predicate

validity in the validity interval?

c. There is no safety related necessary

restriction with respect to the frequency

but the train must stop at least one time

if the train receives the negative message.

Therefore the right class is validity at

least n times (with n=1).

6. a. Modality of demand.

b. What is the modality of demand?

c. The safety requirement does not state a

permitted or forbidden behaviour but a

necessary one. That is why the class is


7. a. Type of beginning of validity.

b. When exactly should the validity of the

demanded property begin?

c. The stopping of the train may be started

from that point in time on when the train

receives the message. Therefore, the

safety requirement has to be assigned to

the class validity from a certain point in

time on.

Based on this classification the following

safety pattern with the appropriate explanation is


Safety pattern in norm language:

b must be valid at least once together with or

anytime after a is valid.

Safety pattern in formal language (CTL):

AG (a → AF b)

Specification of the safety requirement in

norm language:

(train.current_velocity=0 and

train.current_position < levelcrossing.position_beginning)

must be

valid at least once together with or anytime after


protected is valid.

Specification of the safety requirement in

formal language (CTL):

AG (train.message_level_crossing_not_

protected → AF (train.current_

velocity=0 and train.current_position

< level-crossing.position_beginning))

The example shows clearly that the variables

of a safety pattern predicates can be substituted

by state, event, action, condition or configuration

variables of the corresponding operational

model, which has to fulfil the safety requirement.

Furthermore predicates with boolean meaning

can be inserted like comparisons with >,

emoving a signal). In that case a specific pattern

of the following kind is inserted:

Formulation in norm language:

α changes from valid to invalid

Formulation in formal language (CTL):

α & AX not α

In addition to this insertion, before all other

variables in the formal specification of the

requirement an AX has to be placed. It is in

process to support also this kind of instantiation

by the tool SAPIS.

For specification of complex safety

requirements several safety patterns have to be

combined by and, or, xor or not connectives

of Propositional logic. In other cases safety

patterns have to be inserted in other safety

patterns to specify complex safety requirements.

E.g. a safety requirement of a train door control


If the door block button is activated, the

ending of the door blocking is only permitted

when the signal v5 is not longer contacted.

It is obvious that this safety requirement

consists of two parts: A causal condition and a

temporal condition. The causal condition for the

whole safety requirement is: the door block

button is activated. The temporal condition for

the ending of the door blocking is: the signal v5

is not longer contacted. For that reason two

safety patterns have to be identified in such a

way like it is explained before, to specify this

safety requirement.

First selected safety pattern:

Safety pattern in norm language:

Always if a is valid, then b must also be valid.

Alternative: Always if a is valid, then it must

also be valid: b

Safety pattern in formal language (CTL):

AG (a → b)

Instantiation of this safety pattern for the relevant

part of the safety requirement:

Safety requirement in norm language:

Always if door_blockbutton_activated

is valid it must also be valid: b

For b a second safety pattern has to be inserted.

Second selected safety pattern:

Safety pattern in norm language:

a must be valid permanently until b is valid.

Safety pattern in formal language (CTL):

A(a W (b and a))

Instantiation of this safety pattern for the relevant

part of the safety requirement:

Safety requirement in norm language:

door_blocked must be valid permanently

until not signal_v5 is valid.

Total result - specification of the complete safety


Safety requirement in norm language:

Always if door_blockbutton_activated

is valid then it must also be valid:

door_blocked must be valid permanently

until not signal_v5 is valid.

Safety pattern formulation in formal

language (CTL):

AG (door_blockbutton_activated →

A(door_blocked W (not signal_v5

and door_blocked)))


Bitsch & Göhner, 2002 and Bitsch, 2001 have

already discussed works related to the safety

pattern concept. Moreover there is the pattern

library for the Certifier of the tool Statemate of

I-Logix Inc. (I-Logix Inc. and OFFIS Systems

and Consulting GmbH, 2002). A basic difference

of their pattern system is that they expect the

user to have knowledge and mastery of temporal

logic application, which is not necessary in our

approach. They only divide the patterns into four

classes and give no further support to identify the

correct pattern, neither by a detailed pattern

classification nor by a tool. There are no patterns

for specification in a terminology of natural

language and only in some cases explanations in

natural language are provided. A good idea is

that they give an example of a state diagram for

every pattern, which meets the respective

requirement. In some cases they give graphical

explanations using timelines.

A main difference to the safety patterns

approach is, that they do not restrict the practical

use of formal verification to the context of

safety. For this reason their considered kinds of

specification patterns are not restricted to safety

requirements. If the interest of a user in formal

specification was only in the context to safety, it

would be much easier to use a pattern system,

which is restricted to the context to safety.

Otherwise there are many patterns, which are not

relevant to safety requirements in general.

Therefore it is easier to select the suitable pattern

in a pattern system restricted to the context to

safety. Furthermore the bigger the pattern system

is, the more it is difficult to control ambiguities

of natural language terminology.

A closer approach is of Heiner et al. 2001

and Mertke et al. 2001. They do not use the term

“pattern” but implicitly there are patterns which

are designated as “requirement sentences” with

corresponding “formal formulas”. A basic

difference of their approach is that they focus on

SFC controls (Sequential Function Charts)

whereas the safety pattern approach is usable for

any kind of system or software model notation.

Second their core idea of applying the patterns is,

that the user has to specify requirements by using

defined sentence structures in natural language.

Their requirements specific technical language is

not oriented on the theoretical works of Ortner,

1997 and Schienmann, 1997. Their pattern

system only contains 18 patterns, which are

classified by two categories of requirement

contents. The safety pattern concept attaches

much more importance to the identification of

the properties of the safety requirement to be

specified. A similar approach and tool is not

known for requirement’s properties selection.

The approaches of Heiner et al. 2001,

Mertke et al. 2001 and I-Logix Inc. and OFFIS

Systems and Consulting GmbH, 2002 contain

significantly less patterns. That means first of all

that their approaches contain a bigger challenge

to the abilities of the user. The user needs more

control for composition and instantiation of

patterns. Second the safety pattern approach

enables the specification of those requirements,

which cannot be specified with the help of the

other approaches. The reason is that their

objectives are not to give a complete pattern

system for safety requirements specification.

Third the safety pattern concept supports the

specification of safety requirements not

containing temporal logic specific specification

problems only. One kind of these specification

problems is well described in prEN50129 and

IEC61508: “Quantified time intervals and

constraints are not handled explicitly in temporal

logic. Absolute timing has to be handled by

creating additional time states as part of the state

description.” So it is possible to specify some

problems in temporal logic but it is not explicitly

treated in the temporal logic languages. Such

kinds of problems are also supported by the

safety pattern approach in contrast to any other

known approach. With the help of other

approaches it is possible to specify those

requirements, too, but it is more difficult for the

user because he gets no support by special

patterns like in the safety pattern approach.

During the development of the safety pattern

classification of our approach we set value on

practical relevance of the safety patterns for any

kind of industrial automation system. A result is

e.g. that we consider requirements with explicit

time, the frequency of validity in a time interval

or safety requirements for time triggered systems

in own classes. Another example is that we

distinguish the exact succession of propositions

in detail, such that there may be an overlap

between the validity of the successor and the

predecessor. This is e.g. important for bus

systems. E.g. these cases are not considered in

any other known approach. So we can take the

note that in several respects the user has more

responsibility and more risk in other approaches.

Besides the extensive information listing for

every safety pattern in the safety pattern

approach is missing in the other approaches (e.g.

natural language and partly graphical

explanations). Finally only in the safety pattern

approach patterns are specified in several formal

languages. In any case the agreement of both

related approaches with the safety pattern

approach is the conviction of the benefit of

formal requirement specification patterns.


It has been shown how with the help of safety

patterns and the dialog system SAPIS the

recommendations and demands of the standards

IEC61508 and EN50128 for safety requirements

specification can be met. The formal

specification of safety requirements and the

corresponding specification in a terminology of

natural language are supported. The explained

approach also removes weaknesses of the

standards in this way that the correct use of

formal languages is supported for safety

requirements specification. Also the avoidance of

ambiguities is supported when using natural

language specifications for describing the formal

specifications. This is achieved by using safety

patterns formulated in the safety pattern norm

language. So the equivalence between both

specifications is guaranteed. The safety pattern

catalogue also helps to interpret correctly a

specified safety requirement in such a way that

the specification meaning can be looked up in the

safety pattern catalogue. In Figure 3 the principle

of the approach is shown.

With the tool SAPIS the safety pattern

concept moves from theory into practice. A web

application is available (see Bitsch & Lovasi,

2002) for identification of the appropriate safety

patterns for the safety requirements to be


We are still collecting more practical

experience for the safety pattern concept with the

help of case studies, especially by developing

system models related to the railway control

area. It is planed to extend the tool SAPIS by

support functions for the application of the

selected safety patterns for safety requirements

specification. The safety pattern norm language

is still under development. The reference of the

terms of the norm language is to be supported by

hyperlink technology. Also a graphical notation

in speciality for safety pattern specification is

currently being developed. So far graphical

representations are only used for explanations of

examples, which fulfil the requirement of the

respective safety pattern.

conventional safety requirment specification

safety pattern

dialogue system

safety pattern

identification catalogue

of the suitable

safety pattern

specification of safety requirement

• in formal language

• in norm language

formal language

• norm language

• graphical explanations

• explanation in natural language

• example of use

Fig. 3. Principle of the safety pattern approach.

Furthermore an XML-based language is

under development. Such an XML-based

language will be the basis to generate the

specification of the safety patterns in different

formal languages. In such a way it is not

necessary to specify manually every safety

pattern in several formal specification languages.

Besides, an XML-based safety pattern language

is also a suitable software technology basis to

explain the safety patterns by graphical

illustrations or by simulations. A further benefit

is that using XML a specification language could

be developed, which is easily useable and

interpretable and which is oriented according to

the safety pattern classification. Such a language

would not be as universal as temporal logic

languages but fit the characteristics of safety

pattern properties.


This work was sponsored by the German

Research Council (DFG) within the scope of the

focus area program (1064) on the “Integration of

Specification Techniques with Applications in

Engineering” which is gratefully acknowledged.


Arabestani, S. and J.-T. Gayen (2000).

Objektorientierte Analyse zur Modellierung im

Eisenbahnwesen. Signal & Draht

92(2000)1+2, S. 20-27.

Bitsch, F., E. Canver and A. Moik (2000).

Strukturierte Erstellung von Sicherheitsspezifikationen

in UML mit Hilfe der FMEA-

Methode. In: FORMS '99 - Formale Techniken

für die Eisenbahnsicherung (E. Schnieder,

Ed.), Fortschritt-Berichte VDI, Reihe 12,

Nr.436, VDI Verlag GmbH, Düsseldorf, S.


Bitsch, F. and C. Lovasi (2002). Safety Pattern

Instantiation System - SAPIS. http://


Bitsch, F. (2002). Process Model for the

Development of System Requirements

Specifications for Railway Systems. In:

Workshop on Software specification of safety

relevant transportation control tasks (E.

Schnieder, Ed.), Fortschritt-Berichte VDI, VDI

Verlag GmbH, Düsseldorf.

Bitsch, F. (2001). Safety Patterns - The Key to

Formal Specification of Safety Requirements.

In: Proceedings of 20th International

Conference SAFECOMP 2001 - Computer

Safety Reliability and Security (U. Voges, Ed.),

Berlin, Heidelberg: Springer-Verlag, LNCS

2187, S. 176-189.

Bitsch, F. and P. Göhner (2002). Spezifikation

von Sicherheitsanforderungen mit Safety-

Patterns. Software Engineering in der

industriellen Praxis, VDI-Bericht-Nr. 1666,

Düsseldorf, S. 29-40.

Heitmeyer, C. and J. Kirby, Jr., B. Labaw, M.

Archer and R. Bharadwaj (1998). Using

Abstraction and Model Checking to Detect

Safety Violations in Requirements Specifications.

IEEE Transactions on software

engineering, vol. 24, no. 11, pp. 927-948,

November 1998.

Dill, D.L. and A.J. Drexler, A.J. Hu, and C.H.

Yang (1992). Protocol Verification as a

Hardware Design Aid. Proc. IEEE Int’l Conf.

Computer Design: VLSI in Computers and

Processors, pp. 522–525.

Dwyer, M.B. et al. (1999). Patterns in Property

Specification for Finite-state Verification. In

Proceedings of the 21st International

Conference on Software Engineering.

Flake, S. and W. Mueller (2001). An OCL

Extension for Real-Time Constraints. In:

Advances in Object Modelling with the OCL

(T. Clark and J. Warmer, Eds.). Heidelberg:


Gorski, J. (1986): Design for Safety Using

Temporal Logic. In: Proceedings of Safecomp

’86 (W.J. Quirk, Ed.), pergamon press,


Huth, M. and M. Ryan (2000). Logic in

Computer Science – Modelling and reasoning

about systems. Cambridge: Cambridge

University press.

Kammel, K., K. Lennartz and K.-H. Suwe

(2000). Die Anwendung von formalen

Techniken aus Sicht des Eisenbahn-

Bundesamtes. In: FORMS '99 - Formale

Techniken für die Eisenbahnsicherung (E.

Schnieder, Ed.), Fortschritt-Berichte VDI,

Reihe 12, Nr.436, VDI Verlag GmbH,

Düsseldorf, S. 55-69.

CENELEC EN 50128 (2001). Railway

Applications - Communications, signaling and

processing systems - Software for railway

control and protection systems.

CENELEC prEN 50129 (2000). Railway

Applications - Safety related electronic

systems for signaling.

Heiner, M., Th. Mertke and P. Deussen (2001).

A Safety-oriented Technical Language for the

Requirement Specification in Control

Engineering. Computer Science Reports 09/01,

Brandenburg University of Technology at

Cottbus, May 2001.

International Standard IEC 61508 (2000).

Functional Safety of Electrical/Electronic/

Programmable Electronic Safety Related

Systems. International Electrotechnical

Commission, Geneva, Switzerland.

Mertke, Th., P. Deussen and M. Heiner (2001):

Eine anwenderorientierte Sicherheitsfachsprache

zur Verifikation von Steuerungsprogrammen.

In: Engineering komplexer Automatisierungssysteme

(EKA) (E. Schnieder,

Ed.), S. 297-309.

Moik, A. (2002). Ingenieurgerechte formale

Methoden für die Entwicklung von sicheren

Automatisierungssystemen. Dissertation, IAS,

Universität Stuttgart.

navicon GmbH (2002). Produktbroschüre

“Navican Decision Suite”. Frankfurt.

Ortner, E. (1997). Methodenneutraler Fachentwurf

- Zu den Grundlagen einer anwendungsorientierten

Informatik. Stuttgart, Leipzig: B.

G. Teubner Verlagsgesellschaft, 1997.

I-Logix Inc. and OFFIS Systems and Consulting

GmbH (2002). Statemate Magnum – Certifier

– Pattern Library – User Guide. Andover.

Schienmann, E. (1997). Objektorientierter

Fachentwurf. Stuttgart, Leipzig: B. G. Teubner


Villa, T., G. Swamy and T. Shiple. VIS User’s

Manual. The VIS Group, University of

California, Berkeley.

Wille, R. (2000). Begriffliche Wissensverarbeitung:

Theorie und Praxis. Informatik

Spektrum, Organ der GI, Band 23, Heft 6, S.

357-369, Dezember 2000.

More magazines by this user
Similar magazines