Traffic Light Program: Interlocks, Not Timers, Control Safety

After the fix, every commanded indication follows an approved state sequence, conflicting outputs remain blocked, and each transition has a recorded pass result. A working claim alone is not a commissioning record: no logic listing, controller family, I/O map, phase topology, timing values, or field-test results are defined here. Build those installation-specific details into the acceptance basis before treating the program as deployable.

Scope and acceptance basis

The term topology here means the number of signal heads, controlled approaches, permitted movements, and auxiliary indications governed by the program. Determine first whether the application is a demonstration panel, a private-site signal, or equipment that controls public movement. That decision changes the required hardware, approval process, fault response, and independent protection.

Obtain the approved phase plan and convert it into an acceptance matrix. For every operating state, record each indication as commanded on or off. Add required dwell or clearance values from the design documents, but do not create timing values from operator preference or PLC scan behavior. Also identify startup, shutdown, manual, maintenance, and detected-fault behavior.

Separate three acceptance levels:

• Logic acceptance: the state machine requests only combinations allowed by the phase plan.
• Output acceptance: the PLC output image matches the requested state.
• Field acceptance: the actual lamp or signaling device assumes the commanded condition.

An energized PLC output proves only the command unless the installation provides independent device feedback. A failed lamp, welded relay, wiring cross-connection, or loss of field power can make the physical indication differ from the output image.

Check 1: expect a signed state matrix containing every normal and abnormal mode, the required transition order, installation timing values, output assignments, and the method used to confirm the physical indications.

State model and output ownership

Represent the sequence as explicit, mutually exclusive states. A state is the complete operating condition for one phase of the sequence, not merely a timer-done bit. Outputs should be decoded from the active state so one part of the program owns every signal command. Scattered output coils, duplicated addresses, and independently latched color bits create multiple authorities and make contradictory commands possible.

For an application with opposing movements, the approved state matrix commonly needs movement, warning, and clearance states. The precise order depends on the approved phase plan. Do not silently assume that a simple green-yellow-red classroom cycle is valid for a field installation. Pedestrian movements, turn indications, flashing modes, and request-based phases add states and transition conditions.

Use one deterministic startup state. The safe startup command must come from the system design; de-energizing every output does not automatically produce a safe visible condition. Relay contact selection, lamp supply architecture, and output-module behavior determine what appears in the field when power or logic is lost.

Derive output commands from the active state, then apply a final conflict layer. The conflict layer blocks combinations prohibited by the state matrix even if a programming error, forced bit, or abnormal transition requests them. Software interlocks improve deterministic behavior but do not replace any independent protective hardware required by the installation.

Check 2: monitor the state representation through one complete simulated cycle. Expect exactly one normal state active at a time and only the output combination assigned to that state.

Transition interlocks and timing

A timer qualifies when a transition may occur; it must not be the sole reason conflicting movements stay separated. Interlocks establish which next state is permitted. This distinction prevents a timer preset, reset, or scan-order error from directly commanding an unsafe output combination.

For each state, define:

• the permitted successor state or states;
• the condition that starts the dwell interval;
• the approved preset source;
• the input or request conditions required for departure;
• the conditions that reset or hold the transition;
• the destination for an invalid state or detected conflict.

Start a dwell timer from confirmed state entry, not from a request that may remain active across several phases. Reset or reinitialize transition timing when leaving the state. Otherwise, an accumulated or already-complete timer can cause an immediate transition when the program returns to that state.

PLC scan order also matters. If transition logic changes a state and output logic reads that change later in the same scan, the new output pattern may appear immediately. If separately latched outputs are reset and set in different branches, transient or scan-long combinations become dependent on routine order. A single state transition followed by centralized output decoding makes that behavior reviewable.

Check 3: hold each simulated state before its configured transition threshold and expect no departure. At the documented transition condition, expect one move to an allowed successor, with the old output pattern removed and the new pattern decoded from the resulting state.

Modes, requests, and abnormal conditions

Mode logic sits above the normal sequence. Define how automatic operation, stopped operation, manual testing, startup, and faults acquire control. A selector should request a mode transition; it should not energize field outputs through a second logic path.

Condition external requests before using them. A maintained request may need to be remembered until served, while a momentary request may require edge capture. Mechanical contacts can change repeatedly during one physical operation, and asynchronous inputs can change between scans. Apply the input handling appropriate to the controller and installation, then consume the request at a defined state boundary.

Manual testing needs the same conflict restrictions as automatic operation. A maintenance command that bypasses all interlocks can conceal wiring errors during commissioning and create combinations the automatic sequence could never request. Force handling also belongs in the commissioning plan: record active forces, remove them after each test, and verify the force table is clear before operational release.

Define the response to invalid state data, controller restart, timing configuration outside its permitted engineering range, loss of required feedback, and detected output conflict. Route each condition to the designed abnormal state and require an intentional recovery action where the risk assessment calls for one.

Check 4: exercise every mode and abnormal-condition input separately. Expect one output owner, continued conflict blocking, a deterministic abnormal state, and no automatic return that bypasses the approved recovery path.

Symptom-to-cause isolation

Check 5: inject each testable symptom in simulation or on an isolated commissioning setup. Expect the deciding check to separate a logic-command problem from a field-output problem before any code change is made.

Commissioning procedure

1. Review the state matrix. Cross-check every state, successor, interlock, timing source, and abnormal destination against the approved design. Reject undocumented paths.
2. Search for multiple output writers. Locate every instruction that can affect each physical output or its intermediate command. Expect one centralized output-decoding path.
3. Test without field actuation. Disable or isolate physical movement as required by the site procedure. Simulate inputs and observe state, timer, request, mode, and output-command values.
4. Test every transition boundary. Observe the scan before, at, and after each transition condition. Expect no skipped state and no prohibited intermediate output pattern.
5. Test held and repeated requests. Hold each request active across a full service cycle, then apply repeated and near-boundary requests. Expect each request to be stored, served, or rejected according to the approved design.
6. Test restarts and faults. Exercise controlled controller restart, field-power loss, invalid state handling, and available feedback faults. Expect the defined startup or abnormal state.
7. Map outputs point by point. Command one permitted test condition at a time and confirm terminal, wire, device, and indication identity. Correct swapped conductors or channel assignments before automatic cycling.
8. Run the connected sequence. Use approved timing settings and observe complete cycles in every enabled operating mode. Record commanded and actual indications.
9. Clear temporary controls. Remove forces, simulations, bypasses, and test values. Reload or compare the released configuration as required by the project process.

Check 6: expect a commissioning record with a pass or corrected-and-retested result for every state, transition, request, mode, restart, fault response, output point, and physical indication.

End-to-end verification

Final verification must test the complete path from input condition through state transition, PLC output image, output channel, field wiring, and visible device. Watching program animation alone omits the failure modes between the controller and the lamp.

1. Check 7: start from the designed startup condition. Expect the documented initial state and its exact output pattern, with prohibited combinations off.
2. Check 8: initiate each valid request. Expect the request to affect only an allowed transition and only at the specified state boundary.
3. Check 9: observe every dwell and clearance interval against the approved settings. Expect the state to remain stable until its complete transition condition is true.
4. Check 10: compare the state matrix, output image, terminal condition, and physical indication at every state. Expect all four to agree; where no device feedback exists, record the field observation as a separate result.
5. Check 11: repeat abnormal-mode, restart, and recovery tests with production configuration loaded. Expect the designed abnormal state, conflict blocking, and the approved recovery sequence.

Frequently asked questions