Sensor & Signal Readiness Checklist for Predictive Maintenance (Interactive)

An interactive, evidence-oriented checklist to verify sensor placement, sampling, timestamps, data completeness, labeling, access, and a quick data-acceptance test before launching predictive maintenance pilots.

Interactive Tool

Sensor & Signal Readiness Checklist for Predictive Maintenance

Use this checklist to quickly assess whether the sensor signals and supporting data infrastructure are ready to support a practical predictive maintenance pilot. Each item asks for a short yes/no or numeric response and a place to record evidence or notes. Completing the checklist helps avoid common failures caused by poor sensor placement, unsynchronised timestamps, missing data, or unclear ownership.

Check that sensors are on correct measurement points, firmly mounted, oriented correctly, and isolated from unrelated vibrations or heat sources.
Record photos, part IDs, mounting type (magnet/stud/adhesive), and any anomalies discovered.
Enter the sampling frequency recorded at the ingestion point (e.g., 1024 Hz). If the signal is event-based, enter nominal event frequency or leave blank and explain in notes.
Confirm that analogue low-pass filters or digital decimation preserve the frequency band needed to detect expected failure modes.
List expected failure frequencies, any down-sampling applied, and concerns about lost bandwidth.
Accurate timestamps are critical for aligning signals and events across equipment and systems.
Measure the largest observed difference between devices or between device and server. If unknown, enter -1 and add notes.
Include any corrective actions planned (enable PTP, tighten NTP sync, apply gateway timestamping, etc.).
Typical acceptance threshold: >95% for continuous signals. Enter integer 0-100.
Count distinct gap events (not lost samples). Use logs or historian reports where possible.
Consider whether gaps coincide with failures, shift changes, or network maintenance.
Describe root causes (network, device reboot, ingestion pipeline) and planned mitigations.
Consistent labeling simplifies model training and reduces human interpretation errors (use asset IDs, signal types, units).
Provide an example (e.g., PlantA.Line3.Motor5.VIB_X).
List missing tags, mismatches between historian and OT systems, or needed normalization rules.
Owner ownership ensures someone can investigate issues and provide context or failure history.
Enter team name, role, or person (e.g., ReliabilityEngineer.TeamA).
List roles/groups (e.g., OTAdmin, Reliability, DataScience).
Note firewall, VLAN, historian export, or permission issues preventing data access.
Quick test steps: stream 60–120s of data, visualise waveform, run a simple FFT or moving RMS, and confirm expected behavior.
Record sample screenshots, expected vs observed behaviors, and links to saved artifacts.
Use your judgment across all items. A score of 4–5 suggests proceed with a focused pilot; 1–3 suggests work on gaps first.
1.0 10.0
Be specific: e.g., remount sensor on Motor 5, enable PTP on edge gateway, normalize tag names, grant historian read access to DataScience.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.

Discussion

Comments and conversation will live here.