+ All Categories
Transcript

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

Journal of Intelligent & Fuzzy Systems xx (20xx) x–xxDOI:10.3233/IFS-141198IOS Press

1

Intelligent agents for alarm managementin petroleum ambient

Nayat Sanchez-Pia,∗, Luiz Andre Paes Lemeb and Ana Cristina Bicharra Garciab

aILTC, Instituto de Logica, Filosofia e Teoria da Ciencia, Niteroi. Rio de Janeiro, BrazilbADDLabs, Computer Science Department, Fluminense Federal University, Niteroi. Rio de Janeiro, Brazil

Abstract. Alarm management is a fast-growing and important aspect in the petroleum operation domain. Alarm devices havebecome very cheap leading petroleum equipment manufacturers to overuse them transferring safety responsibility to operators.Not rarely, accident reports cite poor operators understanding of the actual plant status due to too many active alarms. Typicalalarms for a process plant could average over fourteen thousand per day so, there is mandatory to have a filtering process todistinguish expected from non-expected behavior during emergency scenarios. Ambient Intelligence contributes by enriching thepetroleum plant environment with technology (mainly sensors and devices interconnected through a network) and built a systemto help plant operators to make decisions based on real-time information gathered and historical data accumulated. AmbientIntelligence puts together all these resources to provide flexible and intelligent services to users acting in their environment.Inspired by the distributed and encapsulated aspect of the process plant artifact physical model, we proposed a multi-agent-basedalarm management system to synthesize the process plant situation during emergency situations and assisting operators to makesense of alarm avalanche scenarios.

Keywords: Multi-agent systems, ambient intelligence, alarm management, oil industry, fault detection

1. Introduction

The trend in the direction of intelligent supportsystems applied to engineering lead us think ofAmbient Intelligence (AmI). The hardware cost reduc-tion and miniaturization allows including computingdevices in several objects and environments (embeddedsystems).

AmI environments should be aware of the needsof people, customizing requirements and forecast-ing behaviors. These environmentsare very diverse,from typical environments like homes, offices, meet-ing rooms, schools, hospitals, to industry. In the aimsof Artificial Intelligence, research envisages to includemore intelligence in the AmI environments, allowinga better support to the human being and the access to

∗Corresponding author. Nayat Sanchez-Pi, ILTC, Instituto deLogica, Filosofia e Teoria da Ciencia, Niteroi. Rio de Janeiro, Brazil.E-mails: [email protected] (Nayat Sanchez-Pi); [email protected](Luiz Andre Paes Leme); [email protected] (Ana Cristina BicharraGarcia).

the essential knowledge to make better decisions wheninteracting with these environments.

Indeed, it is important to note that the currenttechnological possibilities (e.g., embedded systems,distributed controllers, intelligent actuators and RFID)now allow the definition of ambient intelligence envi-ronments where a growing amount of informationcan be embedded, thus increasing the decision-makingcapability of static and/or mobile entities, either prod-ucts or resources.

There exist several scenarios in industry where theamount of sensor data needs to be intelligently pro-cessed to optimize the decision making process. Anexample is the alarm management in emergency sce-narios that has become a topic of great concern indifferent economic sectors, such as nuclear, aeronauticsand offshore oil industry, due to the frequent accidentsoccurred in the last decades caused by inappropriatealarm management systems. Although great effort hasbeen devoted to plant’s automation and cheap alarmdevice development, operators play an important role

1064-1246/14/$27.50 © 2014 – IOS Press and the authors. All rights reserved

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

2 N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient

mastering all information and adjusting equipments’behavior as needed. The observations of our researchare domain independent, but, in this paper, we focus onthe offshore oil process plant domain.

An alarm informs operators of the process plantstatus and might require immediate action. As thesafety norms become more stringent and sensor devicesbecome inexpensive and easier to embed, manu-facturers have overused installing alarms into theirequipments. Trained operators handle pretty well few,but not many, alarm information at a time. During anon-planned process plant shutdowns, operators face anavalanche of alarm information, frequently over 1000alarms/minute, that must be understood, prioritized andreasoned to decide upon which action, if any, to take.This information overflow has been related as one ofthe major cause of several serious accidents in the lastdecade, such as the Mildford Haven refinery accident inthe UK, on 24 July 1994, which resulted in a loss of 48million pounds and two months of non-operation. Thereport of the Health and Safety Executive department[1] has identified as the accident cause the refinery oper-ators’ inability to identify what was really happeningbehind the large number of triggered alarms generated.The accident could be avoided if the alarm system hadidentified the cause of the problem, sorted alarm infor-mation and displayed only the most important ones sothat the operator is able to act properly.

A process plant of a petroleum offshore unit is acomplex artifact composed of independent equipmentswhich interact with each other to receive petroleumfrom subsea reservoirs; treat it and export gas and oilto land refineries. Each equipment behaves and reactsto accomplish its own goal, such as compress gas ortreat oil, but maintaining its behavior within the safetyfunctioning range. Sensors and actuators are essen-tial devices embedded in the equipments to monitoror control their behavior, respectively. These comple-mentary devices are orchestrated by the process plantautomation system that receives sensors informationand triggers actuators actions, such as closing a valve.

An emergency shutdown (SD) in a process plant unitis a safety measure, in general, triggered by automa-tion systems (AS) to protect the equipment, the system,people operating the system and the environment. EachSD triggers a set of events designed by the automa-tion designers to protect the unit. For example, duringa shutdown of a specific equipment, it is expectedthat this equipment be contained and isolated from therest. In order to accomplish these effects, the automa-tion procedure imposes the closing of upstream and

downstream valves. When shutting down a system oreven the entire unit, many more events may be trig-gered. Of course, these events interact with each otherand further automation procedures must specify thedesired interactions. At the same time sensors monitorparameters’ values for undesirable situations. Some-times these undesirable situations are the expected ones.For instance, a fast pressure drop downstream a pumpmight represent a pump cavity danger. However, thesame information when associated with a pump turn-off means a correct and desirable behavior. As alreadymentioded, in an emergency situation, a great deal ofinformation is generated. It is extremely useful to estab-lish priorities to set which alarms are actually importantto be displayed to operators.

This scenario is very suited to agent architecture:each equipment, system or even a component can bemodeled as autonomous agents. A sensor would be anagent, as well as valves, pumps, compressors, etc. Anagent must know the effect of its good or ill behavior. Ifsomething unexpected occurs the agent can report theproblem together with alarms which support its conclu-sion. But, there could be other agents which would beresponsible for more complex diagnoses that could bebased on the reasoning of other agents. For example,a vessel would be considered contained if all inlet andoutlet valves are completely closed. In this case, eachvalve corresponds to a different agent responsible fordiagnosing the actual state of the valves and the ves-sel to an agent responsible to diagnose the actual stateof the vessel. The vessel agent reasoning rests on thediagnoses of the valve agents. Besides different

The differences between configurations of processplants is another key aspect which points towards theagents technology. Although the set of equipments ofa process plant can not be dynamically changed, it canbe changed over time or operated with different sets ofactive equipments. Moreover, two petroleum offshoreunits can be very different in terms of its process plant.Once Oil companies have to manage many differentpetroleum offshore unit, systems for asset managementand control should be easily configurable and scalable.Agents technology perfectly fits in this kind of engineer-ing problems due to the main characteristics of agents:autonomous reasoning, proactivity, configurability andscalability. During the years researchers have come tothe conclusion that reactivity is also a very importantcharacteristic that an intelligent agent should possess[2]. Reactivity is suitable for changing environmentsperforming an appropriate response to some changeswhich have been recognized and perceived [3].

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient 3

Inspired by the distributed and encapsulated aspectof the process plant artifact physical model, we pro-posed a multi-agent-based alarm management systemto synthesize the process plant situation during emer-gency situations. Each agent represents an equipmentthat understands about its expected and unexpectedbehavior within the process plant. During emergencyscenarios, alarms related to expected behavior can besuppressed to lead operators’ attention to unexpectedbehavior. Distinguishing expected from non-expectedbehavior during emergency scenarios and using thisinformation to filter what to display to operators isthe basis for our intelligent alarm management sys-tem proposal. In addition to proposing a model, wehave implemented a prototype version and tested it ina controlled environment. We are currently deployinga version of the system to work within a Brazilian off-shore petroleum process plant unit. The rest of the paperis structured as followed. The first section presentsrelated work in the area of alarm management systems,focused on offshore oil process plant domain. Next, ourmulti-agent alarm management system is laid down,followed by a case study. Results are presented and aconclusions are outlined.

2. Related work

In 2000 there were at least eight oil spills in Brazil.It is estimated that the sum of fines imposed to oilcompanies, as a result of environmental stresses, alongthat year, exceed two hundred million dollars [4]. Datafrom the Federation of Oil (FUP) [5] and the NationalFront of Oil (PNF) [6] show that since 1967 therewere more than 350 accidents involving fatalities inpetroleum industry. In an attempt to ensure proper oper-ating environment for maximum security for people,environmental protection and operational continuity,leading enterprises have been working steadily in theirpolicies of SMS (Safety, Environment and Health). Onthe other hand, the world economic growth has calledfor an oil production increase.

Process plant automation and alarm managementsystems are a reality in both as academic proposals andon-the-shelf technology. Some of them are:

� The Matrikon Alarm Manager software [7] thatallows multiple tests to be made for an alarm sys-tem. It provides operators with reports in MicrosoftExcel spread- sheets or accessed via web browser.The material can be used to study the artifact’sbehavior using basic statistic functions to access

alarms’ information and advanced analyzes thatinclude a detailed mapping of the condition of thealarm system, focusing on typical problems that canbe detected from statistical tools. It is built usingopen technology standards; including, service ori-ented architectures, MSSQL and Oracle support.

� ABB [8] delivered an alarm management feature aspart of an automation system. In this system rulesare configurated on demand by the operators whichare in charge to decide when the complexity of thealarms is sufficient to suppressed an alarm.

� GEs Alarm Response Management system [9] thatevaluates the response of each individual alarmto the device’s condition while also comparingresponses to multiple alarms using the criticalstatistic. It uses Mean Time To Repair (MTTR) toidentify trends.

Many research studies proposed different combina-tions of systems theoretic and artificial intelligencetechniques to tackle the alarm management prob-lem, and delineated the requirements of such system.There exist many different conventional centralizedapproaches in different industries (oil and electricpower), such as:� [10] propose an alarm management system which

classifies alarms according to the type of distur-bance produced.Their final objective is to find theroot cause of avalanches of alarms (failure tree)and to reduce their number through grouping orclustering techniques.

� [11, 12] these two approaches are not alarmmanagment tools but systems that use artificialintelligence to identify root cause analysis of thefaults in oil and gas plants.

But most of alarm management approaches focuseseither on post-crisis information analysis or on moreautomation procedures.

Besides, several conceptual frameworks have beensuggested for modeling complex intelligent systemsin the past two decades, such as expert systems [13]and multi-agent systems (MAS). MAS, which canbe considered as an instantiation of distributed arti-ficial intelligence, are another conceptual frameworkfor modeling complex systems. The MAS platformemphasizes distribution, autonomy, interaction (i.e.,communication), coordination, and organization ofindividual agents. Some approaches are:� [14] propose a multiagent systems providing self-

healing and adaptive reconfiguration capabilities

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

4 N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient

for power grids based on wide-area system vulner-ability assessment to prevent or reduce catastrophicfailures and cascading sequences of events.

� [15] describe a multi-agent model for fault detec-tion and diagnosis which exploits the concept ofleadership; that is, when a fault is detected oneagent emerges as leader and coordinates the faultclassification process.

� [16] propose a multi-agent system that can achievea range of real-time safety monitoring tasks: faultdetection and diagnosis, alarm annunciation andcontrol of hazardous failures.

� [17] proposes the use of multiagent systems forproviding a flexible and scalable alternative to post-fault disturbance diagnosis. It integrates a legacySCADA interpretation system with new systemsfor digital fault recorder (DFR) record interpreta-tion and for enhancing fault record retrieval fromremote DFRs.

� [18] describes how a multi-agent system (MAS)for transformer condition monitoring has beendesigned to employ the data generated by the ultrahigh frequency (UHF) monitoring of partial dis-charge activity.

� [19] presented an intelligent environmental mon-itoring system, developed with software agentsand using data mining techniques for adding cus-tomized intelligence into them.

But none of the above approaches addresses thechallenge of assisting operators to make sense of thesituation during crisis scenarios. Since our goal is toprovide assistance during crisis, our system must bedesigned as a real-time application.

We have also investigated many different approachesin ambient intelligent environments such as conven-tional centralized structures, decentralized applicationsand multi-agent system. The last approaches has pre-sented the best results concerning response time andflexibility to grow the application. Some of them are:

� [20] propose a multi-agent approach for provision-ing of e-services in u-commerce environments.

� [21] propose a context-aware system using agentsthat can be used in very different domains.

� [22] discuss how to consider software engineeringissues in the development o fagent-based multisen-sor surveillance systems.

� [23] support the argument on prediction strategylimitations into agent-based modelling.

We see three strategies to face the problem ofinformation overflow: 1) mitigate wrong decisions, 2)predict problems to avoid avalanches and 3) real-timeanalysis of the avalanche to filter unimportant alarmsand automatically diagnose problems. We propose thethird strategy. Firstly, because mitigate bad decisions isnot always possible or economically feasible for obvi-ous reasons. Secondly, predictive methods are usuallybased on labeled examples or mathematical modelswhich were not available. Moreover, predicting of prob-lems could not avoid all shutdowns and, therefore,it would still be necessary to manage emergencies.we proposed a multi-agent-based alarm managementsystem to synthesize the process plant situation dur-ing emergency situations. Each agent represents anequipment that understands about its expected andunexpected behavior within the process plant. Dur-ing emergency scenarios, alarms related to expectedbehavior can be suppressed to lead operators’ attentionto unexpected behavior. Distinguishing expected fromnon-expected behavior during emergency scenarios andusing this information to filter what to display to oper-ators is the basis for our intelligent alarm managementsystem proposal. In addition to proposing a model, wehave implemented a prototype version and tested it in acontrolled environment. Previuos work has been doneby authors in [24, 25].

3. MAS for alarm management system

The objective of our approach is to work as analarm filter, receiving and sorting messages sent by theautomation supervisor system (AS), during a seriousnon-planned process plant shutdown, called here sim-ply as STOP. This STOP situation causes an avalancheof alarms. It is humanly impossible for process plantoperators to understand not only what is happeningwith the process plant, but also, and more importantly,if it is being moving to a safe state, i.e. if the plantis properly being turned off. Thus, our proposed sys-tem can be seen as a assisted-stop system. The operatorshould only receive information related to unexpectedalarms or danger degree escalation that may compro-mise the safety of the unit. For example, as previouslymentioned, the alarm of low pressure downstream apump should only be visible if the turn-off commandhas not been sent to the pump, since, in this case, thepump is in danger of cavitation.

Typically, the network of agents is used by theteam of workers in charge of operating the processplant. The master operator receives information from all

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient 5

Fig. 1. Multi-agent architecture.

subsystems of the plant and is responsible for coordinat-ing the work of the field operators that are responsiblefor handling possible issues detected during a STOP.The field operators are spread along the many subsys-tems of the process plant. Each subsystem is equippedwith an information agent which acts as a “blackboard"of messages, that interacts with agents that monitors thesurrounding equipments, and shows relevant informa-tion regarded to their subsystems. On the other hand,the information agent of the master operator shows mes-sages from all subsystems. This configuration allows forgreater agility in information flow between operatorsand is easily adaptable to different process plants.

3.1. MAS Architecture

The Agents paradigm provides an excellent modelingabstraction for our intelligent alarm management sys-tem due to agent’s human-like characteristics, includingreasoning, proactivity, communication and adaptivebehavior. Moreover, Alarm Management Systems inEmergency Situations beg for technologies that aretransparent, so that the functional behavior in an emer-gency situation can be easily understood by operators.

Our model, illustrated in Figure 1, represents an intel-ligent support system for alarms management in anoffshore oil production domain. The MAS architec-ture is composed of four types of agents: Environment

Agent, Automation Agent, Log Handler Agent, LogAnalyzer Agent and Blackboard Agent. The agentsmain functionalities are the following:

� Environment agent: This agent monitors infor-mation from nature. It also manages informationregarding the Oil Production Platform status suchus the identification of a SD.

� Automation agent: Automation System (AS).Events and alarms continuously monitored andidentified by sensors embedded in the equipmentsare sent to the automation system (AS). Later, theAS triggers Actuators (pumps, valves, compres-sors, etc.) for actions (open/close, turn-on/turn-off).This agent creates a log of events which are sent tothe Log Handler Agent.

� Log handler agent: This agent reads and parses thelog of events in the blackboard to create structuredinformation that can be further analyzed.

� Log analyser agent: This agent is actually a set ofagents. Each agent understands about a equipment.Each agent selects, from the structured informa-tion stored in the blackboard, only the informationthat concerns its expertise. Its knowledge is writ-ten in terms of production rules describing expectedand unexpected behaviors. Expected behaviors trig-gers an alarm information suppression action, thatmeans an information removal from the blackboard.

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

6 N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient

Fig. 2. Domain ontology.

� Blackboard agent: This agent handles informationthat will be displayed to operators. It must handleinformation synchronization since many agents arereading and writing into its structure. It invokes theGUI where alarms information are shown to thefinal operator.

The agents are developed, so that it is possible toreplicate them and synchronize the internal states of thereplicas. Thus, the loss of one or more agents causes themessages to this agents being forwarded to the activereplicas.

3.2. Ontology

We model the process plant domain using an ontol-ogy, illustrated in Figure 2, that emphasizes thecomponent and monitoring characteristics of the arti-fact. Modeling this environment involves representingentities and relationships among these entities. Themain concepts of the ontology and its description areas follows.

� Equipment: It is a component of a process plant.� Actuator: It is a device, such as valves, pumps

and compressors, which controls the equipmentbehavior.

� Equipment behavior: It represents the way theequipment behaves in order to achieve a desiredfunctionality. Equipment behavior is measuredthrough sensors.

� Event: It is an action over the actuators that mightcauses a change in the state of the alarm. Forinstance, the event "close" over the actuator "valve"should cause a decrease on oil flow in the pipeline.

� Alarm: It represents an abnormal state of the equip-ment behavior. The possible values are High (H),Very High (HH), Low (L) or Very Low (LL). HHand LL leads to equipment and even the entire unitshut down.

� Sensor: It is a device that measures control vari-ables.

� Control variable status: It indicates the variationof a measurement. A control variable status indi-cates for instance if the temperature is increasing.

An equipment is part of a process plant. Equipmentachieves its goals though a set of behaviors such as oillevel, pressure, temperature and flow that are monitoredby sensors. Alarm is a special type of sensor that indi-cates an equipment behavior overtake danger thresholdvalues. There are four types of alarms: Very high, high,low and very low alarm. There is also analogic sen-sors that measure the exact value of a given behavior.

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient 7

Fig. 3. Rules processing.

Automation controls equipment behaviors thoughevents changing actuators status such as pump turn-off. Valves, pumps and compressors are examples ofactuators.

3.3. Stored procedures

One of the drawbacks of the agent technology in ourscenario is the inability of handling large amount of datain a short time. Indeed, the log messages analyzed by theagents can achieve hundreds of thousands of messagesper minute. In order to overcome such limitation, wecombined the agent technology with a database systemsby developing the reasoning part of the Log Handlerand Log Analyzer agents using stored procedures. Thestrategy was the best choice and the results have provenit so far.

As named, stored procedures are programs storedin a database. Relational programming are programsdeveloped using sequences of SQL statements. Followa sample of a procedure used by the Log Analyzer agent.

PROCEDURE LOG_ANALYZER( ) IS ... BEGIN ...

INSERT INTO T_STOPS(ID,TYPE,DT_START,ALARM)(SELECTP.ID,TP.TYPE,

MIN(P.DT_START),MIN(P.ID_ALARM)

FROM(SELECT DISTINCT ID, TYPE, DT_START, ID_ALARMFROM PARADASTART WITH (DT_STRAT <= DT AND DT_END IS NULL)CONNECT BY NOCYCLE(DT_START <= DTAND (DT_START BETWEENPRIOR DT_START AND NVL( PRIOR DT_END DT)

OR DT_END + TOLERANCE BETWEENPRIOR DT_START AND NVL(PRIOR DT_END, DT)))) P

INNER JOIN TYPE TP ON P.ID=TP.IDGROUP BY P.ID, TP.TYPE);

The automation agent continuously harvest data fromenvironment agents to identify emergencies and trig-ger shutdowns. It also sends harvested data to the LogHandler agent in the form of text messages (Figure 3a).

The Log Handler agent interprets data from theautomation system, filters useful data and publishestreated data in a blackboard which is stored in a rela-tional table (Figures 3b and 3d). Log Handler agentsare platform specific because the syntactic rules ofmessages may vary between offshore units. It dis-cards repeated messages, extracts structured data fromunstructured messages, validate chronology of mes-sages and identify the element (valve, pump, etc.) thatmessages refers to.

There are one analyzer agent for each environmentagent that should be monitored, i.e. a valve has a

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

8 N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient

Fig. 4. Relational operations to assess rules.

corresponding analyzer which diagnoses its failures. Ifthe valve does not close or open when it should do, itsanalyzer publishes diagnoses and suggestions of actionsto operators in the blackboard. The blackboard agent,then, filters what is important.

The rules are propositional implications in the con-junctive normal form where each clause states variable

transitions or states of alarms, actuators and variables.It is stored in a relational table as well (Figure 3c).The inferences currently done are checking of actualstate of valves, pumps, compressors, etc. and dangerdegree escalation. Danger degree escalation is whenfire or gas leak happens in the same area of the initiatorof the SD. The inferences of each agent can be accom-plished through a set of relational operations over thetwo mentioned relations as shown in Figure 4.

The rules for all agents are fed by automationexperts though a special knowledge acquisition inter-face (not included in the main model) and stored inthe knowledge-base. There are two types of rules:those depending only on the status of each equipmentbehavior and those that depend on a combination ofequipments’ behaviors. Therefore, there is a rule chain.

4. Case study

Now we are going deeper into more details aboutthe agents behavior. The environment and automationagents will not be covered because they do not dif-fer from existing automation systems. As example ofhow to automatically manage alarms consider an atmo-spheric separator SG1 (Figure 5), which is part of aprocess plant. It is an equipment in which petroleum isseparated into oil and gas. It is equipped with three sen-sors and four alarms that keep track of the level insidethe vessel and a valve SDV1 (Figure 5) in the oil out-let of SG1. The sensors and alarms of the separator

Fig. 5. Atmospheric separator.

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient 9

detect and indicate if the level is very high, high, normal,low and very low. When level is very high or very lowthe automation system triggers a shutdown, i.e. the AStakes a set of actions that stops the production process ofthe platform. One of the actions is to close the SDV1.It may happen that, because of the wear of the valveor malfunctioning of closing mechanism, the valvecloses but do not completely seal the oil outlet or evendo not close properly as commanded by automationsystem.

Then, the alarm management system has to extractfrom operational data (event logs - Figure 3a) clues thatcould indicate that the valve is closed after a shutdown isinitiated, otherwise the platform would be in an unsafestate until the valve is closed. Of course there will beother actions such as close the inlet valve of oil and theoutlet valve of gas, but this actions will be monitoredby other agents similarly.

Analyzing the schema of the separator it can be seenthat if the valve is closed it is unexpected that the valvewill not declare itself closed. In the platform control sys-tem which we were dealing with all actuators declaredits state. It is unexpected, as well, that the level insideSG1 will decrease. On the other hand, it is expectedthat the level will not decrease, i.e. will increase ormaintain, depending on the state of the inlet valve. Itis expected that pressure downstream SDV1 decreasesas well. The agent can then reason on observations ofwhat is unexpected and expected and diagnose what isthe actual state of the valve. If nothing unexpected hashappened and everything expected have happened thenthe valve would be considered closed otherwise it mightbe open.

We propose to specify both unexpected and expectedbehavior rules. To better understand why, note that inthe previous example the valve could be partially open,but an inlet flow could be compensating an outlet flowso that the level remains the same, i.e. the level will notdecrease as unexpected behavior rules require. In thiscase, valve opening would only be detected by checkingpressure downstream the valve in the expected behav-ior rule. Moreover, in terms of knowledge acquisition toconfigure reasoning rules of agents this approach facil-itates one to remember what should be checked. If wewant to assure that something was done it is natural tothink in terms of what was unexpected and expected tohappen.

Figure 3a is a fragment of the log messages thatare analyzed by the agents. The first two lines statesthat the valve SDV1 is closed and that the level insideSG1 decreased. It is an unexpected behavior because it

means that level inside SG1 decreased, but if the valvewas properly closed the level could not have decreased.Log analyzer periodically checks incoming messagesin order to detect ESD occurrences. When an SD isdetected the analyzer starts evaluating rules in a for-ward chaining fashion. When rules evaluation points toa failed event the event description and a set of relatedalarms are sent to the blackboard. The alarms not relatedto failed events are ignored, what relieves operatorsfrom dealing with the complete and large sets of alarms.Following, is an example of rules for evaluating events(Figure 6).

In the running example, the rules can be defined asfollows:� Unxpected behavior rules:

Rule 1: IF the valve did not declare itself closedTHEN something wrong has happened

Rule 2: IF the level inside SG1 did decreaseTHEN something wrong has happened

� Expected behavior rules:

Rule 3: IF the level inside SG1 did not decreaseAND the pressure downstream SDV1 didfall to zero THEN all expected to SDV1has happened

� Decision rule:

Rule 4: IF nothing unexpected happened toSDV1 AND everything expected to SDV1happened THEN the valve SDV1 is sup-posed to be is closed OTHERWISE thevalve is supposed to be open

The reasoning rules are stored as in Figure 3c ina relational table. The first two lines represent theunexpected rules for SDV1 analyzer agent (UB meansunexpected behavior) and the next two represent theexpected rules (EB means expected behavior). Figure4 shows the set of relational operations on the black-board and rules relations which are processed by theSDV1 analyzer agent to detect that the valve is actuallyopen. The agent then corrects the state of the valve onthe blackboard (3d) and adds the information about thealarms which led to the conclusion.

We have tested the system in an environment wherethe automation agent generated up to 30 messages/secduring a shutdown and that there was 200 analyzeragents. The measured load capacity of the log handleragent was 40 messages/second and the average process-ing time for each analyzer agent was 7 milliseconds.

Figure 7 shows the results of the analyzes of datafrom 22 SDs. The last column represents the percentage

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

10 N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient

Fig. 6. Logs, events and rules relationship.

Fig. 7. Results. Alarms suppressed.

of alarm suppression. As shown, there are scenarios of93,76% of suppression.

5. Conclusions

More than a decade has passed since intelligent sys-tems were first applied in oil industry but still lacks of

applications that can bring the power of integrated andembedded intelligent systems into the main stream ofthe oil and gas profession. Most alarm managementapproaches existing for oil industry focus either onpost-crisis information analysis or on more automa-tion procedures. The innovation of our approach forpetroleum ambient combines the challenges of real-time systems and intelligent decision support systems.

In Press

Journal Identification = IFS Article Identification = 1198 Date: March 29, 2014 Time: 1:10 pm

N. Sanchez-Pi et al. / Intelligent agents for alarm management in petroleum ambient 11

This work presents an alarm management systemthat provides a solution for improving operators’ situa-tion awareness during emergency situations in offshoreoil platforms. The system is based on multi-agenttechnology and benefits from great efficiency in dataprocessing of the database systems.The innovative partis that agents reasoning were implemented by means ofstored procedures in order to overcome the limitation ofhandling large amount of data in short time, like the hun-dreds of thousands of messages per minute agents canexchange. This MAS-based model provides a compre-hensive treatment of the alarm management problem.

Oil process plant is a very complex artifact composedof independent subparts that interacts with each other,so the possibility of working with real-world data wasvery demanding and challenging issue. The results ofinitial experiments run in our research lab using actualdata information coming from SD scenarios have shownthat only 6 percent of the total of the alarms were visu-alized to the operator which is an outstanding result.Additionally, operators confirmed that the suppressedinformation was unnecessary.

Future research of this project will be addressed inthe area of sensor network fusion. Another interest isalso extending the multi-agent architecture to supportredundancy to achive more reliability and robustness ofthe system.This extension will also highlight the abilityof learning of the agents from the interaction with theusers.

References

[1] Health and Safety Executive, The Explosion and Fires atthe Texaco Refinery, Milford Haven, 24 July 1994 (IncidentReport), HSE Books, 1997.

[2] R. Kornelije, A combination of reactive and deliberative agentsin hospital logistics, in Proceedings of 17 th InternationalConference on Information and Intelligent Systems, (Croatia),(2006), pp. 63–70.

[3] K. Rabuzin, M. Malekovic, and M. Cubrilo, Resolving physicalconflicts in multiagent systems, in 2008 The Third InternationalMulti-Conference on Computing in the Global InformationTechnology (iccgi 2008), pp. 193–199, IEEE, (2008).

[4] Principais Acidentes da Industria Petrolıfera noMundo, tech.rep.

[5] Ajudante cai dentro de silo de soja e morre asfixiado, tech. rep.,2002.

[6] F.N. dos Petroleiros, Historico dos Acidentes e Mortes na Petro-bras, 2008.

[7] Apparatus and method for performing process hazard analysis,US Patent 7,716,239, 2010.

[8] ABB, Asea Brown Boveri, tech. rep.

[9] GE, Alarm Response Management, tech. rep.[10] O. Aizpurua, R. Galan, and A. Jimenez, A new cognitive-based

massive alarm management system in electrical power admin-istration, in 2008 7th International Caribbean Conference onDevices, Circuits and Systems, pp. 1-6, IEEE, (2008).

[11] J.E. Skogdalen and J.E. Vinnem, Combining precursor inci-dents investigations and QRA in oil and gas industry, ReliabilityEngineering & System Safety 101 (2012), 48–58.

[12] G.P. Zarri, Knowledge representation and inference tech-niques to improve the management of gas and oil facilities,Knowledge-Based Systems 24 (2011), 989–1003.

[13] N. Sanchez-Pi, J. Carbo and J.M. Molina, A knowledge-basedsystem approach for a context-aware system, Knowl Based Syst27 (2012), 1–17.

[14] G.T. Heydt, V. Vittal and A.G. Phadke, The strategic powerinfrastructure defense (SPID) system. A conceptual design,IEEE Control Systems 20 (2000), 40–52.

[15] B. Mendoza, P. Xu, and L. Song, A multi-agent model forfault diagnosis in petrochemical plants, in 2011 IEEE SensorsApplications Symposium, pp. 203–208, IEEE (2011).

[16] A. Dheedan and Y. Papadopoulos, Model-based distributedon-line safety monitoring, in EMERGING 2011, The ThirdInternational Conference on Emerging Network Intelligence,(Lisbon, Portugal) (2011), pp. 1–7.

[17] J.A. Hossack, J. Menal, S.D.J. McArthur and J.R. McDonald,A multiagent architecture for protection engineering diagnosticassistance, in 2003 IEEE Power Engineering Society Gen-eral Meeting (IEEE Cat. No.03CH37491) 2, p. 640, IEEE2003.

[18] S.D.J. McArthur, S.M. Strachan and G. Jahn, The designof a multi-agent transformer condition monitoring system,IEEE Transactions on Power Systems 19 (2004), 1845–1852.

[19] I.N. Athanasiadis and P.A. Mitkas, An agent-based intel-ligent environmental monitoring system, Management ofEnvironmental Quality: An International Journal 15(3) (2004),238–249.

[20] N. Sanchez-Pi and J.M. Molina, A multi-agent approach forprovisioning of e-services in u-commerce environments, Inter-net Research 20(3) (2010), 276–295.

[21] V. Venturini, J. Carbo and J.M. Molina, Methodological designand comparative evaluation of a mas providing ami, ExpertSystems with Applications 39(12) (2012), 10656–10673.

[22] J. Pavon, J. Gomez-Sanz, A. Fernandez-Caballero and J.J.Valencia-Jimenez, Development of intelligent multisensorsurveillance systems with agents, Robotics and AutonomousSystems 55(12) (2007), 892–903.

[23] S. Hassan, J. Arroyo, J. M. Galan, L. Antunes, and J. Pavon,Asking the oracle: Introducing forecasting principles intoagent-based modelling, Journal of Artificial Societies andSocial Simulation 16(3) (2013), p. 13.

[24] A.C.B. Garcia, L.A.P. Leme, F.B. Pinto, and N. Sanchez-Pi, Mas for alarm management system in emergencies, inIBERAMIA (2012), pp. 712–721.

[25] A.C.B. Garcia, L.A. Portes, F. Pinto and N. Sanchez-Pi, Real-time alarm management system for emergency situations, inModern Advances in Intelligent Systems and Tools (W. Ding,H. Jiang, M. Ali, and M. Li, eds.), vol. 431 of Studies in Com-putational Intelligence, pp. 9–18, Springer Berlin Heidelberg,2012.


Top Related