One of the main topics discussed during the Navelink Developer forum in February was STM, SECOM and MMS design patterns for services. The attendees were also given a presentation about the POLO app for port actors, which was held by Anders Berg, Senior Manager for Maritime Solutions at Unikie.
The STM, SECOM and MMS ways
A common question asked by service providers is which design patterns to use when designing services; the STM way, the SECOM way or the MMS way? Here is an overview of the three design patterns.
The STM way is a proven concept throughout the work of Sea Traffic Management, STM. One of its strengths is that it is built on simple REST technology with authentication on the communication channel (HTTPS/TLS), where clients authenticate themselves with X509 Certificates to the service. Further, it has no central routing of data. On the downside, there is the lack of signatures on data, and the last link between the ship and service for incoming data is not standardized.
For route plan exchange (RTZ) and navigational warning (S-124), the same Voyage Information Service (VIS) was used both for ship and shore side services, hence resulting in one common Service Design for all exchanges of RTZ and S-124.
The STM design patterns for services have current implementations in that the 170+ services registered in Navelink today are based on VIS technical design. The forecast is that VIS and RTZ will continue to be used throughout 2023 and at least during 2024.
The SECOM way offers similar advantages to the STM way, namely being built on REST technology, being a proven concept in STM and having no central routing of data. It also shares the same downside of not having a standardized last link between the ship and the service for incoming data.
SECOM is based on the STM concept but extended and integrated with the IHO S-100 standard. The difference to the STM design patterns is that SECOM requires signatures on the data to enable data authentication independent of transport security, which is in line with S-100.
SECOM contains guidelines for optionally encrypting data, as well as guidelines and API for exchanging the encryption key. SECOM contains API for big data using other files in combination with the SECOM REST Service. SECOM contains standard SECOM REST Service API “template” independent of payload format, rendering the same SECOM REST Service API usable for any S-product and other well-formatted data formats.
SECOM is of IEC 63173-2 standard and is approved. Work is ongoing to create service specifications based on SECOM for Aids to Navigate (AtoN) services, S-124 Navigational Warning services and VTS services. There are neither any approved specifications, nor any approved SECOM artifacts registered in Navelink yet. The forecast is that SECOM artifacts will be registered in Navelink during 2023 and 2024.
The MMS (Maritime Messaging Service) design patterns have been around for a while. Some of its advantages compared to STM and SECOM are that the last link between ship and service for incoming data is standardized and that it is more adaptable to non-IP communication. MMS design patterns are used in Korea and are a proven concept in SMART, but the STM Validation Project chose to not use the MMS since the REST services were adequate for validating the concept. The main difference is that MMS is built with a central message router, where all clients connect, send and receive the data which is routed by the central MMS router network.
The MMS has now been re-introduced in combination with VDES. Work is ongoing to standardize MMS (by RTCM), and drafts will be used in the coming VDES testbeds during 2023-2025.
Navelink’s role regarding the design patterns
Navelink provides technology and infrastructure for maritime services, based on specifications agreed upon in established forums. The role of Naveling is to support whatever kind of standard technologies the maritime market wants to create for maritime services. Navelink provides security and the registration of maritime services independent of the standard technology used by the service providers and consumers.
By providing information about the current usage of the design patterns, their advantages and disadvantages, as well as the forecast for their future usage, Navelink aims to offer the service providers a basis for decision-making.
Developer forum is a monthly recurring digital event offering Navelink users and stakeholders the chance to discuss development progress and coming focus areas. The next Developer Forum will be held on the 24th of March 2023 at 14:00h CET.
Author: Milena Dalinaros