Case study · Sector: naval propulsion
Propulsion data from every ship. Without touching the control.
A Linux PLC on board reads the propulsion control, listens to NMEA 2000 and sends the data to shore over MQTT.
Each ship is a site with no cable to the office.
So every propulsion system gets a gateway, and the data reaches shore when the link allows.
Based on real installations of Industrial Shields customers in the naval propulsion sector; data and names are not published. The gateway role, the controller bought in series for it and its interfaces (Ethernet, RS-485 and CAN) come from what these makers buy and ask us. Register maps, PGNs, messages and panel values on this page are examples of a typical way to do it.
The challenge
Data locked inside the propulsion control.
Makers of propulsion systems (propellers, thrusters and their controls) install their equipment on ships that sail all over the world. The control system knows pitch, shaft speed, hydraulic pressures and alarms, but that data stays on board. To support the crew, plan service and design the next system, each maker needs the data on shore, from every vessel, without adding risk to a system that moves the ship. That calls for a separate gateway: it reads, and it never commands.
Read the propulsion control
Pitch, shaft speed, setpoints, hydraulic values and alarms over Modbus TCP or Modbus RTU.
Listen to the ship
Engine and navigation data from NMEA 2000 or J1939, with a CAN board.
Send to shore
MQTT through the router of the vessel, with a local buffer while the satellite or 4G link is down.
The same unit on every ship
One gateway and one software image, with a configuration file per vessel.
Read only, by design
The gateway has no write path to the propulsion control: Modbus reads only, CAN listening only, and its own network segment. Commands and alarms stay in the propulsion control and the alarm system of the ship.
How it works
Three jobs: read the propulsion, send to shore, listen to the ship.
Each panel shows one job of the gateway. Press the buttons. The panels are illustrative simulations with example values, not data from a customer or a vessel.
Poll, check, timestamp.
The gateway polls the propulsion control over Modbus TCP, or over Modbus RTU on RS-485, at a fixed rate. Each value is scaled, checked against its range and timestamped. If the control stops answering, the gateway marks the values as stale instead of sending an old number as if it were new. Go from harbour to transit, then lose the answer.
- Pitch, shaft speed, hydraulic pressure, alarms
- Scaling and a range check per register
- A stale flag when an answer is missing
Gateway log (example)
- Gateway polling the propulsion control.
Illustrative simulation. Example values, no data from a customer. The register map comes from the documentation of each propulsion control. A gateway that only reads holding or input registers cannot change a setpoint by mistake.
Try Modbus polling, timeouts and stale values: Modbus network simulator
Keep it at sea, send it when the link is back.
The gateway publishes the values over MQTT to a broker on shore, through the router of the vessel: satellite at sea, 4G near the coast. The link comes and goes, so every message is stored first on the gateway and sent in order when the link returns. Values go out when they change, plus periodic summaries, to save bandwidth. Lose the satellite, then get it back.
- MQTT over TLS to the broker on shore
- A local buffer while the link is down
- Send on change, plus summaries
Link log (example)
- Gateway connected to the broker on shore.
Illustrative simulation. Example values, no data from a customer. Message rates and buffer sizes are examples. Size the buffer for the longest time without a link on the route of the vessel, and keep the timestamps of the gateway, not the time of arrival on shore.
The data is already on the backbone. Listen, do not talk.
Engine speed, speed over ground and speed through the water are already on the NMEA 2000 backbone of many vessels. With a CAN board, the gateway listens to the parameter groups it needs (PGNs) and puts them next to the propulsion data, so pitch and power can be compared with the real speed of the ship. It only listens: it does not claim an address or send to the backbone. Compare two voyages.
- PGN 127488: engine speed
- PGN 129026: speed and course over ground
- PGN 128259: speed through the water
NMEA 2000 log (example)
- CAN board on the backbone, 250 kbit/s.
Illustrative simulation. Example values, no data from a customer. Less speed for the same pitch and power can come from current, wind, waves, load or fouling. The gateway only puts the numbers side by side; the analysis on shore decides. Which PGNs a vessel has depends on its devices.
System architecture
How do you get propulsion data from a ship to shore?
The propulsion control serves its values over Modbus TCP on Ethernet or Modbus RTU on RS-485. A RASPBERRY PLC CPU-Gateway FLEX polls them, and with a CAN board it also listens to NMEA 2000 or J1939. Python or Node-RED scales, checks and timestamps the values, stores them, and publishes them over MQTT to a broker on shore through the router of the vessel. The gateway sits on its own network segment and has no write path to the control.
| Signal | Between | Type | Purpose |
|---|---|---|---|
| Pitch, shaft speed, setpoints | BetweenPropulsion control → gateway | TypeModbus TCP, read only | PurposeOperating profile of the propeller |
| Hydraulic pressure and temperature | BetweenHPU or thruster control → gateway | TypeModbus RTU on RS-485 | PurposeService planning |
| Alarms and events | BetweenPropulsion control → gateway | TypeModbus registers, read only | PurposeA timeline of events on shore |
| Engine speed | BetweenNMEA 2000 → gateway | TypePGN 127488, CAN, listen only | PurposeCompare with shaft speed and pitch |
| Speed and course over ground | BetweenNMEA 2000 → gateway | TypePGN 129026 | PurposeSpeed against power |
| Speed through the water | BetweenNMEA 2000 → gateway | TypePGN 128259 | PurposeHull and propeller condition, as a trend |
| All values, with time and quality | BetweenGateway → broker on shore | TypeMQTT over TLS | PurposeService, support and R&D |
| Gateway status | BetweenGateway → broker on shore | TypeMQTT | PurposeKnow that the gateway itself is alive |
Why it works
A gateway that reads everything and commands nothing.
No risk to the control
Reads only, its own network segment, no commands. The propulsion control and its alarm system stay as they are.
Built for a series
The same Linux image on every unit, with one configuration file per vessel.
Open software
Debian with Python and Node-RED: the maker owns the protocol code and can read every line of it.
The ports a ship needs
Two Ethernet, two RS-485 and a CAN board option in one DIN rail unit.
It survives the link
A local buffer and MQTT keep the data while the satellite is down.
Data for the next design
Real operating profiles of the propeller feed service plans and R&D.
Hardware
A Linux PLC with no local I/O: a gateway.
Bought in series for this roleRASPBERRY PLC CPU-Gateway FLEX
The Raspberry PLC without local I/O. In this sector it is bought in series, one per installation, to collect data and pass it on; the I/O stays in the propulsion control.
- Role in this design
- Polls Modbus, listens to CAN, buffers the data and publishes it over MQTT
- Compute
- Raspberry Pi 4, quad core 64-bit, 1.8 GHz, 2, 4 or 8 GB RAM
- Ports
- 1 x Gigabit and 1 x 10/100 Ethernet, Wi-Fi, Bluetooth LE, 2 x USB 2.0, 2 x USB 3.0, 2 x RS-485
- Expansion
- One optional board: CAN, LoRa or 4G (LTE-M/NB-IoT or LTE Cat 4)
- Software
- Debian 64-bit preinstalled; runs Python, Node-RED and C/C++
- Power and mounting
- 12 to 24 Vdc, UPS with supercapacitors, real-time clock, DIN rail TS35, IP20, 0 to 50 °C
This page does not claim a marine type approval from a classification society. Use the gateway for data and monitoring outside the essential control and alarm functions, and agree its place with the yard and the class society. A 24 V ship supply varies with batteries and chargers, so feed the gateway from a stable supply. NMEA 2000 runs on CAN at 250 kbit/s: the CAN board gives the bus, and the protocol layer comes from the software. Test it on the real backbone before the series. The gateway is rated 0 to 50 °C: mount it in a ventilated cabinet away from engine room heat, and check the environmental limits the class society sets for that location.
Questions about this case
What is an onboard data gateway for propulsion?
A separate computer on board that reads the propulsion control and other ship systems, checks and timestamps the values, stores them, and sends them to shore. It does not control anything. Here it is a RASPBERRY PLC CPU-Gateway FLEX, one per installation, reading Modbus and CAN and publishing over MQTT.
NMEA 2000, Modbus or MQTT: which one?
Each has its own place. Modbus TCP or Modbus RTU is what propulsion controls usually offer to read their values. NMEA 2000 carries the engine and navigation data that is already on the backbone of the vessel. MQTT carries everything to shore over a link that comes and goes. You can try Modbus polling, timeouts, stale values and word order in the Modbus network simulator.
Can a Raspberry PLC read NMEA 2000?
Yes, with the CAN board. NMEA 2000 runs on CAN at 250 kbit/s; Linux sees the board as a SocketCAN interface, and the protocol layer (for example, fast packet for PGNs longer than one frame) comes from the software, such as open source NMEA 2000 decoders. To listen, the gateway does not need to claim an address. To send on the backbone it must claim one, and a product sold as NMEA 2000 certified needs the certification of the NMEA. Test with the real backbone on the bench before the series. For CAN on a Raspberry PLC, see this CANopen reading example.
Why read only?
Because the propulsion control moves the ship. A gateway that only reads and sits on its own network segment cannot change a setpoint or silence an alarm by mistake, and it keeps the cyber exposure of the control low. For ships contracted from 1 July 2024, IACS UR E26 and E27 set cyber resilience requirements for the ship and its onboard systems; agree with the yard and the class society how a data gateway fits.
What happens when the satellite link drops?
The gateway keeps every message, with its own timestamp, in a local buffer and sends it in order when the link returns. MQTT with a persistent session and a quality of service of 1 helps not to lose messages at the broker. For a Python bridge from MQTT to a database on a Raspberry PLC, see this example.
Does the gateway need marine type approval?
It depends on the function and on the class society. Equipment for essential control, alarm or safety functions usually needs type approval; a data gateway outside those functions often does not, but the class society decides. This page does not claim a type approval for the Raspberry PLC.
Download the case study
4-page PDF with the challenge, the logic, the architecture and the hardware. No form required.
Similar project?
Tell us about your propulsion data. An engineer will answer.
Tell us which controls you need to read and over which protocol, whether there is an NMEA 2000 or J1939 network on board, how the vessel connects to shore, and how many installations a year you deliver. We will tell you how to build the gateway.
- You get an answer from our technical team
- Modbus TCP and RTU, CAN, NMEA 2000 and MQTT
- Arduino, ESP32 or Raspberry Pi based PLCs