Methodology of the review of software for safety important systems

Transcription

1 G. I. Schueller, P. Kafka (eds). Safety and Reliability. Proceedings of ESREL 99 The Tenth European Conference on Safety and Reliability, Munich Garching, Germany, September 1999, pp Methodology of the review of software for safety important systems S.A.Vilkomir & V. S. Kharchenko State Scientific and Technical Center on Nuclear and Radiation Safety, Kharkov, Ukraine ABSTRACT: This paper presents a methodology of the review of software during licensing of important for safety computer systems at nuclear power plants (NPPs). The basis of this methodology is an assessment of fulfilment of the requirements to software at various phases of the software life cycle. The contents of such requirements are formulated. It is proposed to unite these requirements in five criteria: completeness, documentation, intelligibility, independence, and conformity. The standard list of stages of the software review is developed. The problems, which have arisen at practical activities on software review of computer systems at Ukrainian NPPs, are analysed. 1 INRODUCTION The term "review" is understood in a broad sense in the present paper, as an assessment of software features. In principle, such assessment can be conducted by the user or buyer of the computer system or by the developer of software, for example, during verification of But often the influence of possible software errors on reliability and safety can be extremely significant, that requires an independent review of software, including the assessment of process of its creation and verification. In all countries with the advanced atomic energetics there are special state regulatory bodies, whose basic task - independent control of observance of nuclear and radiation safety. In particular, at deployment of a new computer control system at NPP the regulatory bodies carry out the review and licensing of such system and issue the sanction on its use. In Ukraine such works are carried out by Nuclear Regulatory Administration (NRA) and State Scientific and Technical Center on Nuclear and Radiation Safety (SSTC NRS) (Vilkomir & Zhidok 1995). The present paper is devoted to the methodology of the software review during licensing of important for safety systems at NPPs. 2 THE PLACE OF THE SOFTWARE REVIEW IN THE GENERAL LICENSING PROCESS The assessment of all phases of the development cycle of computer systems is carried out during licensing: phases of the technical requirements, designing, testing (verification). Thus hardware, software and system as whole are estimated. The approach to the software review has the peculiarities in various countries depending on particular conditions and capabilities. The situation at NPPs of Ukraine is characterized by the active process of modernizing and commissioning of computer information and control systems. Thus the value of the software review in the general process of licensing increases, that is provoked by two following tendencies: 1. Using of a series of identical computer systems at various NPPs. 2. Using of computer systems of various assignments, constructed on the basis of a unified set of hardware and software units. The example of the first tendency is commissioning of the Rod Group and Individual Control System at South-Ukrainian-1 NPP and Khmelnitsky-1 NPP in There are minor distinctions in these systems at various NPPs because of different features of each NPP. Such distinctions in the main reveal itself in modifications of software units. Therefore at the review of the repeatedly introduced system, the main attention is

2 given to the assessment of modified or new software units. The example of the second tendency is commissioning of the Unit Information System and the Safety Parameters Display Systems at South- Ukrainian-1, Zaporozhye-5, Khmelnitsky-1, and Chernobyl-3 NPPs in All these systems are constructed on the basis of a set of WDPF modules, elaborated by Westinghouse (USA). The distinctions between these systems reveal themselves in quantity of one-type means and in different functional Therefore, since the review of second from the sequence of systems, the volume of the software review in the total volume of review activities increases. 3 ELEMENTS OF THE METHODOLOGY OF THE SOFTWARE REVIEW 3.1 Basic purposes and principles The purpose of the software review is the check of its conformity to criteria, norms and rules of safety. This check is carried out by the analysis of the documentation, submitted to the review. Both the working documentation (for example, materials of the project) and documents released by the developer specially for the purposes of licensing (for example, the safety analysis report) can be considered. There can also be necessity in representation of additional information by the developer during the review for the explanation of problems not enough completely stated in the basic documentation. The second important purpose of the activity of the experts is the influence on increasing of the safety level of For achievement of this purpose, all remarks and recommendations of the experts should be transmitted to the developers for the operating elimination of detected defects. The used methods can include also the assessment by realization of additional independent testing. The inspections, audits, walkthroughs are also applied. The basis of the methodology of the software review is the assessment of the fulfilment of the requirements to software at various phases of the life cycle. It is necessary to evaluate the fulfilment of functional and general requirements to software (see section 3.1) and also requirements to verification (see section 3.2). The functional requirements we understand as the requirement on the fulfilment by software of system functions. The general requirements are laid to software of all important for safety systems, irrespective of their functionality. Such requirements are determined, for example, in the IEC-880 standard (IEC 1986), former USSR standards GOST (GOST 1991) and GOST (GOST 1985) and other normative documents. It is proposed to unite requirements in five criteria: completeness, documentation, intelligibility, independence, and conformity. It is possible to set conformity of criteria and the estimated requirements as a matrix. The results of the review are also convenient for representing in the table, which contains individual evaluations of the fulfilment of the separate requirements and total evaluations on criteria. The main for software is the criterion of completeness: software should be sufficient for the fulfilment of all functions of the system and correspond to all requirements of the specifications, standards and other normative documents. 3.2 General requirements to software The general requirements to software detail the criterion of completeness and are its constituent. The general requirements are following: 1. Software should have the well-defined modular structure. 2. For the safety system software, the use of operating system and interrupts should be restricted. 3. Software should carry out self-supervision. 4. Software should carry out diagnostics of hardware. 5. Software should allow carrying out periodic testing of system functions. 6. Software should check up on the input data and carry out the protection from distortions of the input data. 7. Software should provide the protection against failures of hardware. 8. Software should provide the protection against errors of the personnel. 9. Software should provide the protection against the non-authorized access. 10. Software should carry out the protection against common mode failures, including failures because of software errors. The last requirement is one of the most important general requirements. For the protection against common mode failures the application of the following approaches (Kharchenko 1997) is possible: 1. The use of two various digital systems (basic and diversion) for the fulfilment of the same functions, but constructed on various hardware and 2. The use of the various software versions in various channels of the system for the fulfilment of the same function. 3. The use of more than one criteria for each situation, when the action of the system is needed (functional redundancy). The use of the latter approach means, that each emergency situation (the initial event) should be found out in several ways on various physically

3 interconnected technological parameters. The data processing on these parameters should be fulfilled by various software modules in various hardware units. If such approach is used, it is necessary to be convinced at the review that during software testing the developer checked up in detail and proved the achievement of functional independence. 3.3 Requirement to the software verification The main requirements (criteria) to the software verification are the following: 1. The software conformity to all requirements of the specifications, standards and other normative documents (criterion of completeness) should be tested during verification. 2. The criterion of independence should be observed during verification. Software of safety systems needs complete independence, when testing is carried out by the division, which administratively and financially does not depend on the division - developer of For software of important for safety systems (but not safety systems), the partial independence is admissible, when the development and testing of software can be carried out by the various experts of the same division. 3. The verification plan and report should be released (criterion of documentation). The independent parts of the verification plan and report (testing programs, testing procedures etc.) can be released as the separate documents. 4. The documentation on the software verification should be stated in the form, clear for experts not participating in the software development and verification (criterion of intelligibility). The following requirements detail the criterion of completeness: 1. Verification should be conducted after each phase of the software life cycle: the phase of the requirements development, the design phase, the phase of coding. 2. If automatic tools for the code generation are used during the software development, these tools should be verified with the same requirements, as system 3. The protection against common mode failures, including failures because of software errors, should be especially checked. The potential sources of common mode failures should be reflected and their possible influence should be considered. 4. If predeveloped software (earlier developed for other systems and already has been verified) is used, it is sufficient to verify only modified parts of 5. If predeveloped software, the documentation on which is inaccessible in the full volume, is used, it is necessary to evaluate the experience of operation of such The application of such software for safety systems is accepted only in specially stipulated cases. 6. If the configuration of software units is used, verification should consist of two parts: verification of standard units and verification of configuration data. 4 STAGES OF THE SOFTWARE REVIEW Before the beginning of control system licensing the plan of the review is established. This plan covers as well the software assessment. The schedule of the review is established, including deadlines of representation by the developer of the concrete software documents. The plan of the assessment of software includes: 1. The brief description of the subject of the assessment. 2. Criteria, on which the assessment is conducted. 3. The list of methods and actions which are carried out during the assessment. The plan of the software review should contain a detailed list of review stages, which is taking into account specificity of the considered system and its The standard content of such list for software review stages at all phases of software life cycle is offered below. At the phase of the software requirements, the review contains the following three stages: 1. The evaluation of conformity of the software requirements to the system requirements. 2. The evaluation of the reflection of general software requirements in the software requirements specifications. 3. The transfer of the remarks to the developer and obtaining the corrected and supplemented software requirements. At the phase of the software project, the review contains the following four stages: 1. The evaluation of the reflection of the requirements to software in the project documentation. 2. The analysis of the software structure for the protection against common mode failures, including failures because of software errors. 3. Working out of the detailed software requirements and functions list on the base on the design documentation for using at further review stages. 4. The transfer of the remarks to the developer. At the phase of the verification plan, the review contains the following five stages: 1. The evaluation of availability of the programs and procedures of software testing. 2. The evaluation of intelligibility of the verification plan.

4 3. The evaluation of the reflection of the detailed requirements to software, composed at the previous stage of review, in the verification plan. 4. The evaluation of completeness and sufficiency of the volume of tests, including in the verification plan. Working out, if necessary, propositions on additional testing for most important for safety functions. 5. The transfer of the remarks and additions to the developer and obtaining the corrected and supplemented verification plan. At the phase of the verification report, the review contains the following six stages: 1. The evaluation of availability of the verification reports for each programs and procedures of software testing. 2. The evaluation of completeness of the executed tests. 3. The evaluation of independence of verification. 4. The assessment of tools, applied at software development and verification. 5. The evaluation of conformity of all tests. 6. The issue of the final experts' report and recommendations to the regulatory bodies about possibility of software use. The phases of the software verification plan and report are the most important. Just at these phases the regulatory bodies have an opportunity to be convinced of achievement of a required degree of software quality, reliability and safety. Thus the direct influence of regulatory bodies and experts on increase of the safety level is possible. For this purpose the plans and programs of software testing are estimated prior to the testing beginning. Both the additions and remarks are transferred to the software developer for the consideration and elimination. At realization of software testing, the developer takes into account the requirements of regulatory bodies and experts on safety. 5 PRACTICAL EXPERIENCE OF THE SOFTWARE REVIEW OF SYSTEMS, INTRODUCED INTO UKRAINIAN NPPS The approach to the software assessment, described in the previous sections, is applied at SSTC NRS at the review of the following systems (Vilkomir & Zhidok 1998): 1. Rod Group and Individual Control System of Skoda-Controls (Czech Republic) at South- Ukrainian-1 NPP and Khmelnitsky-1 NPP. 2. Turbine Control System of Shevchenko Plant (Ukraine) for Zaporozhye-1 NPP. 3. Safety Parameters Display System of Westinghouse (USA) at Zaporozhye-5 NPP, Khmelnitsky-1 NPP and Chernobyl-3 NPP. 4. Unit Information System of WESTRON (Ukraine-USA) at South-Ukrainian-1 NPP and others. The experience of software assessments allows selecting problems, which happen in the practical works. In some cases, initial requirements to software (software requirements specifications) are stated not enough in detail in documentation or even are absent. Thereby, it is difficult to separate the requirements to software from requirements to system as a whole. So, it obstructs the assessment of testing completeness. The second defect is the formal approach to working out of software testing reports. In such cases, finding software errors and defects are corrected and checked back, but this is not documented duly. So only final positive results are present at testing reports. In some cases experts have made remarks, which required the revision of software testing plans. To typical examples pertain: 1. The absence of testing on some software functions. Basically, there are auxiliary functions such as the self-supervision function and so on. 2. During testing of the complex logical software functions the limited number of test data sets is used, not covering the variety of possible situations. The experience of practical works has also shown need of the use of special software tools during the review. Such tools could: 1. Relieve the work with big volume of the documentation and the check to its coherence and completeness. 2. Allow the experts to conduct their own dynamic testing and static analysis of the part of 6 CONCLUSIONS The offered methodology of the software review allows carrying out the assessment of software during licensing of important for safety systems at NPPs. This methodology can be adapted to software assessment for other critical application systems. The commissioning of digital control systems at the Ukrainian NPPs is extended. It is planned to deploy digital protection systems - the most important for safety systems at NPPs. It does the problem of development of the methodology of the software review important and actual. REFERENCES GOST Unified system of standards of computer control systems. Computer control systems. General requirements. Moscow. (In Russian). GOST Nuclear instrumentation systems for nuclear power stations. General requirements. Moscow. (In Russian).

5 IEC-880 Std Software for computers in the safety systems of nuclear power stations. International Electrotechnical Commission (IEC). Kharchenko, V.S Choice of design technologies and basic architectures for the defect-tolerant digital control and computing real-time systems. Space Science and Technology. 3(5/6): (In Russian). Vilkomir, S.A. & Zhidok, G.I Software for nuclear power-generating unit protection systems: safety and reliability problem. Control Systems and Machines. 4/5: (In Russian). Vilkomir, S.A. & Zhidok, G.I Experience of licensing of software for digital safety related systems in Ukraine. Project Control for 2000 and Beyond. Proceedings of ESCOM-ENCRESS 98, May 1998, Rome, Italy: