1 Introduction
1.1 General
1.1.1 Computer based systems are of increasing importance to safety in nuclear power plants as their use in plants is rapidly increasing. They are used both in safety related systems, such as some functions of the process control and monitoring systems, as well as in systems important to safety, such as reactor protection or actuation of safety facilities. The dependability of computer based systems important to safety is therefore of prime interest and shall be ensured.
1.1.2 With current technology, it is possible in principle to develop computer based instrumentation and control systems for systems important to safety that have the potential for improving the level of safety and reliability with sufficient dependability. However, their dependability can be predicted and demonstrated only if a systematic, fully documented and reviewable engineering process is followed. The development of software for computer based systems important to safety in nuclear power plants shall comply with the issued regulations, guides and standards dealing with software engineering and quality assurance.
1.2 Objective
The objective of the Safety Guide is to provide guidance on the collection of evidence and preparation of documentation to be used in the safety demonstration for the software for computer based systems important to safety in nuclear power plants, for all phases of the system life cycle.
1.3 Scope
1.3.1 The Safety Guide is applicable to systems important to safety as defined in relevant nuclear safety regulations. Since at present the reliability of a computer based system cannot be predicted on the sole basis of, or built in by, the design process, it is not allowed to agree systematically on any possible relaxation in the Safety Guide to apply to software for safety related systems. Whenever possible, software which applies only to safety systems and not to safety related systems are explicitly identified.
1.3.2 The Safety Guide relates primarily to the software used in computer based systems important to safety. Guidance on the other aspects of computer based systems, such as those concerned with the design and operation of the computer based system itself and its hardware, is limited to the issues raised by the development, verification and validation of software, and are beyond the scope of the Safety Guide.
1.3.3 The main focus of the Safety Guide is on the preparation of documentation that is used for an adequate demonstration of the safety and reliability of computer based systems important to safety.
1.3.4 The Safety Guide applies to all types of software: pre-existing software or firmware (such as an operating system), software to be specifically developed for the project, or software to be developed from a pre-existing equipment family of hardware or software modules. The issue of the use for safety functions of pre-existing or existing commercial software, on the development of which little information is available, is addressed in Annex A.
1.3.5 The Safety Guide is intended for use by those involved in the production, assessment and licensing of computer based systems, including plant system designers, software designers and programmers, verifiers, validators, certifiers and regulators, as well as plant operators.
2 Technical Considerations for Computer Based Systems
2.1 Characteristics of computer based systems
2.1.1 In relation to the assessment of safety and reliability, computer based systems have two basic properties. They are programmable and their hardware is based on discrete digital logic. As with other systems, hardware faults may be due to errors in design or manufacturing, but typically they result from wearing out, degradation or environmental processes, and are of a random nature. Software, the programmable part of the computer, does not wear out, but it may be affected by changes in the operating environment. Software faults may result from either bad or unclear specification of requirements (which gives rise to errors in the logical design or implementation) or errors introduced during the implementation phase or maintenance phase.
2.1.2 The programmable nature of computer based systems coupled with the discrete logic means that they have a number of advantages over non-digital and non-programmable systems. They facilitate the achievement of complex functions; in particular, they can provide improved monitoring of plant variables, improved operator interfaces, improved testing, calibration, self-checking, and fault diagnosis facilities. They can also provide greater accuracy and stability. The use of multiplexed ‘bus’ structures may lead to a reduced need for cabling. Software modifications require less physical disruption of equipment, which will facilitate maintenance.
2.1.3 These advantages are counterbalanced by a number of disadvantages. Software implementation tends to be more complex and therefore more prone to design errors than implementation of purely hardware systems. Moreover, software implementations are discrete logic models of the real world. This has two types of consequences. Software is more sensitive (i.e. less tolerant) to ‘small’ errors. It is also more difficult to test, because interpolation and extrapolation are much more difficult to apply to computer based systems than to traditional analog systems, and ultimately are not entirely valid.
2.2 Development process
2.2.1 The development of systems important to safety shall be a process controlled step by step. It is by nature an iterative process. In this approach, the development process is organized as an ordered collection of distinct phases. Each phase uses information developed in earlier phases and provides input information for later phases. As the design progresses, faults and omissions made in the earlier stages become apparent and necessitate attention on the earlier stages. An essential feature of this approach is that the products of each development phase are verified against the requirements of the previous phase. At certain phases of the development a validation process is carried out to confirm compliance of the product with all functional requirements and non-functional requirements and the absence of unintended behavior.
2.2.2 Typical phases of the development process and an outline of the process that may be applied are shown in Figure 1. The boxes in the figure show the development activities to be performed and the arrows show the intended order and the primary information flow. The numbers in parentheses in Figure 1 indicate the sections of the Safety Guide in which the development activities and products are described. Activities without numbers are not within the scope of the Safety Guide. Figure 2 illustrates the relationship of verification and validation to the requirements, design and implementation. The choice of the particular development activities and their order in these figures are not intended to require a particular method of development; variations of the method may also have the necessary attributes and be capable of meeting the requirements.
Figure 1 Development of Software for Computer Based Systems Important to Safety
(Numbers in parentheses refer to sections of the Safety Guide)
2.2.3 The development of the computer based system shall start with an analysis of the plant and system requirements carried out by engineering specialists, including safety engineers and software engineers. On the basis of the results of this analysis, the requirements for the computer based system are derived. Iterations are normally needed in this analysis before a final set of requirements is identified. There shall be a clear demonstration of a systematic derivation since omissions at this stage may result in an incorrect specification of requirements for the safety provisions and hence may result in an unsafe system.
2.2.4 The first design decision shall be to apportion the requirements for the computer based system between the computer system and conventional electrical and electronic equipment for measuring plant variables and actuating the control devices (other components). The designer may have reasons to opt for analog equipment to implement certain functional requirements .
2.2.5 The computer system requirements are apportioned between the software requirements and the computer hardware in computer system design. The software is then designed as a set of interacting modules (software design) which are coded and tested as programs that will run on the computer hardware (software implementation). Next, the software is integrated with the computer hardware to produce the computer system (computer system integration). Finally, the computer system is installed in the plant for commissioning and operation. One of the steps of the commissioning phase is the integration of the computer system with the other components (which is part of the system integration phase).
Figure 2 Verification, Validation and Commissioning
(numbers in parentheses refer to sections of the Safety Guide)
2.3 Safety and reliability issues
2.3.1 Because of the disadvantages mentioned earlier, the quantitative evaluation of the reliability of software based systems is more difficult than that for non-programmable systems and this may raise specific difficulties in demonstrating the expected safety of a computer based system. Quantitative indicators of high software reliability are not demonstrable at the present time. Hence, designs requiring a single computer based system to achieve probabilities of failure on demand of lower than 10–4 for the software shall be treated with caution.
2.3.2 Since software faults are systematic rather than random in nature, common cause failure of computer based safety systems employing redundant subsystems using identical copies of the software is a critical issue. Countermeasures are not easy to implement. Designers shall adopt independence and diversity and a comprehensive qualification strategy to protect against common cause failures. However, it may be difficult to estimate the degree of success and the benefits of these strategies when software is involved.
2.3.3 With current technology, it is possible in principle to develop computer based instrumentation and control systems with the necessary dependability for systems important to safety and to demonstrate their safety sufficiently. However, dependability can only be demonstrated if a careful and fully documented process is followed. This process may include the evaluation of operating experience with pre-existing software, following specific requirements (see also Annex A). Recommendations for achieving an adequate safety demonstration are given in the Safety Guide.
2.4 Organizational and legal issues
2.4.1 There are various organizational and legal aspects of the development project for a computer based system that shall be carefully taken into consideration at a very early stage of the project in order to ensure its success. They include such factors as the availability of a suitable legal and administrative framework for licensing computer based systems important to safety and sufficient competence and resources within the organizations involved in the system development process. If these factors are not carefully considered at the conceptual design stage of the project, its schedule and costs may be considerably affected. Some of these factors may influence the decision to use programmable digital technology, making this option impractical or even prohibitively expensive.
2.4.2 Quantification of software reliability is an unresolved issue. Software testing will be limited. The quantification of software reliability for computer based systems may be difficult or impossible to demonstrate. The regulatory position concerning the safety demonstration and reliability required of software shall be clarified early in the project planning stage. The approach to be followed to deal with the safety and reliability issues shall be determined, documented, made available to and if necessary agreed upon by the regulator. This may include specific regulatory hold points.
2.4.3 It shall be ensured that sufficient competence and resources are available in the regulatory organization, the licensee’s design team, the nuclear safety regulator’s technical support staff and the supplier to fulfill the recommendations for the software development process and the assessment of its safety demonstration. The licensee shall also ensure that the supplier of the computer and/or software will be prepared to release all proprietary information that would be needed for the licensing process.
2.4.4 The licensee (i.e. the user of the computer system) shall establish an appropriate organization to deal with operational and maintenance issues. Occasionally, the licensee may need its own team to perform post-delivery modifications on the software. This team shall have the same level of competence and equipment as would have been provided by the original producer.
3 Application of Requirements for Management of Computer Based System Safety
3.1 General
The majority of requirements for management of safety developed for traditional instrumentation and control systems are applicable to computer based systems. However, the application of these requirements for management of safety to computer based systems, in view of the differences between software and hardware, is not always straightforward and has, in many cases, new implications. Chapter 3 provides a brief overview of relevant requirements for management of safety, on issues related to requirements for design, design and development, management and quality assurance, and documentation. These requirements for management of safety form the basis for deriving the basic requirements of the computer based systems, especially the non-functional requirements. Documentation shall be of high quality, owing to its importance in the design of software and in the safety demonstration.
3.2 Requirements for management of safety
3.2.1 Simplicity in design
3.2.1.1 It shall be demonstrated that all unnecessary complexity has been avoided both in the functionality of the system and in its implementation. This demonstration is important to safety and is not straightforward, as digital programmable technology is adopted for the achievement of more complex functionality. Evidence of obedience to a structured design, to a programming discipline and to coding rules shall be part of this demonstration.
3.2.1.2 For safety systems, the functional requirements that are to be fulfilled by a computer system shall all be essential to the achievement of safety functions; safety-related functions shall be separated from and shown not to impact the safety functions.
3.2.1.3 For computer based system development, top-down decomposition, levels of abstraction and modular structure are important concepts for coping with the problems of unavoidable complexity. They not only allow the system developer to tackle several smaller, more manageable problems, but also allow a more effective review by the verifier. The logic structure behind the system modularization and the definition of interfaces shall be made as simple as possible, for example by applying “information hiding”.
3.2.1.4 In the design of system modules, simpler algorithms shall be chosen over complex ones. Simplicity shall not be sacrificed to achieve performance that is not required. The computer hardware used in safety systems shall be specified with sufficient capacity and performance to prevent software from becoming too complex.
3.2.2 Safety culture
The personnel working on a software development project for a system with a high safety importance shall include application specialists as well as computer software and hardware specialists. This combination of expertise helps to ensure that safety requirements, which are generally well known owing to the maturity of the industry, are effectively communicated to the computer specialists. It shall be ensured that all personnel understand how their jobs are related to the fulfillment of the safety requirements and they shall be encouraged to question activities or decisions that may compromise the safety of the system. This means that the software specialists shall also have a good understanding of the application. An appropriate specification language (e.g. a graphical language) can be used for the description of safety functions.
3.2.3 Safety classification scheme
A safety classification scheme to define the safety importance of the instrumentation and control system functions may be used for the system development process. It directs the appropriate degree of attention by the plant designers, operators and nuclear safety regulator to the specifications, design, qualification, quality assurance, manufacturing, installation, maintenance and testing (see 3.2.4) of the systems and equipment that ensure safety.
3.2.4 Balance between risk reduction and development effort
3.2.4.1 Trade-offs in the achievement of various conflicting design objectives shall be carefully assessed at each design stage for the system and its associated software. A top-down design and development process shall be used to facilitate this assessment. Graded design and qualification requirements, when applied to computer system functions, may be derived from a safety classification scheme (see 3.2.3). This gradation may be used in order to balance the design and qualification effort. The computer system shall meet the criteria for the highest safety class of the functions it is implementing.
3.2.4.2 Appropriate measures to warrant the level of confidence that is necessary shall be associated with each safety class. It shall be noted that for the hardware part of the system the confidence level can be assessed by using quantitative techniques; however, for software only qualitative assessment is possible.
3.2.5 Defense in depth
Defense in depth as applied in the design of nuclear power plants shall be used in the development of the computer based system and its associated software. If a software based system constitutes the main safety function, defense in depth shall be provided by means of a diverse secondary protection system.
3.2.6 Redundancy
Traditional design based on multiple redundant instrumentation channels with a voting arrangement, as commonly used in analog applications, has benefits for reliability of the hardware of computer systems. However, this type of redundancy does not prevent a failure of the system due to common cause faults in hardware and software design that could lead to impairment of all redundant channels.
3.2.7 Single failure criterion
The application of the single failure criterion to hardware random failures is straightforward: no single failure shall result in loss of the safety functions. However, in software this criterion is difficult to meet, since a fault that causes a software failure is necessarily present in all the replicas of this software (see 3.2.8).
3.2.8 Diversity
The reliability of computer based systems can be enhanced by using diversity to reduce the potential for software common cause failures. The use of diverse functions and system components at different levels of the design shall be considered. Diversity of methods, languages, tools and personnel shall also be taken into consideration. However, it shall be noted that although diverse software may provide improved protection against common cause failures, it does not guarantee the absence of coincident errors. The decision by the licensee whether to use diversity and the choice of type of diversity shall be justified.
3.2.9 Fail-safe design, supervision and fault tolerance
System fail-safe features, supervision and fault tolerant mechanisms shall be added into the software, but only to the extent that the additional complexity is justified by a demonstrable global increase in safety. When software is used to check the hardware it is running on, then its ability to respond correctly shall also be demonstrated. The use of external devices, such as watchdog timers, makes the system response to fault detection more dependable. Defensive design, the use of appropriate languages, including safe subsets and coding techniques, shall be used to ensure a safe response under all circumstances, as far as this is achievable. One goal of the computer system requirements phase shall be to completely specify the desired and safe response to all combinations of inputs.
3.2.10 Security
It shall be demonstrated that measures have been taken to protect the computer based system throughout its entire lifetime against physical attack, intentional and non-intentional intrusion, fraud, viruses and so on. Safety systems shall not be connected to external networks when justification cannot be made that it is safe to do so.
3.2.11 Maintainability
The computer based system shall be designed to facilitate the detection, location and diagnosis of failures so that the system can be repaired or replaced efficiently. Software that has a modular structure will be easier to repair and will also be easier to review and analyze, since the design can be easier to understand and easier to modify without introducing new errors. Software maintainability also includes the concept of making changes to the functionality. The design of a computer based system shall ensure that changes are confined to a small part of the software.
3.2.12 Full representation of operating modes
The requirements for and design of the software for systems important to safety shall explicitly define all relations between input and output for each of the operating modes. The software design shall be simple enough to permit consideration of all input combinations that represent all operating modes.
3.2.13 Human-machine interfaces and anticipation of human limitations
The design of human-machine interfaces may have a significant impact on safety. The human-machine interfaces shall be designed to provide the operator with a sufficient and structured but not an overwhelming amount of information, and also to provide sufficient time for reacting (see, for example, the thirty minute rule in relevant documentation). When functions are allocated to the operator, the computer system shall allow for the time needed to derive a manual action from the information provided. All operator inputs shall be checked for validity as a defense against impairment by operator error. The possibility of the operator overriding these validity checks shall be investigated carefully.
3.2.14 Demonstrable dependability
Not only shall the system be dependable, it shall also be possible to demonstrate to the regulator that it is dependable. The Safety Guide recommends to licensees how to achieve demonstrable dependability through design and qualification methods that improve traceability and through the production of adequate documents.
3.2.15 Testability
Each requirement and each design feature shall be expressed in such a manner that a test can be done to determine whether that feature has been implemented correctly. Both functional and non-functional requirements shall be testable. Test results shall be traceable back to the associated requirements.
3.3 Design and development activities
3.3.1 General
In determining the necessary design and development activities, particular attention shall be given to contents of 3.3.2~3.3.7.
3.3.2 Process controlled step by step
The design and development process shall be controlled step by step. This development process can give evidence of correctness by its very construction. This can also ease the verification process and ensure that errors are detected early in the design process.
3.3.3 Reviewability
Accurate and easily reviewable documentation shall be produced for all stages of the development process. The documentation used to demonstrate adequacy to the regulator shall be the same as the documentation actually used in the design.
3.3.4 Comprehensive testing
Comprehensive testing shall be applied. Testing is an important part of development, verification and validation. A demonstration of test coverage, including tracing of test cases to source documents (design specification and requirements specifications, etc.), shall be provided. The test results, demonstration of test coverage and other test records shall be available for third party audit. A comprehensive test plan shall be established and made available to the regulator at an early stage of the project.
3.3.5 Use of automated tools
All tools used shall be mutually compatible. The tools shall be qualified to a level commensurate with their function in the development of the software and in the safety demonstration. The techniques used to gain confidence in the tools shall be specified and documented.
3.3.6 Traceability
Requirements shall be traceable to design; design shall be traceable to code; requirements, design and code shall be traceable to tests. Traceability shall be maintained when changes are made. There shall also be traceability in the reverse direction, to ensure that no unintended functions have been created.
3.3.7 Compliance with standards
The requirements for management of safety, safety requirements and technical standards to be used in the development shall be identified. A compliance analysis shall be prepared for the key standard used in the specification and implementation of the computer system design.
3.4 Management and quality assurance
3.4.1 Clearly defined functions and qualifications of personnel
The plant management shall demonstrate to the nuclear safety regulator that the level of staffing is adequate. Management shall establish the functions and qualifications required of personnel involved in software design, production and maintenance, and shall ensure that only qualified and experienced personnel perform these functions. Personnel qualifications shall be established for each task within the software development and maintenance process, including the execution of the quality assurance program.
3.4.2 Acceptable practices
Well established methods, languages and tools for software development shall be used. Methods, languages and tools that are still at the research stage shall not be used.
3.4.3 Quality assurance program
The organization’s quality assurance program shall extend into the software development process and shall also cover configuration management and change control after the software is delivered. At least for safety systems, independent verification, validation and testing, with independent supporting audits, shall also be covered. The quality requirements for the software shall be described in a software quality assurance plan which shall be required by the quality assurance program.
3.4.4 Assignment of responsibilities
Interfaces shall be established between organizational entities within the design organization and between the design organization, its client (user) and other organizations involved in the system development process. Controls pertaining to design interfacing shall be established and shall include the assignment of responsibilities and the issue and transmission of documents to and from the interfacing organizations.
3.4.5 Third party assessment
3.4.5.1 Third party assessment shall be used for safety systems. Its scope and extent shall be defined in the quality assurance program. The team performing the quality assurance and the verification and validation tasks shall be independent of the development team. These issues are covered later in 3.4.5.2 and 4.4.6 of the Safety Guide.
3.4.5.2 The objective of the third party assessment is to provide a view on the adequacy of the system and its software which is independent of both the supplier and the user (the licensee). Such an assessment may be undertaken by the regulator or by a body acceptable to the regulator. It shall provide confidence in the production process of the licensee and suppliers. The assessment strategy, the competence and the knowledge of the project necessary for the third party assessment in order to provide the necessary level of confidence shall be carefully considered. In addition, third party assessment shall be agreed to by all parties (nuclear safety regulator, licensee, suppliers) so that the appropriate resources can be made available at the desired time. Some of the third party assessments shall involve examination of the process (e.g. through quality assurance audits and technical inspections). Other third party assessments shall include examination of the product (e.g. through static analysis, dynamic analysis, code and/or data inspection and test coverage analysis). The assessment of the final product shall (as far as possible, in view of time constraints) be undertaken on the final version of the software. This can include third party assessment of intermediate products of the development process, such as software specifications.
3.5 Documentation
3.5.1 General
3.5.1.1 For confidence in the reliability of a software product, evidence shall be provided of the soundness of the development process. The documentation is crucial in providing the ‘transparency’ and ‘traceability’ necessitated by this approach. Documentation for the design and implementation of a trustworthy software product shall be clear and precise.
3.5.1.2 The set of documents shall ensure the traceability of design decisions. Appropriate documents shall be produced at each step of the development process. Documentation shall be updated throughout the development, including commissioning and ongoing maintenance processes. The documents available to the regulator shall be identical to those used by the designers. The designer shall be informed of this early in the project.
3.5.1.3 Documentation of the requirements, the design and the code shall be clear and precise so that the designers, the programmers and the independent reviewers can comprehend fully every stage of the development and verify its completeness and correctness.
3.5.1.4 Good documentation is also essential to maintenance. The proper documentation format shall be used to reduce the likelihood of inconsistencies and errors in future maintenance related changes. Documents shall have the attributes of comprehensibility, preciseness, traceability and completeness, consistency, verifiability and modifiability, as described in 3.5.2~3.5.7.
3.5.2 Comprehensibility
Documentation shall be understandable by people with a variety of backgrounds and expertise. The language used shall be clear, and when it is formal (e.g. graphical forms), it shall have well defined syntax and semantics.
3.5.3 Preciseness
Requirements and designs shall be described formally with explanations given in natural language. There shall be only one possible interpretation of each description.
3.5.4 Traceability and completeness
3.5.4.1 The purpose of tracing is to demonstrate that the implementation is complete with respect to the computer system requirements and design, and to facilitate the detection of unsafe features in the implementation. Tracing from higher level documents to software documents checks completeness, and tracing back from software documents to higher level documents checks for unspecified items which might be unsafe. Every requirement shall be uniquely identified.
3.5.4.2 A traceability matrix (or matrices) shall be implemented that clearly shows the linkage between computer based system requirements and following items which implement each computer based system requirement in the computer system requirements analysis, the computer system design, the software requirements analysis, the software design and the software implementation. This matrix shall demonstrate complete test coverage of the requirements for the computer based system during implementation, integration, installation and commissioning.
1 Introduction
2 Technical Considerations for Computer Based Systems
3 Application of Requirements for Management of Computer Based System Safety
4 Project Planning
5 Computer System Requirements
6 Computer System Design
7 Software Requirements
8 Software Design
9 Software Implementation
10 Verification and Analysis
11 Computer System Integration
12 Validation of Computer System
13 Installation and Commissioning
14 Operation
15 Post-delivery Modifications
Annex A Use and Confirmation of Pre-existing and Existing Software
Annex B Term Explanation
