It is essential that all aspects of nuclear safety systems achieve high reliability standards. To measure their compliance it thus becomes necessary to quantize reliability. Traditionally, this was done by investigating lifetimes, probability of breakdowns, or likelihoods of events that would lead to device malfunction. A system’s reliability must be quantized before certification may be achieved.
Digital systems and software, such as those of computer based shutdown systems, present inherent difficulties in the certification. Traditional failure-rate calculations cannot be applied to non-physical systems as their failure methods are often not related to aging and wear [24].
However, there are analysis criteria and tools designed specifically for hardware and software of nuclear safety systems. It is always first essential to divide software programs into categories based upon their degree of criticality to safety. Standardized methods include STUK’s safety classes of Finland and the IEC’s Safety Integrity Level [64], [65]. The safety criticality determines the required reliability and necessary testing.
Once reliability requirements are found, the IEC recommends the Process Assessment Standard 15504, referred to as ‘SPICE’ [66]. Used mostly in the prequalification phase, SPICE assesses the capability level of each sub-process of the software [24]. SPICE follows a Preliminary Hazard Analysis (PHA) which defines user requirements for the application [66]. After PHA, there is a Failure Mode Effect Analysis (FMEA) which traces accidents back to their possible causes. This determines the most critical tests and evaluations, which SPICE then investigates.
2.7.1 Canadian Requirements
Canadian requirements for safety systems are summarized in CNSC R-8 document [6]. Canadian safety philosophy focuses on high performance requirements rather than specific methodologies [23]. The R-8 performance requirements focus on the effectiveness of the shutdown systems, but do have some requirements for the safety logic.
The R-8 contains 15 design basis events. Each design basis event must be readily identifiable through at least two different parameters [22]. The system must be able to operate autonomously, and must perform in a manner such that all requirements of the SDS are met. Further, the system must be self-diagnosing, notifying control room operators of any failures that might interfere with its function [22].
Canadian law dictates safety systems must adhere to the requirements for diversity and separation [22]. There must be redundant channels which are independent and physically separate. Like with SDS, the multiple, redundant safety systems must not be dependent upon one another in any way, and their functioning or malfunctioning must not interfere with the effectiveness of other safety systems [22].
2.7.2 Verification and Validation
V&V is a standardized concept in nuclear systems [45]. V&V provides a systematic means to determine the proper design and implementation of the system. It is divided into:
Verification: The system, as it has been designed, has been successfully realized and performs without error.
Validation: The design fulfills all user requirements, with capability demonstrated.
The V&V process is meant to provide substantial evidence that not only has ‘the work been done right’, but also that ‘the right work has been done’. USNRC guidelines for software V&V are outlined in NUREG-0800 [41]. This focuses on clear outlining of requirements, objectives of testing, design best practises, and testing methods.
Requirement Design Implementation System Test Integration Test Component Test Verification Validation
Figure 2.5: Simplified V&V Diagram
The V&V process for digital systems can be summarized with the ‘V-diagram’, as simplified in Figure 2.5. Each task on the left is related to tests on the right. Systematic testing ensures both the implementation and the design have been performed correctly.
Following Figure 2.5, the end requirements are specified first. These are the final criteria by against which the system will be held accountable. The design is then built off of these requirements. Implementation of the design is then performed and the system is thus realized.
Component testing then follows to ensure that the implementation has been performed to standard. Once each component is verified, integration tests confirm the design has been successfully realized. Finally, system tests examine whether the initial requirements, those created in the first task, have been fulfilled.
Physical models, such as HIL systems or the NPCTF, aid the V&V process as testing platforms. Being capable of testing components, their implementation, and their overall success on a physical process demonstrate design capability. As the NPCTF uses its physical dynamics, rather than modelling, less compatibility alterations need to be made, making it an ideal V&V platform for safety systems.
2.7.3 IEEE Std. 1012
IEEE Standard 1012 is the ‘IEEE Standard for System and Software Verification and Validation’ [31]. IEEE 1012 aids in:
a) Creation of requirements for software, and
b) Determining software conformity to said requirements
IEEE 1012 encompasses all aspects of the software including interaction with hardware and system requirements. Further, it outlines lifetime requirements for development, maintenance, and reuse [31]. It contains risk/hazard analysis outlines and determinants for integrity level (not to be confused nuclear safety integrity levels (SIL)) [31].
The IEEE 1012’s V&V effort requires documentation of objectives and methods used to satisfy them [31]. Each desired integrity level performs the same primary activities. At each objective, there are five to fifteen subtasks. Quantity of subtasks performed corresponds to the desired integrity level [31]. These primary steps and their descriptions are in Table 2.5.
Table 2.5: IEEE Std. 1012 Process Steps.
Task V&V Activity Description
1 Software Concept Describing the specific solution, avoiding false
assumptions, specifying system requirements in hardware, software, and HMI
2 Software Requirements
Specifies performance, interface, data definitions, human factors, installation and acceptance, operation and
maintenance
3 Software Design Uses task 2 to create a detailed design for each software component. Ensures design is correct, accurate, and complete.
4 Software Construction
Design is transformed into code, structures, and machine executables. Verifies this transformation is correct and complete.
5 Integration Test Each component (unit or module) is incrementally integrated. Assure system requirements allocated to software are valid.
6 Qualification Test Assure the integrated software product satisfies its requirements.
7 Software Acceptance Assure software satisfies acceptance criteria. Opportunity to allow customer to accept the produce.
8 Installation and Checkout
Tested in target environment.
9 Software Operation Evaluates impact of changes in operating environment. Assesses system changes and operating procedures.
10 Software Maintenance
Changed in response to need for system maintenance. Includes modifications, migration, and retirement.
11 Software Disposal Supervises deactivation or disassembly of software
product. Ensures elements are properly stored or destroyed as required.
Subtasks relate to traceability, criticality, and hazard, security, and risk analysis [43]. Each subtask in the standard further includes specific means of analysis.