Things used in this project

Story

Introduction

This project proposes a use case for automating docking operations of unmanned vessels in maritime environments using real-time data computation and edge technologies. Currently, docking and related logistics rely heavily on manual coordination between pilots, port operators, and truck drivers, leading to inefficiencies, high costs, safety risks, and environmental impact. The proposed solution integrates oneM2M (for data storage and sharing) with MEC applications that process sensor data (e.g., cameras, LIDAR, and proximity sensors) to detect available berths and coordinate vessel movements autonomously. AI algorithms at the edge identify optimal docking slots and manage real-time communication between ships, OTs, and trucks. Once docking begins, automated notifications and control commands streamline loading and unloading operations. Overall, the use case demonstrates how interoperable, real-time edge computing architectures can transform maritime logistics into a more intelligent, coordinated, and eco-efficient ecosystem.

Domain and context

In this use case, we selected the maritime domain where more than 80% of today’s world trade is being realized by the international shipping industry. The maritime industry has evolved from traditional mechanical systems to electromechanical and digital systems, involving changes in industrial control systems over the past decade. The implementation of ICT-based solutions makes it possible to capture, visualize, and transfer real-time data; generate new ways to communicate and collaborate among distributed actors; share information between different actors; and automate processes.

Problem Statement

Docking operations for unmanned vessels in a maritime environment are very risky and require a high level of reliability. At the current stage, all these kinds of operations are performed manually. In this process, once the berth for the vessel has been identified, the Pilot guides the ship to dock, relying on personal experience. Once the ship is docked, the OT operators are informed to start loading and unloading operations. In the meantime, truck drivers are asked to start approaching port terminals. The entire chain currently results in various challenges. Some of them are related to:

• Safety: collision avoidance.
• Efficiency: reduce the waste of time.
• Sustainability: Reduce pollution.
• Cost reduction: reduce waste of resources.

The identified challenges in automating all the processes in real-time require highly computing tasks to harmonize work performed by different entities.

The question we want to address with this use case is how to exploit real-time computation of several data sources, using the interoperability between the oneM2M store & share platform and MEC applications, for automated docking to enhance berth operations in a safe, sustainable, efficient, and cost-reduced way?

Use Case Scenario

In a maritime environment, a ship is waiting for an instruction to approach the port for docking operations. The AI algorithms running on the edge at each berthing place, processing images related to Cameras and LIDARs (proximity sensors), and stored in a oneM2M MN-CSE, recognise that there is a free slot for berthing. To identify the optimal free slot, another component running as an MEC application collects data coming from edge MEC applications running AI algorithms. Once the optimal slot is computed, the vessel is informed to start the docking maneuver. As soon as the ship approaches the geographical area assigned, a oneM2M application controller running on the edge and subscribed to the location service is notified with the current location of the ship. After this notification, the oneM2M application controller decides to send commands to OTs (Operational Technologies) and trucks in parallel to start loading and unloading operations. Once the ship is docked and the trucks reach the loading/unloading area, the controller notifies the OTs to start their operations.

Stakeholders and Actors

The following table introduces all the stakeholders who could benefit from the usage of the system defined in our use case.

Expected Benefits

Since almost 80% of today’s worldwide goods are transported by sea, optimizing docking, loading, and unloading operations by leveraging real-time computation on the edge of heterogeneous data sources can significantly reduce costs, environmental pollution, and, on the other hand, increase time efficiency. Consequently, this will have a big impact on the economy of all the stakeholders involved in these operations, such as Port Authorities, shipowners, and truck companies.

User Requirements

The following user requirements define the key needs and expectations of stakeholders involved in automated docking and port operations.

Overall Architecture

System Requirements

This section describes the functional and non-functional system requirements that the proposed oneM2M and MEC-based automated berth operations solution must satisfy to meet the needs identified in the use case and user requirements. These requirements fulfil user expectations such as safety, efficiency, sustainability, and interoperability into precise and verifiable technical obligations for system design, implementation, and evaluation.

The functional requirements define what the system shall do, including data acquisition from heterogeneous sensors, real-time decision-making at the edge through MEC, and coordination of port berth operations through oneM2M service functions. The non-functional requirements define how well the system shall perform, addressing attributes such as availability, resilience, latency, scalability, cybersecurity, and reliability under operational and anomalous conditions.

1 / 2

oneM2M/MEC Interworking based on Deployment Option-B

In the automated docking scenario, the interworking between oneM2M and MEC establishes a distributed yet coordinated control loop between data-producing Application Entities (AEs) such as cameras, LiDARs, ships, trucks, and OTs and the oneM2M Controller, an intelligent edge application running on each MEC node.

Each AE within the port ecosystem exposes two distinct oneM2M containers: a data container, used to publish sensed or processed information, and a command container, used to receive control instructions. The oneM2M Controller subscribes to the data containers of all relevant AEs to continuously collect and aggregate situational information, while each AE subscribes to its own command container so that it can be asynchronously notified whenever new operational commands are generated by the controller’s business logic.

As soon as the ship contacts the IN-CSE to announce its arrival, this event triggers all MN-CSE instances deployed on the MEC nodes at the port edge. Each oneM2M Controller running on each edge automatically subscribes to the ship’s data container through the IN-CSE, ensuring that every edge node has immediate visibility of the ship’s status and intent. This simultaneous subscription allows all MN-CSEs to start the process of berth evaluation in parallel, minimizing decision latency.

At the same time, each oneM2M Controller maintains subscriptions to the data containers of neighbouring MN-CSEs, enabling cross-edge coordination. This inter-oneM2M-controller communication allows each controller to be aware of the state and occupancy of adjacent berthing zones, as well as the workload of their local MEC resources. Based on this shared situational picture, the controllers can collaboratively determine not only the optimal berthing slot but also the most suitable edge Optimizer MEC application to process the corresponding optimization task.

At the edge level, a Computer Vision MEC application processes image streams coming from the cameras deployed at each berth. It subscribes to the data containers of all camera AEs, performs local inference to detect obstacles, free berthing slots, and abnormal conditions, and then publishes its detection results into its own data container managed by the MN-CSE. Simultaneously, LiDAR acts as a separate AE, pushing its reading to the respective data container, which the oneM2M Controller also monitors. In addition to berth slot detection, the Computer Vision MEC app is responsible for emergency and incident detection, using the same visual and LiDAR data streams to identify potential hazards such as collisions, unsafe proximity, or equipment malfunction. When such an event is recognized, it publishes an alert message into its data container, which the oneM2M Controller, already subscribed to, retrieves in real time. The controller then takes charge of the notification and response process, posting appropriate commands to the command containers of the relevant Operational Technologies and emergency personnel to initiate safety procedures—such as stopping machinery, activating alarms, or dispatching human operators to the affected area.

An Optimizer MEC application consumes these analytics by subscribing to the data containers of the Computer Vision modules and other sensors. Through this aggregation, the Optimizer computes the optimal docking position based on berth availability, vessel size, and environmental context. The optimization outcome is published to the data container of the Optimizer AE, where the oneM2M Controller, already subscribed, retrieves it in real time.

Once the optimal berth is identified, the oneM2M Controller issues a corresponding command toward the ship’s command container, instructing it to begin its docking manoeuvre. As the vessel approaches, the Controller, leveraging the MEC Location API, receives continuous position updates from both ships and trucks. Based on these updates, the Controller dynamically posts new commands to the command containers of Operational Technologies (OTs) such as cranes, reach stackers, and forklifts, as well as to the trucks’ command containers, coordinating their approach to the loading and unloading zones.

When the ship and trucks reach their designated areas, the Controller verifies this through the subscribed data containers of the respective AEs. It then sends final actuation commands to the OT command containers, triggering the start of cargo handling operations. Throughout this process, the MN-CSE on each MEC node ensures low-latency communication and local orchestration, while the IN-CSE in the cloud aggregates the operational data and logs from all MN-CSE instances for long-term storage, global berth scheduling, and system-level analytics.

This two-container model, separating data collection and command dissemination while enabling cross-MN-CSE collaboration, supports a distributed decision-making ecosystem where multiple MEC nodes cooperate through oneM2M service functions. The MEC applications provide localized, real-time analytics and inference, whereas oneM2M ensures standardized discovery, subscription, and interoperability across heterogeneous entities and geographically distributed nodes. Together, they enable a scalable and intelligent port infrastructure capable of real-time edge decision-making, global synchronization, adaptive load distribution, and proactive incident response, ensuring docking, loading, and unloading operations are performed safely, efficiently.

Data Management

This section describes the data management in our scenario and explains the time sensitivity, storage persistence.

Time-Sensitive Data

In the automated docking scenario, time-sensitive data refers to real-time sensor and control information required for immediate decision-making during vessel manoeuvring and berth coordination. Examples include:

LiDAR and camera feeds from docking areas are used for detecting obstacles, vessel proximity, and free berthing slots. Vessel and truck geolocation data gathered through MEC Location APIs to track movements within the port.

• LiDAR and camera feeds from docking areas are used for detecting obstacles, vessel proximity, and free berthing slots. Vessel and truck geolocation data gathered through MEC Location APIs to track movements within the port.
• Vessel and truck geolocation data gathered through MEC Location APIs to track movements within the port. Operational commands and alerts are processed on the edge by the orchestrator based on heterogeneous data collected through MN-CSE and notified to cranes, forklifts, and trucks.
• Operational commands and alerts are processed on the edge by the orchestrator based on heterogeneous data collected through MN-CSE and notified to cranes, forklifts, and trucks. Incident and emergency alerts detected by AI models running at the edge.
• Incident and emergency alerts detected by AI models running at the edge.

All such data are processed locally within MEC nodes, where latency-sensitive AI applications perform immediate inference (e.g., slot detection, incident recognition).

This ensures ultra-low latency and high reliability for safety-critical operations. Edge-level oneM2M MN-CSEs store and share this operational data within the same zone to coordinate real-time actions without depending on the central cloud.

Persistent Storage and Global Coordination

While edge-level data processing handles time-sensitive workloads, persistent storage and global coordination occur at the oneM2M IN-CSE located in the cloud or central control centre.

The IN-CSE aggregates metadata, historical logs, and analytical outputs coming from distributed MN-CSEs to:

• Maintain long-term datasets for predictive maintenance. Enable global berth scheduling and port-level analytics for optimizing docking allocation.
• Enable global berth scheduling and port-level analytics for optimizing docking allocation. Provide cross-zone synchronization, ensuring consistency between different port segments.
• Provide cross-zone synchronization, ensuring consistency between different port segments.

This design enables a hierarchical data flow:

• Edge level (MEC / MN-CSE): Real-time, short-term sensor fusion and actuation.
• Cloud level (IN-CSE): Persistent storage, coordination, and global optimization.

To ensure reliability, both layers implement redundant nodes and data replication mechanisms, enabling system recovery in case of hardware, network, or software failures.

Security and Reliability

The proposed system ensures the security of the information being exchanged between communicating parties by utilizing end-to-end security features of SECOM published by IEC. Our system will include an implementation of SECOM that provides the establishment of a secure session key between communicating parties with the exchange of public keys running as a MEC app. This, in return, will guarantee the confidentiality, integrity, and non-repudiation of the data being exchanged. On top of this authenticity of the entities involved in the information exchange will be guaranteed.

By combining SECOM-based security with MEC deployment, the system achieves low-latency and secure communication between edge and cloud components while maintaining reliability through:

• Distributed processing across multiple MEC nodes;
• Redundant data synchronization via oneM2M CSEs.

This ensures that even in the event of connectivity loss or node failure, the system maintains service continuity, trust, and resilience across the entire automated docking ecosystem.

Impact

The proposed architecture aims to solve the problem and challenges identified in this use case, exploiting the interworking capabilities of oneM2M platforms and MEC applications. Deploying MN-CSE instances directly on MEC nodes located at the edge in the berth areas of the port enables local execution of tasks like berth slot allocation or emergency incident recognition, minimizing the latency and ensuring high responsiveness. Moreover, edge computation enables real-time coordination among ships, trucks, and OTs, improving safety, efficiency, and sustainability during docking operations.

MEC applications host AI computation that processes heterogeneous sensor data coming from cameras and LiDARs, while oneM2M MN-CSE can provide the standardized store and share platform for heterogeneous data exchange and orchestration among distributed components.

Combining oneM2M and MEC standard technologies, we can build a system capable of ensuring low-latency decision-making at the edge, while maintaining global synchronization and data persistence in the cloud-based IN

**Read more

Custom parts and enclosures

Schematics

Code

Credits