PLC alarm history analysis means reconstructing what the available event records report, with their timing and quality limits intact. Preserve the source, timestamp meaning, signal identity, value, and quality before comparing events. Temporal order can narrow an investigation; it is not sufficient proof of causation.
Keep the fields needed to check an interpretation
A screenshot can help describe an alarm, but an export with identifiable records is usually easier to trace across an incident. Maintain a link to the original file and distinguish supplied values from anything added during analysis.
| Field | What to preserve |
|---|---|
| Source | System, asset, original file, and row or event identifier. |
| Time | Original timestamp, time zone, timestamp meaning, and known clock limitations. |
| Signal or alarm | Exact identifier and the applicable export mapping. |
| Value or transition | Reported value, units where relevant, and whether this is an event or a sampled state. |
| Quality | Raw status code plus its documented interpretation; unknown if undocumented. |
| Evidence kind | Reported signal, direct observation, approved reference, or interpretation. |
Check source time, receipt time, and clock alignment
A historian receiving a value later does not necessarily mean the underlying process changed later. The OPC Foundation’s DataValue specification distinguishes a source timestamp from a server timestamp: they describe different points in the value’s history. Preserve both when supplied and do not treat them as interchangeable.
Record which clock each source uses and whether synchronization is known. Converting two displayed times to UTC fixes a time-zone representation difference; it does not correct clock drift. If clock alignment is unknown, keep each source’s local ordering and label the uncertainty in the combined timeline.
Do not infer a precise sequence from identical timestamps. The export’s timestamp resolution may be coarser than the underlying activity. Likewise, the order of rows in a file may reflect sorting or retrieval rather than the actual order of process events.
Keep quality beside the value
The OPC UA status-code guidance distinguishes Good, Uncertain, and Bad severity. The status changes how a value should be interpreted; an unusable value must not become a confident process observation simply because it looks plausible.
Other exports can use their own quality conventions. Look up the mapping for the specific source. Do not assume that a numeric code from one export means the same thing in another. Preserve an undocumented code as unknown, and keep any gap visible to reviewers.
Distinguish duplicate imports from repeated observations
Overlapping exports may include the same event more than once. Use a stable source event identifier where available. Otherwise, agree a duplicate rule that considers the source, timestamp, signal, value, and other relevant fields, and retains a record of what was skipped.
Two identical values at different times can be meaningful repeated samples. Two alarms with the same text can be separate occurrences. Do not discard them merely because the wording matches. A quiet interval is also not proof that the machine was healthy; it can reflect missing collection or a source that only records changes.
For a worked conveyor sequence with late-arriving records, use the first-fault analysis guide and worksheet.
Separate command, state, feedback, and cause
A start request, a generated run command, a reported sequence state, and independent physical feedback answer different questions. In the Reliabotix synthetic example, the request becomes TRUE while the sequence is reported as WAIT_START and the run command as FALSE. Those records identify an area for further review. They do not establish the reason for the transition failing or prove the machine’s physical condition.
Finish the analysis with a bounded observation, competing explanations, and the next missing record. Relevant existing logic, configuration, approved references, and qualified review may still be needed. Use the incident report template to keep an unresolved hypothesis out of the verified-fix history.
PUT ONE FAULT ON RECORD
Bring the history. Start with the evidence.
Tell us which recurring fault costs your team time. A first review can start with sanitized records and no live plant connection.
Review a recurring fault ↗