safety assurence in process control

•Programmable logic
controllers are popular in
process-control
applications, but the
software can be very
complex. Usingformal
specifications to create
function blocks helps make
the safety of
PLC software easier
to verify.
IEEE SOFTWARE
Safety
Assurance in
Process
Control
WOLFGANG A. HALANG and BERND]. KRAMER
FemUniversitiit Hagen
rogrammable electronic 'ys
terns are being used more and more to
control and automate functions in safety
critical applications like traffic control,
patient monitoring, and process and pro
duction-line control.
A specific class of these systems -
programmable logic controllers - are
replacing hard-wired switching networks
in a range of applications, from binary
and sequence control to process supervi
sion and otber tasks involved in industri
al process control.
The advantage of PLCs over purely
,hardware solutions is tbat they can pro
cess more information faster. Vhen tbe
process changes, developers simply re
program a PLC to adapt. Hardware, on
tbe other hand, is based on relay or dis
crete electronic logic, and so must be
rewired to a ccommodate process
changes.However, PLC software can be
very complex, and there are few sound
074G7459/94/0100jOO61 /$0300 © IEEE
and accepted methods for thoroughly
understanding, specifying, designing,
implementing, maintaining, and assess
ing a PLC's critical properties. Errors
cannot be detected solely by peer reviews
or other informal metbods typical of tra
ditional software development. Also, ex
haustive testing is impossible because
PLC software often uses concurrency or
has a huge number of program states.
Consequently, licensing autborities
are still extremely reluctant to certify
safety-critical systems whose behavior is
exclusively program-controlled.
To make it easier to verify tbe safety of
this type of software, we have created a rig
orous process tbat uses formal specifica
tions of function blocks, which are typical
ly used in safety-critical control and
automation applications. Key to tbe pro
cess is tbe use ofObj,an algebraic language
, tbat lets you specify requirements and de
I signs independently of any data represen-
61

Figure 1. Steps oftheflrrnal-d,:ve!vpmentpro'TSS.
tation and implementation.! vVe also used
the Obj3 system,2 which supports the lat
est version of Obj with an interpreter and
and a functional programming environ
ment, to automate parts of s pecification
testing and formal verification.
FORMAL DEVELOPMENT
The process we have created builds on
work done earlier on the development of
PLC software for safety-critical process
control applications in the chemical indus
ny.3 Developers of this kind of software use
a catalog of predefined function blocks in
designing process-control software. Their
task is supported by a gTaphical editor that
lets them invoke function-block instances
from the function-block library, place
them, and interconnect them
Our earlier work was to provide check
ing and compilation functions through
formal semantics of both individual func
tion blocks and complete diagrams. Using
these semantics, we defined a collection of
consistency conditions for interconnect
ing functi�n blocks and structuring them
in a hierarchy.3 (The figure on p. 64shows
a view of the graphical editor.)
Ve focused on the consistency and cor
recrness of rile entire application under the
assumption that if the function blocks are
62
proved correct, the entire systemis correct.
VV1mt we did not do was make the tor
mal-development process explicit. This is
what we are concerned with here.
In rills fonnal-development process, we
crcate individual function blocks and dem
onstrate their adequacy and correcmess.
Ne represent and implement each
function block in a function block diagram
and structured text, both of which are de
fined by the International Elecn'otechni
cal Comnllssion's standard TEl: 1131-3
(previously mc 6SA). In a function-block
diagram, each software module represents
part of thc systcm's overall functionality.
Structured text is a Pascal-like language
thatllses modules and tasks to describe the
structure and to implement the behavior
of function blocks.
The formal-development process
lets developers validate and verity the
correcrness and adequacy of individual
function blocks at different stages of de
velopment. Developers can use this pro
cess together with the function-block
catalog and a technique called diverse
back translation, which is described in the
box on the facing page. This technique,
required hy German licensing authori
ties, helpsincrease confidence in a design.
Developersuseit oncetheyare finishedwith
ourfom1al process.
Process overview. Figure 1 shows the
major process steps;
• F01771alize rcquin!ments. The devel
oper creates a reference point for detect
ing oIIllssions, inconsistencies, or ambigu
ities and tor deriving properties of the
requirements with fOffilal reasoning.
• Specifjdesifll. The developer uses the
formalized requirements to LTeate func
tion blocks. A black-box view of the block
is fonned from specifications of its func
tional properties and safety constraint);.
The developer identifies suitable func
tion blocks in the catalog and intercon
nects them to torm a more complex pro
g=. Using a high-level Petri-net model
of function-block diagrams, which in
cludes algebraic interlace specifications,
the developer can apply existing tech
niques, such as structural induction, term
rewriting, invariant analysis, and net sim
ulation, to deternllne the static and dy
nanllC properties of both concurrent a�d
distributed programs.
• Verifydesign. The developer uses the
specifiL'3tions created in the previous step
to verify that the design conforms with
critical requirements.
• Test design. The developer can also
use the functional and safety specifications
to demonstrate the design's adequacy, in a
sense answering the proverbial question,
"Are we building the right thing'" This
specification-based testing is actually a
form of rapid prototyping that lets devel
opers ny out their designs in variolls use
scenarios and remove requirements or de
sign errors before taking more expensive
development steps. It also lets them test
entireclasses of programs, rather than one
instance of a class of implementations, as
in program testing.
• Com1:rU(t program. If both design
verification and testing produce accept
able results. the developer can proceed to
build a structured-text prog=-a clear
box, or transparent, view of the function
block. An important part of this step is to
annotate the program with verification
conditions that represent assertions about
program behavior.
• Verify program. The de veloper
proves the validity of the assertions eiriler
manually or with appropriate tools. The
JANUARY 1994

developer can derive verification condi
tions automatically from either the design
specification or program by usingverifica
tion-condition generators. These genera
tors rely on logical deduction systems that
use axioms and deduction rules based on
Hoare logic4 to map one set of fonnulas
into another.
We used proof techniques developed
byJoseph Goguen5 and the Obj3 system2
to verity the consistency between critical
requirements and the corresponding de
sign specification. We used a variant of
Hoare-style proof rules6 to verity that a
stmctured-text program confonns to its
specification.
Hoare logic proved to be highly suit
able for PLCs bccause these systems rely
on simple programming constructs (like
variables and constants), elementary data
types (like Boolean, integer, real, bit se
quence, character, and string), conditional
and assignment statements, statemcnt se
quences, and Boolean and arithmetic ex
pressions- all of which are easilyhandled
by Hoare logic. N"asty constructs like un
bounded loops, recursion, or subpro
grams, which complicate proofs in Hoare
logic, are avoided because they often com
promise crucial real-time requirements
like predictability and timeliness.
• Test code. The process concludes
whcn the developer tests the code that re
sults from compiling the structured-text
pmgram.The developer can use the design
specification to generate suitable test data.
This approach follows Rogerio de
Lemos and colleagues' concept of split
ting requirements into mission
(functionality) and safety categories.7
Such a split gives developcrs freedom to
choose different formalisms to express
each part, but there must be a way to ver
ity the consistency of both.
To enable a seamless integration ofdif
ferent process steps, we uniformly use an
algebraic specification technique for
stating functional properties and (first
order)safetyconstraints as well as design
and program spccifications. We also use
term rewrit'ng both in design and pro
gram verifi'_'3tion and in specification
based testint,.
Obvious]y, PLC software developers
IEEE SOFTWARE
will have to work harder to follow this
method, as opposed to conventional ap
proaches that rely on informal or semifor
mal requirements and designs pro
grammcd directly in terms of ladder
diagrams (abstractions
Obj and Obj3. We used Obj through the
entire development process to fom1alize
requirements (step I), caphlre design re
quirements (step 2), verity the correctness
of design specifications and execute them
symholically (step 3), and
and formalizations ofelec
trical current-flow dia
grams) or insnuction lists
(mainly assembly-level
vendor and machine-spe
cific procedural lan
guages).
But they will find it
well worth the effurt. First,
thousands of control pro
grams use standard fimc
tion blocks. Fonnal inter-
WITH THIS
METHOD, YOU
CAN REUSE
FUNOION
BLOCKS AS
WELL AS
to state the implemen
tation,s pre- and post- I
conditionsin Hoare logic
(step 4).
Obj is rigorously
based on order-sorted
logic; its code consists of
equations and condi
tional equations. Obj's
basic building blocks are
objects, declarations, and
theories. Objects, which
THEIR PROOFS.
face specifications make it
possible to systematically reuse fimction
blocks and the proofs to verity them.
Also, formal development providcs
more evidence about the logical consis
tency between the �Jlecification and pro
gram for all possible input data.
Finally, because developers gain
deeper insight into the problem early on,
the cost to detect errors in later develop
ment stages and maintenance is lower.
DIVERSE BACK TRANSLATION
represent initial order
sorted algebl'3s - sorted sets with an in
clusion relationshipand a family of opera
tions - are named entities that encapsu
late specific kinds of data. This data can be
manipulated only through the operations
an object provides. Declarations intro
duce the kinds ofobjects and their opera
tions. Theories support parameterized
programming by specitying both the syn
tactic snucture and semantic properties of
This technique, which is required by German licensing authorities, was developed
for the Halden experimenllli nuclear-power-plant project byTOV Rheinland.t
Developers read machine programs from memory and give them to teams. Without
contactingeach other, the teams manuallydisassemble and decompile the code with the
finalgoal of regaining the specification.Asafety license is granted to thesoftware ifits
original specification agrees with the reengineered specifications.
The methotl is generally extremely cumbersome, time consuming, and expensive.
Thereis a tremendous semantic gap between a specification formulated in terms of user
fimctions and the usual machineinstructions to carrythem out. Usingthe process de-
I
scribed in the main text helps, however, because the design is dircc'tiy mapped onto se
, quences ofprocedure invocations and the corresponding object code consists only of
thesecalls and parameter passing. Consequently, thereis little effurt tointerpret the
code, reconstruct graphical design specifications, and verifytheirconsistencywith for
malized requirements specifications.
We are pursuing new research aimed at providing automated support for diverse
back translation usingthe semantics defined in the main text.
REFERENCES
I. H. Krebs and U. Haspel, "EinVerfahren zur Software-Verifikation: Regelungstechn"che PrllXis, Feb. 1984,
pp. 73-78 (inGerman).
63

Analog
data from
the technical
process
==
==
ADC
PARIN
-
CHECK
DIGX X-
--H EVAL
ICF
XB
XE
UA Lj SVISE
EUAE
----1,----- UL
LA -
LAE
r-- LL
COND I
Figure 2. Function-bkckdescription of" p,ugrmn tosupm!isejJrocm dota.
modules and module interlaces.
Obj3 is the latest in a series of systems
that supportObj by interpreting the equa
tions as re""Tite rules. We use Obj3 to for
mali:l;e function-block requirements, de
sign specifications, and the structured-text
program specification in terms ofObj dec
larations and (conditional) equations. We
then used Obj3's interpreter to automate
parts of verification and testing.
The Obj3 environment offers unique
semantics and underlying equational cal
culus, which let you provc theorems and
equations from specifications and derive
one set of terms from another using equa
tions as rewrite rules (called reducti on
rules in Obj3). This term-re""Titing capa
bilitywasparticularlyuseful in manipulat
ing the specifications needed to reason
about the properties of specifications and
programs, verilYtheircorrectness, and ex
ecute them symbolically.
EXAMPLE
'10 illustrate our method, we apply it to
the CHECK function block in Figure 2.
This blocktransforms a digitized and nor
malized signal DIGX produced by an an
alog-to-digital converter from analog raw
data into a measuring value provided on
output x. Ttl compute this value, we use
measuring-range limits XB and XE as pa
rameters.
A'i Figure 2 shows, CIIECK has eight
DTC;X
XB
XE
digitized measuremelllvalue X
lower bound ofX
upper bound ofX
CF channel fault signal
UAE beyond range alarm enaoleu
CL upperalarm bound
LAF, below range alarm enableu
LL lo",er alann hound
and four outputs:
X corresponding integer value ofX
UA heyond range alann signal
LA below range alaTIn signal
COND condition coue
if a channel fault, CF, is indicated, the
most recent proper value is delivered on
output X, not a newly computed value.
inputs UL and LL define the upper and
lower limits at which an alann is raised
through outputs UA and LA, respectively,
prO�ded inputs UAE and LAE, respcc
tivelv, are active.
Output Cond produces a notification
aboutCHECK's processing state. A value
of 1 indicates a channel fault, 2 means that
the measuring value exceeded the upper
limit, and 3 tells the operator that the mea
suring value remained under the lower
limit. Error notifications are ordered ac
cording to this priority.
The example we have chosen has tvw
characteristics: First, the requirements
that capmre the functional relationship
between X and certain input values of
CHECK are mixed; for example, safety
demands impose lower and upper bounds
on X or require alarm signals wlder cer-
PRST
To printer/tap
Recenter
LeftTop
Config
Profile
Adopt
Create
tain error conditions. Second, CHECK is
as<;umed to produce an output under any
condition. The implicit assumption here
is that CHECK and all other function
blocks of the PLC software are �eriodi
cally triggered by a control signal; thatis,
a function block is ready to compute new
output data whenever it is triggered.
Forma6ze requirements. Formalizing re
quirements for CHECK requires tranSlat
ingtheconcepts of the problem domaininto
mnstructs suitable for Obj specifications.
Obj provides a collection of built-in
objects including BOOL, INT, and
PROPC, which specify the laws of Bool
ean algehra, integer arithmetic, and prop
ositional calculus, respectively. There are
also two Boolean-valued operators, _==_
and _=1=_ and a polymorphic conditional
choice construct, iCthen_else_fi, which
applies to every sort s in its second and
third arguments,
Thebehavior of a functionblockis nat
uraly represented by Obj3 operations,
while types of 1/0 data are represented by
sorts. For example, we might associate sort
Eml widl binaly-value inputs and outputs,
usebit sequencestorepresent digitized data,
and employ integers to model measuring
and range values.
One data sort y may be a subsort of an
other sort S (written subsOtt s 5). This
means that s data can be USEd as an argu
ment of an operation that expects S data.
The interpreter in tbe Obj3 environ-
II inputs:
�--�--�-----------��=.��-==-�---�--�------====��--��---�
64 JANUA'1Y 1994

ment implicitly convertss data to Sdata.
In our example, objectTIMEprovides
distinguishable clock ticks:
obj TIME is sort TIme
opO : .... Time
optick : TIme -' Time
endo
In nontrivial cases, developers define
the properties of the operations provided
by modules, mutually relating the behav
ior of such properties using equations and
conditional equations. Because fi.mction
blocks are regularly triggered, they syn
chronously process streams a(0), a(l), ...
of time-varying data. To make the nmc
tion block'sinterfaceprecise, you can view
names of inputs and outputs as abbrevia
tions for access nmctions that map time
values to the typed data observed on
CHECK's inputs and outputs.
obj CHECK-INPUT is protecting !NT
protecting BITS
protecting TTMF.
opdigx : TIme -' Bits
opxb : TIme -' Int
oplae : Time -' Baal
endo
Because the results of computations
may refer to results of pre,�ous computa
tional steps, we assume that each output is
initialized with a suitable value to ensure
that allcomputations ofCHECKare well
defined. Vhen we try to initialize output
Cond, we see dlat the infonnal problem
specification gives no indication ahout the
state in which no stated faults occurred.
Thu�, we encode the OK indication as
value 0 to the output specification, which
is represented by operation cond (op
cond) in object CHECK-OUTPUT,
ob) CHECK-OUTPUTis
protecting :--ruM
protecting BITS
protectingTIME
op x : Time -' Int
op 11a : Time .... Bool
op la : TIme .... Int
op cond: Time .... Nat
eq x(O) = minnUlll
eq ua(O) = false
eq la(O) = false
cq cond(O) = 0
endo
IEEE SOFTWARE
More interesting is the following re
quirement for output Cond for arbitrary
times greater than 0:
cond(tick(1'» = 0 if not cf(I) and
not ua(I) and not la(I)
cond(tickCT» = 1 if cf(I)
cond(tick(l» = 2 if not cf(I) and ua(T)
cnnd(tickCT» = 3 if notcf(I) and
not ua(T) and la(I)
The definition of tbis requirement is
incomplete because it depends on the def
initions of output func1lons ua and lao Ve
examine tbis in the next step.
Spedfy,ver� CIId test design. The design
specification gives meaning to the opera
tions of CIIECK that compute its out
puts. Once these functions are abstractly
defined, we can apply specification-veriii
cation techniques to verilY that there is no
ambiguity, incompleteness, and inconsis
tency from design errors and oversights.
Additionally, we can apply tenn-rewriting
techniques to enhance the user's or
designer's confidence in a design by test
ing the design specification.
The definition of the output functions,
however, requires a careful interpretation
of the problem statement and sufficient
knowledge about the problem domain.
are
Two output definitions for CHECK
eq ua(tick(T»= ul(tick(T» x(tick(T») and
uae(tick(I)
cq x(tick(I) = xb(tick(T» + bi(digx(tickCT)))
* (xe(tick(l) - xb(tick(I)))
,
if notcf(tick(T»
cq x(tick(I) = x(I) ifcf(tick(I)
where cq and eq are Obj kcy words that
stand for conditional equation and equa
tion. Infonna!ly the first definition states
that ua is true if and only if both the acmal
value of x exceeds the upper range limit ul
and input uae is True at the same time.
The second definition reflects what we
know about normalizing measuring val
ues. It uses an auxiliary operation, bi,
whichmaps bitsequencesintotheir corre
sponding number value.
In the rest of this article, we apply
Goguen's proof techniques to fonnally
verilY that the designspecification satisfies
the requirements and any other proposi
tions about design properties. These re-
quirements or propositions are expressed
as equational theorems in Ohj3. A proof
consists of a sequence of rewrite steps
using premises and specification equa
tions. Its goal is to conclude the theorem
from the given specification and a set of
premises, which are again equations.
TheObj3 environment helps develop
ers perform routine work automatically.
The modularity ofObj is useful in struc
turing user-directed proofs in modules
and hierarchies.
To illustrate how Obj3 works, we give
protocol excerpts from a session in which
we verified the correctness of function x
with respect to dle following requirement:
0; xCT)= true if xb(T) ,,; xe(T)
using structural induction over the bit se
quences provided by DigX.
Bccause the requirement is expressed
as a conditionalequation, we must assume
the condition is true. Hence we assert
obj CHEC.K-BEHAV is using
CHECK-VARS
ops t t' : -' lIme .
cq t= tick(t').
eq xb(t); xe(t)= true .
eq 0 ,,; x(t') = true.
endo
and attempt to verifY the base cases with
I digx(t) I � 1 for some arbitrary Bit B and
d�t) = true or false.
The first case is trivial (the first two
lines show Obj3's prompt of the user's
input.The last linepresents the computed
result:
OBJ reduce 0 ;x(t)
result Hool: tme
because x(t) reduces to xC!'), for which the
condition holds by input assumption.
For cf(t) = false, a reduction yields
OB.l reduce 0,,; x(t)
result Hool: 0; xb(t) + bi(B) * (xe(t) - xb(t»
The resulting expression cannot be
further reduced, because xb(t), xe(t), and
x(t) arc constants whose structure is un
known but must be known to use equa
tions ofdatatype lIlt. Because of the input
assumption xb(t) :::; xe(t), however, we can
conclude that xe(t)-xb(t) is a natural num
ber, say m.
Further we know that bi(B) is a natural
number, say n. Hence, we know that n * m
is also a natural nwnber.
65

Q = (COND = 0 and not ua and not la and not d) or
(COND == 1 and d) or
(COND == 2 and not cfand ua) or
(COND == 3 and not cf and not ua and la)
[AI
{true}
Ifnot (cfor ua or la)
Then COND := 0
Else
{efor ua or la}
lfef
Then COND ;= 1
Else
{(cf or ua or la) and not d)
Ifua
Then COND := 2
Else
(cfor ua or la) and notcfand not ua}
Ifla
Fi
Then COND := 3
Fi
{Q}
{Q}
Fi
(Q)
Fi
(Q)
[81
(not Cdor ua or la» implies Q{COND/O}
«cfor ua or la) and cf) implies Q{CONDIII
, «cfor ua or la) and not cf and ua)implies Q{CONDI2}
«efor ua or la) and not cfand not ua and la) implies Q{COND/3}
leI
OB] reduce «efor ua or la) and d) implies Q{COND/1}.
reduce in PROG-VERIFICATION:
(efor ua or la) andcfimplies Q(COND/1}
rewrites: 206
result BooI: true
101
Figure J. Part oja structured-text program to implement tbe design specification ofCHECK (A) The
function Crmd, (B) local erificatioll cOl1ditiom d7ved1m, the precondition I'me and yme postconditirfll
cOl1'esponding to tbe requh'emmtf01' output Cond, (C) the (onditirms to he verifiedfin' (B), and (D) the proof
ofthe secondcondition of(C).
Hecause 0 ; Tv1 + N holds for two arbi
trary natural numbers Tv1 and N, the base
case is verified and we can assert
xb(t) + 1 * (xe(t) - xb(t» = xe(t)
After asserting the induction assump-
tion, the indul-110Il step yields
OB] reduoe x(t)
result Bool: true
for cfCt) = false
Other properties and output func.tions
are treated similarly.
Because Obj specifications are execut
able, the design specification can also he
taken as a prototype of the CHECKfunc
tion blocktovalidate itsfunctioningUllder
6 6
the conditions of a specific application.
Simple tests of the function hi are
OBJ reduce bill 0 1)
result Nat: 5
Ul:IJ reduce birO)
result Nat: 0
ConstJud, verify, and test program. Pro
gram construction involves building a
structured-text program from the design
and adding assertions about program in
puts and outputs in the form of pre- and
postconditions. Programconstruction is a
creative step, yet it is often relatively sys
tematic. Equational statements of the de-
sign specification are transfonned into a
sequence of program statements such as
if-then-e1se clauses, assignment state
ments, and Boolean and atithmetic ex
pressions. Figure 3 shuws a section df a
structured-text program intendcd to im
plement the design specification of
CHECK. Figure 3a shows function
Condo Figure 3b shows the local verifica
tion comlitions derived from the precon
dition true and some posteonditions cor
responding to the requirementfor output.
The specification for output Cond (sec
ond column of p. 65) has been translated
into the nested if-then-else clause in Fig
ure 3b.
The goal of program verification is to !
verify a program's conformance to its
specification in a finite number of steps by
applying appropriateHoare proof rules to
the statements of that program. Hoare's
technique lets us verify the partial correct
ness of a program S with respect to asser
tions P and Q that may or may not be �
satisfied hy the variables OCCUlTing in S. An
annotated expression of the form {PIS[Q)
inf0l11lally means that, if assertion P holds
before the execution of 51, assertion Q
holds when the execution of 5 tenninates.
For example, for a conditional statement
s= IfCThen 51 Else 52 Fi
'With precondition P and postcondition R,
we can detive pre- and postconditions for
51 and S'2 using the general rule for condi
tional statements4;
{P and C] Sj (R)
{P md not C] S2 {R}
If we can find proofS for these assertions,
we also have a proof for {P}S{R}.
In the stepwise proof we proceed as
follows:
I. Start /i'om the postcondition and
tollow the program path in reverse.
2. For each statement S on this path,
apply an appropriate proof rule to trans
form the postcondition of this statement
into the weakest precondition. This pre
condition becomes the postcondition of
the preceding statement. That is, you de
rive pre- and posteonditions for the I
CHECK statements using appropriate
proof rules to end up with a structmed
text program whose individual statements
are annotated with verification conditions.
JANUARY 1094

Figure 3c gives dle conditions to be
verified for me programin Figure 3b. The
expression Q{COND/l} denotes the
same as condition Q except that variable
Cond in Q is substiruted wim 1. Figurc 3d
shows me proof of me conditions, which
comes down to a term reduction in Obj3.
(VVe used an Obj specification not given
here do dUs reduction.)
Thus, having proved all verification
conditions generated for CHECK, we
have proved me correctness of me entire
program wim respect to its requirements
and design specifications.
To validate (test) me resulting pro
gram, we used standard techniques such as
dynamic code testing and static program
analysis. The selection of test procedure
(mutation, back-to-back, random, bound
ary checking, and so on) depends on me
domain requiremcnts and function-block
characteristics.
�ere are many advantages tousingfor
• mal specification and validation tech
niques in me development ofPLC software
for safety-related applications. The main
one is that bomPLC developers and certifi
cation authorities can use these techniques
to show a program's dependability.
Our emphasis was on demonstrating
dle functional correctness of reusable
function blocks to become members of a
domain-specific catalog of standard build
ing blocks and, merefore, justifY me extra
effort necessary to guarantee safety. Ve
hope it became clear mat manual proofu of
verification conditions, even for relatively
simple programs, are tedious and error
prone. The notations and techniques we
used - Obj, term rewriting, and Hoare
logic - are wcll-understood, supported
by effective tools, and have been success
fully used in similar experiments bom for
hardware and software specification and
verification.
By interconnecting verified function
blocks, correctness proofu are reduced to
verifYing me horiwntal and vertical con
sistency of me functional composition plus
any analyses of how individual blocks in
terplay.
Still missing is a full a=lmt of timing
properties, which occur often in me type
IEEE SOFTWARE
of process-control applications considered
here. Tinling characteristics are covered
reasonably well for individual function
blocks, but we arc still looking at how to
handle me rinling characteristics of me en
tire program. Specifically, we are experi
menting wim various logic and formal
isms, including time notions like duration
calculus, real-time logic, timed communi
cating sequential processes, and timed
Petri nets.
As an alternative to considering tinled
logic and to gain experience wim a predi
cate-logic approach, we specified a simple
timer to be used in an emergencyshut-down
system and verified its correctness using a
verifier written inhigher orderlogic.
R
The timer is a monostable element,
which cannot be retriggered and has a
selectable delay. 'hen me timer is in
me nonexcited state and detects a rising
edge at its input, it switches its output to
the logical true state for a specified
delay.
The timer relies on time readings of a
radio receiver, which provides monotoni
cally increasing time values broadcast by
official agencies mrough me satellites of
me GlobalPositioning System or wough
terrestrial stations in vari()U� cOlmtries.
Furilier experiments are underway to gain
better data for eompating me practicality
and ease of use in bom me Obj3 and HOL
approaches. •
�l��C�rinCiPles ofOB]2,·· m Pro... AC1 Symp. PrindplerofPmgmmming Languager,=-lPress� New York, 19t15, pp. 52-66.
I
2. J. Goguen and T. Winkler, Introducing OB]3, Tech. Report SRI-l:SL-RR-9, SRI Int't, Menlo Park,
��
II
3. V Halang and Il. Kramer, Achieving High Integrity of Process Control Software by Graphical Design
and Fonnal Verification. Software Engineering].,].n. 1912, pp. 53-64.
4. C. Hoare, An Axiomatic Basis for Computer Prof,'Tarnming, Cvmm. AC/'vl, Oct. 1969, pp. Si6-580.
5. J Goguen, OB) as a T heorem Prover with Applications to Hardware Verification,' Tech. Report SRI
CSL-88-4R2, SRI Int'I, Menlo Park, l:alif., 1988.
6. R. Rackhollse, Prognlfn COIJXlrIUflO'llilltd H:rifoation, Prentice-Hall, Englewood Cliffs, NJ., 1986.
7. R. dt: Lemos, A Saeed, and T. Anderson, A Train Set as a Case Study for the Requirements Analysis of
Safety-Critical Systems. The Cmnputrr].,Jan.l9l2, pp. 30-4D.
8. 11. Gordon, NlechaniLing Programming Logics in Higher Order Logic, in Current Trends in Hardware
I/e-nfication andAuwmatedTheorem Proving, G. Birmistlc and P.A Suhrahmanyam, eds., Springer-Verlag,
Berlin, 1989, pp. 387-439.
-olfgang A. Halangholds the chair of infonnation technology at FernUniversicit
J ragen, where his research interests an: predictable �ystem behavior and rigorous soft
ware verification and safety licensing. He is founder and editor-in-chief of Real-Time .�'V.I'
tcmsand has ,'littcn mare than 100 publications on real-time systems. He is coauthor
with Alexander SlOyenku ufConTructing Predhtable Reol-time Systems(Kluwer Acadmic
Publishers. 1911) and with Bernd Kramer and others ofA Safety T.imlJahle Comp1ltingAr
chitecture.
Halang received a PhD in mathematics from Ruhr-Universitat Bochum and a PhD
in computer science from the Universitat Dorbnund.
BerndKramerholdsthe chair afdata-processing technology at FernUniversitat
Hagen and is director ofthe associated InsLitute fur New'Iec:hnologies in Electrical En
ginet:ring. His research interests include fanna] specification, design and analysis tech
niques for distributed systems, advanced communicationtechniques, and development
methods for high-integritysofrniare. He is author ofC'uncepts, Syntax, ilnd Sema1ltit'Soj
SEGR4S(R. OIJenbourg, 1989) and coauthor with Wolfgang Halang and others of A
SafetyLiansable Camputing .4hitfcturr (World Scientific, 1YY3).
Kramer received a diploma and a PhD in computer science, both from the Tech
nische Universitiit Berlin.
Address questions about this drtide to Kramer at FernUniversitit Hagen, Fachbereich Elel'tratechnik, 58084
Hagen, Gennany; bernd.kraemer®fernuni-hagen.de.
67

safety assurence in process control

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to safety assurence in process control (20)

Recently uploaded (20)

safety assurence in process control