Industrial connectivity and machine-level analytics engineered from the signal upwards: the right sampling rate, the machine state alongside it, and a sensor you have validated before you trust the result.
Most industrial IoT disappointment traces to one of two causes, and neither is the analytics. Either the signal was sampled too slowly to contain the pattern anybody wanted to find, or the value arrived without the machine state that makes it interpretable.
This table is the feasibility conversation, and it is worth having before any platform is chosen. Two of these six cannot be solved with analytics at all.
| What you want to detect | What the signal has to support | What happens if it does not |
|---|---|---|
| Bearing and gearbox wear | High-rate vibration, consistently | Nothing. The pattern is not in the data |
| An overheating trend | Low rate is fine, a stable sensor | A calibration drift read as a trend |
| Process parameter deviation | The parameter, plus product and state | A deviation that was a product change |
| Energy waste | Sub-metering at the asset | A site total nobody can act on |
| Downtime cause | Machine state, not only output | A stop with no reason, and a guess |
| Utilisation | State plus the shift calendar | A number nobody in the plant agrees with |
Equipment with no connectivity at all
Bought before anybody wanted its data.
Machine-level visibility that stops at output
Counts, but no state and no reason.
Sensors collected inconsistently
Different rates, different units, different plants.
Legacy assets with a serial port and pride
Where the honest options are three, per section 3.
Time-series volume that surprises everybody
Because nobody decided the sampling rate.
Anomalies detected a shift later
Which is after the batch it affected.
IT and OT integration, and the cyber security question
Two mandates, and an answer nobody has written down.
Difficulty scaling IoT across multiple plants
Because the second plant’s equipment is different.
Take the thing you most want to detect and ask at what rate the signal is currently sampled. If the answer is once a minute and the phenomenon happens in milliseconds, the project is an instrumentation project and no platform will change that. Establishing this for your top three detection goals takes an afternoon with a maintenance engineer, and it prevents the most expensive kind of industrial IoT disappointment.
Industrial IoT programmes commonly start by connecting assets and then look for value in what arrives. That produces volume, cost and a dashboard nobody opens.
We start from the decision somebody wants to make, establish what signal that requires at what rate with what context, and then connect what is needed. The feasibility answer comes before the platform decision, and sometimes the answer is that the instrumentation has to change first.
Step 1
Assess the asset estate and what each machine can already provide
Step 2
Identify and prioritise the use cases from those decisions
Step 3
Establish the signal requirement per decision
Step 4
Prioritise by value against connectivity cost
Step 5
Design the connectivity route per asset class
Step 6
Design the edge and cloud split from the rate and latency
Step 7
Build ingestion with buffering and gap detection
Step 8
Normalise: units, rates, naming and the tag dictionary
Step 9
Implement sensor validation before any analytic
Step 10
Build the analytics and the alerting with the people on call
Step 11
Pilot on one asset class at one plant, measured
Step 12
Roll out by asset class, not by plant
Before connecting anything, write down the decision the data will change and who makes it. If that sentence cannot be completed, the connection will produce a dashboard rather than a decision. This single discipline is what separates the IoT programmes that survive their second year from the ones that are quietly defunded, and it costs nothing to apply.
Grouped by what each part does. The signal quality group is the one that makes the analytics trustworthy and the one most often skipped.
Connectivity and ingestion
Industrial equipment connectivity across controllers, drives, gateways and retrofit sensors
PLC, SCADA, DCS and historian connectivity, read-only, through supported interfaces
Sensor data ingestion and processing at the rates each use case requires
Edge collection with buffering, ordered recovery and gap detection
Device management and connectivity monitoring, so a silent sensor is noticed
Multi-plant rollout by asset class, with a deployment template per class, and cloud or hybrid IoT platform hosting where the estate requires it
Signal quality and context
The tag dictionary, shared with our Manufacturing Data Platform Engineering page, since both depend on it
Unit, rate and naming normalisation across plants and vendors
Sensor validation: stuck values, drift, dead channels, out-of-range and flatline detection
Machine state and context capture, which is section 2’s missing dimension
Time alignment to the platform’s time model, including device clock handling
Analytics
Real-time machine condition monitoring against validated signals
Industrial time-series analytics: trending, comparison across operating points, and signal feature extraction
Equipment anomaly detection with the alarm economics agreed in advance
Energy and utility monitoring, including compressed air and sub-metered assets
Environmental and process condition monitoring where the product requires it
Production equipment utilisation tracking, with the measure definitions owned by our Operational & Production Analytics page
Delivery and alerting
Dashboards for the people who will act, on the devices they actually use
Alerting with a defined response per alert, agreed with whoever is on call
Edge analytics and distributed processing where the rate or the latency requires it
Integration to ERP, MES and CMMS so a condition can become a work order, with the workflow on our AI Agents & Workflow Automation page
These are the common applications. The signal requirement is named for each, because that is what determines feasibility and cost before any platform is chosen.
Machine temperature and vibration monitoring
Watching the condition of rotating equipment and drives.
Equipment condition monitoring
A general view of asset health across several signals.
Production equipment utilisation
How much of available time an asset spends producing.
Energy consumption and efficiency
Where energy goes and which assets or products consume disproportionately.
Compressed air and utility monitoring
Generation, distribution and consumption of plant utilities.
Process parameter deviation detection
Detecting when the process moves away from where it should be.
Downtime event analysis
Understanding what stopped, when, for how long and why.
Environmental condition monitoring
Temperature, humidity, particulates or other conditions where the product requires them.
Asset performance across plants
Comparing the same asset class at different sites.
Measure compressed air consumption on a weekend when the plant is not producing. Whatever is flowing is being wasted. In most plants the number is larger than anybody expects, the cost per unit is already known to finance, and the fix is a maintenance task list rather than a project. It is the cheapest credible result an industrial IoT programme can produce.
We work within your existing OT architecture, vendor estate and security boundary. The protocol layer is largely determined by what your equipment speaks; the choices that matter are above it.
Sensors and instruments
Existing, retrofit, or absent. Section 3 covers the three options.
Controllers and historians
PLC, DCS, SCADA and historian, read-only.
Gateways and edge
Collection, buffering, feature computation, sensor validation.
Protocol layer
OPC UA, MQTT, Modbus and vendor interfaces, as the estate requires.
Time-series storage
Sized for the rate and the retention decision, not for everything.
Event streaming
Where consumers need the signal as it happens.
Analytics and visualisation
At the latency the decision actually requires.
Enterprise integration
ERP, MES and CMMS, so a condition can become work.
OPC UA where the equipment and historian support it, which is the preferred route and increasingly available
MQTT for gateway and sensor publishing, where a lightweight publish and subscribe model suits the topology
Modbus and vendor-specific protocols where that is what the machine speaks, usually bridged at a gateway
Historian interfaces, which hold the most history and the most tags and are often the best first source
Direct controller tag access, read-only, through the route your controls engineers support and with an agreed load budget
And secure file or batch extraction for the assets where nothing else is available, which is acceptable if the gaps are visible
Connecting plant equipment to anything creates a path that did not exist before. Two positions have to be stated before the architecture, because they determine what the rest of the controls are protecting.
Network segmentation
IT and OT separated, with one reviewable boundary component.
Secure device connectivity
Authenticated, encrypted where the protocol allows, documented where it does not.
Device identity and access
Each device known, credentialed and revocable.
Signal integrity
Sensor validation, per section 4, as a control rather than a feature.
Edge device security
Hardening and patching on a plant-realistic schedule, per section 6.
Standards alignment
Industrial cyber frameworks your security function names.
Data ownership and retention
Per tag class, with an owner and a stated period.
Remote monitoring
Where used, with access that is granted, logged and time-bounded.
Turn manufacturing data into actionable insights that improve production visibility, optimize performance, and support informed decision-making. From industrial IoT and sensor analytics to production intelligence, predictive forecasting, and business intelligence, help manufacturers identify inefficiencies, anticipate operational challenges, and drive continuous improvement.
An industrial IoT estate degrades quietly. Sensors fail, gateways drop off, certificates expire, and the dashboards keep showing something. The measures below exist to catch that rather than to describe the plant.
Sensor and device connectivity: which devices are reporting, which have gone silent, and for how long. Silence is the primary failure mode and it needs an alarm rather than a chart
Signal reliability per tag: stuck, drifting, out-of-range or noisy, from the validation in section 4
Data completeness per asset and per period, so a gap is visible rather than appearing as a quiet machine
Ingestion latency against the stated requirement for each use case
Gateway and edge health: resource use, buffer depth, restarts and firmware state
Certificate and credential expiry horizon across the device estate, per section 6
Anomaly detection performance against what the maintenance team found when they attended
ALERT ACCURACY AND FALSE ALARM RATE, which is the measure that decides whether this programme survives. A maintenance team that attends three false alarms stops attending promptly
Alert attendance time, which is the leading indicator of trust and falls before the complaints start
Alerts that were actioned and what was found, captured as a label rather than only as a disposition
Coverage: assets monitored against assets intended, with the unmonitored ones explicitly accepted rather than forgotten
Infrastructure cost per plant and per tag class, against the retention decisions in section 6
Scalability headroom: whether the infrastructure can absorb the next plant and the next asset class without a redesign
Count how many of your sensors reported nothing at all last week. In an estate of any size the answer is not zero, and in most it is unknown because silence raises no alarm. That number is the honest health measure of an industrial IoT deployment, it is trivial to produce once somebody asks for it, and every analysis built on a silent sensor is quietly wrong.
Outcomes depend on your asset estate, your existing instrumentation and which decisions you want to change. These are the changes the work is aimed at.
Equipment condition is visible on the assets that matter, at a rate that can contain what you want to detect
Every signal arrives with the machine state that makes it interpretable
A failing sensor raises an alert about the sensor rather than a false conclusion about the machine
Operating abnormalities are identified earlier, while there is still time to act, and the alert reaches somebody who will
Unplanned downtime risk falls on the assets where the lead time made intervention possible, which is the honest version of that claim
Energy and utility waste is measured, and the compressed air finding usually pays for the first phase
Downtime events carry a state transition and a reason, so the analysis is about causes rather than guesses
The alarm rate is agreed with maintenance and the attendance time is monitored
Connectivity is maintained as an estate, with silence alarmed and certificates tracked
Sampling and retention are decided per tag class, which bounds the cost deliberately
And nothing the system does writes to the plant or stands in for a safety function
Bring us one asset class and the decision you want to change, and we will establish what signal that requires, whether your equipment can provide it, what the connectivity costs, and what the sampling and retention decision should be before anything is bought.
CaliberFocus engineers industrial IoT from the signal upwards: sampling rates that can contain the phenomenon, machine state alongside every value, and sensor validation before any analytic. We read from the plant and never write back, decide sampling and retention per tag class, and agree the alarm rate with the maintenance team who will respond.
- Sampling rates set from the phenomenon you want to detect
- Machine state captured as context for every signal
- Sensor validation that alerts on the sensor, not the machine
- Read-only at the OT boundary, with nothing inbound
Security & Compliance
