A New Chapter in Industrial IoT: Integrated Applications of Sensors, PLCs, and Modbus Gateways/Routers
Updated: Oct 12
A sensor, a PLC, and a Modbus gateway can all appear on the same network diagram, but that does not mean they speak the same interface or share the same job. A sensor might connect to a PLC input; a PLC may expose selected values over Modbus; and a gateway may bridge a serial network to an IP connection. Each step needs to be confirmed for the equipment in the project.
Start by tracing one data point from its source to the system that will read it. This keeps wiring, control logic, protocol conversion, and remote access from being treated as one feature.
The Role of Sensors in Industrial IoT: The Foundation of Data Acquisition
Sensors make physical conditions available as electrical signals or digital values. Temperature, pressure, humidity, vibration and flow data can support maintenance and process decisions, but the measurement must first be suitable for the task. A vibration trend may help an engineer investigate a bearing; it does not establish a fault diagnosis or prevent downtime by itself. Record measurement range, accuracy, installation conditions and the update behavior the application needs.
Draw the path in order:
Sensor → input or communication interface → PLC logic/data point → Modbus client or server → gateway or network path → SCADA or monitoring application
The arrows can change with the equipment. Some sensors provide analog or discrete signals that terminate at a PLC input. Others expose data digitally. Check the sensor and PLC manuals for the actual interface, wiring, scaling, and update behavior; do not assume a sensor has a Modbus address simply because the PLC uses Modbus elsewhere.
Sensor type | Measurement role | Interface to verify | Application check |
|---|---|---|---|
Proximity | Object or position detection | Discrete output, electrical level and input compatibility | Confirm state changes at the PLC under the intended target and mounting conditions |
Temperature | Process or equipment temperature | RTD, thermocouple, transmitter or digital interface as specified | Verify range, scaling, unit and reference measurement |
Pressure | Fluid or gas pressure | Analog transmitter or documented digital protocol | Verify range, supply, process connection and known-pressure reading |
PLCs: The Core Brain of Industrial Automation
Definition and Functions of PLCs
PLCs run the local control program and connect input and output modules to machinery. A typical program reads inputs, evaluates logic and updates outputs; tasks, scan behavior and response time depend on the controller, program and I/O system. Ladder logic is one programming option. Keep protective and time-critical functions within the engineered control system instead of transferring responsibility to a remote monitoring service.
The PLC project defines which measured values, states and commands are shared with other equipment. A temperature input can be scaled into engineering units and used to control a valve locally, while a separately mapped value is exposed for monitoring. The controller can be a Modbus client, a server, both or neither, depending on its modules, firmware and application. Confirm this before selecting a gateway.
Next, identify where the value is stored and how it becomes available to another system. The PLC may expose a configured data point through a Modbus server, or it may act as a client that reads another device. Confirm the role and data map in the PLC project and manual. A register map is a deliberate configuration, not an automatic mirror of every sensor input.
PLC Manufacturers: Model-Specific Checks
The historical manufacturer list is useful as a procurement checklist, not a ranking. Identify the CPU, communication module, firmware and engineering software version for every proposed controller. Ask whether the required Modbus variant and client/server role are native, require a library or module, or need an external gateway. Cloud services, OPC UA and MQTT are separate capabilities. A manufacturer name does not establish them or the total project cost.
Manufacturer | Project identification | Protocol and integration evidence | Official entry |
|---|---|---|---|
Siemens | Historical examples; verify current configuration: SIMATIC S7-1200/1500. Record CPU, modules and firmware; do not assume a whole series behaves identically. | Check Modbus variant, client/server role, required library/module and data map. | |
Schneider Electric | Historical examples; verify current configuration: Modicon M221/M340. Record CPU, modules and firmware; do not assume a whole series behaves identically. | Check Modbus variant, client/server role, required library/module and data map. | |
Allen-Bradley (Rockwell Automation) | Historical examples; verify current configuration: CompactLogix. Record CPU, modules and firmware; do not assume a whole series behaves identically. | Check Modbus variant, client/server role, required library/module and data map. | |
Mitsubishi Electric | Historical examples; verify current configuration: MELSEC iQ-R. Record CPU, modules and firmware; do not assume a whole series behaves identically. | Check Modbus variant, client/server role, required library/module and data map. | |
Inovance | Historical examples; verify current configuration: H3U/H5U. Record CPU, modules and firmware; do not assume a whole series behaves identically. | Check Modbus variant, client/server role, required library/module and data map. | |
XINJE | Historical examples; verify current configuration: XC/XD/XL. Record CPU, modules and firmware; do not assume a whole series behaves identically. | Check Modbus variant, client/server role, required library/module and data map. | |
Delta | Historical examples; verify current configuration: DVP-12SE/DVP28SV. Record CPU, modules and firmware; do not assume a whole series behaves identically. | Check Modbus variant, client/server role, required library/module and data map. |
Modbus Protocol: The Bridge of Industrial Communication
Modbus provides an application data model built around coils, discrete inputs, input registers and holding registers. Supported function codes determine what a client may read or write. Its serial and TCP variants can help connect older equipment to supervisory applications, but shared protocol names do not guarantee matching register semantics, access rights or data representation.
Modbus RTU and ASCII use serial framing. Modbus TCP carries Modbus application data over TCP/IP with an MBAP header. The variants share parts of the application data model, but their messages and connection settings differ. RS-485 is a common physical layer for serial Modbus; it does not by itself define the message format.
Link segment | Record before configuration |
|---|---|
Sensor to PLC | Electrical/digital interface, wiring, scaling, and which device supplies the value |
PLC to Modbus client | PLC role, RTU/ASCII/TCP variant, endpoint, serial settings or IP/port, and supported function codes |
Gateway to upstream application | Gateway mode, source and destination variants, client/server roles, device identifiers, and register mapping |
Do not assume that “Modbus compatible” settles these details. A device may support only some function codes or one variant. Refer to the Modbus Application Protocol Specification, the Serial Line Protocol guide, and the TCP/IP implementation guide for protocol framing. Use each device's manual for the features it actually implements.
In a serial installation, choose compatible electrical interfaces, wiring, termination and communication parameters. In a TCP installation, document the server address, configured service port and connection policy. Serial-line timing, device turnaround, request size, controller processing and the polling schedule all affect the achieved update rate. Ethernet link speed is not Modbus transaction throughput, and cable reach must follow the actual physical-layer design.
Aspect | Serial Modbus RTU/ASCII | Modbus TCP | What to verify |
|---|---|---|---|
Physical path | Compatible serial interface and bus design | An engineered TCP/IP network | Wiring, isolation, endpoint and network reachability |
Framing | RTU and ASCII use different serial framing | Modbus application data with an MBAP header | Exact supported variant and conversion direction |
Roles | A client initiates requests to addressed devices | A client opens a connection to a server | Supported role, concurrency and unit-identifier treatment |
Data and addressing | Function codes and agreed data map | Function codes and agreed data map | Address convention, type, byte order, scaling and permissions |
Timing and capacity | Baud rate, turnaround and bus sharing affect updates | Processing, requests and connections affect updates | Measured response time and load; no generic distance or rate promise |
Protection | Serial access still needs physical and operational controls | A reachable service still needs approved network controls | Segmentation, permitted peers, write authority and recovery |
A working network path does not prove that a measured value has the correct address, unit or meaning.
Modbus Gateway vs. Modbus Router: Differences and Functions
Definitions of Modbus Gateway and Modbus Router
A protocol gateway terminates and interprets one protocol variant and creates messages for another. A serial server can instead carry an unchanged byte stream, and an IP router moves packets between networks. One product can combine these functions, but address translation, Modbus unit-identifier handling and application register remapping remain different operations.
An IP router forwards IP traffic between networks; RFC 1812 describes IPv4 router requirements. A serial server can transport serial bytes over an IP connection while leaving the Modbus serial message intact. A Modbus gateway can terminate one variant and generate requests in another, but the device must explicitly support the required mode and mapping.
The names “gateway” and “router” are not enough to establish behavior.
Check the product manual for the exact direction of conversion, the supported client/server roles, how device identifiers are handled, and whether data is passed through or polled and remapped. If those details are absent, treat the behavior as unverified and ask the vendor before designing around it.
Functional Comparison
Use the device-role comparison to place each function deliberately. A gateway is unnecessary when the two endpoints already support the same variant and can communicate through the approved network. Conversely, adding an IP route cannot convert a serial frame into a Modbus TCP request.
Device role | What it does | What it does not establish | Selection evidence |
|---|---|---|---|
IP router | Forwards IP packets between networks | Serial conversion or automatic register remapping | Routes, firewall rules, VPN and accepted endpoints |
Serial server | Transports serial bytes over an IP path | Modbus interpretation or TCP variant conversion unless specified | Transport mode, endpoint software and serial settings |
Protocol gateway | Interprets a supported source variant and generates a supported destination variant | Universal PLC support or cloud compatibility | Conversion direction, roles, unit identifiers and point mapping |
Why Modbus Gateways/Routers Are Essential
Gateways become useful when an approved design needs serial-to-TCP conversion, documented polling and aggregation, or a supported interface to an upstream application. Routing, firewall policy and a VPN can provide a controlled network path between sites. Segmentation and availability still depend on the complete design; a gateway does not automatically isolate every failure or secure an otherwise exposed controller.
Wavetel Solution Selection and Scope
Capabilities to Verify
For a Wavetel project, first separate the required networking role from the required data-acquisition role. Check the exact router or gateway model, serial and Ethernet interfaces, firmware options, client/server roles, supported conversion direction and mapping limits. If MQTT, HTTP or a cloud service is required, verify the payload, credentials, reconnect behavior and platform compatibility in that product configuration rather than assuming them from the product category.
Evaluate environmental limits, power input, recovery behavior and remote-management operations against the installation. A supported firewall or VPN must be configured with the site policy and tested; it is not a guarantee of secure data transmission. Back up the accepted configuration and record the software version, recovery procedure and ownership of future changes.
Wavetel IoT Modbus Gateway Application Scenarios
The following are design examples for selecting and testing a suitable Wavetel configuration. They describe responsibilities and acceptance evidence, not a claim that every Wavetel router performs protocol conversion or cloud aggregation.
Application | Project need | Possible configured role | Acceptance evidence |
|---|---|---|---|
Water monitoring | Read distributed flow and pressure points | A suitable serial/TCP acquisition device with an approved WAN path | Known-point readings, timestamps, recovery and protected local pump control |
Factory supervision | Collect agreed points from different PLCs | Supported protocol interfaces and explicit per-controller mapping | Correct values and units, bounded load and documented access rights |
Energy metering | Collect meter readings for an energy application | Supported polling and upstream delivery if implemented by the selected model | Meter map, collection schedule, missing-data handling and application receipt |
Integrating Modbus Gateway/Router into Sensor-PLC-IoT Systems
A practical integration follows four responsibilities: the sensor produces a signal; the PLC validates, scales and uses it; a configured client or gateway reads only the agreed points; and the network carries approved traffic to SCADA or another application. A Modbus server may expose holding registers, input registers, coils or discrete inputs as the project requires. Do not force every value into a holding register or require a separate router where the topology does not need one.
Stage | Configuration task | Evidence before expanding |
|---|---|---|
Sensor and PLC | Verify wiring, scaling, local logic and the agreed readable point | PLC view matches a known measurement and documented unit |
Modbus endpoint | Set supported variant, client/server role, address convention and network/serial settings | One documented read succeeds with the intended function code |
Gateway and network | Configure only the required conversion, mapping, polling and approved remote path | Correct source/destination values, bounded load and outage recovery |
Application | Map the accepted value into SCADA or a supported upstream interface | Timestamp, unit, quality state, access permissions and end-to-end receipt |
Use the configuration table as a handover checklist. Choose an update schedule from device limits and application needs, then test it under realistic load. A cloud subscription or dashboard is only the last step after the protocol and data interpretation are known to work; it is not evidence that the PLC-side measurement is correct.
Build a Point Map Before Polling
For each value, record the source and its interpretation before configuring an application:
Field | Example of what to record |
|---|---|
Source | Sensor tag and the PLC input or data point that represents it |
Protocol endpoint | Device model and firmware, client/server role, and RTU/ASCII/TCP variant |
Modbus request | Data group, function code, manual reference, and client address or offset convention |
Value interpretation | Data type, signedness, byte and word order, scale, and unit |
Access and timing | Read-only or writable permission, expected update behavior, and polling interval allowed by the device/application design |
Register labels such as 40001 are not guaranteed to be the exact numeric address a client should send. Check both the device manual and the client software's address convention.
Start with one documented read-only point. Compare the response with a known value and confirm the units and scaling before adding more registers or allowing writes. This helps separate a transport problem from an address or data-format problem.
Keep the Control and Monitoring Paths Clear
Decide which system is responsible for control and which one is collecting or presenting data. A monitoring gateway or remote platform should not be assumed to own the PLC's control function. Specify which traffic is permitted, who can write values, and what the system should do when the upstream connection is unavailable.
For remote monitoring, document the network boundary, approved peers, account permissions, and logging path. NIST's Guide to Operational Technology Security provides broader guidance for planning OT network segmentation, access, and monitoring. Apply the site's own security and change-control requirements to the actual topology.
Avoid adding cloud polling to a control path until the owner has defined its purpose, allowed access, and behavior during a network interruption. The desired update rate should come from the application and device documentation, not a generic example value.
Keep local control ownership explicit when adding remote data collection.
Commission in a Small, Observable Sequence
Verify the sensor signal or digital interface at the PLC and confirm the value and unit in the PLC project.
Confirm the Modbus endpoint, variant, roles, address convention, and supported function code from the current manuals.
Read one known point without writes and compare the returned value with the PLC's local view.
Add points in small groups and monitor response time, timeouts, and device load under the intended polling schedule.
Test the approved network path and access policy, then record what happens when the upstream link is unavailable.
If a PLC, drive, or SCADA value is stale or timing out, use the separate PLC/Modbus troubleshooting guide to distinguish a device-side fault from a communication-path issue. Keep the point map with the tested firmware and configuration so later changes can be compared.
Application Scenarios and an Illustrative Deployment
Application Scenarios
Manufacturing may use condition trends to support maintenance; energy systems may collect meter and generation data; building automation may supervise HVAC states; water systems may monitor pressure and flow at several sites. In every case, define the measured quantity, local control owner, freshness requirement and expected behavior during loss of communications. An alert should be based on validated data and a specified rule or analytical method.
An Illustrative Factory Retrofit
Consider an illustrative factory retrofit, not a measured customer result. An engineer first checks the vibration sensor interface and the PLC value, maps an agreed read-only point, and tests a suitable gateway or client against it. The application then stores timestamped trends and flags a defined condition for maintenance review. Loss of the WAN must not silently change the PLC control function. Compare alarms with inspection findings before claiming predictive capability.
Judge the pilot by observed data quality, request failures, freshness, recovery and maintenance usefulness. Any claim about lower downtime, fewer visits or cost savings requires a recorded baseline and a comparable observation period. Adding further machines should repeat the point-map and load checks; it should not merely copy the first machine configuration.
Conclusion
An integrated IIoT system works when the sensor interface, PLC program, Modbus data map, conversion function and IP path each have a defined job and a testable boundary. Start with one known value, preserve local control responsibility, and extend the proven design gradually. Keep model manuals, point maps, firmware and acceptance records together so the next change can be checked.
FAQ
Do all industrial sensors use Modbus?
No. The sensor may provide an analog, discrete, pulse, or digital communication interface. Check its manual and the PLC's supported input or communication modules before choosing a network protocol.
Does a PLC automatically expose every sensor value as a Modbus register?
No. The PLC project and device configuration determine which values are mapped, how they are represented, and which function codes and client/server roles are available. Verify the map in the PLC documentation.
Is a Modbus gateway the same as an IP router?
No. An IP router forwards IP packets. A serial transport device may carry bytes over IP. Protocol conversion requires an explicitly supported gateway function that handles the source and destination variants.
Is register 40001 always the first address to enter in a client?
No. It is commonly used as a human-facing reference for the first holding register, but manuals and software may expect a zero-based offset or another convention. Check both ends and verify with a documented read-only point.
Should a cloud platform poll the PLC directly?
That depends on the approved architecture and security policy. Define the network boundary, access rights, polling load, and behavior during an outage before connecting a remote service. Do not make the remote system part of the control path by implication.
