a corba-based architecture for strategic process control

Annual Reviews in Control 27 (2003) 15–22

Review

A CORBA-based architecture for strategic process control

Ricardo Sanz∗

ETS Ingenieros Industriales, Universidad Politécnica de Madrid, José Gutierrez Abascal 2, 28006 Madrid, Spain

Abstract

Strategic decision-making in complex continuous process plants has been a matter for humans since ever. Automated decision supportsystems are built to help human operators in making reliable, fast and economically advantageous decisions. In many cases, however, theconstruction of these systems is very complex due to the needs of integrating heterogeneous information sources or knowledge sources. Thispaper introduces the topic of strategic process control and gives an example of such an application in the cement sector built atop the integratedcontrol architecture (ICa).© 2003 Elsevier Ltd. All rights reserved.

Keywords:Integration; Distributed control; Supervision; Intelligence; Real-time object oriented systems

1. Introduction

Strategic decision-making in complex continuous processplants (chemical, oil, cement, etc.) has been a topic re-stricted for humans since ever (Sheridan, Vámos, & Aida,1983). The reasons for this restriction—lack of automationindeed—are grounded in the unpredictability derived fromplant complexity (Åström et al., 2000).

Strategic control issues are those related with the top levelmanagement of the plant. They are oriented to reach globalobjectives that, in many cases, are not suitable to be inte-grated in an automated planner due to their heterogeneityand abstractness. Examples aresafety, production, stabilityor maintainability. In these plants, the responsibility for thistype of decisions is always of a human that decides what todo in any problematic situation.

Automation, however, is desirable—in a general sense—in any type of plant and for any type of task if this automa-tion does not mean the sacrifice of any one of those toplevel objectives. Partial automation is achieved for some ofthe objectives but no total solution is available in general,because these plants are mostly unique (at least after sometime of operation).

The flexibility offered by present-day information tech-nology helps bridge the gap between an heterogeneouscollection of information sources without sacrificing de-pendability or performance. Automated decision supportsystems are emerging to help human operators in making

∗ Tel.: +34-91-336-3061; fax:+34-91-336-3010.E-mail address:[email protected] (R. Sanz).

reliable, fast, and economically advantageous decisions(Petrov & Stoyen, 2000).

In this paper we are not going to propose “the ultimateutility function” for this type of application, but to show anexample of how a suitable integration technology can lead toa specifically tailored decision support system that can pro-vide an integrated plant view for strategic decision-making(de Antonio et al., 2000).

Not surprisingly, the construction process for these tai-lored systems is extremely complex due to the needs of inte-grating heterogeneous information sources (new and legacysystems) into a single whole application. Extreme complex-ity is reached when the system is designed even for integra-tion with future (not yet existing nor specified) systems asis the common need in complex plants.

The PIKMAC system described in this paper was devel-oped to support human-centered operation of a cement plantduring periods when this operator is the only person in theplant (i.e. the only person capable of making strategic de-cisions in real-time). This application exploits the integra-tional capability of CORBA middleware (OMG, 2000) togather heterogeneous information that is fused into simplequality, economy, and maintenance views. This applicationis deployed atop the integrated control architecture (ICa;Sanz, Segarra, de Antonio, & Clavijo, 1999b) that has beenspecifically built for the control systems domain.

2. Strategic process control

Control systems in large plants are hierarchically orga-nized to integrate the complex functionality required from

1367-5788/$ – see front matter © 2003 Elsevier Ltd. All rights reserved.doi:10.1016/S1367-5788(03)00003-8

16 R. Sanz / Annual Reviews in Control 27 (2003) 15–22

Fig. 1. Typical hierarchical organization of a control systems in complexplants.

them.Fig. 1shows an overview of the layers of a typical hi-erarchy. Lower layers are typically available in any processcontrol system and higher layers are typically custom-builtto target specific plant needs.

Strategic process control is the set of activities regard-ing top level decision-making in a process plant. Strategiccontrol is traditionally considered a management activityand hence studied as part of business processes and practice(Simons, 1995). In our domain we consider it as mostly re-lated with global optimization and risk management at theenterprise level. Hence this paper focus strictly on a techni-cal level, addressing strategic control of production systemsfrom a purely technical perspective.

While strategic decision-making is typically considereda human activity, the necessary incorporation of advancedcomputing mechanisms in the top level decision-makingprocess in large industries, makes this process an mixedhuman–machine system. In the case of management ofpurely technical systems, the decision support system (DSS)becomes critical for the proper and timely understandingand assessment of the situation of the plant.

DSS are a specific class of interactive computing sys-tems that support human decision-making activities. DSSin control applications are interactive computer-based sys-tems intended to help plant operators (decision makers)use control, computing and communications technologiesto exploit data, documents, knowledge and/or models toidentify and solve problems and make proper decisions inreal-time. Five specific DSS types are typically identified:

• Communications-driven DSS,• Data-driven DSS,• Document-driven DSS,• Knowledge-driven DSS,• Model-driven DSS.

Expert systems technology has been operational in theimplementation of knowledge-based DSS leading to multi-ple successes in the enhancement of processes carried byhuman operators. Good results have been achieved even inthe presence of uncertainty by means of using mechanismsbased on Bayesian methods or fuzzy logic.

But in many cases, decision-making is done in thepresence of excess of uncertainty that forbids automaticdecision-making. This is particularly clear during faultand emergency management. Even while experiments havebeen done in the automatic management of these situationsin small systems (Bernard et al., 1999), the technologiesavailable so far do not scale up to complex industrial plantemergency management. In these situations decisions arenecessarily taken by hybrid decision makers (human+machine).

The work described in this article focus on the implemen-tation of a concrete DSS that uses CORBA technology tointegrate heterogeneous sources of knowledge to help thedecision-making process.

3. Operational objectives for the plant

Cement production is somewhat tricky due to the ex-treme nature of the process (chemical reactions in high-temperature fused material) and the nature of the inputsolids (they are usually rocks from a mountain nearby).Chemical composition is critical for the quality of the fi-nal product (it gets hard by chemical reaction with water)and the main cost is not raw materials but energy andsalaries.

Energy is obtained from the combustion of different prod-ucts: coal, fuel, oil, waste, etc. (during one of the demonstra-tions of this application they were burning peach). Each typeof fuel has its own qualities (energy per kilogram, cost perkilogram) and side effects (specially in kiln controllability).

Cement plants suffer—as any other industrial plant—theglobal business objective of reduction of human personnelin all types of tasks. But this must be done with a minimumsacrifice in the rest of the strategic objectives.

Some of the key factors of success for cement industryare to gain capability to quickly react to customer needs;be able to employ different fuels of poor quality (heavyfuel, recycled oils, waste, etc.) without altering the qualityof the final product; and reach the capability to compete ata larger geographic scale by permanently streamlining theproduction costs, and optimizing the value created by thecompany (DIXIT Consortium, 1998).

To advance in the achievement of these capabilities La-farge Ciments managers decided to develop a new genera-tion of IT applications, taking advantage of existing processautomation and supervision applications already installed,to be used by all types of plant personnel.

The ideas behind this technology program were:

• To extract from the huge amount of data continu-ously stored in CIM.21 process database and otherplant databases, the synthetic information relevant fordecision-making at any moment;

• To derive through an explicit (mathematical) model oran implicit (neural net) models high level value added

R. Sanz / Annual Reviews in Control 27 (2003) 15–22 17

information consistent with the overall target objectivesof the plant (cost, quantity, quality);

• To provide decision support to control room operator totake better decisions in case of failure, in a way that in-corporate commercial data, economic factors and humanresources constraints to the pure technical data usuallytaken into account until now;

• To gather in a single user interface all the information,heterogeneous in nature, to facilitate the global control ofthe production;

• To offer an innovative presentation paradigm and explo-ration tool making easier production global performancecomparison for different moments (for example, now ver-sus one month ago) or different process configurations(fuel types, clinker quality, etc.);

• To facilitate the real-time dissemination of production per-formance information according to formats that can beshared and understood by all the plant department peo-ple (management, maintenance, commercial, production,quality, etc.).

The plant selected for the development of the PIKMACtools is placed in Contes, France. This plant had anotherchallenge for PIKMAC because it was operated by only oneperson during night and week-end shifts (this means that hewas the only person in plant during that time).

4. The integrated control architecture

The PIKMAC application was deployed using a CORBAmiddleware specially suited for control purposes. The namefor this middleware is ICa Broker and it is the cornerstoneof the ICa.

ICa is an ongoing, long-term project at the UniversidadPolitécnica de Madrid, with a basic objective: simplify theconstruction, deployment and maintenance of software in-tensive, distributed controllers.

The ICa follows the specifications developed by OMG(http://www.omg.org) for distributed object systems, beingUPM one of its members. On top of these specifications, ICaadds control design patterns (Sanz et al., 1999c) and classlibraries to support these patterns.

The election of CORBA as a basis for ICa is grounded inits extensibility and the capabilities it offers for real-time andembedded systems (OMG, 2000, 2002). It is not easy to findthese capabilities in other enterprise integration architectureslike Microsoft DNA, Java EJB or XML/SOAP.

Fig. 2 shows how CORBA subsystems running atop het-erogeneous protocols (for example, TCP/IP and IEC 60870)can be seamless interoperated (Sanz et al., 2002).

The ICa methodology is strongly based on the use ofdesign patterns. Software pattern technology (Buschmann,Meunier, Rohnert, Sommerlad, & Stal, 1996; Gamma,Helm, Johnson, & Vlissides, 1995) is a methodologyused in the capture, transfer, and exploitation of design

Fig. 2. A CORBA-based domain architecture provides the required func-tionality to deal with the special requirements of the distributed–embeddeddomain.

knowledge. It has been deeply used in the object-orientedprogramming community but it has also proved useful inother communities related with the design and implemen-tation of complex real-time systems (Sanz & Zalewski,2003).

The ICa development model is based on the use of ob-ject frameworks that are specialized to narrower domainsto construct complex control product lines (Sanz, Alarcón,Segarra, de Antonio, & Clavijo, 1999a). The CORBA In-terface Definition Language (IDL) technology helps in thistask because it provides mechanisms of multiple inheritancethat simplify the mixing of functionality that is typically re-quired when using multiple design patterns.

5. The PIKMAC decision support system

PIKMAC stands forprocess information and knowledgemodeling for advanced control. This demonstration applica-tion was deployed in the Lafarge Ciments plant of Contes(France).

Its purpose is to keep operators informed to perform a bet-ter strategic control of the process in terms ofmaintenance,quality, andcost. PIKMAC is based on the fact that a lot ofprocess information is continuously acquired (sensor mea-surements, control system variables, operator commands,automatic test laboratory, etc.) but remains under-used inmost cases.

This information concerns all the parts of the cement pro-duction process—raw material mill, kiln, cooler, and clinkermill—and covers a wide range of process behavior charac-teristics.

While several applications could be designed in order toefficiently support the plant operators and process engineersonly three integrated applications were demonstrated in PIK-MAC:

• Production Performance Synthetic Indicator(PPSI): pro-vides real-time estimations of production performance

http://www.omg.org


Fig. 3. PIKMAC is built as a collection of active CORBA objects thatprovide specific pieces of functionality: core systems, legacy applicationwrapping, operator interface and system support.

(quantity and cost) using a Global Production Controlconcept.

• Quality Deviation Early Detector(QDED): estimatescontinuously key quality parameters making possible theearly detection of non-optimal situations.

• Alarm Management Operator Assistant(AMOA): helpsthe operator—in particular, during night and weekends—to deal with alarm situations to optimize calls to mainte-nance people.

5.1. Global application structure

The global structure of the application is very simple: itis a collection of active and passive agents running over theICa broker. These agents provide different types of functionsand their interaction capabilities are expressed by means ofCORBA IDL (OMG, 2000).

The system is depicted inFig. 3 showing the collectionof agents that composed the application.

The domain architecture for PIKMAC was designed byLafarge Ciments personnel to follow their own ideas on thisnew set of IT tools for plant management. The people incharge of the DIXIT architecture did only map that concep-tual architecture to a specific CORBA implementation basedon ICa agents.

PIKMAC agents can be grouped in four categories:

• Core subsystems: They provide the basic functionality ofthe PIKMAC demonstrator. They are QDED, PPSI, andAMOA.

• Data sources wrappers: They wrap external data sourcesto be exploited in a CORBA environment. They areCIM.21, LAB, and IRDB.

• Operator interface: They are the user interface for thesystem. There is only one type of agent (OI) but it can bereplicated in any number of hosts.

• System support: They provide hidden functionality for therest of the agents. They are the ICa Monitor and the Var-Manager.

Fig. 4. Overall view of PPSI calculation model.

5.2. Data sources wrappers

The three main data sources for PIKMAC are: (i) thereal-time process database of the CIM.21 control system, (ii)the incident report database (IRDB), and (iii) the automatedlaboratory (LAB). All they are legacy systems that can beaccessed using their specific APIs. They appear in PIKMACas conventional CORBA objects resulting from wrappingpart of the APIs.

5.3. PPSI

The PPSI agent implements the core functionality forPPSI service. It perform calculations of process throughputand cost per processed unit. These calculations are done on-line in a continuous manner and uses sampled process datagathered from the plant.

The PPSI implements a cost calculation model (Fig. 4)which takes into account the long processing time for theraw material in cement production.

5.4. AMOA

AMOA is built entirely on G2, an expert systems de-velopment tool from Gensym (http://www.gensym.com). Ituses DIXIT’s G2-ORB Bridge to connect to the plant datasources and other applications like the operator interfacethrough the ICa ORB.

The main component in AMOA is theprocess reasoningmodule. It gathers and analyze the real data coming fromthe plant, generating reports regarding present and possi-ble future failures. In case of a problem situation, AMOAwill generate reports informing the user about the real rootcauses of the problem, based on the process analysis it does(Fig. 5). AMOA will also guide the user in the task of de-ciding whether a maintenance team is to be called or not,and which is the maintenance team that must be called if itis the case.

The interaction with AMOA can be done using the genericPIKMAC user interface (that provides a simple syntheticview) or the more specialized AMOA native G2 interface.

http://www.gensym.com


Fig. 5. Failure causal flow chart about P30 flow rate used in the knowledge base of AMOA.

5.5. QDED

The QDED agent society predicts some critical qualityproperties of cement (free lime percentage, SO3 ratio, C3Sratio, and C3A ratio) as the cement is produced in the factory.

QDED agents use neural networks trained on historicaldata to make online predictions (seeFig. 6). The core is-

Fig. 6. The QDED neural network uses inputs from all the cement process with proper delays to estimate present quality.

sue here is to provide reliable estimates of these parameters,avoiding the delay and the cost derived from slow and ex-pensive automatic laboratory analysis.

A single network is trained for each of these tasks, andthe final version of QDED thus require all four agentsrunning simultaneously to provide estimates for all fourparameters.


Fig. 7. PIKMAC has a user-friendly human–machine interface that runson Windows NT platforms. This figure shows the part of the OI thatcontains quality information from QDED.

5.6. Operator interface

The PIKMAC system is deployed over an heterogeneouscollection of computing equipment. In the demonstrationapplication most parts are running on Alpha/UNIX and In-tel/NT platforms.

The user interface runs on Windows NT computers pro-viding a synthetic view of the plant state from the threeperspectives: cost, quality, and maintenance.Fig. 7 showsthe main user interface for the quality section. It providesnumeric and visual information about the status of qualityelements for the cement provided by a remote QDED agent.

There is no fixed number of operator interfaces than canbe run in an installation, thanks to the brokerage mechanismsprovided by the CORBA middleware.

This agent is built using native Microsoft technologyelements (i.e. COM Components, OLE Automation, andActive-X Controls) that are connected to the CORBA worldby means of COM–CORBA interoperability mechanisms.

5.7. System support

There are two agents that provide support for the rest ofthe system. ICa Monitor continuously monitors the state ofthe systems controlling the particular status of any agent.

PIKMAC VarManager is a real-time database with addedfeatures for DIXIT applications: it gathers data from datasources upon schedule, can process this information andcalculate derived data and also supports subscription servicesfor any data it handles.

6. Strategic emergency management

The system described here was implemented to supporthuman operators dealing with cement plants but the technol-

Fig. 8. RiskMan application structure as a collection of interacting CORBAobjects. The figure shows the base middleware (ICa) and the objects thatimplement system functionality.

ogy behind it was also successfully used to implement otherstrategic controllers focused on risk reduction and emer-gency management.

The RiskMan system (Sanz et al., 2000) was implementedas a solution to the problems of emergency management inchemical plants by means of ICa-based agents. The basicsubsystems in this application were aPreventive System, anEmergency Manager, and aWorkpermit Managerto han-dle human-induced risks. All them were implemented usingCORBA objects over the ICa integration middleware (seeFig. 8).

The Emergency Managerdeals with the management ofemergencies and implementation of the plant safety planfollowing the already established policies for dealing withemergencies. Safety protocols for this plant are very com-plex because they involve safety regulations from the Euro-pean Union, Spanish laws, Catalan laws, Tarragona’s chemi-cal sector plans and Repsol’s own policies. This includes thereal-time elaboration of theemergency organization chart,i.e. the human organization structure to deal with the emer-gency, under the constraints posed by the emergency as wellas the communication of the actuation procedures to the per-sonnel involved in the emergency (Fig. 9).

Fig. 9. RiskMan Emergency Manager user interface. The figure showsthe navigation map used to focus on specific areas of the complex.


Once the emergency is declared, the system automaticallyhandles all issues related to the organization chart elabora-tion and information management.

ThePreventive Systemmonitors the state of a subsystemdetecting abnormal situations before they reach a criticalstage. This component is only applied to a set of selectedequipment in order to fully test its suitability and correct-ness. A complete implementation, i.e. covering the wholecomplex, was out of the scope of the project. A rule-basedapproach is utilized in this software module.

The acceptance or not of certain human-performed main-tenance activities depends on the result of a risk evaluation.It was estimated that automating these protocols, at leastpartially, could save a lot of time and reduce the risk ofaccidents, during maintenance operations. This leads to thedefinition and implementation of aWorkpermit Manager,an application that helps Repsol personnel in the manage-ment of the protocols for the authorization and control ofrisk-inducing maintenance operations. In order to do so, theapplication automates many of the procedures that are cur-rently done by hand with the subsequent loss of time andincrease of risk. The application helps the user by consid-ering relevant on-line process information that should betaken into account for the authorization and execution ofsuch maintenance operations.

7. Conclusions

While this is an “applications” paper (nothing extremelynew is shown here) it demonstrates how integration archi-tectures and technologies help develop future plant-wideintegrated control systems in an easy and modular way.All the systems described here were developed by fivedevelopment groups in four countries and put to worktogether in a matter of hours (only for demonstrationpurposes).

The PIKMAC application can only be considered ademonstration of the technology and not a full fledgedapplication. More work is necessary to make it a depend-able decision support system. Extensions to support expertsystems justification (Guida & Zanella, 1997) or fault tol-erance (Butler & Finelli, 1993; OMG, 1999) are obviouslynecessary to exploit it in a real context.

CORBA technology is here to stay and offers a clearopportunity for control system developers for leveragingprevious developments in an easy way. But some contri-bution to OMG is needed from the controls community.While CORBA is been widely used in real-time settings(see Fig. 10) not many industrial applications are de-scribed that pose critical requirements for the ORB infra-structure.

The contribution of control systems engineers is neces-sary for this technology, and the results that we can obtainfrom it are extremely high for the deployment of new con-trol technologies in large, complex, and distributed plants.

Fig. 10. Current use of ORB middleware in embedded and real-timeapplications (fromCzerny, 2000).

A new working group in Control Systems has been recentlychartered by the OMG to foster the suitability of OMG tech-nologies for control systems implementation.

Acknowledgements

The development of the ICa framework was partiallyfunded by the Spanish Comisión Interministerial de Cienciay Tecnologıa. This system was developed inside the DIXITproject funded by the European Commission. The membersof the DIXIT consortium were IIC (es), daCapo (se), Repsol(es), Lafarge Ciments (fr), Rambøll (dk), Eusristic Systémes(fr) and UPM (es).

References

Åström, K., Alberto, I., Pedro, A., Mogens, B., Walter, S., & Sanz, R.(Eds. ). (2000).Control of complex systems. Berlin: Springer.

Bernard, D., Dorais, G., Gamble, E., Kanefsky, B., Kurien, J., Man, G.K., Millar, W., Muscettola, N., Nayak, P., Rajan, R., Rouquette, N.,Smith, B., Taylor W., & Tung, Y.-W. (1999). Spacecraft autonomyflight experience: The ds1 remote agent experiment. InProceedingsof the AIAA’1999. Albuquerque, NM: AAAI.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M.(1996). Pattern oriented software architecture. A system of patterns.Chichester, UK: Wiley.

Butler, R. W. Finelli, G. B. (1993). The infeasibility of quantifyingthe reliability of life-critical real-time software.IEEE Transactions onSoftware Engineering, 19(1), 3–12.

Czerny, P. (2000). Current uses of middleware in embedded/real-timeapplications. InProceedings of the 1st OMG Workshop on Real-Timeand Embedded Distributed Object Computing. Falls Church, USA:OMG.

de Antonio, A., Sanz R., Matıa, F., & Segarra, M. J. (2000). Tacklingcontrol systems complexity. In N. Katevas (Ed. ),Mobile robotics inhealthcare. Amsterdam: IOS Press.

DIXIT Consortium. (1998).PIKMAC user manual.Gamma, E., Helm, R., Johnson R., & Vlissides, J. (1995).Design pat-

terns. Elements of reusable object oriented software. Reading, MA:Addison-Wesley.


Guida, G., & Zanella, M. (1997). Bridging the gap between users andcomplex decision support systems: The role of justification. InPro-ceedings of Third IEEE International Conference on Engineering ofComplex Computer Systems, ICECCS’97(pp. 229–238).

OMG (1999). Fault tolerant CORBA joint revised submission. Techni-cal Report orbos/99-10-05. Object Management Group, Falls Church,USA.

OMG (2000).Common object request broker architecture and specifica-tion. Release 2. 4. Technical Report. Object Management Group, FallsChurch, USA.

OMG (2002).The common object request broker: Architecture and speci-fication. Technical Report Version 3. 0, formal/02-06-01. Object Man-agement Group, Falls Church, USA.

Petrov, P. V., & Stoyen, A. D. (2000). An intelligent-agent based decisionsupport system for a complex command and control application. InProceedings of Sixth IEEE International Conference on Engineeringof Complex Computer Systems, ICECCS’2000(pp. 94–104).

Sanz, R. Zalewski, J. (2003). Pattern-based Control Systems Engineer-ing: Using design patterns to document, transfer, and exploit designknowledge.IEEE Control Systems Magazine, 23(3), 43–60.

Sanz, R. Alarcón, A. Segarra, M. J. de Antonio, A. Calvijo, J.A. (1999a). Progressive domain focalization in intelligent controlsystems.Control Engineering Practice, 7(5), 665–671.

Sanz, R., Segarra, M. J., de Antonio, A., & Clavijo, J. A. (1999b).ICa: Middleware for intelligent process control. InIEEE InternationalSymposium on Intelligent Control, ISIC’1999, Cambridge, MA.

Sanz, R., Segarra, M. J., de Antonio, A., Matıa, F., Jiménez, A., &Galán, R. (1999c). Design patterns in intelligent control systems. InProceedings of IFAC 14th World Congress, Beijing, China.

Sanz, R., Segarra, M. J., de Antonio, A., Alarcón, I., Matıa F., & Jiménez,A. (2000). Plant-wide risk management using distributed objects. InIFAC SAFEPROCESS’2000, Budapest, Hungary.

Sanz, R., González, I., Segarra, M. J., Tagliarini, R., Gomes, L., Hernán-dez, G., & Zangrilli, A. (2002). CORBA-based interoperation insubstation automation systems. InProceedings of 15th IFAC WorldCongress, Barcelona, Spain.

Sheridan, T. B. Vámos, T. Aida, S. (1983). Adapting automation toman, culture and society.Automatica, 19(6), 605–612.

Simons, R. L. (1995). Control in an age of empowerment.HarvardBusiness Review, March–April, 80–88.

a corba-based architecture for strategic process control

Documents