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

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.