A hierarchical platform for implementing hybrid systems in process control

Control Eng. Practice, Vol. 5, No. 6, pp. 779-789, 1997 1997 Elsevier Science Ltd Printed in Great Britain 09674)661/97 $17.00 + 0.00

Pergamon PII0967-0661 (97)00062-2

A HIERARCHICAL PLATFORM FOR IMPLEMENTING HYBRID SYSTEMS IN PROCESS CONTROL H.E. Garcia Argonne National Laboratory, P 0 Box 2528, Idaho Falls, ID 83403-2528, USA ([email protected])

(ReceivedJuly 1996; infinal form March 1997) Abstract: This paper describes a development platform for the description, analysis and implementation of real-time control systems, consisting of a mixture of continuous and discrete components. Hybrid and discrete-event system techniques are used for formally defining the control and supervisory system requirements. These requirements result from functional characteristics specified for the process to be controlled. Based on the specifications, a series of control components belonging to a finite set of object classes is defined and arranged in a hierarchical architecture. The hierarchical topology is a simple tree, where any component has a single parent. Object-oriented technologies are used to implement the notion of component classes. With this formal description of process functionality, a computer software generator interprets the control specifications and produces executable control software. This software reacts to environmental responses by executing the supervisory and control actions required to achieve the desired process behavior. The paper only describes the conceptual idea of the proposed control development platform in a general manner. As an example, an application of this platform is presented for developing the control software for a production process that converts metallic sodium from nuclear reactors to sodium carbonate for safe waste disposal. Keywords: Hybrid systems, discrete-event, hierarchical systems, object-oriented application.

1. INTRODUCTION

complex capabilities, including constrained timing behavior and continuous services. Because of the tight connection to its real-time physical environment, the required software for these domains has special characteristics. In particular, the software is usually real-time and reactive, capable of sensing, through process sensors, changes to the state of its environment, and capable of reacting to aperiodic requests through process actuators. With the increasing needs of more demanding performance specifications, the task of developing a control software that is correct, robust, and flexible has become increasingly more difficult to achieve. Providing an assurance that the system will perform may not be possible as demanded if the control

To achieve specified process functionalities, digital computers are increasingly used to control physical processes. As a result, software is employed to synthesize more complex behaviors than other technologies, and its development is limited more by the designer's mental capabilities than by physical processes (Andersson, 1992). It is not the technology itself but the conceptual complexity of its application domains that causes problems. Thus, the given application domain determines the set of operations that the control system must provide. In many applications, such as process control, the particular needs of interacting with physical processes demand more 779

780

H.E. Garcia

software is to be developed by relying on non-formal, ad-hoc descriptive control and programming techniques, mostly based on practical experience. In fact, these traditional techniques are application-dependent and do not address the generality associated with an effective theoretical framework. In addition, this methodology does not fully support the reuse of previous development efforts. Many modern control implementations consist of a mixture of continuous and discrete components. These systems, composed of both continuous and discrete parts, are known as Hybrid Systems (Gollu and Varaiya, 1989; Grossman, et al., 1993). They appear in many engineering applications such as process control and manufacturing systems (e.g., (Balemi, et al., 1993; Brockett, 1993; Garcia, et al., 1995; Garcia. 1996), causing an increased interest in them from the control community, as asserted from many recent papers and books (e.g., (Andersson, 1993)). In particular, the continuous components of hybrid implementations are usually continuously varying systems (CVS) with dynamics described by sets of differential or difference equations. For process control, the continuous part generally represents a given physical process that needs to be controlled. The descriptive equations are formulated by applying physical laws applicable to the particular environment. On the other hand, the discrete components represent supervisory elements, which react to events generated by the continuous process to achieve a specified performance. Therefore, discrete parts are usually modeled with event descriptions. To take advantage of enhanced control capabilities, the discrete control components implemented via digital computers and based on computer technology should be analyzed and synthesized in a computer framework, which functions as a discrete-event system (DES). A DES is logical, causal, dynamic, and asynchronous. The evolution of these systems is better described by interactions of discrete events rather than by differential or difference equations. Consequently, CVS and DES techniques are combined into a hybrid system for decision and control. Many approaches to the modeling, analysis, and synthesis of hybrid systems have been reported in the literature (e.g., (Gollu and Varaiya, 1989; Balemi, et al., 1993; Brockett, 1993; Andersson, 1993; Li and Womham, 1993; Cao and Ho, 1990; Kumar, et al., 1993)). However, many do not relate the theory to a development framework for control software generation. In addition, detailed discussions of implementation methodologies that support the reuse of models, and well-defined topologies, are seldom provided. This paper discusses the concept and related formulations of the proposed hierarchical hybrid approach and a development platform used to describe and implement real-time supervisory and control systems. The proposed development framework is used

to model, analyze, and synthesize control softwareto govern the operation of physical processes. The main components of the platform are briefly discussed in this paper without entering into the whole implementation stage details. As a practical example, the platform is used to develop a control system to govern the operation of a production process. In particular, the paper covers the application from the control theory point of view and from qualitative causal description of the control system in objectoriented methodology. The process, needing to be controlled and under construction at Argonne National Laboratory, will convert sodium to sodium carbonate. The significance of this application is as follows. The Experimental Breeder Reactor-II (EBR-II) is a liquid metal reactor operated by Argonne National Laboratory (ANL). In 1994, it was shutdown, and defueling was started. Part of the planned decommissioning activities includes the disposal of the sodium used as the coolant for EBR-II and for the FERMI reactor. Being radioactive and chemically reactive, this sodium coolant is a mixed waste that must be processed before disposal. The plan is to convert this sodium to sodium carbonate, which is a chemically inert form suitable for near-surface burial as a low-level waste. The scheduled goal is to convert approximately 660,000 liters of sodium. This goal demands a system with high reliability, productivity and safety. In particular, the control system needs to sense many process variables (about 500 inputs) to assert plant conditions and to control process actuators (about 300 outputs) to achieve the specified plant behavior. The control task is complex enough to demonstrate the benefits of using the proposed framework. In particular, a control development platform is being developed based on the ideas presented here. This tool will act as an automatic code generator for producing real-time control software. Given the desired behavior for the process to be controlled, a control engineer would first identify the set of control tasks needing to be executed. Then, a set of system components belonging to a finite set of classes provided by the tool are selected and arranged in the proposed hierarchy. The particular characterization of each element is then specified by the control engineer. This characterization often takes the form of discrete-event representations, such as state-charts, or difference equations, such as that resulting from PID schemes. After this structuring is done, the control tool reads, validates, and automatically generates all the control software required to achieve the given control specifications. The paper is organized in seven sections, including the Introduction, as follows. Section 2 presents the general architecture of the proposed hierarchical hybrid control scheme, and Section 3 discusses the specifics of each system component. The framework used for modeling each control component is then

Implementing Hybrid Systems in Process Control provided in Section 4. Section 5 describes the physical process selected to demonstrate the proposed development platform. In Section 6, both the physical and logical control architectures developed for the given process control application are illustrated. Conclusions and future research are then given in Section 7. 2. HIERARCHICAL HYBRID CONTROL ARCHITECTURE

781

way control specifications are entered to the system, the tasks of verifying, validating, and proving the correctness (including quantitative timing correctness) of the logic entered are eased. In this respect, several treatments concerning verification, validation, and correctness proof practices have appeared in the software engineering literature (e.g., (Leveson, 1991; Parnas, et al., 1990; Rushby and von Henke 1993)). This paper does not address these issues, but provides a discussion on the proposed framework, as follows.

2.1 Motivation

2.2 Hierarchical arrangement

Decision-making and the control of complex dynamic processes, such as those in process control, possess certain unique features. These processes are generally composed of a large set of distributed and interrelated sub-processes and controlled by physically distributed actuators. They may be characterized by wide conditions, with the possibility of experiencing predictable or unpredictable disturbances. In addition, actions taken in some subsystems may significantly affect other remote parts of the plant. This usually requires some degree of coordination among disparate controllers. Therefore, when devising control systems for complex processes, the implementation should have a reactive and adaptive behavior to act upon operational changes properly. In addition, it should be capable of supervising and coordinating the operation of control modules to achieve system-wide objectives. Similarly, the control architecture should be such that a wide range of domain applications can be tackled with it, and the tasks of specifying, synthesizing, maintaining, and upgrading can be simplified. The intention is to promote reuse as a way to increase robustness.

The proposed system is hierarchically structured into five layers, namely, process I/O, control, supervision, coordination, and user-interface layers, as seen in Fig. 1. These layers are in part ordered according to the principle of increasing intelligence with decreasing precision (Sadiris, 1989). The process 1/0 layer refers 'to the process dynamics, with this layer in direct contact with the physical process. The tasks of sensing and acting on the plant are done here by entities called sensors and actuators, respectively. At the control layer, the tasks of organizing and generating the control actions to be executed on the plant are performed. Entities such as low-level and high-level controllers reside here. While low-level controllers are the actual objects responsible for generating the control outputs, high-level controllers direct commands to and assign control patterns to lowlevel controllers to select the control policies to be used on the plant. At the supervisory layer, the task of governing and supervising the operation of the control layer is performed. In particular, this layer defines and prioritizes the control activities that the control layer must accomplish on each subsystem to achieve requested system-wide goals. The entities responsible for executing these tasks are called supervisors and sub-supervisors. To attain the specified control requirements, the task of coordinating the supervisory actions is performed at the coordination layer. The entities responsible for executing these tasks are called coordinators. By overseeing the plant performance, this layer dynamically selects the activities to be

The control-generating platform resulting from the hybrid approach proposed in this paper attempts to address the system needs mentioned above. In particular, this platform provides a control engineer with a finite set of distinct control element classes, with well-defined characteristics and already validated code implementations. It is assumed that this set is sufficient and complete, in the sense that any control requirement can be translated into instantiations of control elements belonging to the classes provided. Thus, the cardinality and characteristic of this set result in a control development framework that is flexible to accommodate many practical control problems. The control elements resulting from class instantiations are then arranged and connected by the control engineer according to the proposed hierarchy. After logically validating the entered element descriptions, the control-generating platform translates the specified arrangement of control elements into executable software. By creating control elements from instantiations of a finite set of classes, reuse is promoted and code robustness is improved, assuming that the code-translation task executes correctly. In addition, by enforcing homogeneity in the

..orO .... '°'r'°°

l

=odU=:

coor.,o--o Layer

[

Layer

| Sub-supervlsors

Control Layer

~

_C ontr__o I l__er_ss

[

Low-level

_ i~iii?

.....

i11- ~ - ? ~

Coordinators

High-level

Process Layer

[. X/O

Fig. 1. Control hierarchy.

C°'!tr°!~?';_!......

l

782

H.E. Garcia

executed, and assigns strategy patterns to the supervisory layer to ensure that the process behaves in a desirable manner. The final layer is the user-interface layer with which the operator communicates. Schedulers reside here providing visualization of process operation and the capability to accept inputs from users.

achieved for the task. The requested activity set is first checked by the control system to verify that this set is consistent. That is, all requested activities should be able to be executed concurrently without violating safety and performance constraints.

2.3 System topology

3.1 Motivation

The proposed platform constrains the control engineer to arrange control elements in the hierarchical configuration of a simple tree, as illustrated in Fig. 2. In this kind of arrangement, any system component has a single dominant object or parent (excluding the root, which has no parent) with none or several subordinate objects or children. The flow of information is well defined in this topology, where communication is only possible among directly adjacent (above/below) objects. Consequently, there is no direct lateral information flow. Specifically, between two objects, information leaving an object would first go to their common dominant object before reaching the other object. Notice that there always exists a common dominant component between any two objects in this treelike hierarchy. The aim of these information-flow design criteria is to increase the robustness of the final code.

As indicated, in the proposed development framework, the control engineer must arrange control components in the manner defined by the given topology. These objects must execute all the tasks of process I/O, control, supervision, coordination and user-interface demanded by the particular application. Based on the tasks that need to be executed, classes of objects can be identified, with each class tailored for performing a given task. A class is, then, a user-defined type of object. A practical importance of the key concept of classes is that there is now an instrument that allows the grouping of system components that have similar functionality. By coding classes instead of objects, and creating objects as particular instantiations of classes, reuse of code is promoted. This is particularly true when the cardinality of the set of classes defined is less than the cardinality of the set of objects required. Therefore, a general-purpose development software should provide a finite but reasonably small set of object classes. However, this set must be sufficient for specifying and implementing all control tasks. The control tool mentioned here is being developed under these guidelines. To promote reuse, object-oriented technology is employed in this research. Object-oriented programming has evolved to support the independent development and reuse of software components. In general, this technology also helps in the software development of real-time systems in a way that naturally maps to the inherent nature of the system being built, while providing other benefits such as increased extensibility and robustness.

2.4 System utilization A final user or operator interacts with the resulting control software by entering control commands, or by specifying the set of required (concurrent) activities that should be performed by the system. This set is defined by the control engineer from the identified control requirements. In particular, an activity is a task in a given mode. A task specifies a given operation, while a mode specifies the final operational state wanted to be

1CZ" Supervisors

Sub-Jupcrvisors

CoulTolk'r*

3.2 Object classes

Supcrviwrs

SIb-lupcrvhmrs

!22 i high-level _ il

Hi|lI-Lcv©l co.,..,,.,

] (HiIIa-L©vcl -

l co..o,.~, / l c.''*'''

Coml~rollm } I Coltmllcrs

[-"! .-Lcv.il co.,,.,.,, Contmllms

Y A- Y I A V ; I lVll s°o,o.]r. . . . . . s..,..1 .. q s "f° " . . . .

s,.,.,

Fig. 2. Control architecture.

3. COMPONENT CLASSES

^,.,,0.

As mentioned in Section 2, any system component belongs to a given class of a defined finite set of classes. That is, the control engineer does not remake classes, but creates a control element by instantiating a given particular class. In other words, all classes are assumed to have already been defined, created, and validated during the development of the control platform proposed here. Specifically, eight classes of objects are provided by the proposed system, namely: 1) Sensors, 2)Actuators, 3) Low-level Controllers, 4) High-level Controllers, 5) Sub-supervisors, 6) Supervisors, 7) Coordinators, and 8) Schedulers. A brief discussion of each class is provided next. Sensors/actuators. A sensor (resp. an actuator) object

Implementing Hybrid Systems in Process Control is declared and introduced in the hierarchical control system being devised by the control engineer whenever a process variable (resp. a control output) needs to be acquired (resp. sent) by the control system from (resp. to) the plant. Routines for data conditioning and diagnosis can be incorporated in these objects. Low-level controllers. A low-level control object is declared and introduced in the hierarchical control system being devised by the control engineer whenever a given control policy or policies need to be implemented to manipulate process variables. A lowlevel controller receives control patterns from a highlevel controller to determine the control policies to be applied on the plant. In general, low-level controllers have limited local actions. The cbntrol algorithms may be devised from different control designs such as on-off control, PID compensation, fuzzy control, and robust synthesis schemes. High-level controllers. A high-level control object is declared and introduced in the hierarchical control system being devised by the control engineer to govern, supervise, and organize the operation of a set of subordinate controllers. Consequently, the higher the object is in the hierarchy, their range of responsibilities and scope of actions increases. Notice that a high-level controller may have another high-level controller as a child or as a parent. State automata, data-flow diagrams, or state charts may be used to describe their dynamic behavior and functionality, respectively. Supervisors / sub-supervisors. A supervisor object is declared and introduced in the hierarchical control system being devised by the control engineer whenever the plant has been divided into subsystems, and local supervision of the given subsystems is required. By decomposing into subsystems, the scope of each domain to be tackled at once is reduced. This eases the tasks of control-system formulation, implementation, verification and upgrading. It may not only reduce the time for completion by promoting parallel implementation, but may also increase flexibility by using incremental development. Specifically, supervisors can be defined based on functional and physical partitioning. In either case, each supervisor has a defined range of possible actions and responsibilities for configuring its underlying control scheme so that every requested activity is supported. Depending upon the underlying complexity of the supervisory task, a supervisor may rely on subordinate supervisors or sub-supervisors to accomplish the assigned activities. It is important to address here that supervisors could have also been defined in relation to the completion of activities, with only one supervisor being responsible for each activity. Because of the possibility of concurrent execution of activities, this approach could have resulted in a controller receiving commands from several supervisors whenever its end-

783

effectors were involved in executing more than one activity. To resolve these situations, it would have been necessary to give controllers decision-making capabilities. This would have violated the principle of decreasing intelligence while increasing precision when moving down in the proposed hierarchy, and would potentially have complicated the final implementation. Partitioning the supervisors based on underlying physical boundaries ensures that only one supervisor can govern the operation of any given controller under its domain, and places the decisionmaking functions in higher-level objects. Coordinators. A coordinator object is declared and introduced in the hierarchical control system being devised by the control engineer whenever coordination among subordinate supervisors, resulting from system decomposition, is required. In fact, decomposition into subsystems is not without cost. A coordinating agent needs to be incorporated to integrate dependent processes into system-wide goals. In particular, a coordinator directs and coordinates its subordinate supervisors in a way that completes the set of commanded activities. Schedulers. A scheduler object is declared and introduced in the hierarchical control system being devised by the control engineer to collect requests from the user, and then to validate and communicate them to the control objects. In particular, the final user or operator interacts with a scheduler to define the set of concurrent activities to be executed anytime, or to impose operational commands on the underlying control system. 4. MODELING FRAMEWORK Different model paradigms are used to describe processes in different layers. In particular, processes with either time-driven or event-driven dynamics are present in the proposed hybrid configuration. To describe and implement time-driven processes, such as low-level controllers, ordinary differential or difference equations are used. On the other hand, to describe and implement event-driven processes, such as high-level controllers, discrete-event and hybrid system techniques are employed here. In this paper, only the hybrid paradigm is discussed as follows. 4.1. Functional model Fig. 3 shows a block diagram of a hybrid object. As seen, an object communicates to other objects through communication channels. Two types of channels are identified: condition channels and event channels. Condition channels transport piecewise constant signals representing state conditions. For example, logical states of equipment, current nodes of objects, and quantified values of process variables may be sent

784

H.E. Garcia

ConditionI

Event

Channel; ~lChannel

High-level Interface

Hybrid Object Condition~ _ 1Event Channel ~t

Channel

subordinate objects. Therefore, in each object, there is a set of execute-up and execute-down operations that are performed when the object is invoked during the executing-up and executing-down passes, respectively. Assuming regularity of measurement intervals, it must be ensured that the time needed to execute both passes is less than the defined sampling period, to guarantee proper system response. The current implementation runs on a real-time operating system that monitors for timing violations.

Low-level

Interface

Fig 3. Hybrid object. through this channel. On the other hand, event channels transport discrete (delta) signals representing events. Events may be either commands or environmental responses, with commands traveling from top to bottom in the control hierarchy, and environmental responses traveling in the reverse direction. For example, user or system commands, such as directives to abort a task, and environmental responses, such as temperatures reaching given values, may be sent through this channel. In general, an event channel can transfer events in either direction. This results in an event~state feedback control scheme (Garcia, et al., 1995). However, as seen in Fig. 3, only commands are sent through event channels and communicated among objects in the current implementation. This strategy results in a state feedback arrangement. Usually, state feedback schemes are easier to implement, and do not lose generality, because any event/state scheme can always be translated into an equivalent state feedback configuration, as indicated in (Garcia and Ray, 1996). In particular, the implementation of the proposed control platform software was simplified by letting each object generate its own environmental response internally, based on received state feedback. That is, a parent, seeing the current states of its children, combines subordinate state information to generate an "internally generated" environmental response. An environmental response generated in this way is then used to trigger possible changes in the given object's internal state. Therefore, this state-based internalevent-generation approach is effectively equivalent to sending environmental response through event channels. When running the control software at each predefined sampling interval, the control hierarchy is executed in two passes. During the executing-up pass, from the bottom to the top of the hierarchy, each object is updated with the current information about its subordinate objects. Consequently, the state of the tree is refreshed with the new state of the plant at the end of the first pass. During the executing-down pass, fi'om the top to the bottom of the hierarchy, commands computed by a dominant object are sent down to its

With respect to their dynamic nature, hybrid objects generally function as Markov processes, having eventdriven dynamics. Therefore, the particular operational condition of an object can be characterized by its current state. However, to increase the modeling power of the proposed framework, additional internal variables, such as timers and process state variables, are incorporated in the model. The execution of the executing-up and executing-down passes generates events (responses during executing up and commands during executing down) that may change the state of a given object. This is an implementation detail, transparent during the control design, that will not be further expanded here. When using the proposed platform, the control engineer needs only to define the information that each object communicates and receives from other objects, and how it responds to the received information. This is indicated when specifying the static components of the given object, as discussed next. 4.2 Hybrid dynamic model

A hybrid mechanism (Garcia, et al., 1995) is here defined as a tuple: M:(F, tlJ)

(1)

where F and ~ are the static and the dynamic components of M, respectively. The static component r is defined over the following eight-tuple F=(N, V, T, Y., n,, x,, T,)

(2)

where N denotes the set of nodes that comprises a node diagram. For example, nodes might be OFF, VALVE_OPEN, and MAINTAIN. V denotes the set of state variables; that is, the plant input and output variables related with the particular object. For example, state variables might be temperature, pressure, and heater on/off flags. T denotes the set of timers. Timers are needed to verify the system is working correctly or to time a particular control operation; for example, timers might be watchdog timers, alarm timers, and heater sit-at-temperature timers. ~ denotes the set of possible events. An event is the instrument by which node changes may occur in

Implementing Hybrid Systems in Process Control an object. An event can come from a parent or a child, or it can be internally generated by meeting operational conditions. This event generation results in two types of events, namely, internally generated or externally received. For example, internally generated events might be temperatures going over a limit, crossing a threshold or timer completion, while externally received events might be commands acquired from parent objects. P denotes a collection of state predicates. Predicates are the Boolean conditional expressions used in if-then type statements evaluated to decide whether the terminating conditions of nodes are met. For example, predicates might be "temperature > 150 degrees", "timer == 0", and "device == manual". The constant no defines the initial node when the software first starts, xo defines the initial state variable values of the input variables and the initial settings for the plant output variables in the initial node. For example, initial outputs might be the faiisafe conditions for the plant output variables. Finally, T o defines the initial timer values set on entry into the initial node. For example, if the initial node is SHUTDOWN the timers may be set to zero. On the other hand, the dynamic component • is defined over the following eight tuple:

= (d(.), act(°), acv(o), acu(.), f(.), g(o), in(°), out(°)) (3) where d(°) denotes the possible events function, act(°) denotes the timing constraint function, acv(o) denotes the state constraint function, acu(o) denotes the device constraint function, f(°) denotes the state transition function, g(o) denotes the internal evolution function, in(°) denotes the input function, and out(°) denotes the output function. Specifically, d(°) specifies which events can legally occur at each node of the given object. It is primarily used as a debugging or coding error-detection tool. That is, if an event is received or generated that was not specified for the current node, this will indicate an implementation error. The function act(°) verifies that the timing constraint for a node is satisfied. It generates internal event responses related to timing for the given object. In this way, quantitative timing constraints related to the operation of an object can be incorporated. For example, an event can be generated on timer completion. It is assumed that this function also updates the set of defined timers. The acv(o) function verifies that state constraints for the node are satisfied. It generates internal event responses based on conditions on the plant input/output variables for the given object. For example, an event might be generated when a temperature exceeds a certain value. The function acu(°) verifies that the device operational constraints for the node are satisfied. It generates internal event responses related to proper operational settings for the given object. For example, an "unable" event might be generated when a subordinate device of

785

the given object is in manual state. The function f(°) indicates which node to jump to next, based on a received event. In addition, f(o) will set the state variables, timers, and any other parameters, in general, to the initial values specified for entry into the new node. The function g(o) says how the state variables should evolve for each given node. This function is primarily used for detecting process abnormalities, including sensor and actuator malfunctions and human errors. The function in(°) is used to update the given object's data area. In particular, an object executes the input function to receive data from subordinate objects. Therefore, in(°) is only invoked during the executing-up pass. Finally, the function out(°) is used to send data to the object's children. In particular, an object executes the output function to send data to subordinate objects. Therefore, out(°) is only invoked during the executing-down pass. In summary, each object verifies that its set of current activities is consistent, with their progress following this hybrid model. An activity being in a given node precisely defines the operational conditions and possible responses that could be observed to occur in case of operational changes. 4.3 Control approach As indicated, an object may change its current state when receiving an event. It is the state transition function f(-) that defines how changes in states occur in a given object due to received or internally generated events. The dynamic of an object M is then modeled by f(.) as follows; x[x+l] = f(x[k], e[k+l])

(4)

where x[k] ~ N is the state of M after the kth event e[k] e Y. acts on M. Recall that e[k+l] e d(xIk]).

(5)

To control M, certain events in the system are enabled or disabled by the choice of control inputs, thus governing, whenever possible, transitions among the states of M. Based on their controllability, the set ~ is partitioned into two sets, ~l and ~u. While the subset ~ represents the set of controllable events, which can be prevented from occurring, )2u represents the set of uncontrollable events that cannot be prevented from occurring, with ~u = ~ - [I~. While controllable events generally represent commands, uncontrollable events represent environmental responses. It is through ~ that a given object M admits external control. The control task is then to generate controllable events based on the current objects states so that a given functionality is achieved. In particular, an object may first experience state transitions due to state changes of its subordinate objects resulting from environmental changes. Then, based on the object state, the object's

786

H.E. Garcia

parent consequently generates commands to place the object in a state appropriate to the current operational needs. It is the task of the control engineer to specify the set of states and events defined for an object, and how these events affect state transitions. This is conveniently specified by state chart diagrams. 5. CONTROLLED PROCESS To illustrate, demonstrate, and evaluate the use of the proposed development framework, a production process currently being built at Argonne National Laboratory was selected for conducting the control experiments. In particular, the plant is the chemical conversion process that occurs in the Sodium Process Facility (SPF) at ANL-West, including the Carbonate Addition. The conversion will be performed in two steps. The first step, which converts sodium to sodium hydroxide, will be conducted in the SPF Sodium Hydroxide Process. In particular, this process will transfer sodium stored onsite to a reaction vessel, combine it with water in a caustic medium to produce sodium hydroxide, and deliver the caustic product to the following step. Specifically, sodium is first moved from two different sources to the Sodium Storage Tank, as seen in Fig. 4. A source of sodium comes from about 1400 barrels, each containing 208 liters of sodium used with the FERMI reactor. A second source is the Secondary Sodium Storage Tank, containing sodium used with the EBR-II reactor. Sodium is then moved from Sodium Storage Tank to the Day Tanks for reaction. The sodium in a Day Tank is then transferred to the Reaction Vessel, where it is combined with water in the

~ SecondarySodium StorageTank I L l Drainina Barrel ~ Liqum ,. || SolidSodium

presence of a caustic solution to form sodium hydroxide. The resulting caustic product is moved from the Reaction Vessel to the Caustic Cooling Tank. Caustic from the Caustic Cooling Tank is pumped out and used in the next conversion process. This second step, which converts sodium hydroxide to sodium carbonate, will be done in the SPF Sodium Carbonate Process. As seen in Fig. 5, the sodium hydroxide is pumped from the Caustic Cooling Tank (in the Sodium Hydroxide Process) and fed to a horizontal thin-film evaporator blanketed with a carbon dioxide atmosphere. Here, the caustic solution reacts with the carbon dioxide to form sodium carbonate. The reaction is exothermic and produces most of the heat necessary to evaporate the excess water, leaving a dry sodium carbonate product. The evaporated water is condensed and drained to a water-holding tank, and the carbonate product is discharged into drums for landfill disposal. 6. CONTROL IMPLEMENTATION: EXAMPLE

6.1 Physical control architecture

In this implementation, the SPF system will be monitored, controlled, and supervised by a computer system. The sense, control, and operator interface functions will be incorporated into a distributed control system consisting of a control and two (I/O) front-end computers as seen in Fig. 6. All of the process sensor and actuator wiring comes into the I/O front-end (STD Bus-based) computers via terminal strips connected to the I/O boards. The front-end computers communicate with the control computer via serial links. The control computer drives a graphic terminal used to monitor and control the SPF systems.

From Caustic

LiquidC02

StorageTank ~ Sodium

Wat¢ , System ' / DayTnnks S ySodsuimt e m I ~[ ~ Sist [ , .... , lqitroSe,f ; lStem ~ Reaction ~ Water l Vessel Steam

[

Nitrogen

I

~ [

w,ter

v Off-Gas System

*

J cau;tc ,t,,yoo, I ^.ospho..1 coo,.g T.k System I Tothe"

Carbonate Process

[- Caus,ie

/ StorageTank

Fig. 4. Sodium hydroxide process.

I

Caustic

i Carbondioxide

Steam Thin-Film Evaporator

w,tev

/ Caustic Water | Holding Tank lj

Process-

i Sodium

Carbonate

i Off-Gas 1 Water

PackagingandHandling Off-Gasl ~Water-I t System] i Holdmg[ _S_Yi_c_m_.......

I Waste

I Drum! Fig. 5. Sodium carbonate process.

J

Implementing Hybrid Systems in Process Control

Control Computer

Compu~rs I/0 Prontend

Maintenance Terminal

lo :--I

Fig. 6. SPF computer control system. These three computers contain all the software needed to interact with the operator, read the process sensors, condition data, drive process actuators, control the SPF through its various operating modes, and display process graphics. This paper is concerned with the development of the control task using the proposed control development platform. 6.2 Logical control architecture As discussed previously, the task of developing a control system can be eased if the principle of divideand-conquer is used. In this application, the SPF system was divided into subsystems. Then, instantiations of the class supervisor (defined in the control platform) were defined to create supervisory elements having a correlation with the physical subdivision of the described plant. For example, based on Figs 4 and 5, instances of implemented supervisors include the DrainBarrel Supervisor, SodiumStorage Supervisor, DayTanks Supervisor, Reaction Supervisor, CausticStorage Supervisor, Carbonate Supervisor and Support Supervisor. The DrainBarrel Supervisor, for example, is responsible for ensuring that its assigned end-effectors, i.e., sensors and actuators, operate properly in support of the activities it may be involved in anytime. In cases where a subsystem was too complex to be analyzed and synthesized as a whole, the sub-process was further divided, and corresponding sub-supervisors were created. For example, the DayTank Supervisor relies on two sub-supervisors, one defined for each of the existing two day tanks in the plant. To integrate the operations of these supervisors, a single coordinator element was created from the coordinator class and included in the design. Similarly, to provide interaction with an operator, a scheduler object was also introduced. Following the guidelines of the proposed developing platform, these objects were

787

arranged as partially illustrated in Fig. 7. The objects constituting the control and process I/O layers are not shown due to their large number. To illustrate a control layer arrangement, Fig. 8 show a sub-tree that resulted from controlling the temperature in a container. As seen, the sub-tree is composed of a high-level "heat" controller and three low-level "heat" controllers. During the executing-up pass, the lowlevel heat controllers read plant conditions that may internally generate environmental events or responses. These responses can cause node changes. The highlevel heat controller then reads the states of its subordinates, which may trigger state changes too. Subsequently, during the executing-down pass, the high-level controller receives commands from its parent (not shown) that may cause a node shift. Based on its current state and those of its children, the highlevel controller sends commands to each of them. These commands may respectively trigger node changes. Based on their current state and selected control algorithms, the low-level controllers finally send control outputs to the plant. The advantages of object-oriented technology can be seen in Figs 7 and 8. While there are 13 objects declared in these figures, they are all instantiations of only 5 classes. Code for five classes instead of thirteen elements appears in the software, making the code more compact, easier to verify and maintain. To illustrate how objects were specified by the control engineer, Figs 9 and 10 are provided. These figures graphically describe a particular high-level and lowlevel heat controller, respectively, where the set of nodes N, state variables V, timers T, events ~, and predicates P is given for each case. The functions that constitute the dynamic component of objects are implicitly given in the state diagrams, as well. Recall that commands, 52, are received while responses, ~u, are internally generated when evaluating given predicates Pi at given constraint functions (i.e., act(.), acv(o), and acu(o) ). 6.3 Control activities As indicated, a user operator interacts with the generated control software by directing commands or

S~u~

Fig. 7. SPF (high-layers).

788

H.E. Garcia

C•ff••.

Higb.k.v©lH~CoWaoller {SodnStompTuk)

~.~lHu~nUu (TopH¢~)

to,~IH~C~

I-COO~_I

t,ow.~cl~'utcomu~

(gkklkHc~tn')

(Bot~Ik~r) l

t-~ld ~

c-dT

Fig.8. A tank temperature control. specifying operative activities. For SPF, several commands and activities were defined. Instances of commands include: complete, suspend, abort, and retry. For example, the command 'suspend' allows an operator temporarily to halt operations related to a particular activity. Instances of activities include DrainSodium, ReactSodium, StoreCaustic, and MakeCarbonate. For example, as seen in Fig. 4, the task 'DrainSodium' defines all the operations required for extracting the sodium contained in several drums (FERMI Drums) and transferring it to the Sodium Storage Tank. As indicated earlier, modes are needed to define the desirable final operational conditions or marked state of a given task. Examples of modes are Shutdown, ColdStandby, HotStandby and Run. For instance, a task in mode 'CoidStandby' defines all the setup conditions that must be met to maintain the tanks associated with the given activity at a specified operating temperature. Similarly, in 'HotStandby', not only the associated tanks but also valves, pumps and piping are taken to proper operational conditions. As discussed in Section 2, a task (e.g., StoreCaustic), in a mode (e.g., HotStandby), defines an activity (e.g., StoreCaustic.HotStandby). An operator then interfaces with the control software by requesting a given task (e.g., ReactSodium) to be placed in a given mode (e.g., Shutdown). The control software then generates all the required directives to accomplish the requested activity ReactSodium.Shutdown. An activity may require the participation of one or more supervisory objects to be executed. The set of supervisors involved in supporting a given activity is called the activity supervisors set. Each of these supervisors is responsible for ensuring that its endeffectors are operated in support of the requested activity. For example, to execute the activity MakeCarbonate.Run, the CausticStorage, the Carbonate and the Support supervisors are needed and operationally integrated; however, the DayTanks supervisor is not involved in this activity. To assert the current operational phase or condition of the given activity, status is introduced. Possible activitystatuses include Idle, Setting, Ready, Working, Suspended and Down. For instance, an activity in a 'Suspended' status will indicate that it has been halted momentarily to resolve an abnormality in the system.

: { oft;uuab,htl,ha, hi3,ant,c001} V: {Up-t0p,Up-mid,tmp-b0t} ~c: {e.0ff,c-h~c.~ } T:{limerl} ~, ={r-wb,r.rdl,r-d2,r.rd3,r-ood,r.c01d}

P={(Pl:tmp-top >~p-mid+kl),...,{Pj:tincrI >ld),,,,} Fig. 9. A high-level tank temperature controller. The status of each activity is used by higher modules to coordinate the operation of their subordinate objects. For example, to compute the status of a given activity, the coordinator looks at the statuses reported by each of its supervisors involved in supporting the given activity. Based on the reported statuses (at the supervisory level) and given guidelines, the coordinator assigns the status for the activity as seen at its level. For instance, assume that a given activity involves three supervisors. Two supervisors indicate to their coordinator that the commanded activity is Ready to be executed, while the third supervisor reports the activity is still at Setting in its domain. The coordinator thus reports to the scheduler that the activity is still in a Setting status; the activity will be declared Ready to progress when all supervisors indicate so. This activity status (at the coordinator level) is then used to resolve operational inquires. Similarly, if a supervisor relies on a set of subordinated sub-supervisors to support a commanded activity, it asserts the activity status by gathering the reports communicated by its subordinates. This procedure extends all the way to the control level, where no further division of operation occurs. Controllers, which are the only objects in direct

0off .... :-0n

N = { noheat, heat }

V = {temp-mid }

Yc = { c-off, c-on }

T= { }

~e = { r-htemp } P = { (PI: temp-mid > kmax) } Fig. 10. A low-level heater controller.

Implementing Hybrid Systems in Process Control contact with the physical system, finally retrieve the information required to assert activity statuses at higher levels. 7. CONCLUSIONS To ease the implementation and verification of the correctness of control software, a development platform was described. Object-oriented technologies are used. Object-oriented concepts such as inheritance and class abstraction can be beneficially employed in the design of real-time systems to enhance reusability, understandability and software quality. In addition, formal modeling approaches are used to characterize object behavior clearly. The limited and similar responsibility attached to each object, and the formal modeling strategy characterizing their behaviors are intended to increase the overall robustness of the implemented software. Using the proposed control platform, the control engineer, in need of a real-time software to control a given process, concentrates his efforts on defining the control behaviors that he expects to be achieved. After the control specifications have been entered in the control framework by instantiating control classes, and resulting elements arranged in the described architecture, the proposed control development system will automatically generate an object-oriented code that will enforce the desired operational specifications. The paper illustrates the use of the proposed platform when devising the control software for a chemical conversion process existing at the Sodium Process Facility (SPF) of Argonne National Laboratory. Specifically, the resulting control system is hybrid in nature, consisting of continuous time processes controlled by discrete-event processes running on realtime computers. In principle, the integration of realtime continuous and discrete-event components into a control system can be done in an ad hoc manner. However, feasible operational states, changes and conditions may be far more difficult to categorize, correctly interpret, and respond to, unless a formal approach is used. Control and software engineering methods are used in the design and implementation of the SPF control system to improve the tasks of verifying software correctness, debugging, updating, and maintenance. Detailed discussion of the formulation and implementation on the proposed software generator will be addressed in subsequent papers.

ACKNOWLEDGMENTS The author would like to acknowledge the technical assistance offered by Reed B. Carlson at Argonne National Laboratory. The author wants to recognize the efforts of Dr. H.P. Planchon in supporting completion and in-plant testing of the proposed platform. The valuable comments provided by the referees are also greatly appreciated.

789

REFERENCES Andersson, M. (1992). Discrete event modeling and simulation in Omola, IEEE Symposium on Computer Aided Control System Design, pp. 262268. Andersson, M. (1993). Modeling of combined discrete event and continuous time dynamical systems. 12th IFAC World Congress, Sydney, vol.9, pp. 69-72. Balemi, S., et al. (1993). Supervisory control of rapid thermal multiprocessor, IEEE Trans. Automatic Control, vol. 38, no. 7, pp. 1040-1059. Brockett, R.W. (1993). Hybrid models for motion control systems, In H.L. Trentelman, J.C. Willems, editors, Essays on Control: Perspectives in Theory and its Applications, Birkhauser, pp. 29-53. Cao, X.R. and Y.C. Ho. (1990). Models of discreteevent dynamic systems, IEEE CSM, pp. 69-76. Garcia, H.E. and A. Ray (1996). State-space supervisory control of reconfigurable discrete event systems, Int. J. Control, vol. 63, no. 4, pp. 767797. Garcia, H.E., et al. (1995). A reconfigurable hybrid system and its application to power plant control, IEEE Trans. on Control Systems Technology, Vol. 3, No. 2, pp. 157-170. Gollu, A. and P. Varaiya (1989). Hybrid dynarnieal systems, Proc 28th CDC, Tampa, FL, pp. 27082712. Grossman, R.L., A. Nerode, A.P. Ravn, and H. Rischel (1993). HybridSystems, (Ed.) Lecture Notes in Computer Science 736, Springer-Verlag. Kumar, R., V. Garg, and S.I. Marcus. (1993). Predicates and predicate transformers for supervisory control of discrete-event dynamical systems, IEEE Trans. Automatic Control, vol. 38, no. 2. Leveson, N. (1991). Software safety in embedded computer systems, Com. ACM, V, pp. 34-46. Li, Y. and W. M. Womham. (1993). Control of vector discrete-event systems Part I-The base model, IEEE Trans. AC, vol. 38, no. 8, pp. 1214-1227. Parnas, D.L., G.J. Asmis, J. Madey (1990). Managing complexity in safety-critical software, ACM Conf. on Critical Issues, Mclean, V, 6 Nov. 1990, 10Pgs. Rushby, J. and F. yon Henke (1993). Formal verification of algorithms for critical systems, IEEE Trans. Software Engineering, vol. 19, no. 1, pp. 13-23. Sadiris, G.N. (1989). Analytic formulation of the principle of increasing precision with decreasing intelligence for intelligent machines, Automatica, vo. 5, pp. 461-467.