Version 1.1 · reviewed 30 August 2026
Download a 49-test master checklist and eight supporting resources that connect requirements, hardware, software, field evidence and as-left recovery. Preview everything, download without signup and adapt it to the project's controlled procedures.
Direct answer
A commissioning checklist is a controlled evidence register—not a memory aid with boxes to tick. Each test should identify its prerequisite, approved requirement, verification method, expected result, evidence, responsible owner, witness, status, exception and retest. For a PLC system, the scope normally spans document and version control, exact hardware/software identity, pre-power inspection, controlled energization, I/O and network proving, program execution, normal and failed behavior, recovery, backups and as-built handover.
This template is intentionally controls-specific. The broad search phrase also returns HVAC, building and general equipment forms, but those do not test PLC task execution, raw-to-normalized I/O, command-versus-feedback, network quality, warm restart or the identity of the running software. Add the applicable electrical, mechanical, process, cybersecurity, regulatory and safety records instead of stretching one spreadsheet beyond its competent scope.
| Checklist field | Purpose | Weak entry | Useful entry |
|---|---|---|---|
| Requirement ID | Trace test to approved intent | Motor works | FDS-MTR-014 / C&E row 23 |
| Expected result | Define pass before execution | Looks OK | Run feedback true within approved timeout; no fault |
| Evidence | Make result reproducible | Screenshot | Trend CX-052-01, event export and witness initials |
| Status | Use one controlled vocabulary | Done | Pass / Fail / Blocked / Accepted exception |
| Exception | Preserve incomplete or divergent work | Fix later | P-017, impact, owner, due date and retest link |
| As-left state | Identify what was accepted | Latest file | Uploaded project, comparison result, version and hash |
Before functional testing
Do not turn the main disconnect merely because software is ready. The responsible electrical and site teams must determine the inspection, test instruments, exposure controls, permits and sequence for the installation. The controls record should link to those approved results, confirm the exact PLC system identity and define the safe initial state before ordinary outputs can be enabled.
| Boundary | Controls check | Evidence | Progression blocker example |
|---|---|---|---|
| Document identity | Panel, drawings, I/O and network registers refer to the same system | Controlled revisions and redline log | Unknown or conflicting panel identity |
| Installed hardware | Controller, modules, power supplies, switches and interfaces match manifest | Catalogue/firmware asset record | Unsupported module or firmware chain |
| Installation | Identification, segregation, terminals and field interfaces are ready for approved inspection | Signed inspection records | Unterminated or untraceable conductor |
| Energy controls | Required permits, isolation boundaries, test roles and stop conditions are current | Site authorization reference | No authorized energization plan |
| Recovery | Pre-change PLC, HMI, drive and network baselines are recoverable | Archive, comparison and restore notes | Only unknown laptop copy exists |
| Initial state | Modes, output inhibits and equipment conditions prevent unintended operation | Pre-start state checklist | Actuator could move on power restoration |
In US general-industry servicing scope, OSHA 1910.147 defines control-circuit devices such as pushbuttons as different from energy-isolating devices and provides a specific sequence when lockout or tagout must be temporarily removed for testing or positioning. Other jurisdictions and activities differ. The commissioning sheet should reference the actual employer procedure; it should never summarize that procedure into “LOTO complete” and imply blanket permission for energized diagnosis.
Point-to-point proof
A loop check follows one signal end to end. For an input, start with an approved physical stimulus and prove the field device, junction/terminal path, module channel, raw tag, normalized application state, HMI indication and downstream consumer. For an output, prove the software command, mapped channel, field signal, device response and independent feedback. Do not use the output command as proof that the final device or process moved.
| Signal class | Stimulus / command | Observe | Failure behavior | Evidence |
|---|---|---|---|---|
| Digital input | Approved field open/closed states | Module point, raw tag, normalized state and display | Broken-wire or contradictory-state expectation | Photos/drawing reference plus timestamped tag trace |
| Digital output | Controlled command with equipment ready | Mapped point, field signal, device action and feedback | Inhibit, module fault and missing-feedback response | Command/feedback timeline and witness |
| Analog input | Traceable points across required range | Raw count, scaled unit, quality, alarm and history | Under/over-range, bad quality and stale value | As-found/as-left table and instrument reference |
| Analog output | Traceable commanded points | Command, raw output, field signal, position/value feedback | Open circuit, saturation and device fault | Command-versus-measurement table |
| Network value | Known payload and state transitions | Type, byte order, scaling, timestamp/quality and consumer | Timeout, reconnect and stale-data policy | Packet/device diagnostics and application trace |
If a channel is rewired, a range is corrected or scaling is changed, record the initial observation before correction. Then identify the authorized change and repeat the test. Replacing a failed result with the final pass hides the evidence needed to understand design drift, workmanship, later failures and whether adjacent points require review.
Nine-gate workflow
The master CSV contains 49 editable tests grouped into the gates below. It does not prescribe universal acceptance limits or a universal sequence: the approved project protocol does that. The gates make hidden assumptions visible and stop one successful demonstration from being mistaken for complete acceptance.
| Gate | Decision | Minimum coverage | Release evidence |
|---|---|---|---|
| G0 | Control the scope | Approved specification, roles, hazards, acceptance authority and change process | Signed plan and requirement trace |
| G1 | Review the design | Hardware/software manifests, drawings, I/O, networks, program structure and test cases | Resolved review record |
| G2 | Inspect before power | Installation, identification, segregation, protection, bonding and recoverable backups | Authorized pre-power release |
| G3 | Energize deliberately | Briefing, permits, supplies, diagnostics, network identity and safe initial state | Controlled energization record |
| G4 | Prove I/O and loops | Raw-to-normalized inputs, outputs, analog range, quality, timeout and as-left values | Point-to-point evidence |
| G5 | Execute FAT | Modes, sequences, failures, restart, performance, HMI and exception evidence | Witnessed factory record |
| G6 | Reconcile the site | FAT closeout, installation differences, utilities, interfaces and operating readiness | Site-ready authorization |
| G7 | Execute SAT | Installed normal, abnormal, integration and contract-specific performance cases | Witnessed site record |
| G8 | Hand over control | Temporary-condition removal, exceptions, running backups, as-builts and training | Accepted as-left package |
A hold point is a condition that prevents progression until the named acceptance authority releases it. Examples include an unapproved drawing, unresolved protective bonding result, incorrect controller identity, unavailable backup, safety-validation blocker or FAT exception that affects site energization. Record who can release the hold, what evidence is required and what downstream tests become invalid if the hold is ignored. “We needed to keep moving” is not a technical disposition.
Pass means the predefined result was observed. Fail means it was not. Blocked means the test could not be validly executed because a prerequisite or environment was missing. Accepted exception means the authorized parties knowingly accepted a documented divergence with its impact and obligations. These states should never be collapsed into “complete,” because they drive different decisions, retests and residual risk.
Download pack
CSV opens in Excel, LibreOffice and Google Sheets. Preserve revision, owner and status columns when adapting the files.
Prove behavior before site pressure
Factory acceptance should test the approved automation behavior while faults can still be injected without disrupting an installed process. Start with project identity and test readiness; execute normal modes and transitions; then prove the defined responses to missing feedback, failed sensors, lost communications, utility loss, restart and recovery. A build with no compiler errors is not evidence that the machine requirement is correct.
| Injected condition | Expected control result | Expected diagnostic | Recovery question |
|---|---|---|---|
| Start and stop together | Defined dominant condition wins | Command reason remains explainable | Is a new start required after release? |
| Permissive false before start | Run request remains blocked | Specific blocking condition is visible | Does clearing alone start equipment? |
| Feedback missing after command | Command follows approved timeout policy | First-out feedback fault with elapsed context | What reset and retry conditions apply? |
| Sensor stuck true or false | Sequence holds, degrades or stops as specified | Plausibility or timeout identifies the signal | Can recovery skip or duplicate product? |
| Network value becomes stale | Consumer uses defined stale-data behavior | Quality/timeout identifies interface and age | Is reconnect bumpless and state reconciled? |
| Controller or device power cycle | No unintended start; state follows retention policy | Startup/recovery event is retained | Which operator acknowledgement is required? |
| Output inhibited or device faulted | Command and physical state remain distinguishable | Module/device fault and missing response are visible | Is the cause cleared before reset? |
| Task exceeds timing budget | Watchdog/degraded behavior follows platform design | Task overlap or execution evidence is available | Is the root cause removed before returning to service? |
A simulator is useful for repeating command, permissive, timer, sequence and selected fault cases before FAT. It does not prove installed wiring, firmware-specific behavior, network timing, device dynamics, protection or safety. PLC Simulation Software is operated by the same publisher as this site; use its browser exercises only as preparation for the controlled vendor and physical tests in the project protocol.
Practise a fault case in the simulator →Installed-system proof
Site acceptance is not “repeat FAT with real outputs.” Reconcile what changed during shipping and installation, prove field I/O and utilities, test upstream/downstream handshakes, involve operations and maintenance, close or accept exceptions, remove temporary commissioning conditions and archive the system that is actually running. Site integration tests should identify both sides of every interface and the behavior when either side is unavailable or contradictory.
| Evidence layer | FAT can establish | SAT / SIT must establish | Still separate |
|---|---|---|---|
| Software behavior | Configured modes, sequences and injected failures | Behavior with installed devices and actual interfaces | Future untested modifications |
| I/O | Simulated or bench signal mapping | Field identity, polarity, scaling, quality and response | Electrical certification and calibration scope |
| Networks | Configured devices and laboratory fault cases | Installed topology, names, timing, load and recovery | Every future traffic or security condition |
| Process/mechanics | Modelled or substituted states | Real utility, load, sensor and actuator response | Conditions outside the approved test envelope |
| Operations | HMI and alarm behavior with test team | Role-based operator and maintenance use and recovery | Ongoing competence and procedure governance |
| Safety | Ordinary interface behavior where authorized | Reference to completed project-specific validation | Replacement for qualified safety validation |
A 24-, 48- or 72-hour run is not automatically appropriate merely because another project used it. The contract must define duration, production state, allowable stops, exclusions, restart of the clock, data source and acceptance calculation. Record the operating envelope and disturbances so an apparently successful run is not used as evidence for loads or recipes that were never exercised.
Need the workflow behind the sheets?
Read the functional design specification, cause-and-effect matrix and site acceptance test references.
When a test fails
Preserve the first symptom before resetting, forcing, downloading or cycling power. Record the test ID, time, operating state, controller/device diagnostics and last action. Then isolate one boundary at a time: requirement and identity, task and logic, I/O and network, field circuit, device/mechanics and process result. One controlled observation should eliminate a layer; random edits make the evidence weaker.
| Symptom | First observation | Next boundary | Avoid |
|---|---|---|---|
| Cannot go online | Exact controller, route, project/firmware and security state | Engineering workstation and network path | Downloading the open file to see if it connects |
| Logic visible but inert | Controller mode, task, program, main routine and call path | Enable conditions and scheduler evidence | Rewriting a rung that never executes |
| Input LED changes; tag does not | Channel diagnostics, mapping, raw tag and update quality | Terminal/wiring/device under approved procedure | Changing addresses until a bit moves |
| Output command true; device idle | Command, mapped point, module state, inhibit/force and feedback | Network, starter/drive, field circuit and mechanism | Calling the command bit “motor running” |
| Sequence stalls | Current state, transition conditions, timers and first-out fault | Sensor/process condition and requirement | Writing the next state manually |
| Restart differs from FAT | Power-cycle type, retained state, startup task and device reconnect order | Version/site environment differences | Adding retention without a recovery analysis |
| Intermittent failure | Time-correlated event, task, network, power and process data | Repeatable controlled stimulus | Resetting before collecting the first event |
Give each exception a stable ID, affected requirement and test, as-found evidence, impact, temporary condition, owner, due date, disposition, approval and retest. If the item changes hardware, logic, configuration or a setpoint, update the controlled baseline and identify which completed tests must be repeated. Never delete the failed row after the correction; link it to the passing retest.
| Disposition | Meaning | Required evidence |
|---|---|---|
| Correct and retest | Observed result did not meet approved expectation | Authorized change, new version, original case and regression pass |
| Blocked | Prerequisite or environment prevents a valid test | Blocking condition, owner, next action and rescheduled test |
| Accepted exception | Authorized parties accept a known divergence | Impact, affected scope, obligation, expiry/review and approver |
| Duplicate / not applicable | Row does not apply or is proved elsewhere | Reason and link to controlling requirement or evidence |
| Deferred scope | Work is moved to a later controlled phase | Contract/change reference, owner, entry criteria and hold-point impact |
At handover, an independent engineer should be able to identify the approved requirement, installed hardware, running software, field signal, test result and unresolved exception without reconstructing the project from email. At minimum, retain approved specifications, as-built drawings, I/O and instrument registers, network schedules, backups, FAT/SAT records, calibration/loop evidence, punch lists, training records and the final change log.
Review the pack after the first real project and send corrections through the corrections process. Versioned improvements make this asset more useful than a static checklist copied between jobs.
| Handover object | Identity to retain | Acceptance question |
|---|---|---|
| Running control software | Controller/HMI/drive/network version, project, upload/compare and hash where supported | Does the archive match what is running as-left? |
| Hardware and firmware | Catalogue, series, firmware, module slot, device identity and replacement constraints | Can a future maintainer identify a compatible replacement? |
| Engineering records | Approved and as-built drawings, I/O, instrument, cable, alarm and interface revisions | Do all tags and interfaces resolve without email archaeology? |
| Test evidence | Requirement, test ID, expected/observed, witness, data and exception links | Can an independent reviewer reproduce the acceptance decision? |
| Temporary conditions | Forces, bypasses, temporary wiring/code/accounts and approved residual exceptions | Is every temporary state removed or explicitly controlled? |
| Recovery package | Tool/OS/licence needs, credentials process, backups, restore and rollback instructions | Has recovery been assessed for the exact platform and site? |
| People and support | Role-based training, procedures, spares, warranty and escalation contacts | Can operations and maintenance recognize and respond to failures? |
If a training note, project standard or article points readers to these files, link to this versioned landing page so they also receive the use boundary, updates and corrections—not an orphaned spreadsheet.
https://plcprogramming.io/tools/commissioning-toolkitAnswer surface
A commissioning checklist is a controlled test register that identifies prerequisites, the requirement being proved, the verification method, expected result, evidence, owner, witness, status, exception and retest. A useful checklist is project-specific and traceable; a list of generic yes/no questions is only a starting template.
Include document and version control, exact hardware and software identity, pre-power inspection, controlled energization, digital and analog I/O checks, network and data mapping, program execution, modes and sequences, permissives and interlocks, fault injection, restart behavior, HMI and alarms, performance, backups, exceptions, training and as-built handover. Safety validation must remain a separate qualified record.
FAT proves the specified automation system at the supplier or integrator before site deployment. SAT proves the installed system at site. SIT focuses on integrated interfaces and systems. Commissioning is the broader project activity that can include inspection, loop checks, controlled energization, functional testing, startup and handover. The current ISA-105 page notes that ANSI/ISA-62381-2026 covers FAT, SAT and SIT but does not itself cover loop checks or commissioning.
No. They overlap at panel identity, supplies, protection, bonding, wiring and controlled energization, but electrical inspection and testing require their own competent-person procedures and acceptance limits. The PLC checklist continues through task and program execution, I/O meaning, data mapping, sequences, alarms, communications, failure behavior and software recovery.
Capture a recoverable baseline before controlled changes, then archive tested milestones and the final as-left running system. Record controller and tool versions, project identity, upload/compare result, included device configurations, checksums where supported and restoration instructions. A file on a laptop is not a proven backup until the applicable restore path has been assessed and tested safely.
Start from the approved I/O and loop schedule. Trace each field state through the terminal and module channel to the raw tag, normalized application value, HMI indication and historian or interface where applicable. For outputs, separate the controller command from module state, field signal, device action and independent feedback. Retain as-found and as-left values plus traceable test equipment references.
Select tests from the approved requirements and risk process. Common ordinary-control cases include simultaneous commands, missing or contradictory feedback, sensor stuck or bad quality, network timeout, utility loss, blocked downstream equipment, task overrun, warm restart, power cycle and recovery after a cleared fault. Do not invent or execute hazardous tests outside the authorized procedure.
Classify each item by impact on safety, authorization, test validity, operation, maintainability, documentation and schedule. Give it a stable ID, owner, due date, disposition, affected tests and retest evidence. The contract and acceptance authority define which items block progression; this template does not create a universal A/B/C punch-list rule.
No. Simulation can exercise logic, sequences, timer behavior, operator commands and selected failure cases before site work. It cannot validate installed power, protective bonding, field wiring, device configuration, network timing, machinery, process dynamics or safety functions. Use simulation evidence to improve FAT and SAT tests, not to claim the physical system is commissioned.
Retain approved specifications, as-built drawings and registers, exact hardware and software manifests, running PLC/HMI/drive/network backups, compare or checksum evidence, FAT/SAT/SIT and loop records, calibration evidence, alarm and interlock results, cleared or accepted exceptions, change history, training records, spares and recovery instructions. The archive should let an independent engineer identify the accepted as-left system.
Primary-source map
Reviewed 30 August 2026. These sources define their own scopes; none endorses this independent template. Public catalogue/help pages were used to identify current editions, responsibilities and platform operations. Purchase and apply the standards, manuals, contract and jurisdiction required for the actual installation.