Legacy PLCs often remain operational for decades because their control logic is stable, validated and closely tied to production equipment. The difficulty begins when a plant needs to connect these controllers to SCADA, MES, EMS, predictive maintenance software or cloud analytics.
From Tespro's engineering perspective, replacing a functioning PLC solely to gain modern connectivity is rarely the first option. A properly configured Multi-Protocol Industrial Gateway can preserve the existing control layer while creating a secure, structured data path between legacy equipment and modern IIoT systems.
Legacy PLC Integration Is a Multi-Layer Problem
Connecting an old PLC is not simply a matter of adding Ethernet. Engineers must resolve four separate compatibility layers:
| Integration Layer | Typical Legacy Condition | Gateway Requirement |
| Physical interface | RS232, RS485 or early Ethernet | Compatible, isolated industrial ports |
| Device protocol | Modbus RTU/TCP, BACnet or proprietary protocol | Correct client/server implementation |
| Data model | Raw registers without labels or timestamps | Data typing, scaling and normalization |
| Application interface | No native cloud connectivity | MQTT, OPC UA or HTTPS publishing |
A connection can be electrically correct while still producing unusable data. Before commissioning, the integrator must know the PLC address, serial parameters, register map, data types, byte order and permitted read/write operations.
Router, Protocol Converter or Industrial Gateway?
These devices address different parts of the integration problem.
| Device | Primary Role | Protocol Interpretation | Edge Processing | Cloud Data Publishing |
| Industrial router | Connect IP networks | Limited | Limited | Usually external |
| Protocol converter | Translate defined protocol pairs | Yes | Basic | Application-dependent |
| Multi-Protocol Industrial Gateway | Acquire, normalize, process and publish data | Yes | Yes | Integrated |
An industrial router may provide remote network access, but it does not necessarily understand what PLC register 40021 represents. A protocol converter can translate one communication format into another, but may not provide local filtering, data buffering, scripting or fleet management.
A Multi-Protocol Industrial Gateway is more appropriate when a project combines different PLCs, multiple interfaces, edge logic and several northbound systems.
How a Multi-Protocol Industrial Gateway Processes PLC Data
1. Establish the Southbound Connection
The gateway connects to the PLC through RS232, RS485 or Ethernet. Serial integration requires more than matching connectors. The following parameters must be confirmed:
• Baud rate, parity and stop bits
• PLC address or Modbus slave ID
• RS485 two-wire or four-wire configuration
• Master/slave or client/server roles
• Termination, grounding and cable length
• Polling timeout and retry limits
Interface isolation is important in electrically noisy cabinets because communication grounds, surge events and potential differences can cause intermittent faults or damage.
2. Decode the PLC Register Map
The Multi-Protocol Industrial Gateway polls only the points required by the IIoT application. Each point should be documented with:
• Register or object address
• Read/write permission
• Data length and type
• Scaling factor and engineering unit
• Valid operating range
• Sampling and reporting interval
Monitoring deployments should be read-only by default. If remote commands are required, writable points should be separately authenticated, logged and restricted to defined operating states.
3. Normalize Heterogeneous Data
Legacy PLCs frequently store values as INT16, UINT32, FLOAT32, HEX or ASCII. Two PLCs using Modbus may still represent the same measurement differently.
The gateway must therefore handle:
• Signed and unsigned value conversion
• ABCD, DCBA, CDAB and BADC byte orders
• Raw-value scaling
• Tag naming and equipment hierarchy
• Timestamp assignment
• Quality and exception codes
This normalization stage turns protocol-specific registers into consistent information that MES, EMS and cloud applications can interpret.
4. Execute Edge Rules
Sending every polled value to the cloud wastes bandwidth and complicates analytics. A Multi-Protocol Industrial Gateway can process selected data locally by applying:
• Change-of-value or deadband reporting
• Minimum, maximum and average calculations
• Threshold and equipment-state alarms
• Data aggregation
• Protocol-specific exception handling
• Event-triggered reporting
Critical interlocks and deterministic machine control should remain within the PLC. The gateway should support data integration and supervisory functions without becoming an unnecessary dependency in the primary control loop.
5. Publish Northbound Data
Normalized data can be delivered through MQTT, OPC UA or HTTP/HTTPS to SCADA, MES, EMS, an MQTT broker or a cloud platform.
The northbound specification should define MQTT topic structure, QoS, payload schema, timestamps, certificates and device identity. For OPC UA, engineers should define namespaces, node structure, security policies and client/server roles.
Designing for Unstable Networks
Industrial IIoT sites cannot assume continuous connectivity. Ethernet, Wi-Fi and cellular links may fail because of carrier outages, weak signal, damaged cabling or upstream maintenance.
A reliable Multi-Protocol Industrial Gateway deployment should define:
• Local buffering capacity
• Store-and-forward behavior
• Reconnection intervals
• Message sequencing and deduplication
• Primary and backup links
• Heartbeat and connection-status monitoring
• Recovery after power interruption
Without these rules, the cloud platform may receive incomplete, duplicated or incorrectly ordered records after a network outage.
Security Between OT and IIoT Systems
The gateway should form a controlled boundary rather than expose PLC ports directly to external networks. Recommended controls include:
• VLAN separation between control and maintenance networks
• VPN tunnels for remote connectivity
• TLS certificates for MQTT and HTTPS
• Individual user accounts and role-based permissions
• Firewall rules and service whitelists
• Disabled unused interfaces and services
• Logged configuration changes
• Controlled firmware and certificate updates
Remote access should follow least-privilege principles. Cloud applications should not receive unrestricted routes into the PLC network merely because data needs to be collected.
Tespro TG-325 as an Integration Platform
At Tespro, we designed the TG-325 Intelligent Edge Computing Gateway for projects that combine legacy serial equipment with modern wired, wireless and cellular infrastructure.
The hardware provides:
• One RS232 and two RS485 ports with 3 kV isolation
• Four configurable GPIO channels
• Two 10/100/1000 Mbps Ethernet ports
• Dual-band Wi-Fi
• 2G/3G/4G/5G connectivity
• Dual SIM/eSIM options
• 12–36 V DC input
• Fanless metal enclosure and DIN-rail or wall mounting
• −40°C to +75°C specified operating range
The TG-325 protocol environment includes Modbus RTU/TCP, BACnet, M-Bus and OPC UA, while MQTT, Azure MQTT and HTTP(S) support northbound reporting. TesproOS provides Web-based configuration, event and system logs, remote diagnostics, batch configuration and cloud firmware upgrades.
For distributed installations, VPN options, VLAN isolation, certificate management, link detection, dual-SIM switching and a built-in watchdog help maintain secure connectivity and recover from common communication faults. Exact protocol drivers and optional features should be verified against the PLC documentation and delivered firmware.
Commissioning Checklist
Before deploying a Multi-Protocol Industrial Gateway, verify:
- PLC model, firmware, interface and protocol version
- Register map, data type, scaling and byte order
- Read-only and authorized writable points
- Polling rate and acceptable PLC communication load
- Edge filtering, alarm and buffering rules
- MQTT, OPC UA or API data model
- Ethernet, Wi-Fi or cellular failover behavior
- VPN, certificates and access permissions
- Power, grounding, temperature and enclosure conditions
- Data accuracy, latency, outage recovery and remote-upgrade results
Conclusion
A Multi-Protocol Industrial Gateway allows manufacturers to retain proven PLC control systems while making their data available to modern IIoT applications. The result depends on disciplined protocol mapping, data normalization, security design and field acceptance testing—not protocol support alone.
If you are planning a legacy PLC integration, Tespro can review your PLC model, communication manual, point list, network conditions and target IIoT platform to help define a suitable TG-325 configuration and test plan before site deployment.
FAQs
Q1. Can the Tespro TG-325 connect to legacy PLCs?
Yes. The TG-325 provides RS232, isolated RS485 and Gigabit Ethernet interfaces for connecting legacy PLCs, controllers, meters and industrial instruments. Compatibility should be verified using the PLC communication manual and protocol version.
Q2. Which industrial protocols does the Tespro TG-325 support?
The TG-325 supports protocols such as Modbus RTU, Modbus TCP, BACnet, M-Bus and OPC UA. It also supports several electricity-meter and energy protocols. Available drivers should be confirmed for the delivered firmware.
Q3. Can the TG-325 convert Modbus RTU data to Modbus TCP?
Yes. The Tespro TG-325 can acquire data from Modbus RTU devices through RS485 and make the data available through Modbus TCP. Register addresses, data types, byte order and polling intervals must be configured correctly.
Q4. Can Tespro send legacy PLC data to an MQTT platform?
Yes. The TG-325 supports MQTT publishing and Modbus-to-MQTT integration. Engineers can define data points, MQTT topics, reporting intervals and server parameters according to the target IIoT platform.
Q5. Does the TG-325 support OPC UA integration?
Yes. OPC UA is included in the TG-325 protocol environment. Project planning should define whether the gateway operates as a client or server, along with node structures, certificates and security policies.
