Slide 1

WW HMI SCADA-02Discover the new Alarmimprovements delivered inWonderware System Platform 2014

Rob KambachProduct ManagerPlatform and AppServer

@InvensysOpsMgmt / #SoftwareRevolution

/Wonderware

/WonderwareHMI

social.invensys.com

© 2013 Invensys. All Rights Reserved. The names, logos, and taglines identifying the products and services of Invensys are proprietary marks of Invensys or its subsidiaries.All third party trademarks and service marks are the proprietary marks of their respective owners.

Rob KambachProduct ManagerPlatform and AppServer

/Wonderware

/Group - HMI/Scada/AppServer

Current state around alarming

Configured alarms per operator

Number of Alarms an operatorcan theoretically respond to

Slide 3

10 per minute per operator

Why did the number of alarms increase?

• Automation evolution (including fieldbus) brought more

accessible information per sensor/actuator

• Alarms are easily configurable now (no more wired) ->

no real cost at engineering or operating time to add alarms

• People (SI/EPC) tend to believe more is better: nothing can

happen without noticing if everything has an attached alarm

Slide 4

• Automation evolution (including fieldbus) brought more

accessible information per sensor/actuator

• Alarms are easily configurable now (no more wired) ->

no real cost at engineering or operating time to add alarms

• People (SI/EPC) tend to believe more is better: nothing can

happen without noticing if everything has an attached alarm

Typical observed behavior

Operator overload leads to :

• Over-acknowledgement to keep managementhappy and control room quieter

• Inhibiting “noisy alarms”

• Missing important alarms

• Not being able to mitigate in proper time

Texaco Pembroke 1994

Slide 5

Operator overload leads to :

• Over-acknowledgement to keep managementhappy and control room quieter

• Inhibiting “noisy alarms”

• Missing important alarms

• Not being able to mitigate in proper time

Piper Alpha North sea 1988

Operators have too many alarms to manage

Slide 6

What can we do?

A set of standards and guidelines

EEMUA 191, Alarm systems a guide to design

Namur NA 102 Worksheet, Alarm Management

NPD YA 711, Principles for alarm design (Norwegianpetroleum doctorate slowly adopted throughout Europeas the standard)

VDI/VDE Guideline 3699 (process control using monitors)

ISA S18.02, Management of alarm systems for the processindustry

Slide 7

EEMUA 191, Alarm systems a guide to design

Namur NA 102 Worksheet, Alarm Management

NPD YA 711, Principles for alarm design (Norwegianpetroleum doctorate slowly adopted throughout Europeas the standard)

VDI/VDE Guideline 3699 (process control using monitors)

ISA S18.02, Management of alarm systems for the processindustry

ANSI/ISA 18.2Management

of AlarmSystems forthe ProcessIndustries

API RP-1167Alarm

ManagementFor Pipeline

Systems

Our VisionTo build a best of class Alarm System that is flexible, robust and

complies to all regulations.

Slide 8

What did we address so far…2014release..- Robustness, we developed a new storage mechanism that is

redundant.

- Severity, we introduced severities as a new indication 1-4

- Aggregation, we aggregate all active alarms throughout our objectmodel so @ any level you can see the current state.

- Introduced a new Animation called alarm border.

- Have pre configured alarm controls that go with the default cabfiles.

- Simplified workflow to store alarms from 21 steps to 1 to 2.

- Have new alarm widgets to use in graphics and navigation.

Slide 9

- Robustness, we developed a new storage mechanism that isredundant.

- Severity, we introduced severities as a new indication 1-4

- Aggregation, we aggregate all active alarms throughout our objectmodel so @ any level you can see the current state.

- Introduced a new Animation called alarm border.

- Have pre configured alarm controls that go with the default cabfiles.

- Simplified workflow to store alarms from 21 steps to 1 to 2.

- Have new alarm widgets to use in graphics and navigation.

What is still to come after 2014

- Global Alarm Shelving based on time and operational permissions.

- State based suppression.

- Flexible messaging

- Navigate from alarms to graphics

- Extend alarm primitive to the field

- Simple KPI index based on EEMUA

Slide 10

- Global Alarm Shelving based on time and operational permissions.

- State based suppression.

- Flexible messaging

- Navigate from alarms to graphics

- Extend alarm primitive to the field

- Simple KPI index based on EEMUA

Storage robustness.Support for- Redundant Engines- Store forward- Redundant Historians- Simplicity, no configuration required.

Slide 11

Architecture Historical

Configured for Hist_02

Configured for Hist_01

Auto_Failover

Slide 12

Configured for Hist_02

Double redundant Historical A&E logging, Application Engines and Historians

Architecture RTAlarm Hot Backup Manager supports Alarm platforms as providers

Slide 13

• Alarm Manager increased memory, modifiable through registry• Fixed the Microsoft session 0 issue that got introduced in Vista,So now multiple Alarm Managers can run as a service.

Simplicity of loggingCheckboxes in the Alarm Severity list of the IDE determine if Alarms get logged.If Historian is defined, no further action is needed.

Slide 14

The Old Process had 17 – 21 error prone steps.Changes in Functionality:• If an alarm is silenced it will still log state changes to the A2ALMDB• New DB A2ALMD to allow easy upgrades DB gets auto created, schema unchanged• Supports domain security and OS based security• Granular, event messages can be turned off

Migration• When moving from new to old typical the alarm DB logger logs

alarms to the WWALMDB, the new DB is called A2ALMDB.

• So systems can co exist and alarm logging for new systems is formigrated systems by default turned off.

• Although the name A2ALMDB is fixed and gets installed by theHistorian configurator, the file name is chosen in a way so the nodename is part of the DB name.

Slide 15

• When moving from new to old typical the alarm DB logger logsalarms to the WWALMDB, the new DB is called A2ALMDB.

• So systems can co exist and alarm logging for new systems is formigrated systems by default turned off.

• Although the name A2ALMDB is fixed and gets installed by theHistorian configurator, the file name is chosen in a way so the nodename is part of the DB name.

• DB Schema did not get changed in this release.

Global Priority to Severity mapping

Slide 16

One location to change and customizable image…

Default Alarm Border Icons

Global defined styles for alarm colorsand borders.

One place to change all apps how they represent Alarms

Slide 17

Alarm Border animation.

Global Icons

Global Styles

Auto Configuration for Field_Attributes or objects

Runtime

Slide 18

Simplicity and IT compliance clientsWindows integrated security can be used

Slide 19

Windows account security (domain based)

Updated Clients- Historical• Defined with the standard Themes and Styles colors• Fonts best Practices HMI Standards• Dynamic Filter tabs• Group By functionality

Slide 20

Update Clients - Runtime• Tabbed filtering• Actual alarm indicators on Tabs• Ack buttons• And styles and themes setup as default

Slide 21

Severity Indication in Runtime andHistory mode within the ALM Grids

Slide 22

Widgets for Alarming

Area Indicator Object or Device Indicator Nav Button Indicator

Slide 23

Field Attribute or reference details

Platform Alarms customizable.

Ability to switch of or change the priority of a Platform comm. alarm

Slide 24

Ability to switch of or change the priority of a Platform comm. alarm

Thank you!Open for Questions

Slide 25

Slide 26