The document describes a formal process for developing programmable logic controller (PLC) software to improve safety verification. The process involves: 1) Formalizing requirements and using them to specify function block designs. 2) Verifying the designs meet requirements and testing them symbolically. 3) Constructing and verifying structured text programs that implement the designs. 4) Testing the final code. The process is demonstrated by formally developing a CHECK function block that transforms sensor readings within set limits and triggers alarms.

1. •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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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