oasys dna and control room management compliance …

Updated May 15, 2014

OASyS DNA and Control Room Management

Compliance Statement

OASyS DNA and Control Room Management Schneider Electric Compliance Statement | 2 Updated May 15, 2014 Proprietary and Confidential to Schneider Electric

1 OASyS DNA and Control Room Management

Executive Summary

This document describes how OASyS, specifically the current release – Columbia (and earlier releases using the Smart Client Architecture - ezXOS, XE and ADE) helps pipeline operators comply with the PHMSA CRM regulations for gas and hazardous liquid pipelines under 49 CFR Parts 192 and 195, respectively. Schneider Electric’s active participation with the various industry trade associations, regulatory agencies and direct customer feedback has provided us with valuable input necessary to position our products to meet the objectives of control room management and other industry best practices.

Each operator’s control room management plan must describe how they will comply with every element of the rule and ensure they can provide records that demonstrate compliance with their plan. SCADA technology can, and does play a major role in the management of any control room and as such, pipeline operators must ensure that their CRM plan is supported by their SCADA system in production.

OASyS has many control room management capabilities that support compliance with an operator’s CRM plan. The rest of this document describes the PHMSA regulatory requirements and how OASyS supports compliance.

Schneider Electric is committed to continue to enhance our products to make it easier to comply with these and other evolving regulations and to give operators the tools they need to operate their pipelines as safely as possible.


2 OASyS and Control Room Management Requirements

The following section contains the text of the CFR 49 Control Room Management regulation followed by information describing how OASyS helps to comply with the requirements.

49 CFR Parts 192 and 195 Pipeline Safety: Control Room Management/Human Factors; Final Rule, June 16, 2011

(a) General

(1) This section applies to each operator of a pipeline facility with a controller working in a control room who monitors and controls all or part of a pipeline facility through a SCADA system. Each operator must have and follow written control room management procedures that implement the requirements of this section, except that for each control room where an operator’s activities are limited to either or both of:

(i) Distribution with less than 250,000 services, or (ii) Transmission without a compressor station, the operator must have and follow written procedures that implement only paragraphs (d) (regarding fatigue), (i) (regarding compliance validation), and (j) (regarding compliance and deviations) of this section.

(2) The procedures required by this section must be integrated, as appropriate, with operating and emergency procedures required by §§ 192.605 and 192.615. An operator must develop the procedures no later than August 1, 2011 and implement the procedures as noted above.

(b) Roles and Responsibilities.

Each operator must define the roles and responsibilities of a controller during normal, abnormal, and emergency operating conditions. To provide for a controller’s prompt and appropriate response to operating conditions, an operator must define each of the following:

(1) A controller’s authority and responsibility to make decisions and take actions during normal operations;

(2) A controller’s role when an abnormal operating condition is detected, even if the controller is not the first to detect the condition, including the controller’s responsibility to take specific actions and to communicate with others;

(3) A controller’s role during an emergency, even if the controller is not the first to detect the emergency, including the controller’s responsibility to take specific actions and to communicate with others; and

(4) A method of recording controller shift-changes and any hand-over of responsibility between controllers.

OASyS Support of Roles and Responsibilities Requirement

OASyS uses the login authorities established in active directory to help pipeline operators manage roles and responsibilities established by their procedures. An example of this is using the security permissions within OASyS to allow certain a level of controller to change alarm limits while restricting others. OASyS “Areas of Responsibilities (AOR’s) further help to manage a user’s defined roles and responsibilities by limiting what they can view and control.


(c) Provide Adequate Information.

Each operator must provide its controllers with the information, tools, processes and procedures necessary for the controllers to carry out the roles and responsibilities the operator has defined by performing each of the following:

Implement sections 1, 4, 8, 9, 11.1, and 11.3 of API RP 1165 (incorporated by reference, see § 192.7) whenever a SCADA system is added, expanded or replaced, unless the operator demonstrates that certain provisions of sections 1, 4, 8, 9, 11.1, and 11.3 of API RP 1165 are not practical for the SCADA system used;

Pipeline operators are required to assure that new SCADA displays and displays for SCADA systems that are expanded or replaced meet the provisions of the consensus standard governing such displays - API RP 1165. (Displays for gas pipelines are required to meet only some provisions of the standard). Operators will be required to validate the accuracy of SCADA displays whenever field equipment is added or moved and when other changes that may affect pipeline safety are made to field equipment or SCADA displays.


(c) Provide Adequate Information (1)

OASyS Compliance with API RP 1165

OASyS supports full compliance with API RP 1165. The recent addition of “Composites” in OASyS 7.5 DNA Extended Editor (XE) significantly reduces the effort and maintenance of OASyS displays to meet the API RP 1165 requirements. By using the API 1165 composites for analog and statuses along with the API RP 1165 symbol library that comes with OASyS 7.5, the data quality and symbols presented in the appendixes of API RP 1165 become a standard part of the display object definition. API RP 1165 states in section 6.3.4 – Layering that the alarm window should never be minimized and should remain “on top” of the stack if layering is utilized. OASyS ezXOS enables the user to configure the alarm window to prevent minimizing or dismissing, as well as to enforce that the window be “top most” which prevents other window from being layered on top of it. In addition to meeting the visual aspects of API RP 1165, OASyS also meets the administration requirements for display management of change (Section 11.4) As OASyS displays are stored as a file, they can be managed using various source control software applications (i.e. subversion) for documenting changes as well as recording verification information. OASyS supports the best practice of display building using a “Test & Development” environment. Once a display is ready to be deployed, it is transferred to the live system where a live update is triggered. The display then becomes active without any action required by the controller. The synchronization of new or changed displays needs to be properly managed to ensure that controllers do not suddenly get modified displays without being aware of the changes. In cases were a change is significant or affects the safety of the pipeline, additional training may be required before deploying to a controllers console. To facilitate the management of display synchronization, OASyS DNA 7.5 Columbia provides the “xossync” utility. This utility provides graphical indicators of which consoles have been synchronized with revised displays. The administrator can interactively select which console to synchronize as needed. Excel reports can be generated to capture the status of every consoles for managing and auditing purposes, confirming synchronization or identifying missing and out of date displays for all consoles across all systems. Schneider Electric can provide customers with an API RP 1165 “Self-Assessment Form” that will help identify areas that may need modifications for better compliance. The results of this assessment can be used to provide documentation to regulators that the practices outlined by API RP 1165 have been considered and implemented where possible. Some organizations have adopted the Abnormal Situation Management (ASM) guidelines for HMI’s. This display philosophy and best practice can be achieved with the XE, ezXOS applications The OASyS Smart Client Architecture provides the ability to use the Columbia display environment (ezXOS, XE and ADE) on pre 7.5 versions of OASyS.


(2) Conduct a point-to-point verification between SCADA displays and related field equipment when field equipment is added or moved and when other changes that affect pipeline safety are made to field equipment or SCADA displays;

Point-to-point verification means confirming that the input or output of each field instrument is accurately and reliably reflected in the SCADA information presented to the controller. Operators must document the actual field parameters, as measured in the field, and the corresponding SCADA display values as witnessed by a controller or SCADA administrator. The date and names of individuals involved in the verification should also be recorded as a means to help demonstrate thoroughness and authenticity. Alarm set-point values should also be checked at the same time.

Point-to-Point Verification Control Panel


OASyS and Point-to Point Verification

A “Point-to Point Verification” application is now available as an add-on to OASyS DNA 7.5 (Columbia) to help with this work flow. The point to point verification application provides a workflow for operators to document the field parameters as measured in the field, along with the corresponding SCADA display values as witnessed by a controller or SCADA administrator. Alarm set-point values can also be checked at the same time. The date and names of individuals involved in the verification are recorded as evidence to the authenticity of the procedure. Queries and reports can be generated to track verification progress.



(3) Test and verify an internal communication plan to provide adequate means for manual operation of the pipeline safely, at least once each calendar year, but at intervals not to exceed 15 months;

Gas pipeline operators are developing these plans as directed. Liquid pipeline companies are typically opting to shut down the pipeline when there is a total loss of SCADA, and documenting the shutdown and restart procedures as part of their operating procedures. (c) Provide Adequate Information (4)

(4) Test any backup SCADA systems at least once each calendar year, but at intervals not to exceed 15 months; and

In addition to testing your backup system, PHMSA is recommending you include procedures for an orderly evacuation of your control room in your plan. If an operator experiences an actual emergency or is required to operate from the backup center for any reason, this can be used to meet the backup test requirement as long as sufficient documentation of the activity is provided


(5) Establish and implement procedures for when a different controller assumes responsibility, including the content of information to be exchanged.


OASyS and Testing of Backup SCADA Systems The inherent distributed architecture of OASyS facilitates performing mode switches to test the availability and performance of any backup systems. Tests can vary from a partial test where polling is switched to the alternate location with controllers staying in the main control center, to a complete switch with controllers manning the back up for a period of time.

To provide records that demonstrate compliance with the backup testing, events that occur during the mode switch can be collected and additional CRM notes relative to the mode switch (i.e. Mode Switch Test Success) can be added to the events.


OASyS and Point-to Point Verification – Alarm Testing

By combining the information collected with the Point to Point application with CRM Operator Notes discussed below, it is possible to attach a record to an event from a safety point alarm test. (i.e. “Safety Point Test Success”) to provide proof that the safety point alarm test was done.


CRM Notes – Selection options are customer defined

In order to streamline the capture of the essential control room management information, the CRM Notes application provides a quick and easy way to attach information deemed relevant by the controllers - with a simple click and by selecting the CRM headline that describes the information to be shared.

Every alarm and action performed on the SCADA system is captured in a historical event log. As such the event record becomes the logical record to associate CRM Notes.

By selecting an event from the event summary to attach a CRM Note to, the event is presented with the timestamp and message as logged. The operator can simply select a pre-configured CRM Note instance and save. Pre-configured notes are assigned to a category to help with the reporting and analysis of the CRM Note by management. Pre-configured categories include:

Shift Change Relevant

Maintenance

Emergency


OASyS and Shift Change Relevant Events

The CRM Notes application available in OASyS DNA 7.5 Columbia provide a quick and easy way to attach information deemed relevant by the controllers - with a simple click and by selecting the headline that describes the information to be shared. Controllers can easily attach “Shift Change Relevant” CRM Notes to events they wish to include in their shift handover. Shift Change reports can then be automated using the OASyS Job Scheduler or Microsoft Reporting Services, and scheduled to run just prior to the shift change to compile all CRM Notes flagged as "Shift Change Relevant” collected for the shift. These reports can then be printed off for the controllers to review as part of their formal shift handover.


As the CRM Notes are captured in the OASyS historical database (MS SQL) they become a rich source of CRM information that can be presented in numerous reports or a CRM dashboard that summarizes the key aspects of your CRM program. Alarm Limit change reasons, manual override reasons, inhibiting or disabling alarms reasons can be attached to the event of the change.

(d) Fatigue Mitigation

Each operator must implement the following methods to reduce the risk associated with controller fatigue that could inhibit a controller’s ability to carry out the roles and responsibilities the operator has defined:

(1) Establish shift lengths and schedule rotations that provide controllers off-duty time sufficient to achieve eight hours of continuous sleep;

(2) Educate controllers and supervisors in fatigue mitigation strategies and how off-duty activities contribute to fatigue;

(3) Train controllers and supervisors to recognize the effects of fatigue; and

(4) Establish a maximum limit on controller hours-of-service, which may provide for an emergency deviation from the maximum limit if necessary for the safe operation of a pipeline facility.

Did you know … Schneider Electric was a sponsor of research done by Circadian Technologies prepared for Southern Gas Association - April 2010 that provided scientific research used to determine recommended hours of service for shift work.


OASYS Point Conditioning

The OASYS Point Conditioning feature allows telemetered data polled from a front-end processor or data concentrator to be flagged as stale if the concentrator doesn’t have up-to-date data for that point. This prevents the operator from seeing telemetered values as normal (i.e., fresh) when in fact the data concentrator has lost contact with the sub-remote. A status point in the RTU or protocol converter device should be set to indicate that the data in the RTU/device is valid for a specific sub-remote. This status point is then configured as the point conditioning status point for all analog, rate, and status points which are polled from the host for that sub-remote..

(d) Fatigue Mitigation

OASyS and Fatigue Mitigation

A controller’s logon and logoff is tracked in the OASyS historian. Reports can be created to present the hours of service to management or regulatory inspectors. Active directory can also be configured to log any users login duration for reporting purposes.

This represents only part of the total hours of services as some controller activities occur off the SCADA system (training, safety meetings, alarm management reviews). The online “hours of service” tracking can become part of an overall time tracking documentation to ensure that controllers do not exceed the maximum shift lengths established as part of the operators control room management plan.

OASyS has the ability to log out a user after a specified time, however due to the nature of pipeline control; best practices do not recommend implementing this feature. “Shift Length Exceeded” or “Fit for Service?” alarms have been implemented by some customers using ACE (Advanced Calculation Engine) and the OASyS job scheduler.


(e) Alarm Management.

Each operator using a SCADA system must have a written alarm management plan to provide for effective controller response to alarms. An operator’s plan must include provisions to:

(1) Review SCADA safety-related alarm operations using a process that ensures alarms are accurate and support safe pipeline operations;

(2) Identify at least once each calendar month points affecting safety that have been taken off scan in the SCADA host, have had alarms inhibited, generated false alarms, or that have had forced or manual values for periods of time exceeding that required for associated maintenance or operating activities;

(3) Verify the correct safety-related alarm set-point values and alarm descriptions at least once each calendar year, but at intervals not to exceed 15 months;

(4) Review the alarm management plan required by this paragraph at least once each calendar year, but at intervals not exceeding 15 months, to determine the effectiveness of the plan;

(5) Monitor the content and volume of general activity being directed to and required of each controller at least once each calendar year, but at intervals not to exceed 15 months, that will assure controllers have sufficient time to analyze and react to incoming alarms; and

(e) Alarm Management (1)

OASYS DNA with “Schneider Electric Alarm Manager – powered by LogMate” provides a comprehensive solution to assist our customers with all aspects of an alarm management program. Alarm Analysis and reporting, Rationalization Tools, Master Alarm Database and Management of Change tools are part of the solution. Other 3

rd party alarm management

solutions have also been integrated with OASyS to provide a complete alarm management life-cycle program.


By properly designating safety related points and following a comprehensive alarm management life-cycle program, safety-related alarm set-point values can be monitored and any discrepancies flagged and corrected. Currently alarm descriptions cannot be changed.


LogMate integrated with OASYS provides extensive reports on the content and volume of alarms directed to the controllers to support the objectives of increased situational awareness and alarm management best practices.


Key performance indicators (KPIs) from alarm analysis applications that monitor the alarm system performance are the basis of measuring the effectiveness of the alarm management plan. By using the OASyS CRM notes, controllers can provide direct input on the effectiveness on their alarm management plan.


OASyS can designate points as safety related in a number of ways. OASyS uses “data quality” indicators to identify points that are off scan, manually overwritten and have alarm limits inhibited. Summary screens are available to review and reports can be generated to present this information. Many operators are identifying points that are alarms inhibited or manually overwritten on a shift by shift basis.


(6) Address deficiencies identified through the implementation of paragraphs (e)(1) through (e)(5) of this section.

OASyS is feature rich in its alarm handling capabilities. In order to provide less customization and more consistent functionality to address new alarm management best practices, several common features have been added to the product as standard features. These include:


Alarm management tools in conjunction with the alarm handling in CRM Notes in OASyS will provide insight to problems with alarm systems. Once identified, it is important to address the issues found by modifying OASyS configuration, adding logical alarm suppression where necessary and continuing to do what is necessary to meet the overall objectives of your plan.

OASyS DNA Conformance with Alarm Management Standards and Best Practices Alarm management follows “Recognized as Generally Accepted as Good Engineering Practice” and as such, there are several reference standards and guidelines available to assist in the implementation of a comprehensive alarm management program. Alarm management standards and best practices are not specific to any particular SCADA system as the proper principles are not SCADA system specific. It is important to have your control management plan and alarm management plans reflect your OASyS system’s specific capabilities.

OASyS DNA conforms to, or supports the best practices of the following alarm management standards and best practices:

EEMUA Publication 191 (Engineering Equipment and Materials Users Association)

The publication originally published in 1999 and followed by a revised second edition in 2007, has been produced by users of alarm systems in industry and is based on what leading companies are doing and promotes continuous improvement in alarm management practices. ISA Standards & Practices 18.2 Management of Alarm Systems for the Process Industries

This standard defines the terminology and models to develop an alarm system, and it defines the work processes recommended to effectively maintain the alarm system throughout the lifecycle. To conform to this standard, it must be shown that each of the requirements in the normative clauses has been satisfied.

API RP 1167 - American Petroleum Institute Recommend Practice

An API workgroup made up of pipeline operating companies, alarm management experts, Schneider Electric and other vendors participated in the development of the alarm management recommended practice API RP 1167. The document provides guidance for effective alarm system design, good alarm audit and review practices and strategies to minimize overload and nuisance alarms. Members of the AGA (American Gas Association) participated in the API 1167 workgroup and have written an Alarm Management Whitepaper to address specific alarm management practices for the gas industry.

API RP 1167 is the most comprehensive alarm management recommended best practice developed by the pipeline industry. Implementation of its recommendations and processes provide the framework for compliance with the alarm management requirements of the PHMSA Control Room Management/Human Factors Rule.


Alert Subsystem

The Alert subsystem is an optional methodology that provides the ability to designate lower priority alarms as alerts (i.e. Minor, Low). Alert notifications must not be safety-related or require a response. Alert conditions are continually checked – and “annunciated” but not on the standard alarm display. Alerts are always of lower priority than alarms and ignoring an alert does not have any safety consequences.

Alerts are presented in a "New Alerts" Summary and must be acknowledged as they are important notifications. If they are not important they should be removed from the system.

Separate Hi-Lo Alarms

OASyS now has separate Hi-Lo Alarm enabling which allows the administrator to enable and disable Hi and Lo, Hi-Hi and Lo-Lo alarm thresholds for analog and rate points separately, providing an additional level of alarm management control to the operator.

Re-Alarming

Re-alarming facilitates having a point re-alarm after a configurable amount of time. This re-alarming (or re-ring) is intended to bring an alarm back into focus without having to dynamically change the severity. Once acknowledged, it will re-alarm after the timer has elapsed. If the point returns to the normal before the re-alarm time period expires, the re-alarm process terminates.

If the point does not return to the normal state, the alarming will be re-annunciated and will retain the timestamp of the initial alarm. The message clearly states "Re-alarm" in the message to ensure that the controller is aware that the re-alarm is not a new alarm.

Email Alarm Notification

Email Alarm Notification automatically sends email messages to designated lists of recipients when specific alarm conditions occur within the SCADA system. The administrator configures the recipients and the conditions that will trigger email notification. Currently, this is restricted to level alarms on analog and rate points, and abnormal state alarms on status and multistate points. The controller also has the option of sending an email about an alarm condition directly from the Alarm Summary.

Alarm Parking (Snooze)

Alarm Parking allows the controller to “park” an alarm for a period of time they specify, to be reminded of the alarm later. While parked, the alarm stops flashing and disappears from the newest Alarm Summary window as if it were acknowledged (where it would remains in the Alarm Summary). It remains parked until it changes state or the timer expires (at which time the alarm returns – beeping and flashing in the unacknowledged state).

Test Mode Alarms

Test Mode Alarming allows the user to place a remote into test mode. Once in test mode, all telemetry alarms generated from that remote will be marked “TEST” in the alarm text, to allow controllers to see at a glance that the alarm condition is due to a planned test in the field.

Timed Group Suppression

As an alternative to Test Mode alarms that mark alarms in Test, the new group control panel allows for the suppression of all points in the designated group for the time period configured. No alarms will be generated; events will record the alarms as non-annunciated. After the time period expires, the group suppression is automatically cancelled. Alternatively, the suppression can be cancelled on demand.


Station Level Alarming

Station Level Alarming introduces the “station” entity that provides for a grouping of remotes associated with a single station (or pipeline/region/district). This provides monitoring of operations at the station level, including a roll-up of alarm activity to the station level to display the total alarm counts in each severity class for the station.

Safety Point Designation

Safety Points allow the user to designate certain points as being safety-related. Applying the safety designation is a one-time operation. The designation of certain points as being safety-related allows the controller to filter for safety-related points as well as ensure that safety points are highly managed from an alarming perspective.

Manual Override Alarm

The Manual Override Alarm feature provides an option to generate an alarm when a point has been manually overridden for more than a configurable period of time. This provides a measure of safety to ensure that points are not forgotten in the manual state.

Annunciated Alarm Events

The Annunciated Alarm Events application provides a way to identify the alarms from the event log that were inhibited at the time they were generated and therefore newer presented to a controller. This supports the task of properly assessing alarm system performance (i.e., accurately measuring the alarm load on the controllers based on how many alarms were annunciated versus just logged).

Tag Expiry Alarm

The Tag Expiry feature allows the controller to set an expiry time on warning or control tags. When a tag reaches its expiration date and time, controllers within the tag’s Area of Responsibility will be notified with a SCADA alarm. At the time of the alarm, a controller is then able to extend, make permanent, or delete the expired tag.

Operator Reminder Alarms

Operator Reminders will allow the operator to configure custom alarm and event messages and to schedule their occurrence. Operator Reminders can be scheduled as one-time events, by specifying a future date or time, or as recurring events. Operator Reminders can be set to occur when certain conditions are met during a particular date and time period, such as an analog value being less than, equal to, or greater than a constant or another analog; or a status variable entering a specific state. If the condition is met, in the right timeframe, the alarm will occur. These messages will appear in the OASyS Alarm and Event Summaries and are classified as type “reminder” so alarm analysis can monitor there usage.

Operator Alarm Limits

As many organizations new alarm philosophies restrict the controllers ability to change alarm setting, the Operator Alarm Limits functionality provides the controller with an set of configurable high-low limits for their use. (analog, rate, gasmeter, and flow_total point). Each point thus has three sets of high-low limits, two of which are administrator-configurable (highhigh-lowlow, high-low) and one of which is operator configurable. If operator alarm limits are not desired these additional alarm sets could be used as warnings for pre-high or pre-low.

Set Point Creep Alarm

The Setpoint Creep Alarms enhancement adds additional setpoint creep alarm support to analog and rate point types. When enabled and configured, the setpoint creep alarm category causes


OASyS to generate an alarm when the value of an analog point's current value field deviates too far from the commanded setpoint.

Non Covered Area Alarm

Non-Covered Area alarming allows the option of generating an alarm whenever an area is in an unsupervised state. That is, when there is no-logged in user with the area defined in their active set.) This feature proactively notifies administrators that an area is unsupervised so that action can be taken immediately to ensure all alarms are received.

On-Off Alarm Delay

The Off-Delay Enhancements allow various threshold alarms for analog points to be held off long enough to ensure that the point really has entered the alarm state (on-delay) or really has returned to normal (off-delay). This reduces nuisance alarms caused by a telemetered value bouncing quickly in and out of the alarm state.

Poll Time Exceeded Alarm

This application creates alarms on remotes when they exceed the maximum allowed polling time. This application allows the administrator to define a maximum poll time. If the remote cannot complete its poll cycle in that time, an alarm is triggered.

Telemetry Last-Change Time

Telemetry Last-Change Time adds information to each analog, rate, status, and multistate point indicating the date and time when the input value last changed, as well as when the commanded value last changed. This is included on summary displays (and can be used on reports) and other applications to allow for better tracking of telemetry updates and outages.

Communications Suppression

Enhanced Communication Suppression provides additional options to reduce nuisance alarms associated with communication failures. Modem bank alarms and/or events can be inhibited, per remote. Communication path switch alarms and/or events can be inhibited, per remote. Remote communication alarms due to illegal or short messages can be configured to hold-off for a configurable interval before generating an alarm. When a multi-drop connection fails the user can chose if all remotes alarm or only the connection alarms.

Uncommanded COS Alarming

Enhancement to Uncommanded COS Alarming reduces alarms for expected COS’s resulting from PLC’s and other field automation logic. When commanded, all COS’s for the child points referenced are suppressed for the configured time-out period. After the specified time-out, the new state is assumed as the valid state to which un-commanded COS resumes.

Alternate Alarm Sets

Alternate Alarms provides a methodology to achieve many forms of advanced alarming. Typical uses include; different alarm profiles for – Flow Rates, Seasonal, Shut-in, Transient, Suppression, etc. There are 256 possible named alternate sets per point. Each alarm limit set is associated with an identifier such as “Summer”, “Winter”, “SteadyState”. These identifiers are set by the administrators and can be selected by controllers, or by automated logic that selects the desired set based on ACE scripting or other applications.

The currently "Active Limit Set" is displayed and when activated, an event is generated with: User or program, Time, Table and point, Alarm limit set selected, previous alarm limit set.

OPS-Params

OPS-Params provide Dynamic Alarm Limits for a variety of pipeline conditions and are particularly useful to notify controllers when pipeline condition change relative to the current state


of the pipeline, before and maximum or minimum pressures or flows are met. When the pipeline is operating at a steady state, the controllers can apply the OPS-Params to a group of points (typically related pressures and flows) for a section of the operating pipeline. This then clamps an alarm window around the current values creating tighter limits for the pipeline hydraulics. This technique has proved very valuable in providing an indication of leaks or ruptures quickly.

(f) Change Management

Each operator must assure that changes that could affect control room operations are coordinated with the control room personnel by performing each of the following:

(1) Establish communications between control room representatives, operator's management, and associated field personnel when planning and implementing physical changes to pipeline equipment or configuration;

(2) Require its field personnel to contact the control room when emergency conditions exist and when making field changes that affect control room operations; and

(3) Seek control room or control room management participation in planning prior to implementation of significant pipeline hydraulic or configuration changes.


SCADA “Management of Change Bulletin Board”

A CRM Note that is not associated with an event can be used as a “SCADA Management of Change Bulletin Board” to help complying with section (f) of the rule; Change Management. The SCADA supervisor or the control room manager would enter into the bulletin board information related to any physical changes to pipeline equipment or configuration. This information would then be presented as the first display presented when a controller logs in, and must be acknowledged as “read and understood” before the controller can begin their normal tasks.


OASyS CRM Notes for Change Management

OASyS CRM Notes is a key tool to facilitate inclusion of the controllers in providing input and feedback to the management of change process. CRM Notes provide the ability to make quick, easy to add, operational intelligence to events as they happen. Examples of management of change activities that CRM Notes can facilitate include:

Display verification - ensure displays reflect all field changes accurately

Providing important feedback on changes to alarm configuration

o Identifying or flagging false, problematic or nuisance alarms resulting from change

Adding/ requesting corrective action or procedural information for new system changes

With controllers capturing important control room management of change issues using CRM Notes, it makes it easy to make the information available in reports for control room supervisors and management to review and ensure changes flagged by controllers become part of the continuous improvement aspect of any control room management program.


(g) Operating Experience

Each operator must assure that lessons learned from its operating experience are incorporated, as appropriate, into its control room management procedures by performing each of the following:

(1) Review incidents that must be reported pursuant to 49 CFR part 191 to determine if control room actions contributed to the event and, if so, correct, where necessary, deficiencies related to:

(i) Controller fatigue;

(ii) Field equipment;

(iii) The operation of any relief device;

(iv) Procedures;

(v) SCADA system configuration; and

(vi) SCADA system performance.

(2) Include lessons learned from the operator's experience in the training program required by this section.

(h) Training

Each operator must establish a controller training program and review the training program content to identify potential improvements at least once each calendar year, but at intervals not to exceed 15 months. An operator's program must provide for training each controller to carry out the roles and responsibilities defined by the operator. In addition, the training program must include the following elements:

(1) Responding to abnormal operating conditions likely to occur simultaneously or in sequence;

(2) Use of a computerized simulator or non-computerized (tabletop) method for training controllers to recognize abnormal operating conditions;

(h) Training (1)

OASyS CRM Notes facilitate the controller flagging of Abnormal Operating Conditions - AOC’s. (Start of AOC, End of AOC, or Near Miss). Once flagged the operator has the time series of events identified to analyze for input to their training program

(g) Operating Experience

OASyS CRM Notes for Operating Experience

OASyS CRM Notes can be used to flag important operational experiences such as AOCs, Near Miss, and Reportable Events. Control room supervisors can use the CRM Notes summary display to monitor CRM Notes and use the information to identify areas requiring additional training, lesson learned experiences as well as maintenance activities needed to improve control room management.


(3) Training controllers on their responsibilities for communication under the operator's emergency response procedures;

(4) Training that will provide a controller a working knowledge of the pipeline system, especially during the development of abnormal operating conditions; and

(5) For pipeline operating setups that are periodically, but infrequently used, providing an opportunity for controllers to review relevant procedures in advance of their application.

(i) Compliance Validation.

Upon request, operators must submit their procedures to PHMSA or, in the case of an intrastate pipeline facility regulated by a State, to the appropriate State agency.

(j) Compliance and Deviations

An operator must maintain for review during inspection:

(1) Records that demonstrate compliance with the requirements of this section; and

(2) Documentation to demonstrate that any deviation from the procedures required by this section was necessary for the safe operation of a pipeline facility.

(h) Training (4,5)

Pipeline operators who use simulators for training provide an environment that is every effective to train for rarely occurring setups and AOC’s. In contrast, on-the-job training (without simulators) for such events has been found to be less effective because these events are rare and may not occur during training.

Operators are encouraged to include "lessons learned" in controller training programs. Reviews for ‘‘near misses’’ or events that meet criteria for reportable events are encouraged. OASyS CRM notes can be used to flag near misses or reportable events for management to evaluate for inclusion in their training programs.

(h) Training (3)

OASyS CRM Notes provide the tool to easily capture information from the SCADA system that should be communicated as part of their emergency response procedures.

(h) Training (2)

Schneider Electric provides both full scope and generic pipeline training simulators leveraging the world’s most technologically advanced pipeline simulator – SimSuite. Only simulator technology can provide realistic, repeatable and unbiased assessments of each controller’s skills and abilities.

Our “full scope” trainer is an exact representation of a pipeline, complete with the logic for key control elements of the actual pipeline, providing the best possible training simulation experience for your controllers.

The Universal OASyS DNA Operator Trainer provides generic simulations on three pre-configured pipelines; crude oil, refined product line and a natural gas grid. Each pipeline comes with five training scenarios and ensures each operator has been evaluated against their relevant covered tasks and can recognize and react to abnormal operating conditions

Data Playback is available as an add-on to Columbia and also can be used to provide support for lessons learned/incident review, as well as procedural development for normal and abnormal operation conditions. Displays can be toggled from live SCADA to “replay mode” for the date and time specified. Data Playback includes controls for start/stop fast forward and rewind.


(j) Compliance and Deviations (2)

For customers in the process of implementing or upgrading to a new OASyS system there has been concerned raised over the compliance deadlines, specifically with regards to point-to-point check out (for safety related points) and compliance with API RP 1165 for displays. These requirements are to be met by August 1

st 2012. PHMSA recognizes the challenges this

presents for those operators that are expanding or replacing their SCADA system and provide this guidance for those cases;

In such cases, if it is not practical for the SCADA system to be in immediate compliance with CRM requirements, operators must document the deviation in accordance with paragraph (j)(2) of the CRM rule. The documentation must demonstrate why immediate compliance with all CRM requirements is not practical, how the deviation is necessary for safe operation, and include a justified project timeline that includes an indication when full compliance is to be attained.

Any OASyS project that is in this situation may have to determine a “justified project timeline” that takes system cut-over and commissioning into consideration, along with providing a timeline for full compliance.

oasys dna and control room management compliance …

Documents