Testing, Commissioning, Troubleshooting and Maintenance

Introduction

A programmable logic controller (PLC) installation is not complete when the program has been written. It becomes an engineering system only after its hardware, software, field instruments, networks, control functions, safety functions, documentation, and operating procedures have been verified together. Testing and commissioning provide evidence that the system satisfies its specification. Troubleshooting restores operation when faults occur, while maintenance preserves performance throughout the asset life cycle.

Industrial automation work is particularly sensitive to incomplete testing. A wiring error may cause a motor to start unexpectedly; an incorrect analog scaling factor may produce an unsafe process condition; and an untested network redundancy feature may fail precisely when it is needed. A disciplined lifecycle therefore moves from simulation and code review to factory acceptance testing (FAT), site acceptance testing (SAT), loop checks, functional validation, operation, and maintenance.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the purpose and sequence of simulation, code review, FAT, SAT, loop checks, and validation.
2. Develop structured test evidence for PLC hardware, software, instrumentation, safety, and communications.
3. Diagnose common hardware, software, instrumentation, and network faults using a systematic method.
4. Apply secure backup, version-control, and change-management practices.
5. Distinguish corrective, preventive, predictive, and reliability-centered maintenance.
6. Evaluate a commissioning problem and recommend technically justified actions.

1. Verification and Validation in Automation

Verification asks, “Was the system built according to its requirements?” Examples include checking that every input is mapped to the correct PLC address and that the program follows the approved design. Validation asks, “Does the completed system perform the intended operational function?” For example, a validated pump-control system must maintain the required process flow under realistic operating conditions, not merely execute without software errors.

A useful quality model has four layers:

Testing must be traceable to requirements. A requirements traceability matrix links each requirement to design documents, test cases, results, and approval. A failed test is not erased; it is recorded with the defect, risk, responsible person, corrective action, retest result, and closure authority.

2. Simulation and Code Review

2.1 Simulation

Simulation tests control behavior before field devices are energized. A simulated input may represent a limit switch, pressure transmitter, motor overload, or emergency-stop circuit. Simulated outputs may be connected to lamps, virtual devices, or a process model.

Simulation is most useful for:

• sequence logic and state transitions;
• permissives, interlocks, and alarms;
• start-up, shutdown, and fault recovery;
• analog scaling and limit handling;
• abnormal and boundary conditions; and
• operator-screen behavior.

A simulation is not a substitute for a field test. It cannot fully reveal reversed motor rotation, incorrect instrument tubing, electrical noise, grounding problems, or a wrong terminal connection.

A strong test set includes normal, abnormal, and recovery cases. For a conveyor, these may include a normal start, blocked discharge, motor overload, loss of a photoelectric sensor, emergency stop, power restoration, and restart authorization. Each test should state the initial conditions, input stimulus, expected output, timing requirement, actual result, and acceptance status.

2.2 Code Review

Code review is a structured examination by someone other than the original programmer, preferably using an approved checklist. Important review topics include:

• naming conventions and comments;
• modular structure and reusable function blocks;
• safe initial states and restart behavior;
• permissives and interlocks;
• timer, counter, and analog-limit settings;
• treatment of bad-quality or failed signals;
• alarm priority and alarm reset behavior;
• diagnostic messages;
• scan-time and memory use;
• race conditions and one-shot logic;
• access control and passwords; and
• consistency between PLC code, HMI screens, electrical drawings, and cause-and-effect documents.

A reviewer should challenge assumptions. For example, “motor feedback is true” may mean that a contactor auxiliary contact is closed, but it does not necessarily prove that the motor is rotating. If rotation is important, a speed switch or encoder may be required.

3. Factory Acceptance Testing

FAT is performed before shipment, normally at the system integrator’s facility. Its purpose is to demonstrate to the customer that the assembled control system satisfies agreed requirements under controlled conditions. FAT generally includes the PLC rack, remote I/O, HMI, safety system, network equipment, control panels, simulated field signals, and documentation.

A typical FAT sequence is:

1. Confirm approved drawings, software, test procedures, and instrument lists.
2. Inspect panel construction, labeling, terminal blocks, earthing, ventilation, and power supplies.
3. Energize equipment safely and verify voltage, polarity, and protective devices.
4. Check PLC diagnostics, I/O modules, communication links, and redundancy.
5. Execute functional test cases using simulated signals.
6. Test alarms, trends, recipes, reports, user roles, and time synchronization.
7. Test fault handling, power cycling, and controlled recovery.
8. Record deviations and agree on punch-list closure.
9. Archive the tested software and issue the FAT report.

FAT reduces site risk and travel cost, but it has limitations. Field wiring, actual process dynamics, instrument installation, environmental conditions, and interactions with existing plant systems may not be represented accurately. FAT acceptance therefore does not eliminate SAT.

4. Site Acceptance Testing and Commissioning

SAT is performed at the installed site after equipment, field wiring, instruments, utilities, and interfaces are available. Commissioning should be planned in stages rather than treated as a single event.

4.1 Pre-commissioning

Pre-commissioning includes mechanical completion, panel inspection, cable testing, instrument calibration, network installation, labeling, inspection of protective earth connections, and confirmation that the work area is safe. Energization must follow an approved permit and isolation procedure.

4.2 Cold and Hot Commissioning

Cold commissioning checks equipment without process material or hazardous operation. Examples include jog tests, valve stroking, I/O verification, and network checks. Hot commissioning tests the system under actual process conditions. It requires operating procedures, emergency arrangements, trained personnel, and clear authority to stop the test.

4.3 SAT Evidence

SAT should demonstrate:

• correct operation of every field input and output;
• correct sequence and permissive behavior;
• proper alarm generation, acknowledgment, shelving, and reset;
• correct analog values, engineering units, and ranges;
• safe response to loss of power, air, signal, or communication;
• correct HMI commands and indication;
• acceptable cycle time and process performance; and
• completion of training, drawings, backups, and maintenance documentation.

5. Loop Checks and Instrument Validation

A loop check verifies the complete signal path from field device to controller and operator interface, and—where applicable—from controller output to the final control element. It is more comprehensive than checking an individual wire.

For a pressure transmitter, the loop may include the sensing element, impulse tubing, transmitter, cable, marshalling terminals, analog input card, PLC tag, scaling block, HMI display, alarm limits, historian, and control response. A loop-check record should identify the tag, device range, signal type, terminal numbers, PLC address, expected values, measured values, calibration equipment, date, and signatures.

For a 4–20 mA transmitter with range 0–10 bar, linear scaling is commonly represented by:

where PV is the process value in bar, I is loop current in mA, L is the lower range value, and H is the upper range value. The equation assumes a correctly wired linear transmitter, a valid 4–20 mA signal, and no sensor fault. At 12 mA for this example:

A current below 4 mA or above 20 mA may indicate underrange, overrange, wiring failure, or a transmitter diagnostic condition; the exact interpretation depends on the instrument standard and configuration. Engineers must not automatically convert every abnormal current into a valid process value.

Digital loops require confirmation of both logical state and physical action. If a PLC output commands a solenoid, the test should verify output indication, voltage at the terminal, voltage at the solenoid, valve movement, feedback, and the resulting process effect.

6. Functional Safety and Validation

Safety-related functions require a higher degree of independence and rigor than ordinary control functions. Validation should confirm the complete safety chain: initiating sensor, safety logic solver, output device, final element, reset conditions, diagnostics, and proof-test procedure.

Typical checks include emergency-stop operation, guard switches, overspeed trips, burner management sequences, safe torque off, reset authorization, and behavior after power restoration. A safety function must not rely solely on a software alarm where a defined de-energized or safe state is required.

Testing must not defeat protective functions without formal authorization. Temporary bypasses require identification, risk assessment, time limits, compensating measures, and removal verification. Applicable machinery, electrical, process-safety, cybersecurity, and occupational-safety regulations must be followed in the relevant jurisdiction.

7. A Systematic Troubleshooting Method

Troubleshooting should be evidence-based rather than based on random component replacement. A practical method is:

1. Make the situation safe and identify hazards.
2. Define the symptom precisely: what failed, when, and under what conditions?
3. Check recent changes, alarms, diagnostics, and maintenance history.
4. Divide the system into sections: power, field device, I/O, controller, network, HMI, and final element.
5. Test from the symptom toward the source, or use a known-good reference.
6. Measure rather than assume; record readings and time.
7. Correct one cause at a time and retest the complete function.
8. Document the root cause, temporary action, permanent correction, and lessons learned.

7.1 Hardware Faults

Common hardware symptoms and checks include:

Measurements must be made with appropriately rated instruments and safe isolation. A voltage reading alone does not prove that a circuit can deliver the required current under load.

7.2 Software Faults

Software faults include incorrect addressing, overwritten tags, wrong timer units, missed one-shot conditions, faulty state transitions, and logic that does not define behavior after a restart. Online monitoring can reveal whether a permissive is false, a timer is timing, or a command is being overwritten later in the scan.

A useful distinction is between command, permission, and feedback. A motor may have a start command but no permission; it may have permission but no output due to a program branch; or it may have an output but no running feedback because of a contactor or motor fault.

7.3 Network Faults

Network troubleshooting begins with physical-layer checks: power, connectors, cable type, shielding, termination, link indicators, and topology. It then proceeds to addressing, duplicate node identifiers, protocol configuration, timeouts, update rates, managed-switch diagnostics, and excessive broadcast or multicast traffic.

Intermittent network faults are often difficult because the system may recover before an engineer arrives. Event logs, switch counters, time-stamped PLC diagnostics, and packet or traffic analysis can establish whether the problem is physical, configuration-related, or caused by system loading. A network should not be declared reliable merely because a ping test succeeds; control protocols, update deadlines, redundancy behavior, and device diagnostics must also be checked.

8. Backups, Version Control, and Change Management

The authoritative automation baseline should include PLC and safety programs, HMI and SCADA projects, drive parameters, robot programs, network configurations, recipes, firmware records, drawings, bills of material, licenses, test reports, and calibration data.

A robust practice follows the 3-2-1 principle: maintain at least three copies, on at least two different media, with at least one copy offline or otherwise protected from the production network. Backups must be tested by restoration; a file that cannot be restored is not a dependable backup.

Every released version should have a unique identifier, date, author, change description, approval status, and compatibility information. Before editing a live controller, capture the current program and configuration. Changes should be reviewed, tested, authorized, implemented during a controlled window, and accompanied by a rollback plan.

Cybersecurity is part of configuration management. Access should follow least privilege, unused accounts should be removed, portable media should be controlled, and remote access should be authenticated, logged, time-limited, and approved. Safety and security changes require special governance because a cyber incident can create a physical hazard.

9. Maintenance Strategies

Corrective Maintenance

Corrective maintenance restores a failed asset. It is unavoidable for some low-consequence devices but can be expensive when failure interrupts production or creates safety risk.

Preventive Maintenance

Preventive maintenance is performed at planned intervals, such as inspection, cleaning, tightening, calibration, battery replacement, or proof testing. Time-based maintenance is effective when deterioration is predictable, but excessive intervention can introduce faults and waste resources.

Predictive and Condition-Based Maintenance

Predictive maintenance uses condition data to identify developing failure. Examples include vibration analysis for rotating machines, thermal imaging of electrical connections, motor-current analysis, oil analysis, valve-stroke monitoring, and trend analysis of I/O quality. A condition indicator should be connected to an action threshold and a responsible decision process; collecting data without acting on it has little value.

Reliability-Centered Maintenance

Reliability-centered maintenance (RCM) selects maintenance tasks according to function, functional failure, failure mode, consequence, and technically feasible task. A safety-critical shutdown valve may require proof testing and partial-stroke testing, while a noncritical indicator lamp may simply be replaced on failure. RCM avoids applying the same maintenance interval to every asset.

Availability is commonly expressed as:

where A is inherent availability, MTBF is mean time between failures, and MTTR is mean time to repair, with both times expressed in the same units. The expression assumes a repairable item and a simplified renewal model; planned downtime, logistics delays, and standby redundancy may require a different availability model.

For MTBF = 900 h and MTTR = 3 h:

This figure does not mean that every production system will deliver 99.67% output, because material shortages, planned shutdowns, quality losses, and upstream or downstream constraints are excluded.

10. Illustrative Case: Packaging-Line Commissioning Failure

Background

A new automated packaging line contains conveyors, a case packer, photoelectric sensors, variable-speed drives, a PLC, HMI, and an industrial Ethernet network. FAT was completed with simulated sensors, and the system was installed during a planned shutdown.

Problem

During SAT, the discharge conveyor stopped intermittently. The HMI showed a motor-running command, but the motor-feedback indication disappeared. Operators initially suspected the PLC program.

Analysis

The commissioning team first made the line safe and reviewed event logs. The fault occurred when the conveyor accelerated. The PLC output remained energized, but voltage at the drive control terminal dropped. Inspection found that the control cable shared a poorly terminated terminal block with a high-current conductor. Vibration caused intermittent contact resistance, and acceleration increased electrical disturbance. A second issue was found in the program: the fault timer was too short for the drive’s normal acceleration time.

Approach and Outcome

The terminal block and cable termination were corrected, cable routing was improved, and the drive shield and bonding arrangement were installed according to the design requirements. The acceleration-time parameter and PLC feedback timer were reconciled using the approved drive specification. The team repeated cold tests, then ran the conveyor with product at minimum, normal, and maximum rates. The event log, alarm response, and restart procedure were verified. The final report recorded both the physical defect and the software coordination defect.

Learning Points

The case demonstrates that a symptom at the PLC may originate in field wiring, drive configuration, or an unrealistic timing assumption. FAT reduced software risk but could not reproduce installation vibration and electrical interference. Successful commissioning required measurement, cross-disciplinary review, controlled retesting, and updated documentation.

11. Challenges, Limitations, and Best Practices

Automation systems combine electrical, mechanical, instrumentation, software, network, and human factors. A fault may therefore cross disciplinary boundaries. Digital diagnostic tools also have limitations: a healthy communication status does not guarantee correct process data, and an alarm-free system may still be operating with a wrong set point or bypassed interlock.

Best practices include:

• begin testing from approved requirements and cause-and-effect documents;
• use independent review for safety-critical logic;
• test abnormal, boundary, restart, and loss-of-communication conditions;
• preserve objective evidence, not only signatures;
• maintain a controlled single source of truth for software and drawings;
• train operators and maintainers using realistic scenarios;
• distinguish temporary restoration from permanent corrective action;
• use risk-based maintenance rather than arbitrary intervals; and
• treat cybersecurity, functional safety, and change control as operational responsibilities.

Artificial intelligence can assist anomaly detection, alarm rationalization, predictive maintenance, and document search. It should support—not replace—engineering judgment. Models require representative data, validation, cybersecurity controls, explainable recommendations, and human authorization before an automated action affects a safety-critical process.

Chapter Summary

Testing and commissioning establish evidence that an automation system is correctly built and fit for operation. Simulation and code review identify logic defects before field work. FAT verifies the assembled control system under controlled conditions, while SAT confirms operation in the actual installation. Loop checks trace signals from field devices through I/O, control logic, HMI, and final elements. Functional-safety validation must verify the entire protective chain and must control bypasses carefully.

Effective troubleshooting is systematic, safe, measurement-based, and documented. Hardware, software, instrumentation, and networks require different diagnostic approaches, but all benefit from clear symptom definition and staged isolation. Backups, version control, restoration tests, and authorized change management protect operational continuity. Corrective, preventive, predictive, and reliability-centered maintenance should be selected according to failure behavior and consequence. Availability calculations are useful indicators, but they do not represent total production performance without considering the wider system.

Key Terms

Verification: Confirmation that a system meets specified design requirements.

Validation: Confirmation that a completed system fulfills its intended operational purpose.

Simulation: Testing control behavior with modeled or substituted inputs and outputs.

Code review: Structured examination of software by qualified personnel.

FAT: Factory acceptance testing before shipment to the operating site.

SAT: Site acceptance testing after installation at the operating site.

Commissioning: Activities that place an installed system into safe, functional operation.

Loop check: Verification of a complete instrument or control signal path.

Permissive: A condition that must be true before an operation is allowed.

Interlock: Logic that prevents or stops an operation under defined conditions.

Functional validation: Demonstration that an implemented function performs as required.

Traceability matrix: Record linking requirements to design and test evidence.

Corrective maintenance: Maintenance performed after a failure to restore function.

Preventive maintenance: Planned maintenance intended to reduce failure probability.

Predictive maintenance: Maintenance based on measured condition or forecast deterioration.

Reliability-centered maintenance: Risk- and function-based selection of maintenance tasks.

MTBF: Mean time between failures for a repairable asset.

MTTR: Mean time to repair an asset.

Configuration management: Controlled identification, recording, and approval of system versions and changes.

Root cause: Underlying reason that produced a failure or undesired event.

Review Questions

Short Answer Questions

1. Distinguish verification from validation in a PLC project.
2. State two limitations of FAT.
3. What information should be included in a loop-check record?
4. Why must backups be tested by restoration?
5. Define predictive maintenance.

Long Answer Questions

1. Explain a complete FAT and SAT strategy for a motor-control system.
2. Describe a systematic method for diagnosing an intermittent industrial network fault.
3. Compare corrective, preventive, predictive, and reliability-centered maintenance.
4. Explain how functional-safety validation differs from ordinary PLC testing.
5. Discuss the role of version control and change management in automation reliability.

Analytical / Application Questions

1. A 4–20 mA transmitter has a range of 0–16 bar and produces 15 mA. Calculate the indicated pressure, state the assumptions, and describe two additional checks before accepting the value.
2. A repairable PLC subsystem has an MTBF of 1,200 h and an MTTR of 6 h. Calculate its simplified inherent availability and explain why this may not equal plant production availability.
3. A pump command is present, the output LED is on, but the pump-feedback signal is absent. Develop a safe troubleshooting sequence that separates logic, wiring, starter, motor, and feedback-device causes.

Multiple Choice Questions with Answers

Question 1

Which activity primarily demonstrates that an installed automation system performs its intended process function?

A. Validation

B. Component labeling

C. Version numbering

D. Panel painting

Correct Answer: A. Validation

Question 2

What is a principal limitation of FAT?

A. It cannot test any software function

B. It may not represent actual field wiring and process conditions

C. It must always be performed after SAT

D. It eliminates the need for loop checks

Correct Answer: B. It may not represent actual field wiring and process conditions

Question 3

For a 0–10 bar, 4–20 mA linear transmitter, what process value corresponds to 12 mA?

A. 2.5 bar

B. 4 bar

C. 5 bar

D. 7.5 bar

Correct Answer: C. 5 bar

Question 4

Which item is normally part of a complete loop check?

A. Only the PLC program file

B. Only the instrument nameplate

C. The signal path from field device through display and control response

D. Only the HMI color scheme

Correct Answer: C. The signal path from field device through display and control response

Question 5

What should be done first when troubleshooting a hazardous automation fault?

A. Replace the PLC CPU

B. Make the situation safe and identify hazards

C. Delete the alarm history

D. Increase the scan rate

Correct Answer: B. Make the situation safe and identify hazards

Question 6

Which practice best supports recovery from an accidental or malicious configuration change?

A. Keeping one undocumented copy on the live workstation

B. Using tested, versioned backups with controlled access

C. Allowing all users administrator privileges

D. Disabling all diagnostic logs

Correct Answer: B. Using tested, versioned backups with controlled access

Question 7

Which maintenance strategy uses vibration or thermal data to identify developing failure?

A. Corrective maintenance

B. Predictive maintenance

C. Break-in maintenance

D. Unplanned maintenance

Correct Answer: B. Predictive maintenance

Question 8

If MTBF is 900 h and MTTR is 3 h, the simplified inherent availability is approximately:

A. 90.00%

B. 96.67%

C. 99.67%

D. 100.30%

Correct Answer: C. 99.67%

Question 9

Why is a command-feedback distinction useful in troubleshooting?

A. It proves that a motor is mechanically healthy

B. It separates an intended action from evidence that the action occurred

C. It removes the need for field measurements

D. It automatically corrects network addressing

Correct Answer: B. It separates an intended action from evidence that the action occurred

Question 10

What is a central principle of reliability-centered maintenance?

A. Apply identical maintenance intervals to every asset

B. Replace every component before commissioning

C. Select tasks according to function, failure mode, and consequence

D. Perform maintenance only after catastrophic failure

Correct Answer: C. Select tasks according to function, failure mode, and consequence