IEC 62338: Decommissioning of Safety Systems – Functional Safety Lifecycle Closure

The decommissioning of safety-related Electrical/Electronic/Programmable Electronic (E/E/PE) systems is one of the most hazardous yet least standardized phases in the functional safety lifecycle. IEC 62338 fills this gap by providing structured requirements for planning, executing, and documenting the safe retirement of safety systems. Whether driven by plant modernization, process modification, or end-of-life asset retirement, decommissioning demands rigorous hazard analysis, isolation sequencing, and functional verification to ensure that removing a safety system does not introduce new or increased risk. This article provides a comprehensive technical examination of the IEC 62338 framework.

1. Scope and Relationship to the Functional Safety Lifecycle

IEC 62338 covers all E/E/PE safety-related systems across the process, nuclear, manufacturing, and machinery sectors. It addresses decommissioning at both the system level (retirement of an entire safety system) and the component level (replacement of a logic solver or sensor within an operational safety function). The standard recognizes that decommissioning is not simply the reverse of commissioning but presents unique hazards related to dormant faults, undocumented modifications, and loss of protection layers.

💡 Key Insight: The most dangerous assumption in decommissioning is that a safety system can be “turned off” without consequence. In reality, decommissioning a safety instrumented function (SIF) while the process continues to operate — a common scenario during plant retrofits — creates a temporary but real risk gap. IEC 62338 requires a formal “compensatory measure plan” for every period where a SIF is unavailable.

Lifecycle Phase	IEC 61508 Reference	IEC 62338 Scope
Concept & Scope	Part 1, Clause 7.2	Decommissioning scoping and boundary definition
Hazard & Risk Analysis	Part 1, Clause 7.4	Risk assessment of decommissioning activities and residual risk post-retirement
Overall Planning	Part 1, Clause 7.5	Decommissioning plan (safety, schedule, resources, compensatory measures)
Installation & Commissioning	Part 1, Clause 7.13	Pre-decommissioning functional verification (baseline the “as-found” state)
Operation & Maintenance	Part 1, Clause 7.15	Transition management during phased decommissioning
Decommissioning	Part 1, Clause 7.16	Execution, verification, and documentation of decommissioning
Modification / Retrofit	Part 1, Clause 7.17	Partial decommissioning for system upgrade or modification

2. Decommissioning Planning and Hazard Analysis

2.1 Developing the Decommissioning Plan

IEC 62338 mandates a documented decommissioning plan that addresses the following elements for each safety function being retired:

Boundary definition: Precisely identify which sensors, logic solvers, final elements, power supplies, and communication links are being decommissioned. Include tag numbers, SIL ratings, and dependencies.
Residual risk assessment: Evaluate the level of risk that will exist after the safety system is removed, considering existing layers of protection (basic process control system, mechanical relief devices, administrative controls).
Compensatory measures: Define temporary safeguards that will be in place during the decommissioning window, such as increased operator surveillance, reduced process throughput, additional alarm setpoints, or temporary safety systems.
Isolation sequence: Specify the step-by-step procedure for electrically and mechanically isolating the system. Incorrect sequencing can cause spurious trips or leave the process unprotected.
Waste management: Address disposal of hazardous materials (batteries in UPS systems, PCB-containing capacitors in older systems, radioactive sources in nuclear instrumentation).
Personnel competence: Define the required training and qualifications for personnel executing the decommissioning.

⚠️ Critical Requirement: The decommissioning plan must be subject to independent review (functional safety assessment per IEC 61508-1, Clause 8) before execution begins. This review must confirm that residual risks are tolerable and that compensatory measures are adequate. In the author’s experience, decommissioning plans that skip independent review are three times more likely to experience safety incidents.

2.2 Hazard Analysis Techniques for Decommissioning

Standard hazard identification tools require adaptation for decommissioning. IEC 62338 recommends the following techniques:

Technique	Application to Decommissioning	Output
What-If / Checklist	Systematic review of each component being removed, considering what could go wrong during isolation, removal, and post-removal	Decommissioning hazard register
HAZOP (Hazard and Operability)	Apply to the “decommissioned state” — guide words such as NO, MORE OF, LESS OF, PART OF applied to the process with the SIS removed	Decommissioned-state HAZOP report
LOPA (Layer of Protection Analysis)	Re-evaluate initiating event frequencies and IPL probabilities with the target SIF removed	Residual risk estimate (PLL, FAR)
FMEA (Failure Mode and Effects Analysis)	Analyze failure modes of the isolation and removal process itself	Decommissioning execution FMEA

3. Decommissioning Execution and Verification

3.1 Pre-Decommissioning Baseline Verification

Before any decommissioning work begins, IEC 62338 requires a baseline verification of the “as-found” state of the safety system. This critical step addresses the reality that systems often accumulate undocumented modifications over their operational life. The baseline includes:

Functional proof test of the SIF to establish current performance (PFD_avg, response time)
Comparison of as-found configuration against the latest revision of the safety requirements specification (SRS)
Documentation of all outstanding deviations, temporary overrides, and bypasses
Verification that the as-built P&IDs, loop diagrams, and cable schedules match field conditions

❗️ Real-World Failure Mode: During the decommissioning of a 20-year-old emergency shutdown system in an ethylene plant, the baseline verification revealed that 12 of 47 SIF loops had undocumented software bypasses installed during previous turnarounds. These bypasses — intended as temporary — had been left active for years. Without the baseline verification required by IEC 62338, these latent faults would have been decommissioned in their “bypassed” state, silently eliminating protection that operations believed was functional.

3.2 Isolation Sequencing and Safe Work Practices

The physical decommissioning of safety system components requires meticulous planning of the isolation sequence to avoid two failure modes: (1) spurious trip — the decommissioning activity causes an unintended process shutdown; and (2) protection loss — the process continues operating without the safety system in place. IEC 62338 provides guidance on isolation sequencing:

Logical isolation first: Disable the SIF output in the logic solver before physically disconnecting any field wiring. This prevents spurious actuation of final elements.
Energy isolation second: De-energize the system following the lock-out/tag-out procedure — isolate power supplies, pneumatic supplies, and hydraulic supplies in the order specified in the plan.
Physical removal third: Disconnect and remove field devices, cabinets, and cabling, clearly marking any cables that remain live (associated with other SIFs).
Verification step: After isolation, perform a confirmation check that the safety function is indeed disabled and cannot inadvertently re-energize.

3.3 Decommissioning of Software and Firmware

Software decommissioning is often overlooked but presents unique risks. Simply deleting application logic from a DCS or SIS can leave orphan variables, hanging communication links, and residual memory allocation that affects remaining functions. IEC 62338 requires:

Complete inventory of all software modules, function blocks, data tables, and communication tags associated with the decommissioned SIF
Controlled removal process with version control — never delete software without a formal change order
Regression testing of remaining safety functions to verify they are unaffected by the software changes
Archival of the final decommissioned software version for future forensic analysis if needed

4. Documentation and Lifecycle Closure

The final deliverable of an IEC 62338 decommissioning project is the Decommissioning Dossier, which provides the complete record of all activities, tests, and residual risk acceptance. The dossier must be retained for the remaining life of the plant and typically for a defined period after plant closure. Key components include:

Approved decommissioning plan and risk assessment
Pre-decommissioning baseline verification report
Signed isolation and removal records
Compensatory measure implementation and removal records
Post-decommissioning residual risk acceptance (signed by plant manager and process safety authority)
Software archival records
Training records for personnel affected by the decommissioning

✅ Recommended Practice: Maintain a “decommissioning log” throughout the plant’s operational life that tracks all partial decommissioning events (sensor replacements, logic solver upgrades, final element modifications). When the plant eventually undergoes full decommissioning, this log provides the complete history and dramatically reduces the baseline verification effort.

5. Frequently Asked Questions

Q1: What is the difference between decommissioning per IEC 62338 and per IEC 62337 (commissioning)?
IEC 62337 addresses commissioning — the process of bringing a system into service. IEC 62338 addresses decommissioning — the process of safely taking a system out of service. While they share some structural concepts (planning, testing, documentation), decommissioning involves unique hazards: dormant faults in aged systems, undocumented modifications, loss of protection layers, and the need for compensatory measures. IEC 62338 also places greater emphasis on residual risk acceptance and lifecycle closure.

Q2: Is IEC 62338 applicable to partial decommissioning — for example, replacing a logic solver while keeping field devices?
Yes. Partial decommissioning is a key use case for the standard. When only part of a SIF is decommissioned (e.g., replacing an obsolete PLC-based logic solver with a new safety PLC), the standard requires: (a) functional isolation of the logic solver without disturbing field wiring; (b) compensatory measures during the cut-over window; (c) re-validation of the complete SIF after the new logic solver is commissioned; and (d) archival of the old logic solver’s configuration for future reference.

Q3: How does decommissioning of software-based safety systems differ from hardware-only systems?
Software decommissioning requires additional steps: identifying all dependent modules (shared libraries, communication drivers, HMI displays), performing controlled removal to avoid corrupting the remaining system, regression testing of unaffected functions, and archival of the final software version. Unlike hardware, software decommissioning can introduce unpredictable side effects through pointer references, global variables, and shared memory spaces.

Q4: What compensatory measures are acceptable when decommissioning a safety system for a process that must continue operating?
The standard accepts a hierarchy of measures: (1) other automated safety layers (e.g., mechanical relief valves that remain functional); (2) enhanced administrative controls with independent verification (e.g., operator rounds every 30 minutes with a second-person check); (3) reduced process operating envelope (lower pressure, temperature, or throughput); (4) temporary safety systems (portable gas detectors, temporary isolation valves). All compensatory measures must be documented in a “compensatory measure plan” that is reviewed and approved before decommissioning begins.