Get production data off the plant floor and into the cloud without losing a single reading
Machine-to-cloud integration puts live equipment data — cycle counts, temperatures, states, alarms — into cloud platforms where dashboards, analytics, and business systems can use it. It removes the situation most plants are in today: the machines know exactly what happened, and that knowledge dies at the end of the shift on a clipboard or inside a PLC nobody queries.
Willowark builds these pipelines with an OT-first mindset. We read from controllers without loading them down, we never assume the network to the cloud is reliable, and we involve your IT and controls people early because a pipeline that plant IT distrusts gets unplugged. The design goal is simple: every reading arrives exactly once, in order, with the machine and timestamp it belongs to.
Systems IntegrationHow the work gets done
The same way every time: scope, build, hand over.
A typical build pairs an edge gateway with a cloud ingestion path. The gateway speaks the plant protocols — OPC UA, Modbus TCP, EtherNet/IP, vendor-specific drivers — normalizes tags into a coherent namespace, and publishes over MQTT, often with Sparkplug B for state awareness. Store-and-forward buffering on the gateway means a dropped WAN link costs you latency, not data. On the cloud side we land readings in a time-series store, model equipment hierarchy explicitly, and expose the data through the platform you already use, whether that is AWS IoT, Azure IoT Hub, or a plain broker and database you control.
Security is structural, not bolted on: outbound-only connections from the plant, TLS with per-device certificates, and no inbound firewall rules to argue about. In production, success looks like a dashboard that agrees with the machine to the second, gap-free history through network outages, and a tag namespace tidy enough that adding machine twelve takes a configuration change, not a project.
The project begins with a walk of the floor and a tag inventory: which machines, which controllers, which tags actually carry meaning, and who on the plant side owns each one. That becomes the integration map — machine to gateway to broker to storage — with the network zone and firewall crossing marked at every hop, so IT and OT can review the same drawing. Machine vendors who lock down their controllers are common, and we work with them at the interfaces they publish: an OPC UA server, a documented register block, a data export. We do not modify vendor logic to get a reading.
Each hop is tested on its own before the chain is trusted. Gateway polling is validated against the controller on the bench or during planned downtime, then the broker path is proven with the WAN deliberately cut and restored to confirm nothing is lost. Machines are brought online in phases — usually one or two first, running for a while beside the existing manual collection so numbers can be compared — before the rest follow. The final package lists every connection, its protocol, its network path, and the person responsible for it on both the plant and cloud sides.
Scope it in writing
What we agree before work starts
- Edge gateway configuration with protocol drivers and store-and-forward buffering
- Tag namespace and equipment data model documentation
Build with checkpoints
Working results, not slide decks
- Cloud ingestion pipeline with time-series storage
- Certificate-based security setup with outbound-only network posture
Hand over something you own
Documentation, source, and training
- Data validation report comparing cloud records against machine-side truth
- Phased rollout plan with per-machine validation and outage recovery testing
Sound familiar?
Where machine-to-cloud integration earns its keep.
A plant manager who wants live OEE without walking the floor to collect whiteboard numbers
Twenty injection molding machines whose process parameters should feed a quality analytics platform
A remote pumping site that reports over cellular and must tolerate days of dropped connectivity
An OEM that wants fleet telemetry from machines already installed at customer sites
Ask about Machine-to-Cloud 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 machine-to-cloud integration project.
Will polling our PLCs for cloud data affect machine performance?
Not if it is engineered properly. We calculate the communication load before connecting anything, poll at rates the controller has headroom for, and prefer report-by-exception where the protocol supports it. On sensitive or older controllers we test the load on a bench or during planned downtime first.
Our IT department will not open inbound ports to the plant network. Is that a problem?
No — that is the posture we design for. The edge gateway makes outbound-only, TLS-encrypted connections to the broker or cloud endpoint, so nothing on the internet can initiate a connection into the plant. Most IT teams approve the design quickly once they see the data flow diagram.
Which cloud platform should we use?
The honest answer is that the edge architecture matters more than the cloud logo. We build the plant side so it publishes standard MQTT to a namespace you own, which means the cloud consumer can be AWS, Azure, an on-premises historian, or all three, and you can change your mind later without re-touching machines.
Do we need to replace our PLCs to get data to the cloud?
Usually not. Most controllers made in the last couple of decades expose their data over a protocol a gateway can read — EtherNet/IP, Modbus TCP, OPC UA, or a vendor driver — and the gateway does the translation without changing the controller. Older or fully closed machines are handled with the same non-invasive approaches we use for legacy connectivity. We identify the exceptions during the tag inventory, so any hardware change is a decision made with numbers, not a surprise.
How much data will this send, and what will the cloud cost?
That depends on how many tags you publish and how often, which is a design choice we make together rather than a default. Report-by-exception and sensible deadbands typically cut traffic substantially compared with fixed polling, and downsampling at the edge keeps high-rate signals manageable. We estimate message volume and storage before anything is deployed, and the architecture publishes to a broker you own, so the cloud consumer and its cost model can be changed later without touching machines.
Where this sits
Machine-to-Cloud 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.