Process data where it's produced, not where storage is cheap
Edge computing puts real processing power next to the machines producing the data, so decisions happen in milliseconds, raw data streams get reduced before they hit the network, and operations continue when the internet does not. It removes the three chronic weaknesses of cloud-only architectures on a plant floor: latency, bandwidth cost, and dependence on a connection you do not control.
Willowark right-sizes edge deployments — a fanless industrial PC, an NVIDIA Jetson for vision inference, or a hardened gateway — and designs the software so offline operation is a normal mode, not an outage.
IoT & Smart SystemsHow the work gets done
The same way every time: scope, build, hand over.
The hardware layer is chosen for the workload and the environment: fanless, wide-temperature industrial PCs on DIN rail or in panels, Jetson modules where neural network inference needs local GPU, and compute sized with real headroom. Software deploys as containers — Docker, with k3s where a small cluster warrants orchestration — so applications are versioned, portable, and updatable across a fleet rather than hand-installed. Data handling follows a consistent pattern: process locally, buffer locally in a time-series store, forward summaries and events upstream, and replay the buffer automatically after an outage so history has no holes.
Success has concrete numbers: decision latency held inside budget, upstream bandwidth cut by orders of magnitude versus raw streaming, and continuity through network failures measured in zero lost decisions. Watchdogs and automatic recovery keep unattended boxes unattended, and fleet management — health, metrics, remote updates — is part of the design, because ten edge nodes without it become ten separate maintenance problems.
Edge projects start with one node on one problem — a single line's vision inference, one cell's OEE calculation — deployed on the hardware class the fleet will eventually use. That first node settles sizing with real numbers: CPU and GPU load under actual traffic, thermal behavior inside the real panel, and how much local storage a realistic outage consumes. It also exposes the integration details that never appear in an architecture diagram, such as which PLC tags update at what rate and what the network switch in the cell actually supports. The second and later nodes are then a repeatable image and a checklist, not a new project.
We keep edge software portable and the data paths open. Applications are ordinary containers that run on any Linux host, local buffers are standard time-series or SQL databases, and upstream traffic is MQTT or plain HTTPS to a broker or API you own — so replacing a hardware vendor, moving to a different cloud, or running a node fully on-premises is configuration, not a rewrite. Power is engineered too: industrial supplies, a small UPS where clean shutdown matters, and a wiring plan the panel builder can follow. Handover includes the image build, deployment scripts, a per-node configuration inventory, and a maintenance runbook for replacing a failed unit from a spare.
Scope it in writing
What we agree before work starts
- Edge architecture defining what runs locally versus upstream
- Industrial edge hardware specification and deployment
Build with checkpoints
Working results, not slide decks
- Containerized application platform with versioned deployment
- Local buffering with store-and-forward synchronization
Hand over something you own
Documentation, source, and training
- Fleet health monitoring and remote update tooling
- Documented latency, bandwidth, and offline-operation performance
Sound familiar?
Where edge computing earns its keep.
Vision inference at the line without cloud round-trips
Local OEE and production calculations that survive outages
Preprocessing high-rate sensor data into events and features
Remote sites with unreliable or expensive connectivity
Ask about Edge Computing
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 edge computing project.
How do we decide what runs at the edge versus in the cloud?
Three tests: latency, bandwidth, and autonomy. Anything needing a fast decision, anything generating high-rate raw data, and anything that must work offline belongs at the edge. Cross-site analytics, long-term storage, and dashboards for people far from the machine belong upstream. Most systems split cleanly once you apply those tests.
Doesn't a fleet of edge devices become a maintenance burden?
Only if managed by hand. With containerized workloads, versioned images, remote updates, and centralized health monitoring, a fleet of edge nodes is administered like one system. The failure mode to avoid is artisanal boxes with undocumented configurations — which is an engineering choice, not an inherent property of edge computing.
What hardware do you deploy at the edge?
Proven industrial gear matched to the workload: fanless x86 or ARM industrial PCs for general processing, NVIDIA Jetson where GPU inference is needed, hardened gateways for lighter duty. Selection weighs temperature range, mounting, I/O, and long-term availability — a consumer mini-PC in a hot panel is a scheduled failure.
Can edge nodes run machine learning models, and who maintains them?
Yes — on-device inference is one of the main reasons to deploy edge hardware, and a Jetson or a capable x86 box handles most vision and anomaly-detection models comfortably. Maintenance is the part to plan for: models drift as products, lighting, and processes change, so the deployment includes a way to log inputs and predictions, retrain on your side or ours, and roll a new model out through the same versioned container pipeline as any other software update.
Can we host this ourselves, with nothing going to the cloud?
Yes. Fully on-premises edge deployments are common in plants with strict data policies or no reliable internet, and nothing in the architecture requires a cloud account: the broker, databases, dashboards, and fleet management tooling all run on a server in your rack. The trade-off is that your IT team takes on backups and server maintenance, and remote support from us needs an access path you control, such as a VPN you can switch off. We document both options and let you choose.
Where this sits
Edge Computing, 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.