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

A WAY FOR APPLICABLE FORMAL SPECIFICATION OF SAFETY
REQUIREMENTS BY TOOL-SUPPORT
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
patterns
1. INTRODUCTION
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.
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

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
pattern.
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
understand.
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.
4. SAFETY PATTERN IDENTIFICATION
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
CTL:
A((not q) W (p and (not q)))
LTL:
(not q) W (p and (not q))
µ-Calculus:
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
System
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
System).
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;
[0,T]:
proposition
validity
1
0
T
t
class beginning of validity: validity of a
proposition from a certain point in time on;
[T,∞):
proposition
validity 1
0
T
t
class beginning & duration of validity: validity
of a proposition between two points in time;
[T 1 ,T 2 ]:
proposition
validity 1
0
T 1 T t
2
Fig. 2. Illustration of the classes of the
classification criterion temporal restriction of
validity.
5. APPLICATION OF THE SAFETY
PATTERN APPROACH BY
USING THE TOOL SAPIS
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
crossing.
Therefore, the safety requirement belongs
to the class safety requirements with
temporal dependencies between
propositions.
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
interval.
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
necessity.
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
identified:
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
train.message_level_crossing_not_
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
is:
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
requirement:
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)))
6. RELATED WORKS
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.
7. SUMMARY AND OUTLOOK
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
specified.
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.
ACKNOWLEDGEMENT
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.
REFERENCES
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.
225-245.
Bitsch, F. and C. Lovasi (2002). Safety Pattern
Instantiation System - SAPIS. http://
www.ias.uni-stuttgart.de/safety_patterns/.
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:
Springer-Verlag.
Gorski, J. (1986): Design for Safety Using
Temporal Logic. In: Proceedings of Safecomp
’86 (W.J. Quirk, Ed.), pergamon press,
Oxford.
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
Verlagsgesellschaft.
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.