Speaking at the SPE Digital Energy event earlier this year Nestor Fesas of the Athens Group noted that drilling software was particularly risky. One application that controlled a top drive caused erratic behavior and injured two rig hands. Drilling software is risky because it is ‘invisible,’ specs are often inadequate, the development processes are immature. This means that it is ‘easy’ to change and implement specs late in the development cycle, a dangerous process.
Athens Group produces an annual survey of drilling non-productive time (NPT)1. The key message from the last report is that drilling (software) control systems (DCS)-related NPT is ‘way too high.’ Athens Group advocates a lifecycle approach to software development. Software quality is inversely proportional to risk—so it is a good idea to embed risk mitigation efforts early in the development lifecycle. This can be achieved by establishing contractual software standards, by validating and verifying requirements and design.
What is software risk identification and management? Fesas gave the example of the documentation for an alarm system that was 85 pages long and contained over 1,000 alarms! This very risky specification document was approved with minimal review. This is ‘clearly wrong.’ Contractual language should allow for the verification of performance quality and HSE expectations. Industry standards for performance, quality, health and environmental (PQHSE) requirements need to be included.
In the Q&A, Fesas was asked if he could see the equivalent of an API spec for software development. He said that wording for a ‘fit for purpose’ end user agreement was being mooted for certain contracts. Further quality improvement is achievable by ‘using a subset of the operating system.’ Another questioner asked how version upgrades could be made to interconnected control systems without compromising the system. Fesas opined that, ‘Interaction between systems is a relatively well constrained dialog. You can also simulate inputs and outputs. Some clients use the training simulator to check out software before deployment.’ Full paper available on www.oilit.com/links/1106_9.
1 The State of NPT on High-Specification Offshore Assets—www.oilit.com/links/1106_10.
This article originally appeared in Oil IT Journal 2011 Issue # 6.
For more information or to comment on this topic email here.