For an international oil and gas operator, getting operational data off a vessel was an integration challenge as much as a communications challenge. Ships carried several onboard systems, each with its own interface, while shore-side access depended on satellite connectivity at sea. The project brought those sources into an Ignition-based data path and used scheduled JSON messages over MQTT to move selected information toward enterprise systems.
The operational challenge
The fleet needed a repeatable way to collect information locally and make it available ashore. A vessel could not be treated as an extension of a continuously connected office network. Data acquisition, movement through onboard network boundaries, and publication over the external connection each required explicit handling.
Source integration introduced a second challenge. One engine-performance monitoring application lacked a suitable standard driver for bringing its data into Ignition. The integration had to accommodate the interfaces available in the existing environment.
A layered shipboard architecture
The shipboard architecture followed three Purdue-oriented layers: Level 3 — Operations, Level 3.5 — Industrial Demilitarized Zone, and Level 4 — Enterprise. Shore-side cloud services formed a separate destination beyond the onboard network. Each layer provided a distinct boundary along the data path.
Ignition gateways and MQTT components formed part of the staged data path. The architecture separated local source integration from onward delivery, allowing the enterprise destination to receive information through the designated zones rather than requiring direct access to individual control systems.
Ship-to-Shore Telemetry Architecture
Operations, Industrial Demilitarized Zone and Enterprise layers linked to a shore-side enterprise gateway over satellite connectivity.View Image
Integrating existing ship systems
The integration reached into both control systems and monitoring applications. The reference architecture includes propulsion and diesel-engine controls, alarm and automation systems, navigation and voyage recording, and cargo monitoring. It also places engine-performance, power-quality, vibration, and weather monitoring equipment at the industrial boundary. Vendor gateways, serial-to-Ethernet interfaces, application servers, and databases provided different routes to that information. Ignition served as the integration platform for acquiring and mapping accessible data before onward MQTT publication.
Engine-performance monitoring illustrates the need for source-specific integration. Its vendor-specific data format required custom decoding to make the information usable within Ignition. This decoding step formed part of the broader integration approach: interpret the source data, map it into a common representation, and publish selected information through MQTT.
Alarm monitoring and voyage data recorder interfaces introduced additional integration requirements. Their differing protocols and configuration requirements reinforced the need for a common representation after acquisition. Ship and zone naming conventions helped preserve context as data moved upstream.
Publishing JSON over MQTT
The implementation contribution described here centered on publishing collected data at a configured interval when internet connectivity was available. Values were encoded as JSON and published through MQTT toward the enterprise environment. The publication logic encoded tag/value pairs as JSON before passing the payload to the MQTT publish function.
The custom publication path used JSON payloads, alongside other MQTT components in the wider system. This case study focuses on that scheduled JSON publication rather than treating every MQTT connection in the installation as the same implementation.
Separating collection from publication made the transfer schedule an explicit integration concern. Source acquisition could be configured around the equipment, while onward publication could be configured around the ship-to-shore connection. The important operational question was not simply whether a local value existed, but whether it had become available to the shore-side consumer.
Making the data path understandable
A useful telemetry interface brings source status, onboard zone status, and shore-side publication into the same view. The representative interface below illustrates that relationship using fictional vessel identifiers and sample states. It is an explanatory reconstruction, rather than an archived production screen.
Vessel Telemetry and Connectivity
Vessel telemetry interface showing local sources, network zones and MQTT publication context.A repeatable foundation for a fleet
A reusable configuration approach was intended to support consistent gateway, device, tag, and module configuration across vessels. Naming conventions, zone-specific resources, and a shared data model were part of that work. This addressed a practical fleet concern: repeating the same architectural pattern while accommodating different equipment on each ship.
The configuration approach distinguished installation prerequisites and manually configured connections from the configuration steps targeted for automation. That distinction is useful engineering context: a repeatable deployment approach depends on understanding which steps can be automated and which still require installation-specific configuration.
What the project delivered
The central contribution was an Ignition-based integration and publication approach for moving shipboard data toward enterprise systems over intermittent connectivity. The implementation combined source integration work with interval-based JSON publication over MQTT when a connection was available.
The case demonstrates how protocol adaptation, network zoning, consistent data naming, and publication scheduling work together in a remote monitoring system. The value lies in creating a usable path from isolated equipment data to a shore-side consumer, while respecting the existing shipboard architecture.
Engineering lessons that remain relevant
The enduring lesson is to treat source integration, network boundaries, and remote delivery as related but distinct engineering problems. A common messaging transport does not remove the need to understand the source protocol, and a healthy onboard connection does not establish that information has reached shore.
For similar projects today, the same questions deserve early attention: which values must be collected, how their source and time are represented, when they should be published, and how operators can distinguish current local data from the latest information received remotely.
Planning a remote monitoring or industrial integration project? Discuss your requirements with No Ceilings