Manufacturing software built for the plant, not the demo
On a shop floor the network drops, the tablet is worn with a glove, and a sensor slowly starts lying. Software that assumes otherwise gets switched off within a month.
What makes a plant different from an office
5 things that decide this
- 01A sensor reading is a claim, not a fact. Sensors drift over months, and a system that treats a reading as truth produces inventory numbers that are quietly wrong in one direction.
- 02Missing data and a reading of zero are different states, and conflating them either hides a real problem or invents one that is not there.
- 03Standard procedure written in a document is not standard procedure people follow. WAIQ enforces it with versioned workflows and quizzes, across manufacturing, healthcare, retail and logistics sites.
- 04Physical access is a real constraint. A device behind a locked gate cannot be restarted by your support team, so remote diagnostics and update paths are part of the build rather than a later phase.
- 05Any device installed in an area where flammable vapour may be present must be rated for it. That is a hardware decision a software team has to get right at design time.
The data looks fine until it does not
Plant software rarely fails loudly. It fails by being slightly wrong for a long time. A sensor drifts by a small amount each month, and nobody notices until a stock figure is off by enough to matter.
By then the wrongness looks like a business problem rather than a technical one. People blame the count, the shift or the supplier. The actual cause is a schema decision made in week one, when someone stored a single number with no record of how it was measured.
Keep the raw reading and the derived value apart. Hold a calibration record with dates against each device. A recalibration then reinterprets your history instead of destroying it. TankAware works this way, and it is the difference between data you can audit and data you can only hope about.
- 01Store the raw value and never overwrite it. Derived numbers are recomputed, not corrected in place.
- 02A device that has gone quiet has not reported zero. Say so in the data model.
- 03Alerts that are usually wrong train people to ignore all alerts, including the one that matters.
- ReadRaw value, device, timestamp.
- BufferThe link is down for days, not minutes.
- BackfillOriginal times kept on reconnect.
- CalibrateDrift is expected and recorded.
- TriageOne condition, one alert.
- ActA person with the authority to stop the line.
The middle four steps are what separates a telemetry project that survives its first winter from one that produces a dashboard nobody opens.
Where we are useful
Telemetry that behaves offline
TankAware streams IoT sensor data on AWS with predictive alerts, built for remote sites where connectivity drops for days. Buffering and backfill preserve the time a reading was taken.
Standard work across sites
WAIQ holds procedures under version control, walks staff through each task step by step, and confirms training with quizzes. Leaders see completion and readiness across every location.
Inspection and deficiency workflow
Scheduled checks per asset, captured offline with photos and a named signer, then a deficiency-to-work-order lifecycle that reaches outside contractors. Shipped on TankAware.
Access that matches the org chart
Five permission tiers on TankAware, with each organisation isolated. Operators, site managers and contractors need different slices of the same plant data.
An alarm that cries wolf is worse than no alarm
Alert fatigue is the defining social failure of industrial software. An alarm that is wrong most of the time teaches operators to clear alarms without reading them. Then the real one arrives and gets cleared too.
The fix is not a better model. It is refusing to put a raw device alarm in front of a person. Deduplicate, so one condition raises one alert. Suppress the patterns that are usually benign. Then track how often an alert was right, as a number you report on.
Treat a drop in that number as an incident. Teams monitor uptime religiously and let alert precision rot, which is backwards, because a system nobody believes has an availability of zero.
- One condition, one alert. Not one per poll.
- An alarm during a scheduled event is usually that event.
- Keep the original device code on every alert, so a mapping mistake stays traceable.
Systems running unattended across sites
“TankAware has revolutionized how we manage petroleum sites. The real-time data and automation have exceeded expectations.”
Blake Sutherland · President, Sutherland Excavating Ltd.
The stack behind our industrial builds
Built with
Field and device work
Security
Questions buyers ask us first
01Our line data is already in a historian. Why add software?
Because a historian records what happened and rarely tells anyone to do something about it. The value sits on top of yours. Turning a pattern into an alert somebody trusts, a work order somebody owns, and a record that survives an audit. Your historian stays the source and wins any conflict about a value.
02Can a tablet on the floor work when the network drops?
Yes, and it has to. Your app should hold the full task offline, capture results and photos, take a signature and queue the record. Timestamps belong to the moment of work, and sync time is stored separately. A shift worked in a dead zone then does not look like a late entry.
03How do you stop sensor drift from corrupting our numbers?
Store raw readings separately from anything derived, and hold a calibration record per device with effective dates. Recalibration then becomes an event that reinterprets past data rather than a correction that overwrites it. Without this, drift shows up months later as a stock discrepancy nobody can explain.
04Do you build the hardware as well?
No. We work with the devices and gateways you or your integrator select, and we raise constraints early. Anything installed where flammable vapour may be present must carry the right rating. That call belongs to your electrical engineer and the authority having jurisdiction, never to a software team.
05Can we make every plant follow the same process?
Yes, and software enforces what a document cannot. WAIQ keeps procedures under version control, guides staff through each step, and verifies training with quizzes before someone runs the task. Leaders get a live view of completion and readiness by site, which is usually the first time anyone can see the drift between plants.
06How do you price a first project with us?
Scoping calls are free. Where the work means going into your existing codebase, there is a paid two-week diagnostic. It ends in a fixed price rather than a range. We also scope a first project to be small and provable, so one line or one site proves the pattern before it is rolled out.
