DNVGL-OS-D203 Integrated software dependent systems (ISDS)

The electronic pdf version of this document, available free of chargefrom http://www.dnvgl.com, is the officially binding version.

DNV GL AS

OFFSHORE STANDARDS

DNVGL-OS-D203 Edition July 2017

Integrated software dependent systems(ISDS)

FOREWORD

DNV GL offshore standards contain technical requirements, principles and acceptance criteriarelated to classification of offshore units.

© DNV GL AS July 2017

Any comments may be sent by e-mail to [email protected]

This service document has been prepared based on available knowledge, technology and/or information at the time of issuance of thisdocument. The use of this document by others than DNV GL is at the user's sole risk. DNV GL does not accept any liability or responsibilityfor loss or damages resulting from any use of this document.

Cha

nges

- c

urre

nt

Offshore standards, DNVGL-OS-D203. Edition July 2017 Page 3Integrated software dependent systems (ISDS)

DNV GL AS

CHANGES – CURRENT

This document supersedes the July 2015 edition of DNVGL-OS-D203. Changes in this document are highlighted in red colour. However, if the changes involve a whole chapter,section or sub-section, normally only the title will be in red colour.

Main changes July 2017, entering into force January 2018

Topic Reference Description

Ch.1 Sec.1 Table 4 Added references to international standards.

Ch.2 Sec.2 Confidence level 1 is removed from the standard.

The scope of CL3 is changed. Now it does not include any additionalrequirements to any role except the independent verifier (IV).

Ch.2 Sec.3 andApp.B

The contributor role is removed. The contribution requirements arereplaced with specific requirements for each role in question.

Ch.2 Sec.5 Added a pre-requisite requirement for the owner.

Removed all newbuilding requirements for the owner.

Simplified deliverymodel for ISDS projects

Ch.2 Sec.6, Ch.2Sec.7 and App.B

Reduced total number of ISDS requirement by combining severalactivities.

Ch.2 Sec.4 [1.7] Added description of system life-cycle in relation to the vessel life-cycle.

Ch.2 Sec.8 andCh.3 Sec.1 [1.5]

Independent verifier activities have changed from approval andreview of action plans, testing and development design, to approval ofdevelopment plans and quality control of gate reviews.

App.B [1.2.6],App.B [1.3.4] andApp.B [1.3.15]

Added or modified several requirements to focus on analysis and reviewsduring the vessel and system life-cycle.

Increased emphasison system life-cycleplanning and qualityassurance

App.B [1.7.7] Added requirement to a development plan.

Increased focus on cybersecurity

Ch.2 Sec.6 andApp.B [1.2.5]

Added requirement to a security policy.

ISDS made applicablefor more systems

Ch.3 Sec.1 Table 2 Added:

— steering, propulsion and thruster control and monitoring— workover completion system— cargo control and monitoring— remote access and diagnostics system— diving system— tension leg control system.

Increased focus onaligning formats,documentation andmechanisms used in theproject

App.B [1.3.3] andApp.B [1.7.8]

Added specific requirements for information and document management.

Cha

nges

- c

urre

nt


DNV GL AS

Editorial corrections

In addition to the above stated changes, editorial corrections may have been made.

Con

tent

s


DNV GL AS

CONTENTS

Changes – current............................................................3

Chapter 1 Introduction..................................................... 7Section 1 General................................................................................................................ 7

1 General.................................................................................................................7

2 References........................................................................................................... 8

3 Definitions and abbreviations............................................................................ 10

Chapter 2 Technical provisions....................................... 11Section 1 Principles........................................................................................................... 11

1 General...............................................................................................................11

Section 2 Confidence levels............................................................................................... 12

1 Confidence levels..............................................................................................12

Section 3 Responsibilities.................................................................................................. 13

1 Activities and roles............................................................................................ 13

Section 4 Project phases and process areas......................................................................14

1 Project phases................................................................................................... 14

2 Process areas.....................................................................................................16

Section 5 Integrated software dependent systems requirements for owners....................19

1 Owner requirements.......................................................................................... 19

Section 6 Integrated software dependent systems requirements for systemintegrators.................................................................................................................... 21

1 System integrator requirements........................................................................ 21

Section 7 Integrated software dependent systems requirements for suppliers................. 24

1 Supplier requirements........................................................................................24

Section 8 Integrated software dependent systems requirements for the independentverifier.......................................................................................................................... 27

1 Independent verifier requirements.................................................................... 27

Chapter 3 Classification and certification........................37Section 1 Requirements.....................................................................................................37

1 General...............................................................................................................37

2 Class notation.................................................................................................... 38

3 In operation assessments..................................................................................42

Appendix A Definitions and abbreviations...................... 441 Definitions.............................................................................................44

Con

tent

s


DNV GL AS

2 Abbreviations........................................................................................ 53

Appendix B Requirement definition................................ 561 Requirement definition......................................................................... 56

Changes – historic........................................................106

Cha

pter

1 Sec

tion

1


DNV GL AS

CHAPTER 1 INTRODUCTION

SECTION 1 GENERAL

1 General

1.1 Introduction

1.1.1 This standard contains requirements and guidance on the process of design, construction,commissioning and operation of integrated software dependent systems (ISDS). ISDS are integrated systemswhere the overall behaviour depends on the behaviour of the systems’ software components.

1.1.2 This standard focuses on the integration of the software dependent systems, sub-systems and systemcomponents, and the effects these have on the overall performance of the vessel (ship, rig etc.) in terms offunctionality, quality, reliability, availability, maintainability and safety.This standard intends to help system integrators (SI) and suppliers (SU) as well as owner (OW) to:

— reduce the risk for delays in newbuilding projects and modification projects— reduce the risk for downtime and accidents caused by software in the operation phase— improve the processes for maintenance and upgrades of software dependent systems throughout the life

cycle— improve the knowledge of the relevant systems and software across the organisations— work within a common framework to deliver on schedule while achieving functionality, quality, reliability,

availability, maintainability and safety targets— communicate and resolve key issues related to integration challenges at an early stage and throughout

the whole life cycle.

1.2 ObjectivesThe objectives of this standard are to:

— provide an internationally acceptable standard for ISDS by defining requirements for the work processesduring design, construction, commissioning and operation

— serve as a contractual reference document between suppliers and purchasers— serve as a guideline for designers, suppliers, purchasers and regulators— specify processes and requirements for vessels or installations subject to DNV GL certification and

classification services.

1.3 Organisation of contentThis document is divided into the following chapters and appendices:

— Ch.1 gives general introduction, scope and references.— Ch.2 lists the requirements for the different roles, including assessment and document requirements.— Ch.3 gives procedures and principles applicable when this standard is used as part of DNV GL

classification.— App.A lists definitions and abbreviations used in this standard.— App.B gives a detailed description of the activities introduced in Ch.2.

Cha

pter

1 Sec

tion

1


DNV GL AS

1.4 Assumptions

1.4.1 The requirements of this standard are based on the assumptions that the personnel are qualified toexecute the assigned activities.

1.4.2 The requirements of this standard are based on the assumptions that the parties involved in thedifferent processes are familiar with the intended function(s) of the system(s) subject for ISDS.

1.5 Scope and application

1.5.1 The requirements of this standard apply to the processes that manage ISDS throughout the life cycleof a ship or offshore unit, and apply to new-builds, upgrades and modification projects. It puts requirementson the ways of working, but does not contain any specific product requirements.

1.5.2 The requirements of this standard apply to systems, sub-systems and software components created,modified, parameterized, tuned and/or configured for the specific project where this standard is applied. Thisstandard focuses on the software aspect in the context of system and vessel requirements.

1.5.3 The voluntary ISDS class notation, as specified in Ch.3, may be assigned when DNV GL has verifiedcompliance. DNV GL’s verification activities include all the activities specified under the independent verifier(IV) role in Ch.2, for the relevant confidence level (CL).

1.6 Types of software within scopeThis standard focuses on achieving high software quality and takes into consideration all types of controlsystems software. The requirements differ depending on whether the software is new, reused or commercialoff-the-shelf (COTS):

— New software (typically application software) developed within the project is qualified for use in the ISDSby showing that the supplier’s development process is compliant to this standard.

— All reused software shall be qualified for use. Reused software is typically base products. The term baseproduct is here used to describe any kind of existing product, component, software library, softwaretemplate or similar on which the supplier bases the development (or automatic generation) of thecustomer specific product.

— Procurement of COTS software shall be handled according to the requirements in this standard.

The qualification of reused software shall be performed by using one of these options:

1) Demonstrating compliance with this standard.2) Assessing the quality through due diligence of the software.3) Demonstrating that the software is proven-in-use.

1.7 Alterations and additions of approved systemsWhen an alteration or addition to the approved system(s) is proposed, applicable ISDS requirements shallbe applied and relevant information shall be submitted to DNV GL. The alterations or additions shall bepresented for assessment and verification.

2 References

2.1 DNV GL reference documentsApplicable DNV GL publications are given in Table 1 to Table 3.

Cha

pter

1 Sec

tion

1


DNV GL AS

Table 1 DNV GL rules for classification: Offshore units

Document code Title

DNVGL-RU-OU-0101 Offshore drilling and support units

DNVGL-RU-OU-0102 Floating production, storage and loading units

DNVGL-RU-OU-0103 Floating LNG/LPG production, storage and loading units

DNVGL-RU-OU-0104 Self elevating units, including wind turbine installation units and liftboats

Table 2 DNV GL offshore standards

Document code Title

DNVGL-OS-A101 Safety principles and arrangements

DNVGL-OS-D101 Marine and machinery systems and equipment

DNVGL-OS-D201 Electrical installations

DNVGL-OS-D202 Automation, safety and telecommunication systems

DNVGL-OS-D301 Fire protection

DNVGL-OS-E101 Drilling plant

DNVGL-OS-E201 Oil and gas processing systems

DNVGL-OS-E301 Position mooring

Table 3 Other DNV GL references

Document code Title

DNVGL-RU-SHIP Pt.4 Ch.9 Control and monitoring systems

DNVGL-RU-SHIP Pt.6 Ch.3 Navigation, manoeuvring and position keeping

DNVGL-ST-0373 Hardware in the loop testing (HIL)

2.2 International or national referencesThe standards listed in Table 4 are referenced in this standard.

Table 4 International or national references

Document code Title

IEC IEV 191 Dependability and quality of service

IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems

IEC 61511 Functional safety – Safety instrumented systems for the process industry sector

IEC 19501:2005 Unified modelling language specification

IEEE 610.12:1990 Glossary of software engineering terminology

IEEE 828-1983 Software configuration management plan

Cha

pter

1 Sec

tion

1


DNV GL AS

Document code Title

IEEE 829-1983 Software test documentation

IEEE 1074:2006 Developing software life cycle processes

INCOSE SE 2004 INCOSE System Engineering Handbook, 2004

ISO/IEC 9126 Software engineering — Product quality

ISO/IEC 15288 Life Cycle Management — System Life Cycle Processes

ISO/IEC 12207 Systems and software engineering — Software Life Cycle Processes

ISO 9000 Quality management systems

ISO/IEC 90003 Software engineering -- Guidelines for the application of ISO 9001:2008 to computersoftware

SWEBOK 2004 Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004 Version

3 Definitions and abbreviationsFor general definitions and abbreviation see App.A. For requirement definitions see App.B.

Cha

pter

2 Sec

tion

1


DNV GL AS

CHAPTER 2 TECHNICAL PROVISIONS

SECTION 1 PRINCIPLES

1 General

1.1 Process requirementsThis standard provides requirements for a process. These requirements are formulated as a set of activitiesthat apply for specific roles during specific project phases and at specific confidence levels.

1.2 System hierarchyIn order to describe the different parts that make up ISDS, this standard uses the hierarchy defined inFigure 1.

Figure 1 The hierarchy terms used in this standard

Cha

pter

2 Sec

tion

2


DNV GL AS

SECTION 2 CONFIDENCE LEVELS

1 Confidence levels

1.1 Definition of confidence levels

1.1.1 Confidence levels shall be assigned by the owner to a selection of the vessel’s functions and systems,based on evaluations of the importance of these functions in relation to reliability, availability, maintainabilityand safety.

1.1.2 Confidence levels define the required level of trust that a given function (implemented by one or moresystems) will perform as expected. This standard defines the confidence levels 2 and 3 where the higherconfidence level will require a higher project ambition level with the aim of increasing the dependability of thesystems in scope. The higher confidence levels also include the activities required for the lower ones.

Guidance note:

Confidence level 1 (previously used for systems with limited system integration) is no longer considered applicable for systemssubject to the ISDS class notation, and thus have been removed from this standard.

Despite there being only two confidence levels, the names CL2 & CL3 are used to keep the names consistent with previousversions of this ISDS standard.

---e-n-d---o-f---g-u-i-d-a-n-c-e---n-o-t-e---

1.1.3 For recommended confidence levels for systems and components relevant for selected vessel types(drilling unit, floating production storage and offloading units (FPSO) etc.) see Ch.3 Sec.1 [2.2].

1.1.4 Table 1 shows the difference between confidence levels 2 and 3.

Table 1 The difference between the confidence levels

CL Characteristics Focus Key activities

2 Software andintegration

System development

System integration

Project management

Defined ways of working

Design and verification of software and interactions betweensystems

Interface definition

Traceability of requirements

Reliability, availability, maintainability, safety (RAMS)

Obsolescence management

3 Enhancedindependentverification

System development

System integration

High dependability

Independent RAMS verification

Cha

pter

2 Sec

tion

3


DNV GL AS

SECTION 3 RESPONSIBILITIES

1 Activities and roles

1.1 ActivitiesEach requirement of this standard is formulated as an activity which is assigned to a role, a defined projectphase, and a confidence level. The activities are listed in Sec.5 to Sec.7 and described in detail in App.B.

Guidance note:

Each required activity has a unique identifier. The identifier is structured in three parts: Z.YYY.NN. The first part (Z) of the activityidentifier refers to the project phase. The second part (YYY) of the activity identifier refers to the process area. The third part(NN) of the activity identifier is a unique number for the activity. For example, A.REQ.2 is the identifier of the 2nd activity of therequirements process area for the basic engineering phase. Some activities are performed in two or several phases. In this case,the activity’s phase is described as an X. Each X activity describes in which phases it shall be performed. X.REQ.1 is the commonactivity no.1 for the requirements process area for managing requirement changes in all phases.


1.2 Roles

1.2.1 This standard defines requirements on several organisations with responsibilities within the system lifecycle. Each role is assigned activities and has the responsibility to perform the activity with an outcome thatfulfils the specified criteria.

1.2.2 Each organisation is assigned one of four predefined roles. The four roles are:

— OW: in the context of this standard the owner is the organisation who decides to develop the vessel (ship,rig etc.) and provides funding. The operator of the system may be part of the owner's organisation or asubcontractor acting on behalf of the owner. For a definition of the term owner see the applicable DNV GLrules for classification: Offshore units (RU-OU).

— SI: responsible for the integration of all systems included in the scope of this standard. The systemintegrator is normally the shipyard, but parts of the integration may be delegated to other parties. In suchcase this shall be clearly defined and documented.

— SU: responsible for the integration and delivery of one or more single systems (drilling control system,power management system (PMS) etc.). If the supplier purchases products and services from otherorganisations, these are regarded as sub-suppliers, and are under the supplier's responsibility.

— IV: an organisation that is mandated to independently verify that the system is developed according tothis standard. As part of the classification process for the ISDS notation, DNV GL shall take the role of theIV.

Cha

pter

2 Sec

tion

4


DNV GL AS

SECTION 4 PROJECT PHASES AND PROCESS AREAS

1 Project phases

1.1 Introduction

1.1.1 All activities in this standard are mapped to the typical project life cycle, see Figure 1.

1.1.2 The transitions between the phases represent ISDS milestones. At each milestone the followinginformation shall be reported by the involved roles:

— status for the compliance to this standard— action plans for handling non-conformities— risk observations made by the IV.

1.1.3 At each milestone a milestone meeting should be arranged. The system integrator is responsible forarranging such meetings at all milestones.

1.1.4 An ISDS milestone is completed when the owner, the system integrator and the IV endorse theinformation presented at the milestone.

Figure 1 Process chart.

Figure 1 describes the relationship between project phases A to E and ISDS milestones (M1 to M5). ISDSmilestone M5 is only applicable for modifications made during the operation phase.

1.2 A - Basic engineering phaseDuring this phase the technical specification and design of the vessel are established, including RAMSrequirements. The main systems which will be included in the scope for ISDS requirements and theirconfidence levels are identified. The contract between the owner and the system integrator is establishedduring this phase.

1.3 B - Engineering phaseIn this phase contracts are established with suppliers, and the suppliers are involved in setting up thedevelopment/configuration of each system. The detailed design of the vessel and systems is documented.The verification, validation, testing and integration strategies, and major interfaces are established, andRAMS analyses are carried out.

1.4 C - Construction phaseIn this phase the construction and integration of the systems are carried out. Detailed software design,coding, configuration and/or parameterization are performed. Systems and interfaces are tested, validatedand verified as part of this phase.

Cha

pter

2 Sec

tion

4


DNV GL AS

1.5 D - Acceptance phaseIn this phase, the functionality, performance, RAMS requirements and other aspects of the integratedsystems are validated, through commissioning activities, integration testing, and sea trials.

1.6 E - Operation phaseIn this phase the vessel is in operation. Maintenance and small upgrades are performed as deemed necessaryby the owner.Large upgrades should be managed as separate projects, following a distinct lifecycle based on this standard.

Guidance note:

Any planned upgrade resulting in the shutdown of the vessel or ship for any extended period of time should be regarded as a largeupgrade.


1.7 System life-cycleThe timeline for each system will vary based on the building schedule for the vessel. It is therefore likely thatdifferent systems will reach the subsequent phase at different points in time. Each system will go througha project life-cycle as illustrated in Figure 2, however different system is likely to reach each review gate atseparate times. For the purpose of an ISDS project, the system life-cycle is considered to start in the phaseB, when suppliers are involved.Each system will be subject to three key decision gates, where readiness for subsequent project activitiesshall be reviewed. The review records and decisions from the review gates shall be documented. These threedecision gates include:

— G1: requirements review (B.VV.2). The requirements from the system integrator shall be analysed andreviewed for completeness, consistency and correctness. The review shall involve the system integrator.

— G2: readiness for acceptance test review (C.VV.3). All supplier internal test activity results shall beanalysed to evaluate if the system is ready for acceptance testing with the system integrator.

— G3: readiness for commissioning review (D.INT.1). The system shall be evaluated to see if relevantactivities are performed and relevant changes tracked to closure before starting commissioning. Thesystem integrator has responsibility for this activity.

Figure 2 Process chart

The process chart describes the relationship between project phases A to E and key decision gates for thesystem development.

Cha

pter

2 Sec

tion

4


DNV GL AS

Figure 3 Timeline examples

Figure 3 consists of three examples of different timelines for different systems:(A) Project timeline for the vessel including the ISDS milestones.(B) Project timeline for a system with late delivery including key decision gates.(C) Project timeline for a system with early delivery including key decision gates.

2 Process areas

2.1 IntroductionActivities are logically grouped in process areas based on the typical engineering discipline they address.Each process area spans multiple project phases.

2.2 Requirements engineeringThe requirements engineering process area covers the activities needed to define, document and manage therequirements on the vessel, the systems and the related software.The overall goal and specifications for the vessel are defined and the requirements on the vessel and relevantsystems are specified. A dialogue between the owner/system integrator on one hand and the potentialsuppliers on the other is expected to take place in order to align the requirements with the supplier’ssystems. The allocation of requirements to systems shall be documented. A trace from requirements todesign and verification shall be documented and maintained.

2.3 DesignThe design process area consists of activities to establish a design on different levels. Together with theinterface related activities in the integration process area (INT), this creates the design basis from which thesystems and related software may be produced and verified.Each system is designed with identification of major sub-systems and components. The external interfacesshall be documented and coordinated with other relevant systems. The vessel design is documented,maintained, and analysed with focus on integration of the systems. A strategy for handling of current

Cha

pter

2 Sec

tion

4


DNV GL AS

and future obsolescence is expected to be defined, and monitoring of components and systems withregards to obsolescence during the operation phase is required. The architecture of relevant systems andsoftware components is detailed and documented, including new, reused, and parameterized software. Thedocumentation related to any base-products shall be kept up to date.

2.4 ImplementationThe implementation process area covers the coding and configuration activities needed to create andcustomize software modules in order to fulfil the specified design. In addition, associated supportdocumentation shall be created.The software components are programmed, configured, parameterized and tested based on a baselineddesign. Implementation guidelines and methods are expected to be used as additional input to theprogramming, configuration and parameterization, and support documentation like user manuals is produced.

2.5 AcquisitionThe acquisition process area includes activities related to when a supplier uses sub-suppliers to developor deliver components/systems. It covers both the situation where configuration and development of thesoftware components is subcontracted and the situation where the supplier buys COTS systems.Specific contracts between the supplier and the sub-supplier are established and followed-up. Thecomponents or systems are verified at delivery and it shall be ensured that the delivered component/systemcan be integrated into the system/vessel in question. The COTS systems are selected based on definedcriteria. Intermediate deliveries are reviewed in the case of outsourced software development.

2.6 IntegrationThe integration process area covers the assembly of the systems into the vessel, and activities to coordinatethe interfaces between the systems.The responsibilities regarding each system and how it shall be integrated are defined and a specificintegration plan is produced. Inter-system interfaces are coordinated and systems checked against pre-defined criteria before the integration takes place.

2.7 Verification and validationThe verification and validation process area addresses the quality assurance activities needed to ensure thateach software component, each system and the integrated systems in concert perform as expected and fulfilthe needs of the intended use.It is required that a verification strategy is defined, and that basic verification activities like factoryacceptance tests (FAT), peer reviews, and qualification of reused software are prepared and performedaccording to this strategy. It is also expected that validation testing is performed during the acceptancephase, and when modifications and upgrades are performed during the operation phase. There is focus onthe functionality and performance of the integrated systems working together, and on early verification ofthe correctness and the completeness of requirements, interface specifications, user interfaces, and designdocumentation. The verification and validation results are expected to be analysed and compared withdefined targets.

Cha

pter

2 Sec

tion

4


DNV GL AS

2.8 Reliability, availability, maintainability and safetyThe RAMS process area gathers the activities dealing with the definition, analysis and verification of theRAMS properties of the vessel and specific systems. Security aspects are also included. Particular focus isplaced on RAMS throughout the vessel and system life-cycle to highlight the importance of these systemcharacteristics.Goals regarding reliability, availability, maintainability (RAM) are established, analysed and verified, the goalscan be qualitative or quantitative in nature. Risks and mitigations related to the RAMS aspects are managed.The activities related to handling of the RAMS aspects are planned and followed-up during the project.On CL3, additional IV activities are also introduced for enhanced verification of the RAMS process area.

2.9 Project managementThe project management process area covers the activities required to make sure that the project plans forthe different organizations involved are created, synchronized and followed-up. Basic project managementactivities regarding project planning and tracking are required.

2.10 Risk managementThe risk management process area covers activities related to defining a project risk management plan,identifying, mitigating and tracking project risks related to systems and software. Risks are identified,reviewed, tracked, and updated. Also risk mitigation actions shall be tracked to verify that they have theexpected effect on the risk. A risk strategy for the project is also defined.

2.11 Process and quality assuranceThe process and quality assurance process area covers the activities needed to define and follow up theway of working within the project. It also covers the activities needed to make sure that the involvedorganizations fulfil the requirements in this standard. The applicable procedures for each organization aredefined and when necessary coordinated with the other roles. The adherence to the defined proceduresis followed-up by each organization. DNV GL will follow-up on the adherence to the requirements in thisstandard.

2.12 Configuration managementThe configuration management area covers activities to make sure that changes to documents and softwareare performed in a controlled way, and to ensure the integrity and consistency of the systems, theirconfiguration, and all related work products (requirements, design, interface specifications, specifications,source code, documentation, etc.).

Cha

pter

2 Sec

tion

5


DNV GL AS

SECTION 5 INTEGRATED SOFTWARE DEPENDENT SYSTEMSREQUIREMENTS FOR OWNERS

1 Owner requirements

1.1 Requirements under the owner’s responsibility

1.1.1 The following requirement is a prerequisite for running ISDS projects and will be assessed by the IVbefore the start of phase A.

OW.REQ.1 Provide clear and complete requirements

Requirement definition

The owner shall develop requirements documentation including the following items:

— scope of ISDS including designation of systems for enhanced verification (CL3)— cyber security standards— flag and shelf state requirements— health, safety and environmental requirements— RAMS requirement and objectives— system specifications.

Guidance note:

A clear and complete statement of requirements is essential to a successful project outcome. These items typically are specifiedin the technical building specification (TBS) for the vessel and included in the contract between the shipyard and the owner. Theseitems often are developed in a front-end engineering and design (FEED) study prior to contract award.

A mission definition, operational concept and operational scenarios often are developed to facilitate definition of RAMS objectivesand other operational requirements. These items may be reviewed with intended users and potential suppliers to improve theiraccuracy.


Assessment criteria Documents required for review

Technical building specification and supporting documents Vessel specification (for information (FI)) on CL2, reviewedin A.IV.1

1.1.2 Table 1 lists the requirements under the owner’s responsibility. The table also lists all documents to besent to the IV and in which activities the IV is going to use the different documents.

1.1.3 App.B fully specifies the requirements for all roles, including detailed requirements, acceptance criteriaand documentation required for review by the IV.

1.1.4 All documents provided by the owner will be FI only.Guidance note:

When the IV is expected to comment on the document, the word reviewed is employed. For documents which serve as backgroundinformation to put the reviewed documents in a context, the word used is employed.


Cha

pter

2 Sec

tion

5


DNV GL AS

1.1.5 Requirements for owner

Table 1 Requirements for owner

Reference Required activity

E.CM.1 Manage change requests during operation

E.CM.2 Perform configuration audits

E.DES.1 Manage and monitor obsolescence

E.PQA.1 Define procedures for problem resolution, change handling, and maintenance activities

E.RAMS.1 Collect reliability, availability, maintainability and safety data

E.RAMS.2 Analyse RAMS data and address discrepancies

E.RAMS.3 Perform RAMS impact analysis of changes

E.RAMS.4 Periodically perform security audits of the systems in operation

E.VV.1 Perform validation testing after changes in the systems in operation

Cha

pter

2 Sec

tion

6


DNV GL AS

SECTION 6 INTEGRATED SOFTWARE DEPENDENT SYSTEMSREQUIREMENTS FOR SYSTEM INTEGRATORS

1 System integrator requirements

1.1 Requirements under the system integrator’s responsibility

1.1.1 The following Table 1 lists the requirements under the system integrator’s responsibility. The table alsolists all documents to be sent to the IV and in which activities the IV is going to use the different documents.

1.1.2 App.B fully specifies the requirements for all roles, including detailed requirements, acceptance criteriaand documentation required for review by the IV.

1.1.3 Most documents shall be provided FI. The only document that shall be approved by the IV is thedevelopment plan.

Guidance note:



1.1.4 For full specification of the requirements for all roles see App.B.

Table 1 Requirements under system integrator’s responsibility

Reference Required activity Documents required for IV review

A.CM.1 Establish a baseline of requirements for the unit None

A.DES.1 Establish the vessel design Vessel design (FI) used in B.IV.2for CL.2.

A.PM.1 Establish the project master plan None

A.RAMS.1 Develop the RAMS plan for the unit

Plan for handling of RAMS (FI):

— reviewed in A.IV.3 at CL3— used in B.IV.3 at CL3— used in D.IV.3 at CL3.

A.RAMS.2 Establish security policy for the vessel Security policy (FI), used inD.IV.3.

A.REQ.1 Perform requirements analysis for the vessel and systems

RAMS requirements (FI):

— reviewed in A.IV.3 at CL3— used in B.IV.3 at CL3— used in D.IV.3 at CL3.

A.REQ.2 Establish traceability of requirements None

B.ACQ.1 Select COTS products based on defined criteria None

B.CM.1 Establish and implement information and document management None

Cha

pter

2 Sec

tion

6


DNV GL AS


B.CM.2 Perform review of system requirements

Review report (FI) are reviewed inB.IV.2 at CL2.

Baselines (FI) are used in C.IV.1at CL2.

B.CM.3 Establish baselines of design None

B.DES.1 Design the system Functional Description (FI) used inC.IV.1 at CL2.

B.DES.3 Analyse and refine the unit design None

B.INT.1 Coordinate inter-system interfaces None

B.PM.1 Establish a project plan None

B.RAMS.2 Identify system dependencies and assess RAMS risks betweensystems Report reviewed in B.IV.4 at CL3.

B.VV.1 Define verification, validation and integration strategy

Verification and validation strategy(FI):

— reviewed in B.IV.2, at CL2— used in C.IV.1 at CL2— used in D.IV.1 at CL2.

C.PQA.1 Establish procedures for problem resolution and maintenanceactivities None

D.CM.1 Manage software changes after FAT Configuration managementprocedure (FI) used in D.IV.2.

D.CM.2 Transfer responsibility for system configuration management toowner None

D.INT.1 Check readiness for integration of systems and components beforecommissioning

Readiness report (FI) used inD.IV.1 at CL.2.

D.RAMS.1 Demonstrate achievement of unit RAMS requirements RAMS compliance report (FI)reviewed in D.IV.3 at CL3.

D.RAMS.2 Perform a security audit on the deployed systems Security audit report (FI) used inD.IV.3 at CL3.

D.VV.1 Perform systems integration tests None

D.VV.2 Perform validation testing None

X.CM.1 Track and control changes to the baselines None

X.PM.1 Monitor project status against plan None

X.PM.2 Perform joint project milestone reviews None

X.PQA.1 Establish a development plan

X.PQA.2 Coordinate key formats and mechanisms None

X.PQA.3 Control procedures None

X.REQ.1 Maintain requirements traceability information None

Cha

pter

2 Sec

tion

6


DNV GL AS


X.RISK.1 Track, review and update risks None

Cha

pter

2 Sec

tion

7


DNV GL AS

SECTION 7 INTEGRATED SOFTWARE DEPENDENT SYSTEMSREQUIREMENTS FOR SUPPLIERS

1 Supplier requirements

1.1 Requirements under the supplier’s responsibility

1.1.1 The following Table 1 lists the requirements under the supplier’s responsibility. The table also lists alldocuments to be sent to the IV and in which activities the IV is going to use the different documents.

1.1.2 For requirements for all roles, including detailed requirements, acceptance criteria and documentationrequired for review by the IV see App.B.

1.1.3 Most documents shall be provided FI. The only document that shall be approved by the IV is thedevelopment plan.

Guidance note:



1.1.4 Requirements under supplier’s responsibility

Table 1 Requirements under supplier’s responsibility


B.ACQ.1 Select COTS products based on defined criteria None

B.ACQ.2 Establish contract with sub-suppliers None

B.CM.1 Establish and implement information and documentmanagement None

B.CM.2 Perform review of system requirements

Review report (FI) are reviewed inB.IV.2 at CL2.

Baselines (FI) are used in C.IV.1 atCL2.

B.CM.3 Establish baselines of design Baselines (FI) are used in C.IV.1 atCL2.

B.DES.1 Design the system Functional Description (FI) used inC.IV.1 at CL2.

B.DES.2 Design each software component None

B.DES.4 Define obsolescence strategy None

B.PM.1 Establish a project plan None

B.RAMS.1 Develop the RAMS plan for the system


— reviewed in B.IV.3 at CL3— used in C.IV.2 at CL3.

Cha

pter

2 Sec

tion

7


DNV GL AS


B.RAMS.3 Identify software-related RAMS risks, priorities and mitigationactions

RAMS risk register (FI) and RAMS riskanalysis documentation (FI):


B.REQ.1 Identify and refine requirements for the system Specification (FI) used in B.IV.2 atCL2.

B.VV.1 Define verification, validation and integration strategy

Verification and validation strategy(FI):

— reviewed in B.IV.2, at CL2— used in C.IV.1 at CL2.

B.VV.2 Qualify reused software None

C.ACQ.1 Accept deliverables None

C.ACQ.2 Ensure transition and integration of the delivered product None

C.IMP.1 Develop and configure the software components from design None

C.IMP.2 Develop support documentation None

C.IMP.3 Perform software component testing None

C.PQA.1 Establish procedures for problem resolution and maintenanceactivities in the construction and acceptance phases None

C.RAMS.1 Demonstrate achievement of system RAMS requirements RAMS compliance report (FI)reviewed in C.IV.2 at CL3.

C.VV.1 Verify source code and configuration None

C.VV.2 Perform internal testing Test report (FI) used in C.IV.1 at CL2.

C.VV.3 Analyse verification results with respect to targets Verification analysis report (FI)reviewed in C.IV.1 at CL2.

C.VV.4 Perform FATSystem FAT procedure (FI) andsystem FAT report (FI):

— used in C.IV.1 at CL2.

D.CM.1 Manage software changes after FAT None

E.CM.1 Manage change requests during operation None

E.DES.1 Manage and monitor obsolescence None

E.RAMS.2 Analyse RAMS data and address discrepancies None

E.RAMS.3 Perform RAMS impact analysis of changes None

X.ACQ.1 Monitor contract execution and changes None

X.ACQ.2 Review intermediate deliverables None

X.CM.1 Track and control changes to the baselines None

X.CM.2 Establish a release note for the delivered system None

X.PM.1 Monitor project status against plan None

Cha

pter

2 Sec

tion

7


DNV GL AS


X.PQA.1 Establish a development plan Development plan, for approval (AP),reviewed in B.IV.1 for CL2.

X.PQA.3 Control procedures None

X.REQ.1 Maintain requirements traceability information Traceability matrices (FI) used inC.IV.1 at CL2.

X.RISK.1 Track, review and update risks None

X.VV.1 Perform verification and validation on added and modifiedsoftware components None

Cha

pter

2 Sec

tion

8


DNV GL AS

SECTION 8 INTEGRATED SOFTWARE DEPENDENT SYSTEMSREQUIREMENTS FOR THE INDEPENDENT VERIFIER

1 Independent verifier requirements

1.1 Activities for which the independent verifier is responsible

1.1.1 The following table describes the activities that shall be performed by the IV.Guidance note:

As part of the classification process for the ISDS classnotation, DNV GL takes the role of IV. Document types listed in the tableare further described in DNVGL-RU-SHIP Pt.1 Ch.3 Sec.3 and a description of the content in an ISDS context is given in theassessment criteria for each of the referenced activities.


1.1.2 As part of the classification process for the ISDS classnotation, DNV GL shall take the role of IV.

1.1.3 Most documents shall be reviewed FI, only the development plan is subject to AP.

1.1.4 For requirements under independent verifier’s responsibility see Table 1 below.

Offshore standards, D

NVG

L-OS-D

203. Edition July 2017Page 28

Integrated software dependent system

s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Table 1 Requirements under independent verifier’s responsibility

Input

ID CL Activity Description Guidance noteDocument type Acceptance criteria Activity

reference

Verificationoutput

A.IV.1 2 Review ownerrequirements

The technicalspecification ofthe vessel shall bereviewed to verifythat the relevantrequirement,policies, standardsand responsibilitiesare addressed.The reviewshall considerif the types ofrequirements,listed in A.REQ.1,have beenaddressed.

None

Z040-Vesselspecification(OW.REQ.1)

— Relevant systems,requirements andstandards areincluded

— The technicalspecification isconsistent andcomplete

OW.REQ.1 - Reviewcommentson Z040documenttype

A.IV.2 2 Review theSI vesseldevelopment plan

The vesseldevelopment planfor the systemintegrator shallbe reviewed toensure that thesufficient plansand procedures areestablished to meetthe requirements ofthis standard.

The review shalladdress whetherall relevant ISDSrequirementsare explicitlymapped to the SIway-of-workingframework.

None

I140-Softwarequality plan - Vesseldevelopment plan(X.PQA.1)

— A vessel developmentplan containingdescription ofhow all relevantISDS requirementsfor the systemintegrator (SI) will beperformed. Includingexplicit mapping to allSI requirement in thisstandard.

X.PQA.1 - Reviewcommentson I140documenttype


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

A.IV.3 3 Review the RAMSapproach for thevessel

Review of RAMSrequirements,the allocationto systems andthe plan forperforming RAMactivities to ensurecompleteness andconsistency. None

I300-RAMSdocumentation forthe vessel-List ofRAMS requirements(A.REQ.1)

I300-RAMSdocumentation forthe vessel-Plan forhandling of RAMS(A.RAMS.1)

— Completeness:

a) Listing of, laws,standards, andrules that applyregarding safety

b) Plan showingobjectives,methods, tools,and proceduresto be used.

c) Schedule ofRAMS activities.

d) RAM data to becollected

e) RAMSrequirements

A.REQ.1

A.RAMS.1

- Reviewcommentson allI300 inputdocumenttypes

B.IV.1 2 Review the systemdevelopment plans

The systemdevelopment planfor the suppliershall be reviewedto ensure that thesufficient plansand procedures areestablished to meetthe requirements ofthis standard.

The review shalladdress whetherall relevant ISDSrequirements areexplicitly mappedto the suppliersway-of-workingframework.

None

I140-Softwarequality plan - Systemdevelopment plan(X.PQA.1)

— A systemdevelopment plancontaining descriptionof how all relevantISDS requirementsfor the supplier (SU)will be performed.Including explicitmapping to all SUrequirement in thisstandard.

X.PQA.1 - Reviewcommentson I140documenttype


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

B.IV.2 2 Review therequirementsanalysis results

Review reportsfrom therequirementsanalysis todeterminecompleteness andconsistency of theanalysis.

None

Review report(B.CM.2)

System requirements(B.REQ.1)

— Completeness ofrequirements andsystems addressed inthe review report

B.REQ.1

B.CM.2

- Reviewcommentson reviewreportdocumenttypes

B.IV.3 2 Review integration,verification andvalidation strategyfor the vessel andsystems

Review verification/validation/integration strategyagainst technicalspecification forcompletenessof verificationintended to beachieved.

None

I140-Verification,Validation andIntegration Strategy(B.VV.1)

I030-Block (topology)diagram (A.DES.1)

— Completeness ofverification intendedto be achieved(functions, interfaces)

— Completeness ofvalidation intendedto be achieved(requirements)

— Completeness ofintegration plan withregards to software

A.DES.1

B.VV.1

- Reviewcommentson I140documenttypes


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

B.IV.4 3 Review andcomment onthe softwaredependentsystems partof the safetyanalysis for criticalfunctions in scopeof the ISDS

Review thesoftware-relatedRAMS risks andpriorities, andthe resultingsoftware dependentsystems-relatedRAMS mitigationactions.

Specialmethods forRAMS riskanalysis andmitigation areused, suchas: hazardidentification(HAZID),hazard andoperabilitystudy(HAZOP),Failure modeand effectsanalysis(FMEA), andfailure modes,effects,criticalityanalysis(FMECAs).

I300-RAMSdocumentation for thevessel - RAMS riskregister (B.RAMS.2)

I310-RAMSdocumentation for thesystem - RAMS riskregister (B.RAMS.3)

I300- RAMSdocumentationfor the vessel-RAMS risk analysisdocumentation(B.RAMS.2)

I310- RAMSdocumentationfor the system-RAMS risk analysisdocumentation(B.RAMS.3)

— Consistency of thescope selection forrisk identification,

— Consistency betweenvessel and systemlevel risk analysis,

— Consideration of thesoftware failuresmodes,

— Consideration of thehardware-inducedsoftware failuremodes.

B.RAMS.2

B.RAMS.3

- Reviewcommentson I300and I310documenttypes

B.IV.5 3 Review the RAMSapproach for thesystem

Review of RAMSrequirementsfor the system,and the plan forperforming RAMactivities to ensurecompleteness andconsistency.

None

I300-RAMSdocumentation forthe vessel-List ofRAMS requirements(B.REQ.1)

I300-RAMSdocumentation forthe vessel-Planfor handling ofRAMS(A.RAMS.1)

I310-RAMSdocumentation forthe system-Plan forhandling of RAMS(B.RAMS.1)

— Completeness:

a) Listing of, laws,standards, andrules that applyregarding safety

b) Plan showingobjectives,methods, tools,and proceduresto be used.

c) Schedule ofRAMS activities.

d) RAM data to becollected

e) RAMSrequirements.

A.RAMS.1

A.REQ.1

B.RAMS.1

- Reviewcommentson the I310documenttype


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

C.IV.1 2 Review theverificationanalysis prior toFAT

Review relevantinput to theverificationanalysis.

Review theverification analysisreport.

Participation at theverification analysisprior to FAT maybe required at therequest of the IV.

None

I020-Functionaldescription (B.DES.1)

Z120-Test procedureat manufacturer-System FAT procedure(C.VV.4)

Z130 -Report fromtest at manufacturer–System internal testreport(C.VV.2)

I140-Software qualityplan-Verification andvalidation strategy(B.VV.1)

Z290-Record-Traceability matrices(X.REQ.1)

Z320-Documentregister-Baselines(B.CM.2 and B.CM.3)

Z241 - Measurementreport - Verificationanalysis report(C.VV.3)

— Consistency betweenverification strategyand test procedures

— Completeness oftest procedures(functions, interfaces,design)

— Completeness of testcases

— Test reports reflectthe actual testresults with pass/fail judgements anddeviations fromprocedures

— Relevant test stagesand results areaddressed in theverification analysisand an explicitdecision of whetherto process to FAT ismade

B.CM.2

B.CM.3

B.DES.1

B.VV.1

C.VV.2

C.VV.3

C.VV.4

X.REQ.1

- Reviewcommentson Z241documenttype


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

C.IV.2 3 Review RAMSarguments andevidence for thesystem

The RAMSarguments andreviews shall bereviewed to ensurecompleteness andcompared with theRAMS requirementsfor the system.

None

I310-RAMSdocumentation forthe system-RAMScompliance report(C.RAMS.1)

I310-RAMSdocumentation forthe system-ListRAMS requirements(B.REQ.1)

I310-RAMSdocumentation for thesystem - RAMS riskregister ( B.RAMS.3)

I310-RAMSdocumentation forthe system-Plan forhandling of RAMS(B.RAMS.1)

— Completeness ofcontent:

a) RAM data andRAM calculations

b) RAMScompliancereport

— Risks to RAM andsoftware safety areunder control.

B.REQ.1

A.RAMS.2

B.RAMS.1

B.RAMS.3

C.RAMS.1

- Reviewcommentson I310-RAMScompliancereportdocumenttypes

D.IV.1 2 Review theintegrationreadinessreport prior tocommissioning

Review relevantinput to theintegrationreadiness report.

Review theintegrationreadiness report.

Participation atthe integrationreadinessreview prior tocommissioning maybe required at therequest of the IV.

None

I140-Software qualityplan - Verification,validation andintegration strategy(B.VV.1)

Report fromintegration readinessreview (D.INT.1)

— Relevant items in theintegration plan arecompleted

— Relevant ISDSrequirements havebeen completed

— An explicit decisionto move on to thecommissioningis included in theintegration readinessreport

B.VV.1

D.INT.1

-Reviewcommentson reportfromintegrationreadinessreviewdocumenttypes


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

D.IV.2 2 Perform softwareconfiguration audit

Perform softwareconfiguration auditsfor systems in ISDSscope

For systemsdeliveredwith multiplesub-systemdeliveries, e.g.equipmenthandling (EH),sampling ofselected sub-systems maybe performed.

Configurationmanagement rules

— The audited systemadheres to theconfigurationmanagement rules

D.CM.1 Softwareconfigurationaudit report

D.IV.3 3 Review RAMSarguments andevidence for thevessel

The RAMSarguments andreviews shall bereviewed to ensurecompleteness andcompared with theRAMS requirementsfor the vessel.

None

I300-RAMSdocumentation forthe vessel-Plan forhandling of RAMS(A.RAMS.1)

I300-RAMSdocumentationfor the vessel-List of regulatoryrequirements(A.REQ.1)

I300-RAMSdocumentation for thevessel-Security policy(A.RAMS.2)

I300-RAMSdocumentation forthe vessel-RAMScompliance report(D.RAMS.1)

I300-RAMSdocumentation for thevessel-Security auditreport (D.RAMS.2)

— Completeness ofcontent of reports

a) Calculationsof RAM valuesfor designatedsystems

b) RAMScompliancereport

— For CL2 systems:qualitative RAMS aregood enough

— For CL3 systems:qualitative RAMS arerequired

— Risks To RAM andSoftware Safety areunder control.

— Security audit hasbeen performed.

A.RAMS.1

A.RAMS.2

A.REQ.1

B.RAMS.2

D.RAMS.1

D.RAMS.2

- Reviewcommentson I300-RAMScompliancereportdocumenttypes


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

X.IV.1 2 Assess complianceto the ISDSstandard

Processes shallbe assessed todetermine howthey comply withthe applicable ISDSstandard.

An activity statusreport is issuedby the IV for eachmilestone.

This activity shallbe performed inphases A to D andmay be performedin phase E.

For phase E, seedescription ofannual and renewalassessments in

Ch.3 Sec.1 [3.2] -Sec.1 [3.3].

Eachorganizationis responsiblefor its qualityassurance.The qualityassurance isresponsible forensuring theISDS practicesare achieved.The purposeof the IV isnot to bearresponsibilityfor theorganizationsto performtheir activitiesas intended,but to verifythat sucha targethas beenachieved.

In addition relevantdocumentation isreviewed during theassessment.

— Compliance toISDS activitiesand documentrequirements.

All relevantISDSrequirementsfor thephase inquestion

- UpdatedISDS rating


NVG

L-OS-D



s (ISD

S)

DN

V G

L AS

Chapter 2 Section 8

Input


reference

Verificationoutput

X.IV.2 2 Analyse andpresent the ISDSassessment and IVactivities resultsfor the phase

Gather the resultsfrom the variousindependentverificationactivities.

Analyse theresults fromthe IV activitiesand analyse theassociated risks.

Present theanalysis result andassociated risks atmilestone meeting.

This activity shallbe performed inphases A to D.

The inputs tothis activityare the resultsfrom all theIV activitiesperformed inthe phase.

All documentsproduced by IVactivities.

IV activities - Milestonereport

- Milestonepresentation

Cha

pter

3 Sec

tion

1


DNV GL AS

CHAPTER 3 CLASSIFICATION AND CERTIFICATION

SECTION 1 REQUIREMENTS

1 General

1.1 Introduction

1.1.1 As well as representing DNV GL’s interpretation of safe and recommended engineering practice forgeneral use by the offshore industry, the offshore standards also provide the technical basis for DNV GLclassification, certification and verification services.

1.1.2 A complete description of principles, procedures, applicable class notations and technical basis foroffshore classification is given by the DNV GL rules for classification: offshore units (RU-OU), see Table 1.

Table 1 DNV GL rules for classification: Offshore units

Document code Title

DNVGL-RU-OU-0101 Offshore drilling and support units

DNVGL-RU-OU-0102 Floating production, storage and loading units

DNVGL-RU-OU-0103 Floating LNG/LPG production, storage and loading units

DNVGL-RU-OU-0104 Self elevating units, including wind turbine installation units and liftboats

1.2 Organisation of chapter threeThis chapter identifies the specific documentation, certification and surveying requirements to be appliedwhen using this standard for certification and classification purposes.

1.3 Classification principles

1.3.1 The requirements of this standard shall only be applied for systems also subject to classificationthrough main class and other additional class notations, as relevant.

1.3.2 As part of the classification process DNV GL shall take the role as the IV. IV activities are given in Ch.2Sec.8.

1.4 Compliance of activities

1.4.1 The requirements for all activities are listed in Ch.2 Sec.5 to Ch.2 Sec.7, and explained in detail inApp.B.

1.4.2 Compliance of activities is verified through assessments carried out by the Society. Each role shall beassessed by the DNV GL during the project. For the operation phase (E), assessments shall be performedregularly as defined in [3.1] to [3.3].

Cha

pter

3 Sec

tion

1


DNV GL AS

1.4.3 During the assessment the Society shall assess each activity for the relevant role, confidence level andproject phase. Findings shall be reported by the Society to the assessed role in an assessment report.

1.5 Approval of documents

1.5.1 The SI and suppliers shall submit the development plan (see X.PQA.1 in App.B [1.7.7]) for approvalprior to the initial ISDS assessment performed by DNV GL. The approved development plan will be used asbasis for the initial assessment.

1.5.2 The development plan shall be kept up to date throughout the project and the updated report shall beresubmitted if major changes are made.

1.5.3 Documentation, other than the development plan, listed under the documentation criteria for each rolein Ch.2 in this standard, shall be submitted to DNV GL for information.

Guidance note:

Findings from the review of these documents will be used to rate compliance of the relevant requirement (see [1.6]).


1.6 Rating of compliance

1.6.1 DNV GL rates the different activities defined for each role in Ch.2 based on observations duringassessments and document review, and list these as findings in an assessment report.

1.6.2 Some activities may be attributed a not applicable (NA) rating. This will be the case if the scope asdefined according to role and CL does not include the activity, or the activity can be rated NA by DNV GL if itdoes not apply in a project because of special circumstances.

1.7 Reporting and milestone meetings

1.7.1 Each assessed organisation will receive an assessment report with the major findings and status withregards to approval of activities.

1.7.2 DNV GL will provide input to the milestone meetings M1, M2, M3 and M4 in the form of a presentationof an ISDS status report which summarises the different organisation’s compliance with this standard asassessed by DNV GL.

1.7.3 DNV GL will at the same time provide an assessment of the risks associated with the total project’scompliance-status towards this standard.

2 Class notation

2.1 Designation

2.1.1 Vessels built and tested in compliance with the requirements of this standard may be assigned theoptional class notation ISDS.

2.1.2 ISDS may be assigned to a newbuilding when compliance is verified for phases A through D. Tomaintain the notation, compliance shall be verified for phase E.

Cha

pter

3 Sec

tion

1


DNV GL AS

2.1.3 The designation for the class notation shows the notation name, ISDS, the systems included in thescope of the notation, and the confidence level specified for each system: ISDS (system1CL, system2CL,…, systemnCL).

Guidance note:

Example: ISDS (DP2, PMS2, WCS3): these systems have been developed according to the scope and confidence levels identifiedin [2.2]. The dynamic positioning (DP) abbreviation refers to the system itself and not to the class notations such as DYNPOS-AUTR etc.


2.1.4 The ISDS class notation does not replace, but is complementary to other class notations.

2.2 Scope

2.2.1 Table 2 defines the systems and confidence levels recommended to include in the scope of the ISDSclass notation.

2.2.2 Unless otherwise agreed upon by the owner, system integrator and DNV GL, and specified by theowner, the scope and confidence levels defined in Table 2 apply for the ISDS class notation.

Table 2 ISDS class notation scope, system definitions and confidence levels for selected systems

FunctionSystem that may beincluded in scope forISDS

Typical sub-systems andcomponents4)

DNV GL standardreference1) CL Applicable for

— emergency shutdown (ESD)system.

DNVGL-OS-A101

— process shutdown (PSD)system.

DNVGL-OS-E101Shutdown anddisconnection systems(SDS) — critical alarm and action panel

(CAAP)— high integrity protection system

(HIPS).

DNVGL-OS-E201

2/3 Drilling unit

Wellintervention unit

FPSO

Floating storageunit (FSU)Prevent

escalationof abnormalconditions

Fire and gas system(F&G)

— fire and gas detection system— alarm and communication

system— systems for automatic action.

DNVGL-OS-D301 2 Drilling unit


FPSO

FSU

Cha

pter

3 Sec

tion

1


DNV GL AS




Well control Well control system(WCS)

— choke and kill system— diverter system— blow out prevention (BOP)

system or well control package(WCP), including

— topside panels— subsea electronic modules

(SEM)

— emergency disconnect system(EDS)/emergency quickdisconnect (EQD) system

— managed pressure drilling(MPD),

DNVGL-OS-E101 33) Drilling unit


Drilling control system(DCS)

— heating, ventilation, and airconditioning (HVAC) for driller’scabin and local equipment room

— driller’s chair— zone management/anti-collision

system— drilling data acquisition and

analysis system— top drive— drawwork (considered part of

HCTS if drawwork is used foractive heave compensation)

— rotary table

— drilling power managementsystem.

DNVGL-OS-E101 2 Drilling unit


Equipment handling(EH)

— pipe handling systems— casing handling— make up system— BOP handler.

DNVGL-OS.E101 2 Drilling unit


Heave compensationand tensioning system(HCTS)

— marine riser tensioners,including re-coil system

— active compensation systems— heave motion compensators,

DNVGL-OS-E101 22) Drilling unit


Drilling

Drilling fluid circulationand cementing (MUD)

— mud circulation system, highpressure

— mud control system, lowpressure

— cementing system.

DNVGL-OS-E101 2 Drilling unit


Cha

pter

3 Sec

tion

1


DNV GL AS




Work over/completion

Work over controlsystem (WOCS)

— WOCS container— WOCS’s chair— data acquisition system.

DNVGL-OS-E101 2 Wellintervention unit

Power managementsystem (PMS)

— power generation system— power distribution system— blackout prevention and load

reduction systems— blackout recovery systems.

DNVGL-OS-D201 2 All vessel types

Powergenerationanddistribution

Power plant controlsystem (PPC)

— governor and synchronizing unit— turbine controls— protection relays— thruster drives— drilling drives— high voltage or low voltage

switchboard, including

— synchronizing unit— protection relays.


Dynamic positioningsystem (DP)

— main, alternative and back-up DP control system (asapplicable)

— independent joystick system— positioning reference systems— thruster control mode selection

system.

DNVGL-RU-SHIPPt.6 Ch.3

2 All vessel types

POSMOOR system(POS)

— POSMOOR control system— independent joystick system— positioning reference systems— active mooring equipment, e.g.

windlass and winch.

DNVGL-OS-E301 2 Drilling Unit

WellInterventionUnit

FPSO

FSU

Positionkeeping

Jacking systems(JACK)

— hydraulic system— jacking and fixation system— drives.

DNVGL-OS-D101 2 Drilling unit


Wind installationunit

Steering,propulsionand thrustercontrol andmonitoringsystems

Steering, propulsionand thruster controland monitoring system(SPT)

— steering system— propulsion system— thruster system.

DNVGL-RU-SHIPPt.4 Ch.9

2 All vessel types

Cha

pter

3 Sec

tion

1


DNV GL AS




Control andmonitoring

Integrated control andmonitoring system(ICM)

— vessel alarm system— sea water, fresh water, hot

water, high pressure wash downsystem

— fuel oil system— HVAC system— service, instrument and bulk air

system— hydraulic power system— bilge and ballast system— load and stability system.


1) Only systems and components with software should be considered.2) CL3 should be applied for vessels involved in fixed-to-bottom operations that rely on software (SW) for heave

compensation (e.g. active heave drawworks).3) CL2 may be applied where redundancy is based on passive components, typical for choke and kill systems.4) For all systems, operating stations, interfaces to others systems and networks shall be included where applicable.

2.2.3 Other systems than those listed in Table 2 that may be included in the ISDS notation at CL2 or CL3are:

— crane (CR)— navigation systems (NAV)— process control system (PCS)— well test system (WT)— workover completion system (WOCS)— cargo control and monitoring (CCM)— remote access and diagnostic system (RAD)— diving system (DIVE)— tension leg control system (TL).

2.2.4 For each system a reference to the applicable DNV GL rules for classification: Ships (RU-SHIP) or DNVGL offshore standards (OS) is listed. The rules or standards identified will provide a more specific descriptionof the systems. DNVGL-OS-D202 provides generic common requirements to, and is applicable for, all systemslisted above.

3 In operation assessments

3.1 Objectives

3.1.1 The ISDS class notation is maintained through demonstrating compliance to the requirements of thisstandard in the operation phase.

3.1.2 DNV GL, as the IV, shall perform an annual assessment of the vessel in operation to verify compliance.

3.1.3 DNV GL shall perform a renewal assessment of the vessel every fifth year.

Cha

pter

3 Sec

tion

1


DNV GL AS

3.1.4 Annual and renewal assessments for the ISDS notation shall be carried out at the same time andinterval as the periodical classification survey of the vessel, but may be based on of documentation andevidence assessed onshore.

3.1.5 An action plan that demonstrates how findings will be closed shall be prepared by the owner. DNV GLshall verify, through re-assessment(s), that the action plan is implemented and the notation maintained.

3.1.6 The owner shall inform DNV GL whenever a system with the ISDS notation is modified. For majorupgrades or conversions of the vessel in operation the full set of requirements in this standard may apply.

3.2 Scope of annual assessments

3.2.1 The purpose of the annual assessment shall ensure that the confidence that has been built into thevessel is actually maintained. The effective implementation and continuous maintenance of the activitiesrequired by this standard for phase E, operation, shall be assessed.

3.2.2 As part of the annual assessment any changes, introduced after the latest assessment, to the systemswithin ISDS scope shall be addressed. An impact analysis of changes shall be reviewed and confirmed. Anyfollow up activities shall be agreed upon.

3.2.3 Updated evidence shall be kept and made available for review by the attending surveyor. Relevantevidence include (with reference to required activity in parentheses):

— Inventory and spare part records with focus on obsolescence (E.DES.1).— Configuration management plan and logs for configuration management activities, including SW change

orders (E.CM.1).— Change request logs including impact assessments (E.CM.1).— Configuration audit reports (E.CM.2).— Procedures for modifications request (E.PQA.1).— Maintenance plans and procedures (E.RAMS.1 and E.PQA.1).— Maintenance in operation plans, including migration and SW retirement plans (E.RAMS.1).— Records of RAMS data (E.RAMS.2).— Analysis and investigation reports from RAMS incidents/failures (E.RAMS.3).— Records of RAMS impact analysis (E.RAMS.4).— Security audit reports (E.RAMS.5).— Records from validation, verification and testing, as relevant if systems have been changed in operation

(E.VV1).— Version histories for baselines, requirements trace and configuration records (X.CM.1).

3.3 Scope of renewal assessmentsThe scope of the annual assessment shall be carried out. This is based on the operation phase requirementsstated in this standard. In addition the renewal assessment shall have a specific focus on identified processareas or activities. These areas or activities shall be selected based on a discussion with owner of specificfocus areas and on important or frequent findings from the annual assessments carried out since the lastrenewal.

App

endi

x A


DNV GL AS

APPENDIX A DEFINITIONS AND ABBREVIATIONS

1 Definitions

1.1 Verbal forms

Table 1 Verbal forms

Term Definition

shall verbal form used to indicate requirements strictly to be followed in order to conform to thedocument

should verbal form used to indicate that among several possibilities one is recommended asparticularly suitable, without mentioning or excluding others, or that a certain course of actionis preferred but not necessarily required

may verbal form used to indicate a course of action permissible within the limits of the document

1.2 Definitions

Table 2 Definitions

Term Definition

acceptance criteria the criteria that a system or component must satisfy in order to be accepted by a user,customer, or other authorized entitySee IEEE Std 610.12:1990.

activity a defined body of work to be performed, including its required input and output (IO)informationSee The Institute of Electrical and Electronics Engineers (IEEE) Std 1074-2006.

application software software designed to fill specific needs of a user

assessment an activity to collect, review, analyse evidences of compliance and implementation against areference standard, reference model or reference framework

audit an independent examination of a work product or set of work products to assess compliancewith specifications, standards, contractual agreements, or other criteriaSee IEEE Std 610.12-1990.

availability the ability of the system to provide access to its resources in a timely manner for a specifieddurationSee The International Electrotechnical Commission (IEC) IEV-191-02-05), alternatively, thetime or proportion of time that the system is functioning as intended.

baseline a consistent set of specifications or products that have been formally reviewed and agreedupon, that thereafter serve as the basis for further development, and that may only bechanged through formal change control proceduresSee International Organization for Standardization (ISO)/IEC 15288:2008).

base product a pre-existing product which is reused, configured, qualified, modified or enhanced to meetthe specific needs of new projects

App

endi

x A


DNV GL AS

Term Definition

black-box 1) a system or component whose inputs, outputs, and general function are known butwhose contents or implementation are unknown or irrelevant

2) pertaining to an approach that treats a system or component as in 1)

See IEEE Std 610.12:1990.

black-box testing see functional testing

block diagram a diagram of a system, computer, or device in which the principal parts are representedby suitably annotated geometrical figures to show both the functions of the parts and theirfunctional relationshipsSee IEEE Std 610.12:1990.

change control board see configuration control board

code review systematic examination (often as peer review) of computer source code intended to find andfix mistakes overlooked in the initial development phase, improving the overall quality ofsoftware, code review may also be partly automated

commercial off-the-shelf(COTS)

COTS products are ready-made packages sold off-the-shelf to the acquirer who had noinfluence on its features and other qualities, typically the software is sold pre-wrapped withits user documentation

See ISO/IEC 25051:2006(E).

commissioning (tests) verifying and documenting that the unit and all of its systems are designed, installed, testedand can be operated and maintained to meet the owner's requirements

component a logical grouping of other components or modules inside a system or sub-system

component testing testing of individual hardware or software components or groups of related componentsSee IEEE Std 610.12:1990.

configuration audits activities ensuring that the configuration management process is followed and that theevolution of a product is compliant to specifications, policies, and contractual agreements

Functional configuration audits are intended to validate that the development of aconfiguration item has been completed and it has achieved the performance and functionalcharacteristics specified in the system specification (functional baseline). The physicalconfiguration audit is a technical review of the configuration item to verify that the as-builtmaps to the technical documentation

See International Council on Systems Engineering (INCOSE) SE, 2004.

configuration controlboard

a group of people or a person responsible for evaluating and approving or disapprovingproposed changes to configuration items, and for ensuring implementation of approvedchanges

configuration data data used to configure/tailor a system or component, the data needs to be quality assured

configuration item an aggregation of hardware, software, or both, that is designated for configurationmanagement and treated as a single entity in the configuration management processSee IEEE Std 610.12:1990.

consequence (failure) real or relative magnitude of the seriousness of the failure (business, environmental andsafety)

consistency the degree of uniformity, standardization, and freedom from contradiction among thedocuments or parts of a system or componentSee IEEE 610.12:1990.

App

endi

x A


DNV GL AS

Term Definition

coverage the amount or proportion of a software component that has been tested, it is commonlyquantified by counting the execution of statements, decision outcomes, and I/0 values,coverage measures help to identify unreachable and untested code

critical any function or component whose failure could interfere significantly with the operation oractivity under consideration

criticality the degree of impact that a requirement, module, error, fault, failure, or other item has onthe development or operation of a systemSee IEEE Std 610.12:1990.

cycle time 1) the period of time required to complete a sequence of events2) a set of operations that is repeated regularly in the same sequence, possibly with

variations in each repetition, for example, a computer's read cycle


deadlock a situation in which computer processing is suspended because two or more devices orprocesses are each awaiting resources assigned to the othersSee IEEE Std 610.12:1990.

decision coverage a measure of the amount of software tested, typically expressed as the number orpercentage of outcomes of decision statements in the component that have been tested

defect non-fulfilment of a requirement related to an intended or specified useSee ISO 9000:2005.

dependability collective term used to describe the availability performance and its influencing factors:reliability performance, maintainability performance and maintenance support performance,see RAMS, to which it adds security

See IEC IEV-191-02-03.

due diligence (software) an investigation, validation and verification of a software system/sub-system/component/module for proving its usefulness and conformity in a given context

error a discrepancy between a computed, observed or measured value and condition and the true,specified or theoretically correct value or conditionSee IEC 61508-4.

essential function (orsystem)

a system supporting the function, which needs to be in continuous operation or continuouslyavailable for on demand operation for maintaining the unit's safetySee DNVGL-OS-D202.

established design a design that has largely been previously, successfully implemented, such designs are oftenthe basis for turnkey fixed price systems such as current generation drill ships

factory acceptance tests(FAT)

acceptance testing (see above) of a component, sub-system or system before delivery andintegration

failure the termination of the ability of a functional unit to perform a required function on demand.

Note: a fault in a part of the system may lead to the failure of its function, itself leading to afault in other linked parts or systems etc.

failure mode a defined manner in which a failure may occur, failure modes can be seen as scenarios forhow a system may go wrong

App

endi

x A


DNV GL AS

Term Definition

fault abnormal condition that may cause a reduction in, or loss of, the capability of a functionalunit to perform a required function excluding the inability during preventive maintenance orother planned actions, or due to lack of external resourcesSee IEC 61508-4.

finding the result of approval, assessment and renewal activities by DNV GL, identifying the mostimportant issues, problems or opportunities for improvement within the scope of thisstandard

firmware the combination of a hardware device and computer instructions and data that reside asread-only software on that deviceSee IEEE Std 610.12:1990.

functional requirement a requirement that specifies a function that a system or system component shall be able toperformSee IEEE Std 610.12:1990.

functional testing 1) testing that ignores the internal mechanism of a system or component and focusessolely on the outputs generated in response to selected inputs and execution conditions

2) testing conducted to evaluate the compliance of a system or component with specifiedfunctional requirements


impact analysis analysis, which identifies all systems and software products affected by a software changerequest and develops an estimate of the resources needed to accomplish the change anddetermines the risk of making the changeSee SWEBOK, 2004.

integration strategy an assembly sequence and strategy that minimizes system integration risks.

This strategy may permit verification against a sequence of progressively more completecomponent configurations and be consistent with a fault isolation and diagnosis strategy. Itdefines the schedule of component availability and the availability of the verification facilities,including test jigs, conditioning facilities, assembly equipment

See ISO/IEC 15288.

integrated softwaredependent system

an integrated software dependent system is an integrated system for which the overallbehaviour is dependent on the behaviour of its software components.

integrated system an integrated system is a set of elements which interact according to a design, where anelement of a system can be another system, called a subsystem, which may be a controllingsystem or a controlled system and may include hardware, software and human interactionSee IEC 61508-4.

inter-system term used to define something between systems, e.g. interfaces, behaviour, functionality

intra-system term used to define something within a system, e.g. interfaces

interface 1) a shared boundary across which information is passed2) a hardware or software component that connects two or more other components for the

purpose of passing information from one to the other3) to connect two or more components for the purpose of passing information from one to

the other4) to serve as a connecting or connected component as in 2), (see IEEE Std 610.12:1990)5) a collection of operations that are used to specify a service of a component

interface specification data describing the communications and interactions among systems and subsystems

App

endi

x A


DNV GL AS

Term Definition

interface testing testing conducted to evaluate whether systems or components pass data and controlcorrectly to one anotherSee IEEE Std 610.12:1990.

maintainability 1) the ease with which a software system or component can be modified to correct faults,improve performance or other attributes, or adapt to a changed environment.

2) the ease with which a hardware system or component may be retained in, or restoredto, a state in which it can perform its required functions, see IEEE Std 610.12:1990

migration system migration involves moving a set of instructions or programs, e.g. programmablelogical controller (PLC) programs, from one platform to another, minimizing reengineering,migration of systems can also involve downtime, while the old system is replaced with a newone

milestone a scheduled event marking the transition from one project phase to the next, this standardidentifies five milestones

mitigation action that reduces the consequence(s) of a hazardous event or riskSee IEC 61511-1.

modification request see change request.

module in this standard used to describe the lowest branches in the system hierarchy, modules canbe made of hardware (HW) or software (SW)

non-functionalrequirement

a requirement that specifies a characteristic or property that is not described as function,e.g. performance requirements

non-standard legacysoftware

non-standard software is software that was not designed to be reused, but may be reusedanyway

novel a feature, capability, or interface that largely is not present in the base product

obsolescence (risk) risk associated with technology within the system that becomes obsolete before the endof the expected shelf or operations life, and cannot provide the planned and desiredfunctionality

operational scenarios a description of a typical sequence of events that includes the interaction of the systemenvironment and users, as well as interaction among its components

peer review a process of subjecting an author's work to the scrutiny of others who are experts in thesame field

portability the ease with which a system or component may be transferred from one hardware orsoftware environment to anotherSee IEEE Std 610.12:1990.

probability (of failure ondemand)

for hardware and random failures, probability that an item fails to operate when required,this probability is estimated by the ratio of the number of failures to operate for a givennumber of commands to operate (demands)

See IEC IEV-191-29-1.

project in the context of this standard the term project refers to the activities, responsibilities androles involved in a new build or upgrade project where the ISDS standard is applied

App

endi

x A


DNV GL AS

Term Definition

prototype a model implemented to check the feasibility of implementing the system against the givenconstraints, to communicate the specifier’s interpretation of the system to the customer, inorder to locate misunderstandings.

A subset of system functions, constraints, and performance requirements are selected.A prototype is built using high-level tools. At this stage, constraints such as the targetcomputer, implementation language, program size, maintainability, reliability and availabilityneed not be considered

See ISO/IEC 61508-7:2010.

prototyping a hardware and software development technique in which a preliminary version of part or allof the hardware or software is developed to permit user feed-back, determine feasibility, orinvestigate timing or other issues in support of the development processSee IEEE Std 610.12-1990.

quality target the objective or criteria agreed by the stakeholders to be reached for a quality characteristic,ISO/IEC 9126-1 proposes many quality characteristics for consideration

record information or documents stating results achieved or providing evidence of activitiesperformed

redundancy the existence of more than one means for performing a required function or for representinginformation (see IEC 61508-4) redundancy prevents the entire system from failing when onecomponent fails

regression testing selective retesting of a system or component to verify that modifications have not causedunintended effects and that the system or component still complies with its specifiedrequirementsSee IEEE Std 610.12:1990.

release note the term release is used to refer to the distribution of a software configuration item outsidethe development activity.

This includes internal releases as activities might contain provisions which cannot be satisfiedat the designated point in the life cycle (see IEEE 12207.0-96:c6s2.6).

The release notes typically describe new capabilities, known problems, and platformrequirements necessary for proper product operation (see SWEBOK, 2004).

reliability the capability of the ISDS to maintain a specified level of performance when used underspecified conditions

reliability, availability,maintainability,(functional) safety(RAMS)

a set of commonly linked generic system attributes that often need to be dealt with in asystematic manner, see also dependability

requirement a condition or capability that shall be met or possessed by a system or system component tosatisfy a contract, standard, specification, or other formally imposed documentsSee IEEE Std 610.12:1990.

reused software software integrated into the system that is not developed during the project, i.e. bothstandard software and non-standard legacy software, software may be reused as is or beconfigured or modified

review activity undertaken to determine the suitability, adequacy and effectiveness of the subjectmatter to achieve established objectivesSee ISO 9000:2005.

App

endi

x A


DNV GL AS

Term Definition

revision control management of multiple revisions of the same unit of information (also known as versioncontrol, source control or (source) code management)

risk the qualitative or quantitative likelihood of an accident or unplanned event occurring,considered in conjunction with the potential consequences of such a failure, in quantitativeterms, risk is the quantified probability of a defined failure mode times its quantifiedconsequence

role a role is an organization with responsibilities within the system lifecycle, a role has specificactivities to perform

See Ch.2 Sec.3 [1.2].

safety integrity level (SIL) a relative level of risk-reduction provided by a safety function, or to specify a target level ofrisk reduction. IEC 61508 defines four levels, where SIL 4 is the most dependable and SIL 1is the least, SIL is not to be confused with confidence level, which is defined in Ch.2 Sec.2

software computer programs, procedures, and possibly associated documentation and data pertainingto the operation of a computer systemSee IEEE Std 610.12:1990.

software component a software component is an interacting set of software modules

software lifecycle the period of time that begins when a software product is conceived and ends when thesoftware is no longer available for use. The software life cycle typically includes a conceptphase, requirements phase, design phase, implementation phase, test phase, installation andcheckout phase, operation and maintenance phase, and, sometimes, retirement phase.

Note: these phases may overlap or be performed iteratively.


software module separately compilable or executable piece of source code. It is also called software unit orsoftware package (see ISO/IEC 12207:2008). A small self-contained program which carriesout a clearly defined task and is intended to operate within a larger program.

single point of failure component or interface of a system for which no backup or redundancy exists and the failureof which will disable the entire system

simulation one of real-world simulation, process simulation, electronic circuit simulation, faultsimulation, simulation of software in the loop (SIL), simulation of the system’s environmentor hardware-in-the-loop (HIL), simulators serve various purposes and use different modellingtechniques

See ISO/IEC 61508-7:2010.

site acceptance tests(SAT)

an acceptance test for a fully integrated system, may be part of commissioning, or may beperformed in the factory before delivery to the unit

source code computer instructions and data definitions expressed in a form suitable for input to anassembler, compiler, interpreter or other translatorSee IEEE Std 610.12:1990.

specification a document that specifies, in a complete, precise, verifiable manner, the requirements,design, behaviour, or other characteristics of a system or component, and, often, theprocedures for determining whether these provisions have been satisfied


standard software ready-made and packaged software intended to be used in different systems, for exampleCOTS software, the ISDS supplier’s own developed standard software components, and opensource software

App

endi

x A


DNV GL AS

Term Definition

state diagram a diagram that depicts the states that a system or component can assume, and shows theevents or circumstances that cause or result from a change from one state to anotherSee IEEE Std 610.12:1990.

statement coverage a measure of the amount of software that has been tested, typically expressed as apercentage of the statements executed out of all the statements in the component tested

static analysis the process of evaluating a system or component based on its form, structure, content, ordocumentation, contrast with: dynamic analysis


statistical testing a testing method based on allocating test cases to components and functions in proportion totheir expected use in operational scenarios, also called random testing, data from statisticaltesting may be used to predict operational reliability

sub-supplier (in the context of this standard) organisations and companies delivering products andservices to suppliers

sub-system a sub-system is a part of a system, for example choke and kill is a part of the well controlsystem, the independent joystick is part of the DP system

See definition in Ch.3 Sec.1 [2].

system a defined product which contains sub-systems, for the purposes of the ISDS notation, asystem refers to the qualifier identified in the notation, for example DP, DCS, PMS, etc.

See Ch.3 Sec.1 [2].

system architecture a selection of the types of system elements, their characteristics, and their arrangementSee INCOSE SE 2004.

system design review a review conducted to evaluate the manner in which the requirements for a system havebeen allocated to configuration items, the system engineering process that producedthe allocation, the engineering planning for the next phase of the effort, manufacturingconsiderations, and the planning for production engineeringSee IEEE Std 610.12:1990.

system testing testing conducted on a complete, integrated system to evaluate the system's compliancewith its specified requirements

See component testing, integration testing, interface testing, (IEEE Std 610.12:1990) .

stress testing testing conducted to evaluate a system or component at or beyond the limits of its specifiedrequirementsSee IEEE Std 610.12:1990.

target environment the configuration of network protocols, computers, PLCs, sensors, final elements and otherhardware on which a software integrated system is intended to be executed in operations

test case a specification of a test in terms of:

— a description of the purpose of the test— pre-conditions (e.g. the state of the software under test and it’s environment)— actions organized in one or several scenarios (including what data to provide)— expected results

traceability linkage between requirements and subsequent work products, e.g. design documentationand test documentation

App

endi

x A


DNV GL AS

Term Definition

traceability matrix a matrix that records the relationship between two or more products of the developmentprocess, for example, a matrix that records the relationship between the requirements andthe design of a given software componentSee IEEE Std 610.12:1990.

unit the vessel that will get the ISDS notation, typically a mobile offshore unit (MOU) or a ship

use case the use case specifies the concepts used primarily to define the behaviour and thefunctionality of a system or a subsystem, without specifying its internal structure, use casesand actors (users) interact when the services of the system are used, in this context an actorplays a coherent set of roles when interacting with the system, note that in the use casecontext an actor may be a user or another system interacting with the first one

See IEC 19501:2005.

validation confirmation, through the provision of objective evidence that the requirements for a specificintended use or application have been fulfilledSee ISO 9000:2005.

validation strategy identification (e.g. list) of validation activities to be performed, along with validationmethods, objectives, and responsibility assigned to them, the purpose of this strategy is tominimize redundancy and maximize effectiveness of the various validation activities

verification tasks, actions and activities performed to evaluate progress and effectiveness of theevolving system solutions (people, products and process) and to measure compliance withrequirements.

Analysis (including simulation, demonstration, test and inspection) are verificationapproaches used to evaluate risk, people, product and process capabilities, compliance withrequirements, and proof of concept

See INCOSE SE, 2004.

verification strategy identification (e.g. list) of verification activities to be performed, along with verificationmethods, objectives, and responsibility assigned to them. The purpose of this strategy is tominimize redundancy and maximize effectiveness of the various verification activities.

version software items evolve as a software project proceeds, a version of a software item is aparticular identified and specified item, it may be thought of as a state of an evolving item

See SWEBOK, 2004.

white box testing a testing method that uses knowledge of the internal organization of the software to selecttest cases that provides adequate coverage of the software, white box testing is also calledstructural testing

work product a deliverable or outcome that shall be produced to prove the completion of an activity ortask, work products may also be referred to as artefacts

App

endi

x A


DNV GL AS

2 AbbreviationsThe abbreviations in Table 3 are used.

Table 3 Abbreviations

Abbreviation Description

ACQ activities in the acquisition

AP for approval

BOP blow out prevention

CAAP critical alarm and action panel

CCB change control board

CCM cargo control and monitoring

CL confidence level

COTS commercial off-the-shelf

CPU central processing unit

CR crane

DCS drilling control system

DIVE diving system

DP dynamic positioning

EDS emergency disconnect system

EH equipment handling

EQD emergency quick disconnect

ESD emergency shutdown

F&G fire and gas system

FAT factory acceptance tests

FEED front-end engineering and design

FI for information

FMEA failure mode and effects analysis

FMECA failure modes, effects, criticality analysis

FPSO floating production storage and offloading units

FSU floating storage unit

HAZID hazard identification

HAZOP hazard and operability study

HCTS heave compensation and tensioning system

HIPS high integrity protection system

App

endi

x A


DNV GL AS


HVAC heating, ventilation, and air conditioning

HW hardware (as opposed to software)

IAS integrated automation system

ICM integrated control and monitoring system

IEC The International Electrotechnical Commission

IEEE The Institute of Electrical and Electronics Engineers

INCOSE International Council on Systems Engineering

INT integration process area

IO input/output

I/O input/output

ISDS integrated software dependent systems

ISO International Organization for Standardization

IV independent verifier

JACK jacking systems

MOU mobile offshore unit

MPD managed pressure drilling

MTTF mean time to failure

MTBF mean time between failures

MTTR mean time to repair

MUD drilling fluid circulation and cementing

NA not applicable

NAV navigation systems

OS offshore standard

OW owner

PCS process control system

PLC programmable logical controller

PMS power management system

POSMOOR position mooring

POS POSMOOR system

PPC power plant control system

PSD process shut down

RAD remote access and diagnostic system

RAM reliability, availability, maintainability

App

endi

x A


DNV GL AS


RAMS reliability, availability, maintainability, safety

RP recommended practice

SAT site acceptance tests

SDS shutdown and disconnection systems

SEM subsea electronic module

SI system integrator

SPT steering, propulsion and thruster control and monitoring system

SU supplier

SW software

TBS technical building specification

TL tension leg control system

UIO unit in operation

WBS work breakdown structure

WCS well control system

WCP well control package

WOCS work over control system

WT well test system

App

endi

x B


DNV GL AS

APPENDIX B REQUIREMENT DEFINITION

1 Requirement definition

1.1 General

1.1.1 The following lists the required activities for all phases and all roles.

1.1.2 Each activity is presented in the same manner. The list of activities is sorted alphabetically by theactivity ID and contains the following elements:

— The header describes the unique activity identifier (ID), enabling easy reference and traceability, and thename of the activity. The identifier is structured in three parts: Z.YYY.NN. The first part (Z) of the activityidentifier refers to the project phase. The second part (YYY) of the activity identifier refers to the processarea. The third part (NN) of the activity identifier is a unique number for the activity.

— The phase and the confidence level at which the activity is to be performed.— Assignment of responsible roles for vessel and system level.— The requirement definition provides a detailed description of the activity requirements.— A guidance note is provided when needed.— The assessment criteria field provides typical evidence to be made available by the responsible role(s)

for the assessment. It is not required that all of the documents listed shall be presented, but all relevantinformation should be provided to the IV as part of the assessment process.

— The documentation criteria field provides a list of required documentation to be submitted to DNV GL forapproval (AP) or for information (FI).

1.2 Basic engineering phase

1.2.1 A.CM.1 Establish a baseline of requirements for the vesselPhase: basic engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: a baseline of the vessel requirements shall be established at the end of the basic engineeringphase. This baseline shall be used as the reference when requirements evolve in later phases.

Guidance note:

This activity is based on the output from activity A.REQ.1. The baseline is a consistent set of information elements that have beenformally reviewed and agreed upon, that thereafter serve as the basis for further development, and that may be changed onlythrough formal change control procedures. Changes to these baselines require review and approval by appropriate stakeholders,see X.CM.1 in [1.7.3].


Assessment criteria Documents required for review by the IV

Approved and formally version controlled vesselrequirements document.

Revision history of vessel requirements document.

None

App

endi

x B


DNV GL AS

1.2.2 A.DES.1 Establish the vessel designPhase: basic engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: a top level architecture of the systems and software within ISDS scope shall be established,identifying the systems and their interrelationships, including the required interfaces. Relevant vessel designdocumentation shall be sent to the supplier.

Guidance note:

The documentation of this is typically in the form of a interface matrix and block-diagrams. All major software dependent systemsare expected to be included in the design documentation.

The design of the vessel and its systems should be presented to representatives of the end users to ensure it may fulfil theirneeds. The design validation allows the project to get early feedback from the users, increase the user awareness of the futurevessel, and reduce issues during commissioning and sea trials.



Vessel design: vessel design specifications, systems/network topology, interface matrix, block diagrams andfunctional descriptions.

Vessel design (FI) used in B.IV.2 for CL.2

1.2.3 A.PM.1 Establish the project master planPhase: basic engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: a master plan for the development, verification and integration of the vessel’s systems inISDS scope shall be established. The plan shall contain a high level master schedule, taking into account roughestimations and input from potential suppliers. Milestones for the whole project shall be established, includingmilestones required by this ISDS standards. All stakeholders shall be in agreement on the plan.

Guidance note:

The project plan and the milestones should typically show the requirements and design freeze dates. The owner should beconsulted to provide input to schedule constraints and the master schedule in general.

Master document list(s) or equivalent should be established at an early stage to ensure that all required information/documents(including all elements required by this standard) are planned to be transmitted between the organizations. The schedule in theproject plan should give the planned dates for when the main documents will be transferred to the relevant stakeholders. This is tohave a better overview of when to expect necessary inputs to important activities in the different organisations, and to improve thecommitment of the organisations to distribute documents as expected in the project.



Master plan: activities, integration dependencies,schedule and milestones.

Master document list.

None

App

endi

x B


DNV GL AS

1.2.4 A.RAMS.1 Develop the reliability, availability, maintainability, safety plan for the vesselPhase: basic engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: RAMS activities shall be planned, including methods and tools to be used.

Expectations on the suppliers’ RAMS activities, plans and reporting shall be identified.

Guidance note:

The methods, tools and procedures used in all RAMS-related activities should be defined, documented and put under configurationcontrol. This activity provides input to the activity B.RAMS.1. The RAMS plan should cover all relevant RAMS activities includedin this standard, as well as addressing RAMS specific requirements from the owner. This activity may be coordinated with theactivities A.PM.1 and X.PQA.1 and the RAMS plan may be a separate document, or a part of the project plan or quality assuranceplan. Safety may be dealt with separately, for example in a functional safety management plan.

The expectations to the suppliers RAMS activities and plans is expected to be included in the contracts with the suppliers.



Plan(s) showing the methods, tools, and procedures to beused for RAMS activities.

Schedule of RAMS activities.

Expectations on the suppliers’ RAMS plan.

RAM data to be collected (CL3).


— reviewed in A.IV.3 at CL3— used in B.IV.3 at CL3.— used in D.IV.3 at CL3.

1.2.5 A.RAMS.2 Establish security policy for the vesselPhase: basic engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: a policy addressing cyber security for control systems and information within the ISDS scopeshall be defined and communicated to vendors. This policy shall include at least the applicable requirements fromDNVGL-OS-D202. The policy will also address any requirements provided by the owner in OW.REQ.1. Suppliers shallconform to this policy.

Guidance note:

The security policy should address passwords and privileges, virus scanning, firewalls, patch management, approved/disalloweddevices and physical access.

The security policy may be established by designating an existing standard to be followed. A number of different standards areavailable and one of them may be used as a basis for the security audit, e.g. ISA/IEC 62443, ISO 27001/27002 and ISO 62443.

Owner and yard-specific requirements should be considered as well. Ideally, the security policy should be included in the TBSspecified in vendors' contracts.

The security policy should serve as the basis for security audits to be conducted prior to delivery, see D.RAMS.2 in [1.5.5].

DNVGL-RP-0496 Cyber security resilience management for ships and mobile offshore units in operation describes a process foridentifying security risks and mitigations.



Security policy for this project Security policy (FI), used in D.IV.3

App

endi

x B


DNV GL AS

1.2.6 A.REQ.1 Perform requirements analysis for the vessel and systemsPhase: basic engineering.Vessel level responsible system integrator.System level responsible: none.

Requirement definition: owner requirements shall be collected and analysed. The analysis shall focus on addressingoperational needs and system requirements, along with the constraints the owner is placing on the vessel andsystems.

Rules, standards and applicable laws for safety requirements shall be identified, reviewed and agreed upon.

The requirements shall be organized into packages that should serve as the basis for the development of eachsystem. The output of this activity shall be used to detail system requirements specifications to the suppliers.

Guidance note:

The requirements from the owner should be defined prior to the phase A, see OW.REQ.1 in Ch.2 Sec5 [1.1.1].

It is important that requirements on individual systems are defined while taking into account interacting systems and the wholevessel. For each system following requirements should be identified:

— functionality

— reliability

— availability

— maintainability

— safety

— security

— usability

— efficiency

— portability

— integrability

— performance.

The analysis of the requirements may be supported by prototyping, FEED studies, technology qualification or other means.

For critical and novel systems, operational needs should be further detailed by using operational scenarios to capture expectedbehaviour and system interaction. This may be documented by creating a concept of operation document (CO-OPS). For more infosee the ANSI/AIAA G-043-1992 (focusing on new systems) and IEEE Std 1362 (focusing on upgrades to existing systems).

Sources of rules include flag states, shelf states, and classification societies. Also, industry standards such as IEC 61508/61511 orISO 17894 may be applied.

RAM requirements should be explicitly defined as quantitative or qualitative targets or objectives to be met by the functions or thesystems. Explicit RAM requirements should be defined for all systems within the ISDS scope.

As an example of a quantitative requirement, mean time to failure (MTTF) or mean time between failures (MTBF) for a givensystem in a given environment may be used as a reliability target. Relative reliability (e.g. more reliable than…) is an example ofa qualitative requirement. RAM requirements may be part of an overall requirements document. The owner should be consulted ifthe requirements from the owner needs further clarification.



Vessel specification addressing all systems in ISDS scope:operational requirements, functional requirements,RAMS requirements, security requirements, useabilityrequirements, efficiency requirements, portabilityrequirements, integrability requirements, performancerequirements and technical constraints.

RAMS requirements (FI):

— reviewed in A.IV.3 at CL3.— used in B.IV.3 at CL3— used in D.IV.3 at CL3

App

endi

x B


DNV GL AS

1.2.7 A.REQ.2 Establish traceability of requirementsPhase: basic engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition The mechanisms, ambition-level, and eventual tools to be used for the traceability ofrequirements shall be defined and communicated to suppliers. Traceability between different levels of requirementsshall be documented, and shall at this point in time at least cover the trace from vessel level requirements to systemlevel requirements.

Guidance note:

Three different types of traceability are normally expected to be documented during the project, (see X.REQ.1 in [1.7.10]):

1) Traceability between requirements on different levels (e.g. from vessel to system).

2) Traceability from a requirement to where and how it is designed and implemented.

3) Traceability from a requirement to where and how it is verified and validated.

Different levels and granularity of traceability may be defined depending on the complexity and the risk of not achieving therequirements and the confidence level of the system in question. The owner, system integrator and supplier should agree on thelevel of granularity to be applied, see X.PQA.2 in [1.7.8]. DNV GL recommends to trace from requirements to uniquely identifiablerefined requirements, design elements, source code (function/class/method/function block) and test cases.

The traceability information should be kept up to date as described in activity X.REQ.1, this also includes updates that the suppliersare expected to perform.

Traceability matrices are normally used to document the requirement allocation, but also databases or references from documentsto documents may be used as long as the traceability information is explicit and reviewable.



Requirements specification for relevant systems.

Traceability information between requirements on vessellevel and requirements on the different systems.

Defined mechanisms and ambition-level regardingrequirements traceability.

None

App

endi

x B


DNV GL AS

1.3 Engineering phase

1.3.1 B.ACQ.1 Select COTS products based on defined criteriaPhase: engineering.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: in case of commercial off-the-shelf acquisition, selection criteria shall be established thatinclude functionality, RAMS, obsolescence management and other relevant criteria.

Guidance note:

This standard focuses on the technical aspects of the selection process, not the financial aspects, which are out of scope. TheCOTS products in question may be used as a stand-alone product or as a component in the supplier’s system. This activity shouldbe coordinated with the results of activity B.DES.4. This requirement will only be applicable for the system integrator if COTS isacquired directly by the SI.



COTS product selection procedure: obsolescencemanagement.

COTS product selection matrix: rationale for selection,selection criteria, evaluations and selection.

None

App

endi

x B


DNV GL AS

1.3.2 B.ACQ.2 Establish contract with sub-suppliersPhase: engineering.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: contracts with sub-suppliers shall be established, and shall contain at least the followingitems:

— products, functions and components to be included in the delivery— relevant ISDS standard requirements— criteria for acceptance of the acquired product— proprietary, usage, ownership, warranty and licensing rights— maintenance and support in the future.

If the development, updating or configuration of software dependent systems is sub-contracted, relevant parts of theISDS standard apply to the sub-supplier and shall be included in the contract.

Guidance note:

This standard focuses on the technical aspects of the contract(s), not the financial aspects, which are out of scope. If a sub-supplier deliver non-COTS system(s) with custom software, the contractual agreements should clarify which parts of the ISDSstandard the sub-contractor should adhere to and be assessed towards, and which parts of the standard the supplier will take careof.



Supplier agreement: product or component specifications,functional specifications, technical acceptance criteria,ownership transfer conditions, delivery strategy,provisions for review of intermediate deliveries.

None

App

endi

x B


DNV GL AS

1.3.3 B.CM.1 Establish and implement information and document managementPhase: engineering.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: the plans, policies, roles, responsibilities, tools and mechanisms for managing informationand documents shall be defined and implemented. The project specific configuration items and the mechanisms forbaselining these shall be documented.

There shall be a plan focusing especially on configuration and change management of information elements,including, but not limited to change control, impact analysis and approval of changes.

The plan shall as a minimum include:

— mechanisms for submitting and receiving information (documents) between different organisations— mechanisms for defining baselines of information (documents)— mechanisms for handling of documents and information while they are work in progress— mechanisms for review and approval of drawings and other documents.

These mechanisms shall apply until a CCB for commissioning is established in the acceptance phase.

Guidance note:

The information and documentation management plan may be a part of the project plan for the organisation, see activity B.PM.1 in[1.3.11]. Separate configuration management mechanisms may be established for the vessel and individual systems.

A typical way to manage changes to baselines is to let one decision-body (normally called a CCB) make an impact analysis ofproposed changes and then make a yes or no decision and communicate the approved changes to be performed.

On vessel level, the focus for this activity should be on documents or other information-elements like database records included inthe baselines.

The version control rules should also encompass documents/information that has not been included in a formal baseline. Tools forversion control are often utilised.



Configuration management plan: definition of a CCBprocess or similar, identification of required baselines,required baseline content, and change request forms.

Change requests and change decisions.

Version history information of baselines.

Defined rules and mechanisms for version control.

Effective implementation of version control mechanisms.

None

App

endi

x B


DNV GL AS

1.3.4 B.CM.2 Perform review of system requirementsPhase: engineering.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: the supplier shall call for a requirements review. The system integrator shall be included inthe review meeting.

The requirements from the system integrator shall be reviewed for completeness, consistency and correctness.

The reviewed requirements, including relevant actions from the review meeting will serve as the baseline ofrequirements. Once the baseline is established, the development may progress to the detailed design of the system.

Guidance note:

Input to the review meetings include the system specifications, relevant flag, shelf and/or class rules, other governing standards,base-product specifications (if the system is based on a base-product design).

The involvement of the system integrator may be done by either including the system integrator in a review meeting or byperforming an internal meeting where specific items are addressed with the system integrator retroactively. The following systemrequirements should be addressed during the review:

— functionality

— reliability

— availability

— maintainability

— safety

— security

— usability

— efficiency

— portability

— integrability

— performance.

The baseline is a consistent set of information elements that have been formally reviewed and agreed upon, that thereafter serveas the basis for further development, and that may be changed only through formal change control procedures.

The term base products is here used to describe any kind of existing product, component, software library, software template orsimilar on which the supplier bases the development (or automatic generation) of the customer specific product.

Changes to these baselines require review and approval by appropriate stakeholders, see X.CM.1 in [1.7.3].


Assessment criteria Documents required for review

MoM/report from review meeting.

Baseline repositories.

Identification of baselines.

Approved and controlled documents (baselines) for:system requirements and base products.

Review report (FI) are reviewed in B.IV.2 at CL2.

Baselines (FI) are used in C.IV.1 at CL2.

App

endi

x B


DNV GL AS

1.3.5 B.CM.3 Establish baselines of designPhase: engineering.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: baselines of the vessel design, system designs and interface specifications shall beestablished before the information is used for further detailing of design, implementation and verification.

The design information shall be reviewed to verify the completeness of the design with respect to requirements (e.g.functions, interfaces, performance, and RAMS properties), design rules, certainties (e.g. technical risks, and designmargins, design assumptions) and the use of base-products in the design.

All inter-system interface specifications and intra-system interfaces shall be reviewed by relevant stakeholders.

Guidance note:

The baseline is a consistent set of information elements that have been formally reviewed and agreed upon, that thereafter serveas the basis for further development, and that may be changed only through formal change control procedures.

ISDS require that the baseline for requirements is done before starting design, and baseline for design, including interfaces, isdone before start of implementation. Changes to these baselines require review and approval by appropriate stakeholders, seeX.CM.1 in [1.7.3].

The term base products is here used to describe any kind of existing product, component, software library, software template orsimilar on which the supplier bases the development (or automatic generation) of the custom specific product.

Baselines for design and interfaces are normally defined at different stages in the project. The deadlines for these activities shouldbe milestones in the project plan defined in B.PM.1 and updated when necessary as given by X.PM.1.

In order to secure that all relevant aspects are covered, this activity normally encompasses one or more review meetings. Bothintra- and inter-disciplinary reviews are normally performed.

All relevant aspects of the design baseline should be subject for review, including, but not limited to: Architecture, block diagrams,functional descriptions, parameters, schematics, interface documentation

Traceability between different requirements levels should be used to facilitate this review, see A.REQ.2, B.REQ.1 and X.REQ.1.Typical stakeholders for inter-system interfaces are all suppliers relying on the interface information. Typical stakeholders for intra-system interfaces are different departments and disciplines at the supplier, relying on the interface information.

At end of the engineering phase, some interfaces may not have been defined or coordinated between the relevant stakeholders(see B.INT.1). There should be a clear plan on how the remaining interfaces will be reviewed.



Baseline repositories.

Identification of baselines.

Approved and controlled documents (baselines) for: unitdesign, system design and interface specifications.

Supplier (SU) baselines (FI) are used in C.IV.1 at CL2

App

endi

x B


DNV GL AS

1.3.6 B.DES.1 Design the systemPhase: engineering.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: the design for the system shall be developed and documented. The main responsibility fora (sub-)system design is either the system integrator or the supplier, this shall be clarified at the beginning of theproject.

The design shall identify the major subsystems and components and how they interact.

All external interfaces shall be documented in detail and coordinated with other relevant systems.

Appropriate design guidelines and methods shall be used to ensure consistent design of the system.

The functional description and system topology shall be sent to the relevant roles for review.

Guidance note:

Typically for systems where the supplier delivers only the control system, the system integrator needs to take responsibility for thesystem design, e.g. ballast systems, ESD systems etc. For complete system suppliers the system design is typically the suppliersresponsibility e.g. BOP systems, thruster systems etc.

The definition of external interfaces is related to the coordination of the inter-system interfaces, see activity B.INT.1 [1.3.10].Some of the interface definition may be done during the design of software components, see B.DES.2 in [1.7.10]. The systemdesign should normally not be finalized until the vessel design has been refined in activity B.DES.3.

In this context the term guidelines also includes methods, techniques, tools etc. Some guidelines may be mandatory to followand are referred to as rules. The definition and identification of applicable guidelines may be performed as a part of the activitiesX.PQA.1 and X.PQA.1.

Established and well-known design guidelines, techniques and measures are commonly available, for example, IEEE Std 12207,IEEE Std 1016, IEC 61499 part 1 or ISO/IEC 61508 part 7.



Design for system (hardware & software): functionaldescription, user interface descriptions, block/topologydiagrams with software components, external interfacedescriptions and internal interface descriptions.

System design guidelines: including RAMS relatedaspects.

Functional description (FI) used in C.IV.1 at CL2

App

endi

x B


DNV GL AS

1.3.7 B.DES.2 Design the software componentsPhase: engineering.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: the design shall show all major software components in the system, which hardwarecomponents they are going to run on, and indicate which software sub-systems are new, modified, configured or re-used as is. Third party software sub-systems shall be explicitly identified.

Design for each software component shall be documented. The design shall as a minimum:

— identify what hardware runs which software components— identify the major parts of the software components— describe functions and behaviour of the software components— describe the internal structure of the software components— describe the internal interfaces between components— list known limitations of the system— show which software components are new, modified or re-used as is— explicitly identify third party software components.

Appropriate design guidelines and methods shall be used to ensure consistent design of each software component.

Guidance note:

This activity aims at detailing the software design which is a sub-set of the system design defined in B.DES.1 in [1.3.6].

Third party software is either custom made for the system in question or (configured) COTS. This is normally handled by theactivities in the acquisition (ACQ) process area in this standard.

The software component design normally contains information about the structure and behaviour of software components, (e.g.state diagrams, sequence diagrams, class diagrams, etc.) along with a description of the functionality of the component andinternal interfaces.

The design may be documented using various recognised methods and means from models and databases to diagrams anddocuments. It should be possible to identify relevant source code modules/files from the design description.

The design should not be confused with the actual software.

In this context the term guidelines also includes methods, techniques, tools etc. Some guidelines may be mandatory to follow andare referred to as rules.

Established and well-known design guidelines, techniques and measures are commonly available, for example, IEEE Std 12207,IEEE Std 1016, IEC 61499 part 1 or ISO/IEC 61508 part 7.



Component design for each software component, insufficient detail so as to proceed to the making of thesoftware: structural description, functional description,behaviour description, parameters (default, intervals, as-designed), interfaces description, allocation of software tohardware and assumptions and known limitations of thedesign.

Software design guidelines: including RAMS relatedaspects.

None

App

endi

x B


DNV GL AS

1.3.8 B.DES.3 Analyse and refine the vessel designPhase: engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: the system designs shall be analysed in conjunction with the vessel architecture to identifycritical behavioural interactions and complex data flows. Common solutions shall be established, standard alarms andsignals defined, common constraints identified, and rules for handling of shared data resources defined. The vesselarchitecture documentation shall be updated to reflect the results of the analysis.

Guidance note:

This activity should usually not be completed until the suppliers and systems have been selected and awarded contracts becauseboth documentation and participation from the suppliers are normally needed in order to establish the common solutions.

The system design from the suppliers is created in activity B.DES.1. The vessel architecture/design is created in activity A.DES.1.

The vessel architecture may contain a number of views: the physical layout describes the way components and networks arephysically distributed around the facility, including the way they are interconnected (network and main central processing unit(CPU)).

The logical view of the function describes the function in terms of functionality towards its users. The scenarios or dynamic viewdescribes the primary interaction between components when a function is executed, and how the users interact with the functions.

The process view of the function describes the processes and components that compose the function, as well as the responsibilityof individual components and processes, their interaction, triggers and cycle times.

The physical view of the function (or allocation) describes the mapping of the main processes/software components onto thehardware components.

The development view of the function describes the breakdown of the function into sub-functions. Relevant design rules utilised inA.DES.1 should be used.



Updated vessel design documentation: vessel designspecifications, systems/network topology with softwarecomponents, interface specifications, and functionaldescriptions

None

App

endi

x B


DNV GL AS

1.3.9 B.DES.4 Define obsolescence strategyPhase: engineering.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: the strategy for the future management of obsolescence for the systems shall be defined.

The supplier shall send obsolescence statements for each system to the owner.

Guidance note:

The statements to the owners may be sent via the system integrator. The obsolescence statement from the supplier to the ownershould contain at least:

— a list of computer-related hardware components

— a list of the software components in the system, including third party components

— planned obsolescence dates for the major components

— actions to address any obsolescence issues or risks.



Obsolescence management plan: Spare parts list(hardware & software), stock, alternate spare partslist, management of intellectual property. Obsolescencecriteria for software.

Manufacturer preferred equipment list.

None

App

endi

x B


DNV GL AS

1.3.10 B.INT.1 Coordinate inter-system interfacesPhase: engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: an interface matrix or a similar mechanism shall be established to identify inter-systeminterfaces and assign the responsibility for defining and testing them. The status of the interface definition andverification shall be tracked.

Changes to the inter-system interfaces shall be controlled and coordinated.

Guidance note:

This activity is related to the specification of systems and their interaction (A.DES.1 and B.DES.3). Controlling the changes to theinter-system interfaces may be performed by including the interface matrix and the interface definitions in baselines, see B.CM.3 in[1.3.5].

Interface specifications are typically documented by the suppliers as a part of the design of the systems (B.DES.1) and may beincluded in design documents or documented separately. Multiple interface specification documents may be prepared or theymay be packaged into a common document. Typically, the system integrator will manage the baseline of inter-system interfacespecifications.

At end of the engineering phase, some interfaces may not have been completely defined or coordinated between the relevantstakeholders. The list of these interfaces should be clearly identified and communicated (e.g. testing according to C.VV.2 to beperformed at a later stage). There should also be a clear plan on whom, when and how the remaining interfaces will be identified,coordinated and tested.



Interface overview/matrix information with assignedresponsibilities.

Agreed inter-system interface specifications containing:protocol selected, definition of commands, messages,data and alarms to be communicated and specificationsof message formats.

Interface definition and verification status.

None

App

endi

x B


DNV GL AS

1.3.11 B.PM.1 Establish a project planPhase: engineering.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: a project plan shall be established and maintained, in coordination with other stakeholders,for engineering and all succeeding phases.

The plan shall include schedules and resource allocation of software related activities, including documentdeliverables, and take into account the activities for the different phases of the project.

Relevant parts of the project plan from the supplier shall be distributed to the system integrator. The systemintegrator shall ensure the coordination with the master plan.

Guidance note:

In practice, the plan may be detailed for the current phase and roughly outlined for ulterior phases. When reaching the ulteriorphases, the plan may then be detailed. As the acceptance phase is often a critical period for the project, it is recommended thatthis phase be planned in detail to reduce project risks.

The plan for the phases should be established and maintained in coordination with other stakeholders, based on the master planfor the project.

Master document list(s) or equivalent should be established at an early stage to ensure that all required information/documents(including all elements required by this standard) are planned to be transmitted between the organizations. The schedule in theproject plan should give the planned dates for when the main documents will be transferred to the relevant stakeholders. This is tohave a better overview of when to expect necessary inputs to important activities in the different organisations, and to improve thecommitment of the organisations to distribute documents as expected in the project.



Schedule.

Project plan: Work breakdown structure (WBS),technical attributes used for estimating, effort andcosts estimates, deliverables and milestones, RAMSplan, master document list.

Resource allocation.

None

App

endi

x B


DNV GL AS

1.3.12 B.RAMS.1 Develop the reliability, availability, maintainability, safety plan for the systemPhase: engineering.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: RAMS activities shall be planned, including methods and tools to be used.

The RAMS plan for the system shall be derived from the RAMS plan for the vessel.

Guidance note:

This activity builds on the output from activity A.RAMS.1. The methods, tools and procedures used in all RAMS-related activitiesshould be defined, documented and put under configuration control. The RAMS plan should cover all relevant RAMS activitiesincluded in this standard. This activity may be coordinated with the activities B.PM.1 and X.PQA.1 and the RAMS plan may be aseparate document, a part of the project plan, or in a quality assurance plan. Safety may be dealt with separately, for example in afunctional safety management plan



Plan showing objectives, methods, tools, and proceduresto be used, consistent with the RAMS plan for the vessel.Schedule of RAMS activities. RAM data to be collected(CL3)



App

endi

x B


DNV GL AS

1.3.13 B.RAMS.2 Identify system dependencies and assess reliability, availability, maintainability,safety risks between systemsPhase: engineering.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: a review to identify system dependencies shall be performed.

The identified systems dependencies shall be assessed to identify RAMS risks between the systems.

Mitigation actions shall be identified and tracked to closure for the relevant RAMS risks.

Guidance note:

The RAMS risks are those risks related to the vessel in operation. Recognized methods for risk identification should be used, suchas: fault three analysis, HAZID, HAZOP, FME(C)A, performance analysis, reliability analysis, availability analysis, maintainabilityanalysis etc.

The identification of RAMS risk may be combined with requirements from other class activities, like FMEA for DP, see DNVGL-RU-SHIP Pt.6 Ch.3.

It is highly recommended to include relevant project stakeholders when performing the RAMS analysis. Possible hazards and risksrelated to parameterisation and configuration should be identified.

Typical risk mitigation actions include: changes to requirements or design, changed or added verification activities, changes tooperational procedures, changes to documentation etc.



Report/minutes of meeting from review meeting Report reviewed in B.IV.4 at CL3

App

endi

x B


DNV GL AS

1.3.14 B.RAMS.3 Identify software-related reliability, availability, maintainability, safety risks,priorities and mitigation actionsPhase: engineering.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: software related RAMS hazards and risks shall be identified and prioritised. Establishedmethods shall be used for the risk identification. Risks identified shall be shared between relevant roles in theproject.

Identified software-related hazards and risks shall be analysed to identify mitigation actions. Relevant mitigationactions shall be tracked to closure and shared between relevant roles in the project.

Guidance note:

The RAMS risks are those risks related to the vessel (and systems) in operation. Recognized methods for risk identification shouldbe used, such as: fault three analysis, HAZID, HAZOP, FME(C)A, performance analysis, reliability analysis, availability analysis,maintainability analysis etc.

It is highly recommended to include relevant project stakeholders when performing the RAMS analysis. Possible hazards and risksrelated to parameterisation and configuration should be identified.

Mitigation actions may be identified on all levels: the vessel, system, subsystem, hardware components, and software components.Typical risk mitigation actions include: changes to requirements or design, changed or added verification activities, changes tooperational procedures, changes to documentation etc. Examples of software failure modes include, but are not limited to:

— no output or control action not provided when needed

— wrong output or wrong control action provided

— spurious output or control action provided when not needed

— late output or control action not provided on-time

— output or control action stops too soon.



RAMS hazard and risk list showing consideration of software risks.

RAMS hazard and risk mitigation list showing mitigation actions forsoftware risks.

Defined risk identification and analysis methods.

Relevant risks and mitigation actions are communicated to otherroles.

RAMS risk register (FI) and RAMS risk analysisdocumentation (FI):

— reviewed in B.IV.4 at CL3— used in C.IV.2 at CL3

App

endi

x B


DNV GL AS

1.3.15 B.REQ.1 Identify and refine requirements for the systemPhase: engineering.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: the supplier shall provide a breakdown of the systems and identify required modification,customisation or parameterisation of existing systems. New capabilities and components shall be explicitly identified.

For each software component of the system, requirements shall be refined and allocated into componentrequirements.

Guidance note:

The requirement focuses on the identification of software needed to be developed or modified specifically to the project. Specialattention should be made to requirements that leads to new development or modification.

It should be possible to distinguish which requirements are satisfied by the base product as is, which requirements may besatisfied by a simple customisation and which requirements actually need specific developments. These requirements should serveas a basis for establishing traceability of the requirements, see X.REQ.1 in [1.7.10].



System requirements: system breakdown, alternativesand options, description of customisation orparameterisation of products (including software) andrequirements compliance matrix.

Refined component requirements and specification.

Specification (FI) used in B.IV.2 at CL2

App

endi

x B


DNV GL AS

1.3.16 B.VV.1 Define verification, validation and integration strategyPhase: engineering.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: the verification, validation and integration strategies shall be defined, documented andrelevant parts shall be shared with the other project stakeholders.

The strategy shall include a list of verification and validation activities, the test environment, the purpose of eachactivity, the method to be employed in the activity, the exit criteria (e.g. quality targets) to be fulfilled, and theorganisational responsibility for conducting and recording the activity.

On the system level, the verification and validation strategies shall distinguish between base product software,configured software, modified software, newly developed software, and defect corrections.

The verification strategy shall define the means to ensure the vessel/system meets its requirements and that thesystem documentation match the system's behavior and capabilities.

The plan for integration of the different systems into the vessel shall be defined and documented. The criteria,procedures, and the environment for the integration shall be described. The integration plan shall also describe thetype of tests that will be performed to ensure that systems and components interact correctly.

Guidance note:

The purpose of the verification and validation strategies is to ensure that reviews, testing and evaluation is performed efficientlyand effectively through a combination of complementary methods. The integration strategy ensures that necessary planning andpreparation will be done to assemble the systems the correct way and in the correct order, with the proper tools and environmentfor integration testing, e.g. test stubs or simulators.

The verification and validation strategy should provide a description of each test stage and the environment in which it will be run.

Relevant stakeholders, e.g. owner, system integrator and supplier should review and approve the verification and validationstrategy for the elements in their scope. The supplier's strategy should take into account the software component test, includingrequirements to code coverage, and verification of relevant support documentation as well as all other relevant VV activitiesdescribed in this standard (including reviews performed in the engineering phase).

The system integrator should define the strategy at the vessel level, while the suppliers should define their strategy at the systemand component levels. Both should ensure their respective strategies are consistent with each other, and that relevant verificationand validation activities and requirements described in this standard are covered.

The validation strategy should be consistent, complementary and as little redundant as possible with the verification strategy.

Care should be taken to identify the purpose of each test activity performed (for example, test for verification against arequirement, or test for validation against a user scenario).

To test the complete function the following testing method may be applied:

— black-box testing

— boundary testing.

Black-box testing is normally guided:

a) by the structure of the requirements, use case, operational scenarios or results from simulations

b) by the structure of the input data

c) by the risks

d) randomly.

For more information on black-box testing and boundary testing (or analysis), see IEC 61508-7. Detailed procedures and tools fortesting may be established during the construction phase, see C.VV.2 in [1.4.9] and C.VV.4 in [1.4.11]). The information listedunder the Assessment criteria may be a part of a project plan, a project quality plan or similar.


App

endi

x B


DNV GL AS


Verification strategy: which part to verify: vessel, system,sub-system, component, module, design documents.

Method specification documents, etc.: which methodsto use for this verification: testing, inspection, codeanalysis, simulation, prototyping, peer review techniques,acceptance criteria and targets, which test types to use:functional, performance, regression, user interface,negative, what environment to use for verificationand identification of the test stages (e.g. sea trials,integration tests, commissioning, FAT, internal testing,component testing) to be used for the verification and theschedule for those tests.

Validation strategy: products to be validated,validation criteria, operational scenarios, methods andenvironments.

Plan for integration of systems into the vessel:The responsibilities of the different organizations,dependencies among systems, sequence for integration,integration environment, tests and integration readinesscriteria.

Plan for integration of sub-systems and components intosystems: dependencies among systems, sub-systemsand components, sequence for integration, integrationenvironment, tests and integration readiness criteria.

Verification and validation strategy (FI):

— reviewed in B.IV.2, at CL2— used in C.IV.1 at CL2— used in D.IV.1 at CL2

1.3.17 B.VV.2 Qualify reused softwarePhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: standard software and non-standard legacy software shall be qualified for use in the project.The qualification shall be performed by either a) applying the ISDS standard, b) assessing the quality through duediligence of the software or c) by demonstrating that the software is proven-in-use.

Modified reused software (modified source code) shall be treated as new software.

App

endi

x B


DNV GL AS

Guidance note:

For all the methods described below, the following is required:

1) Identified baseline of applicable documents describing the qualified and the reused software.

2) Identified software versions and delta between the qualified and project software.

3) All changes made to the assessed software after qualification as described in a), b) or c), are expected to be done accordingto applicable requirements described in this document.

Qualification of software should be done using the following methods:

a) Process compliance: the process for developing the software is compliant to this ISDS standard. This means that the base-product has been successfully assessed towards the DNVGL-OS-D203 standard released in 2012 and later.

b) Due diligence: for the due diligence, the supplier should assess the reused software against a defined set of acceptance criteriaaccording to the list below, as well as additional acceptance criteria defined by the supplier. A gap analysis of the softwareand applicable documentation should be performed towards the defined criteria, and an action plan should be created forthe revealed gaps. Upon completion of actions in the action plan, a qualification report should be written. This report will beconsidered part of the assessment criteria for the ISDS assessment.

1) Description of the software used in vessels/vessels in operation.

2) Description of the software intended for reuse.

3) Detailed specification of interfaces of the qualified software.

4) Identified third party software components (both COTS and custom made), existing obsolescence status of COTShardware and software components and statement on support from the supplier of the software in question.

5) A report from a determined based sample-review of source code stating that the software is suitable for reuse.

6) Documented evidence that the software has been subject to internal test, FAT, HIL test or similar system test coveringfunctional aspects involving software.

7) Evidence that the source code has been developed based on and reviewed against coding rules and evidence ofcomponent testing performed covering all inputs and outputs of the SW component.

c) Proven in use: in order to demonstrate that the software is proven-in-use, arguments based on analysis of experiences fromprevious systems, where the component has been used, should be provided. The analysis should compare how the componenthas been used, e.g. how it has been configured, with how it will be used in the current system. The supplier should perform agap analysis on the software according to criteria defined below. Gaps should be documented with relevant actions for closure,and a software qualification report should be written. The proven-in-use process is intended to be applied to standard softwareonly. This is software which has been delivered in the same form multiple times. No changes are planned to meet specific projectrequirements, although changes may be made to maintain the software across all installations.The following criteria need to be met to satisfy proven-in-use software qualification:

1) Existing documentation describing the software suitable for reuse, including general purpose, scope, functionality, SW-HW mapping, structure of the software and its interfaces.

2) Identified third party software components (both COTS and custom made), existing obsolescence status of COTShardware and software components and statement on support from the supplier of the software in question.

3) Evidence of configuration/change management applied on the software during its previous use with complete andupdated records.

4) Analysis performed with respect to the intended use determining that no modifications are needed for the currentproject.

5) Available and analysed field data with sufficient quality and coverage on problems and failures observed for thesoftware including problem report history.

6) Substantial history of use, e.g. deployed in the current form ten or more times previously over a time span of at leasttwo years.



Software qualification report: reused software componentlist, qualification method for each reused softwarecomponent and qualification data

None

App

endi

x B


DNV GL AS

1.4 Construction phase

1.4.1 C.ACQ.1 Accept deliverablesPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: deliverables from the sub-suppliers shall be submitted to formal acceptance, usingpredefined criteria and procedures. Acceptance tests shall at least verify that the delivered product is compliant to itsspecification.

In case of COTS acquisition, the acquired products shall be qualified for use in the ISDS scoped system to bedelivered.

Guidance note:

The principles for the qualification mentioned in this activity are outlined in the guidance note of activity B.VV.2 Qualify reusedsoftware.

If software development or software configuration is performed by a sub-supplier, the sub-supplier is going to be assessed towardsrelevant parts of this ISDS standard.



Component acceptance data: acceptance criteria,component acceptance (FAT, site acceptance tests (SAT))test procedures, component acceptance test records,component acceptance issue and problems list andcomponent acceptance test coverage measurements(requirements, structural)

None

1.4.2 C.ACQ.2 Ensure transition and integration of the delivered productPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: documentation, examples, or support necessary to ensure the integrateability of thedelivered components and systems shall be planned and provided.

Guidance note:

This activity is an extension of C.ACQ.1 and is addressing the delivery from the supplier to the system integrator.

The aim of this activity is to help the system integrator by avoiding extra integration work originating from the sub-supplierscomponents.



Supplier agreement on: list of deliverables, review andapproval plans and support and maintenance agreement.

Product documentation.

Operation manual.

Configuration information.

None

App

endi

x B


DNV GL AS

1.4.3 C.IMP.1 Develop and configure the software components from designPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: software components shall be developed according to their design. Configuration andparameterisation of software shall be considered part of the development.

Appropriate guidelines and methods shall be used to enhance RAMS of system and components.

Guidance note:

The software components should be developed from the design (and not the other way around). Software development includescreation of new software components, modification of existing software components, or parameterisation and configuration of new,modified and existing software components.

Guidelines typically address naming conventions, coding style, patterns to be used or avoided etc. Some guidelines may bemandatory to follow and are referred to as rules. IEC 61508-7 references a set of guidelines and methods.

Verification that the guidelines and methods have been followed is typically done in activity C.VV.1 Verify source code andconfiguration.



Commented software source code.

Parameters and configuration files.

I/O list.

Development environment configuration.

Software guidelines/standards/rules/checklists/automated checks.

None

App

endi

x B


DNV GL AS

1.4.4 C.IMP.2 Develop support documentationPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: support documentation for the system and its components shall be developed. Supportdocumentation shall include user manuals, maintenance instructions, relevant installation manuals, training materialand data sheets.

Relevant contents of the support documentation shall be verified through testing with the customer over the courseof the project.

Maintenance plans shall include configuration items, rules for maintenance, backup and restore procedures, expectedmaintenance activities, expected software updates, migration and retirement activities.

Guidance note:

Verification of the support documentation should be described in the verification and validation strategy, see B.VV.1 in [1.3.16].

Maintenance manuals for software dependent systems typically include functions like restarts, backups and replacement ofequipment/parts during operation.



System and software support documentation: datasheets, user manuals, administration manuals, operatingand maintenance procedures, training material and FAQs,known defects and troubleshooting guides.

Maintenance management plan including configurationitems, rules for maintenance, backup and restoreprocedures, expected maintenance activities, expectedsoftware updates, migration and retirement activities.

None

App

endi

x B


DNV GL AS

1.4.5 C.IMP.3 Perform software component testingPhase: construction.Unit level responsible: none.System level responsible: supplier.

Requirement definition: software components shall be tested before verification or acceptance of the completesystem, according to the verification strategy.

The code coverage of the testing and the results shall be documented and reported.

Guidance note:

This particularly applies to testing of new, modified, configured or impacted software.

Custom made function blocks should be tested while standard libraries and standard function blocks are usually already tested.This testing is usually performed by the software development team and is often also called software unit test.

The tests are white box, meaning that knowledge about the software’s internal structure is utilized to ensure that all relevant partsof the code are covered by the tests.

White-box testing is usually performed by the software development team, with a high degree of automated testing involved. Atest log is usually sufficient to record test results. The requirement to code coverage should be detailed in the verification strategy,see B.VV.1 in [1.3.16].



Software test log: list of defects, date of test, tester, testscope and pass or fail.

Software defect list.

None

1.4.6 C.PQA.1 Establish plans and procedures for problem resolution and maintenance activitiesPhase: construction.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: establish procedures for reporting, receiving, recording, resolving, and tracking problems andmodification requests. Maintenance plans including configuration items, rules for maintenance, backup and restoreprocedures, expected maintenance activities, expected software updates, migration and retirement activities shallalso be established.

Guidance note:

Care should be taken to describe procedures for resolving joint problems, at the interface of two or more systems within ISDSscope. Starting at FAT there should be a joint process for resolving problems. The process for problem resolution may be differentin nature for the different project phases (construction, acceptance and operations).

The procedures required here should be coordinated with the requirements in D.CM.1 Manage software changes after FAT. Theoutput from this activity should also form the input for maintenance procedures in E.RAMS.1.



Agreed problem resolution procedures: proceduresfor receiving, recording, resolving, tracking problems(punches) and modification request

None

App

endi

x B


DNV GL AS

1.4.7 C.RAMS.1 Demonstrate achievement of system reliability, availability, maintainability, safetyrequirementsPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: RAMS arguments and evidence shall be assembled to demonstrate achievement of RAMSrequirements and objectives on the system level.

The results shall be sent to the system integrator.

Guidance note:

The RAMS requirements and objectives for the vessel are detailed in activity

. The software-related RAMS risks and mitigation actions for the system are defined in B.RAMS.3.

The arguments and evidence may include: safety analysis, FME(C)A, test cases, test results, inspections, computations andsimulations, certifications, qualification of legacy systems, etc. The RAM data is typically statistical data collected and analysedusing models such as weibull, SINTEF PDS, etc.

Software systems and software components should be specifically checked against RAM requirements and objectives using datacollected from e.g. operations and verification activities.

The output from this activity will be used for input to D.RAMS.1.



RAMS compliance analysis information RAMS compliance report (FI) reviewed in C.IV.2 at CL3

App

endi

x B


DNV GL AS

1.4.8 C.VV.1 Verify source code and configurationPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: peer reviews of new and modified software and project configuration/parameterisation shallbe performed. The consistency of the software with its design documents shall be checked.

Software source code verification shall be performed against a predefined set of rules.

Guidance note:

In this context the term software is used to represent all types of source code, graphical notations and models that is readable forhumans and used to generate machine-readable programs that can be executed by a computer.

Peer reviews are complementary means to testing to detect defects as early as possible in the development cycle.

The code rule set depend on the type of programming language (e.g. a strongly typed language) and the application of e.g. PLCsor standard software, and may be combined with the rules mentioned in activity C.IMP.1.

The source code verification against a predefined set of rules may be performed by peer reviews, static analysis, or complementaryspecific analyses such as schedulability analysis. Semi-automated or manual methods may be used. See ISO 61508 for otherrecommended means. See ISO 9126 for internal quality characteristics.



Peer review methodology description.

Peer review schedule.

Peer review records.

Peer review check lists.

None

App

endi

x B


DNV GL AS

1.4.9 C.VV.2 Perform internal testingPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: developed systems and components shall be verified before decision to release for FAT. Thesystem and component verification shall be analysed and compared with expected quality attribute targets, e.g.regarding RAMS. Internal tests shall include:

— interface testing covering I/O for both bus-interfaces and hardwired interfaces— tests of relevant intra-system interface dynamics by defined scenarios— tests of relevant inter-system interface dynamics by defined scenarios— normal functionality— relevant RAMS risks— error situations and corresponding alarms— degraded functionality— security related testing— performance testing— stress testing— safety related testing— integration between hardware and software.

All requirements mapped to the system shall be tested. Detailed procedures for testing shall be completed (testcases) and documented. The testing steps shall be identified. The expected results for each test case shall bespecified. Functions or properties that cannot be tested before FAT or even at FAT shall be clearly identified.

Guidance note:

The ambition levels for these tests should be clearly described in the verification strategy (see B.VV.1 in [1.3.16]), and basedon the minimum assessment criteria described here. Details regarding the mapping of requirements to tests are covered in theactivity X.REQ.1. The internal testing are normally performed after the white-box test of software components, see C.IMP.3 in[1.4.5], and are sometimes referred to as an internal acceptance test. The limitations of the internal test environment and the useof tools like e.g. test-drivers, simulators and emulators should be clearly described. Testing of RAMS risk should be based on theanalysis performed in B.RAMS.3.



Test procedures.

Test reports.

Test report (FI) used in C.IV.1 at CL2

App

endi

x B


DNV GL AS

1.4.10 C.VV.3 Analyse verification results with respect to targetsPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: the results of all verification activities performed by the supplier shall be evaluated andcompared with the verification targets as defined in the verification strategy.

Defects (punches) shall be tracked and analysed. Criteria for classification of defects shall be established. Defectsshall be analysed for trends to identify defect-prone software.

The quality status of the system under development shall be measured. Relevant findings from the analysis shall bedistributed to relevant stakeholders.

This results from this analysis shall be used as input to determine whether the system is ready for FAT.

Guidance note:

The purpose of this activity is to check if the system is fit for purpose and to identify actions to improve defect prone software in afast and effective manner. The targets are defined in the verification and validation stratgey, see B.VV.1 in [1.3.16].

Relevant findings for other stakeholders may include, but is not limited to, which parts of the system that is not completed,requirements not tested, additional testing needed during commissioning, etc.



Verification result evaluation: result analyses, punch lists,action lists, defect correction and focus on defect pronesoftware

Verification analysis report (FI) reviewed in C.IV.1 at CL2

App

endi

x B


DNV GL AS

1.4.11 C.VV.4 Perform factory acceptance testsPhase: construction.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: FAT shall be performed to ensure the system is compliant to its requirements and acceptablefor the owner. The FAT shall include:

— tests to ensure the system is compliant with selected operational requirements, including normal modes, errorsituations, and degraded modes.

— tests covering the hardware/software integration.— tests of relevant inter-system interface dynamics by defined scenarios.— tests of relevant intra-system interface dynamics by defined scenarios.

Functions or properties that cannot be tested in the FAT shall be clearly identified. The FAT procedures shall beapproved by the system integrator before the tests may be executed.

Guidance note:

The purpose of the FAT is for the system integrator and owner to accept the system. Full coverage of requirements is not requiredas long as the owner and the system integrator are satisfied. The demonstration of previously run tests is typically performed byproviding test reports from internal tests.

The limitations of the FAT environment and the use of tools like e.g. test-drivers, simulators and emulators should be clearlydescribed.

The physical machine FAT and the approval of the associated control system software may be split into separate events. In thiscase the acceptance of the control system software is normally referred to as software FAT, and the requirements from this activitywill apply to that event.

This FAT should be considered the activity where the system integrator accepts the system from the supplier, this may also be thesame activity where the system is subject to manufacturing survey from class (as described in DNVGL-OS-D202 Ch.3 Sec.1).



System FAT procedure: coverage of requirements,functionality, performance, RAMS (when applicable),integration testing, hardware/software integration,interfaces, failure modes and degraded modes.

System FAT report: consistent with procedure, deviationsidentified and coverage measured.

System FAT procedure (FI) and System FAT report(FI):

— used in C.IV.1 at CL2.

App

endi

x B


DNV GL AS

1.5 Acceptance phase

1.5.1 D.CM.1 Manage software changes after FATPhase: acceptance.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: major changes in a system or sub-system/component shall be submitted to a CCB whichanalyses impact and makes a decision regarding the change.

The roles, responsibilities and mechanisms for the CCB shall be defined. These shall ensure that the deployedconfiguration of the systems that have passed FAT cannot change outside of a strict change control procedure.

Guidance note:

The system integrator should coordinate changes across all systems. This activity should be related to the activity C.PQA.1Establish procedures for problem resolution and maintenance activities in the construction and acceptance phases, and also toX.REQ.1 Maintain requirements traceability information. The CCB typically consists of representatives from all relevant projectstakeholders.

The system integrator should consult with the suppliers about the design of the configuration management system. Theconfiguration management system may be described in the configuration management plan.

The ambition level for the joint problem resolution and change management processes should be defined. This includes what typesof changes or parameter tuning must be handled by CCB with system integrator and affected suppliers, and which may be doneoutside of system integrator control. The definition of minor and major changes should be defined and described, and the way ofhandling them should be agreed upon. The mechanisms, tools, documents, roles and responsibilities should also be described.



Defined software configuration management: definitionof CCB, change request forms, description of changeprocess for software, impact analysis, Identificationof items to be controlled, configuration managementtool, including, issue, change, version and configurationtracking tool and prevents unauthorised changes.

Modification records justifying changes, e.g. configurationrecords, version histories, release notes, change orders.

Configuration management procedure (FI) used in D.IV.2

App

endi

x B


DNV GL AS

1.5.2 D.CM.2 Transfer responsibility for system configuration management to the ownerPhase: acceptance.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: after acceptance, the owner shall take the responsibility for the configuration management ofthe systems within ISDS scope. The system integrator shall deliver all necessary software, documentation and datato the owner.

The final delivery shall include documentation of the configuration of the systems in ISDS scope. A release note shallbe produced, describing all the items and their versions, as well as their status (e.g. known defects). In the case ofchanges, differences with respect to the previous version shall be documented in the release note.

Guidance note:

The owner may adopt the configuration management mechanisms already defined or modify them appropriately. The overallrelease note may link to each system's release note. The system integrator should base the release note on inputs from thesuppliers, see X.CM.2 in [1.7.4].



Approved configuration management plan.

Records of transmission of software, documentation anddata, or responsibility thereof.

Overall release note for the systems in ISDS scope.

None

1.5.3 D.INT.1 Check readiness for integration of systems and components before commissioningPhase: construction.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: readiness of the systems and components for integration shall be checked before startingcommissioning. The criteria defined in the integration plan shall be used to assess readiness.

Guidance note:

The FAT report from C.VV.4 and the RAMS compliance report from C.RAMS.1, as well as the ISDS status for the system in questionmay be used as a basis for the check.

This activity is typically performed at mechanical completion. See activity B.VV.1 in [1.3.16] for a description of the integrationplan.



Integration readiness criteria fulfilled per component andper system

Readiness report (FI) used in D.IV.1 at CL.2

App

endi

x B


DNV GL AS

1.5.4 D.RAMS.1 Demonstrate achievement of the vessel reliability, availability, maintainability,safety requirementsPhase: acceptance.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: RAMS arguments and evidence shall be assembled to demonstrate achievement of RAMSrequirements and objectives on the vessel level.

Data from commissioning and integration testing shall be collected and used together with data from earlierverification activities to estimate reliability, availability and maintainability values relative to the RAM objectives.

Guidance note:

The RAMS requirements and objectives are collected in activity A.REQ.1.

The arguments and evidence may include: safety analysis, FME(C)A, test cases, inspections, computations and simulations,certifications etc. The suppliers normally provide information gathered in the activity C.RAMS.1.

Several methods for estimating reliability are available, for example: weibull, SINTEF PDS. Reliability and maintainability datacan be used to calculate availability. Maintainability for software may differentiate activities such as restoration of the production(typically a fast activity), and defect correction (typically a longer one).



RAMS compliance analysis information.

Calculations of RAM values for relevant systems and thevessel.

RAMS compliance report (FI) reviewed in D.IV.3 at CL3

1.5.5 D.RAMS.2 Perform a security audit on the deployed systemsPhase: acceptance.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: a security audit shall be performed on the relevant deployed systems to verify that thesecurity related requirements are fulfilled.

The audit shall be based on the security policy defined in A.RAMS.2.

Guidance note:

The DNVGL-OS-D202 contains some security related requirements, and the owner may request additional requirements to be met.The security requirements are normally documented together with the other vessel and system level requirements, see activityA.REQ.2 in [1.2.7].



Security audit report Security audit report (FI) used in D.IV.3 at CL3

App

endi

x B


DNV GL AS

1.5.6 D.VV.1 Perform systems integration tests Phase: acceptance.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: integration tests shall be performed to ensure that inter-system functionality is working asexpected and that the interfaces between systems are compliant to the requirements. Scenarios involving interfacesbetween the different parts shall be included in the test cases.

Guidance note:

The interaction between the different systems should be tested, not only the match between output signals and input signals. Boththe nominal behaviour and the degraded behaviour should be tested.



Integration test procedures covering system interfacesand inter-system functionality.

Integration test reports.

None

1.5.7 D.VV.2 Perform validation testingPhase: acceptance.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: the validation procedure shall be established according to the validation strategy.

The testing steps for validation shall be identified and clearly separated from the parameterisation and calibrationsteps. Software shall be taken into consideration.

Detailed procedures for testing shall be completed (test cases), and documented. The expected results for each testcase shall be specified.

The test procedures shall be sent to the owner for approval.

Guidance note:

Validation testing is usually divided between different activities and may be performed partly during commissioning, integrationtesting, and quay or sea trials.

Parameterisation and calibration (of the software) should be performed prior to commissioning. A pre-commissioning step is oftensuitable.

In some cases the validation tests also include tests that have not been possible to run during internal tests at the supplier(C.VV.2) or at the FAT (C.VV.4).



Test procedure: black box tests, boundary tests, softwarebehaviour and parameterisation and calibration.

Test reports.

Test issue list: deviations (punches) and variations.

None

App

endi

x B


DNV GL AS

1.6 Operation phase

1.6.1 E.CM.1 Manage change requests during operationPhase: operation.Vessel level responsible: owner.System level responsible: supplier.

Requirement definition: change requests and bug fixes shall be systematically handled. Potential changes shall beanalysed to assess their impact on operation, as well as effects on other systems. A CCB shall evaluate the impactanalysis before approving proposed changes.

Guidance note:

The CCB is expected to handle changes to the system, minor bug fixes may be defined as out of scope for CCB evaluation, seeE.PQA.1 in [1.6.4] for procedures for problem resolution.



Change requests.

Impact analysis.

Change orders.

Work orders.

Problem reports.

Release notes.

Maintenance logs.

None

1.6.2 E.CM.2 Perform configuration auditsPhase: operation.Vessel level responsible: owner.System level responsible: none.

Requirement definition: there shall be regular configuration audits to verify the integrity of the configuration inoperation. Configuration audits shall confirm 1) that the operational software versions match supplier records andon-board back-ups, 2) documentation versions match the operational software versions, and 3) the configurationmanagement plan is being followed.


Configuration audit reports None

App

endi

x B


DNV GL AS

1.6.3 E.DES.1 Manage and monitor obsolescencePhase: operation.Vessel level responsible: owner.System level responsible: supplier.

Requirement definition: the acquired components and systems shall be monitored so that pro-active actionsmay be made before parts become obsolete.

The responsibilities for monitoring obsolescence and taking action when needed shall be clearly defined withinthe organisation.

Guidance note:

The monitoring done by the suppliers is normally done according to the strategy defined in B.DES.4.



Obsolescence strategy document.

Obsolescence management plan: authorised vendorlist, spare parts list (HW and compatible SW), alternatespare parts list and management of intellectualproperty

None

1.6.4 E.PQA.1 Define procedures for problem resolution, change handling, and maintenanceactivitiesPhase: operation.Vessel level responsible: owner.System level responsible: none.

Requirement definition: the owner shall establish procedures for receiving, recording, resolving, and trackingproblems, modification requests, and maintenance activities. Software update, backup and restore procedures shallalso be included.

Guidance note:

The problem resolution should be based on a systematic problem solving method (e.g. identified in the vessels International SafetyManagement (ISM) procedures) to investigate and provide a detailed response (including corrective action) to the problem(s)identified.



Configuration management plan.

Configuration management procedure: migration issuesand software obsolescence (see E.DES.1 in [1.6.3].

Maintenance procedures: procedures for themaintenance, software update, backup and restoreprocedures and procedures for receiving, recording,resolving, tracking problems and modification requests.

Issue tracking and resolution procedure.

None

Acceptable contributions from supplier: provide inputs regarding the supplier’s system(s) to the problem resolutionand change handling process

App

endi

x B


DNV GL AS

1.6.5 E.RAMS.1 Collect reliability, availability, maintainability, safety dataPhase: operation.Vessel level responsible: owner.System level responsible: none.

Requirement definition: a system to collect RAMS data from the vessel in operation shall be established.

Data shall be forwarded to the relevant suppliers.

Guidance note:

RAMS data typically include: failures and incidents, downtime, uptime, number of demands, time to repair, etc. Even small defectsand incidents should be reported, particularly if repeated.



RAMS data collection system.

RAMS data collected.

None

1.6.6 E.RAMS.2 Analyse reliability, availability, maintainability, safety data and addressdiscrepanciesPhase: operation.Vessel level responsible: owner.System level responsible: supplier.

Requirement definition: RAMS data shall be analysed in order to assess and improve the RAMS performance.

For the software, the analysis shall be broken down to the level of software components in order to identify thecomponents that are candidates for improvement.

Discrepancies between RAMS requirements/objectives and the actual RAMS results shall be addressed.

Guidance note:

RAMS analysis typically result in numbers for MTBF, mean time to repair (MTTR) etc.



RAMS analysis. None

App

endi

x B


DNV GL AS

1.6.7 E.RAMS.3 Perform reliability, availability, maintainability, safety impact analysis of changesPhase: operation.Vessel level responsible: owner.System level responsible: supplier.

Requirement definition: before changes are made to the system in operation, the impacts on RAMS properties shallbe analysed. For major changes or changes with major RAMS impact, The owner shall inform DNV GL before thechange is made.

Guidance note:

This activity is an extension of the activity E.CM.1. Major changes are changes that are impacting functionality, performance or theinterfaces of systems. Bug fixes are normally not considered a major change.



Impact analysis showing RAMS evaluation None

1.6.8 E.RAMS.4 Periodically perform security audits of the systems in operationPhase: operation.Vessel level responsible: owner.System level responsible: none.

Requirement definition: relevant systems in ISDS scope shall periodically be audited from a security point of view

Guidance note:

DNVGL-OS-D202 contains some security related requirements. A number of different standards are available and one of them maybe used as a basis for the security audit, see references in A.RAMS.2 in [1.2.5].



Security audit report None

App

endi

x B


DNV GL AS

1.6.9 E.VV.1 Perform validation testing after changes to the systems in operationPhase: operation.Vessel level responsible: owner.System level responsible: none.

Requirement definition: after minor upgrades and corrections, validation testing shall be done for the systemsaffected

Guidance note:

Major upgrades or conversions require the application of the whole ISDS standard.



Test procedure: includes black box tests and includesboundary tests.

Test reports: consistent with procedure.

None

Acceptable contributions from supplier: contribute to preparing test procedures and to execute test

1.7 Several phases

1.7.1 X.ACQ.1 Monitor contract execution and changesPhase: several.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: when development or configuration of a software component is subcontracted, the buyingorganisation shall monitor that the contract is executed as agreed. The ISDS requirements specified in the contractshall be followed up. Progress and quality shall be tracked.

Progress reviews with sub-suppliers shall be planned and held.

The impact of contract changes on software components shall be considered.

This activity shall be performed in phases B-E.


Sub-supplier progress review schedule.

Sub-supplier progress review reports.

Sub-supplier project control records.

Sub-supplier quality control records.

None

App

endi

x B


DNV GL AS

1.7.2 X.ACQ.2 Review intermediate deliverablesPhase: several.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: selected intermediate deliverables from sub-suppliers shall be provided FI and review, inorder to give visibility into status and progress.

The review of deliverables shall be planned.

This activity shall be performed in phases B-C.


Supplier agreement: list of deliverables and review andapproval plans.

Review records/minutes.

None

1.7.3 X.CM.1 Track and control changes to the baselinesPhase: several.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: the development of any part of the vessel shall follow the rules in the configurationmanagement plan to maintain consistency at all levels and among all software components.

Changes to requirements, design, interface definitions and software baselines shall be tracked and controlled.When changes are made to lower level designs and code, higher level designs and requirements shall be updatedappropriately. This activity shall be performed in phases A-D for the system integrator and in phases B-E for thesupplier.

Guidance note:

Typical information tracked includes: date, author, contents of the change, rationale for the change, components impacted, andversion and configuration number changes. Proposed changes should be reviewed and approved. This activity should follow theconfiguration management plan.



Change requests/orders.

Version histories for baselines.

Changes to: vessel requirements, vessel design, systemrequirements, system design, software design, interfacespecifications and software.

Configuration records from document or softwarerepositories.

None

App

endi

x B


DNV GL AS

1.7.4 X.CM.2 Establish a release note for the delivered systemPhase: several.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: each time a system, sub-system or software component is presented outside the suppliers'sorganisation, it shall come with a release note, describing the functional content of the delivery (versions of theapplicable specifications) as well as its physical content (list of items with their versions). The differences withrespect to the previous version shall be documented in the release note. This activity shall be performed in phases C-E.

Guidance note:

Release notes are typically not used to describe tuning of parameters during commissioning. Details on how to document suchchanges should be decided as part of the D.CM.1 activity. Release notes are typically expected:

— before entering the FAT

— at handover of the software to the system integrator (in case of changes after FAT)

— before entering the commissioning tests

— at handover of the software from the system integrator to the owner (in case of changes after commissioning)

— whenever important updates have been made to the software (according to D.CM.1).



Component release note: including list of changesto previous version the system, sub-system or ofcomponent

None

App

endi

x B


DNV GL AS

1.7.5 X.PM.1 Monitor project status against the planPhase: several.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: the project’s activities shall be monitored against the plan and reported. Corrective actionsshall be taken when significant deviations from the plan occur. When needed, coordinated actions shall be undertakenwith other stakeholders.

This activity shall be performed in phases A-D for the system integrator and phases B-E for the supplier.

Guidance note:

It is strongly recommended that joint meetings between the different organizations/roles are conducted on a regular basis in orderto coordinate and track the progress of the activities in this standard.

Corrective actions may include actions to bring back the project’s status to the plan, or actions to establish new work estimatesand/or an updated plan.

Policies (information security) or strategies (obsolescence, verification, validation, and integration) should be updated whenneeded.

During operation, most activities are constrained by maintenance or operation plan. Significant upgrades or corrections requiringcoordination with several stakeholders may require a specific project plan, as specified by this standard.



Master schedule.

Master plan (updated).

Project status report.

Project action list.

Minutes of review meetings.

Progress report.

None

App

endi

x B


DNV GL AS

1.7.6 X.PM.2 Perform joint project milestone reviewsPhase: several.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: joint project milestone reviews to check achievement of phase objectives and ISDScompliance status shall be planned and carried-out. Significant risks, issues and their impact shall be documentedand tracked until closure. Decisions whether or not, or how, to progress to the next phase shall be recorded.

In the phase A, the system integrator and the owner shall participate. In the B-D phases, all roles shall participate.

Guidance note:

The ISDS milestones are intended to be the critical event to decide whether to proceed further in the project, weighing the risks ofmoving to the next phase versus the risks of postponing it. In some cases, the decision to move forward may include considerableproject risks. The milestone is a good practice to communicate the extent of such risks to all stakeholders.

The milestone review is typically the last activity to be performed in each phase.

For the phase E, this activity is only applicable in case of large upgrades, where the changes are managed as separate projects(see Ch.2 Sec.4).



Minutes of joint milestone meetings.

ISDS compliance status.

Action plans.

List of risks

None

App

endi

x B


DNV GL AS

1.7.7 X.PQA.1 Establish a development planPhase: basic engineering.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: a development plan for the vessel/system shall be established at the beginning of the project(phase A for system integrator, phase B for supplier).

Procedures to be used within the project shall be defined and all relevant ISDS requirements shall be explicitlymapped to the procedures that will be used in the project.

Roles, responsibilities and specific requirements as defined in this standard shall be explicitly addressed. The vessel/system development plan shall be kept up to date throughout the project.

Guidance note:

The word procedures in this context are used to represent all documentation regarding the way of working, e.g. processdescriptions, standard operating procedures, work instructions, checklists, guidelines etc.

Some procedures may need to be coordinated with the other project stakeholders, see X.PQA.2 in [1.7.8].

The vessel development plan needs to be coordinated with the project master plan, see A.PM.1 in [1.2.3].

The vessel/system development plan (also referred to as project quality plan) is normally made up of quality management systemdocuments: e.g. standard operating procedures, process description, checklists, and document templates along with any projectspecific adaptations of these.



Vessel/system development plan, and supportingdocumentation including: a quality system, documents,minutes of meetings, or other relevant informationshowing: a defined way of working for the majoractivities in the project, clear roles and responsibilitiesand defined ways of interaction between the differentorganizations (e.g. owner, system integrator, supplier,IV, and others).

Development plan (AP) reviewed in A.IV.2 (systemintegrator) and B.IV.1 (supplier) for CL2.

App

endi

x B


DNV GL AS

1.7.8 X.PQA.2 Coordinate key formats and mechanismsPhase: several.Vessel level responsible: system integrator.System level responsible: none.

Requirement definition: all project roles (owner, system integrator, supplier) shall agree on a number of concepts tobe used in the project. These concepts shall at least include:

— risk reporting mechanisms, see X.RISK.1 in [1.7.11]— format for interface specifications, see B.INT.1 in [1.3.10]— format for requirements traceability information, see A.REQ.2 in [1.7.2] and X.REQ.1 in [1.7.10]— document submittal and approval scheme, see B.CM.1 in [1.3.3]— problem resolution scheme, see C.PQA.1 in [1.4.6].

Guidance note:

As a general principal, relevant concepts should be agreed upon before being actively used in the project, e.g. format for interfacespecifications needs to be agreed upon before work on interface specifications begin in the project. For details regarding whichinformation that shall be agreed upon, see description for each specific activity.



Agreed governing project documentation addressing theconcepts and mechanisms in question.

None

1.7.9 X.PQA.3 Control proceduresPhase: several.Unit level responsible: system integrator.System level responsible: supplier.

Requirement definition: procedures shall be controlled to ensure defined procedures are followed and that theactivities required by this standard are executed in practice.

This activity shall be performed in phases A-D for the system integrator and B-E for the suppliers.

Guidance note:

Follow up of the procedures may result in increased process adherence, improvement of procedures, or training as required.



Proof that process adherence is being assessed: qualitycontrol records, project control records and minutes ofmeetings, or other relevant information.

None

App

endi

x B


DNV GL AS

1.7.10 X.REQ.1 Maintain requirements traceability informationPhase: several.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: traceability of requirements shall be kept up to date. Three kinds of traceability informationare required:

1) Traceability between requirements on different levels (e.g. from vessel to system and system to component).

2) Traceability from a requirement to where and how it is designed and implemented.

3) Traceability from a requirement to where and how it is verified and validated.

This activity shall be performed in phases A-D for the system integrator and in phases B-E for the supplier.

Guidance note:

The traceability information between vessel and systems is established in activity A.REQ.2. The traceability information withina system emerges in activity B.REQ.1, B.DES.1 and B.DES.2. The traceability information from requirements to verification andvalidation emerges in activity C.VV.2/4, D.VV.1/2 and X.VV.1 as applicable.

Traceability matrices are normally used to document the traceability information, but also databases or references from documentsto documents may be used as long as the traceability information is explicit and reviewable.

The purpose of the traceability information is to ensure completeness and consistency of all requirements on all levels. In additionit is a tool to help verify that no requirement has been forgotten or added without the proper actions.



Up to date traceability information: from owner tosystem requirements, from system requirements tofunctional specifications (where applicable), from systemrequirements to base-product and configuration data(where applicable), from functional specifications to sub-system/component specifications and from requirementsto test procedures (when the test procedures areavailable).

Completeness and consistency review records of thetraceability information.

Traceability matrices (FI) used in C.IV.1 at CL2

App

endi

x B


DNV GL AS

1.7.11 X.RISK.1 Track, review and update risksPhase: several.Vessel level responsible: system integrator.System level responsible: supplier.

Requirement definition: the list of risks shall be reviewed and updated regularly, in order to re-evaluate the riskattributes or to take into account new risks. Risks involving other stakeholders shall be regularly shared, reviewedand updated jointly.

Risk mitigation actions shall be decided and planned, according to the risk strategy. Status of these actions shall bemonitored regularly. Efficiency of mitigation actions shall be assessed and new actions taken as needed. Mitigationactions involving other stakeholders shall be coordinated.

This activity shall be performed in phases A-D for the system integrator and phases B-E for the supplier. For the Ephase, the owner shall establish and maintain the risk list for significant upgrades or conversions.

Guidance note:

It is important that a consistent picture of the risks involving other stakeholders is regularly shared, both with externalstakeholders, and with the stakeholders within the organisation.

New stakeholders introduced throughout the project should be informed about the risk management plan and the jointly identifiedrisks and be given an opportvessely to provide inputs to necessary updates.



Project risk management plan.

Updated internal risk register: risk list, mitigation actionsand follow-up records (per organization).

Updated project risk register: risk list, mitigation actionsand follow-up records (jointly managed).

None

App

endi

x B


DNV GL AS

1.7.12 X.VV.1 Perform verification and validation on added and modified software componentsPhase: several.Vessel level responsible: none.System level responsible: supplier.

Requirement definition: developed and integrated software components shall be verified, validated and tested forregression before decision to accept the component. This also applies if changes to software components occurafter defined baselines, such as FAT. The status of the component verification and validation shall be analysed andcompared with expected process and quality attributes targets.

Detailed procedures for testing shall be completed (test cases), and documented. The expected results for each testcase shall be specified. This activity shall be performed in phases C-E.

Guidance note:

Changes to software components should not only trigger verification and validation of the component that has been changed, butalso of other related components to prevent regression.



Test procedure: consistent with change or upgrade scope.Test report: consistent with test procedure.

None

Cha

nges

– h

isto

ric


DNV GL AS

CHANGES – HISTORIC

July 2015 edition

Main changes July 2015

• GeneralThe revision of this document is part of the DNV GL merger, updating the previous DNV standard into a DNVGL format including updated nomenclature and document reference numbering, e.g.:

— Main class identification 1A1 becomes 1A.— DNV replaced by DNV GL.— DNV-RP-A201 to DNVGL-CG-0168. A complete listing with updated reference numbers can be found on

DNV GL's homepage on internet.

To complete your understanding, observe that the entire DNV GL update process will be implementedsequentially. Hence, for some of the references, still the legacy DNV documents apply and are explicitlyindicated as such, e.g.: Rules for Ships has become DNV Rules for Ships.

About DNV GLDriven by our purpose of safeguarding life, property and the environment, DNV GL enablesorganizations to advance the safety and sustainability of their business. We provide classification,technical assurance, software and independent expert advisory services to the maritime, oil & gasand energy industries. We also provide certification services to customers across a wide rangeof industries. Operating in more than 100 countries, our experts are dedicated to helping ourcustomers make the world safer, smarter and greener.

SAFER, SMARTER, GREENER