Search Knowledge Base Articles

Controls Commissioning, Functional Testing & Production Validation

CE-SOP-007 — CONTROLS COMMISSIONING, FUNCTIONAL TESTING & PRODUCTION VALIDATION

Department: Engineering – Electrical Controls & Automation
Document Type: Standard Operating Procedure
Document ID: CE-SOP-007
Revision: Rev. 1.0
Status: Active Standard
Process Owner: Electrical Controls Engineering
Related Documents: CE-SOP-001, CE-SOP-003, CE-SOP-004, CE-SOP-005, CE-SOP-006

1. PURPOSE

The purpose of this Standard Operating Procedure is to establish a controlled, repeatable, documented process for commissioning controls and automation systems before release to production.

Commissioning shall verify that the implemented system:

Matches approved requirements
Operates as designed
Responds correctly to operator commands
Processes field inputs correctly
Controls outputs correctly
Enforces permissives
Enforces interlocks
Generates required alarms
Handles faults appropriately
Recovers appropriately
Communicates correctly
Performs correctly under actual production conditions

The fundamental principle is:

DO NOT ONLY TEST WHETHER THE MACHINE WORKS.

TEST WHETHER IT FAILS CORRECTLY.

2. SCOPE

This SOP applies to commissioning involving:

PLC program modifications
HMI modifications
SCADA changes
New I/O
New sensors
New actuators
Valves
Solenoids
Motors
VFDs
Servo systems
Alarm additions
Sequence modifications
Interlock modifications
Permissive modifications
Bypass logic
Industrial network changes
Remote I/O
Hardware replacements
Hardware upgrades
Software upgrades
New equipment
Existing equipment modifications
Vendor/integrator modifications

Testing depth shall be proportional to project complexity and risk.

3. COMMISSIONING PRINCIPLE

Commissioning answers:

DID WE BUILD WHAT WAS REQUESTED?

DOES IT OPERATE CORRECTLY?

DOES IT FAIL CORRECTLY?

CAN THE OPERATOR UNDERSTAND IT?

CAN MAINTENANCE TROUBLESHOOT IT?

CAN THE SYSTEM RECOVER?

IS IT READY FOR PRODUCTION?

Commissioning is not simply watching the machine run once.

4. COMMISSIONING WORKFLOW

The standard workflow is:

ENGINEERING DEVELOPMENT COMPLETE

↓

OFFLINE VERIFICATION

↓

PRE-COMMISSIONING REVIEW

↓

SAFE WORK CONDITION

↓

PHYSICAL INSPECTION

↓

POWER / COMMUNICATION CHECK

↓

I/O CHECKOUT

↓

MANUAL FUNCTION TEST

↓

SEQUENCE TEST

↓

AUTO MODE TEST

↓

INTERLOCK TEST

↓

PERMISSIVE TEST

↓

ALARM TEST

↓

FAULT / FAILURE TEST

↓

RESET / RECOVERY TEST

↓

HMI VALIDATION

↓

PRODUCTION TEST

↓

REQUIREMENTS VERIFICATION

↓

PUNCH LIST

↓

STAKEHOLDER ACCEPTANCE

↓

RELEASE TO PRODUCTION

↓

MONITORING

5. COMMISSIONING RESPONSIBILITY

The designated Controls Engineer is responsible for ensuring commissioning is properly planned and documented.

Other participants may include:

Operations
Maintenance
Mechanical Engineering
Process Engineering
Quality
EHS/Safety
IT/OT
Vendor
OEM
System Integrator

Not every project requires all participants.

6. COMMISSIONING RECORD

Every significant project should have a:

CE-FRM-005 — COMMISSIONING TEST RECORD

The record should include:

Project ID
Change ID
Equipment
Date
Engineer
Participants
PLC Revision
HMI Revision
Test Cases
Expected Results
Actual Results
PASS/FAIL
Comments
Corrective Actions
Retest Results
Final Acceptance

7. TEST STATUS

Each test should receive one status:

PASS

Expected behavior confirmed.

FAIL

Expected behavior not achieved.

NOT TESTED

Test not yet performed.

NOT APPLICABLE

Test does not apply.

DEFERRED

Test intentionally postponed with documented reason.

A blank field shall not be assumed to mean PASS.

8. PRE-COMMISSIONING REQUIREMENTS

Before commissioning begins confirm applicable:

☐ Project scope defined

☐ Sequence of Operation defined

☐ Functional requirements defined

☐ PLC development complete

☐ HMI development complete

☐ Electrical work complete

☐ Hardware installed

☐ PRECHANGE backup available

☐ Rollback plan available

☐ Test plan available

☐ Required drawings available

☐ Required tools available

☐ Required stakeholders notified

☐ Approved downtime available

9. PRE-COMMISSIONING SAFETY REVIEW

Before energizing or commanding equipment determine:

Who is working on the equipment?
Is mechanical work complete?
Is electrical work complete?
Are guards installed where required?
Are tools removed?
Are personnel clear?
Are required energy-control procedures satisfied?
Could unexpected motion occur?
Could valves move?
Could pressure be released?
Could heating begin?
Could conveyors start?
Could downstream equipment be affected?

Follow all applicable company safety procedures.

Commissioning does not override established safety requirements.

10. PRE-POWER INSPECTION

For new or modified hardware inspect applicable:

☐ Correct device installed

☐ Correct voltage

☐ Correct power supply

☐ Correct fuse/breaker

☐ Correct terminals

☐ Wiring secure

☐ Grounding complete

☐ Polarity correct

☐ I/O wiring correct

☐ Ethernet connections correct

☐ Device addressing correct

☐ Panel free of loose conductors/tools

Do not energize newly modified controls hardware solely because installation appears finished.

11. DRAWING-TO-FIELD VERIFICATION

Where electrical changes occurred, compare:

DRAWING

against

ACTUAL FIELD INSTALLATION

Verify:

Device tags
Terminal numbers
Wire numbers
I/O channels
Voltage
Panel location

Document discrepancies.

12. POWER-UP TEST

During initial power-up verify:

☐ Correct devices energize

☐ No unexpected trips

☐ No abnormal heating

☐ PLC powers correctly

☐ HMI powers correctly

☐ I/O modules healthy

☐ Network devices healthy

☐ Drives healthy

☐ Safety devices healthy where applicable

Stop if abnormal conditions occur.

13. PLC HEALTH CHECK

Verify:

Processor mode
Controller fault status
I/O module status
Communication status
Major/minor faults
Expected program revision
Correct controller identity

Do not begin functional testing on a controller with unexplained faults.

14. HMI HEALTH CHECK

Verify:

HMI boots
Correct application loads
PLC communication established
Startup display correct
Navigation works
No unexpected communication errors
Correct machine/application identified

15. NETWORK HEALTH CHECK

Where applicable verify:

Correct IP addresses
Correct subnet
Correct gateway
PLC communication
HMI communication
Remote I/O communication
VFD communication
Scanner communication
Managed switch health
Required device connections

Resolve duplicate IP or communication issues before functional testing.

16. I/O CHECKOUT

I/O checkout verifies the complete signal path.

For an input:

PHYSICAL DEVICE → FIELD WIRING → I/O MODULE → PLC TAG → HMI STATUS

For an output:

PLC COMMAND → I/O MODULE → FIELD WIRING → DEVICE → PHYSICAL RESPONSE → FEEDBACK

Do not verify only the PLC bit.

Verify the actual field function where safe and practical.

17. DIGITAL INPUT TEST

For each affected digital input:

Place equipment in safe test condition.
Activate physical device.
Observe input module.
Observe PLC input.
Observe mapped internal tag.
Observe HMI indication where applicable.
Release device.
Verify return state.

Record:

Device
Address
Tag
Expected State
Actual State
PASS/FAIL

18. DIGITAL OUTPUT TEST

For each affected digital output:

Establish safe test condition.
Issue controlled command.
Observe PLC output.
Observe output module.
Observe physical device.
Verify feedback where available.
Remove command.
Verify return state.

Examples:

Solenoid
Valve
Stacklight
Horn
Relay
Motor starter
Can Stop

19. ANALOG INPUT TEST

For analog inputs verify:

Raw value
Scaling
Engineering units
Minimum
Maximum
Normal operating value
Alarm thresholds
HMI display

Examples:

Temperature
Pressure
Flow
Level
Speed

20. ANALOG OUTPUT TEST

For analog outputs verify:

Command value
Raw output
Engineering scaling
Physical response
Minimum/maximum limits
Feedback where available

Use safe test values.

21. I/O POLARITY / NORMAL STATE

Confirm the program correctly interprets:

Normally Open
Normally Closed
Energize-to-run
De-energize-to-trip
Active High
Active Low

A PLC bit changing does not guarantee the logic interprets the signal correctly.

22. MANUAL MODE TESTING

Where Manual Mode exists test:

☐ Entry into Manual

☐ Manual indication

☐ Individual commands

☐ Output response

☐ Interlocks retained

☐ Required permissives retained

☐ Exit from Manual

☐ Outputs return to expected state

☐ Transition back to Auto

Manual operation shall not unintentionally defeat required protections.

23. AUTO MODE TESTING

Verify:

Auto selection
Auto indication
Required permissives
Startup sequence
Normal sequence
Timers
Counters
Device commands
Feedback
Alarm behavior
Shutdown
Restart

Run enough cycles to establish confidence.

24. MODE TRANSITION TESTING

Test transitions where applicable:

Disabled → Auto
Auto → Disabled
Auto → Manual
Manual → Auto
Faulted → Reset
Maintenance → Auto
Bypass → Normal

Verify transitions do not create unexpected output behavior.

25. SEQUENCE TESTING

Test the Sequence of Operation step-by-step.

For each step record:

Sequence Step
Trigger
Expected Action
Actual Action
PASS/FAIL

Do not rely solely on observing the final result.

26. TIMER TESTING

For every affected timer verify:

Start condition
Timing behavior
Preset
Done condition
Reset condition
Retentive/non-retentive behavior where relevant
HMI adjustment
Min/max limits

Example:

Requirement: Jam condition after five seconds.

Test:

Block sensor.
Verify timer starts.
Clear at four seconds.
Verify timer resets.
Block again.
Hold greater than five seconds.
Verify jam triggers.

This tests both sides of the threshold.

27. COUNTER TESTING

Verify:

Correct event increments count
Event does not double-count
Preset behavior
Reset behavior
Retention
HMI display
HMI reset security where applicable

28. PERMISSIVE TESTING

For each permissive:

Establish normal condition.
Verify operation permitted.
Remove permissive.
Attempt operation.
Verify operation is prevented.
Restore permissive.
Verify expected recovery.

Examples:

Air Pressure OK
Downstream Ready
Drive Healthy
System Enabled

29. INTERLOCK TESTING

For each interlock:

Establish normal operation.
Create or simulate interlock condition where safe.
Verify expected action.
Verify HMI indication.
Clear condition.
Verify reset/recovery.

An interlock is not proven merely because its contact exists in ladder logic.

30. ALARM TESTING

For each new or modified alarm verify:

☐ Correct trigger

☐ Correct delay

☐ Correct alarm message

☐ Correct severity

☐ Correct horn behavior

☐ Correct stacklight behavior

☐ Correct acknowledgment

☐ Correct clear condition

☐ Correct reset behavior

☐ Alarm history where applicable

31. ALARM MESSAGE VALIDATION

The displayed alarm should accurately identify:

WHAT HAPPENED

and where useful:

WHAT THE OPERATOR SHOULD DO

Poor:

FAULT 27

Better:

Line 5 Infeed Jam

Better still:

Line 5 Infeed Jam – Clear Product From Infeed Photo Eye and Press Reset

32. RESET TESTING

Test reset under:

VALID RESET CONDITION

System should reset.

INVALID RESET CONDITION

System should remain faulted.

Example:

If a photo eye must clear before reset:

Create jam.
Keep PE blocked.
Press Reset.
Verify reset rejected.
Clear PE.
Press Reset.
Verify successful recovery.

33. HMI PUSHBUTTON TESTING

For each affected button verify:

Correct tag
Correct action
Press behavior
Release behavior
Momentary/latch behavior
Security
Interlocks
Feedback

Examples:

Start
Stop
Reset
Manual command
Set On
Set Off
Toggle
Mode selection

34. HMI INDICATOR TESTING

Verify indicators correctly represent:

Input status
Output status
Mode
Fault
Alarm
Interlock
Permissive
Communication
Equipment status

Avoid indicators that show only a command when operators believe they represent physical feedback.

35. HMI NUMERIC ENTRY TESTING

For adjustable values verify:

☐ Correct tag

☐ Engineering units

☐ Decimal places

☐ Minimum

☐ Maximum

☐ Default

☐ Security

☐ PLC receives value

☐ Value persists appropriately

Attempt values outside the permitted range.

Verify they are rejected or limited appropriately.

36. HMI NAVIGATION TESTING

Verify:

Main navigation
Back buttons
Home buttons
Popup displays
Diagnostic screens
Alarm screens
Trend screens
Screen security
No dead-end displays

37. HMI COMMUNICATION-LOSS TEST

Where practical determine behavior when HMI communication is lost.

Verify:

Operator receives indication
PLC continues appropriately
Unsafe commands are not retained
Communication restores correctly

The HMI should not be the sole location of critical control logic.

38. FAILURE MODE TESTING

Testing should include reasonable abnormal conditions.

Examples:

Sensor remains blocked
Sensor does not activate
Feedback missing
Motor does not run
Valve fails to confirm
Downstream not ready
Communication unavailable
Operator requests invalid action

The objective is not to damage equipment.

The objective is to prove expected fault handling.

39. SENSOR STUCK-ON TEST

Where relevant:

Simulate/maintain active sensor.
Observe timer/fault behavior.
Verify output response.
Verify alarm.
Verify reset restrictions.
Restore normal signal.
Verify recovery.

40. SENSOR STUCK-OFF TEST

Where relevant:

Prevent expected sensor signal.
Run sequence to expected point.
Verify timeout/fault.
Verify equipment stops or transitions appropriately.
Verify alarm.
Restore signal.
Verify recovery.

41. OUTPUT FAILURE TEST

Where safe and practical simulate:

Output commanded but feedback absent.

Verify:

Timeout
Alarm
Sequence response
Operator diagnostics
Reset/recovery

This is especially valuable for valves, motors, and actuators with feedback.

42. COMMUNICATION FAILURE TESTING

Where practical test loss of communication with affected devices.

Examples:

Remote I/O
VFD
Scanner
PLC-to-PLC communication
Gateway

Verify:

Communication fault detected
Appropriate alarm generated
Equipment response appropriate
Communication recovery works

Do not intentionally disrupt plant-wide networks without proper authorization and planning.

43. POWER LOSS / RECOVERY TEST

Where appropriate verify behavior after power interruption.

Determine:

What states return?
What modes return?
Are latched commands retained?
Are counters retained?
Are setpoints retained?
Does equipment automatically restart?
Is operator action required?

Unexpected automatic restart is a critical commissioning concern.

44. PLC RESTART TEST

For appropriate systems verify:

Processor returns to correct mode
I/O reconnects
communications restore
sequence initializes correctly
outputs assume appropriate states
alarms behave correctly

Do not perform unnecessary processor cycling on production systems where risk outweighs benefit.

45. HMI RESTART TEST

Where appropriate:

Restart HMI.
Verify application launches.
Verify correct startup display.
Verify PLC communication.
Verify navigation.
Verify alarms.
Verify setpoints.
Verify security.

46. VFD TESTING

For modified VFD systems verify:

Start
Stop
Direction
Speed reference
Minimum speed
Maximum speed
Acceleration
Deceleration
Fault status
PLC communication
HMI status
Recovery

Confirm motor rotation before full production operation.

47. VALVE / SOLENOID TESTING

Verify:

Command
Output
Physical movement
Open/closed state
Feedback
Interlocks
Failure behavior
Alarm
Manual control
Auto control

For process valves, confirm correct process consequences before commanding.

48. BYPASS TESTING

If a bypass is part of the approved design verify:

Activation method
Authorization
HMI indication
Warning/alarm
Exact function bypassed
Functions NOT bypassed
Exit behavior
Power-cycle behavior
Auto/Manual interaction

A bypass test must confirm that it does not bypass more than intended.

49. STACKLIGHT TESTING

Verify applicable:

GREEN

Normal/running condition.

AMBER

Warning/attention condition.

RED

Fault/serious condition.

HORN

Immediate attention where required.

Verify combinations and priority behavior where multiple conditions exist.

50. REQUIREMENTS TRACEABILITY

Each Functional Requirement should link to one or more test cases.

Example:

FR-001:
System shall detect infeed blockage >5 seconds.

TC-001:
Block infeed PE >5 seconds.

Expected:
Jam condition activates.

Result:
PASS

This provides direct traceability:

REQUIREMENT → TEST → RESULT

51. TEST CASE FORMAT

Recommended:

Test ID: TC-001

Requirement: FR-001

Description: Verify infeed jam timer.

Preconditions: System in Auto; no existing fault.

Test Steps:

Block PE.
Maintain blockage >5 seconds.

Expected Result: Jam alarm and Can Stop activate.

Actual Result: ______

Status: PASS / FAIL

Tested By: ______

Date: ______

Evidence: ______

52. TEST EVIDENCE

Where beneficial attach:

Screenshots
Photos
Trend captures
PLC screenshots
HMI screenshots
Alarm history
Test measurements
Video
Data logs

Not every test requires evidence attachment.

Use evidence proportional to project significance.

53. FAILED TEST

If a test fails:

Mark FAIL.
Document actual behavior.
Identify cause.
Correct issue.
Record modification.
Retest.
Record new result.

Do not erase the original failed result simply because the problem was later corrected.

The test history provides useful engineering evidence.

54. RETEST

Record:

Original Test: FAIL

Corrective Action: Modified reset permissive.

Retest: PASS

Date: ______

Engineer: ______

This preserves traceability.

55. PUNCH LIST

Issues discovered during commissioning should enter a Punch List.

Fields:

Punch ID
Description
Severity
Owner
Date Identified
Required Action
Due Date
Status

Classify:

CRITICAL

Must resolve before production release.

MAJOR

Significant issue requiring resolution.

MINOR

May be deferred with documented acceptance.

56. STOP CONDITIONS

Stop commissioning if:

Unsafe behavior occurs.
Unexpected motion occurs.
Wrong controller/program identified.
Critical interlock fails.
Critical permissive fails.
Rollback capability is lost.
Production conditions prevent safe testing.
Electrical problem exists.
Hardware behaves unexpectedly.
System becomes unstable.
Scope materially changes.

Investigate before continuing.

57. ROLLBACK DECISION

Rollback should be considered when:

Critical tests fail.
Approved downtime is nearly exhausted.
Unexpected system behavior cannot be quickly explained.
Production cannot safely resume.
New logic causes unrelated failures.
Communication becomes unstable.
Quality requirements cannot be met.

Reference:

CE-SOP-004 – Controls Change Management

58. DRY RUN

Where possible perform a Dry Run before actual production.

A Dry Run may involve:

No product
Water instead of process material where appropriate
Manual simulation
Controlled sensor activation
Empty conveyor
Offline machine cycle

Dry runs reduce production risk.

59. PRODUCTION VALIDATION

After dry testing succeeds, test under actual production conditions.

Verify:

Product detection
Cycle timing
Throughput
Machine interaction
Upstream coordination
Downstream coordination
Alarm behavior
Operator interaction
Quality

Some issues only appear under real production conditions.

60. MULTIPLE-CYCLE TEST

Where appropriate require multiple successful cycles.

Example:

Acceptance Requirement:

Machine shall complete:

10 consecutive normal production cycles

without controls-related fault.

The required number depends on the process.

61. PRODUCT / FORMAT VARIATION

If equipment runs multiple:

Products
Recipes
Formats
Sizes
Speeds

determine whether each affected configuration requires testing.

A change working for one SKU does not guarantee it works for another.

62. STARTUP VALIDATION

Verify behavior from normal startup condition.

Do not test only after the engineer has manually placed the machine into an ideal state.

The operator must be able to start it normally.

63. SHUTDOWN VALIDATION

Verify:

Normal Stop
Controlled shutdown
Device state
Timer reset
Sequence reset
HMI status
Restart readiness

64. FAULT RECOVERY VALIDATION

Create representative fault.

Then verify:

Fault detected.
Equipment responds correctly.
Alarm appears.
Operator clears cause.
Reset becomes available.
Reset clears appropriate fault.
System returns to correct state.
Production resumes normally.

Recovery is part of the function.

65. OPERATOR VALIDATION

Have an appropriate operator use the modified function.

Ask:

Is operation understandable?
Are controls intuitive?
Are alarms understandable?
Is reset clear?
Are indicators meaningful?
Does anything interfere with normal operation?

Engineering understanding alone is not sufficient for operator-facing functionality.

66. MAINTENANCE VALIDATION

For significant modifications review with Maintenance:

New hardware
New I/O
New diagnostics
New alarms
New interlocks
New permissives
New network devices
Troubleshooting expectations

Maintenance should understand the system before the first failure.

67. QUALITY VALIDATION

Where the modification can affect product quality, involve appropriate Quality personnel.

Verify applicable:

Process values
Reject logic
Timing
Recipes
Temperature
Pressure
Product detection
Traceability

Controls commissioning does not replace required Quality approval.

68. SAFETY VALIDATION

Safety-related modifications require applicable formal safety validation.

Do not treat standard commissioning documentation as a substitute for required machine-safety validation procedures.

69. RELEASE TO PRODUCTION GATE

A system may be released when applicable:

☐ Critical tests PASS

☐ I/O verified

☐ Sequence verified

☐ Auto verified

☐ Manual verified

☐ Interlocks verified

☐ Permissives verified

☐ Alarms verified

☐ Reset verified

☐ HMI verified

☐ Failure behavior verified

☐ Recovery verified

☐ Production test successful

☐ Critical Punch List items closed

☐ Stakeholders accept release

70. CONDITIONAL RELEASE

A system may occasionally return to production with minor open items.

Requirements:

No unacceptable safety risk
No critical functional failure
Item documented
Owner assigned
Due date assigned
Stakeholders informed
Follow-up planned

Do not use conditional release to normalize unfinished critical engineering work.

71. RELEASE RECORD

Record:

Equipment: ______

Project: ______

PLC Revision: ______

HMI Revision: ______

Commissioning Result: PASS / CONDITIONAL / FAIL

Released By: ______

Operations Acceptance: ______

Date/Time: ______

Open Items: ______

72. POST-COMMISSIONING BACKUP

Immediately following successful commissioning:

CAPTURE THE ACTUAL RUNNING CONFIGURATION.

Complete:

☐ PLC POSTCHANGE backup

☐ HMI POSTCHANGE backup

☐ Drive configuration where applicable

☐ Network configuration where applicable

☐ Revision update

☐ Change Log update

Reference:

CE-SOP-006 – PLC/HMI Backup, Version Control & Disaster Recovery

73. POST-COMMISSIONING MONITORING

Move project status to:

MONITORING

Observe applicable:

Fault frequency
Alarm frequency
Operator feedback
Reset activity
Downtime
Product quality
Timing
Communication
Unexpected behavior

Recommended significant-project observation:

24–72 hours of meaningful production operation

or an appropriate number of production cycles.

74. COMMISSIONING CLOSEOUT

Before commissioning is considered complete:

☐ Test Record complete

☐ Failed tests resolved or dispositioned

☐ Retests documented

☐ Punch List created

☐ Critical Punch items closed

☐ Production validation complete

☐ Stakeholder acceptance recorded

☐ POSTCHANGE backups completed

☐ Project moved to Monitoring/Documentation

75. WEB SYSTEM — COMMISSIONING TAB

Create a dedicated:

COMMISSIONING

section containing:

GENERAL

Project ID
Change ID
Equipment
Engineer
Date
PLC Revision
HMI Revision

PRE-CHECKS

Backup
Safety
Hardware
Software
Downtime
Rollback

I/O

Inputs
Outputs
Analog
Feedback

FUNCTIONAL

Auto
Manual
Sequence
Timers
Counters

PROTECTION

Permissives
Interlocks
Alarms
Reset

FAILURE

Sensor Failure
Output Failure
Communication Loss
Power Recovery

HMI

Buttons
Indicators
Setpoints
Navigation
Alarms

PRODUCTION

Dry Run
Production Run
Cycle Test
Operator Validation

FINAL

Punch List
Acceptance
Release
POSTCHANGE Backup

76. AUTOMATIC TEST GENERATION

A powerful feature for the web system is:

REQUIREMENTS → TEST CASES

During CE-SOP-003 scoping:

FR-001

FR-002

FR-003

are created.

When project enters Commissioning, automatically generate:

TC-001

TC-002

TC-003

Each test should contain:

Requirement
Expected Result
Actual Result
PASS/FAIL
Tester
Date
Comments
Evidence

This prevents requirements from disappearing between design and commissioning.

77. COMMISSIONING COMPLETION SCORE

The system may display:

COMMISSIONING: 87% COMPLETE

Example:

Passed: 26

Failed: 1

Not Tested: 3

N/A: 4

Outstanding:

Communication-loss test
HMI restart test
Operator validation

This gives immediate project visibility.

78. COMMISSIONING DASHBOARD

Track:

PROJECTS IN COMMISSIONING

TESTS PASSED

TESTS FAILED

TESTS NOT COMPLETED

OPEN CRITICAL PUNCH ITEMS

PROJECTS READY FOR RELEASE

PROJECTS CONDITIONALLY RELEASED

PROJECTS ROLLED BACK

COMMISSIONING FIRST-PASS SUCCESS RATE

79. FIRST-PASS COMMISSIONING RATE

Future KPI:

FIRST-PASS COMMISSIONING SUCCESS

Percentage of projects completing planned commissioning without significant engineering rework.

This can reveal:

Scoping quality
Development quality
Testing quality
Requirement quality

The objective is not to punish failed tests.

A failed test discovered during commissioning is far better than a failure discovered during uncontrolled production.

80. COMMISSIONING EVIDENCE

For significant projects, preserve enough evidence to demonstrate:

WHAT WAS TESTED

WHO TESTED IT

WHEN IT WAS TESTED

WHAT RESULT OCCURRED

WHAT WAS DONE ABOUT FAILURES

This creates engineering traceability.

81. THE "OUTPUT TURNED ON" TRAP

Avoid:

"I forced the output and the valve opened, so commissioning is done."

That proves only part of the system.

Full validation may require:

INPUT

↓

LOGIC

↓

PERMISSIVE

↓

INTERLOCK

↓

COMMAND

↓

OUTPUT

↓

PHYSICAL DEVICE

↓

FEEDBACK

↓

ALARM

↓

RECOVERY

82. THE "ONE GOOD CYCLE" TRAP

One successful cycle does not necessarily prove reliable operation.

Consider:

Multiple cycles
Different products
Different modes
Restart
Fault recovery
Timing boundaries
Production speed

Test based on project risk.

83. THE "ONLY TEST NORMAL" TRAP

Normal testing answers:

Can the system work?

Failure testing answers:

Can the system protect itself when something goes wrong?

A robust commissioning process answers both.

84. THE "ENGINEER KNOWS HOW" TRAP

If the engineer can operate the system but the operator cannot:

Commissioning is incomplete.

Operator-facing systems must be understandable by the intended operator.

85. COMMISSIONING QUALITY TEST

Before release ask:

Have I tested enough of this system that I can reasonably explain what it will do when operation is normal, when a required condition is missing, and when a realistic failure occurs?

If:

continue commissioning.

86. QUICK-REFERENCE COMMISSIONING WORKFLOW

1. PREPARE

Review requirements and test plan.

2. MAKE SAFE

Establish controlled work condition.

3. INSPECT

Verify installation.

4. POWER UP

Check hardware health.

5. CONNECT

Verify communications.

6. CHECK I/O

Input-to-PLC and PLC-to-output.

7. TEST MANUAL

Verify individual commands.

8. TEST AUTO

Verify sequence.

9. TEST PROTECTION

Interlocks and permissives.

10. TEST ALARMS

Trigger, display, clear, reset.

11. TEST FAILURES

Verify abnormal conditions.

12. TEST RECOVERY

Confirm return to normal.

13. TEST HMI

Commands, status, entries, navigation.

14. RUN PRODUCT

Verify real production.

15. VERIFY REQUIREMENTS

PASS/FAIL each requirement.

16. CLOSE PUNCH ITEMS

Resolve critical findings.

17. RELEASE

Obtain acceptance.

18. BACK UP

Capture POSTCHANGE production master.

19. MONITOR

Observe production.

87. COMMISSIONING GOLDEN RULES

RULE #1

Do not commission without a known rollback path.

RULE #2

Verify the physical device—not only the PLC bit.

RULE #3

Test Manual and Auto where applicable.

RULE #4

Test interlocks by attempting the prohibited action.

RULE #5

Test permissives by removing the required condition.

RULE #6

Test alarms from trigger through recovery.

RULE #7

A Reset must not hide an active fault.

RULE #8

Test realistic failure conditions.

RULE #9

Verify mode transitions.

RULE #10

Test HMI limits and invalid entries.

RULE #11

Do not release with unexplained critical failures.

RULE #12

Record failed tests and their corrective actions.

RULE #13

Test under actual production conditions where required.

RULE #14

Capture POSTCHANGE files after successful commissioning.

RULE #15

A system is not commissioned until normal operation and reasonable abnormal behavior are understood.

88. DEFINITION OF SUCCESS

CE-SOP-007 is successful when Controls Engineering can demonstrate:

What was supposed to happen

versus

What actually happened

and provide documented evidence that the system:

Performs required functions
Correctly processes I/O
Enforces required interlocks
Enforces required permissives
Generates correct alarms
Rejects invalid commands
Handles realistic failures
Recovers appropriately
Provides useful operator information
Operates under production conditions
Can be released with understood risk

The objective is not:

"IT RAN ONCE."

The objective is:

"WE TESTED IT, WE UNDERSTAND IT, AND WE CAN DEFEND THE DECISION TO RELEASE IT TO PRODUCTION."

89. REVISION HISTORY

Rev. 1.0

Initial release of CE-SOP-007 – Controls Commissioning, Functional Testing & Production Validation.

Owner: Electrical Controls Engineering

Review Frequency: Annual or following significant changes to Controls Engineering commissioning practices.