Choosing One Gateway SKU for Four Plants with Mixed Fieldbuses and an Unreliable 4G Backhaul
A discrete-parts plant in Suzhou needs to connect 180 CNC machines to a cloud platform. Of these, 140 expose only Modbus RTU over RS-485 at 9600 bps, 8 data bits, no parity, 1 stop bit, with a 1 s response timeout; 25 speak Modbus TCP on a flat 192.168.10.0/24 plant VLAN; the remaining 15 are older machines with pulse outputs that maintenance currently reads by hand. There is no IT staff on site, and the 4G backhaul drops for 5 to 40 minutes at shift changes. The operations manager says this is unacceptable for production-count data because the MES reconciles totals at 06:00 every day. Each machine must report spindle load every 2 seconds and raise alarm codes immediately. The customer wants to buy a single gateway model and reuse it at three other plants that have different protocol mixes, and budget caps the gateway at roughly USD 400 per unit.
1. What gateway capabilities actually decide this selection, and how should the 140 RS-485 machines and the 15 pulse-only machines be handled?
Read the worked answer
Start with bus arithmetic, not the datasheet. RS-485 at 9600 8N1 carries about 960 bytes/s. One Modbus transaction (8-byte request, 9 to 13-byte response, 3.5-character gaps and turnaround) costs roughly 30 to 45 ms on a real bus, so one segment sustains about 22 to 30 transactions/s, not the theoretical 40. Polling 140 slaves every 2 s needs 70 transactions/s, roughly three times one segment's capacity. Therefore the design needs 4 to 6 isolated RS-485 ports, or the polling period must stretch to 10 s for the non-critical tags. Group slaves by port and schedule per port.
Selection criteria in priority order: port count and isolation, protocol plugin breadth, north-bound MQTT/CoAP with store-and-forward, local rule engine, industrial temperature range, DIN rail, and a replaceable storage medium. Buying one SKU across four plants means protocol support must be a software plugin, so confirm Modbus RTU/TCP, DL/T 645, OPC UA and a scripting plugin exist or are committed before signing.
For the 15 pulse-only machines, do not replace the machines. Add a pulse-counting IO module or a small Modbus RTU counter node on the same segment, convert counts into cycles in the gateway rule engine, and record the pulse weight as a device property so it can be corrected remotely after a manual calibration count at commissioning.
2. The 4G link fails for up to 40 minutes. Size the local buffer, and state what must be true about timestamps and replay so the 06:00 MES reconciliation is correct.
Read the worked answer
Compute the load first: 180 machines reporting every 2 s is 90 records/s. At roughly 120 bytes of JSON that is about 11 kB/s, so a 40-minute outage is 2,400 s x 11 kB/s = about 26 MB, or under 10 MB in a compact binary format. An 8 GB eMMC gives large headroom, but sizing is not the real answer; policy is.
Use a ring buffer with two priorities. Alarms and state changes are never dropped. Periodic samples are dropped oldest-first once a high-water mark is reached, and the drop is logged and reported to the platform so nobody mistakes a gap for a stopped machine.
Timestamps must come from the gateway RTC synchronised by NTP while the link is up, with the estimated offset recorded, never from broker receipt time. Otherwise every replayed record lands in the wrong 06:00 bucket and production totals double-count or mis-order. Tag each record with a per-machine monotonic sequence number and replay in order, rate-limited so replay does not saturate the link or trip platform per-device quotas. To finish 26 MB well before 06:00, a replay ceiling of 200 to 500 msg/s is enough.
The stronger answer: keep production counting local over the plant LAN, and send only aggregates to the cloud, so the 06:00 reconciliation never depends on the WAN at all.
3. Which functions belong on the gateway and which in the cloud, and what quantitative case supports the split?
Read the worked answer
On the gateway: protocol conversion, deadband filtering, alarm evaluation with local latching, short-term raw retention, and aggregation. In the cloud: the asset model, long-term history, cross-plant comparison, OTA, and user and role management.
The numbers make the case. Streaming raw 2 s samples for 180 machines to the cloud is 90 msg/s, about 7.8 million messages a day, and every one of them is exposed to the 4G outages. If the gateway stores raw data in a 10-minute ring buffer and uplinks one-minute rollups plus every alarm, the daily volume becomes roughly 180 x 1,440 = 260,000 messages, a 30x reduction, and an outage no longer loses data that the cloud needs.
The 2 s cadence still has a purpose: alarm detection and local display for the line supervisor. It just does not need to travel. Keep the raw window retrievable on demand after a fault, so an engineer can pull the exact 2 s trace around an event without paying to store it forever.
Keep alarm logic on the gateway because an alarm that depends on a working WAN is not an alarm. Keep threshold changes in the cloud as desired configuration, pushed down and cached, so a plant can still protect itself while disconnected.