The daemon controls reading and writing of data to the database, agent execution and the user interaction with the system. For all three interactions an interface ...
7
3URFHHGLQJVRIWKHWK0HGLWHUUDQHDQ&RQIHUHQFHRQ &RQWURO $XWRPDWLRQ-XO\ $WKHQV*UHHFH
A Decision Support System with Distributed Agents for Large-Scale Process Control A. Prayati*, A. Stathaki*, E. Furusjo** and R. E. King* *
Data and Knowledge Engineering Group, Computer Technology Institute, Athens, Greece ** Environmental Research Institute IVL, Stockholm, Sweden
Abstract— As CIM systems are being developed to assist plant managers and operators with real-time monitoring and control, the need for Decision Support Systems (DSS) becomes apparent so as to investigate alternative control strategies, fault diagnosis and alarming situations. As processes become more complex the need to consider also the environmental impact, on top of the commonly used economical factors, leads to new system architectures and multi-objective optimization. In this paper, a DSS architecture is presented considering distributed agents taking into account a multiplicity of impact factors in order to improve overall process operation.
I.
INTRODUCTION
Most small scale process control systems in operation today, involve simple three-term field controllers embedded in programmable controllers or microcontrollers, operating autonomously and rarely linked to supervisory systems for effective process control. Most large-scale control systems do use Supervision, Control and Data Acquisition (SCADA) or Distributed Control Systems (DCS), few of which support optimization, however. Attempts to introduce high-level supervision that offers optimization of the overall plant, have generally failed due to the lack coordination and compatibility between the different control levels [1]. The need for a Decision Support System (DSS) stems from the necessity to handle the increasingly complex aspects of process control and address coordinated optimization process [2,3] efficiently. A DSS is essentially an interactive computer-based system capable of assisting decision makers exploit data and models to identify and deal with unstructured or partially structured decision problems. In cases of completely structured decision problems, computational techniques can be applied automatically by the DSS without human intervention and represent the exclusive domain of process automation [4]. Run-time industrial DSSs aim at satisfying the requirements for improved plant performance in terms of economy [5] and rarely involve the environmental costs [6,7]. The next generation of supervisory control systems however, must not only support data acquisition and process control but also provide the tools for optimum and efficient decision-making taking into account the conflicts among production objectives [8]. The next generation of industrial DSS should thus allow the
appropriate constructs for knowledge management as well as generic models to investigate alternative management policies and control strategies. In this paper, we focus on the design of a DSS with distributed agents that support both on-line control and off-line scenario-based management through model-based simulation. The DSS has been developed, implemented and commissioned as part of an EU funded project and has been commissioned at two test case sites. An optimization functionality supported with appropriate models and constructs is also introduced, in order to satisfy the need for a multi-objective optimization of economical and environmental impact factors using a holistic view of the problem. The proposed system architecture is presented in Section II, while the DSS components are defined in Section III. Finally, the rapid prototype is described in Section IV. II.
SYSTEM SPECIFICATION
The proposed system architecture, shown in Fig. 1, is a distributed network comprising Agents that are available to support run-time process control as well as off-line simulations. The On-line Subsystem (ONS) consists of a cluster of agents that have direct access to the Data Base (DB) and perform all the on-line functions. The Off-line Subsystem (OFS) refers to the cluster of off-line agents that are useful for simulation and scenario- based reasoning. The off-line sub-system involves two databases, which are repositories of process models, data and parameters required by the various distributed agents.
ONS Process ProcessControl Control Optimizer Optimizer
USER HMI HMI
OFS Process ProcessControl Control Optimizer Optimizer
DSS
Simulator Simulator Economical Economical
DB
Monitoring Monitoring
model-DB OFS-DB
Simulator Simulator Economical Economical Monitoring Monitoring Environmental Environmental
Environmental Environmental
PROCESS PROCESS SCADA SCADA Process
Figure 1. System Architecture
7
3URFHHGLQJVRIWKHWK0HGLWHUUDQHDQ&RQIHUHQFHRQ &RQWURO $XWRPDWLRQ-XO\ $WKHQV*UHHFH
B. The Distributed Agents Distributed agents are components of the overall control system, each responsible for a distinct task but able to cooperate with any other within the system. The principal agents of the system are outlined below: Process Control Agent: This agent is responsible for specifying the control strategy that optimizes the performance of the physical process with respect to economical and environmental factors while respecting the physical constraints imposed by specifications. Optimization Agent: This agent performs multiobjective optimization subject to environmental and economical factors and provides the optimum operating conditions for the control system. The agent uses a variety of methodologies that can be called upon to determine the most effective process operating conditions. Environmental Agent: The objective of this agent is to model the environmental impact factors of the process including both the upstream impact of raw materials inflow used in the process and the downstream environmental impact associated with the end product and the treatment of waste byproducts. Economical Model: The objectives of this agent are twofold: to compute the economic performance of the
process by taking into account economical impact factors and to provide information for establishing the optimum operating points of the process. Performance Indicators (PIs) are estimated based on on-line and historical data. Process Monitoring Agent: This agent is responsible for process monitoring and includes soft sensors, process state monitoring, fault and disturbance detection and identification by determining the quality-related parameters of the process. Simulation Agent: The role of this agent is to perform simulation on the results of which the DSS will be able to infer strategies for improved plant management and control. Simulation scenarios under different operating and abnormal conditions can be examined off-line on a separate platform. C. Data Management and Acquisition All agents are linked closely to the Real-Time Data Base, which contains current and historical data from the existing database of the SCADA of the physical process, servicing all the distributed agents with data for processing. Acquired data is tightly coupled to each application and thus highly dependent on the existing process SCADA and the communications facilities it possesses. A non-real time Data Base is integral to the DSS and constitutes the repository of parameters and models required by the various Agents. The Supervisory Control and Data Acquisition System (SCADA) handles the physical process interface, retrieving data from the process for further processing in the DSS. III. THE DSS ARCHITECTURE The architecture of the DSS is shown in the schematic of Fig. 2. The DSS consists of four basic elements, namely the control kernel and the interfaces to the system agents. The control kernel contains three major components: the daemon for coordinating the overall system, the scheduler for managing the agent execution sequence and the watchdog for polling the critical variables and managing the alarms in the process variables. The daemon controls reading and writing of data to the database, agent execution and the user interaction with the system. For all three interactions an interface is defined, called the data base interface, agent interface and HMI respectively.
DSS
Process Control
HMI Optimizer
DSS kernel Daemon Scheduler
Watchdog
DB interface
Agent interface
A. The Decision Support System The core element of the process control system is the DSS, which is responsible for run-time monitoring of the process, coordination of the various system functional components and determination of the optimum control strategy that will minimize economical, energy and environmental impact factors. Distributed agents are an eminently suitable vehicle for implementing such architecture, each inter-operating agent being responsible for a specific task. Apart from run-time monitoring and coordination, the DSS is designed to support off-line operational decisions by allowing simultaneous simulation of different operational scenarios. Simulation support also allows investigation of alternative control strategies for improved overall plant performance for normal and abnormal production conditions. Taking into consideration the possible behaviors that can be expected from a DSS, four categories have been identified and are included in the DSS: request acceptance, information acquisition, information processing and decision making. Thus the principal functions of the DSS are to: i. Assist in configuring the parameters of the agents at run-time. ii. Support a user-friendly graphical user interface for monitoring and controlling the system. iii. Manage the parameters of the agents at run-time and off-line. iv. Ensure normal operation of the system. v. Provide optimum operation set points for the process with respect to economic and environmental impact parameters. vi. Process historical data on the performance of the overall system in order to assess its performance.
Monitoring Economical Module Environmental Module
DB Simulator
Figure 2. A schematic of the DSS architecture
7
3URFHHGLQJVRIWKHWK0HGLWHUUDQHDQ&RQIHUHQFHRQ &RQWURO $XWRPDWLRQ-XO\ $WKHQV*UHHFH
A comprehensive and formal Unified Modeling Language (UML) [9] model of the system is shown in Fig. 3, based on which the DSS components are outlined. A. A. The System Daemon The daemon is the kernel of the DSS, responsible for managing, coordinating and controlling the overall system. The daemon executes and coordinates all the interfaces and agent execution in accordance with the following rules. The daemon executes the Optimization agent at runtime, upon instruction from the watchdog, indicating that an alarm situation has been detected and that a new optimum control strategy must be computed for the process. Since the Optimization agent requires data from all other Agents before activation of the Optimization agent, the daemon must ensure that the necessary models required by the DSS have been executed and the corresponding parameters have been calculated for input to the Optimization agent. The daemon configures the Agents with the appropriate models defined by the user during the configuration phase and activates the agent instances according to the schedule provided by the Scheduler. The results generated are saved in the database and are displayed to the user through a graphical environment. To activate every agent, the following sequence of actions is executed: • Access the model Data Base to load the model to the Agent
•
Access the historical Data Base to retrieve the required inputs for the specific model • Activate the model computation of the agent instance via the agent interface • Access the Data Base to save the results generated by the agent • Notify the operator by displaying the results. In case an alarm condition is sensed by the watchdog under manual operation, the HMI is immediately activated to notify the user When in automatic mode, a “red” alarm is treated automatically by executing the Optimization agent without further user interaction. The daemon executes the Process Control Agent, when a new operation point is selected by the user among optimum alternatives generated by the Optimization agent. The daemon also maintains a record of operational sequence status in a log file, available for display on demand. B. The Scheduler Since distribution of tasks is inherent in the system architecture, the scheduling policy has one extra degree of freedom allowed by concurrency. However, considering alternative implementation cases, where only a single-processor platform is used, a sequential schedule imposes an additional constraint on the scheduling algorithm. The Scheduler produces a feasible scheduling scheme, used by the daemon to execute the corresponding agent sequence.
Clock Us e r Pr of il e us erRight vers ionNo ps w
G et Tim est am p()
S c heduler A ct iveA gent ID Nex t TriggerID Tim eConst rai nts sc h edul ingA lgorit hm
DS S deamo n
1. .n
HM I
1.. n
S ched ule()
P anel
1 .. n Net work
ON-S y st em
m odelDB
DB
Off-line DB
Off-line S ys t em
Result His t oric alDat a
Data na me un it t im est am p Input
S CAD A
1. .n
Dist ribut ed M odule off-line nam e m odelID RequiredM odel Res ult Table suc cess _flag Input[ ] S et M odel() ConfigureA lgorit hm () S tart() S top() A bort ()
O pt im iz er
E c onom ic al
Environm ent al
M oni to ri ng
P roc ess Cont rol
Figure 3. UML system representation
S im ulat or
7
3URFHHGLQJVRIWKHWK0HGLWHUUDQHDQ&RQIHUHQFHRQ &RQWURO $XWRPDWLRQ-XO\ $WKHQV*UHHFH
In order to provide a static schedule, several scheduling strategies have been taken into consideration and are defined as follows: i. Execution interval is configured by the user for every agent instance. ii. Preconditions for agent execution are set i.e. precedence constraints. iii. Logical agent execution or the Optimization agent is executed after all other agents have been executed. iv. Soft real-time constraints imposed by the Process Control agent at run-time. C. The system watchdog The watchdog is essential software of the overall process control system and is responsible for polling the critical variables of the physical process and, in case of alarm, for generating discrete events for executing the Optimization Agent. Apart from checking the alarm boundaries, the watchdog is also responsible for tracking the critical variables in a “quasi-alarm” region, defined as a region sufficiently close to the alarm threshold so as to provide notification that the specific variables are approaching the alarm limits. The watchdog consists of a thread and interacts with the daemon in the following cases: i. To retrieve the critical variables from the Data Base and check their values. ii. To notify the user about alarm situations or threshold boundaries that may be violated. iii. To execute the Optimization agent. Once the daemon is notified of an alarm, the sequence of activating the HMI and Optimization agents is controlled by the daemon itself and the watchdog is reset. This means that alarm events are reset and the thread is restarted.
IV.
THE DSS INTERFACE
In this section the three basic interfaces to the DSS are described: the user interface, the data base interface and the agent interface. A. User interface A Human-Machine-Interface (HMI), used for the graphical user interaction with the system, provides the following functionality: i. Configuration of the agent parameters: model type, input variables and execution interval. ii. Modification of existing configured agent instances. iii. Graphical representation of the results coming up from the configured agent model execution. iv. Graphical support for the user interaction with the agent results. v. User notification in case of alarm. vi. Report generation based on daemon interface events and actions, presented in an event log window. B. Agent interface The DSS-Agent interface uses a wrapper responsible for encapsulating the agent-specific services in a standard DSS-agent interface, as defined in the UML diagram in Fig. 4. Legacy software can thereby readily be incorporated. For the different models that are configured to run on one agent, multiple instances of the agent are created by the DSS. A different model with its associated inputs is loaded from the model library to the corresponding agent instance by the function SetModel (ModelType) where ModelType is the path and name of the file defining the model.
W rapper modelType ResultTable errorFlag InputTable
DSS ActiveAgents : Distributed Module[] watchdog
SetModel(ModelType) : errorFlag, requiredModel, requiredInput, TimeLags GetOutputFunction(ModelType) : Type, inputVariables, OutputVariables, coefficients Start() Stop() Abort() SetRTData(DataTag, InputValue, TimeInstances) : errorFlag
SaveResult(DataTag, ResultValue, TimeStamp) : errorFlag RunWatchdogThread()
DB
Distributed Module ModuleID Name mode offline : boolean
DBTag Name Unit Description TimeStamp
Data
ModelHandler(modelFileName, loadFlag) : errorFlag, requiredModel, requiredInput, TimeLags, modelStruct ExecuteModel(ModelFileName, InputData, TimeInstances) : successFlag, resultTags, result GetFunction() : Type, inputVariables, OutputVariables, coefficients
reliability
Result
Input mandatory : boolean
setReliability(reliability) : void getReliability()
setMandatory(boolean) isMandatory() : boolean
ErrorDescription setDescription(String) : void
Figure 4. Wrapper interface definition
7
3URFHHGLQJVRIWKHWK0HGLWHUUDQHDQ&RQIHUHQFHRQ &RQWURO $XWRPDWLRQ-XO\ $WKHQV*UHHFH
The SetModel function returns the following variables: i. An errorFlag indicating whether the model was successfully loaded. ii. The RequiredModel vector holding the name of other configured models, whose results are a prerequisite for the current model to execute. If the current model is independent of any other, this variable has a predefined value. The required models to provide results to the current model must refer to the same agent type as the current model. iii. The RequiredInput vector containing all required input tags of the loaded models. Each input tag is unique and characterizes the key of the variable in the model Data Base entry. iv. The TimeLags vector containing the time instants, for which input data is required for the model to run. The second interface function is SetRTData (DataTag, InputValue, TimeInstances), which is called to provide data to the configured agent instance. The input data is assigned values by the DSS, which retrieves the corresponding data from the historical DB using the necessary input tags and time lags for every loaded model, performing interpolation if needed. DataTag is a vector containing the input data tags and InputValue is a table holding the values of the corresponding input data tags for the different time instances in each row, while TimeInstances is a matrix complementary to InputValue holding the timestamps corresponding to the input values. For the retrieved input data, the DSS executes the model loaded via the Start function. The Start and Stop functions are necessary to execute the agent instance execution and hold, respectively, according to the scheduling scheme generated by the Scheduler agent. The execution is triggered by the wrapper through the ExecuteModel(ModelName, InputData, TimeInstances) function, which calls the corresponding functions of the distributed agent to execute the ModelName with the set inputData for the specified timeInstances. The execution of the agent instance returns a flag indicating successful completion of the model, together with two vectors with results and their corresponding resultTags, respectively. In case of abnormal operation, the Abort function is used to interrupt execution of the active agent instance. Under normal operation where the agents execute without pre-emption, the wrapper calls the SaveResult(DataTag, ResultValue) function to return results to the DSS once the agent instance has finished its execution,. DataTag is a vector of Strings denoting the Agent execution result data tag, while ResultValue is a vector of type double elements containing the corresponding result values. The input required for the Optimization agent implies particularities that impose the need for additional constructs in the Optimization agent interface, as well as in the wrapper definition. For all corresponding models the physical process parameters, objective functions must be provided as inputs to the Optimization agent. To retrieve this information, the function GetOutputFunction(ModelType) is defined, where ModelType is the model file name for which the objective function must be captured. This function computes:
i. The type of the objective function, namely linear, polynomial etc. ii. The InputVariables vector holding the decision variables of the objective functions. iii. The OutputVariables vector with the output variables of the objective functions. iv. The Coefficients vector indicating the coefficients of the decision variables in the objective function. The coefficient vector has the same size as the InputVariables vector. If a decision variable does not exist in the objective function the corresponding coefficient is zero. C. Database interface The DB, historical DB and model DB are accessible for data required by the agents. The model DB holds information for the available agent models such as their corresponding input and output types, execution time and periodicity. The following accesses to the DB tables are performed through SQL queries for the different DSS functionalities. i. In the configuration phase, the model DB is accessed to retrieve the available models for every agent and its corresponding information. The tables are updated with the configured agent instances and the historical DB data tags are linked to the model inputs. ii. At run-time, the daemon keeps track of model tags executed and accesses the historical DB for input data. iii. The results of every configured agent instance are saved in a separate DB table in order to avoid simultaneous accesses and conflicts. The results are consumed either for graphical representation or other model execution. V.
CASE STUDY
The DSS design and functionality was examined exhaustively using rapid prototypes before the final version was implemented. The DSS agents and the Graphical User Interface (GUI) have been implemented in Visual Basic with Microsoft Visual Studio V6.0, while the agent algorithms were converted in dynamic link libraries with Distributed COM technology (DCOM dll) from packaged Matlab components [10]. The models of the agents residing in the model DB are Matlab/Simulink models. Finally, the DB structure was implemented in Oracle and its interface to the DSS is realized through SQL queries integrated in Visual Basic using ActiveX Data Object (ADO) Microsoft technology. VI.
CONCLUSIONS
The essential architecture of a real-time Decision Support System for holistic integrated process control has been presented. The basic constructs required to support the DSS in applying economical and environmental impact factors of the physical process and their integration into a multi-criterion optimization problem, necessary to compute an optimum control strategy are outlined. Besides multi-criterion optimization and run-
7
3URFHHGLQJVRIWKHWK0HGLWHUUDQHDQ&RQIHUHQFHRQ &RQWURO $XWRPDWLRQ-XO\ $WKHQV*UHHFH
time monitoring, the DSS supports off-line scenariobased decision making. The appropriate interfaces are defined through the use of formal description models. The open architecture of the system allows for ready expansion and additional agents, should more impact factors be necessary. The DSS design is flexible and the UML model open and adaptable for extension to cover applications of different industrial processes. REFERENCES [1]
[2]
[3]
[1] Samad T., “Intelligent control in the process industries: considerations for future research”, Proc. of the 35th Conference on Decision and Control, Kobe, Japan, Dec. 1996, pp. 4512-4513 [2] Holsapple C. W. and A. B. Whinston, “Decision Support Systems: A Knowledge-Based Approach”, West Publishing Company, 1996. [3] Turban E, J., E. Aronson, “Decision Support Systems and Intelligent Systems”, (6th Edition), Pearson Education, November 2000.
[4]
[4] Wierzbicki A. P., M. Makowski and J. Wessels (Eds), “Modelbased Decision Support Methodology with Environmental Applications”, Kluwer Academic Publisher, 2000. [5] [5] Bedford T. and Cooke, “Probabilistic Risk Analysis: foundations and methods”, Cambridge University Press, Cambridge, 2001. [6] [6] Antonsson A.B. and H. Carlsson , “The basis for a method to integrate work environment in life cycle assessments”, Cleaner Prod., 3, 215 – 220, 1995. [7] [7] Thoresen J., E. Eriksson and R. Thun, “Nordic Project on Development and Implementation of Environmental Performance Indicators in Industry”, Nordic Industrial Fund, report No. OR 05.01, 2000. [8] [8] Filip F G, Donciulescu D A and Filip C. I., “Towards Intelligent Real-time Decision Support Systems for Industrial Milieu”, Studies in Informatics and Control, Vol. 11, No. 4, pp. 33-311, December 2002 [9] [9] - “OMG Unified Modelling Language Specification”, Version 1.3, First Edition, Object Management Group Inc. March 2000. [10] [10] Maloney J., “Distributed COM: Application Development using Visual Basic 6.0”, Prentice Hall series in Microsoft Technologies, 1999.
