Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62138:2018 โ Nuclear Power Plants โ Software Aspects for Computer-Based I&C Systems Performing Category B or C Functions
📋 Introduction and Scope
IEC 62138:2018 specifies software safety requirements for computer-based instrumentation and control (I&C) systems that perform safety category B or C functions in nuclear power plants, as defined by IEC 61226. It complements IEC 60880 (which covers category A functions) within the overall framework of IEC 61513 for nuclear I&C system safety.
The standard addresses the complete software safety lifecycle — from requirements specification through design, implementation, verification, validation, installation, operation, and modification. It applies to both application software (plant-specific) and system software (pre-developed platforms and operating systems), and covers software used in safety class 2 and class 3 I&C systems.
💡 Engineering Insight
The second edition (2018) introduced significant technical changes compared to the first edition (2004). The most impactful was the revised approach to pre-developed software qualification, reflecting the nuclear industry’s increasing reliance on commercial-off-the-shelf (COTS) components and software platforms. The 2018 edition provides much more detailed criteria for evidence of correctness, including specific requirements for operational experience documentation and functional suitability analysis.
The second edition (2018) introduced significant technical changes compared to the first edition (2004). The most impactful was the revised approach to pre-developed software qualification, reflecting the nuclear industry’s increasing reliance on commercial-off-the-shelf (COTS) components and software platforms. The 2018 edition provides much more detailed criteria for evidence of correctness, including specific requirements for operational experience documentation and functional suitability analysis.
📊 Key Concepts and Gradation Principles
IEC 62138:2018 is built on several foundational concepts that engineers must understand:
| Concept | Description | Engineering Implication |
|---|---|---|
| Safety Categories (B/C) | Category B functions are those whose failure could lead to a significant release of radioactive material. Category C functions are those whose failure could lead to a minor release. | Category B systems require more rigorous software verification and validation than Category C. |
| System Classes (2/3) | Class 2 systems perform category B functions; class 3 systems perform category C functions. | The requirements in Clause 6 are tagged as applicable to class 2, class 3, or both. |
| Gradation | The application of requirements is proportional to the safety significance of the function. | Not all requirements apply uniformly — the standard uses “shall” for mandatory requirements and distinguishes class-specific applicability. |
| Defence in Depth | Multiple layers of protection against software faults and common cause failures (CCF). | Software diversity and independence are required for CCF defence in class 2 systems. |
⚠️ Critical Consideration — Common Cause Failure (CCF)
The standard dedicates an entire subclause (6.12) to defences against common cause failure due to software. This is a unique aspect of nuclear safety software that distinguishes it from almost all other industrial software safety standards. The concern is that a latent software fault could simultaneously disable multiple redundant channels of an I&C system. Mitigation strategies include software diversity (different algorithms, different programming languages, different development teams), functional diversity, and defence-in-depth architecture.
The standard dedicates an entire subclause (6.12) to defences against common cause failure due to software. This is a unique aspect of nuclear safety software that distinguishes it from almost all other industrial software safety standards. The concern is that a latent software fault could simultaneously disable multiple redundant channels of an I&C system. Mitigation strategies include software diversity (different algorithms, different programming languages, different development teams), functional diversity, and defence-in-depth architecture.
⚙️ Software Lifecycle Requirements
The standard organizes software requirements around a structured safety lifecycle. Key engineering requirements include:
📋 Software Requirements Specification (Clause 6.4)
The requirements specification must be complete, unambiguous, verifiable, and traceable. For class 2 systems, the specification must be expressed using a formal or semi-formal notation (e.g., state diagrams, decision tables, or formal logic). The requirements must be traceable to the system requirements from IEC 61513.
💻 Software Design and Implementation (Clauses 6.5–6.6)
The design must be modular, hierarchical, and of limited complexity. For class 2 systems, the standard recommends the use of application-oriented languages (e.g., function block diagrams per IEC 61131-3) over general-purpose languages (C, C++) because they limit programming constructs and reduce the potential for coding errors. When general-purpose languages are used, additional verification measures are required including coding standards compliance, static analysis, and peer review.
🔍 Verification and Validation (Clauses 6.2.2, 6.7–6.8)
| Activity | Class 2 | Class 3 |
|---|---|---|
| Requirements Verification | Independent review + traceability analysis | Review |
| Design Verification | Independent review + simulation | Review |
| Code Verification | Static analysis + structural coverage (MC/DC) | Static analysis + statement coverage |
| Integration Testing | Functional + robustness + boundary value | Functional testing |
| Validation | Independent V&V team, full functional tests under simulated plant conditions | Functional tests |
| Verification Independence | Organizationally independent from design team | May be same organization, different individuals |
✅ Best Practice
A common source of non-conformance during IEC 62138 audits is the traceability matrix. The standard requires bidirectional traceability between system requirements, software requirements, design elements, code modules, test cases, and test results. We recommend establishing the traceability framework at project initiation (before any design work begins) and maintaining it as a living document throughout the lifecycle. Dedicated requirements management tools (e.g., DOORS, Jama) are strongly recommended for class 2 projects.
A common source of non-conformance during IEC 62138 audits is the traceability matrix. The standard requires bidirectional traceability between system requirements, software requirements, design elements, code modules, test cases, and test results. We recommend establishing the traceability framework at project initiation (before any design work begins) and maintaining it as a living document throughout the lifecycle. Dedicated requirements management tools (e.g., DOORS, Jama) are strongly recommended for class 2 projects.
🔧 Pre-developed Software Qualification
One of the most practically challenging aspects of IEC 62138:2018 is the qualification of pre-developed software (PDS) — software that already exists before the nuclear project begins and is being considered for use within safety-classified I&C systems.
The standard establishes a rigorous qualification process requiring documented evidence in four areas:
- Documentation for Safety: The PDS supplier must provide safety documentation including a description of the development process, verification activities, and known anomalies.
- Evidence of Correctness: This may include proven-in-use argument (≥ 2 years of satisfactory operational experience in a similar application), formal verification results, or extensive test data.
- Functional Suitability: The PDS must be evaluated to confirm that its functional capabilities match the nuclear application requirements.
- Digital Devices of Limited Functionality: For simple devices (e.g., microcontrollers without complex OS), IEC 62671 provides alternative qualification pathways.
⚠️ Practical Challenge
The “proven-in-use” argument is often the most contentious part of PDS qualification. The standard requires that operational experience be documented in a way that demonstrates the software’s behaviour in configurations relevant to the nuclear application. Generic “millions of hours of use in automotive applications” is generally not accepted without detailed analysis of how the usage profile, environmental conditions, and failure modes compare to the nuclear application.
The “proven-in-use” argument is often the most contentious part of PDS qualification. The standard requires that operational experience be documented in a way that demonstrates the software’s behaviour in configurations relevant to the nuclear application. Generic “millions of hours of use in automotive applications” is generally not accepted without detailed analysis of how the usage profile, environmental conditions, and failure modes compare to the nuclear application.
❓ Frequently Asked Questions
Q1: What is the relationship between IEC 62138 and IEC 61508?
IEC 62138 is the nuclear sector-specific implementation of the general safety standard IEC 61508-3 (software requirements). Annex C of IEC 62138 provides a detailed mapping between the two documents. In general, IEC 62138 requirements for class 2 systems correspond to SIL 2–3 of IEC 61508, while class 3 corresponds to SIL 1–2. However, IEC 62138 includes nuclear-specific requirements (e.g., CCF defence, independence of verification) that go beyond IEC 61508.
Q4: Does IEC 62138 apply to software used in nuclear instrumentation outside the reactor protection system?
Yes. The standard applies to all I&C systems performing category B or C safety functions, which includes balance-of-plant systems, radiation monitoring, spent fuel handling, and other safety-related instrumentation. It does not apply to non-safety I&C systems (class 4 / category NC), which may follow IEC 62645 or other appropriate standards.
Q3: Can I use an operating system like Linux in a class 2 safety system?
Using a general-purpose OS in a class 2 system is possible but extremely challenging from a qualification perspective. The standard’s requirements for pre-developed software (Clause 6.3) would apply to the entire OS kernel, libraries, and device drivers. In practice, most class 2 systems use either a small real-time OS with a well-defined safety case (e.g., VxWorks CERT), a bare-metal approach, or a qualified safety OS. Linux certification for class 2 has been attempted but rarely succeeds due to the complexity and the difficulty of providing the required evidence of correctness.
Q4: What are the documentation requirements for a class 2 software project?
Annex A of the standard provides a typical list of software documentation. Expect to produce: Software Safety Plan, Software Requirements Specification, Software Design Description, Source Code (with comments and header), Verification Reports (requirements, design, code), Integration Test Plan/Report, Validation Test Plan/Report, Configuration Management Plan, Anomaly Report Log, and Software Modification Procedure. For a typical class 2 project, the documentation volume can be 5–10 times the volume of the source code itself.
