ISO 4891:2024

International
Standard
ISO 4891
First edition
Ships and marine technology —
2024-11
Interoperability of smart
applications for ships
Navires et technologie maritime — Interopérabilité des
applications intelligentes pour les navires
Reference number
© ISO 2024
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 .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Smart application network . 5
5.1 Overview .5
5.2 4891-components .8
5.2.1 General .8
5.2.2 4891-message broker .9
5.2.3 4891-service discovery.9
5.2.4 4891-unit registry .10
5.2.5 4891-units .10
5.3 4891-messages .11
5.3.1 General .11
5.3.2 Message structure.11
5.3.3 Header values . 12
5.3.4 Data part encoding . 13
5.3.5 Message type .14
5.3.6 Standard message types .14
5.4 Handling of outdated messages . 15
5.5 Direct messaging . 15
5.6 Message relaying . 15
5.7 Trust and encryption . 15
6 Compatibility implementation .16
6.1 General .16
6.2 JSON-encoding for value types .16
6.2.1 General .16
6.2.2 Common types .16
6.2.3 Dictionary type .17
6.2.4 Message type .18
6.3 HTTP-APIs .21
6.3.1 General .21
6.3.2 HTTP-requests .21
6.3.3 HTTP-request query parameters .21
6.3.4 HTTP-responses. 22
6.3.5 HTTP-error responses . 23
6.3.6 4891-unit authentication . 23
6.4 UDP broadcasts . 26
6.4.1 Sending UDP broadcasts. 26
6.4.2 Listening to UDP broadcasts .27
6.5 4891-message broker . 28
6.5.1 General . 28
6.5.2 Client authentication. 28
6.5.3 Connecting to MQTT-server . 28
6.5.4 Message encoding . 28
6.5.5 Publishing a 4891-message via MQTT . 28
6.5.6 Subscribe to 4891-messages via MQTT . 29
6.6 4891-service discovery . 30
6.6.1 General . 30
6.6.2 Service connectors .31
6.6.3 Service discovery API clients .32

iii
6.6.4 Service discovery API server .32
6.6.5 Service discovery API discovery packet . 33
6.6.6 Service discovery API examples . 33
6.7 4891-unit registry . 34
6.7.1 General . 34
6.7.2 Tracking of unit information . 35
6.7.3 Unit registry API clients . 35
6.7.4 Unit registry API server . 35
6.7.5 Unit registry API examples . 38
6.8 4891-unit . 40
6.9 Direct messaging API .41
6.9.1 General .41
6.9.2 Direct messaging API clients .41
6.9.3 Direct messaging API server.42
6.9.4 Direct messaging API discovery packet .43
6.9.5 Direct messaging API examples .43
6.10 Trusted communication . 44
6.10.1 General . 44
6.10.2 Public key infrastructure . 44
6.10.3 Root certificates .45
6.10.4 Unit certificates .47
6.10.5 Signing data (digital signatures) . 49
6.10.6 Encrypting data. 50
6.11 Messaging .51
6.11.1 General .51
6.11.2 Error message .51
6.11.3 Message meta structure .52
6.11.4 Receiving message from another unit . 53
6.11.5 General message processing logic . 53
6.11.6 Message relaying logic. 54
6.11.7 Message handling logic . 55
7 Test methods .55
7.1 General . 55
7.1.1 Manufacturable products . 55
7.1.2 Testing and classification .57
7.1.3 Use of simulated equipment . 58
7.1.4 Testing of UDP broadcasts .59
7.1.5 Testing of HTTP-API servers . .59
7.1.6 Testing of HTTP-API clients .59
7.1.7 Inspecting 4891-messages exchanged between 4891-units . 60
7.2 4891-compliant equipment tests . 60
7.2.1 General . 60
7.2.2 4891-message broker tests . 60
7.2.3 4891-service discovery tests .62
7.2.4 4891-unit registry tests . 63
7.2.5 4891-smart gateway unit tests . 66
7.2.6 4891-I/O unit tests .67
7.3 Shared functionality tests .67
7.3.1 General .67
7.3.2 4891-component tests . 68
7.3.3 4891-unit tests .71
7.3.4 Message broker client tests. 75
7.3.5 Service discovery API client tests .76
7.3.6 Unit registry API client tests . 77
7.3.7 Direct messaging API client tests . 78
7.3.8 Message relaying tests . 78
7.3.9 Root certificate properties tests . 79
7.3.10 Unit certificate properties tests . 79

iv
7.3.11 4891-message properties tests . 80
7.3.12 UDP discovery broadcast sending tests . . 81
7.3.13 UDP discovery broadcast listening tests . 81
7.3.14 HTTP-API server tests . 82
7.3.15 HTTP-API client tests . 83
Annex A (normative) Smart gateway — Interface to controlled equipment .85
Annex B (normative) Smart logbook — Integration with ELRB .121
Bibliography .130

v
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.
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.

vi
Introduction
In 2016, an exchange with ship managers and authorities was held to discuss why the digitalization of the
market was behind that of other industries.
Due to new regulations and the desire to increase efficiency, the shipping industry requires ever more digital
data and expertise. However, this can lead to high manual efforts and distractions.
In response to demands from stakeholders, a fast-growing digitalization process was initated. This
digitalization has nevertheless been lagging in terms of the need for fast and reliant data collection and
utilization.
In 2017, the exchange was widened to cover demands from of employees from ship to shore, to ensure
that products and solutions are applicable also for crew members and linked maritime stakeholders. In
particular, the following were addressed: data-collection, workflow support, automation and compatibility
with other stakeholders, the IoT, ship equipment and other applications and standards.
The ideas and requirements that emerged from this exchange have been developed and summarized
in this document in order to define a common base for the interoperability of digital devices onboard in
collaboration with international experts.
In the process, a modular basis has been created to enable new applications on ships and promote the idea of
preparing ship-related stakeholders for future issues, thus enabling them to work together in a secure and
trustworthy manner.
In order to meet future requirements and to enable synergies between topics and stakeholders, this
document aims to build on the existing technical basis and to add further mutually compatible modules or
applications.
The prefix “4891” (this document's ISO number) is used for some terms throughout this document to
differentiate those terms from similar terms of other documents or standards (e.g. 4891-component vs.
component).
vii
International Standard ISO 4891:2024(en)
Ships and marine technology — Interoperability of smart
applications for ships
1 Scope
This document provides operational and performance requirements for smart applications on board ships.
It is applicable to documentation, process management, connection and data collection through human-
machine interfaces, IoT technologies and related systems.
This document defines methods to implement smart network applications, which are open to participants
who implement the requirements defined in this document.
This document also describes a smart logbook application that can be used as a supplement to ISO 21745,
thus this document is subject to the same security requirements as in ISO 21745 (see Annex B).
This document defines three incremental levels of equipment-classes (see 7.1.1):
a) 4891-compliant equipment (as described in Clauses 5 to 7);
b) 4891.A-compliant equipment (as described in Clauses 5 to 7 and Annex A);
c) 4891.B-compliant equipment (as described in Clauses 5 to 7 and Annexes A and B).
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.
IEC 61162-450:2018, Maritime navigation and radiocommunication equipment and systems — Digital interfaces
— Part 450: Multiple talkers and multiple listeners - Ethernet interconnection
IEC 61162-460, Maritime navigation and radiocommunication equipment and systems — Digital interfaces —
Part 460: Multiple talkers and multiple listeners - Ethernet interconnection - Safety and security
ISO 21745:2019, Electronic record books for ships — Technical specifications and operational requirements
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
4891-component
functional part of the smart application network (3.26), such as the 4891-unit registry (3.8), the 4891-service
discovery (3.6), the 4891-message broker (3.5) or any 4891-unit (3.7)

3.2
4891-smart gateway unit
optional 4891-unit (3.7) that acts as central gateway and integration point between the smart application
network (3.26) and controlled equipment (3.15)
3.3
4891-I/O unit
optional 4891-unit (3.7) that acts as input, output and processing device implementing use case specific
functionality
Note 1 to entry: I/0 units support manual input or automatic collection via sensors of any kind and may provide
additional functions.
3.4
4891-message
structured piece of data that is exchanged between 4891-units (3.7) and used in communication with
controlled equipment (3.15)
3.5
4891-message broker
central 4891-component (3.1) that can be used by 4891-units (3.7) to publish and subscribe to 4891-messages (3.4)
3.6
4891-service discovery
central 4891-component (3.13) that provides connectivity information about the other central
4891-components (3.13)
3.7
4891-unit
4891-smart gateway unit (3.2) or 4891-I/O unit (3.3) that exchanges 4891-messages (3.4) with other 4891-units
(3.7) or communicates with controlled equipment (3.15)
3.8
4891-unit registry
central 4891-component (3.13) that acts as certificate authority and participant lookup of 4891-units (3.7)
3.9
administrator
admin
authorized person, who has the capability to setup and configure the central 4891-components (3.13) via
administration interfaces (e.g. admin web interfaces)
3.10
API endpoint
single part of an API that is addressed via a URL for accessing data or triggering a functionality
3.11
asymmetric cryptography
digitally encrypting data and verifying signatures with public key (3.23) information and decrypting and
signing data with private key (3.22) information
3.12
base URL
URL that is used as a prefix when constructing URLs to reach API endpoints (3.10)
3.13
central 4891-component
4891-component (3.1), that is not a 4891-I/O unit (3.3)
EXAMPLE 4891-message broker (3.5), 4891-service discovery (3.6), 4891-unit registry (3.8) or 4891-smart gateway
unit (3.2).
3.14
certificate
data structure containing a public key (3.23) and identity information (e.g. an identifier or name) that is
digitally signed by another trusted party, binding the key to the identity
3.15
controlled equipment
security and safety related equipment, i.e. equipment according to IEC 61162-450/ IEC 61162-460
EXAMPLE The electronic record book.
3.16
data encryption
transformation of original data with the intention that the original data can only be transformed back by its
designated recipient
3.17
instrumentation
running of software in a special mode that allows measuring of performance and tracing of code execution
and information
3.18
key-pair
pair of related public keys (3.23) and private keys (3.22) used in asymmetric cryptography (3.11)
3.19
message relaying
receiving a 4891-message (3.4) that is targeted to a different 4891-unit (3.7) with the intention of forwarding
that message to that unit in some way
3.20
mobile device
non-stationary data processor that can be moved around
EXAMPLE Smartphones and tablets.
3.21
PEM encoding
common format for serializing cryptographic components such as private keys (3.22), public keys (3.23), and
certificates (3.14)
3.22
private key
secret part of a cryptographic key-pair (3.18) that should be kept a secret and is used for signing data (3.24)
or decrypting data
3.23
public key
public part of a cryptographic key-pair (3.18) that can be shared and is used for validating signed data or
data encryption (3.16)
3.24
signing data
attaching an additional signature data to an original data with the purpose that any modification of the
original data is discoverable
3.25
smart application
function for mobile devices which makes it possible to confidentially collect data directly on board ships,
evaluate it and control procedures

3.26
smart application network
SAppNet
sappnet
4891-network
set of central 4891-components (3.13) and all registered 4891-units (3.7) that communicate via the exchange
of 4891-messages (3.4)
3.27
X.509 certificate
common format for storing and exchanging digital certificates (3.14)
Note 1 to entry: For further information on X.509, see RFC 5280.
4 Abbreviated terms
API application programming interface
CA certification authority
DSA digital signature algorithm
ECDSA elliptic curve digital signature algorithm
ELRB electronic record book (see ISO 21745)
EUT equipment under test
HTTP hypertext transfer protocol (see RFC 2616)
IDE integrated development environment
IoT Internet of Things ®
JSON JavaScript object notation (see RFC 8259)
LAN local area network
MQTT message queuing telemetry transport (see ISO/IEC 20922:2016)
PEM privacy-enhanced mail
PKI public key infrastructure
RSA RSA cryptosystem (Rivest–Shamir–Adleman)
SCRAM salted challenge response authentication mechanism (see RFC 5802)
SAppNet smart application network
SHA secure hash algorithm
OOW officer of the watch
UDP user datagram protocol
URL uniform resource locator
USB universal serial bus
UTC coordinated universal time

UUID universally unique identifier
5 Smart application network
5.1 Overview
A smart application network (see Figures 1 to 4), is an uncontrolled network focusing on uncritical
interactions and contents. Each device may join the network at any time, and disconnect and reconnect as
necessary. Communication between the network participants is done by passing messages in specified ways.
The network consists of the message exchange semantics between its various participants. The document
defines the message structure as a common language to be used.
To ensure compatibility between different manufacturers, an implementation based on the interfaces
described in Clause 6 shall be fulfilled.
If controlled equipment is connected to the smart application network via a 4891-smart gateway unit,
then that controlled equipment shall be implemented in accordance with the requirements of Annex A.
If that controlled equipment represents an ELRB, then that controlled equipment shall furthermore be
implemented in accordance with Annex B (see Figures 3 to 4).
Figure 1 illustrates the positioning of this new network in relation to other existing onboard networks and
standards. Figures 2 to 4 give examples of three different configurations and show how the smart application
network connects with other existing networks and systems.
Figure 1 — Connectivity of 4891-network with other existing vessel networks

Key
data communication (e.g. via ethernet, wifi, bluetooth)
optional data communication
NOTE This configuration uses the equipment specified in this document, excluding the equipment specified in
Annex A and Annex B.
Figure 2 — Configuration example — Basic smart applications setup

Key
data communication (e.g. via ethernet, wifi, bluetooth)
optional data communication
NOTE This configuration uses equipment specified in this document, including in Annex A and Annex B.
Figure 3 — Configuration example — Smart logbook as supplement to ELRB

Key
data communication (e.g. via ethernet, wifi, bluetooth)
optional data communication
NOTE This configuration uses equipment specified in this document, including in Annex A and Annex B.
Figure 4 — Configuration example — Smart logbook as supplement to ELRB with additional
functions
5.2 4891-components
5.2.1 General
The smart application network shall be composed of network entities as listed in Table 1.
Table 1 — 4891-component quantities in smart application network
4891-component Mandatory Quantity
Message broker Yes 1
Service discovery Yes 1
Unit registry Yes 1
Smart gateway unit No 1
I/O unit No Unlimited
Figure 5 — Hierarchy of 4891-components
The message broker, service discovery, unit registry and smart gateway unit are grouped as central
4891-components (see Figure 5). Together with the I/O units, these are called 4891-components (see
Figure 5).
The smart gateway unit shall be installed onboard of the vessel if connectivity between smart application
network and controlled equipment is desired (see Annex A).
The 4891-network shall contain at most one 4891-smart gateway unit acting as a central gateway to
controlled onboard networks (see Figures 3 and 4). Additionally, a conceptually unlimited number of 4891-
I/O units may be added to the network, permanently or temporarily.
Manufacturers may enforce a limit to the maximum number of 4891-I/O units for technical reasons. Such a
number shall be stated in the manufacturer's documentation.
5.2.2 4891-message broker
A central message broker shall be part of the smart application network.
The broker shall accept incoming 4891-messages from 4891-units, which are then sent to other interested
4891-units.
The broker shall allow 4891-units to subscribe to message topics. Those topics shall act as filters. The broker
shall send the messages fulfilling the filter criteria to the subscribed 4891-units. At least the following
message filters shall be supported:
— message type;
— message source unit;
— message destination unit;
— message destination kind: single destination versus broadcast.
The 4891-message broker can be unreliable when delivering a message. In such cases, 4891-units shall take
suitable counter-measurements to enforce the reliability of the message (i.e. by resending and acknowledging
messages).
The 4891-message broker may provide a buffering functionality to retry delivering messages, so as to
improve delivery behaviour in an unstable connected network.
5.2.3 4891-service discovery
The 4891-service discovery shall provide connectivity information (“connectors”) about the other central
4891-components. These connectors include:
— 4891-message broker;
— 4891-unit registry;
— 4891-smart gateway unit.
Those connectors shall be queryable by all 4891-components.
The service discovery shall have a functionality to configure those connectors by authorized persons. How
such configuration can be accomplished shall be described in the manufacturer’s documentation.
5.2.4 4891-unit registry
The 4891-unit registry shall provide the functionality for equipment to register itself as a 4891-unit
when logically joining or leaving the smart application network. The list of registered 4891-units shall be
queryable from the registry by all 4891-components.
The 4891-unit registry shall also act as the certificate authority for trusted message exchange in the smart
application network. The 4891-unit registry shall provide the registering units with data that can be used to
encrypt, decrypt and sign messages. Furthermore, the registry shall provide the functionality for 4891-units
to lookup information, allowing them to encrypt, decrypt and sign messages as needed (see 5.7), i.e. by using
PKI, issuing signed unit certificates, and allowing lookup of public keys of units.
5.2.5 4891-units
5.2.5.1 General
A 4891-unit is part of a manufacturer-specific application that is implemented on top of the smart application
network. For that reason, one or more units perform logic and exchange information.
4891-units shall provide functionality to create and process 4891-messages as a mechanism to exchange
information with other 4891-units.
4891-units may exchange 4891-messages directly with other 4891-units (i.e. direct messaging, see 5.5),
indirectly via other 4891-units (i.e. message relaying, see 5.6) or via the central 4891-message broker,
depending on capabilities and purpose of units.
Two types of 4891-units are distinguished by their intended purpose:
— the smart gateway unit is intended for integration with other onboard equipment in controlled networks;
— the I/O unit is intended for data collection, data processing and data interaction by users.
5.2.5.2 4891-smart gateway unit
The 4891-smart gateway unit is an optional central component of the smart application network. It is the
integration point with other potentially controlled networks. In that regard, the 4891-smart gateway unit acts
as a gateway and firewall between the controlled equipment of those networks and the 4891-components.
The 4891-smart gateway unit regulates data access between 4891-I/O units and systems in controlled
networks depending on system specific requirements.
If a 4891-smart gateway unit is part of the 4891-network, it shall be permanently connected to the
4891-message broker, subscribing at least to 4891-messages targeted at the smart gateway unit.
If existing, the 4891-smart gateway unit shall be installed onboard of the vessel.
If the 4891-smart gateway is connected to navi
...