How to Set Up an OPC UA Server on a Vessel Safely
For OPC UA maritime integration, put the server on the vessel's data side, behind a firewall. Feed it read-only from gateways that read NMEA 2000, Modbus and engine controllers, and turn on the standard's own certificates, encryption and user authentication. Model equipment with existing companion specifications where they exist, and decide shore-link behavior separately from the OPC UA session.
Which parts of OPC UA matter on a vessel
Four parts matter: the information model, the address space, the services and the security model. The specification is split along these lines. The BSI study of OPC UA lists Part 1 (Overview and Concepts), Part 2 (Security Model) and Part 4 (Services) among them.
Learn the server architecture first. Part 1 of the specification describes the server as the endpoint of client/server interactions, with real objects behind it such as sensors, actuators and motors. On a ship, those real objects are your pumps, engines and tanks, and the server is the single place clients ask about them.
The services are already standardized. According to the OPC Foundation's overview, a caller needs no special knowledge of how a particular service behaves, so a shore client does not need a custom protocol per vendor.
Address space and information model
A device becomes an object with values, alarms and limits, arranged in a hierarchy any client can browse. The OPC Foundation overview says the object model integrates production data, alarms, events and historic data in a single server, and gives the example of a temperature device carrying its value, alarm parameters and limits.
For a vessel, that means a main engine is one object, not forty loose tags. Its exhaust temperatures, alarm setpoints and history sit beneath it. Clients navigate through one interface, and the top levels of the hierarchy are standardized for all servers. Decide your tree early: vessel, then system, then equipment, then signals. Changing it later breaks every client that browsed the old path.
Connecting NMEA 2000, Modbus and engine controllers
Use gateways or drivers that expose each source as an OPC UA server, or that feed one. NMEA 2000 converters exist in both roles. One published converter family includes a client-side unit that reads and writes NMEA 2000 data using OPC UA servers, and a server-side unit that lets OPC UA clients reach NMEA 2000 devices such as fluid level sensors.
Keep the gateway's role narrow. For data collection, you want read access only.
| Source | Connection pattern | OPC UA role | Still needs mapping |
|---|---|---|---|
| NMEA 2000 | Converter on the bus | Server exposing devices, or client feeding your server | Device names and units to shared fields |
| Modbus | Driver or gateway polling registers | Feeds your server as a client | Register addresses to named signals |
| Engine controller | Vendor interface or gateway | Feeds your server as a client | OEM signal names, units and identifiers |
Modbus registers carry no names, so the register map is the documentation. Treat it as a deliverable, because someone will need it in five years.
Companion specifications for marine and machinery equipment
Reuse existing companion specifications and check the online reference for your domain before defining your own. The OPC Foundation says companion specifications publish information models for specific industries, devices and use cases. Its modelling best practices recommend reusing them to increase interoperability at the information model level, and note that domain examples include robots, vision systems and machine tools, alongside generic ones built as a base for more specific work.
Do not assume a marine specification covers your engine. If none does, build on the generic base models rather than inventing node types from scratch.
Mapping differing OEM signals to one schema
OPC UA standardizes how data is exposed, not what each OEM calls a signal. Two engines from different makers can both serve a coolant temperature through a clean OPC UA interface, with different names, units and identifiers. An operations manager comparing two vessels still cannot line them up.
That translation needs doing once, in a layer above the server.
Placing the OPC UA server in the ship network
Put the server on a data-side segment, read-only toward control systems, with a firewall between. The decision rule is direction. Data may flow from control networks to the server. Nothing from the server, shore or any client may write back toward propulsion, power or safety systems.
If a gateway must sit on a control bus, keep it passive or read-only, and keep the OPC UA server itself off that bus. Where a use case needs write access, such as setpoints, treat it as a separate control-side design with its own risk assessment, and never as an extension of the data server.
Cybersecurity requirements for vessel systems that expose data
Guidance expects risk-based safeguards per critical system, with OT treated differently from IT. DNV's recommended practice on ship cyber resilience says that once a critical system's risk is determined, existing safeguards should be compared with target safeguards depending on the system's IT/OT nature.
In practice, document the server as a system, list what it connects to, assess the risk of each connection and record the safeguards you chose. Class and flag requirements for your vessel may add to this, so check them for your ship.
How OPC UA certificates, encryption and authentication fit
The security model covers application certificates, message encryption and user authentication. Part 2 of the specification defines it, and gateway vendors note that OPC UA communication can be encrypted.
The standard supplies the mechanisms. You operate them. Use signed and encrypted sessions rather than anonymous, unsecured endpoints. Give each client its own user identity with the least access it needs. Keep a trust list of approved application certificates, and plan renewal before certificates expire, because a vessel offshore cannot easily fix a lapsed one.
Intermittent satellite links and limited bandwidth
Buffer at the edge, send alarms first, summarize trends and backfill history when the link returns. Choose by what the data is for.
- Alarms and events: send immediately and in small messages. They are the reason someone ashore is watching.
- Trends: send summaries such as averages, minimums and maximums over an interval, at a rate that suits the question being asked.
- Bulk history: hold it onboard and upload when the link is good or the vessel is in port.
Because the address space already integrates alarms, events and history, one server can serve all three classes. Do not hold the OPC UA session open across the satellite hop. Run it onboard and let a store-and-forward service carry data to shore, with timestamps set at the source so late data lands in the right place.
Avoiding rebuilt connectors as tools change
A shared schema above the OPC UA layer means new tools connect once. Without it, every new analytics tool or dashboard needs its own mapping, which is the integration tax. Sizing that rework before you buy shows the real cost.
We build that unified schema on top of your existing systems, without replacing them. To see how it would look built from your own vessel data, start with a demo.
Related resources
SailPlan builds the machine-readable data model that makes every AI tool in your stack actually work. Request a demo to see it in action.