ISO 16425:2013

INTERNATIONAL ISO
STANDARD 16425
First edition
2013-02-01
Ships and marine technology —
Guidelines for the installation of
ship communication networks for
shipboard equipment and systems
Navires et technologie maritime — Lignes directrices pour
l’installation de réseaux de communication des navires pour les
équipements et systèmes embarqués
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the
address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviations. 3
5 Network system architecture . 3
5.1 Network system design . 3
5.2 Network interface for shipboard equipment and systems . 5
5.3 Equipment constituting communication network system . 6
6 Data requirements . 8
6.1 General . 8
6.2 Meaning of data and description of structure . 8
6.3 Data attribute definitions .10
6.4 Data delivery format .11
7 Network administration requirements .12
7.1 Network administration requirements and definitions .12
7.2 Network administration scope .12
7.3 Network administration items .13
7.4 Requirements for network monitoring devices .13
7.5 Requirements for network nodes .14
8 Operational guidelines .15
8.1 Notes for network operations .15
8.2 Notes for exchanging data .16
8.3 System maintenance .17
9 Installation procedure .17
9.1 General .17
9.2 Network installation procedure .17
9.3 Cabling procedure for network cables .21
9.4 Network testing procedure .22
10 Testing .24
10.1 General .24
10.2 Testing procedure .24
10.3 Network device connection testing .25
10.4 Inter-node connection testing .26
10.5 Testing of network monitoring devices and functionality .26
Annex A (informative) Implementation of the content provided in this International Standard .28
Bibliography .61
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 16425 was prepared by Technical Committee ISO/TC 8, Ships and marine technology, Subcommittee
SC 6, Navigation and ship operations.
iv © ISO 2013 – All rights reserved

Introduction
This International Standard gives guidelines relating to such matters as the communication network-
system architecture, data requirements, administration, operation, commissioning, inspection and testing.
This International Standard also takes into account differences between shipboard communication
networks and networks that are used outside of ships, and stipulates requirements and the like in
clauses relating to matters unique to shipboard use.
Until now, there have not been comprehensive guidelines for connecting devices provided by many different
manufacturers to a network via generic means, and this has impeded the wider use of shipboard networks.
This International Standard will make it possible to provide guidelines for all aspects of communication
network-system design, commissioning, inspection, testing and operation, and improve convenience to
all involved parties, including manufacturers, engineering firms, shipbuilders, and shipping companies.
This communication network for shipboard equipment connects equipment, and shares information
gathered from shipboard equipment and systems via a network. This communication network is connected
to the navigational equipment network and engine-control network via an appropriate gateway.
The independence of such a network is ensured by using a gateway.
This network is intended for information sharing and is not directly related to safety of navigation. Also,
it is not a system targeted for classification rules.
Additionally, Annex A is attached to provide detailed examples of technical information that serve as
guidelines for some difficulties caused when the information network system is designed.
NOTE Requirements for wireless communication systems, which serve as an effective method of
onboard wireless communication, is specified in IEEE 802.11, and national laws are established based on the
aforementioned IEEE in each country. Different frequency and output range are allotted by each country, and
regulations exist for such frequencies and ranges in some countries. Given the circumstances, it is possible that
wireless communication systems cannot be used when calling at a port. Therefore, wireless communication
systems are outside the scope of this International Standard.
INTERNATIONAL STANDARD ISO 16425:2013(E)
Ships and marine technology — Guidelines for the
installation of ship communication networks for shipboard
equipment and systems
1 Scope
This International Standard specifies installation guidelines for ship communication networks for
improving communication for shipboard equipment and systems that are independent from navigational
equipment networks and engine-control networks.
This International Standard utilizes existing standards relating to protocols, and provides new
guidelines for such aspects as communication network-system architecture, administration, operation,
and installation.
The new guidelines specifically include: redundancy if necessary for a shipboard communication
network system; network administration that does not require experts; physical as well as logical
security; and network installation.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
IEC 61162-450, Maritime navigation and radio communication equipment and systems — Digital
interfaces — Part 450: Multiple talkers and multiple listeners — Ethernet interconnection
IEEE 802.3, Ethernet (Formerly: Carrier Sense Multiple Access with Collision Detection)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
network
communication network restricted in scope to a ship
3.2
XML
eXtensible Markup Language
meta language for sending and receiving data via a network that is recommended by the WWW Consortium
3.3
gateway
communication device that connects computer networks to networks with differing protocols
3.4
collision domain
domain in a computer network where simultaneous transmission will cause collisions or congestion
3.5
broadcast domain
domain on a computer network where broadcasted frames (broadcasts) are received
3.6
STP
spanning tree protocol
method of control in a loop topology network for preventing data from entering endless loops
3.7
IP
internet protocol
protocol for sending and receiving information via the Internet
3.8
OSI reference model
Open Systems Interconnection reference model
model that divides the communication functions stipulated for computers by the International
Organization for Standardization into layers
3.9
SNMP
Simple Network Management Protocol
communication rules that define methods for communicating information in order to monitor and
control network devices on network
3.10
ICMP
Internet Control Message Protocol
communication rules that are used for such purposes as notifications of errors in the processing of
datagrams, and notifications of information relating to communication
3.11
MIB
Management Information Base
type of database for managing devices in a network
3.12
port trunk
method of raising transmission speed by governing two or more physical cables
3.13
VLAN
Virtual LAN
method for configuring a network virtually, regardless of the physical network configuration
2 © ISO 2013 – All rights reserved

4 Abbreviations
UTC Universal Time, Coordinated
RSTP Rapid Spanning Tree Protocol
CSMA/CD Carrier Sense Multiple Access/Collision Detection
QoS Quality of service
RIP Routing information protocol
OSPF Open shortest path first
CD Compact Disc
DVD Digital Versatile Disc
ECR Engine Control Room
BR Bridge
RM Room
GEN General
E/R Engine Room
C/R Control Room
IGMP Internet Group Management Protocol
ASCII American Standard Code for Information Interchange
MAC Media Access Control
VPN Virtual Private Network
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol over Secure Socket Layer
UTP Unshield Twisted Pair
5 Network system architecture
5.1 Network system design
The design of this network system shall give due consideration to such matters as the compatibility of
the various devices in the network as a whole, and data transmission (amount of information, latency,
and routes). Consequently, a network-system designer should have a grasp of the overall system,
comprehensive knowledge, and consideration for shipboard use.
When designing the network system, the effective data volume and network load factor should be pre-
calculated when the network media are under maximum load. In addition, provision should be made for
further network expansion and increase of the data traffic.
The design shall also foresee the various potential system states, including initial state, failure state,
and normal state, in order to define which communication is to be granted in various failure scenarios.
The network diagrams shall be equipped on the vessel. When the network design is changed, the
network-system designer shall retest the network and update the network diagrams.
As a data requirement, it is extremely vital to consider such factors and to prevent ship equipment
connected to the network that does not send or receive data from being excessively impacted.
Data requirements are specified in 6.2 and 6.3.
5.1.1 Scope of network system architecture
This network system shall be designed specifically for ships, with the purpose of sharing information
between shipboard devices. It shall be independent from navigational equipment networks and engine-
control networks.
The scope of the network system’s architecture is not limited to the bridge. It extends to all key
locations on the ship.
The network shall not operate (control) the ship’s navigational equipment, however it should allow
monitoring of navigational equipment.
Figure 1 shows a sample network-architecture scope. The typical implementation of the contents
provided in this International Standard is specified in Annex A.
NOTE The following are some examples of areas within the scope of the network-system architecture:
-Navigation Bridge / Control Centre;
-Captain’s Office;
-Officer’s Office;
-Officer’s Mess;
-Captain’s Cabin;
-Officer’s Day Room;
-Engine Control Room;
-Engine Room;
-Cargo Control Room;
-Field / Cargo.
5.1.2 Network system separation
The network system shall be separated from other networks by an L3 switch so that it will not be
adversely affected by failures on other networks. The routing and filtering rules should be configured
appropriately on the L3 switch for traffic and security. For more advanced security, a firewall for the
upper layer may be used.
5.1.3 Network division
The network shall be divided into sub-networks (the broadcast domains) depending on the types of
information handled, in order to control traffic and ensure security. In order to ensure the security and
the control of traffic, the network shall be logically segregated to form sub-networks, depending on the
4 © ISO 2013 – All rights reserved

type of information to be handled. Each network should be designed so that network soundness can be
maintained at all times, including when failures occur on other sub-networks.
NOTE The following are some examples of sub-networks formed from the main network:
-Navigational data collection sub-network;
-Engine data collection sub-network;
-Shipboard telephone sub-network;
-Imaging sub-network;
-General shipboard document-review sub-network.
5.1.4 Traffic division
The network shall be built to minimize the collision domain (the scope of packet collisions), and
appropriately divide the broadcast domain (the domain reached by broadcasts).
The bandwidth used by the core network shall be designed appropriately, and a logical network system
shall be built in order to use the network bandwidth more efficiently.
In order to utilize the network’s available bandwidth efficiently, the logical network shall use a virtual
LAN (VLAN) architecture, which forms the network from a virtual group that does not depend on the
type of physical connections.
During ordinary use, the target traffic on a sub-network should preferably be around 25 % when using
half-duplex, and 50 % when using full-duplex communication.
5.1.5 Redundancy
The connections within the network system shall use a redundant architecture that guarantees that
information will be transmitted without failure. A loop architecture should be used for connections
between sub-networks, employing such architecture as a rapid spanning tree protocol (RSTP) that
should act as a spanning tree to quickly route around connection failures.
Using separate routes from the vessel’s port and starboard systems for the network’s connection cabling
is also an effective way to prevent simultaneous network-connection failures.
5.2 Network interface for shipboard equipment and systems
5.2.1 Interface
The network system shall use the IEEE 802.3 Ethernet standard that is most frequently used for
computer networks: Carrier Sense Multiple Access/Collision Detection (CSMA/CD).
The network shall also use the standard communication network internet protocol defined by this
International Standard.
5.2.2 Connected equipment
The devices to be connected to the network system shall be devices that need to share information
onboard the vessel.
NOTE The following are examples of devices eligible for connection to the network:
-Ship’s clocks;
-Sensor information network converters;
-Network-capable multipoint displays;
-Engine monitoring systems;
-Container monitoring systems;
-Vessel monitoring camera systems;
-Shipboard IP telephone systems;
-VDSL shipboard network systems.
5.3 Equipment constituting communication network system
5.3.1 Network devices
Clearly indicate the specifications for network devices (switches and routers) connected to each of the nodes.
5.3.1.1 Switches
A switch is a computer network device with the same functionality as a bridge or more in OSI reference
model layer 2. It is also called a “layer 2 switch” (or “L2 switch”).
Some models of switch have intelligent functions for network management. The following are examples
of such intelligent functions:
— Rapid Spanning Tree Protocol (RSTP);
— Virtual Local Area Network (VLAN);
— Simple Network Management Protocol (SNMP).
5.3.1.2 Routers
A router is a communication device that connects different networks. It is responsible for OSI reference model
layer 1 to layer 3 connections, and controls the transmission of IP packets between the various networks.
Protocol processing is implemented in software.
The basic functionality of a router is as follows:
— Filters IP headers and the like;
— Has quality of service (QoS) features, including prioritizing line capacity and throttling traffic;
— Manages routing information using route-information collection protocols routing information
protocol (RIP) and open shortest path first (OSPF).
5.3.1.3 L3 switches
L3 switches mainly transfer data in OSI reference model layer 3. Their functionality is nearly equivalent
to that of a router.
They should be faster than routers because they implement protocol processing in hardware.
5.3.2 Network cables
The cables used to connect devices shall be selected with consideration for communication speed and
distance. Installation of shield cables (shield twisted pair cable, foil twisted pair cable, etc.) should be
considered, depending on the installation environment.
6 © ISO 2013 – All rights reserved

Table 1 shows the standard for selecting standards of cables that connect devices, and the specifications
for optical-fibre cables and metal cables used by the system. It is necessary to always pay attention to
the latest standard.
Table 1 — Network cable standards
Protocol Standard Communication Speed Cables Used Range
Protocol
10BASE-T IEEE 802.3i UTP/Shield Twisted Pair 100 m
cable: Cat3
10BASE-FB 2 000 m
10 Mbps
10BASE-F 10BASE-FP IEEE 802.3j Multi mode optical fiber 1 000 m
10BASE-FL 2 000 m
100BASE-TX UTP:Cat5 100 m
IEEE 802.3u
100BASE-T 100BASE-T4 UTP(4): Cat3 100 m
100BASE-T2 IEEE 802.3y 100 Mbps UTP(2): Cat3 100 m
Multi mode optical fiber 2 000 m
100BASE-F 100BASE-FX IEEE 802.3u
Single mode optical fiber 20 km
1000BASE-T IEEE 802.3ab UTP(4): Cat5e 100 m
1000BASE-T
1000BASE-TX TIA-EIA/-854 UTP(4): Cat6 100 m
1000BASE-SX Multi mode 550 m
optical fiber
Multi mode 550 m
1000 Mbps
optical fiber
1000BASE-X 1000BASE-LX IEEE 802.3z
Single mode 5 000 m
optical fiber
1000BASE-CX Coaxial 25 m
cable(2)
UTP(4):Cat6e 100 m
10GBASE-T IEEE 802.3an UTP(4):Cat6a 100 m
UTP(4):Cat7 100 m
10GBASE-SR Multi mode 300 m
10 GMbps
optical fiber
10GBASE-LR Single mode 10 km
10GBASE-R IEEE 802.3ae
optical fiber
10GBASE-ER Single mode 40 km
optical fiber
5.3.3 Relays
The relay devices used in shipboard communication networks are as follows:
— Using switch to divide collision domains;
— Using local routers and L3 switches to divide broadcast domains;
— Using gateway devices to connect to other networks;
NOTE A gateway in Figure 1 is an application gateway.
— Repeater HUB shall not be used as a data collision preventive measure.
Figure 1 — Sample network architecture scope (Reference)
6 Data requirements
6.1 General
This clause specifies the data requirements that shall be implemented in the communication network
system, but the system shall comply with this clause and any applicable international standards such as
IEC 61162-450:2011.
6.2 Meaning of data and description of structure
Language shall be defined in order to specify the category, content, and structure of data prescribed
by the data’s attribute definition. By using a language that is currently used widely on the Internet
many other computer applications become capable of increasing the convenience of developing device
applications. This clause recommends the use of XML, a standard structure-description language that is
easy for standard senders and receivers to parse and analyse the data structure. The use of a structure
description language is expected to improve the convenience to the user, including ease of semantically
analysing data, reusing data, and importing data into databases.
The data requirements specified in each data definition should preferably be determined after referring
to 6.3 and 6.4.
NOTE Sample notations using XML for reference are as follows:
EXAMPLE 1 Sample notation for UTC time and date
8 © ISO 2013 – All rights reserved

Identifier Meaning Category Year Month Day Time
UTC Time and
ZDA Analog 2009 10 15 20:10:19.95
Date
< Navigation Data >
< data_type > UTC Time and Date < /data_type >
< identifier > ZDA < /identifier >
< category > Analog < /category >
< year > 2009 < /year >
< month > 10 < /month >
< day > 15 < /day >
< time > 201019.95 < /time >
< /Navigation Data >
EXAMPLE 2 Sample notation for engine data measurement points
Low
Channel Range Range High Alarm
Channel Name Cat. Range Unit Alarm Signal Type
No. Zero Full Value
Value
M/E T/C REVOLU-
0101 Analog 0 350 100min-1 – 135 4-20mA
TION
M/E FO INLET
0201 Analog 0 200 °C 105 150 Pt100
TEMP
< Engine Data >
< measurement_point >
< channel_num > 0101 < /channel_num >
< channel_name > M/E T/C REVOLUTION < /channel_name >
< category > Analog < /category >
< range_zero > 0 < /range_zero >
< range_full > 350 < /range_full >
< range_unit > 100min-1 < /range_unit >
< low_alarm_value > – < /low_alarm_value >
< high_alarm_value > 135 < /high_alarm_value >
< signal_type > 4-20mA < /signal_type >
< /measurement_point >
< measurement_point >
< channel_num > 0201 < /channel_num >
< channel_name > M/E FO INLET TEMP < /channel_name >
< category > Analog < /category >
< range_zero > 0 < /range_zero >
< range_full > 200 < /range_full >
< range_unit > °C < /range_unit >
< low_alarm_value > 105 < /low_alarm_value >
< high_alarm_value > 150 < /high_alarm_value >
< signal_type > Pt100 < /signal_type >
< /measurement_point >
< /Engine Data >
6.3 Data attribute definitions
The attributes of data exchanged between senders and receivers over the network system shall be
determined, and a summary of the defined information based on these set attributes should be disclosed
to users. Consideration should be taken for information and specifications regarding equipment of the
data senders and receivers when defining specific data attributes.
When defining data contents, user-friendliness, such as ease of semantically analysing data, shall be
taken into account.
6.3.1 Data categories
Information for identifying data shall be defined when data are used between the sender’s and
receiver’s devices.
6.3.1.1 Request/Information identifier
In order to distinguish the type of Request data and Information data, an identifier should be added to
the attribute definitions.
a) Request data
Request data are data to request specific actions to other devices, or to request when using
request/response as data-delivery format and procedures.
b) Information data
Information data are data to send the status or information of the sender’s device for another device.
6.3.1.2 Classification information
Information to classify data shall be determined considering the data’s meaning. The following are some
example classifications: trend graph, bar graph, navigation, equipment alarms, etc.
6.3.1.3 Analog/On/Off signal identifier
If analog and On/Off signal information need to be distinguished, an identifier should be added to the
attribute definitions that do so.
6.3.1.4 Equipment architecture information
Information shall be added for identifying nodes, considering equipment architecture information that
identifies equipment communication nodes. Information for node address numbers, addresses, and
device-specific types are the examples.
10 © ISO 2013 – All rights reserved

6.3.2 Data contents
In order to give the actual data values (e.g. engineering values or converted values), the name of the
actual data value, the data being sent (analog or On/Off signal value), and the unit information (when
using analog signal values) shall be defined.
6.3.2.1 Data name
The data name should preferably be any identifier that is easy for people to understand considering the
meaning of the data being sent. The sender and receiver shall have identical interpretations of identifiers,
because it enables the receiver to identify the data’s value.
6.3.2.2 Values for data names
Actual values for data names shall be given. For analog signal data, the actual value will be determined by
the specifications for the data stored on the device, including the notation (e.g. decimal or hexadecimal)
and the handling of decimals. Although binary notation is generally used for On/Off signal values, the
value shall be defined, including the significance of “0” and “1”.
6.3.2.3 Unit information
If the data name is for an analog signal value, then unit information may also be assigned. The MKSA
unit system should be used for unit information. It should be noted that unit systems other than MKSA
are also used on shipboard systems. Therefore the unit system to use between the sender and receiver
shall be determined in advance.
6.3.3 Data size
The data size (number of records) shall include information about the number of records in the data
repeatedly delivered by the sender. If the number of records becomes extremely large, a large amount of
data will be sent over the network. Therefore the maximum number of records should be ascertained. By
adding the information about the number of records beforehand in order to explicitly state the amount
of data, the identification of the data size will be facilitated.
6.3.4 Data encoding format
There are two main types of data encoding: ASCII and binary. ASCII features the strength of being easily
understandable by humans, while having the weakness of increasing the amount of data to be sent.
Binary data are hard for humans to understand, while having the advantage of reducing the amount of
data to be sent. The format shall be determined with consideration for the data size in 6.3.3.
6.3.5 Use of data encryption
Data are sometimes sent in encrypted form in order to increase the confidentiality of the data. If the data
are encrypted, both the sender and receiver shall be equipped with encryption and decryption algorithms.
6.4 Data delivery format
The data requirements for the network system shall take the following requirements into account.
6.4.1 Data delivery method and procedure
The method and procedure for delivering data are determined in accordance with the equipment
specifications. The communication protocol shall be determined in accordance with the status between
each device; for example, if a device stops processing when being turned off or reset, or if communication
is conducted between devices continually.
The data-delivery format and procedures shall include one-way transmission (one-way stream), and
request/response.
6.4.2 Data delivery format
The method of delivering the data that has the attributes determined in 6.3 shall be taken into account.
The most common data-delivery formats for Ethernet are unicasting, broadcasting, and multicasting.
Each format has its own strengths and weaknesses, and shall be selected in accordance with the purpose
of the inter-device data communication. The delivery format shall be selected with consideration for
such systems as the connected devices, delivery formats, and other elements as a whole, because the
data-delivery format will influence the network load on other devices.
6.4.3 Data notification format
There are two main data-notification formats: event notifications, which are sent when an event occurs
that the sender should send; and periodic communication, which sends data at regular intervals.
6.4.3.1 Event notifications
Event notifications have the advantage of reducing the amount of data to be sent, but should be dealt with
caution, because the notification will not be made if the receiver fails to receive the data. Consideration
is also required for the communication procedure when a receiver recovers from a state in which
reception was not possible (e.g. powered off or malfunctioning).
6.4.3.2 Periodic notifications
Periodic notifications have a certainty of being capable of receiving data from other devices by waiting
for a certain period of time. It has the disadvantage, however, of increasing the network load by sending
large amounts of data periodically over the network. For this reason, data to be sent periodically shall be
determined based on the level of demand for reliability in the sent data, and the network-load forecast.
In particular, measures shall be taken to avoid flooding the network when sending initialization data to
a large number of connected network terminals upon initialization.
In consideration of the data requirements in 6.2 and 6.3, the effective data volume and network load
factor should be pre-calculated when the network media are under maximum load. The design should
also preferably foresee the various potential system states, including initial state, failure state, and
normal state, in order to operate normal data communications on the system in the worst-case scenario.
It is also extremely vital to consider data requirements for equipment connected to the network that
does not send or receive data from being excessively impacted.
7 Network administration requirements
7.1 Network administration requirements and definitions
Network administration is a mechanism for continually monitoring traffic and nodes, and enabling the
crew to ascertain any anomalies.
The mechanism shall be so simple to handle that any crew may easily learn how to administer the
network without being an expert.
7.2 Network administration scope
The scope of administration is the equipment’s communication network only.
The following categories of network administration defined by the ISO OSI shall perform configuration
management, performance management, and fault management and not perform billing management
and confidentiality management.
12 © ISO 2013 – All rights reserved

7.3 Network administration items
Administer the following items:
a) Node status (included alive signal of network devices);
b) Traffic;
c) Cable disconnections.
7.4 Requirements for network monitoring devices
The crew shall be able to monitor from a network-monitoring device installed on the bridge or the like.
The crew shall be able to identify the locations of errors from the network-monitoring device.
The network monitoring device shall indicate appropriate countermeasures for problems.
7.4.1 Functionality of network monitoring devices
Network monitoring devices shall have the following functionality.
7.4.1.1 Function to display physical architecture of network
The network-monitoring device shall display a schematic of the physical architecture of the target network.
The network-monitoring device shall have a function to automatically display information using
SNMP packets.
The network-monitoring device shall make it possible to register devices that do not support SNMP on the
network-architecture schematic manually, and display the status as a response to ICMP communication.
The network-monitoring device shall be able to display the status (linked/not linked) of each node of
the network device.
Use ping or traceroute for the response to ICMP communication.
7.4.1.2 Alarm function
The network-monitoring device shall have a function to detect abnormal state changes and notify the
user of them:
a) When a link is disconnected or the power is turned off for a network device or network terminal;
b) When a link is connected or the power is turned on for a network device or network terminal;
c) When there are Packet loops;
d) When the traffic exceeds the threshold value;
e) When an otherwise defined network-device anomaly occurs;
f) When an otherwise defined network-terminal anomaly occurs.
7.4.1.3 Logging function
The network-monitoring device shall be able to record changes in emergency status, alarms, SNMP
traps, and other events. An event log shall be kept for at least the past 24 h.
But, alarms and SNMP traps event logs should be stored for at least the past 30 days.
7.4.1.4 Traffic display function
The network-monitoring device shall be able to display the network traffic (between network devices
and network terminals, and between network devices) in the form of a trend graph.
7.4.1.5 Setting configuration function
The network-monitoring device shall be able to change the settings of the network-monitoring devices
and MIB of nodes on the network using SNMP.
7.4.1.6 Fault recovery support function
The network-monitoring device shall be able to provide information and suggest remedies in order to
recover from failures.
7.4.1.6.1 Network information
The network-monitoring device shall be able to store and display a list of the device names, MAC address,
IP addresses, and installation locations of network terminals.
The network-monitoring device shall be able to store and display a list of the device names, IP addresses
(if any), and installation locations of network devices.
7.4.1.6.2 Failure remedies
Procedures shall be registered on the network-monitoring device as remedies for the following faults in
network devices:
a) Network device stoppage;
b) Network device restart;
c) Packet loops.
7.5 Requirements for network nodes
There are two types of network node: network devices and network terminals.
Each network node shall have a self-diagnostics feature.
The network nodes shall notify the network-monitoring device of their status periodically or upon failure.
7.5.1 Network devices
Network devices shall relay network data from hubs, switches, routers, gateways and the like.
7.5.1.1 Network device management functions
Network devices shall have the following management function:
a) Support for SNMP;
b) Support for ICMP;
c) The network should have a function to detect loops in IP packets and Ethernet packet sub-frames
Use SNMP v2c (RFC1901-RFC1908) for SNMP.
Use ICMP v4 (RFC792) for ICMP.
14 © ISO 2013 – All rights reserved

7.5.1.1.1 Detection and notification of management status of network devices
The network devices shall be able to detect the following states by performing self-diagnostics, and the
network-monitoring device of the following information using SNMP trap communication shall be notified.
a) Link up of each port on the network device;
b) Link down of each port on the network device;
c) Power on or hardware reset;
d) Loop guard (only if the network device has a loop detection function);
e) Fan halt (only if the network device has a fan and a fan-stop detection function);
f) Abnormal temperature (only if the network device has an abnormal-temperature detection function).
7.5.1.1.2 Network device management information
The management information of the network devices shall be compatible with the MIB. The network
device’s management information shall also be sent to the network-monitoring device periodically.
Use MIB or MIB II (RFC1213).
7.5.2 Network terminals
Terminals are connected to the network and perform data communications.
7.5.2.1 Network terminal management functions
Network terminals shall have the following management function:
a) Support for ICMP;
b) May also support SNMP;
c) If it has a function to notify network-monitoring device of log, the log messages shall use a standard
communication protocol.
Use SNMP v2c (RFC1901-RFC1908).
Use ICMP v4 (RFC792) for ICMP.
Use syslog (RFC3164) as the standard log-message communication protocol.
8 Operational guidelines
8.1 Notes for network operations
8.1.1 Protection from malware
a) Computers shall not be connected to the shipboard network that are not controlled by the shipboard
network, and registered computers shall not be removed from the ship. This does not apply to
systems that operate with compact, portable terminals that move on and off ship, but in this case
take measures to prevent connection to other than determined networks. Additionally, before
replacing a device due to failure or upgrade, the new device shall be checked for viruses to ensure
that it does not contain malware.
b) Antivirus measures on the network terminal shall be installed to prevent infection by computer
viruses, worms, spyware, and other malware. Examples of malware attack vectors include network
ports, as well as USB, connection ports for communication with IEEE 1394 and other external
devices, and CD/DVD/Blue-ray Disc reader drives installed on the network terminal. A virus check
shall be taken before making these connections.
c) When receiving external data in order to perform data exchange, the imported data shall be ensured
whether it is appropriate for the purpose. The imported data should be checked in order to prevent
expecting viruses.
d) Antivirus software shall be installed on each computer, and the virus-definition files updated
periodically. The OS should be updated periodically in order to improve security. Automatic updates
of the virus definitions and OS shall be performed periodically, and shipboard computers shall
be configured to perform auto updates. In order to save communication costs, an update service
application to update operating systems and antivirus o
...