SOFTWARE DEPENDENT SYSTEMS (ISDS) David N. Card1, Thierry Coq2, Rolf Benjamin Johansen3
Copyright 2012, Brazilian Petroleum, Gas and Biofuels Institute - IBP
This Technical Paper was prepared for presentation at the Rio Oi & Gas Expo and Conference 2012, held between September, 1720, 2012, in Rio de Janeiro. This Technical Paper was selected for presentation by the Technical Committee of the event according to the information contained in the final paper submitted by the author(s). The organizers are not supposed to translate or correct the submitted papers. The material as it is presented, does not necessarily represent Brazilian Petroleum, Gas and Biofuels Institute’ opinion, or that of its Members or Representatives. Authors consent to the publication of this Technical Paper in the Rio Oil & Gas Expo and Conference 2012 Proceedings.

Mobile Offshore Units (MOUs) are increasingly dependent on complex software-based controls and automation. However, industry practices have been slow to adapt to this software-intensive environment. Delays in commissioning and operational downtime due to software and integration problems are commonplace. Remi Eriksen (2010) observes that modern offshore units frequently experience delays of seven months or more in commissioning. After vessels become operational, problems continue to emerge. Often these problems cannot be fixed by staff normally onboard, leading to delays in bringing critical systems back on line while the necessary expertise is located. Preventing defects from getting installed in the first place is the most cost-effective solution to these problems. DNV has developed a new offshore standard, OS D-203, Integrated Software Dependent Systems (ISDS) to help ensure the delivery of MOUs with greater reliability, availability, and safety. ISDS focuses on two critical aspects of new builds: software quality and systems integration. Software often has not been fully tested by suppliers prior to installation at the yard. Moreover, even if each individual software component works as designed, problems may occur because messages, handshakes and parameters are not consistently implemented across systems. DNV’s new rule helps to address both software and integration issues.

1. Introduction
The move in offshore towards automation generally has made operations safer and more efficient, while providing volumes of useful information about operations. These improvements in efficiency have, however, come with new challenges and risks. These challenges and risks come from new sources that are currently not being fully managed. Offshore operations have been obstructed by both simple and subtle computing problems, for example: inability to restart a system due lack of passwords, program failure due to a software memory leak, and interface mismatches. These problems are built into the MOU during construction and often overlooked in the rush to complete commissioning. Commissioning is delayed when suppliers deliver software to the shipyard that has not been fully tested. FATs usually are not designed to test the software exhaustively, so thorough internal testing by developers is essential to quality. Much of the software used in the offshore industry is PLC-based. PLCs are assumed to be simple and reliable, but they are not easy to test and suppliers often do not fully test changes. As an example, the Department of Energy (2010) recently issued a safety advisory for firmware for a PLC in a safety system for a nuclear reactor. This software defect was present through 12 versions of the firmware, deployed on two different PLC models, before it was discovered. (Ostensibly, it passed through 12 testing cycles undetected.) The defect resulted in the safety system going off-line unexpectedly. Fortunately, the bug was discovered before this system was needed to handle the feared hazard.

______________________________ 1 BS, Senior Principal Specialist – DNV Korea ² Ingénieur ECP, Principal Consultant – DNV France ³ M.Sc., Project Director – DNV Korea

Rio Oil & Gas Expo and Conference 2012 Sattler (2010) summarized the results of four surveys of BOP failure data. Control systems accounted for 35% to 60% of BOP failures across the surveys. Unfortunately, the proportion of control system failures due to software was not recorded, but can be assumed to be significant. Pallinich (2010) reports on the effects of control systems software and integration problems from a survey of owners and operators that states: Sail date delays cost drilling contractors $12.2 million to over $73.6 million in lost or deferred revenue per delayed rig, while delays in producing first oil cost operators from $48.4 million to $2.4 billion. The need for improved software quality and systems integration is clear to owners and operators. However, shipyards and suppliers have been slow to respond. The offshore new-build industry remains schedule- and cost-driven. OS-D203places system performance and quality among these drivers. Table 1 (based on Eriksen 2010) shows the magnitude of typical cost overruns and schedule delays for offshore vessels: Table 1. Magnitude of Commissioning Problems

Vessel Type Mobile Drilling Unit Production Platform

Cost Overrun 35% 25%

Schedule Delay (Months) 7 6

A significant portion of these costs and delays are due to software and systems integration problems. Addressing these problems early in the project life-cycle will make commissioning and operations run smoother. The following sections explain how OS-D203accomplishes this and summarizes recent experience with its implementation on ships and offshore vessels.

2. Process Models and Best Practices
Computers and software have become pervasive parts of industry and commerce, as well as everyday life. Business success in many domains has become dependent on software and systems quality. The software and systems engineering communities have responded to the quality challenge by developing models of generally accepted good practices. One of the best established of these models is the Capability Maturity Model – Integration (CMMI), (Chrissis, et al., 2010). This model was sponsored by the US government. An internationally sponsored model, Standard 15504 was developed by ISO/IEC (2004). SOFTEX sponsored the development of a national process model – Modelo de Processo de Software Brasiliero (MPS-BR) – based on the CMMI and ISO/IEC 15504. Other industries where failure of software controls poses a threat to life, such as aerospace, automotive and medical devices, have been quick to adopt one (or more) of these models of good practices. Conforming to such a model helps to ensure project success and protect suppliers of software-intensive systems from charges of insufficient diligence. Recent experience suggests that the Maritime and Offshore industries could benefit from more attention to software and systems integration issues. The three models previously mentioned are similar in terms of technical content, but differ in terms of organization and administration. DNV developed OS-D203specifically for the Maritime and Offshore industries. It adopts the terminology and concepts of these industries. Moreover, OS-D203has been designed to fit within the ship and offshore classification systematics. Classification helps ensure quality construction of safe vessels throughout the new build process. Shipyards and suppliers must meet classification requirements during the project. The Classification Society monitors their compliance. In comparison, the CMMI often is used to select suppliers for contract award – suppliers must demonstrate satisfaction of these requirements prior to project start, but thereafter monitor their own compliance. The need for process verification is recognized in OLF/NSA (2011) where these statements appear: In case of complex processes, where it may be difficult to document later that all requirements have been met, verification should be conducted in parallel with the activity to be verified, or the processes leading up to the object to be verified. Examples of verification as parallel process are pre-review of working methods, qualification and review of documentation systematics for a specific process and extensive use of checklists in combination with self-checking by those actually conducting the processes. 2

Rio Oil & Gas Expo and Conference 2012

DNV’s OS-D203applies the concept of process verification to software and systems integration. It establishes requirements for self-checking, as well as providing for continuing process assessments and review of work products by the class society. DNV’s rule is consistent with other standards being promoted in the industry. IEC 61508 targets manufacturers and suppliers of computing devices used in safety systems. IEC 61511 targets system designers, integrators, and users of safety systems. OS-D203addresses both target audiences, but widens the scope beyond safety systems to systems that are business critical, but that don’t necessarily pose safety risks. IEC 61508, Part 3 includes a list of best practices that must be employed in developing safety critical systems. These are consistent with, but more specific than, practices identified in OS D-203. For example, OS-D203requires the application of a systematic software design process without specifying a specific method, while IEC 61508 Part 3 designates specific design methods as acceptable. An organization that implements OS D-203, has put in place a structure that will facilitate satisfaction of IEC 61508 and 61511, should they be required.

3. Key Concepts of ISDS
DNV’s OS-D203was developed through several years of experience and refinement. In 2008 DNV published Recommended Practice (RP) D-201, Integrated Software-Dependent Systems (ISDS), based on the CMMI and other similar models. One of the innovations of the ISDS approach is that it assigns responsibility for each practice to one or more of the following roles: owner, operator, system integrator, supplier, and independent verifier. Participants in an ISDS workshop, conducted by DNV in 2010 for Petrobras and its automation suppliers, agreed that this allocation of activities to roles would help to systematize quality expectations and responsibilities within a project team. Another important feature of ISDS is that it requires the designation of a system integrator. While the shipyard is ultimately responsible for integration they can delegate integration activities to a major supplier or separate systems integration contractor. For example, if one supplier is provided the bulk of automation and controls, then it might make sense to designate that supplier as the system integrator. Depending on the skills, workload, and strategic objectives of the shipyard, it might make sense to hire a separate contractor. Regardless of the choice, ISDS defines the specific activities to be performed by the system integrator. These activities focus on managing requirements, interfaces among the rig systems, and the integration process. During the project DNV will, as the independent verifier, assess the system integrator and verify compliance to OS-D203. The ISDS-required practices for suppliers focus on ensuring that software quality is built into vendors’ products through systematic reviews, inspections, and testing. The goal is to arrive at FAT with software that is already debugged, rather than depending on FAT and commissioning to debug the software. Figure 1 shows how ISDS required activities map to a typical supplier project life cycle. Boxes to the left of the dashed line represent software development activities. Boxes to the right of the dashed line represent software verification, validation, and evaluation activities. All of these requirements are generally accepted good practices in software engineering. Nothing revolutionary is demanded by this DNV standard.


Rio Oil & Gas Expo and Conference 2012

Figure 1.Overview of ISDS Requirements for Suppliers As the independent verifier, DNV conducts process assessments and follows up to ensure that the system integrator and suppliers implement these generally accepted good practices on the owner’s project. Figure 1 shows an example of an assessment summary chart. Each colored cell represents a required practice. The colors indicate the degree to which the requirement is satisfied (High, Medium, Low). DNV (as the independent verifier) also reviews and approves certain key documents related to integration and software. One of the common findings from process assessments performed for pre-qualification, as well as for classification purposes, is that suppliers do not thoroughly test their software before FAT, demonstrated by lots of reds and yellows in the VER (verification) column of Figure 2. .

Figure 2.Sample Process Assessment Summary Another feature of ISDS is the definition of four confidence levels (0 through 3). Each required activity is assigned to confidence level. In order to achieve a specified confidence level, all of the required activities for that confidence level and all lower levels must be implemented. The confidence levels generally correspond to the Safety Integrity Levels in IEC 61508. Figure 2 shows a rating relative to Confidence Level 2. Table 2 shows the systems of mobile drilling unit that are usually selected for ISDS treatment and the Confidence Level DNV recommends be assigned to them.

Overall Function
Prevent Escalation of Abnormal Conditions Fire and Gas Detection Well Control

Main Systems
Emergency Shut Down system (ESD) Fire and Gas Systems Blowout Preventer Diverter Choke and Kill Dynamic Positioning (DP) System Power Management System (PMS) Drilling Control System; Pipe/Riser Handling; Heave Compensation & Tensioning; Storage, Circulation & Cementing. Integrated Automation System (IAS) Power Plant Control System

Confidence Level
2 2 3

Position Keeping Power Management Drilling

2 2 2

Control and Monitoring Power Supply

1 1

Table 2. Recommended Scope and Confidence Levels for Mobile Drilling Unit Systems ISDS also recognizes that different types of software must be treated differently. Most offshore systems are composed of a mixture custom code, COTS products, and configuration data/parameters. This is intended to facilitate meeting customer’s specialized requirements while minimizing the investment in software development for each project. 4

Rio Oil & Gas Expo and Conference 2012 Nevertheless, all of these types of software require some systematic configuration and quality control. ISDS defines three categories of software artifacts and establishes requirements, as follows: New/Modified Software - Definition: software developed or modified specifically for this project - Process Requirements: all supplier activities for the relevant confidence level - Product Requirements: all independent verifier activities for the relevant confidence level Standard Software (often firmware) - Definition: only minor changes and enhancements anticipated, not project specific - Process Requirements: acquirer selection process must include appropriate criteria - Product Requirements: meets acquirer selection criteria, eg., fitness, stability, obsolescence Configuration Data and Parameters - Definition: data input to a software program to configure it for a specific use or vessel - Process Requirements: follow operations phase requirements for new/modified software - Product Requirements: independent verifier activities for confidence level for abbreviated process The goal of defining these categories is to ensure that each type of software is handled appropriately. A system can fail due to problems in software belonging to any of these categories.

4. ISDS as a Class Notation
Seadrill was one of the early movers with ISDS (Laursen 2010). This project employed the ISDS method with a recently delivered vessel in an effort to improve future new builds, as well as identifying weaknesses in the management of operational software. After applying the Recommended Practice on this and more than 10 other projects, DNV evolved the ISDS approach into an offshore rule (OS D-203) in 2010, at the request of rig owners. Packaging as an OS makes it easy for rig owners to apply ISDS to contracts as part of the classification systematics used in this industry. The OS was revised in May 2011 to incorporate experience in implementing ISDS at shipyards. Now, OS-D203 is an optional class notation. Once selected by the owner, it is enforced by the class society just like other class notations. Because ISDS is new, DNV offers a Pre-Qualification service to help suppliers and systems integrators prepare for ISDS projects. During pre-qualification an organization’s processes are assessed relative to the requirements for its intended role, and the organization is guided to fill in the gaps through action planning and followup reviews. Currently, DNV has two ISDS projects on-going. An upgrade project for Dolphin Drilling piloted ISDS in the formal class context (Marshall 2011). The SCADA, HMI, water tight doors, HVAC, and blackout prevention systems of the Borgland Dolphin were upgraded in accordance with the ISDS rule. Dolphin Drilling recently reported that “uptime has been 100%” and that “close to zero errors in the software” have been reported in operation (Svein Torre Mannes at DNV Rig Owners Committee, April 2012). Songa and DSME selected ISDS for the first two Statoil CAT D semisubmersibles (Halvorsen 2012). This project started in 2011. The Blowout Preventer was designated a Confidence Level 3 system (the highest possible level). The other systems within scope (Dynamic Positioning, Power Management, Drilling, Emergency Shutdown, and Fire and Gas) were assigned Confidence Level 2. DSME has taken the systems integrator role. The owner/operator, systems integrator, and suppliers have undergone initial process assessments. The initial process assessments considered the organizations’ plans and normal practices for work. Gaps relative to ISDS were identified and action plans developed. As the CAT D project proceeds, DNV will follow-up with the project team to ensure that the required practices are implemented effectively.

5. Conclusion
The dependence of the oil and gas industries on software, control systems, and automation will continue to increase, just as it is for other industries. For example, the trend towards Integrated Operations requires larger, more complex and more diverse systems. The idea of integrated operations is to move more operational personnel ashore (remote and autonomous operation) and to integrate the various specialties, for example, by putting geophysical data analysts in close contact with drillers. The intended efficiencies of Integrated Operations can only be realized with dependable software and communications. Paula (1993) showed that the failure rate for PLCs across a range of applications is about 2 per PLC per year. Moreover, the probability of a successful changeover in case of redundancy is only 99%. A modern offshore system may contain dozens of PLCs in complex configurations resulting in a substantial 5

Rio Oil & Gas Expo and Conference 2012 cumulative failure rate. Future systems will have more PLCs and other computing devices. ISDS will help to ensure a successful outcome of these challenging new projects. Moreover, Card (2000) suggests that the adoption of process models, such as ISDS, facilitates the introduction of more quantitative means of performance improvement such as Lean and Six Sigma - techniques which have already had a major impact on manufacturing and production in other industries.

6. References
CARD, D., Sorting Out Six Sigma and the CMM, IEEE Software, July 2000
CHRISSIS, M., PAULK, M., and SHRUM S., Capability Maturity Model - Integrated, Addison Wesley, 2003

DEPARTMENT OF ENERGY, Software Quality Assurance: Firmware Defect in Programmable Logic Controller, Safety Advisory, 2010. DET NORSKE VERITAS (DNV), OS D-203, Integrated Software Dependent Systems (ISDS), May 2011 ERIKSEN, R., Industry Must Manage Risks to Control Costs, Offshore, June 3, 2010. HALVORSEN, E., Software Standard Gains Momentum with New Rigs, Offshore, April 2012 INTERNATIONAL ELECTRO-TECHINICAL COMMISSION (IEC), Standard 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems (Parts 1 – 7), 1998 and later INTERNATIONAL ELECTRO-TECHINICAL COMMISSION (IEC), Standard 61511, Functional safety - Safety instrumented systems for the process industry sector (Parts 1 – 3), 2003 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO)/INTERNATIONAL ELECTRO TECHNICAL COMMISSION (IEC) Standard 15504. Information Technology – Process Assessment (Parts 1 – 7), 2004 and later. LAURSEN, W., Dropping Downtime, Offshore Engineer, October 2010 MARSHALL, S., Dolphin in Software Class Leap, Upstream Online, February 2011 NORWEGIAN OIL INDUSTRY ASSOCIATION (OLF)/NORWEGIAN SHIPOWNERS ASSOCIATION (NSA), Handbook for Application for Acknowledgement of Compliance, p. 7, 2011. PALLANICH, J., Time Under a Microscope, Offshore Engineer, May 2012 PAULA, H., Failure Rates for Programmable Logic Controllers, Reliability Engineering and Systems Safety, 1993 SATTLER, J., Just How Reliable is Your BOP Today? Rio Oil and Gas Expo and Conference Proceedings, 2010 SOFTEX, Melhoria de Processo do Software Brasileiro – Guia Geral:2011, June 2011.