Two Modbus TCP Masters from One Modbus RTU Device
Case Study – Two Modbus TCP Masters from One Modbus RTU Device
Please CONTACT US for questions
Overview
Rolls-Royce Canada required secure, simultaneous access to critical fuel tank monitoring data from two independent control networks.
Their INCON TS-5000 EVO Series from Franklin Fueling Systems was integrated via Modbus RTU (RS-232) to an FS-B3510 Multiport Gateway, serving Modbus TCP to a Honeywell EBI Security System on Network N1.
A new requirement was introduced to provide the same data to a Facility Control System (FCS) PLC on a separate network (Network N2). The two networks were required to remain physically and logically isolated, and the existing security integration could not be modified.
Evaluation of the FS-B3510 confirmed that its dual Ethernet ports share a single TCP/IP stack, preventing independent serving across two isolated subnets. To meet the requirement without replacing the validated N1 integration, Chipkin implemented a two-gateway architecture that preserved segmentation and enabled independent Modbus TCP access on both networks.
Customer Goals and Challenges
Rolls-Royce Canada required the INCON TS-5000 EVO Series to serve identical Modbus data to two independent Modbus TCP masters:
- Honeywell EBI Security System (Network N1)
- Facility Control System (FCS) PLC (Network N2)
Strict network separation was mandatory. The security and facility networks could not be bridged or routed, and no modifications or downtime were permitted on the existing Honeywell EBI infrastructure.
Although the FS-B3510 Multiport Gateway includes dual Ethernet ports, technical evaluation confirmed that both ports share a single TCP/IP network stack, preventing independent serving across two isolated subnets. In addition, the INCON panel provides only one Modbus RTU serial port, and routing-based forwarding between networks proved unreliable during testing.
The challenge was therefore architectural rather than protocol-based: duplicate Modbus RTU data across two isolated TCP domains while preserving the validated security integration and maintaining deterministic communications.
Chipkin’s approach to the solution
Because the FS-B3510 Multiport Gateway cannot serve two isolated TCP networks from independent IP stacks, Chipkin implemented a two-gateway cascade architecture rather than attempting routing or firmware workarounds.
Although newer QuickServer models such as the FS-QS-3010 support dual Ethernet with independent subnets, replacing the existing gateway was not acceptable. The Honeywell EBI Security System was mission-critical, and Network N2 had to be introduced without modifying, replacing, or revalidating the existing integration on Network N1.
The FS-B3510 therefore remained in place, continuing to poll the INCON TS-5000 EVO via Modbus RTU and serve Modbus TCP to Honeywell EBI with no changes to IP addressing or configuration.
To duplicate the data, a Modbus RTU slave interface was enabled on the existing gateway. A second QuickServer was added on Network N2, connected via serial link to the first gateway. It polled the exposed register set and independently served Modbus TCP to the Facility Control System PLC on its own subnet.
This architecture maintained full isolation between Network N1 and Network N2, avoided changes to the security infrastructure, imposed no additional load on the INCON panel, and eliminated cross-subnet routing, resulting in a stable and deterministic multi-network Modbus solution.
Results and Key Takeaway
The deployed architecture provided Rolls-Royce Canada with simultaneous access to identical fuel monitoring data across two fully isolated networks. The Honeywell EBI Security System continued operating without interruption on Network N1, while the Facility Control System PLC independently accessed the same Modbus data on Network N2.
The final implementation delivered:
- Deterministic Modbus communications across two separate TCP networks
- Complete preservation of security network isolation
- No modification to the INCON TS-5000 EVO Series configuration
- No operational downtime during implementation
- A scalable architecture for future system expansion
From an engineering perspective, this project highlights a common misconception: dual Ethernet ports do not necessarily provide independent network stacks. When a gateway shares a single IP instance across ports, serving multiple isolated subnets may not be supported at the firmware or TCP/IP stack level.
In applications where strict network segmentation is required, protocol cascading through a secondary gateway can provide a controlled and supportable solution. By separating data duplication at the serial layer rather than the Ethernet layer, independent Modbus TCP serving can be achieved without introducing routing complexity or compromising system stability.
This project demonstrates how legacy gateway constraints can be addressed through architectural redesign rather than configuration workarounds, resulting in a maintainable and production-ready integration.
FAQ
Why wasn’t a single dual-subnet gateway used for this project? +
While newer gateways (e.g., FS-QS-3010) can support dual Ethernet subnets, this project required preserving the validated Honeywell EBI integration on Network N1 with no device replacement or revalidation. Chipkin therefore implemented an additive architecture that introduced Network N2 without altering the existing security infrastructure.
How were two isolated networks served with identical Modbus data? +
The INCON panel was polled by Gateway #1 (FS-B3510) over Modbus RTU (RS-232). Gateway #1 continued serving Modbus TCP to the security system on Network N1. A Modbus RTU slave interface exposed the same register set to Gateway #2 (FS-QS-3010) over a serial Modbus RTU link, allowing Gateway #2 to independently serve Modbus TCP on Network N2.
Why was cross-subnet routing not used? +
Routing-based forwarding between subnets was tested and found unreliable for this application. The final design avoided cross-subnet routing entirely and preserved deterministic behavior by duplicating data at the serial layer while maintaining strict network segmentation.
What protocols were used in this integration? +
The field device communicated using Modbus RTU over RS-232. Both upstream systems consumed data using Modbus TCP/IP on separate networks. The two gateways exchanged the register set over a serial Modbus RTU link to preserve network isolation.
Can Chipkin support similar dual-network Modbus architectures? +
Yes. Chipkin supports Modbus RTU and Modbus TCP integrations across segmented networks, including gateway cascading approaches where network isolation, deterministic polling, and minimal disruption to existing systems are required.