.png)
Sensor-Fault Acceptance Tests: Specify What the System Must Do Before FAT
A factory acceptance test that proves only the normal measurement range leaves an important question unanswered: what will the complete monitoring or control system do when the measurement is no longer trustworthy? Define the fault, the expected response and the evidence before the test. Keep fault simulation inside an approved, isolated test boundary.
Original conceptual illustration; not a specific product, live software screen or customer installation.
Key takeaways
A plausible held value can hide a failed measurement path.
Specify detection, indication, downstream use and recovery separately.
A monitoring acceptance test does not certify a safety function.
1. Write an observable requirement
Sensor failed is not a complete test description. Identify the exact point and failure being assessed: invalid device status, stale communications, loss of a simulated input or another documented condition. Record which component can actually detect that condition.
For each case, specify the visible indication, its permitted detection delay and the treatment of the affected value. Decide whether trends, exports and derived calculations should carry a quality flag, stop updating or use another explicitly approved behaviour. Do not allow a hidden assumption to become the acceptance criterion.
A held last value may be useful for investigation, but it must not appear indistinguishable from a current valid reading. State how a technician will recognise its age and quality. Use the capabilities documented for the actual equipment and software revision.
2. Set a safe test boundary
NIST SP 800-82r3 emphasises the performance, reliability and safety constraints of operational technology. Apply that context when planning any test that could affect plant behaviour. Its security guidance is not a substitute for the project’s functional requirements or Australian installation obligations.
Use an approved isolated bench setup or a formally controlled commissioning arrangement. Competent people must define isolation, responsibilities and restoration checks. Do not disconnect live process instruments, force outputs or defeat protective functions simply to create a convenient fault.
Keep monitoring and safety responsibilities explicit. A standard PLC alarm, cloud notification or visualisation must not be described as a certified safety function without application-specific evidence. Safety-related design and validation belong to appropriately competent specialists.
3. A hypothetical fault-response test
Consider a non-safety-critical tank-level monitoring point in a bench simulation. The agreed requirement is that an invalid input becomes visibly invalid within an agreed project interval, is excluded from a derived daily statistic and returns to normal only after valid data is available. No particular delay is recommended here.
The test sheet records the simulator state, the controller indication, the displayed point quality and the exported result. If the screen flags a fault but an export silently retains the old number as valid, the end-to-end test has found a real gap.
Next restore a valid simulated input and observe recovery. Check whether an old fault indication remains latched, whether an acknowledgement is required by the approved design and whether a calculation resumes correctly. The intended behaviour must be documented before a pass is awarded.
Original explanatory diagram. Hypothetical values and proposed checks are described in the text; this is not a product specification or field result.
4. Record evidence at each boundary
Record the relevant hardware and software revisions, configuration baseline, point name, input condition and expected result. Use time references appropriate to the required response interval. An undated screenshot with no point identity is difficult to compare with a later retest.
Separate detection failure from presentation failure. A controller may detect invalid data correctly while a gateway drops the quality status. Conversely, an application might receive no data without the field device declaring a local fault. These cases need different corrective actions.
Agree how retests are identified. Keep the original failed result, the correction reference and the successful repeat together. Replacing the failed sheet with a clean one removes useful information about what changed.
Identify one documented failure condition and point.
Agree expected detection, indication and downstream behaviour.
Approve the isolated test and restoration boundary.
Record failure, correction and recovery evidence against the configuration revision.
5. Common omissions and handover
Avoid assuming every analogue transmitter uses the same fault-current limits. Exact thresholds, diagnostic support and receiver interpretation depend on the documented products and configuration. A generic 4–20 mA label does not establish fault handling.
Other omissions include checking only the first screen, ignoring derived values and forgetting power-up or communications recovery. Test the agreed paths without expanding into uncontrolled plant experimentation. Site acceptance still needs its own approved checks for the installed application.
Before FAT, ask the project team for a short fault-response matrix covering detection, indication, downstream data use and recovery. ProSense Solutions can discuss the monitoring and integration scope using the actual point list and available equipment documentation. Resolve unknown behaviours before ordering a test around them.
Related guide and project resources
Technical references
Need help with your application?
Send the relevant point list, equipment documentation and a sanitised example of the behaviour you need to verify. Confirm the available functions and integration requirements for the exact equipment and deployment.
