641 Ni - 2017 12 PDF

Guidelines for
Autonomous Shipping
December 2017
Guidance Note
NI 641 DT R00 E
Marine & Offshore

92937 Paris la Défense Cedex – France
Tel: + 33 (0)1 55 24 70 00
Website: http://www.veristar.com
Email: [email protected]
 2017 Bureau Veritas - All rights reserved
MARINE & OFFSHORE - GENERAL CONDITIONS
1. INDEPENDENCY OF THE SOCIETY AND APPLICABLE TERMS 3.2. Subject to the Services performance and always by reference to 9.2. In such a case, the class granted to the concerned Unit and the
1.1. The Society shall remain at all times an independent contractor the Rules, the Society shall: previously issued certificates shall remain valid until the date of effect
and neither the Society nor any of its officers, employees, servants, • review the construction arrangements of the Unit as shown on the of the termination notice issued, subject to compliance with clause 4.1
agents or subcontractors shall be or act as an employee, servant or documents provided by the Client; and 6 above.
agent of any other party hereto in the performance of the Services. • conduct the Unit surveys at the place of the Unit construction; 10. FORCE MAJEURE
1.2. The operations of the Society in providing its Services are exclu- • class the Unit and enters the Unit's class in the Society's Register; 10.1. Neither Party shall be responsible for any failure to fulfil any term
sively conducted by way of random inspections and do not, in any cir- • survey the Unit periodically in service to note that the requirements or provision of the Conditions if and to the extent that fulfilment has
cumstances, involve monitoring or exhaustive verification. for the maintenance of class are met. The Client shall inform the been delayed or temporarily prevented by a force majeure occurrence
1.3. The Society acts as a services provider. This cannot be construed Society without delay of any circumstances which may cause any without the fault or negligence of the Party affected and which, by the
as an obligation bearing on the Society to obtain a result or as a war- changes on the conducted surveys or Services. exercise of reasonable diligence, the said Party is unable to provide
ranty. The Society is not and may not be considered as an underwriter, The Society will not: against.
broker in Unit's sale or chartering, expert in Unit's valuation, consulting • declare the acceptance or commissioning of a Unit, nor its construc- 10.2. For the purpose of this clause, force majeure shall mean any cir-
engineer, controller, naval architect, manufacturer, shipbuilder, repair tion in conformity with its design, such activities remaining under the cumstance not being within a Party's reasonable control including, but
or conversion yard, charterer or shipowner; none of them above listed exclusive responsibility of the Unit's owner or builder; not limited to: acts of God, natural disasters, epidemics or pandemics,
being relieved of any of their expressed or implied obligations as a re- • engage in any work relating to the design, construction, production wars, terrorist attacks, riots, sabotages, impositions of sanctions, em-
sult of the interventions of the Society. or repair checks, neither in the operation of the Unit or the Unit's bargoes, nuclear, chemical or biological contaminations, laws or action
1.4. The Services are carried out by the Society according to the appli- trade, neither in any advisory services, and cannot be held liable on taken by a government or public authority, quotas or prohibition, expro-
cable Rules and to the Bureau Veritas' Code of Ethics. The Society those accounts. priations, destructions of the worksite, explosions, fires, accidents, any
only is qualified to apply and interpret its Rules. 4. RESERVATION CLAUSE labour or trade disputes, strikes or lockouts
1.5. The Client acknowledges the latest versions of the Conditions and 4.1. The Client shall always: (i) maintain the Unit in good condition after 11. CONFIDENTIALITY
of the applicable Rules applying to the Services' performance. surveys; (ii) present the Unit after surveys; (iii) present the Unit for sur- 11.1. The documents and data provided to or prepared by the Society
1.6. Unless an express written agreement is made between the Parties veys; and (iv) inform the Society in due course of any circumstances in performing the Services, and the information made available to the
on the applicable Rules, the applicable Rules shall be the rules applica- that may affect the given appraisement of the Unit or cause to modify Society, are treated as confidential except where the information:
ble at the time of the Services' performance and con tract's execution. the scope of the Services. • is already known by the receiving Party from another source and is
1.7. The Services' performance is solely based on the Conditions. No 4.2. Certificates referring to the Society's Rules are only valid if issued properly and lawfully in the possession of the receiving Party prior
other terms shall apply whether express or implied. by the Society. to the date that it is disclosed;
2. DEFINITIONS 4.3. The Society has entire control over the Certificates issued and • is already in possession of the public or has entered the public
2.1. "Certificate(s)" means class certificates, attestations and reports may at any time withdraw a Certificate at its entire discretion including, domain, otherwise than through a breach of this obligation;
following the Society's intervention. The Certificates are an appraise- but not limited to, in the following situations: where the Client fails to • is acquired independently from a third party that has the right to dis-
ment given by the Society to the Client, at a certain date, following sur- comply in due time with instructions of the Society or where the Client seminate such information;
veys by its surveyors on the level of compliance of the Unit to the fails to pay in accordance with clause 6.2 hereunder. • is required to be disclosed under applicable law or by a governmen-
Society's Rules or to the documents of reference for the Services pro- 5. ACCESS AND SAFETY tal order, decree, regulation or rule or by a stock exchange authority
vided. They cannot be construed as an implied or express warranty of 5.1. The Client shall give to the Society all access and information nec- (provided that the receiving Party shall make all reasonable efforts
safety, fitness for the purpose, seaworthiness of the Unit or of its value essary for the efficient performance of the requested Services. The Cli- to give prompt written notice to the disclosing Party prior to such
for sale, insurance or chartering. ent shall be the sole responsible for the conditions of presentation of disclosure.
2.2. "Certification" means the activity of certification in application of the Unit for tests, trials and surveys and the conditions under which 11.2. The Society and the Client shall use the confidential information
national and international regulations or standards, in particular by del- tests and trials are carried out. Any information, drawings, etc. required exclusively within the framework of their activity underlying these Con-
egation from different governments that can result in the issuance of a for the performance of the Services must be made available in due ditions.
certificate. time. 11.3. Confidential information shall only be provided to third parties
2.3. "Classification" means the classification of a Unit that can result 5.2. The Client shall notify the Society of any relevant safety issue and with the prior written consent of the other Party. However, such prior
or not in the issuance of a class certificate with reference to the Rules. shall take all necessary safety-related measures to ensure a safe work consent shall not be required when the Society provides the confiden-
2.4. "Client" means the Party and/or its representative requesting the environment for the Society or any of its officers, employees, servants, tial information to a subsidiary.
Services. agents or subcontractors and shall comply with all applicable safety 11.4. The Society shall have the right to disclose the confidential infor-
2.5. "Conditions" means the terms and conditions set out in the regulations. mation if required to do so under regulations of the International Asso-
present document. ciation of Classifications Societies (IACS) or any statutory obligations.
6. PAYMENT OF INVOICES
2.6. "Industry Practice" means International Maritime and/or Offshore
6.1. The provision of the Services by the Society, whether complete or 12. INTELLECTUAL PROPERTY
industry practices.
not, involve, for the part carried out, the payment of fees thirty (30) days 12.1. Each Party exclusively owns all rights to its Intellectual Property
2.7. "Intellectual Property" means all patents, rights to inventions, utility
upon issuance of the invoice. created before or after the commencement date of the Conditions and
models, copyright and related rights, trade marks, logos, service marks,
6.2. Without prejudice to any other rights hereunder, in case of Client's whether or not associated with any contract between the Parties.
trade dress, business and domain names, rights in trade dress or get-up,
payment default, the Society shall be entitled to charge, in addition to 12.2. The Intellectual Property developed for the performance of the
rights in goodwill or to sue for passing off, unfair competition rights, rights
the amount not properly paid, interests equal to twelve (12) months LI- Services including, but not limited to drawings, calculations, and re-
in designs, rights in computer software, database rights, topography
BOR plus two (2) per cent as of due date calculated on the number of ports shall remain exclusive property of the Society.
rights, moral rights, rights in confidential information (including know-
days such payment is delinquent. The Society shall also have the right 13. ASSIGNMENT
how and trade secrets), methods and proto cols for Services, and any
to withhold certificates and other documents and/or to suspend or re- 13.1. The contract resulting from to these Conditions cannot be as-
other intellectual property rights, in each case whether capable of regis-
voke the validity of certificates. signed or transferred by any means by a Party to a third party without
tration, registered or unregistered and including all applications for and
6.3. In case of dispute on the invoice amount, the undisputed portion the prior written consent of the other Party.
renewals, reversions or extensions of such rights, and all similar or
of the invoice shall be paid and an explanation on the dispute shall ac- 13.2. The Society shall however have the right to assign or transfer by
equivalent rights or forms of protection in any part of the world.
company payment so that action can be taken to solve the dispute. any means the said contract to a subsidiary of the Bureau Veritas
2.8. "Parties" means the Society and Client together.
2.9. "Party" means the Society or the Client. 7. 7. LIABILITY Group.
2.10. "Register" means the register published annually by the Society. 7.1. The Society bears no liability for consequential loss. For the pur- 14. SEVERABILITY
2.11. "Rules" means the Society's classification rules, guidance notes and pose of this clause consequential loss shall include, without limitation: 14.1. Invalidity of one or more provisions does not affect the remaining
other documents. The Rules, procedures and instructions of the Society • Indirect or consequential loss; provisions.
take into account at the date of their preparation the state of currently avail- • Any loss and/or deferral of production, loss of product, loss of use, 14.2. Definitions herein take precedence over other definitions which
able and proven technical minimum requirements but are not a standard loss of bargain, loss of revenue, loss of profit or anticipated profit, may appear in other documents issued by the Society.
or a code of construction neither a guide for maintenance, a safety hand- loss of business and business interruption, in each case whether 14.3. In case of doubt as to the interpretation of the Conditions, the
book or a guide of professional practices, all of which are assumed to be direct or indirect. English text shall prevail.
known in detail and carefully followed at all times by the Client. The Client shall save, indemnify, defend and hold harmless the Society
15. GOVERNING LAW AND DISPUTE RESOLUTION
2.12. "Services" means the services set out in clauses 2.2 and 2.3 but from the Client's own consequential loss regardless of cause.
15.1. The Conditions shall be construed and governed by the laws of
also other services related to Classification and Certification such as, but 7.2. In any case, the Society's maximum liability towards the Client is
England and Wales.
not limited to: ship and company safety management certification, ship limited to one hundred and fifty per-cents (150%) of the price paid by
15.2. The Society and the Client shall make every effort to settle any
and port security certification, training activities, all activities and duties the Client to the Society for the performance of the Services. This limit
dispute amicably and in good faith by way of negotiation within thirty
incidental thereto such as documentation on any supporting means, soft- applies regardless of fault by the Society, including breach of contract,
(30) days from the date of receipt by either one of the Parties of a writ-
ware, instrumentation, measurements, tests and trials on board. breach of warranty, tort, strict liability, breach of statute.
ten notice of such a dispute.
2.13. "Society" means the classification society 'Bureau Veritas Ma- 7.3. All claims shall be presented to the Society in writing within three
15.3. Failing that, the dispute shall finally be settled by arbitration under
rine & Offshore SAS', a company organized and existing under the (3) months of the Services' performance or (if later) the date when the
the LCIA rules, which rules are deemed to be incorporated by refer-
laws of France, registered in Nanterre under the number 821 131 844, events which are relied on were first discovered by the Client. Any
ence into this clause. The number of arbitrators shall be three (3). The
or any other legal entity of Bureau Veritas Group as may be specified claim not so presented as defined above shall be deemed waived and
place of arbitration shall be London (UK).
in the relevant contract, and whose main activities are Classification absolutely time barred.
16. PROFESSIONNAL ETHICS
and Certification of ships or offshore units. 8. INDEMNITY CLAUSE
16.1. Each Party shall conduct all activities in compliance with all laws,
2.14. "Unit" means any ship or vessel or offshore unit or structure of 8.1. The Client agrees to release, indemnify and hold harmless the So-
statutes, rules, and regulations applicable to such Party including but
any type or part of it or system whether linked to shore, river bed or sea ciety from and against any and all claims, demands, lawsuits or actions
not limited to: child labour, forced labour, collective bargaining, discrim-
bed or not, whether operated or located at sea or in inland waters or for damages, including legal fees, for harm or loss to persons and/or
ination, abuse, working hours and minimum wages, anti-bribery, anti-
partly on land, including submarines, hovercrafts, drilling rigs, offshore property tangible, intangible or otherwise which may be brought
corruption. Each of the Parties warrants that neither it, nor its affiliates,
installations of any type and of any purpose, their related and ancillary against the Society, incidental to, arising out of or in connection with
has made or will make, with respect to the matters provided for here-
equipment, subsea or not, such as well head and pipelines, mooring the performance of the Services except for those claims caused solely
under, any offer, payment, gift or authorization of the payment of any
legs and mooring points or otherwise as decided by the Society. and completely by the negligence of the Society, its officers, employ-
money directly or indirectly, to or for the use or benefit of any official or
3. SCOPE AND PERFORMANCE ees, servants, agents or subcontractors.
employee of the government, political party, official, or candidate.
3.1. The Society shall perform the Services according to the applicable 9. TERMINATION 16.2. In addition, the Client shall act consistently with the Society's
national and international standards and Industry Practice and always 9.1. The Parties shall have the right to terminate the Services (and the Code of Ethics of Bureau Veritas. http://www.bureauveritas.com/
on the assumption that the Client is aware of such standards and In- relevant contract) for convenience after giving the other Party thirty home/about-us/ethics+and+compliance/
dustry Practice. (30) days' written notice, and without prejudice to clause 6 above.
Bureau Veritas Marine & Offshore General Conditions - Edition January 2017
GUIDANCE NOTE NI 641
Guidelines for Autonomous Shipping
SECTION 1 GENERAL
SECTION 2 RISK AND TECHNOLOGY ASSESSMENT
SECTION 3 GUIDELINES FOR FUNCTIONALITY OF AUTONOMOUS SYSTEMS
SECTION 4 GUIDELINES FOR RELIABILITY OF AUTONOMOUS SYSTEMS
December 2017
Section 1 General
1 General 5
1.1 Context
1.2 Scope of the guidelines
1.3 Organization of the guidelines
1.4 Definitions
1.5 Acronyms
2 Safety and security conditions 6
2.1 General
2.2 Main ship capabilities
2.3 Infrastructure
2.4 Reliability
2.5 Human factors
2.6 Cybersecurity
2.7 Cargo
3 Regulations 8
3.1 General
3.2 SOLAS
3.3 MARPOL
3.4 COLREGs
3.5 STCW
Section 2 Risk and Technology Assessment

1 General 9
1.1 Purpose and approach
2 Risk assessment 9
2.1 Methodology
2.2 Model of autonomous ship
2.3 Hazards identification
2.4 Risk analysis
2.5 Risk Control Options
3 Technology assessment 13
3.1 Reference
3.2 General
3.3 Technology rating
3.4 Level of autonomy
Section 3 Guidelines for Functionality of Autonomous Systems

1 General 15
1.1 Scope
2 Bureau Veritas December 2017

2 Navigation system 15
2.1 Goal
2.2 Functional requirements
2.3 References
2.4 Voyage planning
2.5 Navigation
2.6 Ship status and dynamics
2.7 Lookout
2.8 Weather routing
2.9 Collision avoidance
2.10 Voyage recording
2.11 Emergencies and alarm
2.12 Devices used for situational awareness
3 Communication network and system 17

3.1 Goal
3.3 References
3.4 Type of communication system
3.5 Performance
4 Machinery system 17
4.1 Goal
4.3 References
4.4 Monitoring
4.5 Maintenance
4.6 Emergency management
5 Cargo management system 18

5.1 Goal
5.3 References
5.4 Monitoring
5.5 Control
5.6 Loading and unloading
6 Passenger management system 18

6.1 Goal
6.3 References
6.4 Overload prevention
6.5 Boarding sequence
6.6 Life saving
7 Shore control centre 19

7.1 Goal
7.3 Means of communication
7.4 Control and monitoring
7.5 Manning
December 2017 Bureau Veritas 3

Section 4 Guidelines for Reliability of Autonomous Systems
1 General 21
1.1 Scope
2 General system design 21
2.1 References
2.2 Risk-based design
2.3 Component failure
2.4 Network failure
2.5 Power failure
3 Human machine interface 21
3.1 References
3.2 Design
3.3 Information display
3.4 Controls and indicators
3.5 User training
4 Network and communication 22
4.1 References
4.2 Design
4.3 Performance
4.4 Redundancy
5 Software quality assurance 23
5.1 References
5.2 Quality plan
5.3 Testing
5.4 Configuration management
6 Data quality assurance 24
6.1 References
6.2 Data quality assessment
6.3 Data acquisition
6.4 Data storage
6.5 Data authentication
6.6 Data integrity
6.7 Data confidentiality
7 Cybersecurity 24
7.1 References
7.2 Cyber protection
7.3 Identification
7.4 Protection
7.5 Detection
7.6 Response and recovery

NI 641, Sec 1
SECTION 1 GENERAL
1 General • Cybersecurity: preservation of confidentiality, integrity

and availability of information in the Cyberspace
(ISO/IEC 27032:2012)
1.1 Context
• Cyberspace: complex environment resulting from the
1.1.1 Compared to conventional shipping, autonomous interaction of people, software and services on the Inter-
shipping is a great opportunity for the stakeholders of the net by means of technology devices and networks con-
maritime sector to improve the safety, the reliability and to nected to it, which does not exist in any physical form
reduce the costs. (ISO/IEC 27032:2012)
But while the information and communication technologies
• Ergonomics: applied science that studies, designs and
enable the autonomy in the shipping industry, those technol-
adapts equipment, work and the environment to meet
ogies also imply new hazards that are to be identified and
human capabilities and limitations and to enhance
new associated risks that are to be mitigated.
safety and comfort (ISO 14105:2011)
1.2 Scope of the guidelines • Latency: the time interval between the instant at which
an instruction control unit issues a call for data and the
1.2.1 This Guidance Note sets out the main recommenda- instant at which the transfer of data is started
tions for the design or the operation of systems which may (ISO/IEC/IEEE 24765:2010)
be used to enhance the autonomy in the shipping.
• Level of autonomy: degree of decision making (author-
1.2.2 This Guidance Note is mainly focused on surface ity) deferred from the human to the system. A global
units which may be considered as a ship by the authorities level of autonomy of the ship should be defined accord-
(e.g. Maritime Autonomous Surface Ships of 500 GT or ing to the main roles between the human and the sys-
more). This excludes small ships (typically length less than tems. Descriptions of different levels of autonomy from
20 m) and unmanned underwater vehicles. the conventional ship to the fully autonomous ship are
given in Tab 1. A level of autonomy should be defined
for every autonomous ship’s system prior to any assess-
1.3 Organization of the guidelines ment (see Sec 2, [3.4])
1.3.1 In addition to the current introductive section, this • Lookout: activity carried out at all times by sight and
Guidance Note includes 3 sections: hearing as well as by all available means appropriate in
• Sec 2 is about the risk and technology assessment of the prevailing circumstances and conditions so as to
new technologies used in autonomous shipping make a full appraisal of the situation and of the risk of
collision (ISO 8468:2007)
• Sec 3 provides guidelines for ensuring a suitable level
of functionality for autonomous systems
• Navigation: all tasks relevant for deciding, executing
• Sec 4 provides guidelines for improving the reliability and maintaining course and speed in relation to waters
of autonomous systems. and traffic (IACS Unified Requirements N1)
• Reliability: property of a system and its parts to perform

1.4 Definitions
its mission accurately and without failure or significant
degradation (ISO/IEC 27036-3:2013)
1.4.1 Terms used in this Guidance Note are defined below:
• Autonomous ship: ship having the same capabilities as • Sensor: device that responds to biological, chemical, or
those of a smart ship and including autonomous systems physical stimulus (such as heat, light, sound, pressure,
capable of making decisions and performing actions magnetism, motion, and gas detection) and provides a
with or without human in the loop. An autonomous ship measured response of the observed stimulus
may be manned with a reduced crew or unmanned with (ISO/IEC/IEEE 21451-7:2011)
or without supervision • Smart ship: generic term to define a connected ship,
• Conventional ship: ship where most essential decisions capable of collecting data from sensors and having the
and actions are performed by the crew aboard. A con- capacity to process a large amount of data in order to
ventional ship may have automated systems to assist the assist the crew during the decision making process.
crew by automatically performing some actions, but Compared to a conventional ship, a smart ship may be
those systems are always under the control of human manned with reduced crew or totally unmanned with a
aboard. By definition, a conventional ship is manned remote control

NI 641, Sec 1
• System: combination of interacting elements organized LOS : Line Of Sight

to achieve one or more stated purposes (ISO/IEC MARPOL: International Convention for the Prevention of
15288:2008) Pollution from Ships
• System element: member of a set of elements that con- NAVTEX: Navigational Telex
stitutes a system. A system element is a discrete part of a RCM : Risk Control Measure
system that can be implemented to fulfil specified
RCO : Risk Control Options
requirements. A system element can be hardware, soft-
ware, data, humans, processes (e.g., processes for pro- SCC : Shore Control Centre
viding service to users), procedures (e.g., operator SOLAS : International Convention for the Safety of Life at
instructions), facilities, materials, and naturally occur- Sea
ring entities (e.g., water, organisms, minerals), or any STCW : International Convention on Standards of Train-
combination (ISO/IEC 15288:2008) ing, Certification and Watchkeeping for Seafarers
• System integrity: quality of a data processing system ful- VDR : Voyage Data Recorder
filling its operational purpose while both preventing VHF : Very High Frequency
unauthorized users from making modifications to or use
VSAT : Very Small Aperture Terminal
of resources and preventing authorized users from mak-
ing improper modifications to or improper use of VTS : Vessel Traffic Services.
resources (ISO/IEC 2382:2015)
• Unmanned ship: ship that does not physically contain a 2 Safety and security conditions
human and is capable of controlled movement.
Unmanned ship may be remotely controlled, supervised 2.1 General
or fully autonomous.
2.1.1 To achieve an acceptable level of safety and security
the general principles behind the recommendations con-
1.5 Acronyms
tained in this Guidance Note are given in [2.2] to [2.7].
1.5.1 Acronyms used in this Guidance Note are defined
2.1.2 The threats for autonomous ships are very similar to
below:
those for conventional ships, but in addition new threats
AIS : Automatic Identification System may arise from the reduction or absence of crew aboard.
ANS : Autonomous Navigation System They are mainly coming from the environment, other ships
CCTV : Closed Circuit Television in its vicinity and operations of the considered ship.
COLREGs: Convention on the International Regulations for Compared to conventional ships, the management of the
Preventing Collisions at Sea risks is transfered from the crew aboard to the sensors and
the software and ultimately to the supervisors onshore.
CRC : Cyclic Redundancy Check
GPS : Global Positioning System 2.1.3 It is required that autonomous or remotely controlled
ships should be at least as safe as a conventional ship hav-
IACS : International Association of Classification Soci-
ing the same purpose or design (e.g. carrying cargo or pas-
eties
sengers).
IMO : International Maritime Organisation
For safe operations, autonomous ships should not be a
IT : Information Technology source of danger to themself, to the other ships around, to
LIDAR : LIght Detection And Ranging the maritime infrastructures and to the marine environment.
Table 1 : Ship categories and level of autonomy
Authority to Actions
Ship category Level of autonomy Manned Method of control
make decisions initiated by
Automated or manual operations are
Conventional 0 Human operated Yes Human Human
under human control
Decision support
Smart 1 Human directed Yes/No Human Human
Human makes decisions and actions
2 Human delegated Yes/No Human must confirm decisions Human System
System is not expecting confirmation
3 Human supervised Yes/No Human is always informed of the Software System
Autonomous decisions and actions
System is not expecting confirmation
4 Fully autonomous No Human is informed only in case of Software System
emergency
Note 1: Definitions of the level of autonomy are given in Sec 2, Tab 16

NI 641, Sec 1
2.2 Main ship capabilities their vicinity. However, the autonomous ships should be
able to respond at any usual request (e.g. identification,
2.2.1 The autonomous ships should be capable of: position) from other ships by means of radio communica-
tions or visual signals.
• managing a pre-defined voyage plan and updating it in
real-time if relevant Port and coastal authorities should be able to communicate
• navigating according to the predefined voyage plan and with autonomous ships in order to be informed about the
avoid collisions with obstacles coming from the traffic planned manoeuvres and to be able to regulate the traffic.
or unexpected objects
• keeping a sufficient level of manoeuvrability and stability 2.4 Reliability
in various sea states
• withstanding unauthorized physical or virtual trespassing. 2.4.1 Compared to a conventional ship, the autonomous
ships may have less or even no crew aboard to rely on for
2.2.2 The autonomous ships should be designed to author- maintenance operations and corrective tasks due to system
ize a human to come aboard for controlling the ship, for failure. Consequently, the systems should be designed to be
example when a critical situation arises (e.g. fire, flooding, resilient to failure (e.g. fault tolerant) and to have extended
loss of propulsion etc). maintenance intervals (see Sec 4).
During the sea trials or for survey in service, the autono-
mous ships should be designed to accept the presence of a 2.4.2 Highest reliability should be achieved by introducing
human aboard or in their vicinity. efficient diagnostics and predictive algorithms for con-
trolling the risk of failures and pre-scheduling maintenance
Regardless of the possibility of a remote control, the auton- operations that should be performed in harbour (e.g. by
omous ships should be designed to be controlled aboard by using a condition-based maintenance).
either a portable device (e.g. laptop) or by a built-in control
system.
2.4.3 The usage of an intensive remote monitoring and
The possibility for a human to take the control aboard control of the status of the equipment should be considered
should be granted only to the authorized personnel, in par- in order to prevent failures.
ticular when the autonomous ships carry passengers.
A passenger of autonomous ships should have the possibility 2.4.4 A partial or full redundancy are some solutions to
to activate an emergency push button in case of critical situ- improve the availability for critical systems such as commu-
ation (e.g. passenger overboard, obstacle during docking). nication infrastructure or machinery.
2.3 Infrastructure 2.4.5 Redundancy is easiest to achieve for ships with elec-
trical propulsion. Generators producing electricity for
2.3.1 Shore Control Centre recharging batteries or additional emergency batteries
should be considered as a simple and cost-effective way to
The Shore Control Centre (SCC) should be considered as an improve the propulsion and steering reliability.
extension of the ship. To prevent that unexpected events on
the SCC could have consequences on the ship (e.g. fire,
earthquake), mitigation measures should be integrated in 2.5 Human factors
the design and operations of the SCC.
Those measures should not interfere with land-based regu- 2.5.1 The multiple sensors used for the monitoring increase
lations (e.g. lockdown during manoeuvre and procedure for a lot the amount of information provided to an operator. In
fire escape) which may differ from one country to the other order to avoid the risk of overload of information that may
depending on where the SCC is located. reduce the accuracy of the actual ship situation, a fusion of
the data collected by the sensors should be proposed to the
The SCC, including facility and manning, should be quali- operator.
fied with regard to each ship it is supervising. When the
SCC is used for an additional ship, a new qualification
2.5.2 The ergonomics of monitoring systems should take
should be obtained by the SCC for this ship.
into account the human vigilance that could be reduced
When the ship operates near restricted area (e.g. military during extended periods of remote control or when several
fleet), it should be necessary to have more stringent meas- ships which are in different situations are managed by only
ures for the protection of the SCC (e.g. to avoid terrorist one operator.
attack).
2.5.3 The remote operator should be aware of the latency
2.3.2 Interaction with the maritime infrastructure due to the communication that cause a delay between
Interaction with other autonomous or conventional ships his/her action and the actual ship reaction. The latency
should be taken into consideration during the design and should be continuously displayed during the operations
the operation. The autonomous ships should not interfere (e.g. manoeuvring) and a warning should be issued when
with the communications between other ships operating in the latency is over pre-defined limits.

NI 641, Sec 1
2.6 Cybersecurity • Reg.34: Safe navigation and avoidance of dangerous sit-

uations.
2.6.1 The usage of information and communication tech-
The Reg. 12 from Chapter IV (Radio-communications) rela-
nologies makes possible virtual unauthorized or malicious
tive to the continuous watches should also be considered.
actions to autonomous ships (e.g. virus infection). Data
communication between ship and shore or GPS signal 3.2.2 Regarding the obligation of assistance in distress situ-
could be intentionally disturbed or changed in order to ations, autonomous ships should be able to, at least, ensure
hijack the ship or cause severe damages. that distress signals are received and relayed to the relevant
search and rescue authorities.
2.6.2 Amongst the best practices for the usage of informa-
tion and communication technologies, measures should be 3.3 MARPOL
adopted to provide the highest level of confidence for data
(e.g. protection, encryption) and for user access (e.g. pass- 3.3.1 Provisions for prevention of pollution should not
word authentication). have any onerous consequences in the design and opera-
tion for autonomous ships. However, attention should be
2.7 Cargo paid to the regulations about prevention of pollution by oil,
in particular to enable a full automatic control of operations
2.7.1 Likewise for all conventional ships, the cargo on of oil discharges. In a similar way, it should be always possi-
autonomous ships should be carefully loaded and moni- ble to automatically control the air emissions from autono-
tored because the consequences for the ship could be from mous ships.
a simple shifting to fire or flooding. 3.3.2 All record books to report operations as required by
the MARPOL should be maintained in an electronic format.
2.7.2 The correct stowage of cargo aboard should rely on
port operators, since the autonomous ships have few means
(less or no crew and equipment) for ensuring a proper cargo
3.4 COLREGs
securing at sea. 3.4.1 To prevent collision at sea, the two main tasks that
should be handle by autonomous ships are:
3 Regulations • the look-out:
to ensure that ships are always monitored by using
appropriate information to have a full appraisal of the
3.1 General
situation and the risk of collision
3.1.1 Autonomous ships should be compliant with all rele- • the operational decisions:
vant regulations from international conventions adopted by obligation for ships to take avoidance decisions.
IMO or from local legislation. If necessary, exemptions or
equivalent solutions should be explicitly approved by the 3.4.2 Autonomous ships should be able to inform other
Administration. ships about its status and intentions, by giving a specific
light signal or communication message (e.g. AIS). The
autonomous ships should be able to communicate with
3.2 SOLAS other ships to determine if the intentions have been under-
stood and if it is necessary to provide recommendations
3.2.1 The following regulations from Chapter V (Safety of such as to change the route because of a risk of a collision.
navigation) should have a special interest for autonomous This signalling should be resilient to any communication
ships: failure, and for this particular case, the status should be “not
• Reg.14: Ships’ manning under command”.
• Reg.15: Principles relating to bridge design, design and
arrangement of navigational systems and equipment 3.5 STCW
and bridge procedures 3.5.1 The requirements of STCW should be used as a basis
• Reg.22: Navigation bridge visibility for the qualification and the definition of duties for the per-
sonnel operating ships. In particular, the responsibilities of
• Reg.24: Use of heading and/or track control systems
the watchkeeping should be adjusted taking into account
• Reg.33: Distress situations: obligations and procedures that the officers could be shore-based or the crew reduced.

NI 641, Sec 2
SECTION 2 RISK AND TECHNOLOGY ASSESSMENT
1 General 2.2 Model of autonomous ship
2.2.1 At the first stage of the risk assessment, the systems of

1.1 Purpose and approach the autonomous ship, including maritime infrastructure
(SCC), should be split into several groups of functions cov-
1.1.1 The risk and technology assessment are two qualita- ering all aspects of the operations.
tive assessments which are the most appropriate for dealing
with novel technology that may be used for autonomous As a guidance, the following groups of functions should be
ships. considered and some are detailed in [2.3.2] to [2.3.9]:
• voyage
1.1.2 The purpose of those assessments is to identify and to
reduce as low as reasonably practical the risks due to haz- • navigation
ards that may threaten autonomous ships. • detection of navigational and environmental conditions
1.1.3 The risk-based approach considers autonomous ships • safety and emergency
as a model of several different interconnected systems • security
aboard and onshore.
• ship strength and stability
1.1.4 The measures to mitigate the risks should be founded • passenger management
on prescriptive requirements already existing in the Rules or
• cargo management
in other standards or guidance notes from the industry or
regulatory bodies. • technical infrastructure.
2 Risk assessment 2.3 Hazards identification
2.3.1 Principles
2.1 Methodology
The hazards identification should cover all possible sources
2.1.1 References of hazards potentially contributing to undesirable events or
accidents.
The process for the risk assessment should be based on the
techniques available in the following documents: The consideration of a functional failure associated with the
consequence of an accident scenario should be governing
• IMO MSC-MEPC.2/Circ.12 Revised Guidelines for For- the process of identification.
mal Safety Assessment (FSA)
As a guidance, for some group of functions, a list of typical
• ISO/IEC 31010:2009 Risk management - Risk assess- hazards for autonomous ships are given in [2.3.2] to [2.3.9].
ment techniques
• ISO/IEC 27005:2011 Information technology — Secu- 2.3.2 Voyage
rity techniques — Information security risk manage- The hazards that should be considered for voyage purpose
ment. are summarized in Tab 1.
2.1.2 Stages 2.3.3 Navigation

The risk assessment should be performed according to the The hazards that should be considered for navigation pur-
following stages: pose are summarized in Tab 2.
a) model of the autonomous ship’s systems (see [2.2])
2.3.4 Detection of navigational or environmental
b) in case the system is not based on a qualified technology, conditions
a technology assessment should be carried (see [3]) The hazards that should be considered for detection pur-
c) hazards identification (see [2.3]) pose are summarized in Tab 3.
d) risk analysis and associated outcome (see [2.4]) 2.3.5 Safety and emergency
e) risk control options to eliminate intolerable risks (see The hazards that should be considered for safety and emer-
[2.5]). gency purpose are summarized in Tab 4.

NI 641, Sec 2
Table 1 : Hazards for the voyage
Hazard Consequence
Failure of ship-shore connection Loss
Collision
Sinking
Failure of update (e.g. of nautical publications, weather forecasts) Grounding
Sinking
Human error in input of voyage plan Loss
Human error in remote monitoring and control (e.g. through situation unawareness, data misinterpreta-
Collision
tion, SCC capacity overload)
Loss
Human error in remote maintenance
Sinking
Table 2 : Hazards for the navigation
Hazard Consequence
Heavy traffic Collision
Heavy weather Sinking
Low visibility Collision
Propulsion failure Collision
Grounding
Sensor failure Collision
Marine wildlife (e.g. whales, squids, carcasses) Collision
Floating objects Collision
Offshore installations Collision
Table 3 : Hazards for the detection
Hazard Consequence
Failure in detection of small objects (wreckage) Collision
Failure in detection of collision targets Collision
Failure in detection of navigational marks Grounding
Failure in detection of ship lights and shapes Collision
Failure in detection of semi-submerged towed or floating devices (e.g. seismic gauges, fishing trawls) Collision
Detection of unforeseeable events (e.g. freak wave) Sinking
Detection of considerable data discrepancy between charted water depth and sounded water depth -
Grounding
grounding objects
Detection of considerable data discrepancy between weather forecast and actual weather situation Sinking
Table 4 : Hazards for the safety and emergency
Hazard Consequence
Failure in position fixing (due to e.g. GPS selective availability) Collision
Loss of
Communication failure in case of other ship in distress (e.g. message reception, relay, acknowledgment)
other ship
Communication failure in case of own ship in distress (e.g. with SCC, relevant authorities, ships in vicinity) Loss
Fire Loss
Water flooding - sudden hull damage Loss

NI 641, Sec 2
2.3.6 Security 2.3.8 Passenger management

The hazards that should be considered for security purpose The hazards that should be considered in case of a ship car-
are summarized in Tab 5. rying passengers are summarized in Tab 7.
2.3.7 Ship strength and stability 2.3.9 Technical infrastructure

The hazards that should be considered for ship strength and The hazards that should be considered for the technical
stability purpose are summarized in Tab 6. infrastructure are summarized in Tab 8.
Table 5 : Hazards for the security
Hazard Consequence
Willful damage to ship structures by others (e.g. pirates, terrorists) Sinking
Illegal actions
Attempt of unauthorised ship boarding (e.g. pirates, terrorists, stowaways, smugglers) Hijack
Loss
Failure of ship's IT systems (e.g. due to bugs) Loss
Jamming or spoofing of AIS or GPS signals Collision
Jamming or spoofing of communications, hacker attack, also on SCC (e.g. in case of pirate or terrorist attack) Collision Grounding
Table 6 : Hazards for the ship strength and stability
Hazard Consequence
Loss of intact stability due to structural damage
Loss of intact stability due to unfavorable ship responses (e.g. to waves)
Sinking
Loss of intact stability due to shift and/or liquefaction of cargo
Loss of intact stability due to icing
Table 7 : Hazards for the passengers
Hazard Consequence
Too many passenger onboard (overload) Sinking
Passenger overboard Human injury or fatality
Passenger unwellness
Human injury
Passenger injured during arrival or departure
Illegal actions
Passenger interfering in an onboard system (deliberately or not) Hijack
Loss
Table 8 : Hazards for the technical infrastructure
Hazard Consequence
Sensor / Actuator failure Loss of control
Sensor / Actuator failure due to ship icing Loss of observation
Temporary loss of electricity (e.g. due to black-out) Loss of control
Loss of control
Permanent loss of electricity
Grounding
Failure of ship's IT infrastructure (e.g. due to fire in the server room) Loss of control
Part failure or total loss of propulsion system Loss of control
Part failure or total loss of rudder function Loss of control
Failure to drop anchor when drifting Grounding
Unavailability of SCC (fire, environmental phenomenon...) or of operator (faintness, emergency situa-
Loss of control
tion, etc.)

NI 641, Sec 2
Table 9 : Frequency index
Per ship
Index Definition Definition
year
7 Frequent Likely to occur once per month on one ship 10
6 Common Likely to occur once per year on one ship 1
Likely to occur once per year in a fleet of 10 ships, i.e. likely to occur a few times during the
5 Reasonably 0,1
ship's life
4 Possible Likely to occur once per year in a fleet of 100 ships 10-2
Likely to occur once per year in a fleet of 1000 ships, i.e. likely to occur in the total life of sev-
3 Remote 10-3
eral similar ships
2 Unlikely Likely to occur once in the lifetime (20 years) of a fleet of 500 ships 10-4
Extremely
1 Likely to occur once in the lifetime (20 years) of a world fleet of 5000 ships 10-5
unlikely
2.4 Risk analysis Table 10 : Severity index for the human
2.4.1 Principles Equivalent

Index Definition Human
fatalities
The purpose of the risk analysis is to investigate the causes
and the consequences of the most important accident sce- Single or
1 Minor 0,01
nario revealed by the hazards identification. The risk for a minor injuries
given accident scenario due to an hazard is estimated with
Multiple or
a risk index as a combination of the frequency of the cause 2 Significant 0,1
severe injuries
and the severity of the consequence.
Single fatality or
3 Severe 1
2.4.2 Frequency multiple severe injuries
The frequency is estimated by the probability of an event to 4 Catastrophic Multiple fatalities 10
occur once per year in a fleet of several ships having the
same operating mode. The frequency indexes based on a
Table 11 : Severity index for the ship
logarithmic scale are summarized in Tab 9.
Equivalent
2.4.3 Severity Index Definition Ship
damage
The severity is estimated according to the impact on the
Local equipment
human, the ship or the environment. The severity indexes 1 Minor 0,01
damage
based on a logarithmic scale are summarized in Tab 10 to
Tab 12. Non-severe ship
2 Significant 0,1
damage
2.4.4 Risk index
3 Severe Severe damage 1
The risk index is calculated before any mitigation measure
4 Catastrophic Total loss 10
and is obtained on a logarithmic scale by adding the fre-
quency and the severity indexes defined in [2.4.2] and
[2.4.3]: Table 12 : Severity index for the environment
Risk index = Frequency index + Severity index

Equivalent
Finally a risk matrix should be derived to obtain the final oil or chem-
Index Definition Environment
risk index. ical sub-
stance spill
2.4.5 Risk analysis outcome 1 Minor Local spill <1t
For each hazard, the risk index should be evaluated in order Significant
to identify the highest risks by considering separately the 2 Significant 1 - 100
local spill
impact on human, ship and environment. Example of risk
analysis outcome is given in Tab 13. Severe large 100 - 10
3 Severe
spill 000 t
Threshold for risk tolerance may be estimated for example
with regard to economic parameters. 4 Catastrophic Very large spill > 10 000 t

NI 641, Sec 2
Table 13 : Risk analysis outcome
Frequency Severity index Risk index

Hazard Consequence
index Human Ship Environment Human Ship Environment
Failure of ship's IT systems
Loss 3 1 4 1 4 7 4
(e.g. due to bugs)
Failure in position fixing
(due to e.g. GPS selective Collision 4 2 2 1 6 6 5
availability)
Low visibility Collision 7 2 2 1 9 9 8
Fire Loss 4 1 4 2 5 8 6
Table 14 : Risk Control Options
Category Risk Control Option

Design of SCC for a proper control and monitor.
Unmanned ship Suitable SCC manning as well as training of personnel.
and Ship Control
Absence of human is required on unmanned ship.
Centre
Ship should be directly controlled in heavy or complex traffic.
A ship without accommodation section is much easier to secure against stowaways in enclosed spaces.
Design of aboard systems for easy maintenance and accurate monitoring of maintenance state. Must also be
fast to repair.
Unmanned mainte- Need redundant power generation, distribution, propulsion and steering.
nance and technical
Automated fire extinguishing systems are required in all relevant areas.
operations
Note that no crew makes this simpler as areas are smaller and that CO2 can be used more safely.
Improved cargo monitoring and planning is required.
Heavy weather Software are to be able to avoid heavy or otherwise dangerous weather – use of weather routing.
Need good sensor and avoidance systems.
Sensors systems Selected systems must also be redundant so that a single failure does not disable critical functions identified
during the risk assessment.
Cybersecurity measures are important, including alternative position estimation based on non-GPS systems.
Cybersecurity The SCC may be particularly vulnerable.
Data communication links must also have sufficient redundancy.
2.5 Risk Control Options where choices are made in the design concept that
restrict the level of potential risk
2.5.1 Principles • procedural:
The Risk Control Options (RCO) should be determined to when operators control the risk by behaving in accor-
prevent the occurrence or to mitigate the consequences of dance with defined procedures.
an accident scenario.
Typical Risk Control Options for autonomous ships are
given as a guidance in Tab 14.
2.5.2 Risk Control Measures
The RCOs are constituted by a collection of Risk Control
Measure (RCM). Each potential RCM should be select100
3 Technology assessment
ed by considering one or more, but not limited to, the fol- 3.1 Reference
lowing attributes:
• preventive: 3.1.1 When the design and the reliability of a ship’s system
are not covered by any existing standard, a technology
when reducing the probability of the event assessment should be carried out.
• mitigate: The technology assessment should be based on the follow-
when reducing the severity of the outcome of the event ing methodologies:
• Risk Based Qualification of New Technology - Method-
• engineering:
ological Guidelines in the latest revision of the Bureau
where safety features (either built in or added on) are Veritas Guidance Note NI 525 and summarized in [3.3]
within the design • Independent Safety Assessment (ISA)
• inherent: • Goal Structuring Notation (GSN).

NI 641, Sec 2
3.2 General functions are based on a four-stage model of human infor-

mation processing and can be translated into equivalent
3.2.1 The risk assessment described in [2] is influenced by system functions (see Tab 16):
the level of confidence and the degree of autonomy existing
for the technologies used in systems for autonomous ships. a) information acquisition
The purpose of the technology assessment is to evaluate a b) information analysisML
level of confidence having an influence on the probability
of failure (impact on the frequency) and/or on the conse- c) decision and action selection
quences of this failure (impact on the severity). d) action implementation.
To increase or decrease the induced risk by a novel technol-
The four functions can provide an initial categorisation for
ogy, the level of confidence in this technology should be
types of tasks in which automation can support the human.
rated according to [3.3].
To estimate the impact of an autonomous system failure For a high level of autonomy the impact of a system error
using a novel technology, the level of autonomy should be will be predominant, whereas for a low level of autonomy,
defined according to [3.4]. the impact of an human error will be predominant.
3.3 Technology rating Table 15 : Technology rating
3.3.1 The novelty of the technology is rated taking into Application conditions
account both the level of maturity and the proposed condi- Technology maturity
Similar Different
tions of operation (see Tab 15).
Proven 0 1
3.4 Level of autonomy Limited references 1 2
3.4.1 The level of autonomy should be defined to make a Extrapolated from proven 2 3
distinction between the role of the human and the role of
the system among the various functions of the system. These New 3 3
Table 16 : Level of autonomy
Level of autonomy Definition Acquisition Analysis Decision Action

System
0 Human operated Human makes all decisions and controls all functions Human Human Human
Human
System suggests actions System
1 Human directed System Human Human
Human makes decisions and actions Human
System invokes functions System
2 Human delegated System System Human
Human can reject decisions during a certain time Human
System invokes functions without waiting for human System
3 Human supervised System System System
reaction Human
System invokes functions without informing the
4 Fully autonomous System System System System
human, except in case of emergency

NI 641, Sec 3
SECTION 3 GUIDELINES FOR FUNCTIONALITY OF

AUTONOMOUS SYSTEMS
1 General 2.3 References
2.3.1 The navigation system should be compliant with the

1.1 Scope applicable requirements and regulations related to the
assignment of the following additional class notation from
1.1.1 This Section provides guidelines for ensuring a suit- NR467 Rules for Steel Ships:
able level of functionality of systems associated with essen- • for integrated bridge system (SYS-IBS, see NR467 Pt F,
tial services involved in the operations of autonomous ships. Ch 4, Sec 2)
• for dynamic positioning with redundancy (DYNAPOS
For each autonomous system, a goal-based approach has AM/AT R, see NR467 Pt F, Ch 11, Sec 6).
been used to set a minimum level of functionality and asso-
ciated recommendations for the system design.
2.4 Voyage planning
2.4.1 The voyage plan describing the full voyage from

2 Navigation system departure to arrival and taking into account the charts and
weather forecasts should be defined and updated at any
2.1 Goal time by a shore-based operator.
2.4.2 The voyage plan should be established by defining

2.1.1 The goal of the Autonomous Navigation System waypoints, headings, turning angles and safe speeds the
(ANS) is to be able to navigate a ship safely and efficiently ship must follow during its voyage.
along a predefined voyage plan taking into account of traffic
and weather conditions. 2.4.3 Depending on the level of autonomy, the ANS should
be able to notify the SCC each time the ship is deviating
from the planned course and should send an alarm when
2.2 Functional requirements the deviation is out of specified margins. The tolerance in
the deviation should be set in accordance with the context
2.2.1 The Autonomous Navigation System should be (e.g. in heavy traffic or open sea) in order to avoid overload
of information for the supervisor.
responsible for all navigation-related matters with respect to
the legal framework. 2.4.4 In case the connection between ship and shore is
unavailable for a period of time, to be defined depending
2.2.2 The ANS should include SCC communication capa- on the level of autonomy, the ship is to enter into a fail-safe
bilities for remotely controlled or remotely supervised voy- sequence.
age planning and navigation. The purpose of this specific fail-safe sequence is to recover
a safe situation for the ship and may include the following
2.2.3 The ANS should be aware of traffic and weather con- stages to be considered with regard to the risk assessment:
ditions and should be able to make a modification of the a) operator attempts to take a manual control
navigation path accordingly while keeping the ship on the b) ship slows down to the next waypoint
pre-defined voyage plan.
c) ship stops and stays at the current position
2.2.4 The mooring and unmooring operations, as well as d) ship sails back to the previous waypoint.
the harbour navigation or port approach should be remotely
supervised or controlled in case the level of autonomy 2.5 Navigation
doesn’t allow a full autonomy for these operations.
2.5.1 The data from various ship’s sensors should be gath-
ered and evaluated in order to thoroughly determine the
2.2.5 In case of problems of connectivity, a fail-safe
location and heading of the ship. Redundant sensors and
sequence should be defined to put the ship in a safe situa- positioning by multiple sources should ensure a high degree
tion in accordance with the operating mode and the level of of data accuracy. The current speed and water depth should
autonomy (e.g. manoeuvring in harbor or at sea). be monitored as well.

NI 641, Sec 3
2.5.2 The data for navigational and weather forecast should 2.8.3 Combined with predefined parameters and taking
be retrieved from combined external sources such as the into account stability and maneuverability conditions a
SCC, AIS transceivers or data providers (Navigational Telex route optimization should be conducted under weather
NAVTEX, SafetyNET). routing criteria.
2.5.3 The ANS should identify the COLREG obligation of 2.9 Collision avoidance
the ship towards all objects in the vicinity and calculate
COLREG-compliant deviation measures for a given traffic
2.9.1 To navigate the ship safely and to be COLREG-com-
conditions.
pliant a continuous monitoring of the current traffic situa-
For path planning, solutions like sampling-based algorithms tion should be performed.
should be used. For collision avoidance, algorithms like
velocity obstacles should be used. 2.9.2 All traffic-related data should be combined and
assessed and possible future scenarios predicted.
2.5.4 When the level of autonomy requests supervision
during operations in harbour (e.g. docking and undocking) 2.9.3 As soon as a potential close quarters situation is iden-
or heavy traffic conditions near shore, land-based commu- tified, appropriate measures should be taken, such as:
nication networks should be used to provide a maximum
• reduce speed
availability and a minimum latency.
• predict and anticipate the obstacle’s motions
2.6 Ship status and dynamics • deviate from the initial ship’s path.
2.6.1 The ship status data should include position with dis- 2.10 Voyage recording
placement, draft, trim, ship motions within 6 degrees of free-
dom and information about propulsion and steering systems. 2.10.1 Data from essential ship processes (e.g. navigation,
Cargo monitoring should also be part of the ship status. machinery, propulsion or any significant process identified
during the risk assessment) should be received and stored in
2.6.2 The dynamics of the ship (velocities and acceleration) the log book. Situational data are similar to what is
should be predicted within a short time frame (less than 5 recorded by a VDR and should be complemented with
minutes) based on own ship’s characteristics as well as envi- expected or unexpected events or decisions.
ronmental conditions (e.g. wind, wave headings and fre-
quencies). 2.10.2 Data type regularly submitted to the SCC and their
associated intervals and amount should depend on the cur-
2.6.3 The weight distribution aboard the ship should be rent ship control mode (e.g. remote or fully autonomous).
calculated to determine the ship’s buoyancy and to control
the stability. 2.10.3 All log book data should be able to be retrieved
directly by the SCC at any time.
2.7 Lookout
2.11 Emergencies and alarm
2.7.1 The ship should independently gather weather data
from its own sensors. The accumulated data like wind speed, 2.11.1 Situations which are potentially threatening the
wave frequencies, should be used for subsequent weather safety of the ship should be managed with permanent and
routing and should be also stored and provided to the SCC. reliable means to inform the SCC and other ship’s processes
(e.g. fire alarms).
2.7.2 Navigational sensors aboard the ship should continu-
ously gather data to generate a complete traffic picture of 2.12 Devices used for situational awareness
the vicinity of the ship. Objects should be detected, identi-
fied and tracked. This traffic assessment should be sup-
2.12.1 Relevant input parameters for the process of autono-
ported by at least one CCTV system.
mous navigation should be provided by devices (e.g. sen-
sors) to have an accurate situational awareness, which
2.8 Weather routing provides the ANS with a perception of the vicinity of the
ship, including environmental conditions as well as with
2.8.1 The weather data which have been gathered by the target data for detected objects.
ship should be evaluated in comparison with weather fore- This perception should be done for example by using a sen-
casts which have been received from shore via the SCC. sor fusion-based approach where raw sensor data from
existing navigational sensors (e.g. data provided by LIDARs,
2.8.2 With this data combination a valid estimation of cur- cameras, radars and GNSS) are gathered, processed and
rent and upcoming weather conditions along the naviga- correlated among themselves to map a realistic representa-
tional and voyage plan of the ship should be made. tion of the ship’s environment.

NI 641, Sec 3
2.12.2 Special attention should be paid to the limitations 3.4.3 Line of sight communication systems should be
due to technical reasons and legal reasons (COLREGs). The mainly based on AIS or digital VHF systems with a range of
sensors should be able to detect floating or partly submerged at least two kilometers.
object of standard container size (typically several meters) in
a mid-range distance (typically less than one kilometer). 3.5 Performance
2.12.3 The sensors should be also capable of detection of a 3.5.1 Remotely controlled ship should require more com-
life raft or a person in the water in a short range distance munication bandwidth for operation than a conventional
(typically several hectometers). ship and should need several communication channels.
2.12.4 The sensors should be able to detect any limitation 3.5.2 Bandwidth and latency of the communication net-
in the operating range such as a reduced visibility (e.g. use work and system should be adequate for the traffic that is
of Circular Error Probability to detect uncertainties of object mainly oriented from ship to shore due to the amount of
position). data transmitted by the autonomous systems.
3.5.3 The minimum bandwidth and latency for various

3 Communication network and system types of data streaming are given as a guidance in Tab 1.
3.5.4 Methods for reducing the amount of data to only

3.1 Goal what is needed for human perception should be considered.
Such methods should be the reduction of the frame-rate, the
3.1.1 The goal of the communication network and system image resolution or an efficient image compression.
is to be available to transfer data externally (ship to shore,
ship to ship) and internally, without compromising their Table 1 : Minimum bandwidth and latency
integrity.
Data streaming Bandwidth (KBps) Latency (sec)
3.2 Functional requirements Ship to ship 2 0,05
3.2.1 Land-based and space-based communication system Remote control 2 1

should be used for the ship to shore communications. For Telemetry 32 1
ship to ship communications, a line of sight (LOS) commu- Radar images 75 1
nication system should be used.
Video (HD) 3000 2,5
3.2.2 The ship should include an efficient and secure net-
work for communication between systems internally and 4 Machinery system
externally.
4.1 Goal
3.2.3 The communication system should be designed to
operate with different level of communication quality and 4.1.1 The goal of the autonomous machinery system is to
should be resilient to a signal degradation. ensure that safety in all sailing conditions, including
manoeuvring is equivalent to that of a ship having machinery
3.3 References spaces manned.
3.3.1 The communication network and system should be 4.2 Functional requirements
compliant with the applicable requirements from IEC
61850-90-4 Network Engineering. 4.2.1 The autonomous machinery system should control
and monitor the propulsion plant and steering system.
3.4 Type of communication system 4.2.2 The autonomous machinery system should mitigate
the impact of emergency situations such as fire and flooding.
3.4.1 For external communication, in order to maintain a
correct level of availability in case of failure, backup 4.2.3 A maintenance plan should be developed for an
arrangement is to be provided for the transmission of critical extensive period of time and should include adequate pre-
data. In the event of a failure, an automatic transition ventive actions for limiting periodic maintenance tasks.
between the main and the backup solution should be pro-
vided, and an alarm should be triggered. A solution should 4.3 References
be to use two independent communication systems, for
example the Iridium system and a VSAT system operating 4.3.1 The machinery system should be compliant with the
outside the L-band. applicable requirements and regulations related to the
assignment of the following additional class notation from
3.4.2 Different frequency bands should be used in order to NR467 Rules for Steel Ships:
minimize the risks of disturbance of signals due to atmo- • for integrated machinery spaces (AUT-IMS see NR467
spheric effects (e.g. fading due to heavy rain). Pt F, Ch 3, Sec 4)

NI 641, Sec 3
• for automated operation in port (AUT-PORT see NR467 5.2 Functional requirements
Pt F, Ch 3, Sec 3)
• for availability of machinery (AVM-IPS see NR467 Pt F, 5.2.1 The autonomous cargo management system should
Ch 2, Sec 3). collect and monitor the main cargo parameters.
5.2.2 The loading and unloading sequences should be

4.4 Monitoring properly handled by the autonomous cargo management
system.
4.4.1 The machinery system should be able to collect and
analyse information about operating condition and health
condition from, but not limited to, the main engine, engine 5.3 References
for auxiliary systems and shafting. A visual monitoring
should be provided by at least one CCTV system. 5.3.1 The cargo management system should be compliant
with the applicable requirements and regulations related to
4.4.2 The data from diagnostics should be transmitted, the assignment of the following additional class notation:
recorded and documented in a suitable format to be used • for liquid cargo in bulk (CARGOCONTROL, see NR467
by the remote controller or the supervisor. Pt F, Ch 11, Sec 9)
• for liquid cold cargo (COLD CARGO, see NR467 Pt F,
4.5 Maintenance Ch 11, Sec 11)
4.5.1 The machinery system should be designed to allow • for refrigerated cargo (REF-CARGO, see NR467 Pt F, Ch
an extended period of time without any physical interfer- 7, Sec 2).
ence in the machinery spaces (e.g. 500 hours).
5.4 Monitoring
4.5.2 Based on the condition assessment of the machinery,
the system should suggest or take corrective actions for the 5.4.1 The cargo parameters should be collected and anal-
prevention of machinery failure. Instead of a condition- ysed by means of sensors installed in the cargo hold, within
based maintenance, systematic preventive maintenance the carrying device or directly on the cargo. A visual moni-
should also be adopted. toring should be provided by at least one CCTV system.
4.5.3 Information on the need for spare parts that enable 5.4.2 The temperature, the pressure, the gas, the water
ordering in advance should be delivered to the operator. incoming, the cargo shifting, are the main parameters that
should be monitored.
4.6 Emergency management
5.4.3 An alarm system able to issue warning or alert to the
4.6.1 An alarm system should be provided to allow identifi- operator should be provided for the detection of abnormal
cation of faults in the machinery and should be able to values for each cargo parameter.
communicate with a remote SCC.
5.5 Control
4.6.2 The alarm system should be triggered by sensors such
as IR-cameras, water inrush detectors, gas and fire detectors.
5.5.1 Means should be provided to automatically control
the cargo parameters, such as for heating, cooling, ventilat-
4.6.3 In case of the detection of an emergency situation, ing or pumping.
the system should be able to automatically activate means
to recover a safe situation or at least to mitigate the damages
(e.g. automatic change-over). 5.6 Loading and unloading
4.6.4 Fire fighting systems or pumps should be able to start 5.6.1 During the loading and unloading sequences, the
automatically upon the request of the system or the opera- autonomous cargo management system should monitor the
tor. Means should be provided to prevent any inadvertent cargo capacity, the ballast water, the ship’s structural
starting of fire fighting systems. strength and the stability (loads induced by the cargo).
5 Cargo management system 6 Passenger management system
5.1 Goal 6.1 Goal
5.1.1 The goal of the autonomous cargo management sys- 6.1.1 The goal of the passenger management system is to
tem is to ensure that cargo does not compromise the safety ensure the safety of passengers during a voyage on autono-
of the ship or not degrade the environment. mous ships.

NI 641, Sec 3
6.2 Functional requirements 7 Shore control centre

6.2.1 The passenger management system should prevent
any overload due to an exceedance of the ship’s capacity. 7.1 Goal
6.2.2 During boarding and un-boarding sequences, the 7.1.1 The goal of the Shore Control Centre is to be able to
passenger management system should prevent any passen- continuously control and monitor several autonomous ships
ger from injury. of the same or different type.
6.2.3 In case of a critical incident (e.g. man overboard), the
passenger management system should provide means for 7.2 Functional requirements
alerting and rescuing.
7.2.1 The SCC system should be designed for displaying
6.2.4 All systems onboard should be designed to avoid any
suitable information, facilitate the decision making process
deliberate or unwilled interference or obstruction by a pas-
and remote control for the operator.
senger.
7.2.2 The SCC system should provide means of communi-

6.3 References cations with the autonomous ships and any other decision
centre taking part in the operation of the ship.
6.3.1 The passenger management system should be compli-
ant with the applicable requirements and regulations of
SOLAS, in particular those from Chapter III about Life-saving 7.2.3 The SCC should be designed and operated in accor-
appliances and arrangements. dance with land-based regulations.
6.4 Overload prevention 7.3 Means of communication
6.4.1 In order to prevent the overload, a system should be 7.3.1 The SCC should be linked to the ship, to the Vessel
provided to determine the number of passenger with regard Traffic Services (VTS), to the port authorities or the shipping
to the capacity of the ship. This system should be arranged company by using communication technologies that are
prior to the boarding stage of the passengers. available (e.g. GSM, WiMax, VHF or satellite).
6.4.2 In order to ensure that the ship has sufficient free-
board, an alarm should be installed and triggered when the 7.4 Control and monitoring
waterline exceed the load line.
7.4.1 The SCC should be able to plan and to upload voyage
6.4.3 The ship’s capacity should be estimated by a maxi-
data to the ship.
mum number of person and/or approximate weight. This
estimation should take into account a safety margin for addi-
tional weight per passenger (e.g. due to luggage, bicycle...). 7.4.2 The SCC operator should be able to easily identify
operational abnormalities, unexpected threats and errors
efficiently in a highly automated context and then commu-
6.5 Boarding sequence nicate this situation to other stakeholders in the SCC.
6.5.1 The docking and undocking procedures should be

monitored by sensors (e.g. pressure sensors, radar...) to con- 7.4.3 It is recommended to gather essential information on
one dashboard for each ship under control.
firm that there are no obstacles for the safe progress.
6.5.2 In case the system is not able to detect a situation of 7.4.4 In addition to have a clear visibility around the ship
danger, an emergency push button should be accessible to as requested by SOLAS Ch V reg 22 (Navigation bridge visi-
the passengers to stop the sequence. bility), the dashboard should also include sea chart, radar
screen and weather chart.
6.6 Life saving
7.4.5 The dashboard should display an information panel
6.6.1 The life saving appliances should be stowed in order summarizing the essential systems to have a clear view of
to be accessible for all passengers and should be designed the situation of the ship (e.g. navigation, machinery, cargo),
to be simple to use. A convenient solution should be for with for each of them, a coloured flag indicator:
each passenger to wear a life jacket.
• green for normal situation
6.6.2 In case of a passenger overboard, an alarm should be • yellow for warning that require operator attention and
accessible to the passengers onboard (emergency push but- verification
ton) and/or should be activated by the passenger in the
water (radio or water activated) to maintain the ship near • red for alert that require operator’s immediate corrective
the actual position and to alert the rescue team. actions.

NI 641, Sec 3
7.5 Manning 7.5.2 Manning of shore control centre should include

properly qualified personnel such as operators, supervisors,
7.5.1 The SCC should be manned for uninterrupted super- ship engineers and captains.
vision during operations of autonomous ships. Personnel should have sufficient sea-going or in service
A chain of SCCs around the world could alternate in con- experiences related to an equivalent ship under control.
trolling a ship always making sure the center in control have Simulator training should be used for practicing of operators
daylight hours, to avoid night shifts with increased risk of and supervisors.
accidents.
Taking into account the fatigue due to the large time spent
on computer’s screen, the proportion between rest and duty
periods should be arranged to ensure the efficiency of the
watchkeeping.

NI 641, Sec 4
SECTION 4 GUIDELINES FOR RELIABILITY OF

AUTONOMOUS SYSTEMS
1 General 2.4 Network failure
2.4.1 When the systems are interconnected through a net-

1.1 Scope work, failure of the network should not prevent individual
system from performing its functions.
1.1.1 This Section provides guidelines for improving the
reliability of systems associated with essential services
involved in the operations of autonomous ships.
2.5 Power failure
2.5.1 The system should be arranged with an automatic

2 General system design change-over to a continuously available stand-by power
supply in case of loss of normal power source.
2.1 References 2.5.2 The capacity of the stand-by power supply should be
sufficient to allow the normal operation of the system for at
2.1.1 The computerized based system lifecycle should be least half an hour.
based on the following international standards:
• ISO/IEC 15288:2015 Systems and Software Engineering 3 Human machine interface
- System Lifecycle Processes
• ISO/IEC 12207:2008 Systems and Software Engineering 3.1 References
- Software Lifecycle Processes
• ISO/IEC 61508:2010 (all parts) Functional safety of elec- 3.1.1 The ergonomics, the layout and interfaces of the sys-
trical/electronic/programmable electronic safety-related tem should be based on the following international stand-
ards:
systems.
• ISO 9241-210:2010 Ergonomics of human-system inter-
action - Part 210: Human-centred design for interactive
2.2 Risk-based design systems
2.2.1 A risk-based design approach (failure analysis) should • ISO 8468:2007 Ships and marine technology - Ship's
be adopted to identify, evaluate and mitigate the effects of a bridge layout and associated equipment - Requirements
system failure. The methodology should be based on a Fail- and guidelines
ure Mode Effects and Criticality Analysis (FMECA). • ISO 2412:1982 Shipbuilding - Colours of indicator
lights
2.2.2 The boundaries of the system should be clearly iden-
• IMO A.1021(26) Code on alerts and indicators.
tified with all critical components that may affect the safety
of operations.
3.2 Design
2.3 Component failure 3.2.1 The human machine interface should be designed to
be easily understood in a consistent style. Particular consid-
2.3.1 The system should be designed in such a way that a eration should be given to:
failure of one component should not affect the functionality
of other components except for those functions directly • symbols
dependent upon the information from the defective compo- • colours
nent. • controls
2.3.2 System and software should be fault tolerant and • information priorities
providing an acceptable level of resilience against unex- • layout.
pected failure.
3.2.2 System’s controls and indicators should be designed
2.3.3 This resiliency should be achieved by using an with due regard to the human operator. Controls and indi-
appropriate redundancy on the system’s critical compo- cators are to be so constructed that they can be efficiently
nents (e.g. power supply, communication equipment). operated by suitably qualified personnel.

NI 641, Sec 4
3.3 Information display 4 Network and communication

3.3.1 Continuously displayed information should be
reduced to the minimum necessary for safe operation. Sup-
4.1 References
plementary information should be readily accessible.
4.1.1 The network components and communication equip-
3.3.2 Operational information should be presented in a ment should be designed in accordance with the following
readily understandable format without the need to trans- standards:
pose, compute or translate. • IEC 61162:(all parts) Maritime navigation and radio-
communication equipment and systems - Digital inter-
3.3.3 Displays and indicators should present the simplest faces
information consistent with their function.
• IMO MSC.252(83) Performance Standards for Integrated
Navigation Systems (INS).
3.3.4 All information required by the user to perform an
operation should be available on the current display.
4.2 Design
3.3.5 The human machine interface should use marine ter-
minology. 4.2.1 Permanent and reversible communication system
between ship and shore should be available. The network
should be designed to enable a permanent collection of
3.4 Controls and indicators
data aboard and its availability for subsequent transmission.
3.4.1 The number of operational controls, their design
4.2.2 The network components and communication equip-
manner of function, location, arrangement and size should
ment should be type approved products.
be provided for a simple, quick and effective operation.
4.2.3 Transmission protocol should be in accordance with
3.4.2 All operational controls should permit normal adjust-
a recognised international standard. Satellite communica-
ments to be easily performed and should be arranged in a
tion provider should be recognized by International Mari-
manner which minimises the possibility of inadvertent oper-
time Satellite Organisation (IMSO).
ation. Controls not required for normal operation should
not be readily accessible.
4.2.4 The network should have the capacity to transmit the
required amount of data with a margin for overload without
3.4.3 Feedback timing should be consistent with the task
compromising the data integrity.
requirements. There should be clear feedback from any
action within a short time. When a perceptible delay in
4.2.5 Wireless data communication should employ recog-
response occurs taking into consideration the communica-
nised international wireless communication system that
tion latency, visible indication should be provided.
incorporate the following features:
3.4.4 Warning and alarm indicators should be designed to a) message integrity:
show no light in normal position that is an indication of a
fault prevention, detection, diagnosis, and correction so
safe situation. Colour coding of functions and signals
that the received message is not corrupted or altered
should be in accordance with international standards.
when compared to the transmitted message
3.4.5 Indications, which may be accompanied by a short b) configuration and device authentication:
low intensity acoustic signal, should occur on the user dis-
shall only permit connection of devices that are
play when an attempt is made to execute an invalid func-
included in the system design
tion or use an invalid information.
c) message encryption:
3.4.6 In case of an input error, the system is to require the
protection of the confidentiality and or criticality the
operator to correct the error immediately.
data content
3.4.7 The system should indicate default values when d) security management:
applicable.
protection of network assets, prevention of unauthorised
access to network assets.
3.5 User training
4.2.6 The network is to be self-checking, detecting failures
3.5.1 Training should be provided to the personnel and on the link itself and data communication failures on nodes
should be carried using suitable material and methods to connected to the link. Detected failures are to initiate an
cover the following topics: alarm.
• general understanding and operation of the system
4.2.7 The network devices should be automatically started
• mastering of uncommon conditions in the system. when power is turned on, or restarted after loss of power.

NI 641, Sec 4
4.3 Performance 5.2.2 The quality plan should include the test procedure for
software and the results of tests should be documented.
4.3.1 A means of transmission control should be provided
and designed so as to verify the completion of the data
transmitted (CRC or equivalent acceptable method). When 5.3 Testing
corrupted data is detected, the number of retries should be
limited so as to keep an acceptable global response time. 5.3.1 Software should be tested in association with hard-
ware and evidences of testing should be produced accord-
4.3.2 All data should be identified with a priority level. The ing to the quality plan.
transmission software should be designed so as to take into
consideration the priority of data. 5.3.2 The software modules of the application software
should be tested individually and subsequently subjected to
4.3.3 Missing or corrupted data transmitted through the
an integration test. It should be checked that:
network should not affect functions which are not depend-
ent on this data. • the development work has been carried out in accord-
ance with the quality plan
4.3.4 When a hardware or software transmission failure
occurs, it should be detected by the transmitter and the • the documentation includes the method of testing, the
recipient which should activate an alarm. test programs producing, the simulation, the acceptance
criteria and the results.
4.3.5 A means should be provided to verify the activity of
transmission and its proper function (positive information).
5.3.3 Software module tests should provide evidence that
each module performs its intended function and does not
4.4 Redundancy perform unintended functions.
4.4.1 Except if the availability of the connection can be

5.3.4 The behaviour of a machine-learning system is
demonstrated in the event of a failure, all transmission
dependent on the training set used during the learning
equipment should be duplicated or have a secondary
phase of the system. It is recommended to use an extensive
means which is capable of the same transmission capacity,
training set in order to cover a maximum number of poten-
with an automatic commutation from one to the other.
tial situations.
4.4.2 Functions that are required to operate continuously The consistency of the behaviour of a machine-learning sys-
to provide essential services dependent on wireless data tem should be tested (repeatability). In particular to be sure
communication links should have an alternative means of that after a long period, the behaviour of the system is not
control that can be brought in action within an acceptable modified and is always responding in the same way.
period of time.
When testing a machine-learning system, the test data
5 Software quality assurance should include some exceptional conditions, in order to
validate the behaviour of the system and to detect any devi-
ation from the expected behaviour.
5.1 References
5.1.1 The software quality assurance should be based on 5.3.5 System or subsystem testing should verify that mod-
the following international standards or industry guidelines: ules interact correctly to perform the functions in accord-
ance with specified requirements and do not perform
• IMO MSC.1-CIRC.1512 Guidelines on Software Quality unintended functions.
Assurance and Human-Centred Design for E-Navigation
• ISO 10007:2003 Quality management systems - Guide- 5.3.6 Repetition tests should be required to verify the con-
lines for Configuration Management sistency of test results.
• ISO/IEC 90003:2014 Software engineering - Guidelines
for the application of ISO 9001:2008 to computer soft- 5.3.7 Faults should be simulated as realistically as possible
ware to demonstrate appropriate software fault detection and
• Bureau Veritas BV SW100 - Software development and software response.
assessment guidelines.
5.1.2 The software quality assurance is to comply with the 5.4 Configuration management
requirements of NR467 Pt C, Ch 3, Sec 3.
5.4.1 A software maintenance should be in place to man-
5.2 Quality plan age failure due to software change and in case of wrong
interaction with existing software from other systems.
5.2.1 The software development should be carried out
according to a quality plan defined by the software provider 5.4.2 Software change should be the responsibility of qual-
and records are to be kept. ified and authorised member (e.g. chief engineer).

NI 641, Sec 4
6 Data quality assurance 6.4.3 The data storage should have a backup feature (e.g.
automatic duplication) and should be fault-tolerant (e.g.
due to power failure).
6.1 References
6.1.1 The data quality assurance should be based on the 6.5 Data authentication
following international standards:
• ISO 8000: Data quality 6.5.1 The authentication of data should be possible each
time it is requested by the system, by using a mechanism
• ISO/IEC 10181: Information technology - Open Systems
such as a digital signature or a secure protocol.
Interconnection - Security frameworks for open systems.
6.2 Data quality assessment 6.6 Data integrity
6.2.1 The data quality assessment should be carried on the 6.6.1 Data integrity (unaltered data) should be preserved by
following measurements: providing means of protection from unauthorised access,
the data should carry an internal data checksum against
• completeness:
deliberate or unintentional modifications.
all necessary data are recorded
• uniqueness:
6.7 Data confidentiality
no data will be recorded more than once
• timeliness: 6.7.1 Data confidentiality should be maintained by using
the degree to which data represent reality from the means of encryption and an adequate level of authorisation
required point in time for access in consultation of the data storage.
• validity:
data are valid if it conforms to the syntax (format, type, 7 Cybersecurity
range) of its definition
• accuracy: 7.1 References
the degree to which data correctly describes the «real
world» object or event being described 7.1.1 The cybersecurity should be managed by using the
following international standards or industry guidelines:
• consistency:
• ISO/IEC 15408:2009 Information technology -Security
the absence of difference, when comparing two or more
techniques - Evaluation criteria for IT security
representations of a data item against its definition. It is
possible to have consistency without validity or accuracy. • ISO/IEC 27001:2013 Information technology -Security
techniques - Information Security Management Systems
6.3 Data acquisition • IMO MSC.CIRC.1526 Interim Guidelines on Maritime
Cyber Risk Management
6.3.1 For the data acquisition, the location and the selec-
• National Institute of Standards and Technology (NIST)
tion of the sensors should be done so as to measure the
Framework for Cybersecurity (2014)
actual value of the parameters. Temperature, vibration and
electromagnetic interference levels should be taken into • ANSSI Best Practices for CyberSecurity On-board Ships
account. The sensors should be designed to withstand the • Bureau Veritas - BV SW 200 - Cybersecurity Guidelines
local environment. for Software Development & Assessment.
6.3.2 Means should be provided for testing, calibration and In addition, the requirements for the cybersecurity from the
replacement of sensors. Such means should be designed, as additional class notation SYS-COM (see NR467, Pt F, Ch 4,
far as practicable, so as to avoid perturbation of the normal Sec 3) should be considered.
operation of the system.
6.3.3 Low level signal sensors should be avoided. When

7.2 Cyber protection
installed they should be located as close as possible to
7.2.1 The following functions should be in place to organize
amplifiers, so as to avoid external influences.
the cyber protection:
6.4 Data storage • identify:

define personnel roles and responsibilities for cyber risk
6.4.1 The data storage should be suitable for the amount of management and identify the systems, assets, data and
collected data. In case of overcapacity, a mechanism should capabilities that, when disrupted, pose risks to ship
be provided to remove unnecessary or obsolete data and to operations,
recover to a normal situation.
• protect:
6.4.2 When the data storage is based on a network or dis- implement risk control processes and measures, and
tributed system (e.g. storage in the cloud), consequences of contingency planning to protect against a cyberevent
the outage of the provider should be considered. and ensure continuity of shipping operations,

NI 641, Sec 4
• detect: 7.4.3 Software updates should be performed regularly fol-

lowing an update policy. This policy should include:
develop and implement activities necessary to detect a
• the list of components (machine and software) to be
cyber event in a timely manner,
updated
• respond: • the responsibilities of the various actors in the updating
process
develop and implement activities and plans to provide • the means used to obtain and assess updates
resilience and to restore systems necessary for shipping
• a verification of the updates prior to the installation
operations or services impaired due to a cyberevent,
• a procedure to recover previous configuration in case of
• recover: update failure.
identify measures to back-up and restore cyber systems 7.4.4 In case of an automatic download and installation
necessary for shipping operations impacted by a cyber- from internet or e-mail, the software patches should be
event. retrieved from trusted sources (preferably from genuine soft-
ware provider).
7.3 Identification 7.4.5 The network and especially wireless network should
be protected by using secure protocols such as encrypted
7.3.1 An accurate map of the IT installations should be transmissions.
established and should be regularly updated. 7.4.6 The internet connection should be secured by a gate-
way enabling compartmentalisation between internet
7.3.2 This map should describe the network architecture access and the internal network.
and include a list of equipment (identified by a model num-
ber) and software (identified by a version number). 7.5 Detection
7.3.3 An inventory of all users accounts with the associated 7.5.1 Monitoring should be in place to detect abnormal
privileges should reflect the actual level of authorization events or intrusion such as massive data transfers (depend-
given to each user. ing on usual operating modes), several log-in failures to an
active or inactive account.
7.4 Protection 7.6 Response and recovery
7.4.1 User access management should be based on a 7.6.1 In the event of an incident, a contingency plan
should be defined for working in downgraded mode. The
secure authentication protocol including best practises such
first measure should be to isolate all infected machines from
as avoidance of generic or anonymous accounts, a regular
the network. For each incident, a feedback should be capi-
password change with a required high level of complexity.
talised in order to be more effective in dealing with a similar
event in the future.
7.4.2 Procedures for arrival and departure of users (man-
agement of accounts, access to SCC or sensitive documen- 7.6.2 Essential information and software backup facilities
tation) should be created and followed. should be available for recovering to a clean system.

NI 641, Sec 4

641 Ni - 2017 12 PDF

Uploaded by

Copyright:

Available Formats

641 Ni - 2017 12 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

641 Ni - 2017 12 PDF

Uploaded by

Copyright:

Available Formats

Guidelines for

Marine & Offshore

Guidelines for Autonomous Shipping

SECTION 2 RISK AND TECHNOLOGY ASSESSMENT

SECTION 3 GUIDELINES FOR FUNCTIONALITY OF AUTONOMOUS SYSTEMS

SECTION 4 GUIDELINES FOR RELIABILITY OF AUTONOMOUS SYSTEMS

Section 2 Risk and Technology Assessment

Section 3 Guidelines for Functionality of Autonomous Systems

2 Bureau Veritas December 2017

3 Communication network and system 17

5 Cargo management system 18

6 Passenger management system 18

7 Shore control centre 19

December 2017 Bureau Veritas 3

4 Bureau Veritas December 2017

1 General • Cybersecurity: preservation of confidentiality, integrity

• Reliability: property of a system and its parts to perform

December 2017 Bureau Veritas 5

• System: combination of interacting elements organized LOS : Line Of Sight

Table 1 : Ship categories and level of autonomy

6 Bureau Veritas December 2017

December 2017 Bureau Veritas 7

2.6 Cybersecurity • Reg.34: Safe navigation and avoidance of dangerous sit-

8 Bureau Veritas December 2017

SECTION 2 RISK AND TECHNOLOGY ASSESSMENT

1 General 2.2 Model of autonomous ship

2.2.1 At the first stage of the risk assessment, the systems of

2 Risk assessment 2.3 Hazards identification

2.1.2 Stages 2.3.3 Navigation

December 2017 Bureau Veritas 9

Table 1 : Hazards for the voyage

Table 2 : Hazards for the navigation

Table 3 : Hazards for the detection

Table 4 : Hazards for the safety and emergency

10 Bureau Veritas December 2017

2.3.6 Security 2.3.8 Passenger management

2.3.7 Ship strength and stability 2.3.9 Technical infrastructure

Table 5 : Hazards for the security

Table 6 : Hazards for the ship strength and stability

Table 7 : Hazards for the passengers

Table 8 : Hazards for the technical infrastructure

December 2017 Bureau Veritas 11

Table 9 : Frequency index

2.4 Risk analysis Table 10 : Severity index for the human

2.4.1 Principles Equivalent

Risk index = Frequency index + Severity index

12 Bureau Veritas December 2017

Table 13 : Risk analysis outcome

Frequency Severity index Risk index

Table 14 : Risk Control Options

Category Risk Control Option

December 2017 Bureau Veritas 13

3.2 General functions are based on a four-stage model of human infor-

3.3 Technology rating Table 15 : Technology rating

Table 16 : Level of autonomy

Level of autonomy Definition Acquisition Analysis Decision Action

14 Bureau Veritas December 2017

SECTION 3 GUIDELINES FOR FUNCTIONALITY OF

1 General 2.3 References