Alarm Acknowledge audit Merged

1.Background

The customer has developed and will maintain unique alarm management paradigm where the system does not replace persistent alarm after the state has changed. As a result, alarms that were generated by the SCADA system will be visible on the alarm summary until SCADA operator acknowledges them one-by-one.

Note: This functionality is beyond the scope of this document and will be implemented by the Delivery organization as a custom solution built on top of AVEVA’s Enterprise SCADA system.

In SPLC current system, when alarm acknowledge event is recorded, the message of the event contains date/ time, severity and the current value that caused the alarm.

As such, capturing the original time stamp, message and severity of the original alarm enables the customer to associate the acknowledgement event to a specific alarm that was acknowledged.

In comparison, in current AVEVA’s baseline Enterprise SCADA system, alarm acknowledgement event captures only the original alarm message.

As such, due to the nature of AVEVA’s alarm management paradigm, alarm acknowledgement events can only be relating to the last alarm raised and does not provide a direct indication to the alarm acknowledged. When the events are reviewed, the acknowledgement event can only be inferred to alarm that was acknowledged

2. Big Picture User Experience

This enhancement request aimed to improve the auditing capabilities of alarms. The functionality requested is to include in the alarm acknowledgement event message the original date/time and the severity of the original alarm that was acknowledged. This will enable at auditing time, to evaluate which alarm the SCADA operator acknowledged has acknowledged.

3. Detailed Description

3.1. Enhancement of alarm Acknowledgment event message

The enhancement request is to amend the current alarm acknowledgement event message to include the timestamp and severity of the alarm that is being acknowledged. This enables at audit time, to correlate the alarm acknowledge event to a specific alarm acknowledged.

3.2. General Acceptance Criteria

1. In addition to the current alarm acknowledgement event message, the message shall include the original date/time and alarm severity of the acknowledged alarm.

4. Business Value

Improves auditing capabilities by establishing clear association between alarm event and acknowledgement event. Rather inferring the association based on last alarm message.

5. Customer, Project, and Deadline Details

Number of customers (names/projects) that will consume this

• Shell (SPLC) will use this feature.

Deadlines and Commitments

• Shell is expected to be the first consumer of this feature.

• Shell project kick-off is Q2-2022.

• Project team may need to start with ES2022-R2, and upgrade mid-flight to ES2023 in Q1-2023

Commercial and/or Contractual Impacts

• Commitments to SPLC have been made to have this feature.

6. Out of Scope

Can’t think of anything

7. Assumptions

• Assuming TiPS will not be affected by this change, if so, please make note of how.

8. Dependencies

• Can’t think of any.

9. PSR - Performance, Scalability, Resilience

• No alarm degradation shall be observed.

10. NFR – Non-Functional Requirements

1. Properly documented in user documentation.

11. Risks/Mitigations

None identified

12. Use cases

12.1. Alarm auditing

As a SCADA Safety Analyst, I want to inspect the audit log to know how long it took for SCADA Operator to acknowledge the alarm so that I can determine if current operational process needs to be improved if the alarms are not acknowledged in timely manner based on their severity.

Note: The customer has a procedural guidance stipulating the time alarm MUST be acknowledged by the set time frame from generation for each alarm severity. The auditing of this time between alarm generation and acknowledgment safety related process that the customer conduct to verify their operators are operating within guidelines.