Big Picture User Experience
As an integrator of 3rd party alarm analysis tools, I need a way to group all events that relate to an alarm together. I need this so that I can create views that describe the progression of the alarm with times. I need this sot hat I can calculate various metrics around alarm handling.
My 3rd party alarm analysis tool is used to report on many different metrics, many if which are in the PHMSA regulations. Those that are the hardest to create for Enterprise SCADA are those that are time based, as in, time spent in alarm or in a particular alarm state (like HI vs HiHi):
Time to ack
fleeting alarms
chattering alarms
time in alarm
time to acknowledge
It should be noted that there are many other alarms metrics that do not depend on the time spent in the various alarm states, like, alarms per hour per console in a shift.
Detailed Description
Events are logged whenever the following happens:
Alarm is created
Alarm transitions between states (e.g. Hi to HiHi) in the same category (e.g. HILO category)
Operator acknowleges the alarm
The point Returns to Normal (RTN)
What is needed is a way to group these events and pivot them onto a single row that can then be used to calculate the various times spend in various states.
There will be some metrics that are common (regulatory) and some that are unique to the customer. By providing the grouping, integrators can create the views and pivot needed for each metric.
Eventually, perhaps the product will ship with those views that are most common, likely those required by the larger regulatory bodies.
Acceptance Criteria
It is possible to use SQL to group and pivot these events as needed, without the need for external parsing and searching tools.
Business Value
Alarm analytics is becoming increasingly important as Pipeline operators are expected to report on the ergonomic
Out of Scope
Assumptions
Alarm IDs is often mentioned as a potential solution.
We will stop adding meta-data to the alarm message field.
Dependencies
Alarm dictionaries, internationalisation of already written alarm events.
Future desire to continue to unpack the alarm message string into proper columns - e.g. test mode, as the next step after we establish the mandate of no longer adding meta-data to the alarm message field.
While not a dependency for our scope, 3rd party alarm management tools are the main consumer of this data, and the goal is to reduce as much as possible any project work required to "unpack" or de-normalize event data into "landing tables" for these interfaces.
