DNVGL-RP-D201 Integrated software dependent systems€¦ · The purpose of the revision of this...

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

DNV GL AS

RECOMMENDED PRACTICE

DNVGL-RP-D201 Edition July 2017

Integrated software dependent systems

FOREWORD

DNV GL recommended practices contain sound engineering practice and guidance.

© DNV GL AS July 2017

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

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

Cha

nges

- c

urre

nt

Recommended practice — DNVGL-RP-D201. Edition July 2017 Integrated software dependent systems

DNV GL AS

CHANGES – CURRENT

GeneralThis document supersedes the October 2009 edition of DNV-RP-D201.The purpose of the revision of this service document is to comply with the new DNV GL document reference code system and profile requirements following the merger between DNV and GL in 2013. Changes mainly consist of updated company name and references to other documents within the DNV GL portfolio.

Some references in this service document may refer to documents in the DNV GL portfolio not yet published (planned published within 2017). In such cases please see the relevant legacy DNV or GL document. References to external documents (non-DNV GL) have not been updated.

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

Con

tent

s


DNV GL AS

CONTENTS

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

Section 1 General....................................................................................................71.1 Objectives......................................................................................... 71.2 Scope and application.......................................................................71.3 Structure of this document...............................................................81.4 How to use this document................................................................8

Section 2 Definitions, abbreviations and references............................................... 92.1 Definitions.........................................................................................92.2 References...................................................................................... 13

Section 3 Philosophy and principles......................................................................163.1 General........................................................................................... 16

Section 4 Assessment of confidence levels........................................................... 194.1 Confidence levels............................................................................194.2 Definition and assessment of the confidence levels........................ 194.3 Function allocation to ISDS elements............................................. 204.4 Combining functions....................................................................... 21

Section 5 System and software engineering activities.......................................... 225.1 Phases............................................................................................ 225.2 Disciplines.......................................................................................235.3 Responsibilities...............................................................................255.4 Activities and confidence levels......................................................265.5 Lifecycle tailoring........................................................................... 275.6 Integrated software dependent systems and new technologyqualification.......................................................................................... 28

Section 6 Concept phase....................................................................................... 316.1 Scope.............................................................................................. 316.2 Goal................................................................................................ 316.3 Mandatory activities........................................................................316.4 Activities......................................................................................... 32

Section 7 Engineering phase.................................................................................377.1 Scope.............................................................................................. 377.2 Goal................................................................................................ 37

Con

tent

s


DNV GL AS

7.3 Activities......................................................................................... 38

Section 8 Construction phase................................................................................428.1 Scope.............................................................................................. 428.2 Goal................................................................................................ 428.3 Activities......................................................................................... 42

Section 9 Acceptance phase..................................................................................479.1 Scope.............................................................................................. 479.2 Goal................................................................................................ 479.3 Activities......................................................................................... 47

Section 10 Operation phase.................................................................................. 5010.1 Scope............................................................................................ 5010.2 Goal...............................................................................................5010.3 Activities....................................................................................... 50

Appendix A Generic system requirements.............................................................53A.1 Building a consistent set of generic system requirements.............. 54A.2 Consequences of omitting generic system requirements................ 54A.3 Adding other generic system requirements.................................... 55A.4 Functionality................................................................................... 55A.5 Reliability........................................................................................56A.6 Availability......................................................................................56A.7 Usability..........................................................................................57A.8 Efficiency........................................................................................ 58A.9 Maintainability................................................................................ 58A.10 Portability..................................................................................... 59A.11 Integrability..................................................................................59A.12 Functional safety.......................................................................... 59A.13 Specification of characteristics and attributes.............................. 60A.14 Balancing between generic system requirements, feasibilityand other needs................................................................................... 60A.15 Verification of achievement of characteristics and attributes........60

Appendix B Detailed description of recommended activities................................. 63B.1 Concept phase activities................................................................. 63B.2 Engineering phase activities...........................................................68B.3 Construction phase activities..........................................................74B.4 Acceptance phase activities............................................................78B.5 Operation phase activities.............................................................. 80

Con

tent

s


DNV GL AS

Appendix C Traceability between activities and generic system requirements...... 83

Appendix D Risk identification checklist............................................................... 92

Appendix E Complete references and bibliography............................................... 96E.1 Complete references....................................................................... 96E.2 Bibliography....................................................................................97

Changes – historic................................................................................................98


DNV GL AS

SECTION 1 GENERALEquipment and systems have become more complex, automated, with a higher level of integration. Thistrend is accelerating with time. This continuing evolution provides owners of vessels and installations withopportunities but also it introduces challenges to the management of such systems, for their full life cyclefrom development to operations, from cradle to grave. When an owner strives for a high production and safeinstallation, demands have to be set upon the systems that control the installation. The automation industryhas mainly focused on the connectivity ensuring physical integration of the various control systems.The main challenge for integrated software dependent systems (ISDS), is how to engineer the varioussystem elements into a single system that meets all the necessary requirements, in terms of safety,functionality, reliability, etc. Selecting and connecting system elements that may individually satisfy therequirements is not sufficient. The challenge extends to the integration of the system elements and anunderstanding of their operation within the system, in particular the effect both negative and positive thatsystem elements may have on each other, in order to deliver the emerging properties of the system.This recommended practice (RP) presents recommendations related to work processes and quality assurancefor the full lifecycle of ISDS, where control, monitoring and safety systems serving several functions couldbe integrated, or connected via communication networks. The focus of this RP is on which processes shall beimplemented to be compliant with this RP, and not how they can be implemented.

1.1 ObjectivesThe objective of this RP is to provide a common framework to improve the life cycle economics of ISDS in themaritime and energy industries, including offshore oil and gas.Applying the RP helps owners and operators to find an optimal balance between the opportunities and thecost of automation and manage the risk related to poor quality, incorrect functionality and unsafe behaviourof a function during the entire life cycle.For system integrators (typically builders or yards) and suppliers the application of this RP providesa common framework that helps to deliver the ISDS on schedule, within budget while achieving thefunctionality and quality targets. This is an efficient tool for system integrators and suppliers to clearlycommunicate and resolve key issues related to the integration challenge at an early stage and throughoutthe whole life cycle.This RP recommends an approach for managing the risk and gradually create confidence in the ISDS. Itdoes not impose a new quality system, but ensures that integration activities are planned, executed andmanaged according to best practices. Existing quality systems may reference the RP ISDS as applicable orrecommended guidelines to improve the life cycle economics for the entire life cycle, for the organizationsinvolved in the project.A final key benefit of this RP is that it recommends cost effective activities corresponding to the missioncriticality of the ISDS.

1.2 Scope and applicationThis RP aims at giving guidance for integrated software dependent systems development, construction andoperations in the energy (including oil andgas) and maritime industries. Systems under consideration are anyof the systems involved in facilities and vessels operations in these sectors. There is no limitation concerningtheir size or complexity. This RP addresses the whole system, including the controlled systems, the controlsystems and also the links between the two.This RP provides guidance on the processes to manage ISDS throughout the life cycle. It describes howproduct requirements should be developed and does not specify any specific product requirements. Otherstandards, such as those referenced in [2.2], provide more product specific requirements.The level of therecommended activities in this RP corresponds to the mission criticality of the ISDS. The mission criticalitycould be either environmental, safety or business related and the higher the mission criticality is the moreintegrated the recommended activities are.


DNV GL AS

The number of recommended activities to be applied varies from low confidence levels for systems withlimited risks and business impacts up to high confidence levels for system which are business, environmentaland/or safety-critical systems.A successful implementation of the RP activities will mean focusing on the initial phases of the systemdevelopment but will allow much better early decision-making and significantly reduce the overall cost andrisk for these systems.

1.3 Structure of this documentSec.2 describes terms and concepts used in this document.Sec.3 explains the principles and philosophy behind this recommended practice.Sec.4 covers definition and determination of the confidence levels.Sec.5 describes the phases and responsibilities used to structure the disciplines and activities to beimplemented by each actor.Sec.6 to Sec.10 contain the recommended activities for the different phases of the ISDS lifecycle.Appendices describe in details the activities to be performed as well as the generic system requirements thatshould be taken into account for system design.

1.4 How to use this documentThis RP may be used by owners, yards and subcontractors involved in such systems development andoperations. Once this RP has been selected and made applicable on a project, its recommendations becomemandatory requirements to be applied and traced by actors.First reading should focus on Sec.3, which explains the philosophy and principles of this recommendedpractice. This RP is mostly focused on the owner and the system integrator. The system integrator isthe organization designated by the owner to lead and be responsible for the system development andintegration.Identification of the main responsibilities regarding the development of the system shall be done as soon aspossible, in order to assign the responsibilities given in [5.3] (Responsibilities), and no later than the end ofthe concept phase.The first step is for the owner to define what the expected functions of the system are. Then the ownershould identify the risks related to these functions, and determine the confidence level. Sec.4 gives guidanceon how to assess the confidence level from the risks.The next step is to identify what is the lifecycle chosen for the system development and operation, whichdescribes what the main phases of the development and operation are. This shall be done by the systemintegrator, following recommendations given in [5.5] (Lifecycle tailoring). The objective is to provide theframework in which the activities shall take place.Each responsible shall then implement the recommended activities for each phase (see Sec.6 to Sec.10). Atable list of recommended activities for each responsible is provided for each phase, given the confidencelevel. Owner, operator, system integrator and subcontractors (suppliers) shall extract from their own set ofactivities to implement and track.Depending on the confidence level, an independent verifier shall be appointed by the owner to performindependent verification on the conformance of the key actors in the system lifecycle towards their assignedactivities (see activities assigned to the independent verifier).


DNV GL AS

SECTION 2 DEFINITIONS, ABBREVIATIONS AND REFERENCES

2.1 Definitions

2.1.1 Verbal formsThe terms will, can and may are used when describing DNV GL’s actions or activities, and the terms shall,should and may are used when referring to other parties than DNV GL.

Table 2-1 Definitions of verbal forms

Term Definition

shall indicates requirements strictly to be followed in order to conform to this RP and from which no deviation ispermitted

should indicates that among several possibilities, one is recommended as particularly suitable, without mentioningor excluding others, or that a certain course of action is preferred but not necessarily required. Otherpossibilities may be applied subject to agreement

will indicates a mandatory action or activity to be undertaken by DNV GL (Ref. shall for other parties.)

can indicates an action or activity that DNV GL not necessarily does unless specifically requested by the client.(Ref. should for other parties.)

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

2.1.2 DefinitionsTable 2-2 Definitions of terms

Term Definition

activity a defined body of work to be performed, including its required input and output information

[IEEE 1074:1997]

availability the ability for the system to provide access to its resources in a timely manner for a specifiedduration [IEV 191-02-05]

CL<n> confidence level <n> (n=0 to 3). [See Sec.4]

code review systematic examination (often as peer review) of computer source code intended to find and fixmistakes overlooked in the initial development phase, improving the overall quality of software

common causefailure

failure of multiple items occurring from a single cause that is common to all of them

[EN 13701:2001]

common modefailure

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]

configurablecode

code (source code or executable code) that can be tailored by setting values of parameters

[ECSS-E-40B: 2003]


DNV GL AS

Term Definition

configurationmanagement

the management of features and assurances through control of changes made to requirements,hardware, software, firmware, documentation, test, test fixtures and test documentation of anautomated information system, throughout the system lifecycle

consequence(failure)

ranking of the seriousness of the failure (business, environmental and safety)

COTS commercial off-the-shelf; software or hardware, generally technology or computer products, thatare ready-made and available for sale, lease, or license to the general public

CPU central processing unit

criticality combined measure of the severity of a failure mode and its probability of occurrence

defect non-fulfilment of a requirement related to an intended or specified use

[ISO 9000:2000]

discipline a set of activities dealing with consistent objectives and skills within the system lifecycle

emerging

system

property

a property of a system which cannot be observed, measured, tested or verified at the sub-systemor equipment levelFor example, the properties of a feedback loop cannot be determined by looking at one of theindividual pieces of the loop.

error a discrepancy between a computed, observed or measured value or condition and the true,specified or theoretically correct value or condition

[IEC 61508-4]

Note: An error can be caused by a faulty item, e.g. a computing error made by faulty computerequipment.

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 faultin other linked pieces of equipment, etc. (see below failure propagation).

failure,

random

hardware

failure, occurring at a random time, which results from one or more of the possible degradationmechanisms in the hardware

[IEC 61508-4]

Note: A major distinguishing feature between random hardware failures and systematic failures(see below), is that system failure rates (or other appropriate measures), arising from randomhardware failures, can be predicted with reasonable accuracy but systematic failures by their verynature cannot be accurately predicted. That is, system failure rates arising from random hardwarefailures can be quantified with reasonable accuracy but those arising from systematic failurescannot be accurately statistically quantified because the events leading to them cannot easily bepredicted.

failure,

systematic

failure related in a deterministic way to a certain cause, which can only be eliminated by amodification of the design or of the manufacturing process, operational procedures, documentationor other relevant factors

[IEC 61508-4]

Examples of causes of systematic failures include human error in:

— the safety requirements specification— the design, manufacture, installation, operation of the hardware— the design, implementation, etc. of the software.


DNV GL AS

Term Definition

failure

propagation

any physical or logical event caused by failure within a product which can lead to failure(s) ofproducts outside the boundaries of the product under analysis

fault abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit toperform a required function

[IEC 61508-4]

Excluding the inability during preventive maintenance or other planned actions, or due to lack ofexternal resources.

functionalsafety

functional safety is part of the overall safety that depends on a system or equipment operatingcorrectly in response to its inputs

Neither safety nor functional safety can be determined without considering the systems as a wholeand the environment with which they interact.

[IEC 61508-0:2000 Functional Safety]

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

independent applied to the verifier responsibility. The level of independence is the one defined by IEC 61508

Integration

testing

testing in which software components, hardware elements, or both are combined and tested toevaluate the interaction between them[IEEE 610.12:1990]

IO input/output (also I/O)

IOC initial operational capacity: for a system developed in stages, describes the capabilities of the firstdelivery of the system to the operator. Additional deliveries may increase the capabilities over time

integrated

system

an integrated system is a set of elements which interact according to a design, where an elementof a system can be another system, called a subsystem, which may be a controlling system or acontrolled system and may include hardware, software and human interaction

[IEC 61508-4]

Note: The INCOSE SE focuses more on the intent of the system: An integrated system is anintegrated set of elements that accomplish a defined objective.

ISDE see ISDS element

ISDS integrated software dependent system

An ISDS is an integrated system which overall behaviour is dependent on the behaviour of itssoftware components.

The purpose of this RP is to provide recommendations on the building and operations of suchsystems, including within their environment (operators, other systems and structures, etc).

ISDS element integrated software dependent system Eeement.A component, subsystem or control circuit, etc. that is a part of the ISDS.

maintainability the ability of a system under given conditions of use, to be retained in, or restored to a state inwhich it can perform its functions, when maintenance is performed under given conditions andusing stated procedures and resources

MTTF, mean time to failureMay be used as target for reliability.


DNV GL AS

Term Definition

MTBF mean time between failuresMay be used as target for reliability.

MTTR mean time to repairMay be used as target for reliability.

nonconformity the non fulfilment of specified requirements, a particular kind of defect

obsolescence(risk)

risk associated with technology within the system that becomes obsolete before the end ofthe expected shelf or operations life (see [A.6]), and cannot provide the planned and desiredfunctionalityThis risk may be mitigated by the Portability Generic System Requirement (See [A.10]).

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

probability(failure)

for hardware, probability that an item fails to operate when required

This probability is estimated by the ratio of the number of failures to operate for a given number ofcommands to operate, to the number of commands.

[IEV-191-29-1]

PSSA preliminary system safety analysis; a systematic evaluation of a proposed system architecture andimplementation based on the functional hazard assessment and failure condition classification todetermine safety requirements for all items

[ARP 4761]

RAMS reliability, availability, maintainability, (functional) safety; a set of commonly linked generic systemattributes that often need to be dealt with in a systematic manner

regressiontesting

selective retesting of a system or component to verify that modifications have not causedunintended effects and that the system or component still complies with its specified requirements

[IEEE 610.12:1990]

reliability the capability of the ISDS to maintain a specified level of performance when used under specifiedconditions (see [A.5])

review activity undertaken to determine the suitability, adequacy and effectiveness of the subject matterto achieve established objectives

[ISO 9000:2000]

revision

control

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

risk combination of the probability of occurrence of an incident and the severity of that incident. SeeIEC 61508 for more information

safe state state of the system when safety is achieved

[IEC 61508-4]

Note: In going from a potentially hazardous condition to the final safe state, the ISDS may haveto go through a number of intermediate safe states. For some situations a safe state exists onlyso long as the ISDS is continuously controlled. Such continuous control may be for a short or anindefinite period of time.

software ISDSelement

a software component of an ISDS


DNV GL AS

Term Definition

software

product

set of computer programs, procedures, documentation and their associated data

software unit separately compileable piece of source code. Also called module or package

SSA system safety analysis; a systematic, comprehensive evaluation of the implemented system toshow that the relevant requirements are met. [ARP 4761]

Also,

Safety and security application area: a set of best practices to implement safety and securityactivities, provided by the FAA, to be used for process assessment and improvement.

SW software

stress testing testing that evaluates a system or software component at or beyond its value limits

test case a specification of a test in terms of:

— a description of the purpose of the test— pre-conditions (e.g. the state of the software under test)— actions organized in one or several scenarios— post-conditions (expected reaction).

Unit and ISDSelement testing

a process for testing components to ensure functionality as defined for the component, beforeintegration.

validation confirmation, through the provision of objective evidence that the requirements for a specificintended use or application have been fulfilled

[ISO 9000:2000]

verification confirmation through the provision of objective evidence that the specified requirements have beenfulfilled

[ISO 9000:2000]

2.2 ReferencesThis RP brings together a wealth of information and standards from many different sources. It joins themin order to provide a practical systems engineering document combining integrated project management,systems engineering, engineering disciplines and specialities such as safety and risk management. It alsofocuses on the maritime and energy world.The following table lists the major source or reference documents and explains the relationship of the RP tothe source. A complete list of references may be referred to in App.E.

Table 2-3 Major source or reference documents

Reference Description Relationship to RP

DNVGL-OS-D202 DNV GL offshore standardfor automation, safety, andtelecommunication systems

Basic requirements to satisfy. The RP focuses on theintegration thereof.

DNVGL-RU-SHIPPt.4 Ch.9

DNV GL rules for classification ofships – chapter on control andmonitoring systems

As above.


DNV GL AS


DNVGL-OS-A101 DNV GL offshore standard forsafety principles and arrangements

Basic safety requirements. The RP is compatible with suchsafety requirements, but goes beyond in dealing withbusiness issues.

ARP 4761 Guidelines and methods forconducting the safety assessmentprocess on civil airborne systemsand equipment

Not applicable as such within the RP scope, but used assource material for the RAMS discipline.

ARP 4754 Certification considerations forhighly- integrated or complexaircraft systems

As above.

DNVGL-OS-E101 DNV GL offshore standard fordrilling plant

Basic architecture requirements for drilling plants.

The RP is compatible with such requirements.

OLF 070 Guidelines for the applicationof IEC 61508 and IEC 61511 inthe petroleum activities on thecontinental shelf

Applicable safety guidelines. The RP is compatible with suchguidelines, see the RAMS discipline.

OLF 104 Information security baselinerequirements for process control,safety, and support ICT systems

As above.

ISO 9126 Software quality characteristics The RP is compatible with the SW quality characteristicsdefined in 9126. However, whenever practicable, it hasextended the concepts to the system level. The GenericSystem Attributes can be traced mostly to 9126, withadditions from other sources to take into account theintegrated nature of its subject.

ISO/IEC 12207 Information technology - softwarelife cycle processes

The RP is compatible with the SW life cycle processesdefined here. However, it is more general as it covers thesystem life-cycle and not only the SW. See CMMI below.

ISO/IEC 15288 Systems engineering - system lifecycle processes

The RP uses the IEC 15288 and the INCOSE systemsengineering handbook as reference material for the systemsengineering point of view. The RP is tailored to proposea dedicated life-cycle using the maritime and energyvocabulary. The RP is compatible with other life cycles, ifneeded.

ISO 17894 General principles for thedevelopment and use ofprogrammable electronic systemsin marine applications

Specific standard derived from ISO/IEC 61508 for use inmarine applications. The RP is compatible with ISO 17894.The RP provides overall guidelines for implementing therequirements in a practical manner, over a distributed supplychain.

IEC 60300 Dependability management Base standard for the RAMS discipline. Also provides somedefinitions for GSRs, such as availability and reliability.


DNV GL AS


IEC 61508 Functional safety of electrical/electronicprogrammable electronicsafety related systems

Base standard for the RAMS discipline. The RP is compatiblewith IEC 61508. The RP provides overall guidelines forimplementing the requirements in a maritime and energycontext. Detailed techniques as described by the 61508should be used where appropriate. The IEC 61508 providesguidelines to be applied, for example the independenceguidelines.

IEC 61511 Functional safety - safetyinstrumented systems for theprocess industry sector

Derived standard for the process industry.

The RP is compatible with IEC 61511.

The IEC 61511 standard is often used in the energy context.

INCOSE

Handbook

INCOSE systems engineeringhandbook, June 2004

See IEC 15288 above.

CMMI for DEV,V1.2

Capability

Maturity model integration fordevelopment, version 1.2, August2006.

The CMMI model provides the reference system lifecycleprocesses. The RP is compatible with the CMMI modeland uses a similar approach for organizing disciplines andpractices. In addition, the RP distinguishes responsibilities inorder to facilitate the implementation of the practices by thevarious contributors to the project.

SSA Safety and security extensionsfor integrated capability maturitymodels, FAA

Not applicable per se. The RP uses this material fromthe FAA as a way of integrating safety processes withinthe overall systems engineering processes. The SSA iscompatible with IEC 61508 and other functional safetyrelated standards, such as DO-178B and DO-254.

DNVGL-RP-A203 Technology qualification Recommended practice from DNV GL. Can be used inconjunction with this ISDS RP in order to qualify newintegrated technology.


DNV GL AS

SECTION 3 PHILOSOPHY AND PRINCIPLES

3.1 GeneralThis recommended practice provides a process and set of activities for managing the development,procurement, operations and large maintenance of an ISDS.The process is based on the functional breakdown of the ISDS and the allocation of a confidence level to eachof the functions. The confidence level is a measure of how important a function is to the operation of thesystem and safety.The confidence level assignment proposed in this RP shall be adapted for use by the owner or operator.The RP defines a set of activities that shall be applied to that function throughout the project, based on theassigned confidence Level.The RP divides the project into five distinct phases and for each of these phases identifies core activities thatshall be undertaken in any case and activities that are selected based on the confidence level required by thefunction.

Figure 3-1 Integrated software dependent system – development lifecycle

How to implement these activities and processes is not prescribed by the recommended practice. Therecommended practice is primarily focused 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 managingthe project risks (Figure 3-1). The following are examples of decision gates ensuring progress adequacybefore starting new phases and tasks:


DNV GL AS

M0: project launch

— sponsorship, stakeholders and their responsibilities are clearly defined.

M1: ready to design and purchase

— confidence level is defined— overall design is defined (main ISDS elements and main interfaces)— potential subcontractors have been consulted— feasibility is assessed.

M2: 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)— global design is refined, kept consistent and verified.

M3: ready to verify and validate the system

— integration and testing strategies and plans are clearly documented identifying all the milestones andexpected 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 integration tests have been performed.

M4: 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 environment— documentation and training has been delivered.

M5: ready for decommissioningEach of the project phases has a defined set of activities and processes1. The application of these activitiesand processes is dependent on the confidence level assigned to the function (Figure 3-2). The confidencelevel is a measure of how critical a function, subsystem or ISDS Element is to the operation of the system.confidence level of a function, as well as the related ISDS Element, increases as the positive or negativepotential impact of this function increases.1) This generic lifecycle can be tailored if required for the ISDS development. See [5.5] in this RP.Risk based techniques such as an FMECA can be used to assess which functions, systems or ISDS Elementsrepresent the highest risk to the system if lost due to malfunction, mal-operation or poor implementation.The risk is quantified in terms dependent on the application, for example, financial loss, environmentalimpact, etc.The design activities in this RP are meant to help the designers define and describe the desirable systemstates during operation, including safe states in case of degradation of the system or its environment. The RPfocuses on the ISDS states rather than the states of its components.A set of supporting processes has also been defined. These are applied across all of the project phases. Thesupporting processes are a core of common processes that should be applied throughout the project.The following key motivations underline this recommended practice:

1) Other RPs, class rules and regulations deal with individual pieces of equipment or components. This RPfocuses on the integration opportunities and issues, and comes in addition to activities and procedures todesign and implement individual ISDS Elements.

2) Most integration defects are introduced at an early stage and are extremely costly to correct once inoperations2. Therefore, the RP focuses on early activities.


DNV GL AS

3) Most early defects originate in non-written or badly written requirements and architecture2. Thereforethe RP focuses on system requirement activities and architecture activities, and on the validation of theirresults (operational scenarios, performance testing).

4) Most of the time, integration of a complex system is taken into account once ISDS Elements have beenprocured. Identified integration problems are difficult and expensive to correct at that stage, when theystill can be corrected3. Therefore the RP focuses on managing the interfaces over the lifecycle of theproject.

5) The verification and validation of properties of individual ISDS elements or sub-systems are not sufficientand cannot be substituted for the verification and validation of system (emerging) properties. Therefore,this RP focuses on a joint system and component point of view for all activities, including verification andvalidation.

6) This RP is used in many different contexts and usages. Therefore the RP is structured in order tobe scalable and tailor able to the level required. The capability of the processes (the amount anddepth of activities) to be set up is based on a confidence level to be defined at the start of the systemdevelopment.

2) For numbers of defects categorized by phase and type, see [CJ2000].3) DNV SMICT Research, 2006 [DNV2006].The management of interfaces and the interdependencies between functions, ISDS elements and subsystemsis one of the keys to a successful integration project. A single organization shall be the overall responsiblefor managing these interfaces and ensuring that dependent systems operate in the manner defined in therequirements documents and according to the defined safe state.The responsibility of implementing the requirements does not lie with solely one party (e.g. supplier oroperator). It is expected that the supplier responsible of the ISDS element, subsystem or function shall beresponsible for its implementation according to information supplied in the requirements documents and theinterface register.

Figure 3-2 From functionality to confidence levels and recommended integration activities


DNV GL AS

SECTION 4 ASSESSMENT OF CONFIDENCE LEVELS

4.1 Confidence levelsConfidence levels define the required level of trust that a control function or system (or controlled function orsystem) will perform as expected. This RP defines confidence level 1 through 3 where the higher confidencelevel will provide increasingly more reliable systems or control system functions. That means specifyingconfidence level 3 will provide the highest degree of assurance that the control system will be reliable.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 specifiedconfidence level should be.Confidence levels are assigned to the overall system and then to each function within the control system.This then derives the confidence level to the ISDS Elements (components or networks within the system).See [4.4] for further details on this.The number of activities specified by this RP is defined based on specified confidence level. This meansthat based on an assigned confidence level for a control system or function, specified activities are definedthrough its life cycle. It is also possible to define confidence level 0 for a control function which means thatthis RP will not be applied for that function.Project execution risks during the design and building of the systems providing the functions are not takeninto account in the confidence levels. They are taken into account separately, within the support discipline asa part of project management.

4.2 Definition and assessment of the confidence levelsEach function shall have a specific confidence level, based upon the potential impact of a non-performingfunction. The confidence level goes beyond the traditional safety risks and also covers business and economicimpact. Only the potential impact of non-performance of the function is taken into account for the confidencelevel (likelihood is not used at that stage). The performance target should be determined based on anegotiation between supplier and buyer of the system during the concept phase.Three types of potential consequences should be taken into consideration when selecting the confidencelevel: safety, environmental and business impact. When considering business impact one should considerthe cost of restoring the system to working order (cost of downtime, time to diagnose, develop and qualifya modified system) but also the impact on your business reputation which is becoming increasingly moreimportant in today’s market place.The assignment of the associated acceptable level of occurrence is part of the trade-offs made during theconcept phase. This shall be part of a commercial negotiation between system integrator and owner beforethe contract is awarded: design trade-offs (including associated costs during construction and operation)versus the expected costs of non-performance during operation. The core of the negotiation should be theacceptable level of non-performance, not the downgrading of the confidence level required.Table 4-1 provides some guidance on how to select the appropriate confidence level.

Table 4-1 Assessing confidence levels

Potential consequences

Safety Environmental 1 Business impact

Suggestedconfidence

level

The function not behavingas expected does notcompromise safety in anysignificant way.

Loss of functiondoes not impact theenvironment in anymanner.

Loss of function has minimal impact on theoperation.

The function might lead to loss of auxiliaryprocesses but does not affect the mainpurpose(s) of the system.

0


DNV GL AS

Potential consequences

Safety Environmental 1 Business impact

Suggestedconfidence

level

Negligible safetyimplications.

Loss of function maylead to minor pollution.

Loss of function might lead to a temporaryshutdown of non-critical systems that are easilyrepairable. May result in increased operatorworkload.

Loss of function might lead to minor financialloss

1

Loss of function maylead to major injuries orpotential for a fatality.

Loss of function maylead to significantpollution.

Loss of function may lead to prolonged loss ofthe main function of the system. The incidentcould escalate to major financial loss or severedamage to the system.

Degradation of company reputation

2

May lead to multiplefatalities.

Severe environmentalimpact

Loss of function might lead to catastrophic lossof the system and severe financial impact.

Loss of company reputation3

1) Definition of minor, significant and severe environmental impact is dependant on the context, and should bespecified by the owner.

The confidence level is the maximum level resulting from the Table 4-1. For example, if safety andenvironmental impact results in confidence level 1 but business impact results in confidence level 3, thenconfidence level 3 should be chosen.

Guidance note:

1) When discussing potential business impact between owner and supplier/system integrator, it is usually better to definethe consequences in terms of down-time, delay and repair resources rather than in monetary terms. This is because theeconomic impact for a given event will usually be very different for the owner/operator versus the supplier/system integrator.

2) DNVGL-OS-D202 and DNVGL-RU-SHIP Pt.4 Ch.9 define essential, important and non-essential control monitoring, safety andcommunication systems. Generally, this translates to the following confidence levels:

— Essential control monitoring, safety and communication systems generally translate to either a confidence level 2 orconfidence level 3, depending on the impact on human life

— Important control monitoring, safety and communication systems generally translate to confidence level 1

— Non-essential control monitoring, safety and communication systems generally translate to a confidence level 0

3) Assessing the confidence level from the possible consequences is also a means, in this RP, to control systematic failures (seefailure, systematic in [2.1.2]) which likelihoods are difficult to estimate. The higher the confidence level, the more activitiesare in place to prevent, mitigate or tolerate systematic failures, which may occur in the ISDS in software, in configurationdata, in hardware or in the integration thereof.

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

4.3 Function allocation to ISDS elementsA function has a specific confidence level and after the design negotiations have been concluded also astated and measurable set of generic system requirement targets. The function will typically be implementedby several ISDS elements, distributed around the system. The individual ISDS elements might either beacquired or constructed, and even have a stated reliability. However, the quality of the function is onlypartially defined by the quality of the individual ISDS element. The quality is, to a great extent, alsodependent on the consistent behaviour of the ISDS elements which cooperate together to perform thefunction. The design of the overall consistent behaviour of the ISDS elements is the task of the systemintegrator.


DNV GL AS

For confidence levels 1 and above, specific ISDS elements can be assigned lower targets during theengineering phase, based on their place in the overall system architecture, for example by introducingredundancy. However, this does not lower the required confidence level of the complete function: the samelevel of effort and proof has to be delivered to show that the overall architecture of the integrated functionmeets its stated system requirement targets. The allocation of a control function on several ISDS elementsshall be described by a design rationale. It is expected that a system integrator provides this rationaleexplaining the choices made in the overall architecture of the function, including demands on specific ISDSelements, and their contribution to the specific generic system requirement targets (see App.A). This designrationale shall at least describe the way the function is split over several ISDS elements and which designdecisions have been made.

Guidance note:Even when there are two completely isolated chains of ISDS elements realizing the same function (i.e. there are two systemsthat have complete functional redundancy), the overall function and thus all subsystems still are all of the same confidence level.However, the generic system requirement targets for each of the individual chains could be much lower, depending on the riskanalysis. In short, redundancy of equipment does not change confidence level.


4.4 Combining functionsISDS elements in the architecture (i.e. ISDS elements and networks) may be shared by several functionssimultaneously, provided that there shall be a defined confidence level for all functions. The combined useof ISDS elements by several functions shall not affect the generic system requirement behaviour of any ofthe functions (cross-contamination). This means that even when one of the functions is in high demand or adefective state, other functions using the same ISDS element shall not be affected in an unintended way. Therationale provided by the supplier shall describe the way these combination requirements are satisfied andthe tests performed by the integrator shall prove there are no cross contamination effects.The basic principle is that the function with the highest confidence level allocated to an ISDS element willdetermine the required confidence level for that ISDS element. It should be noted that if a function has trueredundancy for an ISDS element then a lower confidence level may be applied. However consideration forcommon mode failure (e.g. software) should be given.Figure 4-1 summarizes the approach for deriving confidence levels of each of the ISDS elements from theconfidence levels of each function they implement. This allows defining a specific confidence level for eachISDS elements, which will be used to identify what are the activities expected from the supplier or developerof each ISDS element.

Figure 4-1 ISDS elements confidence level assessment


DNV GL AS

SECTION 5 SYSTEM AND SOFTWARE ENGINEERING ACTIVITIES

5.1 Phases

5.1.1 IntroductionA typical ISDS lifecycle can be structured using the key milestones described in Sec.3, Philosophy andPrinciples. This structure is the most common and the most recommended: it gives a framework where thereis a focus on the ‘decision gates’ where one can check that the status of the progress is adequate to start thenext type of tasks.However, in some cases, some limits between phases have to be more flexible. Though, it would not berecommendable to drop any notion of decision gates in such context, but rather to provide adaptation rules,allowing more flexibility but keeping the control. This topic is addressed in [5.5].

5.1.2 Concept phase (A)The objective of this phase is to define the scope of the project, the needs and constraints it should fulfil, andto establish the preliminary design of the system. It should identify the main ISDS elements which will beassembled in the system. This is also a setup phase, where project organization should be defined, as wellas the planning of the development. At the beginning of this phase the confidence level shall be defined asdescribed in Sec.4.

5.1.3 Engineering phase (B)In this phase, the detailed design of the system is established, and suppliers are involved to setup thedevelopment of each subcontracted ISDS element of the system. Contracts are established with suppliersand detailed design of each ISDS element is performed.

5.1.4 Construction phase (C)This phase aims at developing or acquiring the ISDS elements of the system, and integrating them into thefinal system. Coding or parameterization of the ISDS elements is performed, ISDS elements are unit-testedand verified, interfaces are verified, and finally the ISDS is verified.

5.1.5 Acceptance phase (D)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 enterinto operation.

5.1.6 Operation phase (E)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 asneeded. The end of life of the system is planned for, to take into account integration issues during the switchfrom the old system to the replacement system, if necessary. Large upgrades should be managed as aseparate project, following a distinct lifecycle based on the RP.


DNV GL AS

Guidance note:The difference between small and large upgrades depends on the subject system, ship or unit. The owner shall be responsible forassigning the use of the RP for a given upgrade. A rule of thumb is that any planned upgrade resulting in the shutdown of the unitor ship for any extended period of time should be managed as a whole project using the RP as an applicable document.


5.2 Disciplines

5.2.1 IntroductionA discipline is a group of activities related to a same type of processes. The activities from one discipline areusually undertaken by a certain type of actors in the project, with dedicated skills.The disciplines we used to structure the practices are described here below.

5.2.2 Requirements engineeringThis discipline gathers the activities needed to elicit, document and manage the requirements, all along thelifecycle of the system. It is mainly focused on the beginning of the development on eliciting the needs thatshould be fulfilled by the system, giving rise to set of requirements and scenarios for the system. The set ofrequirements will then be managed all along the development but also during operations, to keep control onthe functionalities of the system and how all the system parts collaborate to fulfil these needs.There is a close relationship between system requirements (what the system should do) and the architectureand mechanisms within the system (how the system will work). Moreover, there is a permanent trade-offbetween expectations and feasibility, and requirements often have to evolve during system design andimplementation.

5.2.3 Solution definitionSolution definition discipline encompasses the activities needed to establish the technical solution of thesystem: investigating of alternative, selection of the solution. It produces the overall architecture of thesystem, structured into ISDS elements.

5.2.4 DesignThe design discipline aims at providing detailed architecture, modelization and detailed interfaces of ISDSelements and subsystem elements of the system.

5.2.5 ImplementationImplementation covers the coding and parameterization needed to develop the ISDS elements, as well as theassociated support documentation.

5.2.6 AcquisitionAcquisition includes the activities related to subcontracting: proposals, invitation to tender, supplier selection,contract establishment, contract execution, supplier monitoring, deliverables reception, verification andacceptance.Note: In this RP, the acquirer is the system integrator. The word suppliers is used for the others entitieswhich provide parts of the system.


DNV GL AS

5.2.7 IntegrationThe integration discipline covers the assembly and interfaces control activities of the different parts of thesystems.

5.2.8 VerificationThe verification discipline addresses the verification that each product complies with its specification.

5.2.9 Validation and acceptanceThe validation and acceptance discipline covers the activities aiming at controlling that the system fulfils itsintended use in its target environment. These activities apply to final system, but also to the intermediatework products.

5.2.10 Reliability, availability, maintainability and safetyThe reliability availability maintainability and safety (RAMS) discipline gathers the activities aimingat identifying and satisfying the expected system requirements. It comprises the analysis, rules andmechanisms to ensure they will be fulfilled.See App.A for further description on terms reliability, availability and maintainability.

5.2.11 Supportive activities5.2.11.1 Project managementThe project management discipline covers the activities related to planning, monitoring, and controllingthe project. It encompasses activities like tasks identification, estimation and scheduling, establishmentand maintenance of the project plan, identification and coordination of the stakeholders for the project,establishing and tracking the commitments of the different stakeholders, tracking the progress of the projectand controlling it, as well as managing the risks of the projects.In the context of ISDS development, a focus has to be maintained around managing the coordination issuesamong the different stakeholders.

5.2.11.2 Risk managementThe risk management discipline is a support discipline covers the activities related to identifying, qualifying,mitigating and tracking product and project risks, activities conducted by owners, systems integrators,operators and suppliers. Typical risks to be managed include product risks such as risks of not meetingexplicit or implied generic system requirements and include project risks, such as schedule, resource orcosts risks for each phase of the project. The risk management discipline is related both to the projectmanagement discipline and the RAMS discipline.

5.2.11.3 Process and quality assuranceThe process and quality assurance discipline is a support discipline covers the activities related to processmanagement and quality assurance, to ensure the activities recommended by the RP are defined, organizedand executed in a manner consistent with the defined and expected level of quality. Activities include processdefinition, responsibility assignment, quality assurance and quality control.

5.2.11.4 Configuration managementThe objective of configuration management activities is to ensure integrity and consistency of all the workproducts of the system (ISDS elements, specifications, documentation, interfaces …) all along its lifecycle,including the operation phase. It relies on identification of the different items composing the system andtheir status, the establishment of baselines of consistent items, the control of the changes on them, andconfiguration audits.


DNV GL AS

Figure 5-1 Typical distribution of recommended activities throughout the whole lifecycle of theproject.

Figure 5-1 breaks down the activities according to the major responsibilities: owner, operator, supplier andsystem integrator (see below). Further description of these recommended activities are given in Sec.6 toSec.10.

5.3 ResponsibilitiesThis recommended practice addresses several types of actors of the system development, construction andoperation. Each of them has specific activities to perform. Therefore, five responsibilities are defined:

— Owner: The owner is the organisation 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 thewhole system. In some cases, the system integrator may delegate SI activities to suppliers. The delegatedresponsibilities shall be clearly defined. During some phases, the SI role may not be assigned to adedicated organization, in which case the SI responsibility is assigned to one of the existing organizations:owner, operator or supplier.

— Operator: The operator is the organisation who will finally use the system when it is under operations.This covers also the responsibility of maintaining it (this last responsibility may be delegated to anotheractor).


DNV GL AS

— Supplier: The supplier represents any subcontractor which provides an ISDS element of the system, underthe coordination of the system Integrator. The ISDS element may be specifically designed and built for theproject, or customized and parameterized from a standard product baseline.

— Independent verifier: The independent verifier is an organization that is mandated to independently verifythat the system is developed according to the expected rules, standards, processes and quality. Thisresponsibility can be undertaken by either the owner or a third party organization. For systems with highconfidence level (CL3), this responsibility shall be undertaken by a third party company.

Figure 5-2 Typical communications between responsibilities

Establishing well understood roles and responsibilities is critical to establishing clear lines of communicationbetween the various organizations involved in developing the integrated software-dependent system.

5.4 Activities and confidence levelsAs described in Sec.3, this RP provides a scalable approach for good practices implementation. For systemswhich potential consequences of non-performance are negligible, the set of expected activities can bequite low, whereas for systems with high safety, environmental or business implications, a complete set ofactivities will be expected.For each confidence level, this RP identify a consistent set of required activities, which number increases asconfidence level increases. As a result, activities required at level 2 are the ones required for level 1 plusseveral others, and for level 3 we will find the whole set of activities described in this RP.


DNV GL AS

At confidence level 0, no activity is required, except the preliminary assessment of confidence level of thesystem.At confidence level 1, the expected activities aims at ensuring that system is kept under control during itsdevelopment and operations. This means that expected content of each part of the system is thoroughlymanaged, in terms of requirements and configuration. Moreover, it is required at that level that activities areplanned and controlled, to ensure that expected tasks can effectively be performed. For the same reasons, itis also required that subcontracting activities are carefully managed at that level.Confidence level 2 systems involve a more detailed control of the engineering activities. At that level, itmust be ensured that development is performed with a complete, consistent and verified approach. Thus,architecture, design, development, integration, verification and validation tasks shall comply with a large setof expected activities. At this level, risk management activities as well as RAMS requirements identificationand tracking should be performed. This level introduces also the independent verifier, who shall undertakeprocesses verification.Confidence level 3 requires additional activities, needed for such safety and reliability demanding systems.It encompasses generalization of independent verification procedures for engineering activities (design,specifications, coding, testing), as well as the activities needed to ensure RAMS expectations, such as failureanalyses or specific design patterns (e.g.: redundancy).

5.5 Lifecycle tailoringThe structure of the activities per phases has been set up to give a good understanding of the objectivesof the activities according to the context in which they take place. Moreover, it stresses the need to definemilestones within the lifecycle of the system.However, in some cases, the lifecycle to be followed for the system development construction and operationmay differ from the template proposed in this RP.One typical example can be found where development of some ISDS Elements has to be started ahead ofthe defined lifecycle, for example in order to reduce risks on schedule, or on feasibility. In other cases, someISDS Elements can be developed in an iterative approach, with a progressive design and development ofan increasing number of features. In general, most of the usual lifecycle adaptations can occur between thedesign and construction phases.Figure 5-3 illustrates how an iterative development process can be integrated within the project lifecycle fromM0 to M5. Operations may well start at the end of the first iteration block with an initial operational capacity(IOC); with additional functionalities being developed and implemented along the following iterations. In thisexample operations need to be interrupted in order to execute validation activities, which are increasing inworkload along following the increase of operational capacity.


DNV GL AS

Figure 5-3 Lifecycle adaptation using an iterative development process

In addition, major changes on the system (for example replacement or major evolution of a part of thesystem) should follow the same steps as for the development of the whole system, but more limited in timeand restricted to the involved functions and components of the system.In any case, the most important is to define relevant milestones during the development, and to keep thepractice of ensuring all the elements are in the right status to start a new phase of development. If thereis an overlap in the ISDS elements development, the construction mustn't start before interfaces betweenISDS elements are clearly defined. And similarly, integration must not start with untested ISDS elements. Insuch approaches, there is an increased need for a clearly documented integration strategy, identifying all themilestones and expected status of ISDS elements to integrate.In such contexts, activities described in the following sections are relevant and shall be followed, but theyhave to be applied in different design/construction/integration phases within the whole system lifecycle.

5.6 Integrated software dependent systems and new technologyqualificationThere is a clear synergy between the challenge related to ISDS and issues related to qualification of newtechnology.DNV GL has published a recommended practice for the qualification of new technology namely DNVGL-RP-A203 Technology qualification.While DNVGL-RP-A203 focuses on providing a systematic approach to the qualification of new technology,ensuring that the technology functions reliably within specified limits, this DNVGL-RP-D201 focuses onintegrated systems, which are characterized by the complexity of their integration issues, both technologicaland programmatic. Such ISDS may or may not use new technology. If they do, then the risks are increased,


DNV GL AS

by the combination of integration and new technology risks. This section provides the link between the twoRPs.There are two cases when the DNVGL-RP-D201 for ISDS and DNVGL-RP-A203 for qualification of newtechnology can be used in combination:

1) The entire system consists of new technologies to be delivered to a future owner. The RP ISDS providesa complement to the DNVGL-RP-A203 in order to deliver an integrated system fit for purpose and with amature technology level. The DNVGL-RP-D201 is integrated to the DNVGL-RP-A203.

2) The overall system to be integrated includes one or several subsystems or components which arenew technology, which development may be enhanced by the use of the DNVGL-RP-A203. This RP isintegrated at the subsystem level to the DNVGL-RP-D201.

a) Qualifying an integrated systemWhen qualifying an integrated system, the following table shall be used to link the minimumconfidence level for the system and the technology level from DNVGL-RP-A203 Technologyqualification.The confidence level selected by the owner may in the end by higher than recommended by table, inorder to meet business, environmental or safety objectives. When qualifying an integrated system,the new technology lifecycle and the integrated system development lifecycle shall be harmonized:Figure 5-4 is an example of a possible harmonization.

Figure 5-4 New technology qualification and ISDS integrated lifecycleb) Including a new subsystem or component that needs to be qualified

Table 5-1 Confidence levels and technology qualification levels

Technology level

Applicationarea

Technology Techlevel Description

Proven 1Known

Limited fieldhistory

2

Known application and at least field experience of the technology.

There is no impact on ISDS confidence level.


DNV GL AS

Technology level

Applicationarea

Technology Techlevel Description

New Any 2-4

Any New 3-4

Integration of a new application or a new technology. The newapplication area warrants a CL2 as a minimum.

Table 5-1 may be used to provide a minimum technology qualification level, based on the confidencelevel provided by the owner. The selected technology qualification level may be higher in the end,depending on the application of the new technology RP to the subsystem or component.Figure 5-5 shows how the subsystem/component lifecycle may be integrated into the system lifecycle.

Figure 5-5 New technology qualification of a component within an ISDS lifecycle


DNV GL AS

SECTION 6 CONCEPT PHASE

Figure 6-1 The concept phase

6.1 ScopeThe processes in this section cover the initial phases of the project from concept, preliminary design andfront end engineering studies up to the point where main ISDS elements of the system are identified and canbe subcontracted as needed.

6.2 GoalThe goal of this stage is to be able to clearly define the scope of supply of the project, such that theequipment or services can be procured. The phase starts with the purchaser of the system identifying a needfor a system. The purchaser shall define the systems requirements and attributes. The requirements shalldefine the function of the system along with any safety, security or other critical requirements. The definitionshall also detail any specific requirements for design, testing and compliance to applicable rules (class andstatutory), internal and external standards.The supplier shall review the requirements documentation and identify gaps between their intended scopeof supply and the purchaser’s system requirements. These gaps shall be highlighted as a possible risk tothe project. As part of the review the supplier shall also confirm that there is sufficient time in the project tocomplete the system, that they have the appropriate number of skilled staff to perform the work, and thatthey have the infrastructure to support the integration and operation phases.On completion of this phase the preliminary design shall be established, including system architecture. Boththe supplier and the end user shall have a good common understanding of the scope of supply. In additionthe interfaces and areas of increased project risks shall be defined and an individual shall be nominated tooversee the interfaces and integration.

6.3 Mandatory activitiesThese activities are required regardless of confidence level as they are necessary to assess the confidencelevel.

Table 6-1 Mandatory activities

Activity title (see description below) Ref.

Owner

Requirements engineering

Contribute to requirements collection. A.REQ.2


DNV GL AS

Activity title (see description below) Ref.

Supportive processes

Identify risks A.SUP.6

Determine confidence level A.SUP.12

System integrator


Collect requirements A.REQ.1



Supplier



Owner



6.4 ActivitiesTable 6-2 Concept phase activities

Confidence levelActivity title (see description below) Ref.

1 2 3

Owner


Contribute to requirements collection. A.REQ.2 X X X

Contribute to mission, objectives, shared vision and operationalconcept and scenarios definition. A.REQ.5 X X

Solution definition

Achieve balance between needs and feasibility/cost/performance A.SOL.4 X X

Define obsolescence strategy A.SOL.6 X X

Design

Validate concept design documents with stakeholders A.DES.2 X X X

Acquisition

Consult potential subcontractors for acquired components A.ACQ.1 X X X

Validation

Use prototypes or simulations to validate concept A.VAL.2 X X


DNV GL AS


1 2 3


Identify relevant stakeholders A.SUP.2 X X X

Obtain agreement with stakeholders on overall plan A.SUP.3 X X X

Establish work estimates based on task attributes A.SUP.4 X X X

Define a strategy for risk management A.SUP.5 X X

Identify and implement risk mitigation actions A.SUP.7 X X

Define a baseline of requirements A.SUP.8 X X X

Define processes to follow and setup process managementactivities A.SUP.9 X X X

Assign an independent verifier A.SUP.10 X X

Chose a third party independent verifier A.SUP.11 X

Determine confidence level A.SUP.12 X X X

System integrator


Collect requirements A.REQ.1 X X X

Translate needs into product requirements A.REQ.3 X X

Define mission, objectives, shared vision and operational conceptand scenarios. A.REQ.4 X X

Establish and document functional architecture A.REQ.6 X X

Describe allocation of functions to ISDS elements A.REQ.7 X X X

Use traceability matrix to ensure completeness and consistency A.REQ.8 X X X

Solution definition

Select solution for system design using criteria A.SOL.1 X X

Establish top level architecture A.SOL.2 X X X

Perform make/buy/reuse analysis A.SOL.3 X X

Achieve balance between needs and feasibility/cost/performance A.SOL.4 X X

Evolve needs and operational scenarios with design A.SOL.5 X X


Design

Document system design A.DES.1 X X


Implementation

Develop simulators or prototypes to validate concept A.IMP.1 X X


DNV GL AS


1 2 3

Acquisition


Analyse subcontractors proposals to evolve design A.ACQ.2 X X

Integration

Define roles, responsibilities, boundaries and exclusions forintegration activities, for each ISDS element

A.INT.1 X X X

Verification

Verify consistency of customer and product requirements A.VER.1 X X X

Verify completeness of system requirements allocation A.VER.2 X X X

Validation

Present the concept of the system to the users A.VAL.1 X X


Reliability, availability, maintainability and safety

Determine rules, standards and laws applicable A.RAMS.1 X X

Qualify RAMS environment A.RAMS.2 X X

Collect reliability, availability, maintainability and safety relatedrequirements A.RAMS.3 X X


Establish and maintain the development plan of the system,including high level master schedule A.SUP.1 X X X

Identify relevant stakeholders A.SUP.2 X X X



Define a strategy for risk management A.SUP.5 X X

Identify risks A.SUP.6 X X X

Identify and implement risks mitigation actions A.SUP.7 X X



Assign an independent verifier A.SUP.10 X X

Supplier

Acquisition



DNV GL AS


1 2 3

Submit proposals to system integrator with compliance status A.ACQ.3 X X X

Integration

Define roles, responsibilities, boundaries and exclusions forintegration activities, for each ISDS element

A.INT.1 X X X





Operator


Contribute to requirements collection. A.REQ.2 X X X

Contribute to mission, objectives, shared vision and operationalconcept and scenarios definition. A.REQ.5 X X

Solution definition

Evolve needs and operational scenarios with design A.SOL.5 X X


Design


Acquisition


Validation

Present the concept of the system to the users A.VAL.1 X X X





Identify and implement risks mitigation actions A.SUP.7 X X



Independent verifier

Verification


DNV GL AS


1 2 3

Independently verify overall design A.VER.3 X


DNV GL AS

SECTION 7 ENGINEERING PHASE

Figure 7-1 The engineering phase

7.1 ScopeThis phase covers the system definition and design activities and processes. It covers the clarification andfinal acceptance of the system specifications and the detailed design of the system and subsystems. Decisionto acquire some ISDS elements is done at this stage, and contracts are established with suppliers. This phasestarts by taking the preliminary architecture and designs and refining them into the final architecture anddesign, looking at the whole system and interfaces as well as each ISDS element.

7.2 GoalThe goal of this stage is to produce detailed design documents from the preliminary designs. The systemarchitecture shall be finalised and all interfaces and interdependencies shall be defined and managed. Thesystem shall be broken down and the subsystems shall be identified. Function confidence levels shall beassigned. Project risks shall be identified, recorded and controlled.The design shall be evaluated against the system requirements document, particular attention shall bepaid to the consistency of the design to the system requirements document, the testability of the system,the feasibility of the system architecture design, appropriateness of the standards and design tools used,the feasibility of the functions fulfilling their requirements and the feasibility of integration, deployment,operation and maintenance. Traceability of the system design to the requirements specification shall bemaintained at all time.Interfaces between subsystems shall be identified and documented. The interfaces shall be documented withsufficient detail so that no further information is required for the design process.In case of high confidence level system, it is expected that during this phase risk analysis tools such asHAZOPs, HAZIDs and FME(C)A are employed, giving rise to systematic identification of procedures andspecificities to take into account during system and ISDS elements development.The verification and validation plans shall be finalised. These plans shall be traceable to the requirementsspecification and risk studies, to ensure system can be fully tested against the needs it should fulfil.The integration and deployment plans shall be produced; these shall include test requirements, equipmentand personnel requirements, procedures, responsibilities and schedule.


DNV GL AS

7.3 ActivitiesTable 7-1 Engineering phase activities


1 2 3

Owner

Acquisition

Identify main contractor A.SUP.6 X X X

Validation

Define validation strategy B.VAL.1 X X


Review and update risks B.SUP.3 X X X

Decide and track risk mitigation actions B.SUP.4 X X

Establish a baseline of requirements and design B.SUP.6 X X X

Control processes B.SUP.7 X X X

Establish project plan B.SUP.9 X X X

Monitor project status against plan B.SUP.10 X X X

System integrator


Refine system requirements into components requirements B.REQ.1 X X

Detail use cases and operational scenarios by component B.REQ.2 X X

Maintain traceability of requirements including refinedrequirements B.REQ.4 X X X

Solution definition

Establish technical solution and provide physical layout view B.SOL.1 X X

Verify consistency of design with operational scenarios B.SOL.2 X X

Achieve balance between technical constraints and systemobjectives B.SOL.3 X X

Maintain system design documentation B.SOL.4 X X

Establish canonical data model B.SOL.5 X X X

Design

Document component interfaces B.DES.2 X X

Design into independent components. B.DES.4 X

Implementation


DNV GL AS


1 2 3

Develop prototypes to reduce design or integration risks B.IMP.1 X X

Acquisition

Select subcontractors B.ACQ.1 X X X

Select COTS B.ACQ.2 X X X

Establish contract with subcontractors B.ACQ.3 X X X

Establish COTS acquisition contract B.ACQ.5 X X X

Select COTS based on obsolescence criteria B.ACQ.6 X X

Integration

Review consistency of interfaces design B.INT.1 X X

Define Integration strategy B.INT.2 X X

Verification

Review completeness of design with respect to requirements anddesign rules B.VER.1 X X X

Define verification strategy B.VER.2 X X

Validation


Validate design by prototyping B.VAL.2 X X


Identify RAMS risks and priorities B.RAMS.1 X X X

Identify mitigation actions for selected events leading to majorfailures B.RAMS.2 X X

Perform FMECA on critical functions B.RAMS.3 X

Perform independent criticality analysis. B.RAMS.4 X


Integrate master plan for development and stakeholders plans B.SUP.1 X X X


Decide and track risks mitigation actions B.SUP.4 X X

Allocate resources to integration/verification/validation tasks B.SUP.5 X X X





Supplier


DNV GL AS


1 2 3


Refine system requirements into components requirements B.REQ.1 X X

Detail use cases and operational scenarios by component B.REQ.2 X X

Maintain traceability of requirements including refinedrequirements B.REQ.4 X X X

Solution definition

Establish technical solution and provide physical layout view B.SOL.1 X X

Establish canonical data model B.SOL.5 X X X

Implementation

Develop prototypes to reduce design or integration risks B.IMP.1 X X

Design

Design each component B.DES.1 X X

Document component interfaces B.DES.2 X X

Document component design B.DES.3 X X

Acquisition

Establish contract with subcontractors B.ACQ.3 X X X

Select COTS based on obsolescence criteria B.ACQ.6 X X

Integration

Review consistency of interfaces design B.INT.1 X X


Provide estimation of work by component B.SUP.2 X X X







Operator


Detail operational scenarios by component B.REQ.3 X X

Validation



DNV GL AS


1 2 3









Verification

Perform independent selected design reviews B.VER.3 X X

Verify independently technical Specification B.VER.4 X

Verify independently design documents B.VER.5 X

Verify canonical data model B.VER.6 X X


Perform independent criticality analysis. B.RAMS.3 X


Independently control processes B.SUP.8 X X


DNV GL AS

SECTION 8 CONSTRUCTION PHASE

Figure 8-1 The construction phase

8.1 ScopeThis phase covers the realisation activities of the project when the system is manufactured, procured andassembled from the designs produced in the previous phase. Parameterization and configuration of itemsshall also be considered as part of implementation phase. Unit testing and commissioning is also undertakenin this phase. The consistency of interfaces and readiness of ISDS Elements are verified and integration isperformed.

8.2 GoalThe aim of this phase is to complete the manufacturing, procurement and assembly tasks as defined in thedetailed specifications and according to the project schedule.The items (systems, sub-systems and ISDS elements) shall also be tested according their respective testplans. All interfaces shall be simulated and tested to confirm their correctness. The coverage of the testingshall be defined and measured in proportion to the items required confidence level: the higher the confidencelevel, the more coverage shall be achieved. The coverage objective shall be defined by the system integratorand accepted by the supplier.All subsystems and ISDS elements that were defined in the design shall be delivered so that integration canbegin. The ISDS elements and subsystems are brought together into a single system; thorough integrationtesting shall be used to verify the integration of the systems and ISDS elements. Interface testing shallbe performed to expose faults in the interfaces and the in the interaction between ISDS elements andsubsystems.

8.3 ActivitiesTable 8-1 Construction Phase Activities


1 2 3

Owner


Manage change requests C.REQ.1 X X X

Validation


DNV GL AS


1 2 3

Validate performances using a prototype C.VAL.1 X X


Track risks C.SUP.1 X X X

Decide and track risks mitigation actions C.SUP.2 X X

Establish a configuration management plan C.SUP.3 X X X

Follow configuration management rules C.SUP.4 X X X

Control processes during construction C.SUP.7 X X X

Monitor project status against plan C.SUP.9 X X X

System integrator



Maintain requirements traceability C.REQ.2 X X X

Solution definition

Manage changes to the technical solution C.SOL.1 X X X

Implementation

Define quality targets and track quality status C.IMP.4 X X

Ensure interfaces are free of deadlock C.IMP.5 X X

Design without single point of failure C.IMP.6 X X

Obtain complete understanding of interfaces C.IMP.7 X X

Acquisition

Monitor contracts execution with suppliers C.ACQ.1 X X X

Manage contract changes C.ACQ.2 X X X

Ensure visibility on suppliers activities C.ACQ.3 X X

Review intermediate deliverables from subcontractors C.ACQ.4 X X

Accept deliverables from subcontractors C.ACQ.5 X X X

Accept and ensure transition of acquired COTS C.ACQ.7 X X X

Integration

Provide integration, validation and verification environments C.INT.1 X X

Transfer components to integration after decision to release C.INT.2 X X X

Check readiness status of components before integration C.INT.3 X X

Assemble the components C.INT.4 X X

Perform integration tests C.INT.5 X X


DNV GL AS


1 2 3

Maintain canonical data model C.INT.6 X X X

Verification

Perform peer-reviews on software and documents C.VER.1 X X

Detail procedures for testing C.VER.2 X X

Perform verification on developed components C.VER.3 X X

Perform verification tests C.VER.4 X X

Ensure test coverage as specified (statements and data coupling) C.VER.5 X X

Ensure test coverage as specified (MC/DC) C.VER.6 X

Perform code analysis C.VER.7 X X

Validation



Evaluate components and modules against RAMS requirements C.RAMS.1 X X

Ensure no interference between confidence level of functions C.RAMS.2 X X X

Protect network against domination C.RAMS.3 X X

Provide secondary means of operation for essential functions C.RAMS.4 X




Establish a release note for ISDS C.SUP.6 X X X


Supplier



Solution definition

Manage changes to the technical solution C.SOL.1 X X X

Design

Refine design during implementation if needed C.DES.1 X X

Implementation

Develop the components from design C.IMP.1 X X X

Develop support documentation C.IMP.2 X X

Perform unit testing for components C.IMP.3 X X X


DNV GL AS


1 2 3

Define quality targets and track quality status C.IMP.4 X X

Obtain complete understanding of interfaces C.IMP.7 X X

Integration

Maintain canonical data model C.INT.6 X X X

Acquisition

Manage contract changes C.ACQ.2 X X X

Accept deliverables from subcontractors C.ACQ.5 X X X

Ensure transition of delivered product C.ACQ.6 X X X

Verification

Perform peer-reviews on software and documents C.VER.1 X X

Perform verification on developed components C.VER.3 X X

Ensure test coverage as specified (statements and data coupling) C.VER.5 X X

Ensure test coverage as specified (MC/DC) C.VER.6 X

Perform code analysis C.VER.7 X X


Evaluate components and modules against RAMS requirements C.RAMS.1 X X



Decide and track risks mitigation actions C.SUP.2 X X



Establish a release note for delivered components C.SUP.5 X X X



Operator



Validation




Decide and track risks mitigation actions C.SUP.2 X X X


DNV GL AS


1 2 3






Verification

Perform independent code analysis C.VER.8 X

Perform independent ISDS elements qualification C.VER.9 X


Independently control processes during construction C.SUP.8 X X


DNV GL AS

SECTION 9 ACCEPTANCE PHASE

Figure 9-1 The acceptance phase

9.1 ScopeThis phase covers all activities involved in assuring compliance of the system to the requirements. The phasealso covers the deployment, integration and testing on site up until the system is handed over for operation.

9.2 GoalThe aim of this phase is to control the activities from the completion of the integration tests to the pointthe system is handed over to operations. The aim of this phase is to ensure that the ISDS elements andsubsystems perform as expected as a single system. The system performance shall be validated againstthe procurement specifications. Testing may occur off-site, prior to shipping on-site. In addition to nominalmodes, selected failure modes of the system shall be tested to ensure that the defined safe states are valid.

9.3 ActivitiesTable 9-1 Acceptance phase activities


1 2 3

Owner


Manage change requests D.REQ.1 X X X


Establish a control system on deployed configuration D.SUP.3 X X X

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 actions D.SUP.8 X X

System integrator



DNV GL AS


1 2 3


Solution definition

Manage changes to the technical solution D.SOL.1 X X X

Implementation

Implement changes to the system in a controlled manner model D.IMP.1 X X X

Acquisition

Accept deliverables from suppliers D.ACQ.1 X X X

Verification

Perform verification on developed and integrated components D.VER.1 X X X

Validation

Perform validation through operational scenarios D.VAL.1 X X

Analyse results with respect to quality targets D.VAL.2 X X

Perform black-box testing D.VAL.3 X X


Collect RAMS arguments and evidence to demonstrate achievementof RAMS objectives D.RAMS.1 X X


Establish a release note for the system that enters into operations D.SUP.1 X X X

Submit and decide components changes to control board D.SUP.2 X X X


Control configuration during acceptance in case of updating D.SUP.4 X X X





Supplier



Solution definition

Manage changes to the technical solution D.SOL.1 X X X

Implementation

Implement changes to the system in a controlled manner model D.IMP.1 X X X


DNV GL AS


1 2 3

Verification

Perform verification on developed and integrated components D.VER.1 X X X


Establish a release note for the system that enters into operations D.SUP.1 X X X

Submit and decide components changes to the control board D.SUP.2 X X X






Operator



Validation

Perform validation through operational scenarios D.VAL.1 X X

Analyse results with respect to quality targets D.VAL.2 X X








Validation

Perform independent validation and verification D.REQ.1 X

Independently control processes D.SUP.9 X X


DNV GL AS

SECTION 10 OPERATION PHASE

Figure 10-1 The operation phase

10.1 ScopeThis phase covers all operational and maintenance activities, including scheduled and unscheduled upgradesand problem resolution activities. The phase also extends to retirement activities. The responsibilities fortasks in this phase can lie either with the supplier or with the operator.

10.2 GoalThe goal is to manage the operation of the system from first start-up to retirement. The aim is to set inplace procedures that manage the operational testing, system operation, maintenance, system audit anduser support. In addition a structured manner of analysing problems and modifications and implementingmodifications shall be developed. Where necessary, a retirement plan shall be developed and maintainedthroughout the life of the project.

10.3 ActivitiesTable 10-1 Operation phase activities


1 2 3

Owner


Manage change requests E.REQ.1 X X X

Acquisition

Manage and monitor obsolescence E.ACQ.1 X X

Validation

Perform validation through operational scenarios E.VAL.1 X X


Transfer responsibility for system configuration management tooperator E.SUP.1 X X X

Analyse impacts of modification requests and decide changes E.SUP.5 X X X


DNV GL AS


1 2 3

Control processes 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 actions E.SUP.10 X X

System integrator



Solution definition

Manage changes to the technical solution E.SOL.1 X X X

Implementation

Implement changes to the system in a controlled manner model E.IMP.1 X X X

Verification

Perform verification on developed and integrated components E.VER.1 X X X



Define procedures for maintenance activities E.SUP.2 X X X

Analyze impacts of modification requests and decide changes E.SUP.5 X X X

Supplier



Solution definition

Manage changes to the technical solution E.SOL.1 X X X

Acquisition




Control processes E.SUP.7 X X X




Verification


DNV GL AS


1 2 3

Perform verification on developed and integrated components E.VER.1 X X X

Operator



Acquisition



Monitor operations and report incidents E.RAMS.1 X X



Define procedures for maintenance activities E.SUP.2 X X X

Perform operational testing after upgrading E.SUP.3 X X X

Manage change requests during maintenance E.SUP.4 X X X


Perform configuration audits E.SUP.6 X X X

Control processes during operation E.SUP.7 X X X





DNV GL AS

APPENDIX A GENERIC SYSTEM REQUIREMENTSEach ISDS operator will have different priorities for the generic system requirements which shall be explicitlydefined in order to be able to perform the necessary tradeoffs. Such priorities may not be established byan outside party in general. The priorities as defined by the ISDS operator are called the generic systemrequirement targets (GSR) in this document.

Figure A-1 The generic system requirements

The generic system requirement attributes list (see Figure A-1) is:

— Functionality, the ability for the ISDS to perform as expected in its intended environment.— Reliability, the ability for the ISDS to continue performing its functionality, perhaps in a degraded mode, in

the presence of faults.— Availability, the ability for the system to provide access to its resources in a timely manner for a specified

duration.— Maintainability, the ability for the ISDS to be repairable and enhanced over time.— Usability, the ability for the ISDS to be used by its intended service personnel.— Efficiency, the ability for the ISDS to use efficiently the resources provided; hardware, software and

consumables.— Portability (for the software), the ability for the ISDS software to be ported to other hardware and

operating systems in order to mitigate technical obsolescence— Integrability: the ability for separately developed ISDS elements to work correctly together, as planned.— Functional safety: Functional safety is part of the overall safety that depends on a system or equipment

operating correctly in response to its inputs.

The ISDS operator or its representatives shall define their priority for each system requirement attributeabove.Each generic system requirement selected is described in the following paragraphs.


DNV GL AS

A.1 Building a consistent set of generic system requirementsThe structure of consistent set of generic system requirements is as follows:

Figure A-2 The generic system requirement structure

A generic system requirement (or characteristic) defines a set of attributes. The set of attributes areproposed by this RP, but may be reduced or increased as needed.System attributes define measurable objectives for the owner and/or operator.A system attribute is therefore a set of metrics, which have defined target values. The target values shouldbe defined by the owner and operator, and agreed upon by the integrator and its suppliers.

A.2 Consequences of omitting generic system requirementsIt is common for owners, operators and system integrators to omit generic system requirements, from theirrequirements. The obvious consequence is that they are not taken into account by the supply chain, from theintegrator to the last component manufacturer. In this situation, each organization will design and developor provide components, subsystems and systems with their own level of expectations for the GSR. There is,of course, no chance at all that the suppliers’ GSRs will be identical to, or even compatible with the impliedGSRs of the owner and operators.The most common risks resulting from implicit GSRs, as seen in the field are:

— Lack (or excess of) functionality: the system is not suitable for the expected purpose. The owner oroperator had another functionality in mind and discovers (during factory acceptance tests (FAT) or later)the provided functionality. Depending on the contract, the piece of equipment will have to be accepted asis, or reworked, incurring costly delays.

— Lack of RAMS will lead directly to operational problems if not detected during FAT or commissioning,in some cases, rendering the system inoperable. If detected during commissioning, depending on theseverity, may lead to rework or scrapping of the system to be replaced by another with suitable GSRs.

— Lack of quality attributes leads to lack of performance, reduced usability and reduced portability. Thiswill lead to higher operational and maintenance costs, including costs for all concerned (from owner tosupplier), and will lead also to a reduced operating life (portability, changeability, for example). The lack


DNV GL AS

of portability will also drastically increase the risk of obsolescence, inducing the need to scrap the wholesystem when an electronic device or other hardware ceases being available as a spare part.

A.3 Adding other generic system requirementsThe GSRs selected in this RP are commonly used (see ISO 9126, IEC 61508) and have an impact on systemswithin the scope of the RP. Other GSRs may be evaluated and included as requirements by the owner oroperator. See the appendices for references and bibliography for additional GSRs.

A.4 Functionality

A.4.1 DefinitionThe functionality system requirement defines the ability for the ISDS to perform as expected in its intendedenvironment.

A.4.2 UsageThe functionality system requirement shall be defined in terms of the compliance of the functions provided bythe ISDS with respect to expected:

— process functions, both active and passive— control functions— monitoring functions— maintenance facilitation functions— safe operation or safe shutdown functions.

The measurement is usually a Boolean value: yes or no. When combined with prioritization and for a set offunctions, the aggregate measure may be a percentage of functions provided for different levels of priority(for example: Must have, Should have, Could have, Won't have, abbreviated as MoSCoW) 1.1) MoSCoW Prioritization rules : see DSDMThe specific functionality is mainly described in project functional requirements, other rules, regulations andstandards. The generic attributes of functionality are:

— Suitability: determines the appropriateness (to specification) of the functions of the ISDS; usuallymeasured by a simple Boolean value (yes or no).

— Accuracy: This refers to the correctness and precision of the functions,

— For example, in dynamic positioning (DP): precision in meters of the positioning, or in degrees of theorientation of the vessel.

— Interoperability: this attribute concerns the ability of an ISDS or ISDS Element to interact with other ISDSelements or systems. Usual metrics measure compliance to de facto or de jure standards (like ModBus)

— Security:

— Confidentiality: determines the access by authorized personnel (and non-access by non-authorizedpersonnel).

— Integrity: determines the rights of authorized personnel to change the system, in particular its data(either operating or configuration).

— Availability may be a component of security. See below.Usual metrics measure compliance to security regulations or results from security audits

— Compliance: compliance with other rules and regulations. Usually measured by simple Boolean values(yes or no).


DNV GL AS

These attributes shall be related to a functional analysis of the ISDS and of the by the ISDS systems undercontrol.

A.5 Reliability

A.5.1 DefinitionReliability is the capability of the ISDS to maintain a specified level of performance when used underspecified conditions.

A.5.2 UsageReliability may be expressed in terms time measurements, for example, using MTTF or MTBF, characteristics,for failures leading to partial or total loss of functionality, or expressed in terms of tolerance to faults orprobability of failure on demand.The attributes of reliability generally accepted1 are:

— Maturity, the attributes of the system that bear on the frequency of faults in the system, for example:

— design complexity of the hardware, number of CPUs, number of IOs— defect density in the software, defects per KLOC, thousand lines of source code (KLOC)— MTTF; mean time to failure— MTBF, mean time between failure.

— Fault tolerance, the attributes of the ISDS that bear on its capacity to maintain a specified level ofperformance in case of fault or interface infringement, for example:

— redundancy of hardware— independency of software design and implementation— number of faults a system can tolerate or recover from.

— Recoverability (for SW) 2, the attributes of the software of the system that bear on the capability to re-establish the level of performance and recover the data directly affected by the failure, and the time andcost to do so, for example:

— the SW-MTTR (mean time to repair)— availability of back-up and restore functions— time to restore SW or data from archive.

1) Source: ISO91262) It should be noted in this case that SW recoverability is a reliability attribute, and not a maintainabilityattribute, in order to stay compliant as much as possible with ISO 9126. Change of SW is not included here,but is dealt with in maintainability.

A.6 Availability

A.6.1 DefinitionAvailability (performance) is the ability for the system to be in a state to perform its functions under givenconditions at a given instant of time or over a time interval, assuming the required external resources areprovided.


DNV GL AS

A.6.2 UsageTypical availability characteristics include:

— Mean uptime (MUT), the average time the function or system is available. Measured as a percentagecomputed for a specified period, for example, 99.7% for the calendar year

— Mean downtime (MDT), the average time the function or system is not available. Measured in as apercentage computed for a specified period, for example, 0.3% per year (24 hours total downtime peryear, for the calendar year), or 2% per day (equivalent to 30' total downtime per day)

— Probability of a successful operation for discrete functions, such as starting or stopping a motor, setting analarm, etc). measured in percentage.

— Continuity of operations, measured in duration units (hours, days, weeks, …).— Expected operations life, measured in duration units (e.g. years).— Expected shelf life, measured in duration units (e.g. years).

Availability takes into account the reliability and maintainability performances.

A.7 Usability

A.7.1 DefinitionUsability is the system’s capacity to be usable by its intended operators and maintenance technicians.

A.7.2 UsageTypical usability attributes include:

— Understand ability: determines the ease of which the ISDS functions can be understood, relates to usermental models in human computer Interaction methods. Typical metrics include:

— expected years of formal training of users (none, technician, engineer, PHD-level)— expected years of experience of users.

— Learn ability: determines the learning effort for different types of personnel, may be further broken downinto (familiarity, consistency, generalise ability, predictability, simplicity) or aggregate measures may beused, such as:

— expected time of training to proficiency (days, weeks, months)— expected time for using uncommon system functions (seconds, minutes, hours)— availability of training material or resources (paper, electronic, web-based, human teachers).

— Operability: Operability is the ease with which a system operator can perform the assigned mission with asystem when that system is performing its required functions. Typical measures include:

— operating costs per unit of time— operating cost profile over the designed life period— number of operators needed, overall or simultaneously.Guidance note:For example, one usability metric may be established as follows: select 3 experienced operators of more than 2 years ofexperience, perform a 2-hour training on an ISDS, and have them demonstrate their usage of more than 80% of the availablefunctionality. The target value may be that 2 of the 3 selected operators are capable of achieving the result.



DNV GL AS

A.8 Efficiency

A.8.1 DefinitionThe efficiency of the system is the capability of the system to provide appropriate performance, relative tothe amount of resources used, under stated conditions.

A.8.2 UsageTypical efficiency characteristics include:

— Time behaviour: Characterizes response times for a given throughput

— Control:commands to be sent and acknowledged within specified hard-real-time constraints

— Monitoring:alarms to be received within specified hard-real-time constraints,alarms to be received in order of appearance,alarm priorities and handling in order to prevent alarm flooding.

— Network usage:Throughput, latencies, quality of service.

— Resource behaviour: Characterizes resources used, e.g. memory, CPU, disk, network and electrical andother fluxes’ usage.

A.9 Maintainability

A.9.1 DefinitionMaintainability is the ability for the system to be repairable and enhanced over time.

A.9.2 UsageMaintainability characteristics are:

— Analyzability: attributes of the system that bear on the effort to diagnose deficiencies or causes offailures, or to identify parts to change;

— Changeability: Attributes of the ISDS that bear on the effort needed for modification, fault removal or forenvironmental change;

— Stability: Attributes of the ISDS that bear on the risk of unexpected effect of modifications;— Testability: Attributes of the ISDS that bear on the effort needed for validating the modified software.

These attributes are applicable to both hardware and software. In the software, these attributes are oftenmeasured by assessing the structure of the SW, the presence or absence of means to enhance or hindermaintainability like object-oriented programming, the use of multiple inheritance, the use of separate orjoined modules, the use of well-documented parameters, etc.For example, one measure of maintainability for an ISDS may be established as follows: select onemaintenance technician, perform the standard one day training on maintenance operations, and thenmeasure how many maintenance issues he or she is capable of addressing during a test period of 3 or 6months. A target measure may be 80% of expected maintenance issues should be addressed.


DNV GL AS

A.10 Portability

A.10.1 DefinitionPortability is the ability for the ISDS software to be transferred from one environment (hardware, operatingsystem) to another.

A.10.2 UsageThis characteristic is available only for software. The quality attributes defined are:

— Adaptability: Attributes of software that bear on the opportunity for its adaptation to different specifiedenvironments without applying other actions or means than those provided for this purpose for thesoftware considered

— Installability: Attributes of software that bear on the effort needed to install the software in a specifiedenvironment

— Conformance: Attributes of software that make the software adhere to standards or conventions relatingto portability

— Replaceability: Attributes of software that bear on opportunity and effort using it in the place of specifiedother software in the environment of that software.

Portability is often used to mitigate technology obsolescence, in particular technology obsolescence ofhardware.

A.11 Integrability

A.11.1 DefinitionIntegrability is the ability for separately developed ISDS elements of an ISDS of working correctly together,as planned.

A.11.2 UsageThe following attributes compose the integrability characteristic:

— Data consistency: the absence of contradictory data in the system. The use of uniform design anddocumentation techniques throughout the system’s development project

— Version consistency: the ability of avoiding version mismatch in a configuration— Adaptability: the ability for adaptation to new requirements or new environment or similar— Composeability: the ability to be integrated with the parts of a system— Interoperability: the ability of a system to work with another system— Openness: the ability to integrate new functions developed by third party— Heterogeneity: the ability to integrate heterogeneous elements both software and hardware.

A.12 Functional safety

A.12.1 DefinitionFunctional safety is part of the overall safety that depends on an ISDS or equipment operating correctly inresponse to its inputs. [IEC 61508].


DNV GL AS

Neither safety nor functional safety can be determined without considering the system as a whole and theenvironment with which it interact.Other requirements may distinguish between safety systems and control systems, and may require, as ameans to provide functional safety, separation of safety systems and control systems.

A.12.2 UsageThe ISDS may provide direct safety functionality, which needs to be operated with a high confidence, suchas starting/stopping pumps, starting/stopping fire-fighting equipment, etc. The safe state of operations isachieved when the safety functioned is executed as needed, in a discrete or continuous manner.In addition, the ISDS may provide functions which have a safety component:

— Some functions need to be operated in a continuous manner to maintain safety, such as DP during someoperations like docking or drilling. The safe-state of operations is the current operational mode and needsto be maintained, even in case of failure.

— Some functions may have their operations discontinued in case of failure, but need to fail gracefully inorder to bring the ISDS and the system to a safe-state.

Functional safety attributes are:

— Safety Functions: which safety functions are provided by the system,— Safety Integrity Level: the likelihood of a safety function being performed satisfactorily. (See IEC 61508).

A.13 Specification of characteristics and attributesExpectations for the system that will be developed must be clearly established by the owner and/or operatoras early as possible in system lifecycle. These expectations should state for each type of generic systemrequirements what will be the tangible measures to use to assess if objectives are achieved with respect toeach generic requirement attribute (target values).The specification of these expectations may follow the template given here below. This specification shouldbe performed by the system integrator for specifying/designing the ISDS and its major subsystems, basedon the input provided by the owner and/or operator. The metrics and target values should be defined for theISDS and its critical elements.Various RP activities (A.REQ.1 to A.REQ.5, in particular A.REQ.3, A.RAMS.3) implement the best practices forspecifying generic system requirements.

A.14 Balancing between generic system requirements, feasibilityand other needsDuring the system lifecycle tradeoffs will naturally occur between the functionality, dependability, quality,schedule and costs needs. The stakeholders involved in the project should upgrade as necessary the variousrequirements of their project, in particular the generic system requirements, in order to maintain a consistentlevel of expectations within the project.Various RP activities (A.SOL1, A.SOL.3, A.SOL.4 and A.SOL.5, A.ACQ.2, B.SOL.3) implement the bestpractices for balancing tradeoffs between the various generic system requirements. The RP change requestactivities (C.REQ.1, D.REQ.1, E.REQ.1) also include a trade-off activity.

A.15 Verification of achievement of characteristics and attributesDuring the system lifecycle, once the attributes and their targets are defined, it is necessary to verify usingvarious means that the targets have been achieved according to the requirements.Various RP activities implement best practices for verifying the achievement of generic system attributetargets:


DNV GL AS

— Functional requirements are checked using functional and operation verification and validation (forexample: C.VER.4, D.VER.1, D.VAL.1, D.VAL.3, E.VER.1, E.VAL.1).

— RAMS requirements are checked using inspections, verification and validation (for example: C.VER.1,C.VER.5, C.VER.6, C.VER.7, C.VAL1, C.RAMS.1, C.RAMS.3, C.RAMS.4, D.RAMS.1, E.RAMS.1).

Table A-1 Generic system requirements target

Requirement set Generic systemrequirements Attribute Metric Target value

Functionality Suitability

Accuracy

Interoperability

Security

Functionality

Compliance

Reliability Maturity

Fault tolerance

Recoverability

Availability Mean uptime

Mean downtime

Probability of successful operation (fordiscrete functions)

Continuity of operations

Expected operations life duration

Expected shelf life duration

Maintainability Analyzability

Changeability

Stability

Testability

Functional safety Safety functionality

RAMS

Safety integrity

Usability Understandability

Learnability

Operability

Efficiency Time behaviour

Quality

Resource behaviour

Portability Adaptability

Installability


DNV GL AS

Requirement set Generic systemrequirements Attribute Metric Target value

Conformance

Replaceability

Integrate ability Data consistency

Version consistency

Adaptability

Composeability

Interoperability

Openness

Quality (Ctd)

Heterogeneity


DNV GL AS

APPENDIX B DETAILED DESCRIPTION OF RECOMMENDEDACTIVITIES

B.1 Concept phase activitiesA.REQ.1 Owner and operator requirements shall be collected. These

requirements should focus on operational needs, but also theconstraints the owner is placing on the system. Collection of therequirements may be supported by prototyping, market survey ortechnology demonstrations. Supplier should be proactive to help thepurchaser to formulate its requirements.

CL0 SI

A.REQ.2 Owner and Operator should participate to requirements collection. CL0 OWOP

A.REQ.3 Product requirements shall be specified, translating purchaser needsinto system requirements.Non-functional requirements and constraints (see App.A Genericsystem requirements) shall be specified in addition to delivera complete and consistent set of functional and non-functionalrequirements.

CL2 SI

Particular care should be taken to express requirements relatedto reliability, including degraded and backup modes, as well asperformance. More generally, the usage of the general systemrequirements to specify nonfunctional requirements is recommended tobuild a complete set of requirements.

A.REQ.4 Mission and objectives of the system shall be defined. Main use casesfor the system should be identified. The vision of the system missionshall be formalized and shared by all the stakeholders. Operationalconcept and scenarios shall be established (in relation with overalldesign).

CL2 SI

Operational concept is a general description of the way in which thesystem is used or operates.Operational scenario is a description of a typical sequence of eventsthat includes the interaction of the system environment and users, aswell as interaction among its components.Operational scenarios are used to evaluate the requirements anddesign of the system and to verify and validate the systems.

A.REQ.5 Owner and operator should participate to mission, objectives, sharedvision and operational concept and scenarios definition activities. Theyshould agree and validate these elements.

CL2 OWOP

A.REQ.6 Functional architecture of the system should be established anddocumented.

CL2 SI

A.REQ.7 Allocation of functions/requirements to components should bedescribed (in relation with overall design).

CL1 SI


DNV GL AS

A.REQ.8 Traceability of requirements allocation shall be ensured. A matrixbetween purchaser requirements, system requirements and componentallocation shall be established. Consistency and completeness of thematrix shall be verified to ensure no requirement has been forgotten oradded.

CL1 SI

A.SOL.1 Alternatives solutions for overall systems design shall be evaluated.Selection of technical solution for overall system design shall be basedon predefined criteria.

CL2 SI

A.SOL.2 A top level architecture of the system shall be established, identifyingall components (hardware and software).

CL1 SI

A.SOL.3 Make/buy/reuse analysis shall be performed for each component.Particular care should be taken to express requirements relatedto reliability, including degraded and backup modes, as well asperformance. More generally, the usage of the general systemrequirements to specify non-functional requirements is recommendedto build a complete set of requirements.

CL2 SI

A.SOL.4 Balance between needs and feasibility/cost/performance shall beachieved.

CL2 OWSI

A.SOL.5 Needs and operational scenarios can be evolved in consistency withoverall design (impact of design decisions on needs and functionalities,as well as impacts of change in the needs on design).

CL2 SIOP

A.SOL.6 Obsolescence risks shall be assessed, based on top level architectureand make/buy/reuse analyses. The strategy for the futuremanagement of obsolescence shall be defined (defensive, progressive,mixed, other) and used for design strategies.

CL2 OWSIOP

A.DES.1 System design shall be documented, including component andinterfaces description as well as operational scenarios and use cases.The system design shall include:

— mapping of the functional view to the component view (from usecases tocomponents interaction),

— descriptions of the main interfaces between components.

CL2 SI


DNV GL AS

A.DES.2 Before switching to detailed component design and/or subcontractingthe components development, concept and overall design documentsshall be verified and validated by stakeholders (for example, during themilestone review). Such verification and validation shall be coordinatedby the System Integrator.In particular, the owner and the operator should verify their designconstraints for the system are explicit, justified and applied. Whilethe owner and the operator are not designing the system, they mayhave particular requirements on how and with which equipment thesystem should be designed. For example, an operator may requirethe use of a particular type or make of PLC, for approval or spareparts management reasons. Or an operator may require the use of astandardized PLC programming language, compliant to 61131, also formaintenance reasons.

CL1 OWSIOP

A.IMP.1 Simulators or prototypes may be developed to develop or validateconcept.Developing an inexpensive prototype or simulator in order to gatheruser interface requirements, performance requirements or otherfeasibility information is a typical best practice. In some cases, it maybe the most effective tool of gathering such requirements, instead ofwriting a formal requirements document.

CL2 SI

A.ACQ.1A.ACQ.A

Potential subcontractors for developing part of the subsystems(components) shall be consulted.Make/buy/reuse analysis the input to determine what part of thesystem could be acquired.In particular, intellectual property of software components may benegotiated as a means to mitigate software obsolescence risk.For example, suppliers usually retain ownership rights to the software,while providing a license to use to the owner and operator. However,the software may be placed in escrow so that in certain circumstanceswhere the supplier becomes unable or unwilling to correct defects orperform upgrades, the owner and the operator may obtain the softwaresource data for their own use in order to have it corrected or upgraded.This mechanism is also suitable for managing obsolescence risk.

CL1 OWSIOP

A.ACQ.2 Proposals from potential subcontractors shall be analyzed to evolveoverall design if needed.

CL2 SI

A.ACQ.3 Supplier shall submit its proposal in response to System Integratorexpectations. The proposal shall contain a compliance status regardingSystem Integrator requirements.The supplier should provide a breakdown of ISDS elements conformingto the make/buy/reuse analyses, and take care to identify any requiredcustomization or parameterization of existing products, in particular ofexisting software products.

CL1 SU


DNV GL AS

A.INT.1 Roles and responsibilities for planning and executing the integration ofeach ISDS element shall be defined and documented. The boundariesand exclusions of integration of the various elements shall be definedexplicitly. A process to solve integration issues shall be set up early.Many integration issues reveal themselves at the end of theconstruction, but have roots in the early definition (or non-definition)of the responsibilities of the system integrator and various stakeholdersin the integration process. Questions arising from the integrationof new equipment from different suppliers should be addressed, aswell as questions arising from the integration of new equipment withexisting equipment, or new equipment replacing old equipment onan as-is basis. Who is responsible for the correct operations of theelement-in-the-system, and in what conditions, are the key questionsto ask. The various roles, responsibilities, boundaries and exclusionsshould be clearly specified in a joint, agreed-upon process document,in the agreement between system integrator and supplier if necessary.

CL1 SISU

A.VER.1 Consistency of customer requirements and product requirements shallbe verified.

CL1 SI

A.VER.2 Completeness of system requirements allocation to components shallbe verified.

CL1 SI

A.VER.3 Overall design of the system shall be independently verified. CL3 IV

A.VAL.1 Concept of the system shall be presented to representatives of the finaluser to ensure it can fulfil their needs.Whenever possible, prototypes or simulations shall be used to validatethe concept of the system with the users.

CL2 OWSIP

A.RAMS.1 Rules, standards and applicable laws shall be identified, and whereinterpretations are possible, discussed to ensure a consistent approachto RAMS is applied throughout the lifecycle.For example, the use of IEC 61508 or ISO 17894 standards may beassessed, and where needed, discussions will be conducted with safetyauthorities and independent verifiers to ensure the requirements areconsistently understood in the project.

CL2 SI

A.RAMS.2 A qualified work environment for the RAMS activities shall be set upand maintained. In particular, the integrity of RAMS information anddata shall be set up and maintained during the life cycle. Independentreporting of RAMS status and issues shall be set up.

CL2 SI

A.RAMS.3 Reliability, availability, maintainability and safety related requirementsshall be included in the requirements collection activity.

CL2 SI

A.SUP.1 A plan for the development of the systems shall be established andmaintained. The plan shall contain a high level master schedule,taking into account rough estimations and discussions with potentialsuppliers.Decision gates for the whole project shall be established.

CL1 SI

A.SUP.2 Relevant stakeholders for the system under development shall beidentified.

CL1 OWSI


DNV GL AS

A.SUP.3 There shall be an agreement on the content of the overall plan(including requirements to be implemented) from stakeholders.

CL1 OWSISUOP

A.SUP.4 Work estimates (workload, costs, duration, …) shall be justified byobjective attributes, like size or complexity and rationale for theestimations should be documented.

CL1 OWSISUOP

The objective is to build estimations on concrete attributes, ratherthan feelings. In case of comparative estimation (with respect toformer projects), differences and similarities should be expressed interms of tangible parameters (number of equipment, complexity of thetechnology, amount of data to process, etc.), to feed the estimationprocess and make it more reliable, communicable, as well as giving theopportunity to improve subsequent estimates using past data.

A.SUP.5 There shall be a strategy defined for risk management. It shouldidentify the sources of the risks, how they are categorized, how theywill be characterized (attributes) and prioritized, and which risksmitigations to use.

CL2 OWSI

A.SUP.6 Risks shall be identified at the beginning of the development.Consequences (safety, environment, financial, etc.) and the associatedprobability shall be evaluated and documented. During the project,the risks list shall be reviewed and updated regularly, in order to re-evaluate the risk attributes or to take into account new risks. Risksinvolving other stakeholders shall be regularly shared, reviewed andupdated jointly.

CL0 OWSISUOP

The risk identification and tracking shall be done even at ConfidenceLevel 0 (in order to assess confidence level – see Sec.4).However, it is not strictly required at CL0 and CL1 to complement riskidentification and tracking with risk mitigation strategy and actions.

A.SUP.7 Risk mitigation actions shall be decided and planned, according to therisk strategy. Status of these actions should be monitored regularly.Efficiency of mitigation actions should be assessed, and new actions betaken as needed. Mitigation actions involving other stakeholders shallbe coordinated.

CL2 OWSIOP

A.SUP.8 A baseline of the systems requirements shall be established at theend of concept phase. This baseline should be used as the referencewhen requirements will evolve in further phases. Control of themodifications of the content of the baseline should be placed under theresponsibility of a commission involving the purchaser and the supplier.Representatives of owners and operators shall approve the baseline.

CL1 OWSIOP


DNV GL AS

A.SUP.9 Processes to be used within the project activities shall be definedand agreed, within and across organizations participating in theproject. Roles and Responsibilities as defined in the RP shall beexplicitly allocated. The System Integrator may delegate some of its SIresponsibilities to a supplier. In that case, the allocated responsibilitiesand the retained responsibilities shall be clearly identified.Quality assurance means for ensuring the defined processes arefollowed shall be allocated (for example: checklists, resources, peerreviews, inspections). A verifier for the system under developmentshall be assigned.

CL1 OWSISUOP

The verification levels required by the RP are as follows:

— at level 1, verification activities shall be conducted,— at level 2, verification activities shall be conducted by an

independent party (outside of the project, but possibly within theorganization),

— at level 3, verification activities shall be conducted by a third party.

The defined processes typically include: process descriptions,standards and requirements for products and services, processperformance objectives, assignment of responsibility and authority,process scheduling, resource allocation to perform the process, trainingas necessary to perform the processes, measurements requirements,stakeholders involved, procedures for monitoring and controlling,and management review activities. See [CMMI] for example for moreguidance.

A.SUP.10 An independent verifier for the system under development shall beassigned.

CL2 OW

A.SUP.11 The independent verifier for the system shall be a third party. CL3 OW

A.SUP.12 Confidence level of the system functions shall be determined.See Sec.4.

CL0 OW

A.SUP.13 Joint project milestone reviews to check achievement of phaseobjectives before decision gates M0 and M1 shall be planned andcarried-out. Significant risks, issues and their impact shall bedocumented and tracked until closure. Decisions whether or not, orhow, to progress to next phase shall be recorded.Such decision gates are intended to be the critical event to decidewhether to proceed further in the project, weighing the risks of movingto the next phase versus the risks of postponing it. In some cases, thedecision to move forward may include considerable project risks. Thedecision gate is a good practice to communicate the extent of suchrisks to all stakeholders.

CL1 OWSISUOP

B.2 Engineering phase activitiesB.REQ.1 For each component, requirements shall be refined and allocated into

components requirements.CL2 SI

SU


DNV GL AS

B.REQ.2 For each component, operational scenarios involving the componentshall be detailed.Detailed use cases shall be established for requiredcomponents functionalities. These use cases may be completed withstate diagrams.

CL2 SISU

Use cases should include overall and detailed scenarios as well asdegraded mode scenarios. Performance targets should be defined foruse cases and scenarios.

B.REQ.3 Operator shall be involved in the definition of detailed use cases andoperational scenarios.

CL2 OP

B.REQ.4 Traceability of requirements allocation shall be maintained. If detailedrequirements are derived from higher level requirements, theyrequirements shall be traced to initial components requirements.

CL1 SISU

B.SOL.1 Technical solution shall be established, identifying the maincomponents and interaction between them. A physical layout shoulddescribe the way components and networks are physically distributedaround the facility, including the way they are interconnected.

CL2 SISU

Supplied architecture shall describe:

— Physical layout, which shall describe the physical distribution of thehardware on the system, including network and CPUs.

— The logical view on the function shall describe the function in termsof functionality towards its users.

— The process view of the function shall describe the processes andcomponents that compose the function, as well as the responsibilityof individual components and processes, their interaction, triggersand cycle times.

— The physical view of the function shall describe the mapping of theprocesses/components onto hardware (modules).

— The development view of the function shall describe thedecomposition of the function into distinctive layers and sub-functions.

— The scenarios shall describe the primary interaction betweencomponents when a function is executed.

B.SOL.2 Consistency between functions and interfaces assigned to eachcomponent and system operational scenarios should be verified.

CL2 SI

B.SOL.3 System design and/or systems functionalities shall be analysed andevolved during the design activates, to achieve the balance betweentechnical constraints and objectives of the system (quality attributes).

CL2 SI

B.SOL.4 The system design documentation should be maintained during alldesign activities.

CL2 SI


DNV GL AS

B.SOL.5 A canonical data model shall be defined by the integrator and used byall subcontractors.The data model is intended to be used as a common language amongall specific systems involved*, reducing the number of specializedinterfaces between specific systems, resulting in both reliability andmaintainability issues. It models all relevant information for controllingthe installation, so all relevant measurements and controls (actuators),as well as:

— Their meaning on the installation (is it pressure of hydraulic oil vs.the pressure of the produced crude oil).

— Why they are important (what risk is involved in not knowing thedata).

— Their unit of measurement to be used in communication andstorage.

*This implies that all sub-systems need to speak the commonlanguage, instead of the common language becoming the superset ofall subsystems.

CL1 SISU

B.DES.1 Design for each component shall be developed. CL2 SU

B.DES.2 Interfaces of each component should be detailed. The rationale forinterfaces selection should be documented.

CL2 SISU

B.DES.3 Design for each component shall be documented. CL2 SU

B.DES.4 ISDS supporting one or more essential or important functions shall bearranged to allow individual components to be tested, repaired andrestarted without interference with the maintained operation of theremaining parts of the system.

CL3 SI

B.IMP.1 Prototypes should be developed to reduce design or integration risks.Developing an inexpensive prototype in order to check design orintegration issues is a typical best practice. For example, developinga prototype for the upgrade of an existing system may be needed tocheck the compatibility of the interfaces, before the construction phasestarts.

CL2 SISU

B.ACQ.1 Selection of subcontractors shall be performed, using predefinedcriteria and selection rationale. Selection procedure should bedocumented.

CL1 SI

B.ACQ.2 In case of COTS acquisition, selection procedures should follow thesame rules as above: definition of criteria and rationale for COTSselection, evaluation of the proposals, selection.

CL1 SI

B.ACQ.3 Contract with selected supplier should be established, and it shouldspecify the functions and components allocated to the supplier. Criteriafor acquired product acceptance must be defined, as well as termand conditions to ensure the transfer of the component to the maincontractor.

CL1 SISU


DNV GL AS

B.ACQ.4 One main contractor shall be identified, including explicit agreement onresponsibilities of the client, main contractor and subcontractors in theexecution of all applicable activities in this RP.

CL1 OW

B.ACQ.5 In case of COTS acquisition, a contract with each supplier shall addressacquisition requirements, including the cost and schedule. Alsoproprietary, usage, ownership, warranty and licensing rights associatedwith the reusable off-the-shelf software products shall be addressed.In addition, future maintenance and support shall be addressed. Thescope of the additional qualification needed for the COTS shall bedefined, based on existing qualification certificate and existing in-usefeedback.

CL1 SI

B.ACQ.6 In case of COTS acquisition and obsolescence management, selectionprocedures shall include obsolescence studies for COTS.

CL2 SISU

B.INT.1 Design documents from all the components shall be reviewed to verifycompleteness and consistency of the interfaces between components.

CL2 SISU

B.INT.2 Strategy for integration shall be defined and documented. Theprocedures and the environment for the integration shall be described.The integration strategy shall also describe the tests that will beperformed to ensure the right behaviour of the components at theirinterfaces.

CL2 SI

The integration strategy should describe the different steps to followto assemble the components of the system: for example progressiveassembly of some components, or big-bang integration for example.Environment is one the key aspects of integration; integration strategyshould take into account the need for stubs or simulators to performintegration tests.

B.VER.1 The design document shall be reviewed to verify the completeness ofthe design with respect to requirements (functions, interfaces) andrules concerning the design.

CL1 SI

B.VER.2 The verification strategy shall be defined and documented. It shalldefine the means to ensure the system meets its requirements:

— which product to verify: component, assembly of components,design documents, specification documents, etc.

— which methods to use for these verification: testing, inspection,prototyping

— what environments to use for verification.

The verification strategy shall plan the verification activities, define thequality criteria and the targets for each verification stage (for examplein terms of coverage).Verification strategy shall include peer reviewing techniques (documentor code inspection for example).Detailed procedures (test cases) and tools for testing may beestablished (or developed) during the implementation phase.

CL2 SI

B.VER.3 Design reviews shall be performed on selected parts of the design. CL2 IV


DNV GL AS

B.VER.4 Independent verification of the technical specification should beperformed.

CL3 IV

B.VER.5 Independent verification of the software architectural design and thesoftware detailed design should be performed.

CL3 IV

B.VER.6 The canonical data model shall be reviewed.Managing the definitions and designs of interfaces not only applies tothe product components and external systems, but may also apply tothe verification and validation environments.

CL2 IV

B.VAL.1 The validation strategy shall be defined. It shall describe theprocedures to ensure the system will fulfil the intended use in its targetenvironment. This strategy should be documented, with procedures(ex: testing), and associated planning. Criteria should be defined toassess the quality of the validation results. The validation strategyshould be consistent, complementary and as less as possible redundantwith verification procedures. Validation procedures should at leastcover the operational scenarios defined for the system.

CL2 OWSIOP

B.VAL.2 Design should be validated by prototyping. CL2 SI

B.RAMS.1 RAMS hazards and risks shall be identified and prioritized.App.D may be used as a guideline and initial risk list for theassessment of ISDS-specific risks.The recommended practiceDNVGL-RP-A203 may be used as a guideline for the assessment oftechnological risks and their impact on RAMS properties.

CL1 SI

B.RAMS.2 Based on hazards and risks, selected events leading to major failuresshall be analysed to identify mitigation actions, for example using FTAtechniques.In addition to random hardware failures, events leading to systematicfailures should also be analysed, especially to identify mitigationactions to remedy common cause failures.

CL2 SI

B.RAMS.3 For each critical system function, FMECA should be performed. CL3 SI

B.RAMS.4 A software criticality analysis shall be performed by an independentverifier. The analysis shall result in assigning confidence levels and/orcriticality levels to software requirements, components and units, asneeded.

CL3 SIIV

B.SUP.1 Master plan for the development of the system should be establishedand made consistent with suppliers or others stakeholders plans (andschedules).

CL1 SI

B.SUP.2 Estimates for the tasks to perform should be provided for eachcomponent by its supplier.For software, the supplier shall distinguish work to be performed onspecific components, reused but customized and/or parameterizedcomponents, or reused as-is components.

CL1 SU


DNV GL AS

B.SUP.3 The risk list shall be reviewed and updated regularly, in order to re-evaluate the risk attributes or to take into account new risks. Risksinvolving other stakeholders shall be regularly shared, reviewed andupdated jointly.

CL1 OWSISUOP

B.SUP.4 Risk mitigation actions shall be decided and planned, according tothe risk strategy. Status of these actions shall be monitored regularly.Efficiency of mitigation actions shall be assessed and new actions betaken as needed. Mitigation actions involving other stakeholders shallbe coordinated.

CL2 OWSISUOP

B.SUP.5 Effort needed for system activities like integration, verification orvalidation tasks shall be estimated and planned (resources shall beallocated to perform that tasks).

CL1 SI

B.SUP.6 Before developing the components, a requirements and design baselineshall be established for all components. The consistency of thisbaseline shall be verified.

CL1 OWSISUOP

B.SUP.7 Processes shall be controlled to ensure defined processes are followed. CL1 OWSISUOP

B.SUP.8 Processes shall be independently controlled to ensure definedprocesses are followed.

CL2 IV

B.SUP.9 A project plan shall be established and maintained, in coordination withother stakeholders, for engineering and all succeeding phases.In practice, the plan may be detailed for the current phase and roughlyoutlined for ulterior phases. When reaching the ulterior phases, theplan may then be detailed. As the acceptance phase is often a criticalperiod for the project, it is recommended that this phase be planned indetail to reduce project risks.

CL1 OWSISUOP

B.SUP.10 The project's activities during engineering shall be monitored againstthe plan, and corrective actions shall be taken when significantdeviations from the plan occur. When needed, coordinated actions shallbe undertaken with other stakeholders.Corrective actions may include actions to bring back the project'sstatus to the plan, or actions to establish a new plan.

CL1 OWSISUOP


DNV GL AS

B.3 Construction phase activitiesC.REQ.1 Change requests shall be collected and managed. Requests shall be

analysed to assess impact and feasibility. A commission board shallbe accountable for decisions regarding change requests and changeorders. This change control board shall comprise representativesfrom the owner, the operator, the system integrator, and suppliers, asneeded.

CL1 OWSISUOP

C.REQ.2 Traceability of requirements allocation shall be maintained. CL1 SI

C.SOL.1 Changes to the solution shall be collected, managed and documented.Changes to the solution shall be analyzed for consistency and allocatedto the components to ensure completeness of the technical solution.

CL1 SISU

C.DES.1 Design may be refined during implementation phase. Inconsistenciesbetween design documentation and implementation shall bedocumented.

CL2 SU

C.IMP.1 Components shall be developed, according to their design. CL1 SU

C.IMP.2 Support documentation for the component shall be developed. CL2 SU

Support documentation includes user manuals, operating andmaintenance procedures, training manual, etc.

C.IMP.3 Each component shall be unit tested before entering into verification/acceptance. The extent (coverage) of the testing and the results shallbe documented and made available.

CL1 SU

C.IMP.4 Quality targets shall be defined for each component to be developed.The status of the in-development component with respect to its qualitytarget shall be measured during the development.

CL2 SISU

C.IMP.5 Interfaces between components shall be free of deadlocks. CL2 SI

C.IMP.6 The overall design shall be free of single points of failure. CL2 SI

C.IMP.7 During design, it shall be verified that all generated signals/messagesbetween communicating components are defined and understoodby receiving party. This means that the domains of output-signalsmessages of any component must have a 100% overlap with the inputdomain of the receiving component.

CL2 SISU

C.ACQ.1 When development of the component is subcontracted, the maincontractor shall control that the contract is executed as agreed.Activities planned in the contract shall be monitored and tracked.Progress reviews with subcontractor shall be planned and shall be held.

CL1 SI

C.ACQ.2 Once the contract is underway, the acquirer will control changes tothe contract through negotiation with the supplier as part of a changecontrol mechanism. Changes to the contract shall be investigated forimpact on project plans, costs, benefits, quality, and schedule.

CL1 SISU


DNV GL AS

C.ACQ.3 Visibility on the subcontractor activities shall be maintained, especiallyon key processes of the subcontractor. Main contractor shall haveenough information to ensure rules and quality expectation will beachieved by subcontractor.

CL2 SI

C.ACQ.4 Intermediate deliverables from the subcontractor shall give visibility tothe main contractor, which shall be able to review them.

CL2 SI

C.ACQ.5 Deliverables from the supplier shall be submitted to formal acceptance,using predefined criteria and procedures. Acceptance tests shall atleast verify that the delivered product is compliant to its specification.

CL1 SI

C.ACQ.6 Documentation, examples, or support necessary to ensure theintegrate ability of the delivered product by the main contractor shallbe planned and provided.

CL1 SU

C.ACQ.7 In case of COTS acquisition, acceptance and transition shall beensured, as for newly developed components. As planned in B.ACQ.5, areduced acceptance procedure may be performed.

CL1 SI

C.INT.1 Environments required for integration, verification and validation shallbe provided. This preparation is mandatory to ensure these activitiescan be performed. It includes the acquisition or the development of theneeded tools or simulators and the setup of the physical environments.

CL2 SI

C.INT.2 After the decision to release the component (or acceptance in caseof subcontracted component), developed components with theirdocumentation shall be transferred to the integration team.

CL1 SI

C.INT.3 Readiness of the components for the integration should be checkedbefore starting the integration. The criteria defined in the integrationstrategy should be used to assess the readiness.

CL2 SI

C.INT.4 Assembly of the components shall be performed, following theintegration strategy. For each integration step, environmentrequirement and procedures shall be satisfied.

CL2 SI

C.INT.5 Integration tests should be performed to ensure interfaces betweencomponents are compliant to the requirements. Scenarios involvinginterfaces between components should be performed in the test cases.

CL2 SI

C.INT.6 Changes to the canonical data model shall be collected, managed,documented and analysed for consistency.The canonical data model needs to be periodically reviewed foradequacy and maintained in a repository accessible to projectparticipants.

CL1 SISU

C.VER.1 Peer reviews of under-development software and documents should beused to detect defects as soon as possible in the development cycle.

CL2 SISU

C.VER.2 Detailed procedures for testing shall be completed (test cases), anddocumented. In case of automated testing, implementation of the testcases shall be performed. The implementation of the test cases shall beperformed with the same quality requirements as the product.

CL2 SI


DNV GL AS

C.VER.3 Developed components shall be verified before decision to release thecomponent. Status of the component verification shall be analysed andcompared with expected quality attributes targets.

CL2 SISU

C.VER.4 Verification tests shall be performed on the ISDS, to ensure the systemis compliant to its requirements. Verification procedures shall ensurethat each requirement is fulfilled.

CL2 SI

C.VER.5 Tests coverage of software structure regarding statements and datacoupling shall be achieved according to targets defined in verificationstrategy.

CL2 SISU

C.VER.6 Tests coverage of software structure regarding modified condition/decision coverage (MC/DC) shall be achieved according to targetsdefined in verification strategy.

CL3 SISU

C.VER.7 Adequate software source code verification shall be performed. CL2 SISU

For example, the source code verification may be performed by peerreviews, static analysis, or schedule ability analysis. See ISO 61508 forother recommended means.

C.VER.8 Software source code shall be independently verified. CL3 IV

C.VER.9 ISDS Elements shall be independently verified and qualified. CL3 IV

C.VAL.1 Performance requirements shall be validated using a prototype. CL2 OWSIOP

C.RAMS.1 The components and modules shall be specifically checked againstRAMS requirements and objectives. The RAMS shall be assessed andreported. Criteria shall be defined to allow or not the construction gateto be passed on RAMS status.

CL2 SISU

C.RAMS.2 Lower confidence-level functions shall not interfere with higherConfidence Level functions.

CL1 SI

C.RAMS.3 Networks and component connections to networks shall be designedand implemented to protect networks against domination.

CL2 SI

Networks may be protected against domination by a single componenteither by physical isolation or quality of service (QoS) solution.

C.RAMS.4 Where a system or component is part of an essential function, asecondary means of operation shall be provided by either a nonautomated system/component or by an independent system/component of appropriate diversity.

CL3 SI


DNV GL AS

C.SUP.1 The risk list shall be reviewed and updated regularly, in order to re-evaluate the risk attributes or to take into account new risks. Risksinvolving other stakeholders shall be regularly shared, reviewed andupdated jointly.

CL1 OWSISUOP

C.SUP.2 Risk mitigation actions shall be decided and planned, according tothe risk strategy. Status of these actions shall be monitored regularly.Efficiency of mitigation actions shall be assessed and new actions betaken as needed. Mitigation actions involving other stakeholders shallbe coordinated.

CL2 OWSISUOP

C.SUP.3 For the system and for each component to develop, a configurationmanagement plan shall be established, identifying the items composingand describing the system or the component, the rules and proceduresto ensure configuration control within the system or the component,and delivery strategy (number, schedule and contents of releases).

CL1 OWSISUOP

C.SUP.4 The development of any part of the system shall follow theconfiguration management rules to allow collaborative work and tomaintain consistency within components and between components.

CL1 OWSISUOP

C.SUP.5 Each delivered component shall come with a release note, describingthe functional content of the delivery (versions of the applicablespecifications) as well as its physical content (list of items with theirversions). In case of new delivery of a component, differences withrespect to previous version shall be documented in the release note.

CL1 SU

System release note can link to each component's release note.

C.SUP.6 Integration team shall establish a release note for the whole system,describing the functional content of the delivery (versions of theapplicable specifications) as well as its physical content (list ofitems with their versions). In case of new delivery of a component,differences with respect to previous version shall be documented in therelease note.

CL1 SI

C.SUP.7 Processes shall be controlled to ensure defined processes are followed.Quality assurance means for ensuring the defined processes arefollowed shall be allocated (for example: checklists, resources, peerreviews, inspections).

CL1 OWSISUOP

C.SUP.8 Processes shall be independently controlled to ensure definedprocesses are followed.

CL2 IV

C.SUP.9 The project's activities during construction shall be monitored againstthe plan, and corrective actions shall be taken when significantdeviations from the plan occur. When needed, coordinated actions shallbe undertaken with other stakeholders.Corrective actions may include actions to bring back the project'sstatus to the plan, or actions to establish a new plan.

CL1 OWSISUOP


DNV GL AS

C.SUP.10 Project milestone reviews such as completion of project phases M0to M5 shall be planned and carried-out. Significant issues and theirimpacts shall be documented and tracked until closure.

CL1 OWSISUOP

B.4 Acceptance phase activitiesD.REQ.1 Change requests shall be collected and managed. Requests shall be

analysed to assess impact and feasibility before implementation. Acommission board shall be accountable for decisions regarding changerequests and change orders. This change control board shall compriserepresentatives from the owner, the operator, the system integrator,and suppliers, as needed.

CL1 OWSISUOP

D.SOL.1 Changes to the solution shall be collected, managed and documented.Changes to the solution shall be analyzed for consistency and allocatedto the components to ensure completeness of the technical solution.

CL1 SISU

D.IMP.1 Changes to the system during acceptance shall be implemented inreference to the technical solution. Care shall be taken not to impactother features of the system, for example by performing system-wide regression testing, based on the impact analysis performedpreviously.Software changes shall be reversible in order to be able tofall back to the existing working order of the system, if the changeshave undesirable side effects.The technical solution shall be updated todocument the solution as implemented.

CL1 SISU

D.ACQ.1 Deliverables from the supplier shall be submitted to formal acceptance,using predefined criteria and procedures. Acceptance tests shall atleast verify that the delivered product is compliant to its specification.

CL1 SI

D.VER.1 Developed and integrated components shall be verified before decisionto accept the component. Status of the component verificationshould be analysed and compared with expected process and qualityattributes targets.

CL1 SISU

D.VAL.1 Operational scenarios shall be demonstrated on the ISDS in anenvironment representative of the target environment. Validation shallbe performed according to the validation strategy.

CL2 SIOP

D.VAL.2 Quality criteria shall be evaluated and compared with quality targets.Decision for authorizing the system to go into operations shall be madeon the basis of the validation results.

CL2 SIOP

D.VAL.3 The complete function shall be tested as a black-box, and testing shallinclude boundary-testing.

CL2 SI

D.VAL.4 The ISDS shall be verified/validated by an independent party. CL3 IV


DNV GL AS

D.RAMS.1 RAMS shall be documented (for example: FME(C)As, test cases,proofs, inspections, computations and simulations, certification…)to demonstrate with confidence that the system has met the RAMSobjectives.DNVGL-RP-A203 may be used as a guideline for checking and verifyingevidence from proofs, processes and product measures in order todemonstrate that the RAMS properties are achieved and that thetechnology level of the system is now consistent with deployment.

CL2 SI

D.SUP.1 Before entering into operations, the configuration of the systemshall be documented. A release note shall be produced, describingall the items and their versions, as well as their content (applicablespecifications, known defects ….).

CL1 SISU

D.SUP.2 Any change in a component of the system should be submitted to achange control board.

CL1 SISU

D.SUP.3 A configuration control system shall ensure that the deployedconfiguration cannot change outside a strict change control procedure.

CL1 OWSISUOP

D.SUP.4 In case of update of one on more component or component part ofthe system, configuration records shall trace the modification and itsrationale.

CL1 SI

D.SUP.5 Processes shall be controlled to ensure defined processes are followed.Quality assurance means for ensuring the defined processes arefollowed shall be allocated (for example: checklists, resources, peerreviews, inspections).

CL1 OWSISUOP

D.SUP.6 The project's activities during acceptance shall be monitored againstthe plan, and corrective actions shall be taken when significantdeviations from the plan occur. When needed, coordinated actions shallbe undertaken with other stakeholders.Corrective actions may include actions to bring back the project'sstatus to the plan, or actions to establish a new plan.

CL1 OWSISUOP

D.SUP.7 The risk list shall be reviewed and updated regularly, in order to re-evaluate the risk attributes or to take into account new risks. Risksinvolving other stakeholders shall be regularly shared, reviewed andupdated jointly.

CL1 OWSISUOP

D.SUP.8 Risk mitigation actions shall be decided and planned, according tothe risk strategy. Status of these actions shall be monitored regularly.Efficiency of mitigation actions shall be assessed and new actions betaken as needed. Mitigation actions involving other stakeholders shallbe coordinated.

CL1 OWSISUOP

D.SUP.9 Processes shall be independently controlled to ensure definedprocesses are followed.

CL2 IV


DNV GL AS

D.SUP.10 Project milestone reviews such as completion of project phases M0to M5 shall be planned and carried-out. Significant issues and theirimpacts shall be documented and tracked until closure.

CL1 OWSISUOP

B.5 Operation phase activitiesE.REQ.1 Change requests shall be collected and managed. Requests shall be

analysed to assess impact and feasibility before implementation. Acommission board shall be accountable for decisions regarding changerequests and change orders. This change control board shall compriserepresentatives from the owner, the operator, the system integrator,and suppliers, as needed.

CL1 OWSISUOP

E.SOL.1 Changes to the solution shall be collected, managed and documented.Changes to the solution shall be analyzed for consistency and allocatedto the components to ensure completeness of the technical solution.

CL1 SISU

E.IMP.1 Changes to the system shall be implemented in reference to thetechnical solution. Care shall be taken not to impact other features ofthe system, for example by performing system-wide regression testing,based on the impact analysis performed previously. Software changesshall be reversible in order to be able to fall back to the existingworking order of the system, if the changes have undesirable sideeffects.The technical solution shall be updated to reflect the solution asimplemented.

CL1 SISU

E.ACQ.1 After acceptance, the acquirer shall take the responsibility for themanagement of the obsolescence of the system and its components.Spare parts shall have been acquired and shall be maintained asappropriate. In case of progressive obsolescence management,intellectual property management of software components, alternatereplacement parts and upgrade strategies shall be prepared andexecuted.

CL2 OWOPSU

E.VER.1 Modified, developed and integrated components shall be verifiedbefore decision to accept and operate the component. Status of thecomponent verification shall be analysed and compared with expectedprocess and quality attributes targets.

CL1 SIOP

E.VAL.1 Operational scenarios shall be demonstrated on the ISDS. Validationshall be performed according to the validation strategy, revised ifnecessary to take into account the implemented changes.

CL2 SISU


DNV GL AS

E.RAMS.1 The RAMS properties of the ISDS shall be measured during theoperational life, and compared to the RAMS objectives and RAMSarguments to check for consistency.Discrepancies between expectedand achieved RAMS properties shall be investigated.RAMS incidentsshall be investigated and traced to the piece(s) of equipment and/orpiece(s) of software concerned. The trace shall specifically not stop atCPU or Programmable Electronic Systems (PES) level.Lessons learnedshall be used for modifying operational procedures, re-designing theISDS or improving design of subsequent products as appropriate.The introduction phase (for example, during design) of defects thatmay result in systematic failures shall be diagnosed, in order toimprove the ISDS development process and prevent or mitigatesystematic failures difficult to predict.Automatic recording of RAMS failures in the field should be preferredover human reporting: most incidents may go unreported. Inmany cases users may often get accustomed to underperformingsystems.Analyzing incidents should also distinguish, if possible,between failures caused by defects in the system itself from failurescaused by the misuse of the system. Early life behaviour may differsignificantly from later, more mature life when the ISDS displays aconsistent RAMS behaviour. New ISDS, even assembled from standardcomponents may show unintended behaviour until debugged. Thetarget objectives should state the early life expectations when theydiffer from the mature life targets.Late life behaviour where a changein observed RAMS properties may be expected may also requireparticular monitoring.A good practice based on monitoring RAMSproperties is to replace or remove failure-prone ISDS elements, eitherhardware, or software. It should be noted that for software, as in manyother industries, the 80/20 rule is applicable: 80% of the failures areusually caused in 20% of the software.

CL2 OP

E.SUP.1 After acceptance, the acquirer shall take the responsibility forthe configuration management of the delivered system and itscomponents.

CL1 OWSIOP

E.SUP.2 The operator shall establish procedures for receiving, recording,resolving, tracking problems and modification requests. Problems shallbe dealt with in a problem resolution process. A plan for the operationof the system shall be established and maintained, identifying theconfiguration items, the rules for operation and the expected activitiesfor maintenance. Migration and software retirement issues shall beaddressed in this plan.

CL1 SIOP

E.SUP.3 For each new upgrade, release or modified version of system and/orcomponents, the operator shall perform operational testing, and, onsatisfying the specified criteria, release the component for operationaluse. Testing shall include integration tests if the interface of thereleased component has been modified.

CL1 OP

E.SUP.4 The operator shall provide assistance and consultation to the users ofthe system as requested. Requests shall be recorded and monitored toconclusion. If necessary, requests shall be forwarded to a maintenanceprocess.

CL1 OP


DNV GL AS

E.SUP.5 The maintainer shall analyse and document problems and modificationrequests, including the impact on the existing component/system andthe interfacing components/systems. Criteria to assess impact shallinclude criticality, or impact on RAMS. The results of the analysis shallbe used by a change control board, to decide if the change is to beimplemented.

CL1 OWSISUOP

E.SUP.6 There shall be regular configuration audits to verify the integrity of theconfiguration in operations.

CL1 OP

E.SUP.7 Processes shall be controlled to ensure defined processes are followed.Quality assurance means for ensuring the defined processes arefollowed shall be allocated (for example: checklists, resources, peerreviews, inspections).

CL1 OWSISUOP

E.SUP.8 The project's activities during operations shall be monitored against theplan, and corrective actions shall be taken when significant deviationsfrom the plan occur. When needed, coordinated actions shall beundertaken with other stakeholders.During operations, most activities are planned to a maintenanceor operations process. Specific upgrades or corrections requiringcoordination with several stakeholders may require a project plan, asspecified by the RP.Corrective actions may include actions to bring back the project'sstatus to the plan, or actions to establish a new plan.

CL1 OWSISUOP

E.SUP.9 The risk list shall be reviewed and updated regularly, in order to re-evaluate the risk attributes or to take into account new risks. Risksinvolving other stakeholders shall be regularly shared, reviewed andupdated jointly.

CL1 OWSISUOP

E.SUP.10 Risk mitigation actions shall be decided and planned, according tothe risk strategy. Status of these actions shall be monitored regularly.Efficiency of mitigation actions shall be assessed and new actions betaken as needed. Mitigation actions involving other stakeholders shallbe coordinated.

CL2 OWSISUOP

E.SUP.11 Project milestone reviews such as completion of project phases M0to M5 shall be planned and carried-out. Significant issues and theirimpacts shall be documented and tracked until closure.

CL1 OWSISUOP


DNV GL AS

APPENDIX C TRACEABILITY BETWEEN ACTIVITIES AND GENERICSYSTEM REQUIREMENTS

Table C-1 Generic system requirements target table

Activities/generic system requirements

Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

A.REQ.1 Collect requirements • • • • • • • • •

A.REQ.2 Contribute to requirements collection. • • • • • • • • •

A.REQ.3 Translate needs into product requirements • • • • • • • • •

A.REQ.4 Define mission, objectives, shared vision andoperational concept and scenarios. • • •

A.REQ.5 Contribute to mission, objectives, shared visionand operational concept and scenarios definition. • • •

A.REQ.6 Establish and document functional architecture • •

A.REQ.7 Describe allocation of functions to ISDSelements • • •

A.REQ.8 Use traceability matrix to ensure completenessand consistency • • • • • • • • •

A.SOL.1 Select solution for system design using criteria • • • • • •

A.SOL.2 Establish top level architecture • • • • • •

A.SOL.3 Perform make/buy/reuse analysis • • • • • • • • • • •

A.SOL.4 Achieve balance between needs and feasibility/cost/performance • • • • • • • • • • •

A.SOL.5 Evolve needs and operational scenarios withdesign • •

A.SOL.6 Define obsolescence strategy • • • • •

A.DES.1 Document system design • • • •

A.DES.2 Validate concept design documents withstakeholders • • •

A.ACQ.1 Consult potential subcontractors for acquiredISDS elements • • • • •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

A.ACQ.2 Analyze subcontractors proposals to evolvedesign • • • •

A.INT.1 Define integration roles, responsibilities andboundaries • • • • • • •

A.VER.1 Verify consistency of customer and productrequirements • • • • • • • • •

A.VER.2 Verify completeness of system requirementsallocation • • • • • • • • •

A.VER.3 Independently verify overall design • • • • • • • • •

A.VAL.1 Present the concept of the system to the users • •

A.VAL.2 Use prototypes or simulations to validateconcept • •

A.RAMS.1 Determine rules, standards and laws applicable • • • •

A.RAMS.2 Qualify RAMS environment • • • •

A.RAMS.3 Collect reliability, availability, maintainability andsafety related requirements • • • •

A.SUP.1 Establish and maintain the development plan ofthe system, including high level master schedule • •

A.SUP.2 Identify relevant stakeholders • •

A.SUP.3 Obtain agreement with stakeholders on overalldesign • •

A.SUP.4 Establish Work estimates based on taskattributes • •

A.SUP.5 Define a strategy for risk management • •

A.SUP.6 Identify risks • •

A.SUP.7 Identify and implement risks mitigation actions • •

A.SUP.8 Define a baseline of requirements • • • • • • • • •

A.SUP.9 Define processes to follow and setup processmanagement activities • •

A.SUP.10 Assign an independent verifier • • •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

A.SUP.11 Chose a third party independent Verifier • • •

A.SUP.12 Determine confidence level • • • • • • • • •

A.SUP.13 Perform joint project milestone reviews • •

B.REQ.1 Refine system requirements into ISDS Elementsrequirements • • • • • • • • •

B.REQ.2 Detail use cases and operational scenarios byISDS element • •

B.REQ.3 Detail operational scenarios by ISDS Element • •

B.REQ.4 Maintain traceability of requirements includingrefined requirements • • • • • • • • •

B.SOL.1 Establish technical solution and provide physicallayout view • • •

B.SOL.2 Verify consistency of design with operationalscenarios • •

B.SOL.3 Achieve balance between technical constraintsand system objectives • • • • • • • • • • •

B.SOL.4 Maintain system design documentation • • • •

B.SOL.5 Establish canonical data model • • • • • • •

B.DES.1 Design each ISDS element • • •

B.DES.2 Document ISDS element interfaces • • • •

B.DES.3 Document ISDS element design • • • • •

B.DES.4 Design into independent ISDS elements • • • • • •

B.IMP.1 Prototype to reduce design and integration risks • • • • • • •

B.ACQ.1 Select subcontractors • •

B.ACQ.2 Select COTS • • • • • •

B.ACQ.3 Establish contract with subcontractors • • • • • •

B.ACQ.4 Identify main contractor • • •

B.ACQ.5 Establish COTS acquisition contract • • •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

B.ACQ.6 Select COTS based on obsolescence criteria • • • • • •

B.INT.1 Review consistency of interfaces design • • • • • • • • • • •

B.INT.2 Define integration strategy • • • • • • • • • • •

B.VER.1 Review completeness of design with respect torequirements and design rules • • • • • • • • • • •

B.VER.2 Define verification strategy • • • • • • • • • • •

B.VER.3 Perform independent selected design reviews • • • • • • • • • • •

B.VER.4 Verify independently technical specification • • • • • • • • • • •

B.VER.5 Verify independently design documents • • • • • • • • • • •

B.VER.6 Verify canonical data model • • • • • • •

B.VAL.1 Define validation strategy • • • • • • • • • • •

B.VAL.2 Validate design by prototyping • • • • • • • • • • •

B.RAMS.1 Identify RAMS risks and priorities • • • •

B.RAMS.2 Identify mitigation actions for selected eventsleading to major failures • • • •

B.RAMS.3 Perform FMECA on critical functions • • • •

B.RAMS.4 Perform independent criticality analysis • • • •

B.SUP.1 Integrate master plan for development andstakeholders plans • •

B.SUP.2 Provide estimation of work by ISDS Element • •

B.SUP.3 Review and update risks • •

B.SUP.4 Decide and track risks mitigation actions • •

B.SUP.5 Allocate resources to integration/verification/validation tasks • •

B.SUP.6 Establish baseline of requirements and design • • • • • • • • •

B.SUP.7 Control processes • •

B.SUP.8 Independently control processes •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

B.SUP.9 Establish and maintain coordinated project plan • •

B.SUP.10 Monitor the plan and undertake coordinatedactions • •

B.SUP.11 Perform joint project milestone reviews • •

C.REQ.1 Manage change requests • • • • • • • • •

C.REQ.2 Maintain requirements traceability • • • • • • • • •

C.SOL.1 Manage changes to the technical solution • • • • • • • • • • •

C.DES.1 Refine design during implementation if needed •

C.IMP.1 Develop the ISDS elements from design • • • • •

C.IMP.2 Develop support documentation • • •

C.IMP.3 Perform unit testing for ISDS elements • •

C.IMP.4 Define quality targets and track quality status. • • • • • • •

C.IMP.5 Ensure interfaces are free of deadlock • •

C.IMP.6 Design without single point of failure • •

C.IMP.7 Obtain complete understanding of interfaces • •

C.ACQ.1 Monitor contracts execution with suppliers • •

C.ACQ.2 Manage contract changes • •

C.ACQ.3 Ensure visibility on suppliers activities • • •

C.ACQ.4 Review intermediate deliverables fromsubcontractors • • •

C.ACQ.5 Accept deliverables from subcontractors • • • • •

C.ACQ.6 Ensure transition of delivered product • • • •

C.ACQ.7 Accept and ensure transition of acquired COTS • • • •

C.INT.1 Provide integration, validation and verificationenvironments • • •

C.INT.2 Transfer ISDS elements to integration afterdecision to release •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

C.INT.3 Check readiness status of ISDS Elements beforeintegration • • •

C.INT.4 Assemble the ISDS elements • •

C.INT.5 Perform integration tests • • •

C.INT.6 Maintain canonical data model

C.VER.1 Perform peer-reviews on software anddocuments • •

C.VER.2 Detail procedures for testing • • •

C.VER.3 Perform verification on developed ISDS elements • • • • • • • • •

C.VER.4 Perform verification tests • • • • • • • • •

C.VER.5 Ensure test coverage as specified (statementsand data coupling) • • •

C.VER.6 Ensure test coverage as specified (MCDCMC/DC) • • •

C.VER.7 Perform code analysis • • • •

C.VER.8 Perform Independent code analysis • • • •

C.VER.9 Perform Independent ISDS elementsqualification • • • • • • • • •

C.VAL.3 Validate performances using a prototype •

C.RAMS.1 Evaluate ISDS elements and modules againstRAMS requirements • • • •

C.RAMS.2 Ensure no interference between confidence levelof functions •

C.RAMS.3 Protect network against domination • •

C.RAMS.4 Provide secondary means of operation foressential functions •

C.SUP.1 Track risks • •

C.SUP.2 Decide and track risks mitigation actions • •

C.SUP.3 Establish a configuration management plan • •

C.SUP.4 Follow configuration management rules • • •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

C.SUP.5 Establish a release note for delivered ISDSelements •

C.SUP.6 Establish a release note for ISDS • •

C.SUP.7 Control processes during construction • •

C.SUP.8 Independently control processes duringconstruction •

C.SUP.9 Monitor the plan and undertake coordinatedactions • •

C.SUP.10 Perform joint project milestone reviews • •

D.REQ.1 Manage change requests • • • • • • • • •

D.SOL.1 Manage changes to the technical solution. • • • • • • • • • • •

D.IMP.1 Maintain the technical solution • • • • • •

D.ACQ.1 Accept deliverables from suppliers • • • •

D.VER.1 Perform verification on developed and ISDSelements • • • • • • • • •

D.VAL.1 Perform validation through operational scenarios • •

D.VAL.2 Analyse results with respect to quality targets • • • • • • • • •

D.VAL.3 Perform black-box testing • • •

D.VAL.4 Perform independent validation and verification • • • • • • • • •

D.RAMS.1 Collect RAMS arguments and evidence todemonstrate achievement of RAMS objectives • • • •

D.SUP.1 Establish a release note for the system thatenters into operations •

D.SUP.2 Submit and decide ISDS elements changes tocontrol board • • • • • • • • •

D.SUP.3 Establish a control system on deployedconfiguration • • •

D.SUP.4 Control configuration during acceptance in caseof updating • • •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

D.SUP.5 Control processes • • •

D.SUP.6 Monitor the plan and undertake coordinatedactions • •

D.SUP.7 Track joint risks • •

D.SUP.8 Mitigate joint risks • •

D.SUP.9 Independently control processes • •

D.SUP.10 Perform joint project milestone reviews • •

E.REQ.1 Manage change requests • • • • • • • • •

E.SOL.1 Manage changes to the technical solution • • • • • • • • • • •

E.IMP.1 Perform changes in reference to the technicalsolution • • • • • •

E.VER.1 Perform verification on developed and ISDSelements • • • • • • • • •

E.VAL.1 Perform validation through operational scenarios • • •

E.RAMS.1 Monitor operations andrReport incidents • • • •

E.ACQ.1 Manage and monitor obsolescence • • • • •

E.SUP.1 Transfer responsibility for system configurationmanagement to operator • •

E.SUP.2 Define procedures for maintenance activities • •

E.SUP.3 Perform operational testing after upgrading • •

E.SUP.4 Manage change requests during maintenance • • • • • • • • • •

E.SUP.5 Analyze impacts of modification requests anddecide changes • • • • • • • • • •

E.SUP.6 Perform configuration audits • • •

E.SUP.7 Control Processes during operation • • •

E.SUP.8 Monitor the plan and undertake coordinatedactions • •

E.SUP.9 Track joint risks • •


DNV GL AS


Func

tiona

lity

Rel

iabi

lity

Usa

bilit

y

Effic

ienc

y

Ava

ilabi

lity

Mai

ntai

nabi

lity

Port

abili

ty

Inte

grat

e ab

ility

Func

tiona

l saf

ety

Cos

ts

Sch

edul

e

E.SUP.10 Mitigate joint risks • •

E.SUP.11 Perform joint project milestone reviews • •


DNV GL AS

APPENDIX D RISK IDENTIFICATION CHECKLISTThe following checklist is provided as a starting point for some typical risk for an integrated softwaredependent system. This list is not all inclusive and some of the listed risk may not apply to every project.

Table D-1 Risk identification checklist

Id Name Description Type Comments

R01 COTS missingor wrongfunctionality,compared toexpected

Misunderstandings of supplier-suppliedbrochures of component functionalityand behaviour often lead to owner andoperator having less-than-expectedfunctionality.

Business Buying COTS does not guaranteeexpectations will be met. It is goodpractice, as outlined in the RP tomanage COTS requirements as wellas for specific products.

R02 Use of COTSSW in safetycriticalapplications

Use of standard real time operatingsystems that have not been developedaccording to standards for safety criticalsoftware may result in potential safetyissues.

Safety Many organisations are not awarethat there are also special versionsof these operating systems available.These versions are developedaccording to safety standards.However, they may typically havea reduced functionality and limitedHW support making a late stagesubstitution more or less impossible.

R03 Interactionbetweensystems leadto unexpectedbehaviour ofsafety functions

The interactions between the safetyfunctions, and the other are notunderstood by the individual suppliers,and not controlled by the integrator,resulting in potential safety issues.

Safety Mitigation activities may includesuch activities as defining staticand dynamic interfaces betweensystems, defining and checkingvarious operational scenarios.

R04 Obsolescenceof electronicequipment

The electronic equipment used often havelimited shelf life and limited productionruns. If management for obsolescencehas not been taken into account, gettingspare parts may be impossible, portingthe SW may be impossible, resulting inthe current system being binned andreplaced.

Business In addition, the cost of replacing theold system by a new as-identicalsystem way be important.

R05 Obsolescenceof SW

Support for standard pieces of SW,or made-to-order may be limited andstopped. Using systems in operationswhere support is not available may resultin loss of uptime in case of failures orwhen upgrades are needed.

Business SW pieces are usually maintainedfor a given set of years. Managingthe intellectual property, theobsolescence and the replacement ofSW may mitigate this risk by takingsteps for preserving the original OEMservice, allowing SW replacement, ortransferring SW source code to otherservice organisations.


DNV GL AS


R06 Lack of SWrequirements

The lack of software requirements(derived from functional requirementsfor the system) may lead to qualitydefects identified late, maybe duringFAT or commissioning, or maybe duringoperations, resulting in inconveniences,lack of performance, need for more usertraining and expertise.

Quality

R07 Lack of systemSW registry

In case of failure, during operations,or during maintenance activities andupgrades, the qualified SW set may belost. Without a consistent SW registry,it may be very difficult to return to anoperational state.

Schedule The availability of supplier registriesmay partly mitigate this risk, but caremust be taken that the whole systemconfiguration is recorded, in orderto get a consistent set of SW andparameters.

R08 Decoupling ofsystems dueto informationnetwork loss

The systems' components may, in caseof failure, propagate the failure modeto the network instead of isolatingthemselves from the network, causingother components to fail. The wholesystem may then fail.

Business A common occurrence in moderninformation network technology.May be mitigated by a combinationof activities including designingadequate network topology, requiringnetwork-capable components andverification of network propertiessuch as resistance to componentfailures.

R09 Maintenanceactivitiesdegrade system

Due to lack of documentation, complexdesign or other maintainability defects,the system may be degraded duringmaintenance activities by insufficientlytrained service personnel. Instead ofremoving defects, additional defects maybe introduced.

Schedule The overall availability of thesystem is usually not concernedby this risk in the first few years ofoperations. Every upgrade and largermaintenance activities thereafter mayincrease the risk.

R10 Incompatiblefail-to-safestates

Based on their standard equipment,suppliers design fail-to-safe statesfor their equipment, usually in orderto protect the equipment from harm.However, this behaviour may beincompatible with the fail-to-safe state ofthe whole system.

Safety For example, in a hull breach, thepumps should work as much aspossible, even in case of overheat.In this situation, the fail-to-safe ofthe pump in case of overheating isincompatible with the safety of thevessel.

Mitigation activities include theanalysis of degraded mode scenariosof several interacting systems,possibly using simulation if needed.

R11 Commoncause preventsredundancyprotectionagainst failure

SW and HW may fail by designwhen placed in certain operationalcircumstances. In that case, theredundancy introduced to protect againststatistical independent failures maynot protect as expected against theconsequences. (see failure, systematic in§2.1.2)

Safety For example, a DP system relying onsatellite information alone or usingthe same type of terminal may fail(has failed) entirely. All terminalsfrom the same manufacturer mayfail in the same manner, at the sametime.


DNV GL AS


R12 Lack ofalive-signalmonitoringmechanisms

Alive-signal monitoring mechanisms,like watchdogs, should be considered tomonitor periodic tasks.

Safety

R13 Lack ofacknowledgemechanisms

Acknowledge mechanisms, likeacknowledge messages, should beconsidered in order to increase theconfidence in the system.

Safety

R14 Lack of accessto fail-to-safestate

Is it possible to enter fail-to-safe stateanytime and in any situation or toperform any other procedure in orderto ensure that the system remains in aconsistent state?

It should be assessed if the systemcan be brought into fail-to-safe stateor is able to abort all the requirednominal operations whenever faultrecovery procedures are unsuccessful,independently of the system state.

Safety

R15 Lack of accesscontrol strategyregardingsharedresources

Access control issues should beconsidered in the requirements anddesign. Issues like access strategy(e.g. Priority Inheritance) or assigningpriorities to different processes should beaddressed.

Safety

R16 Unexpectedinput/outputdata format

Inputs/outputs should be verified andvalidated according to the expectedformat

Safety

R17 Lack ofparametermonitoring

Critical parameters and their boundariesshould be monitored (e.g. healthmonitors, timeout monitors). Bymonitoring different parameters, faultdetection increases its efficiency andcompleteness.

Safety

R18 Lack of errordetection/correctionmechanismsfor transmitteddata

Transmission errors should be consideredand a strategy implemented in order toavoid/prevent this type of issues (e.g.parity bits, CRC, retransmission etc.).

Safety

R19 Lack ofreference totime codes ortime signatures

A mechanism of signing data should beconsidered when gathering data (e.g.time stamps).

Safety

R20 Lack of faultdetectionreports

A report or log should be generatedwhenever a fault is detected. The reportgenerated by the fault detection shouldclearly identify the problem.

Safety


DNV GL AS


R21 Isolationmechanisms toprevent faultpropagation

There should be mechanisms to preventthat a failure propagates to otherfunctions or software modules (e.g. afterdetecting an incorrect formatted tele-command, it should be discarded andnot passed to any other function forprocessing).

Safety

R22 Lack ofrecoveryactions

A recovery action should be specifiedfor the detected faults and a reportgenerated whenever a recovery actionis completed. This report shall, at least,identify the recovery action and its result

(successful, unsuccessful).

Safety

R24 Inadequatetraining in howto operateback-upsystems andhow to copewith abnormalsituations

As reliability of software and hardwareis increasing, the level of integrationis increasing and the operators arebecoming more and more dependanton the automatic functions within theintegrated control system.

When an abnormal situation occurs,the operator may need to cope with thesituation by using the integrated controlsystem in a new and different way. Thisunusual method of operation can (dueto lack of practice or badly designedinterface) result in wrong decisions beingmade and/or actions being performed thatamplify the abnormal situation.

Alternatively, when an abnormal situationoccurs, the operator may need to copewith the situation by using manual meansof operation. This manual operation maylead to the same escalated problems dueto lack of practice and such issues asimproper marking of valves, etc.

Safety In this case, the first fault is whenautomation stops working asintended and the second fault occurswhen the operator cannot performthe action that everyone thinkshe can because he is inadequatelytrained or because the manual meansof operation are poorly designed.

R25 Lack ofcorrection offirst faults leadto second faultissues andcollapse of theISDS

The second fault issue is related to theredundant networks that are often seenon vessels. The effect of the first faultis one alarm and everything works asnormal. The effect of the second faultmay be total collapse of the entire ISDS.After the second fault, the vessel maynot be manned to handle this situation atall. If one experiences a single networkfault during operation - don't fix it untilbeing in safe harbour. Don't wait to fix itin harbour.

Safety Complexity of modern ISDS andlack of training lead to a moreprudent operational process formanaging seemingly innocuous faultsin order to be sure second failuresdo not cause harm to the vessel, itspassengers or the environment.


DNV GL AS

APPENDIX E COMPLETE REFERENCES AND BIBLIOGRAPHY

E.1 Complete referencesARP 4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems

ARP 4761 Guidelines and Methods for Conducting the Safety Assessment Process on CivilAirborne Systems and Equipment

BS 5760 Reliability of systems, equipment and components

CMMI Capability Maturity Model Integration, version 1.2, August 2006

DNVGL-RU-SHIPPt.4 Ch.9

DNV GL rules for classification of ships – Pt.4 Systems and components, Ch.9 Controland monitoring systems

DNVGL-OS-A101 DNV GL offshore standard for safety principles and arrangements

DNVGL-OS-D202 DNV GL offshore standard for automation, safety, and telecommunication systems

DNVGL-OS-E101 DNV GL offshore standard for drilling plant

DNVGL-RP-A203 Technology qualification

DO-178B Software Considerations in Airborne Systems and Equipment Certification, RTCA,December 1992

DO-254 Design Assurance Guidance for Airborne Electronic Hardware, RTCA, April 2000

IEC 60300 Dependability Management

IEC 61508 Functional safety of electrica electronic/programmable electronic safety relatedsystems

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

INCOSEHandbook

INCOSE Systems Engineering Handbook, June 2004

ARP 4761 Guidelines and Methods for Conducting the Safety Assessment Process on CivilAirborne Systems and Equipment.

ARP 4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems

OLF 070 Guidelines for the Application of IEC 61508 and IEC 61511 in the petroleum activitieson the continental shelf

OLF 104 Information Security Baseline Requirements for Process Control, Safety, and SupportICT Systems

ISO/IEC 12207 Information technology -- Software life cycle processes

ISO/IEC 15288 Systems engineering -- System life cycle processes

ISO 17894 General Principles for the Development and use of Programmable Electronic Systemsin Marine Applications

ISVV-GUIDE ESA Guide for Independent Software Verification and Validation

OLF 070 Guidelines for the Application of IEC 61508 and IEC 61511 in the petroleum activitieson the continental shelf

OLF 104 Information Security Baseline Requirements for Process Control, Safety, and SupportICT Systems

IEC 60300 Dependability Management


DNV GL AS

IEC 61508 Functional safety of electrical/electronic/programmable electronic safety relatedsystems

INCOSEHandbook

INCOSE Systems Engineering Handbook, June 2004.

CMMI Capability Maturity Model Integration, version 1.2, August 2006.

SSA Safety and Security Extensions for Integrated Capability Maturity Models, FAA.

DO-178B Software Considerations in Airborne Systems and Equipment Certification, RTCA,December 1992.

DO-254 Design Assurance Guidance for Airborne Electronic Hardware, RTCA, April 2000.

ISVV-GUIDE ESA Guide for Independent Software Verification and Validation

E.2 Bibliography[CJ2000] Capers Jones, Software Assessments, Benchmarks and Best Practices, 2000.

[DNV2006] DNV Internal SMICT Research Report.

[DSDM] The DSDM Manual

[WK2008a] http://en.wikipedia.org/wiki/List_of_System_Quality_Attributes

http://en.wikipedia.org/wiki/List_of_System_Quality_Attributes

Cha

nges

– h

isto

ric


DNV GL AS

CHANGES – HISTORICThere are currently no historical changes for this document.

About DNV GLDriven by our purpose of safeguarding life, property and the environment, DNV GL enablesorganizations to advance the safety and sustainability of their business. We provide classification,technical assurance, software and independent expert advisory services to the maritime, oil & gasand energy industries. We also provide certification services to customers across a wide rangeof industries. Operating in more than 100 countries, our experts are dedicated to helping ourcustomers make the world safer, smarter and greener.

SAFER, SMARTER, GREENER

DNVGL-RP-D201 Integrated software dependent systems€¦ · The purpose of the revision of this...

Documents

Transcript of DNVGL-RP-D201 Integrated software dependent systems€¦ · The purpose of the revision of this...