dnvgl-os-d203 integrated software dependent …...modified, parameterized, tuned and/or configured...

OFFSHORE STANDARD

DNVGL-OS-D203 Edition July 2015

Integrated software dependent systems (ISDS)

DNV GL AS

The electronic pdf version of this document found through http://www.dnvgl.com is the officially binding version. The documents are available free of charge in PDF format.

FOREWORD
DNV GL offshore standards contain technical requirements, principles and acceptance criteria related toclassification of offshore units.
© DNV GL AS July 2015

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 this document. The use of thisdocument by others than DNV GL is at the user's sole risk. DNV GL does not accept any liability or responsibility for loss or damages resulting from any use ofthis document.

C

hang

es –

cur

rent
CHANGES – CURRENT
GeneralThis document supersedes DNV-OS-D203, December 2012.

Text affected by the main changes in this edition is highlighted in red colour. However, if the changes

On 12 September 2013, DNV and GL merged to form DNV GL Group. On 25 November 2013 Det NorskeVeritas AS became the 100% shareholder of Germanischer Lloyd SE, the parent company of the GL Group,and on 27 November 2013 Det Norske Veritas AS, company registration number 945 748 931, changed itsname to DNV GL AS. For further information, see www.dnvgl.com. Any reference in this document to “DetNorske Veritas AS”, “Det Norske Veritas”, “DNV”, “GL”, “Germanischer Lloyd SE”, “GL Group” or any otherlegal entity name or trading name presently owned by the DNV GL Group shall therefore also be considereda reference to “DNV GL AS”.

involve a whole chapter, section or sub-section, normally only the title will be in red colour.

Main changes July 2015• GeneralThe revision of this document is part of the DNV GL merger, updating the previous DNV standard into a DNV GL 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 implemented sequentially. Hence, for some of the references, still the legacy DNV documents apply and are explicitly indicated as such, e.g.: Rules for Ships has become DNV Rules for Ships.

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

Editorial corrections

Offshore standard, DNVGL-OS-D203 – Edition July 2015 Integrated software dependent systems (ISDS)

DNV GL AS

C

onte

nts
CONTENTS
CHANGES – CURRENT ................................................................................................. 3

CH. 1 INTRODUCTION ......................................................... 7Sec.1 General ......................................................................................................... 7

1 General .....................................................................................................71.1 Introduction.......................................................................................71.2 Objectives .........................................................................................71.3 Organisation of content .......................................................................71.4 Assumptions ......................................................................................71.5 Scope and application .........................................................................81.6 Types of software within scope .............................................................81.7 Alterations and additions of approved systems........................................8

2 References................................................................................................82.1 International or national references.......................................................82.2 DNV/ DNV GL reference documents.......................................................9

3 Definitions and abbreviations ...................................................................9

CH. 2 TECHNICAL PROVISIONS ......................................... 10Sec.1 Principles .................................................................................................... 10

1 General ...................................................................................................101.1 Process requirements ........................................................................101.2 System hierarchy .............................................................................10

Sec.2 Confidence levels ........................................................................................ 111 Confidence levels...................................................................................11

1.1 Definition of confidence levels ............................................................11

Sec.3 Responsibilities ........................................................................................... 121 Activities and roles .................................................................................12

1.1 Activities .........................................................................................121.2 Roles ..............................................................................................13

Sec.4 Project phases and process areas ............................................................... 141 Project phases ........................................................................................14

1.1 Introduction.....................................................................................141.2 A - basic engineering phase ...............................................................141.3 B - engineering phase .......................................................................141.4 C - construction phase ......................................................................151.5 D - acceptance phase........................................................................151.6 E - operation phase...........................................................................15

2 Process areas .........................................................................................152.1 Introduction.....................................................................................152.2 Requirements engineering (REQ) ........................................................152.3 Design (DES) ...................................................................................152.4 Implementation (IMP) .......................................................................162.5 Acquisition (ACQ) .............................................................................162.6 Integration (INT) ..............................................................................162.7 Verification and validation (VV)...........................................................162.8 Reliability, availability, maintainability and safety (RAMS) ......................172.9 Project management (PM) .................................................................172.10 Risk management (RISK) ..................................................................17


DNV GL AS

C

onte

nts
2.11 Process and quality assurance (PQA)...................................................17
2.12 Configuration management (CM) ........................................................17

Sec.5 ISDS requirements for owners .................................................................... 181 Owner requirements...............................................................................18

1.1 Requirements under the owner’s responsibility .....................................181.2 Acceptance criteria for owner assessments...........................................181.3 Documentation criteria for the owner ..................................................20

Sec.6 ISDS requirements for system integrators .................................................. 211 System integrator requirements .............................................................21

1.1 Requirements under the system integrator’s responsibility .....................211.2 Acceptance criteria for system integrator assessments...........................221.3 Documentation criteria for the system integrator ..................................25

Sec.7 ISDS requirements for suppliers ................................................................. 271 Supplier requirements ............................................................................27

1.1 Requirements under the supplier’s responsibility ...................................271.2 Acceptance criteria for supplier assessments ........................................281.3 Documentation criteria for the supplier ................................................32

Sec.8 ISDS requirements for the independent Verifier ......................................... 341 Independent verifier requirements.........................................................34

1.1 Activities for which the independent verifier is responsible......................34

CH. 3 CLASSIFICATION AND CERTIFICATION.................... 43Sec.1 Requirements.............................................................................................. 43

1 General ...................................................................................................431.1 Introduction.....................................................................................431.2 Organisation of Chapter 3 ..................................................................431.3 Classification principles......................................................................431.4 Compliance of activities .....................................................................431.5 Approval of documents......................................................................431.6 Rating of compliance ........................................................................441.7 Reporting and milestone meetings ......................................................44

2 Class notation.........................................................................................442.1 Designation .....................................................................................442.2 Scope .............................................................................................44

3 In operation assessments.......................................................................483.1 Objectives .......................................................................................483.2 Scope of annual assessments .............................................................483.3 Scope of renewal assessments ...........................................................49

APP. A DEFINITIONS AND ABBREVIATIONS ...................... 501 Definitions ..............................................................................................50

1.1 Verbal forms ....................................................................................501.2 Definitions .......................................................................................50

2 Abbreviations .........................................................................................56

APP. B REQUIREMENT DEFINITION ................................... 581 Requirement definition ...........................................................................58

1.1 General ...........................................................................................581.2 Activity definition basic engineering ....................................................58


DNV GL AS

C

onte

nts
1.3 Activity definition engineering ............................................................66
1.4 Activity definition construction............................................................771.5 Activity definition acceptance .............................................................861.6 Activity definition operation................................................................901.7 Activity definition several phases ........................................................94


DNV GL AS

Cha

pter

1

Sec

tion

1
CHAPTER 1 INTRODUCTION
SECTION 1 GENERAL

1 General

1.1 Introduction1.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 systems where 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 system components, and the effects these have on the overall performance of the unit (ship, rig etc.) in terms of functionality, quality, reliability, availability, maintainability and safety.

This standard intends to help system integrators and suppliers as well as owner to:

— reduce the risk for delays in new-build 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 integrated software dependent systems by defining requirements for the work processes during 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 units 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.

1.4 Assumptions1.4.1 The requirements of this standard are based on the assumptions that the personnel are qualified to execute the assigned activities.

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


DNV GL AS

Cha

pter

1

Sec

tion

1
1.5 Scope and application1.5.1 The requirements of this standard apply to the processes that manage ISDS throughout the life cycle of a ship or offshore unit, and apply to new-builds, upgrades and modification projects. It puts requirements on 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. This standard focuses on the software aspect in the context of system and unit requirements.

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

1.6 Types of software within scopeThis standard focuses on achieving high software quality and takes into consideration all typical types of software. The requirements differ depending on whether the software is new or reused:

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

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

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.

4) Procurement of COTS software as described in this standard.

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

2 References

2.1 International or national referencesThe standards listed in Table 1 are referenced in this standard.

Table 1 International or national references

Reference TitleIEC IEV 191 Dependability and quality of serviceIEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systemsIEC 61511 Functional safety – Safety instrumented systems for the process industry sectorIEC 19501:2005 Unified modelling language specificationIEEE 610.12:1990 Glossary of software engineering terminologyIEEE 828-1983 Software configuration management planIEEE 829-1983 Software test documentationIEEE 1074:2006 Developing software life cycle processesINCOSE SE 2004 INCOSE System Engineering Handbook, 2004


DNV GL AS

Cha

pter

1

Sec

tion

1

2.2 DNV/ DNV GL reference documentsApplicable DNV GL publications are given in Table 2 to Table 4.

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

ISO/IEC 9126 Software engineering — Product qualityISO/IEC 15288 Life Cycle Management — System Life Cycle ProcessesISO 9000 Quality management systemsSWEBOK 2004 Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004 Version

Table 2 DNV GL rules for classification - Offshore units

Reference Title DNVGL-RU-OU-0101 Offshore drilling and support units DNVGL-RU-OU-0102 Floating production, storage and loading unitsDNVGL-RU-OU-0103 Floating LNG/LPG production, storage and loading unitsDNVGL-RU-OU-0104 Self elevating units

Table 3 DNV GL offshore Standards

Standard TitleDNVGL-OS-A101 Safety principles and arrangementsDNVGL-OS-D101 Marine and machinery systems and equipmentDNVGL-OS-D201 Electrical installationsDNVGL-OS-D202 Automation, safety and telecommunication systemsDNVGL-OS-D301 Fire protectionDNVGL-OS-E101 Drilling plantDNVGL-OS-E201 Oil and gas processing systemsDNVGL-OS-E301 Position mooring

Table 4 Other DNV and DNV GL references

Reference TitleDNV-OSS-300 Risk Based VerificationDNV-RP-D201 Recommended practice for Integrated Software Dependent SystemsDNVGL-CG-0168 Plan approval documentation types – definitionsDNV-RP-A203 Recommended Practice for Qualification of New TechnologyDNV Rules for ships Pt.6 Ch.7

DNV Rules for Classification of Ships - Dynamic Positioning Systems

DNV Rules for ships Pt.6 Ch.26

DNV Rules for Classification of Ships - Dynamic Positioning System - Enhanced Reliability DYNPOS-ER

DNV SfC 2.24 DNV Standards for Certification - Hardware in the Loop Testing (HIL)

Table 1 International or national references (Continued)

Reference Title


DNV GL AS

Cha

pter

2

Sec

tion

1
CHAPTER 2 TECHNICAL PROVISIONS
SECTION 1 PRINCIPLES

1 General

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

1.2 System hierarchy1.2.1 In order to describe the different parts that make up Integrated Software Dependent Systems, this standard uses the hierarchy defined in Figure 1.

Figure 1 The hierarchy terms used in this standard


DNV GL AS

Cha

pter

2

Sec

tion

2
SECTION 2 CONFIDENCE LEVELS
1 Confidence levels

1.1 Definition of confidence levels1.1.1 Confidence levels are assigned by the owner to a selection of the unit’s functions and systems, based on evaluations of the importance of these functions in relation to reliability, availability, maintainability and safety.

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

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

1.1.4 Ch.3 Sec.1 [2.2] shows the recommended confidence levels for systems and components relevant for selected unit types (drilling unit, FPSO etc.).

Guidance note:See DNV-RP-D201 for general guidance on the principles of assigning confidence levels to functions and systems.

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

Table 1 The difference between the confidence levels

Confidence level Characteristics Focus Key activities

1 Basic software confidence System Project managementDefined ways of workingDesign and verification of software within a system

2 Enhanced integration confidence SystemsSystem integration

Interface definitionDescribing interaction between systemsTraceability of requirementsQualitative RAMSObsolescence management

3 Enhanced quantified confidence SystemsSystem integrationHigh dependability

Quantitative RAMSHigh involvement of independent verifierEnhanced verification


DNV GL AS

Cha

pter

2

Sec

tion

3
SECTION 3 RESPONSIBILITIES
1 Activities and roles

1.1 Activities1.1.1 Each requirement of this standard is formulated as an activity which is assigned to a role, a defined project phase, 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 activity identifier 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 the requirements process area for the basic engineering phase. Some activities are performed in 2 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 common activity no. 1 for the requirements process area for managing requirement changes in all phases.


1.1.2 Several activities require communication between different roles to be carried out. For these activities the contributing role(s) are specified, in addition to the responsible role. The expected contributions are specified in this standard, and the contributing role shall provide the specified information to the responsible role when requested.

Figure 1 An overview of communication and exchange of information between the roles.


DNV GL AS

Cha

pter

2

Sec

tion

3
1.2 Roles1.2.1 This standard defines requirements on several organisations with responsibilities within the system life cycle. Each role is assigned activities and has the responsibility to perform the activity with an outcome that fulfils the specified criteria.
1.2.2 Each organisation is assigned one of four predefined roles. The four roles are:

— Owner (OW): In the context of this standard the owner is the organisation who decides to develop the unit (ship, rig etc.), and provides funding. The operator of the system can be part of the owner's organisation, or can be a subcontractor acting on behalf of the owner. For a definition of the term owner reference is also made to the applicable Rules for offshore units Ch.1 Sec.1 [2].

— System integrator (SI): Responsible for the integration of all systems included in the scope of this standard. The system integrator is normally the shipyard, but parts of the integration may be delegated to other parties. In such case this shall be clearly defined and documented.

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

— Independent verifier (IV): An organisation that is mandated to independently verify that the system is developed according to this standard. As part of the classification process for the ISDS notation, DNV GL shall take the role of independent verifier.


DNV GL AS

Cha

pter

2

Sec

tion

4
SECTION 4 PROJECT PHASES AND PROCESS AREAS
1 Project phases

1.1 Introduction1.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 following information 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 independent verifier.

1.1.3 At each milestone a “milestone meeting” should be arranged. The system integrator is responsible for arranging such meetings at all milestones, except M5 for which the owner is responsible.

1.1.4 An ISDS milestone is completed when the owner, the system integrator and the independent verifier endorse the information presented at the milestone.

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

1.2 A - basic engineering phase During this phase the technical specification and design of the unit are established, including RAMS requirements. The main systems which will be included in the scope for ISDS requirements and their confidence levels are identified. The contract between the owner and the system integrator is established during this phase.

Guidance note:The following activities normally take place before the contract between the owner and the system integrator is signed, depending on the confidence level for the different systems:

— Define mission, objectives and shared vision (A.REQ.1, CL1 and above).

— Define operational modes and scenarios to capture expected behaviour (A.REQ.3, CL2 and above).

— Define RAM related requirements and objectives (A.RAMS.2, CL2 and above).

— Define procedures (owner) (A.PQA.1, CL1 and above).


1.3 B - engineering phase In this phase contracts are established with suppliers, and the suppliers are involved in setting up the development/configuration of each system. The detailed design of the unit and systems is documented. The verification, validation, testing and integration strategies, and major interfaces are established, and RAMS analyses are carried out.

Guidance note:The ISDS process is normally aligned with the overall building schedule so that steel cutting takes place towards the end of the ISDS engineering phase.

Normally, only one phase B activity takes place before the contracts between the system integrator and the suppliers are signed:


DNV GL AS

Cha

pter

2

Sec

tion

4
— Submit proposals to system integrator with compliance status (B.REQ.1, CL1 and above).

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

1.5 D - acceptance phase In this phase, the functionality, performance, RAMS requirements and other aspects of the integrated systems are validated, through commissioning activities, integration testing, and sea trials.

1.6 E - operation phase1.6.1 In this phase the unit is in operation. Maintenance and small upgrades are performed as deemed necessary by the owner.

1.6.2 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 unit or ship for any extended period of time should be regarded as a large upgrade.


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 engineering (REQ)The requirements engineering process area covers the activities needed to define, document and manage the requirements on the unit, the systems and the related software.

On CL1, the overall goal and vision for the unit are defined and the requirements on the unit and relevant systems are specified. A dialogue between the owner/system integrator on one hand and the potential suppliers on the other is expected to take place in order to align the requirements with the supplier’s systems. The allocation of requirements to systems shall be documented. No specific methods or formats for the unit or system requirements are expected.

On CL2, operational modes and scenarios are defined in order to put the requirements into an operational context, and to detail the interaction between different systems. A trace from requirements to design and verification shall be documented and maintained.

CL3 introduces additional independent verifier activities.

2.3 Design (DES)The design process area consists of activities to establish a design on different levels. Together with the interface related activities in the integration process area (INT), this creates the design basis from which the systems and related software can be produced and verified.

On CL1, each system is designed with identification of major sub-systems and components. The external interfaces shall be documented and coordinated with other relevant systems.

On CL2, the unit design is documented, maintained, and analysed with focus on integration of the systems. A strategy for handling of current and future obsolescence is expected to be defined, and design guidelines to be established. The architecture of relevant systems and software components is detailed and


DNV GL AS

Cha

pter

2

Sec

tion

4
documented, including new, reused, and parameterized software. The documentation related to any base-products shall be kept up to date.

2.4 Implementation (IMP)The implementation process area covers the coding and configuration activities needed to create and customize software modules in order to fulfil the specified design. In addition, associated support documentation shall be created.

On CL1, the software components are programmed, parameterized and tested based on a baselined design.

On CL2, implementation guidelines and methods are expected to be used as additional input to the programming and parameterization, and support documentation like user manuals is produced.

CL3 does not add any requirements.

2.5 Acquisition (ACQ)The acquisition process area includes activities related to when a supplier uses sub-suppliers to develop or deliver components/systems. It covers both the situation where configuration and development of the software components is subcontracted and the situation where the supplier buys 'commercial off the shelf' (COTS) systems.

On CL1, specific contracts between the supplier and the sub-supplier are established and followed-up. The components or systems are verified at delivery and it shall be ensured that the delivered component/system can be integrated into the system/unit in question.

On CL2, the COTS systems are selected based on defined criteria. Intermediate deliveries are reviewed, and acquired components or systems are monitored with regards to obsolescence during the operation phase.

CL3 does not add any requirements.

2.6 Integration (INT)The integration process area covers the assembly of the systems into the unit, and activities to coordinate the interfaces between the systems.

On CL1, the responsibilities regarding each system and how it is to be integrated are defined.

On CL2, a specific integration plan is produced. Inter-system interfaces are coordinated and systems checked against pre-defined criteria before the integration takes place.


2.7 Verification and validation (VV)The verification and validation process area addresses the quality assurance activities needed to ensure that that each software component, each system and the integrated systems in concert perform as expected and fulfil the needs of the intended use.

On CL1, the focus is on the individual systems. It is required that a verification strategy is defined, and that basic verification activities like FAT, peer reviews, and qualification of reused software are prepared and performed according to this strategy. It is also expected that the owner performs validation testing during the acceptance phase, and when modifications and upgrades are performed during the operation phase.

On CL2 the focus is on the functionality and performance of the integrated systems working together, and on early verification of the correctness and the completeness of requirements, interface specifications, user interfaces, and design documentation. The verification and validation results are expected to be analysed and compared with defined targets.

On CL3, the focus is on an elaborated system testing, and that an independent party performs testing on the system(s). Additional independent verifier activities are also introduced.


DNV GL AS

Cha

pter

2

Sec

tion

4
2.8 Reliability, availability, maintainability and safety (RAMS)The reliability, availability, maintainability and safety (RAMS) process area gathers the activities dealing with the definition, analysis and verification of the RAMS properties of the unit and specific systems. Security aspects are also included.
On CL1, the focus is on the safety part, meaning that applicable laws and regulations regarding safety are identified, and that software and software failures are taken into account when doing safety analysis. In the operation phase a structured way of doing maintenance is required.

On CL 2, the focus is on the reliability, availability and maintainability (RAM) of the systems in question. Goals regarding RAM are established, analysed and verified, but the goals can be qualitative 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. Security aspects are dealt with by performing security audits.

On CL3, the focus is on RAM objectives that are explicitly defined, analysed and proven fulfilled. In order to achieve this, the RAM objectives need to be quantitative. Additional independent verifier activities are also introduced.

2.9 Project management (PM)The project management process area covers the activities required to make sure that the project plans for the different organizations involved are created, synchronized and followed-up.

On CL1, basic project management activities regarding project planning and tracking are required, and there are no additional requirements at CL2 and CL3.

2.10 Risk management (RISK)The risk management process area covers activities related to identifying, mitigating and tracking product and project risks related to systems and software. Based on the risks, the different systems are assigned a confidence level.

On CL1, risks are identified, reviewed, tracked, and updated.

On CL2, also the risk mitigation actions shall be tracked to verify that they have the expected effect on the risk.


2.11 Process and quality assurance (PQA)The process and quality assurance process area covers the activities needed to define and follow up the way of working within the project. It also covers the activities needed to make sure that the involved organizations fulfil the requirements in this standard.

On CL1, the applicable procedures for each organization are defined and when necessary coordinated with the other roles. The adherence to the defined procedures is followed-up by each organization. DNV GL will follow-up on the adherence to the requirements in this standard.

There are no additional requirements at CL2 and CL3.

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

On CL1, the configuration management area includes all required activities, and there are no additional requirements at CL2 and CL3.


DNV GL AS

Cha

pter

2

Sec

tion

5
SECTION 5 ISDS REQUIREMENTS FOR OWNERS
1 Owner requirements

1.1 Requirements under the owner’s responsibility1.1.1 The following Table 1 lists the requirements under the owner’s responsibility. See also Table 2 for the associated acceptance criteria and Table 3 for documentation criteria.

1.1.2 The owner shall also contribute to requirements that are under the responsibility of other roles.

1.1.3 App.B fully specifies the requirements for all roles.

1.2 Acceptance criteria for owner assessments1.2.1 The following Table 2 lists the acceptance criteria for assessments of the owner. The following evidence shall be presented to the independent verifier during assessments to document that the required activities have been performed.

Table 1 Requirements under owner’s responsibility

Reference Required activity Contributor(s) Phase CLA.PQA.1 Define procedures (owner) Basic engineering CL1A.RAMS.2 Define RAM related requirements and objectives Basic engineering CL2A.REQ.1 Define mission, objectives and shared vision Basic engineering CL1

A.REQ.3 Define operational modes and scenarios to capture expected behaviour Basic engineering CL2

A.RISK.1 Define a strategy for risk management System integrator Basic engineering CL2A.RISK.3 Assign confidence levels System integrator Basic engineering CL1A.VV.1 Validate the concept of the unit with the users System integrator Basic engineering CL2

B.DES.5 Define obsolescence strategy System integrator,Supplier Engineering CL2

D.VV.1 Perform validation testing System integrator,Supplier Acceptance CL1

D.VV.2 Perform validation with operational scenarios System integrator,Supplier Acceptance CL2

D.VV.3 Analyse validation results with respect to targets Acceptance CL2E.CM.1 Manage change requests during operation Operation CL1E.CM.2 Perform configuration audits Supplier Operation CL1

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

E.RAMS.1 Maintain and execute the plan for maintenance in operation Supplier Operation CL1

E.RAMS.2 Collect RAMS data Operation CL2E.RAMS.3 Analyse RAMS data and address discrepancies Operation CL2E.RAMS.4 Perform RAMS impact analysis of changes Operation CL2

E.RAMS.5 Periodically perform security audits of the systems in operation Operation CL2

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

E.VV.2 Perform validation with operational scenarios after changes in the systems in operation Supplier Operation CL2

X.PQA.1 Control procedures (owner) Several CL1X.PQA.4 Follow-up of ISDS assessment gaps (owner) Several CL1


DNV GL AS

Cha

pter

2

Sec

tion

5
1.2.2 See also Table 3 for the required documentation criteria.
Table 2 Acceptance criteria for assessments of owner

Reference Assessment criteria

A.PQA.1

A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, clear roles and responsibilities and defined ways of interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others).

A.RAMS.2Listing of RAM requirements.For CL2: qualitative requirements are acceptable.For CL3: quantitative requirements (objectives) are required.

A.REQ.1 Unit design intention and philosophy: The vision of the unit/system, descriptions of the unit/systems overall behaviour and the expected business/safety/environmental performance.

A.REQ.3 Vessel specification: description of the operational modes and corresponding key operational scenarios, detailed to the level of the different systems.

A.RISK.1 Risk management procedure.Blank risk register.

A.RISK.3 Confidence level matrix for the relevant systems.

A.VV.1 Unit concept presentation: Simulations and Minutes of System Concept Review Meeting.FEED study.

B.DES.5Obsolescence management plan: Authorised vendor list, Spare parts list (hardware & software), stock, alternate spare parts list, management of intellectual property. Obsolescence criteria for software.Manufacturer preferred equipment list.

D.VV.1

Test procedure: black box tests, boundary tests, software behaviour and parameterisation and calibration.Test reports: executed consistent with procedure.Test issue list: deviations (punches) and variations.

D.VV.2 Test procedure: operational scenarios.Test reports: tests performed in compliance with procedure and coverage of scenarios.

D.VV.3Test procedure: quality criteria.Test reports: analysis of the results.Test issue list.

E.CM.1

Change requestsImpact analysisChange ordersWork ordersProblem reportsRelease notesMaintenance logs

E.CM.2 Configuration audit reports.

E.PQA.1

Configuration management plan.Configuration management procedure: migration issues and software obsolescence (ref E.ACQ.1).Maintenance procedures: procedures for the maintenance, software update, migration and retirement, backup and restore procedures and procedures for receiving, recording, resolving, tracking problems and modification requests.Change management procedure.Issue tracking and resolution procedure.

E.RAMS.1

Maintenance plan: configuration items, audit activities, maintenance activities, expected software update, migration and retirement activities, maintenance intervals and tailored procedures for the maintenance in operation.Malicious software scan log files records.Maintenance logs.

E.RAMS.2 RAMS data collection system.RAMS data collected.

E.RAMS.3 RAMS analysis.E.RAMS.4 Impact analysis showing RAMS evaluation.E.RAMS.5 Security audit report.

E.VV.1 Test procedure: includes black box tests and includes boundary tests.Test reports: consistent with procedure.


DNV GL AS

Cha

pter

2

Sec

tion

5

1.3 Documentation criteria for the owner1.3.1 The table below lists all documents to be sent to the independent verifier and in which activities the independent verifier is going to use the different documents.

1.3.2 When the independent verifier is expected to comment on the document, the word ‘reviewed’ is employed. For documents which serve as background information to put the reviewed documents in a context, the word ‘used’ is employed.

1.3.3 Most documents are provided for information (FI). The only document that is sent to the independent verifier for approval (AP) is the corrective action plan.

E.VV.2 Test procedures: Covering relevant Operational scenarios.Test reports: tests performed in compliance with procedure and analysis of the results.

X.PQA.1 Proof that process adherence is being assessed: Quality control records, Project control records and Minutes of meetings, or other relevant information.

X.PQA.4 Corrective action plan: Responsibility allocation for actions, Records of actions taken and Evidence of implementation of the actions.

Table 3 Documents required for review

Reference DocumentsA.PQA.1 No documentation to be submitted to DNV GL for review.

A.RAMS.2

List of RAM requirements unit (FI):- reviewed in A.IV.2 and B.IV.4 at CL3- used in D.IV.3 at CL3.List of RAM requirements system (FI) used in C.IV.3 at CL3.

A.REQ.1 Design Philosophy (FI) used in A.IV.1 at CL3.A.REQ.3 Vessel specification (FI) reviewed in A.IV.1 at CL3.A.RISK.1 No documentation to be submitted to DNV GL for review.

A.RISK.3Vessel specification (confidence levels) (FI):- reviewed in A.IV.1 at CL3- used in A.IV.2 and B.IV.4 at CL3.

A.VV.1 No documentation to be submitted to DNV GL for review.B.DES.5 No documentation to be submitted to DNV GL for review.

D.VV.1Test procedure for quay and sea trials (FI) and Report from quay and sea trials (FI) reviewed in D.IV.1 at CL2 and CL3.Report from quay and sea trials (FI) used in D.IV.2 at CL3.

D.VV.2 Test procedure (FI) and Test report (FI) reviewed in D.IV.1 at CL2 and CL3.Test report (FI) used in D.IV.2 at CL3.

D.VV.3 Verification analysis report (FI) reviewed in D.IV.2 at CL3.E.CM.1 No documentation to be submitted to DNV GL for review.E.CM.2 No documentation to be submitted to DNV GL for review.E.PQA.1 No documentation to be submitted to DNV GL for review.E.RAMS.1 No documentation to be submitted to DNV GL for review.E.RAMS.2 No documentation to be submitted to DNV GL for review.E.RAMS.3 No documentation to be submitted to DNV GL for review.E.RAMS.4 No documentation to be submitted to DNV GL for review.E.RAMS.5 No documentation to be submitted to DNV GL for review.E.VV.1 Test procedure (FI) and Test report (FI) reviewed in E.IV.1 at CL3.E.VV.2 Test procedure (FI) and Test report (FI) reviewed in E.IV.1 at CL3.X.PQA.1 No documentation to be submitted to DNV GL for review.X.PQA.4 Corrective action plan (AP) reviewed and approved in X.IV.1.

Table 2 Acceptance criteria for assessments of owner (Continued)



DNV GL AS

Cha

pter

2

Sec

tion

6
SECTION 6 ISDS REQUIREMENTS FOR SYSTEM INTEGRATORS
1 System integrator requirements

1.1 Requirements under the system integrator’s responsibility1.1.1 The following Table 1 lists the requirements under the system integrator’s responsibility. See also Table 2 for the associated acceptance criteria and Table 3 for documentation criteria.

1.1.2 The system integrator shall also contribute to requirements that are under the responsibility of other roles.


Table 1 Requirements under system integrator’s responsibility

Reference Required activity Contributor(s) Phase CL

A.CM.1 Establish a baseline of requirements for the unit Owner Basic engineering CL1

A.DES.1 Establish the unit design Owner Basic engineering CL2

A.PM.1 Establish the master plan Owner Basic engineering CL1

A.PQA.2 Define procedures (system integrator) Basic engineering CL1

A.RAMS.1 Determine safety rules, standards and laws applicable Owner Basic engineering CL1

A.RAMS.3 Develop the RAMS plan for the unit Owner Basic engineering CL2

A.REQ.2 Collect requirements for the unit and systems Owner Basic engineering CL1

A.REQ.4 Allocate functions and requirements to systems Owner Basic engineering CL1

A.REQ.5 Consult potential suppliers for acquiring of systems Owner Basic engineering CL1

A.REQ.6 Establish traceability of requirements Basic engineering CL2

A.RISK.2 Jointly identify risks Owner Basic engineering CL1

A.VV.2 Verify the unit and system requirements Basic engineering CL2

B.CM.1 Establish baselines of requirements and design Owner Engineering CL1B.CM.2 Establish and implement configuration management Owner Engineering CL1B.DES.3 Use established design guidelines and methods Engineering CL2

B.DES.4 Analyse and refine the unit design Owner,Supplier Engineering CL2

B.INT.1 Define integration plan Supplier Engineering CL2B.INT.2 Coordinate inter-system interfaces Supplier Engineering CL2B.PM.1 Establish the project plan for each organisation Owner Engineering CL1

B.PM.2 Coordinate and integrate the project plans with the master plan

Owner,Supplier Engineering CL1

B.RAMS.1 Identify software-related RAMS risks and priorities Owner Engineering CL2B.RAMS.2 Identify RAMS risk mitigation actions Engineering CL2B.VV.1 Define verification and validation strategy Owner Engineering CL1

B.VV.2 Review the design with respect to requirements and design rules Owner Engineering CL2

B.VV.3 Review consistency between design and operational scenarios Engineering CL2


DNV GL AS

Cha

pter

2

Sec

tion

6

1.2 Acceptance criteria for system integrator assessments1.2.1 The following Table 2 lists the acceptance criteria for assessments of the system integrator. The following evidence shall be presented to the independent verifier during assessments to document that the required activities have been performed.


B.VV.4 Review interface specifications Engineering CL2

B.VV.5 Validate critical or novel user-system interactions Owner,Supplier Engineering CL2

C.INT.1 Check readiness status of systems and components before integration Construction CL2

C.PQA.1 Establish procedures for problem resolution and maintenance activities in the construction and acceptance phases Supplier Construction CL1

C.VV.9 Arrange independent testing Supplier Construction CL3

D.CM.1 Manage software changes during commissioning Owner,Supplier Acceptance CL1

D.CM.2 Establish a release note for the systems in ISDS scope Acceptance CL1

D.CM.3 Transfer responsibility for system configuration management to owner

Owner,Supplier Acceptance CL1

D.RAMS.1 Demonstrate achievement of unit RAMS requirements Supplier Acceptance CL2D.RAMS.2 Collect data and calculate RAM values Supplier Acceptance CL3D.RAMS.3 Perform a security audit on the deployed systems Acceptance CL2D.VV.4 Perform systems integration tests Supplier Acceptance CL2X.CM.1 Track and control changes to the baselines Several CL1

X.PM.1 Monitor project status against plan Owner,Supplier Several CL1

X.PM.2 Perform joint project milestone reviews Owner,Supplier Several CL1

X.PQA.2 Control procedures (system integrator) Several CL1X.PQA.5 Follow-up of ISDS assessment gaps (system integrator) Several CL1X.REQ.1 Maintain requirements traceability information Several CL2

X.RISK.1 Track, review and update risks Owner,Supplier Several CL1

X.RISK.2 Decide, implement and track risk mitigation actions to closure Owner Several CL2

X.VV.2 Detail procedures for testing Several CL1

Table 2 Acceptance criteria for assessments of system integrator


A.CM.1 Approved and controlled unit requirements document.Revision history of unit requirements document.

A.DES.1 Unit design: unit design specifications, systems/network topology and functional descriptions.A.PM.1 Master plan: Activities, work breakdown structure (WBS), schedule, and milestones.

A.PQA.2

A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, clear roles and responsibilities and defined ways of interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others).

A.RAMS.1Listing of regulatory requirements that apply regarding safety.Resolution of conflicting rules.Application guidelines.

A.RAMS.3

Plan(s) showing the methods, tools, and procedures to be used for RAMS activities.Schedule of RAMS activities.Expectations on the suppliers’ RAMS plan.RAM data to be collected (CL3).

Table 1 Requirements under system integrator’s responsibility (Continued)



DNV GL AS

Cha

pter

2

Sec

tion

6

A.REQ.2 Vessel specification: operational requirements, functional requirements, non-functional requirements and technical constraints.

A.REQ.4 Design specification (or requirements) for the relevant systems.

A.REQ.5System request for proposal (RfP): functional specifications, generic system requirements and obsolescence information.Requirements compliance information (on CL2 and above).

A.REQ.6 Traceability information between requirements on unit level and requirements on the different systems.Defined mechanisms and ambition-level regarding requirements traceability.

A.RISK.2 Project risk list: risk list with risks related to e.g. requirements, schedule, effort, quality, performance, consistency and obsolescence (for both hardware and software).

A.VV.2 Review records of the unit requirements.Review records for the system requirements.

B.CM.1

Baseline repositories.Identification of baselines.Approved and controlled documents (baselines) for: unit specifications, unit design, system requirements, system design, interface specifications and base products.

B.CM.2

Configuration management plan: Definition of a Change Control Board (CCB) process or similar, identification of required baselines, required baseline content, 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.

B.DES.3 System design guidelines: including RAMS related aspects.Unit design guidelines: including RAMS related aspects.

B.DES.4 Updated unit design documentation: unit design specifications, systems/network topology with software components, interface specifications, and functional descriptions.

B.INT.1

Plan for integration of systems into unit: The responsibilities of the different organizations, dependencies among systems, sequence for integration, integration environment, tests and integration readiness criteria.Plan for integration of sub-systems and components into systems (when required): Dependencies among systems, sub-systems and components, sequence for integration, integration environment, tests and integration readiness criteria.

B.INT.2

Interface overview/matrix information with assigned responsibilities.Agreed inter-system interface specifications containing: protocol selected, definition of commands, messages, data and alarms to be communicated and specifications of message formats.Interface definition and verification status.

B.PM.1

Schedule.Project plan: WBS, technical attributes used for estimating, effort and costs estimates, deliverables and milestones, configuration management plan.Resource allocation.

B.PM.2 Master plan.Project plans.

B.RAMS.1RAMS hazard and risk list showing consideration of software risks.Defined risk identification and analysis methods.Relevant risks are communicated to other roles.

B.RAMS.2 RAMS hazard and risk mitigation list showing mitigation actions for software risks.Relevant mitigation actions are communicated to other roles

B.VV.1

Verification strategy: which part to verify: unit, system, sub-system, component, module, design documents.Method specification documents, etc.: which methods to use for this verification: testing, inspection, code analysis, simulation, prototyping, peer review techniques, quality criteria and targets, which test types to use: functional, performance, regression, user interface, negative, what environment to use for verification and identification of the test stages (e.g. sea trials, integration tests, commissioning, FAT, internal testing, component testing) to be used for the verification and the schedule for those tests.Validation strategy: products to be validated, validation criteria, operational scenarios, methods and environments.

B.VV.2 Documented design review records addressing: requirements verification, design rules and verification of uncertainties.

B.VV.3 Minutes from review: review results considering consistency of interface/function/component/scenarios.

Table 2 Acceptance criteria for assessments of system integrator (Continued)



DNV GL AS

Cha

pter

2

Sec

tion

6

B.VV.4Interface specification reviews addressing at least: consistency between input and output signals, frequency and scan rates, deadlocks, propagation of failures from one part to another, engineering units, network domination.

B.VV.5 Validation records including: workshop minutes, user representative’s participation and comments and agreed action lists.

C.INT.1 Integration readiness criteria fulfilled per component and per system.

C.PQA.1

Agreed maintenance procedures: Procedures for general system maintenance activities and procedures for software update, backup and roll-back.Agreed problem resolution procedures: Procedures for receiving, recording, resolving, tracking problems (punches) and modification requests.

C.VV.9 Test procedure: covering the system and its interfaces.Test report.

D.CM.1

Defined software configuration management: definition of Change Control Board (CCB), change request forms, description of change process for software, impact analysis, Identification of items to be controlled, configuration management tool, including, issue, change, version and configuration tracking tool and prevents unauthorised changes.Modification records justifying changes:configuration records,version histories,release notes,change orders.

D.CM.2 Overall release note for the systems in ISDS scope.

D.CM.3 Approved configuration management plan.Records of transmission of software, documentation and data, or responsibility thereof.

D.RAMS.1 RAMS compliance analysis information.

D.RAMS.2 Calculations of RAM values for relevant systems and the unit.RAM data.

D.RAMS.3 Security audit records.

D.VV.4 Integration test procedures covering system interfaces and inter-system functionality.Integration test reports.

X.CM.1

Change requests/orders.Version histories for baselines.Changes to: unit requirements, unit design, system requirements, system design, software design, interface specifications and software.Configuration records from document or software repositories.

X.PM.1

Master schedule.Master plan (updated).Project status report.Project action list.Minutes of review meetings.Progress report.

X.PM.2Minutes of joint milestone meetings.ISDS compliance status.Action plans.



X.REQ.1

Up to date traceability information: from owner to system requirements, from system requirements to functional specifications (where applicable), from system requirements to base-product and configuration data (where applicable), from functional specifications to sub-system/component specifications and from requirements to test procedures (when the test procedures are available).Completeness and consistency review records of the traceability information.

X.RISK.1Project risk management plan.Updated internal risk register (per organization).Updated project risk register (jointly managed).

X.RISK.2 Updated internal risk register: risk list, mitigation actions and follow-up records (per organization).Updated project risk register: risk list, mitigation actions and follow-up records (jointly managed).




DNV GL AS

Cha

pter

2

Sec

tion

6

1.3 Documentation criteria for the system integrator1.3.1 The table below lists all documents to be sent to the independent verifier and in which activities the independent verifier is going to use the different documents.



X.VV.2 Existence of relevant test procedures.


Reference DocumentsA.CM.1 No documentation to be submitted to DNV GL for review.A.DES.1 No documentation to be submitted to DNV GL for review.A.PM.1 No documentation to be submitted to DNV GL for review.A.PQA.2 No documentation to be submitted to DNV GL for review.

A.RAMS.1

List of regulatory requirements unit (FI):- reviewed in A.IV.2 at CL3- used in B.IV.4 and D.IV.3 at CL3.List of regulatory requirements system (FI) used in C.IV.3 at CL3.

A.RAMS.3Plan for handling of RAMS (FI):- reviewed in A.IV.2 at CL3- used in B.IV.4 at CL3.

A.REQ.2 Vessel specification (FI) reviewed in A.IV.1 at CL3.A.REQ.4 Specification (FI) reviewed in A.IV.1 at CL3.A.REQ.5 No documentation to be submitted to DNV GL for review.A.REQ.6 Traceability matrices (FI) used in A.IV.1 at CL3.A.RISK.2 No documentation to be submitted to DNV GL for review.A.VV.2 No documentation to be submitted to DNV GL for review.B.CM.1 No documentation to be submitted to DNV GL for review.B.CM.2 No documentation to be submitted to DNV GL for review.

B.DES.3 RAMS design guidelines and methods for the vessel (FI) used in B.IV.1 at CL3.RAMS design guidelines and methods for the system (FI) used in B.IV.1 at CL3.

B.DES.4

Interface description (FI) reviewed in B.IV.1 at CL3,Functional description (FI) reviewed in B.IV.1 at CL3,Block (topology) diagram (FI):- reviewed in B.IV.1 at CL3- used in B.IV.2 at CL2 and CL3.

B.INT.1Integration plan (FI):- reviewed in B.IV.2 at CL2 and CL3- used in C.IV.1 at CL3.

B.INT.2 Interface description (FI) used in B.IV.2 at CL2 and CL3.B.PM.1 No documentation to be submitted to DNV GL for review.B.PM.2 No documentation to be submitted to DNV GL for review.B.RAMS.1 RAMS risk register (FI) and RAMS risk analysis documentation (FI) reviewed in B.IV.3 at CL3.

B.RAMS.2RAMS risk register (FI):- reviewed in B.IV.3 at CL3- used in C.IV.3 and D.IV.3 at CL3.

B.VV.1Verification and validation strategy (FI):- reviewed in B.IV.2, at CL2 and CL3- used in C.IV.1 at CL3, and C.IV.2 and D.IV.1 at CL2 and CL3.

B.VV.2 No documentation to be submitted to DNV GL for review.




DNV GL AS

Cha

pter

2

Sec

tion

6

B.VV.3 No documentation to be submitted to DNV GL for review.B.VV.4 No documentation to be submitted to DNV GL for review.B.VV.5 No documentation to be submitted to DNV GL for review.C.INT.1 No documentation to be submitted to DNV GL for review.C.PQA.1 No documentation to be submitted to DNV GL for review.

C.VV.9 Independent test procedure (FI) and Independent test report (FI) reviewed in D.IV.1 at CL3.Independent test report (FI) used in D.IV.2 at CL3.

D.CM.1 No documentation to be submitted to DNV GL for review.D.CM.2 No documentation to be submitted to DNV GL for review.D.CM.3 No documentation to be submitted to DNV GL for review.D.RAMS.1 RAMS compliance report (FI) reviewed in D.IV.3 at CL3.

D.RAMS.2 RAM report (FI) unit reviewed in D.IV.3.RAM report (FI) system used in D.IV.3.

D.RAMS.3 Security audit report (FI) used in D.IV.3 at CL3.

D.VV.4 Test procedure (FI) and Test report (FI) reviewed in D.IV.1 at CL2 and CL3.Test report (FI) used in D.IV.2 at CL3.

X.CM.1 No documentation to be submitted to DNV GL for review.X.PM.1 No documentation to be submitted to DNV GL for review.X.PM.2 No documentation to be submitted to DNV GL for review.X.PQA.2 No documentation to be submitted to DNV GL for review.X.PQA.5 Corrective action plan (AP) reviewed and approved in X.IV.1.X.REQ.1 Traceability matrices (FI) used in B.IV.1 and C.IV.1 at CL3, and in C.IV.2 at CL2 and CL3.X.RISK.1 No documentation to be submitted to DNV GL for review.X.RISK.2 No documentation to be submitted to DNV GL for review.X.VV.2 No documentation to be submitted to DNV GL for review.

Table 3 Documents required for review (Continued)

Reference Documents


DNV GL AS

Cha

pter

2

Sec

tion

7
SECTION 7 ISDS REQUIREMENTS FOR SUPPLIERS
1 Supplier requirements

1.1 Requirements under the supplier’s responsibility1.1.1 The following Table 1 lists the requirements under the supplier’s responsibility. See also Table 2 for the associated acceptance criteria and Table 3 for documentation criteria.

1.1.2 The supplier shall also contribute to requirements that are under the responsibility of other roles.


Table 1 Requirements under supplier’s responsibility

Reference Required activity Contributor(s) Phase CLB.ACQ.1 Select COTS products based on defined criteria Engineering CL2B.ACQ.2 Establish contract with sub-suppliers Engineering CL1B.CM.1 Establish baselines of requirements and design Owner Engineering CL1B.CM.2 Establish and implement configuration management Owner Engineering CL1B.DES.1 Design the system System integrator Engineering CL1B.DES.2 Design each software component Engineering CL2B.DES.3 Use established design guidelines and methods Engineering CL2

B.DES.5 Define obsolescence strategy System integrator,Supplier Engineering CL2

B.INT.1 Define integration plan Supplier Engineering CL2B.PM.1 Establish the project plan for each organisation Owner Engineering CL1B.PQA.1 Define procedures (supplier) Engineering CL1B.RAMS.1 Identify software-related RAMS risks and priorities Owner Engineering CL2B.RAMS.2 Identify RAMS risk mitigation actions Engineering CL2

B.RAMS.3 Consider software failure modes in safety analysis activities Engineering CL1

B.RAMS.4 Develop the RAMS plan for the system System integrator Engineering CL2

B.REQ.1 Submit proposals to system integrator with compliance status Engineering CL1

B.REQ.2 Refine system requirements into software component requirements Engineering CL2

B.REQ.3 Detail operational scenarios Engineering CL2B.VV.1 Define verification and validation strategy Owner Engineering CL1

B.VV.2 Review the design with respect to requirements and design rules Owner Engineering CL2

B.VV.3 Review consistency between design and operational scenarios Engineering CL2

B.VV.4 Review interface specifications Engineering CL2C.ACQ.1 Accept deliverables Construction CL1C.ACQ.2 Ensure transition and integration of the delivered product Construction CL1

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

C.IMP.2 Develop support documentation Owner,System integrator Construction CL2

C.IMP.3 Perform software component testing Construction CL1

C.IMP.4 Use established software implementation guidelines and methods Construction CL2

C.INT.1 Check readiness status of systems and components before integration Construction CL2

C.RAMS.1 Demonstrate achievement of system RAMS requirements Construction CL2


DNV GL AS

Cha

pter

2

Sec

tion

7
1.2 Acceptance criteria for supplier assessments1.2.1 The following Table 2 lists the acceptance criteria for assessments of the supplier. The following evidence shall be presented to the independent verifier during assessments to document that the required activities have been performed.
C.RAMS.2 Evaluate software systems and software components against RAM objectives Construction CL3

C.RAMS.3 Prepare a plan for system maintenance during operation Owner Construction CL1C.VV.1 Perform peer-reviews of software Construction CL1C.VV.2 Review software parameterisation data System integrator Construction CL1C.VV.3 Perform internal testing System integrator Construction CL2C.VV.4 Perform high integrity internal testing System integrator Construction CL3C.VV.5 Perform code analysis on new and modified software Construction CL2C.VV.6 Analyse verification results with respect to targets System integrator Construction CL2C.VV.7 Qualify reused software Construction CL1

C.VV.8 Perform Factory Acceptance Tests (FAT) Owner,System integrator Construction CL1

E.ACQ.1 Manage and monitor obsolescence Operation CL2E.CM.1 Manage change requests during operation Operation CL1E.RAMS.3 Analyse RAMS data and address discrepancies Operation CL2E.RAMS.4 Perform RAMS impact analysis of changes Operation CL2X.ACQ.1 Monitor contract execution and changes Several CL1X.ACQ.2 Review intermediate deliverables Several CL2X.CM.1 Track and control changes to the baselines Several CL1X.CM.2 Establish a release note for the delivered system Several CL1X.DES.1 Update the base-product design documentation Several CL2

X.PM.1 Monitor project status against plan Owner,Supplier Several CL1

X.PQA.3 Control procedures (supplier) Several CL1X.PQA.6 Follow-up of ISDS assessment gaps (supplier) Several CL1X.REQ.1 Maintain requirements traceability information Several CL2

X.RISK.1 Track, review and update risks Owner,Supplier Several CL1

X.RISK.2 Decide, implement and track risk mitigation actions to closure Owner Several CL2

X.VV.1 Perform verification and validation on added and modified software components Owner Several CL1

X.VV.2 Detail procedures for testing Several CL1

Table 1 Requirements under supplier’s responsibility (Continued)



DNV GL AS

Cha

pter

2

Sec

tion

7
Table 2 Acceptance criteria for assessments of supplier


B.ACQ.1 COTS product selection procedure: obsolescence management.COTS product selection matrix: rationale for selection, selection criteria, evaluations and selection.

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

B.CM.1

Baseline repositories.Identification of baselines.Approved and controlled documents (baselines) for: unit specifications, unit design, system requirements, system design, interface specifications and base products.

B.CM.2

Configuration management plan: Definition of a Change Control Board (CCB) process or similar, identification of required baselines, required baseline content, 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.

B.DES.1Design for system (hardware & software): functional description, user interface descriptions, block/topology diagrams with software components, external interface descriptions and internal interface descriptions.

B.DES.2

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

B.DES.3 System design guidelines: including RAMS related aspects.Unit design guidelines: including RAMS related aspects.

B.DES.5Obsolescence management plan: Authorised vendor list, Spare parts list (hardware & software), stock, alternate spare parts list, management of intellectual property. Obsolescence criteria for software.Manufacturer preferred equipment list.

B.INT.1

Plan for integration of systems into unit: The responsibilities of the different organizations, dependencies among systems, sequence for integration, integration environment, tests and integration readiness criteria.Plan for integration of sub-systems and components into systems (when required): Dependencies among systems, sub-systems and components, sequence for integration, integration environment, tests and integration readiness criteria.

B.PM.1

Schedule.Project plan: WBS, technical attributes used for estimating, effort and costs estimates, deliverables and milestones, configuration management plan.Resource allocation.

B.PQA.1

A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, Clear roles and responsibilities and Defined ways of interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others).

B.RAMS.1RAMS hazard and risk list showing consideration of software risks.Defined risk identification and analysis methods.Relevant risks are communicated to other roles.

B.RAMS.2 RAMS hazard and risk mitigation list showing mitigation actions for software risks.Relevant mitigation actions are communicated to other roles

B.RAMS.3 Safety analysis showing consideration of software failure modes.

B.RAMS.4

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

B.REQ.1Submitted technical proposal for the system: system breakdown, alternatives and options, description of customisation or parameterisation of existing products (including software), requirements compliance matrix and software lifecycle information (including licensing, ownership and obsolescence).

B.REQ.2 Refined component requirements and specification.Requirement allocation matrix.


DNV GL AS

Cha

pter

2

Sec

tion

7

B.REQ.3System/component behaviour and interaction specification and descriptions: use cases, sequences (including signal usage), state diagrams, interlocks, degraded sequences, performance targets and constraints and limitations.

B.VV.1

Verification strategy: which part to verify: unit, system, sub-system, component, module, design documents.Method specification documents, etc.: which methods to use for this verification: testing, inspection, code analysis, simulation, prototyping, peer review techniques, quality criteria and targets, which test types to use: functional, performance, regression, user interface, negative, what environment to use for verification and identification of the test stages (e.g. sea trials, integration tests, commissioning, FAT, internal testing, component testing) to be used for the verification and the schedule for those tests.Validation strategy: products to be validated, validation criteria, operational scenarios, methods and environments.

B.VV.2 Documented design review records addressing: requirements verification, design rules and verification of uncertainties.

B.VV.3 Minutes from review: review results considering consistency of interface/function/component/scenarios.

B.VV.4Interface specification reviews addressing at least: consistency between input and output signals, frequency and scan rates, deadlocks, propagation of failures from one part to another, engineering units, network domination.

C.ACQ.1Component acceptance data: acceptance criteria, component acceptance (FAT, SAT) test procedures, component acceptance test records, component acceptance issue and problems list and component acceptance coverage measurements (requirements, structural).

C.ACQ.2

Supplier agreement on: list of deliverables, review and approval plans and support and maintenance agreement.Product documentation.Operation manual.Configuration information.

C.IMP.1

Developed component release note.Commented software source code.Parameters and configuration files.I/O List.Development environment configuration.

C.IMP.2

System and component support documentation: data sheets, user manuals, administration manuals, operating and maintenance procedures, training material and FAQs, known defects and troubleshooting guides.Review records for the support documentation.

C.IMP.3 Software test log: list of defects, date of test, tester, test scope and pass or fail.Software defect list.

C.IMP.4 Software guidelines/standards/rules/checklists/automated checks.Review records.

C.INT.1 Integration readiness criteria fulfilled per component and per system.C.RAMS.1 RAMS compliance analysis information.C.RAMS.2 RAM report: Calculations of RAM values for designated systems and RAM data.

C.RAMS.3Maintenance management plan: configuration items, rules for operation/maintenance, backup and restore procedures, expected maintenance activities, expected software update, migration and retirement activities, schedules and tailored procedures for maintenance in operation.

C.VV.1

Peer review methodology description.Peer review schedule.Peer review records.Peer review check lists.

C.VV.2 Parameter list review report: name, value, tolerance, function.

C.VV.3 Test procedures.Test reports.

C.VV.4 Test proceduresTest reports

C.VV.5 Software code verification: peer review reports, code analysis reports and code rule set.

C.VV.6 Verification result evaluation: result analyses, punch lists, action lists, defect correction and focus on defect prone software.

Table 2 Acceptance criteria for assessments of supplier (Continued)



DNV GL AS

Cha

pter

2

Sec

tion

7

C.VV.7 Software qualification report: reused software component list, qualification method for each reused software component and qualification data.

C.VV.8System FAT procedure: coverage of requirements, functionality, performance, RAMS (when applicable), integration testing, hardware/software integration, interfaces and degraded modes.System FAT report: consistent with procedure, deviations identified and coverage measured.

E.ACQ.1Obsolescence strategy document.Obsolescence management plan: Authorised vendor list, Spare parts list (HW & compatible SW), Alternate spare parts list and Management of intellectual property.

E.CM.1

Change requestsImpact analysisChange ordersWork ordersProblem reportsRelease notesMaintenance logs

E.RAMS.3 RAMS analysis.E.RAMS.4 Impact analysis showing RAMS evaluation.

X.ACQ.1

Sub-supplier progress review schedule.Sub-supplier progress review reports.Sub-supplier project control records.Sub-supplier quality control records.

X.ACQ.2 Supplier agreement: list of deliverables and review and approval plans.Review records/minutes.

X.CM.1

Change requests/orders.Version histories for baselines.Changes to: unit requirements, unit design, system requirements, system design, software design, interface specifications and software.Configuration records from document or software repositories.

X.CM.2 Component release note: including list of changes to previous version of component.

X.DES.1 Base product design description.Revision information for updated base-product components.

X.PM.1

Master schedule.Master plan (updated).Project status report.Project action list.Minutes of review meetings.Progress report.



X.REQ.1

Up to date traceability information: from owner to system requirements, from system requirements to functional specifications (where applicable), from system requirements to base-product and configuration data (where applicable), from functional specifications to sub-system/component specifications and from requirements to test procedures (when the test procedures are available).Completeness and consistency review records of the traceability information.

X.RISK.1Project risk management plan.Updated internal risk register (per organization).Updated project risk register (jointly managed).

X.RISK.2 Updated internal risk register: risk list, mitigation actions and follow-up records (per organization).Updated project risk register: risk list, mitigation actions and follow-up records (jointly managed).

X.VV.1 Test procedure: consistent with change or upgrade scope.Test report: consistent with test procedure.

X.VV.2 Existence of relevant test procedures.

Table 2 Acceptance criteria for assessments of supplier (Continued)



DNV GL AS

Cha

pter

2

Sec

tion

7
1.3 Documentation criteria for the supplier1.3.1 The table below lists all documents to be sent to the independent verifier and in which activities the independent verifier is going to use the different documents.



Reference DocumentsB.ACQ.1 No documentation to be submitted to DNV GL for review.B.ACQ.2 No documentation to be submitted to DNV GL for review.B.CM.1 No documentation to be submitted to DNV GL for review.B.CM.2 No documentation to be submitted to DNV GL for review.

B.DES.1Interface description (FI),Functional description (FI) andBlock (topology) diagram (FI) reviewed in B.IV.1 at CL3.

B.DES.2 Software design description (FI) reviewed in B.IV.1 at CL3.

B.DES.3 RAMS design guidelines and methods for the vessel (FI) used in B.IV.1 at CL3.RAMS design guidelines and methods for the system (FI) used in B.IV.1 at CL3.

B.DES.5 No documentation to be submitted to DNV GL for review.

B.INT.1Integration plan (FI):- reviewed in B.IV.2 at CL2 and CL3- used in C.IV.1 at CL3.

B.PM.1 No documentation to be submitted to DNV GL for review.B.PQA.1 No documentation to be submitted to DNV GL for review.B.RAMS.1 RAMS risk register (FI) and RAMS risk analysis documentation (FI) reviewed in B.IV.3 at CL3.

B.RAMS.2RAMS risk register (FI):- reviewed in B.IV.3 at CL3- used in C.IV.3 and D.IV.3 at CL3.

B.RAMS.3 Safety assessment report (FI) used in C.IV.3 at CL3.

B.RAMS.4Plan for handling of RAMS (FI):- reviewed in B.IV.4 at CL3- used in C.IV.3 at CL3.

B.REQ.1 Specification (FI) used in B.IV.1 at CL3.B.REQ.2 Specifications (FI) used in B.IV.1 at CL3.B.REQ.3 Specifications (FI) used in B.IV.1 at CL3.

B.VV.1Verification and validation strategy (FI):- reviewed in B.IV.2, at CL2 and CL3- used in C.IV.1 at CL3, and C.IV.2 and D.IV.1 at CL2 and CL3.

B.VV.2 No documentation to be submitted to DNV GL for review.B.VV.3 No documentation to be submitted to DNV GL for review.B.VV.4 No documentation to be submitted to DNV GL for review.C.ACQ.1 No documentation to be submitted to DNV GL for review.C.ACQ.2 No documentation to be submitted to DNV GL for review.C.IMP.1 No documentation to be submitted to DNV GL for review.C.IMP.2 No documentation to be submitted to DNV GL for review.C.IMP.3 No documentation to be submitted to DNV GL for review.C.IMP.4 No documentation to be submitted to DNV GL for review.C.INT.1 No documentation to be submitted to DNV GL for review.C.RAMS.1 RAMS compliance report (FI) reviewed in C.IV.3 at CL3.C.RAMS.2 RAM report (FI) reviewed in C.IV.3.


DNV GL AS

Cha

pter

2

Sec

tion

7

C.RAMS.3 No documentation to be submitted to DNV GL for review.C.VV.1 Software peer review records (FI) used in C.IV.1 at CL3.C.VV.2 No documentation to be submitted to DNV GL for review.C.VV.3 No documentation to be submitted to DNV GL for review.

C.VV.4 Test procedure at manufacturer (FI) andTest report at manufacturer (FI) used in C.IV.1 at CL3.

C.VV.5 Software code analysis record (FI) used in C.IV.1 at CL3.C.VV.6 Verification analysis report (FI) reviewed in C.IV.1 at CL3.C.VV.7 No documentation to be submitted to DNV GL for review.

C.VV.8System FAT procedure (FI) and System FAT report (FI):- reviewed in C.IV.2 at CL2 and CL3- used in C.IV.1 at CL3.

E.ACQ.1 No documentation to be submitted to DNV GL for review.E.CM.1 No documentation to be submitted to DNV GL for review.E.RAMS.3 No documentation to be submitted to DNV GL for review.E.RAMS.4 No documentation to be submitted to DNV GL for review.X.ACQ.1 No documentation to be submitted to DNV GL for review.X.ACQ.2 No documentation to be submitted to DNV GL for review.X.CM.1 No documentation to be submitted to DNV GL for review.X.CM.2 No documentation to be submitted to DNV GL for review.X.DES.1 No documentation to be submitted to DNV GL for review.X.PM.1 No documentation to be submitted to DNV GL for review.X.PQA.3 No documentation to be submitted to DNV GL for review.X.PQA.6 Corrective action plan (AP) reviewed and approved in X.IV.1.X.REQ.1 Traceability matrices (FI) used in B.IV.1 and C.IV.1 at CL3, and in C.IV.2 at CL2 and CL3.X.RISK.1 No documentation to be submitted to DNV GL for review.X.RISK.2 No documentation to be submitted to DNV GL for review.X.VV.1 Test procedure (FI) and Test report (FI) used in E.IV.1 at CL3.X.VV.2 No documentation to be submitted to DNV GL for review.

Table 3 Documents required for review (Continued)

Reference Documents


DNV GL AS

Cha

pter

2

Sec

tion

8
SECTION 8 ISDS REQUIREMENTS FOR THE INDEPENDENT VERIFIER
1 Independent verifier requirements

1.1 Activities for which the independent verifier is responsible1.1.1 The following table describes the activities that shall be performed by the independent verifier.

1.1.2 As part of the classification process for the ISDS notation, DNV GL shall take the role of independent verifier.

1.1.3 Most documents are reviewed for information (FI), only the corrective action plan is reviewed for approval (AP).

1.1.4 Document types listed in the table are further described in DNVGL-CG-0168 and a description of the content in an ISDS context is given in the assessment criteria for each of the referenced activities.


DNV GL AS

Chapter 2 Section 8

Offshore standard, D

NVG

L-OS-D

203 – Edition July 2015

Integrated software dependent system

s (ISD

S)

DN

V G

L A

S

Table 1 Requirements under independent verifier’s responsibility

utVerification

Outputcceptance Criteria Activity Ref.

3 systems are designed work together without onsistencieser systems are not

ving a compromising pact on the CL3 tem(s).

A.REQ.1A.REQ.2A.REQ.3A.REQ.4A.REQ.6A.RISK.3

- Review comments on Z040 and Z100 document types

mpleteness:

Listing of, laws, standards, and rules that apply regarding safetyPlan showing objectives, methods, tools, and procedures to be used. Schedule of RAMS activities. RAM data to be collected (CL3)RAMS requirementsConfidence levels

CL2: qualitative uirements CL3: quantitative uirements are required.

A.RAMS.1A.RAMS.2A.RAMS.3A.RISK.3

- Review comments on all I300 input document types

ID CL Activity Description Guidance NoteInp

Document type A

A.IV.1 3 Review technical specification

The technical specification of the unit shall be reviewed to verify that CL3 systems are working together without inconsistencies. Interfaces to other systems are also addressed in order to see that there are no compromising impacts on the CL3 systems.

None Z050-Design Philosophy(A.REQ.1)Z040-Vessel specification(A.REQ.2 & A.REQ.3)Z100-Specification (A.REQ.4)Z290-Record-Traceability matrices (A.REQ.6)Z040-Vessel specification-ISDS Confidence levels (A.RISK.3)

— CLto inc

— Othhaimsys

A.IV.2 3 Review the RAMS approach for the unit

Review of RAMS requirements, the allocation to systems and the plan for performing RAM activities to ensure completeness and consistency.

None I300-RAMS documentation for the vessel-List of regulatory requirements (A.RAMS.1)I300-RAMS documentation for the vessel-List of RAM requirements for the vessel (A.RAMS.2)I300-RAMS documentation for the vessel-Plan for handling of RAMS (A.RAMS.3)Z040-Vessel specification-ISDS Confidence levels (A.RISK.3)

— Co

a)

b)

c)

d)

e)f)

— Forreq

— Forreq

Chapter 2 Section 8


NVG

L-OS-D



s (ISD

S)

DN

V G

L A

S

nsistency of functional sign specification and tware design cification agreed upon

supplier and yard against ssel specification, nsistency with RAMS jectives.

B.DES.1B.DES.2B.DES.3B.DES.4B.REQ.1B.REQ.2B.REQ.3X.REQ.1

- Review comments on I020, I030, I220, I290 and Z060 document types

mpleteness of rification intended to be ieved (functions,

erfaces)mpleteness of validation ended to be achieved quirements, scenarios)mpleteness of integration n with regards to tware

B.DES.4B.INT.1B.INT.2B.VV.1

- Review comments on I140 and I210 document types

Table 1 Requirements under independent verifier’s responsibility (Continued)

utVerification


B.IV.1 3 Review technical specification and design

Review of functional design specification and software design specification agreed upon by supplier and yard against vessel specification, as well as other criteria and RAMS objectives.

None Z100-Specification (B.REQ.1, B.REQ.2, B.REQ.3)Z060-Functional description (B.DES.4).I020-Functional description (B.DES.1) I030-Block (topology) diagram (B.DES.1, B.DES.4)I220-Interface description-Inter-system interface specification (B.DES.4)I220-Interface description-Intra-system interface specification (B.DES.1)I290-Software design description (B.DES.2)I300-RAMS documentation for the vessel-RAMS design guidelines and methods (B.DES.3)I310-RAMS documentation for the system-RAMS design guidelines and methods (B.DES.3)Z290-Record-Traceability matrices (X.REQ.1)

— Codesofspebyve

— Coob

B.IV.2 2 Review integration, verification and validation strategy

Review verification/validation/integration strategy against technical specification for completeness of verification intended to be achieved.

None I140-Verification and Validation Strategy (B.VV.1),I210-Integration plan- (B.INT.1),I220-Interface description –inter system interface specification (B.INT.2)I030-Block (topology) diagram (B.DES.4)

— Coveachint

— Coint(re

— Coplasof


Document type A

Chapter 2 Section 8


NVG

L-OS-D



s (ISD

S)

DN

V G

L A

S

nsistency of the scope ection for risk ntification, nsistency between unit d system level risk alysis, nsideration of the tware failures modes, nsideration of the rdware-induced software lure modes.

B.RAMS.1B.RAMS.2

- Review comments on I300 and I310 document types

mpleteness:

Listing of, laws, standards, and rules that apply regarding safetyPlan showing objectives, methods, tools, and procedures to be used. Schedule of RAMS activities. RAM data to be collected (CL3) RAMS requirements.

CL2: qualitative uirements are good

ough CL3: quantitative uirements are required.

A.RAMS.1A.RAMS.2A.RAMS.3A.RISK.3B.RAMS.4

- Review comments on the I310 document type


utVerification


B.IV.3 3 Review and comment on the software part of the safety analysis for critical functions in scope of the ISDS

Review the software-related RAMS risks and priorities, and the resulting software-related RAMS mitigation actions.

Special methods for RAMS risk analysis and mitigation are used, such as: HAZID, HAZOP, FMEAs, and FMECAs.

I300-RAMS documentation for the vessel - RAMS risk register (B.RAMS.1 & B.RAMS.2)I310-RAMS documentation for the system - RAMS risk register (B.RAMS.1 & B.RAMS.2)I300- RAMS documentation for the vessel-RAMS risk analysis documentation (B.RAMS.1)I310- RAMS documentation for the system-RAMS risk analysis documentation (B.RAMS.1)

— Coselide

— Coanan

— Cosof

— Cohafai

B.IV.4 3 Review the RAMS approach for the system

Review of RAMS requirements for the system, and the plan for performing RAM activities to ensure completeness and consistency.

None I300-RAMS documentation for the vessel-List of regulatory requirements (A.RAMS.1)I300-RAMS documentation for the vessel-Plan for handling of RAMS(A.RAMS.3)I310-RAMS documentation for the system-Listing of RAM requirements for the system (A.RAMS.2)I310-RAMS documentation for the system-Plan for handling of RAMS (B.RAMS.4)Z040-Vessel specification-ISDS Confidence levels (A.RISK.3)

— Co

a)

b)

c)

d)

e)

— Forreqen

— Forreq


Document type A

Chapter 2 Section 8


NVG

L-OS-D



s (ISD

S)

DN

V G

L A

S

nned verification ivities have been cessfully completed and blems resolved.

rification and validation is track as expected by the ategies.

B.INT.1B.VV.1C.VV.1C.VV.4C.VV.5C.VV.6C.VV.8X.REQ.1

- Review comments on the Z241 document type

nsistency between rification strategy and t proceduresmpleteness of test cedures (functions, erfaces, design)mpleteness of test casesst reports reflect the ual test results with ss/fail judgements and viations from procedures.

B.VV.1C.VV.8X.REQ.1

- Review comments on Z120 and Z130 document types


utVerification


C.IV.1 3 Review the verification activities in the construction phase

Evaluate how completely the verification strategy has been executed in the construction phase (through the FAT). Determine whether or not all required testing, peer reviews, and other verification activities have been conducted. Confirm that any issues or problems identified during these activities are being tracked to closure.

Records of V&V activities (e.g., test reports, peer review reports) should be matched to configuration items. Traceability matrices should be checked to see that requirements are included in test plans or other V&V activities.

Z290-Record-Software peer review (C.VV.1)Z120-Test procedure at manufacturer (C.VV.4)Z130 -Report from test at manufacturer (C.VV.4)Z290-Record -Software code analysis (C.VV.5)Z120-Test procedure at manufacturer-System FAT procedure (C.VV.8)Z130 -Report from test at manufacturer-System FAT report(C.VV.8)Z241-Measurement report- Verification analysis report (C.VV.6)I210-Integration plan (B.INT.1)I140-Software quality plan - Verification and validation strategy (B.VV.1)Z290-Record-Traceability matrices (X.REQ.1)

— Plaactsucpro

— Veonstr

C.IV.2 2 Review and witness the FAT

Review and contribute to the FAT procedure. Witness the FAT execution.

None Z120-Test procedure at manufacturer-System FAT procedure (C.VV.8)Z130 -Report from test at manufacturer–System FAT report(C.VV.8)I140-Software quality plan-Verification and validation strategy (B.VV.1)Z290-Record-Traceability matrices (X.REQ.1)

— Covetes

— Coproint

— Co— Te

actpade


Document type A

Chapter 2 Section 8


NVG

L-OS-D



s (ISD

S)

DN

V G

L A

S

mpleteness of content:

RAM data and RAM calculationsRAMS compliance report

ks to RAM and software ety are under control.

A.RAMS.1A.RAMS.2B.RAMS.2B.RAMS.3B.RAMS.4C.RAMS.1C.RAMS.2

- Review comments on I310-RAMS compliance report and I310-RAM report document types


utVerification


C.IV.3 3 Review RAMS arguments and evidence for the system

The RAMS arguments and reviews shall be reviewed to ensure completeness and compared with the RAMS requirements for the system.

None I310-RAMS documentation for the system-RAMS compliance report (C.RAMS.1)I310-RAMS documentation for the system -RAM report (C.RAMS.2)I310-RAMS documentation for the system-List of RAM requirements (A.RAMS.2)I310-RAMS documentation for the system-List of regulatory requirements (A.RAMS.1)I310-RAMS documentation for the system - RAMS risk register ( B.RAMS.2)I310-RAMS documentation for the system -Safety assessment report (B.RAMS.3)I310-RAMS documentation for the system-Plan for handling of RAMS (B.RAMS.4)

— Co

a)

b)

— Rissaf


Document type A

Chapter 2 Section 8


NVG

L-OS-D



s (ISD

S)

DN

V G

L A

S

nsistency between rification strategy and t proceduresmpleteness of test cedures (functions, erfaces, design)mpleteness of test casesnsistent with RAMS jectivesst reports reflect the ual test results with ss/fail judgements and viations from procedures.

B.VV.1C.VV.9D.VV.1D.VV.2D.VV.4

-Review comments on Z140 and Z150 document types

nned verification and lidation activities have en successfully

pleted and problems olved.rification and validation ategies have achieved ir objectives.MS objectives are met.

C.VV.9D.VV.1D.VV.2D.VV.3D.VV.4

- Review comments on the Z241 document type.


utVerification


D.IV.1 2 Review and witness the Commissioning tests

Review and contribute to the commissioning tests. Witness the commissioning execution.

None I140-Software quality plan - Verification and validation strategy (B.VV.1)Z140-Test procedure for quay and sea trial (D.VV.1, D.VV.2)Z150-Report from quay and sea trials (D.VV.1, D.VV.2)Z140-Test procedure for quay and sea trial-Integration test procedure (D.VV.4)Z150-Report from quay and sea trials-Integration test report (D.VV.4)Z140-Test procedure for quay and sea trial-Independent test procedure, if at CL3 (C.VV.9)Z150-Report from quay and sea trials-Independent test report, if at CL3 (C.VV.9)

— Covetes

— Coproint

— Co— Co

ob— Te

actpade

D.IV.2 3 Review commissioning test results

Review and analyse the results of all tests activities done by the system integrator and owner.

This activity focuses on the review of activities performed after C.IV.1 activity.

Z150-Report from quay and sea trials (D.VV.1, D.VV.2)Z150-Report from quay and sea trials-Integration test report (D.VV.4)Z150-Report from quay and sea trials-Independent test report(C.VV.9)Z241-Measurements report-Verification analysis report (D.VV.3)

— Plavabecomres

— Vestrthe

— RA


Document type A

Chapter 2 Section 8


NVG

L-OS-D



s (ISD

S)

DN

V G

L A

S

mpleteness of content of orts

Calculations of RAM values for designated systemsRAMS compliance report

CL2 systems: alitative RAMS are good ough CL3 systems:

alitative RAMS are uiredks To RAM and Software fety are under control.curity audit has been rformed.

A.RAMS.1A.RAMS.2B.RAMS.2D.RAMS.1D.RAMS.2D.RAMS.3

- Review comments on I300-RAMS compliance report and I300-RAM report document types

mpleteness of test cedures (impacted ctions, impacted uirements, impacted narios)nsistent with RAMS jectives.

E.VV.1E.VV.2X.VV.1

-Review comments on Z140 and Z150 document types


utVerification


D.IV.3 3 Review RAMS arguments and evidence for the unit

The RAMS arguments and reviews shall be reviewed to ensure completeness and compared with the RAMS requirements for the unit.

None I300-RAMS documentation for the vessel-List of regulatory requirements (A.RAMS.1)I300-RAMS documentation for the vessel-List of RAM requirements (A.RAMS.2)I300-RAMS documentation for the vessel-RAMS risk register (B.RAMS.2)I300-RAMS documentation for the vessel-RAMS compliance report (D.RAMS.1)I300-RAMS documentation for the vessel-RAM report (D.RAMS.2)I310-RAMS documentation for the system-RAM report (D.RAMS.2)I300-RAMS documentation for the vessel-Security audit report (D.RAMS.3)

— Corep

a)

b)

— Forquen

— Forqureq

— RisSa

— Sepe

E.IV.1 3 Witness upgrade commissioning tests

Review and contribute to the upgrade tests. Witness the test execution.

None Z140-Test procedure for quay and sea trial (E.VV.1, E.VV.2)Z150-Report from quay and sea trials (E.VV.1, E.VV.2)Z120-Test procedure at manufacturer (X.VV.1)Z130 -Report from test at manufacturer (X.VV.1)

— Coprofunreqsce

— Coob


Document type A

Chapter 2 Section 8


NVG

L-OS-D



s (ISD

S)

DN

V G

L A

S

mpliance to ISDS ivities and document uirements.

X.PQA.4X.PQA.5X.PQA.6

- Review comments on, and approval of the Q030 document type

IV activities

- Milestone report- Milestone presentation


utVerification


X.IV.1 1 Assess compliance to the ISDS standard

Processes shall be assessed to determine how they comply with the applicable ISDS standard.An activity status report is issued by the independent verifier for each milestone.

The corrective action plan shall be reviewed for approval. The implementation of the corrective actions shall be assessed in the subsequent phase.

This activity shall be performed in phases A to D and may be performed in phase E.For the E phase, see description of annual and renewal assessments in Ch.3 Sec.1 [3.2]-[3.3].

Each organization is responsible for its quality assurance. The quality assurance is responsible for ensuring the ISDS practices are achieved. The purpose of the independent verifier is not to bear responsibility for the organizations to perform their activities as intended, but to verify that such a target has been achieved.

Q030-Corrective action plan (X.PQA.4, X.PQA.5 and X.PQA.6)In addition relevant documentation is reviewed during the assessment.

— Coactreq

X.IV.2 1 Analyse and present the ISDS assessment and IV activities results for the phase

Gather the results from the various independent verification activities.

Analyse the results from the independent verifier activities and analyse the associated risks.Present the analysis result and associated risks at milestone meeting.This activity shall be performed in phases A to D.

The inputs to this activity are the results from all the IV activities performed in the phase.

All documents produced by IV activities.

-


Document type A

Cha

pter

3

Sec

tion

1
CHAPTER 3 CLASSIFICATION AND CERTIFICATION
SECTION 1 REQUIREMENTS

1 General

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

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

1.2 Organisation of Chapter 3This chapter identifies the specific documentation, certification and surveying requirements to be applied when using this standard for certification and classification purposes.

1.3 Classification principles1.3.1 The requirements of this standard shall only be applied for systems also subject to classification through 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 independent verifier (IV). Independent verifier activities are given in Ch.2 Sec.8.

1.4 Compliance of activities1.4.1 The requirements and corresponding acceptance criteria for all activities are listed in Ch.2 Sec.5 to Sec.7, and explained in detail in App.B.

1.4.2 Compliance of activities is verified through assessments carried out by the independent verifier. Each role shall be assessed by the independent verifier during the project. For the operation phase (E), assessments shall be performed regularly as defined in [3.1] to [3.3].

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

1.5 Approval of documents1.5.1 Based on the assessment performed by the independent verifier the assessed role shall present an action plan for approval, with specific and time bound actions for each non-conformity.

1.5.2 The independent verifier shall verify that the actions in the approved action plan are carried out according to the plan.

1.5.3 Documentation, other than the action plan, listed under the documentation criteria for each role in Ch.2 in this standard, shall be reviewed and commented by the independent verifier for information.

Table 1 DNV GL rules for classification - Offshore units

Reference Title DNVGL-RU-OU-0101 Offshore drilling and support units DNVGL-RU-OU-0102 Floating production, storage and loading unitsDNVGL-RU-OU-0103 Floating LNG/LPG production, storage and loading unitsDNVGL-RU-OU-0104 Self elevating units


DNV GL AS

Cha

pter

3

Sec

tion

1
1.6 Rating of compliance 1.6.1 DNV GL rates the different activities defined for each role in Ch.2 based on observations during assessments and document review, and list these as findings in an assessment report.
1.6.2 Three different types of ratings are used; High compliance, Medium compliance and Low compliance.

1.6.3 In the assessment report High compliance is represented by the colour green, Medium compliance by the colour orange and Low compliance by the colour red.

1.7 Reporting and milestone meetings1.7.1 Each assessed organisation will receive an assessment report with the major findings and status with regards 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 presentation of an ISDS status report which summarises the different organisation’s compliance with this standard as assessed by DNV GL.

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

2 Class notation

2.1 Designation2.1.1 Units built and tested in compliance with the requirements of this standard can be assigned the optional class notations for Integrated Software Dependent Systems (ISDS).

2.1.2 The notation can be assigned to a new-build when compliance is verified for phases A through D. To maintain the notation, compliance must be verified for phase E.

2.1.3 The designation for the class notation shows the notation name, which is ISDS, the systems included in the scope 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 identified in Ch.3 Sec.1 [2.2]. The 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 Scope2.2.1 Table 2 defines the systems and confidence levels recommended to include in the scope of the ISDS class notation.

2.2.2 Unless otherwise agreed by Owner and DNV GL, and specified by Owner, the scope and confidence levels defined in Table 2 applies for the ISDS class notation.


DNV GL AS

Cha

pter

3

Sec

tion

1

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

Function System that may be included in scope for ISDS

Typical sub-systems and components

DNV GL Standard reference*

CL Applicable for

Prevent escalation of abnormal conditions

Shutdown and Disconnection Systems (SDS)

— Network— Emergency Shutdown (ESD)

system, including:

— Input devices — Interfaces towards other

safety systems— Central control unit— Output actuators — Signal transfer lines — Power supply

— Process Shutdown (PSD) system

— Emergency Disconnect System (EDS)/Emergency Quick Disconnect (EQD) system

— Critical Alarm and Action Panel (CAAP)

— High Integrity Protection System (HIPS)

OS-A101

OS-E101

OS-D202

OS-E201

2 Drilling UnitWell Intervention UnitFPSOFSU

Fire & Gas System (F&G) — Network— Fire and gas detection system— Alarm and communication

system— Systems for automatic action

OS-D301 2 Drilling UnitWell Intervention UnitFPSOFSU

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— Network— Subsea Electronic

Modules (SEM)

OS-E101Table A2

3 Drilling UnitWell Intervention Unit


DNV GL AS

Cha

pter

3

Sec

tion

1

Drilling Drilling Control system (DCS)

— HVAC for driller’s cabin— Driller’s chair— Network— Zone management/anti-

collision system— Drilling data acquisition

system— Top drive— Drawwork— Rotary table

OS-E101 2 Drilling UnitWell Intervention Unit

Equipment Handling (EH) — Vertical pipe handler— Horizontal pipe handler— Fingerboard— Make up system— BOP handler

OS-E101Table A5


Heave Compensation and Tensioning System (HCTS)

— Marine riser tensioners, including re-coil system

— Active compensation systems— Heave motion compensators

OS-E101Table A3

2** Drilling UnitWell Intervention Unit

Drilling fluid circulation and cementing (MUD)

— Mud circulation system, high pressure

— Cementing system

OS-E101Table A6


Well Testing Systems (WT)

— Production shut down system— Blow down system

OS-E101Table A7


Work Over/Completion

Work Over Control System (WOCS)

— WOCS Container— WOCS’s chair— Data acquisition system— Network

OS-E101 2 Well Intervention Unit

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




CL Applicable for


DNV GL AS

Cha

pter

3

Sec

tion

1

Power generation and distribution

Power Management System (PMS)

— Power generation remote control and monitoring

— Power distribution remote control and monitoring

— Blackout prevention— Load dependent start/stop

including drilling drive and thruster drive power limitations.

— Engine change over— Load sharing in remote droop

mode (symmetric, asymmetric and manual)

— Blackout recovery— Network— Operator stations— Integration with system

specific PMS (drilling system PMS etc.), if applicable

OS-D201 2 All unit types

Power Plant Control System (PPC)

— Governor & synchronizing unit— Turbine controls— Protection relays— Thruster drives— Drilling drives— High voltage or low voltage

switchboard


Position keeping

Dynamic Positioning System (DP)

— DP control computer(s)— Independent joystick— Sensor systems— Display systems— Operator panels— Network— Positioning reference systems— Thruster control mode

selection system

DNV Rules for Ships Pt.6 Ch.7 and Pt.6 Ch.26

2 All unit types

POSMOOR system (POS) — POSMOOR control computer(s)

— Independent joystick— Sensor systems— Display systems— Operator panels— Network— Positioning reference systems— Active mooring equipment,

e.g. windlass and winch

OS-E301 2 Drilling UnitWell Intervention UnitFPSOFSU

Jacking Systems (JACK) — Hydraulic system— Control system— Drives

OS-D101 2 Drilling UnitWell Intervention UnitWind Installation Unit





CL Applicable for


DNV GL AS

Cha

pter

3

Sec

tion

1

2.2.3 Other systems than those listed in Table 3 may be granted the ISDS notation at CL1, 2 or 3 as specified below:

— Crane (CR)— Navigation Systems (NAV)— Process Control System (PCS)— Propulsion System (PROP) — Steering Systems (ST).

2.2.4 For each system a reference to the applicable DNV GL Rule or Offshore Standard (OS) is listed. The rules or standards identified will provide a more specific description of the systems. DNVGL-OS-D202 provides generic common requirements to, and is applicable for, all systems listed above.

3 In operation assessments

3.1 Objectives3.1.1 The ISDS class notation is maintained through demonstrating compliance to the requirements of this standard in the operation phase.

3.1.2 DNV GL, as the independent verifier, shall perform an annual assessment of the unit in operation to verify compliance.

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

3.1.4 Annual and renewal assessments for the ISDS notation should be carried out at the same time and interval as the periodical classification survey of the unit, and can also be carried out on the basis of documentation and evidence assessed onshore.

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

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

3.2 Scope of annual assessments3.2.1 The purpose of the annual assessment is to ensure that the confidence that has been built into the unit is actually maintained. The effective implementation and continuous maintenance of the activities required by this standard for phase E, operation, shall be assessed.

Control and monitoring

Integrated Control and Monitoring System (ICM)

— Sea water, fresh water, hot water, high pressure wash down system

— Fuel oil system— HVAC system— Service, instrument and bulk

air system— Hydraulic power system— Ballast system— Load and stability system


* Only systems and components with software should be considered.

**CL3 should be applied for units involved in fixed-to-bottom operations.





CL Applicable for


DNV GL AS

Cha

pter

3

Sec

tion

1
3.2.2 As part of the annual assessment any changes, introduced after the latest assessment, to the systems within ISDS scope are to be addressed. An impact analysis of changes shall be reviewed and confirmed. Any follow up activities are to be agreed.
3.2.3 Updated evidence is to be kept and made available for review by the attending surveyor. Relevant evidence include (with reference to required activity in parentheses):

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

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

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

3.3 Scope of renewal assessmentsThe scope of the annual assessment is to be carried out. In addition the renewal assessment will have a specific focus on identified process areas or activities. These areas or activities are to be selected based on a discussion with owner of specific focus areas and should also be based on important or frequent findings from the annual assessments carried out since the last renewal.


DNV GL AS

App

endi

x A
APPENDIX A DEFINITIONS AND ABBREVIATIONS
1 Definitions

1.1 Verbal forms

1.2 Definitions

Table 1 Verbal forms

Term Definition

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

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

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

can indicates a conditional possibility

Table 2 Definitions

Term Definitionacceptance criteria the criteria that a system or component must satisfy in order to be accepted by a user,

customer, or other authorized entity [IEEE 610.12:1990]activity a defined body of work to be performed, including its required input and output information

[IEEE 1074:2006]availability the ability of the system to provide access to its resources in a timely manner for a specified

duration [IEC IEV 191-02-05], alternatively, the time 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 agreed upon, that thereafter serve as the basis for further development, and that can be changed only through formal change control procedures [ISO IEC 15288:2008]

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

black-box (1) a system or component whose inputs, outputs, and general function are known but whose contents or implementation are unknown or irrelevant(2) pertaining to an approach that treats a system or component as in (1).[IEEE 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 represented by

suitably annotated geometrical figures to show both the functions of the parts and their functional relationships [IEEE 610.12:1990]

change control board see configuration control boardcode review systematic examination (often as peer review) of computer source code intended to find and

fix mistakes overlooked in the initial development phase, improving the overall quality of softwareCode 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 no influence on its features and other qualitiesTypically the software is sold pre-wrapped with its user documentation [ISO/IEC 25051:2006(E)].

commissioning (tests) verifying and documenting that the unit and all of its systems are designed, installed, tested and 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-systemcomponent testing testing of individual hardware or software components or groups of related components

[IEEE 610.12:1990]


DNV GL AS

App

endi

x A

configuration audits activities ensuring that the configuration management process is followed and that the evolution of a product is compliant to specifications, policies, and contractual agreementsFunctional configuration audits are intended to validate that the development of a configuration item has been completed and it has achieved the performance and functional characteristics specified in the System Specification (functional baseline). The physical configuration audit is a technical review of the configuration item to verify that the as-built maps to the technical documentation [INCOSE SE 2004].

configuration control board

a group of people or a person responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes

configuration data data used to configure/tailor a system or componentThe data needs to be quality assured.

configuration item an aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process [IEEE 610.12:1990]

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

consistency the degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a system or component [IEEE 610.12:1990]

coverage the amount or proportion of a software component that has been tested It is commonly quantified 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 or activity under consideration

criticality the degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system [IEEE 610.12:1990]

cycle time (1) the period of time required to complete a sequence of events(2) 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.[IEEE 610.12:1990].

deadlock a situation in which computer processing is suspended because two or more devices or processes are each awaiting resources assigned to the others [IEEE 610.12:1990]

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

defect non-fulfilment of a requirement related to an intended or specified use [ISO 9000: 2005] dependability collective term used to describe the availability performance and its influencing factors:

reliability performance, maintainability performance and maintenance support performanceSee also RAMS, to which it adds Security [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 condition [IEC 61508-4]

essential function (or system)

a system supporting the function, which needs to be in continuous operation or continuously available for on demand operation for maintaining the unit's safety [DNVGL-OS-D202]

established design a design that has largely been previously, successfully implementedSuch designs are often the 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 and integration

failure the termination of the ability of a functional unit to perform a required function on demandNote: a fault in a part of the system may lead to the failure of its function, itself leading to a fault in other linked parts or systems etc.

failure mode a defined manner in which a failure can occurFailure modes can be seen as scenarios for how a system can go wrong.

Table 2 Definitions (Continued)

Term Definition


DNV GL AS

App

endi

x A

fault abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function excluding the inability during preventive maintenance or other planned actions, or due to lack of external resources [IEC 61508-4]

finding the result of approval, assessment and renewal activities by DNV GL, identifying the most important issues, problems or opportunities for improvement within the scope of this standard

firmware the combination of a hardware device and computer instructions and data that reside as read-only software on that device [IEEE 610.12:1990]

functional requirement a requirement that specifies a function that a system or system component must be able to perform [IEEE 610.12:1990]

functional testing (1) testing that ignores the internal mechanism of a system or component and focuses solely 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 specified functional requirements.[IEEE 610.12:1990].

generic system requirement (GSR)

an attribute of the system or its function, relating to performance, quality or RAMS, as seen by the owners [DNV-RP-D201] Contain advice which is not mandatory for the assignment or retention of class, but with which DNV GL, in light of general experience, advises compliance [see also applicable Rules for MOU].

impact analysis analysis, which identifies all systems and software products affected by a software change request and develops an estimate of the resources needed to accomplish the change and determines the risk of making the change [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 complete component configurations and be consistent with a fault isolation and diagnosis strategy. It defines the schedule of component availability and the availability of the verification facilities, including test jigs, conditioning facilities, assembly equipment [ISO/IEC 15288].

integrated software dependent system

an integrated software dependent system is an integrated system for which the overall behaviour 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 an element of a system can be another system, called a subsystem, which may be a controlling system or a controlled system and may include hardware, software and human interaction [IEC 61508-4].

interface (1) a shared boundary across which information is passed(2) a hardware or software component that connects two or more other components for the purpose of passing information from one to the other(3) to connect two or more components for the purpose of passing information from one to the other(4) to serve as a connecting or connected component as in (2) [IEEE 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 interface testing testing conducted to evaluate whether systems or components pass data and control

correctly to one another [IEEE 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 can be retained in, or restored to, a state in which it can perform its required functions [IEEE 610.12:1990].

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

milestone a scheduled event marking the transition from one project phase to the nextThis standard identifies 5 milestones.

mitigation action that reduces the consequence(s) of a hazardous event or risk [IEC 61511-1]modification request see change request.


Term Definition


DNV GL AS

App

endi

x A

module in this standard used to describe the lowest branches in the system hierarchyModules can be made of hardware (HW) or software (SW).

non-functional requirement

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

non-standard legacy software

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

novel a feature, capability, or interface that largely is not present in the base productobsolescence (risk) risk associated with technology within the system that becomes obsolete before the end of

the Expected Shelf or Operations Life, and cannot provide the planned and desired functionality This risk may be mitigated by the Portability Generic System Requirement [DNV-RP-D201].

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

portability the ease with which a system or component can be transferred from one hardware or software environment to another [IEEE 610.12:1990]

probability (of failure on demand)

for hardware and random failures, probability that an item fails to operate when requiredThis probability is estimated by the ratio of the number of failures to operate for a given number of commands to operate (demands) [IEC IEV-191-29-1].

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

prototype a model implemented to check the feasibility of implementing the system against the given constraints, to communicate the specifier’s interpretation of the system to the customer, in order to locate misunderstandingsA 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 target computer, implementation language, program size, maintainability, reliability and availability need not be considered [ISO/IEC 61508-7:2010].

prototyping a hardware and software development technique in which a preliminary version of part or all of the hardware or software is developed to permit user feed-back, determine feasibility, or investigate timing or other issues in support of the development process [IEEE 610.12-1990]

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

record information or documents stating results achieved or providing evidence of activities performed

redundancy the existence of more than one means for performing a required function or for representing information [IEC 61508-4] Redundancy prevents the entire system from failing when one component fails.

regression testing selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements [IEEE 610.12:1990]

release note the term “release” is used to refer to the distribution of a software configuration item outside the development activityThis includes internal releases as activities might contain provisions which cannot be satisfied at the designated point in the life cycle [IEEE12207.0-96:c6s2.6]. The release notes typically describe new capabilities, known problems, and platform requirements necessary for proper product operation [SWEBOK 2004].

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

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

a set of commonly linked generic system attributes that often need to be dealt with in a systematic mannerSee also Dependability.

requirement a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents [IEEE 610.12:1990]


Term Definition


DNV GL AS

App

endi

x A

reused software software integrated into the system that is not developed during the project, i.e., both standard software and non-standard legacy softwareSoftware can be reused “as-is” or be configured or modified.

review activity undertaken to determine the suitability, adequacy and effectiveness of the subject matter to achieve established objectives [ISO 9000:2005]

revision control management of multiple revisions of the same unit of information (also known as version control, 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 quantitative terms, risk is the quantified probability of a defined failure mode times its quantified consequence [DNV-OSS-300].

role a role is an organization with responsibilities within the system lifecycleA role has specific activities 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 of risk reduction[IEC 61508] defines four levels, where SIL 4 is the most dependable and SIL 1 is 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 pertaining to the operation of a computer system [IEEE 610.12:1990]

software component a software component is an interacting set of software modulesA software component is a configuration item.

software lifecycle the period of time that begins when a software product is conceived and ends when the software is no longer available for useThe software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and, sometimes, retirement phase. Note: These phases may overlap or be performed iteratively [IEEE 610.12:1990].

software module separately compilable or executable piece of source code It is also called “Software Unit” or “Software Package” [ISO/IEC 12207:2008]. A small self-contained program which carries out 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 failure of which will disable the entire system

simulation one of real-world simulation, process simulation, electronic circuit simulation, fault simulation, simulation of Software in the Loop (SIL), simulation of the system’s environment or Hardware-In-the-Loop (HIL) [DNV SfC 2.24]Simulators serve various purposes and use different modelling techniques [ISO/IEC 61508-7:2010].

site acceptance tests an acceptance test for a fully integrated systemMay be part of commissioning, or may be performed in the factory before delivery to the unit.

source code computer instructions and data definitions expressed in a form suitable for input to an assembler, compiler, interpreter or other translator [IEEE 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, the procedures for determining whether these provisions have been satisfied [IEEE 610.12:1990]

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

state diagram a diagram that depicts the states that a system or component can assume, and shows the events or circumstances that cause or result from a change from one state to another [IEEE 610.12:1990]

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


Term Definition


DNV GL AS

App

endi

x A

static analysis the process of evaluating a system or component based on its form, structure, content, or documentationContrast with: dynamic analysis [IEEE 610.12:1990].

statistical testing a testing method based on allocating test cases to components and functions in proportion to their expected use in operational scenarios, also called random testingData from statistical testing can be used to predict operational reliability.

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

sub-system a sub-system is a part of a systemFor example Choke and Kill is a part of the Well Control System, the Independent joystick is part of the Dynamic Positioning system (ref. definition in Ch.3 Sec.1 [2]).

System a defined product which contains sub-systemsFor the purposes of the ISDS notation, a system refers to the qualifier identified in the notation, for example DP, DCS, PMS, etc. (ref. Ch.3 Sec.1 [2]).

system architecture a selection of the types of system elements, their characteristics, and their arrangement [INCOSE SE 2004]

system design review a review conducted to evaluate the manner in which the requirements for a system have been allocated to configuration items, the system engineering process that produced the allocation, the engineering planning for the next phase of the effort, manufacturing considerations, and the planning for production engineering [IEEE 610.12:1990]

system testing testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements See also: component testing; integration testing; interface testing [IEEE 610.12:1990].

stress testing testing conducted to evaluate a system or component at or beyond the limits of its specified requirements [IEEE 610.12:1990]

target environment the configuration of network protocols, computers, PLCs, sensors, final elements and other hardware 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 documentation and test documentation

traceability matrix a matrix that records the relationship between two or more products of the development process; for example, a matrix that records the relationship between the requirements and the design of a given software component [IEEE 610.12:1990]

unit the vessel that will get the ISDS notation, typically a Mobile Offshore Unit or a Shipuse case the use case specifies the concepts used primarily to define the behaviour and the

functionality of a system or a subsystem, without specifying its internal structure Use cases and actors (users) interact when the services of the system are used. In this context an actor plays a coherent set of roles when interacting with the system. Note that in the use case context an actor may be a user or another system interacting with the first one [IEC 19501:2005].

validation confirmation, through the provision of objective evidence that the requirements for a specific intended use or application have been fulfilled [ISO 9000:2005]

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


Term Definition


DNV GL AS

App

endi

x A

2 AbbreviationsThe abbreviations in Table 3 are used.

verification tasks, actions and activities performed to evaluate progress and effectiveness of the evolving system solutions (people, products and process) and to measure compliance with requirementsAnalysis (including simulation, demonstration, test and inspection) are verification approaches used to evaluate: risk; people, product and process capabilities; compliance with requirements, and proof of concept [INCOSE SE 2004].

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

version software items evolve as a software project proceedsA version of a software item is a particular identified and specified item. It can be thought of as a state of an evolving item [SWEBOK 2004].

white box testing a testing method that uses knowledge of the internal organization of the software to select test cases that provides adequate coverage of the softwareWhite box testing is also called structural testing.

work product a deliverable or outcome that must be produced to prove the completion of an activity or taskWork products may also be referred to as artefacts.

Table 3 Abbreviations

Abbreviation DescriptionAP For ApprovalBOP Blow Out PreventionCAAP Critical Alarm and Action PanelCCB Change Control BoardCL-<n> Confidence Level <n> (n=1 to 3)CMC Certification of Materials and Components COTS Commercial off-the-shelfCPU Central Processing UnitDP Dynamic PositioningEDS Emergency Disconnect SystemEQD Emergency Quick DisconnectESD Emergency Shut DownF&G Fire and GasFAT Factory Acceptance TestsFEED Front-End Engineering and DesignFI For InformationFMECA Failure Modes, Effects, Criticality AnalysisGSR Generic System RequirementHCTS Heave Compensation and Tensioning SystemHIPS High Integrity Protection SystemHVAC Heating, Ventilation, and Air ConditioningHW Hardware (as opposed to software)IAS Integrated Automation SystemIEC The International Electrotechnical CommissionIEEE The Institute of Electrical and Electronics EngineersINCOSE International Council on Systems Engineering


Term Definition


DNV GL AS

App

endi

x A

IO Input/output (also I/O)ISDS Integrated Software Dependent SystemsISO International Organization for StandardizationIV Independent VerifierMOU Mobile Offshore UnitMTTF Mean Time To FailureMTBF Mean Time Between FailuresMTTR Mean Time To Repair MUD Bulk Storage, drilling fluid circulation and cementingOS Offshore StandardOW OwnerPLC Programmable Logical ControllerPMS Power Management SystemPPC Power Plant Control SystemPRH Pipe / Riser HandlingPSD Process Shut DownRAM Reliability, Availability, MaintainabilityRAMS Reliability, Availability, Maintainability, SafetyRfP Request for ProposalRMS Riser Monitoring SystemRP Recommended PracticeSAT Site Acceptance TestsSEM Subsea Electronic ModuleSI System IntegratorSfC Standard for CertificationSU SupplierSW SoftwareUIO Unit In OperationWCS Well Control SystemWCP Well Control PackageWOCS Work Over Control System

Table 3 Abbreviations (Continued)

Abbreviation Description


DNV GL AS

App

endi

x B
APPENDIX B REQUIREMENT DEFINITION
1 Requirement definition

1.1 General1.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 the activity ID and contains the following elements:

— The header describes the unique activity identifier (ID), enabling easy reference and traceability, and the name of the activity. The identifier is structured in three parts: Z.YYY.NN. The first part (“Z”) of the activity identifier 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.

— The phase and the confidence level at which the activity is to be performed.— Assignment of responsible roles for unit 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.— The documentation criteria field provides a list of required documentation to be submitted to DNV GL

for approval (AP) or for information (FI). — The contributions field lists the roles that are expected to contribute to the activity and the details of

the expected contributions.

1.2 Activity definition basic engineering1.2.1 A.CM.1 Establish a baseline of requirements for the unitPhase: Basic engineering. Confidence level: 1 and above.

Unit level responsible: System integrator. System level responsible: None.

Guidance note:The purpose of an explicit requirements baseline is to achieve control of any changes to the requirements.


1.2.2 A.DES.1 Establish the unit designPhase: Basic engineering. Confidence level: 2 and above.


Requirement definition: A baseline of the unit requirements shall be established at the end of the basic engineering phase. This baseline shall be used as the reference when requirements evolve in later phases.

Assessment criteria: Approved and controlled unit requirements document.Revision history of unit requirements document.

Documents required for review: None

Acceptable contributions from Owner.Approval of the requirements document.

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.

Assessment criteria: Unit design: unit design specifications, systems/network topology and functional descriptions.


Acceptable contributions from Owner.Review the unit design/top level architecture.


DNV GL AS

App

endi

x B
1.2.3 A.PM.1 Establish the master plan
Phase: Basic engineering. Confidence level: 1 and above.


Guidance note:The development plan and the milestones should typically show the requirements and design freeze dates.


1.2.4 A.PQA.1 Define procedures (owner)Phase: Basic engineering. Confidence level: 1 and above.

Unit level responsible: Owner. System level responsible: None.

Guidance note:The word ‘procedures’ in this context is used to represent all documentation regarding the way of working, e.g. process descriptions, standard operating procedures, work instructions, checklists, guidelines etc.

Some procedures may need to be coordinated with the system integrator’s procedures when the system integrator is selected (see A.PQA.2).

The defined procedures are normally made up of quality management system documents: e.g. standard operating procedures, process description, checklists, and document templates along with any project specific adaptations of these.

The following areas are normally expected to be covered:

— All activities required to be performed by the owner, listed in Ch.2 Sec.5.

— Responsibilities and authorities of different disciplines and roles,

— 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,

— Mechanisms for approval of deliverables (verification mechanisms),

— Mechanisms for handling of changes to already agreed technical scope, schedule or costs,

— Mechanisms for follow-up of process adherence (see X.PQA.1 and X.PQA.4).


Requirement definition: A master plan for the development of the unit’s systems in ISDS scope shall be established. The plan shall contain a high level master schedule, taking into account rough estimations and discussions with potential suppliers. Milestones for the whole project shall be established, including milestones to the ISDS standards.All stakeholders shall be in agreement on the plan.

Assessment criteria: Master plan: Activities, work breakdown structure (WBS), schedule, and milestones.


Acceptable contributions from Owner.Provide inputs on specific schedule constraints and master schedule.

Requirement definition: Procedures to be used within the project shall be defined, coordinated, and agreed within and between organisations participating in the project.Roles, responsibilities and specific requirements as defined in this standard shall be explicitly addressed.

Assessment criteria: A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, clear roles and responsibilities and defined ways of interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others).


Contributions: No required contributions.


DNV GL AS

App

endi

x B
1.2.5 A.PQA.2 Define procedures (system integrator)



Some procedures may need to be coordinated with the owner (see A.PQA.1) and the suppliers (see B.PQA.1) when the suppliers are selected.



— All activities required to be performed by the system integrator, listed in Ch.2 Sec.6.— Responsibilities and authorities of different disciplines and roles,— 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,— Mechanisms for approval of deliverables (verification mechanisms),— Mechanisms for handling of changes to already agreed technical scope, schedule or costs,— Mechanisms for escalation of problems (see C.PQA.1),— Mechanisms for follow-up of process adherence (see X.PQA.2 and X.PQA.5),— Mechanisms allowing management insight into the project’s status,— Internal procedures and rules for the work to be carried out in the project e.g. design guidelines (see B.DES.3).— Internal procedures and rules regarding how to document the requirements, design, implementation, verification & validation,

and acceptance of the systems within ISDS scope.


1.2.6 A.RAMS.1 Determine safety rules, standards and laws applicablePhase: Basic engineering. Confidence level: 1 and above.

Unit level responsible: System integrator. System level responsible: System integrator.

Guidance note:Sources of statutory rules include flag states, shelf states, and classification societies. Also, industry standards such as IEC 61508/61511 or ISO 17894 may be applied.

This activity is an extension of the A.REQ.2 activity.



Assessment criteria: A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, clear roles and responsibilities and defined ways of interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others).



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


DNV GL AS

App

endi

x B

1.2.7 A.RAMS.2 Define RAM related requirements and objectivesPhase: Basic engineering. Confidence level: 2 and above.

Unit level responsible: Owner. System level responsible: Owner.

Guidance note:RAM requirements may be explicitly defined as quantitative or qualitative targets or objectives that shall be met by the functions or the systems.

As an example of a quantitative requirement, MTTF or MTBF for a given system in a given environment may be used as a reliability target. Relative reliability (e.g., more reliable than…) is an example of a qualitative requirement. RAM requirements may be part of an overall requirements document.

This activity should be coordinated with the activity A.REQ.2, and the RAM requirements are normally documented in the same document as the other unit and system requirements.


1.2.8 A.RAMS.3 Develop the RAMS plan for the unitPhase: Basic engineering. Confidence level: 2 and above.


Guidance note:The methods, tools and procedures used in all RAMS-related activities should be defined, documented and put under configuration control. This activity provides input to the activity B.RAMS.4. The RAMS plan should cover all relevant RAMS activities included in this standard. This activity may be coordinated with the activities A.PM.1 and A.PQA.2 and the RAMS plan may be a separate document, or a part of the project plan or quality assurance plan. Safety may be dealt with separately, for example in a functional safety management plan.


Assessment criteria: Listing of regulatory requirements that apply regarding safety.Resolution of conflicting rules.Application guidelines.

Documents required for review: List of regulatory requirements unit (FI):

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

List of regulatory requirements system (FI) used in C.IV.3 at CL3.Acceptable contributions from Owner.Make clear any specific considerations such as sovereignty of intended area of operation.

Requirement definition: Reliability, availability, and maintainability related requirements shall be defined and documented. These requirements shall be detailed down to the system level and shall be quantitative for CL3.

Assessment criteria: Listing of RAM requirements.For CL2: qualitative requirements are acceptable.For CL3: quantitative requirements (objectives) are required.

Documents required for review: List of RAM requirements unit (FI):

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

List of RAM requirements system (FI) used in C.IV.3 at CL3.Contributions: No required contributions.

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.

Assessment criteria: Plan(s) showing the methods, tools, and procedures to be used for RAMS activities.Schedule of RAMS activities.Expectations on the suppliers’ RAMS plan.RAM data to be collected (CL3).

Documents required for review: Plan for handling of RAMS (FI):

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

Acceptable contributions from Owner.Review and comment on the RAMS plan for the unit.


DNV GL AS

App

endi

x B
1.2.9 A.REQ.1 Define mission, objectives and shared vision


Guidance note:Agreeing on the overall vision, mission and objectives makes it possible for all involved roles to make correct decisions regarding the functionality and capability of the systems in question.

The results may be a design-basis document or part of a FEED study or similar report.


1.2.10 A.REQ.2 Collect requirements for the unit and systemsPhase: Basic engineering. Confidence level: 1 and above.


Guidance note:It is important that requirements on individual Systems are defined while taking into account interacting System and the whole Unit.

There are no specific demands regarding the format or analysis of the requirements, but it is still important that all relevant aspects like functionality, performance, reliability, availability, maintenance, safety are covered. For a more detailed description of what aspects to cover, see DNV RP-D201, Appendix A: Generic System Requirements.

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


1.2.11 A.REQ.3 Define operational modes and scenarios to capture expected behaviourPhase: Basic engineering. Confidence level: 2 and above.


Guidance note:This activity is an extension of the activity A.REQ.2.

An operational scenario is a description of a typical sequence of events that includes the interaction of the system environment and users, as well as interaction among its components. Nominal scenarios should be described as well as key the important degraded ones.

The task of selecting which of the operational scenarios to define as ‘key’ can be done by evaluating the scenarios towards criteria like the novelty of the scenario, novelty of the systems involved, associated risks etc.

During the basic engineering phase operational scenarios are used to evaluate the vessel specification.

Requirement definition: Mission, vision and objectives of the unit shall be defined. The vision of the unit’s final solution shall be formalised and distributed to all stakeholders.

Assessment criteria: Unit design intention and philosophy: The vision of the unit/system, descriptions of the unit/systems overall behaviour and the expected business/safety/environmental performance.

Documents required for review: Design Philosophy (FI) used in A.IV.1 at CL3.


Requirement definition: Owner requirements shall be collected. These requirements shall focus on operational needs, along with the constraints the owner is placing on the unit and systems.

Assessment criteria: Vessel specification: operational requirements, functional requirements, non-functional requirements and technical constraints.

Documents required for review: Vessel specification (FI) reviewed in A.IV.1 at CL3.

Acceptable contributions from Owner.Provide requirements.Review of requirements documents.Participation in clarification of requirements.

Requirement definition: The different operational modes of the unit shall be described and the corresponding operational scenarios defined.The interaction between the operators and the different systems shall be defined for key operational scenarios.The key operational scenarios shall be explicitly described in order to enable the system integrator and suppliers to focus on these.


DNV GL AS

App

endi

x B
At a later stage the operational scenarios are used as input to more detailed use-cases and to create tests-cases for the interaction
between different systems.

The operational modes and scenarios may also serve as input to operation manuals.

The documentation of operational modes and scenarios can be achieved by creating a concept of operation document (CONOPS).

For more info see the ANSI/AIAA G-043-1992 (focusing on new systems) and IEEE Standard 1362 (focusing on upgrades to existing systems).


1.2.12 A.REQ.4Allocate functions and requirements to systemsPhase: Basic engineering. Confidence level: 1 and above.


Guidance note:The system integrator normally requests information from possible suppliers to specify the system requirements.

Some requirements may be unique to a system; other requirements may be common across all or multiple systems.


1.2.13 A.REQ.5 Consult potential suppliers for acquiring of systemsPhase: Basic engineering. Confidence level: 1 and above.


Guidance note:The requirements allocation to systems is defined in activity A.REQ.4 and the traceability information in activity A.REQ.6.

Make/buy/reuse analyses are normally used to determine which/what part of a system could be acquired.

The system integrator should make sure that the system is not over-specified before consulting what suppliers have to offer.

The system integrator should communicate the hard operational constraints so that the suppliers understand the need for their system.


Assessment criteria: Vessel specification: description of the operational modes and corresponding key operational scenarios, detailed to the level of the different systems.

Documents required for review: Vessel specification (FI) reviewed in A.IV.1 at CL3.


Requirement definition: The requirements shall be organized into packages that can serve as the basis for the development of each system. The allocation of requirements shall ensure that systems on a lower confidence level do not have compromising impact on systems on a higher confidence level.

Assessment criteria: Design specification (or requirements) for the relevant systems.

Documents required for review: Specification (FI) reviewed in A.IV.1 at CL3.

Acceptable contributions from Owner.Review of system level functional specifications/requirements documents, participation in clarification of requirements.

Requirement definition: Potential subcontractors for developing/delivering systems shall be consulted. On CL2 and above, the requirements allocated to the system shall be used to track compliance of the supplier’s offer.

Assessment criteria: System request for proposal (RfP): functional specifications, generic system requirements and obsolescence information.Requirements compliance information (on CL2 and above).


Acceptable contributions from Owner. Contribution of Owner to System request for proposal (RfP):

— Technical constraints, — Generic System Requirements (GSR).


DNV GL AS

App

endi

x B
1.2.14 A.REQ.6 Establish traceability of requirements


Guidance note:Three different types of traceability are normally expected to be documented during the project (see X.REQ.1):

1) Traceability between requirements on different levels (e.g. from unit 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 the requirements and the confidence level of the system in question.

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

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


1.2.15 A.RISK.1 Define a strategy for risk managementPhase: Basic engineering. Confidence level: 2 and above.


Guidance note:The risk management strategy is typically a common asset for individual projects. The ISDS standard focuses on the risk management of common risks which impact several systems or the whole project.


1.2.16 A.RISK.2 Jointly identify risksPhase: Basic engineering. Confidence level: 1 and above.


Guidance note:Risks in this process area should focus on project (schedule and effort) and consider product risks which potentially impact several systems or the whole project.

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

Assessment criteria: Traceability information between requirements on unit level and requirements on the different systems.Defined mechanisms and ambition-level regarding requirements traceability.

Documents required for review: Traceability matrices (FI) used in A.IV.1 at CL3.


Requirement definition: A risk management strategy shall be defined. It shall identify the sources of the risks, how they are categorised, how they are characterised (attributes) and prioritised, how risks are reported, who is responsible, which risk mitigations to use and when the risk should be mitigated.

Assessment criteria: Risk management procedure.Blank risk register.


Acceptable contributions from System integrator.Review the risk strategy.

Requirement definition: Risks impacting the project plans or the efforts shall be identified at the beginning of the project. Consequences (schedule, effort, quality, obsolescence, etc.) and the associated probability shall be evaluated and documented.


DNV GL AS

App

endi

x B
RAMS risks are managed in the RAMS process area.
A clear distinction should be made between risks (not having occurred yet) and issues (already present).


1.2.17 A.RISK.3 Assign confidence levelsPhase: Basic engineering. Confidence level: 1 and above.


Guidance note:Confidence levels of the functions and systems can be assigned using three different practices:

— functions and systems in scope of this standard are assigned a confidence level based on the recommendations in Ch.3 Sec.1 [2.2],

— the above functions and systems may be assigned a higher confidence level by the owner,— additional functions and systems may be assigned a confidence level based on the procedure described in DNV-RP-D201.


1.2.18 A.VV.1 Validate the concept of the unit with the usersPhase: Basic engineering. Confidence level: 2 and above.


Guidance note:The concept should represent an overall idea of the unit and its purpose.

The concept validation allows the project to get early feedback from the users, increase the user awareness of the future unit, and reduce issues during commissioning and sea trials.

Prototypes or simulations may be used to validate the concept of the system with the users, providing a different point of view of the system in addition to the specifications.

Other means of validation may be used, such as using existing concepts already validated by the end users.


Assessment criteria: Project risk list: risk list with risks related to e.g. requirements, schedule, effort, quality, performance, consistency and obsolescence (for both hardware and software).


Acceptable contributions from Owner.Provide inputs on operational and business risks relevant for the project, the unit and systems.

Requirement definition: The confidence level (CL) of the functions and systems shall be assigned. The detailed content and borders of the different systems within scope of ISDS shall be documented.

Assessment criteria: Confidence level matrix for the relevant systems.

Documents required for review: Vessel specification (confidence levels) (FI):

— reviewed in A.IV.1 at CL3— used in A.IV.2 and B.IV.4 at CL3.

Acceptable contributions from System integrator.Contribute to assigning confidence levels to functions and systems within the scope.

Requirement definition: The concept of the unit and its systems shall be presented to representatives of the end users to ensure it can fulfil their needs.Comments and changes to the concept shall be shared with all stakeholders.

Assessment criteria: Unit concept presentation: Simulations and Minutes of System Concept Review Meeting.FEED study.


Acceptable contributions from System integrator.Provide inputs to the unit concept and participate in the presentation of the concept to the end users.


DNV GL AS

App

endi

x B
1.2.19 A.VV.2 Verify the unit and system requirements


Guidance note:This activity is a quality assurance of the results from activities A.REQ.1, A.REQ.3, A.REQ.4 and A.DES.1.

Traceability information (from activity A.REQ.6) is normally used to facilitate this activity.


1.3 Activity definition engineering1.3.1 B.ACQ.1 Select COTS products based on defined criteriaPhase: Engineering. Confidence level: 2 and above.

Unit level responsible: None. System level responsible: Supplier.

Guidance note:This standard focuses on the technical aspects of the selection process, not the financial aspects, which are out of scope.The COTS products in question may be used as a stand-alone product or as a component in the supplier’s system.

This activity should be coordinated with the results of activity B.DES.5.


1.3.2 B.ACQ.2 Establish contract with sub-suppliersPhase: Engineering. Confidence level: 1 and above.


Guidance note:This standard focuses on the technical aspects of the selection process, not the financial aspects, which are out of scope.

Requirement definition: The unit requirements shall be verified in the context of operational scenarios and the defined mission and vision of the unit.The correctness, completeness and consistency of the allocation and derivation of requirements to individual systems and known components from the unit requirements shall be verified by reviewing the requirement traceability information.

Assessment criteria: Review records of the unit requirements.Review records for the system requirements.



Requirement definition: In case of COTS acquisition, selection criteria shall be established that include functionality, RAMS, obsolescence management and other relevant criteria.

Assessment criteria: COTS product selection procedure: obsolescence management.COTS product selection matrix: rationale for selection, selection criteria, evaluations and selection.



Requirement definition: Contracts with sub-suppliers shall be established, and shall contain at least the following items:

— 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 the ISDS standard apply to the sub-supplier and shall be included in the contract.


DNV GL AS

App

endi

x B
If a sub-supplier deliver non-COTS system(s) with custom software, the contractual agreements should clarify which parts of the
ISDS standard the sub-contractor should adhere to and be assessed towards, and which parts of the standard the supplier will take care of.


1.3.3 B.CM.1 Establish baselines of requirements and designPhase: Engineering. Confidence level: 1 and above.

Unit level responsible: System integrator. System level responsible: Supplier.

Guidance note:Changes to these baselines require review and approval by appropriate stakeholders, ref. X.CM.1.

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


1.3.4 B.CM.2 Establish and implement configuration managementPhase: Engineering. Confidence level: 1 and above.


Guidance note:The configuration management plan may be a part of the project plan for the organisation, see activity B.PM.1.

Separate configuration management mechanisms may be established for the unit and individual systems. The unit level mechanism typically does not provide for a software repository, but this should be in place at the supplier level. A typical way to manage changes to baselines is to let one decision-body (normally called a CCB) make an impact analysis of proposed changes and then make a ‘yes’ or ‘no’ decision and communicate the approved changes to be performed.

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

This activity focuses on the configuration management during the engineering and construction phases in the project, for the acceptance phase other mechanisms are typically needed, see D.CM.1.


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



Requirement definition: Baselines of the unit specifications, unit design, system requirements, system designs, base products, and interface specifications shall be established before the information is used for further detailing of design, implementation and verification.

Assessment criteria: Baseline repositories.Identification of baselines.Approved and controlled documents (baselines) for: unit specifications, unit design, system requirements, system design, interface specifications and base products.


Acceptable contributions from Owner.Approval of requirements and design documents.

Requirement definition: The roles, responsibilities and mechanisms for managing changes and handling versions of all software and documents included in the baselines shall be defined and implemented. The project specific details regarding configuration items and responsibilities shall be documented.These mechanisms shall apply until a Change Control Board (CCB) for commissioning is established in the acceptance phase.


DNV GL AS

App

endi

x B

1.3.5 B.DES.1 Design the systemPhase: Engineering. Confidence level: 1 and above.


Guidance note:The definition of external interfaces is related to the coordination of the inter-system interfaces, see activity B.INT.2.

Some of the interface definition may be done during the design of software components, see B.DES.2.

The system design can normally not be finalized until the unit design has been refined in activity B.DES.4.

CL2 & CL3 systems are usually designed to be free of or resilient to single points of failure.


1.3.6 B.DES.2 Design each software componentPhase: Engineering. Confidence level: 2 and above.


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

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 and internal interfaces.

The design may be documented using various recognised methods and means from models and databases to diagrams and documents.

The design should not be confused with the actual software.


Assessment criteria: Configuration management plan: Definition of a Change Control Board (CCB) process 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.


Acceptable contributions from Owner.Approval of configuration management mechanisms and participation in the Change Control Board (CCB) for unit level baselines.

Requirement definition: The design for the system shall be developed and documented.The design shall identify the major subsystems and components and how they interact.All external interfaces shall be documented and coordinated with other relevant systems.The design shall show the software components of the system and indicate which parts are developed for the specific project and which parts are reused/configured.

Assessment criteria: Design for system (hardware & software): functional description, user interface descriptions, block/topology diagrams with software components, external interface descriptions and internal interface descriptions.

Documents required for review: Interface description (FI),Functional description (FI) andBlock (topology) diagram (FI) reviewed in B.IV.1 at CL3.

Acceptable contributions from System integrator. Review the functional descriptions and system topology.

Requirement definition: Design for each software component shall be documented. The design shall identify the major parts of the software component, their functions and behaviour and describe the interactions and behaviour between these parts and with the hardware. The design shall describe which hardware runs the software component and its parts. The intent and assumptions of the designer shall be clearly visible. The known limitations of the design shall be listed. The design shall show which parts are developed within the project and which parts are reused, e.g., standard software or legacy software.


DNV GL AS

App

endi

x B

1.3.7 B.DES.3 Use established design guidelines and methodsPhase: Engineering. Confidence level: 2 and above.


Guidance note:In this context the term ‘guidelines' also includes methods, techniques, tools etc. Some guidelines may be mandatory to follow and are referred to as ‘rules’. The definition and identification of applicable guidelines can be performed as a part of the activities A.PQA.2 and B.PQA.1

The supplier typically uses the design guidelines as input to the design activities B.DES.1, B.DES.2 and B.RAMS.2.

The system integrator typically uses the design guidelines as input to the activities B.DES.4 and B.RAMS.2.

If applicable the guidelines should also take be selected according to the safety integrity level.

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


1.3.8 B.DES.4 Analyse and refine the unit designPhase: Engineering. Confidence level: 2 and above.


Guidance note:This activity can usually not be completed until the suppliers and systems have been selected and awarded contracts because both 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 unit architecture/design is created in activity A.DES.1. The operational scenarios are defined in activity A.REQ.3.

The unit architecture may contain a number of views:

The physical layout describes the way components and networks are physically distributed around the facility, including the way they are interconnected (network and main CPUs).

The logical view of the function describes the function in terms of functionality towards its users.

The scenarios or dynamic view describes 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 responsibility of 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 the hardware components.

Assessment criteria: Component design for each software component, in sufficient detail so as to proceed to the making of the software: structural description, functional description, behaviour description, parameters (default, intervals, as-designed), interfaces description, allocation of software to hardware and assumptions and known limitations of the design.

Documents required for review: Software design description (FI) reviewed in B.IV.1 at CL3.


Requirement definition: Appropriate guidelines and methods shall be used to ensure consistent design of the inter-system behaviour, the systems and their components.

Assessment criteria: System design guidelines: including RAMS related aspects.Unit design guidelines: including RAMS related aspects.

Documents required for review: RAMS design guidelines and methods for the vessel (FI) used in B.IV.1 at CL3.RAMS design guidelines and methods for the system (FI) used in B.IV.1 at CL3.


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


DNV GL AS

App

endi

x B
The development view of the function describes the breakdown of the function into sub-functions.

1.3.9 B.DES.5 Define obsolescence strategyPhase: Engineering. Confidence level: 2 and above.

Unit level responsible: Owner. System level responsible: Supplier.

Guidance note:The owner is responsible for the overall obsolescence strategy while the supplier makes obsolescence statements for the individual system(s).


1.3.10 B.INT.1 Define integration planPhase: Engineering. Confidence level: 2 and above.


Guidance note:The integration plan should describe the steps to follow to assemble the systems and components of the system. The integration plan should take into account the need for test stubs or simulators to perform integration tests (See C.VV.3 and D.VV.4).

The integration readiness criteria are going to be used in activity C.INT.1.

The output from this activity can be combined with the output from B.VV.1 “Define verification and validation strategy”, in order to avoid duplication of information regarding test strategies.

The various roles and responsibilities regarding integration should be defined and documented at an early stage, while the definition of integration sequences and environments may be defined at a later stage. This means that the integration plan may need to be updated in the construction phase.

Special attention should be placed on identifying boundaries and exclusions of each organization’s responsibility.

Assessment criteria: Updated unit design documentation: unit design specifications, systems/network topology with software components, interface specifications, and functional descriptions.

Documents required for review: Interface description (FI) reviewed in B.IV.1 at CL3,Functional description (FI) reviewed in B.IV.1 at CL3,Block (topology) diagram (FI):

— reviewed in B.IV.1 at CL3— used in B.IV.2 at CL2 and CL3.

Acceptable contributions from Owner and Supplier.Owner: Review the unit design documents.Supplier: Give input to the system integrator in the form of system design information, topology, software structure, and interfaces for the supplier’s system(s). Participate in review of the common solutions (unit design).

Requirement definition: Obsolescence risks shall be assessed, based on top level architecture and make/buy/reuse analyses. The strategy/plan for the future management of obsolescence shall be defined.

Assessment criteria: Obsolescence management plan: Authorised vendor list, Spare parts list (hardware & software), stock, alternate spare parts list, management of intellectual property. Obsolescence criteria for software.Manufacturer preferred equipment list.


Acceptable contributions from System integrator and Supplier. System integrator: Review of obsolescence strategy/plan. Assessment of obsolescence of the computer and networking hardware and software.Supplier: Provide obsolescence statements regarding the systems and components, including software components.

Requirement definition: Roles and responsibilities for planning and executing the integration of all parts of the systems in ISDS scope shall be defined and documented. The plan for integration of the different systems into the unit shall be defined and documented. The criteria, procedures, and the environment for the integration shall be described. The integration plan shall also describe the type of tests that will be performed to ensure that systems and components interact correctly.As a minimum the supplier must define the integration readiness criteria for the components.When required, the system integrator shall ask the supplier for a more comprehensive integration plan for integration of components into a system.


DNV GL AS

App

endi

x B
Separate integration plan for a system is normally only required for complex systems, e.g. the drilling package.

1.3.11 B.INT.2 Coordinate inter-system interfacesPhase: Engineering. Confidence level: 2 and above.


Guidance note:This activity is related to the specification of systems and their interaction (A.DES.1, A.REQ.3, and B.DES.4).

Controlling the changes to the inter-system interfaces may be performed by including the interface matrix and the interface definitions in baselines (see B.CM.1).Interface specifications are typically documented by the suppliers as a part of the design of the systems (B.DES.1) and may be included in design documents or documented separately. Multiple interface specification documents may be prepared or they may be packaged into a common document. Typically, the system integrator will manage the baseline of inter-system interface specifications.


1.3.12 B.PM.1 Establish the project plan for each organisationPhase: Engineering. Confidence level: 1 and above.


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

Assessment criteria: Plan for integration of systems into the unit: The responsibilities of the different organizations, dependencies among systems, sequence for integration, integration environment, tests and integration readiness criteria.Plan for integration of sub-systems and components into systems (when required): Dependencies among systems, sub-systems and components, sequence for integration, integration environment, tests and integration readiness criteria.

Documents required for review: Integration plan (FI):

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

Acceptable contributions from Supplier.Provide information about the system dependencies, and other considerations for integrating their system(s) into the unit.Acknowledge assigned responsibilities.When requested, provide a plan for integration of sub-systems and components into a system.

Requirement definition: An interface matrix or a similar mechanism shall be established to identify inter-system interfaces and assign the responsibility for defining and testing them. The status of the interface definition and verification shall be tracked.Changes to the inter-system interfaces shall be controlled and coordinated.

Assessment criteria: Interface overview/matrix information with assigned responsibilities.Agreed inter-system interface specifications containing: protocol selected, definition of commands, messages, data and alarms to be communicated and specifications of message formats.Interface definition and verification status.

Documents required for review: Interface description (FI) used in B.IV.2 at CL2 and CL3.

Acceptable contributions from Supplier.Notify the system integrator when changes are needed to inter-system interfaces. Cooperate with other suppliers in the definition of inter-system interfaces. Update inter-system interface specifications when required.

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 at least schedules and resource allocation of software related activities and take into account the activities for the different phases of the project.


DNV GL AS

App

endi

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


1.3.13 B.PM.2 Coordinate and integrate the project plans with the master planPhase: Engineering. Confidence level: 1 and above.


Guidance note:The initial master plan is provided in activity A.PM.1.

The integration plan (see B.INT.1) and the RAMS plan (see B.RAMS.4) should be taken into account and made visible in the master and project plans. The verification and validation strategies (see B.VV.1) normally also gives inputs that impacts the project plans.


1.3.14 B.PQA.1 Define procedures (supplier)Phase: Engineering. Confidence level: 1 and above.



Some of the supplier’s procedures should be coordinated with the procedures given by the owner (see A.PQA.1) and the system integrator (see A.PQA.2).



— All activities required to be performed by the supplier, listed in Ch.2 Sec.7.— Responsibilities and authorities of different disciplines and roles,— 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,— Mechanisms for approval of deliverables (verification mechanisms),— Mechanisms for handling of changes to already agreed technical scope, schedule or costs,— Mechanisms for escalation of problems (see C.PQA.1),— Mechanisms for follow-up of process adherence (see X.PQA.3 and X.PQA.6),— Mechanisms allowing management insight into the project’s status,— Internal procedures and rules for the work to be carried out in the project, e.g. guidelines for design and implementation (see

B.DES.3 and C.IMP.4).

Assessment criteria: Schedule.Project plan: WBS, technical attributes used for estimating, effort and costs estimates, deliverables and milestones, configuration management plan.Resource allocation.


Acceptable contributions from Owner.Provide inputs to the project plan, including users’ schedules and constraints.

Requirement definition: The master plan of the system should be refined and made consistent with suppliers’ or other stakeholders’ plans and schedules.

Assessment criteria: Master plan.Project plans.


Acceptable contributions from Owner and Supplier.Coordinate plans and schedules.



DNV GL AS

App

endi

x B
— Internal procedures and rules regarding how to document the requirements, design, implementation, verification & validation,
and acceptance of the systems within ISDS scope.


1.3.15 B.RAMS.1 Identify software-related RAMS risks and prioritiesPhase: Engineering. Confidence level: 2 and above.


Guidance note:The RAMS risks are those risks related to the unit (and systems) in operation. At CL1 RAMS risks may be identified along with the project risks. At higher confidence levels special methods should be used, such as: Fault Three Analysis, HAZID, HAZOP, FME(C)A.


1.3.16 B.RAMS.2 Identify RAMS risk mitigation actionsPhase: Engineering. Confidence level: 2 and above.


Guidance note:This activity builds upon the output from activity B.RAMS.1. Mitigation actions can be identified on all levels: the unit, system, subsystem, hardware components, and software components. Typical risk mitigation actions include: changes to requirements or design, changed or added verification activities, changes to operational procedures, changes to documentation etc.


1.3.17 B.RAMS.3 Consider software failure modes in safety analysis activitiesPhase: Engineering. Confidence level: 1 and above.


Assessment criteria: A quality system, documents, minutes of meetings, or other relevant information showing: A defined way of working for the major activities in the project, Clear roles and responsibilities and Defined ways of interaction between the different organizations (e.g. owner, system integrator, supplier, independent verifier, and others).



Requirement definition: Software-related RAMS hazards and risks shall be identified and prioritised. Established methods shall be used for the risk identification. Risks identified at unit and system level shall be shared between relevant roles in the project.

Assessment criteria: RAMS hazard and risk list showing consideration of software risks.Defined risk identification and analysis methods.Relevant risks are communicated to other roles.

Documents required for review: RAMS risk register (FI) and RAMS risk analysis documentation (FI) reviewed in B.IV.3 at CL3.

Acceptable contributions from Owner.Give input to, and participate in risk identification on unit level.

Requirement definition: Identified software-related hazards and risks shall be analysed to identify mitigation actions. Relevant mitigation actions shall be shared between relevant roles in the project.

Assessment criteria: RAMS hazard and risk mitigation list showing mitigation actions for software risks.Relevant mitigation actions are communicated to other roles

Documents required for review: RAMS risk register (FI):

— reviewed in B.IV.3 at CL3— used in C.IV.3 and D.IV.3 at CL3.


Requirement definition: When performing safety analysis, potential software failure modes shall be included in the analysis.


DNV GL AS

App

endi

x B
Guidance note:
Examples of safety analysis methods include, but are not limited to:

FME(C)A, HAZOP, HAZID, Fault Three Analysis, Bowtie, Safety cases, 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.


1.3.18 B.RAMS.4 Develop the RAMS plan for the systemPhase: Engineering. Confidence level: 2 and above.


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


1.3.19 B.REQ.1 Submit proposals to system integrator with compliance statusPhase: Engineering. Confidence level: 1 and above.


Guidance note:The supplier should provide a breakdown of the systems conforming to the Make/Buy/Reuse analyses, and take care to identify any required customisation or parameterisation of existing products, in particular of existing software products.


Assessment criteria: Safety analysis showing consideration of software failure modes.

Documents required for review: Safety assessment report (FI) used in C.IV.3 at CL3.


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 unit.

Assessment criteria: Plan showing objectives, methods, tools, and procedures to be used, consistent with the RAMS plan for the unit.Schedule of RAMS activities.RAM data to be collected (CL3).

Documents required for review: Plan for handling of RAMS (FI):

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

Acceptable contributions from System integrator.Review the RAMS pan for the system to check consistency with the RAMS plan for the unit.

Requirement definition: The supplier shall submit its proposal in response to the system integrator’s request. The proposal shall contain software lifecycle information and a compliance status towards the system requirements.

Assessment criteria: Submitted technical proposal for the system: system breakdown, alternatives and options, description of customisation or parameterisation of existing products (including software), requirements compliance matrix and software lifecycle information (including licensing, ownership and obsolescence).

Documents required for review: Specification (FI) used in B.IV.1 at CL3.



DNV GL AS

App

endi

x B
1.3.20 B.REQ.2 Refine system requirements into software component requirements
Phase: Engineering. Confidence level: 2 and above.


Guidance note:It should be possible to distinguish which requirements are satisfied by the base product as-is, which requirements can be satisfied by a simple customisation and which requirements actually need specific developments.


1.3.21 B.REQ.3 Detail operational scenariosPhase: Engineering. Confidence level: 2 and above.


Guidance note:Use case descriptions may be used in order to ‘drill down’ in operational scenarios and describe the interaction between the end user and the system.

Use case descriptions should include both the normal sequence and relevant alternative- and error -sequences. Performance targets should be defined for use cases.

Use case realisation diagrams (often in the form of sequence diagrams or collaboration diagrams) may be used to show the interaction between different systems and components when performing specific use cases.


1.3.22 B.VV.1 Define verification and validation strategyPhase: Engineering. Confidence level: 1 and above.


Guidance note:The purpose of the verification and validation strategies is to ensure that testing and evaluation is performed efficiently and effectively through a combination of complementary methods.

Relevant stakeholders, e.g. owner, system integrator and supplier should review and approve the verification and validation strategy for the elements in their scope. The supplier's verification strategy should take into account the software module test (C.IMP.3) in addition to all relevant VV activities described in this standard.

Requirement definition: For each software component of the system, requirements shall be refined and allocated into component requirements.If the system is configured or generated from an existing base-product or components, there shall be explicit allocation of requirements to the base-product part and the custom part.

Assessment criteria: Refined component requirements and specification.Requirement allocation matrix.

Documents required for review: Specifications (FI) used in B.IV.1 at CL3.


Requirement definition: The key operational scenarios shall be developed and detailed to show the interaction between the end user and the systems(s) along with the interaction between different sub-systems or components in the system(s).

Assessment criteria: System/component behaviour and interaction specification and descriptions: use cases, sequences (including signal usage), state diagrams, interlocks, degraded sequences, performance targets and constraints and limitations.

Documents required for review: Specifications (FI) used in B.IV.1 at CL3.


Requirement definition: The verification and validation strategies shall be defined and documented.The strategy shall include a list of verification and validation activities, the test environment, the purpose of each activity, the method to be employed in the activity, the quality criteria (quality objectives) to be fulfilled, and the organisational 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 unit/system meets its requirements.


DNV GL AS

App

endi

x B
The system integrator should define the verification and validation strategy at the unit level, while the suppliers should define their
verification and validation strategy at the lower levels. Both should ensure their respective strategies are consistent with each other, and that relevant verification and 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 a requirement, or test for validation against a user scenario).

Detailed procedures and tools for testing may be established during the construction phase (See C.VV.3, C.VV.8 and

D.VV.1).

The information listed under the Assessment criteria may be a part of a project plan, a project quality plan or similar.


1.3.23 B.VV.2 Review the design with respect to requirements and design rulesPhase: Engineering. Confidence level: 2 and above.


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

The review should include software considerations. The design rules are defined in activity B.DES.3.

Good traceability between different requirements levels eases this review; see A.REQ4, B.REQ.2 and X.REQ.1.

This activity verifies the outcomes of all DES activities in phase B.


1.3.24 B.VV.3 Review consistency between design and operational scenariosPhase: Engineering. Confidence level: 2 and above.


Assessment criteria: Verification strategy: which part to verify: unit, system, sub-system, component, module, design documents.Method specification documents, etc.: which methods to use for this verification: testing, inspection, code analysis, simulation, prototyping, peer review techniques, quality criteria and targets, which test types to use: functional, performance, regression, user interface, negative, what environment to use for verification and identification of the test stages (e.g. sea trials, integration tests, commissioning, FAT, internal testing, component testing) to be used for the verification and the schedule for those tests.Validation strategy: products to be validated, validation criteria, operational scenarios, methods and environments.

Documents required for review: Verification and validation strategy (FI):

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

and CL3.

Acceptable contributions from Owner.Provide inputs based on operational scenarios, quality criteria, user needs etc.Provide inputs regarding FAT, commissioning, integration, and quay or sea trials.

Requirement definition: 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 and uncertainties (e.g. technical risks, and design margins, design assumptions).

Assessment criteria: Documented design review records addressing: requirements verification, design rules and verification of uncertainties.


Acceptable contributions from Owner.Review the design from the operation and user point of view.

Requirement definition: Consistency between functions and interfaces assigned to each system and the defined operational scenarios shall be reviewed.


DNV GL AS

App

endi

x B

1.3.25 B.VV.4 Review interface specificationsPhase: Engineering. Confidence level: 2 and above.


Guidance note:This activity verifies the outcomes of B.INT.2 and B.DES.1.Interface specifications may be included in design documents or prepared separately.

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.


1.3.26 B.VV.5 Validate critical or novel user-system interactionsPhase: Engineering. Confidence level: 2 and above.


Guidance note:This validation may be performed by reviewing the different systems against each other to check for usability and consistency.

The validation is usually done as one or several workshops with supplier and user representatives. A document review alone is usually not sufficient.

Diverse means may be used such as simulation (from whiteboard to 3D modelling), demonstrations of similar existing systems and their interactions, etc.

The definition of typical or classes of user system interactions may be used to select the interactions to be validated.


1.4 Activity definition construction1.4.1 C.ACQ.1 Accept deliverablesPhase: Construction. Confidence level: 1 and above.


Assessment criteria: Minutes from review: review results considering consistency of interface/function/component/scenarios.



Requirement definition: All inter-system interface specifications and intra-system interfaces shall be reviewed by relevant stakeholders. The review of inter-system interfaces shall be coordinated by the system integrator.

Assessment criteria: Interface specification reviews addressing at least: consistency between input and output signals, frequency and scan rates, deadlocks, propagation of failures from one part to another, engineering units, network domination.



Requirement definition: Within the specification constraints for the unit, critical or novel user-system interactions shall be validated for usability and consistency.

Assessment criteria: Validation records including: workshop minutes, user representative’s participation and comments and agreed action lists.


Acceptable contributions from Owner and Supplier.Owner: provide inputs based on operational scenarios, quality criteria, user needs etc. The users comment on usability.Supplier: provide information about system usage.


DNV GL AS

App

endi

x B

Guidance note:The principles for the qualification mentioned in this activity are outlined in the guidance note of activity C.VV.7 - “Qualify reused software”.

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


1.4.2 C.ACQ.2 Ensure transition and integration of the delivered productPhase: Construction. Confidence level: 1 and above.


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-suppliers' components.


1.4.3 C.IMP.1 Develop and configure the software components from designPhase: Construction. Confidence level: 1 and above.


Guidance note:The software components should be developed from the design (and not the other way around).

Software development includes creation of new software components, modification of existing software components, or parameterisation and configuration of new, modified and existing software components.


Requirement definition: Deliverables from the sub-suppliers shall be submitted to formal acceptance, using predefined criteria and procedures. Acceptance tests shall at least verify that the delivered product is compliant to its specification.In case of COTS acquisition, the acquired products shall be qualified for use in the ISDS scoped system to be delivered.

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



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

Assessment criteria: Supplier agreement on: list of deliverables, review and approval plans and support and maintenance agreement.Product documentation.Operation manual.Configuration information.



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


DNV GL AS

App

endi

x B

1.4.4 C.IMP.2 Develop support documentationPhase: Construction. Confidence level: 2 and above.


Guidance note:Focus should be put on delivering this documentation early enough to be available for testing.


1.4.5 C.IMP.3 Perform software component testingPhase: Construction. Confidence level: 1 and above.


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 explicitly 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 parts of the code are covered by the tests.


1.4.6 C.IMP.4 Use established software implementation guidelines and methodsPhase: Construction. Confidence level: 2 and above.


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

Assessment criteria: Developed component release note.Commented software source code.Parameters and configuration files.I/O List.Development environment configuration.



Requirement definition: Support documentation for the components and the whole system shall be developed and checked against each other for consistency.

Assessment criteria: System and component support documentation: data sheets, user manuals, administration manuals, operating and maintenance procedures, training material and FAQs, known defects and troubleshooting guides.Review records for the support documentation.


Acceptable contributions from System integrator and Owner.System integrator: Provide guidelines and rules for consistency of support documentation, Review support documentation.Owner: Review support documentation.

Requirement definition: Software components shall be tested before verification or acceptance, according to the verification strategy.The extent (coverage) of the testing and the results shall be documented and reported.

Assessment criteria: Software test log: list of defects, date of test, tester, test scope and pass or fail.Software defect list.



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


DNV GL AS

App

endi

x B
Confidence level and safety level should be considered when selecting and defining guidelines.
Verification that the guidelines and methods have been followed is typically done in activity C.VV.5 “Perform code analysis on new and modified software” and in the review activities C.VV.1 and C.VV.2


1.4.7 C.INT.1 Check readiness status of systems and components before integrationPhase: Construction. Confidence level: 2 and above.


Guidance note:The verification analysis report from C.VV.6 and the RAMS compliance report from C.RAMS.1 may be used as a basis for the check.

See activity B.INT.1 for a description of the integration plan.


1.4.8 C.PQA.1 Establish procedures for problem resolution and maintenance activities in the construction and acceptance phasesPhase: Construction. Confidence level: 1 and above.


Guidance note:The procedures required here should be coordinated with the requirements in D.CM.1 “Manage software changes during commissioning”.

Care should be taken to describe procedures for resolving joint problems, at the interface of two or more systems within ISDS scope. Starting at FAT there should be a joint process for resolving problems.


Assessment criteria: Software guidelines/standards/rules/checklists/automated checks.Review records.



Requirement definition: Readiness of the systems and components for integration shall be checked before starting integration. The criteria defined in the integration plan shall be used to assess readiness.

Assessment criteria: Integration readiness criteria fulfilled per component and per system.



Requirement definition: Establish procedures for receiving, recording, resolving, and tracking problems and modification requests. Maintenance procedures covering software updates, backup and rollback shall also be established.

Assessment criteria: Agreed maintenance procedures: Procedures for general system maintenance activities and procedures for software update, backup and roll-back.Agreed problem resolution procedures: Procedures for receiving, recording, resolving, tracking problems (punches) and modification requests.


Acceptable contributions from Supplier.Provide inputs to the procedures for problem resolution and maintenance activities and participate in the problem resolution process.


DNV GL AS

App

endi

x B
1.4.9 C.RAMS.1 Demonstrate achievement of system RAMS requirements
Phase: Construction. Confidence level: 2 and above.


Guidance note:The RAMS requirements and objectives are defined in activities A.RAMS.1 and A.RAMS.2.

The arguments and evidence may include: Safety analysis, FME(C)A, test cases, test results, inspections, computations and simulations, certifications, qualification of legacy systems, etc.


1.4.10 C.RAMS.2 Evaluate software systems and software components against RAM objectivesPhase: Construction. Confidence level: 3.


Guidance note:This activity is an extension of the activity C.RAMS.1.

The RAM data is typically statistical data collected and analysed using models such as Weibull, PDS (SINTEF STF38A97434), etc.


1.4.11 C.RAMS.3 Prepare a plan for system maintenance during operationPhase: Construction. Confidence level: 1 and above.


Guidance note:The output from this activity forms the basis for the execution of the maintenance in activity E.RAMS.1.

The finalised plan is normally needed in order to perform the activity D.CM.3 “Transfer responsibility for system configuration management to owner”.


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

Assessment criteria: RAMS compliance analysis information.

Documents required for review: RAMS compliance report (FI) reviewed in C.IV.3 at CL3.


Requirement definition: Software systems and software components shall be specifically checked against RAM requirements and objectives using data collected from internal testing, FAT and other verification activities.

Assessment criteria: RAM report: Calculations of RAM values for designated systems and RAM data.

Documents required for review: RAM report (FI) reviewed in C.IV.3.


Requirement definition: A plan for the maintenance of the system during operation shall be defined, describing maintenance related functions like restarts, backups and replacement of equipment/parts during operation.

Assessment criteria: Maintenance management plan: configuration items, rules for operation/maintenance, backup and restore procedures, expected maintenance activities, expected software update, migration and retirement activities, schedules and tailored procedures for maintenance in operation.


Acceptable contributions from Owner.Provide inputs to the development of the maintenance plan.


DNV GL AS

App

endi

x B
1.4.12 C.VV.1 Perform peer-reviews of software


Guidance note:In this context the term ‘software’ is used to represent all types of source code, graphical notations and models that is readable for humans 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.

Peer reviews are often also used to verify that applicable guidelines and methods have been applied in the software, see activity C.IMP.4.


1.4.13 C.VV.2 Review software parameterisation dataPhase: Construction. Confidence level: 1 and above.


Guidance note:Successful parameterisation of the software depends on the quality of the data taken into account by the supplier and provided by the system integrator documenting the physical or dynamic properties of the unit and its various systems.

In practice, the supplier responsible and the system integrator usually review the quality of the parameterisation together.

The input data for the parameterisation is typically an outcome of B.DES.1.


Requirement definition: Peer reviews of new, modified and configured/parameterised software shall be performed. The consistency of the software with its design documents shall be checked.

Assessment criteria: Peer review methodology description.Peer review schedule.Peer review records.Peer review check lists.

Documents required for review: Software peer review records (FI) used in C.IV.1 at CL3.


Requirement definition: Review the software parameterisation for completeness and correctness.

Assessment criteria: Parameter list review report: name, value, tolerance, function.


Acceptable contributions from System integrator.Participate to review of key parameters, check for:

— completeness,— minimum level of uncertainties,— accurate description of unit.


DNV GL AS

App

endi

x B
1.4.14 C.VV.3 Perform internal testing


Guidance note:The ambition levels for these tests should be clearly described in the verification strategy (see B.VV.1), and based on the minimum assessment criteria described here. Details regarding the mapping of requirements to tests are covered in the activity X.REQ.1. The software component test described in activity C.IMP.3 can be used as a means of white box testing. The other aspects of the internal testing are normally performed after the software component test and are sometimes referred to as an ‘internal acceptance test’. The limitations of the internal test environment and the use of tools like e.g. test-drivers, simulators and emulators should be clearly described.


1.4.15 C.VV.4 Perform high integrity internal testingPhase: Construction. Confidence level: 3.


Guidance note:This activity is an extension of the internal test described in C.VV.3 taking into account the additional quantitative RAMS requirements on CL3. The ambition levels for these tests should be clearly described in the verification strategy, and based on the minimum assessment criteria described here.


Requirement definition: Developed systems and components shall be verified before decision to release for FAT. The system and component verification shall be analysed and compared with expected quality attribute targets, e.g. RAMS (qualitative).Tests shall include:

— white box tests with 100% statement coverage of new and modified software— 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— error situations and corresponding alarms— degraded functionality— integration between hardware and software.

All requirements mapped to the system shall be tested.Functions or properties that cannot be tested before FAT or even in FAT shall be clearly identified.

Assessment criteria: Test procedures.Test reports.


Acceptable contributions from System integrator.Review the internal tests results and analyse impact on the verification strategy.

Requirement definition: Internal high integrity tests shall be performed. Tests shall include:

— white box tests with 100% decision coverage of new and modified software— statistical testing— detailed performance testing.— stress testing— FME(C)A based testing— Security related testing— start, restart, shutdown testing.

Functions or properties that cannot be tested before FAT or even in FAT shall be clearly identified.


DNV GL AS

App

endi

x B

1.4.16 C.VV.5 Perform code analysis on new and modified softwarePhase: Construction. Confidence level: 2 and above.


Guidance note:For example, the source code verification may be performed by peer reviews, static analysis, or complementary specific analyses such as schedulability analysis. Semi-automated or manual methods may be used. See ISO 61508 for other recommended means. See ISO 9126 for internal quality characteristics.

If this activity is performed by peer reviews, it can be combined with C.VV.1 provided the software is checked against both design and rule set.

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


1.4.17 C.VV.6 Analyse verification results with respect to targetsPhase: Construction. Confidence level: 2 and above.


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 a fast and effective manner. The targets are defined in activity B.VV.1.


1.4.18 C.VV.7 Qualify reused softwarePhase: Construction. Confidence level: 1 and above.


Assessment criteria: Test proceduresTest reports

Documents required for review: Test procedure at manufacturer (FI) andTest report at manufacturer (FI) used in C.IV.1 at CL3.

Acceptable contributions from System integrator.Review the internal tests results and analyse impact on the verification strategy.

Requirement definition: Adequate software source code verification shall be performed against a predefined set of rules. Code analysis shall be performed on new and modified software.

Assessment criteria: Software code verification: peer review reports, code analysis reports and code rule set.

Documents required for review: Software code analysis record (FI) used in C.IV.1 at CL3.


Requirement definition: The results of all verification activities performed by the supplier shall be evaluated and compared 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. Defects shall be analysed for trends to identify defect prone software.The quality status of the system under development shall be measured.

Assessment criteria: Verification result evaluation: result analyses, punch lists, action lists, defect correction and focus on defect prone software.

Documents required for review: Verification analysis report (FI) reviewed in C.IV.1 at CL3.

Acceptable contributions from System integrator.Review the verification analysis information.

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 due diligence 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.


DNV GL AS

App

endi

x B
Guidance note:
Qualification of software can be done using the following methods:

a) The process for developing the software is compliant to this ISDS standard.

b) The due diligence should evaluate the component against predefined quality criteria. It should review relevant documentation like existing qualification certificates (e.g., type approvals), in-use feedback, requirements specifications, design descriptions, source code, test reports, release notes, and user manuals and other support documentation. When needed, critical functionality, performance, and other characteristics should be tested in a test environment similar to the target environment with the configuration data used in the systems in the ISDS scope.

c) In order to demonstrate that the software is proven-in-use, arguments based on analysis of experiences from previous systems where the component has been used should be provided. The analysis should compare how the component has been used, e.g., how it has been configured, with how it will be used in the current system. Differences should be documented and it should be demonstrated, e.g., by testing or analysis, that the differences do not imply any unacceptable risks. The proven-in-use analysis should investigate failure data from previous systems that have been operated in a controlled way, e.g., all errors and software changes must have been recorded (the requirements in this standard for the operation phase apply).


1.4.19 C.VV.8 Perform factory acceptance tests (FAT)Phase: Construction. Confidence level: 1 and above.


Guidance note:The purpose of the FAT is for the system integrator and owner to accept the system. Full coverage of requirements is not required as long as the owner and the system integrator are satisfied. The demonstration of previously run tests is typically performed by providing 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 clearly described.


Assessment criteria: Software qualification report: reused software component list, qualification method for each reused software component and qualification data.



Requirement definition: Factory acceptance tests (FAT) shall be performed to ensure the system is compliant to its requirements and acceptable for the owner.The FAT shall include:

— tests to ensure the system is compliant with selected operational requirements, including normal modes, error situations, 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.

Assessment criteria: System FAT procedure: coverage of requirements, functionality, performance, RAMS (when applicable), integration testing, hardware/software integration, interfaces and degraded modes.System FAT report: consistent with procedure, deviations identified and coverage measured.

Documents required for review: System FAT procedure (FI) and System FAT report (FI):

— reviewed in C.IV.2 at CL2 and CL3— used in C.IV.1 at CL3.

Acceptable contributions from Owner and System integrator.System integrator: approve the FAT test procedures before the start of the FAT. Both: review, analyse and approve the tests results.Both: accept or reject the system as necessary, based on objective criteria.


DNV GL AS

App

endi

x B
1.4.20 C.VV.9 Arrange independent testing
Phase: Construction. Confidence level: 3.

Unit level responsible: None. System level responsible: System integrator.

Guidance note:A representative environment is the actual unit or an integration of relevant systems creating a test situation similar to the final operational environment. HIL testing may be one method to be used for independent testing (see DNV SfC 2.24).

The system integrator is responsible for arranging the independent testing, but the independent party performing the testing is normally not the system integrator or the supplier.

The term ‘system’ in this context refers to a system on CL3 including all interfaces to other systems regardless of their confidence level.


1.5 Activity definition acceptance1.5.1 D.CM.1 Manage software changes during commissioningPhase: Acceptance. Confidence level: 1 and above.


Guidance note:The system integrator should coordinate changes across all systems. This activity should be related to the activity C.PQA.1 “Establish procedures for problem resolution and maintenance activities in the construction and acceptance phases”, and also to X.REQ.1 “Maintain requirements traceability information”.

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


Requirement definition: The system and its interfaces shall be tested by an independent party in its representative environment.The environment shall be documented, including its assumptions and limitations.

Assessment criteria: Test procedure: covering the system and its interfaces.Test report.

Documents required for review: Independent test procedure (FI) and Independent test report (FI) reviewed in D.IV.1 at CL3.Independent test report (FI) used in D.IV.2 at CL3.

Acceptable contributions from Supplier.Contribute to the preparation of the independent tests.

Requirement definition: Any change in a system or sub-system/component shall be submitted to a change control board which analyses impact and makes a decision regarding the change.The roles, responsibilities and mechanisms for the change control board shall be defined. These shall ensure that the deployed configuration of the systems that have passed FAT cannot change outside of a strict change control procedure.

Assessment criteria: Defined software configuration management: definition of Change Control Board (CCB), change request forms, description of change process for software, impact analysis, Identification of items to be controlled, configuration management tool, including, issue, change, version and configuration tracking tool and prevents unauthorised changes.Modification records justifying changes:configuration records,version histories,release notes, change orders.


Acceptable contributions from Owner and Supplier. Approval of software and document change requests.


DNV GL AS

App

endi

x B
1.5.2 D.CM.2 Establish a release note for the systems in ISDS scope
Phase: Acceptance. Confidence level: 1 and above.


Guidance note:The overall release note can link to each system's release note. The system integrator will base the release note on inputs from the suppliers, see X.CM.2.


1.5.3 D.CM.3 Transfer responsibility for system configuration management to ownerPhase: Acceptance. Confidence level: 1 and above.


Guidance note:The owner may adopt the configuration management mechanisms already defined or modify them appropriately.


1.5.4 D.RAMS.1 Demonstrate achievement of unit RAMS requirements Phase: Acceptance. Confidence level: 2 and above.


Guidance note:The RAMS requirements and objectives are defined in activities A.RAMS.1 and A.RAMS.2.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.


Requirement definition: Before entering into operation, the configuration of the systems in the ISDS scope shall be documented. A release note shall be produced, describing all the items and their versions, as well as their status (e.g. known defects).In the case of changes, differences with respect to previous version shall be documented in the release note.

Assessment criteria: Overall release note for the systems in ISDS scope.



Requirement definition: After acceptance, the owner shall take the responsibility for the configuration management of the systems within ISDS scope. The system integrator shall deliver all necessary software, documentation, and data to the owner.

Assessment criteria: Approved configuration management plan.Records of transmission of software, documentation and data, or responsibility thereof.


Acceptable contributions from Owner and Supplier.Owner: Approval of configuration management system.Supplier: Supply the system integrator with relevant software, documentation and data.

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

Assessment criteria: RAMS compliance analysis information.

Documents required for review: RAMS compliance report (FI) reviewed in D.IV.3 at CL3.

Acceptable contributions from Supplier.Provide RAMS arguments and evidence for the system.


DNV GL AS

App

endi

x B
1.5.5 D.RAMS.2 Collect data and calculate RAM values
Phase: Acceptance. Confidence level: 3.


Guidance note:This activity is an extension of D.RAMS.1.

Several methods for estimating reliability are available, for example: PDS (SINTEF STF38A97434).

Reliability and maintainability data can 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).

The information supplied by the suppliers normally come from the activity C.RAMS.2.


1.5.6 D.RAMS.3 Perform a security audit on the deployed systemsPhase: Acceptance. Confidence level: 2 and above.


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 unit and system level requirements, see activity A.REQ.2. A number of different standards are available and one of them may be used as a basis for the security audit, e.g. ISA 99, BS 5750, and ISO 62443.


1.5.7 D.VV.1 Perform validation testingPhase: Acceptance. Confidence level: 1 and above.


Guidance note:Validation testing is usually broken down and may be performed partly during commissioning, integration testing, and quay or sea trials.

Parameterisation and calibration (of the software) should be performed prior to commissioning. A pre-commissioning step is often suitable.

In some cases the validation tests also include tests that have not been possible to run during internal tests at the supplier (C.VV.3) or at the FAT (C.VV.8).


Requirement definition: Data from commissioning and integration testing shall be collected and used together with data from earlier verification activities to estimate reliability, availability and maintainability values relative to the RAM objectives.

Assessment criteria: Calculations of RAM values for relevant systems and the unit.RAM data.

Documents required for review: RAM report (FI) unit reviewed in D.IV.3.RAM report (FI) system used in D.IV.3.

Acceptable contributions from Supplier.Provide RAM data and evaluations for the system.

Requirement definition: A security audit shall be performed on the relevant systems to verify that the security related requirements are fulfilled.

Assessment criteria: Security audit records.

Documents required for review: Security audit report (FI) used in D.IV.3 at CL3.


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 calibration steps. They shall take software into consideration.


DNV GL AS

App

endi

x B

1.5.8 D.VV.2 Perform validation with operational scenariosPhase: Acceptance. Confidence level: 2 and above.


Guidance note:Qualified simulators, or the unit itself in integration testing, quay or sea trials qualify as representative of the target environment.


1.5.9 D.VV.3 Analyse validation results with respect to targetsPhase: Acceptance. Confidence level: 2 and above.


Guidance note:Decision for authorising the system or unit to go into operation should be made on the basis of the validation results from commissioning, integration testing and quay and sea trials.

The quality targets are defined in activity B.VV.1.


1.5.10 D.VV.4 Perform systems integration tests Phase: Acceptance. Confidence level: 2 and above.


Guidance note:The interaction between the different systems should be tested, not only the match between output signals and input signals.

Both the nominal behaviour and the degraded behaviour should be tested.

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

Assessment criteria: Test procedure: black box tests, boundary tests, software behaviour and parameterisation and calibration.Test reports: executed consistent with procedure.Test issue list: deviations (punches) and variations.

Documents required for review: Test procedure for quay and sea trials (FI) and Report from quay and sea trials (FI) reviewed in D.IV.1 at CL2 and CL3.Report from quay and sea trials (FI) used in D.IV.2 at CL3.

Acceptable contributions from System integrator and Supplier.Both: provide input to test procedures and test data.

Requirement definition: Operational scenarios shall be demonstrated on the systems in the ISDS scope in an environment representative of the target environment.

Assessment criteria: Test procedure: operational scenarios.Test reports: tests performed in compliance with procedure and coverage of scenarios.

Documents required for review: Test procedure (FI) and Test report (FI) reviewed in D.IV.1 at CL2 and CL3.Test report (FI) used in D.IV.2 at CL3.

Acceptable contributions from System integrator and Supplier.Both: provide input to test procedures and test data.

Requirement definition: The validation results and its analyses, including the evaluation of the validation method, the defects identified, and the comparison between the expected results and the actual results shall be recorded.Quality criteria shall be evaluated and compared with quality targets.

Assessment criteria: Test procedure: quality criteria.Test reports: analysis of the results.Test issue list.

Documents required for review: Verification analysis report (FI) reviewed in D.IV.2 at CL3.


Requirement definition: Integration tests shall be performed to ensure that inter-system functionality is working as expected and that the interfaces between systems are compliant to the requirements. Scenarios involving interfaces between the different parts shall be included in the test cases.


DNV GL AS

App

endi

x B
— 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.


1.6 Activity definition operation1.6.1 E.ACQ.1 Manage and monitor obsolescencePhase: Operation. Confidence level: 2 and above.


1.6.2 E.CM.1 Manage change requests during operationPhase: Operation. Confidence level: 1 and above.


E.CM.2 Perform configuration audits

Phase: Operation. Confidence level: 1 and above.

Assessment criteria: Integration test procedures covering system interfaces and inter-system functionality.Integration test reports.

Documents required for review: Test procedure (FI) and Test report (FI) reviewed in D.IV.1 at CL2 and CL3.Test report (FI) used in D.IV.2 at CL3.

Acceptable contributions from Supplier.Contribute with inputs from FAT (activity C.VV.8).

Requirement definition: The acquired components and systems shall be monitored so that pro-active actions can be made before parts become obsolete.The responsibilities for monitoring obsolescence and taking action when needed shall be clearly defined within the organisation.

Assessment criteria: Obsolescence strategy document.Obsolescence management plan: Authorised vendor list, Spare parts list (HW & compatible SW), Alternate spare parts list and Management of intellectual property.



Requirement definition: Change requests shall be systematically handled. Potential changes shall be analysed to assess their impact on operation, as well as effects on other systems. A Change Control Board (CCB) shall consider the impact analysis before approving proposed changes.

Assessment criteria: Change requestsImpact analysisChange ordersWork ordersProblem reportsRelease notesMaintenance logs




DNV GL AS

App

endi

x B
1.6.3 E.PQA.1 Define procedures for problem resolution, change handling, and maintenance activitiesPhase: Operation. Confidence level: 1 and above.


Guidance note:The problem resolution should be based on a systematic problem solving method (e.g. identified in the units International Safety Management (ISM) procedures) to investigate and provide a detailed response (including corrective action) to the problem(s) identified.


1.6.4 E.RAMS.1 Maintain and execute the plan for maintenance in operationPhase: Operation. Confidence level: 1 and above.


Guidance note:The maintenance plans are based on the maintenance related input from the suppliers in activity C.RAMS.3.

Some elements of this plan may be addressed in the configuration management system.


Requirement definition: There shall be regular configuration audits to verify the integrity of the configuration in operation. Configuration audits shall confirm 1) that the operational software versions match supplier records and on-board back-ups, 2) documentation versions match the operational software versions, and 3) the configuration management plan is being followed.

Assessment criteria: Configuration audit reports.


Acceptable contributions from Supplier.Identification of software versions as installed from supplier.

Requirement definition: The owner shall establish procedures for receiving, recording, resolving, and tracking problems, modification requests, and maintenance activities. Software update, migration, retirement, backup and restore procedures shall also be included.

Assessment criteria: Configuration management plan.Configuration management procedure: migration issues and software obsolescence (ref E.ACQ.1).Maintenance procedures: procedures for the maintenance, software update, migration and retirement, backup and restore procedures and procedures for receiving, recording, resolving, tracking problems and modification requests.Change management procedure.Issue tracking and resolution procedure.


Acceptable contributions from Supplier.Provide inputs regarding the supplier’s system(s) to the problem resolution and change handling process.

Requirement definition: The plan for the maintenance in operation of the unit and systems shall be maintained and executed, identifying the configuration items, the rules for maintenance in operation (e.g. access control and logging of maintenance), and the expected activities for maintenance and security patches.Configuration audits, security audits, obsolescence of hardware and software, migration and software retirement issues shall also be addressed in this plan.


DNV GL AS

App

endi

x B

1.6.5 E.RAMS.2 Collect RAMS dataPhase: Operation. Confidence level: 2 and above.


Guidance note:RAMS data typically include:

Failures and incidents, downtime, uptime, number of demands, time to repair, etc.

Even small defects and incidents should be reported, particularly if repeated.


1.6.6 E.RAMS.3 Analyse RAMS data and address discrepanciesPhase: Operation. Confidence level: 2 and above.


Guidance note:RAMS analysis typically result in numbers for MTBF, MTTR etc.


1.6.7 E.RAMS.4 Perform RAMS impact analysis of changesPhase: Operation. Confidence level: 2 and above.


Guidance note:This activity is an extension of the activity E.CM.1.

For major changes, or changes with major RAMS impact, DNV GL will typically review and witness the commissioning of the systems in question as described in activity E.IV.1.

Assessment criteria: Maintenance plan: configuration items, audit activities, maintenance activities, expected software update, migration and retirement activities, maintenance intervals and tailored procedures for the maintenance in operation.Malicious software scan log files records.Maintenance logs.


Acceptable contributions from Supplier.Provide input regarding the supplier’s system(s) regarding maintenance and obsolescence.

Requirement definition: A system to collect RAMS data from the unit in operation shall be established.Data shall be forwarded to the relevant suppliers.

Assessment criteria: RAMS data collection system.RAMS data collected.



Requirement definition: RAMS data shall be analysed in order to assess and improve the RAMS performance.For the software, the analysis must be broken down to the level of software components in order to identify the components that are candidates for improvement.Discrepancies between RAMS requirements/objectives and the actual RAMS results shall be addressed.

Assessment criteria: RAMS analysis.



Requirement definition: Before changes are made to the system in operation, the impacts on RAMS properties shall be analysed. For major changes or changes with major RAMS impact, The owner shall inform DNV GL before the change is made.


DNV GL AS

App

endi

x B
Major changes are changes that are impacting functionality, performance or the interfaces of systems on CL2 or CL3. Bug fixes are
normally not considered a major change.


1.6.8 E.RAMS.5 Periodically perform security audits of the systems in operationPhase: Operation. Confidence level: 2 and above.


Guidance note:DNVGL-OS-D202 contains some security related requirement.

A number of different standards are available and one of them may be used as a basis for the security audit, e.g. ISA 99, BS 5750 and ISO 62443.


1.6.9 E.VV.1 Perform validation testing after changes in the systems in operationPhase: Operation. Confidence level: 1 and above.


Guidance note:Major upgrades or conversions require the application of the whole ISDS standard.


1.6.10 E.VV.2 Perform validation with operational scenarios after changes in the systems in operationPhase: Operation. Confidence level: 2 and above.


Guidance note:This activity is an extension of E.VV.1.

Major upgrades or conversions require the application of the whole ISDS standard.


Assessment criteria: Impact analysis showing RAMS evaluation.



Requirement definition: Relevant systems in ISDS scope shall periodically be audited from a security point of view.

Assessment criteria: Security audit report.



Requirement definition: After minor upgrades and corrections, validation testing shall be done for the systems affected.

Assessment criteria: Test procedure: includes black box tests and includes boundary tests.Test reports: consistent with procedure.

Documents required for review: Test procedure (FI) and Test report (FI) reviewed in E.IV.1 at CL3.

Acceptable contributions from Supplier.Contribute to preparing test procedures and to execute test.

Requirement definition: After minor upgrades and corrections, validation with operational scenarios shall be done for the systems affected.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 calibration steps. They shall take software into consideration.The validation tests shall be performed according to the test procedure.


DNV GL AS

App

endi

x B

1.7 Activity definition several phases1.7.1 X.ACQ.1 Monitor contract execution and changesPhase: Several. Confidence level: 1 and above.


1.7.2 X.ACQ.2 Review intermediate deliverablesPhase: Several. Confidence level: 2 and above.


1.7.3 X.CM.1 Track and control changes to the baselinesPhase: Several. Confidence level: 1 and above.


Guidance note:Typical information tracked includes: date, author, contents of the change, rationale for the change, components impacted, and version and configuration number changes. Proposed changes should be reviewed and approved. This activity should follow the configuration management plan.


Assessment criteria: Test procedures: Covering relevant Operational scenarios.Test reports: tests performed in compliance with procedure and analysis of the results.

Documents required for review: Test procedure (FI) and Test report (FI) reviewed in E.IV.1 at CL3.

Acceptable contributions from Supplier.Contribute to preparing test procedures and to execute test.

Requirement definition: When development or configuration of a software component is subcontracted, the buying organisation shall monitor that the contract is executed as agreed. The ISDS requirements specified in the contract shall 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.

Assessment criteria: Sub-supplier progress review schedule.Sub-supplier progress review reports.Sub-supplier project control records.Sub-supplier quality control records.



Requirement definition: Selected intermediate deliverables from sub-suppliers shall be provided for information and review, in order to give visibility into status and progress.The review of deliverables shall be planned.This activity shall be performed in phases B-C.

Assessment criteria: Supplier agreement: list of deliverables and review and approval plans.Review records/minutes.



Requirement definition: The development of any part of the unit shall follow the rules in the configuration management 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. As changes are made to lower level designs and code, higher level designs and requirements shall be updated appropriately.This activity shall be performed in phases A-D for the system integrator and in phases B-E for the supplier.


DNV GL AS

App

endi

x B

1.7.4 X.CM.2 Establish a release note for the delivered systemPhase: Several. Confidence level: 1 and above.


1.7.5 X.DES.1 Update the base-product design documentationPhase: Several. Confidence level: 2 and above.


Guidance note:Tools and environments needed to configure or generate a project specific product should be considered a part of the same product repository.


1.7.6 X.PM.1 Monitor project status against planPhase: Several. Confidence level: 1 and above.


Guidance note:It is strongly recommended that joint meetings between the different organizations/roles are conducted on a regular basis in order to 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 estimates and/or an updated plan.

Policies (information security) or strategies (obsolescence, verification, validation, and integration) should be updated when needed.

Assessment criteria: Change requests/orders.Version histories for baselines.Changes to: unit requirements, unit design, system requirements, system design, software design, interface specifications and software.Configuration records from document or software repositories.



Requirement definition: Each delivered system/sub-system shall come with a release note, describing the functional content of the delivery (versions of the applicable specifications) as well as its physical content (list of items with their versions). In case of new delivery of a software component, differences with respect to the previous version shall be documented in the release note.This activity shall be performed in phases C-E.

Assessment criteria: Component release note: including list of changes to previous version of component.



Requirement definition: If the system/software is created using base-products, the base product design documentation shall be kept up to date. The documentation of tools and environments needed to configure or generate the system/software from the base-products shall also be kept up to date.This activity shall be performed in phases B-E.

Assessment criteria: Base product design description.Revision information for updated base-product components.



Requirement definition: The project’s activities shall be monitored against the plan and reported. Corrective actions shall be taken when significant deviations from the plan occur. When needed, coordinated actions shall be undertaken with other stakeholders.This activity shall be performed in phases A-D for the system integrator and phases B-E for the supplier.


DNV GL AS

App

endi

x B
During operation, most activities are constrained by maintenance or operation plan. Significant upgrades or corrections requiring
coordination with several stakeholders may require a specific project plan, as specified by this standard.


1.7.7 X.PM.2 Perform joint project milestone reviewsPhase: Several. Confidence level: 1 and above.


Guidance note:The ISDS milestones are intended to be the critical event to decide whether to proceed further in the project, weighing the risks of moving to the next phase versus the risks of postponing it. In some cases, the decision to move forward may include considerable project 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.


1.7.8 X.PQA.1 Control procedures (owner)Phase: Several. Confidence level: 1 and above.


Guidance note:Follow up of the procedures may result in increased process adherence, improvement of procedures, or training as required.


Assessment criteria: Master schedule.Master plan (updated).Project status report.Project action list.Minutes of review meetings.Progress report.


Acceptable contributions from Owner and Supplier.Supplier to provide inputs on specific schedule constraints and deviations to plan for the unit level. Owner to contribute to update policies and strategies and to establish corrective actions.Owner to provide the master plan in phase E, when applicable.

Requirement definition: Joint project milestone reviews to check achievement of phase objectives shall be planned and carried-out. Significant risks, issues and their impact shall be documented and tracked until closure. Decisions whether or not, or how, to progress to the next phase shall be recorded. In the A phase, the system integrator and the owner shall participate. In the B-D phases, all roles shall participate.

Assessment criteria: Minutes of joint milestone meetings.ISDS compliance status.Action plans.


Acceptable contributions from Owner and Supplier.Owner and Supplier to participate in the milestone meeting and provide status and plans. Owner and Supplier to contribute to the decisions related to the further progress of the project.

Requirement definition: Procedures shall be controlled to ensure defined procedures are followed and that the activities required by this standard are executed in practice.This activity shall be performed in phases A-E.

Assessment criteria: Proof that process adherence is being assessed: Quality control records, Project control records and Minutes of meetings, or other relevant information.




DNV GL AS

App

endi

x B
1.7.9 X.PQA.2 Control procedures (system integrator)
Phase: Several. Confidence level: 1 and above.




1.7.10 X.PQA.3 Control procedures (supplier)Phase: Several. Confidence level: 1 and above.




1.7.11 X.PQA.4 Follow-up of ISDS assessment gaps (owner)Phase: Several. Confidence level: 1 and above.


Guidance note:The ‘reasonable time’ can be decided from case to case, but normally an action plan is expected to be submitted for approval within 14 days of the assessment report is issued, and gaps are expected to be closed within the ISDS project-phase in question, and not later than 3 months after the assessment report.

The assessed organisation is expected to closely follow-up on the activities in the corrective action plan.


Requirement definition: Procedures shall be controlled to ensure defined procedures are followed and that the activities required by this standard are executed in practice.This activity shall be performed in phases A-D.




Requirement definition: Procedures shall be controlled to ensure defined procedures are followed and that the activities required by this standard are executed in practice.This activity shall be performed in phases B-E.




Requirement definition: If the independent verifier finds gaps towards this standard during a process assessment, the organisation in question shall plan and implement actions to close those gaps within reasonable time. A corrective action plan outlining the actions to be taken shall be submitted to the independent verifier for approval.This activity shall be performed in phases A-E.

Assessment criteria: Corrective action plan: Responsibility allocation for actions, Records of actions taken and Evidence of implementation of the actions.

Documents required for review: Corrective action plan (AP) reviewed and approved in X.IV.1.



DNV GL AS

App

endi

x B
1.7.12 X.PQA.5 Follow-up of ISDS assessment gaps (system integrator)
Phase: Several. Confidence level: 1 and above.





1.7.13 X.PQA.6 Follow-up of ISDS assessment gaps (supplier)Phase: Several. Confidence level: 1 and above.





1.7.14 X.REQ.1 Maintain requirements traceability informationPhase: Several. Confidence level: 2 and above.


Guidance note:Depending on the confidence level there may be different ambition levels for traceability, but regardless of the ambition level the trace information should be kept up to date when during the project.The traceability information between unit and systems is established in activities A.REQ.6 and B.INT.2.

The traceability information within a system emerges in activity B.REQ.2, B.DES.1 and B.DES.2.

Requirement definition: If the independent verifier finds gaps towards this standard during a process assessment, the organisation in question shall plan and implement actions to close those gaps within reasonable time. A corrective action plan outlining the actions to be taken shall be submitted to the independent verifier for approval.This activity shall be performed in phases A-D.




Requirement definition: If the independent verifier finds gaps towards this standard during a process assessment, the organisation in question shall plan and implement actions to close those gaps within reasonable time. A corrective action plan outlining the actions to be taken shall be submitted to the independent verifier for approval.This activity shall be performed in phases B-E.




Requirement definition: Traceability of requirements shall be kept up to date. Three kinds of traceability information are required: 1) Traceability between requirements on different levels (e.g. from unit 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. This activity shall be performed in phases A-D for the system integrator and in phases B-E for the supplier.


DNV GL AS

App

endi

x B
The traceability information from requirements to verification and validation emerges in activity C.VV.3/4/5/8, D.VV.1/2/4 and
X.VV.1/2 as applicable.

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


1.7.15 X.RISK.1 Track, review and update risksPhase: Several. Confidence level: 1 and above.


Guidance note:It is important that a consistent picture of the risks involving other stakeholders is regularly shared, both with external stakeholders, and with the stakeholders within the organisation.


1.7.16 X.RISK.2 Decide, implement and track risk mitigation actions to closurePhase: Several. Confidence level: 2 and above.


Guidance note:New stakeholders introduced throughout the project should be informed about the risk strategy and the jointly identified risks and be given an opportunity to provide inputs to necessary updates.


Assessment criteria: Up to date traceability information: from owner to system requirements, from system requirements to functional specifications (where applicable), from system requirements to base-product and configuration data (where applicable), from functional specifications to sub-system/component specifications and from requirements to test procedures (when the test procedures are available).Completeness and consistency review records of the traceability information.

Documents required for review: Traceability matrices (FI) used in B.IV.1 and C.IV.1 at CL3, and in C.IV.2 at CL2 and CL3.


Requirement definition: The risk list shall be reviewed and updated regularly, in order to re-evaluate the risk attributes or to take into account new risks. Risks involving other stakeholders shall be regularly shared, reviewed and updated jointly.This activity shall be performed in phases B-D for the system integrator and phases B-E for the supplier. For the E phase, the owner shall establish and maintain the risk list for significant upgrades or conversions.

Assessment criteria: Project risk management plan.Updated internal risk register (per organization).Updated project risk register (jointly managed).


Acceptable contributions from Owner and Supplier.Supplier shall provide input on risks identification on unit level.Owner shall provide inputs on operational and business risks relevant for the project and related to the product.Owner shall manage the risk list for the E phase.

Requirement definition: Risk mitigation actions shall be decided and planned, according to the risk strategy. Status of these actions shall be monitored regularly. Efficiency of mitigation actions shall be assessed and new actions taken as needed. Mitigation actions 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.Major upgrades or conversions require the application of the whole ISDS standard.


DNV GL AS

App

endi

x B

1.7.17 X.VV.1 Perform verification and validation on added and modified software componentsPhase: Several. Confidence level: 1 and above.


Guidance note:Changes to software components should not only trigger verification and validation of the component that has been changed, but also of other related components to prevent regression.


1.7.18 X.VV.2 Detail procedures for testingPhase: Several. Confidence level: 1 and above.


Guidance note:Procedures for testing should take software into consideration, and should focus on new, modified and parameterised software.

In case of (semi-)automated testing, implementation of the test cases should be performed beforehand.

For testing performed in C.IMP.3, a test log is usually sufficient.


Assessment criteria: Updated internal risk register: risk list, mitigation actions and follow-up records (per organization).Updated project risk register: risk list, mitigation actions and follow-up records (jointly managed).


Acceptable contributions from OwnerContribute to identifying and deciding on risk mitigation actions and the closing of same.

Requirement definition: Developed and integrated software components shall be verified, validated and tested for regression before decision to accept the component. This also applies if changes to software components occur after defined baselines, such as FAT. The status of the component verification and validation shall be analysed and compared with expected process and quality attributes targets.This activity shall be performed in phases C-E.

Assessment criteria: Test procedure: consistent with change or upgrade scope.Test report: consistent with test procedure.

Documents required for review: Test procedure (FI) and Test report (FI) used in E.IV.1 at CL3.

Acceptable contributions from Owner.Provide inputs on expected process and quality attribute targets.

Requirement definition: Detailed procedures for testing shall be completed (test cases), and documented. The testing steps shall be identified and clearly separated from the parameterisation and calibration steps.The expected results for each test case shall be specified.Traceability to requirements/function specifications shall be taken into consideration.This activity shall be performed in phases C-E for the supplier and phase D for the system integrator.

Assessment criteria: Existence of relevant test procedures.




DNV GL AS

SAF

DNV GLDriven by our purpose of safeguarding life, property and the environment, DNV GL enables organizations to advance the safety and sustainability of their business. We provide classification and technical assurance along with software and independent expert advisory services to the maritime, oil and gas, and energy industries. We also provide certification services to customers across a wide range of industries. Operating in more than 100 countries, our 16 000 professionals are dedicated to helping our customers make the world safer, smarter and greener.

ER, SMARTER, GREENER