Modbus, OPC UA, MQTT, EtherNet/IP — we make them agree so your systems don't have to
Protocol integration makes devices that speak different industrial languages exchange data correctly — the drive on Modbus RTU, the PLC on EtherNet/IP, the historian expecting OPC UA, the cloud expecting MQTT. It removes the islands: equipment that works perfectly alone but cannot participate in anything larger because nothing else on the network understands it.
Willowark treats protocol work as engineering, not configuration guessing. We start from the documents — register maps, EDS files, vendor manuals — and from the wire itself, capturing actual traffic before trusting any datasheet. Then we choose the bridging approach deliberately: a configured gateway when one fits, custom translation software when the mapping logic is too rich for a gateway's checkbox options.
Systems IntegrationHow the work gets done
The same way every time: scope, build, hand over.
The daily reality of this work is concrete: bridging RS-485 Modbus RTU segments onto TCP with correct timing and termination, mapping 16-bit register pairs into floats with the right word order, exposing PLC tag structures through an OPC UA server with sensible node organization, and translating between the polling world of fieldbuses and the publish-subscribe world of MQTT without inventing false freshness. Byte order, scaling factors, units, and timestamp semantics are where these projects are won or lost, so every mapping is documented field by field and verified against known values injected at the source.
Delivered properly, the result is a network where every value has one name, one unit, and one authoritative path, and where the next engineer can trace any tag from wire to database using the documentation alone. We measure success by mapping verification — every point checked end to end — and by communication statistics: error rates, retry counts, and poll timing that stay flat under production load.
Discovery is a network survey, done with a laptop, a protocol analyzer, and your maintenance people. We catalog every device, its protocol, its address, its physical layer, and the documentation that exists for it, then draw the integration map: which values need to get from which device to which consumer, and through what bridge. Vendors who publish only a partial register map or refuse to share one are a normal part of the landscape; we work at whatever interface they do document and capture the rest from the wire, keeping a record of what was observed versus what was specified.
Every bridge is verified point by point before it goes into service. A known value is set at the source — a forced register, a known meter reading, a test message — and traced through each translation to the consumer, with byte order, scaling, and units checked at each hop. Cutover happens one segment at a time, typically with the old path left running in parallel until the new one has matched it for long enough to trust. If something misbehaves, the bridge can be pulled without disturbing the devices behind it. The handover documents every connection, its addressing, and who owns each device.
Scope it in writing
What we agree before work starts
- Protocol and network assessment of existing equipment
- Gateway configuration or custom translation software
Build with checkpoints
Working results, not slide decks
- Field-by-field mapping document with scaling, units, and byte order
- End-to-end point verification report with injected test values
Hand over something you own
Documentation, source, and training
- Network documentation covering addressing, wiring, and termination
- Segment-by-segment cutover plan with parallel-run verification and rollback
Sound familiar?
Where protocol integration earns its keep.
A building full of Modbus RTU power meters that a new energy platform expects to reach over TCP
A packaging line mixing Allen-Bradley and Siemens equipment that must share interlock and status data
A SCADA migration that requires legacy serial devices to appear as OPC UA nodes
A sensor vendor's proprietary serial output that has to feed a standard MQTT namespace
Ask about Protocol Integration
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 protocol integration project.
Can't we just buy a protocol converter off the shelf?
Often you can, and when a configured gateway covers the need we will recommend one and set it up. Off-the-shelf converters struggle when the mapping requires logic — conditional scaling, combining points, handling a device's quirks — or when one side is proprietary. We pick the cheapest option that is actually correct.
Our devices are on the network but the values come through wrong. Can you fix that?
This is one of the most common calls we get, and it is usually byte order, register offset, or scaling rather than anything broken. We verify with a protocol analyzer and known injected values at the source, then correct the mapping and document it so the fix survives the next configuration change.
Does adding protocol bridges create security risk?
Any new network path deserves scrutiny, so we design with segmentation in mind: bridges live in the right network zone, expose only the points needed, and use authenticated, encrypted protocols like OPC UA with certificates or MQTT over TLS on any segment that leaves the cell. We document the data flows so your IT team can review them.
Can you integrate a protocol you have not worked with before?
Usually, yes. Industrial protocols share a small number of underlying patterns — register polling, tag browsing, publish-subscribe, framed serial — and most unfamiliar ones turn out to be a variation on one of them. We start from the specification and a wire capture, build a small proof on the bench, and confirm the mapping against known values before quoting the full job. If a protocol is genuinely undocumented and proprietary, that becomes a custom integration investigation, which we scope separately.
What does a protocol integration project typically involve for our staff?
Mostly access and knowledge. We need someone who can get us to the devices and the network, planned windows for any work that touches live equipment, and the people who know what each value actually means on the floor. Most of the engineering happens without interrupting production, since reading traffic and configuring a bridge are non-invasive. Your controls and IT staff typically review the integration map and the network changes, and we walk them through the final mapping so they can maintain it.
Where this sits
Protocol Integration, inside a systems integration 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.
A legacy machine, an ERP, a vision cell and a quality database are joined by an integration layer so the data exists once and the people who need it see it.
Components:
- Legacy machine (serial): A 1998 controller with an RS-232 port and no documentation.
- ERP: Orders, inventory, costing.
- Vision cell: Inspection results per part.
- Integration layer (the seam): Translates, validates, and stores once. This is the work.
- Unified data: One record per part, per order, per event.
- People (dashboards, alerts): Production, quality and the office see the same numbers.
Connections:
- Legacy machine to Integration layer over serial
- ERP to Integration layer over REST, both directions
- Vision cell to Integration layer over REST
- Integration layer to Unified data over SQL
- Unified data to People over REST
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.