E22

E22
E22

(Dec
2006)
(cont)(Corr.1
Oct 2007)(Rev.1
Sept 2010)(Rev.2June 2016)(Rev.3June 2023)

On Board Use and Application ofComputer-based systems
1

Introduction

1.1

Scope

These requirements apply to design, construction, commissioning and maintenance ofcomputer-based systems where they depend on software for the proper achievement of theirfunctions. The requirements focus on the functionality of the software and on the hardware
supporting the software.
These requirements apply to systems which provide control, alarm, monitoring, safety, orinternal vessel communication functions that the use of computer-based systems which
provide control, alarm, monitoring, safety or internal communication functions which are
subject to classification requirements.
1.2

ExclusionComputer-based systems that are covered by statutory regulations are excluded from therequirements of this UR. Navigation systems required by SOLAS Chapter V, Radiocommunication systems required by SOLAS Chapter IV, and vessel loading
instrument/stability computer are not in the scope of this requirement.
Guidance:
Examples of such systems are navigation systems and radio communication system required
by SOLAS chapter V and IV, and vessel loading instrument/stability computer.
Note: For loading instrument/stability computer, IACS recommendation no. Rec No. 48 may
be considered.

Note:
1.
2.
3.
4.
5.

This UR is to be applied only to such systems on new ships contracted for construction
on and after 1 January 2008 by IACS Societies.
Rev.1 of this UR is to be applied only to such systems on new ships contracted forconstruction on and after 1 January 2012 by IACS Societies.
Rev.2 of this UR is to be applied only to such systems on new ships contracted forconstruction on and after 1 July 2017 by IACS Societies.
Rev.3 of this UR is to be applied to such systems on new ships contracted forconstruction on and after 1 July 2024 by IACS Societies and may be used for otherships as non-mandatory guidance.
The “contracted for construction” date means the date on which the contract to build thevessel is signed between the prospective owner and the shipbuilder. For further details
regarding the date of “contract for construction”, refer to IACS Procedural Requirement(PR) No. 29.
Page 1 of 32

IACS Rev.3 2023

E22

E22

(cont)

1.3
1.3.1

References
Normative standards

For the purposes of this UR, the following standards are normative:-

IACS UR E10 Test specification for type approval-

IACS UR E26 Cyber resilience of ships-

IACS UR E27 Cyber resilience of on-board systems and equipment

1.3.2

Informative standards

For the purposes of this UR, the following standards are listed for information and may be
used for the development of hardware/software of computer-based systems:-

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

ISO/IEC 12207:2017 Systems and software engineering – Software life cycle processes-

ISO 9001:2015 Quality Management Systems – Requirements-

ISO/IEC 90003:2018 Software engineering - Guidelines for the application of ISO
9001:2015 to computer software-

IEC 60092-504:2016 Electrical installations in ships - Part 504: Special features Control and instrumentation-

ISO/IEC 25000:2014 Systems and software engineering - Systems and software
Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE-

ISO/IEC 25041:2012 Systems and software engineering - Systems and software
Quality Requirements and Evaluation (SQuaRE) - Evaluation guide for developers,
acquirers and independent evaluators-

IEC 61511:2016 Functional safety - Safety instrumented systems for the processindustry sector-

ISO/IEC 15288:2015 Systems and software engineering - System life cycle process-

ISO 90007:2017 Quality management – Guidelines for configuration management-

ISO 24060:2021 Ships and marine technology - Ship software logging system for
operational technology

Other industry standards may also be considered.For the purpose of application of this UR,
the following identified standards can be used for the development of hardware/software ofcomputer-based systems. Other industry standards may be considered:Page 2 of 32

IACS Rev.3 2023

E22

E22

(cont)

1.4

Structure

The general certification requirements for computer-based systems and the relation to typeapproval is described in paragraph 2. The requirements and extent of verification of acomputer-based system depends on its categorization into one of three categories. The
categories are described in paragraph 3.
The requirements of this UR cover the lifecycle of computer-based system from design
through operations. The requirements are split into groups representing the different phasesof the life cycle and the roles responsible for fulfilling the requirements.
The activities related to the development and delivery of a computer-based system is
described in paragraph 4, while the activities related to the maintenance in the operational
phase are described in paragraph 5.
Management of changes to software and systems is given special attention in this UR, andthe main aspects of a management of change process are described in paragraph 6.
Most requirements in this UR are related to the way of working, and thus focus on activities tobe performed, but it also contains some technical requirements. The technical requirementson computer-based systems have been gathered in paragraph 7.
Each activity contains a requirement part which describes the minimum requirements on therole in question, and a part which describes the Class Society’s verification of the activity inquestion.
1.5

Definition of abbreviations and terminology

1.5.1 Abbreviations
Table 1 Abbreviations
Abbreviation:
Cat I
Cat IICat III
COTS
FAT
FMEA
IT
OT
PMS
SAT
SOST
SSLS
UR

Expansion:
Category one systems as defined in paragraph 3.1
Category two systems as defined in paragraph 3.1
Category three systems as defined in paragraph 3.1
Commercial off-the-shelf
Factory acceptance test
Failure mode and effect analysis
Information technology
Operational technology
Planned maintenance system
System acceptance test
System of systems test
Ship software logging system
Unified requirement

Page 3 of 32

IACS Rev.3 2023

E22

E22

1.5.2 Terminology(cont)

Table 2 Terminology
Term:Black-box description
Black-box test methods

Computer-based system(CBS)

Failure mode description

Owner

Parameterization

Programmable device
Robustness
Service supplier

Simulation test

Definition:
A description of a system’s functionality and behaviour andperformance as observed from outside the system in question
Verification of the functionality, performance, and robustnessof a system, sub-system or component by only manipulating
the inputs and observing the outputs. This does not require
any knowledge of the system’s inner workings and focuses
only on the observable behaviour of the system/component
under test in order to achieve the desired level of verification.
A programmable electronic device, or interoperable set ofprogrammable electronic devices, organized to achieve one ormore specified purposes such as collection, processing,maintenance, use, sharing, dissemination, or disposition of
information. CBSs onboard include IT and OT systems. A CBS
may be a combination of subsystems connected via network.
Onboard CBSs may be connected directly or via public meansof communications (e.g. Internet) to ashore CBSs, othervessels’ CBSs and/or other facilities.
A document describing the effects due to failures in thesystem, not failures in the equipment supported by the system.
The following aspects shall be covered:- list of failures which are subject to assessment, with- description of the system response to each of the above
failures- comments to the consequence of each of these failures
The organization or person which orders the vessel in theconstruction phase or the organization which owns or
manages the vessel in service.
In the context of this UR this is a defined role with specificresponsibilities.
To configure and tune system and software functionality bychanging parameters. It does not usually require-computer
programming and is normally done by the system supplier or aservice provider, not the operator or end-user.
Physical component where software is installed
The ability to respond to abnormal inputs and conditions
A person or company, not employed by an IACS
Member, who at the request of an equipment manufacturer,
shipyard, vessel’s owner or other client acts in connection withinspection work and provides services for a ship or a mobile
offshore unit such as measurements, tests or maintenance ofsafetysystems and equipment, the results of which are used bysurveyors in making decisions affecting classification or
statutory certification and services
Monitoring, control, or safety system testing where theequipment under control is partly or fully replaced withsimulation tools, or where parts of the communication networkand lines are replaced with simulation tools.
Page 4 of 32

IACS Rev.3 2023

E22

E22

(cont)Term:
Society Certificate

Software component
Software master files

Software-structure
Sub-system
Supplier
SystemSystem of systems

System supplier

Systemss integrator

Type approval Certificate
VesselDefinition:
Compliance document issued by a Class Society stating:- conformity with applicable rules and requirements.
- that the tests and inspections have been carried out on:- the finished certified component itself; or- on samples taken from earlier stages in the production of thecomponent, when applicable.
- that the inspection and tests were performed in the presenceof the Surveyor or in accordance with special agreements, i.e.
Alternative Certification Scheme (ACS)A standalone piece of code that provides specific and closely
coupled functionality.
The computer-files that constitutes the original source of thesoftware. For custom made software this may be readable
source- code files, and for COTS software it may be different
forms of binary files.
Overview of how the different software components interact
and is commonly referred to as the Software Architecture, orSoftware Hierarchy
Identifiable part of a system, which may perform a specificfunction or set of functions.
A generic term used for any organisation or person that is acontracted or a subcontracted provider of services, systemcomponents, or software.
A combination of components, equipment and logic which has
a defined purpose, functionality, and performance.
In the context of this UR, a specific system is delivered by one
system supplier.
A system which is made up of several systems,
In the context of this UR, the system of systems encompasses
all monitoring, control and safety systems delivered from the
Shipyard as a part of a vessel
An organisation or person that is contracted or a
subcontracted provider of system components or software
under the coordination of the Systems integrator. In thecontext of this UR this is a defined role with specificresponsibilities.
Single organization or a person coordinating interaction
between suppliers of systems and sub-systems on all stagesof life cycle of computer-based systems in order to integratethem into a verified vessel-wide system of systems and toprovide proper operation and maintenance of the computerbased systems. In the context of this UR this is a defined rolewith specific responsibilities.
During the design and delivery phase the Shipyard is thedefault Systems integrator, during operations phase the Owneris the default.
Compliance document issued by a Class Society by which theSociety declares that a product design meets a minimum set oftechnical requirements
Ship or offshore unit where the computer-based system is to
be installed.
Page 5 of 32

IACS Rev.3 2023

E22

E22

(cont)

VesselSystemSystemSub-System

ProgrammabledeviceSub-System
ProgrammabledeviceSoftware module

Software module

Software module

Software module

Note: dashed lines show non-developed branches of diagram

Figure 1 - Illustrative System Hierarchy

Page 6 of 32

IACS Rev.3 2023

E22

E22

(cont)

2.

Definition

2.1

Stakeholders

2.1.1

Owner

The Owner is responsible for contracting the system integrator and/or suppliers to provide a
hardware system including software according to the owner’s specification. The Owner could
be the Ship Builder Integrator (Builder or Shipyard) during initial construction. After vesseldelivery, the owner may delegate some responsibilities to the vessel operating company.
2.1.2

System integrator

The role of system integrator shall be taken by the yard unless an alternative organisation is
specifically contracted/assigned this responsibility. The system integrator is responsible forthe integration of systems and products provided by suppliers into the system invoked by therequirements specified herein and for providing the integrated system. The system integrator
may also be responsible for integration of systems in the vessel.
If there are multiple parties performing system integration at any one time a single party is tobe responsible for overall system integration and coordinating the integration activities. If
there are multiple stages of integration different System Integrators may be responsible for
specific stages of integration but a single party is to be responsible for defining andcoordinating all of the stages of integration.
2.1.3

Supplier

The Supplier is any contracted or subcontracted provider of system components or software
under the coordination of the System Integrator or Shipyard. The supplier is responsible forproviding programmable devices, sub-systems or systems to the system integrator. The
supplier provides a description of the software functionality that meets the Owner’s
specification, applicable international and national standards, and the requirements specified
herein.
2.2

Objects

The following diagram (Figure 1) shows the hierarchy and relationships of a typical computerbased system.
2.2.1

Object definitions

2.2.1.1 Vessel
Ship or offshore unit where the system is to be installed.

Page 7 of 32

IACS Rev.3 2023

E22

E22

(cont)

2.2.1.2 System
Combination of interacting programmable devices and/or sub-systems organized to achieve
one or more specified purposes.
2.2.1.3 Sub-system
Identifiable part of a system, which may perform a specific function or set of functions.
2.2.1.4 Programmable device
Physical component where software is installed.
2.2.1.5 Software module
A module is a standalone piece of code that provides specific and closely coupledfunctionality.
2

Approval of system and components

2.1

System certification

Computer-based systems that are necessary to accomplish vessel-functions of category II or
category III (as defined in paragraph 3.1 below) shall be delivered with a vessel-specificSociety certificate. The objective of the vessel-specific system certification is to confirm thatdesign and manufacturing of the system has been completed and that the system complies
with applicable rules of the classification Society.
Vessel-specific system certification consist of two main verification activities:
1)

Assessment of vessel-specific documentation(see paragraph 4.2 and paragraph 6)

2)

Survey and testing of the system to be delivered to the vessel (see paragraph 4.2.7)

The classification Society may accept Alternative Certification Scheme (ACS) provided thatthe requirements are met, and that the system is provided with a vessel-specific certificate.
2.2Type approval of computer-based systems

Computer-based systems that are routinely manufactured and include standardized software
functions may be type approved in accordance with specified rules of the classification
Society. Hardware shall be documented according to the requirement in paragraph 4.2.4.
The type approval consist of two main verification activities:
1)

Assessment of type-specific documentation

2)

Survey and testing of the standardized functions
Page 8 of 32

IACS Rev.3 2023

E22

E22

(cont)

Type approval will normally not yield exemption from vessel-specific system certification sincevessel-specific functions, parameter configurations and installation elements demand vesselspecific verification.

3

2.3 System categories

3.1

System category definitions

The categorization of a system in the context of this UR is based on the potential severity of
the consequences if the system serving the function fails. Table 3 provides the definitions of
the categories The following table (Table 1) shows how to assign system categories based on
their effects on system functionality.
Table 3 1 System categories
Category: Failure effects:
I
Those systems, failure of which
will not lead to dangerous
situations for human safety,
safety of the vessel and/or threat
to the environment.
II
Those systems, failure of which
could eventually lead todangerous situations for humansafety, safety of the vessel
and/or threat to the environment.

III

3.2

Typical System functionality:
Monitoring, informational andadministrative functions Monitoring
function for informational/
administrative tasks-

Alarm and monitoring functions
Control functions which arenecessary to maintain the ship in its
normal operational and habitableconditions
Vessel alarm, monitoring and control
functions which are necessary tomaintain the vessel in its normal
operational and habitable conditions

Those systems, failure of which
could immediately lead todangerous or catastrophic
situations for human safety,
safety of the vessel and/or threat
to the environment.

Control functions for maintaining thevessel’s propulsion and steering
Vessel safety functions

Class Societies’ scope

Category I systems are normally not subject to verification by the Class society, as failure ofthese systems shall not lead to dangerous situations. However, information pertinent tocategory I systems shall be required upon request to determine the correct category or
ensure that they do not influence the operation of systems in category II and category III.
3.3

System category examples

The category of a system shall always be evaluated in the context of the specific vessel inquestion; thus, the categorization of a system may vary from one vessel to the next. This

Page 9 of 32

IACS Rev.3 2023

E22

E22

(cont)

means that the examples of categories below are given as guidance only. For determining
the categorization of systems for a specific vessel, see paragraph 4.3.3.
Examples of category I systems:
Fuel monitoring system, maintenance support system, diagnostics and troubleshooting
system, closed circuit television, cabin security, entertainment system, fish detection system.
Examples of category II systems:
Fuel oil treatment system, alarm and monitoring and safety systems for propulsion andauxiliary machinery, Inert gas system, control, monitoring and safety system for cargocontainment system.
Examples of category III systems:
Propulsion control system, steering gear control system, electric power system (including
power management system), dynamic positioning system (IMO classes 2 and 3).
The list of example systems is not exhaustive.
The following systems typically belong to Category III, the exact category being dependent on
the risk assessment for all operational scenarios:-

Propulsion system of a ship, meaning the means to generate and control mechanicalthrust in order to move the ship (devices used only during manoeuvring are not in thescope of this requirement such as bow tunnel thrusters)-

Steering system control system-

Electric power system (including power management system)-

Ship safety systems covering fire detection and fighting, flooding detection and fighting,internal communication systems involved in evacuation phases, ship systems involvedin operation of life saving appliances equipment-

Dynamic positioning system of equipment classes 2 and 3 according to IMO
MSC/Circ.645-

Drilling systems

The following systems typically belong to Category II, the exact category being dependent on
the risk assessment for all operational scenarios:-

Liquid cargo transfer control system-

Bilge level detection and associated control of pumps-

Fuel oil treatment system-

Ballast transfer valve remote control system-

Stabilization and ride control systems-

Alarm and monitoring systems for propulsion systems

The example systems are not exhaustive.

Page 10 of 32

IACS Rev.3 2023

E22

E22

(cont)

2.4
2.4.1

Other terminology
Simulation tests

Control system testing where the equipment under control is partly or fully replaced withsimulation tools, or where parts of the communication network and lines are replaced withsimulation tools.
4

Requirements for software and supporting hardware Requirements ondevelopment and certification of computer-based system

4.1

General requirements

4.1.1

Life cycle approach with appropriate standards

Requirement:
A global top-down approach shall be undertaken in the design and development of both
hardware and software and the integration in sub-systems, systems, and system of systems,
spanning the complete system lifecycle. This approach shall be based on the standards aslisted herein or other standards recognized by the Class Society.
Class Society’s verification:
This is verified by the Class Society as a part of the quality management system verification
described in paragraph 4.1.2.
A global top to bottom approach shall be undertaken regarding software and the integration ina system, spanning the software lifecycle. This approach shall be accomplished according tosoftware development standards as listed herein or other standards recognized by the Class
Society.
4.1.2

Quality management system

Systems integrators and system suppliers shall in the development of computer-based
systems for category II and category III, comply to a recognised quality standard such as ISO
9001; also incorporating principles of IEC/ISO 90003.
The quality management system shall as a minimum include the following topics, applicablefor both category II and category III systems:operate a quality system regarding softwaredevelopment and testing and associated hardware such as ISO 9001 taking into account ISO
90003.
Table 4 Quality management system
Area
#

Topic

1

Responsibilities and competency of the staff.
The complete lifecycle of delivered software and of
associated hardware
Specific procedure for unique identification of acomputer-based system, it’s components andversions.

2
3

Page 11 of 32

Systemsupplierxx

Role
Systems
integratorxxx

IACS Rev.3 2023

E22

E22

Area
#

(cont)

4
5
6
7
8
9
10
11
12
13
14
15

Topic
Creation and update of the vessel’s systemarchitecture
Organization set in place for acquisition of softwareand related hardware from suppliers
Organization set in place for software code writing
and verification
Organization set in place for system validation
before integration in the vessel
Specific procedure for conducting and approving ofsystems at FAT and SAT
Creation and update of system documentation
Specific procedure for software modification andinstallation on board the vessel, includinginteractions with shipyard and ownerSpecific procedures for verification of software code
Procedures for integrating systems with othersystems and testing of the system of systems for thevessel
Procedures for managing changes to software andconfigurations before FATProcedures for managing and documenting changes
to software and configurations after FAT
Checkpoints for the organization’s own follow-up ofadherence to the quality management system

Systemsupplier

Role
Systems
integrator
x

x

x

x
x
x

x

x
x

x

x
x

x

x
x

x

x

x

Class Society’s verification:
The quality management system may be verified by two alternative means:
1)
2)

The Class Society confirming that the quality management system is certified ascompliant to a recognized standard by an organisation with accreditation under anational accreditation scheme.
The Class Society confirming compliance to a standard through a specific assessmentof the quality management system. The documentation requirements will be defined per
case.

Satisfaction of this requirement shall be demonstrated by either:-

The quality system being certified as compliant to the recognized standard by anorganisation with accreditation under a national accreditation scheme, or-

The Class Society confirming compliance to the standard through a specificassessment.

Requirements on the system supplier: This quality system shall include:
3.1.1.1 Relevant procedures regarding responsibilities, system documentation, configuration
management and competent staff.
3.1.1.2 Relevant procedures regarding software lifecycle and associated hardware:
Page 12 of 32

IACS Rev.3 2023

E22

E22

(cont)-

Organization set in place for acquisition of related hardware and software fromsuppliers
Organization set in place for software code writing and verification
Organization set in place for system validation before integration in the vessel

3.1.1.3 Minimum requirements for approval of Quality system:-

Having a specific procedure for verification of software code of Category II and III at thelevel of systems, sub-systems and programmable devices and modules
Having check points for the Class Society for Category II and III systems (see Annex forthe minimum check points1)
Having a specific procedure for software modification and installation on board thevessel defining interactions with owners

4.2
4.2.1

Quality Plan Define and follow a quality plan

Requirement:
The system supplier shall document that the quality management system is applied for thedesign, construction, delivery, and maintenance of the specific system to be delivered.
All applicable items described in paragraph 4.1.2 (for the system supplier role) shall bedemonstrated to exist and being followed, as relevant.
Class Society’s verification:
Category I: No documentation required
Category II and III: The quality plan shall be available during survey (FAT) or submitted for
information upon request (FI).
A document, referred to herein as a Quality Plan, shall be produced that records how thequality management system will be applied for the specific computer-based system and that
includes, as a minimum, all of material required by paragraphs 3.1.1.1 to 3.1.1.3 inclusively.
4.2.2

Unique identification of systems and software

Requirement:
A method for unique identification of a system, its different software components and different
revisions of the same software component shall be applied.
The method shall be applied throughout the lifecycle of the system and the software.
See also paragraph 7.1 for related technical requirements on the system in question.
The documentation of the method is typically a part of the quality management system, seeparagraph 4.1.2.
Class Society’s verification:
Category I: Not required
Category II and III: Application of the identification system is verified as a part of the FAT(paragraph 4.2.7) and SAT (paragraph 4.3.6)
4.2.3

System description

Requirement:

Page 13 of 32

IACS Rev.3 2023

E22

E22

(cont)The system’s specification and design shall be determined and documented in a systemdescription. In addition to serve as a specification for the detailed design and implementation,
the purpose of the system description is to document that the entire system-delivery isaccording to the specifications and in compliance with applicable rules and regulations.
The system description shall contain information of the following:•

Purpose and main functions, including any safety aspects•

System category as defined•

Key performance characteristics•

Compliance with the technical requirements and Class Society rules•

User interfaces/mimics•

Communication and Interface aspectso•Identification and description of interfaces to other vessel systems

Hardware-arrangement related aspects:
o
o
o
o
o

Network-architecture/topology, including all network components likeswitches, routers, gateways, firewalls etc.
Internal structure with regards to all interfaces and hardware nodes in thesystem (e.g. operator stations, displays, computers, programmable devices,sensors, actuators, I/O modules etc)
I/O allocation (mapping of field devices to channel, communication link,
hardware unit, logic function)
Power supply arrangement
Failure mode description

Guidance:
The information listed above is in this UR collectively referred to as the system description. It
may however be divided into a number of different documents and models.
Class Society’s verification:
Category I: The system description documentation shall upon request be submitted for
information (FI).
Category II and III: The system description documentation shall be submitted for approval
(AP).
4.2.4

Environmental compliance of hardware components

Requirement:
Evidence of environmental type testing according to IACS UR E10 regarding hardware
elements included in the system and sub-systems shall be submitted to the Class Society.
Class Society’s verification:
Category I: This requirement is not mandatory for category I systems. Reference to Typeapproval certificate or other evidence of type testing shall upon request be submitted for
information (FI) see paragraph 3.2.
Category II and III: Reference to Type approval certificate or other evidence of type testing
shall be submitted for information (FI).
Page 14 of 32

IACS Rev.3 2023

E22

E22

(cont)

4.2.5

Software code creation, parameterization, and testing

Requirement:
The software created, changed, or configured for the delivery project shall be developed andhave the quality assurance activities assessed according to the selected standard(s) as
described in the quality plan.
The quality assurance activities may be performed on several levels of the software-structureand shall include both custom-made software and configured components (e.g. software
libraries) as appropriate.
The verification of the software shall as a minimum verify the following aspects based onblack-box methods:•

Correctness, completeness and consistency of any parameterization andconfiguration of software components•

Intended functionality•

Intended robustness

For components in systems of Category II and III, the scope, purpose, and results of all
performed reviews, analyses, tests, and other verification activities shall be documented in
test reports.
Guidance:
Some of the methods utilized in this activity are sometimes referred to as “software unit test”
or “developer test” and may also include verification methods like code-reviews and static- or
dynamic code analysis.
Class Society’s verification:
Category I: No documentation required
Category II and III: Software test reports shall upon request be submitted for information (FI).
4.2.6Internal system testing before FAT

Requirement:
The system shall as far as practicable be tested before the FAT. The main purpose of thesystem test is for the system supplier to verify that the entire system delivery is according to
the specifications, approved documentation and in compliance with applicable rules andregulations; and further, that the system is completed and ready for the FAT.
The testing shall at least verify the following aspects of the system:•

Functionality•

Effect of faults and failures (including diagnostic functions, detection, alerts
response)•

Performance•

Integration between software and hardware components•

Human-machine interfaces
Page 15 of 32

IACS Rev.3 2023

E22

E22

(cont)•

Interfaces to other systems

Faults are to be simulated as realistically as possible to demonstrate appropriate system fault
detection and system response.
Some of the testing may be performed by utilizing simulators and replica hardware.
The test-environment shall be documented, including a description of any simulators,
emulators, test-stubs, test-management tools, or other tools affecting the test environment
and its limitations.
Test cases and test results shall be documented in test programs and test reports
respectively.
Class Society’s verification:
Category I: No documentation required
Category II and III: Internal system test report shall be made available during FAT or
submitted upon request (FI)
4.2.7

Factory acceptance testing (FAT) before installation on board

Requirement:
A factory acceptance test (FAT) shall be arranged for the system in question. The main
purpose of the FAT is to demonstrate to the Class Society that the system is completed andcompliant with applicable classification rules, thus enabling issuance of a Society Certificate
for the system.
The FAT test program shall cover a representative selection of the test items from the internal
system test (described in paragraph 4.2.6 ), including normal system functionality andresponse to failures.
For category II and III systems, network testing to verify the network resilience requirementsin paragraph 7.2.1 shall be performed. If agreed by all parties, the network testing may be
performed as a part of the system test onboard the vessel.
The FAT shall as a rule be performed with the project specific software operating on theactual hardware components to be installed on board, with necessary means for simulation offunctions and failure responses, however other solutions such as replica hardware or
simulated hardware (emulators) may be agreed with the Class Society.
For each test-case it shall be noted if the test passed or failed, and the test-results shall be
documented in a test report. The test report shall also contain a list of the software (including
software versions) that were installed in the system when the test was executed.
Guidance:
For complex systems there may be a large difference in scope between the “Internal system
testing before FAT” activity and the FAT, while for some systems the scope may be identical.
Class Society’s verification:
Category I: FAT not required.
Category II and III: The FAT program shall be approved (AP) before the test is executed.
The FAT execution shall be witnessed by the Class Society.
The FAT report shall be submitted for information (FI).
Additional FAT documentation including e.g., user manuals and internal system test reportshall be made available during FAT or submitted upon request for information (FI).
Page 16 of 32

IACS Rev.3 2023

E22

E22

(cont)

4.2.8

Secure and controlled software installation on the vessel

Requirement:
The initial installation and subsequent updates of the software components of the systemshall be done according to a management of change procedure which has been agreed
between the system supplier and the systems integrator.
The management of change procedure shall comply with the requirements in paragraph 6.
Cyber security measures shall be observed as described in relevant IACS URs.
Class Society’s verification:
Category I: Not required
Category II and III: The management of change procedure shall upon request be submitted
for information (FI).
4.3
4.3.1

Requirements on the systems integrator
Responsibilities

For the purposes of this UR, the Shipyard is considered as the systems integrator in thedevelopment and delivery phase unless another organization or person is explicitly appointed
by the Shipyard.
4.3.2

Define and follow a quality plan

Requirement:
The systems integrator shall document that the quality management system is applied for the
installation, integration, completion, and maintenance of the systems to be installed on board.
All applicable items described in paragraph 4.1.2 (for the systems integrator role) shall bedemonstrated to exist and being followed, as relevant.
Class Society’s verification:
Category I: No documentation required
Category II and III: The quality plan shall be made available during survey (at SAT/SOST) or
upon request submitted for information (FI).
4.3.3

Determining the category of the system in question

Requirement:
For each system delivery to a particular vessel, it shall be decided which category the systemfalls under based on the failure effects of the system (as defined in paragraph 3). The
category for a specific system must be conveyed to the relevant system supplier. The Class
Society may decide that a risk-assessment is needed to verify the proper system category.
Class Society’s verification:
Category I, II and III: The category for the different systems shall upon request be
documented and submitted for approval (AP).
3.1.2

Design phase

4.3.4

3.1.2.1Risk assessment of the system

Page 17 of 32

IACS Rev.3 2023

E22

E22

(cont)

Requirement:
If requested by the Class Society, a risk assessment of a specific system in context of thespecific vessel in question shall be performed and documented in order to determine theapplicable category for the system.
Guidance:
IEC/ISO31010 “Risk management - Risk assessment techniques” may be used as guidancein order to determine method of risk assessment.
Class Society’s verification:
Category I, II and III: The risk assessment report shall upon request be submitted for approval
(AP).
4.3.5

Define the vessel’s system-architecture

Requirement:
The system of systems (SoS) shall be specified and documented. This architecture
specification provides the basis for category determination and development of the different
integrated systems by allocating functionality to individual systems and by identifying themain interfaces between the systems. It shall also serve as a basis for the testing of theintegrated systems on the vessel level (see paragraph 4.3.7).
The vessel’s system architecture shall at least contain description of:•

Overview of the total systems architecture (the system of systems)•

Each system’s purpose and main functionality•

Communication and interface aspects between different systems

Guidance:
See also UR E26 for diagram of security zones and conduitsClass Society’s verification:
Category I, II, and III: The vessel’s system architecture shall upon request be submitted for
information (FI).
4.3.6

System acceptance test (SAT) onboard the vessel

Requirement:
A system acceptance test shall be arranged onboard the vessel. The main purpose of thesystem acceptance test (SAT) is to verify the system functionality, after installation andintegration with the applicable machinery/electrical/process systems on board including
possible interfaces with other control and monitoring systems.
For each test-case it shall be noted if the test passed or failed, and the test-results shall be
documented in a test report. The test report shall also contain a list of the software (including
software versions) that were installed in the system when the test was executed.
Class Society’s verification:
Category I: Not required.
Category II and III: The SAT program shall be submitted for approval (AP) before the test is
executed.

Page 18 of 32

IACS Rev.3 2023

E22

E22

(cont)The SAT execution shall be witnessed by the Class Society.
The SAT report shall be submitted for information (FI).
4.3.7

Testing of integrated systems on vessel-level (SOST)

Requirement:
Integration tests shall be conducted after installation and integration of the different systems
in its final environment on board. The purpose of the tests is to verify the functionality of thecomplete installation (system of systems) including all interfaces and inter-dependencies incompliance with requirements and specifications.
The testing shall at least verify the following aspects of the system of systems:•

The overall functionality of the interacting systems as a whole•

Failure response between systems•

Performance•

Human-machine interfaces•

Interfaces between the different systems

Guidance:
For complex systems there may be a large difference in scope between the “System
acceptance test (SAT) onboard the vessel” activity and the SOST, while for some systems
the scope may be overlapping or identical. It is possible to combine the two activities into one
when the test scope is similar.
Class Society’s verification:
Category I: Not required.
Category II and III: The SOST program shall submitted for approval (AP) before the test is
executed.
The SOST execution shall be witnessed by the Class Society.
The SOST report shall be submitted for information (FI).
4.3.8

Change management

The systems integrator shall follow procedures for management of change to the system as
described in paragraph 6 .
Class Society’s verification:
Category I: No documentation requirements
Category II and III: The management of change procedure shall upon request be submitted
for information (FI).
This step shall be undertaken to determine the risk to the system throughout the lifecycle byidentifying and evaluating the hazards associated with each function of the system. A risk
assessment report shall upon request be submitted to the Class Society:This document shall normally be submitted by the System Integrator or the Supplier, including
data coming from other suppliers.

Page 19 of 32

IACS Rev.3 2023

E22

E22

(cont)

IEC/ISO31010 “Risk management - Risk assessment techniques” may be applied in order todetermine method of risk assessment. The method of risk assessment shall be agreed by thesociety.
Based on the risk assessment, a revised system category might need to be agreed between
Class and the system supplier.
Where the risks associated with a computer-based system are well understood, it ispermissible for the risk assessment to be omitted, however in such cases the supplier or thesystem integrator shall provide a justification for the omission. The justification should giveconsideration to:-

How the risks are known

The equivalence of the context of use of the current computer-based system and thecomputer-based system initially used to determine the risks-

The adequacy of existing control measures in the current context of use

Examples of check points can be a required submittal of documentation, a test event, atechnical design review meeting, or peer review meeting.
1

3.1.2.2 Code production and testing
The following documentation shall be provided to the Class Society for Category II and III
systems:
Software modules functional description and associated hardware description forprogrammable devices. This shall be provided by Supplier and System Integrator.
Evidence of verification (detection and correction of software errors) for softwaremodules, in accordance with the selected software development standard. Evidence
requirements of the selected software standard might differ depending on how critical thecorrect operation of the software is to the function it performs (i.e. IEC 61508 has different
requirements depending on SILs, similar approaches are taken by other recognized
standard). This shall be supplied by the Supplier and System Integrator.
Evidence of functional tests for programmable devices at the software module, subsystem, and system level. This shall be supplied by the Supplier via the System Integrator.
The functional testing shall be designed to test the provisions of features used by thesoftware but provided by the operating system, function libraries, customized layer ofsoftware and any set of parameters.
5

Requirements on maintenance of computer-based systems

5.1

Requirements on the Vessel Owner

5.1.1

Responsibilities

For the purposes of this UR, the vessel owner is considered to be the systems integrator in
the operations phase unless another organization or person is explicitly appointed by theowner.
Page 20 of 32

IACS Rev.3 2023

E22

E22

(cont)

Accordingly, the Class Society shall in a timely manner be informed by the owner about theappointed systems integrator which is responsible for implementing any changes to thesystems in conjunction with system supplier(s).
5.2
5.2.1

Requirements on the Systems integrator
Change management

Requirement:
The systems integrator shall ensure that necessary procedures for software and hardware
change management exist on board, and that any software modification/upgrade are
performed according to the procedure(s). For details about change management please seeparagraph 6 .
Changes to computer-based systems in the operational phase shall be recorded.
The records shall contain information about the relevant software versions and other relevant
information as described in paragraph 6.11 .
Class Society’s verification:
Category I: No documentation requirements
Category II and III: See paragraph 6.12 .
5.3
5.3.1

Requirements on the System Supplier
Change management

Requirement:
The system supplier shall follow procedures for maintenance of the system including
procedures for management of change as described in paragraph 6.
Class Society’s verification:
Category I: No documentation requirements
Category II and III: See paragraph 6.12 .
5.3.2

Testing of changes before installation onboard

Requirement:
The system supplier shall make sure that the planned changes to a system have passed
relevant in-house tests before the change is made to systems on board.
Class Society’s verification:
Category I: No documentation requirements
Category II and III: See paragraph 6.12 .
3.1.3

Integration testing before installation on board

6

Management of change

6.1

GeneralParagraph 6 provides requirements for the management of change throughout the lifecycle ofa computer-based system. Different procedures for the management of change may be

Page 21 of 32

IACS Rev.3 2023

E22

E22

(cont)

defined for specific phases in a system’s lifecycle as the different phases typically involve
different stakeholders. The Class Society’s verification is described in paragraph 6.12.
6.2

Documented change management procedures

Requirement:
The organization in question shall have defined and documented change management
procedures applicable for the computer-based system in question covering both hardware
and software. After FAT, the system supplier shall manage all changes to the system inaccordance with the procedure. Examples could be qualification of new versions of acquired
software, new hardware, modified control logic, changes to configurable parameters.
The procedure(s) shall at least describe the activities listed in paragraphs 6.3 through 6.11.
The outcome of the impact analysis in 6.8 will determine to what extent the activities in 6.3 to
6.12 shall be performed. Change records (described in paragraph 6.11) shall always be
produced.
6.3

Agreement between relevant stakeholders

Requirement:
The management of change process shall be coordinated and agreed between the relevant
stakeholders along the different stages of the lifecycle of the computer-based system.
Guidance:
Typically, the management of change address at least three different stages:

6.4•

Development and internal verification before FAT; involving the system supplier andsub-suppliers.

•

From FAT to handover of the vessel to the owner; involving the system supplier, thesystems integrator, the Class Society, and the owner.

•

In operation; involving the system supplier, service suppliers, the owner, and theClass Society

Approved software shall be under change management

Requirement:
If changes are required to a system after it has been approved by applicable stakeholders(typically the systems integrator and the Class Society at FAT) the modifications shall follow
defined change management procedures.
6.5

Unique identification of system and software versions

Requirement:
The system supplier shall make sure that each system and software version is uniquely
identifiable, see paragraph 4.2.2.
6.6

Handling of software master files

Requirement:
There shall be defined mechanisms for handling of the files that constitutes the master-files
for a software component. Personnel authorities shall be clearly defined along with the tools
and mechanisms used to ensure the integrity of the master files.
Page 22 of 32

IACS Rev.3 2023

E22

E22

(cont)

6.7

Backup and restoration of onboard software

Requirement:
It shall be clearly defined how to perform backup and restoration of the software components
of a computer-based system onboard the vessel.
6.8

Impact analysis before change is madeRequirement:
Before a change to the system is made, an impact analysis shall be performed in order to:•

Determine the criticality of the change.

•

Determine the impact on existing documentation.

•

Determine the needed verification and test activities.

•

Determine the need to inform other stakeholders about the change.

•

Determine the need to obtain approval from other stakeholders (e.g. Class Society
and or Owner) before the change is made.

6.9

Roll-back in case of failed software changes

Requirement:
When maintenance includes installation of new versions of the software in the system, it shallbe possible to perform a rollback of the software to the previous installed version with the
purpose of returning the system to a known, stable state.
Roll-backs shall be documented and analysed to find and eliminate the root cause.
6.10 Verification and validation of system changes
Requirement:
To the largest degree practically possible, modifications shall be verified before being
installed onboard.
After installation, the modification(s) shall be verified onboard according to a documented
verification program containing:•

Verification that the new functionalities and/or improvements have had the intended
effect.

•Regression test to verify that the modification has not had any negative effects on
functionality or capabilities that was not expected to be affected.

6.11 Change records
Changes to systems and software shall be documented in change records to allow for
visibility and traceability of the changes. The change records shall contain at least thefollowing items:•

The purpose for a change

Page 23 of 32

IACS Rev.3 2023

E22

E22

(cont)•A description of the changes and modifications•

The main conclusions from the impact analysis (see paragraph 6.8)•

The identity and version of any new system or software version(s)(see paragraph 6.5)•

Test reports or tests summaries (see paragraph 6.10)

Documentation of the changes to software may be recorded in the planned maintenancesystem (PMS), in a software registry or equivalent.
6.12 Verification of change management by the Class Society
6.12.1

In operation (vessel in service) phase

The verification by the Class Society regarding the management of change in operation is
generally performed during the annual survey of the vessel. Procedures for management ofchange and relevant change records (see paragraph 6.11) shall be made available at thetime of survey.
In the cases where the change requires approval from the Class Society up front, the relevant
procedures and documentation for the change in question may be verified at that time.
6.12.2

During newbuilding

The verification of management of change in the newbuilding phase is divided into two;
Procedures are verified as a part of the verification of the quality management system(paragraph 4.1.2), while project specific implementation of the procedures are verified during
FAT (4.2.7) and after FAT (6.12.1)
7

Technical requirements on computer-based systems

The paragraphs below contain technical requirements on computer-based systems. The
compliance to these requirements shall be documented in the design documentation (seeparagraph 4.2.3) and verified through the verification activities described in this UR.
7.1
7.1.1

Reporting of system and software identification and version
System identification

The system shall provide means to identify its name, version, identifier, and manufacturer. It
is recommended that the system can automatically report the status of its software to a ship
software logging system (SSLS) as specified in the international standard ISO 24060.
7.2

Data links

Intra-system integration testing shall be done between system and sub-system softwaremodules before being integrated on board. The objective is to check that software functions
are properly executed, that the software and the hardware it controls interact and function
properly together and that software systems react properly in case of failures. Faults are to be
simulated as realistically as possible to demonstrate appropriate system fault detection andPage 24 of 32

IACS Rev.3 2023

E22

E22

(cont)

system response. The results of any required failure analysis are to be observed. Functionaland failure testing can be demonstrated by simulation tests.
For Category II and III systems:-

Test programs and procedures for functional tests and failure tests shall be submitted to
the Class Society. A FMEA may be requested by the Class Society in order to support
containment of failure tests programs.

-

Factory acceptance test including functional and failure tests shall be witnessed byClass Society.
Following documentation shall be provided:(i)Functional description of software(ii) List and versions of software installed in system(iii) User manual including instructions for use during software maintenance(iv) List of interfaces between system and other ship systems(v) List of standards used for data links(vi) Additional documentation as requested by the Class Society which might include
an FMEA or equivalent to demonstrate the adequacy of failure test case applied

3.1.4

Approval of programmable devices for Category II and III systems

Approval of programmable devices integrated inside a system shall be delivered to thesystem integrator or supplier. Approval can be granted on case by case basis, or as part of a
product type approval, so long as above mentioned documents have beenreviewed/approved (as per annex) and the required tests have been witnessed by the Class
Society (also see paragraph 4 regarding hardware environmental type tests). Documentation
should address the compatibility of the programmable device in the ship’s application, thenecessity to have on board tests during ship integration and should identify the components
of system using the approved programmable devices.
3.1.5

Final integration and on board testing

Simulation tests are to be undertaken before installation, when it is found necessary to checksafe interaction with other computerized systems and functions that could not be tested
previously.
On board tests shall check that a computer-based system in its final environment, integrated
with all other systems with which it interacts is:-

Performing functions it was designed for-

Reacting safely in case of failures originated internally or by devices external to thesystemInteracting safely with other systems implemented on board vessel
For final integration and on board testing of Category II and III systems:-

Test specifications shall be submitted to the Class Society for approval-

The tests shall be witnessed by the Class Society

3.2

Limited approval
Page 25 of 32

IACS Rev.3 2023

E22

E22

(cont)

Sub-systems and programmable devices may be approved for limited applications withservice restrictions by the Class Society when the ship system where they will be integrated
is not known. In this case, requirements about Quality systems under paragraph 3.1.1 mightneed to be fulfilled as required by the Class Society. Additional drawings, details, tests
reports and surveys related to the Standard declared by the Supplier may be required by theClass Society upon request.
Sub-systems and programmable devices may in this case be granted with a limited approvalmentioning the required checks and tests performed.
3.3
3.3.1

Modifications during operation
Responsibilities

Organizations in charge of software modifications shall be clearly declared by Owner to theClass Society. A System integrator shall be designated by the Owner and shall fulfil
requirements mentioned in paragraph 3.1. Limited life cycle steps may be considered formodifications already considered and accepted in the scope of initial approval. The level of
documentation needed to be provided for the modification shall be determined by the Class
Society.
At the vessel level, it is the responsibility of Owner to manage traceability of thesemodifications; the achievement of this responsibility shall be supported by system integrators
updating the Software Registry. This Software Registry shall contain:-

List and versions of software installed in systems required in paragraph 3.1.3-

Results of security scans as described in paragraph 3.4

3.3.2

Change management

The owner shall ensure that necessary procedures for software and hardware change
management exist on board, and that any software modification/upgrade are performed
according to the procedure. All changes to computer-based systems in the operational phaseshall be recorded and be traceable.
3.4

System security

Owner, system integrator and suppliers shall adopt security policies and include these in their
quality systems and procedures.
For Category I, II, and III systems, physical and logical security measures shall be in place toprevent unauthorized or unintentional modification of software, whether undertaken at thephysical system or remotely.
Prior to installation, all artefacts, software code, executables and the physical medium used
for installation on the vessel are to be scanned for viruses and malicious software. Results ofthe scan are to be documented and kept with the Software Registry.
4.

Requirements for hardware regarding environment

Evidence of environmental type testing according to UR E10 regarding hardware elements
included in the system and sub-systems shall be submitted to the Class Society for Category

Page 26 of 32

IACS Rev.3 2023

E22

E22

(cont)I, II and III computer-based systems. This requirement is not mandatory for Category I
computer-based systems not considered by Class.
5.
7.2.1

Requirements for data links for Category II and III systmes
General requirements for category II and III systems

5.1

General requirements

5.1.1
Loss of a data link shall be specifically addressed in risk assessment analysis/FMEA.
See paragraph 4.2.3.
1)
A single failure in data link shall not cause loss of vessel- functions of category III. Any
effect of such failures shall meet the principle of fail-to-safe for the vessel-function(s) being
served.
5.1.2 A single failure in data link hardware shall be automatically treated in order to restore
proper working of system. For Category III systems a single failure in data link hardware shallnot influence the proper working of the system.
2)
For vessel-functions of category II and III, any loss of functionality in the remote control
system shall be compensated for by local/manual means.
3)
The data link shall have means to prevent or cope with excessive communication rates.
5.1.3 Characteristics of data link shall prevent overloading in any operational condition ofsystem.
4)5.1.4Data links shall be self-checking, detecting failures or performance issues on the linkitself and data communication failures on nodes connected to the link.
5)
7.2.2

Detected failures shall initiate an alarm.
5.2 Specific requirements for wireless data links1)5.2.1Category III systems shall not use wireless data links unless specifically considered by
the Class Society on the basis of an engineering analysis carried out in accordance with an
International or National Standard acceptable to the Society.
5.2.2 Other categories of systems may use wireless data links with the following
requirements:
2)5.2.2.1Recognised international wireless communication system protocols shall be
employed, incorporating:a. Message integrity. Fault prevention, detection, diagnosis, and correction so that thereceived message is not corrupted or altered when compared to the transmitted
message.
b. Configuration and device authentication. Shall only permit connection of devices thatare included in the system design.
c. Message encryption. Protection of the confidentiality and or criticality of the data
content.
d. Security management. Protection of network assets, prevention of unauthorizedaccess to network assets.

Page 27 of 32

IACS Rev.3 2023

E22

E22

(cont)

3)5.2.2.2The internal wireless system within the vessel shall comply with the radio frequency
and power level requirements of International Telecommunication Union and flag state
requirements.
4)
Consideration should be given to system operation in the event of port state and local
regulations that pertain to the use of radio-frequency transmission prohibiting the operation ofa wireless data communication link due to frequency and power level restrictions.
5)5.2.2.3For wireless data communication equipment, tests during harbour and sea trials areto be conducted to demonstrate that radio-frequency transmission does not cause failure ofany equipment and does not its self-fail as a result of electromagnetic interference during
expected operating conditions.
7.3

Verification of technical requirements by the Class Society

The implementation of the technical requirements provided in paragraph 7 is verified by theClass Society as part of the system description (paragraph 4.2.3), FAT (paragraph 4.2.7) andSAT (paragraph 4.3.6) described above.

Page 28 of 32

IACS Rev.3 2023

E22

E22

(cont)

Annex: A: Summary of documentation submittal Documents for Class Society and test
attendance
Table 5 and Table 6 below summarise the documentation to be submitted to the Class
Society.
Table 5 Summary of documentation submittal by the system supplier
Item
Document

Paragraphreference
4.2.1

Quality plan

4.2.3

System description

4.2.4

4.2.6

Environmental
compliance
Software test
reports
System test report

4.2.7

FAT program

4.2.7

FAT report

4.2.7

Additional FAT
docs. (e.g. user
manual, etc)
Management ofchange procedure

4.2.5

4.2.8

Responsible
role
Systemsupplier
Systemsupplier
Systemsupplier
Systemsupplier
Systemsupplier
Systemsupplier
Systemsupplier

System category
Cat I
Cat II Cat III
FI on
req.

FI on
req.

AP

AP

FI

FI

FI on
req.
FI on
req.

FI on
req.
FI on
req.

-

AP

AP

-

FI

FI

Systemsupplier

-

FI on
req.

FI on
req.

Systemsupplier

-

FI on
req.

FI on
req.

FI on
req.
FI on
req.
-

Legend: AP = Approval, FI = For Information, “-“ = No requirement, on req. = Upon request from the Class Society

Page 29 of 32

IACS Rev.3 2023

E22

E22

(cont)

Table 6 Summary of documentation submittal by the systems integrator
Paragraphreference
4.3.2
4.3.3

Item
Document
Quality plan

4.3.6

List of system
categorizations
Risk assessment
reportVessel’s systemarchitecture
SAT program

4.3.6

SAT report

4.3.7

SOST program

4.3.7

SOST report

4.3.8

Changemanagement
procedure forsoftware

4.3.4
4.3.5

Responsible
role
Systems
integrator
Systems
integrator
Systems
integrator
Systems
integrator
Systems
integrator
Systems
integrator
Systems
integrator
Systems
integrator
Systems
integrator

System category
Cat I
Cat II Cat III

AP on
req.
AP on
req.
FI on
req.

FI on
req.
AP on
req.
AP on
req.
FI on
req.

FI on
req.
AP on
req.
AP on
req.
FI on
req.

-

AP

AP

-

FI

FI

-

AP

AP

-

FI

FI

-

FI on
req.

FI on
req.

-

Legend: AP = Approval, FI = For Information, “-“ = No requirement, on req. = Upon request from the Class Society

Page 30 of 32

IACS Rev.3 2023

E22

E22

(cont)

ANNEX B: Summary of test witnessing and survey
Table 7 below summarises the activities that shall be witnessed or surveyed by the Class
Society. The responsible role shall facilitate the activity.
Table 7 Summary of test witnessing and survey
Item
Paragraph
Activityreference
4.2.7
FAT
witnessing
4.3.6
SAT
witnessing
4.3.7
SOST
witnessing
6.12
Verificationof changes

Responsible
role

System category
Cat I
Cat IICat III

System Supplier

-

x

x

Systems integrator

-

x

x

Systems integrator

-

x

x

Systems integrator

-

x

x

Legend: “x” = Witnessing required “-“ = Witnessing not requiredⒶ Submitted (For Approval)Ⓘ Provided (For information)Ⓦ Witness

1 Additional documentation may be required upon request
2 Upon request

3 If in the scope of Class requirement

Requirement
Quality Plan
Risk assessment
reportSoftwaremodulesfunctionaldescription andassociatedhardwaredescription
Evidence ofverification ofsoftware code
Evidence offunctional tests
for elements
included insystems of
Category II and III
at the level ofsoftware module,
sub-system andsystemSUPPLIER
INVOLVEDXSYSTEMINTEGRATORINVOLVEDXX

OWNER
INVOLVED

CATEGORY
I1

CATEGORYII

CATEGORY
III

Ⓐ2

Ⓐ

Ⓐ

Ⓘ2

Ⓘ2

Ⓘ2

X (if
necessary)

X

Ⓘ

Ⓘ

X (if
necessary)

X

Ⓘ

Ⓘ

X

X

Ⓘ

Ⓘ

Page 31 of 32

IACS Rev.3 2023

E22

E22

(cont)

Requirement
Test programs
and proceduresfor functional
tests and failure
tests including a
supporting FMEA
or equivalent, at
the request of theClass Society
Factory
acceptance test
event including
functional andfailure tests
Test program forsimulation tests
for final
integration
Simulation tests
for final
integration
Test program foron board tests(includes wirelessnetwork testing)On board
integration tests(includes wirelessnetwork testing)- List andversions ofsoftware installedin system- Functionaldescription ofsoftware- User manual
including
instructions
during software
maintenance- List of interfaces
between systemand other ship
systems
UpdatedSoftware Registry
Procedures anddocumentation
related toSecurity Policy
Test reports
according to UR
E10 requirements

SUPPLIER
INVOLVEDXSYSTEMINTEGRATORINVOLVED

CATEGORYII

CATEGORY
III

X

Ⓐ

Ⓐ

X

Ⓦ

Ⓦ

X

Ⓐ

Ⓐ

X

Ⓦ

Ⓦ

X

Ⓐ

Ⓐ

X

Ⓦ

Ⓦ

X

Ⓘ

Ⓘ

Ⓘ

Ⓘ

Ⓘ

Ⓘ

Ⓐ

Ⓐ

X

X

X

OWNER
INVOLVED

CATEGORY
I1

XⒶ3

End ofDocument

Page 32 of 32

IACS Rev.3 2023