EN-GUIDE-01 · PLC EXECUTION EVIDENCE
PLC Task, Scan-Time & Watchdog Fault Evidence Before Restart
A normal average scan time does not prove adequate execution margin. Preserve task type, period, priority, watchdog, maximum execution time, overlap, events, changes and process impact on one timeline before changing settings or authorizing restart.
DECISION SUMMARY
Treat watchdog and scan symptoms as an evidence problem before treating them as a setting problem.
OBSERVABLE SYMPTOMS
Signals that justify a controlled evidence capture
- HMI response or sequential control slows only during peak production.
- A periodic task is triggered again before its previous execution has finished.
- A watchdog or major fault follows an online edit, message burst or communications change.
- The controller returns to RUN, but I/O, motion, safety, recipe or historian state is unverified.
- The proposed correction begins with a setting increase rather than a causal test.
STOP-WORK CONDITIONS
Pause the work when the boundary, baseline or final state cannot be proven.
Safety-task or process-response impact has not been assessed.
Controller identity, project baseline or task configuration cannot be verified.
Fault and overlap evidence may be cleared before export.
An online change lacks safe-state, rollback and communications plans.
A watchdog, period or priority change is proposed without an approved hypothesis and stop limit.
The test requires defeating an interlock, bypassing protection, unsafe live work or unauthorized energization.
DATA TO COLLECT
Preserve the system identity and the event context before any change.
| Evidence group | Minimum record | Why it matters |
|---|---|---|
| System identity | Site, line, equipment, controller model, firmware, operating mode | Prevents evidence from being assigned to the wrong controller or revision. |
| Project baseline | Project revision, checksum or hash, backup time, authorized baseline | Separates an as-found condition from an untracked software change. |
| Task configuration | Type, trigger, period, priority, watchdog, program and routine allocation | Defines how execution is intended to occur. |
| Task performance | Current and maximum execution, trigger interval, overlap count, status | Shows margin and recurrence that an average alone can hide. |
| Aligned events | Major/minor faults, controller events, first-out, clock source and offset | Builds a defensible cause-and-effect timeline. |
| External load | I/O update, messages, HMI, historian, network and production load | Tests whether execution symptoms follow another system load. |
| Process final state | I/O, motion, safety demand, recipe, historian and downstream impact | Prevents a controller-only restart decision. |
| Change and authority | Recent edits, approved test boundary, rollback trigger, stop limit, release authority | Links every change to control and accountability. |
DECISION GATES
Move forward only when the next gate has its required evidence.
| Gate | Required evidence | Result |
|---|---|---|
| Hold | Identity, baseline, safety or event evidence is missing. | Do not change settings or restart. |
| Analyze | Reproducible symptom and aligned evidence are available. | Test one hypothesis at a time. |
| Controlled test | Approved change, expected result, stop limit and rollback are defined. | Execute inside the authorized boundary. |
| Release | Normal, peak, fault and restart results plus as-left package are accepted. | Return to service with monitoring. |
SIX-STEP PROCEDURE
Build the evidence path in an order that preserves causality.
- 01Fix the system and safety boundary.
Identify the controller, affected task, process, hazards, permits and approval authority.
- 02Preserve the as-found baseline.
Export the project, task configuration, controller faults, performance values and synchronized process evidence.
- 03Align the event timeline.
Record clock source and offset, first symptom, controller events, HMI alarms, network load, I/O and operator actions.
- 04Separate hypotheses.
Compare one variable at a time: application execution, communications, I/O, online change, hardware, power or process load.
- 05Run an approved test.
Define expected result, stop limit, rollback trigger and observation window before changing any value.
- 06Release by final state.
Confirm controller, I/O, safety, motion, HMI, network, process and historian state; hand over as-left evidence and unresolved limits.
EXPERT REVIEW
Questions for the responsible engineer
- Is the measured maximum tied to the correct task, trigger and production condition?
- Does the proposed change alter safety response, process timing, I/O freshness or fault behavior?
- Is the time source accurate enough to align controller, HMI, network and process events?
- Can the test be stopped and rolled back before loss of control or product impact?
- Has peak-load behavior been observed, not only idle or maintenance mode?
HANDOVER PACKAGE
Leave enough evidence for the next qualified person to reproduce the decision.
- As-found and as-left controller/task configuration
- Project backup, revision, checksum or hash, and storage location
- Fault/event exports and task performance evidence
- Time-source and offset record
- Test plan, expected and observed results, failures and rollback
- I/O, motion, safety, HMI, communications and process final state
- Temporary measures, unresolved defects and monitoring window
- Names, roles, approvals, handover time and next review
OFFICIAL PRIMARY SOURCES
Manufacturer task evidence and OT operational boundaries
- Rockwell Automation - View Task Performance Details
- Rockwell Automation - Access the Task Object
- NIST SP 800-82 Rev. 3 - Guide to Operational Technology Security
These sources support terminology, task-performance evidence and the need to protect OT safety, reliability and controlled change. They do not establish a universal scan-time, watchdog or restart acceptance value. Confirm the controller revision, OEM instructions, country, site rules, authority having jurisdiction, permit, competence requirements and responsible engineer's approval.