IEC TR 63084 Edition 1 0 201 7 06 TECHNICAL REPORT Nuclear power plants – Instrumentation and control important to safety – Platform qualifaction for systems important to safety IE C T R 6 3 0 8 4 2 0[.]
General – Structure of the platform qualification 1 5
This document discusses the qualification of platforms for obtaining pre-qualification credits essential for implementing safety-critical I&C systems It emphasizes that application-specific qualifications must also be conducted for these systems The goal is to ensure that the pre-qualification evidence meets the nuclear use requirements of the existing I&C system and adheres to the engineering processes for developing application-specific components The qualification process aims to identify and address any gaps found during this evaluation.
When utilizing a platform for an application, the platform's properties impose specific constraints that influence the design and implementation phases These constraints are incorporated as requirements during development, ensuring that the platform's features are effectively utilized Following this, the production modules from the platform are integrated into the system, which is subsequently tested and installed in the plant This life cycle is illustrated in Figure 1, which delineates the processes for both platform and application development.
Figu re 1 – Platform and application development process
The development of platform requirements relies on engineering judgment to encompass the necessary specifications before its application in a plant setting Consequently, platforms are not directly influenced by plant safety requirements; however, developers must understand the intended usage to incorporate essential features for diverse applications.
Engineering judgment Plant design basis
Design Platform features used in design of application
Production modules integrated into system Test
Manufacturing I nstallation Operation and maintenance Performed at plant
Production modules Repeat for each module
Platform qualification includes the assessment of hardware modules, ensuring they meet relevant environmental standards, as well as software modules and the application software development environment This individual module qualification is typically enhanced by integrating hardware and software qualification processes.
Figure 2 provides a general overview of the qualification process for I&C systems based on their intended safety class The qualification of the I&C platform is conducted as the first level in a two-level approach, while the second level focuses on the application-specific qualification of the I&C system, which is beyond the scope of this document.
Figure 2 – General overview of a typical qualification process
The compliance of individual hardware and software modules of the I&C platform is assessed against suppliers' system descriptions and the general design, implementation, and verification requirements outlined by the IEC SC 45A standards These requirements are crucial for defining the essential features of the I&C platform Typically, these features are validated through representatively integrated I&C systems, which consist of interconnected module configurations The primary goal of this evaluation is to ascertain the basic suitability of the I&C platforms for systems of a specific safety class at the earliest possible stage.
I&C platform as an object of qualification – Conceptual design 1 6
I&C standards are typically designed for I&C systems, necessitating the interpretation and adaptation of these requirements for I&C platforms This approach ensures that platform qualification serves as a prerequisite for the safety system qualification, as illustrated in Figure 2 The advantage of system qualification lies in the prior testing and analysis of platform modules, eliminating the need for redundant tests during I&C system implementation However, it is important to note that while generic platform qualification can support the process, it cannot replace the need for I&C system qualification.
Platform qualification is essential for selecting and acquiring an Instrumentation and Control (I&C) platform tailored to a specific plant's needs This report outlines evaluations designed to streamline the purchasing process by assessing whether the platform's scope and reliability align with the requirements of the intended I&C system.
Documentation of the I &C platform 1 6
The I&C platform can be qualified only if properly documented Documentation of the platform is to be discussed with the vendor, but generally the following items will be expected:
• A general description of the product with references to all material allowing detailed insight into product operation
I &C system (in a NPP) I&C module of the platform
• List of standards and regulations defining basis for product development, including vendor's formal commitment to compliance with the requirements of the listed standards
• (Access to) conceptual design and manufacturing drawings and schemes of components, sub-assemblies, circuits, etc All with descriptions and explanations necessary for the understanding of those drawings and schemes
• Platform software architecture, the level of access to the code of modules will be dependent on the class of intended use
• Information on manufacturer's software development environment, procedures and software tools; the level of detail will be dependent on the class of intended use
• A description of the vendors (and/or sub-suppliers as appropriate) manufacturing processes, hardware design processes, and hardware testing techniques used for creating the hardware of the I&C platform
• Information on security of the product development processes
• Documentation of V&V procedures Here both access to records of unit tests and of validation tests at the final product integration Information on validation methods and tools included
• Records of product maintenance, product failures etc (necessary for evaluation of operating experience)
The vendor must also supply general information about the organizations involved in the platform procurement processes, highlighting the expertise levels of key staff members.
Organisation of the qualification 1 7
The qualification process for platform 1 will be systematically organized in accordance with established management methods outlined in IAEA guides, such as SSG-39, and IEC standards, including IEC 61513 These methodologies are summarized as follows:
A clearly identifiable party must take initiative and responsibility for the qualification process, which could be the plant owner, vendor, or an I&C branch representative such as an independent assessor or regulator Subsequently, a qualification project group, consisting of the aforementioned parties, can be established to oversee the qualification body.
A platform concept report is essential for specifying platform requirements, as it outlines the safety needs of target industries and clients The decisions made in the platform concept are driven by market demands, reflecting the functionalities that the vendor chooses to implement.
• Qualification scope and plan must be defined and documented; indispensable for the qualification is that the hardware and software components, and their constituents, are uniquely identifiable
• Processes and methods of qualification/certification are specified and established
• Presentation of results is agreed upon, including documentation and scope of qualification/certifications to be issued
The Finnish regulatory body employs a type approval approach to ensure that products and their implementations comply with the relevant technical requirements.
All demonstrations, whether suggested by the vendor or mandated by the qualification body, should be meticulously planned These plans must outline the methods for achieving the demonstration, specify the types of evidence to be utilized, and detail the timeline for producing this evidence Effective planning is crucial, especially when addressing safety and security concerns.
The following parties (depending on the qualification objective) are involved in the process of platform qualification:
Product development, manufacturing, distribution, and maintenance are typically handled by various organizations In these situations, the vendor acts as the primary contractor, legally representing all involved entities.
An accredited organization is responsible for the independent assessment of the I&C platform, ensuring that the vendor's claims and proofs are adequate and trustworthy National accreditation bodies grant this authorization, serving as a vital means to demonstrate the competence of conformity assessment organizations.
The involvement of the regulatory body may be optional depending on national practice
• Plant operating organisation – plant owner that is responsible for the plant and its particular I&C project where the I &C platform may be used
The involvement of the plant operating organisation may be optional depending on national practice
As roles and positions of the parties are concerned, note the following:
• The qualification process covers both vendor's organization and vendor's product – I&C platform Both stages of qualification may require different competences of the qualifying party
The plant owner typically receives platform qualification, enabling the selection of a platform that meets their Instrumentation and Control (I&C) requirements Additionally, the owner can actively participate in the qualification process by commissioning an independent assessor or by appointing their own experts.
• Depending on the party initiating the qualification, the result can be generic for the platform or valid specifically for particular kinds of I&C systems
• The independent assessor (see definition 3.1 0) has to be agreed by all parties involved in the process
The independent assessor possesses the necessary knowledge and expertise to navigate the complexities of the I&C platform, backed by a sufficient amount of experience in the platform domain It is important to note that this individual is not accountable for any aspects of the platform development life cycle, including procurement, design, implementation, and testing phases.
Qualified experts, certified by relevant boards or societies, along with those holding professional licenses or academic qualifications, are essential for representing independent assessors, regulators, and owners, ensuring recognized expertise in their respective fields.
Vendors can be assessed through evaluations of their organizational performance, including project execution in product development, design, manufacturing, delivery, service, and maintenance Guidelines for vendor qualification are available in the rules set by leading I&C producers for sub-supplier qualification.
Scope of the qualification 1 9
Hardware modules 1 9
The evaluation and assessment of hardware modules are crucial to ensure their characteristics meet the specifications of the I &C platform To achieve this, it is essential to have thoroughly documented hardware modules that facilitate comprehensive evaluation.
• The ability of the hardware module to perform the specified functions
• Susceptibility of the hardware module to environmental conditions (temperature, moisture, vibration, electro-magnetic influences)
• The ability of the evaluated hardware module to function under all environmental conditions claimed by the supplier, and following IEC/IEEE 60780-323 and other identified standards
• The reliability and maintainability of the evaluated hardware module
• The correct version of the firmware (as identified by configuration management), if used (the correct performance of the firmware is part of the software qualification)
When evaluating vendors, it is crucial to examine their manufacturing processes, hardware testing methods, and design practices Key considerations include the use of certified components to avoid counterfeit parts, maintaining supply chain integrity, and conducting thorough hardware testing to verify operability and compliance with requirements Additionally, the hardware design should be carefully crafted to prevent the introduction of unintended functions and failure modes.
The usefulness of operating experience, possibly previous non-nuclear qualifications or certificates may be taken into account Complementary testing and analyses of selected modules will be recommended
Electronic boards incorporate Hardware Description Language Programmed Devices (HPD) to facilitate electronic functions The development documentation for HPD software components is evaluated for compliance with engineering procedures and standards such as IEC 62566 This evaluation process follows a structured approach aligned with the phases of the software life cycle development, which will be detailed in the subsequent paragraphs.
The development of a board featuring a High-Performance Device (HPD) follows a comprehensive global process, which includes a dedicated procedure for the HPD itself The final validation of the HPD occurs on the actual target, ensuring that the HPD functions as intended when integrated into the board This targeted process is essential for confirming the design and functionality of the customized HPD.
Once the HPD is developed and validated, the board by itself and as a whole is managed and qualified like any other boards (type testing, environmental, seismic, etc.)
Development documents are evaluated based on key principles such as top-down design and modularity, ensuring both formal and functional consistency Formal consistency includes aspects like meaningful identification, consistent references, clear structure, and comprehensible text with illustrations Functional consistency is assessed for the document and its phase transitions, focusing on the accurate and complete transfer of functional and non-functional requirements across development phases This evaluation emphasizes the execution of essential tests and the inclusion of critical information, such as timing behavior, interface descriptions, failure behavior, and self-tests, in the development documents.
Operational system software
The platform qualification encompasses the operational system software that runs on the target processor during system operation This includes the operating system, input/output drivers, exception handlers, communication software, application-software libraries (such as functional blocks libraries), online diagnostics, and management of redundancy and graceful degradation.
V&V activities in software development involve verifying life cycle documentation and validating fully coded software components Verification assesses whether documents align with national and international standards, as well as internal guidelines of the software designer Additionally, it evaluates the extent to which these documents meet the requirements set in earlier phases For generated software code, verification activities may integrate multiple development phases.
Validation requires assessing and evaluating whether the software meets the requirements stated in the requirement specification Validation comprises extensive tests of the software
Verification and validation (V&V) activities encompass reviews, analyses, and tests, utilizing various methods and techniques Comprehensive discussions on V&V methods can be found in Annex E of IEC 60880:2006 and Annex G of IEEE Std 1012 TM -2004.
The requirements specification is a crucial initial step in software development, outlining the functional, technical, and qualitative requirements for the components It should also detail quality assurance measures and acceptance criteria For software components, their role within the overall system must be clearly defined Additionally, the content and methods for development and verification and validation (V&V) activities vary based on safety requirements.
The review tasks concerning the requirements specification may be organized in three steps
The consistency check confirms the document's transparency and usability Additionally, the content completeness assessment reveals that the component description is both comprehensive and adequate Lastly, it is demonstrated that the layout format is appropriate for the technical implementation of the necessary functions.
Review tasks outlined in the requirements specification can be applied to documents in later phases of the development life cycle, including preliminary design, detailed design, and test documentation These review tasks are influenced by the specific phase model of the development life cycle used by the organization.
Incorporating cyber security requirements into the software development life cycle is essential for effective design This process involves planning, integrating cyber security considerations into product design, and ensuring that these requirements are implemented and tested Reference materials such as IEC 62645 and the NIST SP 800 series can provide valuable guidance A thorough review process is necessary to confirm that all identified cyber security requirements have been adequately addressed.
Effective verification and validation (V&V) of coded programs hinge on thorough testing, which involves selecting appropriate test cases and ensuring compliance with requirements To prepare for testing, it is essential to create a comprehensive test set aligned with a defined strategy, supplemented by various program analyses beyond mere correctness and robustness tests Consequently, reviewing the test specifications and reports encompasses not only the evaluation of the planned and executed tests—such as strategy, test case selection, execution, and evaluation—but also the assessment of the program analyses employed.
To ensure comprehensive development, it is essential to conduct analyses for both formal and technical traceability of functional and non-functional requirements Formal traceability ensures that requirements are fully transitioned throughout the development life cycle, linking them from the initial stages down to the final software code and up to verification and validation (V&V) activities This process confirms that all testable requirements are adequately tested and identifies which requirements are addressed by each test On the other hand, technical traceability focuses on the consistency and plausibility of derived or refined requirements and design decisions, ensuring that outputs from each phase align with previous phases and maintain internal coherence.
To effectively translate program design into source code, it is essential to adhere to a set of rules that promote "good programming style," enhancing readability, modifiability, and testability Certain requirements, such as restricting the use of specific language constructs, are crucial for implementing validation techniques and conducting thorough program testing A review process will ensure that the established coding rules have been recognized and adhered to.
Application software
Application software is typically tailored for Instrumentation and Control (I&C) systems rather than being a generic component of the platform However, there can be specific developments, such as a neutron-flux measurement system, that utilize a more general platform In such instances, certain elements of the application software may fall under the platform qualification scope For further details on application software development, refer to section 7.3.3.
Tools
The qualification of tools is determined by the necessary reliability and the potential risks of errors and faults they may introduce, as well as the degree to which the outputs of these tools will be verified Relevant guidance can be found in IEC 60880 and IEC 62138.
The evaluation of tools focuses on their ability to address the various phases of the safety life cycle, ensuring comprehensive coverage This completeness enhances the quality assurance and reliability of safety-critical functions Additionally, clear handling instructions and effective interconnectivity are essential factors to consider.
The qualification process for application software must include tools that impact its implementation, such as code generators These tools will be assessed to ensure they meet functional and qualitative standards Specifically, the evaluation will follow Clause 14 of IEC 60880:2006 for tools that generate application code In contrast, tools that do not affect the application software, like documentation tools, will adhere to the ISO 9001 development process for qualification.
Integration to a representative system
The integration of hardware and software components in a representative I&C system is essential for testing the operability of the software/hardware complex and its generic platform characteristics This system will be configured based on qualification expectations and typical platform usage.
Platform characteristics are considered generic when they remain valid regardless of the specific hardware and software configurations If they are not universally applicable, the qualification results will be limited to the particular configuration for which the platform characteristic is deemed valid.
Methods of qualification
General
According to IEC 61 51 3, it is good practice to perform qualification in well-defined stages, i.e by taking credit from platform qualification (see Figure 2)
Type testing, along with operational experience and analysis, forms the foundation of qualification as outlined by IEC 60780-323, IEC 60880, and IEC 62138 standards Typically, modules undergo qualification through type testing or a combination of methods, which may include evaluating operational experiences, conducting audits, performing analyses, and executing additional testing.
The methods of qualification will rely generally on review and evaluation of platform development processes, as well as on general evaluation of platform functions and capabilities
Starting the qualification process requires a thorough review of the platform information provided by the vendor, as outlined in section 5.3 This review should be conducted in close collaboration with the vendor to ensure that all necessary information is accessible to the assessing parties.
Special attention will be paid to application development environment (see 7.3.3) where the qualification may be enhanced by the following guidance:
• Prepare specification (list) of the required environment properties (see Clause 6) complemented with information on platform documentation and on the particular requirements of the qualifying parties
• Start qualification with vendor's demonstration of platform properties
• Follow demonstration by the audit of the issues selected at the demonstration
• Allow representatives of the qualifying parties short training and “hands on” experience of the application environment chosen for the representative system (see 6.2.5)
• Define test cases for detailed evaluation of selected environment features
• Refer to earlier projects of plant I&C systems, paying special attention to the occurrence of late changes in specifications and scope of the field tests required.
Type testing
Type testing, initially designed for qualifying hardware modules, involves testing representative samples of these modules This concept has also been adapted for software modules where applicable.
Type testing aims to distinguish between tests and inspections that are independent of a specific plant and those that are tailored to the unique design of the instrumentation and control (I&C) system By utilizing type-tested modules, one can trust that these modules meet the specifications outlined in the data sheets or software development documents Additionally, tests and inspections can be conducted independently and prior to their implementation in the plant Importantly, the type testing procedure is only required to be performed once, allowing subsequent uses in an I&C system to reference the successful type testing This approach not only reduces the number of tests and inspections needed for a specific plant but also establishes a clear framework for the licensing process of an I&C system.
All hardware and software modules required for the implementation of the I&C system must be managed under configuration management as outlined in section 6.3.2.3 of IEC 61513:2011 at the system or platform level, and section 5.6 for software This ensures that the deliverable target platform, including both software products and hardware equipment, matches the configuration that was qualified through testing.
Qualification is performed in accordance with the specified applicable industry codes and standards to ensure that the platform modules will function as required
The qualification effort for a platform is determined by its intended use for class 1, class 2, or class 3 I&C systems According to IEC 61513, the software design and verification and validation (V&V) efforts can be categorized Class 1 systems must adhere to the criteria and requirements outlined in IEC 60880, while class 2 and class 3 systems are governed by the criteria and requirements specified in IEC 62138.
Operating experience
Effective operating experience relies on well-documented data that accurately represent relevant operational conditions and performance It is essential to evaluate past operational conditions and performance in relation to the current conditions and performance of the equipment being qualified Consequently, the application of operating experience is confined to these specific circumstances.
The existing standards and guidelines lack concrete support for utilizing operating experience; instead, they recommend tests and certification Operating experience can help address quality gaps in products and is often viewed as a confidence-building measure in the qualification process However, statistical testing to gather operating experience data has proven to be an ineffective method.
Vendor is expected to be able to present all data on platform operational safety performance
To ensure effective evaluation, it is essential to grade platform performance records based on established performance indicators Safety incident records, particularly those involving human errors due to improper platform use, are of critical importance Additionally, all operational performance data from vendors should be accessible to the qualifying group, and both past and current users of the platform should be encouraged to provide references.
In case of newly developed I &C platforms, operating experience may be gained by using the platform at first in lower classified systems.
Analyses
Qualification by analysis, as outlined in IEC/IEEE 60780-323, necessitates a logical evaluation or a representative model of the modules being qualified This model relies on the physical laws of nature, test data, operational experience, and condition indicators To establish qualification, one can analyze data and tests related to material properties, equipment ratings, and environmental tolerances However, it is important to note that analysis alone is insufficient to demonstrate qualification.
There is a variety of techniques to analyse hardware and software modules They are needed only from case to case The techniques can be grouped into:
• Proofs (from simple algorithm checks to formalized mathematical deductions)
• Static analyses (examinations of the program code; from simple standard tests to complex path analyses)
• Dynamic analyses (observation and recording of the runtime behaviour; from simple time measures to the analysis of the real-time behaviour)
• Testing (from specifying simple test patterns to the development of complex test strategies)
Ensuring formal correctness relies on proving that the algorithmic solution meets the specified requirements of the module specification However, this approach is limited in its applicability due to a lack of adequate tool support.
Static program analyses evaluate development documents or program texts without executing the programs These analyses aim to ensure compliance with programming rules, visualize program structure, identify weaknesses in control and data flow, and facilitate program testing.
Dynamic program analyses evaluate software by analyzing its behavior during execution These analyses aim to perform tasks such as verifying the validity of assertions and monitoring runtime performance.
Program testing focuses on choosing test cases that ensure a high level of confidence in the reliable operation of the software To achieve this, a systematic and goal-oriented test strategy is essential, aiming to cover all functional requirements and operational demands Test case selection criteria can be derived from the requirements list for functional testing or from the program's organization and structure for structural testing.
Documentation of qualification results
The qualification results are recorded in Lists of Open Points (LOPs) The LOPs can be structured in tables of
• minor issues (e.g typing errors, form errors);
• requests (e.g wrong descriptions of technically correct items, inconsistent or insufficient descriptions);
• key issues (e.g non-conformance with IEC standards or equipment characteristics)
The LOPs are defined in collaboration with the developer or supplier of the I&C platform, and any unresolved non-conformities will be recorded in the final qualification report This report encapsulates the qualification activities and outcomes, assesses the overall quality of the platform, and offers recommendations Upon successful qualification, certificates are issued to confirm the I&C platform's suitability for designated applications, including relevant safety classes.
The result of qualification is documented and certificates may be issued, in case of successful qualification result.
Maintenance of qualification
The validity of platform qualifications and their corresponding certificates is typically time-limited and requires revalidation upon expiration Minor modifications to hardware and software modules may allow for sustained platform qualification, such as changes in hardware layout or the expiration of a certificate However, these modifications must be assessed concerning the functionality and interfaces of the components Accumulating multiple minor changes to the same part may necessitate additional qualification.
Significant alterations, such as introducing a new hardware module or making minor adjustments to software functional requirements or qualified generic components, may necessitate additional qualification In contrast, fundamental changes to hardware or software design criteria, properties, or the introduction of a new CPU could require an entirely new platform qualification The process for maintaining platform qualification is depicted in Figure 3.
Figure 3 – Process for maintaining the platform qu alification
Various factors can raise concerns about a platform's qualification, such as changes in manufacturers or suppliers' capabilities and significant incidents related to the platform's characteristics Furthermore, the introduction of new standards and regulations may render an existing platform qualification invalid.
The plant operator, as the duty holder, is responsible for maintaining qualifications once a system based on the platform is operational; however, other parties can also play a role in supporting this maintenance activity.
The regulator may outline the responsibilities for maintaining platform qualifications between the supplier and the independent assessor The independent assessor is tasked with staying updated on any changes in standards and regulations that could affect the compliance of the qualified design Meanwhile, the supplier must notify the independent assessor of any modifications to the qualified design that could impact adherence to essential safety requirements or the validity of the certification.
All maintenance activities must be documented through a comprehensive maintenance plan and records The maintenance plan should adhere to the requirements of IEC 61513 It is essential to ensure that all changes and corrections to the I&C platform features critical for safety, regardless of their size, are managed formally through established hardware or software modification requests, following clearly defined procedures in the configuration management system.
In accordance with national regulatory requirements, it is advisable that if the parties consent to the owner assuming full responsibility for the I & C system support, the vendor should transfer the development and configuration management environment for the platform to the owner.
7 Dependency on the platform through life-cycle of the I&C system
General
The platform is defined as a combination of hardware and software that executes instrumentation and control (I&C) functions, as well as a product that creates an environment for the effective and safe implementation of I&C systems This implementation encompasses all phases of the system life cycle, which is illustrated by the traditional "V-cycle" in the IEC SC 45A standards.
When assessing the platform, it is crucial to focus on specific aspects that, while potentially outside the technical report's scope, are essential for ensuring a smooth and safe implementation of I&C systems.
• Cooperation of the parties involved in I &C system implementation (see 7.2)
• Features of the application implementation environment (see 7.3)
• System integration, validation and commissioning (see 7.4).
Models of cooperation between the parties of the I&C system project
The implementation of an I&C system requires collaboration among the utility (owner), the supplier (vendor), and the regulator It is essential to qualify the platform within the framework of agreements between these parties to ensure effective cooperation.
Traditional cooperation models rely on a clear division of responsibilities between the owner and the supplier, where the owner defines requirements for the vendor to meet However, this approach often leads to issues, as the owner may not fully understand the platform during the specification phase Consequently, contracts frequently require renegotiation to align the owner's needs with the platform's capabilities, resulting in conflicts due to incomplete information Both parties tend to focus on claims regarding unmet functionalities, leaving project management preoccupied with resolving these disputes.
An alternative approach involves a joint user-supplier organization for specific Instrumentation and Control (I&C) projects, based on an early agreement to utilize a pre-qualified platform, such as those meeting IEC SC 45A or IEEE standards However, varying national regulations and interpretations of standards can lead to significant challenges, indicating that selecting a pre-qualified platform does not entirely resolve qualification issues Therefore, the qualification of the platform must be integrated into the I&C system project framework, even when using a pre-qualified option The platform's capabilities should align individual business objectives with a common strategy to optimize I&C implementation outcomes A crucial aspect of this partnership is leveraging platform capabilities to facilitate the early identification and continuous sharing of risks and rewards, governed by predefined rules.
Still another option would be standardised application implementation environment available for the owners, prior to final purchase of the particular platform.
Platform environment for implementation of applications
Platform supported procedures for I &C system implementation
Development of I &C platforms results in provision of automatic tools and services enabling safe and efficient handling of various life-cycle stages of I &C system
Figure 4 may be used as a guide and an example of such a development The engineering procedures for the implementation of I &C systems are related there to a classical “V-cycle” introduced in IEC 60880
The left part side shows the “specification activities”, which are in the focus of whole I&C implementation Those activities result in:
• specification of I&C system including the conceptual design;
• detailed specification of I &C functions and architecture, addressing both system hardware and software;
• specification of test cases to verify the design targets
The detailed design of the Instrumentation and Control (I&C) system involves software engineering tasks, as illustrated in the lower box of Figure 4 This process facilitates the comprehensive design of I&C hardware equipment, leading to its subsequent manufacturing and installation in the factory.
Figure 4 – Life cycle procedu res/tasks of th e I&C system implementation
The platform is designed to fully support the validation activities of Instrumentation and Control (I&C) systems, now enhanced by the integration of software modules within the hardware These activities can be executed as illustrated in the upper right box of Figure 4.
• at the factory, in the test field environment during system integration, for the verification of pre-defined performance of the I&C system (e.g CPU-loads of processing units and bus loads);
• in the test field environment, after software integration into the complete target system addressing adequateness of the I&C system design (e.g redundancies, fault tolerance);
• on site, by validation of on-site functionality and performed by site acceptance tests on the target system installed in the plant
The validation activities require normally the target system and availability of the process controlled The platform would be expected to mitigate it by provision of the process simulation environment
Speci fi cati on acti viti es
Te st c as es sp ec ifi ca tio ns
Detailed I&C system design (architectu re and fu nctions)
Vali dation acti vi ti es
Site Acceptance Tests (SAT) commissioning
Tests in test environment (simulations)
Software modules selection, development and testing (establ ishm ent of m od ul e librari es)
Software implementation (au to code generation)
Detailed design of hardware equipment
To ensure platform qualification, maintenance activities are outlined in section 6.5 These tasks may impact all or some life cycle phases as illustrated in Figure 4 For instance, if there is a change in the software requirements specification, the entire software development process for any affected part of the I&C system must be re-evaluated.
Tool-based implementation – Kind of tools required
The platform supported procedures discussed above are implemented through various tools The following are examples of recommended tools:
• Tools for simulation of the process controlled enabling development and early validation of I&C control functions (preferably available already for the requirements specification)
NOTE The requirements specification can be presented in form of models of both the process and I&C functions
Handlers, including translators and compilers, play a crucial role in providing a formal environment for detailed specifications, structuring, and architecture of application-bound instrumentation and control (I&C) hardware and software systems Additionally, they serve as design tools for I&C functions and systems.
• Automatic source code generators and compilers, directly from the formal specifications
• Test tools for validation of the requirement specification of the target code
• Test tools for validation of the integrated I&C system
• Tools for handling test cases for verification of engineering activities relevant to safety
• Management tools for effective management of all project data, preferabl y configuration management prescribed by I EC standards Methods for software authentication in the target system.
Application software development
Application development environment of the platform may be further evaluated on the following issues:
• The environment is expected to build on the application functions' modularity
The platform operating system aims to provide standardized access to intelligent drivers, sensing devices, actuating devices, and communication channels or protocols It is essential to fully define and document the interface between the system software and the application software.
• The environment is expected to support documentation of application modules and module architecture (e.g comments, explanatory text in module code)
Parameter configurable software refers to existing software that can be tailored for specific applications through the use of simple parameter values and an application-oriented input language.
Library modules must implement robust defensive programming at the application level, focusing on validating input parameter values to ensure they are "within range," detecting anomalies, and generating safe outputs.
• System for detection and safe reaction on module/system failure modes is expected
• Features facilitating static analysis and testing of application software are expected to be available under the full range of specified operating conditions
Support for the development and use of module templates is anticipated, as template packaging will help limit the maximum size of modules and contain changes or failures to a single module or a small number of modules.
• Modules are expected to be defined in a way allowing unit tests, i.e in isolation from other module parts and from other modules
It is essential that the platform will provide means facilitating application development based on the concept of libraries, as presented here in Figure 5
Figure 5 – Application development based on the project library (V-for vendor, O-for owner)
Users can create a "project library" tailored for specific I&C systems, utilizing vendor-specific components and platform features to support new developments This owner's library will facilitate the continuous improvement and validation of projects through operational experience, providing a solid foundation for all ongoing I&C initiatives.
I&C system integration, validation and commissioning
The final implementation of the approved source code is carried out on the testing site by compiling and loading it onto the target system The I &C platform will be assessed for its efficiency and security in code loading, as well as for the availability of an integrated testing environment that includes simulation and fault monitoring capabilities.
In the I & C implementation process, it is crucial to focus on the platform's capability to manage test scripts that define test cases The selection and assessment of tests will be enhanced through simulation-based factory testing, allowing for the reuse of tests in the plant This dual application of test scripts will facilitate a comparison between application software testing on simulators and system validation during in-field testing and commissioning of the integrated target system.
Platform environment for test-scripts handling would facilitate preparation of validation and commissioning plans
(structure, classification, div in m odul es from availabl e libs) V&O
TARGET I and C SYSTEM Generated of m odu les and components of project l ibrary onl y
I&C platforms with means for that approach would allow deep understanding of controllers and processes and by reducing in-plant testing, enhance safety and reduce costs
This technical report outlines a framework for the efficient and transparent qualification of Instrumentation and Control (I&C) platforms for safety-critical nuclear applications The assessment focuses on the pre-qualification of I&C platforms independent of any specific plant design.
The lack of consensus on I&C platform qualification has hindered its standardization, with varying definitions and approaches across different countries This inconsistency is compounded by diverse perceptions regarding the roles of regulators and plants in the qualification process Additionally, the multitude of national and international guidelines and standards further complicates the situation.
The I&C platform qualification enhances efficiency by allowing parties to focus on application functions specific to their plants, while basic system functions can depend on the established platform qualification.
A suggestion emerged in the report's development to utilize the technical report as a foundational explanation for the new work item proposal regarding commercial grade item dedication, which was introduced at the 2014 Las Vegas meeting.
The working group WG A3 will monitor the possibility to launch – in the future – the development of a standard on the topic covered by this technical report
Annex A (informative) Issues of the Finnish licensing approach
Annex A examines the issues of the Finnish licensing approach As such, the “shalls” and
“shoulds” used in the text of Annex A do not represent requirements or recommendations of this document
Typical use of I&C platform qualification results is in the licensing process of I&C systems
Licensing an Instrumentation and Control (I&C) platform is essential when introducing a new safety-related I&C system or implementing significant changes to an existing one It's important to recognize that a single platform may serve multiple systems within a functional chain or operate across several parallel systems However, in such cases, it is crucial to adhere to the restrictions imposed by the plant's defense-in-depth and diversity requirements.
A platform to be licensed usually has previous qualifications for the same or more usually for some earlier version of the platform
In a system quality and qualification plan, the licensee outlines to the regulatory body how the safety-related instrumentation and control (I&C) system platform will be qualified and licensed.
The preliminary safety analysis report of a new or renovated safety related I &C system is usually accompanied with the documents of the I&C platform generic qualification if the platform is already chosen
In certain Finnish projects, it has been beneficial to separate the plant-specific qualification and licensing process into two distinct phases: the preliminary and final suitability analysis The licensing requirements outlined here adhere to this two-phase approach.
When selecting an I&C platform for a safety-related application, the licensing process begins with submitting preliminary qualification documentation to the regulatory body as part of the preliminary suitability analysis.
• requirement specification for equipment specific for the intended location of use;
In Safety Class 1 (IAEA safety class), an evaluation report is generated from the review of the requirement specifications for the Instrumentation and Control (I&C) equipment This "equipment" may refer to the entire platform or can be segmented into components, such as the main PLC modules and priority modules.
• verification of the suitability of the component;
• information and plans concerning type approvals and tests as well as the standards, organizations and accreditations used in them
Requirement specification (these are the requirements set by the intended place of service in the system where the item of the equipment is to be installed):
• A requirement specification shall be prepared when selecting or procuring I&C equipment in safety classes 1 and 2
The requirement specification for I&C equipment in safety classes 1 and 2 must detail the necessary properties for its intended use, including functional, performance, and reliability requirements, as well as considerations for environmental and operational conditions Additionally, it should outline requirements related to connections, periodic testing, maintenance, information security, qualification, and service life.
• The requirement specification of I &C equipment in safety classes 1 and 2 shall indicate the safety classification and seismic classification of the component
• The requirement specification of I &C equipment in safety classes 1 and 2 shall indicate the essential safety standards applied to the component and the deviations to their requirements
• The requirement specification of I &C equipment in safety classes 1 and 2 shall indicate the requirements regarding the component presented in the quality plan of the system and its components
• The requirement specification of I&C equipment in safety classes 1 and 2 shall indicate the requirements regarding the component set forth in the system or component qualification plan
• The requirement specification of I &C equipment in safety classes 1 and 2 shall be maintained throughout the design, manufacture and operation period of the system
The final requirement specification for I & C equipment classified as safety class 1 or 2 must be sufficiently detailed to enable traceable verification of compliance with the specified requirements for the final product.
• The requirements of I&C equipment in safety classes 1 and 2 shall be unambiguous and shall not contain conflicting information
• The requirements of I&C equipment in safety class 1 or 2 shall be traceable to their higher-level requirements (such as system level requirements, facility level concept requirements, etc.)
The assessment of requirement specifications for safety class 1 I&C equipment must be conducted by an independent expert who was not involved in the design process This evaluation is essential to ensure that the product's requirements align with the overarching higher-level requirements.
In safety class 1, a report must be generated to evaluate the requirement specification of I&C equipment, detailing the observations made during the assessment and providing a justified conclusion on the accuracy, scope, and consistency of the requirement specification.
• The assessment report on the requirement specification of I&C equipment in safety class 1 shall be updated when the requirement specification is modified
General
Annex C provides a review of Westinghouse ALS platform qualification As such, the
“shoulds” used in the text of Annex C do not represent recommendations of this document.
Introduction and ALS-background
The ALS platform is a logic-based system that operates without a microprocessor or software, utilizing a straightforward hardware architecture It employs field programmable gate array (FPGA) technology for its logic implementation Developed by Westinghouse Electric Company, the ALS platform is classified as nuclear safety-related (Class 1 E) and complies with 10 CFR Part 50, Appendix B standards.
In late 2003, Wolf Creek Nuclear Generating Station identified the need to replace its safety-related instrumentation and control (I&C) systems due to reliability and obsolescence issues With no viable market solutions available, Wolf Creek initiated a new approach in early 2004 by partnering with CS Innovations This collaboration led to the proposal of the ALS architecture, designed as a general safety platform aimed at the U.S Nuclear Power Plant (NPP) safety-related I&C system market.
The ALS platform serves as a universal safety system, offering advanced diagnostics and testability features Its reliable architecture, combined with sophisticated design processes, enhances system dependability To address potential obsolescence, the ALS incorporates a simplified board-level design, preserving proven logic in an abstracted format for future hardware updates This approach prevents the need to start from scratch with each system upgrade.
The ALS is a versatile modular platform that enables the combination of generic modules, known as ALS boards, to address diverse nuclear safety applications This platform offers scalability, allowing for upgrades ranging from a single system enhancement to comprehensive safety system upgrades, all utilizing the same ALS framework.
The ALS platform incorporates two possible levels of diversity: Core Diversity and Embedded Design Diversity
Core Diversity is applied to all FPGAs on ALS boards, achieved by altering the logic implementation during the synthesis and Place & Route processes Additionally, Embedded Design Diversity introduces further design variation, resulting in two distinct FPGA images.
A and B, which implement the same functionality in a diverse manner
3 This information is given for the convenience of users of this document and does not constitute an endorsement by I EC of the companies named
The ALS platform was initially created by CS Innovations, a supplier compliant with 10 CFR Part 50, Appendix B This company later became a wholly owned subsidiary of Westinghouse Electric Company, which has since fully acquired, developed, and maintains the product, as the subsidiary is no longer in existence.
The level of diversity employed for a particular application is determined by the complexity of the application.
Westinghouse’s life cycle management process
The development of the ALS platform adhered to a traditional waterfall life cycle, encompassing top-down requirement and specification development, design implementation, and a thorough bottom-up verification and validation (V&V) process at each integration level Integral to these stages were prototyping activities and in-process quality assurance efforts.
The licensing documentation required by the NRC was created in accordance with ISG-06, Interim Staff Guidance 6 – Task Working Group #6: Digital I&C Licensing Process, Revision 1, as outlined in document ML110140103 from the U.S Nuclear Regulatory Commission.
The Verification and Validation (V&V) activities were conducted in a systematic, bottoms-up approach, starting from the FPGA digital logic programming level, advancing to the board level, and culminating at the system level The Independent Verification and Validation (iV&V) team carried out these processes, ensuring adherence to formal iV&V protocols Notably, Westinghouse’s iV&V team operates independently in terms of management, scheduling, and financial aspects.
Standards, guidelines and regulatory compliance
Equipment qualification
The ALS test program for equipment qualification includes the following:
Environmental qualification
The ALS platform hardware has been certified for Class 1 E applications in mild environments To meet the standards set by GDC 4, 10 CFR 50.49, and IEEE 603-1991, the qualification program adhered to IEEE Standard 323-1974 and IEEE Standard 323-2003.
Seismic qualification
The ALS platform hardware was qualified for Class 1 E safety functions and operations per IEEE Standard 344-1 987
Clause 4 of IEEE Standard 344-1 987 and Clause 5 of IEEE Standard 344-2004 state that the seismic qualification of Class 1 E equipment should demonstrate an equipment’s ability to perform its safety function during and after the time it is subjected to the forces resulting from one safe shutdown earthquake (SSE) I n addition, the equipment must withstand the effects of a number of operating basis earthquakes (OBEs) prior to the application of an SSE
The ALS platform hardware was tested for functionality during seismic events by conducting a series of seismic simulation tests on a tri-axial seismic shake table This comprehensive testing included resonance search tests, five Operational Basis Earthquake (OBE) tests, and a Seismic Safety Evaluation (SSE) test.
EMC qualification
The ALS platform hardware has been qualified for electromagnetic compatibility in accordance with Regulatory Guide 1.180 Rev 1 It utilizes specific test methods from MIL-STD-461E and the IEC 61000 series, as endorsed by Regulatory Guide 1.180 These tests effectively assess the impact of conducted and radiated electromagnetic interference (EMI), radiofrequency interference (RFI), and power surges on safety-related instrumentation and control (I&C) systems.
Fault/isolation qualification
The ALS platform hardware was qualified for safety/non-safety (Class 1 E/Non-1 E) and inter- divisional interfaces per Regulatory Guide 1 75 Rev 3 and I EEE 384-1 992 for independence of Class 1 E circuits.
Software qualification
The ALS platform software has been verified and validated in accordance with Regulatory Guide 1 1 68 Revision 1 and IEEE 1 01 2-1 998
Software verification and validation (V&V) is a crucial aspect of systems engineering aimed at ensuring quality throughout the software life cycle The primary goal of V&V is to assist development organizations in embedding quality into their software Through V&V processes, it is determined whether the products of a specific development activity meet the established requirements and if the software fulfills its intended purpose and user needs.
Regulatory compliance
To fulfil the regulatory requirements the ALS-platform was designed to fulfil the following standards and guidelines:
• IEEE 603 – IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations
• IEEE 7-4.3.2 – Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations
• DI &C-I SG-04 – Highly-I ntegrated Control Rooms – Communications Issues
• BTP 7-1 4 – Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems
• BTP 7-1 9 – Guidance for Evaluation of Diversity and Defense-In-Depth in Digital Computer-Based Instrumentation and Control Systems
• Regulatory Guide 1 1 52 – Criteria for Use of Computers in Safety Systems of Nuclear Power Plants
• DI &C ISG-06 – Digital I&C Licensing Process
Review by NRC
The ALS-platform has been reviewed and approved by the NRC – U.S Nuclear Regulatory Commission.
Review of equipment qualification
The NRC has reviewed the “ALS Topical Report,” “ALS EQ Plan,” and “ALS Platform EQ Summary Report,” concluding that the manufacturer’s equipment qualification aligns with Regulatory Position 1’s preference for type testing, as outlined in RG 1.209 This is due to the ALS platform manufacturer conducting type testing on seven standardized circuit boards, a backplane, and a chassis with FPGA programs representative of production Additionally, the NRC assessed whether the manufacturer documented its equipment qualification adequately to assist applicants and licensees in verifying that the ALS platform meets its environmental qualification program and ensures the safety functions of plant-specific equipment remain operational during and after design basis events.
C.4.1 0 Review of regu latory compliance
The evaluation of the platform topical report focused on its compliance with the application-specific system provisions outlined in IEEE Standard 603-1991, which sets criteria for safety systems in nuclear power generating stations The NRC staff's assessment was guided by SRP Chapter 7, Appendix 7.1-C, which details the acceptance criteria for conformance to IEEE Std 603.
The NRC has confirmed that the ALS platform aligns with various sections of IEEE Std 603-1 991 Applicants or licensees referencing the ALS Safety Evaluation Report must detail their approach to comply with each relevant clause of this standard It is crucial for them to consider their plant-specific design basis, as the scope of the ALS Topical Report is limited The Safety Evaluation Report does not provide a specific application, define a safety system, or analyze the impact of credible events and their consequences Therefore, applicants or licensees must clarify their plant-specific design basis for the safety system and how each clause of IEEE Std 603-1 991 applies to their ALS-based safety system or component Additionally, they should demonstrate that the use of the ALS platform meets the applicable clauses of IEEE Std 603-1 991 in line with their specific design basis and safety system application.
Equipment utilizing ALS platform components is designed for safety systems and related applications The platform's topical report was assessed for its compliance with the IEEE Standard 7-4.3.2-2003, which outlines criteria for digital computers in safety systems of nuclear power plants According to RG 1.152, adherence to IEEE Std 7-4.3.2-2003 is an acceptable method for the NRC to ensure high functional reliability and design standards for safety system computers The NRC's evaluation follows the guidance in SRP Chapter 7, Appendix 7.1-D, which details the acceptance criteria for this standard.
The NRC has confirmed that the ALS platform aligns with various sections of IEEE Std 7-4.3.2-2003 Applicants or licensees must detail their approach to comply with each relevant clause in The Safety Evaluation Report It is essential for them to consider their specific plant design basis, as the scope of the “ALS Topical Report” is limited The Safety Evaluation Report does not provide a specific application, define a safety system, or analyze the impact of credible events and their consequences Therefore, applicants or licensees should clearly outline their plant-specific design basis for the safety system and how each clause of IEEE Std 7-4.3.2-2003 applies to their ALS-based safety system or component.
The compliance with DI&C-I SG-04, BTP 7-1 4, BTP 7-1 9, Regulatory Guide 1.152, DI&C ISG-06, and other relevant standards has been thoroughly reviewed by the US NRC staff Additional information is available in the "U.S Nuclear Regulatory Commission Safety" documentation.
Evaluation for Topical Report 6002-00301 “Advanced Logic System Topical Report” “: http://pbadupws.nrc.gov/docs/ML1 321 /ML1 321 8A979.pdf.