557
1 INTRODUCTION
The maritime domain is undergoing a progressive
digital transformation. In the context of e-navigation,
information that has traditionally been distributed
through heterogeneous communication channels and
presented in different formats is increasingly being
structured, exchanged and presented digitally. The
International Maritime Organization (IMO) defines e-
navigation as the harmonised collection, integration,
exchange, presentation and analysis of marine
information on board and ashore by electronic means,
to enhance berth-to-berth navigation and related
services for safety and security at sea [13, 15]. The
development of the S-100 framework by the
International Hydrographic Organization (IHO) is a
central element of this transition. S-100 is not a single
chart product but a framework for a family of maritime
geospatial data products. The current IHO catalogue
includes, among others, S-101 Electronic Navigational
Chart, S-102 Bathymetric Surface, S-104 Water Level
Information for Surface Navigation, S-111 Surface
Towards an Open Platform for S-100 Service
Experimentation: A Proof-of-Concept S-124
Navigational Warnings Plugin for OpenCPN
P. Merino Laso & H. Ahmad
French Maritime Academy, Nantes, France
ABSTRACT: The transition from the S-57 electronic navigational charting environment towards the IHO S-100
framework is introducing a growing family of interoperable maritime data products and services. With S-100-
capable ECDIS becoming installable from January 2026 under IMO resolution MSC.530(106), this evolution
creates a pressing need for software environments in which researchers, hydrographic offices, educators and
developers can experiment with, validate and demonstrate emerging S-100 services without depending
exclusively on proprietary, safety-certified navigation systems. This paper identifies a set of requirements for
such an open S-100 experimentation platform and evaluates the open-source application OpenCPN as a candidate
host. Guided by these requirements, a proof-of-concept (PoC) implementation of S-124 Navigational Warnings
was developed as an OpenCPN plugin and released publicly under GPLv3 with its full source code and cross-
platform build automation. The plugin ingests S-124 datasets both from local GML (Geography Markup
Language) files and from live Secure Communication between ship and shore (SECOM) service endpoints; it
parses warning metadata, temporal validity and geometry, and renders point, curve and surface features as an
interactive overlay on the OpenCPN chart canvas. The implementation was exercised against operational data
from PING, the French national navigational-warning distribution platform, retrieving navigational warnings
across multiple SECOM series. We evaluate the resulting system against the identified requirements and position
it relative to existing S-124 efforts. The objective is not to present a type-approved navigation system, nor a
quantified improvement in navigational safety, but to demonstrate that an open, modifiable navigation
environment can serve as a practical basis for S-100 experimentation and for future research into presentation,
interoperability, scenario-based testing, situational awareness, safety and maritime security.
http://www.transnav.eu
the International Journal
on Marine Navigation
and Safety of Sea Transportation
Volume 20
Number 3
September 2026
DOI: 10.12716/1001.20.03.04
558
Currents, S-124 Navigational Warnings and S-129
Under Keel Clearance Management [12]. This
transition is no longer purely prospective: following
the adoption of IMO resolution MSC.530(106), S-100-
capable ECDIS may be installed on a voluntary basis
from 1 January 2026, and from 1 January 2029 all newly
installed ECDIS must comply with the revised
performance standards [10, 14]. The growing number
of products creates opportunities for richer and more
integrated information on the bridge, but it also creates
an immediate need for software in which their use can
be explored, tested and taught.
S-124, Navigational Warnings, is particularly
relevant to this evolution. The IHO defines S-124 as a
product specification for datasets containing
navigational-warning information, intended for use as
a Navigational Warning Information Overlay within
ECDIS. A navigational warning is urgent information
relevant to safe navigation, and is therefore a natural
candidate for digital dissemination and graphical
presentation [11]. Warnings may concern hazards,
casualties, temporary restrictions, special operations
and other situations that can require a mariner to
increase awareness or modify a voyage plan. A
concrete illustration is a fire aboard a containership.
Beyond the emergency response on board, the casualty
becomes a hazard to surrounding traffic – typically
requiring a temporary exclusion or restricted area,
assistance from nearby vessels and coordination with
shore authorities – and S-124 is the standardised means
of conveying the resulting navigational warning to
other ships, including information about lost
containers drifting as hazards to navigation. Scenarios
of this kind, involving fire incidents aboard cargo
ships, are being studied in the OVERHEAT project [1,
2] and motivate the present work.
The transition to S-100 therefore creates not only a
data-production challenge but also an application and
evaluation challenge. Researchers and educators may
need to modify the presentation of a new product,
inject controlled datasets, reproduce a navigation
situation, compare alternative interfaces, or combine
several S-100 products. These activities are difficult to
perform when the only available software
environment is a proprietary and safety-certified
navigation system whose source code and behaviour
cannot be modified.
This paper addresses the following research
question: What characteristics should an open software
platform provide to support experimentation and
evaluation of S-100 maritime services, and can an open-
source navigation platform demonstrate these
characteristics through an S-124 implementation?
The contribution is framed at two levels. First,
requirements for an open S-100 experimentation
platform are identified from the perspective of
research, education, prototyping and validation.
Second, an S-124 PoC is used as an implementation
case study to assess whether an existing open-source
navigation application can provide such an
environment, and to position that environment relative
to existing S-124 systems. The plugin is therefore an
experimental artefact supporting the research question
rather than the sole research contribution.
This paper is organised as follows. Section 2 reviews
the S-100/e-navigation context and related software
and services. Section 3 presents the motivation and
requirements for an open experimentation platform.
Section 4 describes the selection of OpenCPN and the
implementation of the S-124 PoC, including results
obtained with operational data. Section 5 evaluates the
implementation against the identified requirements.
Section 6 discusses implications for scenario-based
research, safety and security, limitations and future
work. Section 7 concludes.
2 RELATED WORK
2.1 E-navigation, situational awareness and S-100
The IMO e-navigation strategy is explicitly concerned
with harmonising information and systems to improve
navigation and related services for safety and security
[15]. The strategy implementation plan emphasises
user needs and identifies improved integration and
presentation of available information as one of its e-
navigation solutions [13]. This is directly relevant to the
evaluation of S-100 services: technical interoperability
alone does not determine whether a digital service
improves the mariner’s understanding of a situation.
Recent work by the authors in maritime fire safety
has examined how digital information systems and S-
100-based information sharing can contribute to shared
situational awareness and decision support [1, 2].
These studies motivate a broader question for S-100
research: how can researchers rapidly prototype and
evaluate information services and their presentation
without being tied to a particular proprietary
navigation system? The S-100 framework provides a
common basis for a growing family of products [12],
and this diversity makes an experimentation platform
particularly useful, because different products may
require different presentation, interaction, temporal or
spatial-analysis mechanisms.
2.2 S-124 Navigational Warnings
S-124 is an S-100 product specification for navigational
warnings. Edition 2.0.0, dated March 2025, is identified
by the IHO as the first operational edition of S-124 and
is associated with S-100 Edition 5.2.0 [11]. An S-124
warning is simultaneously a semantic object (its type,
category and text), a temporal object (publication,
cancellation and effective validity) and a spatial object
(point, curve or surface geometry). This tripartite
nature is precisely what makes S-124 a useful vehicle
for experimentation: a research platform can support
investigations into whether warnings are noticed, how
their spatial extent is interpreted, how temporal
validity is communicated, and how warning
information should be associated with a vessel’s route
or operational context.
2.3 Existing S-124 systems and services
S-124 has already been the subject of substantial
operational and pre-operational work. The Sea Traffic
Management (STM) Validation project pioneered the
delivery of navigational warnings directly into ECDIS
using the draft S-124 format, validating the concept
with ships and within the European Maritime
Simulator Network and reporting reduced crew
559
workload compared with manual transcription from
NAVTEX or voice broadcast [22]. On the production
side, Niord is an open-source editor and publication
system for navigational warnings and notices to
mariners, originally developed in the EfficienSea2 EU
project and deployed operationally by the Danish
Maritime Authority, and subsequently aligned with
the S-124 model [5]. Several hydrographic and
coastguard authorities now expose S-124 through
SECOM services [9]. The Canadian Coast Guard
operates a public S-124 test service using a web-based,
system-to-system SECOM interface [3], and in France
the SHOM PING platform distributes operational S-
124 datasets over a dedicated SECOM service [23].
Delivery mechanisms are likewise diversifying:
Sternula and partners disseminate S-124 warnings over
VDES (VHF Data Exchange System) using the
Maritime Messaging Service and the Maritime
Connectivity Platform (MCP), with authenticated
shore-to-ship delivery [24]. On the presentation side, a
recent effort in China describes an intelligent S-124
visualisation service spanning data production and use
in mobile apps and shipborne electronic chart systems
[26].
Commercial maritime software development kits
also provide mature tooling for visualising and
processing ENC and S-100 data. The Nautilus Maritime
SDK, for example, is marketed as a development kit for
visualising, querying and rendering ENC and S-100
data, including production-oriented S- 100 capabilities
[25]. Such tools reduce implementation effort for
commercial products, but the research problem
addressed here is different: the researcher or educator
needs source-code accessibility, unrestricted
modification, low acquisition barriers, and the ability
to construct experimental scenarios independently of a
commercial vendor.
2.4 OpenCPN as a candidate open host
OpenCPN represents a complementary approach. It is
an open-source navigation application with a plugin
architecture for third-party extensions, and its core is
released under GPLv2+ [17]. The development
documentation describes a decentralised plugin
ecosystem in which plugins can be developed
independently of the core project, and plugins can add
overlays, menu items and dialogs to the chart canvas
[18]. This makes OpenCPN a candidate host for
experimental S-100 services rather than a replacement
for type-approved ECDIS.
Beyond its technical suitability, OpenCPN’s reach
strengthens the case for using it as a host in two ways.
First, it is already an established platform in maritime
research: it has been chosen, for example, as the open
navigation system for testing the interoperability of
automatically compiled S-100/S-101 charts in a web-
based charting testbed [4], and as a monitoring and
AIS-tracking component in maritime cyber-physical
testbeds and e-navigation assessment platforms [20].
Building an experimental service on OpenCPN
therefore places it in an environment that other
researchers already use and can reproduce. Second,
OpenCPN is a widely used operational electronic chart
system (ECS) rather than a type-approved ECDIS, and
is found aboard a broad range of recreational and small
commercial craft, including sailing yachts, motor
vessels, fishing boats and pilot vessels. It can be
installed directly on standard computers or run on
low-cost embedded hardware – for example through
OpenPlotter, a Raspberry Pi-based marine software
suite that bundles OpenCPN [19]. Because it can ingest
and display live AIS streams, it is also used ashore as a
low-cost tool for monitoring vessel traffic in coastal and
port areas – for example, in harbour masters’ offices, to
organise ship reception and manage vessel movements
within the port, and in AIS traffic-monitoring research
[16, 20]. This matters for impact: such non-SOLAS
vessels are generally not subject to mandatory ECDIS
carriage and may not receive S-124 warnings through
certified shipboard systems, yet they navigate the same
congested and hazardous waters. An open, freely
installable S-124 capability for OpenCPN can therefore
bring standardised digital navigational warnings to a
large segment of the fleet that would otherwise remain
outside the S-100 information flow, extending the
value of the work from the research setting to real-
world non-SOLAS navigation.
2.5 Positioning of this work
Table 1 situates the present work within this landscape.
The existing efforts are, respectively, operational or
pre-operational dissemination services (STM [22], CCG
[3], SHOM/PING [23], Sternula [24]), shore- side
authoring and publication systems (Niord [5]),
production-oriented visualisation services (the
Chinese S-124 service [26]) or proprietary development
kits (Nautilus [25]). None of them is, at the same time,
open-source, freely modifiable, and oriented towards
onboard display and controlled experimentation. That
combination is the gap this paper addresses: an open,
inspectable, and modifiable onboard environment in
which S-124 – and, prospectively, other S-100 products
– can be received, portrayed, and studied for research
and education.
Table 1. Positioning of the S-124 PoC relative to existing S-
124 efforts.
Effort
Open
source
Orientation
STM / Baltic
NW [22]
No
Operational /
validation testbed
Niord [5]
Yes
Shore-side
production
CCG S-124
[3]
No
Operational (test)
service
SHOM PING
[23]
No
Operational
distribution
Sternula [24]
Partly
Operational
delivery
China S-124
[26]
No
Production / app +
ECS
Nautilus
SDK [25]
No
Commercial
development
This work
Yes
Research / education
3 MOTIVATION AND REQUIREMENTS
IDENTIFICATION
3.1 Research and development need
SOLAS vessels operating under mandatory carriage
requirements depend on approved navigation
equipment and procedures. Research, education and
560
prototyping have different needs. A researcher
developing a new S-100 presentation concept may
need to modify source code, inject synthetic or
historical datasets, create controlled situations,
compare alternative visualisations, or deliberately test
abnormal cases. A university may need software that
students can install and modify without expensive
proprietary licences. Commercial systems can provide
high-quality, safety-critical functionality, but their
modifiability is generally constrained by their
commercial and technical models, and dependence on
a proprietary development environment can introduce
procurement, licensing and administrative constraints
that slow research iteration and hinder reproducibility.
The aim is therefore not to replace certified navigation
equipment, but to provide a complementary
environment in which new S-100 services can be
explored before formal operational validation.
3.2 Identified requirements
Building on the e-navigation emphasis on user needs
and information presentation [13] and on the
accessibility and reproducibility expectations of
research and education [8], we identify the following
requirements for an open S-100 experimentation
platform:
1. Open source: source code should be available for
inspection and modification.
2. Free to use: the platform should not require a
commercial ECDIS licence.
3. Cross-platform: the environment should run on
commonly available operating systems and
architectures.
4. Easily extensible: new S-100 products should be
implementable as extensions rather than requiring
a complete application rewrite.
5. Suitable for rapid prototyping: researchers should
be able to modify and iterate on experi- mental
functions quickly.
6. Capable of generating and replaying test scenarios:
controlled situations should be reproducible and,
ideally, replayable.
7. Independent of commercial ECDIS vendors:
research should not depend on a proprietary ECDIS
development ecosystem.
8. Suitable for education and training: students and
instructors should be able to install, inspect and
modify the environment.
9. Compatible with multiple S-100 products: the
architecture should be reusable beyond a single
product specification.
The distinction between a research platform and an
operational navigation system is fundamental. The
requirements above describe an environment for
experimentation and validation; they are not proposed
as requirements for type approval.
4 PROOF-OF-CONCEPT: S-124 INTEGRATION IN
OPENCPN
4.1 Selection of OpenCPN
OpenCPN was selected because its characteristics align
with the requirements above. The project is open
source, its core is distributed under GPLv2+, and its
plugin architecture explicitly supports third- party
functional extensions [17, 18]. Implementing an S-100
service as a plugin lets the experimental software be
developed, distributed and modified independently of
the core navigation application, which reduces its
scope and lowers the barrier to reuse.
The plugin targets the OpenCPN Plugin API 1.16
and is written in C++11. Its build system uses CMake
and depends on wxWidgets, libcurl and OpenGL. The
repository includes continuous integration workflows
that build packages for Linux x86 64, Linux ARM64
(including Raspberry Pi) and Windows, providing a
practical basis for multi-platform distribution. The
plugin is released under GPLv3 with its full source
code [6].
4.2 Plugin architecture
The plugin is organised into the functional components
shown in Fig. 1:
− Plugin controller: initialises the OpenCPN plugin,
creates the toolbar entry, persists config- uration,
manages the auto-refresh timer, and connects user
actions to the data and rendering components.
− S-124 parser: parses XML/GML data and extracts S-
124 warning information.
− Warning model: represents warning metadata, text,
temporal information and geometry, and computes
a centroid for each warning.
− Points layer: converts geographic coordinates to
screen coordinates, renders warning geometries
through both the wxWidgets device-context and the
OpenGL paths, and performs hit testing.
− SECOM client: retrieves warning data from
configured service endpoints and decodes the
returned payloads.
− User-interface dialogs: configure SECOM
connections, automatic refresh and warning
colours, and display detailed warning information.
Figure 1. Architecture of the S-124 PoC.
Data sources (local GML files or SECOM endpoints)
feed the parser; the warning model is rendered by the
points layer as an overlay on the OpenCPN chart
canvas. Solid arrows denote the data path. The plugin
is confined to the OpenCPN plugin boundary and does
not modify the host core.
This separation is central to the experimentation-
platform concept: the data-processing and
presentation logic lives entirely in plugin components,
while OpenCPN supplies the chart display
environment, plugin infrastructure and user
interaction.
561
4.3 S-124 GML parsing
The parser uses the XML facilities provided by
wxWidgets and identifies elements by their local name,
so that namespace prefixes may vary between
producers. It performs two passes over the document.
In the first pass, NavwarnPreamble features are
collected into warning objects, from which the parser
extracts the GML identifier, warning number, year,
series name, warning type (read from the code
attribute rather than the element text), general
category, publication time, cancellation date and
area/locality names. In the same pass, NavwarnPart
features are collected together with the reference that
links a part back to its preamble, the warning text and
subject, the effective date range (including time of day)
and language, and the part geometry. In the second
pass, each part is attached to its preamble,
concatenating message text and merging temporal and
language information.
The geometry parser supports point, curve and
surface representations, handling Point, LineString,
Curve, Surface, Polygon and PolygonPatch elements,
unwrapping S-100 property containers (pointProperty,
curveProperty, surfaceProperty), and recursing into
multi-geometry and geometry- collection structures.
Coordinates are stored as latitude/longitude pairs
following the S-100 axis order, and a centroid is
computed for each warning for interaction and display.
4.4 Data sources and SECOM retrieval
The plugin supports two acquisition modes. In the first,
the user loads a single local S-124 GML/XML file or
selects a folder, in which case the plugin parses every
GML/XML file found and combines the successfully
parsed warnings, reporting errors. This mode provides
controlled, repeatable inputs that are well suited to
experimentation.
Figure 2: SECOM retrieval and decoding flow.
The second mode retrieves data from one or more
configured SECOM endpoints. Each connection carries
a name, base URL, optional data reference, optional
API key, optional client certificate and key for mutual
TLS, an optional CA bundle, an SSL-verification toggle
and a timeout; multiple connections can be configured
and their results combined. First, as summarised in Fig.
2, the SECOM client tries up to three retrieval strategies
in order. It first issues paginated GET /v1/object
requests (as used by the PING SECOM node), reading
the dataResponseObject array and computing the
remaining items from the reported pagination. If that
endpoint is absent or unrecognised, it issues POST
/v1/searchService requests with offset-based
pagination, reading the responseObject array and
remainingObject counter. If the server does not accept
the POST (for example, returning HTTP 405), the client
falls back to a direct GET of the base URL. The client
recognises the several JSON response-array names
used across SECOM implementations.
Returned objects carry base64-encoded payloads.
After decoding, the client inspects the leading bytes
and transparently handles plain GML, gzip-
compressed GML, and ZIP archives containing GML
– the last being relevant to S-100 Exchange Set
handling. Successfully decoded content is passed to the
same S-124 parser used for local files, so both modes
share a single, testable ingestion path. An optional
auto-refresh timer can periodically re-fetch the
configured connections; the default interval is 15
minutes and is user-configurable.
4.5 Visualisation and interaction
The plugin renders S-124 warnings as an overlay on the
OpenCPN chart canvas, through both the device-
context and OpenGL rendering paths so that display is
consistent regardless of the active canvas mode. Point
geometries are drawn as filled circular markers with a
light outline, curves as lines, and surfaces as semi-
transparent filled polygons with a solid outline.
Warnings that carry multiple geometries, and surface
warnings, additionally receive a centroid diamond that
provides a convenient interaction target.
The colour of a warning is derived from its warning
type, grouping warnings into local, coastal, sub-area
and NAVAREA classes, with a fallback class for other
values; the user can reconfigure these colours through
the plugin interface, and the mapping is applied
consistently across every SECOM connection. The
plugin implements hit testing for points (proximity),
curves (distance to segment) and surfaces (point-in-
polygon), iterating from the topmost drawn feature so
that overlapping features resolve predictably. Clicking
a warning opens a detail dialog presenting, when
available, the warning series, number and year, type,
category and subject, area, effective period, publication
and cancellation information, language, centroid
position and full warning text.
This interaction is intentionally simple. The PoC
does not implement a separate alarm or alerting
subsystem; its present objective is to demonstrate the
ingestion, spatial presentation and inspection of S-124
information in an open navigation environment.
4.6 Results with operational data
The implementation was exercised against operational
S-124 Edition 2.0.0 data published by the French
national navigational-warning platform PING,
operated by the SHOM [23]. The platform exposes
navigational warnings (AVURNAV), inland-waterway
notices (AVINAV) and port and harbour notices
(AVIRADE) as separate SECOM series, spanning
metropolitan France and the overseas coordination
centres (Brest, Cherbourg, Toulon, Cayenne, Fort-de-
France, La R´eunion and Papeete); public access
requires no API key. This provides a realistic, multi-
source, multilingual testbed rather than synthetic data
alone.
562
Figure 3. S-124 warnings rendered in OpenCPN after
retrieval from three SECOM connections on the PING
platform with 85 received navigational warnings.
Figure 4. Inspection of an individual warning. The dialog
presents warning metadata, temporal validity, position and
text while the surface geometry remains visible on the chart.
Figure 3 shows the plugin after retrieval from three
SECOM connections, in which the demonstration
received 85 navigational warnings and rendered their
point, curve and surface geometries across the western-
European maritime area. Figure 4 shows the inspection
of an individual warning – an AVURNAV LOCAL
BREST notice describing a scientific-survey special
operation near the Saint-Nazaire (Gu´erande) offshore
wind farm – with its metadata, effective and
cancellation times, position and French-language text
presented while the surface geometry remains visible
on the chart. Together, these results confirm end-to-
end operation against a live national service: SECOM
retrieval and pagination, payload decoding, extraction
of semantic, temporal and spatial attributes, geometry
rendering, and interactive inspection.
4.7 Integration into a maritime simulator
A first building block for scenario generation is already
in place. Because the plugin ingests S-124 from local
GML files, warnings can be authored manually and
loaded directly, independently of any operational
service. We verified this by hand-crafting custom S-124
datasets and displaying them in OpenCPN running
inside the SOMOS maritime simulator [7, 21] (Fig. 5
and Fig. 6), confirming that self-authored warnings can
be injected into a simulated navigation environment
and rendered exactly as service-sourced warnings are.
This demonstrates a concrete training application:
an instructor can compose bespoke navigational
warnings—with chosen hazards, affected areas,
warning types and validity periods—and present them
to trainees within a simulator exercise, rather than
being limited to whatever warnings a live service
happens to be publishing.
Figure 5. Manually authored S-124 warnings as displayed by
the plugin in OpenCPN.
Figure 6. The S-124 plugin running in OpenCPN on the
SOMOS maritime simulator.
5 EVALUATION
The evaluation considers whether the implementation
demonstrates the characteristics required of an open S-
100 experimentation environment. It does not evaluate
the software as a certified ECDIS and does not claim a
measured improvement in navigational safety. For
each requirement, Table 2 states the status supported
by the PoC and the residual gap that remains for future
work.
The assessment supports the central hypothesis: an
open navigation application with a plugin architecture
can host an S-100 PoC. Two properties are decisive.
First, source-code availability makes the
implementation inspectable and modifiable rather
than an opaque instrument. Second, the plugin
boundary cleanly separates the experimental service
from the host navigation application. The
implementation also shows that the platform supports
both offline experimentation, through controlled local
GML inputs, and service-based retrieval, through live
SECOM connections – a combination that lets
repeatable experiments use fixed datasets while
integration issues are explored against operational
services such as PING (Section 4.6).
The evaluation also exposes the principal gap: the
platform does not yet provide a formal scenario-
563
generation and replay framework. The local-file
mechanism is a useful building block, but a research
platform should ultimately represent a scenario as a
reproducible package containing data products, vessel
state, route, time and other contextual information.
5.1 Potential contribution to safety and maritime security
The PoC should not be read as evidence that S-124
integration automatically improves safety; rather, it
provides a technical capability that can enable future
evaluation of such hypotheses. For example, a
controlled scenario could contain a vessel route and
one or more S-124 warnings representing a hazard such
as a lost container, a casualty, a temporary restriction
or a special operation. The same scenario could then be
presented using different display concepts, and
researchers could measure warning- detection time,
localisation accuracy, comprehension, route-deviation
decisions or other human-factors variables. This
capability is relevant to the safety objective of e-
navigation, which the IMO explicitly links with the
harmonised integration and presentation of
information for safety and security at sea [15]. It is
equally relevant to maritime security and resilience
research: an open platform can be modified to study
degraded information, conflicting warnings,
incomplete datasets or service interruptions in a
controlled environment, without altering an
operational navigation system. The contribution of the
present work is to enable such experiments rather than
to report their safety results.
6 DISCUSSION
6.1 From a plugin to a reusable research platform
The S-124 plugin is an artefact resulting from a broader
need: an environment in which emerging S-100
services can be implemented and assessed without
depending exclusively on proprietary navigation
software. Its architecture suggests a reusable
development pattern in which product-specific
parsing and data structures are isolated in plugin
components while the host application provides chart
display, user interaction and a general navigation
environment. Future plugins could investigate other S-
100 products and share common scenario, service and
visualisation components. The current IHO catalogue
contains many candidate products for such
experimentation, including S-102, S-104, S-111, S-125,
S-127, S-128 and S-129 [12]; implementing several of
them would test whether OpenCPN can serve as a
general S-100 experimentation platform rather than
only an S-124 demonstrator.
6.2 Scenario generation and reproducibility
A first approach to scenario development with
maritime simulators has been demonstrated, as
described in Section 4.7. What remains to be built is a
structured scenario layer around this capability. A
future platform should distinguish a single data
product from a complete navigation scenario, where a
scenario could define one or more S-100 datasets;
vessel position and movement; a route and relevant
waypoints; a time reference and event timeline;
environmental or operational context; and optional
faults, omissions or conflicting information. For S-124
this would turn today’s manual dataset authoring into
controlled, repeatable variation of warning position,
affected area, warning type, validity period and
relationship to the vessel route. A scenario could then
be stored and replayed so that different display or
interaction concepts are compared under identical
conditions, moving the platform from a demonstrator
towards a reusable experimental testbed for software
testing, training, human-factors experiments,
interoperability studies and demonstrations.
The open-source model also supports
reproducibility. The repository contains the source
code, build system, automated build workflows,
screenshots and documentation, and the plugin is
distributed under GPLv3, so that another researcher
can inspect, build or modify it rather than treating it as
an opaque instrument. Full scientific reproducibility
additionally requires versioned datasets, documented
configurations, scenario definitions and test
procedures; these should be included in future releases
associated with specific experiments.
6.3 Limitations
Several limitations should be acknowledged. The
implementation is explicitly a PoC: as the repository
states, it has not undergone the testing or validation
expected of production navigational software and
must not be treated as a certified navigational aid or as
the sole means of receiving navigational warnings. The
parser does not perform formal S-124 schema or
Portrayal Catalogue validation; it extracts the
structures needed for the demonstration, and future
work should validate against the relevant IHO
artefacts and document the supported edition and
feature coverage more formally. The evaluation is
qualitative: it demonstrates technical capabilities and
assesses requirements, but does not quantify effects on
situational awareness, warning detection, decision-
making, safety or security. S-124 is the only S-100
product currently implemented, so the proposed
generality of the platform remains a hypothesis.
Finally, although build automation targets several
platforms, systematic compatibility and performance
testing has not yet been established and should precede
larger experimental campaigns.
6.4 Future work
Future work should proceed along four
complementary directions. First, the S-124
implementation should be strengthened through
systematic validation against S-124 Edition 2.0.0
datasets and schemas, covering different warning
types, temporal conditions and geometry
combinations. Second, realistic scenario datasets
should be produced to create controlled multi-product
S-100 navigation situations; in particular, within the
OVERHEAT project we will develop scenarios centred
on fire incidents aboard containerships, building on the
project’s work on shared situational awareness and
information management for maritime fire safety [1, 2].
Third, additional S-100 products should be
implemented to test the scalability of the plugin-based
564
architecture and to investigate interoperability
between products. Fourth, human-centred
experiments should be conducted with representative
users to compare warning-presentation concepts and
measure detection, interpretation, localisation and
decision-making – providing the evidence needed to
move from a technical PoC towards quantified claims
about safety and situational awareness.
Table 2. Assessment of the identified requirements against
the S-124 PoC, with residual gaps.
Requirement
Status
Evidence and residual gap
Open source
Met
Full source is public under GPLv3
[6].
Free to use
Met
Distributed as free/open-source
software; no commercial ECDIS
licence required.
Cross-platform
Met
Plugin available for Linux x86 64,
Linux ARM64 (Raspberry Pi) and
Windows.
Easily extensible
Demonstrated
S-124 is implemented as an
independent plugin using the
Plugin API, without modifying the
OpenCPN core.
Rapid prototyping
Demonstrated
Parsing, rendering and interaction
were developed and iterated
purely in plugin components.
Scenario
generation/replay
Demonstrated
Local GML files and folders give
controlled inputs. Simple
dedicated scenarios have been
tested with a maritime simulator.
A structured scenario-definition
and replay framework is still to be
built.
Vendor
independence
Met
Development and execution
require no proprietary ECDIS
licences.
Education and
training
Partially met
Free distribution and readable
source lower access barriers;
custom warnings were shown in a
maritime simulator; a dedicated
educational evaluation is future
work.
Multiple S-100
products
Not yet met
S-124 is the first product
implemented; generality must be
shown through additional
products.
7 CONCLUSION
The transition towards S-100-based maritime
information creates new opportunities for e-
navigation, but also a need for accessible environments
in which new services can be explored before they
enter operational systems – a need made concrete by
the arrival of S-100-capable ECDIS from 2026. This
paper identified nine requirements for an open S-100
experimentation platform and selected OpenCPN as a
candidate host because its open-source model and
plugin architecture align with them. An S-124
Navigational Warnings PoC was developed and
publicly released under GPLv3. It loads local S-124
GML data, retrieves warnings from SECOM endpoints,
parses warning metadata, temporal validity and
spatial information, renders point, curve and surface
geometries on the OpenCPN chart canvas, and
provides interactive access to warning details; it was
validated end-to-end against operational data from the
French PING platform.
The main contribution is therefore not the plugin
alone, but the demonstration of an open research
approach in which S-100 services can be implemented
and evaluated independently of proprietary ECDIS
development environments, and its explicit
positioning relative to existing operational, shore-side
and proprietary S-124 efforts. The current PoC does not
establish operational readiness or a quantified safety
improvement; it provides a concrete and modifiable
basis for future studies of S-100 interoperability,
presentation, scenario-based testing, situational
awareness, safety and maritime security. The next step
is to extend this environment from a single-product
PoC into a reproducible S-100 experimentation
platform with controlled scenarios, replay, additional
products and human-factors evaluation – an
environment that could complement, rather than
replace, certified navigation systems during the
continuing transition to S-100 and e-navigation.
CODE AND DATA AVAILABILITY
The plugin installation files, source code, and documentation
are publicly available under the GNU General Public License
version 3.0 at https://github.com/ENSM-Nantes/s124-plugin
[6]. The operational S-124 datasets used for the
demonstration are published by the SHOM PING platform
[23]. If you use this plugin in academic or professional work,
please cite this article and/or our other related works. The
software itself may also be cited via its repository:
https://github.com/ENSM-Nantes/s124-plugin.
ACKNOWLEDGEMENTS
This work has received funding from HORIZON Europe
with grant agreement No. 101076633 (OVER- HEAT project)
under European Union’s Horizon Europe Innovation Actions
Framework Programme.
REFERENCES
[1] Hasan Ahmad and Pedro Merino Laso. Enhanced shared
situational awareness and decision support in maritime
firefighting: Insights from the overheat project. In 2025
IEEE Conference on Cognitive and Computational
Aspects of Situation Management (CogSIMA), pages 17–
24, 2025. doi: 10.1109/COGSIMA64436.2025.11079492.
[2] Hasan Ahmad, Pedro Merino-Laso, and Massimo
Capozza. Enhanced information system and data
management for maritime fire safety. In OCEANS 2025
Brest, 2025. doi: 10.1109/OCEANS 58557.2025.11104754.
[3] Canadian Coast Guard. S-100 products and services: S-124
navigational warnings service, 2026. URL https://e-
navigation.canada.ca/topics/s100/index-en. Test service;
accessed 28 August 2026.
[4] Stilianos Contarinis et al. Web-based nautical charts:
Automated compilation from open hydrospa- tial data.
The Journal of Navigation, 75(4):763–783, 2022. doi:
10.1017/S0373463322000327.
[5] Danish Maritime Authority. Niord – open-source editor
and publication system for navigational warnings and
notices to mariners. Originally developed in the
EfficienSea2 EU project, 2026. URL https://niord.org/.
Accessed 28 August 2026.
[6] ENSM-Nantes. S-124 navigational warnings opencpn
plugin. GitHub repository, 2026. URL
565
https://github.com/ENSM-Nantes/s124-plugin. Version
1.0; GPLv3; accessed 28 August 2026.
[7] French Maritime Academy (ENSM). Bridge command.
somos project. GitHub repository, 2026. URL
https://github.com/ENSM-Nantes/bc. Version 3.2;
accessed 07 September 2026.
[8] International Association of Marine Aids to Navigation
and Lighthouse Authorities (IALA). Guideline G1107:
Planning and reporting of testbeds in the maritime
domain. Technical Report G1107, Edition 3.0, IALA, 2023.
URL https://www.iala.int/content/uploads/2023/02/G11
07-Ed3.0-Planning-and-reporting-testbeds-on-the-
maritime-domain.pdf.
[9] International Electrotechnical Commission. IEC 63173-
2:2022 maritime navigation and radiocom- munication
equipment and systems – data interface – part 2: Secure
communication between ship and shore (SECOM), 2022.
URL https://webstore.iec.ch/publication/64543. Accessed
28 August 2026.
[10] International Hydrographic Organization. Major
milestone achieved in transition to smart navi- gation
with operational editions of S-100 standards, 2025. URL
https://iho.int/en/major-m ilestone-achieved-in-
transition-to-smart-navigation-with-operational-
editions-of-s-100-standards. Accessed 28 August 2026.
[11] International Hydrographic Organization. S-124
navigational warnings: Product specification, edition
2.0.0, 2025. URL
https://registry.iho.int/productspec/view.do?category=pr
oduct_ID&domainS=ALL&idx=218&product_ID=S-124.
S-100 Edition 5.2.0; accessed 28 August 2026.
[12] International Hydrographic Organization. S-100 based
product specifications, 2026. URL https://iho.int/en/s-100-
based-product-specifications. Accessed 28 August 2026.
[13] International Maritime Organization. E-navigation
strategy implementation plan – update 1. Technical
Report MSC.1/Circ.1595, International Maritime
Organization, 2018. URL https://
wwwcdn.imo.org/localresources/en/OurWork/Safety/Do
cuments/enavigation/MSC.1-Circ.1595%20-%20E-
Navigation%20Strategy%20Implementation%20Plan%20
-%20Update%201.pdf.
[14] International Maritime Organization. Resolution
MSC.530(106): Performance standards for electronic chart
display and information systems (ECDIS). Technical
Report MSC.530(106), International Maritime
Organization, 2022. URL
https://wwwcdn.imo.org/localresources/
en/KnowledgeCentre/IndexofIMOResolutions/MSCReso
lutions/MSC.530(106).pdf. Adopted 7 November 2022;
subsequently revised as MSC.530(106)/Rev.1. Accessed 28
August 2026.
[15] International Maritime Organization. E-navigation,
2026. URL https://www.imo.org/en/ourwo
rk/safety/pages/enavigation.aspx. Accessed 28 August
2026.
[16] Gary C. Kessler. AIS research using a Raspberry Pi, 2026.
URL https://www.garykessler.ne t/library/ais_pi.html.
Uses OpenCPN to monitor live and simulated AIS traffic;
accessed 28 August 2026.
[17] OpenCPN Project. Opencpn latest version 5.14.0, 2026.
URL https://opencpn.org/. Accessed 28 August 2026.
[18] OpenCPN Project. Plugins, 2026. URL
https://opencpn.org/wiki/dokuwiki/doku.php?id=
opencpn:manual_basic:quick_start_guide:plugins.
Accessed 28 August 2026.
[19] OpenMarine. Openplotter. open marine website, 2026.
URL https://openmarine.net/. Accessed 28 August 2026.
[20] Aybars Oruc, Vasileios Gkioulos, and Sokratis Katsikas.
Towards a cyber-physical range for the integrated
navigation system (INS). Journal of Marine Science and
Engineering, 10(1):107, 2022. doi: 10.3390/jmse10010107.
[21] Julien Rieffel, Lilou Corlay, Malo Selosse, Pedro Merino-
Laso, Hasan Ahmad, and Matthieu Sacher. Identifying
key requirements for maritime bridge simulators in
wind-assisted ship propulsion training. In OCEANS 2025
Brest, pages 1–5. IEEE, 2025.
[22] Sea Traffic Management. Baltic navigational warnings
directly in ECDIS reduce accident risk. Sea Traffic
Management (STM) Validation Project, 2019. URL
https://www.seatrafficmanagement.info/news/stm-
baltic-navigational-warnings-directly-in-ecdis-reduce-
accident-risk/. Accessed 28 August 2026.
[23] Service Hydrographique et Oc´eanographique de la
Marine (SHOM). PING – portail d’information nautique:
S-124 edition 2.0.0 SECOM services, 2026. URL
https://portail.ping-info-nauti que.fr/static/s124-2-0.
French national navigational-warning distribution
platform; accessed 28 August 2026.
[24] Sternula. Navigational warnings (S-124) over VDES and
the maritime messaging service, 2026. URL
https://www.sternula.com/navigational-warnings/.
Accessed 28 August 2026.
[25] Teledyne SevenCs. Nautilus maritime sdk, 2026. URL
https://www.sevencs.com/products/m aritime-
sdk/nautilus-maritime-sdk. Accessed 28 August 2026.
[26] Xiaoting Wu. Intelligent production and application of s-
124 standard navigation warning visualiza- tion service.
Open Journal of Social Sciences, 13(10):732–740, 2025. doi:
10.4236/jss.2025.1310042.