A Mission Exchange Model (MEZ) for Autonomous Inland Waterway Navigation

Journal of Physics: Conference Series PAPER • OPEN ACCESS A Mission Exchange Model (MEZ) for Autonomous Inland Waterway Navigation To cite this article: Marianne Hagaseth et al 2025 J. Phys.: Conf. Ser. 3123 012012 View the article online for updates and enhancements. You may also like Safety Assessment and ExperienceBuilding Scheme Using Simulators for Automatic Collision Avoidance Algorithm Ryohei Sawada, Makiko Minami, Keiji Sato et al. - Automated Maneuvering of Networked Vessels in Confined Waters Nick Eisenblätter, Tim Rehbronn, Martin Kurowski et al. - Concept Design of an Autonomous Navigation System enabling Intelligent Bridge Operations Andrea Pecoraro, Elisa Perrone, Emanuele Sansebastiano et al. - This content was downloaded from IP address 129.233.224.227 on 07/11/2025 at 10:41 Content from this work may be used under the terms of the Creative Commons Attribution 4.0 licence. Any further distribution of this work must maintain attribution to the author(s) and the title of the work, journal citation and DOI. Published under licence by IOP Publishing Ltd ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 1 A Mission Exchange Model (MEZ) for Autonomous Inland Waterway Navigation Marianne Hagaseth1*, Håvard Nordahl1, Lars Andreas Lien Wennersberg1, Hans-Christoph Burmeister2, and Øyvind Pedersen3 1 Maritime ICT a nd Cybernetics Group, Energy and Transport Department, SINTEF Ocean, Trondheim, Norway 2 Frau nhofer CML, Hamburg, Germa ny 3 Maritime Robotics, Trondheim, Norway *E-mail: Marianne.Hagaseth @sintef.no Abstract. Even i f autonomous vessels can operate independently of a person monitoring or controlling it on some parts of the voyage, a Remote Operation Centre (ROC) is still needed. The ROC operator will be responsible for planning the voyage and to follow up on its operation. Also, the ROC operator will be responsible for handling those situations where human interventions are needed, either unforeseen situations, interactions with crewed vessels, or planned interaction with other operation centres, e.g., for bridges and locks. For an autonomous vessel to navigate on inland waterways (IWW), a clear description of the operations must be provided to the onboard Autonomous Navigation System (ANS) by the ROC operator. Further, the description of the mission must be sent from the ROC to the vessel and be handled by the ANS onboard to conduct the sailing from the departure to the arrival berth, including lockand bridge passing. In this paper, we describe the requirements to a Mission Exchange Model (MEZ), investigate existing and relevant standards that cover mission data, and propose a format for such missions to be sent from the ROC to the ANS. We wil l also describe how the planning of the mission can be performed in the ROC, and we will present a test run with an autonomous sea drone that was performed in Trondheim, Norway, in 2025, to show case the usage of some parts of this MEZ. 1. Introduction Humans will be involved in the operation of autonomous vessels for the foreseeable future, irrespective of whether the autonomous vessel is capable of navigating inland waterways (IWW) without continuous human supervision for certain parts of the voyage. The established principle of autonomous navigation, somewhat simplified, is that a) the Situation Awareness System (SAS) provides the Autonomous Navigation System (ANS) with the required information to perform navigation, such as positioning, traffic and other objects, b) to navigate autonomously, the ANS must determine if the actions it currently executes, such as docking or transit, can commence as planned, or if corrective actions such as speed and course changes are required, and c ) that the operator intervenes if deemed necessary or requested by the ANS, or otherwise monitor the operation, Figure 1. This principle emerged very early in autonomous vessel development [1], and is reflected in the ongoing IMO MASS Code development and international s tandardization [2], as well as within the first commercial IWW applications. ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 2 Although the autonomous navigation system should be c apable of making decision on its own, it cannot determine i ts own purpose, that is, what it is supposed to do. Thus, it falls upon humans to tell the autonomous vessel what it is supposed to do, when it is supposed to do it, where it is supposed to be at given times, and what navigational constraints it must consider. This is the mission, and that is assigned to the autonomous vessel by a remote operator that resides in ROC , before leaving the departure port. Figure 1. Environment for IWW Missio n Pla nning and Execution The remainder of the paper is structured as follows. Section 2 will give background and context for the work, and an overview of the IWW vessel operation. Section 3 describes the methodology we applied to create the mission exchange model. Section 4 presents the MEZ whilst results from a scaled-demo of parts of the MEZ is presented in Section 5. We draw conclusions in Section 6 and explain what further work are relevant. 2. Background and Context 2.1. Related Work on Route Planning and Autonomous Navigation In manned maritime transport, one core task of navigation is voyage planning, which serves as the backbone of safe navigation. Voyage planning is linked to SOLAS Regulation 34 [3], with IMO Resolution A.893(21) giving guidelines on how to execute this task [4]. The plan itself typically consists of amongst others: Plotting of the intended route, safe speed, necessary speed alterations, minimum clearances, and course alteration points. Since 2015, this is electronically supported by a route plan exchange format, which is called RTZ, and standardized by CIRM [5], and also standardized in IEC 61174:2015, Edition 4 [6]. This was tested for vessel-shore interaction capabilities by the STM project [7]. An extended version of RTZ , named S-421 and developed by IEC as IEC63173-1:2021 [8] is added to the IHO S -100 framework of standards. Also, during the ISTS-project, a converter from the RTZ-format to the S-421 format was implemented [9]. Routes in RTZ and S-421-formats are described by geographical waypoints, allowed cross track errors, schedules, and optionally by a simple turning radius between legs. On open sea, such voyage plans can be executed from a track pilot supervised by an officer of the watch. In inland navigation, similar processes apply, yet less formalized. For Autonomous and Inland Navigation, additional specific data elements need to be covered, which are not yet included in the given voyage planning data format, including 1) Specific geometries: The meandering nature of (natural) IWW requires m ore c omplex route planning than static turni ng radius. State-of-the-art track control systems for IWW do typically work with rotation speed regulation instead. 2) Infrastructure interactions: Pausing and waiting during a ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 3 voyage at IWW infrastructure such as bridges and locks, are more c ommon on the voyage than in maritime. Those do typically affect the schedule, which cannot be totally preplanned. 3) Changing autonomous operations: In contrast to manned shipping, different modes of operations (autonomous and remote) as well as different degrees of autonomy (CCNR 0-5) are possible during different parts of the voyage and need to be planned. Significant efforts have been put into studying autonomous navigation systems where the focus has been on the ROC [10], [11], [12], [13], the Guidance, Navigation and Control (GNC) methods of the ANS [14], [15], [16], [17], support functions of ROC and other shore-based personnel for anomaly detection [18], [19], and also on communication issues [20], [21]. However, less attention has been given to how the ROC should communicate plans, and changes to plans, to the ANS. This includes the definition of the mission that the ANS shall execute, and how it should be exchanged between the ROC and the ANS. The review in [22] investigates the current advancements on autonomous mission planning and management for autonomous underwater vehicles and aerial vehicles. While a high-level architecture for a typical mission planning and management system is presented, the mission exchange model is not discussed. The review of mission planning in [23] discusses the decomposition hierarchy of the U SV (Unmanned Surface Vehicle) mission into specific goals, tasks, and behaviour, however, neither the mission creation nor a data model for transferring a mission from a control centre to the USV is discussed. Robust mission planning for Autonomous Marine Vehic le fleets is proposed in [24], where the planner translates mission goals to tasks that are distributed over the fleet of autonomous drones. However, a mission exchange model is not discussed. An AI planning module for executing the autonomous vessel mission, intended as a translator between the mission and the path and motion planning unit, is proposed in [25]. However, neither the mission creation nor the mission exchange model is discussed. Temporal mission planning for Maritime Autonomous Surface Ships (MASS) is proposed in [26], where an temporal AI planning is used to create the control tasks for the GNC. It takes goals and actions as inputs, but the mission exchange model, that would contain these goals and actions to be communicated between the ROC and the vessel, is not discussed. While the literature s eems to focus on the planning problem from the perspective of translating mission goals into tasks, to the best of the authors knowledge, no studies address the data model for transferring the mission to the ANS. In this paper, we propose a Mission Exchange Model, which is the data model for the mission to be sent from the ROC to the IWW vessel. This data model will be based on existing standards for route plan exchange (RTZ for current usage[5] and S-421 for further usage[8]) and standards for IWW navigation (currently IENC 2.4 [27], and future S-401[28]), as well as class terminology for au tonomous operations (as e.g. DNV Autoremote [29] or CCNR[30]), to be easi ly adapted by existing technologies. The mission exchange model will contain all the information that the autonomous vessel will need to execute a mission, including relevant i nformation about the cargo, departure and arrival berths, the route to navigate (with any restrictions such as shallow draft), with the related schedule, bridges and locks to pass, and the allocated posi tions in the lock chambers and at the berth derived from the Inland ENCs. 2.2. Overview of IWW Vessel Operation Figure 2 describes the m essage exchanges related to the planning, execution and updates of a mission, related to the environment shown in Figure 1. T he process starts with the ROC operator describing the mission, including the route and waypoints, planned speed over ground, time schedule, cross track distance for each leg, if the ANS or the ROC operator is in control for each ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 4 leg, information about the lock passing and bridge passing, and information about when the ANS should notify the ROC operator and what situation to report on. The Mission planner in the ROC will create the Mission Exchange Message according to the Mission Exchange Model, and this wi ll be sent by the ROC communication interface using the ANS-ROC communication carrier. The ANS will need to validate the mission, and it will then send the approval back to the ROC operator. Then, the mission is ready for execution by the vessel. The ANS c an either execute the mission by sending the set points to the Track pilot or DP system, or it can instead hand over the control to the ROC operator, dependent on the instructions in the mission. During the execution of the mission, the ANS will continuously send statuses and feedback to the ROC operator, according to the mission, and to what is already defined by the ANS. For each request, the ROC operator must evaluate the request and act as needed. This may be to take over the control of the vessel from the ANS, to contact lock or bridge operators, or to handle some requests that requires updates of the mission plan. During the execution of the mission, external actors as lock or bridge operators may also give warnings or information to the ROC operator that may lead to updates of the mission plan. Figure 2. Mission Exchange Message sequence diagram 3. Methodology 3.1. Overview To develop the mission exchange model, we applied a case study method. The case study was designed to be carried out over four phase s, with each phase having a specific purpose: • Requirements: In the first phase, we elicited requirements to the mission exchange model in a series of online workshops with joint industry and research organisations represented by the authors of this paper, see Section 3.2. • Gap Analysis: Secondly, based on the identified requirements, we did a review of existing data models and standards applicable to inland waterways, but also standards for seagoing vessels. We investigated which parts of these existing standards could cover which of the requirements to the Mission Exc hange Model, and which gaps that still existed, see Section 3.3. ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 5 • Extended Data Models: Thirdly, we proposed new data elements that are extensions to the existing models and standards to cover the mission exchange data between the ROC and the autonomous vessel that are not already covered. These extensions are proposed as UML classes that can be further implemented as messages on XSD-format or other formats, see Section 4. • Demonstration: Fourth, and finally, a part of the mission exchange model was implemented and demonstrated on a scaled demonstration vessel (OtterX) as proof-ofconcept, see Section 5. 3.2. Requirements to Mission Exchange Model The requirements to the Mission Exchange Model were collected during online workshops with AutoFlex [31] project partners, and this can be summarized as follows: • The mission exchange m odel covers data needed to be sent from the ROC to the ANS to define the navigation from a departure berth in a terminal to the arrival berth in the arrival terminal. • The mission exchange model covers data needed to be sent from the vessel to the ROC regarding situations detected by the vessel that needs attention by the ROC operator. • The mission data model does not cover data sent between the ROC and the lock/bridge or other shore-based infrastructure. • The vessel travels a fixed route, from a departure port to an arrival port. The vessel will need information about the mission before it leaves the departure port. • Details on the communication protocol between the ROC and ANS is not part of the mission exchange model. • The vessel does not have interface to the RIS (river Information System), as this is only handled by the ROC. • The vessel is assumed to be on at least level 4 of automation (high automation) according to the CCNR definition of levels of automation in inland navigation [32], where the vessel is capable of operating between two successive locks. • The ANS sends status information continuously to the ROC for the ROC operator to monitor the sailing and also to get sufficient situational awareness in those cases where the ROC operator needs to take over control or to update the mission. • The vessel is able to handle s ituations in its vicinity through its autonomous navigation system and situational awareness functionalities. • A mission update is sent from the ROC to the ANS when changes to the mission is needed. This avoids problems with latency of communication. • The vessel notifies the ROC when it enters a fallback state, which needs to be handled by the ROC. Another important part of the mission is to ensure that the handover between the ANS and the ROC operator is correctly handled, i.e., to ensure that sufficient information is available among the mission data to send notifications between the vessel and the ROC operator. This includes preplanned actions defined by the ROC operator that must be performed by the vessel, for instance the mission may contain certain waypoints whe re the vessel shall stop, notify the ROC, and await acknowledgement or further instructions before proceeding, such as bridges that needs to be opened before passing. This can also be a point where the vessel shall do a transition between two voyage phases that requires the ROC operator to either do an action or to verify information before the vessel can proceed. One example is that the remote operator must communicate with a lock operator via VHF before entering the first lock chamber. Another example is to visually ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 6 verify that the berth is clear before initiating automatic mooring. A third example of an action point is a point where a pre-planned transition from one operational mode to another is performed, e.g., from automatic navigation to ROC operator-controlled navigation. This transition of operational mode may for instance be needed when the vessel is about to enter a lock. 3.3. Gap Analysis of Existing Standards IWW traffic is not regulated through IMO by COLREG or SOLAS, but by regional and national regulations. For Europe, CEVNI (European Code for Navigation on Inland Waterways) regulates the navigation of most of Europe’s rivers, canals, and lakes [33]. During this work, we have therefore looked at the regulations of inland ENC. However, we have also investigated definitions from IMO, to reuse as much of existing definitions as possible. For information that is specific for inland waterways, e.g., for locks, bridges, and the signalling requirements when sailing on the rivers and canals, we have used information from the iENC regulations. The Mission Exchange Model was described as data types and data elements in a UML model based on the IWW use case (first step), a walk-through of the following standards (step 2), and a gap analysis of these: • The S-421 standard (IEC 63173-1:2021) on route exchange [34] i s reused when it comes to the definitions of routes, legs, waypoints, action points, and the schedule. • The current Inland ECDIS Standard Edition 2.4 [35] and the IENC Feature catalogue [27] were used to find specifics related to the IWW sailing, lock passing and bridge passing, that is not covered by S-421. • The upcoming S-401-standard for Inland Electronic Navigational Charts [36],[28] when it comes to information about port features. • The EDIFACT message BAPLIE regarding the bayplan/stowage plan describing container related data on weights and dangerous goods [37] when it comes to cargo information needed by the IWW vessel. • The reference model and list of data elements as described i n the IMO compendium [38] when it comes to static information about the vessel. 4. Description of Message Exchange Model (MEZ) 4.1. Overview Figure 3 gives a simplified overview of the interaction between the ANS onboard the vessel that is used during the mission execution and the person in the ROC that follows up on the vessel. The rounded boxes show different activities handled by the ROC operator and the vessel. The arrows show transitions between these activities. 1. Green boxes: Initially, the ROC operator plans the mission for a vessel. The operator uses the mission planning tool to set up the route, timetable, and action points. The mission message is generated and s ent to the vessel for approval and execution. During the voyage, the ROC operator can also update the mission based on input received duri ng the monitoring or the controlling of the vessel. 2. Blue boxes: a. After the initial planning of the mission has been done, the ROC operator works in one of two modes: Remote control of the vessel or monitoring the vessel. b. The vessel either controls the sailing by executing the mission or it is passive while being remotely operated by the ROC operator. ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 7 When it comes to controlling the vessel , either the automation onboard or the ROC operator must be accountable for the operation of the vessel, not both at the same time. This means that when the vessel is executing the mission, the ROC operator will monitor the vessel. Wh en the ROC operator is remotely controlling the vessel, the vessel is manually controlled and the ANS is not used. 3. Light yellow boxes: a. The vessel must continuously send i ts statuses and requests to the ROC for further processing by the ROC systems and the ROC operator. b. The ROC operator must interact with external persons and system, both during monitoring and during remote control operation. Figure 3. Phases and Interactions between Autonomous IWW Vessel and the ROC Operator The Mission Exchange Model contains of two parts: A) Mission planning data, that is needed for the planning of the mission, and is sent from the ROC to the ANS, and B) the Mission execution data that is sent from the vessel (ANS) to the ROC during vessel operation. A) Mission planning data that are sent from the ROC to the ANS to inform the ANS about the details of the passage from the berth in the departure port to the berth in the arrival port . This describes the planned mission to be approved and executed by the ANS: ➢ Planned route and planned actions, Section 4.2. ➢ Planned schedule with planned actions, Section 4.3. ➢ Mooring, Section 4.4. ➢ Planned autonomy level, Section 4.5. ➢ Cargo, Section 4.6. B) Mission execution data that are sent from the ANS to the ROC during execution of the mission. This information comes in addition to the sensor data s ent from the vessel to the ROC, see Section 4.7. 4.2. Planned route and planned actions Figure 4 shows the UML classes representing the data for planning the rou te legs and for specifying action points. The light brown boxes are a simplified view of the classes from S-421 Route Exchange, while the green boxes represent additional classes defined to cover the IWW mission planning. • Information about Action Points: The current version (June 2025) of S-421 defines the action point either as a point, as a circle with a position and a diameter, or as a user defined space ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 8 geometry. This mission exchange model will allow action points of all these types. Several action points can be defined for each route. They are linked directly to the route, and not necessarily to a waypoint. The following extra data is needed for the mission exchange model compared to S-421: • Extra data related to Action Point: o A route action point type (RouteActionPointType) is needed to explain the type of action related to a specific route action point. This can be for instance a radio callingin point, an area indicating a traffic signal station for a bridge or lock passing or port entry and departure, an area i ndicating that communication with VTS, locks, bridge etc. can be done. These values are derived based on the Encoding Guide for Inland ENCs [35]. In addition to this comes action point types to indicate that the lock passing and bridge passing need to be done remotely controlled by the ROC operator. o The enumeration RouteActionPointRequiredAction is extended with a valu e for MissionAction to indicate that the action point is used in relation to a mission plan. o ShipPlannedActionPointRequest: This is a list of different notifications that the ROC operator expects the ANS to do related to an action point, or at some other point in time. Examples are to notify the ROC operator when entering (ATA) or leaving (ATD) the action point area, notify about the expected arrival time (ETA) or expected departure time (ETD), or instruct the ANS to notify the ROC operator when a green light or unknown object is detected. The value of attribute routeActionPointTimeToAct in RouteActionPoint is used to describe the point in time when the notification should happen, for ins tance how long time before the ETA or ETD should be given. • Extra data related to Legs between two Waypoints: o A route is defined by a list of route waypoints. The legs of the route are defined between two route waypoints with information related to this leg describing the centerline of the leg, the crosstrack distance to port and starboard (routeWaypointLegPortXTDL, routeWaypointLegStarboardXTDL), and the broader clearance to port and starboard defined by routeWaypointLegPortCL and routeWaypointLegStartboardCL. o The following extra information is needed for the legs in the mission: o For each leg, the ROC operator plans a list of requests that the vessel must perform for this leg. This is defined in ShipPlannedWaypointLegRequest and includes notifications saying that the vessel has moved outside the PortXTDL line or StarboardXTDL line. It also includes notifications that the vessel has entered a fallback state because the vessel has moved outside the PortCL line or StarboardCL line. o In addition to this, a level of au tonomy and notification deadline is defined for each leg. o Note that the planned SOG for the leg is defined in the RouteScheduleElement (a data element i n S-421) as RouteScheduleElementPlanSOG related to the end waypoint of the leg. ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 15 Reference [1] H. C. Burmeister, Ø. J. Rødseth, and T. Porathe, ‘Autonomous Unmanned Merchant Vessel and its Contribution towards the e-Navigation Implementation: The MUNIN Perspective’, in International Journal of e-Navigation and Maritime Economy, 2014, pp. 1–13. [2] ISO, ISO/TS 23860:2022 Ships and marine technology — Vocabulary related to autonomous ship systems, 2022. Accessed: Jun. 19, 2023. [Online]. Available: https://www.iso.org/standard/77186.html [3] IMO, ‘Amendments to IMO instruments: upcoming and recent entry into force/effective dates’. Accessed: Jun. 20, 2025. [Online]. Available: https://www.imo.org/en/About/Conventions/Pages/Amendments-to-IMOinstruments.aspx [4] IMO, ‘IMO Resolution A.893(21)’, A.893(21), Nov. 1999. Accessed: Jun. 20, 2025. [Online]. Available: https://wwwcdn.imo.org/localresources/en/KnowledgeCentre/IndexofIMOResolutions/AssemblyDocuments /A.893(21).pdf [5] Route plan exchange format - RTZ. [Online]. Available: https://cirm.org/rtz-xmlschemas [6] A. Rydlinger, ‘MONALISA 2.0 – Activity 1.3 STM Voyage exchange format and architecture’, MONALISA 2 0_D1.3.2, Dec. 2015. [7] H. C. Burmeister, T. Scheidweiler, M. Reimann, and C. Jahn, ‘Assessing Safety Effects of Digitization with the European Maritime Simulator Network EMSN: The Sea Traffic Management Case.’, in The International Journal on Marine Navigation and Safety of Sea Transportation, 2020, pp. 91–96. doi: 10.12716/1001.14.01.10. [8] IEC 63173-1:2021: Maritime navigation and radiocommunication equipment and systems - Data interfaces - Part 1: S-421 route plan based on S-100. [Online]. Available: https://webstore.iec.ch/en/publication/32931 [9] S-421 Converter. ECC. [Online]. Available: https://s421creator.ecc.no/ [10] H. Dybvik, E. Veitch, and M. Steinert, ‘EXPLORING CHALLENGES WITH DESIGNING AND DEVELOPING SHORE CONTROL CENTERS (SCC) FOR AUTONOMOUS SHIPS’, Proc. Des. Soc. Des. Conf., vol. 1, pp. 847–856, May 2020, doi: 10.1017/dsd.2020.131. [11] J. (Hans) van den Broek, J. R. (Jaco) Griffioen, and M. (Monique) van der Drift, ‘ Meaningf ul Human Control in Autonomous Shipping: An Overview ’, IOP Conf. Ser. Mater. Sci. Eng., vol. 929, no. 1, p. 012008, Nov. 2020, doi: 10.1088/1757-899X/929/1/012008. [12] O. A. Alsos et al., ‘NTNU Shore Control Lab: Designing shore control centres in the age of autonomous ships’, J. Phys. Conf. Ser., vol. 2311, no. 1, p. 012030, Jul. 2022, doi: 10.1088/1742-6596/2311/1/012030. [13] E. Veitch, ‘Designing for Land-based Control of Autonomous Vessels’, Doctoral thesis, NTNU, 2023 . Accessed: May 26, 2025. [Online]. Available: https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/3088574 [14] L. P. Perera, V. Ferrari, F. P. Santos, M. A. Hinostroza, and C. Guedes Soares, ‘Experimental Evaluations on Ship Autonomous Navigation and Collision Avoidance by Intelligent Guidance’, IEEE J. Ocean. Eng., vol. 40, no. 2, pp. 374–387, Apr. 2015, doi: 10.1109/JOE.2014.2304793. [15] Y. Gu, J. C. Goe z, M. Guajardo, and S. W. Wallace, ‘Autonomous vessels: state of the art and potential opportunities in logistics’, Int. Trans. Oper. Res., vol. 28, no. 4, pp. 1706–1739, 2021, doi: 10.1111/itor.12785. [16] U . O ztu rk, M. Akdag , and T. Ayabakan, ‘A review of path planning algorithms in maritime autonomous surface ships: Navigation safety perspective’, Ocean Eng., vol. 251, p. 111010, May 2022, doi: 10.1016/j.oceaneng.2022.111010. [17] Y. Qiao, J. Yin, W. Wang, F. Duarte, J. Yang, and C. Ratti, ‘Survey of Deep Learning for Autonomous Surface Vehicles in Marine Environments’, IEEE Trans. Intell. Transp. Syst., vol. 24, no. 4, pp. 3678–3701, Apr. 2023, doi: 10.1109/TITS.2023.3235911. [18] T. Stach, Y. Kinkel, M. Constapel, and H.-C. Burmeister, ‘Maritime Anomaly Detection for Vessel Traffic Services: A Survey.’, in J. Mar. Sci. Eng., 2023. doi: https://doi.org/10.3390/jmse11061174. [19] K. Wolsing, L. Bauer, and K. Wehrle, ‘Anomaly Detection in Maritime AIS Tracks: A Review of Recent Approaches.’, in J. Mar. Sci. Eng., 2022. doi: https://doi.org/10.3390/jmse10010112. [20] G. Kia and S. Van Staeyen, ‘Barge Use Case’, D4.1. [Online]. Available: https://www.5gblueprint.eu/wpcontent/uploads/sites/62/2024/01/D4.1_Barge-use-case_V1.2_15.12.2023.pdf [21] ‘SeaNext’, [Online]. Available: https://business.esa.int/projects/seanext [22] A. Atyabi, S. MahmoudZadeh, and S. Nefti-Meziani, ‘Current advancements on autonomous mission planning and management systems: An AUV and UAV perspective’, Annu. Rev. Control, vol. 46, pp. 196–215, Jan. 2018, doi: 10.1016/j.arcontrol.2018.07.002. [23] F. Thompson and D. Guihen, ‘Review of mission planning for autonomous marine vehicle fleets’, J. Field Robot., vol. 36, no. 2, pp. 333–354, 2019, doi: 10.1002/rob.21819. [24] F. Thompson and R. Galeazzi, ‘Robust mission planning for Autonomous Marine Vehicle fleets’, Robot. Auton. Syst., vol. 124, p. 103404, Feb. 2020, doi: 10.1016/j.robot.2019.10 3404. [25] M. A. Hinostroza and A. M. Lekkas, ‘A Rudimentary Mission Planning System for Marine Autonomous Surface Ships’, IFAC-Pap., vol. 55, no. 31, pp. 196–203, Jan. 2022, doi: 10.1016/j.ifacol.2022.10.431. ICMASS-ISSS-2025 Journal of Physics: Conference Series 3123 (2025) 012012 IOP Publishing doi:10.1088/1742-6596/3123/1/012012 16 [26] M. A. Hinostroza and A. M. Lekkas, ‘Te mporal mission planning for autonomous ships: Design and integration with guidance, navigation and control’, Ocean Eng., vol. 297, p. 117104, Apr. 2024, doi: 10.1016/j.oceaneng.2024.117104. [27] IENC Feature Catalogue, Apr. 21, 2021. [Online]. Available: https://www.cesni.eu/wpcontent/uploads/2023/05/Appendices-Part1-IECDIS_BD.pdf [28] INLAND ELECTRONIC NAVIGATIONAL CHART PRODUCT SPECIFICATION, Draft IEHG Publication S-401, Annex A Data Classification and Encoding Guide. [29] Autoremote systems. Accessed: Jun. 22, 2025. [Online]. Available: https://www.dnv.com/maritime/autonomous-remotely-operated-ships/autoremote-systems/ [30] Explanatory note related to the international definition of levels of automation in inland navigation, 2022. [31] ‘https://autoflex-vessel.eu/’. [32] ‘Explanatory note related to the international definition of levels of automation in inland navigation’. CCNR, 2022. [33] CEVNI European Code for Inland Waterways, 2021. [34] S-421 Route Exchange. [Online]. Available: https://cirm.org/s-421 [35] ‘Encodin g Guide for Inland ENC (draft)’. in Inland ENC Harmonization Group. [36] IEHG INLAND ELECTRONIC NAVIGATIONAL CHART PRODUCT SPECIFICATION Draft, Sep. 2024. [37] Bayplan/stowage plan occupied and empty locations message. [Online]. Available: https://service.unece.org/trade/untdid/d17a/trmd/baplie_c.htm [38] IMO Compendium on Facilitation and Electronic Business. [Online]. Available: https://imocompendium.imo.org/public/IMO-Compendium/Current/index.htm [39] IHO Marine Harbour Infrastructure (MHI) Product Specification, S-131, Mar. 2023. [Online]. Available: https://iho.int/uploads/user/pubs/Drafts/S131%20Marine%20Harbour%20Infrastructure%201_0_0%20Product%20Specification.pdf [40] Maritime Robotics, ‘The Otter X’, Maritime Robotics. Accessed: Jun. 19, 2025. [Online]. Available: https://www.maritimerobotics.com/otter-x