ISO 18131:2025

International
Standard
ISO 18131
First edition
Ships and marine technology —
2025-11
Publish-subscribe architecture on
ship-shore data communication —
General requirements
Navires et technologie maritime — Architecture Publish-
subscribe (publier/s'abonner) pour la communication de données
entre les navires et les autorités à terre — Exigences générales
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 General requirements for publish-subscribe architecture on ship-shore data
communication . 4
5.1 General .4
5.2 Sequence diagram.5
6 Requirements for security management . 6
6.1 General requirements .6
6.2 Application layer authentication .6
6.3 Authorization for topic permission .8
6.4 Data encryption by transport layer security .8
7 General requirements for message format . 8
7.1 General requirements .8
7.2 Topic name .9
7.2.1 General .9
7.2.2 Topic naming definition .9
7.2.3 Topic name of data type .10
7.3 Data model.14
7.3.1 General .14
7.3.2 Header of data model . 15
7.3.3 Payload of data model . 15
8 Functional requirements for data management.29
8.1 Data backup . 29
8.2 Data recovery . . 29
8.3 Log and event storage management . 29
Annex A (informative) Examples of data taxonomy.30
Bibliography .136

iii
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.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 8 Ships and marine technology, Subcommittee
SC 26, Smart shipping.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iv
Introduction
Information and Communication Technology (ICT) plays an increasingly important role in assuring effective
and secure data communication in the marine industry. In this context, there is a growing need for an
architecture that not only enables interoperability between applications and systems onboard vessels,
but also supports real-time streaming services within ships. Moreover, data communication between ship
and shore is provided in real time to support decision-making as integrated information by collecting and
analysing data.
In order to expand the usage range between relative entities and to improve the ship's performance, it is
important to standardize the message format transmitted from the ship side server to the shore side server.
Existing International Standards on managing data that are derived from ship or shore have been used in
the industry such as:
— the IEC 61162 series for the digital interfaces of navigational equipment within a ship;
— ISO 19847 for shipboard data servers;
— ISO 19848 for standard data for shipboard machinery and equipment;
— ISO 23807 for asynchronous time-insensitive ship-shore data transmission.
However, it is recommended to establish a message communication system that shall respond flexibly to
the various message formats derived from relevant sectors such as smart shipping, smart ports, smart
logistics, etc. Furthermore, utilizing a communication protocol optimized for satellite communication can be
considered, even in a situation where communication is intermittently disconnected. Furthermore, it should
be highlighted that the data model is designed with scalability to accommodate future expansions related to
eco-friendly technologies and environmental regulations.
This document defines a publish-subscribe architecture to facilitate widespread data utilization. It enables
many-to-many communication by allowing data to be transferred through registered topics. It provides a
dynamic, batch-based messaging structure.
This document provides general requirements for publish-subscribe communication, including security
requirements, topic naming definitions, message format, and functional requirements for data management.

v
International Standard ISO 18131:2025(en)
Ships and marine technology — Publish-subscribe
architecture on ship-shore data communication — General
requirements
1 Scope
This document specifies requirements on publish-subscribe architecture on ship-shore data communication.
It is intended for use by system providers and users, including software vendors, platform developers,
fleet managers, application users in the field of the shipbuilding industry, shipping companies, equipment
manufacturers, and port and on-shore service providers, to communicate in the publish-subscribe
architecture between ship and shore.
This document focuses on enabling interoperability of shipboard and shore-based systems for the exchange
of operational data using publish-subscribe methods.
This document describes:
— the role of a broker, publisher and subscriber;
— the multitenancy-based data management system in the cloud environment;
— general requirements for publish-subscribe architecture;
— security requirements for ensuring data confidentiality, integrity and availability;
— the message format for client id and topic name, and data model;
— functional requirements for data management.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 24060, Ships and marine technology — Ship software logging system for operational technology
IEC 61162-460, Maritime navigation and radiocommunication equipment and systems — Digital interfaces —
Part 460: Multiple talkers and multiple listeners — Ethernet interconnection — Safety and security
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/

3.1
publish-subscribe architecture
system in which publishers (3.5) post messages to an intermediary message broker (3.4) and subscribers (3.6)
register subscriptions with that broker, allowing the broker to filter, classify the client and designate the
priority of messages
Note 1 to entry: The message broker performs a store-and-forward function to route messages from publishers to
subscribers, with optional prioritization of messages in a queue before routing.
3.2
quality of service
QoS
level that is a deal between two parties, the publisher (3.5) and subscriber (3.6), of a message with respect to
the assurance of distribution of data
3.3
topic naming definition
hierarchical structure in which clients publish messages on designated topics and receive messages that
match those topics
Note 1 to entry: This structure comprises multiple topic levels separated by slash (“/”) characters and allows the use
of wildcards such as “+” and “#”.
3.4
message broker
intermediary system responsible for controlling the distribution of data, and storing, forwarding, filtering
and prioritizing public requests from the publisher (3.5) to the subscriber (3.6)
Note 1 to entry: Clients switch between publisher role and subscriber role depending on the functionalities desired.
3.5
publisher
client of ship side or shore side who sends messages with a topic to a message broker (3.4) and the topic
matches with a subscription created by the client
3.6
subscriber
client on the ship side or shore side who receives published messages on a specific topic
Note 1 to entry: The subscriber obtains data by registering a subscription with the message broker (3.4) according to
a defined topic structure.
3.7
multitenancy
architecture in which many tenants (users) simultaneously share the same software instance
Note 1 to entry: It allows a single message broker (3.4) to serve multiple tenants or customers, while keeping their
data and communication separated from each other. It stores metadata about each tenant and uses this data to alter
the software instance at runtime to fit each tenant's needs. The tenants are isolated from each other via permissions.
Even though the tenants share the same software instance, each one uses and experiences the software differently. It
consists of handling multiple IDs on a single server in cloud environments.
3.8
ship-shore data communication
exchange of information between a shipboard system and a shore-based system through a
communication network
Note 1 to entry: It enables real-time sharing of operational, navigational, safety, environmental, and maintenance data,
supporting enhanced monitoring, management, decision-making, and regulatory compliance for vessel operations.
This communication typically utilizes a publish-subscribe architecture depending on the specific operational and
technical requirements.
4 Abbreviated terms
API application programming interface
CSV comma-separated values
ICT information and communication technology
IoT internet of things
JSON javascript object notation
QoS quality of service
URL uniform resource locator
UUID universally unique identifier
VPN virtual private network
XML extensible markup language
XSD XML schema definition language
MQTT Message Queuing Telemetry Transport
AMQP Advanced Message Queue Protocol
pub/sub publish-subscribe
NOx Nitrogen Oxides
SOx Sulfur Oxides
LNG liquefied natural gas
HT high temperature
LT low temperature
ECR engine control room
LAN local area network
UV ultraviolet
TBN total base number
BOG boil-off gas
CCTV closed-circuit television
RDF radio direction finder
GPS Global Positioning System
EPIRB emergency position-indicating radio beacon

5 General requirements for publish-subscribe architecture on ship-shore data
communication
5.1 General
Data for communication between ship and shore can comprise a variety of messages to navigation,
machinery, cargo, administration etc. As a communication method, the message is exchanged between the
server on the ship and the server on the shore, in which the most beneficial architecture is the publish-
subscribe (pub/sub) architecture.
Known to be well-suited for IoT applications, the pub/sub architecture is designed to have a superior
flexibility and scalability, and to be suitable for bandwidth saving and service expansion. The pub/sub
architecture also enables bi-directional communication between ship and shore.
Figure 1 — Schematic of ship-shore data communication
For ship-shore data communication using the pub/sub architecture, data shall be published and subscribed
in accordance with the topic naming definition specified in 7.2.2, whereby it is possible to enable
communication between a single data source and a single recipient (one-to-one), or between multiple
sources and multiple recipients (many-to-many), by registering data on a topic, as illustrated in Figure 1.
Data streaming is continuously enabled as long as the registration of the topic is not cancelled.
For example, in the case where it is required to monitor the temperature of an engine air cooler in a specified
vessel, the temperature can continuously be communicated without cancelling from the topic subscription.
The configuration of data streaming between ship and shore is based on a publisher, subscriber and
message broker approach. Normally message brokers are located in onshore data centers, and publisher and
subscribers are located to both ship and shore side. The flow of the data communication is as follows. First,
data obtained from equipment in each vessel at sea is sent to the broker in the form of a configured topic.
Subsequently, various clients including the onshore operation centre acquire the data through the broker,
and vice versa.
In this document, it is necessary to consider communicating not only navigation and machinery equipment
data on the ship side, but also data generated from shore-based systems. Thus, the pub/sub architecture can
be useful in ship-shore data communication.
Since there are various data categories beyond navigation and machinery equipment, new data structures
shall be established on the basis of the pub/sub architecture.

Therefore, the publish-subscribe architecture should be compatible with the standardized existing data
structure for navigation and machinery equipment, and even be able to communicate between ship and
shore by mapping the existing data structure into the pub/sub data patterns.
By viewing a semantic perspective, the architecture can be also compatible with a data quality index
that consists of accuracy, completeness, consistency, credibility and timeliness, since the architecture
has the benefit of qualifying the data by real-time integrity. This architecture is also applicable for data
communication between ship-to-ship.
Accordingly, the configuration of the data communication between ship and shore is presented in Figure 2.
5.2 Sequence diagram
In a pub/sub model, there is a broker in the middle as an intermediary. Clients can subscribe to receive
messages from the broker and also publish messages to the broker which are then transmitted to all
subscribed clients. A sequence diagram for the data communication flow is shown in Figure 2.
Key
lifeline
session period
Figure 2 — Sequence diagram for data communication flow
A detailed explanation for topic name and data schema is given in Clause 7.
From a broker's perspective, data publishing and subscribing occur simultaneously, so it can be viewed as
bidirectional. For example, the package update or feedback command can be transferred by the pub/sub
from ships, and also from shore.
The security against vulnerability caused by the direct opening of the data server for data communication
shall be improved. A method shall be implemented that can compensate for the restriction of data
communication due to the ship's dynamic IP address and the quality of data communication according to
the state of the satellite. Thus, all these issues regarding security and unstable network conditions that can
occur during ocean navigation can be managed while the broker acts as an intermediary.

Figure 2 shows the functionalities on the high-level layer when sending a message by the pub/sub pattern,
which can be also used on virtual private network (VPN). The diagram includes “Ack” messages, which
indicate acknowledgements confirming message receipt.
When connecting to the broker, WebSocket can be used for real-time message delivery using the pub/sub
pattern. The broker can support WebSocket communication by adjusting its configuration settings.
6 Requirements for security management
6.1 General requirements
To effectively address security issues that can arise in the communication between ship and shore, all
data assets shall be protected by multiple security management methods such as authentication on the
application layer, authorization for topic permission, data encryption and detection log management. Some
of these methods are defined as follows.
— Authentication for application layer: The application layer belonging to the top layer of the protocol is
easily attacked by hackers among other layers. The application layer is exposed to more network threats
than other layers, thus the secure authentication method is required.
— Authorization for topic permission: Assuming that an open broker is not used, an access permission of
the topic is required. Therefore, only authorized clients can publish and subscribe, and the broker should
have a method for the access scheme towards the topic.
— Data encryption: When sensitive data are transmitted through network communication, data shall be
encrypted so that it cannot be manipulated or tampered by a man-in-the-middle attack.
NOTE To enhance cyber security, other relevant rules, regulations and standards can apply.
6.2 Application layer authentication
In general, if the validity of the client certificate is proven, it can be used as an authentication for the client
to access the server, and the server provides a digital certificate issued by a third party that can confirm the
client's identity.
The primary purpose of a client ID is to serve as a unique identifier for each client that connects to a broker. This
unique identifier is crucial for managing the connection and session state between the client and the broker.
An example of the naming definitions for the client ID is shown in Table 1.
Table 1 — Example of client ID
Contents Ship platform ID - Ship ID - Sequence Remark
Number of Three digits - Above 10 digits - Ship’s randomized The number of digits is
digits unique number just an example.
Example Shipboard data man- - IMO number - UUID, encrypted code Ship platform ID-
agement server IMOxxxxx-UUID or
(IMO xxxxxxx),
encrypted code
Official number,
Ship series number,
etc.
The client ID consists of the following three elements:
— Ship platform ID, which refers to a unique identifier assigned to a specific ship platform to facilitate
communication and data exchange.
— Ship ID, a persistent identifier linked to a vessel throughout its lifetime, used to ensure accurate data
routing and vessel tracking.
— Sequence, which may include a UUID and encrypted code, used to enhance security, identification, and
message integrity.
For example, in a typical communication flow, the ship may first generate a randomized session-specific
number. A UUID is then created and attached to the message. The message is encrypted to generate an
encrypted code and is published to the broker. The shore-based system then decrypts the message using the
shared key and validates the UUID to ensure session integrity and secure identification.
Figure 3 — Sequence diagram for the authentication process
Figure 3 shows a sequence diagram for the authentication process. This diagram outlines the roles and
interactions between entities, which are described as follows:
— Connection request: The client application connects to the broker using the client ID.
— Broker verification: The broker verifies the credentials against its user database.
— Response: The broker responds with either an “authentication success” or “authentication failure”
message.
— Secure connection initiation: After successful authentication, the client application initiates a TLS
handshake with the broker.
— Broker certificate provision: The broker provides its digital certificate to the client during the TLS
handshake.
— Certificate verification: The client application verifies the broker’s certificate using a trusted certificate
channel.
— Key exchange: A symmetric key exchange occurs to establish a secure communication channel.
— Secure communication: The client securely publishes and subscribes to topics through the broker after
the secure session is established.

Since the digital certificate contains the server's public encryption key, the client receives the server’s
certificate to verify its authenticity. On the application layer, when sending a CONNECT message to the
broker, the authentication is proven through the client ID and password. The username of the client ID is
defined as a UTF-8 encoded string, and password is defined as binary data.
For example, OAuth2, which is widely used on the internet as an open authentication protocol, can also be used.
6.3 Authorization for topic permission
The authorization for topic permission means granting only authorized clients the right to access an
allocated resource. The authorization management for accessing to the topic shall be assigned and managed
by a broker. The authorized clients shall be permitted to publish to or subscribe to the topic.
The types of access permissions managed by the broker include:
— access to only a registered topic (intended one by clients);
— the restriction of the client's choice (only publishing, only subscribing or both);
— the selection of the Quality of Service (QoS 0,1,2)
6.4 Data encryption by transport layer security
The entities shall be able to confirm those entities that are trustworthy of each other. The contents of the
communication between entities shall be protected from being eavesdropped by a third party. Therefore,
a certificate with an electronic signature is used, and communication contents are encrypted. In other
words, the transport layer security encrypts data sent over the internet to ensure that eavesdroppers and
hackers are unable to see what data are transmitted. This is a method of generating encrypted data through
a symmetric and asymmetric key, and of obtaining data using the same key for decryption.
7 General requirements for message format
7.1 General requirements
To communicate data in a pub/sub pattern, the following shall be defined:
— the type of data to communicate;
— how the message format is designed.
The message format is composed of the client ID, topic name and data model. Since the client ID is related
to the authentication, see Table 1 for further details. The topic name can be configured by topic naming
definitions. The data model has two components: header and payload.
The message format firstly requires the authentication to access the topic, and allows mutual data users
through the data model to check the header and the payload configurations.
The broker manages common topics as a tool to send data to multiple clients, and each client creates a
response topic and delivers it to the broker, thereby creating a virtual connection between the publisher and
the subscriber.
The messages are distributed in the formatted schema and the data model parses and checks the necessary data.
The hierarchical modelling for the message format can be implemented as shown in Figure 4.

Figure 4 — Model of message format
7.2 Topic name
7.2.1 General
The topic name is generated by the topic naming definition and can be configured according to various
data types.
7.2.2 Topic naming definition
The configuration of topic naming definitions uses delimiters to classify topic levels, and means that the
broker uses it to filter messages coming from each connected client. As shown in Table 2, the topic naming
definition follows a four-level hierarchy.
Table 2 — Example of topic naming definition
Contents Ship platform ID / Ship ID / Data type / Response
Alarm data ShipplatformID / Vesselnumber / metrics/alarm / Applicable when sub-
scribing
(IMO number)
Example (Publishing) shipplatformID/Vesselnumber/metrics/alarm
(Subscribing) shipplatformID/Vesselnumber/metrics/alarm/response
The contents refers to specific data elements included within a message, encompassing various fields and
types of data as defined in Table 4.
The ship platform ID refers to a unique identifier assigned to a specific ship platform to facilitate
communication and data exchange.
The metrics/alarm refers to data used for monitoring and analysis; alarms serve as critical notifications
prompting operators or system administrators to take immediate action to prevent potential issues or
failures.
The response refers to the message sent from a server in reply to a client request, containing either the
requested information or the result of the operation performed.
The data type for sending the alarm message derived from a component of the main engine is defined as
metrics and the sub-element is designated as an alarm coming from the component.

Table 2 shows that when publishing alarm data, the classification of topic level is defined by using slashes in
the order of the ship platform ID, the ship's unique number (IMO number), and the data type (metrics/alarm).
Table 2 also shows that when subscribing to the data, a response is added at the end of the publishing topic
syntax. For this reason, a subscribing client can receive all the alarm data generated by the vessel, but if the
subscriber wants to receive data only about the alarm of a specific component of the main engine, it can be
parsed into more readable data formats. The component model structure is shown in Annex A.
When subscribing to a topic, it can use wildcards to subscribe to multiple topics simultaneously. A wildcard
can only be used to subscribe to topics, not to publish a message.
The Quality of Service (QoS levels) can be properly decided according to the data type or the priority.
It supports three levels of Quality of Service which are described below.
— QoS0 (At most once): The message is sent at most once and does not provide delivery guarantee of a
message. It means the message is not stored and can be lost if the client is disconnected, or if the server
fails. In the maritime industry, the architecture does not recommend servers to forward publications at
QoS0 to a client.
— QoS1 (At least once): The message is sent at least once and it is possible to deliver a message more than
once by setting the value of duplicate flag by 1. In maritime industry, the architecture does require
QoS1 as the default mode of transfer in accordance with the Table 3, because reliable transfer should be
implemented where the communication failure occurred by the shadowing area or the satellite unstable
condition.
— QoS2 (Exactly once): The message is sent exactly once by using four-way handshaking. Where the
acknowledgement for the message transmission is required between publisher and subscriber, QoS2
should be required specially for the message of a ship control, query service, and portcall.
7.2.3 Topic name of data type
Table 3 lists the data types that shall be referred to in the topic naming definitions specified in Table 2.
Table 3 — Topic name of data type
a
Type Subelement Categorical data Topic name QoS
ShipplatformID/Vesselnumber/metrics/alarm,
Alarm metrics/alarm 1
ShipplatformID/Vesselnumber/metrics/alarm/
response
Metrics
ShipplatformID/Vesselnumber/metrics/sensor,
Sensor metrics/sensor 1
ShipplatformID/Vesselnumber/metrics/sensor/
response
ShipplatformID/Vesselnumber/file/image,
Image file/image 1
ShipplatformID/Vesselnumber/file/image/
response
ShipplatformID/Vesselnumber/file/voice,
Voice file/voice 1
ShipplatformID/Vesselnumber/file/voice/
response
File
ShipplatformID/Vesselnumber/file/alarm,
Alarm file/alarm ShipplatformID/Vesselnumber/file/alarm/ 1
response
ShipplatformID/Vesselnumber/file/sensor,
Sensor file/sensor ShipplatformID/Vesselnumber/file/sensor/ 1
response
a
See 7.2.2 for an explanation of the QoS levels.

TTabablele 3 3 ((ccoonnttiinnueuedd))
a
Type Subelement Categorical data Topic name QoS
ShipplatformID/Vesselnumber/platform
Platform
/monitoring /platformlog,
/monitoring 1
ShipplatformID/Vesselnumber/platform
/platformlog
/monitoring/platformlog/response
Monitoring
ShipplatformID/Vesselnumber/platform/monitor-
Platform
ing/servicelog,
/monitoring 1
ShipplatformID/Vesselnumber/platform/monitor-
/servicelog
ing/servicelog/response
ShipplatformID/Vesselnumber/platform/
shipparticular,
platform/
Ship particular 1
shipparticular
ShipplatformID/Vesselnumber/platform/
shipparticular/response
ShipplatformID/Vesselnumber/platform/
feedbackcommand,
Feedback com- Platform
mand /feedbackcommand
ShipplatformID/Vesselnumber/platform/
feedbackcommand/response
Platform ShipplatformID/Vesselnumber/platform/query,
Query service platform/query 2
ShipplatformID/Vesselnumber/platform/query/
response
ShipplatformID/Vesselnumber/platform/
firmware,
Firmware Platform
update /firmware
ShipplatformID/Vesselnumber/platform/
firmware/response
*Ship to Shore
ShipplatformID/Vesselnumber/platform/
management,
ShipplatformID/Vesselnumber/platform/
management/response
Platform man- Platform
agement /management
*Shore to Ship
ShipplatformID/Vesselnumber/platform/
management/onshore,
ShipplatformID/Vesselnumber/platform/
management/onshore/response
ShipplatformID/Vesselnumber/safety/hullstress,
Hull stress safety/hullstress 1
ShipplatformID/Vesselnumber/safety/hullstress/
response
ShipplatformID/Vesselnumber/safety/riskfire,
Fire safety/riskfire 1
ShipplatformID/Vesselnumber/safety/riskfire/
response
ShipplatformID/Vesselnumber/safety/
riskexplosion,
Safety
Explosion 1
/riskexplosion
Safety ShipplatformID/Vesselnumber/safety/
riskexplosion /response
ShipplatformID/Vesselnumber/safety/
riskcollision,
Safety
Collision 1
/riskcollision
ShipplatformID/Vesselnumber/safety/
riskcollision/response
ShipplatformID/Vesselnumber/safety/
sailingpath,
Sailing path safety/sailingpath 1
ShipplatformID/Vesselnumber/safety/
sailingpath/response
a
See 7.2.2 for an explanation of the QoS levels.

TTabablele 3 3 ((ccoonnttiinnueuedd))
a
Type Subelement Categorical data Topic name QoS
ShipplatformID/Vesselnumber/economic/
routerule,
Economic
Routing rule 1
/routerule
ShipplatformID/Vesselnumber/economic/
routerule /response
Economic
ShipplatformID/Vesselnumber/economic/
insurance,
Economic
Insurance 1
/insurance
ShipplatformID/Vesselnumber/economic/
insurance /response
ShipplatformID/Vesselnumber/om/equipment,
Operation
Equipment om/equipment 1
ShipplatformID/Vesselnumber/om/equipment/
maintenance
response
ShipplatformID/Vesselnumber/inventory/
equipment,
Inventory
Equipment 1
/equipment
ShipplatformID/Vesselnumber/inventory/
equipment /response
ShipplatformID/Vesselnumber/inventory/
safetydevice,
Inventory
Safety device 1
/safetydevice
ShipplatformID/Vesselnumber/inventory/
Inventory safetydevice /response
ShipplatformID/Vesselnumber/inventory/
medicine,
Inventory
Medicine 1
/medicine
ShipplatformID/Vesselnumber/inventory/
medicine/response
ShipplatformID/Vesselnumber/inventory/
grocery,
Grocery inventory/grocery 1
ShipplatformID/Vesselnumber/inventory/
grocery/response
ShipplatformID/Vesselnumber/report/noon,
Noon report report/noon 1
ShipplatformID/Vesselnumber/report/noon/
response
ShipplatformID/Vesselnumber/report/ablog,
Abstract re-
report/ablog 1
ShipplatformID/Vesselnumber/report/ablog/
port
response
ShipplatformID/Vesselnumber/report/mrv,
Report MRV report/mrv 1
ShipplatformID/Vesselnumber/report/mrv/
response
ShipplatformID/Vesselnumber/report/cii,
CII report/cii 1
ShipplatformID/Vesselnumber/report/cii/
response
ShipplatformID/Vesselnumber/report/eexi,
EEXI report/eexi 1
ShipplatformID/Vesselnumber/report/eexi/
response
ShipplatformID/Vesselnumber/logistics/cargo,
Cargo logistics/cargo 1
ShipplatformID/Vesselnumber/logistics/cargo/
response
Logistics
ShipplatformID/Vesselnumber/logistics/
container,
Container logistics/container 1
ShipplatformID/Vesselnumber/logistics/
container/response
a
See 7.2.2 for an explanation of the QoS levels.

TTabablele 3 3 ((ccoonnttiinnueuedd))
a
Type Subelement Categorical data Topic name QoS
ShipplatformID/Vesselnumber/port/portcall,
Portcall opti-
port/portcall 2
ShipplatformID/Vesselnumber/port/portcall/
mization
response
Port
ShipplatformID/Vesselnumber/port/immigration,
Immigration port/immigration 1
ShipplatformID/Vesselnumber/port/immigration/
response
ShipplatformID/Vesselnumber/environment/
ballast,
Environment
Ballast 1
/ballast
ShipplatformID/Vesselnumber/environment/
ballast /response
ShipplatformID/Vesselnumber/environment/
noxsox,
Environment
NoxSox 1
/noxsox
ShipplatformID/Vesselnumber/environment/
Environment noxsox/response
ShipplatformID/Vesselnumber/environment/
co2emission,
Environment
Emission 1
/co2emission
ShipplatformID/Vesselnumber/environment/
co2emission/response
ShipplatformID/Vesselnumber/environment/
weather,
Environment
Weather 1
/weather
ShipplatformID/Vesselnumber/environment/
weather/response
ShipplatformID/Vesselnumber/fuel/volume,
Volume fuel/volume 1
ShipplatformID/Vesselnumber/fuel/volume/
response
Fuel
ShipplatformID/Vesselnumber/fuel/charge,
Charge fuel/charge 1
ShipplatformID/Vesselnumber/fuel/charge/
response
ShipplatformID/Vesselnumber/employee/health,
Health employee/health 1
ShipplatformID/Vesselnumber/employee/health/
response
Employee
ShipplatformID/Vesselnumber/employee/
information,
Employee
Information 1
/information
ShipplatformID/Vesselnumber/employee/
information/response
a
See 7.2.2 for an explanation of the QoS levels.
The type refers to the classification of data as represented in Table 4.
The subelement refers to a component or child element within a data type that contains properties or values
nested under that data structure.
The categorical data refers to a type of data that can take on a set of distinct values with meaningful
groupings or orderings enabling structured analysis and reporting.
The topic name refers to hierarchical string used to organize and route messages between publishers
and subscribers, acting as an address that allows subscribers to receive relevant messages based on their
subscriptions.
The QoS1 level should be applied to most data types to prevent communication failures in coverage-
limited (blanket) areas. It is recommended to apply the QoS 2 level to data that required formal approval or
confirmation between ship and shore systems, such as feedback command, operational acknowledgements,
or regulatory reporting.
Depending on the system configuration, the topic level can be subdivided down to the equipment layer to
support extended usability and detailed data mapping.
Details of each data type are described in Table 4.
Table 4 — Description of data types
Type Description
Measures of quantitative value such as alarm or sensor commonly used for tracking
and comparing performance or operation.
Metrics
i.e. analog (sensor measuring), digital (alarm, control)
File Large amount of data such as alarm, sensor, image or voice.
An integrated set that collectively meets client’s end-to-end data needs. It is neces-
sary information for the efficient operation of the platform.
Platform
i.e. monitoring, ship particular, feedback command, query service, firmware update,
ship platform management
It is necessary information for the safe operation of ship.
Safety
i.e. hull stress, fire and explosive information, collision risk, route information
Key information for economic management of the ship’s operation.
Economic
i.e. routing rule, insurance
Information related to the operation and maintenance service of equipment.
Operation maintenance
i.e. equipment information, running hour
Stocks related to equipment, medicines, and provision.
Inventory
i.e. equipment, safety device, first aids, food and drink
Vessel’s operation information and environmental data required by IMO.
Report
i.e. noon report, abstract report, Monitoring, Reporting and Verification (MRV), Car-
bon Intensity Indicator (CII), Energy Efficiency Existing Ship Index (EEXI)
Logistics information linked to land-distribution.
Logistics
i.e. ship logistic information, container information
Port arrival and departure information and immigration procedures.
Port
i.e. port call optimizatio
...