Tr 1
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Tr 1 as PDF for free.
More details
- Words: 6,031
- Pages: 7
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
Article history: Received 30 May 2008 Received in revised form 6 August 2008 Accepted 12 August 2008 Available online 11 September 2008 Keywords: Batch control Batch phases Behaviour model State machine
a b s t r a c t There is a problem with managing the complexity and meeting the high-quality requirements of batchprocess control software in the environment of the modern tools for batch-process control according to the ISA 88.00.01 standard. The problem stems from the insufficient abstraction level of the phasebehaviour model consisting of only five active sequences. A solution to this problem is proposed, based 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, is described, and its use is illustrated by means of the specification of a phase from a real batch-control project. © 2008 ISA. Published by Elsevier Ltd. All rights reserved.
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: [email protected].
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,
0019-0578/$ – see front matter © 2008 ISA. Published by Elsevier Ltd. All rights reserved. doi:10.1016/j.isatra.2008.08.002
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 overcomplicating the application program.
G. Godena / ISA Transactions 48 (2009) 3–9
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 phasebehaviour 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 introducing a phase-behaviour model with finer granularity. The most appropriate option seems to be a model that would differ from the current model, mainly in terms of two important features. The first proposed feature is the nested states (superstates, substates), whose aim is to avoid the repetition of information, which is one of the notoriously worst attributes of the software. Superstates include all the common behaviour (the activities and transitions) of their substates. The second feature is the finer granularity of the activities. Instead of using only five active sequences belonging to five transient states, as defined by ISA 88.00.01 and implemented in various batch tools, we consider widening the set of active states and defining different types of action, such as Entry, Loop, Exit and Always actions of the states or actions of the transitions. Thus, by introducing a phase-behaviour model of finer granularity, we will achieve a better modularization of the application software and possibly approach the goal of having software built just of simple sequences. As an example of a higher-level notation based on the abstraction of state machines, let us first mention the Statechart notation [2], which is also one of the nine notations used in the frame of the Unified Modelling Language (UML) [3]. Statechart includes both nested states and fine granularity of the processing. On the other hand, it also has, in our opinion, some drawbacks, the most important of them, in the context of batch-control software, being the separation of the processing (activities) and the state model. In fact, its actions of states and transitions do not include processing; they are just triggering the activities, which are separated from the state model, resulting in difficulties in the synchronization of sequential/concurrent activities. As a second example of a higher-level notation based on a statemachine abstraction, let us mention the domain-specific modelling language ProcGraph [4], where the activities are an integral part of the state model. 3. Proposed extensions of the phase-behaviour model The phase states arise from the behaviour model, as it is defined by the ISA 88.00.01 standard. The model is extended by introducing nested states and fine-grained processing in order to attain better properties, especially with regard to the simplicity, transparency, ease of understanding and reliability of the application software.
5
Fig. 2. A new phase-behaviour model.
3.1. Phase behaviour In order to attain phase-logic building blocks that are as simple as possible, it is essential to build a model where the phase building blocks will be, as far as is possible, merely simple sequences, without any internal states or threading, and without the need to memorize the entry point of the sequence (for example, whether we came to the Running.ENTRY sequence from the state Idle or from the state Held, as the actions in these two cases differ). In compliance with this and arising from the behaviour model of the procedural control entities in our domain-specific modelling language ProcGraph [4], we defined the phase-behaviour model, which is an extended state-machine model and is shown in Fig. 2. The differences in comparison with the ISA 88.00.01 phasebehaviour model are as follows: 1. The elimination of the state Restarting, since this state’s processing can be placed into other elements of the model. 2. The introduction of nested states (elementary states and a number of superstates). 3. The introduction of a very fine granularity of the processing (action) structure: (a) State sequences of actions, five different possible sequences for each state: • ENTRY actions, which are executed only once on entry to a given state (in Fig. 2 the states having ENTRY actions are marked with an E), • LOOP actions, which are executed cyclically all the time the phase is in a given state (in Fig. 2 the states having LOOP actions are marked with an L), • EXIT actions, which are executed only once at the exit from a given state (in Fig. 2 the states having EXIT actions are marked with an X ), • ALWAYS actions, which are executed during the state activity and during transitions entering this state (in Fig. 2 the states having ALWAYS actions are marked with an A), • TRANSIENT actions, which are executed only once at transient states (in Fig. 2 the states having TRANSIENT 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).
2.
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 Operating, 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:
• • • •
3.
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.
4.
3.3. Complex transitions
5.
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
6.
7.
8.
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. 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 conditions are placed into the sequence of the transition from Inactive 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. 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. 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. The complex transition from the state Running to the state Complete, which occurs after the phase has successfully completed its function. 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. 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. 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 modularization 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 transitions. 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
12. 13.
14.
15.
16.
17.
18.
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. HeldEXIT sequence, which contains the code to be executed once, immediately before the phase exits the state Held. 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. 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. ACT_TR_Held-Running sequence, which contains the code to be executed on the transition from the state Held to the state Running. ACT_TR_Running-Holding sequence, which contains the code to be executed on the transition from the state Running to the state Holding. ACT_TR_Inactive-Running sequence, which contains the code to be executed on the transition from the state Inactive to the state Running. 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: OperatingLOOP, 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 reactionwater 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 lowlevel 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-firstserved 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 machine to NonEmptying. 6. Sequence RunningLOOP
internal
state
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 highlevel 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 Education, Science and Technology (P2-0001) is gratefully acknowledged.
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 processcontrol software specification. Control Engineering Practice 2004;12:99–111. [5] ISA 88.00.01-1995, Batch Control, Part 1: Models and Terminology.
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
Article history: Received 30 May 2008 Received in revised form 6 August 2008 Accepted 12 August 2008 Available online 11 September 2008 Keywords: Batch control Batch phases Behaviour model State machine
a b s t r a c t There is a problem with managing the complexity and meeting the high-quality requirements of batchprocess control software in the environment of the modern tools for batch-process control according to the ISA 88.00.01 standard. The problem stems from the insufficient abstraction level of the phasebehaviour model consisting of only five active sequences. A solution to this problem is proposed, based 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, is described, and its use is illustrated by means of the specification of a phase from a real batch-control project. © 2008 ISA. Published by Elsevier Ltd. All rights reserved.
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: [email protected].
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,
0019-0578/$ – see front matter © 2008 ISA. Published by Elsevier Ltd. All rights reserved. doi:10.1016/j.isatra.2008.08.002
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 overcomplicating the application program.
G. Godena / ISA Transactions 48 (2009) 3–9
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 phasebehaviour 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 introducing a phase-behaviour model with finer granularity. The most appropriate option seems to be a model that would differ from the current model, mainly in terms of two important features. The first proposed feature is the nested states (superstates, substates), whose aim is to avoid the repetition of information, which is one of the notoriously worst attributes of the software. Superstates include all the common behaviour (the activities and transitions) of their substates. The second feature is the finer granularity of the activities. Instead of using only five active sequences belonging to five transient states, as defined by ISA 88.00.01 and implemented in various batch tools, we consider widening the set of active states and defining different types of action, such as Entry, Loop, Exit and Always actions of the states or actions of the transitions. Thus, by introducing a phase-behaviour model of finer granularity, we will achieve a better modularization of the application software and possibly approach the goal of having software built just of simple sequences. As an example of a higher-level notation based on the abstraction of state machines, let us first mention the Statechart notation [2], which is also one of the nine notations used in the frame of the Unified Modelling Language (UML) [3]. Statechart includes both nested states and fine granularity of the processing. On the other hand, it also has, in our opinion, some drawbacks, the most important of them, in the context of batch-control software, being the separation of the processing (activities) and the state model. In fact, its actions of states and transitions do not include processing; they are just triggering the activities, which are separated from the state model, resulting in difficulties in the synchronization of sequential/concurrent activities. As a second example of a higher-level notation based on a statemachine abstraction, let us mention the domain-specific modelling language ProcGraph [4], where the activities are an integral part of the state model. 3. Proposed extensions of the phase-behaviour model The phase states arise from the behaviour model, as it is defined by the ISA 88.00.01 standard. The model is extended by introducing nested states and fine-grained processing in order to attain better properties, especially with regard to the simplicity, transparency, ease of understanding and reliability of the application software.
5
Fig. 2. A new phase-behaviour model.
3.1. Phase behaviour In order to attain phase-logic building blocks that are as simple as possible, it is essential to build a model where the phase building blocks will be, as far as is possible, merely simple sequences, without any internal states or threading, and without the need to memorize the entry point of the sequence (for example, whether we came to the Running.ENTRY sequence from the state Idle or from the state Held, as the actions in these two cases differ). In compliance with this and arising from the behaviour model of the procedural control entities in our domain-specific modelling language ProcGraph [4], we defined the phase-behaviour model, which is an extended state-machine model and is shown in Fig. 2. The differences in comparison with the ISA 88.00.01 phasebehaviour model are as follows: 1. The elimination of the state Restarting, since this state’s processing can be placed into other elements of the model. 2. The introduction of nested states (elementary states and a number of superstates). 3. The introduction of a very fine granularity of the processing (action) structure: (a) State sequences of actions, five different possible sequences for each state: • ENTRY actions, which are executed only once on entry to a given state (in Fig. 2 the states having ENTRY actions are marked with an E), • LOOP actions, which are executed cyclically all the time the phase is in a given state (in Fig. 2 the states having LOOP actions are marked with an L), • EXIT actions, which are executed only once at the exit from a given state (in Fig. 2 the states having EXIT actions are marked with an X ), • ALWAYS actions, which are executed during the state activity and during transitions entering this state (in Fig. 2 the states having ALWAYS actions are marked with an A), • TRANSIENT actions, which are executed only once at transient states (in Fig. 2 the states having TRANSIENT 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).
2.
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 Operating, 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:
• • • •
3.
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.
4.
3.3. Complex transitions
5.
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
6.
7.
8.
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. 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 conditions are placed into the sequence of the transition from Inactive 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. 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. 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. The complex transition from the state Running to the state Complete, which occurs after the phase has successfully completed its function. 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. 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. 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 modularization 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 transitions. 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
12. 13.
14.
15.
16.
17.
18.
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. HeldEXIT sequence, which contains the code to be executed once, immediately before the phase exits the state Held. 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. 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. ACT_TR_Held-Running sequence, which contains the code to be executed on the transition from the state Held to the state Running. ACT_TR_Running-Holding sequence, which contains the code to be executed on the transition from the state Running to the state Holding. ACT_TR_Inactive-Running sequence, which contains the code to be executed on the transition from the state Inactive to the state Running. 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: OperatingLOOP, 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 reactionwater 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 lowlevel 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-firstserved 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 machine to NonEmptying. 6. Sequence RunningLOOP
internal
state
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 highlevel 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 Education, Science and Technology (P2-0001) is gratefully acknowledged.
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 processcontrol software specification. Control Engineering Practice 2004;12:99–111. [5] ISA 88.00.01-1995, Batch Control, Part 1: Models and Terminology.
