You are Home   »   News   »   View Article

Software Management of Change in drilling

Thursday, June 27, 2013

We require 'Permits to Work' for simple welding jobs -but allow software vendors to make untested changes to the control system of drilling equipment without even telling the operator. A better system is needed, says Christopher Goetz of Kingston Systems

In the DEJ November 2012 issue Kingston Systems identified the critical need for control system software management practices on modern offshore drilling units(MODUs).

The objective of these practices was to help reduce significant non-productive time (NPT).

Specifically we addressed the need to improve version management and access to, controlled equipment like drilling and dynamic positioning systems.

In this article we follow up with practical advice on how to implement a Software Management of Change (SMOC) program.

Bad Releases, Poor Testing, Inappropriate Access, and general lack of Version Control, these are all common examples of software related causes of costly equipment NPT. All of these causes can be effectively controlled when a SMOC program is in place and followed.

Basic SMOC Components

The Management of Change (MOC) concept is broadly accepted and well executed in our industry.

A good SMOC program builds on this core concept with a set of policies supported by procedures and tools to control and track changes to software and its configuration.

The basic components and thus the blue print for typical SMOC program are:

A Corporate Process: A corporately established policy that defines roles, workflows, procedures and boundaries for shore and off shore management, the crew and vendors.Management buy in to the process and concept is critical to ensure that it is diligently enforced and followed. Incorporating the vendors actually makes implementing the process easier and improves vendor relationships as you share the responsibility of managing the control code for the rig.

Training: Responsibility for SMOC goes well beyond the electronics technician. Other key personnel, the driller for example, need to understand their fiduciary responsibility to prevent unwarranted system access and to control post change testing. And the crew in general needs to be aware of no go areas and no go actions; such as inserting a thumb drive into an industrial PC. Training material tied to role and skill matrices provides measurable accountability and legitimizes management buy in.

A Registry to inventory the software assets, and define the versioning on that asset. The first step to being able to manage something is to know what you have, a registry accomplishes this task. It can be an on line application or a simple spread sheet. Capturing basic information regarding the asset, version, backup and recovery location is essential.

The next component is a Change Request form capturing the reason for the change, the pre and post testing required, as well as a recovery plan. The form, specifically the testing components is important. It forces the implementer to stop and think about their actions and those implications. Just slowing down the 'sledge hammer' mentality would likely prevent many mistakes.

Corporate & Rig Specific Rollout: No application or mandated process will be successful without a clear rollout plan. The rollout plan should incorporate resources for the initial additional work load, training time, role adjustment, funding, as well as a capacity to audit the implementation and reward successful behaviours.

As outlined above, the tool components of SMOC are not complex. They can be paper based, though many vendors provide automated solutions.

Some are web based portals to facilitate information record keeping. Often they are tied to existing maintenance systems which can incorporate workflow and approvals. Others monitor actual PLC write actions and can distribute alerts when a PLC action is made.

Tools are not enough

Having the tools and even a plan is not enough. What is particularly challenging is getting the implementation offshore right the first time due to our very unique culture.

We are an industry of type A doers, where 20 years of salty experience and a 'bigger hammer' often win out over, stopping, thinking, and acting. A bigger hammer will not work with software.

Recently we observed a deepwater drilling contractor make this mistake while we were investigating an equipment failure.

This contractor has all policies, the procedures, the best training and the best web tools linked to version archiving servers.

Electronic change requests are automatically routed via the maintenance system for approvals.

The register is also electronic. Most software components are archived on various systems, some on a corporate server.

However, quite by accident we observed them, laptop open, making changes to the PLC ladder logic.

This was not the vendor, but the Rig Chief Electrician and electronics technician. Needless to say the equipment problem did not get better.

So while the rig management faced some challenging questions from their client, the NPT continued, and now the vendor is challenged with a significant version control quandary.

Cultural gap

Fallout of this incident aside, it's how cases the 'act first think later 'and 'bigger hammer' mentality often seen and encouraged by the hurry attitude of our industry.

A parallel can be drawn to the safety culture we used to have. Thirty years ago, safety took a back seat to operational needs.

Then, with incidents like Piper Alpha, we slowly started to change our attitude towards safety. Now safety is integrated into our daily operations and our attitude towards safety is significantly different.

Question yourself. Why is a PTW (permit to work) needed for a simple welding job, while a vendor can make untested code changes to the draw works, without the operator's knowledge of the event, or comprehension of the implications to safe operations? Is our focus in the wrong area?

No, we need to only expand that focus to include software and systems.

As an industry, managing software has long been a peripheral concern in rig operation. However as new rigs with increasingly complex control systems are delivered, effective software change management is critical in avoiding down time. Software Management of Change implementation is a logical component of the solution and it can be effectively implemented.

The reward

A good software management of change (SMOC) program provides increased system uptime via stability, predictability, and accountability.

It ensures only tested, well understood software changes are installed, and that any changes made can be recovered in a timely manner.

A strong SMOC will deliver improved vendor relationships, better disaster recovery, a strong maintenance crew and reduced NPT.
A solid SMOC program will pay for itself many times over with reduced NPT alone.

comments powered by Disqus


To attend our free events, receive our newsletter, and receive the free colour Digital Energy Journal.


Latest Edition Jan-Feb 2024
Jan 2024

Download latest and back issues


Learn more about supporting Digital Energy Journal