IIoT sensor selection checklist
The working worksheet for choosing sensors that survive the plant and earn maintenance trust — decision first, catalogue second.
IIoT projects lose credibility at the sensor layer first.
The gateway can be installed, the connection can work, and the application can receive data — while the signal stays noisy, badly located, hard to maintain, or disconnected from any operating decision. This worksheet walks the ten checks that prevent that, anchored to ISO 17359 condition-monitoring practice.
For the full engineering reasoning behind each step, read the companion field guide: Industrial IoT Sensor Selection — from field signals to reliable decisions.
Five filters before any sensor is specified.
If a proposed signal fails one of these, defer it. A deferred sensor costs nothing; a distrusted one costs the programme.
| Selection gate | What the evidence must show |
|---|---|
| Loss exposure | Downtime, waste, quality risk, safety exposure, or maintenance uncertainty the signal can actually reduce |
| Decision owner | A named maintenance, production, quality, energy, or engineering owner who will act on the signal |
| Timing margin | Enough early warning to inspect, plan, slow down, or schedule maintenance before the cost lands |
| Field validation | A practical way for the team to compare the signal against observed equipment behaviour |
| Repeatability | A pattern that can be reused on similar assets once the first proof loop works |
The plant decides sensor life.
| Plant condition | Check before selection |
|---|---|
| Washdown or moisture | Enclosure rating, connectors, cable glands, and cleaning-chemical exposure |
| Dust, powder, or cement | Ingress protection, sensor-face buildup, and maintenance access |
| High vibration | Mounting method, cable strain relief, and connector reliability |
| High temperature | Sensor, cable, connector, and electronics temperature ratings |
| Electrical noise | Grounding, shielding, signal type, and panel routing |
| Hazardous area | Required certifications and engineering review before selection |
The ten checks, in working order.
Free to use on this page. Request the formatted PDF above for the field copy with worksheet tables and the data-contract template.
- 01
Name the operating decision the sensor must improve, and the person accountable for acting on it.
- 02
Screen the commercial case: loss exposure, decision owner, timing margin, field validation, repeatability.
- 03
Define the measured variable with its full range — normal, startup, shutdown, and abnormal states.
- 04
Set accuracy and repeatability requirements from the decision, not the catalogue page.
- 05
Check the sensor against the real environment: washdown, dust, vibration, heat, noise, hazardous zones.
- 06
Map the suspected failure mode to decision-grade signals before choosing the device.
- 07
Choose the signal and integration path — digital, 4-20 mA, pulse, IO-Link, fieldbus — to fit the acquisition layer you already run.
- 08
Write the data contract before installation: tag, asset hierarchy, unit, sampling, states, alert logic, owner, destination.
- 09
Plan the security boundary for data leaving the machine network (NIST SP 800-82 as the reference point).
- 10
Run a 90-day proof review: physical reliability, alert accuracy, action taken, trust earned, repeatable pattern.
Write the contract before the installation.
Tag, asset hierarchy, unit, sampling need, operating states, alert logic, action owner, and destination — light enough for a first project, strong enough that the signal stays readable to people outside the project team. ISO 17359 anchors the condition-monitoring method; NIST SP 800-82 anchors the security boundary when data leaves the machine network.
One asset group proves the pattern.
- Physical reliability held in the actual environment.
- Alerts matched observed asset behaviour.
- Maintenance acted within the intended workflow.
- Operators trusted the alert enough to use it.
- The pattern is clear enough to repeat on similar assets.
Questions teams ask before a sensor purchase
How do I choose an industrial IoT sensor for condition monitoring?
Start from the decision and the failure mode, not the catalogue. ISO 17359 frames selection around measurable parameters tied to known failure modes — then check environment survival, signal type, the data contract, and who owns the resulting action.
What should a sensor data contract include?
Tag name, asset hierarchy, engineering unit, sampling need, normal operating states, alert logic, action owner, and data destination. It is the metadata that keeps a signal trustworthy after the person who installed it moves on.
When should a sensor purchase wait?
When the commercial screen fails: no clear loss exposure, no named decision owner, no timing margin to act, or no practical way to validate the signal in the field. A deferred sensor costs nothing; a distrusted one costs the programme.