PLC Code Review Best Practices for Industrial Plants

A PLC code review systematically examines a PLC program for correctness, safety, maintainability, and performance. Unlike software code reviews in IT, PLC reviews must consider the physical process — a logic error can damage equipment, product, or people. This guide provides a practical framework.

When to Do a Code Review#

• Before commissioning a new or modified system
• After a migration from one PLC platform to another
• When taking over an undocumented system
• After an incident or near-miss related to control logic
• Periodically (annual review for safety-critical systems)

What to Check (Priority Order)#

1. Safety Logic (Highest Priority)#

• Emergency stop circuits: Is the E-stop wired and programmed correctly? Does it stop all dangerous motion? Is it fail-safe (active-low / NC contact)?
• Safety interlocks: Are all interlocks present and correctly linked? Can any interlock be bypassed from the program?
• Guard monitoring: Are safety gates, light curtains, and two-hand controls correctly evaluated?
• Forced I/O: Check the force table — are any I/O points permanently forced? This is a common source of hidden safety bypasses.

2. Startup and Shutdown Behavior#

• Cold start (power-on): Does the program initialize all outputs to a safe state? Are no motors or valves activated during startup?
• Restart after fault: Does the program require an explicit operator acknowledgment before restarting?
• Power failure recovery: If power drops and returns, does the program resume safely?

3. Program Structure#

• Block organization: Is the program logically structured? Are there too many blocks (> 200 may indicate poor structure) or too few (everything in OB1)?
• Dead code: Are there blocks that are never called? Unreachable code sections?
• Duplicate code: Are similar logic patterns copied across multiple blocks instead of using parameterized FBs?

4. Data Handling#

• Uninitialized variables: Are all markers and DB elements initialized at startup?
• Overlapping memory access: Is the same marker byte/word written from multiple places? (MW 10 written in PB3 and PB7 — potential race condition)
• Absolute addressing in DBs: On S7-1500, absolute DB access prevents optimized access mode

5. Timer and Counter Usage#

• Timer values: Are they appropriate for the process? A 100ms timer on a 5-second mechanical process suggests copy-paste from another machine.
• Retentive timers (SS): Do they have corresponding reset conditions?
• Counter overflow: Can any counter reach its maximum (999 in S5, 32767 in S7) without reset?

6. Communication#

• Timeout handling: Do communication blocks (BSEND, TRCV_C, PUT/GET) have timeout monitoring?
• Data consistency: Are sent/received data validated before use?

Review Checklist#

Use this checklist during the review:

Safety:

• ☐ E-stop correctly wired and programmed (NC contact, active-low)
• ☐ All safety interlocks present and cannot be software-bypassed
• ☐ No permanently forced I/O (check force table)
• ☐ Safe startup state (no unexpected motion at power-on)
• ☐ Operator acknowledgment required after fault

Structure:

• ☐ Clear block organization (OB→PB/FB→FC structure)
• ☐ No dead code or uncalled blocks
• ☐ Meaningful symbol names for all used addresses
• ☐ Network/block comments present
• ☐ Consistent naming convention

Data:

• ☐ All variables initialized at startup
• ☐ No overlapping marker/DB writes from multiple blocks
• ☐ No hardcoded values (use constants or DB parameters)

Timers/Counters:

• ☐ Timer values match process requirements
• ☐ Retentive timers have reset conditions
• ☐ Counters have overflow protection

Communication:

• ☐ Timeout handling for all communication blocks
• ☐ Data validation before processing received data

How PLCcheck Pro Helps#

PLCcheck Pro automates many review checks:

• Identifies forced I/O references
• Finds dead code and uncalled blocks
• Detects overlapping marker/DB writes
• Lists all hardcoded values
• Generates a review-ready documentation

Upload your PLC code →

Frequently Asked Questions#

Who should do a PLC code review?

Ideally someone who did not write the code — a second pair of eyes catches things the author is blind to. A senior PLC programmer or an automation engineer from another project team is the best choice.

How long does a review take?

A focused review of a medium-sized program (50–100 blocks) takes 1–2 days. Safety-critical reviews may take longer and require documentation of findings.

---

Maintained by PLCcheck.ai. Last update: March 2026. Not affiliated with Siemens AG.