Firmware Change on a SIL 2 Ethylene Oxide Sterilizer
A contract manufacturer operates an ethylene oxide sterilization chamber. The SIL 2 safety instrumented function SIF-14 closes the EO supply valve and opens the emergency exhaust on high chamber temperature. It is implemented in a certified safety PLC with two redundant CPU channels and a shared Ethernet backplane. The current PFDavg is 4×10⁻² with a 12-month proof test, proof-test coverage of 70%, and a beta factor of 5%. The vendor releases firmware v4.2 that changes scan-cycle behavior and adds online diagnostics, but also requires both channels to use a new common network library. Engineering proposes to install it during the next shutdown and treat it as a like-for-like replacement under the site's management-of-change procedure because the safety function logic is unchanged. The unit runs 6,000 batches per year, and the LOPA credits SIF-14 as the only independent protection layer against an EO release scenario with consequence category 4. No SIL verification has been performed since commissioning in 2016.
1. Is like-for-like treatment appropriate? What change impact analysis is required before installation?
Read the worked answer
Like-for-like is not appropriate. The logic may be unchanged, but the firmware alters scan-cycle timing and adds diagnostics, and the new common network library affects both channels. Those changes can affect response time, dangerous-failure detection, systematic capability, and common-cause vulnerability. A safety PLC's certification and safety manual are based on specific firmware and configuration assumptions; using a new firmware revision without vendor confirmation and re-verification breaks that basis.
The change should go through full MOC with a documented impact analysis covering: the safety manual and any firmware restrictions; scan time versus the required response time; diagnostics and proof-test coverage; network independence and common-cause beta; configuration migration and version control; and cyber/security implications. The vendor should confirm compatibility and any required revalidation. Before installation, a factory acceptance test and a function test of SIF-14 should be performed, including simulated high temperature, valve closure, exhaust start, and failure of one channel. After installation, site acceptance testing and a proof test should confirm the PFD assumptions. The change should not be installed until the SIL verification gap is understood.
2. The SIF is called SIL 2 but has a PFDavg of 4×10⁻². What does that imply, and what would you require to close the gap?
Read the worked answer
SIL 2 requires a PFDavg between 1×10⁻³ and 1×10⁻². A PFDavg of 4×10⁻² is in the SIL 1 range, so the installed SIF does not meet its stated SIL 2 target. With only one independent protection layer credited in the LOPA, this is a material deficiency, not a documentation issue.
The gap can be closed by reducing the proof-test interval, improving proof-test coverage, reducing the beta factor, or redesigning the SIF. PFDavg from undetected failures is roughly proportional to the proof-test interval, so reducing the interval from 12 months to 3 months would reduce that contribution by about four, approaching 1×10⁻². That is still marginal, and it assumes the proof test actually detects the dangerous failures. With 70% proof-test coverage, a substantial fraction of dangerous failures remain undetected. A better solution is to raise proof-test coverage to at least 90% by testing the valve stroke and exhaust damper response, add diagnostics that are proven by the vendor to detect dangerous failures, and reduce common cause by separating the two channels' network paths or using an independent hardwired trip. The revised design should be verified by calculation and by test, and the LOPA should be updated if the credited PFD changes.
3. How should common cause and proof testing be addressed after the firmware change?
Read the worked answer
The shared Ethernet backplane and the new common network library increase the potential for common-cause failure between the two CPU channels. A beta factor of 5% may no longer be valid. The site should obtain the vendor's common-cause data for the new library, review whether the channels remain sufficiently independent, and consider architectural separation - for example, separate network segments or an independent hardwired shutdown path. If independence cannot be demonstrated, the beta factor should be increased in the SIL calculation, which will raise PFDavg and may force additional risk reduction.
Proof testing must be updated to match the new diagnostics and firmware behavior. The test procedure should verify the full SIF response, including sensor input, logic, valve closure, and exhaust start, and should record actual response time. Test coverage assumptions should be justified by failure modes, not by the existence of a test procedure. The test interval should be re-derived from the target PFD, and overdue tests should be treated as a mechanical-integrity deficiency. Finally, the site should establish a firmware and configuration baseline, control future updates through MOC, and retain vendor certificates and test records for audit.