The translator between your equipment and everything else
Your equipment speaks Modbus, OPC UA, proprietary serial, or nothing polite at all; your software systems want MQTT, APIs, and structured data. An IoT gateway is the translator in between, and a well-designed one removes the mess of point-to-point integrations that otherwise accumulates until nobody can change anything.
Willowark starts gateway projects with data modeling, not hardware: defining a structured namespace of tags and assets so every consumer sees coherent, named data instead of raw register addresses. The gateway then becomes infrastructure — boring, documented, and replaceable.
IoT & Smart SystemsHow the work gets done
The same way every time: scope, build, hand over.
On the equipment side, gateways poll Modbus RTU and TCP, subscribe to OPC UA servers, read EtherNet/IP and CAN, and — when a machine speaks an undocumented serial protocol — we reverse-engineer it with a logic analyzer and a bench weekend. Upstream, data publishes over MQTT with TLS, using Sparkplug B where its birth-death lifecycle and structured namespace fit, with per-gateway certificates and managed rotation. Store-and-forward buffering rides out network outages without losing readings, and DIN-rail industrial gateway hardware with optional cellular failover keeps remote and bandwidth-poor sites connected.
Architecturally, the gateway is also a security boundary: it initiates outbound connections only, sits at the sole crossing between the OT network and everything else, and exposes equipment data without exposing equipment. Success in production is measured by data completeness through outages, clean security reviews, and how easily the next device gets added — a good gateway design turns new integrations into configuration, not projects.
Hardware is chosen from the industrial catalog before anything is built: DIN-rail gateways with the serial and Ethernet ports the equipment needs, a wide-range power input, and a temperature rating that matches the panel. A single gateway on a single machine goes in first, publishing into the namespace you have agreed on, so the data model gets tested against real register maps and real update rates before it is copied across the line. The pilot usually surfaces the untidy details — a PLC whose documentation does not match its firmware, a serial line with a wiring fault — while there is still time to correct the plan.
Because the gateway publishes to a broker you control using open protocols, every downstream consumer — historian, MES, dashboards, a data science team — subscribes to the same topics, and adding a consumer never touches the equipment side. Gateway configuration lives in version control alongside a description of every tag, its source register, scaling, units, and poll rate, so the mapping is documented rather than trapped in a web form. Handover includes the configuration repository, a per-gateway install guide with wiring and addressing, a tag reference for the people building dashboards, and a runbook for the recurring tasks: adding a device, rotating certificates, and diagnosing a tag that has stopped updating.
Scope it in writing
What we agree before work starts
- Data model and namespace design across your equipment
- Gateway hardware selection and DIN-rail deployment
Build with checkpoints
Working results, not slide decks
- Protocol integration: Modbus, OPC UA, EtherNet/IP, CAN, serial
- Secure MQTT publishing with certificate management
Hand over something you own
Documentation, source, and training
- Store-and-forward buffering with outage recovery
- Network segmentation design between OT and IT
Sound familiar?
Where iot gateways earns its keep.
Connecting legacy PLCs to modern data platforms
OEM machines reporting into a customer-facing portal
Unifying a multi-vendor production line into one namespace
Remote sites publishing over cellular with local buffering
Ask about IoT Gateways
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
Radar centering system for steel mills
Components:
- Radar sensors (strip position): Non-contact radar reading strip edge position in a hot, dusty, vibrating environment where optical sensors fail.
- Edge controller (signal processing): Turns raw radar returns into a clean lateral offset in real time.
- Mill PLC (centering actuators): The mill's existing controller: receives the offset and drives the centering actuators.
- Operator HMI (live position): Live strip position for the operator.
Connections:
- Radar sensors to Edge controller (raw returns)
- Edge controller to Mill PLC (offset)
- Edge controller to Operator HMI
A steel-mill systems provider · Steel manufacturing
Radar-based centering system for steel mills
End-to-end engineering of a radar sensing system that measures and centers material on steel mill lines — from equipment assessment through hardware selection, electrical engineering, software, installation, and commissioning.
Read the case study →Common questions
Asked before every iot gateways project.
Should we buy a commercial gateway or build a custom one?
Commercial gateways handle standard protocol translation well, and we deploy them when they fit. Custom gateways — often on industrial Linux hardware — earn their place when you need unusual protocols, local processing, tight security requirements, or behavior no configuration page offers. The data model matters more than the box either way.
Is connecting our PLCs to a network asking for trouble?
Not when the architecture is right. The gateway reads from the OT network and publishes outbound over TLS; nothing on the internet can initiate a connection inward, and the PLCs themselves are never exposed. Combined with network segmentation, this is dramatically safer than the alternative people actually do — remote desktop into an HMI.
What happens to data when the internet connection drops?
It queues. The gateway buffers readings locally — typically days of capacity — and forwards the backlog automatically when connectivity returns, so your historical data has no gaps. For sites where outages are frequent, cellular failover keeps live data flowing while the primary link is down.
Will polling the PLC slow down the machine?
Done carefully, no. Modbus and OPC UA reads use a small share of a modern PLC's communication capacity, and the gateway is configured with poll rates matched to how fast each value actually changes — a temperature every few seconds, a part counter on change, not everything at maximum rate. On older or heavily loaded controllers we measure scan-time impact during the pilot and back off if needed. The gateway only reads; it never writes to the PLC unless you specifically design for that.
How many machines can one gateway handle?
It depends on protocol, tag count, and poll rate more than on machine count. A single industrial gateway typically handles a whole line of Modbus TCP or OPC UA devices without strain; serial Modbus RTU is limited by bus speed and the number of drops, so a line of older serial equipment may need a gateway per few machines. We size gateways from the tag list and update rates gathered during the survey, and leave headroom so adding a machine later is a configuration change.
Where this sits
IoT Gateways, inside a iot & smart systems system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Field sensors report through an edge gateway to a broker; a time-series store feeds dashboards, and rules raise alerts that reach a person.
Components:
- Sensors (field): Temperature, vibration, level, current — wired or wireless.
- Edge gateway (DIN rail): Reads the sensors, buffers when the link is down, speaks MQTT upward.
- MQTT broker: Pub/sub hub; many gateways, many consumers.
- Time-series store: Every reading, retained for the trend and the audit.
- Rules engine (thresholds): Thresholds, rates of change, missing-heartbeat detection.
- Dashboard: Live and historical views.
- On-call phone: The alert reaches someone who can act.
Connections:
- Sensors to Edge gateway over Modbus
- Edge gateway to MQTT broker over MQTT
- MQTT broker to Time-series store over MQTT
- MQTT broker to Rules engine over MQTT
- Time-series store to Dashboard over REST
- Rules engine to On-call phone over push
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.