- •Iaea safety standards
- •Objective
- •Structure
- •Relationship to other standards
- •2. Management systems for I&c design
- •2.8. The management systems for development of I&c systems should comply with the recommendations of Safety Guides gs-g-3.1, Ref. [5] and gs-g-3.5, Ref. [6].
- •Generic management system processes
- •Configuration management
- •2.15. All I&c configuration items and their associated configuration documents should be designated, given a unique identification, and placed under configuration control.
- •2.31. Insights gained from probabilistic safety assessments (psAs) should be considered in the design of I&c systems.
- •Documentation
- •2.33. Before I&c systems are declared operable their documentation should be complete and should reflect the as-built configuration.
- •2.34. I&c documentation should:
- •2.36. I&c documents should be grouped according to their primary or secondary role in the design process.
- •2.38. Documentation for I&c systems and components should, as a minimum, cover the following topics:
- •3. Design bases
- •Inputs to I&c design bases
- •Identification of I&c functions
- •3.4. The required functions of the I&c systems should be determined as part of the nuclear power plant design process.
- •Content of I&c design bases
- •3.7. The overall I&c system architecture and each I&c system should have a design basis.
- •3.9. The I&c systems required for the safety of the plant should be identified systematically.
- •3.10. I&c system design bases should specify the following:
- •3.12. In addition to the above the design basis for the reactor protection system should specify the following:
- •Variables and states that must be displayed so that the operators can confirm the operation of protective system functions;
- •4. Guidance for overall I&c system architecture architectural design
- •4.3. The overall I&c architecture should:
- •4.4. The inputs to the overall I&c architecture design process should refer to the plant safety design basis documents, which should provide the following information:
- •Defence in depth
- •4.28. When diverse I&c systems are provided to meet requirements for defence-in-depth, the diverse systems should not both be subject to the same errors in design or fabrication.
- •5. Safety classification of I&c functions, systems, and equipment
- •6. Life cycle activities
- •Process implementation
- •Verification that the effects of automatic control system failures will not exceed the acceptance criteria established for anticipated operational occurrences.
- •6.58. The I&c architecture should be designed to fully satisfy the system requirements, including system interfaces and non-functional requirements (e.G., performance and reliability).
- •6.109. The benefits of changes should be weighed against potential negative safety consequences and this assessment documented as part of the justification for the changes.
- •Design for reliability
- •Single failure criterion
- •7.10. Each safety group should perform all actions required to respond to a pie in the presence of:
- •7.15. Non-compliance with the single failure criterion should be exceptional and clearly justified in the safety analysis.
- •7.19. I&c systems should be redundant to the degree needed to meet design basis reliability requirements.
- •Independence
- •7.27. When isolation devices are used between systems of different safety importance, they should be a part of the system of higher importance.
- •7.29. The adequacy of design features provided to meet the independence recommendations should be justified. Physical separation
- •7.31. Items that are part of safety systems should be physically separated from items of lower safety classification.
- •7.32. Redundant items of safety systems should be physically separated from each other.
- •Electrical isolation
- •Diversity
- •7.49. The decision to use diversity or not use diversity should be justified.
- •7.50. Where diversity is provided to cope with ccf several types of diversity should be used.
- •7.51. Where diversity is provided the choice of the types of diversity used should be justified.
- •Failure modes
- •7.57. The failure modes of I&c components should be known and documented.
- •7.60. Failures of I&c components should be detectable by periodic testing or self-revealed by alarm or anomalous indication.
- •7.73. Analysis that is part of the evidence of equipment qualification should include a justification of the methods, theories and assumptions used.
- •7.75. Traceability should be established between each installed system and component important to safety and the applicable evidence of qualification.
- •Suitability and correctness
- •7.81. The equipment qualification program should demonstrate that the as-built I&c systems and installed components correctly implement the qualified design.
- •7.90. Environmental qualification of safety components that must operate in harsh environments should include type testing.
- •7.102. Detailed emc requirements should be determined for safety systems and components and their compliance with the requirements demonstrated.
- •7.105. Equipment and systems, including associated cables, should be designed and installed to withstand the electromagnetic environment in which they are located.
- •7.109. Limits on radiated and conducted electromagnetic emissions should be established for all plant equipment.
- •7.112. The equipment qualification program should show that electromagnetic emissions of plant equipment are within the defined limits.
- •7.114. Instrumentation cables should have twisting and shielding sufficient to minimize interference from electromagnetic and electrostatic interference.
- •Design to cope with ageing
- •7.119. Ageing mechanisms that could significantly affect I&c components and means for following the effects of these mechanisms should be identified during design.
- •7.122. Maintenance programs should include activities to identify any trend towards degradation (ageing) that could result in the loss of operability of equipment.
- •Control of access to systems important to safety
- •7.130. Access to equipment in I&c systems should be limited to prevent unauthorized access and to reduce the possibility of error.
- •Testing and testability during operation
- •Test provisions
- •7.150. Arrangements for testing should neither compromise the independence of safety systems nor introduce the potential for common cause failures.
- •Test interfaces
- •7.153. Provisions for testing I&c systems and components should:
- •7.154. Where equipment to be tested is located in hazardous areas, facilities should be provided to allow testing from outside the hazardous area.
- •7.164. The test program should define processes for periodic tests and calibration of systems that:
- •Individually test each sensor, to the extent practicable.
- •7.165. In addition to the recommendations of paragraph 7.164, the processes defined for periodic tests and calibration of safety systems should:
- •Independently confirm the functional and performance requirements of each channel of sense, command, execute, and support functions;
- •Include as much of the function under test as practical (including sensors and actuators) without jeopardizing continued normal plant operation;
- •Maintainability
- •7.169. The design of I&c systems should include maintenance plans for all systems and components.
- •Setpoints
- •7.185. Trip setpoints used to initiate safety actions should be selected to ensure that required mitigating actions occur before the monitored variable reaches the analytical limit.
- •Operational identification of items important to safety
- •7.186. A consistent and coherent method of naming and identifying all I&c components should be determined and followed throughout the design, installation and, operation phases of the plant.
- •7.190. I&c components in the plant should be marked with their identifying information.
- •8.4. To the extent practicable, the plant conditions of concern should be monitored by direct measurement rather than being inferred from indirect measurements.
- •8.17. Means should also be provided to manually initiate the mechanical safety systems and the individual components necessary to initiate and control performance of their safety functions.
- •Digital computer systems and digital equipment
- •8.68. Specific skilled staff should be available during operation to allow controlled software and configuration data changes to be made when necessary to computer based systems.
- •8.91. Data received and data transmitted should be stored in separate, pre-determined memory locations.
- •8.154. Tools should be used to support all aspects of the I&c life cycle where benefits result through their use and where tools are available.
- •8.173. Confirmation of the suitability and correctness of industrial digital devices for their intended functions should produce evidence:
- •V&V at each stage of development for the final product;
- •9.4. The I&c system should allow the operator in the control room to initiate or take manual control of each function necessary to control the plant and maintain safety.
- •9.21. Instrumentation performing the functions given in 9.20 items a, b, and c should be classified as safety systems.
- •9.32. The main control room, the supplementary control room, and the Emergency Control Centre should have at least two diverse communications links with:
- •9.42. The Human System Interface (hmi) design should retain positive features and avoid hfe issues and problems of previous designs.
- •9.57. Where hmi stations are distributed, plant staff should have means to access these different locations in a safe and timely manner.
- •10.4. Development of software for systems should follow a previously defined life cycle, be duly documented and include thorough verification and validation. (See Chapter 6.)
- •10.49. Coding rules should be prescribed and adherence verified.
- •10.72. Verification should include the following techniques:
- •Software tools
- •Glossary
- •Annex I defense in depth in I&c systems
- •Annex II traceability to previouse I&c safety guides
- •Annex III bibliography of supporting international standards
10.4. Development of software for systems should follow a previously defined life cycle, be duly documented and include thorough verification and validation. (See Chapter 6.)
10.5. Software requirements, design description, and code should be unambiguous, complete, consistent, well-structured, readable, understandable to their target audience (e.g., domain experts, safety engineers, software designers), verifiable, maintainable and documented.
SOFTWARE REQUIREMENTS
10.6. All software necessary to satisfy the I&C system requirements, including reused or automatically generated code, should have documented requirements in appropriate form complying with the recommendations of this chapter.
10.7. Software requirements should define what the software must do within the context of the entire application, and how the software will interact with other components of the system.
10.8. Software requirements should be established using a predetermined combination of techniques commensurate with the system’s importance to safety, which might include specification languages with well-defined syntax and semantics, models, analysis, and review.
10.9. The origin of every software requirement should be documented sufficiently to facilitate verification, traceability to higher-level documents and a demonstration that all relevant requirements have been addressed.
10.10. Software requirement should originate from the relevant processes of I&C life cycle and from processes that interface with the I&C life cycle, e.g., human factors engineering and cyber security activities. See Fig. 2.
10.11. Consideration should be given to potential failure conditions, operation modes, safety monitoring, self-supervision, failure detection, safe conditions to be attained in the event of a detected but unrecoverable failure, other fail safe behaviour, and input and output relationships relevant to safety. Resultant safety requirements should be identified as such.
10.12. The software requirements should include the necessary level of reliability and availability to be achieved. Any supporting software requirements necessary to ensure that this is achieved should also be defined.
10.13. The necessary level of reliability and availability might be defined quantitatively, or qualitatively for example in terms of the supporting software requirements referred to above and/or development processes (e.g., standards compliance).
10.14. Any software reliability model used for licensing should be justified.
10.15. The software requirements should include minimum precision, numerical accuracy, a description of the interfaces (e.g., between the software and the operator, sensors and actuators, computer hardware and other software, and systems), independence of execution threads, self-supervision, timing performance (including fault detection and recovery times) and security (such as validity checks and access privileges).
10.16. As far as possible, the software requirements should be written in terms of what needs to be achieved rather than how they are to be designed and implemented.
10.17. Necessary design constraints should be documented, justified and traceable.
10.18. The requirements specification should allow for the capabilities of the computers, tools and similar existing systems to ensure that the software requirements are feasible.
10.19. Software requirements documentation may include additional information as applicable to its target audience, e.g., background for specific requirements, risk considerations, recommendations for the design of functions or safety features.
10.20. A requirements tracking system should be used so that the software requirements can be traced through the design, implementation, integration, and validation stages of the development project.
SOFTWARE DESIGN
10.21. The software design should be established using a predetermined combination of techniques commensurate with the system’s importance to safety, which might include descriptions, logic diagrams and graphical representations with well defined syntax and semantics, models, analysis and review.
10.22. The software design for systems other than safety systems might for example be a proprietary standard framework used to operate code formed by software tools using application specific logic diagrams, or graphical representations, with configuration information, where this provides sufficient rigour.
10.23. The software design should demonstrably address all software requirements and the system hazards identified in previous analyses.
10.24. Design elements should be identified to a level sufficient to facilitate traceability.
10.25. The software design of safety system software should maximise simplicity at all levels, including overall architecture, external interfaces, internal interfaces between modules, and detailed design.
10.26. Simplicity in design is a key means for achieving and demonstrating safety, but will always involve trade-offs, for example with functionality, flexibility and cost. Whereas the recommendation of paragraph 10.25 applies strictly to safety systems, the balance will be affected, and hence complexity may increase, as the importance to safety reduces.
10.27. The software design architecture should be structured to allow for future modification, maintenance and upgrades, for example to ensure that an expected change is isolated within a minimum number of modules.
10.28. The software architecture should be hierarchical to provide levels of abstraction.
10.29. Use of information hiding where possible is encouraged to enable piecewise review and verification and to aid modification.
10.30. The software design should include the interfaces between the software and its external environment and the detailed design of all software modules.
10.31. The module description should completely define its function, its interface with other modules and the context of its function in the overall software.
10.32. Module interfaces should be consistent. In particular, both sides of each interface between modules should match, and there should be, as far as possible, a consistent partial ordering and use of variable names between module input and output interfaces.
10.33. If the system includes multiple processors and the software is distributed among them, the software design should include which software process runs on which processor and where data and displays are located.
10.34. The software design should ensure predictable and deterministic operation (including in terms of the functional and timing response to particular inputs), see paragraph 8.62.
10.35. Communication protocols should be deterministic and should not depend on the correct operation of external systems (see paragraph 8.75).
10.36. As the design is refined, the need for additional fault detection and self-supervision features should be considered and be included in the software design. See paragraphs 8.70-8.74.
10.37. On failure detection, appropriate action should be taken to meet the software requirements (see paragraph 10.11), in terms of recovery, halting procedures, and error messages and logs, to ensure that the system is maintained in a safe condition.
10.38. The software design documentation should include implementation constraints.
10.39. Implementation constraints include any need to ensure diversity, and the attributes of the programming languages, compilers, subroutine libraries and other supporting tools.
10.40. These constraints should be justified or be traceable to higher-level requirements or constraints.
10.41. The software design architecture should account for constraints on modules and interfaces that might result from the decision to use diversity.
SOFTWARE IMPLEMENTATION
10.42. The softwae implementation should be established using a predetermined combination of techniques commensurate with the system’s importance to safety, covering languages, tools, coding practices, analysis, review and testing (see also section [software verification and analysis]).
10.43. The software implementation should demonstrably address all software requirements and the software design.
10.44. The software implementation should maximise simplicity and ease of understanding, with future readability and maintainability taking precedence over ease of programming.
10.45. All code subject to human inspection should be adequately annotated.
10.46. The documentation of safety systems should include source and executable code listings, the results of unit and module interface tests, and sufficient contextual information to verify the code’s correctness with respect to its specification.
10.47. For safety systems, access to all parts of the executable code (including run time support code and fault supervision functions) is necessary to enable the testing guidance of this Safety Guide to be met.
10.48. For systems other than safety systems, the appropriate documentation will depend on the implementation platform, but might for example include all special code inserts, and a description of all functions (provided in the form of logic diagrams or graphical representations), together with all configuration information necessary to define the application fully.