RECOMMENDED PRACTICE DNV-RP-0582
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
RECOMMENDED PRACTICE
DNV-RP-0582 Edition June 2021
Checkpoint verification of computer-based
systems
The PDF electronic version of this document available at the DNV website dnv.com is the official version. If there
are any inconsistencies between the PDF version and any other available version, the PDF version shall prevail.
DNV AS
FOREWORD DNV recommended practices contain sound engineering practice and guidance. © DNV AS June 2021 Any comments may be sent by e-mail to rules@dnv.com This service document has been prepared based on available knowledge, technology and/or information at the time of issuance of this document. The use of this document by other parties than DNV is at the user's sole risk. DNV does not accept any liability or responsibility for loss or damages resulting from any use of this document.
CHANGES – CURRENT
Changes - current
This is a new document.
Topic Reference Description
Rebranding to DNV, cross- All Some of the documents referred to may not yet have been
references rebranded. If so, please see the relevant DNV GL document.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 3
Checkpoint verification of computer-based systems
DNV AS
Acknowledgements
Changes - current
This recommended practice has been developed based on results from a joint development project (JDP).
The following companies, listed in alphabetical order, are acknowledged for their contributions to the JDP:
— ABB
— Daewoo Shipbuilding and Marine Engineering Co., Ltd. (DSME)
— Honeywell Process Solutions
— Hudong Zhonghua Shipbuilding Group
— Hyundai Heavy Industries (HHI)
— Kongsberg Maritime (KM)
— Nakilat
— Samsung Heavy Industries (SHI)
— Wärtsilä.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 4
Checkpoint verification of computer-based systems
DNV ASCONTENTS
Contents
Changes – current.................................................................................................. 3
Acknowledgements................................................................................. 4
Section 1 General.................................................................................................... 7
1.1 Introduction......................................................................................7
1.2 Objective...........................................................................................8
1.3 Scope................................................................................................ 9
1.4 Application........................................................................................ 9
1.5 References........................................................................................ 9
1.6 Definitions and abbreviations......................................................... 10
Section 2 Life cycle processes...............................................................................18
2.1 General........................................................................................... 18
2.2 Systems under consideration and scope......................................... 20
2.3 Documentation................................................................................23
Section 3 Recommended approach....................................................................... 26
3.1 Hierarchical structure and levels.................................................... 26
3.2 Checkpoints definition.................................................................... 27
3.3 Management of change...................................................................34
3.4 Management of service level agreement.........................................37
Section 4 Verification activities.............................................................................41
4.1 Verification levels (VL)................................................................... 41
4.2 Verification results..........................................................................41
4.3 VL3 verification targets.................................................................. 41
Section 5 Some use cases..................................................................................... 43
5.1 General........................................................................................... 43
5.2 Use cases for supplier: for manufacturing process......................... 44
5.3 Use cases for system integrator: for system integration and
commissioning...................................................................................... 45
5.4 Use cases for owner: for acceptance, operation and
maintenance......................................................................................... 48
5.5 Use cases for independent verifier: for third-party checkpoints
verification............................................................................................50
Section 6 New ways of collaboration.................................................................... 52
6.1 Collaboration processes.................................................................. 52
Recommended practice — DNV-RP-0582. Edition June 2021 Page 5
Checkpoint verification of computer-based systems
DNV AS6.2 Collaboration services and tools..................................................... 55
Contents
Appendix A Documentation explanations and examples....................................... 57
A.1 System block diagram (topology, I030)......................................... 57
A.2 Inventory list for systems under consideration (I071)................... 57
A.3 List of application software (I230).................................................58
A.4 Maintenance plan (I140)................................................................ 58
A.5 Integration plan (I210).................................................................. 59
Appendix B Recommended approach definition.................................................... 60
B.1 Hierarchical structure and levels.................................................... 60
B.2 Mapping between checkpoints and different aspects...................... 60
B.3 Management of service level agreements....................................... 69
Appendix C Forms and guides...............................................................................71
C.1 Forms to be filled in for each checkpoint........................................71
C.2 Guide for service level agreement (SLA)........................................ 81
Changes – historic................................................................................................ 82
Recommended practice — DNV-RP-0582. Edition June 2021 Page 6
Checkpoint verification of computer-based systems
DNV ASSECTION 1 GENERAL
1.1 Introduction
1.1.1 Background
Equipment and systems on board vessels have become more complex, automated, and with a higher level
of integration. This trend is accelerating with time, and the continuing evolution provides owners of vessels
and installations with opportunities, but it also introduces challenges regarding management of such systems
through their full life cycle from design to de-commissioning.
The main challenge when creating complex integrated computer-based systems, is how to engineer the
various system elements into a single system that meets all the specified requirements, in terms of safety,
functionality, reliability, security, etc. Selecting and connecting system elements that may individually satisfy
the requirements is not sufficient. The challenge extends to the integration of the system elements and an
understanding of their operation within the system, in particular the effect that software components may
have on each other, in order to deliver the emerging properties of the system.
1.1.2 Challenges
Software may cause several challenges for both newbuilding (NB) and vessels in operation (ViO), as critical
vessel functions commonly depend on computer based systems. The challenges caused by software are often
due to the nature of software:
— invisible and intangible: there is no physical matter, only instructions to a computer, invisible to humans
— lawless: as its behaviour is not subject to physical laws (except time), it makes it hard to make
assumptions and deductions about it
— no wear and tear: it does not change spontaneously, but may become outdated with time
— no inherent structure: the final structure solely depends on the programmer and the system design
— no limitation of functionality or complexity: potentially making it hard to understand and maintain over
time
— no production time: once it has been created it can be replicated and deployed without much effort or
lead time, making it tempting to make last minute changes
— practically impossible to test completely: a high number of different inputs and outputs, together with a
number of internal states, makes it very hard (or very expensive) to test all combinations.
Experience shows that the following aspects may be attributed as main causes of software related issues:
1) Methods: suppliers and yards are not fully utilizing effective proven system and software engineering
methods to ensure quality, neither are such methods expected by the other stakeholders, like owners
and operators.
2) Management: software and system configurations are not being systematically and consistently managed
throughout the life cycle.
3) Change handling: during newbuilding projects the focus is on getting everything to work there and then.
Obsolescence and upgrades are not sufficiently planned for, and thus become a surprise later.
4) Information: there is sometimes a lack of insight into the actual status of the system development and
delivery projects.
This recommended practice (RP) aims to address these main causes and recommend some practical actions
to handle such issues related to software and computer based systems in the vessel life cycle.
1.1.3 Key approaches
Based on the main causes as listed above, this RP gives guidance regarding quality control and assurance
with a checkpoint-based verification of computer-based systems spanning a vessel's full life cycle, from
design and development, to operations. The key approaches are illustrated in Figure 1-1:
Recommended practice — DNV-RP-0582. Edition June 2021 Page 7
Checkpoint verification of computer-based systems
DNV AS1) Hierarchical structure: making the software components tangible and visible by organizing them as a
part of an overall architecture with multiple abstraction layers.
2) Checkpoints: putting clear expectations on the different stakeholders regarding which 'good practices'
for system- and software-design they are expected (or required) to perform by defining a number of
checkpoints that the different elements in the architecture shall pass.
This also provides a transparency for relevant stakeholders into the actual state of the different system
elements throughout the life cycle.
3) Management of change (MoC): making it possible to systematically follow up on the state of software
components and systems during systems integration and operation, particularly with respect to
managing changes and obsolescence.
4) Utilizing of service level agreements (SLA) during operations: establishing and agreeing upon SLAs
between relevant stakeholders to increase the transparency of life cycle cost and reduce operational
downtime.
See Sec.3 for more details about the different approaches.
Figure 1-1 Key focus areas of the recommended practice
1.2 Objective
This RP provides guidance regarding handling of complex software and computer-based systems during
a vessel's complete life cycle (design, construction, commissioning, and operation) to improve software
reliability and quality through focus on system integration and change handling.
The objectives of this RP are to provide recommendations to:
1) increase the reliability of software and systems to provide more reliable and safer vessel operations, i.e.
reduce the risk for accidents and downtime for ViO
2) reduce the risk for delays during newbuilding (NB) projects
3) increase the interoperability and integrability of software and systems to the vessels in NB and ViO
4) communicate and resolve key issues related to integration challenges at an early stage and throughout
the whole life cycle
5) increase the maintainability of software and systems with maintenance plans and/or SLA to the vessels,
particularly for ViO
6) serve as a guideline, common framework and contractual reference between suppliers and purchasers
during the whole ship life cycle.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 8
Checkpoint verification of computer-based systems
DNV AS1.3 Scope
This RP provides guidance on system integration and software reliability challenges to support more reliable
and safer vessel operations. It may be applied to different levels of the vessel hierarchy, from the vessel
(system of systems), to systems (or sub-systems), interfaces, software components, and key parameters
level. It covers the full life cycle of a vessel, from basic engineering (or requirements), engineering (or
design), construction, acceptance (or commissioning), to operation (and maintenance) phases. It defines a
set of checkpoints, with specific responsibilities for different roles.
This RP covers different kinds of software:
— basic software
— application software
— vessel specific configurations, including key parameters.
Sec.2 describes the life cycle processes, including phases, roles, systems under consideration, checkpoints,
responsibilities.
Sec.3 defines the requirements for the different checkpoints, organized by different phases, levels and roles.
Sec.4 describes the various verification and certification options, including different levels of verification.
Sec.5 explains some possible use-cases for this RP.
Sec.6 introduces some possible new ways of collaboration based on the approaches described in this RP.
1.4 Application
This RP may be relevant for:
— owners or operators: who request that an integrated system of systems is delivered as a part of the
vessel, both for newbuilding and existing vessels in operation.
— system integrators: who are responsible to deliver the integrated system of systems as a part of the
vessel
— system suppliers: who require a systematic approach to ensure and document that the systems will
perform according to expectations
— sub-suppliers: who want to be able to deliver a qualified module to be integrated into a larger system
— independent verifiers: who require a framework and a set of requirements to verify conformity of the
software, systems and vessels.
The core of this RP is developed on the basis of the requirements in DNV-OS-D203 which describes a
voluntary class notation, ISDS - integrated software dependent systems, that apply to a ship or offshore
unit.
This RP may be used as:
1) a contractual element/requirement in newbuilding or conversion projects (especially Sec.3).
2) guidelines for suppliers, system integrators and owners/operators for compliance check and status
follow-up.
See Sec.5 for some possible use-cases of this RP.
1.5 References
Table 1-1 lists DNV references used in this document.
Table 1-1 DNV references
Document code Title
DNV-RU-SHIP Pt.4 Ch.9 Control and monitoring systems
Recommended practice — DNV-RP-0582. Edition June 2021 Page 9
Checkpoint verification of computer-based systems
DNV ASDocument code Title
DNV-OS-D203 Integrated software dependent systems
DNV-RP-D201 Integrated software dependent systems
DNV-RU-SHIP Pt.6 Ch.5 Sec.13 Enhanced system verification
DNV-RU-SHIP Pt.6 Ch.11 Sec.2 Data-driven verification
DNV-RU-SHIP Pt.6 Ch.5 Sec.21 Cyber security
DNV-CG-0557 Data-driven verification
DNV-OS-D202 Automation, safety and telecommunication systems
DNV-CP-0507 Software and systems engineering
DNV-CG-0550 Maritime services - terms and systematics
Table 1-2 lists other references used in this document.
Table 1-2 Other references
Document code Title
IACS UR E22 On board use and application of computer based systems
IACS Rec 166 Recommendation on cyber resilience
ISO 24060 Ships and marine technology - Ship software logging system for operational technology
ISO/IEC 20000 Service management system
ITIL Information technology infrastructure library
FitSM Family of standards for lightweight IT service management
1.6 Definitions and abbreviations
1.6.1 Verbal forms
The verbal forms defined in Table 1-3 are used in this document.
Table 1-3 Verbal forms
Term Definition
shall verbal form used to indicate requirements strictly to be followed in order to conform to the
document
should verbal form used to indicate that among several possibilities one is recommended as
particularly suitable, without mentioning or excluding others
may verbal form used to indicate a course of action permissible within the limits of the document
Recommended practice — DNV-RP-0582. Edition June 2021 Page 10
Checkpoint verification of computer-based systems
DNV AS1.6.2 Definitions
The terms defined in Table 1-4 are used in this document.
Table 1-4 Definitions
Term Definition
activity defined body of work to be performed, including its required work product(s) and record(s)
or information to be provided together
application software software designed to fill specific needs of a user
assessment activity to collect, review, analyse evidences of compliance and implementation against a
reference standard, reference model or reference framework
attribute piece of information which determines properties of a system or function
audit independent examination of a work product or set of work products to assess compliance
with specifications, standards, contractual agreements, or other criteria
availability time or proportion of time that the system is functioning as intended
baseline consistent set of specifications or products that have been formally reviewed and agreed
upon, that thereafter serve as the basis for further development, and that may only be
changed through formal change control procedures
base software software component or a software (sub) system which is made with the purpose of being
reused in many delivery projects
Typically contains attributes that must be correctly configured per vessel or delivery project.
block diagram diagram of a system, computer, or device in which the principal parts are represented by
suitably annotated geometrical figures to show both the functions of the parts and their
functional relationships
checkpoint set of verification activities and questions that should be executed and answered
source (code) review systematic examination (often as peer review) of computer source code intended to find and
fix mistakes overlooked in the initial development phase, improving the overall quality of
software, code review may also be partly automated
commissioning (tests) verifying and documenting that the unit and all of its systems are designed, installed, tested
and can be operated and maintained to meet the owner's requirements
component logical grouping of other components or modules inside a system or sub-system
critical any function or component whose failure could interfere significantly with the operation or
activity under consideration
defect non-fulfilment of a requirement (including both functional and non-functional parts)
dependability collective term used to describe the availability performance and its influencing factors:
reliability performance, maintainability performance and maintenance support performance,
see RAMS, to which it adds security
due diligence (software) investigation, validation and verification of a software system/sub-system/component/
module for proving its usefulness and conformity in a given context
error discrepancy between a computed, observed or measured value and condition and the true,
specified or theoretically correct value or condition
Recommended practice — DNV-RP-0582. Edition June 2021 Page 11
Checkpoint verification of computer-based systems
DNV ASTerm Definition
essential function (or system supporting the function, which needs to be in continuous operation or continuously
system) available for on demand operation for maintaining the unit's safety
See DNV-OS-D202.
factory acceptance tests acceptance testing of a component, sub-system or system before delivery and integration
failure termination of the ability of a functional unit to perform a required function on demand
Note:
A fault in a part of the system may lead to the failure of its function, itself leading to a fault in
other linked parts or systems etc.
---e-n-d---o-f---n-o-t-e---
impact analysis identifies all systems and software products affected by a software change request and
develops an estimate of the resources needed to accomplish the change and determines the
risk of making the change
integration strategy (or assembly sequence and strategy that minimizes system integration risks
plan) This strategy may permit verification against a sequence of progressively more complete
component configurations and be consistent with a fault isolation and diagnosis strategy. It
defines the schedule of component availability and the availability of the verification facilities,
including test jigs, conditioning facilities, assembly equipment.
integrated software integrated system for which the overall behaviour is dependent on the behaviour of its
dependent system software components
integrated system set of elements which interact according to a design, where an element of a system can
be another system, called a subsystem, which may be a controlling system or a controlled
system and may include hardware, software and human interaction
inter-system interaction between two or more systems, e.g. interfaces, behaviour, functionality
interface 1) a shared boundary across which information is passed
2) a hardware or software component that connects two or more other components for the
purpose of passing information from one to the other
3) to connect two or more components for the purpose of passing information from one to
the other
4) to serve as a connecting or connected component as in (2)
5) a collection of operations that are used to specify a service of a component
maintainability 1) the ease with which a software system or component can be modified to correct faults,
improve performance or other attributes, or adapt to a changed environment
2) the ease with which a hardware system or component may be retained in, or restored
to, a state in which it can perform its required functions
milestone scheduled event marking the transition from one project phase to the next, this standard
identifies five milestones
module lowest branches in the system hierarchy, modules can be made of hardware (HW) or
software (SW)
obsolescence (risk) risk associated with technology within the system that becomes obsolete before the end
of the expected shelf or operations life, and cannot provide the planned and desired
functionality without increased risk of failure
operations checkpoint checkpoint in the operations phase
Recommended practice — DNV-RP-0582. Edition June 2021 Page 12
Checkpoint verification of computer-based systems
DNV ASTerm Definition
parameters set of consistent attributes that together make up a specific configuration of a system
peer review process of subjecting an author's work to the scrutiny of others who are experts in the same
field
Used for quality assurance of both documents and software source code (see source (code)
review).
project series of tasks that need to be completed to reach a specific outcome
record information or document stating results achieved or providing evidence of activities
performed
regression testing selective retesting of a system or component to verify that modifications have not caused
unintended effects and that the system or component still complies with its specified
requirements
release note reference to the distribution of a software or system configuration item outside the
development activity
This includes internal releases as activities may contain provisions which cannot be satisfied
at the designated point in the life cycle.
The release notes typically describe new capabilities, known problems, and platform
requirements necessary for proper product operation.
reliability capability of the system to maintain a specified level of performance when used under
specified conditions
requirement objectively verifiable criteria to be fulfilled and from which no deviation is permitted if
conformance with the document is claimed
reused software software integrated into the system that is not developed during the project, i.e. both
standard software and non-standard legacy software, software may be reused as is or be
configured or modified
review activity undertaken to determine the suitability, adequacy and effectiveness of the subject
matter to achieve established objectives
revision control management of multiple revisions of the same unit of information (also known as version
control, source control or (source) code management, document revision management)
risk qualitative or quantitative likelihood of an accident or unplanned event occurring, considered
in conjunction with the potential consequences of such a failure, in quantitative terms, risk is
the quantified probability of a defined failure mode times its quantified consequence
role organization with responsibilities within the system life cycle, a role has specific activities to
perform
software computer programmes, procedures, and possibly associated documentation and data
pertaining to the operation of a computer system
software component interacting set of software modules
software life cycle period of time that begins when a software product is conceived and ends when the software
is no longer available for use
The software life cycle typically includes a concept phase, requirements phase, design
phase, implementation phase, test phase, installation and checkout phase, operation and
maintenance phase, and, sometimes, retirement phase.
Note: these phases may overlap or be performed iteratively.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 13
Checkpoint verification of computer-based systems
DNV ASTerm Definition
software module separately compilable or executable piece of source code
It is also called software unit or software package. A small self-contained programme which
carries out a clearly defined task and is intended to operate within a larger programme.
simulation one of real-world simulation, process simulation, electronic circuit simulation, fault
simulation, simulation of software in the loop (SIL), simulation of the system’s environment
or hardware in the loop (HIL), simulators serve various purposes and use different modelling
techniques
source code computer instructions and data definitions expressed in a form suitable for input to an
assembler, compiler, interpreter or other translator, in a human-readable form
specification document that specifies, in a complete, precise, verifiable manner, the requirements, design,
behaviour, or other characteristics of a system or component, and often, the procedures for
determining whether these provisions have been satisfied
sub-supplier organisations and companies delivering products and services to suppliers
sub-system part of a system, for example choke and kill is a part of the well control system, the
independent joystick is part of the DP system
system defined product which contains sub-systems, a system refers to the qualifier identified in the
notation, for example DP, DCS, PMS, etc.
system architecture The selection of the types of system elements, their characteristics, and their arrangement
traceability linkage between requirements and subsequent work products, e.g. design documentation
and test documentation
validation confirmation, through the provision of objective evidence that the requirements for a specific
intended use or application have been fulfilled
validation strategy identification (e.g. list) of validation activities to be performed, along with validation
methods, objectives, and responsibility assigned to them, the purpose of this strategy is to
minimize redundancy and maximize effectiveness of the various validation activities
verification tasks, actions and activities performed to evaluate progress and effectiveness of the
evolving system solutions (people, products and process) and to measure compliance with
requirements
Analysis (including simulation, demonstration, test and inspection) are verification
approaches used to evaluate risk, people, product and process capabilities, compliance with
requirements, and proof of concept.
verification strategy identification (e.g. list) of verification activities to be performed, along with verification
methods, objectives, and responsibility assigned to them
The purpose of this strategy is to minimize redundancy and maximize effectiveness of the
various verification activities.
version items of software or hardware modules, components and systems that evolve as a project
proceeds, a version of a item is a particular identified and specified item, it may be thought
of as a state of an evolving item
work product deliverable or outcome that shall be produced to prove the completion of an activity or task,
work products may also be referred to as artefacts
Recommended practice — DNV-RP-0582. Edition June 2021 Page 14
Checkpoint verification of computer-based systems
DNV AS1.6.3 Abbreviations
The abbreviations described in Table 1-5 are used in this document.
Table 1-5 Abbreviations
Abbreviation Description
A accountable
AKA also known as
AP for approval
API application programming interface
C consulted
CAAP critical alarm and action panel
CCM cargo control and monitoring
CL confidence level (as defined in DNV-OS-D203 )
COM communication systems
CP checkpoint
DP dynamic positioning
ESD emergency shutdown
F&G fire and gas system
FAT factory acceptance tests
FDS fire and gas detection system
FI for information
FiS fleet in service
H high
HIL hardware in the loop
HVAC heating, ventilation, air conditioning
HW hardware (as opposed to software)
I informed
IACS The International Association of Classification Societies
IAS integrated automation system
ICM integrated control and monitoring system
ICS integrated network communications systems
ID identity/identification
INS integrated navigation system
Int interface
Recommended practice — DNV-RP-0582. Edition June 2021 Page 15
Checkpoint verification of computer-based systems
DNV ASAbbreviation Description
I/O input/output
ISDS integrated software dependent systems
IV independent verifier
JDP joint development project
KPI key performance indicator
L low
M medium
MCP milestone checkpoint
MoC management of change
NAV navigation systems
NB newbuilding
OCP operations checkpoint
OP operator
OS offshore standard/operating system
OW owner
Par parameters
PMS power management system
PSD process shut down
R responsible
RACI responsible (R), accountable (A), consulted (C), informed (I)
RAD remote access and diagnostic system
RAMS reliability, availability, maintainability, safety
RP recommended practice
SDS shutdown and disconnection systems
SI system integrator
SIL software in the loop
SIT system integration test
SLA service level agreement
SoS system of systems
SP safety profile
SPT steering, propulsion and thruster control and monitoring system
SU supplier
SuC systems under consideration
Recommended practice — DNV-RP-0582. Edition June 2021 Page 16
Checkpoint verification of computer-based systems
DNV ASAbbreviation Description
SW software
Sys system
VDU visual display unit
ViO vessels in operation
VL verification level
VV verification and validation
Recommended practice — DNV-RP-0582. Edition June 2021 Page 17
Checkpoint verification of computer-based systems
DNV ASSECTION 2 LIFE CYCLE PROCESSES
2.1 General
2.1.1 Life cycle and phases
The life cycle of a vessel may be divided into several stages in terms of timeline when different activities may
occur, which are named as phases. The transitions between the phases represent milestones. All activities in
this RP are mapped to phases in the typical vessel life cycle.
See Figure 2-1 for the phases and milestones in a typical vessel life cycle.
Figure 2-1 Vessel life cycle, phases and milestones.
The phases are described in more details in Table 2-1.
Table 2-1 Life cycle phases
ID Phase Also known as Description
During this phase the technical specification and design of the vessel
Basic are established. The main systems which will be included in the
A Requirements
engineering scope for the RP are identified. The contract between the owner and
the system integrator is established during this phase.
In this phase contracts are established with suppliers, and the
suppliers are involved in setting up the development/configuration
B Engineering Design of each system. The detailed design of the vessel and systems is
documented. The verification, validation, testing and integration
strategies, and major interfaces are established.
In this phase the construction and integration of the systems are
carried out. Detailed software design, coding, configuration and/or
C Construction Implementation
parameterization are performed. Systems and interfaces are tested,
validated and verified as part of this phase.
Commissioning, In this phase, the functionality, performance, and other aspects
D Acceptance of the integrated systems are validated, through commissioning
testing activities, integration testing, and sea trials.
Operation and In this phase the vessel is in operation. Maintenance and small
maintenance, upgrades are performed as deemed necessary by the owner.
E Operation vessel in operation
(ViO),
fleet in service (FiS)
At each milestone the following information shall be reported by the involved roles:
Recommended practice — DNV-RP-0582. Edition June 2021 Page 18
Checkpoint verification of computer-based systems
DNV AS— status for the compliance to this RP, according to the relevant milestone checkpoint (MCP), see [2.1.2]
below
— action plans for handling non-conformities
— risk observations, with a "traffic-light" colour indication.
A milestone is completed when the relevant roles endorse the information presented at the milestone.
See the roles definition in [2.1.3] and checkpoints definition in [3.2].
2.1.2 Milestone checkpoints
A key approach in this RP is the checkpoint. A checkpoint is a set of verification activities and questions,
defined for the different levels in the hierarchical structure, like the software component, system, up to
the entire scope of delivery for the vessel. For each phase in the vessel's life cycle, an aggregation of
checkpoints, called milestone checkpoint (MCP), is used to check the readiness of corresponding products
and the compliance to the provisions in this RP.
The checkpoints are aggregated into an MCP per phase. Each MCP has a name and number as defined in
Table 2-2.
Table 2-2 Milestone checkpoint (MCP) names
Number Milestone checkpoint (MCP) name For phase
MCP1 Inputs frozen Basic engineering
MCP2 Design frozen Engineering
MCP3 Ready for FAT Construction
MCP4 Ready for operation Acceptance
MCP5 Ready for maintenance Operation
MCP6 Update ready Operation
Figure 2-2 shows the MCPs mapped to each phase in the vessel life cycle.
Figure 2-2 Example of milestone checkpoints used to indicate status using traffic-light colours
See [3.1] for definition of the different levels in the hierarchical structure and [3.2] for details of the
individual checkpoints.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 19
Checkpoint verification of computer-based systems
DNV AS2.1.3 Roles
This RP defines requirements on several organisations with responsibilities within the system life cycle. Each
role is assigned activities and has the responsibility to perform the activity with an outcome that fulfils the
specified criteria.
Each organisation is assigned one of four defined roles. The four roles are:
— Owner (OW): in the context of this standard the owner is the organisation who decides to develop the
vessel and provides funding. The operator (OP) of the system may be part of the owner's organisation or
a subcontractor acting on behalf of the owner.
— System integrator (SI): responsible for the integration of all systems included in the scope of this RP. The
system integrator is normally the shipyard, but parts of the integration may be delegated to other parties.
In such case this shall be clearly defined and documented.
— Supplier (SU): responsible for the integration and delivery of one or more single systems. If the supplier
purchases products and services from other organisations, these are regarded as sub-suppliers, and are
under the supplier's responsibility.
— Independent verifier (IV): an organisation that is mandated to independently verify that the system is
developed according to this RP. As part of the classification process for the class notation, DNV shall take
the role of the IV.
2.2 Systems under consideration and scope
2.2.1 Systems under consideration (SuC)
This RP defines the following six categories of systems to be placed under consideration for the scope of work
for newbuilding vessels:
— Machinery systems: the systems that are essential and important for maintaining the vessel's main
functions, including safety functions.
— Safety systems: the systems that are related to safety functions for human, vessel and the environment.
— Bridge systems: the systems that are used to provide navigation and communication functions.
— Cargo systems: the systems that are related to handling operations of cargos carried by the vessel.
— Industrial systems: the systems that intend to fulfil the industrial purpose or missions of the vessel.
— Plus (+) systems: or other systems for other purposes as specified in the newbuilding specifications.
See Table 2-3 for a list of systems under consideration for newbuilding vessels, per categories as defined
above.
Table 2-3 Systems under consideration and categories
Category System under consideration Abbreviation Typical sub-systems and components Notes
of systems
Steering, propulsion and SPT — steering system
thruster — propulsion system
control and monitoring — thruster system
system
Machinery Power management system PMS — power generation system PMS may be a
— power distribution system part of IAS as an
integrated system.
— blackout prevention and load
reduction systems
— blackout recovery systems
Recommended practice — DNV-RP-0582. Edition June 2021 Page 20
Checkpoint verification of computer-based systems
DNV ASCategory System under consideration Abbreviation Typical sub-systems and components Notes
of systems
Integrated control and ICM (IAS) — vessel alarm management system Integrated system,
monitoring system, (AMS) including AMS,
also known as — sea water, fresh water, hot PMS, etc.
integrated automation and — water, high pressure wash down
control system system
— fuel, lube oil system
— HVAC system
— service, instrument and bulk air
system
— hydraulic power system
— bilge and ballast system
— load and stability system
Fire and gas system F&G — fire and gas detection system (FDS)
— alarm and communication system
— systems for automatic action
Safety
Shutdown and SDS (ESD) — emergency shutdown (ESD)system
disconnection systems — process shutdown (PSD) system
— critical alarm and action panel (CAAP)
Navigation systems NAV — radar, AIS, GNSS, ECDIS,
— compass, gyro, heading and bearing
indicator,
— BNWAS, echo sounder, electronic
plotting, speed and distance
measuring device,
— tracking aid, rate of turn indicator
Bridge and transmitting heading device
— integrated navigation systems (INS).
Communication systems COM — distress alert, EPIRB,
— public announcement, general alarm,
— satellite communication, wireless
communication and integrated
network communications systems
(ICS)
Cargo handling control and CCM — Cargo handling control and
Cargo
monitoring system monitoring system
Dynamic positioning system DP — main, alternative and back-up DP Applicable for
control system (as applicable) DYNPOS and DPS
Industrial — independent joystick system notation
(purpose) — positioning reference systems
— thruster control mode selection
system
Recommended practice — DNV-RP-0582. Edition June 2021 Page 21
Checkpoint verification of computer-based systems
DNV ASCategory System under consideration Abbreviation Typical sub-systems and components Notes
of systems
Drilling control system DRILL (BOP) — heating, ventilation, and air Applicable for
conditioning (HVAC) for local DRILL notation
equipment room
— driller’s chair
— drilling data acquisition and analysis
system
— top drive
— drawwork (considered part of HCTS
if drawwork is used for heave
compensation)
— rotary table
— drilling power management system
Production control system PROD (PCS) — topside process control system (PCS), Applicable for
including PROD notation
— topside panels
— subsea control unit
— subsea power and communication
unit
— topside electronic modules
— emergency/process shutdown (ESD/
PSD) system
+ (Plus) Remote access and RAD — remote access system + other systems
diagnostic system — diagnostic system as specified in
the newbuilding
specifications
Note:
Plus (+) category includes other systems as specified in the newbuilding specifications, that do not fall into the other five defined
categories.
---e-n-d---o-f---n-o-t-e---
This RP refers to the naming and categorization of systems across relevant rules, including the following:
— DNV-OS-D203 Integrated software dependent systems (ISDS): see Table 2 ISDS class notation scope,
system definitions and confidence level selection systems.
— DNV-RU-SHIP Pt.6 Ch.5 Sec.21 Cyber security: [2.3] Table 10 Essential and important systems, Table 11
Bridge systems, Table 12 Industrial purpose systems.
— DNV-RU-SHIP Pt.6 Ch.5 Sec.13 Enhanced system verification (ESV): [1.4.2] Table 1 Target control and
monitoring systems.
— DNV-RU-SHIP Pt.6 Ch.11 Sec.2 Data-driven verification (DDV): [1.5.2] Table 2 Target systems.
2.2.2 Safety profile levels
This RP defines three safety profile (SP) levels to harmonize with different regulations and rule requirements,
aiming to provide an increasing level of protection against failures and safety risks. SP levels 2 and
3 correspond to the ISDS CL2 and CL3 requirements, SP1 corresponds to DNV-RU-SHIP Pt.4 Ch.9
requirements that maps to IACS UR E22. See Table 2-4.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 22
Checkpoint verification of computer-based systems
DNV ASTable 2-4 DNV safety profile levels
SP
Characteristics Focus areas Reference
levels
Software requirements,
Software requirements,
software development, IACS UR E22 compliance, or DNV-RU-SHIP Pt.4
SP1 development and data
networks and data Ch.9 requirements
communication
communication
Software reliability and System development,
SP2 DNV-OS-D203, ISDS CL2 requirements
system integration system integration
High dependability (RAMS)
Enhanced independent requirements,
SP3 DNV-OS-D203, ISDS CL3 requirements
process verification
independent process verification
See [B.3] for a mapping of checkpoints requirements to different rule (e.g. ISDS) requirements and different
levels of ISDS CL's and SP's as defined therein.
2.2.3 Scope of work
The scope of work (SoW) may be expressed using the selected systems under consideration (SuC), in
combination with the safety profile (SP) levels that are assigned to each SuC.
One option is to specify the SoW as a string containing a list of the systems under consideration with the
assigned safety profile (SP) level separated by comma: SoW = {}
Alternatively the SuC's may be aggregated into the system categories they belong to. See Table 2-5 for two
examples.
Table 2-5 Examples of scope of work strings
Aggregated scope of work strings
Example Scope of work strings using
using
1 (CCM2, DP3, ICM2, NAV1, PMS2, SDS3) (Cargo2, Industrial3, Machinery2, Bridge1, Safety3)
(Cargo2, Industrial3, Machinery1/2, Bridge1, Safety3,
2 (CCM2, DP3, ICM2, NAV1, PMS1, RAD2, SDS3)
+(RAD2))
2.3 Documentation
2.3.1 Documentation to be submitted by the system supplier
Table 2-6 lists the requirements for documentation to be submitted by the system supplier.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 23
Checkpoint verification of computer-based systems
DNV ASTable 2-6 Documentation to be submitted by the system supplier
Documentation type Description Info Relevant safety profiles
A schematic drawing at
the system architecture
I030 - System block level showing all main
components, networks and FI SP1+
diagram (topology)
connections, interfaces.
See also [A.1] for example.
A document listing all
inventory components
I071 - Inventory list for (hardware and software)
in the systems under AP SP2+
systems under consideration
consideration (SuC).
See also [A.2] for example.
A list containing
identification of functions
I230 - List of application implemented, software AP SP2+
software version.
See also [A.3] for example.
also may be named as
maintenance plan, a defined
procedure and plan for
I140 - Software quality plan software maintenance FI SP1+
activities during the vessel
life cycle.
See also [A.4] for example.
AP = for approval, FI = for information, SPn+ = SPn and higher levels.
The system suppliers are mainly responsible to submit I030 and I140 documents for the systems under
consideration within their scope of delivery, but also responsible to provide needed inputs to the system
integrator to submit I071 and I230 documents.
See App.A for examples and explanations regarding the documentation.
2.3.2 Documentation to be submitted by the system integrator
Table 2-7 lists the requirements for documentation to be submitted by the system integrator.
Table 2-7 Documentation to be submitted by the system integrator
Documentation type Description Info Relevant safety profiles
I030 - System block See Table 2-6 above.
FI SP1+
diagram (topology) See also [A.1] for example.
I071 - Inventory list for See Table 2-6 above.
AP SP2+
systems under consideration See also [A.2] for example.
I230 - List of application See Table 2-6 above.
AP SP2+
software See also [A.3] for example.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 24
Checkpoint verification of computer-based systems
DNV ASDocumentation type Description Info Relevant safety profiles
also may be named as
master plan, a defined
procedure and plan for
I140 - Software quality plan software and system design AP SP2+
and development activities
during the vessel life cycle.
See also [A.4] for example.
Specification of the
responsible manufacturer for
each of the partial systems
I210 - Integration plan to be integrated in the total FI SP2+
integrated system.
See also [A.5] for example.
AP = for approval, FI = for information, SPn+ = SPn and higher levels.
The system integrator is mainly responsible to submit I030, I140 and I210 documents for the system of
systems under consideration within their scope of integration, but also responsible to submit I071 and I230
documents, based on inputs provided from the system suppliers.
See App.A for examples and explanations regarding the documentation.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 25
Checkpoint verification of computer-based systems
DNV ASSECTION 3 RECOMMENDED APPROACH
3.1 Hierarchical structure and levels
When the vessel is being delivered to the buyer, it always contains different systems structured in some
sort of architecture, even if this architecture is not always fully or consistently documented. One of the key
aspects of this RP is that the structural architecture is defined and managed throughout the project, involving
both the system integrator and the system supplier(s).
In order to describe the different parts that make up the computer based systems in a vessel, this RP defines
a hierarchical structure on the following levels:
1) System of systems (SoS): the systems that work together to provide a set of consistent ship functions,
sometimes encompassing all systems on-board, but may also be limited to bridge systems or machinery
systems.
2) Supplier's delivery scope: the whole scope of delivery from one particular supplier's perspective.
3) System (Sys): the system with sub-systems that implement one or more vessel function(s).
4) Interface (Int): the interconnection between two or more systems.
5) Computer node: a computer node usually including its hardware and software components.
6) Software (SW): the computer software components pertaining to the operation of a computer system.
7) Parameters (Par): the parameters or data used to configure/tailor a system or component to a specific
use or environment.
This RP focuses on five selected levels of the hierarchical structure above. The 'supplier's delivery scope' and
'computer node' levels are not defined with any checkpoints. See Figure 3-1 for an illustration.
Figure 3-1 The five levels in the hierarchical structure used in this RP
See [B.1] for details of definition and some examples.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 26
Checkpoint verification of computer-based systems
DNV AS3.2 Checkpoints definition
3.2.1 Checkpoints definition per phase
This RP defines all together twenty four checkpoints for all phases in a vessel's life cycle. A
checkpoint is a set of verification activities and questions for the different levels in the hierarchical structure
(see [3.2.2]), and per role in the project (see [3.2.3]).
Checkpoints are identified by the following two parts:
1) the hierarchical level that the checkpoint is placed at, and
2) a sequence number to provide an unique identification.
See Table 3-1 below for the format of checkpoint identification (ID).
Table 3-1 format of checkpoint identification
Newbuilding phases Operation phase
Checkpoint: ID = . Checkpoint: ID = .
where:
Level = one of the five levels in the hierarchical structure (SoS, Sys, Int, SW, Par)
n = sequence number (1-5).
The checkpoints are aggregated as a milestone checkpoint (MCP) for each phase in the vessel's life cycle:
1) MCP1 in basic engineering phase: 1 checkpoint.
2) MCP2 in engineering phase: 6 checkpoints.
3) MCP3 in construction phase: 3 checkpoints.
4) MCP4 in acceptance phase: 4 checkpoints.
5) MCP5 in operation phase: 3 checkpoints.
6) MCP6 in operation phase: 7 checkpoints.
For an overview of all checkpoints, per hierarchical level in the vessel newbuilding, see Figure 3-2, and
operation, see Figure 3-3, phases along the flow of time in the vessel's life cycle.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 27
Checkpoint verification of computer-based systems
DNV ASFigure 3-2 Overview of check points in the vessel new-building phases
Figure 3-3 Overview of check points in the vessel operation phase
The responsibility of each checkpoint of 'Who is responsible to do what?' follows the typical RACI
responsibility matrix, as also described in the following Table 3-2.
Recommended practice — DNV-RP-0582. Edition June 2021 Page 28
Checkpoint verification of computer-based systems
DNV ASTable 3-2 Responsibility matrix
ID Responsibility Description
Those who do the work to complete the task. There is at least one role with a
Responsible
R participation type of responsible, although others can be delegated to assist in the
(or recommender)
work required.
The one ultimately answerable for the correct and thorough completion of the
deliverable or task, the one who ensures the prerequisites of the task are met. An
A Accountable (or approver)
accountable shall sign off (approve) work that responsible provides. There shall be
only one accountable specified for each task or deliverable.
C Consulted (or consultant) Those whose opinions are sought, typically subject-matter experts.
Those who are kept up-to-date on progress, often only on completion of the task
I Informed (or informee)
or deliverable.
Table 3-3 to Table 3-8 defines the checkpoints per phase and MCP in the vessel's life cycle, see [2.1.1], with
also the RACI responsibilities for different roles, see [2.1.3].
Note:
It is the role with a 'R' responsibility who is responsible to perform the checkpoint, and make sure the checkpoint results are
logged in a unified way using the corresponding forms in [C.1].
---e-n-d---o-f---n-o-t-e---
Table 3-3 Definition of checkpoints for basic engineering phase: (MCP1) inputs frozen
Checkpoint
ID Checkpoint item IV SI OW SI
name
1) Have the overall scope and content of the system of
systems been defined and documented?
2) Has a cyber security policy been established for the
Overall scope
SoS.CP1 system of systems? A R I C
defined?
3) Is there a master plan for the development and
delivery of the total system of systems?
4) Have all stakeholders agreed to the plan?
Table 3-4 Definition of checkpoints for engineering phase: (MCP2) design frozen
Checkpoint
ID Checkpoint item OW SI SU IV
name
1) Have the requirements on the system been defined
and documented?
System
2) Have the requirements on the system been
Sys.CP1 requirements I A R
reviewed by the supplier and the system integrator
ready?
together?
3) Are all items from the review resolved?
1) Has the interface been identified and given a unique
name?
Interface
Int.CP1 2) Have the involved suppliers been notified? I R, A I
identified?
3) Which organization is responsible for detailing the
interface?
Recommended practice — DNV-RP-0582. Edition June 2021 Page 29
Checkpoint verification of computer-based systems
DNV ASCheckpoint
ID Checkpoint item OW SI SU IV
name
1) Has the software component been designed and
Software described?
SW.CP1 I R, A
design ready? 2) Are the appropriate design rules/guides followed in
the design?
Interface 1) Have all involved parties reviewed and agreed to the
Int.CP2 A R
details agreed? interface description?
1) Is the design of the system stable enough to
continue with the implementation?
System design
Sys.CP2 2) Are documents that makes up the design-baseline C R, A I
ready?
for the system listed?
3) Is the design-base considered complete?
1) Is the overall design describing how the different
systems are going to work together verified and
approved?
2) Have all interfaces between systems been
Overall design identified?
SoS.CP2 I R, A C I
ready? 3) Has the overall design been baselined and is put
under change control?
4) Have the mechanisms for information and document
been established between the system integrator and
each individual system supplier?
Table 3-5 Definition of checkpoints for construction phase: (MCP3) ready for FAT
Checkpoint
ID Checkpoint item OW SI SU IV
name
Key
1) Are the key parameters of the system described and
Par.CP1 parameters I C R, A
reviewed?
described?
1) Have all new and modified source code passed peer-
Software ready
review?
SW.CP2 for integration I I R, A
2) Are all parameters defined, described and reviewed?
into system?
3) Is the software reused? If yes, qualified?
1) Have all software components passed software CP2?
2) Have all internal tests been passed?
Ready for 3) Have the results of all internal verification activities
Sys.CP3 C A R A
system FAT? been evaluated and found satisfactory?
4) Has the FAT procedure been approved by the
system integrator and IV?
Recommended practice — DNV-RP-0582. Edition June 2021 Page 30
Checkpoint verification of computer-based systems
DNV ASYou can also read
