NB/T 20054-2011Nuclear power plants - Instrumentation and control system important to safety - Software aspects for computer-based system performing category A functions (English PDF)

Foreword

This document was issued on 1 July 2011 by the National Energy Administration of the PRC and takes effect on 1 October 2011.

It is a NB/T standard: recommended rather than compulsory, but it is the text a Chinese reviewer applies when assessing a submission.

It is classified under ICS 27.120.99, Chinese classification F 82.

It replaces EJ/T 1058-1998, which is superseded.

This standard was drafted in accordance with the rules given in GB/T 1.1-2009.

This standard replaces EJ/T 1058-1998, Computer software for nuclear power plant safety systems, and EJ/T 1058.2-2005, Computer software for nuclear power plant safety systems, Part 2: Defence against software induced common cause failure, software tools and use of pre-developed software.

This standard is based mainly on EJ/T 1058-1998 and integrates part of the content of EJ/T 1058.2-2005. Compared with EJ/T 1058-1998 and EJ/T 1058.2-2005, apart from editorial modifications, the main technical changes are as follows.

The terms and definitions have been updated.

Symbols and abbreviations have been added.

Detailed content related to software V and V (verification and validation) has been added.

Requirements related to software common mode failure have been added.

Requirements related to software qualification have been added.

This standard is a modified adoption of IEC 60880:2006, Nuclear power plants, instrumentation and control systems important to safety, software aspects for computer-based systems performing category A functions, using the redrafting method.

Compared with IEC 60880:2006, the structure of this standard has been considerably adjusted. Annex A gives a comparison table of the clause and subclause numbering of this standard and of IEC 60880:2006.

There are technical deviations between this standard and IEC 60880:2006. The main technical deviations are listed in the following paragraphs.

Common and easily understood terms and their definitions have been deleted, namely computer, computer program, data, initialization, safety function and software version.

In order to facilitate understanding, the terms robustness and security and their definitions have been added.

In order to suit the technical conditions of China, GB/T 16260 (all parts) is used in Clause 2, Normative references, in place of ISO/IEC 9126 (all parts). The degree of correspondence between the individual parts of the two standards is given in the following four paragraphs.

GB/T 16260.1-2006, Software engineering, Product quality, Part 1: Quality model (ISO/IEC 9126-1:2001, IDT).

GB/T 16260.2-2006, Software engineering, Product quality, Part 2: External metrics (ISO/IEC TR 9126-2:2003, IDT).

GB/T 16260.3-2006, Software engineering, Product quality, Part 3: Internal metrics (ISO/IEC TR 9126-3:2003, IDT).

GB/T 16260.4-2006, Software engineering, Product quality, Part 4: Quality in use metrics (ISO/IEC TR 9126-4:2004, IDT).

There are also editorial modifications between this standard and IEC 60880:2006. The main editorial modifications are listed in the following paragraphs.

The fifth paragraph and the sixth paragraph of Clause 1 have been deleted.

The first paragraph of 5.6 has been deleted.

The first paragraph of Clause 7 has been deleted.

The first paragraph of 7.2.1 has been deleted.

The first paragraph of Clause 12 has been deleted.

The first paragraph of 12.4.1 has been deleted.

The first paragraph of Clause 13 has been deleted.

The first paragraph of 14.1 has been deleted.

The first paragraph of 14.3 has been deleted.

The first sentence of the first paragraph of 14.3.4 has been deleted, and the remaining content of that first paragraph has been given the new subclause number 14.3.4.1.

The first paragraph of 14.3.6 has been deleted.

The second paragraph of 15.3.3 has been deleted.

The first paragraph of 15.3.3.2 has been deleted.

Annex J of the source document has been deleted.

This standard was proposed by the Nuclear Power Standardization Technical Committee of the energy industry.

This standard is under the administration of the Nuclear Industry Standardization Research Institute.

Drafting organizations of this standard: China Nuclear Power Engineering Co., Ltd. and Beijing Guangli Nuclear System Engineering Co., Ltd.

Main drafters of this standard: Bian Hua, Liu Yue, Wang Yanjun, Wang Shaohua, Shi Guilian, Song Lixin, Zuo Xin, Zhang Zhihui and Lyu Xiuhong.

This standard replaces EJ/T 1058-1998 and EJ/T 1058.2-2005.

EJ/T 1058 was first published in March 1998; the present document constitutes its first revision.

EJ/T 1058.2 was first published in April 2005; the present document constitutes its first revision.

Publication data

Standard designation as printed on the cover: NB/T 20054-2011, an energy industry standard of the People's Republic of China issued by the National Energy Administration.

International Classification for Standards (ICS): 27.120.99. Chinese Standard Classification code (CCS): F 82. Record number (filing number): 32967-2011.

Date of issue: 1 July 2011. Date of implementation: 1 October 2011.

Chinese title on the cover: nuclear power plants, computer software for instrumentation and control systems important to safety performing category A functions.

English title as printed on the cover: Nuclear power plants-instrumentation and control system important to safety-software aspects for computer-based system performing category A functions.

This standard supersedes EJ/T 1058-1998 and EJ/T 1058.2-2005.

The standard was proposed by the Nuclear Power Standardization Technical Committee of the energy industry and is under the administration of the Nuclear Industry Standardization Research Institute.

Drafting organizations: China Nuclear Power Engineering Co., Ltd. and Beijing Guangli Nuclear System Engineering Co., Ltd.

Main drafters: Bian Hua, Liu Yue, Wang Yanjun, Wang Shaohua, Shi Guilian, Song Lixin, Zuo Xin, Zhang Zhihui, Lyu Xiuhong.

Publication history of the replaced standards: EJ/T 1058 was first published in March 1998 and this is its first revision; EJ/T 1058.2 was first published in April 2005 and this is its first revision.

The body of the standard comprises 15 clauses, 10 annexes (A to J) and a bibliography, and runs to page 80 of the printed edition.

Structure of the document

The requirements of the standard are set out in fifteen clauses followed by ten annexes and a bibliography, as listed in the official table of contents reproduced below.

Clause 6, Software requirements, covers the software requirements specification (6.1), self-supervision (6.2), periodic testing (6.3) and documentation (6.4), from page 11 to page 12.

Clause 7, Design and implementation, covers the principles of design and implementation (7.1), languages and the supporting translators and tools (7.2), specific recommendations (7.3) and documentation (7.4), from page 13 to page 16.

Clause 8, Software verification, covers the software verification process (8.1) and software verification activities (8.2), from page 16 to page 18.

Clause 9, Software aspects of system integration, covers general provisions (9.1), the software related parts of the system integration plan (9.2), system integration (9.3), verification of the integrated system (9.4), the defect resolution procedure (9.5) and the software part of the integrated system verification report (9.6), from page 19 to page 21.

Clause 10, Software aspects of system validation, covers general provisions (10.1), the software aspects of the system validation plan (10.2), system validation (10.3), the software aspects of the system validation report (10.4) and the defect resolution procedure (10.5), from page 21 to page 22.

Clause 11, Software modification, covers general provisions (11.1), the modification request process (11.2), the execution process of software modification (11.3) and software modification after delivery for use (11.4), from page 22 to page 24.

Clause 12, Software aspects of installation and operation, covers site installation of the software (12.1), site software security (12.2), adaptation of the software to the site environment (12.3) and training of operating personnel (12.4), on page 25.

Clause 13, Defence against software common cause failure, covers general provisions (13.1), software design for the prevention of CCF (13.2), the causes and effects of software induced CCF (13.3), the achievement of diversity (13.4) and the balance of the advantages and drawbacks related to the use of diversity (13.5), from page 26 to page 28.

Clause 14, Software tools for software development, covers general provisions (14.1), the selection of tools (14.2) and the requirements for tools (14.3), from page 28 to page 31.

Clause 15, Quality qualification of pre-developed software, covers an overview (15.1), general requirements (15.2), the assessment and evaluation process (15.3) and the requirements for the integration and modification of PDS in the system (15.4), from page 32 to page 38.

Annex A, informative, gives the structural changes of this standard compared with IEC 60880:2006, from page 39.

Annex B, normative, gives the software safety life cycle and the detailed software requirements, from page 45.

Annex C, normative, gives the detailed requirements and recommendations applicable to the design and implementation process, from page 47.

Annex D, informative, gives an example of application-oriented software engineering, from page 58.

Annex E, informative, deals with languages, translators and link editors, from page 61.

Annex F, informative, deals with software verification and testing, from page 64.

Annex G, informative, gives a typical list of software documents, from page 71.

Annex H, informative, lists the matters to be considered in relation to common cause failure and diversity, from page 72.

Annex I, informative, lists the tools used for preparing and checking technical specifications, design and implementation, from page 76.

Annex J, informative, gives the requirements concerning pre-developed software (PDS), from page 78.

The bibliography closes the document on page 80.

1 Scope

NB/T 20054-2011 governs the software of computer-based instrumentation and control systems performing category A functions in a nuclear power plant - the highest safety category, covering the reactor protection system and the other functions whose failure would directly threaten safety. It is a modified adoption of IEC 60880:2006, and it replaces EJ/T 1058-1998 and EJ/T 1058.2-2005. Software at this level cannot be qualified by testing alone, so the standard governs the process that produces it. It defines the terms and abbreviations, then sets requirements across the whole lifecycle: the software requirements specification and its traceability to the system safety requirements, the design and its structure, the coding rules and the restricted language subsets permitted, the verification performed at each stage, the integration and the validation testing, and the installation and commissioning on site. It addresses the qualification of pre-developed software and of software tools, the defence against common cause failure and the diversity that follows from it, the handling of self-supervision and of failure detection, the configuration management and change control applied during and after development, and the documentation that must exist for an assessor to judge the result. Security against unauthorised modification and the requirements on the organisations and personnel involved complete the standard. It applies to nuclear plants in China.

This standard specifies the requirements for the computer software of instrumentation and control (I and C) systems important to safety in nuclear power plants that perform category A functions.

This standard is applicable to software for which high reliability is to be obtained, and it covers every stage of the generation and documentation process of the software, including the requirements specification, design, implementation, verification, validation and operation.

2 Normative references

The following documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

GB/T 5204, Periodic tests and monitoring of the safety systems of nuclear power plants.

GB/T 15474-2010, Classification of instrumentation and control functions important to safety in nuclear power plants (IEC 61226:2005, MOD).

GB/T 16260 (all parts), Software engineering, Product quality (ISO/IEC 9126, all parts).

NB/T 20026-2010, General requirements for instrumentation and control systems important to safety in nuclear power plants (IEC 61513:2001, IDT).

HAD 102/17, Safety assessment and verification for nuclear power plants.

HAF 102, Design safety regulations for nuclear power plants.

IAEA NS-G-1.3, Instrumentation and control systems important to safety in nuclear power plants.

3 Terms and definitions

The following terms and definitions apply to this document.

3.1 animation: the process of displaying the behaviour defined in a specification by means of the actual values obtained from specified behaviour expressions and from certain input values.

3.2 application function: function of an I and C system that performs a task related to the controlled process and not related to the functioning of the system itself. Source: NB/T 20026-2010, definition 3.1.

3.3 application-oriented language: computer language designed specifically for a certain class of application and used by the relevant experts. Source: NB/T 20053-2011, definition 3.3. Note 1: equipment families commonly use application-oriented languages so that functions can be adjusted to suit specific needs. Note 2: an application-oriented language may be used to specify the functional requirements of an I and C system and to specify or design application software; it may be text based or graphical, or both. Note 3: an example is the function block diagram language defined by IEC 61131-3.

3.4 application software: the part of the software of an I and C system that implements the application functions. Source: NB/T 20026-2010, definition 3.2.

3.5 automated code generation: function of an automatic tool that converts an application-oriented language into a code form that can be compiled or executed.

3.6 channel: arrangement of interconnected components within a system that issues a single output signal; the channel terminates at the point where the single output signal is combined with a signal from another channel, for example a monitoring channel or a safety actuation channel. Source: IAEA NS-G-1.3, glossary.

3.7 code compaction: deliberate reduction of the memory space required by a program by eliminating redundant or extra instructions.

3.8 common cause failure: failure of two or more structures, systems or components arising from a single specific event or cause. Source: IAEA NS-G-1.3, glossary.

3.9 computer-based system: I and C system whose functions depend mainly or entirely on the use of microprocessors, programmable electronic devices or computers. Source: NB/T 20026-2010, definition 3.10. Note: equivalent to digital system, software-based system or programmable system.

3.10 defence in depth: the implementation, for a specified safety objective, of more than one means of protection, so that the safety objective can still be achieved even if one of the means of protection fails.

3.11 diversity: characteristic of achieving a specified objective by two or more different ways or means. Diversity is used specifically to defend against common cause failure. It may be achieved by systems that are physically different from each other or by functional diversity. Functional diversity means using similar systems that achieve the specified objective in different ways. Source: NB/T 20026-2010, definition 3.16.

3.12 dynamic analysis: the process of evaluating a system or component on the basis of its behaviour during execution; the counterpart of static analysis.

3.13 failure: the phenomenon whereby the service delivered deviates from the expected service. Source: NB/T 20026-2010, definition 3.21.

3.14 fault: defect in a hardware, software or system component. Source: NB/T 20026-2010, definition 3.22.

3.15 fault tolerance: the inherent capability of a system to continue to operate correctly in the presence of a limited number of hardware or software failures.

3.16 functional diversity: the application of diversity at the functional level for the same initiating event, for example using both a pressure limit value and a temperature limit value as the conditions that trigger an emergency reactor trip.

3.17 general-purpose language: computer language designed to solve problems of all types. Source: NB/T 20053-2011, definition 3.17. Note 1: the operating system software of an equipment family is generally implemented in a general-purpose language. Note 2: examples are Ada, C and Pascal.

3.18 human error: human action that leads to an unintended result.

3.19 integration tests: tests carried out during the integration of hardware and software, before validation of the computer system, used to verify the compatibility between the software and the hardware of the computer system.

3.20 library: collection of related software elements grouped together by category but selected individually into the final software product.

3.21 N-version software: a group of different programs developed to meet the same requirements and the same acceptance tests, commonly called a combination of versions. These versions are usually executed independently and simultaneously on redundant hardware. The same inputs are used in a test system, or consistent inputs are used in a redundant system. A predetermined strategy, for example voting, is used to judge the inconsistencies between the outputs of the different versions.

3.22 operational system software: software that runs on the target processor during operation, for example software used for input and output drivers, services, interrupt management, schedulers, communication drivers, application-oriented libraries, on-line diagnostics, and redundancy and degradation management.

3.23 postulated initiating event: event identified at the design stage that can lead to anticipated operational occurrences or accident conditions. Source: HAF 102, glossary.

3.24 pre-developed software: existing software, obtainable as a commercial or proprietary product, that is used for a computer-based system. Source: NB/T 20026-2010, definition 3.42.

3.25 redundancy: the provision of additional structures, systems or components, identical or different, such that any one of them can perform the required function irrespective of whether the others are in an operating state or in a failed state. Source: IAEA NS-G-1.3, glossary.

3.26 robustness: the characteristic of maintaining certain performance under a given parametric perturbation of the control system, in structure or in magnitude; that is, the sturdiness of the system, which is the key to its survival under abnormal and hazardous conditions. One aspect of the robustness of a control system is its capability to keep a given performance index unchanged under certain types of disturbance, including disturbance of its own model.

3.27 role-based access control: a form of rule-based access control in which the access permission rules are directed at groups of users having the same role rather than at objects, functions or data defined by individual users.

3.28 safety system: system important to safety provided to ensure the safe shutdown of the reactor, the removal of residual heat from the core, or the limitation of the consequences of anticipated operational occurrences and accident conditions. Source: HAF 102, glossary.

3.29 signal trajectory: the time history of all equipment states, internal states, input signals and operator inputs that determine the outputs of the system.

3.30 software: the programs, that is ordered sets of instructions, the data, the rules and all the associated documentation related to the operation of a computer-based I and C system.

3.31 software development: the phase of the software life cycle in which the software of an I and C system or a software product is generated. It covers all the activities from the software requirements specification through to software validation and site installation.

3.32 software modification: modification of an approved document or set of documents where that modification leads to a change of the executable code. Note: software modification may occur both in the early development period, for example to correct faults found in later development phases, and during the software operation phase.

3.33 software safety life cycle: the necessary activities involved in the development or operation of the software of I and C systems important to safety, covering the period from the software requirements specification produced at the conceptual design stage until the software is no longer used. Source: NB/T 20053-2011, definition 3.30.

3.34 specification: document that specifies, in a complete, accurate and verifiable manner, the requirements, design, performance or other characteristics of a system or component; usually the document also specifies the procedures for determining whether these provisions have been satisfied. Note: there are different kinds of technical specification, such as the software requirements specification and the design specification.

3.35 static analysis: the process of evaluating a system or component on the basis of its form, structure, content or documentary records; the counterpart of dynamic analysis.

3.36 system software: the part of the software of an I and C system designed for a specific computer or equipment family that facilitates the development, operation and modification of the computer system and of its associated programs. It is software designed for a specific computer system or family of computer systems that facilitates the operation and maintenance of the computer system and of its associated programs, for example operating systems, compilers and utility programs. System software usually consists of operational system software and support software, see Figure 2. Source: NB/T 20026-2010, definition 3.64.

3.37 system validation: confirmation, by examination and by the provision of other evidence, that the system fully satisfies the intended requirements specification in terms of functions, response time, fault tolerance and robustness.

3.38 verification: confirmation, by examination and by the provision of objective evidence, that the results of a given activity of a process conform to the objectives and requirements specified for that activity.

3.39 security: the protection of computer hardware and software against accidental or malicious access, use, modification, destruction or disclosure. Security also concerns the protection of persons, data and communications and the physical protection of computer installations. Source: NB/T 20026-2010, definition 3.54.

4 Abbreviations

The following abbreviations apply to this document.

CASE: computer aided software engineering.

CCF: common cause failure, see 3.8.

I and C: instrumentation and control.

PDS: pre-developed software, see 3.24.

PIE: postulated initiating event, see 3.23.

V and V: verification and validation.

5 General requirements for the software project

5.1 Overview. NB/T 20026-2010 defines the generation process of the I and C systems of nuclear power plants and introduces the concept of the system safety life cycle. On the basis of this concept the development process of the software becomes controllable, and its adoption makes it possible to demonstrate reasonably the operation of the safety systems. The system safety life cycle described in NB/T 20026-2010 includes requirements concerning the project arrangement and organization for system generation, but these are not mandatory requirements, as shown in Figure 1.

For computer-based, that is digital, systems, the system safety life cycle further introduces the concept of the software safety life cycle, whose activities are shown in Figure 2. It describes how hardware and software are developed in parallel on the basis of the same specification and are brought together at the integration and installation stages of the life cycle.

The following processes support the development process of each stage of software production: software project management, see 5.4; software quality assurance and quality control, see 5.5; software configuration management, see 5.6; software security, see 5.7; software verification, see Clause 8.

At the same time the supporting processes include the selection of languages, see 7.2 and Annex E, the selection of tools supporting software development, see Clause 14, the prevention of CCF, see Clause 13, and the production of documentation, see 7.4 and Annex G.

Figure 1, Activities related to the system safety life cycle, shows the following chain of activities: system requirements specification; selection of existing equipment or of an equipment family; suitability analysis; system specification; detailed system design and implementation, which comprises application software development and generation, procurement of equipment, that is system software and hardware, and development of new system software and hardware features; functional validation; system integration; system validation; system installation; system modification.

Figure 2, Software related activities within the system safety life cycle, shows the activities related to the target software and the supporting processes. The numbers in brackets in the heavy-line boxes indicate the numbers of the relevant clauses and subclauses of this standard.

The supporting processes shown along the left-hand side of Figure 2 are: software quality assurance (5.5); software verification (8); software configuration management (5.6); selection and use of software tools (14); language selection (7.2); software security (5.7).

The main chain shown in Figure 2 is: system requirements specification; selection of pre-developed software (15.2); suitability analysis of pre-developed software (15.3); system specification; detailed system design and implementation, comprising application software development and generation (7), procurement of equipment, that is system software and hardware, and development of new operational system software (7); functional validation; software aspects of system integration (9, 15.4); software aspects of system validation (10); software aspects of system installation (12.1); software aspects of system modification (11). Note: the dashed boxes indicate activities not covered by this standard.

The method used for software development should be based on the traditional V model. Some development processes may be carried out automatically by tools, and the software development process may be an iterative process in which the necessary adjustments are permitted.

Subclauses 5.2 and 5.3 introduce the different software types and development methods covered by this standard.

5.2 Software types. The software components of the system are usually defined either as operational system software, covering communication, input and output management, standard functions, self-supervision and so on, or as application software, covering interlock logic, control loops, display formats, alarm logic and so on.

Application software usually uses the services provided by the operational system software. This reduces the need to duplicate code in the modules and therefore reduces the total amount of software.

Application software is usually specific to a single engineering project, whereas operational system software can be used for different engineering projects.

Many system designs make extensive use of configuration data. Configuration data may be related to the operational system software and may also be related to the application software. The configuration data related to the application software consists mainly of the plant engineering data produced by the plant design, and these data are usually compiled by plant design personnel who do not need to possess software skills.

Configuration data are divided into two categories. The first consists of data items that cannot be modified on line by plant operating personnel; these data items are subject to the same requirements as the other parts of the software. The second consists of parameters, that is data items that can be modified by operating personnel during plant operation, for example alarm limit values, setpoints and the data required to calibrate instruments; specific requirements apply to this category of data items.

Many modern I and C equipment platforms provide a large number of development tools that allow system engineers to carry out the design and to produce executable code by means of those tools.

For example, a typical I and C system developed using the components of an equipment family includes the following: pre-developed software components such as the operational system software kernel and application function libraries, which are usually developed in a general-purpose language; the configuration data needed to make the operational system software kernel suitable for the input and output environment and for the services required by the application programs; application software developed using an application-oriented language.

5.3 Software development methods. Software is usually of the greatest importance for the functions performed by an I and C system. Software may also support additional functions introduced by the system design, for example the initialization and supervision of hardware and the communication and synchronization between subsystems. Therefore, in most cases the software safety life cycle is integrated with the system safety life cycle. It should be pointed out in particular that the software requirements specification is a part of, or is directly derived from, the system specification and the system design.

Although the verification of new software components is undoubtedly part of the software safety life cycle, there is usually no clear boundary between software integration and system integration, and the two are not separated. Therefore this standard considers software integration as a part of system integration. Likewise, software validation is not a purely software activity: in this standard it is regarded as a part of system integration and of system validation.

This standard assumes that the software life cycle originally used for the development of general-purpose language software is also suitable for development using application-oriented languages and for the configuration of pre-developed software.

However, because the specialized subprocesses introduced at the implementation stage differ in the following cases, the software development processes are different: implementation using a general-purpose language; implementation using an application-oriented language and the associated code generator; selection, use and configuration of pre-developed software products.

The activities application software development and generation and development of new operational system software shown in Figure 2 represent the principal and extremely important parts of the software safety life cycle. Figure 3 illustrates in more detail, by means of examples, the activities between the software requirements specification and software validation, and clearly shows the three different implementation paths. The numbers in brackets in Figure 3 are the numbers of the relevant clauses and subclauses of this standard.

Supplementary requirements for the software are given in Annex C.

The principles reflected in the requirements of this standard are related to the quality of the final code, and these principles are applicable whether a general-purpose language is used or the code or configuration is developed using an application-oriented language with automated code generation.

Figure 3, Development activities of the software safety life cycle, shows the following V-shaped arrangement: software requirements specification (6) with verification (8); software design (7) with verification (8); implementation of new software using a general-purpose language (7.1.2) with verification (8); implementation of new software using an application-oriented language (7.1.3) with verification (8); configuration of pre-developed software (7.1.4) with verification (8); software aspects of system integration (9) with verification (8); software aspects of system validation (10).

5.4 Software project management. 5.4.1 Any software project shall consist of a number of phases. Each phase is to a certain extent independent, but it also depends on the other phases and, conversely, the other phases depend on it. A process is described for a software project by defining its phases and the associated activities; in this standard that process is called software development. It is generally recognized that, if the requirements of the last paragraph of the introductory part of Clause 6 of NB/T 20026-2010 are satisfied, the process is an iterative process.

5.4.2 The activities to be carried out in each development phase shall be determined on the basis of the software development method selected for the project, see 5.2 and 5.3.

5.4.3 The software development activities shall cover the whole software safety life cycle.

5.4.4 Each software development phase referred to in 5.4.1 shall be divided into clearly defined activities.

5.4.5 Each software development phase shall produce formal documents, and no already defined phase shall be neglected.

5.4.6 When a software development activity is carried out automatically by means of a software tool, the automated activity shall be documented, and the documentation shall include the input and output documents associated with that phase.

5.4.7 The inputs and outputs of each phase shall be determined and documented.

5.4.8 Every output of every phase shall be checked systematically, see C.2.3 and C.5.7.

5.4.9 Each phase shall generate the appropriate documents, see Annex G.

5.4.10 Each phase shall be concluded systematically by a review that includes the checking of the relevant documentation.

5.4.11 A list of the documents necessary for the whole safety life cycle shall be established during software development. Annex G gives a typical list.

5.5 Software quality assurance plan. 5.5.1 A quality assurance plan shall be established at an early stage of the software safety life cycle. If the principles established by this standard are satisfied, a dedicated quality assurance plan may be adopted for individual product phases or for special software components on the basis of national or enterprise standards.

5.5.2 Any deviation from the requirements of this standard and of its normative annexes shall be identified and its rationality demonstrated.

5.5.3 If the methods used for quality assurance differ from the requirements of the normative annexes, documentation and review shall be carried out in accordance with the requirements of the main text of this standard.

5.5.4 Particular consideration shall be given to the influence of the software quality assurance plan actually used on the I and C system and on the software.

5.5.5 The quality assurance plan shall discuss all the technical procedures necessary for each phase of the software safety life cycle.

5.5.6 The quality assurance plan shall require that the activities of each phase be implemented by competent personnel and that adequate resources be provided for them.

5.5.7 The quality assurance plan shall require that modifications made to approved documents be confirmed, reviewed and approved by authorized personnel.

5.5.8 The quality assurance plan shall determine and document the methods, languages, tools, rules and standards used, and these shall be understood and mastered by the personnel concerned.

5.5.9 When several methods, languages, tools, rules or standards are used, the quality assurance plan shall require that it be made explicit which of them is used for each activity.

5.5.10 The quality assurance plan shall require the clear definition of the terminology, forms of representation, abbreviations and customary expressions specific to the project.

5.5.11 The quality assurance plan shall require that any quality problem be tracked and resolved.

5.5.12 The application of the quality assurance plan shall be recorded.

5.5.13 Each verification step or review step shall generate a report on the analyses carried out, the conclusions drawn and the agreed resolution schemes, and that report shall be included in the documentation.

5.5.14 Documentary material shall be provided for any deviation from the quality assurance plan in order to demonstrate its rationality.

5.6 Configuration management. Note: subclause 6.2.1.2 of NB/T 20026-2010, the system configuration management plan, gives the configuration management requirements at I and C system level. The present subclause states the specific or particularly important supplementary requirements applicable to the software.

5.6.1 Software configuration management shall be carried out in accordance with the provisions of the configuration management plan or of the quality assurance plan.

5.6.2 These provisions shall be consistent with the configuration management provisions at system level.

5.6.3 In order to satisfy the requirements of 5.6.4 to 5.6.12, a documented software configuration management procedure shall be established at an early stage in the life cycle of the software project.

5.6.4 Each production version of each software entity shall be uniquely identified.

5.6.5 It shall be possible to identify all the relevant versions of all the software documents associated with each software entity.

5.6.6 Software under development shall be kept separate from software already released or in the verified state.

5.6.7 It shall be possible to identify the versions of all the software entities that together constitute the complete version of the final product.

5.6.8 It shall be possible to verify the integrity of the software entities.

5.6.9 It shall be possible to identify the software versions in the target system.

5.6.10 All the software entities affected by a software modification shall be traceable.

5.6.11 Access to all the software entities under configuration management shall be subject to appropriate control, in order to ensure that the software is not modified by unauthorized personnel and to preserve the security capability of the software.

5.6.12 It shall be possible to determine all the translation tools and tool versions used to generate each executable entity, see 14.3.3.

5.7 Software security. 5.7.1 General. The objective of security is to protect the software and the data from being read or modified by unauthorized persons and systems, without denying access to authorized persons and systems.

Subclauses 5.4.2 and 6.2.2 of NB/T 20026-2010 state the security requirements applicable to the architecture of the I and C system and to the individual I and C systems.

Although the use of software gives rise to certain potential threats to security, the principal countermeasures are usually taken at system level, for example physical protection measures and hard-wired interlocking devices. The security requirements placed on the software help to reduce the weak links of the software and can support the protective measures taken at system level.

The present subclause states the specific and particularly important security requirements applicable to the software.

5.7.2 Security analysis. 5.7.2.1 The potential threats of the software to security shall be analysed, taking into account the relevant phases of the system safety life cycle and of the software safety life cycle. The analysis shall determine, on the basis of the requirements of 5.7, the requirements concerning the protection and the accessibility of the data and of the software.

5.7.2.2 The security analysis of the software shall be taken into account in the quality assurance plan of the software or of the system and in the security plan of the software or of the system.

5.7.2.3 If the analysis shows that the countermeasures taken at system level are insufficient, the security analysis shall determine the requirements for software design countermeasures.

5.7.3 Security design. 5.7.3.1 The requirements for the software design countermeasures determined by the security analysis shall be included in the software design requirements.

5.7.3.2 The design of any new software shall reduce the weak links of the system to the greatest extent possible.

5.7.3.3 Any pre-developed software shall be configured and parameterized so as to be able to minimize the weak links of the system, for example by minimizing the functions to those that are necessary, or by making use of the existing security functions of the software.

5.7.3.4 Operating personnel shall be prevented from modifying storage programs.

5.7.3.5 If it is necessary for operating personnel to access and modify data so that the I and C function can operate, the human machine interface equipment shall restrict such access to the necessary extent.

5.7.3.6 In order to counter possible threats to security, effective protective measures shall be included in the design, configuration and parameter assignment associated with the software functions listed in this subclause, among which the printed pages read include selective user access control for the software functions and data connections with systems of lower safety importance. The enumeration continues on the following pages of the printed standard, which lie outside the pages examined here.