Safety Interlock Proof Testing Project

This project produces a proof-test and release package for an installed safety interlock chain. The objective is not to write a generic safety checklist. The objective is to prove, with traceable evidence, that the specific sensor, wiring, logic, actuator, reset sequence, bypass control and stopping response perform the credited protection function before the machine is released to automatic operation.

The example uses a guarded robotic packaging cell, but the workflow transfers to process interlocks, power-converter protection, test rigs, access-controlled laboratories, automated conveyors and equipment where a protection function must be periodically validated. Formal compliance requires the applicable machinery, process, electrical or site-specific safety standards. This project is an engineering validation workflow, not a substitute for a legal safety assessment.

Project objective

Validate the guard-door interlock GS-204 on a robotic case-packing cell after maintenance and before production release.

The final deliverable is an engineering proof-test package containing:

• safety-function boundary and assumptions;
• tag list and physical inspection record;
• stop-time and distance-margin calculation;
• proof-test matrix for normal and abnormal states;
• fault-injection evidence;
• reset and restart-behaviour checks;
• bypass-control and expiry checks;
• residual-risk notes and open limitations;
• release decision signed by engineering, maintenance and operations.

The interlock chain is credited only when the whole chain works. A changing input bit in software is not enough. The proof test must confirm that gate opening produces the required safe state at the hazardous motion sources, that faults are detected or made visible, and that reset cannot restart equipment in an unsafe state.

System boundary

Use this simplified boundary for the project.

Item	Project value
Protected access point	Guarded-cell gate G-204
Primary sensor	Dual-channel coded guard switch GS-204
Logic device	Programmable safety controller PSC-1
Final control elements	Robot safe torque off, conveyor drive safe torque off, pneumatic dump valve
Hazard considered	Reach into robot or pusher motion zone while automatic motion is enabled
Reset station	Outside the guarded cell, with view of the gate area
Normal operating mode	Automatic production at full speed
Maintenance mode	Reduced speed, hold-to-run jog, bypass permit required
Proof-test trigger	Maintenance replacement, safety-controller change, annual validation, incident recovery

The boundary excludes emergency-stop validation, lockout procedure validation, full risk assessment and performance-level calculation. Those records should exist elsewhere and must be cross-referenced. This project validates the installed interlock function against its approved design intent.

Acceptance criteria

Use these project acceptance criteria.

Requirement	Acceptance value
Gate opened in automatic mode	robot and conveyor safe torque off, pneumatic dump commanded
Maximum measured stopping time with guard margin	\le0.78\ \text{s}
Minimum access distance to closest hazard	\ge1.25\ \text{m}
Reset with gate open	no restart, alarm remains active
Reset from inside the cell	impossible or rejected by logic
Bypass in production mode	not allowed
Authorized bypass duration	automatic expiry at 60\ \text{min}
Faulted input channel	detected or prevents automatic restart
Power recovery with gate open	no automatic restart
Evidence quality	test record has tag, state, expected result, observed result, time, owner and disposition

The values are teaching values. A real project must use validated stopping-time measurement, access geometry, approach-speed assumptions, fault exclusions, diagnostic coverage and standards required by the site.

Step 1: Define the safety function

Write the safety function in a testable form:

When guard gate G-204 is opened during automatic operation, hazardous robot, conveyor and pusher motion shall be brought to the defined safe state before a person can reach the hazard zone. Restart shall require the gate closed, a deliberate external reset and a separate start command.

Convert that statement into observable evidence.

Function element	Observable evidence
gate state sensed	both guard-switch channels change consistently
logic state	safety controller reports guard open and automatic motion inhibited
final action	robot and conveyor safe torque off, pusher air dumped
response time	measured stop time is within the allowed screen
reset behaviour	reset clears the fault only when the gate is closed and the cell is clear
restart behaviour	reset alone does not start motion
bypass control	bypass requires permit, mode restriction, timer and visible indication

This conversion is important because it prevents a weak proof test. A checkbox saying “interlock tested” does not identify what was tested, which chain elements were included, or whether the final hazardous energy was actually removed.

Step 2: Perform the stop-time screen

For the initial screen, combine the configured delays and measured mechanical run-down.

Delay term	Value
input filter and safety input processing	35\ \text{ms}
safety-controller logic cycle	30\ \text{ms}
output relay and contactor response	20\ \text{ms}
drive safe-torque-off reaction	60\ \text{ms}
measured mechanical run-down	410\ \text{ms}

The total stop time is:

Use a simplified approach speed:

The travel distance during stopping is:

The measured distance from the gate threshold to the closest hazard zone is:

The simplified margin is:

The screen passes because the margin is positive. The engineering interpretation is limited: this is not a full safety-distance standard calculation. It is a commissioning screen that must be supported by formal design records, validated measurement method and site-specific assumptions.

Step 3: Add repeatability and measurement guard

One stop-time measurement is not enough. Repeat the test after maintenance and use the worst observed result, not the average.

Trial	Measured stop time
1	0.54\ \text{s}
2	0.56\ \text{s}
3	0.55\ \text{s}
4	0.58\ \text{s}
5	0.57\ \text{s}

The worst measured stop time is:

Apply a measurement and condition guard:

The release stop time for the screening record is:

The corresponding distance is:

The margin is:

The result still passes the project acceptance value. The comment in the release package should say that the design has positive margin for the tested configuration, but that any change to robot speed, payload, pneumatic pressure, access geometry, input filtering, safety-controller program or drive configuration requires reassessment.

Step 4: Build the proof-test matrix

The proof-test matrix should include normal operation, abnormal operation and recovery states.

Test ID	Initial state	Action	Expected result	Evidence
PT-01	automatic mode, gate closed	open G-204	robot STO, conveyor STO, air dump, alarm active	safety log, drive status, valve feedback
PT-02	automatic mode, gate open	press reset	reset rejected, no restart	HMI alarm, safety state
PT-03	gate closed, safe state active	press reset, then start	reset accepted, start allowed only after separate command	event log, operator observation
PT-04	maintenance mode	request bypass	bypass allowed only with permit and reduced-speed state	permit record, mode status
PT-05	production mode	request bypass	bypass rejected	HMI event, safety-controller bit
PT-06	bypass active	wait 60\ \text{min}	bypass expires or forces hold state	timer log
PT-07	power cycle with gate open	restore power	no automatic restart	startup log
PT-08	gate switch channel A open circuit	attempt automatic run	fault detected or automatic run inhibited	diagnostic alarm
PT-09	gate switch channel mismatch	attempt reset	reset rejected	diagnostic alarm
PT-10	air dump valve feedback absent	open gate	fault or hold state visible	valve feedback log

Each row needs observed results, not only expected results. If a test fails, the disposition must record whether the system was repaired, retested, accepted with limitation, or held from production.

Step 5: Fault-injection comments

Fault injection is where many weak proof tests fail. The test should not only prove that the system works when every component is healthy. It should show what happens when common dangerous or degraded states occur.

Fault	Engineering reason for the test	Acceptable response
input channel open circuit	detects broken wire or disconnected switch channel	fault visible, automatic start inhibited
channel mismatch	detects switch, wiring or timing disagreement	fault visible, reset rejected
stuck closed input	challenges hidden failure of sensing path	detected by diagnostics or found by proof test before release
failed output feedback	verifies final element is not assumed from command bit	alarm or hold until feedback is restored
reset held active	prevents a taped or failed reset pushbutton from restarting motion	edge detection or reset fault
bypass permit expired	prevents degraded state from becoming normal production	automatic expiry, escalation or forced hold

The engineering comment belongs in the record: the proof test does not need to damage equipment to be useful. It needs a controlled method for producing representative faults, restoring the system, and proving that the protective function does not silently become unavailable.

Step 6: Check bypass exposure control

A bypass is sometimes necessary for alignment, troubleshooting or commissioning. The proof test should verify that the bypass state is engineered as a controlled degraded mode.

Assume the bypass permit allows:

The maintenance work plan estimates:

During a dry run, the bypass remains active for:

The utilization of the authorized window is:

So the bypass used about:

of the authorized time.

That result is acceptable only if the state remained inside the permitted operating condition. If production mode was enabled during the same period, the bypass test would fail even though the timer had not expired. Time control is necessary, but it is not sufficient; mode restriction and visible indication are also required.

Step 7: Screen the proof interval

Some dangerous failures are not self-revealing. A simplified average dangerous undetected probability screen can help explain why periodic proof testing matters.

Use the approximation:

where:

• \lambda_{DU} is the dangerous undetected failure rate;
• T is the proof-test interval in hours;
• the approximation is valid only when \lambda_{DU}T is small.

Assume an illustrative dangerous undetected failure rate:

For annual proof testing:

For semiannual proof testing:

The semiannual screen halves the average dangerous undetected probability in this simplified model. That does not automatically make it the right interval. The final interval should consider demand rate, diagnostic coverage, maintenance burden, component data, regulatory requirements, consequence severity, prior failures and whether the proof test itself creates risk.

Step 8: Score residual actions with RPN

Use risk-priority-number scoring only as a triage aid, not as proof that the system is safe.

Residual issue	Severity	Occurrence	Detection	RPN
bypass request possible from wrong HMI page	8	3	5	8(3)(5)=120
reset station view partially obstructed by spare cartons	7	4	4	7(4)(4)=112
stop-time measurement record not attached to maintenance work order	6	5	6	6(5)(6)=180
event-log export procedure depends on one engineer	5	4	7	5(4)(7)=140

The highest RPN in this simplified table is the missing stop-time attachment:

The engineering decision is not “RPN below a magic number means release.” The decision is that release can proceed only if high-priority residual actions are either closed or explicitly accepted with owner, due date and compensating controls.

Release package

The final package should be short enough to review and complete enough to audit.

Section	Required content
scope	machine, gate, safety function, exclusions
design reference	approved risk assessment, logic revision, electrical drawing, pneumatic drawing
configuration	controller program version, drive settings, input filter, valve feedback tags
proof-test record	matrix with observed results and pass/fail disposition
stop-time evidence	raw measurements, worst case, guard margin, distance screen
fault evidence	injected faults, diagnostics, reset response, restoration record
bypass evidence	permit workflow, mode restriction, expiry, HMI indication
limitations	assumptions, untested states, required follow-up
release decision	hold, conditional release or production release

Use a release decision such as:

The GS-204 interlock chain passed proof testing for automatic production release in the tested configuration. Production release is conditional on keeping bypass disabled in production mode, preserving the external reset station, attaching stop-time evidence to the maintenance record and revalidating after any change to access geometry, robot speed, drive settings, safety logic or final-element hardware.

This statement is useful because it ties release to configuration. It avoids the common error of treating one successful test as permanent proof for future modified states.

Common project mistakes

Common mistakes include:

• testing the software bit instead of the final hazardous-energy removal;
• averaging stop times instead of using the worst measured value plus a guard;
• accepting reset behaviour without checking restart behaviour;
• allowing bypass in production mode because it is convenient during troubleshooting;
• documenting expected results without observed evidence;
• omitting faulted-input and output-feedback tests;
• failing to update the proof-test record after logic, sensor, drive or access-geometry changes.

The practical rule is simple: a proof test is only as strong as the boundary it actually tests. If the record does not show the sensor, logic, final element, timing, reset, bypass and fault response, it is not a release package for the credited interlock function.