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.

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. 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

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 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, such as REST/JSON, XML, WFS or as WebSocket, 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) so that a connected system can read the available data parameters without the need to contact the supplier of the other system. 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 shall 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
  • 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 VODI API shall be built on well-known and documented web-service API-standards, such as REST/JSON, XML, WFS or as WebSocket, in order to enable external systems to access the data without need to contact the supplier of the system
  • 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 be well documented and expose its capabilities in human readable format (such as through getCapabilities or a Swagger UI or similar) so that a connected system supplier can read the available data parameters without the need to contact the supplier of the system
  • 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 shall 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
  • 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