Modbus RTU to Cloud Gateway Using RAPIDSEA Modbus Protocol Stack
Snapshot
RAPIDSEA partnered with an industrial automation OEM to build a production-ready Modbus RTU to Cloud Gateway that bridges legacy RS485 field devices with modern IoT cloud platforms. By deploying the RAPIDSEA Modbus Protocol Stack, the engineering team delivered a fully validated Modbus RTU TCP converter — supporting simultaneous RTU Master and TCP Server roles — in under 8 weeks, cutting protocol integration effort by over 60% and differentiating the product from competing gateways in the market.
Customer Profile
Mid-sized industrial automation OEM serving process industries across India and Southeast Asia. Product portfolio includes data acquisition systems, remote monitoring units, and industrial gateways for energy, water treatment, and manufacturing sectors. Supplies to both end-users and system integrators deploying equipment in brownfield automation environments.
Business Context
Industrial plants continue to operate large fleets of legacy PLCs, sensors, and actuators communicating exclusively over Modbus RTU — a serial protocol standardised under IEC 61158 that predates modern connectivity requirements by decades. The customer identified a clear market gap: clients needed a gateway collecting data from RS485/RS232 field devices and forwarding it to cloud platforms such as AWS IoT and Azure IoT Hub, with minimal disruption to existing plant networks.
The challenge went beyond simple protocol translation. The gateway needed to operate as a Modbus RTU TCP converter embedded in a resource-constrained MCU — simultaneously polling field devices over RS485 and serving upstream SCADA or cloud connectors over Ethernet — without an OS overhead penalty.
Key Challenges
- Dual-Mode Protocol Complexity: The gateway had to operate concurrently as a Modbus RTU Master and Modbus TCP Server — two distinct roles that share the same data model but differ sharply in framing, timing, and error handling.
- Legacy Device Diversity: Field devices from different vendors implemented Modbus RTU inconsistently — varying byte orders, non-standard register maps, and timing tolerances — requiring a highly configurable polling engine.
- Resource-Constrained Target: The target MCU offered limited RAM and no rich OS. A full Modbus protocol stack embedded implementation built from scratch would have consumed most of the available heap before application logic was added.
- Time-to-Market Pressure: The OEM had an existing customer awaiting a working prototype within two months, with production quantities to follow within a quarter.
- Cloud Differentiation: Competing gateways treated cloud connectivity as an afterthought. The OEM required MQTT-based telemetry baked into the firmware architecture, not bolted on.
Target Platform
STM32-based 32-bit ARM Cortex-M4 MCU, running bare-metal with a lightweight RTOS for task scheduling. Dual RS485 ports, Ethernet interface for Modbus TCP and cloud uplink, and onboard EEPROM for configuration persistence. RAPIDSEA Modbus Stack's OS-agnostic, MISRA-C compliant architecture made it a natural fit without requiring OS-specific porting work.
Why RAPIDSEA
- Dual-Mode Architecture Out of the Box: The RAPIDSEA Modbus Protocol Stack natively supports Master, Slave, RTU, and TCP modes as independently configurable modules — no forking, no custom glue code.
- MISRA-C Compliant Source Code: The customer's quality team mandated MISRA-C for production firmware. Open-source alternatives did not meet this bar.
- Royalty-Free Per-Part Licensing: The OEM's business model required embedding the stack across hundreds of gateway units per batch. Per-unit royalties would have eroded margins at scale.
Solution: How to Connect Modbus RTU Devices to a Cloud Platform
Modbus Protocol Stack Embedded Integration: HAL Mapping
Integration began with the RAPIDSEA Hardware Abstraction Layer. The team mapped the STM32's dual UART peripherals — operating in RS485 half-duplex mode — to the RAPIDSEA HAL serial interface. HAL mapping was completed in under two days. The Modbus RTU engine sat cleanly above the hardware with zero MCU-specific code inside the protocol layer.
Modbus RTU Master: Configurable Polling Engine
Configured to poll up to 32 downstream field devices across two RS485 ports. Polling schedule stored in EEPROM and loaded at boot — fully reconfigurable without firmware reflashing. Built-in exception response handling and configurable inter-frame timeout accommodated non-standard legacy devices violating strict IEC 61158 Modbus timing.
Modbus RTU TCP Converter: TCP Server for SCADA and Cloud Connectors
The RAPIDSEA Modbus TCP Server exposed the gateway's internal register map over Ethernet. SCADA systems queried live field data using standard Modbus TCP function codes. The shared data model — implemented using the RAPIDSEA data object architecture — avoided race conditions typical when two protocol engines share state on a bare-metal RTOS.
Cloud Telemetry: MQTT and IoT Stack Integration
MQTT-based telemetry implemented using the RAPIDSEA IoT stack. Register snapshot payloads serialised into JSON using the RAPIDSEA File Formats module and published to AWS IoT Core. Per-register alert thresholds triggered immediate out-of-cycle publishes for real-time alerting.
Validation and Field Deployment
Validated against PLCs from Siemens and Schneider Electric, flow meters, and energy monitoring units over RS485. Protocol conformance verified using Modbus Poll and Modbus Slave simulation tools. Complete integration cycle from HAL bring-up to cloud-connected prototype: 7 weeks.
Engineering Impact
| Metric | Result |
|---|---|
| Time to SoP | 7 weeks from HAL bring-up to cloud-connected prototype |
| Protocol integration effort reduction | 60%+ — estimated 4-5 weeks of protocol engine development eliminated |
| Dual-mode footprint | RTU Master + TCP Server running concurrently under 18 KB ROM on Cortex-M4 |
| Device polling | 32 field devices across 2 RS485 segments with zero frame loss |
| Product differentiation | MQTT telemetry with per-register alerting — absent in all 3 competing gateways evaluated |
| Reuse | Same Modbus stack config portable to NXP LPC variant — HAL callbacks only |
Conclusion
Building a Modbus gateway that bridges IEC 61158-compliant RS485 field devices with modern cloud platforms is a deceptively complex engineering problem. The RAPIDSEA Modbus Protocol Stack gave this OEM a production-validated, MISRA-C compliant foundation for both RTU Master and TCP Server roles — on a resource-constrained MCU, within a commercial schedule, and without per-unit royalty exposure.
Contact us for a technical demo or evaluation package.
Frequently Asked Questions
Yes. The RAPIDSEA Modbus Protocol Stack is architected with RTU and TCP as independently configurable modules sharing a common data model. Both roles can run concurrently on a single MCU including resource-constrained Cortex-M class targets, without conflict or duplication of the register table.