Safety, security and reliability related computers for the 1990s : Symposium : Selected papers

174 Pages·1990·6.95 MB·English

IFAC SYMPOSIA SERIES

Editor-in-Chief
JANOS GERTLER, Department of Electrical Engineering,
George Mason University, Fairfax, Virginia 22030, USA

JOHNSON et al.: Adaptive Systems in Control and Signal Processing
(1990, No. 1)
ISIDOR!: Nonlinear Control Systems Design (1990, No. 2)
AMOUROUX & EL JAI: Control of Distributed Parameter Systems
(1990, No. 3)
CHRISTODOULAKIS: Dynamic Modelling and Control of National Economies (1990,
HUSSON: Advanced Information Processing in Automatic Control
(1990, No. 5)
NISHIMURA: Automatic Control in Aerospace (1990, No. 6)

No. 4)

RIJNSDORP et al.: Dynamics and Control of Chemical Reactors, Distillation Columns and Batch Processes
(DYCORD '89) (1990, No. 7)
UHI AHN: Power Systems and Power Plant Control (1990, No. 8)
REINISCH & THOMA: Large Scale Systems: Theory and Applications (1990, No. 9)
KOPPEL: Automation in Mining, Mineral and Metal Processing (1990, No. 10)
BAOSHENG HU: Analysis, Design and Evaluation of Man-Machine Systems (1990, No. 11)
PERRIN: Control, Computers, Communications in Transportation (1990, No. 12)
PUENTE & NEMES: Information Control Problems in Manufacturing Technology (1990, No. 13)
NISHIKAWA & KAY A: Energy Systems, Management and Economics (J 990, No. 14)
DE CARLI: Low Cost Automation: Components, Instruments, Techniques and Applications
(1990, No. 15)
KOPACEK & CENSER: Skill Based Automated Production (1990, No. 16)
DANIELS: Safety of Computer Control Systems 1990 (SAFECOMP'90) (1990, No. 17)

COBELLI & MARIANI: Modelling and Control in Biomedical Systems
(1989, No. 1)
MACLEOD & HEHER: Software for Computer Control (SOCOCO '88)
(1989, No. 2)
RANTA: Analysis, Design and Evaluation of Man-Machine Systems (1989, No. 3)
MLADENOV: Distributed Intelligence Systems: Methods and Applications (1989, No. 4)
LINKENS & ATHERTON: Trends in Control and Measurement Education (1989, No. 5)
KUMMEL: Adaptive Control of Chemical Processes (1989, No. 6)
CHEN ZHEN-YU: Computer Aided Design in Control Systems (1989, No. 7)
CHEN HAN-FU: Identification and System Parameter Estimation (1989, No. 8)
CALVAER: Power Systems, Modelling and Control Applications (J 989, No. 9)
REMBOLD: Robot Control (SYROCO '88) (1989, No. 10)
JELLALI: Systems Analysis Applied to Management of Water Resources (1989, No. 11)

Other IFAC Publications

AUTOMATICA
the journal of IFAC, the International Federation of Automatic Control

Editor-in-Chief: G. S. Axelby, 211 Coronet Drive, North Linthicum,
Maryland 21090, USA

IFAC WORKSHOP SERIES

Editor-in-Chief: Pieter Eykhoff, University of Technology, NL-5600 MB Eindhoven,

The Netherlands

Full list of IFAC Publications appears at the end of this volume

NOTICE TO READERS

If your library is not already a standing/continuation order customer or subscriber to this series, may we recommend that you place a standing/
continuation or subscription order to receive immediately upon publication all new volumes. Should you find that these volumes no longer serve your
needs your order can be cancelled at any time without notice.

Copies of all previously published volumes are available. A fully descriptive catalogue will be gladly sent on request.

ROBERT MAXWELL
Publisher
SAFETY OF COMPUTER
CONTROL SYSTEMS 1990
(SAFECOMP'90)

Safety, Security and Reliability Related Computers
for the 1990s

Proceedings of the IFACIEWICSISARS Symposium

Gatwick, UK, 30 October-2 November 1990

Edited by

B. K. DANIELS

National Computing Centre Ltd,

Manchester, UK

Published for the

INTERNATIONAL FEDERATION OF AUTOMATIC CONTROL

by

PERGAMON PRESS

Member of Maxwell Macmillan Pergamon Publishing Corporation

OXFORD · NEW YORK · BEIJING · FRANKFURT
SAO PAULO · SYDNEY · TOKYO · TORONTO
U.K. Pergamon Press pie, Headington Hill Hall, Oxford OX3 OBW, England
U.S.A. Pergamon Press, Inc., Maxwell House, Fairview Park, Elmsford, New York 10523, U.S.A.
PEOPLE'S REPUBLIC
OF CHINA Pergamon Press, Room 4037, Qianmen Hotel, Beijing, People's Republic of China
FEDERAL REPUBLIC
OF GERMANY Pergamon Press GmbH, Hammerweg 6, D-6242 Kronberg, Federal Republic of Germany
BRAZIL Pergamon Editora Ltda, Rua E�a de Queiros, 346, CEP 04011, Paraiso, Sao Paulo, Brazil
AUSTRALIA Pergamon Press Australia Pty Ltd., P.O. Box 544, Potts Point, N.S.W. 2011, Australia
JAPAN Pergamon Press, 5th Floor, Matsuoka Central Building, 1-7-1 Nishishinjuku, Shinjuku-ku,
Tokyo 160, Japan
CANADA Pergamon Press Canada Ltd., Suite No. 271, 253 College Street, Toronto, Ontario, Canada M5T 1R5

This compilation copyright© 1990 IFAC

All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in

any form or IYy any means: electronic, electrostatic, magnetic tape, mechanical, photocopying, recording or otherwise, without permission in writing from the copyright holders.

First edition 1990

Library of Congress Cataloging in Publication Data

IFAC/EWICS/SARS Symposium on Safety of Computer Control Systems
(1990: Gatwick, England)
Safety of computer control systems, 1990 (SAFECOMP '90): safety,
security, and reliability related computers for the 1990s:
proceedings of the IFAC/EWICS/SARS Symposium, Gatwick, UK,
30 October-2 November, 1990/edited by B. K. Daniels.- lst ed.
p. cm.-(IFAC symposia series: 1990, no. 17)
Includes indexes.
I. Automatic control-Data processing-Reliability-Congresses.
2. Computer security-Congresses.
3. Computers-ReliabilityCongresses. I. Daniels, B. K. II. International Federation of
Automatic Control. III. European Workshop on Industrial Computer
Systems. IV. Safety and Reliability Society (Great Britain)
V. Title.
90-7988
629.8'9--dc20
TJ212.2.I327 1990

VI. Series.

British Library Cataloguing in Publication Data

Safety of computer control systems 1990 (SAFECOMP '90).
I. Process control. Applications of computer systems
I. Title
II. Daniels, B. K. III. International Federation of Automatic
670.437
IV. Series
Control

ISBN 0-08-040953-9

These proceedings were reproduced IYy means of the photo-offset process using the manuscripts supplied IYy 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 IYy BPCC Wheaton Ltd, Exeter
IFAC/EWICS/SARS SYMPOSIUM ON SAFETY OF

COMPUTER CONTROL SYSTEMS (SAFECOMP'90)

Safety, Security and Reliability Related Computers

for the 1990s

Sponsored by

International Federation of Automatic Control (IFAC)

European Workshop on Industrial Computer Systems Technical

Committee on Safety, Security and Reliability (EWICS TC7)

The Safety and Reliability Society (SARS)

Co-sponsored by

The International Federation for Information Processing (IFIP)

The Institute of Electrical Engineers (IEE)

The Institute of Measurement and Control (Inst MC)

The British Computer Society

The National Computing Centre Ltd (NCC)

The Centre for Software Reliability (CSR)

Safety Net

Organized by

The Safety and Reliability Society (SARS)

International Programme Committee

B. K. Daniels, UK (Chairman)

L. A. Jones, UK (Secretary)

R. Isermann, FRG

H. de Kroes, The Netherlands

R. Bell, UK R. Lauber, FRG
R. Bloomfield, UK J. F. Lindeberg, Norway
S. Bologna, Italy J. McDennid, UK
L. Boullart, Belgium J. M. A. Rata, France
G. Dahll, Norway M. Rodd, UK
W. Ehrenberger, FRG K. Sankaran, Australia
H. Frey, Switzerland B. Sterner, Sweden
R. Genser, Austria B. Tamm, USSR
J. Gorski, Poland M. Thomas, UK
S. L. Hansen, Denmark A. Toola, Finland

National Organizing Committee

J. Catchpole (Chairman)

B. K. Daniels

J. Jones

L. A. Jones

N. Locke
PREFACE

In an expanding worldwide market for safe,
secure and reliable computer systems
SAFECOMP'90 provides an opportunity for
technical experts, operators and legislators to
review the experience of the past decade, to
consider the guidance now available, and to
identify the skills and technologies required for
the l 990's and into the next century.

In the decade since the first SAFECOMP in 1979,
the SAFECOMP's held in Germany, France, the
UK, USA, Italy and Austria have reflected upon
and influenced the significant changes in the
technology and scale of use of computer systems
in applications which are safety security and
reliability related. There is increasing acceptance
that computers can be used in life critical
applications, provided appropriate technology is
used and current guidelines are carefully followed
by people with the right training and experience.

It has recently been estimated that the market for
software in safety critical systems is currently of
the order of £500 Million and is growing at an
annual rate of approximately 20%. Interest in the
UK is very high. I am very grateful to the IPC
for supporting the decision to host this years
SAFECOMP in the UK.

Much valuable work has been done by the UK
Health and Safety Executive on industrial
applications of computers and within UK
Government civil and military research
programmes on formal methods for specification
and 'for static analysis. A new UK technology
transfer and research and development initiative in
safety critical systems, SafelT, has been
announced in 1990, and is featured in a panel
session1 in SAFECOMP� The views of the lawyer,
the insurer and the consumer are also relevant and
these too are featured in a panel session1•

In the first keynote paper1, Martyn Thomas looks
back to the emergence of interest in safety critical

systems and how the technology and marketplace
has changed since 1979.

Jn thirty one contributed papers1, we access

experience of specifying, creating, operating; and
licensing computers in safety, security and
reliability related applications. Authors review the
available guidelines, and provide feedback from
their use by industry. Methods and tools for
specifying, designing, documenting, analyzing,
testing and assessing systems dependent on
computers for safety, security and reliability are
described.

The final keynote paper by �ohn McDermid
addresses the importance of skills and
technologies required for the development and
evaluation of safety critical systems in the 1990's
and into the next century. in the expanding
worldwide market for safety related computers.

As Chaim1an of the. International Programme
Committee (IPC) I would like to thank all
members of the Committee for their advice and
assistance in constructing the Programme. The
Programme Committee included many members of
the European Workshop on Industrial Computer
Systems Technical Committee 7 (Safety Security
and Reliability), who have provided the core of
each SAFECOMP IPC since 1979, on this
occasion the Committee was grateful for the
assistance of a number of additional members
who are key workers in this field.

My thanks must also go to the session Chaim1en,
the authors and co-authors of the papers, and the
members of the National Organising Committee.

Barry Daniels,
National Computing Centre Ltd.,
Oxford Road,
Manchester,
Ml 7ED,
UK

I. Copies of the keynote paper by Martyn Thomas, summaries of the panel sessions, and of the following list of papers not
included inthe proceedings are available from the Safety and Reliability Society, Clayton House, Manchester, Ml 2AQ., UK.

An Outline of the EDI Security Model Application Model, S.Schindler, D Buchta, TELES GmbH, Berlin, FRO.

Developing and Assessfng complex safety and secure systems, I.Elliott, P-E International systems Group, UK.

Static code analysis of (MIL-STD-1750A) Assembly Language. T.Jennings, P.Keenan, SD Scicon pie, UK.

vii
Copyright © IFAC SAFECOMP'90,
London. UK. 1990

M ATHEMATICAL FORMALISMS

A FORMAL MODEL FOR SAFETY-CRITICAL
COMPUTING SYSTEMS

A. Saeed, T. Anderson and M. Koutny

Computing Labomt01y, The Univenity, Nnocastle upon Tyne

NEJ 7RU, UK

Abstract. The paper treats a safety-critical computing system as a component of a larger system which could
cause or allow the overall system to enter into a hazardous state. It is argued that to gain a complete understanding
of such systems, the requirements of the overall system and the properties of the environment must be analysed
in a common formal framework. A system development model based on the separation of safety and mission
issues is discussed. A formal model for the representation of the specifications produced during the analysis is
presented. The semantics of the formal model are based on the notion of a system history. To overcome some
of the problems associated with an unstructured specification the concept of a mode is introduced. To illustrate
the strategy a simple example is presented.

Keywords. Process control; Safety; Computer control; Requirements analysis and Formal Methods.

1. INTRODUCTION

The general class of systems considered in this paper are process
control systems (Smith, 1972); typical application areas include
chemical plants and avionic systems. Though each application
area has its unique problems, process control systems have
significant properties in common. In particular, there is a general
relationship between the main components of a process control
system (see Fig. 1.1).

Operator

Controller

Physical Process or Plant

Fig. 1.1 Process control system components

The controller, of a process control system, is constructed to
control the behaviour of the physical process. The controller
consists of four components: operator console, control system,
sensors and actuators. A precise definition of the computing
systems considered, in this paper, is given in the context of
process control systems.

A safety-critical computing system is a system that is a component
of a process control system which could cause or allow the overall
system to enter into a hazardous state.

A hazardous state is a state which under certain environmental
conditions could lead to a disaster. The term disaster is usually
reserved for calamitous situations such as loss of life, limb,
significant revenue or substantial damage to the environment.
In this paper we concentrate on the requirements analysis of
safety-critical computing systems. Requirements analysis plays
a vital role in the development of systems, since any errors in the
identified requirements will corrupt the subsequent stages of
system development. Experience has shown that errors in the
formulation of requirements are one of the major causes of
mishaps (Leveson, 1986). Current methods for requirements
elicitation are based on a combination of system safety and
software development techniques. A common approach is the use
of HAZOPS (Hazard and Operability Studies) and FfA (Fault

'free Analysis) to identify hazards from which the software safety
requirements are produced (Leveson, 1989). General guidelines
for the integration of system safety and software development
techniques are available (HSE, 1987). The main drawback to
current methods is that no unified formal framework for
requirements analysis is available.

1.1. Formal Framework

To gain a complete understanding of a safety-critical computing
system, the requirements of the overall system and the properties
of the environment should be analysed in a common formal
framework. The benefits of using formal methods during
requirements analysis include unambiguity, checks for
completeness and consistency, formal verification, and the
potential for using automated aids (Jaffe, 1989; Roan, 1986). A
unified framework is needed for the analysis because safety is a
global issue that can only be addressed by analysing the
consequences of system behaviour in the context of the
environment (Gorski, 1986; Leveson, 1986). The benefits gained
from the adoption of a common framework include: i) improved
and precise communication between the members of the analysis
team; ii) the ability to perform a rigorous assessment of the effect
of the inherent properties of the environment on system
behaviour; and iii) the ability to assess the impact of the system
on the environment.
The essential attributes that an appropriate formal model must
possess are that it must be able to express physical laws,
parallelism and timing issues in a coherent (structured) form. The
necessity for the model to be able to express physical laws stems
from the fact that the behaviour of the environment is governed
by such laws. The necessity to treat parallelism explicitly in
specifications which include the environment has been argued by
many researchers (Gorski, 1988). Timing issues will arise in all of
the stages of requirements analysis. Timing issues are present in
the description of the environment, since physical laws make an
explicit reference to time, and in many cases the relationships
between the sensors, actuators and the physical process are
dependent on time. (The importance of timing issues makes
process control systems a subclass of real-time systems.) A
structured model is necessary to handle the complexity of these
systems. The structure should be present in the techniques used
to compose the basic constructs of the model and in the basic
constructs themselves.
2

A. Saeed, T. Anderson and

The remainder of the paper is set out in four sections. In section
2 a development model for requirements analysis is discussed. In
section 3 the basic concepts of a specification model are
introduced. In section 4 a simple example (reaction vessel) that
illustrates the role of the specification model during analysis is
presented. Finally, section 5 concludes the paper by discussing
how the work presented in the paper relates to an overall
approach to requirements analysis.

2. DEV ELOPMENT MODEL

Our approach to requirements analysis is concerned with system
behaviour at two distinct levels of abstraction: real world and
controller. At the real world level we are concerned with the
behaviour exhibited by the physical process. At the controller
level. we are concerned with the behaviour exhibited by the
sensors and actuators and at the operator console.
For safety-critical systems it has been suggested that for a clear
analysis of the safety-related properties, a distinction must be
made between the safety-critical and mission-oriented
behaviour of a system (Leveson, 1984; Mulazzanni, 1986). In our
approach, the distinction between the safety and mission issues
is established during the requirements analysis. This distinction
allows us to partition the analysis (see Fig. 2.1).

System
Conception

M. Koutny

assumptions of the system. The third stage involves the
construction of a safety constraint which specifies the behaviour
that if exhibited by the system will ensure that no identified
disaster can occur - under the safety assumptions of the system.
At the controller level, the safety analysis is performed in two
stages. In the first stage the relationship between the sensors and
actuators of the safety controller and the physical process must be
specified in the formal framework. This specification together
with SD is referred to as the safety environment description (SED).
In the second stage, the behaviour that must be exhibited by the
sensors and actuators and at the operator console to ensure that
the behaviour complies with the safety constraint, under the
safety assumptions is specified - as the safety controller
specification (SCS). The elicitation of the specification is
performed by an analysis of the SED and safety constraint. Tu
guide the analysis general structures for the behaviour of the
safety controller have been proposed in terms of phases. The
phases for the reaction vessel are illustrated below (see Fig. 2.3).

Shutdown

Start up

Monitor

Mission Analysis

Fig. 2.3. Safety controller structure

Mission Real world
Analysis

Mission Controller
Analysis

Fig. 2.1. Requirements analysis phases

The decision to make a distinction between the safety and
mission issues is reflected in our general structure for
safety-critical systems (see Fig. 2.2).

Mission Subsystem

Safety Subsystem

Mission Operator.._____.

'- �--' '-- .....�--'

2.2. Mission Analysis

At the real world level, the mission analysis is performed in two
stages. In the first stage the behaviour of the environment that
impinges on system behaviour is specified. The specification will
be an extension of SD. It will express the real world level
assumptions for the mission of the system. The second stage
involves the construction of a formal mission specification of the
system. At the controller level a two stage analysis is performed
over the mission controller which is similar to the analysis
performed on the safety controller.

2.3. Example System

The concepts described in this paper are illustrated by outlining
the safety analysis of a simple chemical plant (the reaction vessel).
"The reaction vessel reacts a specified volume of chemical A with
a specified volume of chemical B, producing a chemical C. For
the reaction between A and B to take place the temperature of
the vessel must be raised above a specified activation value."

3. SPECIFICATION MODEL

Mission Controller t--"----...J

Physical Process or Plant

Fig. 2.2. Safety-critical system structure

2.1 Safety Analysis

At the real world level, the safety analysis is performed in three
stages. In the first stage the potential disasters associated with the
mission of the system or the environment are identified. The
second stage involves the identification of the hazards that can
lead to potential disasters and their representation in the formal
framework. It also involves the specification of the behaviour of
the environment that impinges on the safety-critical behaviour
of the system; this specification will be referred to as the safety
real world description (SD). The safety real world description and
the assumption that the hazards specify all the conditions under
which a disaster can occur, comprise the safety (real world)

The behaviour of a process control system is not characterized
by a single task, rather as a set of tasks which must be performed
in a specific order. In the specification model, each task is defined
as a mode which specifies the behaviour of the system at the start
of the task, during the task and the behaviour which must be
exhibited by the system for the task to be completed. A graphical
notation, called a mode graph, is used to specify the transitions
between the modes of a system. The key feature of a mode is the
application of system predicates to describe the behaviour of a
task. The behaviour specified by modes is defined over a set of
system behaviours, that obeys the physical laws of the
environment and the construction limitations of the plant. This
set of system behaviours is defined by a history description. To
define modes and history descriptions, the notion of time and
system state must be formalized.

3.1. Time

The base time set BT of the specification model will be the set of
non-negative real numbers. A time point is an element of BT,
A Formal Model for Safety-critical Computing Systems

denoted by t, and if more than one time point is required in an
expression the time points will be subscripted as: to. ti, ... .
Time intervals will be considered as closed finite intervals
included in BT, these intervals will be denoted by Int.
For any interval, two boundary points can be defined: the start
and end points. The start point is the first time point of the
interval and the end point is the last time point of the interval (i.e.,
to e Int is the starl point of lnt iff 'tl1 e Int: t1�to). The start point
of an interval Int will be denoted by s(Int), and the end point by
e(Int). For an interval Int we can define its duration as e(Int) -
s(Int), denoted by dur(lnt). The set of all intervals which are
included in an interval Int, will be denoted by SI(Int). The system
lifetime is the interval of BT denoted by T, where s(T) is the time
when the system starts operation and e(T) is the time when the
system is finally closed down.

3.2. System State

The state of the system will be given by the values of its state
variables. These are (time varying) quantities which either have
a significant effect on, or measure factors which affect, the
mission or safety of a system.
The vector of all the state variables for a system will be referred
to as the state vector. A state vector with n state variables is
denoted by: Sv= (pi, ..., P n). Pi;ofPi· for i;ofj, where Pi represents
a state variable and i, j e {1, ... , n}.
The set of possible values for a state variable are determined by
physical laws or construction limitations. This set will be referred
to as the variable range, and for variable Pi will be denoted by Vpi.
The state space of a system is denoted asr. and is given by the
cross product of the variable range set. That is, for a system with
n state variables, the state spacer is given by: r= Vp1 x Vp2
x ... x Vpn.
The state variables of the reaction vessel example, over which the
safety real world (resp. controller) analysis is performed, are
described in Tuble 1 (resp Table 2). (The contents of the Class
column will be explained later.) The safety subsystem of the
reaction vessel is illustrated by a schematic diagram (see Fig. 3.1).

TABLE 1 Reaction Vessel Real World Variables

No Units Name Range Class
Pt s Clock T Clock
P2 •K Temperature {xERI T,�g.} Continuous

p

3

dm3/s

Flow A

{xERI O�SFA}

Continuous

P• dm3/s FlowB {xERI O�SFB} Continuous
p, dm3/s Flow {xERI OSx:s;Fm} Continuous
P• dm3 Volume {xERI o�:s;Vm} Continuous
p , dm3/s OutflowD {xERI o�:s;Om} Continuous
P• Ex_Rat Explosion {false, true} Free

TABLE 2 Reaction Vessel Safety Controller Variables

No Units Name Range Class
"" Sa_Set Safetydial {on, off} Free
Pio E_State EmptySensor {empty, some} Free
P11 Lock_Set LockA {on, off} Free
P12 Lock_Set LockB {on, off} Free
p 1
3
p,. mm ValveD {xERI O�SDm} Continuous

•K

Thermometer

3.3. System History

{q,, ... , q,}

Free

Given the lifetime and state space of a system a model of the
behaviour of the system can be constructed as a history. A history

3

Safety operator
a

Safety controller

b c d

e

f

Liquid

Key

a: Safetydial
d: LockA

c: LockB
b: ValveD
e: Thermometer f: Empty Sensor

Fig. 3.1. Reaction vessel safety subsystem

is a mapping from each time point in the system lifetime to a
system state. Process control systems are unpredictable, in the
sense that the history is not known in advance. Therefore when
reasoning about such systems all "possible" histories must be
considered. These form the universal history set of a system.
For every possible history H of the system, the sequence of values
taken by a particular state variable Pi can be represented as a
function H.pi: T-+ Vpi. A history itself can be represented as the
mapping H: T-+r, s.t. H(t) = (H.p1(t), ... , H.pn(t)). The universal
history set of a system is denoted as rH and is the set of all
functions H: T-+r.

3.4. History Descriptions

The restrictions imposed on the universal history set by the
environment are due to the laws of physics and construction of
the plant. To specify these restrictions, three formal relations are
provided: i) class relations, ii) invariant relations, and iii) history
relations. The formal semantics of the relations will be so formed
that for every relation we are able to say whether a particular
function H: T-+r satisfies it or not. The relations will be used in
the construction of a history description.
A history description (Desc) is a six-tuple Desc = (f, Sv, VP, CP,
IR, HR), where T is the system lifetime; Sv is the state vector; VP

is the sequence of variable ranges; CP is the sequence of class

relations, (Cp1• ... , Cp11); IR is the sequence of invariant relations,
(lr1, . . . , lrm); and finally HR is the sequence of history relations,
(Hr1, . . . , H'k).

3.4.1. Class Relations

Class relations are used to impose constraints over the functions
which represent the behaviour of a variable. Several useful classes
have been defined (Saeed, 1990), such as non-decreasing,
continuous, free and perfect clock.

A class relation for a variable p; (denoted by Cp;) is a predicate built
using relations and logical connectives, and one free function
variable p;. No other free variable may be used.

We will say that a history satisfies a class relation Cpi if and only
if the substitution of H.p; for Pi results in a well-defined
expression which evaluates to true. This satisfaction will be
denoted by H sat Cpi.
As an example, consider the definition below.

A perfect clock variable is a variable for which at any time point
during the system lifetime the value is equal to the time point.

More precisely, Pi is a prefect clock iff Cpi = ('tl eT: Pi= t).
We will say that a history H of a system satisfies the variable class
4

A. Saeed, T. Anderson and M. Koutny

relations of a history description if and only if the function H.pi
satisfies the constraints of class Cpi, iE{l, ... , n}. The satisfaction
is denoted by H sat CP.

3.4.2. Invariant Relations

Invariant relations are used to express relationships over the state
variables which hold for every time point of the system lifetime;
these are formulated as system predicates.

A system predicate (SysPred) is a predicate built using standard

mathematical functions, relations and logical connectives, and n

free value variables pz, ... , Pn of type Vpz, . . . , VPn· No other free

variables may be used.

The semantics of a system predicate will be defined in terms of
the satisfaction condition. A tuple of values V =(xi. ..., Xn)• where
Xi is of type Vpi, satisfies a system predicate if and only if
substitution of each Xi for Pi within the system predicate results
in a well-defined expression which evaluates to true.We denote
this satisfaction by writing: V sat SysPred.

A system predicate SysPred is an invariant relation for a history H

if and only if (H.p1(t), .. . , H.pn(t)) sat SysPred for all tET. This
satisfaction will be denoted by H sat SysPred.

3.4.3. History Relations

History relations are used to express relationships over the state
variables which hold for every interval of the system lifetime,
these are formulated as history predicates.

A history predicate is a predicate built using standard mathematical

functions, relations and logical connectives, two free time variables

To, Ti, 2n free value variables Pl,O· ... , Pn,O· Pz,z,..., Pn,1 (where P i,j
has type Vp;), and n free function variables pJ, ..., Pn (where Pi is a
function of class Cp;). No other free variables may be used.

We will say that a history H satisfies a history predicate HistPred
for an interval Int if and only if the expression resulting from
substituting: i) s(Int) for To. ii) e(Int) for Ti. iii) H.pi(s(Int)) for
pj,o for all i, iv) H.pi(e(Int)) for Pi·l for all i, and v) H.pi for Pi for
all i, is a well defined expression which evaluates to true. We will
denote this satisfaction by writing: H sat
A Formal Model for Safety-critical Computing Systems

3.7. Mode Sequences

Modes can be used to specify a set of required behaviours of a

system, in a structured format, by the construction of a mode

sequence.

A mode sequence is a sequence, ModeSeq = (m1, ..., m,), where m;

is a mode, for ie{J, ..., r}.

We will say that a history satisfies a mode sequence if the modes
of the sequence are satisfied by the history in the order indicated

5

Safety real world description

The safety real world description, SD, is constructed by an
analysis of the real world to identify the properties which impinge
on the critical behaviour of the system. Firstly the analysis
identifies the variables which influence the variables in the
hazard, and secondly the relationships over the variables are
identified. For the reaction vessel some of the identified relations
are given in Tuble 3.

by the sequence. More precisely, a history H satisfies a mode

sequence (ml• ..., mr) iff 3to, ..., tr: to ::;;

... ::;; tr /\

to= s(T)

TABLE 3 Reaction Vessel Real World Relations

/\

No

Relationship

tr = e(T) /\ H sat