ISA Transactions 48 (2009) 3–9

Contents lists available at ScienceDirect

ISA Transactions
journal homepage: www.elsevier.com/locate/isatrans

A new proposal for the behaviour model of batch phases

Giovanni Godena ∗
J. Stefan Institute, Department of Systems and Control, Jamova 39, 1000 Ljubljana, Slovenia

article info a b s t r a c t

Article history: There is a problem with managing the complexity and meeting the high-quality requirements of batch-
Received 30 May 2008 process control software in the environment of the modern tools for batch-process control according
Received in revised form to the ISA 88.00.01 standard. The problem stems from the insufficient abstraction level of the phase-
6 August 2008
behaviour model consisting of only five active sequences. A solution to this problem is proposed, based
Accepted 12 August 2008
Available online 11 September 2008
on increasing the level of abstraction of the phase-behaviour model by adding to it the nested states and in
defining an increased number of finer-granularity activities. The new concept, together with its elements,
Keywords:
is described, and its use is illustrated by means of the specification of a phase from a real batch-control
Batch control project.
Batch phases © 2008 ISA. Published by Elsevier Ltd. All rights reserved.
Behaviour model
State machine

1. Introduction
There is a broad consensus among the manufacturers of
automation equipment, service providers in this field and end
users of the need to comply with the ISA 88.00.01 standard [5] in
batch-process control, regardless of the level of automation of this
control. However, there are also certain problems concerning the
application of the standard and the batch tools that are based on it.
These problems include:
1. The unsatisfactory reliability of the personal computer (PC)
platform and the real-time communication loop,
2. The poor compatibility of the existing tools,
3. The unsatisfactory behaviour of PCs with regard to execution
speed and time determinism, and
4. The insufficient expressive power of the phase-behaviour
model, which is shown in the generally complicated logic of
the individual states and particularly as a frequent need to
memorize the current step on the state transition in order to
return to the same step, which is a non-transparent low-level
concept, and per se a frequent source of errors.
The first three of the above-mentioned problems are usually
tackled with the development of simplified batch-control tools, for
the PC or the PLC platform, which are more or less compliant with
the ISA 88.00.01 standard. These tools are mostly over simplified
and therefore lose most of the expressive power offered by the
S88.01-based tools. In some cases the recipe control system is
even embodied in the application code, which as a rule has a very
negative impact on the quality. In our recent paper we described
∗ Tel.: +386 1 477 36 19; fax: +386 1 477 39 94.
E-mail address: giovanni.godena@ijs.si.
0019-0578/$ – see front matter © 2008 ISA. Published by Elsevier Ltd. All rights reserved.
doi:10.1016/j.isatra.2008.08.002
the development of a batch-control tool for the PLC platform with
a near-to-ISA 88.00.01 functionality [1].
In the remainder of this paper we present an approach to
solving the problem of an insufficient abstraction level of the
phase-behaviour model. The approach is based on the definition
of a new, enlarged and more complex phase-behaviour model.
The paper is structured in the following manner. Section 2
describes the phase-behaviour model recommended by the
standard ISA 88.00.01. Section 3 describes a new proposal for the
phase-behaviour model.
2. The phase-behaviour model according to the standard ISA
88.00.01
The standard ISA 88.00.01 recommends a phase-behaviour
model based on the abstraction of state machines, which is widely
accepted as a very appropriate notation for describing reactive
systems in general [2]. In our opinion, as well as in the opinion
of the vast majority of the batch-control-software community,
the state-machine abstraction also deals very well in describing
the behaviour of the procedural control entities in the domain
of batch-process control. The phase-behaviour model proposed in
ISA 88.00.01 is shown in Fig. 1 (the only difference between the
presented model and the model given in ISA 88.00.01 is that the
model presented in Fig. 1 is based on the consistent use of nested
states, with the positive consequence of avoiding the repetition of
the transitions).
The model defines ten elementary (lowest-level) states (shown
as dark blue in Fig. 1). Among these ten states there are
five quiescent states (without any processing) and five active
states. The quiescent states are Idle, Complete, Held, Stopped,
4 G. Godena / ISA Transactions 48 (2009) 3–9
Fig. 1. Phase-behaviour model according to S88.01.
and Aborted. The active states are Running, Holding, Restarting,
Stopping, and Aborting; thus, these five states contain the whole
logic of each phase.
The operation of the batch-control system, behaving in
accordance with the above-mentioned model, is as follows. The
control program on the PLC is divided into two parts: the system
part and the application part.
The system part is the so-called Phase Logic Interface (PLI);
this executes the state-machine algorithm of each phase, including
evaluating and carrying out the state transitions, and controlling
(enabling and disabling) the execution of the processing sequences
belonging to the active states.
The application part is composed of distinct blocks of code, with
each block belonging to a particular active state of a particular
phase. Since these blocks are unconnected, it follows that there
does not exist an integrated code entity for each phase—only the
PLI perceives each phase as a whole, which is as a conceptual entity.
In spite of the basic appropriateness of the phase-behaviour
model described above, there are some problems connected with
its practical use, mainly caused by the too coarse granularity
of the application-code modules. Most of us would probably
agree that among the best strategies for developing high-quality
batch-process control software is in keeping it as simple and as
understandable as possible. On the other hand, the basic building
blocks of the application code are the state sequences, which are
often rather complex, instead of being simple-to-manage linear
sequences. The main source of their complexity is that the number
of basic-code building blocks is too low, and, as a consequence,
each of these blocks implements more than one type of behaviour,
which often results in the block complexity being considerably
higher than that which is desirable.
The problem lies in the abstraction used for describing the
phases behaving as simple state machines, without the nesting
of states and with a single sequence per active state as the only
possible form of processing. To illustrate the unsuitability of this
abstraction, let us consider certain details of the ISA 88.00.01
standard and of the documentation of one of the commercial batch
tools. In the standard the complete phase-behaviour model is
not, as one would expect, given as a high-abstraction-level state
diagram; instead, it is given as a state table. In addition, there
is only a partial state diagram, covering about one-third of the
complete behaviour, given in the table. And what is the reason for
choosing the table instead of the diagram as the main notation?
Probably, the reason lies in the fact that describing the complete
phase behaviour using a simple state diagram without superstates
would result in a messy network of multi-repeated transitions,
which would seriously hinder the ease of understanding of the
behaviour model. The table, on the other hand, is crammed with
information repetition: the transition to the state Aborted appears
eight times, and the transition to the state Stopped six times, while
in a properly conceived state diagram, as presented in Fig. 1, each
transition would appear only once.
As a second example we consider the reference manual of one
of the batch tools. In this manual the state model is represented by
a diagram including superstates, whose higher expressive power
is obvious. On the other hand, in this case the diagram is not
completely correct, as again certain transitions appear more than
once: for example, the transition to the state Aborting appears
twice (once from the superstate Executing, and once from the
state Stopping). It is clear that there is a missing level in the state
hierarchy.
In order to illustrate that the inappropriate abstraction with its
repetition of information is a potential source of errors, we will
point out some weaknesses that can be found in both the standard
and the batch-tool documentation.
In the table of the standard there is a superfluous transition
from Stopped to Aborting. There is also a missing transition from
Held to Holding. This does not need to be unequivocally considered
as a deficiency, since this transition is not mandatory, although all
the batch tools that we know contain it.
In the diagram of the batch-tool documentation there are two
missing transitions: from Restarting to Holding, and from Held to
Holding. It should be pointed out that both transitions are also
mentioned in other points of the documentation.
The above-mentioned weaknesses occurred even though both
documents must have been carefully written and checked. In our
opinion, the main cause of the weaknesses is in the lack of, or in
the inconsistent use of, an appropriate phase-behaviour notation.
If the deficiencies of the phase-behaviour model and their
consequences can be observed in the above-mentioned, carefully
checked documents, then the impact of the inappropriate model
on the application software can only be worse. The problem is most
obvious in the state Running, since it assumes different behaviours
depending on the source state. For instance, the phase Dosing
has to reset the dosing counter after its entry from the Idle state,
whereas after its entry from the Restarting state the dosing counter
has to remain unchanged. Similar cases can also be found in other
states.
People are aware of these problems, and a number of solutions
have been proposed; however, most of them, unfortunately, are
inappropriate. As an illustration, let us consider once again the
documentation of the batch-control tool, where two paradigms
are mentioned for phase programming using the SFC notation:
the sequential paradigm and the state-machine paradigm. Each of
these paradigms has its benefits and shortcomings:
• the sequential paradigm is more intuitive and easier to
understand, but it has too little expressive power due to the
low level of its abstraction, which causes difficulties with more
complex behaviours, for example, exceptions;
• the state-machine paradigm is on a higher level of abstraction
and, therefore, has greater expressive power, facilitating the
managing of complex behaviour scenarios, but, on the other
hand, it is harder to understand and carries the risk of over-
complicating the application program.
 G. Godena / ISA Transactions 48 (2009) 3–9 5

The essence of the problem lies in the distribution of the

functionality between the PLI and the application program. The
entire behaviour has a given complexity level, which depends
mostly on the inherent complexity of the problem to be solved
by the application. Like the functionality, the complexity is also
distributed between the PLI and the application program. The
current situation in most batch-control tools is that the phase-
behaviour model implemented in, and executed by, the PLI is
relatively simple. This leads to an increased complexity of the
application program, which often incurs difficulties, particularly
in the case of more demanding application functionalities. The
problem is that too great a part of the complexity is left to the
particular application programmer, which in many cases – and
unpredictably – leads to difficulties in managing the complexity
of the project.
A possible solution to the problem described above would be to
increase the level of the abstraction and the resulting expressive
power of the phase-behaviour model, in order to ensure that the
application program will only consist of simple sequences. Thus,
we intend to ‘‘complicate’’ the system phase-behaviour model,
executed by the PLI and being developed only once, in order to
keep the application sequences, which have to be developed again
in each project (although we always strive to achieve as high a level
of reuse as possible), simple.
The difficulties mentioned above could be alleviated by Fig. 2. A new phase-behaviour model.
introducing a phase-behaviour model with finer granularity. The
most appropriate option seems to be a model that would differ 3.1. Phase behaviour
from the current model, mainly in terms of two important features.
The first proposed feature is the nested states (superstates, In order to attain phase-logic building blocks that are as simple
substates), whose aim is to avoid the repetition of information, as possible, it is essential to build a model where the phase building
which is one of the notoriously worst attributes of the software. blocks will be, as far as is possible, merely simple sequences,
Superstates include all the common behaviour (the activities and without any internal states or threading, and without the need to
transitions) of their substates.
memorize the entry point of the sequence (for example, whether
The second feature is the finer granularity of the activities.
we came to the Running.ENTRY sequence from the state Idle or
Instead of using only five active sequences belonging to five
from the state Held, as the actions in these two cases differ). In
transient states, as defined by ISA 88.00.01 and implemented in
compliance with this and arising from the behaviour model of
various batch tools, we consider widening the set of active states
the procedural control entities in our domain-specific modelling
and defining different types of action, such as Entry, Loop, Exit and
Always actions of the states or actions of the transitions. Thus, by language ProcGraph [4], we defined the phase-behaviour model,
introducing a phase-behaviour model of finer granularity, we will which is an extended state-machine model and is shown in
achieve a better modularization of the application software and Fig. 2. The differences in comparison with the ISA 88.00.01 phase-
possibly approach the goal of having software built just of simple behaviour model are as follows:
sequences.
1. The elimination of the state Restarting, since this state’s
As an example of a higher-level notation based on the
processing can be placed into other elements of the model.
abstraction of state machines, let us first mention the Statechart
2. The introduction of nested states (elementary states and a
notation [2], which is also one of the nine notations used in the
frame of the Unified Modelling Language (UML) [3]. Statechart number of superstates).
includes both nested states and fine granularity of the processing. 3. The introduction of a very fine granularity of the processing
On the other hand, it also has, in our opinion, some drawbacks, (action) structure:
the most important of them, in the context of batch-control (a) State sequences of actions, five different possible sequences
software, being the separation of the processing (activities) and for each state:
the state model. In fact, its actions of states and transitions do not • ENTRY actions, which are executed only once on entry to
include processing; they are just triggering the activities, which a given state (in Fig. 2 the states having ENTRY actions are
are separated from the state model, resulting in difficulties in the marked with an E),
synchronization of sequential/concurrent activities. • LOOP actions, which are executed cyclically all the time
As a second example of a higher-level notation based on a state- the phase is in a given state (in Fig. 2 the states having
machine abstraction, let us mention the domain-specific modelling LOOP actions are marked with an L),
language ProcGraph [4], where the activities are an integral part of
• EXIT actions, which are executed only once at the exit
the state model.
from a given state (in Fig. 2 the states having EXIT actions
are marked with an X ),
3. Proposed extensions of the phase-behaviour model
• ALWAYS actions, which are executed during the state
The phase states arise from the behaviour model, as it is defined activity and during transitions entering this state (in Fig. 2
by the ISA 88.00.01 standard. The model is extended by introducing the states having ALWAYS actions are marked with an A),
nested states and fine-grained processing in order to attain better • TRANSIENT actions, which are executed only once at
properties, especially with regard to the simplicity, transparency, transient states (in Fig. 2 the states having TRANSIENT
ease of understanding and reliability of the application software. actions are marked with a T );
6 G. Godena / ISA Transactions 48 (2009) 3–9
(b) Transition actions, which are basically specific ENTRY
actions of the target state; therefore, they are a part of this
state, but they are executed before the ENTRY actions of this
state (in Fig. 2 the transitions having actions are marked
with an A).
At this point it is very important to mention that the actions of
all the sequences have duration, i.e., they are not instantaneous.
This applies not only to ALWAYS actions and LOOP actions, as is
the case in the Statechart notation, but also to ENTRY, EXIT and
TRANSIENT state actions and transition actions. The advantage of
this is that there is no problem with synchronizing the individual
sequential/concurrent activities.
As a particular detail, let us mention at this point that ENTRY
and LOOP actions are not executed if at the entry to a state the
condition for termination is satisfied; however, EXIT actions are
executed in every case.
3.2. State and transition types
Our phase-behaviour model comprises different state types,
which are classified according to two criteria. According to the
processing criteria the states are divided in the following way:
• Quiescent states are states without any processing (left part of
Fig. 2).
• Active states are states that contain certain processing (right
part of Fig. 2).
According to the duration criteria the states are divided in the
following way:
• Transient states are those states that contain only one sequence,
and when it is executed, a transition to another state occurs.
Each active transient state contains one TRANSIENT sequence.
• Durative states are those states in which a phase normally
remains for a longer time. The processing of active durative
states is divided into several sequences, which can be of the
ENTRY, LOOP, EXIT and/or ALWAYS type.
Quiescent states (all of which are also durative states) are Idle,
Complete, Stopped, Aborted, Terminated and Inactive.
Active durative states are Running, Held, Executing and Operat-
ing, and active transient states are Holding, Stopping and Aborting.
Transitions are divided into active and inactive transitions.
Active transitions contain certain processing. These transitions
are:
• from Inactive to Running,
• from Running to Holding,
• from Held to Holding,
• from Held to Running.
Each active transition contains one sequence of transition
actions.
3.3. Complex transitions
Complex transitions are series of state and transition sequences
between two durative states. In other words, complex transitions
are integrated processing wholes (composed of a number of
sequences) during the execution of a phase-state machine. The
execution of a phase-state machine is performed by the Phase
Logic Interface (PLI), which checks the need for activating one of
the complex transitions that are provided for each active durative
state. When the conditions (or causes) for the occurrence of a
complex transition are met, the PLI executes a complex transition
by consecutively activating all the sequences of this complex
transition. We defined the following complex transitions:
1. The complex transition from the state Inactive to the state
Running, which occurs after the Start command has been issued
to a phase. The source of the Start command can be the PLI
starting a phase in the state Idle, or the operator starting (stand
alone, i.e., not in a recipe) a phase in the state Terminated. The
complex transition begins at the quiescent state Inactive and
terminates into the durative active state Running.
2. The complex transition from the active durative state Running
to the active durative state Held, which occurs after a Hold
command has been issued to a phase, or on the occurrence
of an exception while the phase’s state was in a guarded
region, i.e., in one of the sequences in which the occurrence of
exceptions is checked. These sequences are all the sequences
concurrent with the sequence RunningALWAYS, comprising
the three sequences of the state Running plus the sequences
of both transitions into the state Running—from Inactive and
from Held. Thus, being in a guarded region is equivalent to
the sequence RunningALWAYS being active. Note that the
application programmer’s task regarding exceptions handling
and phase holding is just to fill a certain sequence (depending
on the scope of the exception) with logical expressions, one
for each of this phase’s exceptions (failures). Based on the
current value of ANDing these logical expressions, performed in
each cycle, the PLI starts the complex transition from Running
to Held. Specifically, the logical expressions dealing with the
exceptions can be placed into the following sequences:
• the logical expressions dealing with the exceptions of
broadest scope (always active when a phase is active) are
placed into the sequence ALWAYS of the state Running,
• the logical expressions dealing with phase’s starting condi-
tions are placed into the sequence of the transition from In-
active to Running,
• the logical expressions dealing with phase’s restarting
conditions are placed into the sequence of the transition from
Held to Running,
• the expressions dealing with phase’s conditions common
to starting and the restarting transition are placed into the
ENTRY sequence of the state Running,
• the expressions dealing with exceptions of the scope limited
to the phase’s steady-state processing are placed into the
LOOP sequence of the state Running.
3. The complex transition from the state Held through the state
Holding back to the state Held, which occurs after the failure
increase of a held phase has been detected by the PLI. The
failure increase occurs on increasing an exception of the failure
level higher than the failure level that caused the last holding.
The logical expressions dealing with the phase’s higher-level
failures are placed into the LOOP sequence of the state Held, if
they were not placed into the LOOP sequence of the superstate
Executing, which is equivalent to being in LOOP sequences of
both the Running and Held states.
4. The complex transition from the active durative state Held to
the state Running, which occurs after a Restart command has
been issued to a phase in the state Held.
5. The complex transition from the state Running to the state
Complete, which occurs after the phase has successfully
completed its function.
6. The complex transition from the state Terminated to the state
Idle, which occurs after a Reset command has been issued to a
phase in one of the substates of the superstate Terminated. The
phase in the state Idle waits for the PLI’s command Start. This
complex transition does not include any active sequence.
7. The complex transition from the state Executing to the state
Stopped, which occurs after a Stop command has been issued
to a phase in any elementary (durative or transient) state that
is a substate of the superstate Executing.
8. The complex transition from the state Operating to the state
Aborted, which occurs after an Abort command has been issued
to a phase in any elementary (durative or transient) state that
is a substate of the superstate Operating.
 G. Godena / ISA Transactions 48 (2009) 3–9
3.4. Phase-logic sequences
Phase-logic sequences present a framework for the modulariza-
tion of batch-control software. Considering the phase-behaviour
model shown in Fig. 2, the theoretical number of sequences for
each phase is 54, i.e., four sequences for each durative state, and
there are 10 durative states (elementary states or superstates), one
sequence for each transient state, and there are three transient
states, and one sequence for each transition, and there are 11 tran-
sitions. It is clear that many sequences are not needed and thus
their number can be reduced significantly.
The first, trivial level of sequence reductions refers to all the
sequences of the quiescent states and the transitions between two
quiescent states. However, none of these sequences is needed in
the model and so they were all excluded. The second level of
sequence reduction is performed in the following way: all the
sequences that appear together in a complex transition, and only
in this transition, can be replaced with a single sequence. After
performing both these mentioned reductions of the behaviour
model, the phase contains 18 sequences: 14 in states and 4 in
transitions. These are the following sequences:
1. OperatingENTRY sequence, which contains the code to be
executed once, on the starting of the phase, for example,
starting a counter of the total duration of the phase.
2. OperatingLOOP sequence, which contains the code to be
executed cyclically during the whole activity of a phase
instance.
3. OperatingEXIT sequence, which contains the code to be
executed once, immediately before the transition of the phase
to the Terminated superstate (i.e., one of its substates), for
example, stopping a counter of the total duration of the phase.
4. ExecutingENTRY sequence, which contains the code to be
executed once, on the effective starting of the phase, for
example, resetting the dosing totalizer.
5. ExecutingLOOP sequence, which contains the code to be
executed cyclically during the effective execution of the
phase, which includes the states Running, Holding, Held and
EvaluatingRC, and the transitions between them, for example,
alarming.
6. ExecutingEXIT sequence, which contains the code to be
executed once, immediately before the phase exits from the
effective execution, for example, saving the value of the dosing
totalizer.
7. RunningENTRY sequence, which contains the code to be
executed once, on the entry to the state Running, regardless
of the source state, for example, starting physical equipment.
8. RunningLOOP sequence, which contains the code to be
executed cyclically during the activity of the state Running,
for example, checking the phase-completion conditions or
performing the alarming specific to the Running state.
9. RunningALWAYS sequence, which is executed cyclically and
concurrently with all three internal sequences of the state
Running (Entry, Loop, and Exit), plus the actions of the
transitions to the state Running (i.e., its specific Entry actions).
This is an important sequence, which encompasses the phase’s
guarded region, i.e., the scope of the exception checking for
this phase, and sets the corresponding logical variables (the
interfaces between the phase logic and the PLI) carrying the
information on the phase’s individual failures.
10. HoldingTRANSIENT sequence, which contains the code of the
transient state Holding, i.e., the processing needed to bring the
process to a safe state.
11. HeldLOOP sequence, which contains the code to be executed
cyclically during the activity of the state Held. This sequence
7
may contain exception checking for this phase and sets the
corresponding logical variables (the interfaces between the
phase logic and the PLI) carrying the information on the phase’s
individual failures, which is then used by the PLI to determine
the ‘‘failure increase’’. This sequence may also perform some
reduced functionality or alarming specific to the Held state.
12. HeldEXIT sequence, which contains the code to be executed
once, immediately before the phase exits the state Held.
13. StoppingTRANSIENT sequence, which contains the code of the
transient state Stopping, i.e., the processing needed to bring
the process to the state Stopped. This sequence typically has
duration, since it waits at certain points of the execution for
feedback on successfully terminated subsequences.
14. AbortingTRANSIENT sequence, which contains the code of the
transient state Aborting, i.e., the processing needed to bring the
process to the state Aborted. This sequence typically has no
duration, i.e., it does not wait for any feedback. The purpose
of this sequence is to bring the phase to a terminated state
in cases when the Stopping sequence cannot be executed
successfully due to missing feedback.
15. ACT_TR_Held-Running sequence, which contains the code to
be executed on the transition from the state Held to the state
Running.
16. ACT_TR_Running-Holding sequence, which contains the code
to be executed on the transition from the state Running to the
state Holding.
17. ACT_TR_Inactive-Running sequence, which contains the code
to be executed on the transition from the state Inactive to the
state Running.
18. ACT_TR_Held-Holding sequence, which contains the code to
be executed on the transition from the state Held to the state
Holding.
For an illustration of the processing (PLI actions) occurring
during complex transitions, let us consider, step by step, the events
during the (successful) starting of a phase, i.e., executing the
complex transition from Inactive to Running. During these two
complex transitions the PLI performs the following sequence of
actions:
1. Execution (enabling and waiting for completion) of the
sequence OperatingENTRY.
2. Enabling the sequence OperatingLOOP.
3. Execution of the sequence ExecutingENTRY.
4. Enabling the sequence ExecutingLOOP.
5. Enabling the sequence RunningALWAYS (thus activating the
phase-failure detection).
6. Execution of the sequence ACT_TR_EvaluatingSC-Running.
7. Execution of the sequence RunningENTRY.
8. Enabling the sequence RunningLOOP.
At this point there are four concurrently active sequences: Operat-
ingLOOP, ExecutingLOOP, RunningAlways, and RunningLOOP.
3.5. Further reduction of the phase-behaviour model
The described phase-behaviour model with 18 sequences
represents the maximum possible range of elements or sequences,
i.e., the minimum possible granularity of the execution of phases.
In the case that a certain programmer (organization) thinks that
the above-mentioned 18 sequences are too many, as he/she has
built a simpler phase-behaviour model (with a smaller number
of sequences), he/she should only configure the sequences that
he/she does not want to use to be inactive. The PLI ignores (i.e., does
not activate) sequences configured in this manner. Theoretically,
the programmer can also program applications by using only
one sequence, although in most cases this would look more like
‘‘hacking’’ than programming. He/she can also use exactly the
same five active sequences as the currently available batch-process
control tools use according to the ISA 88.00.01 standard.
8 G. Godena / ISA Transactions 48 (2009) 3–9
3.6. An example
As an example of modelling phase behaviour by means of the
abstraction introduced in this paper, let us consider one very
simple phase from a recent project of developing a control system
for a resin-synthesis plant in a paint factory. The process cell
consists of six production lines, each of them consisting of two
units—the reactor and the thinning tank. The phase we consider
deals with transporting the reaction water from the line’s reaction
water vessel to the process cell’s reaction-water collecting vessel.
We will call the phase EmptyRWV (Empty Reaction Water Vessel).
During the system analysis, the following requirements were
stated for the EmptyRWV phase:
The phase has two possible behaviour modes. In its first mode
the phase acts as a dominant phase: it empties the reaction-
water vessel to the target low-level value, given by a phase-recipe
parameter, and then terminates. In its second mode the phase acts as
a dependent phase: it passes between two internal states, Emptying
and NonEmptying, in order to maintain the level in the reaction-water
vessel between the upper-level and lower-level values, where the low-
level value is given by the same recipe parameter as in the first mode,
and the high-level value is given by another recipe parameter.
The phase may or may not record the amount of transported water,
depending on another recipe parameter.
The phase performs its basic function by means of two elements of
basic control: the pump P1 and the ON–OFF valve V1. In the transfer
starting (stopping) sequence there must be a delay between opening
the valve and turning on the pump (turning off the pump and closing
the valve). The failures of P1 and V1 are causes of holding of the phase.
The failure of the basic-control power supply causes an immediate
holding of the phase during the transition from NonEmptying to
Emptying, while during Emptying this failure causes holding of
the phase with a delay (we allow power-supply failures of short
duration).
The six EmptyRWV phases of the corresponding six lines are
mutually exclusive (i.e., the collecting vessel is a single-use common
resource). The arbitration is performed by means of a first-come-first-
served rule (i.e., non-pre-emptive).
The EmptyRWV phase and the Vacuuming phase on the same
reactor unit are mutually exclusive. In this case the arbitration is
performed by means of a pre-emptive priority-based policy with
Vacuuming having the higher priority. In other words, the phase
EmptyRWV is pushed into the held state in the case it was running
when the Vacuuming is started or it is started while Vacuuming is
running.
In the implementation, the requirements given above were
mapped to 10 of the above-mentioned 18 sequences, as follows:
1. Sequence OperatingENTRY:
Initialize the totalizer of the transported
amount of reaction water.
2. Sequence OperatingLOOP:
If the parameters changed, then read the new
parameter values endif.
3. Sequence ExecutingENTRY:
Activate the generating exceptions in the V1 and
P1 basic-control modules.
4. Sequence ExecutingEXIT
Deactivate the generating exceptions in the V1
and P1 basic-control modules.
5. Sequence RunningENTRY
Initialize the RunningLOOP internal state
machine to NonEmptying.
6. Sequence RunningLOOP
if NonEmptying then
if the phase instance is dominant and the level is near to
the target low-level value then terminate
elsif the level is higher than or equal to the target high-
level value or the phase instance is dominant then
if there is basic-control power-supply failure, then
set phase failure
else
wait and allocate the collecting vessel
perform NonEmptying2Emptying transition basic-control
sequence
set internal machine state to Emptying
endif
endif
else (* Emptying *)
calculate the current transferred amount
if basic-control power-supply failure of certain duration,
then set phase failure
elsif level is lower than or equal to target low level then
perform Emptying2NonEmptying transition basic-control
sequence
set internal machine state to NonEmptying
de-allocate the collecting vessel
if phase instance is dominant then terminate endif
endif
endif
7. Sequence RunningALWAYS
Compute logical expressions for phase failures
(causes of holding):
• FirstScan,
• P1 or V1 unavailability (the expression for each
is ‘‘NOT remote-auto mode OR failure’’) while
the internal state is Emptying,
• the state of the phase Vacuuming is not Inactive.
8. Sequence HoldingTRANSIENT
If Emptying, then perform Emptying2NonEmptying
transition basic-control sequence endif.
9. Sequence StoppingTRANSIENT
If Emptying, then perform Emptying2NonEmptying
transition basic-control sequence endif.
10. Sequence AbortingTRANSIENT
If Emptying, then perform Emptying2NonEmptying
transition basic-control sequence endif.
4. Discussion
We are well aware that it is unlikely to be possible to change a
standard that has been established for many years, particularly one
so well conceived and of such value as ISA 88.00.01. Nevertheless,
we decided to present our new concept to the batch-control
community, encouraged by our extremely positive experiences
with the use of the proposed phase-behaviour model in real
projects. In our experience the approach has led to a significant
shift towards the ‘‘right first time, every time’’ or ‘‘correct by
construction’’ goals in software development. This statement
stems from our recent experience in the development of a control
system for a medium-sized (200 + phases) resin-synthesis plant in
a paint factory, mentioned in the above example, where we have
come very close to the described goals in the development of the
software.
5. Conclusion
A new, batch-phase behaviour model was presented, which
has great potential to improve the quality and the complexity
management of batch-control software. The phase-behaviour
model presented may seem relatively complex, but that only
means that a part of the complexity has been moved from
the application program to the system program PLI, giving
the application programmer the opportunity to achieve better
 G. Godena / ISA Transactions 48 (2009) 3–9
modularization and through it better quality of the application
software. The proposed concept was successfully applied in a
newly developed tool, PLCbatch, for batch-process control on a PLC
platform and validated in a real industrial project.
Acknowledgement
The financial support of the Slovenian Ministry of Higher Ed-
ucation, Science and Technology (P2-0001) is gratefully acknowl-
edged.
9
References
[1] Godena G, Steiner I, Tancek J, Svetina M. Batch process automation executed on
the PLC platform. In: WBF 2008 North American conference.
[2] Harel D. Statecharts: A visual formalism for complex systems. Scientific
Computer Programming 1987;8:231–74.
[3] Booch G, Jacobson I, Rumbaugh J. The unified modelling language user guide.
New York: Addison-Wesley Publishing Company; 1999.
[4] Godena G. ProcGraph: A procedure-oriented graphical notation for process-
control software specification. Control Engineering Practice 2004;12:99–111.
[5] ISA 88.00.01-1995, Batch Control, Part 1: Models and Terminology.