VODI – Vessel Open Data Interface

We are true believers of easy and straightforward information sharing and considering the complexities of existing interface formats onboard ships, we believe that the Maritime Industry could learn from the likes of the Internet on this topic.

We believe that our VODI-concept can greatly help in interfacing data also onboard vessels and the simple idea is to use machine readable and self-documented data – Internet-enabled – interfaces where the interface (and data) is owned by the Vessel owner and not the system supplier. There is no need to setup any new Joint Industry Projects on open interfaces or try to come up with some nice new data protocol, since all that has already been invented a hundred times over on the World Wide Web.

Why not NMEA?

The maritime NMEA “standard” (yes, we put this in quotation marks since there exists also a great number of non-standard NMEA data) comes pretty close to a VODI interface, since it is usually human readable and most of the time self-explanatory. However, NMEA needs to be separately parsed by the receiver and for a typical Coder it causes extra headaches and in some cases an NMEA feed needs to be opened/administered by the System supplier. Non-standard XDR sentences will also need to have a specification available for understanding how they are coded.

Despite its drawbacks, NMEA is a great, simple and robust streaming protocol.

What about Modbus?

Modbus is extensively used in automation systems around the globe and when you configure it correctly it usually works very well indeed from here to eternity. However, Modbus has some hefty limitations, of which the most obvious ones are:

Modbus is not self-documented, i.e. if you type in the IP-address of a Modbus (TCP) server, it usually says nothing at all about itself and you must get the interface spec from the system supplier in order to decipher the content of the data
A Modbus-interface is very often controlled by the System supplier and a Vessel owner cannot access their own data without having to pay extra for it
Modbus as a technology is restricted to 16bit data, which means that larger numbers are combined from two different modbus registers in some big endian, little endian or other likewise uncomprehendable way
Modbus is really lousy at text data and we have actually never yet come across a modbus interface that would deliver text

So, what is VODI?

The Vessel Open Data Infrastructure (VODI) is designed to enable an easier and more cost efficient and future proof way to access relevant data in all the vessel’s internal systems, while at the same time minimizing the need to duplicate sensors or pull new cables each time there is a major overhaul or a new system/solution is installed to the vessel. The VODI works much in the same way as the Internet/World Wide Web, where any number of computers, sensors or devices can be connected to and be discoverable on a common network and, if allowed, access/query the data in another computer, sensor or device on the same network. The connections are done using web-standard APIs (Application Programming Interfaces), which are field-proven and well documented ways to enable Machine-to-Machine (M2M) data exchange.

The basic VODI concept is as follows:

Each onboard system, which has its own sensor(s) or is the physical endpoint of a sensor, shall have a network/Ethernet-based VODI API, through which other systems can query or receive the system’s data over the vessel’s network or a dedicated system/vendor/VODI network
A VODI API shall be built on well-known and openly documented web-service API-standards, using REST/JSON, XML, WFS, MQTT, HTTP, WebSocket or other such typical technology, in order to enable external systems to access the data without need to contact the supplier of the other system or have the other system supplier perform special work to enable an interface
A VODI API can expose simple numerical or text data in a system, but it shall also be designed to handle sharing of document, binary-type data, images, video and sound (using Blob URLs or similar)
A VODI API should also offer access to the system’s raw sensor data to minimize the need to duplicate sensors
A VODI API shall use standard API-authentication methods, such as HTTP Basic Authentication, API-key, Token, OAuth or similar (to be defined by the Owner)
A VODI API shall expose its capabilities in a machine readable and human readable format (such as getCapabilities or by incorporating field names and descriptions into the data itself) so that a connected system can read the available data parameters without the need to contact the supplier of the other system, or at the very least be so self-explanatory that the other system supplier cannot justify any type of cost for setting up or describing the data
Preferably the API is documented with Open Source API-software such as Swagger, which at the same time also documents the API’s capabilities.
A query/response-type VODI API shall be able to handle at least 25 Queries Per Second (25 QPS), which means that up to 25 external systems must be able to query the interface each second
A WebSocket-type VODI API shall be able to handle at least 25 connected clients
Each VODI API should have a password protected and browser-based management console, through which the vessel Owner is able to manage the interface, assign/revoke API-keys or authentications and select which parameters shall be made available to each connected system/API-key, or if this is not pratically possible, then the System supplier shall be responsible for setting up and configuring this at no extra cost (provided that the vessel and system has remote configuration enabled)
A VODI API shall have basic usage logging (who/which system made a query and when and if the query/response was successful) in order to enable easier fault finding

Below text can be added to the specification of each selected system, which is desired to have a VODI API.

Vessel Open Data Infrastructure (VODI) API for a [system]

The system shall have a VODI API with following characteristics:

The VODI API shall include all the available static (as in almost never changing), semi-static (as in Voyage-based quite often changing) and dynamic (as in online-type data) parameters available in the system
The VODI API is to be network/TCP-based
The VVODI API shall be built on well-known and openly documented web-service API-standards, using REST/JSON, XML, WFS, MQTT, HTTP, WebSocket or other such typical technology, in order to enable external systems to access the data without need to contact the supplier of the other system or have the other system supplier perform special work to enable an interface
The VODI API shall primarily offer numerical and string format data. Binary type documents/attachments/images/video/sound can be offered through Blob URLs or similar Object-URLs (if relevant for the system)
The VODI API should also offer access to the system’s raw sensor data to minimize the need to duplicate sensors
The VODI API shall use standard and well documented API-authentication methods, such as HTTP Basic Authentication, API-key, Token, OAuth or similar (to be defined by the Owner)
The VODI API shall expose its capabilities in a machine readable and human readable format (such as getCapabilities or by incorporating field names and descriptions into the data itself) so that a connected system can read the available data parameters without the need to contact the supplier of the other system, or at the very least be so self-explanatory that the other system supplier cannot justify any type of cost for setting up or describing the data
If the VODI API is a query/response-type, it shall be able to handle at least 25 Queries Per Second (25 QPS), which means that up to 25 external systems must be able to query the interface each second
If the VODI API is a WebSocket-type streaming API, it shall be able to handle at least 25 connected clients
The VODI API should have a password protected and browser-based management console, through which the vessel Owner is able to manage the interface, assign/revoke API-keys or authentications and select which parameters shall be made available to each connected system/API-key, or if this is not pratically possible, then the System supplier shall be responsible for setting up and configuring this at no extra cost (provided that the vessel and system has remote configuration enabled)
The VODI API shall have basic usage logging (who/which system made a query and when and if the query/response was successful) in order to enable easier fault finding