In September 2000, two documents were published simultaneously, both of which covered the issue of safety-critial computer software systems in nuclear power plants.
• The IAEA Safety Guide: Software for computer based systems important to safety in nuclear power plants, safety guide NS-G-1.1.
• The European Directorate General for the Environment produced report EUR 19265 EN: Common position of European nuclear regulators for the licensing of safety critical software for nuclear reactors.
The safety guide is a new safety guide of the agency, the first of its kind to focus specifically on software. The EUR report is a first consensus document from nuclear regulators on licensing practices specifically addressing safety critical software and produced under the auspices of an international institution.
The work on the safety guide was first initiated in April 1991, when the IAEA was made aware that its current guidelines did not address important software issues. This led to the publication in 1994 of the technical report 367 (2): “Software important to safety in nuclear power plants”, to which 15 experts contributed.
In April 1995, four experts met in Vienna in order to identify – on the basis of the technical report – the possible contents of a future safety guide. Their report advised the agency to focus on:
• Software issues.
• The interface between the regulator and the licensee.
• On guidelines, not on how to design, but on what is needed to demonstrate adequacy of the design.
There then followed a series of alternate advisory group meetings, technical group and consultant meetings. A fourth version of the document was submitted to the Agency Nuclear Safety Standards Advisory Committee in October 1997, and accepted as a draft for a safety guide project. A subsequent version was then sent to Member States for comments.
The EUR report started in a very similar manner to the safety guide, albeit within the smaller community of the European nuclear regulators.
The 1995-2000 activity programmes of the Nuclear Regulatory Working Group (NRWG) and of the Reactor Safety Working Group (RSWG) of the European Commission Directorate General XI (Environment, Nuclear Safety, and Civil Protection) were set up within the framework of the 1975 and 1992 resolutions of the Council of Ministers on the technological problems of nuclear safety.
The value of the documents
The documents are guidance documents that aim to meet specific needs not met by other standards.
The 1980s left the nuclear I&C community badly traumatised by several modernisation projects involving safety critical software that had experienced abnormal delays and costs.
The lack of experience of practical methods and of interactions between the nuclear and other industrial and software engineering communities were probably some of the causes of these problems.
Two observations emerged from out of these unfortunate experiences. If there was guidance available to design software based safety systems, then there was little or none available to address the specific issues that are raised by the licensing of highly critical software.
As far as software was concerned, regulators and licensees were abandoned to improvisation.
The second observation was that software is not per se either safe or unsafe. Software is only one component of the system. Checking the software is not sufficient, and it is dependent on the environment. The notions of computer safety case and of computer safety demonstration resulted from this observation and received increased attention.
This guidance:
• Addresses regulator and assessor concerns, potential sources of conflict in licensor/licensee negotiations, and identifies grounds for mutual agreement.
• Addresses the safety demonstration (safety case) rather than the system design.
• Emphasises the need for documentation and identifies sources of evidence.
Scope of the documents
Both documents address the software of systems important to safety as the IAEA guides define them, but focus on safety systems. Both documents recognise the difficulty of defining possible relaxations on requirements for safety related software based systems. However, whenever possible, both documents explicitly specify recommendations which apply only to safety systems, and thus indirectly admit possible relaxations for safety related system software.
The safety guide relaxations essentially concern security requirements against the external world, the nature of the independence required from the V&V teams, requirements on the specification of functional and non-functional safety requirements, requirements for statistically valid tests commensurate with the required reliability, and the dedication of safety systems to safety functions.
Moreover, the EU report allows additional relaxations on requirements for the assessment of pre-existing software, on dependability and documentation requirements for tools, on requirements for software produced by tools, on the required safety culture, on staffing levels, on computer system design (isolation, data protection), on programming and coding directives, on statistical testing, on software change control and maintenance, on calibration and testing requirements in operations.
Structure and contents
While the scopes of the two documents are identical, their structures differ. Their different structures reflect the fact that the safety guide emanated from designers, operators and regulators, while the EU report is more focused on the regulator’s viewpoint.
The EU report is organized around a selected set of technical issues which were considered difficult by the task force of regulators and of utmost importance to the licensing process. These issues cover a consistent set of licensing aspects right from the start of the life cycle up to and including commissioning.
These issues were divided into two main sets: generic licensing issues and life cycle phase licensing issues. Issues in the second group are related to a specific stage of design and development process, while those of the former group have more general implications, and apply to either several stages or to the whole system lifecycle.
The salient points
Both documents show consensus on certain prevention or precaution measures to deal with software that either always proved difficult, or are new because they are engendered by new software practices.
Automatic code generation
As far as licensing is concerned, there has always been a great deal of debate between proponents of systems generating code from application specifications and those more familiar with the classical development cycle.
The safety guide recommends: “Code can be produced from the system specifications in various ways that are essentially combinations of two distinct approaches: there is the classical development process through the different stages of specifications and design…, or in the use of code generating tools which receive as input a high level language application-oriented description of the system. The choice between these two approaches depends on the tools and resources available to the parties involved in the project, and should, in particular, take into account trade-offs between design and the demonstration of the dependability of tools.”
Regarding the code that is generated by tools, the safety guide says: “Software requirements are the subset of the computer system requirements that will ultimately be implemented as computer programs… The verification of the software requirements against the upper level requirements is an important step in the licensing process.
“If the computer system requirements are sufficiently detailed and their documentation is sufficiently formal, and if parts of the computer system design and of the code generated by tools, then a separate software requirement document may be unnecessary for those parts. However, those parts of such computer system requirements from which code is generated or reused should be regarded as a statement of software requirements against which subsequent code should be verified. Also, any separately compiled modules that are included by the code generator should be supported by separate documents for the software requirements.”
Software and code hazard analysis
The application of hazard analysis to software is still barely dealt with by international guidance. The safety guide has several recommendations.
• The computer based system and its interfaces to the plant should be evaluated at various phases of the development for potential contribution to hazards at plant level. When such potential critical behaviours are identified, they should be traced into the computer system design, the software design, and the code in order to identify parts of the design and of the software that require special design features.
• Hazards should be traced back into the requirements and should be incorporated into the plant safety analysis as appropriate.
• A documented demonstration should be provided that the software design addresses the hazards identified in previous analyses and the requirements that have been identified as important to safety.
Pre-existing software
The safety guide addresses the issue of pre-existing or commercial off-the-shelf software for safety functions. The EU report recognises that licensees may wish to make use of such software given that an appropriate assessment has been undertaken. Two of its sections deal with the issue: a specific one also reproduced as an annex in the safety guide, and another devoted to safety related systems. For safety systems, the EU report is clear: “For safety systems (category one), the PSW shall be subjected to the same assessment (analysis and review) of the final product (not of the production process) as new software developed for the application. If necessary, reverse engineering shall be performed to enable the full specification of the PSW to be evaluated.”
For safety related software, the EU report recognises that there are several possible sources of evidence that may be exploited. It says: “Simplicity is required for safety systems. Safety related systems can be more complex. For these latter systems, less information may be available on the development process and on the product. In certain cases, it might be possible to compensate for this lack of information by using evidence provided by functional testing and adequate operational feedback.”
Another source of evidence is suggested for safety related software. The EU report says: “In order to evaluate the possibility of relaxing certain requirements of the safety demonstration, as a minimum, the consequences of the potential modes of failure of the computer based system shall be evaluated. For instance, a failure mode analysis may show that certain relaxations are possible, when failures of the system can be anticipated and their efforts can be detected and corrected in time by other means.
Independent assessment
The nature of the independence required from assessors is a difficult issue. Absolute independence is mythical; besides, there are several types of independence, all of which are susceptible to jeopardise access to relevant information.
The safety guide makes the following distinctions and allows relaxations: “The teams that are performing V&V should be independent of the development team. The amount and type of independent V&V should be justified with respect to the safety class of the system. For example, financial independence may not be required for safety related systems. Independence includes:
• Technical independence. Done by different people, preferably using different techniques and tools.
• Management independence. Led and motivated by different people. The V&V team and the development team should have different management lines. Official communication between independent teams should be recorded.
• Financial independence. There should be a separate budget with restrictions on transfer of financial resources between development and V&V.
The EU report emphasises competence, but does not go as far as strictly requiring financial independence. It also recommends that for safety related systems, independent validation only might be needed, in contrast to the requirements for independent verification, validation and assessment defined for safety systems.
Demonstrable dependability
Both documents are more cautious than other international standards are. The safety guide emphasises the issue of dependability, but it avoids that of software reliability.
The safety guide says: “The system must not only be dependable, it must also be possible to demonstrate to the regulator that it is dependable. This safety guide is intended to guide licensees in how to achieve demonstrable dependability through design and qualification methods that improve traceability and through the production of adequate documents.”
In the section on software requirements, it says: “An overall software reliability target may be stated, but it should be understood that the achievement of such a target to demonstrate that quantitative reliability requirements for software have been met. Currently available methods do not provide results in which confidence can be placed at the level required for systems of the highest importance to safety. Therefore, this safety guide does not provide guidance on the use of software reliability models.”
By contrast, however, the EU report is uncompromising on this issue. It says: “It is recognised that the reliability of a computer-based safety system cannot be fully demonstrated by testing. Therefore, the demonstration of safety has to depend to some degree on the quality of the processes that are involved.”
However, at the same time, it recommends that the level of reliability required from the software should be explicitly stated, with the understanding that the achievement of a reliability level is less demonstrable than other requirements.”
Future work
Documents of this kind are never finally complete. Because they result from a consensus, they mark an important step forward, but they need to be revised as knowledge and technology advance.
When the EU report neared completion, the members of the task force identified a few important areas where they agreed that more knowledge or experience was needed to establish useful guidance.
Diversity/redundancy
•Regulator positions requirements for diversity at architecture level.
•Regulator positions on software diversity.
Software reliability
• Methods to obtain quantitative estimations.
• Regulator position to cope with situations where numbers cannot be obtained, although quantitative objectives exist for plant operations.
Structure of safety demonstration
• Contents of a safety demonstration.
• Organisation and structure for claims, sub-claims, arguments, and proofs.
Criteria to rank software based systems in safety categories
• Criteria such as the existence of redundant back-up, pure informative output or direct action, and the consequences of failure are required to be able to rank software based systems.
Explicit requirements and acceptance criteria for distinct sorts of software
• Code produced by application oriented code generation tools (issues of validation).
• Libraries.
• Input/output drivers.
• Run time and system software.
By way of independent confirmation, most of these topics were also included as research targets in the NRC proposed five-year research plan for digital I&C technology,
The value of the two documents lies in the consensus that they have achieved. Whatever the auspices are, consensus and common positions are always obtained at a given time, in a given context and on certain issues. They never dispense from adaptations and revisions.
They are, however, the only way to make progress, especially in those cases where there is uncertainty or where there is some knowledge or operational experience that is missing and a precautionary approach must be followed.
The work proved to be useful in different respects:
• To ensure that technical expertise could be shared among those who contributed.
• To be able to support the regulators in the pursuit of their national policies.
• To assist licensees in dealing with foreign manufacturers and suppliers.
• To help the designers to produce systems that anticipate licensing requirements and that are also portable.
