Safety of Computer Control Systems 1992 (Safecomp ' 92). Computer Systems in Safety-Critical Applications

310 Pages·1992·30.197 MB·English

by  H.H. Frey

SAFETY OF COMPUTER
CONTROL SYSTEMS 1992
(SAFECOMP'92)
Computer Systems in Safety-critical Applications
Proceedings of the IF AC Symposium,
Zürich, Switzerland, 28 - 30 October 1992
Edited by
HEINZ H. FREY
ABB Transportation Systems Ltd,
Zürich, Switzerland
Published for the
INTERNATIONAL FEDERATION OF AUTOMATIC CONTROL
by
PERGAMON PRESS
OXFORD · NEW YORK · SEOUL · TOKYO
UK Pergamon Press Ltd, Headington Hill Hall, Oxford 0X3 OBW, England
USA Pergamon Press, Inc., 660 White Plains Road, Tarrytown, New York 10591-5153, USA
KOREA Pergamon Press Korea, KPO Box 315, Seoul 110-603, Korea
JAPAN Pergamon Press Japan, Tsunashima Building Annex, 3-20-12 Yushima, Bunkyo-ku, Tokyo 113, Japan
Copyright© 1992 IFAC
All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or
transmitted in any form or by any means: electronic, electrostatic, magnetic tape, mechanical,
photocopying, recording or otherwise, without permission in writing from the copyright holders.
First edition 1992
Library of Congress Cataloging in Publication Data
A catalogue record for this book is available from the Library of Congress
British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
ISBN 0-08-041893-7
These proceedings were reproduced by means of the photo-offset process using the manuscripts supplied
by the authors of the different papers. The manuscripts have been typed using different typewriters and
typefaces. The lay-out, figures and tables of some papers did not agree completely with the standard
requirements: consequently the reproduction does not display complete uniformity. To ensure rapid
publication this discrepancy could not be changed: nor could the English be checked completely.
Therefore, the readers are asked to excuse any deficiencies of this publication which may be due to the
above mentioned reasons.
The Editor
Printed in Great Britain
IFAC SYMPOSIUM ON SAFETY OF COMPUTER
CONTROL SYSTEMS 1992 (SAFECOMF92)
Computer Systems in Safety-critical Applications
Sponsored by
International Federation of Automatic Control (IFAC)
Co-sponsored by
International Federation for Information Processing (IFIP)
- Technical Committee TC10
Organized and Supported by
European Workshop on Industrial Computer Systems (EWICS)
- Technical Committee on Safety, Security and Reliability
Swiss Federation for Automatic Control (SGA)
ABB Transportation Systems Ltd, Zurich, Switzerland
Austrian Computer Society (OCG)
Swiss Association for the Promotion of Quality (SAQ)
Centre for Software Reliability, Newcastle-Upon-Tyne, UK
The British Computer Society, London, UK
International Programme Committee
H.H. Frey (CH) (Chairman) F. Koornneef (NL)
R. Bloomfield (UK) (EWICS TC7 Chairman) J.L. de Kroes (NL)
K. Asmis (CON) R. Lauber (G)
S. Bologna (I) J.F. Lindeberg (N)
L. Boullart (B) L. Motus (RUSSIA)
G. Dahil (N) J.M.A. Rata (F)
B.K. Daniels (UK) F. Redmill (UK)
W. Ehrenberger (G) M. Rodd (UK)
K. Frühauf (CH) B. Runge (DK)
R. Genser (A) G.H. Schildt (A)
J. Gorski (PL) E. Schoitsch (A)
S.L. Hansen (DK) B. Sterner (S)
K. Kanoun (F) A. Toola (SF)
H. Kirrmann (CH) G. Vuilleumier (CH)
National Organizing Committee
H.H. Frey (Chairman)
J. Frey
K. Frühauf
H. Kirrmann
R. Messerli
PREFACE
Computer systems controlling and monitoring industrial processes and applied in various ways in
critical missions are commonplace in today's world. Even the use of computers in life-critical
applications is generally accepted, provided that appropriate technology and project management are
used and certain principles and guidelines are carefully observed by specifically trained and
experienced engineers. Significant changes in technology, the increased use of computer systems and
experience have led to the development of these principles and have helped create guidelines in the
key areas of system and software engineering in safety-critical applications.
This book represents the proceedings of the IFAC Conference on Computer Systems in Safety-critical
Applications held in Zurich, Switzerland, 28-30 October 1992. This conference continues the series
of SAFECOMP conferences and workshops which have been held since the first SAFECOMP in
1979. SAFECOMF92 is the 10th in the series. The conference is now held annually. The initiator of
the SAFECOMP events is EWICS TC7, the European Workshop on Industrial Computer Systems TC
on Safety, Security and Reliability. EWICS TC7 was founded in 1974 in Zürich under the name of
Purdue Europe.
SAFECOMP92 advances the state of the art, reviews experiences of the past years, considers the
guidance now available and identifies the skills, methods, tools and technologies required as we move
toward the 21st century.
The great response to the Call for Papers for this conference clearly indicates the ever-growing
importance of computer systems where safe and highly reliable operation is required and shows the
increased interest on the part of industry, system operators and authorities. I must thank all the
authors whose work makes the technical level o fthe conference a high one as well as the International
and National Organizing Committees and their staffs and the co-sponsors whose support have made it
possible to hold SAFECOMP'92.
Heinz H. Frey
A CASE STUDY IN THE ANALYSIS OF SAFETY REQUIREMENTS
Glenn Bruns
Stuart Anderson
Laboratory for Foundations of Computer Science
Computer Science Department, University of Edinburgh
Edinburgh EH9 3JZ, UK
Abstract. We show how formal methods can be used to assist in developing requirements of
a safety-critical system. The approach is to express the requirements in temporal logic, and
then to develop a process model satisfying the requirements. The existence of such a model
ensures the requirements are consistent, and also helps in their validation.
Keywords. Safety; computer software; concurrency; formal methods; temporal logic.
INTRODUCTION SSI c. panel\
The literature on the application of mathematical
methods to the construction of safety-critical systems
high-speed
has tended to assume the requirements analysis is
link
given; concentrating on proving properties of spec-
TFM TFM
ifications (Atkinson and Cunningham, 1991) or of
implementations (Bruns and Anderson, 1991). Here
we explore the use of such methods in formulating
point signal
the safety requirements for systems. Requirements
analysis is an open-ended task but we believe that
by using formally expressed properties and models Fig. 1: Solid State Interlocking
of the system we can support important verification
and validation activities in the requirements stage.
In this paper we explore the use of temporal logic of trains. "Safe", in this context, means that the sys-
and process algebra in carrying out the requirements tem is designed to protect the signal operator from
analysis for a component designed for use in a rail- inadvertently sending trains along routes that could
way interlocking system. We begin by developing lead to a collision or derailment. The entire BR net-
the service and safety requirements of the compo- work is controlled by many SSI's, each responsible
nent. We are then faced with the questions: Is a for one sub-network.
system with these properties feasible? How well does
a system with these properties meet our informal no- Figure 1 depicts an SSI and the devices it controls.
tion of the system? We answer these by constructing Safe commands issued from the control panel are al-
a system with the properties, thereby verifying the lowed to effect signals and points via messages sent
consistency of the properties and providing a simple over a high-speed communication link to track-side
"simulation" model of a system which satisfies these functional modules (TFM's).
properties. We focus on the detection of failures in
a low-speed communication link, but the approach One of the safety-related features of the SSI is its
taken here could be applied to all the service and pattern of communication with the TFM's. In-
safety requirements. An important feature of the ap- stead of sending signal or point commands only
proach is the discovery/refinement of requirements as needed, the SSI sends a message of the form
necessitated by the process of building a model which {TFM address, state) to each attached TFM about
satisfies the chosen properties. once every second, indicating the intended current
device state. These messages are sent in a predefined
cyclic pattern, called a major cycle, one TFM after
BACKGROUND another. After sending a message, the SSI waits at
most a few milliseconds for the addressed TFM to
The overall function of British Rail's Solid State In-
respond with the current state of the device. This
terlocking (SSI) (Cribbens, 1987) is to adjust, at the
scheme allows failures of the TFM's and the com-
request of the signal operator, the settings of signals
munication link to be detected quickly, and forces
and points in the railway to permit the safe passage
devices that have autonomously changed state to re-
SSI c. panel] such a hierarchical safety analysis. We will simply
observe that the primary safety requirements the SSI
must guarantee are: timely and error-free delivery of
commands and timely detection of failures.
TFM SPC SSI-side The SSI can satisfy these requirements if a high-speed
Protocol Converter
link is used. The bandwidth of the link and error
coding of messages ensures that the first requirement
low-grade link |
is met. The TFM-command cycling scheme ensures
X
TFM-side the second is met. Both requirements are threatened
TPC
Protocol Converter by slow-scan.
In this study we focus on the ability of the LGL to
meet the second requirement. In the next section
we develop properties which if they are satisfied by
TFM TFM
an implementation of slow-scan will guarantee that
slow-scan faults will evoke the same behaviour in the
overall system as a failure of the high speed data
Fig. 2: The Slow-scan System
highway.
REQUIREMENTS ANALYSIS
turn to their proper state.
In requirements analysis we are interested in express-
In some sections of the BR network, many miles of
ing all the required properties of the system in a pre-
track lie between TFM's, making the cost of the high-
cisely stated form. In this section we demonstrate
speed link prohibitive. A cheaper low-speed link can-
the use of a temporal logic to express such proper-
not be directly adopted because it could not support
ties. The models underlying the temporal logic are
the bandwidth needed for the TFM command cycling
labelled transition systems, also referred to as pro-
scheme. On the other hand, dropping the scheme
cesses. These systems describe the behaviour of real-
would endanger system safety and force changes to
world systems as states, plus actions that effect state
the SSI and TFM communication protocols. A pro-
changes. Thus, in describing properties of systems,
posed solution is to reduce the needed bandwidth by
we are interested in expressing the ability of a system
designing a pair of protocol converters, one at each
to carry out (or fail to carry out) certain sequences
end of a low-speed link (see Figure 2). The SSI-side
of actions.
protocol converter (SPC) accepts TFM commands,
and responds immediately to the SSI just as a TFM
In slow-scan we are certainly interested in six actions
would, but only sends commands along the low-speed
which should be visible to the outside world (overbars
link occasionally. The TFM-side protocol converter
are used to denote output actions):
(TPC) sends a command to each attached TFM once
every second. Responses from the TFM's are occa-
comm-in: an input action which occurs when slow-
sionally sent by the TPC to the SPC, in order to
scan receives an command from the SSI
update the SPC's device status information. This ar-
comm-out: an output action which occurs when the
rangement of low-speed link (also called a low-grade
TPC generates a command intended for a re-
link, or LGL) and protocol converters is called a slow-
mote TFM
scan system. The requirements we describe here and
the constructed model are broadly in line with those status-in: an input action which occurs when a re-
reported in(Taleb and Gurney, 1990). mote TFM generates a status input to the TPC
status-out: an output action which occurs when the
Clearly the slow-scan system must differ from a high- SPC generates a status output to the SSI
speed link in a manner observable to an external ob-
fail: an output action which occurs when some in-
server. For a safety analysis we do not require slow-
ternal failure occurs in slow-scan
scan to possess all the properties of a high-speed link
det: an output action which occurs when slow-scan
but we should require that properties sufficient to
has detected a failure
guarantee the safety of the system should hold for
slow-scan. In addition we should expect some (suit-
In some ways this list of actions can be seen as a
ably diminished) level of service from the system.
"black box" description of slow-scan. The actions
carry no information of the contents of the messages,
SAFETY CONSIDERATIONS they just indicate they occur — since we are inter-
ested primarily in safety we have no need for ad-
Taken on its own, slow-scan cannot be considered ditional detail. In addition we have no idea of the
safety-critical, since it does not directly control phys- sequences of these actions which the system might
ical devices. However, by first looking at the safety- allow. The goal of requirements analysis to develop
critical properties of the train routing system as a properties of the sequences of actions of the system.
whole, and then working through the levels of the
system, it is possible to obtain derived safety require- To compress the presentation of the process of devel-
ments of slow-scan. There is not room here to present oping properties we focus on a single one, that of the
2
requirement for timely error-detection. ple, the formula μΖ.(—)tt Λ [—]Z holds of deadlock-
free processes.
Formalising Safety Properties
Before considering specific properties of slow-scan we
The requirement has two components. Informally we present two more abbreviations that often make it
can state these properties as follows: possible to avoid the fixed-point operators:
• After a low-grade link failure, slow-scan will [1]*φ =f νΖ.φΛ[1]Ζ
eventually detect the failure and stop respond- {Ε)*φ d= μΖ.φν (L)Z
ing to the SSI and TFM.
Informally, [Σ]*φ holds if φ always holds along all
• No false alarms occur.
paths composed of actions in the set L. For exam-
ple, the absence of deadlock can be written [—]*(—)tt
We use the modal mu-calculus (Kozen, 1983) in a — in every state some action is possible. The dual
slightly extended form (Stirling, 1989) as our tempo- operator (Σ)*φ holds of processes having a finite ex-
ral logic. The syntax of the mu-calculus is as follows, ecution path composed of actions from L leading to
where L ranges over sets of actions and Z ranges over a state in which φ holds.
variables:
We are ready now to formalise the two important
φ::=^φ\φΑφ | [L\4>\ Z \νΖ.φ slow-scan properties. Recall the first property:
1 2
Informally, the formula ->φ holds of a process P if φ After a low-grade link failure, slow-scan
does not hold of P. The formula φ\ A φ holds of P if will eventually detect the failure and stop
2
both φ\ and φ hold of P. The formula [Σ]φ holds of responding to the SSI and TFM.
2
P if φ holds for all processes P' that can be reached
There are two distinct parts to this property: a) fail-
from P through the performance of action a G L.
ures are eventually detected, and b) after detection
The formula νΖ.φ is the greatest fixed point of the
eventually no responses are made to the TFM's or
recursive modal equation Z — φ, where Z appears in
SSI. In formalizing the first part, we have the idea
φ. Some intuition about fixed point formulas can be
"after a fail action occurs then eventually a det ac-
gained by keeping in mind that νΖ.φ can be replaced
tion occurs". Care needs to be taken here with the
by its "unfolding" : the formula φ with Z replaced by
notion of eventuality, however, because the modal
νΖ.φ itself. Thus, νΖ.φ A [{a}]Z = φ A \{α}](νΖ.φ A
mu-calculus has no "built-in" notion of time — we
[{a}]Z) = φΑ [{α}](φ A [{α}]{νΖ.φ A [{a}]Z)) = ...
only have actions. To capture the notion of eventu-
holds of any process for which φ holds along any ex-
ality in this informal statement of the property we
ecution path of a actions.
need the idea that there is some time frame which
is (approximately) the same at either end of slow-
The operators V, (a), and μ can be defined as duals
scan. In order to capture this we introduce a new
to existing operators (where φ[φ/Ζ] is the property
output action called tick which indicates the passage
obtained by substituting φ for free occurrences of Z
of time in this time frame. Any process which sat-
ίηφ):
isfies the safety properties given below should also
Φι V<£ = -*(Φι Αφ) ensure that tick indicates the passage of time at both
2 2
ends of slow-scan.
{1)φ W -[¿b<¿
μΖ.φ d= ^νΖ.φ[^Ζ/Ζ} The next step is therefore to define an abbreviation
for the property "if tick actions continue to occur
Informally (Ι*)φ holds of a process that can perform then eventually action a will occur" :
an action in L and thereby evolve to a process satis-
fying φ. As with ι/Ζ.φ, the formula μΖ.φ can be un- even(a) = μΖ.[—ϋε^α]*[ί^]Ζ
derstood through unfolding, except here only finitely
many unfoldings can be made. Thus, μΖ.φ V ({a})Z A reasonable translation of this formula to English is
holds of a process that can evolve to a process satis- "action a must eventually occur if tick actions con-
fying φ after finitely many occurrences of action o. tinue to occur". A useful and closely-related abbrevi-
ation captures the property "property φ must even-
These additional abbreviations are also convenient tually hold if tick actions continue to occur".
(where L ranges over sets of actions, and Act is the
set of CCS actions): Part of the formalisation of our property is that fail-
ure will eventually be detected after a failure has oc-
[αι,...,αη]<£ = [{αι,...,αη}]<£ curred. To express the eventuality of detection we
[~]φ d={ [Αα]φ use the formula: even(det).
[-1]φ ά= [Act-L]4> Now we can formalise "after fail occurs then eventu-
ally a det action occurs":
The booleans are defined as abbreviations: tt =
uZ.Z, ff = -«tt. An example using these abbrevi- failures-detected = [—fail\*\faií\even(det)
ations is (a, 6)tt, which holds of processes that can
perform either an a or a & action. As another exam- A potential pitfall is that failures-detected is vacu-
ously true if a failure never occurs. So, for example, used to simulate the behaviour of the system.
a deadlocked process satisfies the formula. The for-
mula is also vacuously true of processes in which tick Our notation for describing the behaviour of pro-
actions do not continue to occur. So the process that cesses is CCS (Milner, 1989). We will give only a
performs action fail, then tick, and then deadlocks brief and informal overview of CCS here.
also satisfies the formula. To ensure that the slow-
Processes are described in CCS by terms for which
scan model does not satisfy failures-detected in one
the only possible behaviour is to perform actions,
of these ways, we can write two more formulas:
which are either names (a,b,c,...), co-names (a, b,
failures-possible = (—)*(/ai7)tt c,...), or the special action r. The reason for hav-
ing both names and co-names is that, as we will see,
can-tickd= [-]*(-)* (tic~k)tt
processes composed in parallel can synchronise if one
of them can perform action a and the other* can per-
The formula failures-possible says that there is some
form action a.
execution path containing the action fail. The for-
mula can-tick says that, from every state, there is
Process terms have the following syntax, where L
some execution path containing the action tick. Note
ranges over sets of actions and / ranges over func-
that can-tick is stronger than the property we need:
tions from actions to actions:
"tick can occur infinitely often after a fail action".
P ::= 0 | a.P | P + P \ P \ P \ P\L | P[f]
1 2 1 2
To complete the formalization of the first property,
we need to also express the second part: "after detec- The term 0 denotes the nil process, which can per-
tion eventually no responses are made to the TFM's form no actions. The operator . expresses sequential
or SSI". Using the auxiliary formula silent, the prop- action. The process a.P can perform the action a
erty can be expressed as follows: and thereby become process P. The operator + ex-
presses choice. If Pi can perform a and become P[,
silent = [—]* [comm-out, status-out]±±
then so can P\ + P , and similarly for P . The oper-
2 2
eventually-silent = [—]*[det]even(silent) ator | expresses parallel execution. If process Pi can
perform a and become P[, then Pi | P can perform
2
The property silent expresses that no occurrence of a and become P[ \ P , and similarly for P . Fur-
2 2
actions comm-out or status-out is ever possible. The thermore, if Pi can perform a and become P[, and
first property of interest is thus fully captured by P can perform a and become P , then Pi | P can
2 2 2
the conjunction of failures- detected, eventually-silent, perform r and become P[ \ P . The operator \ ex-
2
failures-possible, and can-tick. presses the restriction of actions. If P can perform
a and become P1, then P\L can only perform a to
The second property, "a failure is detected only if
become P'\L if a £ L. Finally, P[f] expresses the re-
a failure has actually occurred", is much simpler to
labelling of actions, if P can perform a and become
express:
P', then P[f] can perform f(a) and become P'[/]. A
relabelling function / has the property that f(r) = r,
no-false-alarms — [— fail\* [det]±±
and /(a) = /(a).
While carrying out requirements analysis of a safety-
The idea of repetition is captured by allowing recur-
critical system one must also develop a service re-
sive process definitions of the form P = E, where P
quirement which characterises the minimum level of
service required from the system. In validating that is a process constant and E is a process term possi-
the safety properties are consistent one must only bly containing P. For example, the process defined
consider processes which satisfy this service require- by P = a.P -f b.O has the possibility of performing
ment. For example, in the process control area a either a or b, and continues to have this possibility
shutdown interlocking which always shuts the sys- as long as action a is performed. Once action b is
tem down is certainly safe but is unacceptable. For performed, the process terminates.
lack of space we omit the development of the service
requirement for slow-scan which would amount to re- The set of actions that can be eventually performed
quiring that commands and status information are by a process is called its sort. For example, the sort
transmitted in the absence of failures. (The model of ofP=f a.P + 6.0 is {a, b}.
slow-scan to be developed has this property.)
We are now ready to develop a CCS model of slow-
scan. The model will have process components that
A MODEL OF SLOW-SCAN model the behaviour of the LGL, SPC, TPC, and a
clock. Figure 3 shows a flow diagram of the model.
Having formulated our safety requirements we must
now verify that the requirements are consistent. To The low-grade link is modelled as a pair of simple
do this we build a simple model of slow-scan and unidirectional links that operate independently:
check that all the required properties are satisfied.
Furthermore, to give confidence in the feasibility of LGL = Comm[c2/in,c3/out,c3/out]\
u u
implementation, we build a model with a component Comm[s2/in, s3/ out, s3/out]
u u
structure that reflects the hardware components of
slow-scan. The model is also useful in validating the Comm = in.Comm' -f outu.Comm-\-
requirements because we have a model which can be fail.Comm
4
which the SPC could exit failure mode.
[Clock]
mes /^—-^\ met
The TPC model is similar in form. Here commands
are received over the LGL and sent to the TFM, while
comm-out
status information is received from the TFM and sent
over the LGL:
sîatus-in def
TPC(i) = comm-out.status-in.TPC(i)
ψ fail ψ det
+s2.TPC{i)
+mct.72.(if i > n thenlftTPCF
Fig. 3: Flow diagram for the slow-scan model
else TPC(i+I))
+c3.TPC{0) + c3 .TPC(i)
u
Comm = in.fail.Comm + out.Comm + TPC F ά= status-in.TPCF + c3.TPCF
friWomm"
+c3 .TPCF + mct.TPCF
u
Comm" W in.Comm"+ oTt .Comm"
u
Note that both protocol converters stop sending mes-
A link can receive and buffer a message. The output sages after a failure is detected. This causes detec-
actions out and outu, model the delivery of a message tion of an LGL failure in one protocol converter to be
and the signalling that no message is available, re- eventually detected by the other protocol converter.
spectively. Note that messages are modelled simply
as content-less "pulses". A link can fail if its buffering The clock process sends a message to each protocol
capacity is exceeded, or if its communication medium converter after each clock tick:
is broken. After a failure occurs, a link can continue
to accept messages, but will never deliver messages.
Clock = tick.mcs.mct.C lock
To satisfy the safety requirements, the protocol con-
verters must detect LGL failures. The method used The clock process embodies the assumption that the
in the model is to have each protocol converter send protocol converters proceed roughly in synchrony.
a message periodically over the LGL, at the same Rather than constructing such a process we could
time maintaining a count of messages sent since an have developed our properties using the clock ticks
LGL message has been received. If the count ever at the sender and receiver ends of the medium and
exceeds a limit, then an LGL failure must have oc- required synchrony between the two ticks. The exis-
curred. This strategy works because the LGL never tence of the clock process is also justified by the need
outputs messages after a failure. for a physical clock in an implementation so that the
TPC can send TFM messages every major cycle.
The CCS model of the SPC is as follows:
The complete model of the slow-scan with LGL fail-
SPC(i) = comm-in.status-out.SPC(i)
ure detection:
+c~2.SPC(i)
SS d= (SPC(0) | LGL | TPC(O) | Clock)\
+mcs.'c2.(if i > nthenlel.SPCF
{c2, c3, c3 ,s2j s3, s3 ,rncs, met}
elseSPC(i+l)) u u
+s3.SPC(0) + s3 .SPC(i)
u
CHECKING SAFETY PROPERTIES
SPC F d= comm-in.SPCF + &3.SPCF
+s3 .SPCF + mcs.SPCF Now that we have constructed a simple model of slow-
u
scan motivated by its safety and service properties
Two new notational features have been introduced we can begin to check the formalised requirements
here: parametrised actions and conditional state- for consistency. Since the slow-scan model has a fi-
ments. The process term SPC(i) can be regarded nite and reasonably small state space (of 3842 states),
as shorthand for the indexed process constant SPCi. the Concurrency Workbench (Cleavelandet al., 1989)
A term of the form if b then Ρχ else P 2 behaves can be used to check whether the properties formu-
as process P\ if the boolean expression b evaluates to lated in Section hold of the model.
true, or as the process Pi if b evaluates to false.
The complexity of some of the properties means that
The SPC accepts commands from the SSI, responds they cannot practically be checked directly with the
to the SSI with TFM status information, and some- Workbench. For each such property, checking was
times sends a command over the LGL. Also, the SPC made of a smaller model derived from the slow-scan
receives TFM status information over the LGL. In model by hiding actions not relevant to the property.
this new model, the SPC is guaranteed to send a mes- Then, by using a technique (Bruns, 1991) that cannot
sage over the LGL at least once after each message be described here because of space, the property was
from the clock (action mes). Also, if n mes actions shown by hand to hold of the full model if and only
occur without the receipt of a message from the TPC, if it held of the smaller model. In what follows, we
then the SPC enters failure mode, in which it never will write that a property was checked indirectly if
again sends messages to the SSI or LGL. Of course, a this technique was used, and checked directly if the
more detailed model would contain a mechanism by Workbench alone was sufficient.
5
Recall that the first property of interest involved CONCLUSIONS
detection of LGL failures. The property failures-
detected was checked indirectly and shown to hold. We hope that this paper illustrates how the formal-
The properties failures-possible and can-tick were also isation of properties and models of systems can be
shown to hold, the first directly and the second indi- used to provide support for requirements analysis.
rectly. In the course of constructing requirements it is hard
to formulate a small collection of important proper-
The property eventually-silent, which holds if slow- ties. We believe that the approach outlined here in
scan eventually stops performing output actions after which properties and models are developed hand-in-
a failure is detected, could not practically be checked hand provides a promising means of developing re-
even indirectly. The property is expensive to check quirements. An important factor in this is the avail-
because after any det action a complicated eventual- ability of automated tools for checking properties of
ity property must be shown to hold. systems. In this case-study we used the Concurrency
Workbench and even our simple models required a
The second property, no-false-alarms, expresses that fairly large number of states. Work is in progress
failures cannot be detected before they occur. This which should facilitate the verification of several dif-
property could be checked directly, but was found ficult slow-scan properties; we hope to extend the
not to hold. It fails to hold because the action fail scope and effectiveness of this technique.
occurs after a failure, not simultaneously with it. A
failure can be detected, and the corresponding action Acknowledgements
det can occur, between the moment of failure and the
moment action fail occurs. We would like to thank Colin Stirling for discus-
sions and comments, and Ian Mitchell, Chris Gur-
Knowing that no-false-alarms fails to hold, other ney, and others at British Rail Research, Derby,
questions become interesting, such as "can both pro- for their help. This work was supported by SERC
tocol converters signal detection of failure before fail grant "Mathematically-Proven Safety Systems", IED
occurs?", and "if a failure is detected before fail SE/1224.
occurs, must fail eventually occur?". The formula
detects-before-failure expresses the property that two
REFERENCES
det actions can occur before a fail action:
Atkinson, W. and Cunningham, J. (1991). Proving
detects-bef ore-failure = {—fait)* {det) (—fait)* (det)tt properties of a safety-critical system. Software
Engineering Journal.
This property was checking indirectly and shown not Bruns, G. (1991). Verifying properties of large sys-
to hold. However, it was shown that two fail actions tems by abstraction. To be submitted for pub-
can occur before any det actions occur. lication.
Bruns, G. and Anderson, S. (1991). The formaliza-
The two following formulas express the idea that det
tion and analysis of a communications protocol.
and fail are related by property "if a fail occurs be-
In Lindeberg, J., editor, Proceedings of SAFE-
fore a det, then eventually a det will occur, and con- COMP '91.
versely" :
Cleaveland, R., Parrow, J., and Steffen, B. (1989).
even-detect = [— fail, det]*\fait\even(det) The concurrency workbench: A semantics based
tool for the verification of concurrent systems.
even-fail = [—fail, det]*[det]even(fait)
Technical Report ECS-LFCS-89-83, Laboratory
for Foundations of Computer Science, Univer-
Note that the property failures-detected is slightly
sity of Edinburgh.
stronger than even-detect; the former property re-
quires that det occurs after fail even if det occurred Cribbens, A. (1987). Solid-state interlocking (SSI):
before fail. These properties were checked indirectly an integrated electronic signalling system for
and shown to hold. mainline railways. IEE Proceedings, 134(3).
Kozen, D. (1983). Results on the propositional mu-
In summary, we have verified that LGL failures are
calculus. Theoretical Computer Science, 27:333-
detected in our slow-scan model. To ensure that this
354.
property is meaningful we have also shown that in
all states the clock can continue to tick, and that Milner, R. (1989). Communication and Concurrency.
it is possible for such failures can occur. However, Prentice Hall International.
we have not verified that slow-scan will eventually Stirling, C. (1989). An introduction to modal and
stop performing output actions after an LGL failure temporal logics for CCS. In Yonezawa, A. and
is detected by either protocol converter. The fail- Ito, T., editors, Concurrency: Theory, Lan-
ure of no-false-alarms requires either a revision of guage, and Architecture. Springer Verlag. Lec-
the model or the requirement. In a large project ture Notes in Computer Science, volume 391.
the modelling and requirements process would pro-
Taleb, F. and Gurney, C. (1990). Requirements anal-
ceed hand-in-hand and we could expect to see such
ysis final report slow scan SSI project. Technical
decisions resolved by considering which matched the
Report ELS-DOC-4826, British Rail Research.
real-world situation most accurately.
6