Combining IEC and ISA S88 for Batch Control

Transcription

1 Preprints of the 13th IFAC Symposium on Information Control Problems in Manufacturing, Moscow, Russia, June 3-5, 2009 We-A7.1 Combining IEC and ISA S88 for Batch Control D. Ivanova*, I. Batchkova*, S. Panjaitan**, F. Wagner***, G. Frey*** * University of Chemical Technology and Metallurgy, Sofia, Bulgaria ( desy_antonova@abv.bg, idilia@uctm.edu) ** Tanjungpura University, Pontianak, Indonesia ( senopanjaitan@teknik.untan.ac.id) *** Saarland University, Saarbrücken, Germany ( {florian.wagner,georg.frey}@aut.uni-saarland.de) Abstract: Modeling of batch process control over several hierarchical layers is proposed in ISA S88, independently of a concrete implementation. IEC 61499, describes models to implement distributed control systems. This contribution proposes to combine the concepts of ISA S88 for hierarchical design with the models of IEC for distributed implementation. To formally describe and analyze the control sequences, Signal Interpreted Petri Nets are utilized. From the verified description, the implementation is derived using pre-defined IEC function blocks either by hierarchical aggregation of the blocks or by using a scheduler. The scheduler approach allows re-configuration of the sequences without altering the implemented controller. The proposed approach offers analyzable formal models, re-usable basic components, and re-configurable distributed implementation. Keywords: Batch control, IEC 61499, ANSI/ISA S88, Petri Nets. 1. INTRODUCTION In the process industry ANSI/ISA S88 (1995) and its IEC standard equivalent IEC (1997) provide domain specific models for design and control of batch production processes. The models allow the description of continuous production of finite quantities of materials (batches) from two distinct views. The first view, the one of a chemical engineer, focuses on the problem What has to be done?.the second view, the one of a control engineer, focuses on the problem How is it to be done?. S88 defines models and proposes a development process. However, it does not specify means to implement designed controllers. Here, the engineer relies on concepts from the domain of control engineering. Current state of the art for implementation of logic controllers is the technology described in IEC (2003). This standard defines a software model and programming languages for centralized control systems based on PLCs. Recently, due to the increasing demands on modularity, re-use, and reconfigurability the concept of distributed controllers covered in the IEC follow-up standard IEC (2005), becomes more and more attractive to control engineers. The methodology proposed in the following combines the S88 standard for batch process design with the IEC standard for distributed control implementation. Related works that combine the use of S88 and IEC are presented in Peltola et al. (2007) and Thramboulidis et al. (2007). Their approaches adopt Procedure Function Chart (PFC) according to S88, as specified in ANSI/ISA (2001), to describe the batch procedure. After design, a oneto-one mapping from PFC into an IEC function block network is performed. This has the drawback, that changes in the operation sequences require changes of the PFC as well as of the FB connections. To avoid this drawback, in this publication the S³ approach according to Panjaitan (2008), proposing a software architecture that deals with re-configurability by task scheduling of basic functions in IEC 61499, is added to improve the flexibility of the resulting control system. To address dependability aspects, the formal model of Signal Interpreted Petri Nets (SIPN) given in Frey (2002), is used to describe the execution schedules in a formal way for analysis of the system. The paper is organized as follows: the next section briefly introduces S88, SIPN and IEC Section 3 presents a case study that will be used to illustrate the proposed approach, presented in Section 4, and its application in Section 5. Finally, Section 6 draws some conclusions and gives an outlook on further work. 2. SHORT INTRODUCTION OF THE USED MODELLING FORMALISMS 2.1 Batch Control based on ISA S88 ISA S88 provides a guideline for design of batch control systems. It defines basic terminology and a set of descriptive models. The main idea of S88 is to separate product knowledge from the equipment used. To describe a batch process in different grades of detail from chemical and control engineering points of view, S88 proposes a set of seven models as shown in Fig

2 Table 1. Elements of PFC. Element Description Element Description Start element Name End element Name Phase Composed Element Unit Procedure Operation Fig. 1. Process and equipment view of S88 (cf. ANSI/ISA (1995)). Connection fillingof reactor Transition Synchronization Progress condition Taking the process view, design starts with a process model containing the (abstract) chemical knowledge of the process to be realized. From general recipe to control recipe this model is stepwise substantiated (i.e. adapted to the batch plant). The resulting control recipe describes which actions have to be taken in which order to reach the desired process. The control view (or equipment view) is described with the physical control model, dealing with sensor and actuator signals, and its abstractions, equipment control and control recipe. The control recipe is the meeting point of the two points of view. It is also the starting point for the proposed approach and will be explained in detail in the following. dosing ingredient A dosing ingredient B A done B done stirring cooling As all models in S88, the control recipe is built in a hierarchical way. Phases are considered as elementary steps in the control recipe and cannot be decomposed. A phase describes a basic function of the given plant such as dosing, stirring or heating. Collections of phases performed in a specified order (sequential and/or parallel) are operations. The operation filling of reactor could consist of the phases dosing ingredient A followed by dosing ingredient B while stirring and cooling. Operations are organized in unit procedures which are assigned to a specific class of plant units. A unit procedure describes a series of operations providing a high level function such as production of C utilizing the operations filling of reactor followed by performing reaction and emptying reactor. Finally, unit procedures are combined to procedures describing the interaction of plant units. The procedure produce bottled C could be described by the unit procedures production of C followed by bottling C. As text does not provide a way to unambiguously encode process knowledge, S88 introduces the semi-formal design language Procedure Function Chart (PFC). It enables the designer to graphically describe the organization of operations, unit-procedures and procedures using basic elements according to Table 1. Start and End element denote start and end of a Composed element, i.e. a procedure, unit procedure or operation. Between start and end element lower level elements (i.e. unit procedures, operations and phases) are connected by connections over transitions that hold progress conditions. Concurrent branches are embedded in start and end synchronization transitions. Fig. 2 depicts the operation filling of reactor in PFC. Fig. 2. PFC of operation filling of reactor. In contrast to factory automation systems, hierarchical modularization in batch processes cannot be done in a way that elements (or composed elements) always have disjoint access to actuators. It is a common situation that several operations or phases utilize the same actuator. In these cases it must be guaranteed that the phases are not activated simultaneously. An appropriate means to guarantee exclusive activation of the phases is formal verification. As PFC is only a semi-formal model it cannot be used for formal verification directly. However, PFC has significant similarities to the formal design language Signal Interpreted Petri Nets (SIPN). Hence, simple rules can be applied to transform PFC to SIPN. Procedures, unit procedures and operations can then be verified to guarantee certain properties. 2.2 Formal Design and Analysis with SIPN SIPN is an extension of Condition-Event nets which allow process interfacing by output signal assignments associated with places and input signal evaluation in Boolean expressions attached to transitions (cf. Frey (2002)). The conversion of PFC to an equivalent SIPN can be realized element-wise following Table 2. The table shows two different SIPN elements for start and end-element of PFC. Symbols without arcs are only used on top level SIPNs whereas in underlying SIPNs the symbols with arcs are used. (To illustrate the similarities of PFC and SIPN, Fig. 10 shows the SIPN for the PFC given in Fig. 9.) 188

3 Table 2. Equivalent elements of PFC and SIPN. PFC SIPN PFC SIPN Name Name With its formally designed syntax and semantic SIPN allows formal verification based on symbolic model checking. Transformation of SIPN models to the implementation language of the model checker NuSMV can be done automatically, as shown in Frey and Wagner (2006). The properties to be verified are derived from the definition of phases and from restrictions imposed by the plant or the process. They are specified to check the absence of contradictory phase activations (e.g. open route and close route at the same time) and of potentially dangerous situations (e.g. mixing two ingredients which should not be mixed). For the model checking process, the properties have to be expressed in a temporal logic (computational tree logic, CTL, in the case of NuSMV). For example, to check for disjoint activation of the operations A and B the CTL expression AG!(A & B) is used. 2.3 Distributed Controllers based on IEC IEC is a standard for design and implementation of distributed controllers. As its predecessor IEC 61131, it provides a framework for hardware and software aspects of controllers. It defines various models for system, device, resource, and application level. For application design IEC introduces new kinds of function blocks (FBs). An application is built by interconnecting FBs to a Function Block Network. In contrast to the function block concept of IEC 61131, the execution order of IEC FBs in a function block network is explicitly specified. This is made possible by events. An event is an instantaneous piece of information used to trigger the execution of FBs. The event concept is the basis for the main feature of IEC 61499: After designing an application it can be distributed over several physical devices without changing its semantics. Execution of an FB means processing of input data and internal data. In general, it also means generation of new output data based on algorithms, and publication of output events that trigger other FBs. Fig. 3 shows an example FB with all relevant elements according to IEC IEC distinguishes three types of FBs: Basic FB (BFB), Composite FB (CFB), and Service Interface FB (SIFB). All types provide an interface as shown in Fig. 3. They vary in the implementation of Execution Control, Algorithms and Internal Data. BFBs are elementary components providing basic functionality. The BFB provides an implementation pattern for execution control called Execution Control Chart (ECC) which is a Moore automaton. An ECC which is part of a BFB of type PID controller with the interface as shown in Fig. 3 is provided in Fig. 4. An ECC describes a set of states (ellipses) connected by conditional transitions (arcs). When a state gets activated, its associated algorithms are executed and output events are generated. Algorithm calls and generated output events are written in boxes connected to a state. In the given example ECC, starting in state Idle, the state is switched to Control when the BFB is invoked with the input event run. When the state Control is entered, the algorithm PID, calculating the new set data output value u, from the input data control error e and internal variables, is executed. Afterwards the output event e_u is generated and the output data u is updated. Finally the ECC returns to its initial state. Fig. 3. Function block (FB) of IEC Init init set_i init_o Idle run 1 Control Fig. 4. ECC of a Basic Function Block of type PID controller. BFBs are used to implement functionality abstracting from target hardware. To interface sensors or actuators hardwarespecific SIFBs are used. SIFBs do not use ECCs. Instead, it is up to the SIFB provider (usually the device manufacturer) to implement device specific execution control. Compared to BFBs and CFBs, SIFBs can show active behavior as they can generate output events without being triggered by other FBs. CFBs are used to aggregate new functionality based on already available functionality. To do so, FBs are connected to a function block network and wrapped in a dedicated new interface. CFBs allow application design in a hierarchical way reducing complexity. An alternative way for hierarchical structures is the concept of sub-applications. They differ from CFBs as they do not introduce a dedicated interface and can be seen as macro for the contained function block network. PID e_u 3. CASE STUDY: FESTO MINI PULP PROCESS To illustrate the proposed approach, the Mini Pulp Process is used. Fig. 5 depicts the P&ID of this reference example (Peltola et al. 2007). The same process has been used as a 189

4 case example in several other publications combining IEC61499 to batch processes (Dimitrova et al. 2008, Thramboulidis et al. 2007). The considered process is divided into a sequence of five unit procedures: Impregnation, Black Liquor Fill, White Liquor Fill, Cooking, and Discharge. In the following Impregnation is detailed. For Impregnation the digester is filled with Impregnation Liquor from the Impregnation Liquor Tank up to a defined level. Then it is pressurized by continuing filling while its outlet is closed until a specified pressure is reached. Finally, filling is stopped and the digester is depressurized again. controllers. As shown in Fig. 6, it is based on the stepwise transformation process from Specification to Implementation. Specification Hierarchical PFC downto phaselevel Hierarchical SIPN downto phaselevel Verification of SIPN Implementation Hierarchical FBN built using and SIFBs FB Library SIFBs LI -200 LI 200 T200 Impregnation liquor tank V201 V202 V302 V404 V204 P200 LS+300 LS-300 V402 V303 T300 Digester V301 V304 V103 V401 V104 V203 P PI300 TI300 V403 P100 FI 100 V102 T400 Black liquor tank V101 T100 White liquor tank Fig. 5. P&ID of the Festo MPP case study (UNIT according to S88) Based on the physical layout of the MPP, a list of basic functionalities phases in S88 notation can be derived. These are initiating (free or forced) and stopping flows between tanks. Table 1 lists the subset of phases that will be used to build up the unit procedure impregnation. Table 3. Phases for the Impregnation Unit Procedure. Phase Close_T200_T300 Open_T300_T200 Close_T300_T200 Description LI 400 LA+100 LI 100 V105 TI 100 Initiate flow from T200 to T300 (open valves V201, V301, V303) and start pumping (P200 on) Stop flow from T200 to T300 (close valves V201, V301, V303) and stop pumping (P200 off) Allow flow from T300 to T200 (open valve V204) Stop flow from T300 to T200 (close valve V204) 4. PROPOSED APPROACH The methodologies presented in Section 2 are now combined. The basic idea of the approach is to allow the chemical engineer to specify his knowledge using S88 while at the same time giving the control engineer the opportunity to use IEC to design and implement the needed logic Fig. 6. Development Process of the proposed approach. Based on the specification the chemical engineer designs a hierarchical PFC down to phase level. Following the rules given in Section 2 the SIPN is derived from the PFC and can be used for verification. For implementation, the hierarchical SIPN is transformed to a hierarchical function block network according to IEC which can be implemented on the target platform. Elementary components of the function block network are FBs of the phases contained in a library. Furthermore, SIFBs for the sensors and actuators are added for the communication with the process hardware. The actuator SIFBs are designed event-based since they will possibly be accessed by different phase FBs. A phase FB that wants to set or reset an actuator sends an event to the corresponding SIFB. The SIFB maintains an internal memory for the desired state of the corresponding actuator that will be updated according to the received events. To establish the FB network there are two possibilities. A one-to-one mapping of SIPN places to function blocks, and transitions to event connections can be used where synchronization transitions are implemented by means of special FBs. The one-to-one mapping can be seen as a hardwired solution which is adequate if the controller is hardly to be changed in the future. It is equivalent to the one presented for PFC in Peltola et al. (2007). To gain more flexibility, the Scheduler-Selector- Synchronizer (S³) idea (cf. Fig. 7) following Panjaitan (2008) can be used. In this concept a set of basic functions (Fi) in a system (e.g. phases, operations or unit procedures) is described by FBs. Those FBs are connected via three FBs called Scheduler, Selector, and Synchronizer. The process is described by a schedule. The scheduler selects the current tasks from the schedule and sends them to the selector. The selector activates all requested functions. The functions signal their completion to the synchronizer. The synchronizer in turn informs the scheduler to proceed. Principally, in batch systems S³ could be applied on each of the hierarchical levels. However, on higher levels it is more useful since the corresponding functions are more likely to be re-scheduled. An example could be S³ on the level of unit procedure. Here the functions are the operations and the schedule is given by the sequence described in the unit procedure. Since all defined functions (even the ones not used in the current unit procedure) could be connected to Selector and Synchronizer, a new unit procedure could be activated without changing the 190

5 FB network by sending a new schedule to the scheduler. For more details of S³, including extensions for operation mode handling, see Panjaitan (2008). F2 Schedules Scheduler Selector Synchronizer F3 Fn S³ Fig. 7. S³ architecture for flexible execution of FBs. 5. APPLICATION TO THE CASE STUDY 5.1 Building the Library For all identified phases FBs according to IEC have to be built. Fig. 8 shows the FB for the phase as an example. This FB does not contain any algorithms or data interfaces. It works as follows: Initially the ECC is in the state Wait. When the input event req arrives it switches to the state Active. With this state four output events are associated (open_v201, open_v301, open_v303, and start_p200). These are emitted from the FB and the ECC returns to Wait. req 1 Active req Wait open_v201 open_v301 open_v303 start_p200 F1 done open_v201 open_v301 open_v303 start_p200 decomposed into three operations (cf. Fig. 9 left) since those could be used as building blocks for software re-use: 1) Load_Digester (cf. Fig. 9 right): To fill the digester from the impregnation liquor tank material flow from T200 to T300 is initiated using the phase. At the same time the flow of air out of T300 (to T200) is enabled by starting the phase Open_T300_T200 to avoid pressurizing the digester at this stage. Loading is completed when the filling level is reached (condition LS+300). Afterwards the opened routes are closed again. 2) Pressurize_Digester: To pressurize the digester, more impregnation liquor is pumped in. However, now the outlet of the digester is kept close. Hence, the pressure rises. When the desired pressure is reached (PI300 > P_imp) the operation finishes by closing the opened routes. 3) Depressureize_Digester: To depressurize the digester, the route to T200 is opened until the desired pressure is reached (Pl300 < P_min) and then closed again. For the given unit procedure Impregnation, the sequential decomposition seams not to be optimal since, e.g. the route from T200 to T300 is closed at the end of Load_Digester and re-opened at the beginning of Presurize_Digester. However, this is necessary to have a stable state after each operation (see discussion above) and in addition it makes the operations re-usable in other unit procedures. Unit Procedure Impregnation Load_Digester Operation Load_Digester Open_T300_T200 LS+300 Fig. 8. FB for phase. Pressurize_Digester 5.2 Describing the Process by PFC Depressurize_Digester Close_T200_T300 Close_T300_T200 A unit procedure is decomposed into operations and these in turn are decomposed into phases. There is no strict distinction between operations and phases. However, two points from S88 can be used as guideline in the decomposition. 1) Only one operation can run in a unit at any time while it is allowed to have several phases active concurrently. 2) The boundary of an operation should be chosen in a way such that the process is stabilized at the transition from one operation to another, i.e. it can be safely interrupted. Considering the second point, the phase described above should not be considered as an operation since after its execution the pump is still running. It is not mandatory to introduce two hierarchical levels. A unit procedure can also be built from phases directly. In the Impregnation example it is also not necessary because of its simplicity. Nevertheless, in the following, Impregnation is Fig. 9. PFCs for the unit procedure Impregnation (left) and the operation Load_Digester (right). 5.3 Deriving the SIPN model and Verification The semi-formal S88 descriptions of the unit procedures and operations can be expressed as formal SIPN models to be used for verification. The transformation relies on the fact that according to the mapping of Table 2, all elements of a PFC model can be expressed as a semantically equivalent SIPN element. The SIPN in Fig. 10 is the formalized representation of the PFC depicted in Fig. 9. Using the SIPN model it is possible to check for consistent control on operation level, i.e. to guarantee that the order of phase execution fits to the specification of the plant. In this very simple example one can check whether a certain route is to be opened and closed at the same time. 191

6 Unit Procedure Impregnation Operation Load_Digester Load_Digester Open_T300_T200 Pressurize_Digester Close_T200_T300 LS+300 Close_T300_T200 Depressurize_Digester Fig. 10: Hierarchical SIPN for the unit procedure Impregnation (left) and the operation Load_Digester (right). 5.4 Mapping of SIPN to IEC The SIPN model also serves as a basis for implementation in IEC For the unit procedure Impregnation, the operations are built from phases using hard-wired connections, whereas on the next hierarchical layer the operations are connected using the S³ approach. Fig. 11 shows the FB network derived from the SIPN of the operation Load_Digester. The network is encapsulated into a sub-application according to IEC The SIFBs connecting to the sensors and actuators are not shown since they will be integrated on the unit procedure level. Fig. 11. Operation Load_Digester as a network of FBs. The implementation of the Impregnation unit in IEC using the S³ approach is shown in Fig. 12. The three subapplications describing the operations are connected using FBs for Scheduler, Selector, and Synchronizer. The sequence sent to the scheduler is: <Load_Digester, Pressurize_Digester, Depressurize_Digester> 6. CONCLUSIONS AND OUTLOOK The presented approach for batch control integrates three different formalisms IEC 61499, ISA S88, and SIPN to get re-configurable distributed batch control based on reusable software components. Using the FESTO MPP as a case study the presented concepts have been detailed. The approach was also applied to an industrial plant for distillation of sulphate turpentine, as depicted in Ivanova et al. (2008). Further work will be directed to finalization of the industrial study. In a next step the derived controller shall be connected to a simulation environment for intensive testing prior to real implementation at the plant. Fig. 12. FB network of Impregnation unit using S³. REFERENCES ANSI/ISA (1995). Batch Control Part 1: Models and Terminology. ANSI/ISA (2001). Batch Control Part 2: Data Structures and Guidelines for Languages. Dimitrova, D., Panjaitan, S., Batchkova, I. and Frey, G.(2008). IEC61499 component based approach for batch control systems. IFAC World Congress, Seoul, Korea, pp Frey, G. (2002). Design and formal Analysis of Petri Net based Logic Control Algorithms, Dissertation, Universität Kaiserslautern, Shaker-Verlag, Aachen. Frey, G. and Wagner, F. (2006). A Toolbox for the Development of Logic Controllers using Petri Nets. WODES 2006, Ann Arbor (MI), USA, pp IEC (1997). Batch control, part 1: Models and terminology. IEC (2003). 2nd Ed: Programmable Controllers Part 3: Programming languages. IEC (2005). Function blocks - Part 1: Architecture. Ivanova, D., Frey, G., and Batchkova, I. (2008). Intelligent Component Based Batch Control Using IEC61499 and ANSI/ISA S88. Proc. IEEE Int. Conf. on Intelligent Systems, Varna, Bulgaria, Vol. 1, pp Panjaitan, S. (2008). Development Process for Distributed Automation Systems based on Elementary Mechatronic Functions, Dissertation, Universität Kaiserslautern, Germany, Shaker-Verlag, Aachen. Peltola, J. P., Christensen, J. H., Sierla, S. A., and Koskinen K. O. (2007). A migration path to IEC for the batch process industry. INDIN 07, Vienna, Austria, Vol. 2, pp Thramboulidis K., Sierla, S., Papakonstantinou, N. and Koskinen, K. (2007). An IEC based approach for distributed batch process control, IEEE INDIN 07, Vienna, Austria, Vol. 1, pp