IoT systems built for the plant floor, not the demo table
An IoT system connects physical equipment to software: sensors measure, edge devices collect and process, networks carry, and dashboards or applications turn the stream into decisions. What it removes is blindness — clipboard rounds, spreadsheet re-keying, and problems discovered hours after they started.
Willowark builds the whole chain, not just one link. Hardware, firmware, connectivity, backend, and dashboards are engineered together, using boring, proven components chosen for the plant floor: devices that recover from power cuts on their own, links that buffer through outages, and data models that still make sense when the system grows.
IoT & Smart SystemsHow the work gets done
The same way every time: scope, build, hand over.
A typical build starts at the signal: selecting sensors and conditioning them properly, then choosing edge hardware sized for the job. Data moves over MQTT with TLS — Sparkplug B where a structured namespace pays off — with store-and-forward buffering so a dropped connection loses nothing. Server-side, time-series data lands in TimescaleDB or InfluxDB behind dashboards in Grafana or a custom application, and every device gets a unique identity and certificate so provisioning, revocation, and over-the-air updates are manageable at fleet scale rather than heroic at unit scale.
In production, the system is judged on three things: data completeness, alert usefulness, and how little anyone has to think about it. We instrument the instruments — device health, connectivity, and buffer status are monitored alongside the process data — so a silent sensor is a ticket, not a mystery discovered during an audit. Security posture is reviewed as a design deliverable, not a checkbox.
Most deployments start as a pilot on one line or one asset class, and the pilot is engineered as the first slice of the production system rather than a throwaway. The same data model, broker, and provisioning process go in on day one at small scale, so scaling up means adding devices to a namespace that already makes sense — not rebuilding the pipeline once a few dozen nodes expose the shortcuts. A pilot also settles the questions a spreadsheet cannot: which sensors drift, where the Wi-Fi does not reach, and which alerts people act on. Those answers shape the rollout plan for the rest of the plant.
You own the data and the system. Everything lands in standard places — an MQTT broker you can subscribe to, a time-series database you can query with SQL, dashboards built on open tooling — so a future analytics platform, an ERP integration, or a different vendor can read the same stream without asking us. Firmware and backend source, device configurations, and network diagrams are handed over in a repository you control. When the project closes, your team gets a maintenance runbook covering sensor replacement, certificate renewal, and what to do when a device goes quiet, plus a walkthrough with whoever will actually be on call.
Scope it in writing
What we agree before work starts
- System architecture covering sensors, edge, network, and backend
- Edge hardware and firmware with store-and-forward buffering
Build with checkpoints
Working results, not slide decks
- Secure MQTT data pipeline with per-device identity and TLS
- Time-series database and dashboard deployment
Hand over something you own
Documentation, source, and training
- Device provisioning and over-the-air update workflow
- Fleet health monitoring and alerting
Sound familiar?
Where iot systems earns its keep.
Machine utilization and OEE data collection across a plant
Environmental monitoring in warehouses, cleanrooms, or agriculture
Tank farm and remote asset telemetry with alerting
Fleet telemetry for equipment an OEM ships to customers
Ask about IoT Systems
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 systems project.
Do we have to use the cloud, or can this run on-premises?
Either. The same architecture — MQTT broker, time-series database, dashboards — runs on a server in your rack, in your cloud account, or in a hybrid where data stays local and summaries go up. Plenty of manufacturers have good reasons to keep process data on-site, and we design for that from the start.
How do you keep an IoT deployment secure?
Per-device certificates instead of shared passwords, TLS on every link, outbound-only connections from devices so nothing listens for inbound traffic, and network segmentation between OT equipment and IT systems. Updates are signed, and the update path is designed on day one — an unpatchable device is a liability with a long life.
Can you pull data from the PLCs and equipment we already have?
Almost always. Modbus, EtherNet/IP, OPC UA, and plain serial cover most industrial equipment, and a gateway can translate those into the same pipeline as new sensors. Existing equipment usually becomes the first and cheapest data source in the system.
How long does a typical IoT deployment take?
It depends on how many distinct signal types are involved and how much of the plant network already exists. A pilot on a handful of machines with commercial sensors typically takes a few weeks from kickoff to live dashboards; a full-plant rollout with custom hardware runs longer, mostly because of installation scheduling and electrical work rather than software. We scope the pilot first, then estimate the rollout from what the pilot taught us.
What does it cost to run once it is built?
Ongoing cost has three parts: connectivity (cellular plans if used, otherwise close to nothing on your own network), hosting (a modest server on-premises or a small cloud footprint), and maintenance — sensor recalibration, battery swaps on wireless nodes, and occasional software updates. We lay these out as a line-item estimate during design so nothing surprises you, and we favor architectures with no per-device platform licensing, which is usually the cost that grows fastest as a fleet does.
Where this sits
IoT Systems, 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.