September 2015, Vol. 242, No. 9
Web Exclusive
Control Room Management Best Practices
The oil and gas industry is constantly changing, no more so than over the past several years with new technology, new production hot beds and new developing markets to deliver product to. These changes have set the stage for new opportunities and challenges for the midstream industry, particularly when it comes to the pressure of transporting commodities from the production fields to market. Pressure to do it faster but also safer.
This article concludes a two-part series (June 2015) designed to explain how these trends are driving investments in the midstream industry and what companies need to consider to meet business and regulatory goals.
U.S. regulated pipelines are now mandated to meet all the requirements of CFR 49 192.631 & 195.446 for Control Room Management (CRM). The CRM regulations have created many new challenges for pipeline operators when upgrading SCADA systems, as change is the trigger for many of the more onerous requirements of the regulations. Some pipeline operators are reluctant to, or have delayed upgrading their SCADA systems as a result.
Change Triggers for Verification of Adequate Information
“Implement API RP 1165 (incorporated by reference, see §195.3) whenever a SCADA system is added, expanded or replaced, unless the operator demonstrates that certain provisions of API RP 1165 are not practical…
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;”
The CRM regulations are performance-based; meaning pipeline operating companies must provide detailed documentation in their written plans on how they are going to meet the requirements of the regulation. As such, it is up to the operating companies to interpret the regulations, determine how they apply to their operating environments, and ultimately decide what steps they are going to take to be compliant.
This article examines some approaches to address these challenges relative to SCADA upgrades, and how improved upgrading tools and migration documentation could significantly reduce the expense and effort required to commission changes and be compliant in the area of “providing adequate information.”
Upgrade Commission Tools and Utilities
Automated tools are commonly used to convert SCADA displays and databases. When properly documented, they can be effectively used to provide the evidence that these conversions have resulted in the new system having the same key settings as the legacy system and ensure that the new information is mapped correctly.
Database Migration Certification
Database conversion from third-party SCADA systems or an upgrade of a legacy SCADA system is to be completed according to a detailed database migration plan. This migration plan identifies all the key fields in each telemetered database that must be verified to ensure information presented to controllers is unchanged.
In order to provide evidence of a completely successful conversion, a documented and signed report that clearly indicates the “before” configuration matches the “after” configuration as described in the migration plan must be produced.
Parallel System Operations
Side-by-side operations, whereby the old system and the new system’s human nachine interface (HMIs) are run in close proximity with both observed receiving polled data from the field, has long been used as an effective way to confirm the new system is displaying data the same as the original system. What was lacking were screen captures with sign-offs as evidence of the commissioning.
A variety of tools have been used over the years to create listen-only or duplicate data paths to validate that polled data is accurately processed and presented. No single tool is suitable for all cases based on the version of SCADA software, the type of communication channel and the protocols used. Parallel Operation “listen-only” methods include:
Listen-Only Protocol Drivers
• For some protocols, “listen only” drivers are available, making listen- only possible with little effort.
Port Forwarding
• Using hardware configuration, data arriving on a switch/router port is replicated to another port where a listen only connection record processes the incoming data
Signal Cloning
• Custom Tools” used to clone the data transmission enabling parallel operations
The production system must remain unchanged and stable with polling frequency and reliability unaffected.
Point-to-Point Verification Requirement
When changes that affect pipeline safety are made to SCADA displays, a point-to-point check out is required. Taken literally, this could mean that if a display had a safety point moved slightly for better alignment, it would then need to undergo a full end-to-end, point-to-point check out. The time, cost and effort to dispatch field technicians to perform verification on field devices that have not been changed is hard to justify.
As such, it is important to define what a “point” is relative to the change made and document it in your control room management plan. Depending on what the specific change is, the end points may be defined as the point on the display to the corresponding point in the database. In other cases where the field device has been touched, the point-to-point would be defined as the point on the display to the end point of the device in the field.
Display Upgrade Commissioning
For software upgrades that do not alter the display presentation, it is still necessary to provide documentation that the display migration has not altered any display elements or point addresses, and also the displays are evaluated for compliance with API RP 1165. Where the displays do not conform to API RP 1165 any deficiencies must be addressed, or rationalization provided why the displays are inconsistent with the best practice guidelines.
To ensure the migration techniques meet regulatory requirements, documentation of the results of display software migrations must be provided. Artifacts would include:
• “Before & After Upgrade” Screen Captures – Attached to each display commissioning record
• “Before & After Upgrade” Display Migration Report” – Showing point names and database addresses have not been altered for every display migrated.
SCADA Upgrade Scenarios and Verification Considerations
Depending on the architecture of the SCADA system, upgrades may be done in stages. For example, a front end upgrade consists of updating the HMI while leaving the backend (configuration databases) of the real-time server unchanged. For each upgrade scenario the required commissioning and documentation must be part of the upgrade plan.
Summary
The methodology discussed above is the formalization of the good engineering practices that most pipeline organizations have generally followed with regards to SCADA upgrades, but with a focus on defendable documentation.
By following a well-documented upgrade commissioning process including parallel SCADA operations in some cases, the CFR 49 Part 192.631 & Part 195.446 regulation requirement for a host end to field end device testing may be limited to just the new or modified points that affects pipeline safety, significantly reducing the overall cost of a SCADA upgrade.
Comments