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

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.