Your SlideShare is downloading. ×
201201 ureason introduction to use
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

201201 ureason introduction to use


Published on

General introductionto USE - UReason Solution Environment (USE). For more information visit

General introductionto USE - UReason Solution Environment (USE). For more information visit

Published in: Technology, Business

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Introduction to UReason Introduction to USE
  • 2. 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”.
  • 3. 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
  • 4. Products of UReason
    • USE, OASYS-AM, UDesign : Based on Common Product Platform
  • 5. USE – UReason Solution Environment Engineering environment for companies wanting to create intelligent solutions Engineers “Expert Toolbox”
  • 6. 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
  • 7. 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
  • 8. 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.”
  • 9. 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 systems
    • On-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
  • 10. 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
  • 11. USE Typical Environment Raw Data Processing External System DCS, SCADA, Historian, PLC External Systems Interface End User Interface Raw Event Processing Process Model Event Services Reasoning OPC DA OPC A&E Process Variables Raw Events Domain Objects Domain Topology Event Management/handling Engineer Interface ODBC … . Developer User Thin client Thick client Licence/Mode: Engineering Thick client Data Reduction Rules Event Reduction Rules State Engines Event Fault Trees Process Diagnostics Data Validation Event Correlation Decision Support Rules
  • 12. USE - From Data to Point Solutions Data Handling Model(s) Rules Results Step 1 Step 2 Step 3 Step 4 Deploy & Maintain Solution Step 5 Data Access & Processing
    • Step 1 – Access to Process and/or Alarm and Event Data
    • Add-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
  • 13. 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
  • 14. 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
  • 15. 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 Large
      • 200 – 20.000 IO
    • With and without failover
  • 16. USE - From Data to Point Solutions Data Handling Model(s) Rules Results Step 2 Step 1 Step 3 Step 4 Deploy & Maintain Solution Step 5 Map data to Object Model
    • Step 2 – Models: represent a part of the environment a USE solution can analyse
    • Models 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
  • 17. 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
  • 18. 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
  • 19. Model Example
    • Siemens APSS (I&S)
    • Model =
      • Units/Equipment/Sensors
      • Logical Model of Scenarios
        • Wind directions
        • Sensor groups
  • 20. USE - From Data to Point Solutions Data Handling Model(s) Rules Results Step 3 Step 1 Step 2 Step 4 Deploy & Maintain Solution 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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)
  • 25. Configuring Rule Blocks
    • General concept: drag-drop-connect-configure
    • Connecting 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
  • 26. Configuring Rule Blocks
    • Some rule blocks provide special purpose editors for configuration and/or viewing run results (in real-time)
  • 27. 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
  • 28. USE - From Data to Point Solutions Data Handling Model(s) Rules Results Step 4 Step 1 Step 2 Step 3 Deploy & Maintain Solution 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
  • 29. Results Example - Events
  • 30. 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
  • 31. 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)
  • 32. 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
  • 33. 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
  • 34. USE - From Data to Point Solutions Data Handling Model(s) Rules Results Step 5 Step 1 Step 2 Step 3 Deploy & Maintain Solution 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
  • 35. Some Examples
    • Following slides contain some examples of applying UReason technology and services
  • 36. 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 IA
    • A&E Historian: TiPS LogMate
    • Alarm Reporting: OASYS-AM
    • Advanced Alarm Management: OASYS-AM
    Alarm reduction on 4 platforms, Visionary Approach for Centralized Control Room
  • 37. Overview of the reduction realized, varying between 30% – 65% 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 DeltaV Data: TiPS LogMate Emerson OPC Advanced Alarm Management: OASYS-AM
  • 38. 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
  • 39. 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 CS Historian: SQL Server
  • 40. 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
  • 41. 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
  • 42. Siemens - PIMAQ
  • 43. Siemens - PIMAQ
  • 44. 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 life
      • Runtime lifetime varies between 50 days avg to 1500 days.
    • Consequences of losing an ESP
      • Product Loss/Deferment
      • Expensive to Pull and Replace
  • 45. 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) Generic Means: The Same Solution can be applied over-and-over again to 1 or Many ESPs
  • 46. 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
  • 47. Drinking Water Purification Simulator
    • Simulator
      • Object model
      • Hydraulic model
      • Water quality model
      • Control model
  • 48. Water Purification Simulator USPs
    • Technologies: USE + external models from partners
    • Unique selling points:
    • Developed in conjunction with water companies and other industrial partners
    • Generic simulator provides Custom-off-the-shelve simulator
    • Specific 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 evaluation
    • Education
    • Virtual commissioning of process automation system
    • Testing of control strategies
    • Process-control improvement
    • Water quality improvement
  • 49. 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.
  • 50. 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
  • 51.
    • Contact Details:
    • UReason Leiden
    • Pompoenweg 9
    • 2321DK Leiden
    • 071-5281700