OFFSHORE STANDARD

DNV-OS-D203

INTEGRATED SOFTWARE-
DEPENDENT SYSTEM
(TENTATIVE STANDARD)
APRIL 2010

DET NORSKE VERITAS

FOREWORD
DET NORSKE VERITAS (DNV) is an autonomous and independent foundation with the objectives of safeguarding life, prop-
erty and the environment, at sea and onshore. DNV undertakes classification, certification, and other verification and consultancy
services relating to quality of ships, offshore units and installations, and onshore industries worldwide, and carries out research
in relation to these functions.
DNV Offshore Codes consist of a three level hierarchy of documents:
— Offshore Service Specifications. Provide principles and procedures of DNV classification, certification, verification and con-
sultancy services.
— Offshore Standards. Provide technical provisions and acceptance criteria for general use by the offshore industry as well as
the technical basis for DNV offshore services.
— Recommended Practices. Provide proven technology and sound engineering practice as well as guidance for the higher level
Offshore Service Specifications and Offshore Standards.
DNV Offshore Codes are offered within the following areas:
A) Qualification, Quality and Safety Methodology
B) Materials Technology
C) Structures
D) Systems
E) Special Facilities
F) Pipelines and Risers
G) Asset Operation
H) Marine Operations
J) Cleaner Energy
O) Subsea Systems

Amendments and Corrections

Whenever amendments and corrections to the document are necessary, the electronic file will be updated and a new Adobe PDF
file will be generated and made available from the Webshop (http://webshop.dnv.com/global/).

Comments may be sent by e-mail to rules@dnv.com

For subscription orders or information about subscription terms, please use distribution@dnv.com
Comprehensive information about DNV services, research and publications can be found at http://www.dnv.com, or can be obtained from DNV,
Veritasveien 1, NO-1322 Høvik, Norway; Tel +47 67 57 99 00, Fax +47 67 57 99 11.

© Det Norske Veritas. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, including
photocopying and recording, without the prior written consent of Det Norske Veritas.

Computer Typesetting (Adobe FrameMaker) by Det Norske Veritas.

If any person suffers loss or damage which is proved to have been caused by any negligent act or omission of Det Norske Veritas, then Det Norske Veritas shall pay compensation to such person
for his proved direct loss or damage. However, the compensation shall not exceed an amount equal to ten times the fee charged for the service in question, provided that the maximum compen-
sation shall never exceed USD 2 million.
In this provision "Det Norske Veritas" shall mean the Foundation Det Norske Veritas as well as all its subsidiaries, directors, officers, employees, agents and any other acting on behalf of Det
Norske Veritas.

INRODUCTION
• Background
Equipment and systems have become more complex, auto-
mated, with a higher level of integration. This trend has been
accelerating with time, and the continuing evolution provides
owners of Units with opportunities but also introduces chal-
lenges to the management of such systems both when new as
well as for their full life cycle.
The challenge for Integrated Software Dependent Systems
(ISDS), is how to engineer the various system elements into a
single system that meets all the necessary requirements in
terms of safety, functionality, reliability, individually as well
as to the integration of the system elements and the effect both
negative and positive that system elements may have on each
other.
This Offshore Standard (OS) presents applicable best practices
related to work processes and quality assurance for the full life-
cycle of ISDS.
• Scope
This Offshore Standard (OS) is based on the Recommended
Practice for Integrated Software-Dependent Systems (DNV-RP-
DET NORSKE VERITAS
Offshore Standard DNV-OS-D203, April 2010
Introduction – Page 3
D201). The RP is in turn based on best practices from various
automotive, aerospace and industries with a need for highly reli-
able and safe software and software-dependent systems.
Sources are documented in the RP.
DNV Research & Innovation has published research on the
need expressed by the industry for such improvements
(SMICT).
Learning from the first instances of the RP use, customers have
been requesting a Class Notation regime.
• Consequences
It is believed that this document will be used by the customer:
the owner and the operator, in order to make yards and suppli-
ers implement these best practices.
Experiences from other fields show that the implementation of
such practices will result in lower costs for all concerned,
mostly from a reduction of rework and testing of software and
software-dependent systems.
The various confidence levels introduced provide a flexible
mechanism to adapt the level to the needs of the customer and
to the business needs.
Offshore Standard DNV-OS-D203, April 2010
Page 4 – Introduction

DET NORSKE VERITAS


CONTENTS
CH. 1 INTRODUCTION ................................................ 7
Sec. 1 General................................................................... 9
A. About this Standard ................................................................ 9
A 100 Introduction....................................................................... 9
A 200 Objectives ......................................................................... 9
A 300 Scope of application.......................................................... 9
A 400 Structure of this document.............................................. 10
B. References ............................................................................ 10
B 100 International or national references ................................ 10
B 200 DNV references .............................................................. 10
C. Definitions ............................................................................ 10
C 100 Verbal Forms .................................................................. 10
C 200 Definitions ...................................................................... 10
C 300 Abbreviations.................................................................. 12
CH. 2 TECHNICAL PROVISIONS ............................ 13
Sec. 1 General................................................................. 15
A. General.................................................................................. 15
A 100 Objective......................................................................... 15
A 200 Application...................................................................... 15
Sec. 2 Confidence levels and Scope .............................. 16
A. Confidence Levels ................................................................ 16
A 100 Introduction..................................................................... 16
A 200 Confidence levels............................................................ 16
B. Definition and Assessment
of Confidence levels ............................................................. 16
B 100 General............................................................................ 16
C. Function and Confidence levels ........................................... 17
C 100 Allocation of functions to ISDS Elements...................... 17
C 200 Combining functions ...................................................... 17
Sec. 3 Integrated Software-dependent Systems
Process and Method ............................................ 19
A. Philosophy and Principles ................................................... 19
A 100 General............................................................................ 19
B. Decision Gates and Phases ................................................... 19
B 100 Introduction..................................................................... 19
B 200 Concept phase (A) .......................................................... 19
B 300 Engineering phase (B) .................................................... 19
B 400 Construction phase (C) ................................................... 19
B 500 Acceptance phase (D) ..................................................... 20
B 600 Operation phase (E) ........................................................ 20
C. Process Areas........................................................................ 20
C 100Introduction..................................................................... 20
C 200Requirements Engineering (REQ) .................................. 20
C 300Solution Definition (SOL) .............................................. 20
C 400Design (DES).................................................................. 20
C 500Implementation (IMP) .................................................... 20
C 600Acquisition (ACQ).......................................................... 20
C 700Integration (INT)............................................................. 20
C 800Verification (VER) ......................................................... 20
C 900Validation and Acceptance (VAL) ................................. 20
C 1000
Reliability, Availability, Maintainability
and Safety (RAMS) ........................................................ 20
C 1100 Supportive Activities (SUP) ........................................... 21
D. Responsibilities..................................................................... 21
D 100 General............................................................................ 21
E. Activities............................................................................... 22
E 100 General............................................................................ 22
DET NORSKE VERITAS
Offshore Standard DNV-OS-D203, April 2010
Contents – Page 5
F. Activities and Confidence Levels.........................................22
F 100 General............................................................................ 22
Sec. 4 ISDS Requirements for Owners........................ 24
A. Phases ...................................................................................24
A 100 Concept phase................................................................. 24
A 200 Engineering phase........................................................... 24
A 300 Construction phase.......................................................... 24
A 400 Acceptance phase............................................................ 25
A 500 Operations phase............................................................. 25
Sec. 5 ISDS Requirements for Operators ................... 26
A. Phases ...................................................................................26
A 100 Concept phase................................................................. 26
A 200 Engineering phase........................................................... 26
A 300 Construction phase.......................................................... 26
A 400 Acceptance phase............................................................ 27
A 500 Operations phase............................................................. 27
Sec. 6 ISDS Requirements for System Integrators .... 28
A. Phases ...................................................................................28
A 100 Concept phase................................................................. 28
A 200 Engineering phase........................................................... 28
A 300 Construction phase.......................................................... 29
A 400 Acceptance phase............................................................ 30
A 500 Operations phase............................................................. 30
Sec. 7 ISDS Requirements for Suppliers..................... 31
A. Phases ...................................................................................31
A 100 Concept phase................................................................. 31
A 200 Engineering phase........................................................... 31
A 300 Construction phase.......................................................... 31
A 400 Acceptance phase............................................................ 32
A 500 Operations phase............................................................. 32
Sec. 8 Requirements for Independent Verifiers ......... 33
A. Phases ...................................................................................33
A 100 Concept phase................................................................. 33
A 200 Engineering phase........................................................... 33
A 300 Construction phase.......................................................... 33
A 400 Acceptance phase............................................................ 33
A 500 Operations phase............................................................. 33
CH. 3 CLASSIFICATION
AND CERTIFICATION.................................... 35
Sec. 1 Introduction ........................................................ 37
A. General..................................................................................37
A 100 General............................................................................ 37
B. Class Notation.......................................................................37
B 100 General............................................................................ 37
B 200 System list....................................................................... 37
B 300 Scope............................................................................... 37
B 400 Alterations and additions ................................................ 37
B 500 Raising/Reducing the confidence level .......................... 37
B 600 Alternative integration process and method
requirements ................................................................... 37
Sec. 2 Information Requirements ................................ 38
A. General..................................................................................38
A 100 Information related to Integrated Software
Dependant Systems......................................................... 38
Sec. 3 Approval and Assessment.................................. 39
A. General..................................................................................39
A 100 General............................................................................ 39
A 200 Process ............................................................................ 39
Offshore Standard DNV-OS-D203, April 2010
Page 6 – Contents

A 300 Responsible parties .........................................................39 C 500 In operation assessment ..................................................40

A 400 Findings ..........................................................................39
D. Owner Information Requirements ........................................41
B. Approval of Activities .......................................................... 39
B 100 General ............................................................................39 E. Operator Information Requirements.....................................44
C. Assessment of Phases ........................................................... 39 F. System Integrator Information Requirements ......................48
C 100 General ............................................................................39
C 200 Concept and engineering assessment .............................39 G. Supplier Information Requirements .....................................58
C 300 Construction assessment .................................................39
C 400 Commissioning assessment.............................................39 H. Independent Verifier Information Requirements..................64

DET NORSKE VERITAS

 OFFSHORE STANDARD
DNV-OS-D203

INTEGRATED SOFTWARE- DEPENDENT SYSTEM

(TENTATIVE STANDARD)

CHAPTER 1

INTRODUCTION

CONTENTS PAGE
Sec. 1 General ....................................................................................................................................... 9

DET NORSKE VERITAS

Veritasveien 1, NO-1322 Høvik, Norway Tel.: +47 67 57 99 00 Fax: +47 67 57 99 11

SECTION 1
GENERAL
A. About this Standard
A 100 Introduction
101 This Offshore Standard (OS) describes requirements for
Integrated Software-Dependent System (ISDS). An ISDS is an
integrated system for which the overall behaviour is dependent
on the behaviour of its software components. This standard
describes required activities for the design, construction, inte-
gration, commissioning and operations of units with ISDS
onboard. It describes roles and responsibilities for the organi-
zations involved in such activities.
102 Equipment and systems have become more complex,
automated, with a higher level of integration. This trend is
accelerating with time. This continuing evolution provides
owners of units with opportunities but also it introduces chal-
lenges to the management of such systems, for their full life
cycle. When an owner strives for high production and a safe
installation, demands have to be set upon the systems that con-
trol the installation.
103 The main challenge for Integrated Software Dependent
Systems (ISDS) is how to engineer the various system ele-
ments into a single system that meets all the necessary require-
ments, in terms of safety, functionality, reliability, etc.
Selecting and connecting system elements that may individu-
ally satisfy the requirements is not sufficient. The challenge
extends to the integration of the system elements and an under-
standing of their operation within the system, in particular the
effect both negative and positive that system elements may
have on each other, in order to deliver the emerging properties
of the system.
104 This OS presents applicable best practices related to
work processes and quality assurance for the full lifecycle of
ISDS, where control, monitoring and safety systems serving
several functions can be integrated, or connected via commu-
nication networks.
A 200 Objectives
201 The objectives of this document are to:
— provide a common framework to improve the life cycle
economics of ISDS in the maritime and energy industries.
— provide requirements for involved organizations to ensure
that integration activities are planned, executed and man-
aged according to best practices.
202 Applying this OS helps owners and operators find a bal-
ance between the opportunities and the cost of automation and
manage the risk related to poor quality, incorrect functionality
and unsafe behaviour of a function during the entire life cycle.
203 For system integrators (typically builders or yards) and
suppliers the application of this document provides a common
framework to help deliver on schedule and achieve functional-
ity and quality targets. It is an efficient tool for system integra-
tors and suppliers to communicate and resolve key issues
related to the integration challenge at an early stage and
throughout the whole life cycle.
204 This document recommends an approach for managing
the risk and it gradually creates confidence in the ISDS. It does
not impose a new quality system. The focus of this OS is on
which processes shall be implemented to be compliant, and not
how they can be implemented. Existing project quality systems
shall reference the ISDS OS as an applicable document and the
DNV-RP-201 Integrated Software-Dependent System as rec-
ommended guidelines.
DET NORSKE VERITAS
Offshore Standard DNV-OS-D203, April 2010
Ch.1 Sec.1 – Page 9
205 A final key benefit is that this OS provides a flexible,
cost effective scheme of activities that may be tailored to suit
the needs: safety, environmental or business.
A 300 Scope of application
301 The requirements of this document apply to units where
specified onboard systems have undergone integration of soft-
ware-dependent systems (ISDS). A class notation as specified
in these rules can be assigned when this method or equivalent
methods have been used for integration on systems as specified
in Chapter 2 of these rules.
Guidance note:
The requirements in this chapter apply to marine and offshore
systems and cover integration activities that may be utilized to
assist in design, build, upgrade and/or operations of functional-
ity, dependability and performance of such systems. Examples of
ISDS equivalent methods are CMMI and ISO 15288.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
302 The rules address specific processes and activities to
develop and operate integrated software-dependent systems
(ISDS). Application of such activities will provide additional
objective evidence of functionality, quality and dependability
during normal, abnormal and degraded condition in accord-
ance with the relevant requirements and expected use, to the
level of confidence required.
Guidance note:
The objective is to develop and/or operate the specified target
system by applying of one or more integration process and activ-
ities as described in these rules in order to provide objective evi-
dence of acceptable functionality, quality and dependability
according to stated requirements and expected use.
Application of any ISDS process and method should provide
additional broader and/or deeper integration when compared to
normal classification concept, design, construction, test and
operation activities required for the target software-dependent
system(s).
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
303 In addition to the process and method requirements
defined by DNV in these rules, functional, quality and depend-
ability requirements for the stated system(s) shall be specified.
In this context all main and additional class requirements
applicable for the target software-dependent system apply.
Guidance note:
Upon special agreement other rules and requirements may be
made applicable if relevant. In the case that rules and require-
ments have conflicting requirements, such conflicts should be
clarified, concluded, and documented in each case.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
304 This document expresses requirements for ISDS devel-
opment, construction and operations in the Maritime and
Energy industries. Systems under consideration are any of the
systems involved in operation in these sectors. There is no lim-
itation concerning their size or complexity. This document
addresses all systems in scope, including the controlled sys-
tems, the control systems and the interfaces between the two.
305 This document expresses requirements on the processes
to manage ISDS throughout the life cycle. It describes how
product requirements should be developed and does not spec-
ify any specific product requirements. Other rules and stand-
ards provide product specific requirements which shall be
followed in addition.
306 Within the ISDS elements, the scope of the ISDS class
Offshore Standard DNV-OS-D203, April 2010
Page 10 – Ch.1 Sec.1
notation shall apply to software created, modified, parameter-
ized, tuned and/or configured for the specific project in scope.
Standard software shall be qualified for use in the ISDS
project, according to the activities required by this OS.
Guidance note:
Standard components off the shelf (COTS), in this case software,
cannot be subject to the ISDS review. When using COTS, the
processes for acquiring, and qualifying the use of the software
should be reviewed and checked for compliance. For example,
the activity C.ACQ.7 (acceptance and transitioning of COTS) is
expected to be performed for each COTS acquired and included
in the final ISDS. The ISDS activities focus on assembling the
various COTS software together in a controlled and integrated
process.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
A 400 Structure of this document
401 This document consists of three chapters and one appen-
dix:
— Chapter 1 gives the general scope of the document, back-
ground, definition and references,
— Chapter 2 presents an overview of the ISDS activities and
management processes, and describes the ISDS activity
requirements which are further detailed in DNV-RP-D201
Integrated Software-Dependent Systems.
— Chapter 3 describes the class notations and the classifica-
tion activities
— Appendix A lists the information requirements for each
role.
B. References
B 100 International or national references
101 This standard is provided as a facilities standard, and is
complementary to the standards listed in Table B1.
Table B1 International or national references
Reference Title
ARP 4761 Guidelines and methods for conducting the
safety assessment process on civil airborne
systems and equipment
ECSS-E-40B: 2003 Space engineering
IEC IEV 191 Dependability and quality of service
IEC 61508 Functional safety of electrical/electronic/pro-
grammable electronic safety-related systems
IEEE 610.12:1990 Glossary of software engineering terminology
IEEE 1074:2006 Developing software life cycle processes
EN 13701:2001 Glossary of space systems terminology
ISO 9000 Quality management systems
B 200 DNV references
201 The latest revision of the DNV Offshore standards listed
in Table B2 applies.
Table B2 Offshore Standards and other DNV references
Standard Title
DNV-RP-D201 Recommended practice for Integrated Software-
Dependent Systems
C. Definitions
C 100 Verbal Forms
101 Shall: Indicates a mandatory requirement to be followed
for fulfilment or compliance with the present standard. Devia-
DET NORSKE VERITAS
tions are not permitted unless formally and rigorously justified,
and accepted by all parties.
102 Should: Indicates a recommendation that a certain
course of action is preferred or particularly suitable. Alterna-
tive courses of action are allowable under the standard when
agreed between contracting parties, but shall be justified, doc-
umented and approved by DNV.
103 May: Indicates permission, or an opinion, which is per-
mitted as a part of conformance with the standard.
104 Can: Indicates a conditional possibility.
C 200 Definitions
201 Activity: A defined body of work to be performed,
including its required input and output information.
[IEEE 1074:2006]
202 Approval (of activities): An activity (as defined by this
OS) is approved when the findings demonstrate is imple-
mented successfully for the phase.
203 Assessment (of activities): An examination of one or
more processes within the ISDS project by a trained team of
professionals using the ISDS reference model as the basis for
establishing findings and determining, at a minimum, strengths
and weaknesses.
204 Availability: The ability for the system to provide access
to its resources in a timely manner for a specified duration.
[IEC IEV 191-02-05]
205 Canonical Data Model: The canonical data model
(CDM) is a common model of the data exchanges, for all par-
ticipants in the ISDS project. All data exchanged between sub-
system boundaries shall be recorded in the CDM. All data
exchanged by systems provided by different participant organ-
izations shall be recorded in the CDM. The data description
shall include 1) semantic information (the meaning of the data
for the users and the unit, the importance of the data); 2) tech-
nical information: format, precision, plausibility interval,
default values, standards applicable, criticality or safety level
(when applicable), and 3) exchange scenario information
(when is the data sent (originator event), which system (equip-
ment) sends it, which frequency, which protocols are used,
which system(s) receive it, when do they receive it, which
transformations are applied (if any) and what could happen in
case of errors.
206 Code review:Systematic examination (often as peer
review) of computer source code intended to find and fix mis-
takes overlooked in the initial development phase, improving
the overall quality of software. Code review may also be partly
automated.
207 Common cause failure: Failure of multiple items occur-
ring from a single cause that is common to all of them.
[EN 13701:2001].
208 Common mode failure: Failure of multiple identical
items that fail in the same mode. Note: Common mode failures
are a particular case of common cause failures.
[EN 13701:2001].
209 Configurable code: Code (source code or executable
code) that can be tailored by setting values of parameters.
[ECSS-E-40B: 2003].
210 Configuration Management: The management of fea-
tures and assurances through control of changes made to
requirements, hardware, software, firmware, documentation,
test, test fixtures and test documentation of an automated infor-
mation system, throughout the system lifecycle.
211 Consequence (failure): Ranking of the seriousness of
the failure (business, environmental and safety).
212 Commercial off-the-shelf: Software or hardware, gener-
ally technology or computer products, that are ready-made and
available for sale, lease, or license to the general public.

213 Control function: a function in the ISDS system which
responds to input signals from the environment, the process
and/or the operator and generates output signals causing the
system to operate in the desired manner. [Taken and adapted
from IEC 61508, part 4, §3.3.4]
214 Criticality: Combined measure of the severity of a fail-
ure mode and its probability of occurrence.
215 Decision Gate (or Milestone): A scheduled event mark-
ing the completion (or not) of the preceding phase. The various
roles shall be present and shall have provided before hand their
set of deliverables for review and approval. Of the roles has the
responsibility for taking the decision to step through the gate
or not. Some gates are managed by the owner, others are man-
aged by the system integrator.
216 Defect: Non-fulfilment of a requirement related to an
intended or specified use. [ISO 9000:valid version].
217 Dependability: Collective term used to describe the
availability performance and its influencing factors: reliability
performance, maintainability performance and maintenance
support performance. See also RAMS, to which it adds Secu-
rity. [IEC IEV 191-02-03].
218 Process area: A set of activities dealing with consistent
objectives and skills within the system lifecycle.
219 Emerging System Property: A property of a system
which cannot be observed, measured, tested or verified at the
sub-system or equipment level.
Guidance note:
The properties of a feedback loop cannot be determined by look-
ing at one of the individual pieces of the loop.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
220 Error: A discrepancy between a computed, observed or
measured value or condition and the true, specified or theoret-
ically correct value or condition. [IEC 61508-4].
Guidance note:
An error can be caused by a faulty item, e.g. a computing error
made by faulty computer equipment.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
221 Evidence: information, documents or interview results
used as indicators of the implementation of ISDN activities.
222 Failure: The termination of the ability of a functional
unit to perform a required function on demand.
Note: a fault in a piece of equipment may lead to the failure of
its function, itself leading to a fault in other linked pieces of
equipment, etc. (see below failure propagation).
223 Failure, Random Hardware: Failure, occurring at a ran-
dom time, which results from one or more of the possible deg-
radation mechanisms in the hardware. [IEC 61508-4].
Guidance note:
A major distinguishing feature between random hardware fail-
ures and systematic failures (see below), is that system failure
rates (or other appropriate measures), arising from random hard-
ware failures, can be predicted with reasonable accuracy but sys-
tematic failures by their very nature cannot be accurately
predicted. That is, system failure rates arising from random hard-
ware failures can be quantified with reasonable accuracy but
those arising from systematic failures cannot be accurately statis-
tically quantified because the events leading to them cannot eas-
ily be predicted.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
224 Failure, Systematic: Failure related in a deterministic
way to a certain cause, which can only be eliminated by a mod-
ification of the design or of the manufacturing process, opera-
tional procedures, documentation or other relevant factors.
[IEC 61508-4].
DET NORSKE VERITAS
Offshore Standard DNV-OS-D203, April 2010
Ch.1 Sec.1 – Page 11
Guidance note:
Examples of causes of systematic failures include human error
in:
— the safety requirements specification
— the design, manufacture, installation, operation of the hard-
ware
— the design, implementation, etc. of the software.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
225 Failure propagation: Any physical or logical event
caused by failure within a product which can lead to failure(s)
of products outside the boundaries of the product under analy-
sis.
226 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 exter-
nal resources [IEC 61508-4].
227 Finding: the result of approval, assessment and renewal
activities by DNV, identifying the most important issues, prob-
lems or opportunities for improvement within the ISDS scope.
Findings are inferences drawn from corroborated evidence.
228 Functional Safety: Functional safety is part of the over-
all safety that depends on a system or equipment operating cor-
rectly in response to its inputs. Neither safety nor functional
safety can be determined without considering the systems as a
whole and the environment with which they interact.[IEC
61508].
229 GSR: Generic System Requirement: an attribute of the
system or its function, relating to functionality, quality or
RAMS, as seen by the owners and operators.
230 Independent: Applied to the verifier responsibility. The
level of independence is the one defined by IEC 61508.
231 Integration testing: Testing in which software compo-
nents, hardware elements, or both are combined and tested to
evaluate the interaction between them.[IEEE 610.12:1990].
232 Initial Operational Capacity: for a system developed in
stages, describes the capabilities of the first delivery of the sys-
tem to the operator. Additional deliveries may increase the
capabilities over time.
233 Integrated System: An integrated system is a set of ele-
ments 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].
Guidance note:
The INCOSE SE focuses more on the intent of the system: 'An
integrated system is an integrated set of elements that accomplish
a defined objective.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
234 Interview: oral interaction with those implementing or
using the ISDS processes within the project. Interviews are
typically held with various groups or individuals, such as
project leaders, managers, and project members. A combina-
tion of formal and informal interviews may be held, using
interview scripts or exploratory questions developed to elicit
the information needed. A presentation or demonstration may
serve as an interview if interaction between the appraisal team
and presenter can ensue.
235 ISDS Element: Integrated Software Dependent System
Element. A component, subsystem or control circuit, etc. that
is a part of the ISDS.
236 Maintainability: The ability of a system under given
conditions of use, to be retained in, or restored to a state in
which it can perform its functions, when maintenance is per-
Offshore Standard DNV-OS-D203, April 2010
Page 12 – Ch.1 Sec.1

formed under given conditions and using stated procedures
and resources.
237 Milestone:See Decision Gate.
238 MoSCoW: Must have, Should have, Could have, Won’t
have (but would like). MoSCoW is a prioritization technique
applied to requirements, specifically software requirements, in
the Dynamic Systems Development Method (DSDM).
239 Nonconformity: The non fulfilment of specified require-
ments, a particular kind of defect.
achieve or maintain a safe state, taking into account (a) specific
hazardous event(s).
254 Software ISDS Element: A software component of an
ISDS.
255 Software product: Set of computer programs, proce-
dures, documentation and their associated data.
256 Software unit Separately compilable piece of source
code. Also called "Module" or "Package".

240 Non-compliance: A Nonconformity to the process and 257 System Safety Analysis: A systematic, comprehensive
method requirements as expressed in these rules. evaluation of the implemented system to show that the relevant
requirements are met. [ARP 4761]. Also, Safety & Security
241 Obsolescence (Risk): Risk associated with technology Application Area: a set of best practices to implement safety
within the system that becomes obsolete before the end of the
Expected Shelf or Operations Life, and cannot provide the and security activities, provided by the FAA, to be used for
planned and desired functionality. This risk may be mitigated process assessment and improvement.
by the Portability Generic System Requirement. 258 Stress testing: Testing that evaluates a system or soft-
242 Peer review: A process of subjecting an author's work to ware component at or beyond its value limits.
the scrutiny of others who are experts in the same field. Test case: A specification of a test in terms of:
243 Probability (failure): For hardware, probability that an — a description of the purpose of the test
item fails to operate when required.
This probability is estimated by the ratio of the number of fail- — pre-conditions (e.g. the state of the software under test)
ures to operate for a given number of commands to operate, to — actions organized in one or several scenarios
the number of commands [IEC IEV-191-29-1]. — post-conditions (expected reaction).
244 Preliminary System Safety Analysis; A systematic eval- 259 Unit and ISDS Element testing: A process for testing
uation of a proposed system architecture and implementation
based on the Functional Hazard Assessment and failure condi- components to ensure functionality as defined for the compo-
tion classification to determine safety requirements for all nent, before integration.
items. [ARP 4761]. 260 Validation: Confirmation, through the provision of
245 Reliability, Availability, Maintainability, (Functional) objective evidence that the requirements for a specific
Safety: A set of commonly linked generic system attributes that intended use or application have been fulfilled. [ISO
often need to be dealt with in a systematic manner. See also 9000:valid version].
Dependability.
261 Verification: Confirmation through the provision of
246 Record: Information or documents stating results objective evidence that the specified requirements have been
achieved or providing evidence of activities performed. fulfilled. [ISO 9000:valid version].
247 Regression testing: Selective retesting of a system or 262 ISDS XML Format: A format describing a structure for
component to verify that modifications have not caused unin-
tended effects and that the system or component still complies the delivery of information compliant to this OS’ information
with its specified requirements. [IEEE 610.12:1990]. requirements and facilitating the verification process.
248 Reliability: The capability of the ISDS to maintain a C 300 Abbreviations
specified level of performance when used under specified con-
ditions. 301 The abbreviations in Table C1 are used.
249 Review: Activity undertaken to determine the suitabil- Table C1 Abbreviations
ity, adequacy and effectiveness of the subject matter to achieve CDN Canonical Data Model
established objectives. [ISO 9000:valid version].
CL<n> Confidence Level <n> (n=0 to 3)
250 Revision control: Management of multiple revisions of COTS Commercial off-the-shelf
the same unit of information (also known as version control, CPU Central Processing Unit
source control or (source) code management).
HW Hardware (as opposed to software)
251 Risk: Combination of the probability of occurrence of an IO Input/Output (also I/O)
incident and the severity of that incident. See IEC 61508 for IOC Initial Operational Capacity
more information.
ISDE ISDS Element
252 Safe State: State of the system when safety is achieved ISDS Integrated Software Dependent System
[IEC 61508-4]. MTTF Mean Time To Failure
Guidance note: MTBF Mean Time Between Failures
In going from a potentially hazardous condition to the final safe MTTR Mean Time To Repair
state, the ISDS may have to go through a number of intermediate OS Offshore Standard
safe states. For some situations a safe state exists only so long as
the ISDS is continuously controlled. Such continuous control PSSA Preliminary System Safety Analysis
may be for a short or an indefinite period of time. RAMS Reliability, Availability, Maintainability, Safety
RP Recommended Practice
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
SI System Integrator
253 Safety function: for the purpose of this OS, a control SSA System Safety Analysis
function implemented in the ISDS system which is intended to SW Software

DET NORSKE VERITAS

 OFFSHORE STANDARD
DNV-OS-D203

INTEGRATED SOFTWARE- DEPENDENT SYSTEM

(TENTATIVE STANDARD)

CHAPTER 2

TECHNICAL PROVISIONS

CONTENTS PAGE
Sec. 1 General ..................................................................................................................................... 15
Sec. 2 Confidence levels and Scope.................................................................................................... 16
Sec. 3 Integrated Software-dependent Systems Process and Method................................................. 19
Sec. 4 ISDS Requirements for Owners ............................................................................................... 24
Sec. 5 ISDS Requirements for Operators............................................................................................ 26
Sec. 6 ISDS Requirements for System Integrators ............................................................................. 28
Sec. 7 ISDS Requirements for Suppliers ............................................................................................ 31
Sec. 8 Requirements for Independent Verifiers .................................................................................. 33

DET NORSKE VERITAS

Veritasveien 1, NO-1322 Høvik, Norway Tel.: +47 67 57 99 00 Fax: +47 67 57 99 11
 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.1 – Page 15

SECTION 1
GENERAL

A. General A 200 Application

A 100 Objective
101 Application of these principles is intended to establish
an acceptable level of confidence in ISDS, whilst promoting
improvements through experience and available technology.
201 The principles and requirements shall be applied
throughout the project lifecycle, beginning in the concept
phase, and reviewed and updated through detailed design, con-
struction and operational phase. The principles shall also be
applied with respect to subsequent modifications.

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 16 – Ch.2 Sec.2
SECTION 2
CONFIDENCE LEVELS AND SCOPE
A. Confidence Levels
A 100 Introduction
101 The process is based on the functional breakdown of the
ISDS and the allocation of a Confidence Level to each of the
functions. The Confidence Level is a measure of how impor-
tant a function is to the operation of the system and safety.
102 The mission criticality could be either environmental,
safety or business related and the higher the mission criticality
is the more integrated the recommended activities are. The
number of recommended activities to be applied varies from
low Confidence Levels for systems with limited risks and busi-
ness impacts up to high Confidence Levels for system which
are business, environmental and/or safety-critical.
103 A successful implementation of the OS activities will
put focus on the initial phases of the system development and
will allow early decision-making and possibility of reducing
the overall cost and risk for these systems.
A 200 Confidence levels
201 Confidence Levels define the required level of trust that
a given function (implemented by one or more systems) will
perform as expected. This OS defines Confidence Level 1
through 3 where the higher Confidence Level will provide a
more reliable systems or control system functions.
Guidance note:
The basic principle for the selection of the Confidence Level is
that the higher the potential consequence (safety, environmental
or business) of a failure of the control system or function, the
higher the specified Confidence Level should be.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
202 Confidence Levels are assigned to the overall system
and then to each function within the control system and the
controlled system. This then derives the Confidence Level to
the ISDS Elements (components or networks within the sys-
tem).
203 The amount of activities required by this OS on a given
scope is based on specified Confidence Level. This means that
based on an assigned Confidence Level for a control system or
function, specified activities are defined through its life cycle.
It is also possible to define Confidence Level 0 for a control
function which means that this OS will not be applied for that
function.
204 Project risks during the design and building of the sys-
tems providing the functions are not taken into account in the
Confidence Levels. They are taken into account separately,
within the support process area as a part of project manage-
ment.
Guidance note:
Project risks include risks to the schedule, the development
budget, the functional scope or the quality of the delivered ISDS
and are managed in the project management support process
area.
Safety, environmental and business risks are managed in the
RAMS process area.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
DET NORSKE VERITAS
B. Definition and Assessment
of Confidence levels
B 100 General
101 Each function shall have a specific Confidence Level,
based upon the potential impact of a non-performing function.
This goes beyond the traditional safety risks, but also covers
business and economic impact. Only the potential impact of
non-performance of the function is taken into account for the
Confidence Level, the performance target should be deter-
mined based on a negotiation between supplier and buyer of
the system during the concept phase.
102 Three types of potential consequences should be taken
into consideration when selecting the Confidence Level:
Safety, Environmental and Business Impact. When consider-
ing business impact one should consider the cost of restoring
the system to working order (cost of downtime, time to diag-
nose, develop and qualify a modified system) but also the
impact on your business reputation which is becoming increas-
ingly more important in today’s market place.
103 The assignment of the associated acceptable level of
occurrence is part of the trade-offs made during the concept
phase. This shall be part of the discussions between system
integrator and owner before the contract is awarded: design
trade-offs (including associated costs during development,
construction and operation) versus the expected costs of non-
performance during operation. The core of the negotiation
should be the acceptable level of non-performance, not the
downgrading of the Confidence Level required.
104 The Confidence Level is computed as the maximum
level resulting from Table B1.
Guidance note:
If safety and environmental impact results in Confidence Level 1
but business impact results in Confidence Level 3, then Confi-
dence Level 3 should be selected.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
Guidance note:
- When discussing potential business impact between owner
and supplier / system integrator, it is usually better to define
the consequences in terms of down-time, delay and repair
resources rather than in monetary terms. This is because the
economic impact for a given event will usually be very differ-
ent for the owner / operator versus the supplier / system inte-
grator.
- Assessing the confidence level from the possible conse-
quences is also a means, in this document, to control system-
atic failures (see Failure, Systematic in OS) which likelihoods
are difficult to estimate. The higher the confidence level, the
more activities are in place to prevent, mitigate or tolerate sys-
tematic failures, which may occur in the ISDS in software, in
configuration data, in hardware or in the integration thereof.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.2 – Page 17

Table B1 Assessing Confidence Levels

Potential Consequences Suggested
Confidence
Safety Environmental* Business impact Level
The function not behaving as Loss of function does not Loss of function has minimal impact on the operation. 0
expected does not compromise impact the environment in The function might lead to loss of auxiliary processes but
safety in any significant way. any manner. does not affect the main purpose(s) of the system.
Negligible safety implications. Loss of function may lead Loss of function might lead to a temporary shutdown of non- 1
to minor pollution. critical systems that are easily repairable. May result in
increased operator workload.
Loss of function might lead to minor financial loss
Loss of function may lead to Loss of function may lead Loss of function may lead to prolonged loss of the main 2
major injuries or potential for to significant pollution. function of the system. The incident could escalate to major
a fatality. financial loss or severe damage to the system.
Degradation of company reputation
May lead to multiple fatalities Severe environmental Loss of function might lead to catastrophic loss of the system 3
impact and severe financial impact.
Loss of company reputation
* Definition of minor, significant and severe environmental impact is dependant on the context, and should be defined by the owner.
105 The Confidence Level assignment proposed in this doc- Guidance note:
ument shall be adapted by the owner or operator. Even when there are two completely isolated chains of ISDS Ele-
ments realizing the same function (i.e. there are two systems that
Guidance note: have complete functional redundancy), the overall function and
The owner or the operator may use the DNV-RP-D201 as guide- thus all subsystems still are all of the same Confidence Level.
lines for computing the confidence level. However, the generic system requirement targets for each of the
individual chains could be much lower, depending on the risk
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e--- analysis. In short, redundancy of equipment does not change
Confidence Level.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---

C. Function and Confidence levels C 200 Combining functions

C 100 Allocation of functions to ISDS Elements
101 A function has a specific Confidence Level. After the
design negotiations are concluded the function also has a stated
and measurable set of generic system requirement targets. The
function will typically be implemented by several ISDS Ele-
ments, distributed around the system. The individual ISDS
Elements might either be acquired or constructed.. The quality
is, dependent on the consistent behaviour of the ISDS Ele-
ments which cooperate together to perform the function and
defined by the quality of the ISDS Elements. The design of the
overall consistent behaviour of the ISDS Elements is the task
of the system integrator.
102 For Confidence Levels 1 and above, specific ISDS Ele-
ments can be assigned lower targets during the engineering
phase, based on their place in the overall system architecture..
However, this does not lower the required Confidence Level of
the complete function: the same level of effort and proof has to
be delivered to show that the overall architecture of the inte-
grated function meets its stated system requirement targets.
The allocation of a control function on several ISDS Elements
shall be described by a design rationale. It is expected that a
system integrator provides this rationale explaining the choices
made in the overall architecture of the function, including
demands on specific ISDS Elements, and their contribution to
the specific generic system requirement targets (see DNV-RP-
D201 for guidelines on generic system requirements). This
design rationale shall at least describe the way the function is
split over several ISDS Elements and which design decisions
have been made.
201 ISDS Elements in the architecture (i.e. ISDS Elements
and networks) may be shared by several functions simultane-
ously, provided that there shall be a defined confidence level
for all functions. The combined use of ISDS Elements by sev-
eral functions shall not affect the generic system requirement
behaviour of any of the functions (cross-contamination). This
means that even when one of the functions is in high demand
or a defective state, other functions using the same ISDS Ele-
ment shall not be affected in an unintended way. The rationale
provided by the supplier shall describe the way these combina-
tion requirements are satisfied and the tests performed by the
integrator shall prove there are no cross contamination effects.
202 The basic principle is that the function with the highest
Confidence Level allocated to an ISDS Element will determine
the required Confidence Level for that ISDS Element. It
should be noted that if a function has verifiable redundancy
and diversity for an ISDS Element then a lower Confidence
Level may be applied to this element. However the considera-
tions for the mitigation of common mode failures (e.g. soft-
ware) by diversity shall be provided.
Guidance note:
For example, two identical CPUs with the same application soft-
ware are not diverse enough to reduce the confidence level. A
common mode failure could induce the breakdown of both
CPUs.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
203 Figure 1 summarizes the approach for deriving Confi-
dence Levels of each of the ISDS Elements from the Confi-
dence Levels of each function they implement. This allows
defining a specific Confidence Level for each ISDS Elements,
which will be used to identify what are the activities expected
from the supplier or developer of each ISDS Element.

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 18 – Ch.2 Sec.2

Define function Allocate functions Derive component

confidence level to elements confidence level

Derived CL for elements

Figure 1
ISDS Elements Confidence Level assessment

DET NORSKE VERITAS


SECTION 3
INTEGRATED SOFTWARE-DEPENDENT SYSTEMS PROCESS AND METHOD
A. Philosophy and Principles
A 100 General
101 This document provides requirements for a process and
a set of activities for managing the development, operations
and large maintenance of an ISDS.
102 The required process is based on the functional break-
down of the ISDS and the allocation of a Confidence Level to
each of the functions. The Confidence Level is a measure of
how important a function is to the operation of the system and
safety.
103 The Confidence Level assignment shall be performed by
the owner or operator.
104 A set of activities are defined that shall be applied to that
function throughout the project, based on the assigned Confi-
dence Level.
105 This document divides the project into five distinct
phases and for each of these phases identifies core activities
that shall be undertaken and activities that are selected based
on the Confidence Level required by the function, within the
scope of the project.
Guidance note:
This OS is in addition to class notation and other product-related
activities such as CMC since this OS focuses on process require-
ments.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
106 How to implement these activities and processes is not
prescribed. The requirements primarily focus on the ‘what to
do’. Decision gates M0 to M5 ensure all the elements are in the
right status to start a new phase while managing the project
risks. See Process chart below.
B. Decision Gates and Phases
B 100 Introduction
101 A typical ISDS lifecycle can be structured using key
milestones. This structure is the most common and the most
recommended: it gives a framework where there is a focus on
the ‘decision gates’ where one can check that the status of the
progress is adequate to start the next type of tasks.
102 However, in some cases, some limits between phases
have to be more flexible. Though, it would not be recommend-
able to drop any notion of decision gates in such context, but
rather to provide adaptation rules, allowing more flexibility but
keeping the control.
103 Activity status report from verifier.
Figure 1
Process chart
DET NORSKE VERITAS
Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.3 – Page 19
B 200 Concept phase (A)
201 The objective of this phase is to define the scope of the
project, the needs and constraints it should fulfil, and to estab-
lish the preliminary design of the system. It should identify the
main ISDS Elements which will be assembled in the system.
This is also a setup phase, where project organization should
be defined, as well as the planning of the development. At the
beginning of this phase the Confidence Level shall be defined .
202 This phase shall end with the successful passage of the
M1 decision gate: ready to design and purchase
— Confidence Levels are defined.
— Needs are collected.
— Main system requirements and operational scenarios are
defined.
— Overall design is defined (main ISDS Elements and main
interfaces).
— Potential subcontractors have been consulted.
— Feasibility is assessed.
B 300 Engineering phase (B)
301 In this phase, the detailed design of the system is estab-
lished, and suppliers are involved to setup the development of
each subcontracted ISDS Element of the system. Contracts are
established with suppliers and detailed design of each ISDS
Element is performed.
302 This phase shall end with the successful passage of the
M2 decision gate: ready to develop the ISDS Elements
— Interfaces between ISDS Elements are clearly defined.
— Detailed ISDS Elements design is performed.
— Refined requirements and functions are allocated to ISDS
Elements (taking into account RAMS requirements and
criticality issues).
— Overall design is refined, kept consistent and verified.
B 400 Construction phase (C)
401 This phase aims at developing or acquiring the ISDS
Elements of the system, and integrating them into the final sys-
tem. Coding or parameterization of the ISDS Elements is per-
formed, ISDS Elements are unit-tested and verified, interfaces
are verified, and finally the ISDS is verified.
402 This phase shall end with the successful passage of the
M3 decision gate: ready to verify & validate the system
— Integration & testing strategies and plans are clearly doc-
umented identifying all the milestones and expected status
of ISDS elements to integrate.
— Elements have been developed and unit-tested.
— Purchased ISDS Elements have been received.
— ISDS Elements have been tested, assembled and the inte-
gration tests have been performed
Offshore Standard DNV-OS-D203, April 2010
Page 20 – Ch.2 Sec.3
B 500 Acceptance phase (D)
501 In this phase, the ISDS is validated to ensure it fulfils the
user needs in the expected environment. Acceptance of the
systems is pronounced by owner and operator, and the system
is deployed, ready to enter into operation.
502 This phase shall end with the successful passage of the
M4 decision gate: ready to operate
— The whole system has been verified (compliance with
respect to requirements).
— The whole system has been validated (it fulfils the user
needs).
— The whole system has been deployed in its target environ-
ment.
— Documentation and training has been delivered
B 600 Operation phase (E)
601 In this phase the system is under operation. Maintenance
and small upgrades are performed as needed. Configuration of
the system is kept under control all along the life of the system
under operations. Obsolescence is managed. RAMS and GSR
objectives are monitored. Issues are tracked and corrected as
needed.
602 The end of life of the system is planned for, to take into
account integration issues during the switch from the old sys-
tem to the replacement system, if necessary.
603 Large upgrades should be managed as a separate project,
following a distinct lifecycle based on this document.
Guidance note:
The difference between small and large upgrades depends on the
subject system, ship or unit. The owner should be responsible for
assigning the use of the OS for a given upgrade. A rule of thumb
is that any planned upgrade resulting in the shutdown of the unit
or ship for any extended period of time should be managed as a
whole project using this document as an applicable document.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
604 This phase shall end with the successful passage of the
M5: ready for decommissioning
— Before undertaking the replacement, the replacement sys-
tem has been accepted.
— During replacement, the RAMS and GSR requirements
shall be degraded, if so required, in a controlled manner,
explicitly described.
— After replacement, no part of the replaced system shall
continue to provide undocumented services.
C. Process Areas
C 100 Introduction
101 A process area is a group of activities related to a same
type of processes. The activities from one process area are usu-
ally undertaken by a certain type of actors in the project, with
dedicated skills.
102 The process areas we used to structure the practices are
described here below.
C 200 Requirements Engineering (REQ)
201 This process area gathers the activities needed to elicit,
document and manage the requirements, all along the lifecycle
of the system. It is mainly focused on the beginning of the
development on eliciting the needs that should be fulfilled by
the system, giving rise to set of requirements and scenarios for
the system. The set of requirements will then be managed all
along the development but also during operations, to keep con-
trol on the functionalities of the system and how all the system
DET NORSKE VERITAS
parts collaborate to fulfil these needs.
202 There is a close relationship between system require-
ments (what the system should do) and the architecture and
mechanisms within the system (how the system will work).
Moreover, there is a permanent trade-off between expectations
and feasibility, and requirements often have to evolve during
system design and implementation.
C 300 Solution Definition (SOL)
301 The Solution Definition process area encompasses the
activities needed to establish the technical solution of the sys-
tem: investigating of alternative, selection of the solution. It
produces the overall architecture of the system, structured into
ISDS Elements.
C 400 Design (DES)
401 The Design process area aims at providing detailed
architecture, modelling and detailed interfaces of ISDS Ele-
ments and Subsystem Elements of the system.
C 500 Implementation (IMP)
501 Implementation covers the coding and parameterization
needed to develop the ISDS Elements, as well as the associated
support documentation.
C 600 Acquisition (ACQ)
601 Acquisition includes the activities related to subcon-
tracting: proposals, invitation to tender, supplier selection,
contract establishment, contract execution, supplier monitor-
ing, deliverables reception, verification and acceptance.
602 In this document, the “Acquirer” may be the system
integrator, and major suppliers . The word “Supplier” is used
for the other entities which provide parts of the system.
C 700 Integration (INT)
701 The integration process area covers the assembly and
interface control activities of the different parts of the system.
C 800 Verification (VER)
801 The verification process area addresses the verification
that each product complies with its specification.
C 900 Validation and Acceptance (VAL)
901 The validation and acceptance process area covers the
activities aiming at controlling that the system fulfils its
intended use in its target environment. These activities apply to
final system, but also to the intermediate work products.
C 1000 Reliability, Availability, Maintainability
and Safety (RAMS)
1001 The Reliability Availability Maintainability and Safety
(RAMS) process area gathers the activities aiming at identify-
ing and satisfying the expected system requirements. It com-
prises the analysis, rules and mechanisms to ensure they will
be fulfilled. See the DNV-RP-D201 for further description on
terms reliability, availability and maintainability as applied to
integrated software dependent systems.
Guidance note:
The RAMS process area is sometimes called the dependability
process area. It must be noted however that the dependability
word may refer to different properties, sometimes including only
safety, and sometimes adding reliability and maintainability but
not availability. The acronym RAMS is therefore the choice for
limiting the risks of misunderstanding. In addition to the 4 base
system requirements, additional system requirements may be
prescribed by the owner or operator. The DNV-RP-D201 pro-
vides guidelines for defining and measuring system require-
ments.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.3 – Page 21

C 1100 Supportive Activities (SUP) configuration audits.

1101 The Project Management process area covers the activi-
ties related to planning, monitoring, and controlling the project.
It encompasses activities like tasks identification, estimation and
scheduling, establishment and maintenance of the project plan,
identification and coordination of the stakeholders for the
project, establishing and tracking the commitments of the differ-
ent stakeholders, tracking the progress of the project and control-
ling it, as well as managing the risks of the projects.
In the context of ISDS development, a focus has to be main-
tained around managing the coordination issues among the dif-
ferent stakeholders.
1102 The Risk Management process area is a support proc-
ess area covers the activities related to identifying, qualifying,
mitigating and tracking product and project risks, activities
conducted by owners, systems integrators, operators and sup-
pliers. Typical risks to be managed include product risks such
as risks of not meeting explicit or implied generic system
requirements and include project risks, such as schedule,
resource or costs risks for each phase of the project. The risk
management process area is related both to the project man-
agement process area and the RAMS process area
1103 The Process & Quality Assurance process area is a sup-
port process area which covers the activities related to process
management and quality assurance, to ensure that the activities
recommended by the OS are defined, organized and executed
in a manner consistent with the defined and expected level of
quality. Activities include process definition, responsibility
assignment, quality assurance and quality control.
1104 The objective of Configuration Management activities
is to ensure integrity and consistency of all the work products
of the system (ISDS Elements, specifications, documentation,
interfaces …) all along its lifecycle, including the operation
phase. It relies on identification of the different items compos-
ing the system and their status, the establishment of baselines
of consistent items, the control of the changes on them, and
D. Responsibilities
D 100 General
This document addresses several types of actors of the system
development, construction and operation. Each of them has
specific activities to perform. Therefore, five responsibilities
are defined, see below:
Owner: The Owner is the organization who decides to develop
the system, and provides funding.
System Integrator: The System Integrator is responsible for
managing the development of the system, in charge of global
design, ISDS Elements supplier management, and integration
and verification of the whole system. In some cases, the Sys-
tem Integrator may delegate SI activities to suppliers. The del-
egated responsibilities shall be clearly defined. In this case,
there will be several system integrators in the project. During
some phases, the SI role may not be assigned to a dedicated
organization, in which case the SI responsibility is assigned to
one of the existing organizations: Owner, Operator or Sup-
plier.
Operator: The operator is the organization who will finally use
the system when it is under operations. This covers also the
responsibility of maintaining it. This maintenance responsibil-
ity is critical for the correct operations of ISDS. However, this
maintenance responsibility is often delegated in practice to a
subcontractor or another organization, which shall be respon-
sible for implementing the activities in this OS).
Supplier: The Supplier represents any subcontractor which
provides an ISDS Element of the system, under the coordina-
tion of the system Integrator. The ISDS Element may be spe-
cifically designed and built for the project, or customized and
parameterized from a standard product baseline.

A B C D E
Concept Engineering Construction Acceptance Operations
Requirements
Engineering

Solution
Definition

Design

Implementation

Acquisition

Integration

Verification

Validation

Reliability, Availability,
Maintainability, Safety

Supportive
Processes

Owner Syst. Int. Supplier Operator

Figure 2
Typical distribution of activities throughout the phases

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 22 – Ch.2 Sec.3

Operator Needs: Owner

− Scenarios
− Performance Requirement
Deadlines
Budget
Prototypes, Constraints Issues, non compliances,
System Concept
Simulators, Supervision Proposals
defects, process
Components, Costs improvement
System, Feasibility
Training, Visibility & Control
Manuals Risk Management Verifier

System ISDE Specifications

ISDE Specifications Deadlines Work products
Deadlines
Integrator Practices
Budget
Budget Interface Constraints
Interface Constraints

Interface requirements,
design, behaviour,
Supplier prototypes, simulators Supplier
B A
ISDE Specifications ISDE Specifications ISDE Specifications ISDE Specifications
Deadlines Deadlines Deadlines Deadlines
Budget Budget Budget Budget
Interface Constraints Interface Constraints Interface Constraints Interface Constraints
Interface req., Interface req.,
design, behaviour design, behaviour

Sub- Sub- Sub- Sub-

supplier supplier supplier supplier
B.1 B.2 A.1 A.2

101 Independent Verifier: The Independent Verifier is an
organization that is mandated to independently verify that the
system is developed according to the expected rules, standards,
processes and quality. This responsibility can be undertaken by
either the owner or a third party organization. For systems with
high Confidence Level (CL3), this responsibility shall be
undertaken by a third party company.
E. Activities
E 100 General
101 The next four s define the activities required for each
role.
102 An activity is defined in this OS as a defined body to per-
form, with an expected outcome.
103 Each required activity has a unique identifier. The iden-
tifier is structured in three parts: X.YYY.NN.
104 The first part of the activity identifier refers to the phase.
See Sec.3 B above.
105 The second part of the activity identifier refers to the
process area. See Sec.3 C above.
106 The third part of the activity identifier is a unique
number for the activity.
Guidance note:
For example, A.REQ.2 is the identifier of the 2nd activity of the
requirements process area for the concept phase. B.DES.1 is the
1st activity of the design process area in the engineering phase.
E.RAMS.1 is the 1st activity of the RAMS process area in the
operations phase.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
F. Activities and Confidence Levels
F 100 General
101 As described previously, this document provides a scal-
able approach for good practices implementation. For systems
which potential consequences of non-performance are negligi-
ble, the set of expected activities can be quite low, whereas for
systems with high safety, environmental or business implica-
tions, a complete set of activities will be expected.
102 For each Confidence Level, this document identifies a
consistent set of required activities, which number increases as
Confidence Level increases. As a result, activities required at
level 2 are the ones required for level 1 plus several others, and
for level 3 we will find the whole set of activities described in
this OS.
103 At Confidence Level 0, no activity is required, except
the preliminary assessment of Confidence Level of the system.
Once the confidence level is confirmed to be at level 0, no
other activities are required by this OS.
104 At Confidence Level 1, the expected activities aims at
ensuring that system is kept under control during its develop-
ment and operations. This means that expected content of each
part of the system is thoroughly managed, in terms of require-
ments and configuration. Moreover, it is required at that level
that activities are planned and controlled, to ensure that
expected tasks can effectively be performed. For the same rea-
sons, it is also required that subcontracting activities are care-
fully managed at that level. Confidence level 1 targets best
practices for the management of integration.
105 Confidence Level 2 systems involve a more detailed
control of the engineering activities. At that level, it must be
ensured that development is performed with a complete, con-
sistent and verified approach. Thus, architecture, design,
development, integration, verification and validation tasks

DET NORSKE VERITAS


shall comply with a large set of expected activities. At this
level, risk management activities as well as RAMS require-
ments identification and tracking should be performed. This
level introduces also the independent verifier, who shall under-
take processes verification. Confidence level 2 adds best prac-
tices of system integration engineering.
106 Confidence Level 3 requires additional activities,
DET NORSKE VERITAS
Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.3 – Page 23
needed for such safety and reliability demanding systems. It
encompasses generalization of independent verification proce-
dures for engineering activities (design, specifications, coding,
testing), as well as the activities needed to ensure RAMS
expectations, such as failure analyses or applying specific
design patterns (e.g.: redundancy). Confidence level 3 adds
best practices for high integrity systems integration.
Offshore Standard DNV-OS-D203, April 2010
Page 24 – Ch.2 Sec.4

SECTION 4
ISDS REQUIREMENTS FOR OWNERS

A. Phases A 200 Engineering phase

201 No activities need to be performed by the owner at con-
A 100 Concept phase fidence level 0, in this phase.
101 The following table describes the activities that shall be 202 The following table describes the activities that shall be
performed by the owner, regardless of the confidence level: performed by the owner, depending on the confidence level:

Table A1 Owner Mandatory activities Table A3 Owner Engineering Confidence Level

Phase activities Ref 1 2 3
Requirements engineering
Contribute to requirements collection. A.REQ.2 Acquisition
Supportive processes Identify main contractor B.ACQ.4 X X X
Identify Risks A.SUP.6 Validation
Determine Confidence Level A.SUP.12 Define validation strategy B.VAL.1 X X
102 The following table describes the activities that shall be Supportive processes
performed by the owner, depending on the confidence level: Review and update risks B.SUP.3 X X X
Decide and track risk mitigation B.SUP.4 X X
Table A2 Owner Concept Phase Confidence Level actions
activities Ref 1 2 3 Establish a baseline of require- B.SUP.6 X X X
ments and design
Requirements engineering
Control processes B.SUP.7 X X X
Contribute to requirements collec- A.REQ.2 X X X
tion. Establish project plan B.SUP.9 X X X
Contribute to mission, objectives, A.REQ.5 X X Monitor project status against plan B.SUP.10 X X X
shared vision and operational con-
cept A 300 Construction phase
and scenarios definition. 301 No activities need to be performed by the owner at con-
Solution definition fidence level 0, in this phase.
Achieve balance between needs and A.SOL.4 X X 302 The following table describes the activities that shall be
feasibility/cost/performance performed by the owner, depending on the confidence level:
Define obsolescence strategy A.SOL.6 X X
Design Table A4 Construction Phase Confidence
Validate concept design documents A.DES.2 X X X activities Level
with stakeholders Ref 1 2 3
Acquisition Requirements engineering
Consult potential subcontractors for A.ACQ.1 X X X Manage change requests C.REQ.1 X X X
acquired components Validation
Validation Validate performances using a proto- C.VAL.1 X X
Use prototypes or simulations to A.VAL.2 X X type
validate concept Supportive processes
Supportive processes Track risks C.SUP.1 X X X
Identify relevant stakeholders A.SUP.2 X X X Decide and track risk mitigation C.SUP.2 X X
Obtain agreement with stakeholders A.SUP.3 X X X actions
on overall plan Establish a configuration manage- C.SUP.3 X X X
Establish work estimates based on A.SUP.4 X X X ment plan
task attributes Follow configuration management C.SUP.4 X X X
Define a strategy for risk manage- A.SUP.5 X X rules
ment Control processes during construction C.SUP.7 X X X
Identify Risks A.SUP.6 X X X Monitor project status against plan C.SUP.9 X X X
Identify and implement risk mitiga- A.SUP.7 X X
tion actions
Define a baseline of requirements A.SUP.8 X X X
Define processes to follow and A.SUP.9 X X X
setup process management activi-
ties
Assign an Independent Verifier A.SUP.10 X X
Chose a third party Independent A.SUP.11 X
Verifier
Determine Confidence Level A.SUP.12 X X X

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.4 – Page 25

A 400 Acceptance phase performed by the owner, depending on the confidence level:
401 No activities need to be performed by the owner at con-
fidence level 0, in this phase. Table A6 Owner Operations Ref Confidence
Activities Level
402 The following table describes the activities that shall be Ref 1 2 3
performed by the owner, depending on the confidence level:
Requirements engineering
Table A5 Owner Acceptance Confidence Level Manage change requests E.REQ.1 X X X
Activities Ref 1 2 3 Acquisition
Requirements engineering Manage and monitor obsolescence E.ACQ.1 X X
Manage change requests D.REQ.1 X X X Validation
Supportive processes Perform validation through opera- E.VAL.1 X X
tional scenarios
Establish a control system on D.SUP.3 X X X
deployed configuration Supportive processes
Control processes D.SUP.5 X X X Transfer Responsibility for system E.SUP.1 X X X
configuration management to oper-
Monitor project status against plan D.SUP.6 X X X ator
Track risks D.SUP.7 X X X Analyze impacts of modification E.SUP.5 X X X
Decide and track risks mitigation D.SUP.8 X X requests and decide changes
actions Control processes E.SUP.7 X X X
A 500 Operations phase Monitor project status against plan E.SUP.8 X X X
Track risks E.SUP.9 X X X
501 No activities need to be performed by the owner at con-
fidence level 0, in this phase. Decide and track risks mitigation E.SUP.10 X X
actions
502 The following table describes the activities that shall be

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 26 – Ch.2 Sec.5

SECTION 5
ISDS REQUIREMENTS FOR OPERATORS

A. Phases A 200 Engineering phase

201 No activities need to be performed by the operator at
A 100 Concept phase confidence level 0, in this phase.
101 The following table describes the activities that shall be 202 The following table describes the activities that shall be
performed by the operator, regardless of the confidence level: performed by the operator, depending on the confidence level:
Table A1 Operator Mandatory activities
Table A3 Operator Engineering Ref Confidence Level
Supportive processes Phase activities 1 2 3
Identify risks A.SUP.6
Requirements engineering
102 The following table describes the activities that shall be Detail operational scenarios by com- B.REQ.3 X X
performed by the operator, depending on the confidence level: ponent
Table A2 Operator Concept Phase Ref Confidence Level Validation
activities 1 2 3 Define validation strategy B.VAL.1 X X
Supportive processes
Requirements engineering Review and update risks B.SUP.3 X X X
Contribute to requirements collec- A.REQ.2 X X X Decide and track risk mitigation B.SUP.4 X X
tion. actions
Contribute to mission, objectives, A.REQ.5 X X Establish a baseline of requirements B.SUP.6 X X X
shared vision and operational con- and design
cept and scenarios definition.
Control processes B.SUP.7 X X X
Solution definition
Establish project plan B.SUP.9 X X X
Evolve needs and operational sce- A.SOL.5 X X
narios with design Monitor project status against plan B.SUP.1 X X X
0
Define Obsolescence strategy A.SOL.6 X X
Design A 300 Construction phase
Validate concept design documents A.DES.2 X X X 301 No activities need to be performed by the operator at
with stakeholders confidence level 0, in this phase.
Acquisition 302 The following table describes the activities that shall be
Consult potential subcontractors for A.ACQ.1 X X X performed by the operator, depending on the confidence level:
acquired components
Validation Table A4 Operator Construction Ref Confidence Level
Present the concept of the system to A.VAL.1 X X X Phase activities 1 2 3
the users
Use prototypes or simulations to val- A.VAL.2 X X Requirements engineering
idate concept Manage Change requests C.REQ.1 X X X
Supportive processes Validation
Obtain agreement with stakeholders A.SUP.3 X X X Validate performances using a proto- C.VAL.1 X X
on overall plan type
Establish work estimates based on A.SUP.4 X X X Supportive processes
task attributes
Track risks C.SUP.1 X X X
Identify and implement risk mitiga- A.SUP.7 X X
tion actions Decide and track risks mitigation C.SUP.2 X X
actions
Define a baseline of requirements A.SUP.8 X X X
Establish a configuration manage- C.SUP.3 X X X
Define processes to follow and setup A.SUP.9 X X X ment plan
process management activities
Follow configuration management C.SUP.4 X X X
rules
Control processes during construc- C.SUP.7 X X X
tion
Monitor project status against plan C.SUP.9 X X X

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.5 – Page 27

A 400 Acceptance phase A 500 Operations phase

401 No activities need to be performed by the operator at 501 No activities need to be performed by the operator at
confidence level 0, in this phase. confidence level 0, in this phase.
402 The following table describes the activities that shall be 502 The following table describes the activities that shall be
performed by the operator, depending on the confidence level: performed by the operator, depending on the confidence level:
Table A5 Operator Acceptance Ref Confidence Level Table A6 Operator Operations Ref Confidence Level
Phase activities 1 2 3 Phase activities 1 2 3
Requirements engineering Requirements engineering
Manage change requests D.REQ.1 X X X Manage change requests E.REQ.1 X X X
Validation Validation
Perform validation through opera- D.VAL.1 X X Perform validation through opera- E.VAL.1 X X
tional scenarios tional scenarios
Analyze results with respect to qual- D.VAL.2 X X Reliability, Availability, Maintaina-
ity targets bility and Safety
Supportive processes Monitor Operations and Report E.RAMS.1 X X
Establish a control system on D.SUP.3 X X X Incidents
deployed configuration Supportive processes
Control processes D.SUP.5 X X X Transfer responsibility for system E.SUP.1 X X X
Monitor project status against plan D.SUP.6 X X X configuration management to oper-
ator
Track risks D.SUP.7 X X X
Define procedures for maintenance E.SUP.2 X X X
Decide and track risks mitigation D.SUP.8 X X activities
actions
Perform operational testing after E.SUP.3 X X X
upgrading
Manage change requests during E.SUP.4 X X X
maintenance
Analyze impacts of modification E.SUP.5 X X X
requests and decide changes
Perform configuration audits E.SUP.6 X X X
Control processes during operation E.SUP.7 X X X
Monitor project status against plan E.SUP.8 X X X
Track risks E.SUP.9 X X X
Decide and track risks mitigation E.SUP.10 X X
actions
Perform joint project milestone E.SUP.11 X X
reviews, for significant issues

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 28 – Ch.2 Sec.6

SECTION 6
ISDS REQUIREMENTS FOR SYSTEM INTEGRATORS

A. Phases Table A2 System Integrator Confidence Level

Concept Phase activities Ref 1 2 3
A 100 Concept phase Verify completeness of system A.VER.2 X X X
101 The following table describes the activities that shall be requirements allocation
performed by the system integrator, regardless of the confi- Validation
dence level: Present the concept of the system A.VAL.1 X X
to the users
Table A1 System Integrator Mandatory activities Use prototypes or simulations to A.VAL.2 X X
Requirements engineering validate concept
Collect requirements A.REQ.1 Reliability, Availability, Maintain-
Supportive processes ability and Safety
Identify risks A.SUP.6 Determine rules, standards and A.RAMS.1 X X
laws applicable
102 The following table describes the activities that shall be Qualify RAMS Environment A.RAMS.2 X X
performed by the system integrator, depending on the confi- Collect Reliability, availability, A.RAMS.3 X X
dence level: maintainability and safety related
requirements
Table A2 System Integrator Confidence Level Supportive processes
Concept Phase activities Ref 1 2 3 Establish and maintain the devel- A.SUP.1 X X X
Requirements engineering opment Plan of the system, includ-
ing high level master schedule
Collect requirements A.REQ.1 X X X
Identify relevant stakeholders A.SUP.2 X X X
Translate needs into product A.REQ.3 X X
requirements Obtain agreement with stakehold- A.SUP.3 X X X
ers on overall plan
Define Mission, objectives, shared A.REQ.4 X X
vision and operational concept and Establish Work estimates based on A.SUP.4 X X X
scenarios. task attributes
Establish and document Functional A.REQ.6 X X Define a Strategy for Risk Man- A.SUP.5 X X
architecture agement
Describe allocation of functions to A.REQ.7 X X X Identify Risks A.SUP.6 X X X
ISDS Elements Identify and implement Risks miti- A.SUP.7 X X
Use traceability matrix to ensure A.REQ.8 X X X gation actions
completeness and consistency Define a baseline of requirements A.SUP.8 X X X
Solution definition Define processes to follow and A.SUP.9 X X X
Select solution for system design A.SOL.1 X X setup process management activi-
using criteria ties
Establish top level architecture A.SOL.2 X X X Assign an Independent Verifier A.SUP.10 X X
Perform Make/buy/reuse analysis A.SOL.3 X X A 200 Engineering phase
Achieve balance between needs A.SOL.4 X X 201 No activities need to be performed by the system inte-
and feasibility/cost/performance
grator at confidence level 0, in this phase.
Evolve needs and operational sce- A.SOL.5 X X
narios with design 202 The following table describes the activities that shall be
Define obsolescence strategy A.SOL.6 X X performed by the system integrator, depending on the confi-
dence level:
Design
Document System design A.DES.1 X X Table A3 System Integrator Confidence Level
Validate concept design docu- A.DES.2 X X X Engineering Phase activities Ref 1 2 3
ments with stakeholders
Requirements engineering
Implementation
Refine system Requirements into B.REQ.1 X X
Develop simulators or prototypes A.IMP.1 X X components requirements
to validate concept
Detail use cases and operational B.REQ.2 X X
Acquisition scenarios by component
Consult potential subcontractors A.ACQ.1 X X X Maintain Traceability of require- B.REQ.4 X X X
for acquired components ments including refined require-
Analyze subcontractors proposals A.ACQ.2 X X ments
to evolve design Solution definition
Integration Establish Technical solution and B.SOL.1 X X
Define roles, responsibilities, A.INT.1 X X X provide physical layout view
boundaries and exclusions for inte- Verify consistency of design with B.SOL.2 X X
gration activities, for each ISDS operational scenarios
element
Achieve Balance between technical B.SOL.3 X X
Verification constraints and system objectives
Verify Consistency of customer A.VER.1 X X X
and product requirements

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.6 – Page 29

Table A3 System Integrator Confidence Level Table A4 System Integrator Confidence

Engineering Phase activities Ref 1 2 3 Construction Phase activities Level
Maintain system design documen- B.SOL.4 X X Ref 1 2 3
tation Requirements engineering
Establish canonical data model B.SOL.5 X X X Manage change requests C.REQ.1 X X X
Design Maintain requirements traceability C.REQ.2 X X X
Document component interfaces B.DES.2 X X Solution definition
Design into independent compo- B.DES.4 X Manage changes to the technical solu- C.SOL.1 X X X
nents. tion.
Implementation Implementation
Develop prototypes to reduce B.IMP.1 X X Define quality targets and track quality C.IMP.4 X X
design or integration risks status.
Acquisition Ensure interfaces are free of deadlock C.IMP.5 X X
Select Subcontractors B.ACQ.1 X X X Design without single point of failure C.IMP.6 X X
Select COTS B.ACQ.2 X X X Obtain complete understanding of inter- C.IMP.7 X X
Establish Contract with subcontrac- B.ACQ.3 X X X faces
tors Acquisition
Establish COTS acquisition con- B.ACQ.5 X X X Monitor contracts execution with sup- C.ACQ.1 X X X
tract pliers
Select COTS based on obsoles- B.ACQ.6 X X Manage contract changes C.ACQ.2 X X X
cence criteria Ensure visibility on suppliers activities C.ACQ.3 X X
Integration Review intermediate deliverables from C.ACQ.4 X X
Review consistency of interfaces B.INT.1 X X subcontractors
design Accept deliverables from subcontrac- C.ACQ.5 X X X
Define Integration strategy B.INT.2 X X tors
Verification Accept and ensure transition of acquired C.ACQ.7 X X X
Review completeness of design B.VER.1 X X X COTS
with respect to requirements and Integration
design rules Provide integration, validation & verifi- C.INT.1 X X
Define Verification strategy B.VER.2 X X cation environments
Validation Transfer components to integration C.INT.2 X X X
Define Validation strategy B.VAL.1 X X after decision to release
Validate design by prototyping B.VAL.2 X X Check Readiness status of components C.INT.3 X X
before integration
Reliability, Availability, Maintaina-
bility and Safety Assemble the components C.INT.4 X X
Identify RAMS risks and priorities B.RAMS.1 X X X Perform Integration tests C.INT.5 X X
Identify mitigation actions for B.RAMS.2 X X Maintain canonical data model C.INT.6 X X X
selected events leading to major Verification
failures Perform peer-reviews on software and C.VER.1 X X
Perform FMECA on critical func- B.RAMS.3 X documents
tions Detail procedures for testing C.VER.2 X X
Perform independent Criticality B.RAMS.4 X Perform verification on developed com- C.VER.3 X X
Analysis. ponents
Supportive processes Perform verification tests C.VER.4 X X
Integrate master plan for develop- B.SUP.1 X X X Ensure test coverage as specified (state- C.VER.5 X X
ment and stakeholders plans ments and data coupling)
Review and update risks B.SUP.3 X X X Ensure test coverage as specified (MC/ C.VER.6 X
Decide and track Risks mitigation B.SUP.4 X X DC)
actions Perform Code Analysis C.VER.7 X X
Allocate resources to integration/ B.SUP.5 X X X Validation
verification/validation tasks
Validate performances using a proto- C.VAL.1 X X
Establish a baseline of requirements B.SUP.6 X X X type
and design
Reliability, Availability, Maintainabil-
Control processes B.SUP.7 X X X ity and Safety
Establish project plan B.SUP.9 X X X Evaluate Components and modules C.RAMS.1 X X
Monitor project status against plan B.SUP.10 X X X against RAMS requirements
Ensure no interference between C.RAMS.2 X X X
A 300 Construction phase Confidence Level of functions
301 No activities need to be performed by the system inte- Protect Network against domination C.RAMS.3 X X
grator at confidence level 0, in this phase. Provide secondary means C.RAMS.4 X
302 The following table describes the activities that shall be of operation for critical functions
performed by the system integrator, depending on the confi- Supportive processes
dence level: Track risks C.SUP.1 X X X
Decide and track risks mitigation C.SUP.2 X X
actions

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 30 – Ch.2 Sec.6

Table A4 System Integrator Confidence A 500 Operations phase

Construction Phase activities Level 501 No activities need to be performed by the system inte-
(Continued) Ref 1 2 3 grator at confidence level 0, in this phase.
Establish a configuration management C.SUP.3 X X X 502 The following table describes the activities that shall be
plan performed by the system integrator, depending on the confi-
Follow configuration management rules C.SUP.4 X X X dence level:
Establish a release note for ISDS C.SUP.6 X X X
Control processes during construction C.SUP.7 X X X Table A6 System Integrator Confidence
Operations Phase activities Level
Monitor project status against plan C.SUP.9 X X X
Ref 1 2 3
A 400 Acceptance phase Requirements engineering
401 No activities need to be performed by the system inte- Manage Change requests E.REQ.1 X X X
grator at confidence level 0, in this phase. Solution definition
Manage changes to the technical solu- E.SOL.1 X X X
402 The following table describes the activities that shall be tion.
performed by the system integrator, depending on the confi- Implementation
dence level: Implement changes to the system in a E.IMP.1 X X X
controlled manner
Table A5 System Integrator Confidence Acquisition
Acceptance Phase activities Level
Accept deliverables from suppliers E.ACQ.1 X X X
Ref 1 2 3
Verification
Requirements engineering
Perform verification on developed & E.VER.1 X X X
Manage Change requests D.REQ.1 X X X integrated components
Solution definition Validation
Manage changes to the technical solu- D.SOL.1 X X X Perform validation through opera- E.VAL.1 X X
tion. tional scenarios
Implementation Analyze results with respect to quality E.VAL.2 X X
Implement changes to the system in a D.IMP.1 X X X targets
controlled manner Perform black-box testing E.VAL.3 X X
Acquisition Reliability, Availability, Maintainabil-
Accept deliverables from suppliers D.ACQ.1 X X X ity and Safety
Verification Collect RAMS arguments and evi- E.RAMS.1 X X
Perform verification on developed & D.VER.1 X X X dence to demonstrate achievement of
integrated components RAMS objectives
Validation Supportive processes
Perform validation through opera- D.VAL.1 X X Establish a release note for the system E.SUP.1 X X X
tional scenarios that enters into operations
Analyze results with respect to quality D.VAL.2 X X Submit and decide components E.SUP.2 X X X
targets changes to Control board
Perform black-box testing D.VAL.3 X X Establish a control system on deployed E.SUP.3 X X X
configuration
Reliability, Availability, Maintaina-
bility and Safety Control Configuration during accept- E.SUP.4 X X X
ance in case of updating
Collect RAMS arguments and evi- D.RAMS.1 X X
dence to demonstrate achievement of Control processes E.SUP.5 X X X
RAMS objectives Monitor project status against plan E.SUP.6 X X X
Supportive processes Track risks E.SUP.7 X X X
Establish a release note for the system D.SUP.1 X X X Decide and track risks mitigation E.SUP.8 X X
that enters into operations actions
Submit and decide components D.SUP.2 X X X
changes to Control board
Establish a control system on D.SUP.3 X X X
deployed configuration
Control Configuration during accept- D.SUP.4 X X X
ance in case of updating
Control processes D.SUP.5 X X X
Monitor project status against plan D.SUP.6 X X X
Track risks D.SUP.7 X X X
Decide and track risks mitigation D.SUP.8 X X
actions

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.7 – Page 31

SECTION 7
ISDS REQUIREMENTS FOR SUPPLIERS

A. Phases Table A3 Supplier Engineering Confidence

Phase activities (Continued) Level
A 100 Concept phase Ref 1 2 3
101 The following table describes the activities that shall be Acquisition
performed by the supplier, regardless of the confidence level: Establish Contract with subcontrac- B.ACQ.3 X X X
tors
Table A1 Supplier Mandatory activities Select COTS based on obsoles- B.ACQ.6 X X
Supportive processes cence criteria
Identify risks A.SUP.6 Integration
Review consistency of interfaces B.INT.1 X X
102 The following table describes the activities that shall be design
performed by the supplier, depending on the confidence level: Supportive processes
Provide Estimation of work by B.SUP.2 X X X
Table A2 Supplier Concept Phase Confidence Level component
activities Ref 1 2 3 Review and update risks B.SUP.3 X X X
Acquisition Decide and track risk mitigation B.SUP.4 X X
actions
Consult potential subcontractors for A.ACQ.1 X X X
acquired components Establish a baseline of require- B.SUP.6 X X X
ments and design
Submit proposals to system integra- A.ACQ.3 X X X
tor with compliance status Control processes B.SUP.7 X X X
Integration Establish project plan B.SUP.9 X X X
Define roles, responsibilities, A.INT.1 X X X Monitor project status against plan B.SUP.10 X X X
boundaries and exclusions for inte-
gration activities, for each ISDS ele- A 300 Construction phase
ment 301 No activities need to be performed by the supplier at
Supportive processes confidence level 0, in this phase.
Obtain agreement with stakeholders A.SUP.3 X X X 302 The following table describes the activities that shall be
on overall plan performed by the supplier, depending on the confidence level:
Establish Work estimates based on A.SUP.4 X X X
task attributes Table A4 Supplier Construction Confidence Level
Define processes to follow and setup A.SUP.9 X X X Phase activities Ref 1 2 3
process management activities
Requirements engineering
A 200 Engineering phase Manage change requests C.REQ.1 X X X
Solution definition
201 No activities need to be performed by the supplier at
Manage changes to the technical C.SOL.1 X X X
confidence level 0, in this phase. solution.
202 The following table describes the activities that shall be Design
performed by the supplier, depending on the confidence level: Refine design during implementa- C.DES.1 X X
tion if needed
Table A3 Supplier Engineering Confidence Implementation
Phase activities Level Develop the components from C.IMP.1 X X X
Ref 1 2 3 design
Requirements engineering Develop support documentation C.IMP.2 X X
Refine system Requirements into B.REQ.1 X X Perform Unit testing for components C.IMP.3 X X X
components requirements Define Quality targets and track C.IMP.4 X X
Detail use cases and operational B.REQ.2 X X quality status.
scenarios by component Obtain complete understanding of C.IMP.7 X X
Maintain Traceability of require- B.REQ.4 X X X interfaces
ments including refined require- Integration
ments
Maintain canonical data model C.INT.6 X X X
Solution definition
Acquisition
Establish Technical solution and B.SOL.1 X X
provide physical layout view Manage Contract changes C.ACQ.2 X X X
Establish canonical data model. B.SOL.5 X X X Accept deliverables from subcon- C.ACQ.5 X X X
tractors
Implementation
Ensure transition of delivered prod- C.ACQ.6 X X X
Develop prototypes to reduce B.IMP.1 X X uct
design or integration risks
Verification
Design
Perform peer-reviews on software C.VER.1 X X
Design each component B.DES.1 X X and documents
Document component interfaces B.DES.2 X X
Document component design B.DES.3 X X

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 32 – Ch.2 Sec.7

Table A4 Supplier Construction Confidence Level A 500 Operations phase

Phase activities (Continued) Ref 1 2 3 501 There are no mandatory activities that shall be per-
Perform verification on developed C.VER.3 X X formed by the supplier, regardless of the confidence level.
components 502 The following table describes the activities that shall be
Ensure test coverage as specified C.VER.5 X X performed by the supplier, depending on the confidence level:
(statements and data coupling)
Ensure test coverage as specified C.VER.6 X Table A6 Supplier Operations Confidence Level
(MC/DC) Phase activities Ref 1 2 3
Perform Code Analysis C.VER.7 X X Requirements engineering
Reliability, Availability, Maintaina- Manage change requests E.REQ.1 X X X
bility and Safety
Solution definition
Evaluate Components and modules C.RAMS X X
against RAMS requirements .1 Manage changes to the technical E.SOL.1 X X X
solution.
Supportive processes
Implementation
Track risks C.SUP.1 X X X
Implement changes to the system in a E.IMP.1 X X X
Decide and track risks mitigation C.SUP.2 X X controlled manner
actions
Verification
Establish a configuration manage- C.SUP.3 X X X
ment plan Perform verification on developed & E.VER.1 X X X
integrated components
Follow configuration management C.SUP.4 X X X
rules Supportive processes
Establish a release note for delivered C.SUP.5 X X X Establish a release note for the sys- E.SUP.1 X X X
components tem that enters into operations
Control Processes during construc- C.SUP.7 X X X Submit and decide components E.SUP.2 X X X
tion changes to the control board
Monitor project status against plan C.SUP.9 X X X Establish a control system on E.SUP.3 X X X
deployed configuration
A 400 Acceptance phase Control processes E.SUP.5 X X X
401 No activities need to be performed by the supplier at Monitor project status against plan E.SUP.6 X X X
confidence level 0, in this phase. Track risks E.SUP.7 X X X
402 The following table describes the activities that shall be Decide and track risks mitigation E.SUP.8 X X
performed by the supplier, depending on the confidence level: actions

Table A5 Supplier Acceptance Confidence Level

Phase activities Ref 1 2 3
Requirements engineering
Manage change requests D.REQ.1 X X X
Solution definition
Manage changes to the technical D.SOL.1 X X X
solution.
Implementation
Implement changes to the system in a D.IMP.1 X X X
controlled manner
Verification
Perform verification on developed & D.VER.1 X X X
integrated components
Supportive processes
Establish a release note for the sys- D.SUP.1 X X X
tem that enters into operations
Submit and decide components D.SUP.2 X X X
changes to the control board
Establish a control system on D.SUP.3 X X X
deployed configuration
Control processes D.SUP.5 X X X
Monitor project status against plan D.SUP.6 X X X
Track risks D.SUP.7 X X X
Decide and track risks mitigation D.SUP.8 X X
actions

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.2 Sec.8 – Page 33

SECTION 8
REQUIREMENTS FOR INDEPENDENT VERIFIERS

A. Phases A 300 Construction phase

A 100 Concept phase
101 Issue activity status report
102 No activities need to be performed by the independent
verifier at confidence level 0, in this phase.
301 No activities need to be performed by the independent
verifier at confidence level 0, in this phase.
302 The following table describes the activities that shall be
performed by the independent verifier, depending on the con-
fidence level:

Table A1 Independent Verifier Mandatory activities Table A4 Independent Verifier Confidence Level
There are no activities required at confidence level 0. Construction Phase activities Ref 1 2 3
Verification
103 The following table describes the activities that shall be
Perform independent code analy- C.VER.8 X
performed by the independent verifier, depending on the con- sis
fidence level:
Perform independent ISDS ele- C.VER.9 X
ment qualification
Table A2 Independent Confidence Level
Verifier Concept Phase Supportive processes
Ref 1 2 3
activities Independently control processes C.SUP.8 X X
Verification during construction
Independently verify overall A.VER.3 X A 400 Acceptance phase
design
401 No activities need to be performed by the independent
A 200 Engineering phase verifier at confidence level 0, in this phase.
201 No activities need to be performed by the independent 402 The following table describes the activities that shall be
verifier at confidence level 0, in this phase. performed by the independent verifier, depending on the con-
202 The following table describes the activities that shall be fidence level:
performed by the independent verifier, depending on the con-
fidence level: Table A5 Independent Verifier Confidence Level
Acceptance Phase activities Ref 1 2 3
Table A3 Independent Confidence Level Validation
Verifier Engineering Phase Ref 1 2 3 Perform independent validation & D.VAL.4 X
activities verification
Independently control processes D.SUP.9 X X
Verification
Perform independent selected B.VER.3 X X A 500 Operations phase
design reviews
Verify independently Technical B.VER.4 X
501 No activities need to be performed by the independent
Specification verifier at confidence level 0, in this phase.
Verify independently Design B.VER.5 X 502 The following table describes the activities that shall be
documents performed by the independent verifier, depending on the con-
Verify canonical data model B.VER.6 X X fidence level:
Reliability, Availability, Main-
tainability and Safety Table A6 Independent Verifier Confidence Level
Operations Phase activities Ref 1 2 3
Perform independent Criticality B.RAMS X
Analysis. .3 Validation
Supportive processes Perform independent validation & E.VAL.4 X
Independently control proc- B.SUP.8 X X verification
esses Independently control processes E.SUP.9 X X

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 34 – Ch.2 Sec.8

DET NORSKE VERITAS

 OFFSHORE STANDARD
DNV-OS-D203

INTEGRATED SOFTWARE- DEPENDENT SYSTEM

(TENTATIVE STANDARD)

CHAPTER 3

CLASSIFICATION AND CERTIFICATION

CONTENTS PAGE
Sec. 1 Introduction .............................................................................................................................. 37
Sec. 2 Information Requirements........................................................................................................ 38
Sec. 3 Approval and Assessment ........................................................................................................ 39
App. A Information Requirement Tables ............................................................................................. 41

DET NORSKE VERITAS

Veritasveien 1, NO-1322 Høvik, Norway Tel.: +47 67 57 99 00 Fax: +47 67 57 99 11
 Offshore Standard DNV-OS-D203, April 2010
Ch.3 Sec.1 – Page 37

SECTION 1
INTRODUCTION

A. General be included in the class notation. The list is not limitative, other
systems may be included.
A 100 General
101 This chapter provides the basis for DNV ISDS classifi- Table B2 System list
cation. System
102 A complete description of principles, procedures, appli- DP Dynamic Positioning System
cable class notations and technical basis for offshore classifi- ESD Emergency Shut Down System
cation is given by the offshore service specifications, see PCS Process Control System
Table A1. PMS Power Management System
CMS Conditioning Monitoring Systems
Table A1 Offshore Service Specifications
SPS Subsea Production System
Ident. No Title OTS Operator Training System
DNV-OSS-101 Rules for Classification of Offshore Drilling DS Drilling Systems
and
Support Units ST Steering
DNV-OSS-102 Rules for Classification of Floating Production, PROP Propulsion
Storage and Loading Units
B 300 Scope
301 The owner shall specify the systems in scope, prior to
reaching the first decision gate of the newbuilding or upgrade
B. Class Notation project.
B 100 General 302 The owner shall specify the confidence level, prior to
reaching the concept decision gate of the newbuilding or
101 Units built and tested in compliance with the require- upgrade project.
ments of this OS may be assigned one of the optional class
notations for integrated software-dependent systems shown in 303 The ISDS scope shall include the control functions for
Table B1. each system.

Table B1 Class notations B 400 Alterations and additions

ISDS1[system1,…,system n] Units having undergone enhanced 401 In case of alterations of the ISDS, it is the owner's obli-
software-dependent system integra- gation to apply and request application to all parties of the inte-
tion for the system(s) defined in the gration method as per the OS. The owner shall inform the
system list, at confidence level 1. Society about changes made to the software and/or the hard-
ISDS2[system1,…,system n] Units having undergone enhanced ware. The Society will consider the need for additional assess-
software-dependent system integra- ment, verification or testing in connection with such
tion for the system(s) defined in the alterations.
system list, at confidence level 2.
ISDS3[system1,…,system n] Units having undergone enhanced B 500 Raising/Reducing the confidence level
software-dependent system integra-
tion for the system(s) defined in the 501 The confidence levels are additive. Owners may request
system list, at confidence level 3. upgrading from level 1 to level 2 to level 3. There is no contra-
diction between the higher confidence levels and the lower
Guidance note: ones. DNV will assess the impacts in so doing and will revise
For example: the ISDS activities accordingly.
ISDS2[DP, PMS]: the functions of these systems have been 502 The higher confidence levels imply the lower ones: CL3
developed according to ISDS requirements at confidence level 2. implies CL2, CL1 and CL0. CL2 implies CL1 and CL0. Cl1
Ch.2 Sec2 B Table B1. The DP abbreviation refers to the system implies CL0.
itself and not to the class notations such as DYNPOS AUTR etc.
The ISDS class notation does not replace but is complementary
to other class notations. B 600 Alternative integration process and method
requirements
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
601 Alternative integration methods to the ISDS process
described in this OS may be accepted when the overall confi-
B 200 System list dence level is found to be equivalent or better than that of
201 Table B2 below provides examples of systems that can this OS.

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 38 – Ch.3 Sec.2

SECTION 2
INFORMATION REQUIREMENTS

A. General 103 A record of as maintained documentation shall be stored

onboard the unit.
A 100 Information related to Integrated Software
Dependant Systems Guidance note:
As a replacement to paper documentation, the information stored
101 Information requirements for each role are listed in on board the unit may be available within a secure Electronic
Appendix A.
Documentation Management System.
102 A stamped record of as built documentation shall be
stored onboard the unit. ---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---

DET NORSKE VERITAS


SECTION 3
APPROVAL AND ASSESSMENT
A. General
A 100 General
101 The purpose of the classification process is to assure that
the process and method requirements are satisfied in practice.
Objective evidence shall be provided by all responsible parties
involved in the integration of the integrated software-depend-
ent systems. Objective evidence shall include documentation,
electronic information and information gathered from inter-
views with personnel directly performing the activities.
102 In order to obtain the ISDS notation, it shall be demon-
strated to the satisfaction of the Society that the activities
required by the processes are effectively and efficiently
applied in practice.
A 200 Process
201 The classification process shall include approval, assess-
ment and renewal activities to assure the process and method
requirements are satisfied in practice.
202 The responsible parties involved in the project shall pro-
vide suitable support for the execution of the classification
process.
A 300 Responsible parties
301 For the purpose of applying the process and method
requirements, the parties shall be identified by responsibility
and scope.
302 A given responsible party may have several responsibil-
ities, as defined previously.
Guidance note:
An organization may deliver both an integrated system and indi-
vidual equipment within the system and shall apply both system
integrator and supplier responsibilities, for this ISDS.
---e-n-d---of---G-u-i-d-a-n-c-e---n-o-t-e---
303 Within a responsible party, the responsibilities and
scope shall be assigned to individual persons or collective
teams, as appropriate.
A 400 Findings
401 There are four types of findings on activities: compli-
ance, weakness, non-compliance and observation.
402 A compliance records an effective implementation of
one or more activities of the integration method, at the time of
record.
403 A weakness records a partial implementation of one or
more activities of the integration method, at the time of record.
404 A non-compliance records a theoretical, ineffective or
lack of implementation of one or more activities of the integra-
tion method, at the time of record.
405 Observations are findings out of scope of the integration
method which may however have an impact on the integration
or assessment. Observations shall be taken into account by the
responsible parties.
406 In the assessment report compliance is represented by
the colour green, weakness by the colour orange and non-com-
pliance by the colour red.
DET NORSKE VERITAS
Offshore Standard DNV-OS-D203, April 2010
Ch.3 Sec.3 – Page 39
B. Approval of Activities
B 100 General
101 Approval is conducted on each activity.
102 Approvals result in findings for each responsibility and
process area, for the target confidence level, based on evidence
(documentation, information and interviews) provided by the
responsible parties.
103 Based on the findings, activities are rated as either:
implemented, partially implemented, not implemented or not
yet performed. The approval rating may be performed in each
phase.
104 Implemented activities are deemed implemented as
assessed by the approver, based on the evidence provided for
approval or for information.
105 Additional information may be required to each respon-
sible party by the approver to assess the implementation of the
activities in practice.
106 Process approval shall be performed during phases A
to C.
107 Process approval may be performed during phases D
and E, for changes to the system or the process deemed critical
by the Society.
C. Assessment of Phases
C 100 General
101 An assessment concludes each phase.
102 Assessments result in findings for the phase, the confi-
dence level, each responsibility and process area, based on evi-
dence (information and interviews) provided by the
responsible parties.
103 The Society shall participate in the defined decision
gates for each phase and shall issue an activity status report.
104 Non-compliance assessment findings may result in the
Society rejecting the gate passage.
105 The certificate of compliance to the DNV-OS-D201
may be used by the Society as an alternate means for process
assessment, when deemed relevant by the Society.
C 200 Concept and engineering assessment
201 The Society shall participate in the concept and engi-
neering decision gates.
202 The Society shall assessment the activities of the respon-
sible parties for the phases.
C 300 Construction assessment
301 The Society shall participate in the construction decision
gate
302 The Society shall assessment the activities of the respon-
sible parties for the phases.
C 400 Commissioning assessment
401 The Society shall participate in the commissioning deci-
sion gate.
402 The Society shall assess the activities of the responsible
parties for the phase.
403 On successful completion of the commissioning phase,
Offshore Standard DNV-OS-D203, April 2010
Page 40 – Ch.3 Sec.3

the class notation may be assigned to the unit.
C 500 In operation assessment
501 Yearly, the Society shall perform an assessment focus-
ing on maintenance and configuration management.
502 Every 5 years, the Society shall perform a renewal
assessment, reviewing responsible party activities and required
information. Important changes to the process or to the ISDS
systems may require an early renewal assessment.

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 41

APPENDIX A
INFORMATION REQUIREMENT TABLES

A. Owner Information Requirements for each activity to be performed. Such outcomes are expected
by the latest before the end of the phase, and may be delivered
The following table presents the information requirements to DNV or reviewed onsite. Sufficient delay shall be provided
applicable to the owner role. At least one outcome is expected for performing the review and assessment.

Table A1 Owner information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z050 Unit/System design intention and philosophy A 0 A.REQ.2
System - vision of unit/system A.REQ.5
- rationale of business/safety/environmental added value
- description of unit/system overall behaviour

Unit Z040 Owner/Operator requirements: A 0 A.REQ.2

System - operational needs,
- functional needs,
- non-functional needs and technical constraints,
- prototypes

Unit Z290 Clarification records: A 0 A.REQ.2

System - Owner/Operator requirements clarification records A.REQ.5
- Owner/Operator mission and scenario clarification records

Unit Q010 Project risk list: A 2 A.SOL.4

System - risk list related to requirements and schedule/cost/performance A.SOL.6
consistency A.SUP.6
- obsolescence risk list (HW & SW)

Unit Z290 Unit/System design verification & validation report (by Owner rep- A 1 A.DES.2
System resentatives)
System Z040 System request for proposal (RfP): A 1 A.ACQ.1
Equipment - functional specifications,
- GSRs
System Z290 System concept presentation: A 2 A.VAL.1
- Simulations, A.VAL.2
- Prototypes.
- Minutes of System Concept Review Meeting.

Unit Q010 Table of organization for each stakeholder: A 1 A.SUP.2

System - roles,
Equipment - names,
- contact information,
- responsibilities.

Unit Q010 Master plan A 1 A.SUP.3

System - WBS A.SUP.4
- technical attributes used for estimating,
- effort and costs estimates.
- deliverables,
- milestones

Unit Q010 Master schedule A 1 A.SUP.3

System
Unit Q010 Risk management procedure A 2 A.SUP.5
System
Unit Q010 Risk management plan: A 2 A.SUP.7
System - mitigation actions,
Equipment - follow-up records
Unit Z290 System requirements baseline A 1 A.SUP.8
System
Unit Q020 System requirements change management process documents A 1 A.SUP.9
System

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 42 – Ch.3 App.A

Table A1 Owner information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Q010 Project Management Plan A 1 A.SUP.9
System - tailored procedures for the project.
Equipment Quality manual
Software - organization procedures for each process area.

Unit Q010 Quality manual A 1 A.SUP.9

System - organization procedures for each process area.
Equipment
Software

Unit Z290 Quality control records A 1 A.SUP.9

System
Equipment
Software

Unit Z290 Project control records A 1 A.SUP.9

System
Equipment
Software

Unit Z290 Minutes of meetings, E-mails and other relevant information A 1 A.SUP.9
System
Equipment
Software

Unit Q010 Independent Verifier management plan A 2 A.SUP.10

System
Unit Q010 Independent Verifier RfP and Contract (technical and organizational A 3 A.SUP.11
System elements)
Unit Z040 Confidence level matrix for ISDS in scope and justification docu- A 0 A.SUP.12
System ment
Unit Z290 Minutes of milestone meetings A 1 A.SUP.13
System
System Z040 System main contractor selection matrix B 1 B.ACQ.4
Equipment System main contractor contract
System Z250 System validation plan B 2 B.VAL.1
Equipment
Unit Q010 Project risk management plan (updated) B 1 B.SUP.3
System - risk list
Unit Q010 Project risk management plan (updated) B 2 B.SUP.4
System - risk list,
- mitigation actions,
- follow-up records

Unit Z290 System requirements baseline (updated) B 1 B.SUP.6

System System design baseline
Revision history of requirements and design
Differences between baselines

Unit Z290 Quality control records B 1 B.SUP.7

System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software

Unit Q010 Master plan B 1 B.SUP.9

System
Unit Q010 Master schedule B 1 B.SUP.9
System
Unit Z290 Minutes of review meetings B 1 B.SUP.10
System Minutes of milestone meetings. B.SUP.11
Unit Z290 System requirements baseline (updated) C 1 C.REQ.1
System System design baseline (updated) C.SUP.4
Change Requests
Change Orders

Unit Q020 Commission board table of organisation C 1 C.REQ.1

System Change management procedure C.SUP.4

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 43

Table A1 Owner information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z290 Prototype performance validation report C 2 C.VAL.1
Equipment - validation scenarios of prototype's performance & expected results
- performance results
- analysis of results against expected

Unit Q010 Project risk management plan (updated) C 1 C.SUP.1

System - risk list
Unit Q010 Project risk management plan (updated) C 2 C.SUP.2
System - risk list
- mitigation actions,
- follow-up records

Unit Q020 Configuration management plan C 1 C.SUP.3

System
Unit Z290 Quality control records C 1 C.SUP.7
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software

Unit Q010 Master plan (updated) C 1 C.SUP.9

System
Unit Q010 Master schedule (updated) C 1 C.SUP.9
System
Unit Z290 Project status report C 1 C.SUP.9
System Project action list
Equipment
Software

Unit Z290 Minutes of review meetings C 1 C.SUP.10

System Minutes of milestone meetings.
Unit Z290 System requirements baseline (updated) D 1 D.REQ.1
System System design baseline (updated) D.SUP.3
Change Requests
Change Orders

Unit Q010 Project risk management plan (updated) D 1 D.SUP.7

System - risk list
Unit Q010 Project risk management plan (updated) D 2 D.SUP.8
System - risk list
- mitigation actions,
- follow-up records

Unit Q020 Configuration management plan D 1 D.SUP.3

System
Unit Z290 Quality control records D 1 D.SUP.5
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software

Unit Q010 Master plan (updated) D 1 D.SUP.6

System D.SUP.10
Unit Q010 Master schedule (updated) D 1 D.SUP.6
System D.SUP.10
Unit Z290 Project status report C 1 D.SUP.6
System Project action list
Equipment
Software

Unit Z290 Minutes of review meetings D 1 D.SUP.10

System Minutes of milestone meetings. D.SUP.10
Unit Z290 System requirements baseline (updated) E 1 E.REQ.1
System System design baseline (updated) E.SUP.5
Change requests
Impact analyses
Change orders

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 44 – Ch.3 App.A

Table A1 Owner information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Q010 Obsolescence management plan: E 2 E.ACQ.1
System - Authorized vendor list,
- Spare parts list (HW & SW),
- Alternate spare parts list,
- Management of intellectual property.

Unit Z290 Validation Reports E 2 E.VAL.1

System Validation Issue List
Unit Q010 Project risk management plan (updated) E 1 E.SUP.9
System - risk list
Unit Q010 Project risk management plan (updated) E 2 E.SUP.10
System - risk list
- mitigation actions,
- follow-up records

Unit Q020 Configuration management plan E 1 E.SUP.1

System
Unit Z290 Quality control records E 1 E.SUP.7
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software

Unit Q010 Master plan (updated) E 1 E.SUP.8

System
Unit Q010 Master schedule (updated) E 1 E.SUP.8
System
Unit Z290 Minutes of review meetings E 1 E.SUP.8
System E.SUP.11

B. Operator Information Requirements each activity to be performed. Such outcomes are expected by
the latest at the end of the phase, and may be delivered to DNV
The following table presents the information requirements or reviewed onsite.
applicable to the operator role. An outcome is expected for

Table B1 Operator information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z040 Owner/Operator requirements: A 0 A.REQ.2
System - operational needs, A.SOL.5
- functional needs,
- non-functional needs and technical constraints,
- prototypes
Unit Z050 Unit/System design intention and philosophy A 0 A.REQ.2
System - vision of unit/system A.REQ.5
- rationale of business/safety/environmental added value
- description of unit/system overall behaviour
Unit Z290 Clarification records: A 0 A.REQ.2
System - Owner/Operator requirements clarification records A.REQ.5
- Owner/Operator mission and scenario clarification records
Unit Q010 Project risk list: A 2 A.SUP.6
System - risk list related to requirements and schedule/cost/performance con- A.SOL.6
sistency
- obsolescence risk list (HW & SW)
Unit Z290 Unit/System design verification & validation report (by Operator rep- A 1 A.DES.2
System resentatives)
System Z040 Contribution of Operator to System request for proposal (RfP): A 1 A.ACQ.1
Equipment - functional specifications,
- GSRs
(focus on operations phase)
System Z290 System concept presentation: A 2 A.VAL.1
- Simulations, A.VAL.2
- Prototypes.
- Minutes of System Concept Review Meeting.

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 45

Table B1 Operator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Q010 Contribution of Operator to Master plan A 1 A.SUP.3
System - WBS A.SUP.4
- technical attributes used for estimating,
- effort and costs estimates.
- deliverables,
- milestones
Unit Q010 Contribution of Operator to Master schedule A 1 A.SUP.3
System
Unit Q010 Risk management procedure A 2 A.SUP.6
System
Unit Q010 Risk management plan: A 2 A.SUP.7
System - mitigation actions,
Equipment - follow-up records
Unit Z290 Acceptance by Operator of System requirements baseline A 1 A.SUP.8
System
Unit Q020 System requirements change management process documents A 1 A.SUP.8
System
Unit Q010 Project Management Plan A 1 A.SUP.9
System - tailored procedures for the project.
Equipment
Software
Unit Q010 Quality manual A 1 A.SUP.9
System - organization procedures for each process area.
Equipment
Software
Unit Z290 Quality control records A 1 A.SUP.9
System
Equipment
Software
Unit Z290 Project control records A 1 A.SUP.9
System
Equipment
Software
Unit Z290 Minutes of meetings, E-mails and other relevant information A 1 A.SUP.9
System
Equipment
Software
Unit Z290 Minutes of milestone meetings A 1 A.SUP.13
System
Unit Z040 Operational use cases and scenarios: A 0 B.REQ.3
System - detailed to the component level.
System Z250 System validation plan B 2 B.VAL.1
Equipment
Unit Q010 Project risk management plan (updated) B 1 B.SUP.3
System - risk list
Unit Q010 Project risk management plan (updated) B 2 B.SUP.4
System - risk list
- mitigation actions,
- follow-up records
Unit Z290 System requirements baseline (updated) B 1 B.SUP.6
System System design baseline
Revision history of requirements and design
Differences between baselines
Unit Z290 Quality control records B 1 B.SUP.7
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software
Unit Q010 Master plan B 1 B.SUP.9
System
Unit Q010 Master schedule B 1 B.SUP.9
System
Unit Z290 Minutes of review meetings B 1 B.SUP.10
System Minutes of milestone meetings. B.SUP.11

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 46 – Ch.3 App.A

Table B1 Operator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z290 System requirements baseline (updated) C 1 C.REQ.1
System System design baseline (updated) C.SUP.4
Change Requests
Change Orders
Unit Q020 Commission board table of organisation C 1 C.REQ.1
System Change management procedure C.SUP.4
System Z290 Prototype performance validation report C 2 C.VAL.1
Equipment - validation scenarios of prototype's performance & expected results
- performance results
- analysis of results against expected
Unit Q010 Project risk management plan (updated) C 1 C.SUP.1
System - risk list
Unit Q010 Project risk management plan (updated) C 2 C.SUP.2
System - risk list
- mitigation actions,
- follow-up records
Unit Q020 Configuration management plan C 1 C.SUP.3
System
Unit Z290 Quality control records C 1 C.SUP.7
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software
Unit Q010 Master plan (updated) C 1 C.SUP.9
System
Unit Q010 Master schedule (updated) C 1 C.SUP.9
System
Unit Z290 Project status report C 1 C.SUP.9
System Project action list
Equipment
Software
Unit Z290 Minutes of review meetings C 1 C.SUP.10
System Minutes of milestone meetings.
Unit Z290 System requirements baseline (updated) D 1 D.REQ.1
System System design baseline (updated) D.SUP.3
Change Requests
Change Orders
Unit Z290 Validation Reports D 2 D.VAL.1
System Validation Issue List D.VAL.2
Unit Q010 Project risk management plan (updated) D 1 D.SUP.7
System - risk list
Unit Q010 Project risk management plan (updated) D 2 D.SUP.8
System - risk list
- mitigation actions,
- follow-up records
Unit Q020 Configuration management plan D 1 D.SUP.3
System
Unit Z290 Quality control records D 1 D.SUP.5
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software
Unit Q010 Master plan (updated) D 1 D.SUP.6
System
Unit Q010 Master schedule (updated) D 1 D.SUP.6
System
Unit Z290 Minutes of review meetings D 1 D.SUP.6
System
Unit Z290 Project status report C 1 D.SUP.6
System Project action list
Equipment
Software
Unit Z290 Minutes of milestone meetings. D 1 D.SUP.10
System

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 47

Table B1 Operator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z290 System requirements baseline (updated) E 1 E.REQ.1
System System design baseline (updated) E.SUP.5
Change requests
Impact analyses
Change orders
Unit Q010 Obsolescence management plan: E 2 E.ACQ.1
System - Authorized vendor list,
- Spare parts list (HW & SW), stock
- Alternate spare parts list,
- Management of intellectual property,
- Maintenance procedures
Unit Z290 Obsolescence Management Records: E 2 E.ACQ.1
System - repair, replacement or upgrade records
Unit Z290 Test plans E 2 E.VAL.1
System Test reports E.SUP.3
Validation reports
Validation issue list
Unit Z290 Incident database E 2 E.RAMS.1
System Incident report
Equipment Incident analyses
Software
Unit Z250 RAMS measurement procedure E 2 E.RAMS.1
System - Critical RAMS parameters selection criteria
Equipment - Traceability matrix to RAMS objectives
Software - RAMS measurement acquisition, recording, processing and storage
procedures
- RAMS measurement system description
- RAMS measurement integrity assurance procedure
Unit Z290 RAMS measurement operational database E 2 E.RAMS.1
System - RAMS measures
Equipment - Analysis of RAMS measures against RAMS objectives
Software
Unit Z290 RAMS measurement archives (long-term storage) E 2 E.RAMS.1
System - RAMS measures (continuous up to previous assessment)
Equipment - RAMS archives configuration audit reports
Software
Unit Q010 Maintenance Management Plan A 1 E.SUP.2
System - tailored procedures for the maintenance E.SUP.4
Equipment Quality manual
Software - organization procedures for each process area, applicable for main-
tenance activities during operation.
Unit Q010 Project risk management plan (updated) E 1 E.SUP.9
System - risk list
Unit Q010 Project risk management plan (updated) E 2 E.SUP.10
System - risk list
- mitigation actions,
- follow-up records
Unit Q020 Configuration management plan E 1 E.SUP.4
System Sign-off of configuration management activities E.SUP.1
Unit Z290 Configuration audit reports E 1 E.SUP.6
System
Unit Z290 Quality control records E 1 E.SUP.7
System Project Control records E.SUP.8
Equipment Minutes of meetings, E-mails and other relevant information
Software
Unit Q010 Master plan (updated) E 1 E.SUP.8
System
Unit Q010 Master schedule (updated) E 1 E.SUP.8
System
Unit Z290 Minutes of review meetings E 1 E.SUP.8
System E.SUP.11

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 48 – Ch.3 App.A

C. System Integrator Information Requirements expected for each activity to be performed. Such outcomes are
expected by the latest at the end of the phase, and may be deliv-
The following table presents the information requirements ered to DNV or reviewed onsite.
applicable to the system integrator role. An outcome is

Table C1 System integrator information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z050 Unit/System design intention and philosophy A 0 A.REQ.1
System - vision of unit/system A.REQ.4
- rationale of business/safety/environmental added value
- description of unit/system overall behaviour
Unit Z040 Owner/Operator requirements: A 0 A.REQ.1
System - operational needs, A.REQ.4
- functional needs,
- non-functional needs and technical constraints,
- prototypes
Unit Z290 Clarification records: A 0 A.REQ.1
System - System Integrator requirements clarification records A.REQ.4
- System Integrator mission and scenario clarification records
System Z050 Product requirements: A 2 A.REQ.3
- functional requirements, including nominal behaviour and degraded
modes,
- non-functional requirements, including performance and RAMS
requirements,
System Z290 Product requirements: A 2 A.REQ.3
- traceability matrix to owner/operator requirements,
- consistency and completeness check records.
System Z050 Functional Architecture: A 2 A.REQ.6
Equipment - functional (or behaviour) specifications,
- architecture specifications,
- functional allocation to architecture matrix
Equipment Z050 Functional specification for each ISDS component A 1 A.REQ.7

Unit Z050 Traceability matrices: A 1 A.REQ.8

System - from Owner/Operator to Product requirements,
Equipment - from Product requirements to Functional specifications (where
applicable),
- from Functional specifications to component specifications
Unit Z290 Traceability matrices completeness and consistency review records A 1 A.REQ.8
System Minutes of meetings A.VER.1
Equipment A.VER.2
System Z250 System solution selection procedure A 2 A.SOL.1
System solution selection criteria
System Z050 Alternative system solutions A 2 A.SOL.1
- overall description
- advantages and drawbacks,
- selection criteria values
System Z050 System architecture: A 1 A.SOL.2
- equipment drawings A.DES.1
- functional drawings
- software drawings
- system architecture description (textual, or model)
Component Z290 Make/Buy/Reuse justification analyses, for each component A 2 A.SOL.3

System Z290 Feasibility/Cost assessment of alternatives A 2 A.SOL.4

Value analyses
System Z290 Impact analyses of solution on operational scenarios A 2 A.SOL.5
Value analyses
- different versions of operational mission description vs. solution
alternatives
System Z250 Obsolescence strategy document A 2 A.SOL.6
Equipment Manufacturer preferred equipment list
Unit Z290 Project risk list: A 2 A.SOL.4
System - risk list related to requirements and schedule/cost/performance con- A.SOL.6
sistency A.SUP.6
- obsolescence risk list (HW & SW)

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 49

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z050 System design: A 2 A.DES.1
- component (HW & SW) description,
- functional description
- interfaces description,
- network description,
- use cases,
- component interactions
Unit Z290 Unit/System design verification & validation report (by Owner rep- A 1 A.DES.2
System resentatives)
System Z290 System prototype A 2 A.IMP.1
System simulator A.VAL.2
Minutes of simulator/prototype reviews
System Z040 System request for proposal (RfP): A 1 A.ACQ.1
Equipment - functional specifications,
- GSRs
System Z290 Analysis of supplier proposals: A 1 A.ACQ.2
Equipment - selection criteria and threshold
- proposal values for each supplier
- analysis of strengths and weaknesses
- supplier proposal selection decision record
System Q010 Table of organization for integration of ISDS elements: A 1 A.INT.1
Equipment - roles,
- names,
- contact information,
- responsibilities.
System Q010 Table of organization for integration of ISDS elements: A 1 A.INT.1
Equipment - roles,
- names,
- contact information,
- responsibilities.
System Z290 System concept presentation: A 2 A.VAL.1
- Simulations,
- Prototypes.
- Minutes of System Concept Review Meeting.
Unit Q010 RAMS (at least Safety) management plan A 2 A.RAMS.1
System RAMS (Safety) design procedure
Equipment RAMS (Safety) training plan
RAMS (Safety) issue tracking and resolution procedure
Unit Q010 RAMS information management system A 2 A.RAMS.2
System RAMS issue management system
Equipment RAMS verification and validation environment qualification proce-
dure (and records)
RAMS systems integrity auditing procedure (and records)
System Z050 RAMS requirements A 2 A.RAMS.3
Equipment
Unit Q010 Table of organization for each stakeholder: A 1 A.SUP.2
System - roles,
Equipment - names,
- contact information,
- responsibilities.
Unit Q010 Master plan A 1 A.SUP.1
System - WBS A.SUP.3
- technical attributes used for estimating, A.SUP.4
- effort and costs estimates.
- deliverables,
- milestones
Unit Q010 Master schedule A 1 A.SUP.1
System A.SUP.3
Unit Q010 Risk management procedure A 2 A.SUP.5
System
Unit Q010 Project risk list A 2 A.SUP.6
System
Unit Q010 Risk management plan: A 2 A.SUP.7
System - mitigation actions,
Equipment - follow-up records
Unit Z290 System requirements baseline A 1 A.SUP.8
System

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 50 – Ch.3 App.A

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Q020 System requirements change management process documents A 1 A.SUP.9
System
Unit Q010 Project Management Plan A 1 A.SUP.9
System - tailored procedures for the project.
Equipment
Software
Unit Q010 Quality manual A 1 A.SUP.9
System - organization procedures for each process area.
Equipment
Software
Unit Z290 Quality control records A 1 A.SUP.9
System
Equipment
Software
Unit Z290 Project control records A 1 A.SUP.9
System
Equipment
Software
Unit Z290 Minutes of meetings, E-mails and other relevant information A 1 A.SUP.9
System
Equipment
Software
Unit Z290 Independent verifier RfP A 1 A.SUP.10
System Independent verifier selection record
Equipment
Software
Unit Z290 Minutes of milestone meetings A 1 A.SUP.13
System
Equipment Z100 Refined component requirements B 2 B.REQ.1
Software
Equipment Z100 Component operational scenario matrix B 2 B.REQ.2
Software - use cases
- state diagrams
- degrade modes
- performance targets
Equipment Z290 Traceability matrices: B 1 B.REQ.4
Software - from Product requirements to Functional specifications (where
applicable),
- from Functional specifications to component specifications
System Z030 Logical and physical architecture of components and description of B 2 B.SOL.1
Equipment I200 their interactions
Software - process views describing components & process responsibilities,
interactions, triggers & cycle times
- logical views describing user functionalities
- physical distribution of hardware, networks, CPUs
- development view decomposing functions into layers and sub-func-
tions
- scenario descriptions of component primary interactions
Typical documents include but are not limited to: P&IDs, Functional
Design Specifications, Logic diagrams, C&E diagrams, UML design
models, etc.
Unit Z290 Interface verification report B 2 B.SOL.2
System - consistency of interface/function/component/scenarios
Equipment
Software
Unit Z060 Functional Architecture (updated): B 2 B.SOL.3
System - functional (or behaviour) specifications,
Equipment - architecture specifications,
Software - functional allocation to architecture matrix
System Z010 System objectives/quality attributes targets(updated) B 2 B.SOL.3
Equipment
Software
System Z290 Technical constraints/system quality attributes compliance matrix B 2 B.SOL.3
Equipment
Software
System Z040 System requirements baseline (updated) B 2 B.SOL.4
Equipment System design baseline (updated)
Software Change requests
Change orders

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 51

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z100 Canonical data model detailing for each control information: B 1 B.SOL.5
System - meaning on installation
Equipment - impact/risk of missing information
Software - unit of measurement
Equipment Z100 Component design for each ISDS component: B 2 B.DES.2
Software - (HW & SW) description, B.DES.3
- functional description,
- interfaces description.
System Z290 Rationale and description of mechanisms preventing cross contami- B 3 B.DES.4
Equipment Z071 nation effects of a single component failure.
Software - FMEA on hardware/software
- mitigations measures preventing common mode failures.
System Z290 Prototype B 2 B.IMP.1
Equipment - interface compatibility
Software - analysis of results against expected
SEquipment Z290 Supplier selection matrix B 1 B.ACQ.1
Software - selection criteria
Equipment Z290 COTS component selection matrix B 1 B.ACQ.2
Software - rationale for selection
- selection criteria
- proposal evaluations
- selection
Equipment Z290 Supplier agreement B 1 B.ACQ.3
Software - component specifications
- functional specifications
- product acceptance criteria
- component ownership transfer conditions
Equipment Z290 Contract for each COTS supplier B 1 B.ACQ.5
Software - acquisition requirements
- cost & schedule agreement
- reusable software proprietary, usage, ownership, warranty and
licensing rights
- maintenance & support
- additional qualification scope
Unit Z250 COTS product selection procedure B 2 B.ACQ.6
System - obsolescence management
Equipment
Software
System Z290 Component design review reports B 2 B.INT.1
Equipment - verification of interface consistency between components
Software
System I210 Integration strategy B 2 B.INT.2
Equipment - procedure
Software - environment
- component integration tests
- assembly steps
- needs for stubs or simulators
System Z290 Design document review report B 1 B.VER.1
Equipment - requirements verification (functions, interfaces)
Software
System Z250 System verification strategy B 2 B.VER.2
Equipment I140 - work products to be verified
Software - methods
- environment
- plan
- quality criteria
- targets for each verification stage (ex: coverage)
- peer review techniques
- detailed testing procedures & tools
System Z250 System validation plan B 2 B.VAL.1
Equipment - test plans
Software - validation criteria
- operational scenarios
System Z290 Design validation B 2 B.VAL.2
Equipment - prototype
Software
Unit G010 RAMS hazard and risk list B 1 B.RAMS.1
System - prioritisation
Equipment
Software

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 52 – Ch.3 App.A

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z290 RAMS hazard and risk mitigation analysis B 2 B.RAMS.2
System - hardware failures
Equipment - common cause failure modes mitigations
Software
Unit Z071 FMECA for each critical function B 3 B.RAMS.3
System
Equipment
Software
Unit Z290 Software criticality analysis report B 3 B.RAMS.4
System - requirement, component, unit criticality & confidence levels
Equipment
Software
Unit Q010 System master development plan B 1 B.SUP.1
System
Equipment
Software
Unit Q010 Project risk management plan (updated) B 1 B.SUP.3
System - risk list
Equipment
Software
Unit Q010 Project risk management plan (updated) B 2 B.SUP.4
System - risk list
Equipment - mitigation actions,
Software - follow-up records
System Q010 Effort estimation & resource allocation for system activities: B 1 B.SUP.5
Equipment - integration
Software - verification
- validation
Unit Z290 System requirements baseline (updated) B 1 B.SUP.6
System System design baseline
Equipment Revision history of requirements and design
Software Differences between baselines
Unit Z290 Quality control records B 1 B.SUP.7
System
Equipment
Software
Unit Z290 Project control records B 1 B.SUP.7
System
Equipment
Software
Unit Z290 Minutes of meetings, E-mails and other relevant information B 1 B.SUP.7
System
Equipment
Software
Unit Q010 Master plan B 1 B.SUP.9
System
Equipment
Software
Unit Q010 Master schedule B 1 B.SUP.9
System
Equipment
Software
Unit Z290 Minutes of review meetings B 1 B.SUP.10
System
Equipment
Software
Unit Z290 Minutes of milestone meetings B 1 B.SUP.11
System
Equipment
Software
Unit Z290 System requirements baseline (updated) C 1 C.REQ.1
System System design baseline (updated) C.SUP.4
Equipment Change requests
Software Impact analyses
Change orders
Unit Q020 Commission board table of organisation C 1 C.REQ.1
System Change management procedure C.SUP.4
Equipment
Software

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 53

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Z290 Requirements traceability matrix (updated) C 1 C.REQ.2
System
Equipment
Software
Unit Z290 Description of changes to the technical solution, including the archi- C 1 C.SOL.1
System tecture and the canonical data model.
Equipment
Software
Unit Z290 Technical solution review report C 1 C.SOL.1
System - consistency solution with allocated components
Equipment - completeness
Software
Equipment Z290 Quality status of components C 2 C.IMP.4
Software - component quality targets
- measurement of component quality with respect to target
System Z290 Deadlock validation report. For example: C 2 C.IMP.5
Equipment - synchronous language compilation reports,
Software - rate monotonic scheduling report,
- expert review report,
- operating system analysis report,
- network analysis report.
System Z071 FMEA C 2 C.IMP.6
Equipment - mitigations measures preventing common mode failures.
Software
System Z290 Canonical data model review report C 2 C.IMP.7
Equipment - overlap consistency check between all outputs VS all receiving
Software inputs
Equipment Z290 Component supplier quality control records C 1 C.ACQ.1
Software
Equipment Z290 Component supplier project control records C 1 C.ACQ.1
Software
Equipment Z290 Component supplier progress review schedule C 1 C.ACQ.1
Software
Equipment Z290 Component supplier progress review reports C 1 C.ACQ.1
Software
System Z290 Supplier contract change requests C 1 C.ACQ.2
Equipment - impact analyses
Software
Equipment Z290 Supplier contract change orders C 1 C.ACQ.2
Software
Equipment Z250 Supplier activity reporting procedure C 2 C.ACQ.3
Software - key process quality control reports
Equipment Z290 Supplier activity quality control reports C 2 C.ACQ.3
Software
Equipment Z290 Supplier agreement C 2 C.ACQ.4
Software - phased delivery strategy
- acceptance criteria of intermediated deliveries
Equipment Z290 Subcontracted component acceptance procedure C 1 C.ACQ.5
Software - acceptance criteria
- specification validation tests
Equipment Z290 Subcontracted component validation reports C 1 C.ACQ.5
Software
Equipment Z290 COTS acceptance report C 1 C.ACQ.7
Software - COTS agreement validation (ref B.ACQ.5)
System Z250 System integration, verification and validation environment qualifi- C 2 C.INT.1
Equipment cation procedure
Software
System Z290 System integration, verification and validation environment qualifi- C 2 C.INT.1
Equipment cation report
Software
System Z290 System integration, verification and validation environment C 2 C.INT.1
Equipment - validation tools
Software - simulators

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 54 – Ch.3 App.A

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Equipment Z290 Component transfer package for each component C 1 C.INT.2
Software - component
- component release report
- component documentation
- integration team reception signoff
Equipment Z290 Component validation report for each component C 2 C.INT.3
Software
System Z290 Component integration reports for each component C 2 C.INT.4
Equipment - component integration validation C.INT.5
Software - integration environment requirements validation report
- interface validation report based on scenarios
System Z100 Canonical data model baseline (updated) C 1 C.INT.6
Equipment
Software
System Z290 Canonical data model configuration audit schedule C 1 C.INT.6
Equipment
Software
System Z290 Canonical data model configuration audit report C 1 C.INT.6
Equipment - consistency analysis
Software
System Z290 Canonical data model change requests C 1 C.INT.6
Equipment
Software
System Z290 Canonical data model change orders C 1 C.INT.6
Equipment
Software
Software Z290 Software and associated document peer review reports C 2 C.VER.1

Equipment Z250 Equipment testing procedure and plan C 2 C.VER.2

Software Software testing procedure and plan
Equipment Z290 Component verification report for each developed component C 2 C.VER.3
Software - component quality attribute status
System Z250 ISDS test procedure C 2 C.VER.4
Equipment - requirements verification strategy
Software
System Z290 ISDS test reports C 2 C.VER.4
Equipment
Software
Software Z290 Software test reports C 2 C.VER.5
- coverage of statements,
- coverage of data coupling,
- analysis vs. targets.
Software Z290 Software test reports C 3 C.VER.6
- modified condition/decision coverage (MC/DC)
- analysis vs. targets.
Software Z290 Software code verification C 2 C.VER.7
- peer review reports
- static analysis
- schedule ability
System Z290 Prototype performance validation report C 2 C.VAL.1
Equipment - validation scenarios of prototype's performance & expected results
- performance results
- analysis of results against expected
Equipment Z290 Component RAMS verification and validation reports C 2 C.RAMS.1
Software
Unit Z290 ISDS elements confidence level assessment report C 1 C.RAMS.2
System
Equipment
Software
System Z100 Network design C 2 C.RAMS.3
Equipment - mechanism preventing from domination by single component
Software
Unit Z290 System design study demonstrating the diversity of the redundant C 3 C.RAMS.4
System secondary means of operation
Equipment
Software

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 55

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Unit Q010 Project risk management plan (updated) C 1 C.SUP.1
System - risk list
Equipment
Software
Unit Q010 Project risk management plan (updated) C 2 C.SUP.2
System - risk list
- mitigation actions,
- follow-up records
Unit Q020 Configuration management plan C 1 C.SUP.3
System
System Z290 System release note C 1 C.SUP.6
Equipment
Software
Unit Z290 Quality control records C 1 C.SUP.7
System
Equipment
Software
Unit Z290 Project control records C 1 C.SUP.7
System
Equipment
Software
Unit Z290 Minutes of meetings, E-mails and other relevant information C 1 C.SUP.7
System
Equipment
Software
Unit Q010 Master plan (updated) C 1 C.SUP.9
System
Equipment
Software
Unit Q010 Master schedule (updated) C 1 C.SUP.9
System
Equipment
Software
Unit Z290 Project status report C 1 C.SUP.9
System Project action list
Equipment
Software
Unit Z290 Minutes of review meetings C 1 C.SUP.10
System
Equipment
Software
Unit Z290 Minutes of milestone meetings C 1 C.SUP.10
System
Equipment
Software
Unit Z290 System requirements baseline (updated) D 1 D.REQ.1
System System design baseline (updated) D.SUP.3
Equipment Change Requests D.SUP.4
Software Change Orders
Unit Z030 Physical architecture of components & interactions (updated) D 1 D.SOL.1
System I200 - physical distribution of hardware, networks, CPUs
Equipment - logical views describing user functionalities
Software - process views describing components & process responsibilities,
interactions, triggers & cycle times
- development view decomposing functions into layers and sub-func-
tions
- scenario descriptions of component primary interactions
System Z100 System requirements baseline (updated) D 1 D.IMP.1
Equipment System design baseline (updated)
Software Change Requests
Change Orders
Impact analysis
Non regression system testing strategy
Software version control roll-back procedures
Equipment Z250 Subcontracted component acceptance procedure D 1 D.ACQ.1
Software - acceptance criteria
- specification validation tests
Equipment Z290 Component acceptance signoff D 1 D.ACQ.1
Software

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 56 – Ch.3 App.A

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z290 Component verification report for each developed component D 1 D.VER.1
Component - component quality attribute status
Software
Unit Z290 Validation Reports D 2 D.VAL.1
System Validation Issue List D.VAL.2
Unit Z250 Black-box function test procedure, including boundary tests D 2 D.VAL.3
System
Equipment
Software
Unit Z290 Black-box function test reports D 2 D.VAL.3
System
Equipment
Software
Unit Z290 System RAMS case, including verification and validation reports D 2 D.RAMS.1
System
Equipment
Software
System Z290 System release note D 1 D.SUP.1
Equipment
Software
Equipment Z290 Component change requests D 1 D.SUP.2
Software
Equipment Z290 Component change orders D 1 D.SUP.2
Software
Unit Q020 Configuration management plan D 1 D.SUP.3
System
Unit Z290 Quality control records D 1 D.SUP.5
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software
Unit Q010 Master plan (updated) D 1 D.SUP.6
System D.SUP.10
Unit Q010 Master schedule (updated) D 1 D.SUP.6
System D.SUP.10
Unit Z290 Project status report C 1 D.SUP.6
System Project action list
Equipment
Software
Unit Q010 Project risk management plan (updated) D 1 D.SUP.7
System - risk list
Unit Q010 Project risk management plan (updated) D 2 D.SUP.8
System - risk list
- mitigation actions,
- follow-up records
Unit Z290 Minutes of review meetings D 1 D.SUP.10
System
Unit Z290 Minutes of milestone meetings D 1 D.SUP.10
System
Unit Z290 System requirements baseline (updated) E 1 E.REQ.1
System System design baseline (updated) E.SUP.5
Equipment Change requests
Software Impact analyses
Change orders
Unit Z030 Physical architecture of components & interactions (updated) E 1 E.SOL.1
System I200 - physical distribution of hardware, networks, CPUs
Equipment - logical views describing user functionalities
Software - process views describing components & process responsibilities,
interactions, triggers & cycle times
- development view decomposing functions into layers and sub-func-
tions
- scenario descriptions of component primary interactions

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 57

Table C1 System integrator information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z100 System requirements baseline (updated) E 1 E.IMP.1
Equipment System design baseline (updated)
Software Change Requests
Change Orders
Impact analysis
Non regression system testing strategy
Software version control roll-back procedures
Unit Q010 Obsolescence management plan: E 2 E.ACQ.1
System - Authorized vendor list,
Equipment - Spare parts list (HW & SW),
Software - Alternate spare parts list,
- Management of intellectual property.
System Z290 Component verification report for each developed component E 1 E.VER.1
Component - component quality attribute status
Software
Unit Z290 Test plans (updated) E 2 E.VAL.1
System Validation reports
Unit Q020 Configuration management plan E 1 E.SUP.1
System
Unit Z250 Issue tracking and resolution procedure E 1 E.SUP.2
System
Unit Z250 Change management procedure E 1 E.SUP.2
System
Equipment
Software
Unit Z250 Configuration management procedure E 1 E.SUP.2
System - migration issues
Equipment - software obsolescence (ref E.ACQ.1)
Software
Unit Z290 Quality control records E 1 E.SUP.7
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software
Unit Q010 Master plan (updated) E 1 E.SUP.8
System
Unit Q010 Master schedule (updated) E 1 E.SUP.8
System
Unit Z290 Minutes of review meetings E 1 E.SUP.8
System E.SUP.11
Unit Q010 Project risk management plan (updated) E 1 E.SUP.9
System - risk list
Unit Q010 Project risk management plan (updated) E 2 E.SUP.10
System - risk list
- mitigation actions,
- follow-up records
System Z290 Minutes of milestone meetings E 1 E.SUP.11
Equipment
Software

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 58 – Ch.3 App.A

D. Supplier Information Requirements each activity to be performed. Such outcomes are expected by
the latest at the end of the phase, and may be delivered to DNV
The following table presents the information requirements or reviewed onsite.
applicable to the supplier role. An outcome is expected for

Table D1 Supplier information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z290 Submitted proposal A 1 A.ACQ.1
Equipment - breakdown of ISDS elements A.ACQ.3
Software - price drivers and breakdown for CAPEX and OPEX
- alternatives and options
- description of customization or parameterization of existing prod-
ucts (including software)
- requirements compliance matrix
- licensing and ownership scheme (for software)
System Q010 Table of organization for integration of ISDS elements: A 1 A.INT.1
Equipment - roles,
Software - names,
- contact information,
- responsibilities.
System Z250 Joint agreement integration process document A 1 A.INT.1
Equipment - agreement status,
Software - integration boundaries and exclusions,
- responsibilities of the correct operations of the elements of the sys-
tem
System Q010 Master plan A 1 A.SUP.3
Equipment - WBS A.SUP.4
Software - technical attributes used for estimating,
- effort and costs estimates.
- deliverables,
- milestones
System Q010 Master schedule A 1 A.SUP.3
Equipment
Software
System Q010 Contribution of supplier to master plan A 1 A.SUP.3
Equipment
Software
System Q010 Contribution of supplier to master schedule A 1 A.SUP.3
Equipment
Software
System Q010 Project risk list A 0 A.SUP.6
Equipment
Software
System Z250 System requirements change management process documents A 1 A.SUP.9
Equipment
Software
System Z250 Project Management Plan A 1 A.SUP.9
Equipment - tailored procedures for the project.
Software
System Q010 Quality manual A 1 A.SUP.9
Equipment - organization procedures for each process area.
Software
System I140 Software Quality Plan A 1 A.SUP.9
Equipment
Software
System Z290 Quality control records A 1 A.SUP.9
Equipment
Software
System Z290 Project control records A 1 A.SUP.9
Equipment
Software
System Z290 Minutes of meetings, E-mails and other relevant information A 1 A.SUP.9
Equipment
Software
Unit Z290 Minutes of milestone meetings A 1 A.SUP.13
System
Equipment Z100 Refined component requirements B 2 B.REQ.1
Software

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 59

Table D1 Supplier information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
Equipment Z100 Component operational scenario matrix B 2 B.REQ.2
Software - use cases
- state diagrams
- degrade modes
- performance targets
Equipment Z290 Traceability matrices: B 1 B.REQ.4
Software - from Product requirements to Functional specifications (where
applicable),
- from Functional specifications to component specifications
System Z030 Physical architecture of components & interactions B 2 B.SOL.1
Equipment I200 - physical distribution of hardware, networks, CPUs
Software - logical views describing user functionalities
- process views describing components & process responsibilities,
interactions, triggers & cycle times
- development view decomposing functions into layers and sub-func-
tions
- scenario descriptions of component primary interactions
Unit Z100 Canonical data model detailing for each control information: B 1 B.SOL.5
System - meaning on installation
Equipment - impact/risk of missing information
Software - unit of measurement
Equipment Z100 Component design for each ISDS component: B 2 B.DES.1
Software - (HW & SW) description, B.DES.2
- functional description, B.DES.3
- interfaces description.
Equipment Z290 Prototype B 2 B.IMP.1
Software - interface compatibility
- analysis of results against expected
Equipment Z290 Supplier agreement B 1 B.ACQ.3
Software - component specifications
- functional specifications
- product acceptance criteria
- component ownership transfer conditions
Equipment Z290 Contribution of Supplier to Obsolescence studies B 2 B.ACQ.6
Software
System Z290 Component design review reports B 2 B.INT.1
Equipment - verification of interface consistency between components
Software
Equipment Z290 Workload estimation for each component to be developed B 1 B.SUP.2
Software - hardware development workload
- software development workload distribution (customization,
parameterization or reuse as is)
System Q010 Project risk management plan (updated) B 1 B.SUP.3
Equipment - risk list
Software
System Q010 Project risk management plan (updated) B 2 B.SUP.4
Equipment - risk list,
Software - mitigation actions,
- follow-up records
Equipment Z290 Equipment requirements baseline (updated) B 1 B.SUP.6
Software Equipment design baseline
Revision history
Differences between baselines
System Z290 System design baseline B 1 B.SUP.6
Equipment
Software
Unit Z290 Quality control records B 1 B.SUP.7
System
Equipment
Software
Unit Z290 Project control records B 1 B.SUP.7
System
Equipment
Software
Unit Z290 Minutes of meetings, E-mails and other relevant information B 1 B.SUP.7
System
Equipment
Software

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 60 – Ch.3 App.A

Table D1 Supplier information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Q010 Master plan B 1 B.SUP.9
Equipment
Software
System Q010 Master schedule B 1 B.SUP.9
Equipment
Software
System Z290 Minutes of review meetings B 1 B.SUP.10
Equipment
Software
System Z290 Minutes of milestone meetings B 1 B.SUP.11
Equipment
Software
System Z290 System requirements baseline (updated) C 1 C.REQ.1
Equipment System design baseline (updated) C.SUP.4
Software Change requests
Impact analyses
Change orders
System Q020 Commission board table of organisation C 1 C.REQ.1
Equipment Change management procedure C.SUP.4
Software
System Z100 Description of changes to the technical solution, including the archi- C 1 C.SOL.1
Equipment tecture and the canonical data model.
Software
System Z290 Technical solution review report C 1 C.SOL.1
Equipment - consistency solution with allocated components
Software - completeness
System Z100 Refined component design for each ISDS component: C 2 C.DES.1
Equipment - (HW & SW) description,
Software - functional description,
- interfaces description.
System Z290 Component implementation report C 2 C.DES.1
Equipment - inconsistencies between design documentation and implementation
Software
Equipment Z100 Developed component release note C 1 C.IMP.1
Software - test coverage report C.IMP.3
Equipment Z100 Component support documentation C 2 C.IMP.2
Software Z170
Z180
Equipment Z290 Quality status of components C 2 C.IMP.4
Software - component quality targets
- measurement of component quality with respect to target
System Z100 Canonical data model review report C 2 C.IMP.7
Equipment - overlap consistency check between all outputs VS all receiving
Software inputs
Equipment Z290 Supplier contract change requests C 1 C.ACQ.2
Software - contribution of supplier to impact analyses
Equipment Z290 Supplier contract change orders C 1 C.ACQ.2
Software
Equipment Z290 Component acceptance: C 1 C.ACQ.5
Software - component acceptance (FAT, SAT) test plan,
- component acceptance test records,
- component acceptance issue and problems list,
- component acceptance coverage measurements (requirements,
structural).
Equipment Z100 Component integration support documentation C 1 C.ACQ.6
Software Z170
Z180
System Z100 Canonical data model baseline (updated) C 1 C.INT.6
Equipment
Software
System Z290 Canonical data model configuration audit schedule C 1 C.INT.6
Equipment
Software
System Z290 Canonical data model configuration audit report C 1 C.INT.6
Equipment - consistency analysis
Software

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 61

Table D1 Supplier information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z290 Canonical data model change requests C 1 C.INT.6
Equipment
Software
System Z290 Canonical data model change orders C 1 C.INT.6
Equipment
Software
Software Z290 Software and associated document peer review reports C 2 C.VER.1

Equipment Z120 Component verification plan C 2 C.VER.3

Software Component verification report for each developed component
- component quality attribute status
Software Z130 Software test reports C 2 C.VER.5
- coverage of statements,
- coverage of data coupling,
- analysis vs. targets.
Software Z130 Software test reports C 3 C.VER.6
- modified condition/decision coverage (MC/DC)
- analysis vs. targets.
Software Z130 Software code verification C 2 C.VER.7
- peer review reports
- static analysis
- schedule ability
Equipment Z130 Component RAMS verification and validation reports C 2 C.RAMS.1
Software
Unit Q010 Project risk management plan (updated) C 1 C.SUP.1
System - risk list
Equipment
Software
Unit Q010 Project risk management plan (updated) C 2 C.SUP.2
System - risk list
Equipment - mitigation actions,
Software - follow-up records
Unit Q020 Configuration management plan C 1 C.SUP.3
System
Equipment Z290 Component release note C 1 C.SUP.5
Software - changes with previous version of component
System Z290 Quality control records C 1 C.SUP.7
Equipment
Software
System Z290 Project control records C 1 C.SUP.7
Equipment
Software
System Z290 Minutes of meetings, E-mails and other relevant information C 1 C.SUP.7
Equipment
Software
System Q010 Master plan (updated) C 1 C.SUP.9
Equipment
Software
System Q010 Master schedule (updated) C 1 C.SUP.9
Equipment
Software
Unit Z290 Project status report C 1 C.SUP.9
System Project action list
Equipment
Software
System Z290 Minutes of review meetings C 1 C.SUP.10
Equipment
Software
System Z290 Minutes of milestone meetings C 1 C.SUP.10
Equipment
Software
System Z290 System requirements baseline (updated) D 1 D.REQ.1
Equipment System design baseline (updated) D.SUP.3
Software Change Requests
Change Orders

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 62 – Ch.3 App.A

Table D1 Supplier information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z030 Physical architecture of components & interactions (updated) D 1 D.SOL.1
Equipment I200 - physical distribution of hardware, networks, CPUs
Software - logical views describing user functionalities
- process views describing components & process responsibilities,
interactions, triggers & cycle times
- development view decomposing functions into layers and sub-func-
tions
- scenario descriptions of component primary interactions
System Z100 System requirements baseline (updated) D 1 D.IMP.1
Equipment System design baseline (updated)
Software Change Requests
Change Orders
Impact analysis
Non regression system testing strategy
Software version control roll-back procedures
System Z130 Component verification report for each developed component D 1 D.VER.1
Component - component quality attribute status
Software
System Z290 Contribution of supplier to system release note D 1 D.SUP.1
Equipment
Software
Equipment Z290 Component change requests D 1 D.SUP.2
Software
Equipment Z290 Component change orders D 1 D.SUP.2
Software
System Z290 Quality control records D 1 D.SUP.5
Equipment Project Control records
Software Minutes of meetings, E-mails and other relevant information
System Q010 Master plan (updated) D 1 D.SUP.6
Equipment D.SUP.10
Software
System Q010 Master schedule (updated) D 1 D.SUP.6
Equipment D.SUP.10
Software
Unit Z290 Project status report C 1 D.SUP.6
System Project action list
Equipment
Software
System Q010 Project risk management plan (updated) D 1 D.SUP.7
Equipment - risk list
Software
System Q010 Project risk management plan (updated) D 2 D.SUP.8
Equipment - risk list
Software - mitigation actions,
- follow-up records
System Z290 Minutes of review meetings D 1 D.SUP.10
Equipment
Software
System Z290 Minutes of milestone meetings D 1 D.SUP.10
Equipment
Software
System Z290 System requirements baseline (updated) E 1 E.REQ.1
Equipment System design baseline (updated) E.SUP.5
Software Change requests
Impact analyses
Change orders
System Z030 Physical architecture of components & interactions (updated) E 1 E.SOL.1
Equipment I200 - physical distribution of hardware, networks, CPUs
Software - logical views describing user functionalities
- process views describing components & process responsibilities,
interactions, triggers & cycle times
- development view decomposing functions into layers and sub-func-
tions
- scenario descriptions of component primary interactions

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 63

Table D1 Supplier information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z100 System requirements baseline (updated) E 1 E.IMP.1
Equipment System design baseline (updated)
Software Change Requests
Change Orders
Impact analysis
Non regression system testing strategy
Software version control roll-back procedures
System Q010 Contribution of supplier to obsolescence management plan: E 2 E.ACQ.1
Equipment - Spare parts list (HW & SW),
Software - Alternate spare parts list,
- Management of intellectual property.
System Z120 Component test plans (updated) E 1 E.VER.1
Component Z130 Component integration and verification report
Software - component quality attribute status
System Z120 Test plans (updated) E 2 E.VAL.1
Equipment Z140 Validation reports
Software Z130
Z150
System Z290 Quality control records E 1 E.SUP.7
Equipment Project Control records
Software Minutes of meetings, E-mails and other relevant information
System Q010 Master plan (updated) E 1 E.SUP.8
Equipment
Software
System Q010 Master schedule (updated) E 1 E.SUP.8
Equipment
Software
System Z290 Minutes of review meetings E 1 E.SUP.8
Equipment E.SUP.11
Software
System Q010 Project risk management plan (updated) E 1 E.SUP.9
Equipment - risk list
Software
System Q010 Project risk management plan (updated) E 2 E.SUP.10
Equipment - risk list
Software - mitigation actions,
- follow-up records
System Z290 Minutes of milestone meetings E 1 E.SUP.11
Equipment
Software

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 64 – Ch.3 App.A

E. Independent Verifier Information applicable to the independent verifier role. An outcome is

Requirements expected for each activity to be performed. Such outcomes are
expected by the latest at the end of the phase, and may be deliv-
The following table presents the information requirements ered to DNV or reviewed onsite.

Table E1 Independent verifier information requirements for ISDS

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z290 Independent system design verification report A 3 A.VER.3
Equipment
Software
Unit Z290 Independent review report on A 2 A.RAMS.1
System - RAMS (at least Safety) management plan
Equipment - RAMS (Safety) design procedure
- RAMS (Safety) training plan
- RAMS (Safety) issue tracking and resolution procedure
Unit Z290 RAMS requirements verification report A 2 A.RAMS.3
System
Equipment
Unit Z290 Independent ISDS elements confidence level assessment report A 1 A.SUP.12
System
Unit Z290 Joint minutes of milestone meetings A 1 A.SUP.13
System
Unit Z290 Quality control records A 1 A.SUP.14
System Project Control records
Minutes of meetings, E-mails and other relevant information
Independent control process verification report
System Z290 Independent design verification report B 2 B.VER.3
Equipment
Software
System Z290 Independent design verification report B 3 B.VER.4
Equipment
Software
System Z290 Independent software architecture design verification report B 3 B.VER.5
Equipment
Software
System Z290 Independent software detailed design verification report B 3 B.VER.5
Equipment
Software
System Z290 Independent canonical data model verification report B 2 B.VER.6
Equipment
Software
System Z290 Independent verification strategy review report B 3 B.VER.7
Equipment
Software
System Z290 Independent validation strategy review report B 2 B.VAL.3
Equipment
Software
Unit Z290 Software criticality analysis report B 3 B.RAMS.4
System - requirement, component, unit criticality & confidence levels
Equipment
Software
Unit Z290 Quality control records B 1 B.SUP.7
System Project Control records B.SUP.8
Equipment Minutes of meetings, E-mails and other relevant information
Software Independent control process review report
Unit Z290 Joint minutes of milestone meetings B 1 B.SUP.11
System
Unit Z290 Independent project plan review report B 1 B.SUP.12
System
System Z290 Independent quality plan review report B 1 B.SUP.12
Equipment
Software
Component Z290 Component verification report for each developed component C 2 C.VER.3
Software
Software Z290 Independent software source code review report C 3 C.VER.8

System Z290 Independent ISDS element review report C 3 C.VER.9

Equipment
Software

DET NORSKE VERITAS

 Offshore Standard DNV-OS-D203, April 2010
Ch.3 App.A – Page 65

Table E1 Independent verifier information requirements for ISDS (Continued)

Applicable Information Additional Description Phase Confidence Activities
Scope Type Level
System Z290 Independent ISDS element qualification report C 3 C.VER.9
Equipment
Software
Unit Z290 Quality control records C 1 C.SUP.7
System Project Control records C.SUP.8
Equipment Minutes of meetings, E-mails and other relevant information
Software Independent control process review report
Unit Z290 Joint minutes of milestone meetings C 1 C.SUP.10
System
Equipment
Software
Equipment Z290 Component acceptance procedure review report D 1 D.ACQ.1
Software
System Z290 Component verification report for each developed component D 1 D.VER.1
Equipment
Software
Unit Z290 Independent validation report reviews D 2 D.VAL.1
System
System Z290 Independent ISDS verification report D 3 D.VAL.4
Equipment
Software
System Z290 Independent ISDS validation report D 3 D.VAL.4
Equipment
Software
Unit Z290 Independent RAMS verification reports D 2 D.RAMS.1
System
Equipment
Software
Unit Z290 Independent RAMS validation reports D 2 D.RAMS.1
System
Equipment
Software
Unit Z290 Quality control records D 1 D.SUP.5
System Project Control records D.SUP.9
Equipment Minutes of meetings, E-mails and other relevant information
Software Independent control process review report
Unit Z290 Joint minutes of milestone meetings D 1 D.SUP.10
System
Equipment
Software
Unit Z290 Quality control records E 1 E.SUP.7
System Project Control records
Equipment Minutes of meetings, E-mails and other relevant information
Software Independent control process review report
Unit Z290 Joint minutes of milestone meetings E 1 E.SUP.11
System
Equipment
Software

DET NORSKE VERITAS

Offshore Standard DNV-OS-D203, April 2010
Page 66 – Ch.3 App.A

DET NORSKE VERITAS