- •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
8.91. Data received and data transmitted should be stored in separate, pre-determined memory locations.
8.92. No operator control should be capable of influencing the operation of safety equipment outside its own division when that equipment is performing its safety function.
8.93. Safety control stations may operate safety equipment outside its own division by way of a priority function that complies with the recommendation of paragraph 8.110.
8.94. Safety systems or components may also be operated from operator controls of lower safety classification only if the recommendation of paragraph 8.110 is met.
8.95. Information from safety systems may be presented on control stations of lower safety classification if the independence recommendations of this guide are met.
8.96. Only predefined data sets should be processed by a receiving safety system.
8.97. The message protocol, message format, and all valid messages must be pre-determined.
Data communications independence
8.98. Data communications systems should meet the independence guidance given in paragraphs 7.21-to 7.47.
8.99. This section supplements the guidance of paragraphs 7.21-7.47 with additional guidance that is specific to data communications in computer-based systems.
Avoidance of common cause failure
8.100. The data communication network topology and media access control should be designed and implemented to avoid CCF of independent systems or subsystems.
8.101. The data communications network topology should not merge data from multiple divisions of redundant systems or from systems of different levels of safety classification.
Communications between safety divisions
8.102. Communications (including communications errors or failures) between computers in different safety divisions should have no detrimental effect on the safety division in question.
8.103. This is necessary to prevent the propagation of failures between divisions. Typically a combination of data validation (see paragraphs 8.77-8.83), and buffering (see paragraphs 8.88-8.91) is employed.
8.104. One-directional broadcast communication protocols are acceptable and commonly used.
8.105. Architectures using a central hub or router where communications from multiple safety divisions are transmitted across a single channel should not be used.
Communications between different safety classes
8.106. Data transmission from safety systems to systems of lower safety classification should prevent the lower class system from affecting the safety system.
8.107. One-directional, broadcast data communications is often used where computer based systems of a higher classification must provide data to systems of lower safety classification. Hardware characteristics that enforce the one-directional feature, e.g., the use of a link that is connected only to a transmitter in the higher classified system and only to a receiver in the lower classified system, are a favoured means of ensuring one-directional communication.
8.108. Data flow from lower to higher classified I&C systems should be prevented.
8.109. Individual analogue or binary signal lines may send signals from systems of lower to systems of higher safety classification if the independence guidance of paragraphs 7.21-7.47 is met.
8.110. Operation of safety devices by systems of lower safety classification should not be allowed unless completion of safety actions cannot be interrupted by commands, conditions, or failures in the system of lower safety classification.
8.111. Often a priority function is provided to ensure that signals from systems of lower safety classification cannot override demands by safety systems.
Computer security
8.112. IAEA Nuclear Security Series No. 17 provides guidance on concerns, requirements, and strategies for implementing computer security programs at nuclear facilities.
Development process
8.113. The development process and operation of computer-based I&C systems or components should include a computer security plan that specifies and details the means for achieving computer security.
8.114. SSR 2/1 requirement 8 states:
Safety measures, nuclear security measures and arrangements for the State system of accounting for, and control of, nuclear material for a nuclear power plant shall be designed and implemented in an integrated manner so that they do not compromise one another.
8.115. Security design requirements for computer based I&C systems should be informed by vulnerability analyses and should be consistent with the characteristics of the user’s security policies.
8.116. If user security policies are unknown at the time security design requirements are developed for an I&C system, presumed characteristics of the user’s policies may be defined and documented by the developer. Differences between actual and presumed user policies must be addressed before the I&C system is declared operable.
8.117. The implementation process and the subsequent installation of digital computer systems should have suitable measures in place to prevent intentional or unintentional intrusion or corruption of the software or data, the introduction of malicious code, incorrect connection to external networks, or hacking attacks.
8.118. When security measures are implemented on digital I&C safety systems, the design should ensure that neither the operation nor failure of these measures will adversely affect the ability of the system to perform its safety function.
8.119. Where practical, security measures that do not also provide a safety benefit, should be implemented in devices that are separate from those performing safety functions.
8.120. Adding security functions to safety I&C systems increases that systems complexity and might introduce potential failure modes to the system that would challenge its ability to reliably perform its safety function. For this reason, inclusion of such functions must be carefully evaluated and only implemented when it is not possible or otherwise feasible to accomplish an equivalent measure of security protection outside of the I&C systems.
Control of access
8.121. All data connections for systems and components should be placed within enclosures for which both access to the enclosure and access to the inside of the enclosure is controlled in accordance with paragraphs 7.128-7.132.
8.122. Data connections include network connections, connections for external memory, and access to portable media such as memory sticks, flash cards, and data disks.
8.123. Unused data connections should be disabled.
8.124. Forms of disabling unused connections include: removal, physical measures, or logical measures. If logical measures are used as a means of disabling unused data connections, additional measures are necessary to ensure that the connection remains disabled and that any change in connection configuration or status will be detected and evaluated for impact on system operability.
8.125. Connections needed for temporary use, e.g. connection of maintenance computers should be disabled when not in use.
8.126. It is expected that traffic from disabled connections would be detected as inauthentic messages.
8.127. Access to functions that allow changes to software or configuration data of computer systems should require that the user be authenticated by two different means beyond those that allow entry into equipment rooms or equipment enclosures.
8.128. Different means of user authentication include, for example:
Physical means, e.g., key, or one-time password token;
Knowledge means: e.g., password; and
Biometric means, e.g., hand geometry scanner.
8.129. Paragraph 8.127 does not apply to changes in configuration data that can, by design, be made by control room operator consoles.
8.130. Access to functions that allow changes to software or configuration data and the changes themselves should be monitored and logged.
8.131. Communication of data between the plant and the emergency control centre (either on-site or off-site) should be via unidirectional links.
8.132. Communication links between the plant and the emergency control centre, including those that are used for human communications, should be dedicated to the purpose and protected from tampering.
8.133. Data communicated might include information about the status of fundamental safety functions and other information necessary to support emergency management.
Features for operational security
8.134. Scanning for security vulnerabilities should be considered for detecting and mitigating computer security threats.
8.135. Scanning of I&C systems for security vulnerabilities should not adversely affect functions that are important to safety.
8.136. Provisions for security scanning, for example, increase system complexity, competition use system resources, and might introduce new failure modes.
8.137. It is permissible that such provisions allow scanning only when the system is off line. For safety systems, it is preferable to perform scanning functions off-line.
8.138. Computer systems should include provisions for periodic, and post-maintenance verification that security features are properly configured and are properly operating.
DEVICES CONFIGURED WITH HARDWARE DEFINITION LANGUAGES (HDL)
8.139. HDL configured devices are composed of integrated circuits design to provide logic that is later embedded on the integrated circuits using special tools.
8.140. Once the logic is embedded on the integrated circuit and installed in the plant, the logic is hardwired and does not change. Consequently, the configured HDL components are treated as hardware. The logic is designed and manufactured by a process which is similar to generating software.
8.141. HDL configured devices need a development process before use in an I&C system. FPGA are a common example of devices in this class.
8.142. The guidance of this section apply to items that are being specifically configured for nuclear power plant I&C applications. The guidance of this section does not directly apply to HDL configured devices that are embedded into larger components of nuclear power plant I&C systems. It is expected that the functional qualification of such components will address the suitability of the overall component, including the embedded HDL configured devices. See paragraphs 7.77-7.81.
8.143. Development of applications using HDL configured devices should follow a previously defined life cycle, be duly documented, and include thorough verification and validation before they are used in I&C systems.
8.144. The HDL design should guarantee synchronous and deterministic behaviour of the component.
8.145. Synchronous and deterministic behaviour favours correctness and testability and allows for the best use design and verification tools.
8.146. Design activities should use standardized HDL together with qualified and mutually consistent software tools.
8.147. HDL code may be automatically generated from a more functional and application friendly language (e.g., from a functional diagram).
8.148. The design should be restricted to HDL structures having well-defined implementation and behaviour.
8.149. The design should explicitly handle all possible cases of logic and timing, and all operating modes such as reset, power-on, and normal operation.
8.150. The selection of pre-developed items to be included in the final product should follow a defined and documented process to guarantee their suitability, and if necessary to restrict their use to what is needed and safe.
8.151. Pre-developed items include, for example, the programmable circuit to be used (e.g. antifuse vs. static random access memory (SRAM) based devices), libraries, and intellectual property cores.
SOFTWARE TOOLS
8.152. The use of appropriate software tools can increase the integrity of the I&C development process, and hence product reliability, by reducing the risk of introducing faults during the process. The use of tools can also have economic benefits as they can reduce the time and human effort required to produce systems, components, and software. Tools can be used to automatically check for adherence to rules of construction and standards, to generate proper records and consistent documentation in standard formats, and to support change control. Tools can also reduce the effort required for testing and to maintain automated logs. In some cases tools are necessary because a specific development methodology requires their use.
8.153. Software tools used in the development of I&C systems include, for example:
Requirement management systems;
Automated circuit and raceway scheduling software;
Transformational tools such as code generators, compilers, hardware definition languages, electronic design automation software, and tools that transform text or diagrams at one level of abstraction into another, usually lower, level of abstraction;
Verification and validation tools such as static code analyzers, automated circuit testers, text coverage monitors, theorem proving assistants, electronic circuit simulators, and plant system simulators;
Tools for preparing system configuration data.
Infrastructure tools and development support systems such as requirements management systems or integrated development environments; and
Configuration management and control tools.