201201 ureason introduction to use

Introduction to UReasonIntroduction to USE

Achieving Operational Excellence

UReason is

Anglo-Dutch Company with offices in Leiden, Maidenhead and Paris

Delivers real-time applications and solutions in the area of Operational Excellence

Customers in Europe, North-America and Middle-East. Industries: Oil & Gas, (Petro)chemical, Traffic, Energy and Utilities

“We Combine our Expertise and Technology with that of our

customers to improve Operational Excellence”.


Customers of UReason

Operational Advisories:– Sabic– DSM– Remote Surveillance:

• Siemens Power Generation• Vestolit• Shell Global Solutions/NAM

Alarm Management:– BASF– BP– KPE– OMV– Siemens Oil & Gas– LyondellBasell– Total E&P– Anglian Water

Simulation:– WaterSpot: DZH/PWN/Waternet

/ABB/DHV/Vitens/TU-Delft– DISCONTO: PWN/DHV/TU-Delft/RIVM/

Vitens/Dunea/Brabant Water

Active Participant in:

• ANSI/ISA S18.02 Standard• ISA S18.02 TR Development• EEMUA 191 Guideline


Products of UReason

USE, OASYS-AM, UDesign : Based on Common Product Platform

OPC DA ODBC/JDBC Webserver CSV

Process Device Fuzzy Logic Scripting EPDA

Restricted Version Of Product A

Product BProduct A

Product Platform

Visualization Components Intelligent Components

License Components Offline Data Configuration

Co

mp

on

en

tsA

dd

-in

s &

E

xte

nsi

on

sP

rod

uct

s &

So

lutio

ns

Product C

OEM Solution Based On Product A

VAR Version of Product B

AnomalyDetection

Serial Port

FFT LogicDesign

Product C (Customer X Edition)

Neural NetsAnomaly Detection

New Product For Customer X

?

?


Engineering environment for companies wanting to create intelligent solutions

Engineers “Expert Toolbox”

USE – UReason Solution Environment


USE – USP / Benefits

Unique selling points:Out-of-the-box functionality– Interfaces – Data-storage – Rules– Explanation facility – Web access– Model based reasoning and

management– Structured approach– Generic (write once, reuse)

Customer (typical solution provider) benefits:– Reduced engineering time– Easy integration with a wide variety of underlying automation systems


OASYS-AM – Intelligent Alarm Management

Supports organisations in their alarm management, from reporting to dynamic reduction and intelligent predictive

alarming

– Play-back Incidents and upsets– Identify states, causes & effects– Induce rules from pattern mining– Intelligent Alarm engineering

– Reduction rules, cause-effect trees, – State detection diagrams, etc

– Provide advisories (alerts) – Reduce alarms in real-time– Tune operational advisories – Monitor operator actions – Generate EEMUA standard reports


OASYS-AM - USP / Benefits

Unique selling points- Solution covering full scope: from alarm management, over

engineering of logic to reduce and predict alarms to real-time alarm handling (hiding, diagnostics, early event detection)

- Out-of-the-box functionality results in reduced engineering (configuration), installation and interfacing efforts

- Supplier independent, works with all major DCS and SCADA systems

Customer benefits (typical end-user):- One-stop-shop for complete solution + required services if needed- Reduced alarm load enables reduced staffing (up to unmanned

operations)- Technology enables dealing with increasing complexity of

automation, control and safety systems- Best practices (procedures, diagnosis, predictions) put into action,

24x7- Reduced cost of ownership as the customer can maintain and

extend the application and some maintenance work can be automated

OASYS-AM has strong presence in Oil and Gas Markets, where costs of poor alarm management are high:

– Unplanned trip due to a missed alarm: €400.000– Trips about one a day on a new plant which could be prevented if

there were less nuisance alarms– Release of gas resulting in complaints– ARC ARC-Strategies April 2002 - “A CCM application can add 5% or

more to the profits of a manufacturing plant by detecting and avoiding critical conditions before they occur, thus reducing the need for emergency shutdowns.”

Alarm KBLMFW

Product A

Alarm Data

Alarm Configurations

Chattering Alarms

Eclipsing Alarms

Alarm Patterns

Alarm Causalities

Alarm Reduction Rules

Live Alarm Data

Alarm Settings

Reduced Alarm Data

Operator(s)

Process Control Engineer/Technologist

New Rules Reduction Achieved

Alarms Configurations

EquipmentFailure

Human Errors

Control failure


UDesign – Design Validation Environment

Combines the on-line rule engine and simulation capability of UReason’ intelligent platform, with the ability to capture and validate engineering designs

Functionality is especially focused on replacing legacy paper-based design workflow

Superior design tools – Huge increase in productivity when compared to

legacy computer or paper based systems – Better design, less mistakes– Complies with IEC 61131-3 definition for visual

definition of logic systemsOn-demand Simulation

– Validated design BEFORE handover, leads to huge reduction in rework and engineering time.

– Can easily be linked up to real-IO and alarm generation for end-to-end validation

Customized workflow– Matches customer needs, aids acceptance, leads

to roll-out adoption– Use UReason’s Product Platform so can be easily

adapted to customers workflow/design process


Common Product Benefits

Goal: Optimise production, reduction of process upsets & disturbances

ROI: Complying with state laws/regulations– Safety/security potential reduction of insurance premiums– Preventing upsets emission reductions, avoiding production losses– Reducing information overload less operator stress, avoiding burn out of

most valuable resources– Maintaining licence to operate avoid destruction of capital, avoid

equipment damage

ROI: Lower cost of ownership– Reduction engineering time– Ties into preventive maintenance– Ties into asset management

Contributes to operational excellence


USE Typical Environment

Raw Data Processing

External System

DCS, SCADA, Historian, PLC

External Systems Interface

End U

ser Interface

Raw Event Processing

Process Model Event Services

Reasoning

Da

taR

ed

uctio

nR

ule

s

Eve

nt

Re

du

ction

Ru

les

Sta

teE

ng

ine

s

Eve

nt

Fa

ult T

ree

s

Pro

cess

Dia

gn

ostics

Da

ta

Va

lida

tion

Eve

nt

Co

rrela

tion

OPC DA OPC A&E

Process Variables Raw Events

Domain ObjectsDomain Topology Event Management/handling

Engineer Interface

De

cision

Su

pp

ort

Ru

les

ODBC….

Developer UserThin client

Thick client

Licence/Mode:

Engineering

Thick client


USE - From Data to Point Solutions

DataHandling

Model(s) Rules Results

Step 1 Step 2 Step 3 Step 4

Deploy & MaintainSolution

Step 5

Data Access & Processing

Step 1 – Access to Process and/or Alarm and Event DataAdd-ins are available to access data from various data sources such as file, databases and automation layers

– File – CSV– Databases – ODBC/JDBC Compliant– Automation Layers - OPC Data Access


Data Handling

Historical data can be played back at normal or increased speeds

Data has– Validity Status – determined

by data processing rules– Expiry Status – determined by

ExpirationPeriod settings

Data Processing Rules can be used to calculate replacement values for missing data, invalid data or derived data

History of data processed can be kept for RT trending


Configuration

Setup of IO can be done automatically

– F.ex. In case of IO from an OPC DA, files can list the OPC Items and configurations to use (instantiate)

Special – OPC Servers instances Simulation Mode – allows you to feed tag data for OPC Items from file

– Often used to run historical data through a solution for FAT/SAT


Examples

Database Access– SQL Server

• Wonderware InSQL• Yokogawa Exaquantum

– Oracle– MySQL

OPC Data Access– Honeywell TDC3000, Experion– Emerson Delta V– ABB 800x– Invensys IA– Siemens S7 PLC– OSISoft PI– Kepware– Matrikon– Siemens WinCC– Wizcon– Etc. etc.

Small – to Large200 – 20.000 IO

With and without failover



DataHandling Model(s) Rules Results

Step 2Step 1 Step 3 Step 4


Step 5

Map data to Object Model

Step 2 – Models: represent a part of the environment a USE solution can analyseModels consist of the structure and behavior of the domain being analyzed:

– The structure describes the components (objects) in the domain and how they are interconnected and aggregated

– The behavior consists of the relationships between the inputs and outputs of the components and their aggregates

No Coding, compiling or linking classes can be

created (and instantiated) on the fly

OO Models with connectivity and containmentship


Model Example

E.g. when modeling a manufacturing process:

– Each component in the model will be classified: A Pump, A Compressor, A Pipe, etc

– Interrelationships (connections) between each unit/process would be defined: Pump P1F has one stream input, one stream output, one power connection

– Links to live/simulated data sources/sensor readings to attributes of items in the model would be set up: the flow rate of Pump P1F connected to OPC TAG P1F237

Component

Relationship

Live/SimulatedData


Classes

Basis for constructing Models are classes that represent the items you wish to diagnose or analyse

Classes can be defined for Domains or specifically for Scenarios

Classes are the templates (blueprints) for the objects (instances) you require in your model

A Class Definition can have:– Fields: e.g. the Level of the Tank – Representation: e.g. a Tank looks like an open rectangle– Animation: e.g. when the Level of the Tank is above 50 the

Tank highlights red– Instances: e.g. our Domain has two Tank instances: Tank302

and Tank303


Model Example

Siemens APSS (I&S)Model =

– Units/Equipment/Sensors– Logical Model of Scenarios

• Wind directions• Sensor groups






Step 5

Data & Model Driven Rules

Step 3 – Setup the rules that:– Detect certain unwanted symptoms/events– Diagnose possible root causes– Predict failures

USE contains an set of Rule types and Rule blocks to setup the solution logic

Good Model Pays Off Allows for Generic (Model Based) Rules


Setup the Rules

Rule Definitions allow you to:– Detect abnormalities– React upon certain events– Further analyse a

hypothesis by questioning users when problems arise

– Pro-actively predict certain events

– Etc. etc.Rule Definitions can work with models and use the relationships defined to reason with:

– Use containmentship– Use connections


The Rules

Different Rule Types– Data Validation Rules, – Data Reduction Rules– Event Reduction Rules– Symptom/Cause Rules– State Diagrams/Event Fault

Trees– Decision Support Rules

Libraries of rule blocks– Depending on the type of rule

you construct different palettes are available containing the building blocks for a rule

– Palettes available are rule context sensitive

– Add-ins installed can extend the palettes available – i.e. extend the available rule functionality of an installation


General Concepts

Rules can be seen as data flow diagrams

– Building blocks for these ‘diagrams’ are cloned of Palettes

– Diagrams can have layers – depth depends on the Rules Blocks used

Connections in rules follow a ‘syntax’:

– You can connect like to like

– Object connections accept ‘all’

Rule definitions are active or not active (installed/de-installed)

Contains detail


Categories

Categories of Rule Blocks:– Calculations

• Maths• Statistics

– Logic/Flow• Boolean blocks• Gates & Toggles

– Model Operations• Containmentship,

Connectivity, Type Checking, Object values, Parent Objects etc.

– Events• Event Generation• Event Triggering• Mail notification

– Specials:• Decision Support Agent• Topology Agent• State Transition Diagrams• Animation• Fault Tree Definition

Standard Functionality– 60+ Palettes (no Add-ins installed)– 300+ Blocks (extended each

release)


Configuring Rule Blocks

General concept: drag-drop-connect-configureConnecting rule blocks – follows connection syntax, typed connections for:

– Booleans– Conclusions– Events– Numbers– Objects– Strings

Most rule blocks are configured through their Properties

– Nearly all rule blocks provide descriptions on general use and configurations


Configuring Rule Blocks

Some rule blocks provide special purpose editors for configuration and/or viewing run results (in real-time)


Adding Rule Blocks

Using the Scripting Block– Variable inputs, outputs– JavaScript executes

block’s function– Depending on the use can

be incorporated into a Reusable Rule Block Definition

– Available in Add-in: UScript






Step 5

Results

Step 4 – Results of Rule Execution can be: – Events – within the USE environment– Email – if SMTP access is available– Control (writes) via ODBC/JDBC, OPC or

custom interfaces

Results can be validated prior to deployment using

– The build in Simulator– The Rule Validation Add-in


Results Example - Events


Event Lifecycle

Events have a life-cycle, they are:

– Created– Used/Referenced– Changed/Stored– Disposed

The lifecycle of an Event is influenced by:

– The User• Acknowledge an Event,

deletes an Event etc.– The Environment for which

the Event was generated• Event text changes• Condition that raised

event no longer exists


The Simulator

USE includes a feature that allows you to playback, at increased speed, known incidents stored in Data and Event Logs

– The Simulator is helpful to test rules, rule strategies and analyse or diagnose past incidents

– Log Processing Rules have special configurations to allow you to use exactly the same timestamps as used in your data and event logs (WaitForActualStartTime)

Results for specific simulations can be analyzed separately (the system is Simulation Run aware)


Rule Validation Add-in

The Rule Validation Add-in allows you to graphically analyse events, generated by rules, for a given model object for datasets


Analysing Rule Results

Further to the Rule Validation UI logging and a graphical rule debugger assist the engineer in troubleshooting/analysing results

The Debugger allows you to graphically debug a Rule Definition (Query, Detect, Inform, Action)

– When debugging a rule is ‘configured’ to support looking at the rule’s execution state(s) and stop at the Breakpoints you define (toggle)

– You can set a breakpoint in your rule schemes to halt execution on a specific element, immediately before it is executed



DataHandling

Model(s) Rules Results



Step 4

Deployment

Step 5 – Point Solutions developed can easily be deployed and maintained

– Solution (IO/Model/Rules/UI) can be exported/loaded onto deployment hardware

– UI Setup & User Support build in• Thick UI can be setup for controlling users• Thin UI for surveillance users

– Build in change tracking, for deployed solutions (know what has changed)

– User can provide in-line feedback to generated events using annotations

BUILD IN ADVISORIES


Some Examples

Following slides contain some examples of applying UReason technology and services


Example: Northsea Gas producer

Scope of Supply:- Alarm Management Survey- Philosophy Development- Support Alarm Rationalization- Performance Auditing- Advanced Alarm Management System for Onshore Centralized Control Room

DCS: Foxboro IAA&E Historian: TiPS LogMateAlarm Reporting: OASYS-AMAdvanced Alarm Management: OASYS-AM

Alarm reduction on 4 platforms, Visionary Approach for Centralized Control Room

Alarm reduction on 4 platforms, Visionary Approach for Centralized Control Room


Overview of the reduction realized, varying between 30% – 65%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

300 Board Reduced 600 Board Reduced 800 Board Reduced All Boards

Next generation alarm management

Example: LyondellBasell

Scope of Supply:- Rule Discovery from Historical Data- Alarm Display Replacement- Alarm Predictions in Control Room

Corporate Agreement – Advanced Dynamic Alarm Management

DCS: Emerson DeltaVData: TiPS LogMateEmerson OPCAdvanced Alarm Management: OASYS-AM


Example: Chemical Plant Germany

Proactive 24x7 information on gas leaks

Vision/Smell & Sound Sensors Combined

Operators don’t have to do a 12 hours plant inspection

Important for keeping licence to operate

Operator Advisories

Interfaces: Emerson, ABB, Siemens


Example: Refinery Netherlands

Scope of Supply:

- Alarm & Event Historization- Alarm & Event Reporting- Alarm Awareness Workshops - Alarm Philosophy Development- Master Alarm Database- Alarm MOC

DCS: Honeywell TDC, Foxboro IA, Yokogawa CSHistorian: SQL Server


Example: Refinery Netherlands

Scope of Supply:

- Consultancy - Alarm Awareness Workshops - Alarm Philosophy Development- Setup Master Alarm Database- Vendor Selection

- A&E Historization- A&E Reporting- Master Alarm Database & MOC

DCS: Honeywell TDC, HIMA/MagLog ESD


Siemens – Process Real-Time Historian PIMAQ

SISOG PIMAQ System Embeds OASYS-AM

PIMAQ Examples:- Maersk Al-Shaheen FDP 2000- Maersk Al-Shaheen FDP 2005- Maersk Halfdan- Petrobas FPSO Piranema- Venture Oil FPSO Hummingbird- Statoil Snorre A, Snorre B- ConocoPhillips EldFiks- Hydro Njord A & B


Siemens - PIMAQ


Electrical Submersible Pump (ESP) Monitoring

About 15 to 20 percent of almost one million wells worldwide are pumped with some form of artificial lift more and more employing electric submersible pumps

ESPs operate under varying working conditions: High temperature High pressure Scaling/Waxing

…and have a short lifeRuntime lifetime varies between 50

days avg to 1500 days.

Consequences of losing an ESP– Product Loss/Deferment– Expensive to Pull and Replace


Electrical Submersible Pump (ESP) Monitoring

Generic EED & RCA:– Sand Production– Surface Choke– Tubing Leak– Scaling

Specific EED & RCA:– Location Specific– Pump Configuration

Specific

Early Event Detection (EED) and Root Cause Analysis (RCA)Early Event Detection (EED) and Root Cause Analysis (RCA)Generic Means:

The Same Solution can be applied over-and-over again

to 1 or Many ESPs


Proactive Asset Management (Water)

Achieved by highlighting variances in normal operating parameters e.g. pump flow, level, etc:

– E.g. Pump performance degradation, number of stop and starts of the pumps can be used in combination with the number of hours running during a day to determine if a pump is degrading

Inferential measurement and sensor validation which identifies drift on process plant requiring subsequent intervention

– difficult-to-measure parameters can be derived from existing instrumentation. This type of information can be used to track BOD, COD or bacteriological load on-line and so improve consent monitoring and remedial action to ensure consent compliance.

– E.g Inlet flow and suspended solids can be used as model inputs to predict BOD with reasonable accuracy


Drinking Water Purification Simulator

• Simulator– Object model– Hydraulic model – Water quality model– Control model


Water Purification Simulator USPs

Technologies: USE + external models from partners

Unique selling points:Developed in conjunction with water companies and other industrial partnersGeneric simulator provides Custom-off-the-shelve simulatorSpecific simulator can easily be tailored to customer’s processes¼ of the price of a simulator in chemical, oil & gas

Benefits for the customer (water company – engineering agency)Training of operators, regional managers

(off-line)On-line evaluationEducationVirtual commissioning of process

automation systemTesting of control strategiesProcess-control improvementWater quality improvement


Water Safety – Long Term NL Funded Study

Distribution, Control Training and Operations

– Understand the relevant chemical and microbiological processes in the distribution network.

– Develop water quality models to predict quality parameters

– Assess water quality in the whole network to prevent public health risks

– Develop a scenario based calamity simulation system to experiment and understand acute changes in water quality.

– Use calamity simulation to train and educate operators in handling events.

– Deploy real time state of the art water quality sensors.

– Use model integration between process automation system and simulator/models for consistency and efficiency.


Proactive Asset Management General

Using UReason’s Technology : General Statements– Generic Rules can be defined for each asset type

• i.e. implemented once but valid for all the sites using the same asset type

– Can easily integrate with DCS/SCADA, backend systems and alarm databases, etc to infer asset state from different data sources

– Rules filter bad data– Rules can apply state based reasoning;

• e.g. take into account site criticality, site location, time of the year, relation to other assets

– Integrate asset criticality register– Results can be pushed to extend alarm information and/or

influence Maintenance management systems


Contact Details:

UReason LeidenPompoenweg 92321DK Leiden071-5281700www.UReason.com

201201 ureason introduction to use

Technology

Transcript of 201201 ureason introduction to use