The Principle
When troubleshooting a PLC or SCADA issue, do not accept secondhand conclusions at face value. Everyone involved — operators, other engineers, maintenance — will describe the problem through their own lens, filtered by their assumptions and experience. That is human nature, not a criticism. But it means you need to verify.
Get as Close to the Source as Possible
- Check the PLC directly. Go online with the controller. Look at the actual tag values, the actual rung states, the actual I/O status. Do not rely on someone telling you “the input is not coming in” — verify it yourself.
- Check the field device. If possible, measure the signal at the terminal strip, at the I/O card, at the transmitter. A 4-20mA signal that reads 4.2mA at the card but “should be 8mA” tells you where the problem is.
- Check the SCADA historian. Pull the trend data for the period in question. Timestamps and values do not have opinions.
- Check the event/alarm log. Look at what actually happened in sequence, not what someone remembers happening.
Common Biases to Watch For
- “It was working yesterday” — may be true, may not be. Check if anything changed (downloads, configuration edits, firmware updates, wiring work).
- “The PLC is wrong” — the PLC does exactly what it is programmed to do. If the output does not match expectations, the logic, the inputs, or the expectations are wrong.
- “Nothing changed” — something always changed. Check revision logs, recent downloads, maintenance work orders.
Practical Approach
Before forming any theory, spend 10 minutes collecting raw data: live tag values, I/O status, alarm history, and trending. Then form your theory based on what the data shows — not on what you were told.