The offshore risks of bits and bytes

Software and systems are becoming increasingly complex as they evolve to meet more demanding requirements from customers, regulators, and technology. The maritime and offshore industries face greater product innovation with more software embedded systems forming part of the safety and business-critical systems. These industries now realize the need for an improved approach to managing the emerging software risks.

In the oil and gas sector, the motivation to have the systems fully up and running carries a sense of urgency. Modern drilling units are equipped with a host of advanced systems, which means the whole operation is much more software intensive. If a rig is down for a day, that can amount to a loss of $500,000 and maybe more. While existing rules and regulations work to ensure a ship or rig is safe, the rules are not intended to ensure operability and efficiency, especially relating to non-safety critical systems. But the fact is, the more complex the systems on board, the more exposure to failure.

Safe, predictable and profitable operations of software systems depend on three phases: 1. Development of reliable components; 2. Successful integration of these components into systems; 3. Good management and coordination of component and system requirements. This involves development, procurement, testing, validation, integration, commissioning, configuration, and operation.

Most system and software defects occur in the early phase of a project, and hence much emphasis should be put there. Without adequate control of the processes, these defects can remain undetected until the later stages of the project. Frequently, these defects originate through poor system and component requirements. Research shows it can be up to 100 times more expensive to fix defects once the system is delivered, rather than to fix them in earlier phases.

Challenges also arise because most software is designed with a three-year lifecycle, while vessels or complex drilling rigs have a design life of 20-25 years. The situation becomes even more complex when dealing with large fleets with software from different vendors.

Owners usually are very conservative in the software specification, often requiring what was delivered in previous projects. Unfortunately, the “previous project” may not have been specified properly either, so the yard contacts its suppliers to try to interpret the specification as best it can. In a contradiction, tangible hardware assets are fully specified, but the software may not have received the same level of scrutiny. The reason may be that software usually is not regarded as a “real” component in the system. How can one maintain something that is not specified or even recognized as existing?

Other industries have successfully managed the transition from mechanical, electrical, and hydraulic systems to software intensive integrated systems, notably the aerospace, nuclear, and the automotive industries. The fact that a modern drilling rig and a modern cruise vessel both contain more that 1 million lines of code, or the same amount of code as the latest Airbus A380, puts things in perspective. The solution in the aviation industry has been to focus on the processes used to develop and integrate systems. This has resulted in a number of verification and validation methods that can be adapted also to the oil and gas industry.

Since control systems have become so complex, it is no longer practical to fully test the software. Therefore, there was a need for a new approach that can manage to increase or keep the level of robustness for software-embedded systems.

Requests from rig owners, suppliers, and authorities, in addition to the results from the accumulated knowledge, pilot projects, and best practices from other industries, have led to the development of a new class notation for Integrated Software Dependant Systems (ISDS).

There are numerous different systems that “talk” to each other on a vessel or rig. For an ISDS system, the main challenge is to engineer the various elements into a single system that meets all the requirements in terms of safety, functionality, and reliability. It is simply not enough to select and connect system elements that may individually satisfy the requirements.

The new ISDS notation is a voluntary class notation. When this notation is granted to the system, a status reports will be provided while the software is being developed. This gives the status of the software’s readiness with respect to integration and completeness during development or as the project develops.

Since the ISDS notation looks at the complete lifecycle, it also provides requirements for how to prepare the systems for upgrades and future configurations. The class notation therefore will also prepare for and support configuration management in the operational phase by using a proven methodology. As an example it will give requirements to testing prior to installation of upgraded software based on an initial test strategy. This mean the risk of introducing new “bugs” during upgrades will be reduced.

Operations within the offshore and maritime sectors will increase its complexity and software will be even more important, especially in light of the evolution towards integrated operations. Hence, the focus on bits and bytes must be on at least the same level as the focus on rig hardware. Obviously a holistic approach is needed to manage the risks of work processes and quality assurance to the full lifecycle of such integrated systems.

Per Jahre Nilsen
DNV

This page reflects viewpoints on the political, economic, cultural, technological, and environmental issues that shape the future of the petroleum industry. Offshore Magazine invites you to share your thoughts. Email your Beyond the Horizon manuscript to Eldon Ball at[email protected].