IEC 60987 Edition 2 1 2013 02 INTERNATIONAL STANDARD NORME INTERNATIONALE Nuclear power plants – Instrumentation and control important to safety – Hardware design requirements for computer based syste[.]
General
This International Standard is applicable to NPP computer-system hardware for systems of
Class 1 and 2 (as defined by IEC 61513)
The structure of this standard has not changed significantly from the original 1989 issue; however, some issues are now covered by standards which have been issued in the interim
The article discusses the incorporation of updated standards, such as IEC 61513, into system architecture design It highlights modifications made to the standard's text to align with advancements in computer system hardware, the integration of commercial off-the-shelf (COTS) hardware, and the evolution of relevant terminology.
Computer hardware used for software loading and verification is not deemed an essential component of safety-critical systems and is therefore excluded from the scope of this standard.
NOTE 1 Class 3 computer-system hardware is not addressed by this standard, and it is recommended that such systems should be developed to commercial grade standards
In 2006, IEC SC 45A initiated discussions on creating a new standard to meet the hardware requirements for "very complex" hardware If established, this standard would take precedence over IEC 60987 for the development of such hardware.
Use of this standard for pre-developed (for example, COTS)
This standard primarily focuses on new hardware development but can also guide the assessment and utilization of pre-developed hardware, including COTS hardware It offers guidance on interpreting the requirements for evaluating these components, particularly emphasizing the quality assurance requirements related to configuration control.
Pre-developed components may include firmware, and when this firmware is deeply embedded and effectively transparent to the user, IEC 60987 should guide the assessment process This approach is particularly relevant for modern processors that contain microcode, as this code is an integral part of the hardware Consequently, it is appropriate to assess the processor, including its microcode, as an integrated hardware component according to this standard.
Software which is not firmware, as described above, should be developed or assessed according to the requirements of the relevant software standard (for example, IEC 60880 for
Class 1 systems and IEC 62138 for Class 2 systems).
Applicability of this standard to programmable logic devices development
I&C components often feature programmable logic devices that are customized with specific application logic by the designer rather than the chip manufacturer Notable examples of these devices are complex programmable logic devices (CPLD) and field programmable gate arrays (FPGA).
The design processes for programmable logic devices share similarities with those used in traditional logic circuit design, necessitating adherence to relevant standards It is essential that the design and verification processes for these devices consider their unique characteristics Additionally, any software tools employed in the design of programmable logic devices should align with the guidelines set forth in applicable software standards, such as IEC 60880 for Class 1 systems and IEC 62138 for Class 2 systems.
The following referenced 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
IEC 60780, Nuclear power plants – Electrical equipment of the safety system – Qualification
IEC 60812, Analysis techniques for system reliability – Procedures for failure mode and effects analysis (FMEA)
IEC 60880, Nuclear power plants – Instrumentation and control systems important to safety –
Software aspects for computer-based systems performing category A functions
IEC 61000 (all parts), Electromagnetic compatibility (EMC)
IEC 61025, Fault tree analysis (FTA)
IEC 61513:2001, Nuclear power plants – Instrumentation and control for systems important to safety – General requirements for systems
IEC 62138, Nuclear power plants – Instrumentation and control important for safety –
Software aspects for computer-based systems performing category B or C functions
IEC 62671, Nuclear power plants − Instrumentation and control important to safety – Selection and use of industrial digital devices of limited functionality
ISO 2768-1, General tolerances − Part 1: Tolerances for linear and angular dimensions without individual tolerance indications
ISO 2768-2, General tolerances − Part 2: Geometrical tolerances for features without individual tolerance indications
ISO 3951-1 outlines sampling procedures for inspection by variables, specifically focusing on single sampling plans that are indexed by the acceptance quality limit (AQL) This standard is designed for lot-by-lot inspection, addressing a single quality characteristic and a single AQL to ensure consistent quality control in manufacturing processes.
ISO 3951-2, Sampling procedures for inspection by variables − Part 2: General specification for single sampling plans indexed by acceptance quality limit (AQL) for lot-by-lot inspection of independent quality characteristics
ISO 9001, Quality management systems – Requirements
IAEA NS-G 1.3, Instrumentation and control systems important to safety in nuclear power plants
IAEA 50-C/SG-Q:1996, Quality assurance for safety in nuclear power plants and other nuclear installations
For the purposes of this document, the terms and definitions given in IEC 61513, as well as the following, apply
COTS commercial off the shelf; COTS is a subset of pre-developed products
Diversity refers to the presence of two or more distinct methods for achieving a specific goal, serving as a safeguard against common cause failure This can be accomplished through the implementation of systems that are physically different or by utilizing functional diversity, where similar systems accomplish the same objective through varied approaches.
The definition provided here is broader than the one specified by the IAEA NS-G-1.3, which defines it as the existence of two or more systems or components designed to perform a specific function, ensuring that these systems or components possess distinct attributes to minimize the risk of common mode failure.
Firmware is specialized software that is tightly integrated with the hardware it operates on, often remaining invisible to the user This software is considered a fundamental aspect of hardware design, exemplified by processor microcode Typically, users can only modify firmware by replacing hardware components, such as processor chips or cards.
EPROM) which contain this software with components which contain modified software
Configuration control of hardware components by users ensures effective management of firmware According to this standard, firmware is essentially software embedded within the hardware.
FMEA failure modes and effects analysis
3.8 pre-developed item which already exists, is available as a commercial or proprietary product, and is being considered for use in a computer-based system
NOTE This definition is consistent with the definition of pre-developed software provided by IEC 61513:2001
The qualified life period refers to the duration for which a structure, system, or component has been proven, through testing, analysis, or experience, to operate effectively within established acceptance criteria under specific conditions This period ensures that the system can maintain its safety functions during design basis accidents or earthquakes.
3.10 revealed hardware failure a hardware failure which is detected automatically and reported, for example, a board failure where a watchdog circuit automatically detects the failure and raises an alarm
3.11 safety-related system system important to safety that is not part of a safety system
The safety system is crucial for ensuring the safe shutdown of the reactor and the effective removal of residual heat from the core It is designed to limit the consequences of anticipated operational occurrences and design basis accidents, thereby enhancing overall safety.
3.13 single failure failure which results in the loss of capability of a system or component to perform its intended safety function(s), and any consequential failure(s) which result from it
3.14 single failure criterion (SFC) criterion (or requirement) applied to a system such that it is capable of performing its safety task in the presence of any single failure
Safety systems are crucial components within a safety group, as their malfunction or failure can result in radiation exposure to both site personnel and the public.
3.16 system validation confirmation by examination and provision of other evidence that a system fulfils in its entirety the requirement specification as intended (functionality, response time, fault tolerance, robustness)
Unrevealed hardware failure refers to a malfunction that goes undetected by the system until a function reliant on the faulty hardware is attempted.
Such failures may be discovered by functional testing or when an operational demand is placed upon the system
3.18 verification confirmation by examination and by provision of objective evidence that the results of an activity meet the objectives and requirements defined for this activity (ISO 12207)
General
A safety-critical computer-based system project should be organized into distinct phases, each of which is somewhat self-contained These phases rely on inputs from one another and generate outputs that feed into subsequent phases Collectively, these phases constitute the overall safety life cycle.
IEC 61513, Clause 5, which provides requirements for system life cycles) IEC 61513 allows project phases to be performed in parallel providing the integrity of the development process is not compromised
A quality assurance plan shall be applied to the hardware production process.
Project subdivision
The hardware development life cycle for computer-based systems must align with the overall system life cycle requirements outlined in this standard.
Each sub-phase of the hardware development life cycle must involve clearly defined and documented activities Pre-existing hardware products, such as Commercial Off-The-Shelf (COTS) items, should be thoroughly checked, verified, and tested before integration into the design Sufficient resources, including spare parts and testing devices, as well as appropriate facilities like laboratories and workshops, must be available to support each development phase Documentation is essential at every stage, and each phase should conclude with verification activities, as outlined in Clause 7 These verification activities must generate auditable records that capture the conclusions and any design modifications made Additionally, all work activities should be scheduled to allow adequate time for these processes.
1) the resolution of any interactions between the hardware and software development phases required to ensure system hardware/software compatibility;
2) the production of documentation, and the performance of testing, verification and quality assurance activities.
Quality assurance
The design and development process shall meet the relevant requirements of IAEA 50-C/SG-
Compliance with ISO 9001 is a recognized approach to fulfilling hardware quality assurance requirements A comprehensive hardware quality assurance plan must be established, either as an independent document or integrated within a broader quality assurance framework This plan should encompass the utilization of existing hardware and the necessary development of new hardware It is essential that all quality-related activities conducted by the plant operator, owner, contractors, and subcontractors during the hardware development process are incorporated into the quality assurance plan.
4.3.1 The plan should address the following phases, as they are applicable to any particular system or development: a) design and development; b) procurement; c) manufacturing; d) construction and commissioning; e) operation and maintenance
It is not necessary to address all phases before starting the design process; however, a plan must be established to meet the requirements of each phase prior to its initiation.
The quality assurance plan must outline the organization, management, and execution of quality-related activities, which include documentation configuration control, the design and procurement processes for goods and services, and the configuration control of build instructions, procedures, and materials It should also detail quality control activities like formal inspections, the management of test equipment, and the handling, storage, and shipping of hardware Additionally, the plan must address the testing process, monitoring of nonconformances with corrective actions, the storage of quality assurance records, and the procedures for conducting internal audits.
General
The hardware requirements must align with the system's needs and be included in the computer-system specification, as outlined in IEC 61513:2001, Clause 6 This specification details the integrated hardware and software system, defining the design objectives and the functions the computer system is intended to perform Systems can be tailored for specific applications or developed generically, relying on derived generic system requirements.
5.1.2 The hardware requirements shall be specified in the system hardware requirements specification, or in some other suitable document
5.1.3 Hardware requirements shall be presented according to a technique or method whose format shall not preclude readability, i.e the hardware requirements should not be difficult to understand
5.1.4 Functional hardware requirements shall be unambiguous, testable and/or verifiable and achievable
The hardware requirements specification must outline the essential hardware needs, highlight functions critical to nuclear safety (which should be detailed in the system requirements specification if combined with system software), define hardware design criteria, and specify reliability and environmental withstand requirements for the hardware.
The hardware requirements for computer systems encompass both general hardware specifications and specific needs unique to computer system hardware, such as cabling and the surface preparation of enclosures.
Hardware functional requirements should outline what needs to be accomplished rather than the methods of execution The integration of existing components may lead to a bottom-up approach in hardware design Prior to selecting these components, an assessment must be conducted to ensure that their performance characteristics, including failure modes, align with system requirements Any identified discrepancies must be addressed by either adjusting the hardware design or modifying the system design, ensuring that nuclear safety requirements are upheld.
Functional and performance requirements
5.2.1 The hardware functional and performance requirements shall be consistent with the functional and performance requirements of the system important to safety
5.2.2 The hardware functional and performance requirements, combined with the software requirements (to the extent necessary to address all hardware requirements), shall be verified for compliance with the system requirements
All system components that include software must be evaluated according to the guidelines outlined in section 1.2 of this standard Additionally, the hardware functional requirements should encompass, but are not limited to, a clear definition of
1) the purpose of the overall computer system hardware and of each hardware sub- system;
2) the numbers and types of sensors and actuators to be connected to the computer system;
The man/machine interface encompasses various devices, including displays, printers, and keyboards Each component or subsystem supplied for integration must come with a specification that addresses all safety-related performance aspects In the absence of such a specification, an analysis is required to assess the hardware design characteristics to ensure suitability Additionally, hardware performance requirements should be defined based on the specific application needs.
5) required communications interfaces (protocols, transmission speeds);
6) required computational and conversion accuracy;
7) required signal noise rejection capability;
10) geographic requirements (for example, length of data transmission lines);
11) required level of spare capacity (if required);
13) electrical power supply requirements d) Any constraints imposed upon the hardware design by the system or software design shall be stated.
Reliability/Availability requirements
The hardware reliability and availability requirements must align with the system's overall reliability standards This includes detailing any failure types that can be tolerated without significant loss of function or with a clearly defined limited loss Additionally, specific hardware reliability targets should be established.
NOTE Hardware reliability in this context is concerned with random hardware failures and excludes any consideration of failures due to logical design errors
5.3.2 Irrespective of the hardware reliability/availability requirements, the overall I&C architecture for a NPP shall meet the IAEA NS-G-1.3 single failure criteria (see 3.6)
The hardware requirements must specify target figures for reliability parameters, including mean time between failure (revealed), mean time between failure (unrevealed), and mean time to repair for revealed failures Additionally, any reliability claims should be backed by a thorough analysis of the hardware design, which may include evaluations at the subunit, card-level, or component-level.
5.3.4 The methods which may be used to analyse the reliability and the effects of system hardware failures include
– FTA, which is concerned with the identification and analysis of conditions and factors which cause or contribute to the occurrence of a defined undesirable event (see
IEC 61025 for advice concerning this technique);
– FMEA, which identifies failures which have significant consequences affecting the system performance, for example, reliability, safety, availability (see IEC 60812 for advice concerning this technique)
Where relevant, a suitable analysis technique shall be applied to Class 1 and Class 2 hardware systems to ensure that any potential hardware failures do not have unacceptable nuclear safety effects
Combining techniques like Fault Tree Analysis (FTA) with existing component failure data can yield calculated values for the reliability characteristics of system hardware This method is essential for analyzing Class 1 systems as per IEC 61513, unless there is sufficient operational experience to confidently meet the target reliability goals For Class 2 systems, this technique should also be utilized, or a justification for adequate reliability must be provided through qualitative reasoning, such as assessing component quality, hardware redundancy, operational experience, and the ratio of revealed to unrevealed hardware failures, especially when reliability requirements are not stringent.
To ensure the reliability and availability of computer systems throughout their lifecycle, it is essential to define and document maintenance requirements These requirements should focus on preventing maintenance activities from introducing faults that could lead to common-cause failures Given that maintenance on multiple train systems is a significant risk factor for such faults, systems should be designed to minimize the need for these activities whenever possible When maintenance is necessary and poses a risk of common-cause failures, design specifications must outline strategies to mitigate these risks effectively.
Maintenance requirements must encompass several key aspects relevant to each specific system These include ensuring system operation during hardware maintenance, guidelines for replacing consumables like air filters, protocols for the regular replacement of subsystems, modules, or components, and the necessary extent of hardware revalidation, such as testing, after maintenance activities.
5.3.8 However, given that the requirements specification should define “what”, rather than
During the requirement specification phase of a project, it may not be feasible to outline maintenance requirements in detail Therefore, it is essential to fully define these requirements in a later phase of the development process.
Environmental withstand requirements
The hardware must meet environmental withstand requirements that consider physical constraints, climatic conditions, seismic activity, chemical exposure, electrical factors, and radiation levels Additionally, any specific requirements relevant to the installation and commissioning processes should be incorporated.
5.4.2 The degree of immunity to electromagnetic interference shall be specified as required by the operational environment, and tested according to applicable standards, for example,
IEC 61000 The electromagnetic operational environment could potentially be affected by a wide variety of electrical interference sources, for example, switchgear, mobile phones, relays, walkie-talkies, electrostatic discharges, lightning, earth faults
5.4.3 The electromagnetic qualification levels specified should be in accordance with realistic estimates of the operational conditions under all credible worst-case circumstances
5.4.4 The hardware requirements shall identify any prohibited construction materials and any requirements for particular materials to be used, or for particular types of production processes
5.4.5 If a particular hardware qualification process is required, then this should be documented in the hardware requirements.
Documentation requirements
The hardware documentation requirements must be outlined within the overall documentation requirements of the computer system, in accordance with IEC 61513 Relevant documentation to be produced includes design documents detailing system hardware components and interface designs, as well as operators' manuals and maintenance manuals.
General
This clause is applicable to system, subsystem and module level hardware design and development
The design and development of new hardware must begin with a clear hardware requirements specification This process should advance through multiple design stages, ultimately leading to the creation of hardware that fulfills the specified requirements.
Preliminary design involves analyzing various design alternatives to establish the hardware system architecture, focusing on its subsystems and modules.
Preliminary design is typically succeeded by one or more levels of detailed design These detailed design activities enhance the preliminary design by elaborating on the subsystems, modules, and components, ensuring that the overall hardware design description is comprehensive enough for implementation.
6.1.4 Prototype hardware may be built, not only to demonstrate successful interaction between hardware modules, but also to check hardware and software compatibility
Pre-developed components, such as Commercial Off-The-Shelf (COTS) hardware, can be utilized for the entire system or specific hardware subsets While subclauses 6.2 to 6.7 primarily focus on scenarios necessitating custom hardware development, they also offer guidance on how to apply these requirements to the integration of pre-developed components when suitable.
Design activities
System performance requirements that rely on hardware performance must be addressed in the hardware design, with supporting evidence provided through analysis or testing to demonstrate compliance These requirements may encompass calculation accuracy, response time, environmental resilience, and electrical supply needs For existing components, it is essential to verify their specifications against the system's hardware requirements to ensure they meet the necessary standards, or alternatively, to confirm hardware performance through testing.
6.2.2 Any discrepancies against hardware requirements shall be reconciled, by either changing the design or changing the requirements (the impact of any changes shall be fully assessed and documented)
Hardware designers must determine the necessary tests to demonstrate that the required performance standards are met These tests can be conducted on the hardware independently or during the system integration testing phase, where the hardware is evaluated alongside the software.
Hardware designers must outline necessary maintenance activities to ensure that performance and reliability standards are met throughout the equipment's operational life These activities may encompass operational tests, calibration, repairs, periodic replacements, and maintenance procedures It is essential that these tasks are conducted to instill confidence in the equipment's proper functioning while minimizing human intervention and intrusive work, thereby reducing the risk of introducing faults, such as common-mode failure faults, during maintenance.
6.2.5 Where a qualified target life is specified, justification shall be provided that this target is realistic and achievable.
Reliability
6.3.1 Reliability requirements should be specified in the hardware requirements documentation (see 5.3)
To ensure comprehensive system-level safety analysis, it is essential to conduct an analysis of potential hardware failures during the design phase This analysis must account for scenarios involving multiple trains or systems, each potentially comprising single or multiple equipment trains, particularly in the context of nuclear safety functions Additionally, it is crucial to consider the risk of common-cause hardware failures, which can arise from various potential sources.
– maintenance activities performed simultaneously or sequentially on multiple trains of equipment (particularly where such activities may introduce unrevealed hardware faults);
– coincident unrevealed random hardware failures on multiple trains of equipment which affect the same nuclear safety function(s);
– latent design faults affecting multiple equipment trains, and which were not revealed by the design process
6.3.3 Methods which may be used to analyse hardware reliability and the effects of system hardware failures include FTA and FMEA (see 5.3.4)
6.3.4 The hardware design should minimize the potential impact on nuclear safety of the following factors:
– system failure due to random hardware failure;
– hardware failure due to environmental conditions
If the estimated hardware reliability is deemed insufficient for a specific function, appropriate compensatory measures must be implemented These measures may include enhancements to the design or modifications in operations, such as increasing the frequency of operational testing.
Increased operational testing can pose risks, as intrusive activities may inadvertently introduce faults that negatively affect safety To mitigate these risks, testing should ideally occur during station outages or when the equipment is isolated from the operational plant, ensuring that potential faults do not impact nuclear safety.
In the context of a probabilistic safety assessment for a nuclear power plant (NPP), the estimated hardware reliability values, such as those derived from Fault Tree Analysis (FTA), can be integrated into the NPP analysis This integration enhances the precision of the overall reliability calculations for the station.
Maintenance
The hardware design must incorporate specific maintenance requirements outlined in the hardware requirements specification Additionally, it should integrate features that minimize the risk of faults arising from maintenance activities, such as user-friendly access points and error-proofing mechanisms.
– components that may require replacement due to failure should be easily accessible;
– replaceable components should be clearly identified so that maintenance staff may easily check that the correct components are used;
– there should be adequate spacing of terminals;
– there should be adequate provision of dedicated terminals for use during calibration/testing activities (so that plant wiring does not have to be disconnected to facilitate such activities);
– hardware design should have a structured layout with clear labelling to reduce the potential for maintenance errors.
Interfaces
IEC 61513, 6.1.1.2.1, provides system interface requirements which aim to prevent the propagation of failures across system interfaces.
Modification
To the extent required by the hardware requirements specification, the hardware shall be designed to be capable of being modified (see Clause 12).
Power failure
The computer system must be designed to withstand short-term power failures and variations in power supply, including voltage and frequency changes, as specified in the hardware requirements Additionally, the system should include features to alert operators and maintenance personnel about these power fluctuations, although this notification function may not necessarily be assigned to hardware components and could fall outside the scope of this standard.
Component selection
Where pre-existing components are to be used, the design of the components shall be compatible with their role within the system hardware.
Design documentation
The hardware design documentation must detail the hardware design and how the hardware requirements have been met It is advisable to utilize standardized design documentation formats and automated hardware design tools.
A structured hierarchy of design documents for computer system hardware must be created, encompassing multiple documentation levels Each level should detail the relevant design aspects and outline the hardware requirements for the subsequent lower levels Additionally, essential documents for manufacturing, assembly, factory testing, installation, commissioning, maintenance, and operation should be generated throughout the design process.
A preliminary hardware design description outlines the hardware architecture, detailing the structure and interrelationships among various system components It should feature a general layout of the hardware, including block diagrams for subsystems and lower-level modules, as well as specify hardware requirements necessary for the detailed design phase.
– the number and types of central processor units and other processors;
– the number and types of interfaces;
– the number and types of data links and busses
Upon completing the hardware design and development, comprehensive documentation must be created This documentation should provide a detailed description of the design, including lower-level specifics, as well as outlining the hardware's capabilities, limitations, and other essential characteristics.
The final description documentation must include a comprehensive design overview, cross-references to supporting design documents, and a detailed breakdown of hardware subsystems Each subsystem should be described in terms of its major modules and components, utilizing block and circuit diagrams Additionally, the documentation must outline subsystem hardware interfaces in logical, physical, and electrical terms, as well as the computer system hardware interfaces, identifying connections with other systems within or outside the nuclear plant A physical layout description, accompanied by diagrams, is essential, along with qualification data that specifies necessary actions, such as component exchanges, to maintain the required qualification lifetime.
It is essential to include qualification data pertaining to the shelf life of spare parts when applicable Additionally, maintenance requirements must be outlined, along with a detailed description of how the hardware meets reliability and fail-safe property standards.
General
7.1.1 The design and development process shall include formal checks that the hardware design deliverables from each phase of design and development meet the requirements imposed by the previous phase
The hardware verification process starts by ensuring that the hardware design requirements align with the system design requirements It is deemed complete once the system software is successfully integrated into the hardware.
Class 1 and Class 2 systems, IEC 60880 and IEC 62138, respectively, provide relevant requirements for the hardware/software integration phases.
Verification plan
A formal verification plan must be established to outline the approach for verifying hardware design and managing the verification process, and it should be created before any verification actions begin This plan should detail the involved personnel and organizational structure, verification methods, verification levels, schedules, and other key project activities Verification can occur concurrently with the design process, provided that proper configuration control is maintained to promptly identify and rectify errors However, formal verification actions should only commence once design components are officially released for verification by the design team, ensuring that all design documentation is kept under formal configuration control Additionally, the design change process must guarantee that any subsequent modifications to the hardware design are thoroughly verified as required.
Independence of verification
For Class 1 hardware design, it is essential that verifiers maintain managerial independence from hardware designers, potentially being located in different departments or organizations In Class 2 systems, while verifiers must not have designed the items they are verifying, they may belong to the same organization as the design team Additionally, verification personnel must possess technical competence, all verification findings and the design team's responses should be formally documented, and the verification process must adhere to established procedures.
In Class 2 hardware development utilizing Automated Test Equipment (ATE) for verification, the independence requirements apply to the ATE design personnel, not to those overseeing the test performance Conversely, in Class 1 hardware development, individuals are prohibited from testing hardware components they have designed, regardless of whether ATE is used.
Methods
Hardware design verification can be achieved through critical reviews, audits, analyses, manual tests, or automated test equipment (ATE) methods, or a combination of these approaches It is essential to document the rationale behind the selected verification methods in detail to facilitate audits by personnel not directly involved in the design or verification processes When selecting the appropriate verification method, relevant considerations must be taken into account.
– the safety-related classification of the system (i.e Class 1/2, with Class 1 requiring the most rigorous techniques);
The documented reviews and tests conducted on the integrated hardware and software are essential for the system verification and validation processes This approach aims to streamline the hardware verification and validation by eliminating redundant activities, thereby optimizing resource utilization and avoiding unnecessary duplication of efforts.
– previous verification activities performed on the hardware or on systems containing the hardware (i.e where equipment has been effectively pre-qualified);
– system design characteristics, for example, size, maturity/novelty of design principles used, failure modes and complexity;
To ensure thorough testing of subsystems and electronic components, it is essential to utilize supporting data from quality assurance and environmental qualification processes Appropriate tools and methods must be available, with Automated Test Equipment (ATE) employed to enhance the repeatability and thoroughness of testing Calibration of test instruments is crucial for confirming accuracy, and procedures should guarantee that only calibrated instruments are utilized Additionally, software-based test tools need to be validated before use and placed under configuration control All formal testing results must be recorded, with auditable records available to demonstrate that tests have been completed and any anomalies addressed.
Documentation
Auditable records from verification activities must encompass the verification program plan, test procedures, test results, design change records, and documentation of any discrepancies identified during the hardware verification process, along with records detailing the resolution of each discrepancy Test procedures should be clearly articulated, offering step-by-step instructions for hardware verification and including comprehensive information about the test setup Additionally, these procedures must specify unambiguous pass/fail criteria and document any test procedures executed by software.
Discrepancies
Discrepancies identified during verification will be documented and sent to the appropriate personnel for resolution Responses will also be formally recorded to ensure a traceable process for assessing discrepancies and addressing any design deficiencies If design deficiencies are accepted, all effects on system documentation will be thoroughly managed.
Changes and modifications
7.7.1 All design changes shall be subject to design impact assessment to determine which documentation requires amendment and what design and verification processes should be repeated
7.7.2 Modified parts shall be identified in accordance with the relevant quality control procedures.
Installation verification
Verification of correct system installation shall be in accordance with Clause 10.
Validation
System validation of the integrated hardware and software shall be performed as required by
IEC 61513, IEC 60880 or IEC 62138 as applicable.
Verification of pre-existing equipment platforms
When utilizing a pre-existing equipment platform, it is essential to evaluate its suitability for the intended application This assessment should focus on several key design aspects: first, the design process must be reviewed against the relevant requirements outlined in Clause 6; second, actual hardware reliability data should be considered to confirm that reliability targets are achievable, thereby instilling confidence in the hardware's performance; and third, if the initial design review does not provide sufficient justification for the hardware's use, further analysis, testing, or justification may be necessary to support the assessment.
IEC 60780 outlines the essential requirements for qualifying hardware used in nuclear safety applications, emphasizing the importance of adhering to the relevant standards Additionally, Annex B offers a detailed overview of the qualification process.
Subsystems, modules, and components in computer systems, including both pre-developed products like COTS and custom hardware, must be constructed and evaluated according to the applicable standards.
Quality assurance
9.1.1 Manufacturing may be one phase of the overall safety life cycle
Manufacturing is a critical phase in the overall safety lifecycle, and as such, its activities must be incorporated into the hardware quality assurance plan If not included, a separate manufacturing quality assurance plan should be developed to address these activities effectively.
Manufacturing-related activities during the design process (such as manufacturing assessments during product qualification) shall be included in the hardware quality assurance plan of the overall safety life cycle
Hardware produced during the manufacturing phase, and addressed in this clause, includes individual modules, sub-assemblies or equipment as a whole
When defining manufacturing processes for the quality assurance plan, the main focus must be to guarantee that the manufacturing does not jeopardize the product's safety functions.
9.1.3 Procedures and work instructions shall be established for the manufacturing activities
These activities include manufacturing processes and their control, inspection and testing, independent quality surveillance and inspection, identification, handling, packaging, storage and delivery
The procedures and work instructions required for manufacturing activities must be clearly defined based on the significance of the safety functions performed by the hardware components, corresponding to the intended system class.
The objectives of the manufacturing activity are:
– to ensure the manufactured items are identical and meet the product description and specification generated during the design and development phases,
– to ensure the production items meet the requirements demonstrated by the initial model during the qualification programme
When selecting external suppliers for hardware components, it is essential to evaluate their capability to manufacture and deliver items that meet design specifications and quality assurance program requirements as outlined in Clause 9.
When a programmable electronic equipment component is included in the external supply scope, it is essential to evaluate the supplier's capability and commitment to ensure the successful qualification of the equipment during the supplier qualification process.
NOTE Specific product selection and qualification criteria may be found, as appropriate, in standards such as
IEC 60880, IEC 61513 or in related sub-tier standards such as IEC 62671 and IEC 62566
When outsourcing processes that impact product conformity, the designer of the I&C system must ensure adequate control over these processes The quality management plan should clearly define the type and extent of control required for outsourced activities.
Criteria for selecting, evaluating, and re-evaluating external suppliers or subcontractors must be established, encompassing essential factors such as business areas, scope of supply, technical capabilities, manufacturing capacity, quality organization, audit systems, financial health, and market behavior.
9.1.8 Criteria for selection, evaluation and re-evaluation of external products shall be established and these criteria shall be based on the requirements of relevant standards (e.g
IEC 60880, IEC 62671 and/or IEC 62566)
9.1.9 The use of manufacturing processes independently certified to recognised international standards by accredited bodies is recommended (e.g the International Register for
Certificated Assessors scheme for ISO 9001).
Training of personnel
9.2.1 The necessary competence for personnel performing any kind of work involved in the manufacturing and control activities shall be established, documented and maintained
If the records of personnel experience, education, and training do not meet the requirements outlined in section 9.2.1, additional training or relevant actions must be implemented to ensure the necessary competence is achieved Furthermore, the effectiveness of these training efforts and actions taken should be evaluated and documented.
Personnel must be trained to understand the significance of their roles in achieving quality and safety objectives Additionally, it is essential to establish and maintain accurate records of their education, training, skills, and experience.
Planning and organisation of the manufacturing activities
9.3.1 As part of the overall project planning (see 4.3), a manufacturing plan shall be established at the start of the project and shall be kept up to date throughout the project
Effective communication and clear responsibility assignment among different groups involved in design and development are essential for managing interfaces This ensures that all aspects of the equipment relevant to the manufacturing process are well-defined and coordinated.
9.3.3 Effective arrangements for communicating with customers or inspectors shall be established to define and schedule manufacturing steps and the associated inspections, audits or controls.
Input data
9.4.1 Manufacturing inputs shall be established during the design and development phase in order to provide appropriate information for purchasing, production and quality controls including product acceptance criteria
The input data shall include the following information:
– the need for independence between manufacturing activities and the associated processes documented formally;
– any requirements for the customer approval of changes during manufacture to the sourcing of components or manufacturing consumables (e.g solder);
– any requirements for the customer approval of the substitution during manufacture of components or manufacturing consumables (e.g solder);
– any special training as a consequence of the equipment having a nuclear application
During the design process, it is essential to consider any requirements that may affect the manufacturing process This encompasses all relevant statutory and regulatory obligations related to the product, along with its physical and technical characteristics.
Manufacturing standards, such as ISO and ISA, play a crucial role in ensuring the safety of hardware components based on their functional safety class These standards encompass various aspects, including NEMA enclosures, protection standards, fire ratings, material processes, and wiring techniques, all of which contribute to the overall safety and reliability of manufacturing processes.
Before starting purchasing and manufacturing activities, input documents must be reviewed to confirm that product requirements are clearly defined and achievable The results of this review should be documented.
Purchasing and procurement
Specific purchase requirements must be defined based on how the purchased product impacts subsequent product realization or the final product These requirements should include a comprehensive list of documents or access to necessary documentation to ensure the qualification of the equipment.
9.5.2 Procurement process of commercially available components
To ensure compliance with specified requirements, it is essential to provide adequate demonstration or suitable evidence that all equipment components, including electronic boards and housings, meet criteria such as functionality, environmental withstand, reliability, and lifetime.
9.5.2.2 Demonstration shall be provided that the selected components fulfil the expected characteristics
The demonstration may be based on:
– data provided by the supplier of the components (nature and results of testing after manufacture, feedback, results of periodic tests, audits, approvals know-how, etc.),
Self-established feedback is formalized and documented through checks on successive batches, periodic tests on samples, and analysis of operating results, including operating time and component failures.
– analysis (e.g circuit level FMEA), component level operating history assessment, design quality assurance process and records, previous product/component certifications or qualifications,
– or results obtained during type test previously performed
To ensure the quality of purchased components, appropriate measures must be implemented This quality assurance should align with the safety classification of the component's intended functions.
NOTE 1 Related means can consist of type tests of the component itself or of a sub-assembly including it
NOTE 2 The expected quality includes the physical behaviour, static and dynamic electrical behaviour, under normal and extreme environmental conditions as well as the expected reliability
For programmable electronic equipment, refer to specific product selection and qualification criteria in IEC 60880 and IEC 61513 and its related sub-tier standards such as IEC 62671, or
9.5.3 Procurement process of parts used in the I&C equipment
9.5.3.1 The type and extent of control applied to the supplier and the purchased product shall be defined and contractually established with the supplier
When acquiring programmable electronic components, it is essential to implement stringent configuration management and version control for both hardware and software revisions, in accordance with approved qualification and manufacturing records The manufacturer must report all changes and provide a safety impact assessment.
9.5.3.2 Records of the results of evaluations and any necessary actions arising from the evaluation shall be maintained
9.5.3.3 Purchasing information shall describe the product to be purchased, including, where appropriate:
– technical specification, (e.g as schematics, drawings, control programs, test programs),
– requirements for approvals (e.g processes, procedures, product and equipment),
– requirements for qualification of personnel,
9.5.4.1 Inspection or other activities shall be established and performed to ensure that the purchased product, including the related expected documentation, meets the specified purchase requirements (see 4.2 and Clause 7)
9.5.4.2 Where verification at the supplier's premises is intended to be performed, verification arrangements and verification methods used shall be stated in the purchasing information
The preparation and acceptance of factory acceptance test plans must include specific requirements for supervision and witnessing of the acceptance testing Additionally, final factory surveillance and inspection activities are necessary to address any previously identified non-conformance issues and to ensure they are resolved before shipment to the site.
9.5.4.3 The verification arrangements shall contain statements related to follow-up and control steps such as sampling tests, on-site observation or breakpoints
Strict quality control must be implemented for incoming goods, utilizing bonded stores when necessary This quality assurance process includes both non-intrusive methods, like visual inspections, and, when suitable, intrusive methods such as electrical testing and assessments of functional behavior.
9.5.4.5 Dimensional controls and sampling plans for inspection shall conform to those specified in ISO 2768-1, ISO 2768-2, ISO 3951-1 and ISO 3951-2.
Production
9.6.1.1 The overall manufacturing activity shall be defined in a reference process description as part of the overall product life cycle
9.6.1.2 Production shall be planned and carried out under controlled conditions
Controlled conditions shall include, as applicable,
– availability of information that describes the characteristics of the product,
– use and availability of suitable equipment and tools,
– full traceability of component parts,
– full recording of the dates and personnel involved for each production operation,
– implementation of product release, delivery and post-delivery activities
9.6.2 Specification and control of production environmental conditions
9.6.2.1 Requirements for the environmental conditions for production and control areas shall be defined as necessary
9.6.2.2 Area access conditions such as rights to enter, procedures to follow and clothing to be worn shall be defined as necessary
Control plans must be established for managing environmental conditions and access to manufacturing facilities This includes monitoring atmospheric dust, creating an inert atmosphere, regulating humidity and temperature, controlling the chemical composition of water, and managing electrostatic discharges.
9.6.3 Validation of processes for production
Specific production processes must be validated when the output cannot be confirmed through later monitoring or measurement, as deficiencies may only become evident after the product has been used or delivered.
9.6.3.2 Validation shall demonstrate the ability of these processes to be robust in order to achieve planned and repeatable results
Arrangements shall be established for these processes including, as applicable:
– defined criteria for review and approval of the processes,
– approval of equipment and qualification of personnel,
– use of specific methods and procedures,
– requirements for records and validation,
– handling of defective parts including possible consequences for the production process
9.6.4 Assessment of the manufactured I&C equipment acceptance and reproducibility
9.6.4.1 The equipment produced shall be assessed and stated to be accepted by the customer
Acceptance will be determined by the quality assurance management, the comprehensive hardware qualification process, and the successful qualification outcomes of components, modules, or equipment, which are typically the first of their kind.
The designer of the I&C system must demonstrate the capability to produce series equipment that is identical to the qualified hardware, either through in-house manufacturing and assembly or by utilizing subcontracted manufacturing and assembly services.
9.6.4.4 The evaluation of manufacturing should be based on surveys focusing on the I&C system manufacturer's organization and the technical means to manufacture the products
When modifications arise following the qualification of the initial item, the designer of the I&C equipment must conduct an impact analysis This analysis will lead to conclusions that determine whether a new qualification is necessary or if the results from the previous qualification can still be considered valid.
9.6.5 Control of production tools, monitoring and measuring devices
9.6.5.1 The tools necessary to manufacture the product shall be determined
9.6.5.2 Monitoring and measurement processes to be undertaken on the product shall be determined to provide evidence that the product conforms to its requirements
9.6.5.3 Processes shall be established to ensure that production, monitoring and measurement are carried out in a manner that is consistent with the production, monitoring and measurement requirements
9.6.5.4 Where necessary to ensure valid results, tools and measuring devices shall:
– be calibrated or verified, at specified intervals or prior to use, against measurement standards or established basis used for calibration or verification which are recorded;
– be adjusted or re-adjusted when necessary;
– have identification in order to determine their calibration status;
– be safeguarded from adjustments that would invalidate the measurement result;
– be protected from damage and deterioration during handling, maintenance and storage
9.6.5.5 Quality assurance processes shall ensure that if manufactured equipment is found not to conform to requirements due to faults in the manufacturing process that adequate corrective action is taken
9.6.5.6 Records of the results of calibration and verification shall be maintained
When utilizing software-based devices for monitoring and measurement activities, it is essential to verify that the device meets the requirements of its intended application This confirmation should occur before the device's initial use and be re-evaluated as needed.
NOTE Confirmation of the ability of computer software to satisfy the intended application would typically include its verification and configuration management to maintain its suitability for use
9.6.6.1 The manufactured system shall be identified, as well as the parts and materials used to manufacture the system, by suitable means throughout product realization
9.6.6.2 The manufactured system status shall be monitored throughout the overall production process
9.6.6.3 A unique identification of the system, and of the included parts, shall be ensured and records of changes shall be maintained for traceability purposes
An identification file must be created for each piece of equipment and subassembly to outline the reference model, detailing the equipment's description, internal assemblies, components, and versions These files typically encompass a comprehensive list of sub-assemblies, along with plans, drawings, diagrams, and data sheets, as well as references to detailed sub-tier files, ensuring a thorough description of each system version and its sub-assemblies.
To ensure conformity to requirements, the system and its components must be preserved during internal processing This preservation includes proper identification, handling, packaging, storage, and protection conditions prior to the acceptance testing of the equipment.
9.6.8 Sustainability of tools and skills
During the planning of manufacturing activities, it is essential to define the maintenance requirements for tools and other means utilized in manufacturing, testing, and validation These requirements should align with the safety class of the functions performed by the components.
9.6.8.2 Requirements shall be defined for maintaining the skills involved in manufacturing, validation and testing activities
9.6.9 Resolution and control of non-conformities
9.6.9.1 Non-conformities detected during environmental qualification tests, verification activities or manufacturing shall be identified and recorded according to the quality assurance plan (see 4.3.3)
Corrections and solutions must be documented in a manner that allows for easy auditing by external parties Records should detail the nature of the changes, include an impact analysis, and provide justifications along with necessary approvals.
Controls must be implemented on the production line to verify that modifications are accurately incorporated and that the controls and testing procedures, including manufacturing, identification, and acceptance tests, have been properly adjusted.
10.1 Packing, handling, transport, storage and unpacking shall be such as to prevent any damage to the system
Before unpacking and installing the system, it is essential to ensure that the installation environment meets the hardware environmental requirements outlined in section 5.4.
To ensure proper installation, cabling, and wiring of the system according to design specifications, adequate procedures and information must be provided, including earthing requirements and equipment identification A quality plan should be implemented, and the system must be installed, cabled, tested, and commissioned following established procedures.
10.4 The proper working of the system at site shall be checked by planned and specified commissioning tests, as required by IEC 61513
10.5 The tests shall be performed in accordance with relevant standards, for example,
The chosen severity level of electromagnetic interference testing must meet or exceed the most extreme estimated conditions that the system may encounter during operation.
For Class 1 and 2 systems, off-site testing for electromagnetic interference withstand is essential Class 2 systems typically require this testing to ensure proper operation Additionally, on-site testing for Class 1 systems should be conducted when feasible and effective.
Maintenance requirements
11.1.1 A formal procedure (or procedures) shall be specified and applied to control the execution and the documentation of maintenance activities (see Annex C)
This shall take into account
– preventative actions required to reduce the potential for faults to be introduced and the potential for personal injuries to occur;
– organizational and operational preparations required if the maintenance activities have the potential to affect plant operation, or the availability of safety functions or safety-related functions
Maintenance must be conducted by qualified and authorized personnel following established procedures These procedures should include provisions for personal certification, either by an authorized individual or through automated testing, to ensure that all tasks directly affecting safety are completed satisfactorily.
All relevant information, such as time and date, replacements fitted, etc., shall be recorded
11.1.3 The records arising from maintenance work shall be made available for audit if required
For certain essential components, implementing a preventative maintenance strategy is preferable to waiting for failures to occur This approach involves replacing components within a specified timeframe, ensuring they are not used beyond their qualified life, as outlined in IEC 60780.
Spare parts maintained by the operating organization must be stored in an environment suitable for their specific conditions It is essential to monitor and adjust the shelf life of these parts over time, considering their aging characteristics Additionally, necessary actions to ensure the readiness of the spare parts, such as regular energization, should be implemented.
Spares must meet qualification standards equivalent to those for operational components Any attempt to lower the qualification requirements or extend the lifespan of Class 1 or 2 system components should be considered a system modification and evaluated accordingly, as outlined in Clause 12 of IEC 61513, which details the controls for system modifications.
11.1.7 All spares shall be under configuration control and shall have adequate identification marking or labelling
To ensure a reliable future supply of spare components, it is advisable to secure them as much as possible This can be achieved by maintaining an inventory of spare parts, obtaining guarantees from suppliers, or having access to manufacturing capabilities.
Failure data
11.2.1 Failure data acquired during equipment operation constitutes a major source of information which can be used to improve
– component reliability data knowledge (by taking into account real operating environment conditions);
– equipment reliability evaluations (by determining actual field failure data and by observing availability in operating conditions);
– maintenance policy (through better spare parts optimization, better preventative maintenance schedules and better maintenance personnel training requirements)
11.2.2 Accordingly, field failure data (from information available from maintenance reports) should be logged in a failure data bank
11.2.3 The maintenance reports shall contain (if relevant and if known)
– identification of the system with the failed component;
– failure circumstances and failure effects;
– component location within the system;
– description of the fault which caused the failure;
– identification of person(s) who raised the report;
– identification of person(s) who diagnosed the fault
Periodic reviews of failure data for safety-critical systems are essential to maintain component failure rates within acceptable limits It is important to identify and analyze any statistically significant negative trends in the data to predict future equipment performance This proactive approach ensures that the equipment operates satisfactorily until the next assessment or until replacement is necessary, whichever comes first.
Maintenance documentation
11.3.1 Instructions for maintenance shall be provided in written or electronic form by means of procedures, manuals, handbooks, etc
11.3.2 Maintenance documents shall describe the hardware maintenance policy for the equipment in use, including identification of hardware components which require regular checking, re-calibration or replacement
11.3.3 Maintenance documents shall describe any relevant diagnostic processes which should be used to detect the failure of specific modules
11.3.4 Documentation shall describe the repair policy, i.e
– the methods of repair or substitution of different subsystems, modules and components;
– any restrictions which the system should be subjected to during repair time (for example, the system or parts of the system which shall be switched off);
– the extent to which equipment shall be revalidated after a repair
In addition to regular scheduled maintenance, it is essential to implement diagnostic procedures that can aid in investigating unusual system behavior and identifying faulty components when applicable.
Hardware design modification may be required to correct defective performance or to address new or revised performance requirements
12.1 The process controlling hardware design changes shall be compliant with the requirements of 6.3.6 of IEC 61513:2001
Hardware design changes that affect multiple design phases must be managed through a documented procedure This procedure should consider the potential impacts on other system design elements, including hardware components and software.
The design change procedure must identify the effects of all hardware modifications on the verification, validation, and qualification processes of the hardware and system, ensuring that any necessary rework is completed.
Relevant requirements for system operation are provided by IEC 61513 (IEC 60880 and
IEC 62138 contain additional relevant information)
Overview of system life cycle
Requirements for systems important to safety
Final hardware design and prototype manufacture
Installation commissioning and System test Operation
NOTE In the interest of clarity, the feedback paths have not been shown.
Restricted use or utilization, test frequency, on-going qualification
Complete documentation of the type test, analysis, operational experience
Function, calibration, comparison with type tested equipment
Supplementary experimental and analytical assessment possible?
Qualified type tests and supplementary analysis?
Input from operating staff Input from maintenance staff Activity
Timetable, safety measures, material, spare parts provision
Signifies staffing related to activity shown
The following references contain information of some relevance to this standard
IEC 61226, Nuclear power plants – Instrumentation and control systems important to safety –
Classification of instrumentation and control functions
ISO 12207, Information technology – Software life cycle process
IAEA NS-R-1:2000, Safety of nuclear power plants: Design
1.2 Utilisation de cette norme pour l’évaluation des matériels prédéveloppés
1.3 Application de cette norme au développement des composants logiques programmables 45
5.2 Exigences fonctionnelles et de performances 51
5.4 Exigences relatives à la résistance aux conditions d’environnement 53
7.10 Vérification de plateformes matériel préexistantes 59
9.3 lanning et organisation des activités de fabrication 62
10 Installation et mise en service 67
Annexe A (informative) Vue générale du cycle de vie système 71
Annexe B (informative) Tracé du contour de la qualification 72
Annexe C (informative) Exemple de procédure de maintenance 73
CENTRALES NUCLÉAIRES DE PUISSANCE – INSTRUMENTATION ET CONTRÔLE-COMMANDE
IMPORTANTS POUR LA SÛRETÉ – EXIGENCES APPLICABLES À LA CONCEPTION
DU MATÉRIEL DES SYSTÈMES INFORMATISÉS
The International Electrotechnical Commission (IEC) is a global standards organization comprising national electrotechnical committees Its primary goal is to promote international cooperation in standardization within the fields of electricity and electronics To achieve this, the IEC publishes international standards, technical specifications, technical reports, publicly accessible specifications (PAS), and guides, collectively referred to as "IEC Publications." The development of these publications is entrusted to study committees, which allow participation from any interested national committee Additionally, international, governmental, and non-governmental organizations collaborate with the IEC in its efforts The IEC also works closely with the International Organization for Standardization (ISO) under a mutually agreed framework.
Official decisions or agreements of the IEC on technical matters aim to establish an international consensus on the topics under consideration, as each study committee includes representatives from the relevant national IEC committees.
The IEC publications are issued as international recommendations and are approved by the national committees of the IEC While the IEC makes every reasonable effort to ensure the technical accuracy of its publications, it cannot be held responsible for any misuse or misinterpretation by end users.
To promote international consistency, the national committees of the IEC commit to transparently applying IEC publications in their national and regional documents as much as possible Any discrepancies between IEC publications and corresponding national or regional publications must be clearly stated in the latter.
The IEC does not issue any conformity certificates itself Independent certification bodies provide conformity assessment services and, in certain sectors, have access to IEC conformity marks The IEC is not responsible for any services performed by these independent certification organizations.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication
The IEC and its directors, employees, agents, including its specialized experts and members of its study committees and national committees, shall not be held liable for any injury or damage, whether direct or indirect, arising from the publication or use of this IEC Publication or any other IEC Publication, nor for any associated costs, including legal fees and expenses.
8) L'attention est attirée sur les références normatives citées dans cette publication L'utilisation de publications référencées est obligatoire pour une application correcte de la présente publication
Attention is drawn to the fact that some elements of this IEC publication may be subject to patent rights The IEC cannot be held responsible for failing to identify such patent rights or for not reporting their existence.
Cette version consolidée de la CEI 60987 comprend la deuxième édition (2007)
[documents 45A/662/FDIS et 45A/666/RVD] et son amendement 1 (2013) [documents
45A/897/FDIS et 45A/906/RVD] Elle porte le numéro d'édition 2.1
The technical content of this consolidated version is identical to that of the base edition and its amendment; it has been prepared for user convenience A vertical line in the margin indicates where the base publication has been modified by Amendment 1 Additions and deletions are highlighted in red, with deletions struck through.
La Norme internationale CEI 60987 a été établie par le sous-comité 45A: Instrumentation et contrôle-commande des installations nucléaires, du comité d'études 45 de la CEI:
Cette édition inclut les modifications techniques majeures suivantes par rapport à l’édition précédente:
• prise en compte du fait que les techniques de conception du matériel des systèmes informatisộs ont progressộ de faỗon significative ces derniốres annộes;
• mise à jour du format de la norme pour être conforme aux directives ISO/CEI portant sur le style des normes;
• mise en cohérence de la norme avec les nouvelles révisions des documents de l’AIEA
NS-R-1 et NS-G-1.3, cela comprenant autant que possible une adaptation des définitions;
• remplacement, autant que faire se peut, des exigences associées aux normes publiées depuis la parution de la première édition de la CEI 60880, plus particulièrement la
CEI 61513, la CEI 60880, édition 2, et la CEI 62138;
• revue des exigences existantes et mise à jour des définitions et de la terminologie
Cette publication a été rédigée selon les Directives ISO/CEI, Partie 2
The committee has determined that the content of the original publication and its amendments will remain unchanged until the stability date specified on the CEI website.
"http://webstore.iec.ch" dans les données relatives à la publication recherchée A cette date, la publication sera
• remplacée par une édition révisée, ou
IMPORTANT – The "colour inside" logo on the cover of this publication signifies that it contains colors essential for a better understanding of its content Users are therefore encouraged to print this publication using a color printer.
INTRODUCTION a) Contexte technique, questions importantes et structure de cette norme
The fundamental principles of nuclear instrumentation design, particularly as applied to the safety systems of nuclear power plants (NPPs), have been interpreted in nuclear industry standards with reference to wired systems This is especially highlighted in the IAEA's Safety Guide 50-SG-D3, which has since been replaced by the IAEA's NS-G-1.3 guide.
The first edition of IEC 60987 was published in 1989 to address the material aspects of designing computerized systems that are critical for safety, specifically focusing on safety systems and related security systems.
Bien que beaucoup des exigences contenues dans la première édition de la norme restent pertinentes, des facteurs significatifs ont justifié du développement de la révision de la
– une nouvelle norme est parue qui traite en détail des exigences générales applicables au systèmes nucléaires importants pour la sûreté (la CEI 61513);
– l’utilisation de plateformes système prédéveloppées, plutôt que de développements faits sur commande, a significativement augmentée b) Position de la présente norme dans la collection de normes du SC 45A de la CEI
La norme de premier niveau du SC 45A concernant les systèmes informatisés importants pour la sûreté utilisés dans les centrales nucléaires de puissance (CNPs) est la CEI 61513
La CEI 60987 est un document du SC 45A de deuxième niveau qui traite de la question générique de la conception du matériel des systèmes informatisés