
- •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
6. Life cycle activities
6.1. GS-R-3 paragraph 5.1 states:
The processes of the management system that are needed to achieve the goals, provide the means to meet all requirements and deliver the products of the organization shall be identified, and their development shall be planned, implemented, assessed and continually improved.
6.2. Modern nuclear power plant I&C systems are complex entities that need design and qualification approaches beyond those that were typically applied to older systems. Often the functional characteristics and performance of previous generations of I&C systems could be well characterized by models based upon physics principles and testing that validates these models.
6.3. Modern I&C systems, in particular systems whose functionality depends upon software or HDL code, are fundamentally different from older systems in that their behaviour is determined by internal logic and not externally by the continuity of physical laws. Consequently, minor errors in design and implementation can cause software-based systems to exhibit unexpected behaviour.
6.4. As a result, demonstration that the final product is fit for its purpose depends greatly on the use of a high-quality development process that provides for disciplined specification and implementation of design requirements. In modern I&C systems, inspection and testing support verification and validation that the final product is suitable for use, but correct system performance over the full range of conditions cannot be inferred from the combination of testing and physics models to the same extent that this may be done for hardware systems. Consequently, confidence in the correctness of modern systems derives more from the discipline of the development process, than was the case for systems implemented purely with hardware.
6.5. In response to this situation the nuclear power community has developed a extensive guidance regarding processes for developing I&C systems. I&C development processes are commonly represented as life cycle models that describe the necessary activities for the development of I&C systems and the relationships between these activities. Normally, activities related to a given development step are grouped into phases.
Process implementation
6.6. The life cycle process guidance in this chapter supplements the requirements of GS-R-3, Ref. [4] and the recommendations of GS-G-3.1, Ref. [5] and GS-G-3.5, Ref. [6] as they apply to I&C system development.
6.7. Three fundamental levels of life cycles are needed to describe the development of I&C systems:
An overall I&C development life cycle;
One or more individual I&C system development life cycles; and
One or more individual component development life cycles. Component life cycles for computer-based systems are typically divided into separate life cycles for the development of hardware and software.
6.8. I&C development life cycles must be coordinated with two other life cycles that deal with more than I&C, but have a strong influence on I&C development:
A human factors engineering (HFE) life cycle; and
A cyber security life cycle.
6.9. Figure 2 shows an example I&C development life cycle and the main inputs received from the HFE and cyber security life cycles. Figure 3 shows more detail of the hardware and software life cycles that are included in Figure 2.
6.10. The V-model shown in Figure 4 is a useful alternative view of life cycle models. This model illustrates the relationship between requirement specification, design, integration, and validation activities and how V&V activities relate to development activities. Figure 4 applies to both computer-based and non-computer-based systems. Of course if there is no software the software activities are unnecessary.
6.11. At any time lessons learned might result in a need to revise work done in any previous phase. These changes will then flow through and affect work from the intervening phases. For simplicity, these figures do not show the iteration paths.
6.12. There are different types of life cycle models, such as waterfall, spiral, and incremental development. Regardless of the model the necessary activities are basically the same. This document describes life cycles as a linear sequence of activities. This is for simplicity of explanation, and is not intended to indicate a necessity to use a waterfall model. Indeed, any complicated development process follows a hybrid approach.
6.13. Regardless of the structure of the overall I&C life cycle and the individual I&C system life cycles, all life cycle activities should be completed, and traceability established from requirements to installed systems and components before plant I&C is declared operable.
6.14. A requirements tracking system should be used so that the I&C requirements can be traced through all life cycle stages of the development project.
6.15. The recommendations for life cycle processes described in this chapter also apply to life cycle activities described in chapters 9, and 10.
FIG.
2. Typical I&C life cycle activities
FIG.
3 Typical individual component life cycle
FIG.
4 Relationship Between life cycle processes and V&V activities
LIFE CYCLE ACTIVITIES
Process planning
6.16. As a minimum the following I&C development processes should be defined and documented.
Classification of items important to safety;
Life cycle models;
Configuration management;
Requirements specification;
Design;
Implementation, e.g., hardware manufacture and software coding;
Procurement;
Integration;
Installation;
Specification of commissioning activities;
Design change;
Verification and validation;
Qualification and use of tools;
Production and maintenance of documentation;
Resource management, including personnel; and
Risk management.
Use of life cycle models
6.17. The engineering of an overall I&C architecture is a complex process involving many technical disciplines and activities where correct information is necessary at all times.
6.18. All activities associated with development, implementation, and operation of the overall I&C architecture, individual I&C systems, and I&C components (including hardware, software, and HDL code development) should be carried out in the framework of an appropriate development life cycle.
6.19. Each life cycle should cover the period of time that starts with deriving I&C requirements from the plant safety design base and finishes when none of the I&C systems are required for the safety of the plant.
6.20. Before initiation of any life cycle phase (see Figures 2, and 3), a plan describing the activities required in that phase should be prepared and approved.
6.21. The approved plan for each life cycle phase should integrate HFE and cyber security activities with the I&C life cycle activities of that phase.
6.22. Human Factors Engineering and cyber security activities have a broader purpose than support of I&C design. Therefore, there will generally be separate plans for these topics.
6.23. All life cycle activities should be carried out in accordance with the approved plan.
Verification and validation
6.24. In the application of safety life cycles, each phase uses information developed in earlier phases, and provides results to be used as the input for later phases.
6.25. The results of each safety life cycle phase should be verified against the requirements set by the previous phases.
6.26. Each item should be validated to confirm that the results comply with all the functional and other requirements, and to investigate for the existence of unintended behaviour.
6.27. Note that software modules, integrated software, firmware, integrated software and hardware, and HDL code, and software are included in the term item.
6.28. Verification and validation should be carried out by teams, individuals, or groups that are independent of the designers and developers.
6.29. Independence of verification and validation teams normally involves establishing that they are not subject to budget or schedule constraints or to pressure from the design organization, and that they report to a level of management which is not exerting direct pressure for a favourable V&V report.
6.30. HFE verification and validation activities should be carried out to:
Verify the resolution to HFE recommendations and deficiencies identified during analyses;
Verify that the I&C systems conform to applicable HFE design guidelines;
Verify that the design supports operator tasks with adequate I&C systems, other equipment, and operator aids;
Validate, using performance based measures, that personnel can carry out their functions using the I&C system under all conditions under which the system is expected to function;
Verify the as-built design conforms to the validated design
Design analysis
6.31. Design analyses, including the following specific activities, should be performed to confirm that they fulfil their design basis requirements.
Verification that safety systems comply with the single failure criterion.
Verification that the design of I&C systems includes adequate test provisions.
Failure Mode and Effects Analysis is often used to confirm compliance with the single failure criterion, and to confirm that all known failure modes are either self-revealing or detectable by planned testing.
Verification that the overall I&C system supports the plant defence-in-depth concept.
Verification that common cause failure vulnerabilities of I&C safety systems are known and have been adequately addressed.
Defence-in-Depth and Diversity Analysis is one means of investigating vulnerability of safety systems to common cause failure.
Common cause failure vulnerabilities may be addressed by eliminating the vulnerability, providing diverse means of achieving the safety functions subject to the CCF, or justifying acceptance of the vulnerability.
Verification that design basis reliability requirements are met.
This demonstration may be based on a balance of application of deterministic criteria and quantitative reliability analysis that considers design features such as, for example, redundancy, testability, failure modes, and rigour of qualification.
For complicated systems a combination of qualitative analysis, quantitative analysis, and testing is usually needed to verify compliance with design basis reliability requirements.
Test facilities that are part of the safety system must be considered when determining system availability.
Confirmation that all system requirements have been implemented and validated.
Typically traceability analysis is used to confirm implementation and validation of requirements.