Proceedings of the 28th Annual Hawaii international Conference on System Sciences - 1995
Making the
Requirements
of Process Controlled
Systems Explicit
T.K. Sateesh
Computing Department, Faculty of Mathematics and Computing
The Open University, Milton Keynes MK7 6AA, U.K
Abstract
structure of the system operation and furnishes the
operational behaviour of the system. Requirements
specification basedon real world models are transparent
and easy to understand.System interactions are related to
the communication among componentsand environment.
In order to avoid any misunderstandingrequirements must
be expressed in a formal representation. A formalism
specifies a class of objects under discussion in an
unambiguousand general manner [21]. For easy analysis
requirements are required to be stated in a language
understandableby computers.
Process controlled systems have to satisfy
stringent timing characteristics.Timing constraints arise
while maintaining the stability of plant. These timing
constraints depend on the physical characteristicsof the
plant. For example advanced variable cycle jet engines
can blow up if correct control inputs are not applied every
20 to 50 milliseconds [121. Such system needs are
requiredto be representedin a language that incorporates
timing feature. This requires various properties to be
specified as a function of time. As Leveson [14]
observes “most real-time specification languages have
only simple primitives for timing, such as a time-out,
that do not adequately capture the complexities of time
and therefore are inadequate for fully specifying and
modelling requirements”. A requirementslanguage must
facilitate the description of temporal properties that are
meaningful for thesesystems.
Some of the trend setting work in requirements
modelling include [l] and @I. [l] focuseson stimulus response behaviour. and identifies events subject to
timing constraints. However it supports very little
support for abstractionand lacks a clear underlying model
of computation. 181describes the external behaviour of
systems in terms of events defined by transitions.
However it has not explicitly modelled the timing
constraints associatedwith the system. In 133and [2] a
state-basedlanguage is reported. State-basedapproaches
have been found to be unsuitable for describing the
behaviour of large and complex systems. The language
discussed in [20]
has been criticised for being
implementation oriented. Recent efforts like [4] and [5]
suggesta techniquebasedon formal languages.However
Process controlled systems are used for dedicated
applications. Every application is the subject of special
requirements enforced by the customer. Requirements
modelling is an user centred activity. Thesesystemsare
time critical. The requirementsmodelling language used
mustfacilitate the description of temporal requirements
that are meaningful for these systems, while being
understandable by user community. Here we discuss a
language(TRL) ana’its features.
1. Introduction
A major application of computers has been in
the control of physical processes like industrial plant
control, nuclear reactors, flight control systems and
patient monitoring systems. All such applications are
characterisedby their complexity, reliability and safety.
Computer is used to monitor and control functions,
where a failure to honour a timing constraint may result
in destruction of plant and even lives. In all such
applications demand for the correct behaviour of the
system is extremely
high. Such systems are
characterised by hard response time and dynamic
environment. Some researchersclassify the environment
as static and dynamic dependingon whether the systemis
a closed loop or open loop. It is assumedthat in a closed
loop the behaviour of environmentcan easily be predicted.
Though the supposedlystatic environment has to observe
the physical laws, likely changesin the processmay not
always be predictable due to the disturbances.For such
reasons we observe that the environment is always
dynamic.
Process controlled systems normally interact
with external world entities. A system can be thought of
as a collection of a number of components. These
componentsinteract with eachother to achievethe desired
goal. Such a system can be describedfrom external user’s
point of view. External description establishes
associationsamong activities which occur within different
subsystemsof a system. Sequenceof interaction among
components provides a description of the underlying
1060-3425/95$4.00O1995IEEE
372
Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95)
1060-3425/95 $10.00 © 1995 IEEE
Proceedings of the 28th Annual Hawaii International Conference on System Sciences - 1995
formal languages have been criticised for non
understandability[6].
In this article we introduce the conceptsof timed
requirementslanguage(TRL) to specify real time aspects
of the systems.TRL is designedto specify systemswhere
temporal aspects are of interest. TRL promotes a
descriptive method. TRL emphasisesunderstandingwhat
takesplace and when it takes place in the system,which
are systembehaviours. TRL is event centredand models
the system by user oriented concepts. In the following
sections we discussthe features of TRL. The grammar
of TRL is provided in an appendix.
2.1 Approach to Modelling
Functional requirementsoriginates from a sense
of causation.A letter can not be read unlessit is received,
and in a restauranta customer gets what he orders. The
requirement is a chain that mirrors this causal
relationship among several events occurring in a
system. Real-time systemsinteract with physical devices
which are monitored and controlled. A complex systemis
a combination of interacting components. In all these
systemsone device energises the other. The behaviour of
a system is this causal relationship among real world
events. Requirements evolve from this simple set of
behaviour. Requirementof a systeminvolves the order of
occurrenceof events and also the constraints on the time
of occurrence. We make use of event based model to
capture the behaviour of the system. Event based models
havebeenusedby variousresearchers[ 13][9].
The behaviour of a software system may be
characterised by the sequence of events which occur.
Distinct events carry distinct labels. Each event is
assumedto occur instantaneously.Event occurrencemarks
a point in time, which is significant for the analysis of
dynamic behaviourof the system. Thus event servesas a
temporal marker. Continuous events which consumea
definite time interval and is vital for reasoning are
representedby two atomic events like start of the event
and the end of that event. By atomicity we mean that the
eventsare indivisible.
In event model, one is interested in the ongoing
processinvolving real world entities (i.e., how an event is
caused,how an event affects other events,and which event
is dependenton other events). Description of behaviour
produces a chronological relationships between
corresponding events. With real-time systems we are
interestedin the precise sequencingof operationsand the
detailed timing and control characteristics of external
devices.Behaviour is a sequenceof events.The sequence
of events involves the exchange of information between
the co-operating units. These units co-operate to
producethe desiredresult. Modelling the behaviour in any
system adequately, aids the problem of software design
and analysis. Behavioural specifications has to be
operational to aid the easy analysis of system behaviour.
Event sequencerepresents a finer detail of activities
involved in the behaviour.A finer detail of sequencingis
required in message communication
and task
synchronisation. Event oriented strategy emphasisesthe
prescheduling of all events. Behavioural specification
describes constraints on the observable behaviour. A
constraint imposes a restriction on the behaviour of a
system. A commonsense description of the system’s
behaviour envisions the relationship between the
components of system and their potential behaviour.
Functional description of system is describedin terms of
the exact role of its components.
2. System Modelling
System modelling starts with
informal
requirementsand a set of assumptionson the systemand
environment. A model is a simplified representationof
something to be developed. Model incorporates the
essential feature of the system. A model of a
computational paradigm is a set of direct or indirect
observations that can be made of a computational
process[101. A systemdescription constructsa model of a
system.This model identifies the approximatestructureof
systemby recognising the important incidents that occur.
The word structurerefers to a partial descriptionof system
showing it as a collection of parts and showing relations
between the parts [17]. We think of a system in terms of
theseincidents.A system is defined by theseincidentsand
by the relations that hold between these incidents. An
incident providesa dynamic instanceof the descriptionand
is called as an event. Thus an event is an assertionabout
somebehaviour parameter of the system. Requirements
model is an user oriented model. It must describe a
system as perceived by its user community. The object it
manipulates must correspond to the real objects of that
domain.
As suggestedearlier a real time system consists
of various components. The two major componentsthat
can be readily recognisedare controller and environment.
These components are connected by physical devices
which operatein their own time scales. Controller is said
to operate in real-time if actions carried out by the
controller relate to the time scalesof the external tasks.
Relationship among thesetasks can be captured in terms
of passage of time. Typically the requirement of a
controller is to complete a set of operations within a
prespecified time. Majority of tasks fall into this
category. The system is driven by the environment. The
sequenceof actions is not determinedby the designerbut
by the events occurring in the environment.
Environment is an active part of the total system.It is the
responsibility of the controller to overcome any
unsatisfactory behaviour of the environment. While
system modelling, environment has to be modelled first.
This becomesessentialto capture the lag time and various
responsetime requirements.
373
Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95)
1060-3425/95 $10.00 © 1995 IEEE
Proceedings of the 28th Annual Hawaii International Conference on System Sciences - 1995
3. Model
4. Timed Requirements
Requirements of a system refers to a source of
observable information. A requirements model is the
user model of the system. User model of a system is
narratedin principle by the independentobservationof the
system. An observer can not influence the system in any
way. The basic conceptsin our model are timed events,
conditions and timing constraints.
Event basedmodel provides the basis to express
the real time requirements of a system. For the purpose
of mechanicalmanipulation requirementsare required to
be stated in a language understandable by computers.
Such a description is not only executablebut also serves
as a source of projection. A behaviour definition is of
the form
OxLid (el . e2 . .. en) 1
where beh-id is the languageconstruct that relates events
(ei , e2, . . en).
System activity is assertedby defining bodies of
processes.Processesare used to describe the dynamics of
the system. Process consists of a set of behaviour
definitions, where eachbehaviour definition is justified by
the behaviour definition previous in the sequence. A
processP is a set of behaviour definitions of the form
(b&id (el . e2, .. en) 1
Timed Events
Event based model is a tuple c E , T > where
E is the event set and Tis the time base set. Given
a set of events E and a time set T (a totally ordered over
therealsR),atMdeventisapair(e,t)E
ExT,ee
E
andte T.
A timed event sequence is a set of timed events
((ei,ti), (e2, t2), ... , (en,tn)] where there is a total
ordering on the timed events determined by the total
ordering of T, such that for all (ei,ti) I (ej, tj) if tistj,
ei,ej E E and ti,tj E T.
Language
(beh-id (kl ; ei, :. en) )
In TRL every event is a timed event, A timed
event associatesa time parameter with an event. It is
expressed as (button-pressed , tl) where tl is timing
parameterassociatedwith event button pressed’.
Behaviour of a system with event model is
captured by the consequential analysis of events.
Consequentialreasoning is a qualitative reasoning about
observed or postulated behaviour. Such a reasoning is
quite useful for generating explanations on what can
happen and how the things that happen can interact.
System description is derived from the behavioural
description of components and their interconnections.
Behavioural description of each component reveals its
objective. Functional description of a system describes
the overall function in terms of the behavioural
descriptionof eachcomponent.
Conditions
Condition states the property of the system.
Conditions are modelled by their names. A primitive
condition name c E C, where C is the condition name set.
Condition name c is a variable which is characterisedby
a pair (value(c),assignment(c)),where:
value(c) E (true, false] , the value true or false is
assignedto c;
assignment(c) i.e. assignmentto c is an event so
at the instant
as c takes the value, value(c)
time (assignment(c)) .
Examples of such Conditions are “water is hot”, “power
down in progress”and etc,. These describe the physical
condition of the system. The physical condition of a
systemchanges during its lifetime.
Types
Timing Constraints
Following Martin-L% constructive type theory [la] we
define types as predicates that state the properties of
system or its components.Predicate is a property of the
system. For example it may be an expression that a
certain variable has a positive value or that a certain
resourceis available. It may be expressedas
Timing constraint is a restriction on the occurrence
of certain events. Timing constraints are the qualitative
and quantitative statementsabout the required temporal
or&r of events.
Behaviour and Processes
valid-temperature = 15 < temp < 25
high-temperature = temp > 25
The behaviour of the system is a set of sequences
of timed events. The types of behaviour that are of much
interest are periodic and sporadic behaviour [ 151. A
sporadic behaviour is specified by a sporadic constraint
consisting of events that might trigger the behaviour,
with an associatedtiming constraint.A periodic behaviour
is specified by an event that has to occur at regular
intervals of time while a condition holds.
A process is a set of behaviours. Processconsists
of a simple sequenceof timed events that the real system
may engage.
We use the predicate names such as “invalid
temperature”, “high temperature”, “low temperature”to
representsystem properties. We assumethat these have
been suitably defined.
5. Expressing
Requirement
Processcontrolled systemsare reactive and time
critical [19]. Reactivity capturesthe inherent sproradicity
involved in the system. Sporadic behaviour deals with
374
Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95)
1060-3425/95 $10.00 © 1995 IEEE
Proceedings of the 28th Annual Hawaii International Conference on System Sciences - 1995
events which occur at irregular intervals of time. It
requires some event to be executed with a timing
restriction since the occurrence of a certain event. An
inherentproperty of sporadicity is it being driven by some
event happening in the system. This is what happens
with reactive systems.Sporadicity assertsthat one event
triggers another event. This triggering notion is
fundamental to reactive systems.Thus sporadicity in the
systemconsistsof two parts one an activator and another
a triggeredpart
Triggered part defines action sequence in
responseto input events relevant to that system. Action
sequencedescribesthe completepatternof behaviour.This
action sequence may consist of one or more events. In
other words each event may trigger finetly one or more
events. Trigger is a strict partial ordering on events with
utmost one immediate predecessorevent. Causalordering
manifests relation between <activating event> and
caction sequence>. Action sequenceis to be performed
one at a time and in the order they are written. Action
sequencemay be representedby a single event or as a
composition of events. It is possible to specify several
action events which all meet the same selection criteria.
Composition of events is representedby events separated
with a semicolon.
A system can react to several types of events.
For example an automated library assistant (ALA) can
react differently dependingon the type of order received.
ALA
depending on the order received generates a
collection of eventsor a single event.
if (command= reserve, tl) then (proceedto
reservea book, t2)
elsif (command= overdueYnotice,t3) then (proceed
to issue notice, t4)
elsif (command= check-status,t5) then (proceedto
check the status,t6)
elsif (command= help , t7) then (provide help, t8) fi
A boolean condition may be associatedwith the
triggering event. In such a casethe condition is evaluated
first and if the result is true then further event can be
observed.For examplea book can only be reservedif it is
available in library. This is expressedas
if (command= reserve , tl) aswell (book is available)
then (proceedto reservea book, t2) fi
Defunct behaviour (nil) is built into TRL and
this does not engage in any events. Another type of
behaviour recognised with real time system is the
periodic behaviour. A periodic behaviour requires some
event to be executed at fixed intervals while some
condition holds. In other words, after some triggering
event el, the event e2 is executed periodically until
another event e3 occurs making the condition false. The
syntax of a periodic behaviour is:
<periodic behaviour> ::= “from” ceveno “repeat”
<event> “every” <time constant, “until”
<eveno.
5.1 Representationof timing constraint
Timing constraints are an essential part of realtime requirements. In [2] various types of timing
constraints associated with a system are described. A
slightly different approach to temporal requirements is
employed in [l 11. Timing constraints of both types can
easily be expressedwith TRL. More complicated timing
constraints can be expressedinvolving event associated
timers. The timing constraint is expressedas a relation
betweenthe timing parameters,like
if (command= reserve, tl) then
(proceedto reservea book, t2) where
(t2 c= t1+5) A (t2 > tl +l) if
Temporal requirements are the qualitative and
quantitative statementsabout the required temporal order
of activities. Timing constraintsare explicit specifications
of the behaviour of system components. Timing
constraints in TRL are specified by timing relation(s)
between events. Any timing constraint user defined or
system derived can easily be expressed. Timing
constraint can involve the constraint over many events.
With periodic behaviour the periodicity of repetition is
specified. TRL treats functionality and timing in the
same framework. Naturally it is possible to build several
behaviours for the same system. These can be developed
independently to simplify the task of requirements
evolution. Here we are not describing the language in
detail. The description of the language is reported
elsewhere[18]. It is not essentialto this paper, as here we
are only considering the concepts of language. The
grammarof the languageis given in an appendix.
5.2 Operational Requirements
The developmentof requirementsfor real time systemsis
a difficult task. The processof requirementsdevelopment
is incremental in nature. For such a reason we observe a
system as a collection of components, which cooperate
with each other to achieve a desired result. Behaviour of
eachcomponentis representedas a processin TRL.
TRL treats a system as a set of processes.A
process is an abstract representation of a computation.
System behaviour is a composition of the various
processes.Parallel composition ( II ) of a set of processes
describesthe joint behaviour of all the processesrunning
concurrently. Here processes synchronise via common
events, and concurrency is modelled by all possible
interleavingsof the events.
6. Conclusion
The essential feature of the language is being
descriptive and this is appropriate for modelling the real
time aspects of the system. Description of a system
requires the identification of events contained in the
system. As this method is parametrized with respect to
events in a system, it allows to treat different systemsin
a uniform way. TRL is primarily intendedfor representing
375
Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95)
1060-3425/95 $10.00 © 1995 IEEE
Proceedings of the 28th Annual Hawaii International Conference on System Sciences -
the user model of a system. User model of a system
controls the complexity of large systemsby identifying
the various componentsof the system.Systembehaviour
is then the composition of the behaviour of the various
components. The language has a simple underlying
model. It proposesa system at a simple abstract level.
TRL has been used to specify some classic examplesof
real-time systems.A case study with TRL is reported in
[ 191.PREET (Process-orientedREquirementsElucidating
Tool) checks the validity and consistency of
requirementsexpressedin TRL.
1995
<event name> ::= <identifien
<time parameter>::= <identifier>
<condition> ::= <identifier>
<head> ::= <identiller> “$”
<identifier> ::= <letter, { detter> I <digit> )
<r&ion operator, ::= “c” I “B” 1 “<=” 1 “>=”
I ll=ll
<integer> ::= <digit> ( <digiD )
<real> ::= cintegen “.” <digit> ( <digiD )
<statementseparator> ::= “$ ”
<don’t care> ::= ‘Y”
Appendix
Acknowledgement
I would like to thank P.A.V. Hall for suggestions and
commentson the earlier draft of this paper
BNFofTFU
Items enclosedin [ squarebrackets ] may appearzero or
one time, and items enclosed in ( braces ] may appear
zero or more times. Terminal symbols appearin ” double
quotes“.
<system>::= “requirements”<head> ( <processes>)
<process>::= <process> ( ” II ” <process>)
cprocess>::= “process” <identifier> “begin”
<namedbehaviour> [next behaviourname]
( ‘3” cnamed behavioun
[next behaviourname] ] “end”
cnamed behaviour> ::= <identifier> “:” <behaviour>
<next behaviour name> ::= “&” cidentifier>
&ehaviour> ::= “do” <timed event sequence>
“where”<timing constraint>
I <special behavioun
<specialbehaviour> ::= <periodic behaviour>
I eyoradic behaviour>
<periodic behaviour> ::= “from” <timed evenO “repeat”
<timed event> “every”
<time constant> “until” <timed event>
<sporadic behavioun ::= “if” c initiator > “then”
< participator > ( <alternativeevent sequence>)
<alternative event sequence>::= “elsif’ cinitiator>
“then” <participator>
<initiator > ::= <event> I <event> “aswell”
<condition>
cparticipator > ::= “nil” I <timed event sequence> I
<timed event sequence> “where”<timing
constraint > [ “else” <timed event sequence>I
“else” c timed event sequence> “where ”
<timing constraint> ]
<timed evenD ::= “(“<event name> “,”
<time pararneten I’)”
<timed event sequence>::= <timed evenO ( “;‘I
<timed event> )
<time parameter>::= <time parametername>
I <don’t care>
<timing constraino ::= <timing facton
( “and” <timing factor> )
<timing factor> ::= I’(,, <time parameter>
<relation operaton <time parameter> “+‘I
<timing duration> “)”
<time constar ::= <integer> I <real>
References
[l]
M.W Alford,
“A Requirements Engineering
Methodology
for Real-time
Processing
Requirements,” IEEE Transactions On Software
Engineering,January 1977, pp. 60-69.
[2] B. Dasarathy, Timing Constraints of Real-time
Systems:Constructs for Expressing Them, Methods
for Validating Them, IEEE TransactionsOn Software
Engineering, SE- 11 (1) : 80 - 86 , Jan 1985
[3] A.M Davis, “The Design Of a Family Of
Application-Oriented Requirements Languages,”
IEEE Computer, May 1982, pp. 21-28
[4] E. Dubois and J. Hagelstein, Reasoning on Formal
Requirements: A Lift Control system, Proc. of the
Int’l Workshop on Software Specification and
Design, 1987, pp. 161-168
[5] S.J. Goldsack and A.C.W. Finkelstein, Requirements
engineering for real-time systems, Software
Engineering journal, May 1991, pp. 101 - 115
163 A. Hall, Seven Myths of Formal Methods, IEEE
Software, 7(5), 1990, pp. 1 l-20
[7] C.L. Heitmeyer and J.D. McLean, Abstract
RequirementsSpecification: A New Approach and Its
Application, IEEE Transactions on Software
Engineering, Vol SE-g, No. 5, September 1983, pp.
580 - 589
[83 K.L. Heninger, “Specifying Software Requirements
for Complex Systems: New Techniques and Their
Applications”, IEEE Transactions On Software
Engineering , SE-6 (1) : pp. 2 - 12, Jan 1980
[9] C.A.R. Hoare, Communicating Sequential Processes,
Prentice Hall Int’l, 1985
[lo] C.A.R Hoare, Let’s Make Models, in LNCS 458,
Ed J.C.M. Baeten and J.W. Klop , CONCUR - 90,
Theories of Concurrency:Unification and Extension,
Springer - Verlag, 90 pp. 33
[ 111 F. Jahanian and A.K. Mok, Safety Analysis of
Timing Properties in Real-Time Systems, IEEE
Transactions on Software Engineering, Se-12(9),
Sept. 1986, pp. 890 - 904
376
Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95)
1060-3425/95 $10.00 © 1995 IEEE
Proceedings of the 28th Annual Hawaii International Conference on System Sciences - 1995
[12] J.H. Lala, R.E. Harper and L.S Alger, A Design
Approach for Ultrareliable Real-Time Systems”,
IEEE Computer 1991 pp. 12 - 22
[13] L. Lamport. Time, Clocks and the Ordering of
Events in a Distributed System, CACM, Vol. 21
(7). July 1978, pp. 558 - 565
[14] N.G. Leveson, “The Challenge of Building Processcontrol Software”, IEEE Software, November 1990 ,
pp. 55 - 62
[15] AK. Mok, The Decomposition of Real-Time
System Requirementsinto ProcessModels, Proc. of
Real-Time SystemsSymposium, 1984 pp. 125 - 134
[16] B. Nordstrom and J. Smith, Propositions And
Specifications of Programs in Martin-LUfs Type
Theory, BIT 24(1984) pp. 288 - 301
[17] David Pamas, On A ‘Buzzword’ : Hierarchical
Structure, proc. of IFIP 74, North-Holland,
pp. 336 - 339
[18] T.K. Sateesh and P. A. V. Hall, Eliciting
Requirementsfor ProcessControlled Systems,to be
published in proc. of the Int’l Computer Symposium
(ICS 94) to be held at Hsinchu,Taiwan,
Dec. 12-15,1994
1191J. A Stankovic, Misconceptions about Real-Time
Computing: A serious Problem for Next Generation
Systems,IEEE Computer Vol. 21 (10) pp. 10 - 19
[20] P. Zave, An Operational Approach to Requirements
Specification for Embedded Systems, IEEE
Transactions on Software Engineering, vol SE-8,
May 1982, pp. 250 - 269
[21] B.P. Zeigler, Multifaceted Modelling and Discrete
Event Simulation, Academic Press, Orlando 1984
Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95)
1060-3425/95 $10.00 © 1995 IEEE