Engineering Lessons Learned

Lesson Learned #1: This is “fit for purpose” software”?

Factory Acceptance Tests (FATs) are not designed to properly test software. On a DCMS project with automatic control sequences – there was one equipment FAT to simply get one length of pipe from the rack and do one make-up.  There was no testing for most of the designed sequences, and no error-handling testing at all.  During the test, the racker was bringing the pipe back from the fingerboards to a safe area.  One of the operators selected pause from the touch screen; just to make sure that worked; which it did.  When he pressed resume, the racker “forgot” it was supposed to be going to the safe area and went straight to the well center.

Lesson Learned #2: This is an “engineering process”?

Software guys with laptops helicoptering to rigs cannot test changes except in real production. A drawworks vendor flew in a guy to fix a problem.  He hooked up his laptop and made the change, and then told the driller to try it.  The drawworks code change caused bird’s nesting.  It took them hours to sort out both the cables and the code. The coder “felt” there was an if-test the “wrong way round”.  So, he changed the code and the drill super said, “How do I know it’s going to work this time?”  …  They gritted their teeth – tried it – and luckily for the tech – it worked.

Lesson Learned #3: DP Software Failures?

Drive-off is caused by a fault in the thrusters and/or their control system and a fault in the position reference system. As for the drift-off incidents, the failure frequencies are derived from the DPVOA database, which consists of mainly DP Class 2 vessels. For the drive-off incident, these figures are representative also for the DP Class 3 vessels. The major difference between DP Class 2 and 3 is that only the latter is designed to withstand fire and flooding in any one compartment. These two incident types do not affect the drive-off frequency significantly due to the fact that drive-off is caused by logical failures in the thrusters, their control system and/or the position reference system. Hence, the DP Class 2 figures are used directly also for the DP Class 3 vessel.

The frequency of fault in the thrusters and/or their control system can be obtained from manufacturers’ data. The control system is here meant to include all relevant software and hardware. The statistics show that the software failure is about four times as frequent as the hardware failure and slightly more frequent than the pure thruster failure.

Why do you care?

How safe is dropping a stand from the fingerboards? How about self-inflicted software wounds by technicians who have never before seen all the rig equipment that their software touches? Or, a drive off due to a failure to have your software adequately switch from one GPS satellite constellation to another? You need to care because your software can maim and kill you!

What can you do about it?

Read the blog entries on our website – www.athensgroupservices.com, join our LinkedIn Group, and subscribe to our newsletter.

Graphic

Modeled hardware collision results based on rig network response. The area above the ZERO line are collisions caused by poor control software and poorly configured networks. This rig could only function at 10% of its capability due to poorly integrated software.