RAPPORT TECHNIQUE CEI IEC TECHNICAL REPORT 61940 Première édition First edition 1998 06 Instrumentation nucléaire – Revue de l’application de la CEI 60880 (1986) Nuclear instrumentation – A review of[.]
But de l'évaluation
An evaluation against the Standard may be necessary in various situations For instance, during a system development process, design engineers can assess the available methods and techniques in relation to the Standard to select the most suitable options.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
A REVIEW OF THE APPLICATION OF IEC 60880 (1986)
This report aims to synthesize the practical experiences of IEC 60880 users, offering valuable insights for system developers and assessors Contributions from various countries have shaped this document, ensuring it accurately represents the global perspective on IEC 60880.
This report is not intended to represent an interpretation of IEC 60880 as applied on any specific project It is written in a general manner and the suggested interpretations of
IEC 60880 clauses should not be taken as definitive This report does not replace, alter or add to the requirements contained in IEC 60880.
IEC 60880:1986, Software for computers in the safety systems of nuclear power stations
IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic safety- related systems 1)
ISO 9001:1994, Quality systems – Model for quality assurance in design, development, production, installation and servicing
IAEA 50-SG-D3:1980, Safety guide – Protection system and related features in nuclear power plants
The definitions used in this technical report are given in clause 2 “Terms and definitions” of
4 Assessment of compliance with IEC 60880
Assessments against the Standard are often necessary in various scenarios, such as when design engineers evaluate available methodologies and technologies during the system development process to determine the most suitable options for implementation.
The standard can be utilized to assess the adequacy of operational systems during the reevaluation of the safety case for an existing facility Additionally, independent evaluators may need to verify that the development process adheres to the standard.
The primary goal of evaluating a system or its components is to ascertain their suitability for use Demonstrating that a system is fundamentally compliant with IEC 60880 provides confidence in its appropriateness for nuclear safety applications.
Processus d'évaluation
Whether a system is deemed compliant depends not only on its characteristics and development cycle but also on the evaluator's ability to interpret the requirements and recommendations outlined by the standard.
The standard offers recommendations to aid in interpreting its content, particularly in the introduction, which states that the standard should provide a general approach to software development, verification, and validation.
The standard outlines principles and guidelines related to system software and offers specific recommendations for security systems The use of such terminology indicates that the content of the standard is not intended to be applied dogmatically and should be interpreted according to the requirements of specific applications.
Article 1 outlines the scope and purpose, noting that the appendices provide guidelines and additional information on how to comply with the main requirements of the standard Emphasis is placed on the content of Articles 3 to 10 rather than on Appendices A to F The standard mandates that if techniques other than those identified in the appendices are used, they must be documented and auditable.
The main articles of the Standard are qualified in various ways, such as "must," "should," "it is necessary," "it is appropriate," "it would be preferable," and "it is recommended." The significance of any deviation from the Standard depends on the level of constraint indicated in the text.
At the conclusion of a formal evaluation process, it is essential to produce a report that identifies specific items deemed either compliant or non-compliant by the evaluator This report should include documented justifications for compliance, such as explanations, references to manuals, and reports for each item claimed to be compliant In cases where the requirements or recommendations of an item have not been followed, suggested response classifications include: a) not applicable, indicating that a coding recommendation does not pertain to the language used or that a requirement exceeds the scope of the evaluation; for instance, a requirement relevant to clients or users during a system supplier evaluation, or a system requirement when the evaluation is limited to the software production process; b) not yet applicable, such as when an evaluation occurs prior to the delivery of a system, where all recommendations regarding system operation are considered.
The CEI 60880 standards fall into specific categories, including those that are undesirable, meaning recommendations that do not enhance safety or integrity for a particular application or development process Additionally, there are non-mandatory recommendations, such as those qualified with an optional aspect.
The Standard can be utilized to evaluate the adequacy of operational systems during the re-assessment of the safety case for an existing station Additionally, independent assessors may be necessary to verify that the development process adheres to the Standard.
Assessing a system or its components aims to verify their fitness for use Demonstrating compliance with IEC 60880 significantly enhances confidence in the system's suitability for nuclear safety applications.
The compliance of a system is determined by its characteristics, the development life cycle it follows, and the assessor's ability to interpret the requirements and guidance outlined by the Standard.
The Standard offers guidance for interpreting its contents, emphasizing a "general approach" to software development, verification, and validation It discusses essential software principles and provides specific recommendations for safety systems This terminology suggests that the Standard should not be applied rigidly; instead, it should serve as a flexible guide tailored to specific applications.
Clause 1 outlines the scope and purpose, indicating that the appendices provide supplementary guidance on meeting the main requirements of the Standard The focus is primarily on clauses 3 to 10, rather than on appendices A and beyond.
F The Standard requires that if techniques other than those identified in the appendices are used they are to be documented and auditable.
Clauses in the main body of the Standard are qualified in a number of ways, for example “may”,
“shall”, “required”, “should be”, “should be preferred”, “is recommended” The significance of any deviations from the Standard depends upon the degree of compulsion implied by the text.
The end result of a formal assessment process should be a report identifying the particular clauses which are, in the opinion of the assessor, addressed or not addressed by a system.
Compliance justifications must be documented through explanations and references to manuals or reports for each claimed clause If a clause's requirements or recommendations are not followed, responses can be classified as: a) not applicable, indicating a coding recommendation irrelevant to the language used or outside the assessment's scope; b) not yet applicable, such as when an assessment occurs before system delivery, making operational recommendations irrelevant; c) not desirable, referring to recommendations that do not enhance safety or integrity for specific applications; and d) not compulsory, for recommendations that are optional, indicated by the term "may."
Licensed to MECON Limited for internal use in Ranchi/Bangalore, this document outlines two types of non-conformities: minor non-conformity, which refers to a clear deviation from the standard that has little to no impact on the quality or safety of a system, and major non-conformity, which indicates a significant breach of the standard that could have serious implications for quality and safety.
Quand des non-conformités sont identifiées, il convient de fournir une justification incluant une description des facteurs atténuants.
For enhanced clarity, it is recommended to include a summary/conclusions chapter in the evaluation report that considers overall compliance and identifies aspects of the system that exceed the requirements of IEC 60880 It is essential to assess the system's suitability for its intended use and its general compliance with the standard Given the broad scope of the standard and the need for interpretation in specific applications, determining compliance is rarely binary, and a qualified judgment may be necessary.
Il faut prendre en compte un certain nombre de sujets clés lors de l'évaluation de la conformité d'un système.
Cycle de vie
The standard outlines a chronological progression from user requirements to the final integrated and tested system Each phase must conclude with a critical review, as detailed in IEC 60880, paragraph 3.1.6, in Article 6 of this report.
In large systems with a distributed architecture, significant parallel work occurs, making the design process inherently iterative Users often identify new requirements during development that must be integrated into the design It is essential to ensure that no major non-conformities arise regarding the timing of various design activities, provided that the fundamental principles of the standard are considered Ultimately, the final system must reflect user requirements, and the verification and validation processes should be detailed, comprehensive, controlled, and auditable.
Many requirements of the standard implicitly assume a traditional top-down development cycle for new projects Most new systems incorporate components from legacy systems, necessitating a certain degree of bottom-up design to effectively integrate these components.
A typical design process for a modern protection system involves several key steps: first, users create a set of functional requirements; next, the supplier develops a system design specification that outlines how standard components from a generic system will be utilized to meet the requested functionality It is important to note that the generic system may have its own design documentation, and its development should generally adhere to the guidelines set forth by IEC 60880.
The functionalities requiring system software development are identified, and the entire new system software is developed in accordance with the same standards, or better, than the existing generic software This includes independent verification of software modules, ensuring high-quality outcomes.
This document is licensed to MECON Limited for internal use in Ranchi and Bangalore, as supplied by the Book Supply Bureau It outlines two types of non-compliance: minor non-compliance, which refers to a clear breach of the Standard that has little to no impact on the quality or safety of a system, often due to the use of an alternative technique; and major non-compliance, which indicates a significant breach of the Standard that could have serious implications for quality and safety.
Where non-compliance is identified a justification should be provided, to include a description of any mitigating factors.
To enhance clarity, it is recommended that the assessment report includes a summary or conclusions section that evaluates the overall compliance level, highlighting any elements of the system that exceed the requirements set by IEC 60880.
A judgment must be made regarding the suitability of a system for its intended application and its overall compliance with the Standard Given the extensive nature of the Standard and the necessity for interpretation in specific contexts, assessing compliance is often not straightforward, necessitating a qualified judgment.
There are a number of key issues to be considered when assessing the compliance of a system.
The Standard outlines a sequential progression from user requirements to the final integrated and tested system, with each phase requiring a critical review However, in practice, especially for large systems with distributed processing, the design process is often iterative and involves significant parallel work Users may introduce new requirements during development that must be incorporated into the design As long as the core principles of the Standard are upheld—ensuring the final system reflects user requirements and that verification and validation processes are thorough, controlled, and auditable—timing discrepancies in design activities should not be deemed major non-compliance.
The Standard's requirements often presuppose a traditional top-down development life cycle for custom systems However, most new systems integrate elements from existing systems, necessitating a certain level of bottom-up design to effectively incorporate these components.
A typical design process for a modern protection system involves users creating functional requirements, followed by the supplier developing a system design specification This specification outlines how standard components from a generic system "kit" will be utilized to meet the required functionality The generic system should be accompanied by its own design documentation and must be developed in accordance with the methodology recommended by IEC 60880.
The identification of functionality necessitating system software development ensures that all new software is created to meet or exceed the standards of existing generic software, as previously mentioned.
The functional requirements of the system are depicted through diagrams and converted into application software using a validated software tool, meaning this aspect of the system requirements is not included in traditional text-based design documentation, which encompasses system requirements, system specifications, and software specifications Additionally, testing is conducted at the levels of software modules, hardware components, cabinets, and the overall system.
System-level testing is conducted on a generic system prototype, performed initially on the factory-assembled system and again once the system is installed on-site, typically occurring twice—first when it is not connected and then when it is connected to the central unit.
This design process does not directly align with the IEC 60880 development cycle, and it is essential to interpret certain articles of the standard carefully to apply them to the relevant parts of the development process.
S’il y a des déviations majeures par rapport au cycle de développement de référence de la
Types de logiciels
Les composants logiciels d'un systốme sont souvent dộfinis soit en tant que logiciel ôsystốmeằ
(communications, gestion mộmoire, fonctions standard) soit en tant que logiciel d'ôapplicationằ
The application software leverages resources from the system software, minimizing code duplication across modules This approach not only reduces the overall software volume but also decreases the likelihood of errors Key components include locking logic, control loops, image displays, and alarm logic.
There can be two distinct sets of design documents: one for system software and another for application software Application software is typically project-specific, while system software can be utilized across multiple projects.
Data accuracy is often seen as more easily verifiable than code accuracy, leading many system designs to heavily rely on configuration data to enhance integrity and flexibility This conceptual approach aligns with the principles outlined in IEC 60880 (refer to Annex B, B1.a.a and B2.a.ab) Configuration data can be linked to either system software or application software and typically includes both non-modifiable and modifiable data, with the latter being adjustable online Modifiable data usually encompasses alarm limits, set points, and calibration data for instruments, among others.
In summary, software corresponding to a system can include the following types: a) existing system software; b) system software to be developed; c) application software to be developed; d) non-modifiable configuration data to be developed; and e) modifiable configuration data to be developed.
The standard often fails to clearly differentiate between various types of software and data, leading to certain requirements that are not applicable to all software categories Specifically, when modifying configurable data, many of the requirements outlined in Article 9 of the standard do not apply, as noted in the comments at the end of paragraph 5.3 below.
An evaluator should be experienced and well-versed in the requirements of IEC 60880, with the ability to interpret the standard while considering the characteristics of various types of software and data within a system.
Modifications de logiciel
The introduction of IEC 60880 specifies that the standard includes recommendations concerning software maintenance procedures, modifications, and configuration management, which are addressed in Article 9 The scope of this article is broader than its title suggests, as it provides guidance on system change management procedures.
The Standard requires that every modification request be reviewed and an impact analysis conducted Section 9.2.3 of the Standard refers to the articles concerning software verification and programmed system validation, which must be applied either fully or partially based on the results of the impact analysis.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
The software components of a system are often defined as being either “system” software
(communications, memory management, standard functions) or “application” software
Application software leverages the capabilities of system software, minimizing code duplication across modules This approach not only streamlines the overall software but also decreases the likelihood of errors, enhancing the reliability of interlock logic, control loops, display formats, and alarm logic.
Design documentation can be categorized into two distinct sets: one for generic system software and another for application software While application software is typically tailored to a specific project, system software has broader applicability and can be utilized across multiple projects.
Verifying the correctness of data is generally easier than that of code, leading many system designs to rely heavily on configuration data to enhance integrity and flexibility This approach aligns with the principles of IEC 60880 Configuration data can be linked to either system or application software and typically includes both unamendable and amendable data The amendable data often encompasses alarm limits, setpoints, and calibration information for instrumentation.
In summary, software for a system can be categorized into several types: existing system software, system software that is yet to be developed, application software that needs development, non-amendable configuration data to be created, and amendable configuration data that will also be developed.
The Standard frequently lacks clarity in differentiating between various software and data types, leading to some requirements being irrelevant for certain software categories Notably, when it comes to modifying amendable configuration data, many of the requirements outlined in clause 9 of the Standard do not apply, as discussed in subclause 5.3.
An assessor must possess extensive experience and knowledge of IEC 60880 requirements, enabling them to effectively interpret the Standard while considering the unique characteristics of various software and data types within a system.
In the introduction to IEC 60880 it is stated that the Standard contains recommendations for
Clause 9 of the Standard outlines comprehensive procedures for software maintenance, modification, and configuration control, offering extensive guidelines for effective system change control.
The Standard mandates a thorough examination of each modification request, accompanied by an impact analysis According to Subclause 9.2.3, relevant sections on software verification and computer system validation must be applied in whole or in part, based on the findings of the impact analysis.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
Although the articles of the Standard regarding change management do not explicitly acknowledge the need for incremental management procedures, similar to how a system follows the phases of the development cycle, it is important to view the phased introduction of controls as consistent with the general principles of the Standard.
When considering the introduction of change controls, it is essential to reference paragraph 9.1.2 of CEI 60880 This section advises that a modification request should be approved immediately if it is deemed minor, meaning it does not significantly impact the design, and is submitted during the initial development phase.
A typical development process that incorporates formal software management procedures on a module-by-module basis, following module verification, and implementing comprehensive system change controls (as recommended by IEC 60880) after the commencement of final site commissioning tests, aligns with the configuration management requirements outlined in paragraph 7.3 of IEC 60880.
During the development process, users should assess the safety implications of changes to functional requirements, while it is unnecessary for them to review modifications to the means or methods used to fulfill these requirements, as these are transparent to users The scope of the review should be tailored to the type of changes being made It is not advisable for those responsible for the system's functional requirements, such as central engineers, to evaluate detailed technical modifications that do not impact these requirements The level of review and the individuals conducting the reviews should be aligned with the types of changes being implemented.
When evaluating the suitability of a change management process, it is essential to consider the specific characteristics of the software being modified For instance, if a system design allows for the modification of fundamental data, this should be taken into account.
Fiabilité
La Norme fait largement référence à la spécification des exigences de fiabilité du logiciel et à la vérification de ces exigences, par exemple au niveau de la CEI 60880, paragraphes 4.8,
5.1.2, et particuliốrement 6.2.1 qui comporte les termes ôộvaluer chaque ộlộment du logiciel et pour contrụler à chaque phase le respect des exigences fonctionnelles et de fiabilitộằ.
These articles require careful interpretation: while the reliability of hardware components can be assessed through measured failure rates, there is no definitive method to evaluate the reliability of software design or hardware itself.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
The Standard emphasizes the importance of incrementally introducing change control procedures throughout the development life cycle, aligning with the principles of IEC 60880 Specifically, subclause 9.1.2 highlights that change requests deemed "minor," meaning they do not impact the design's foundation, should receive immediate approval, particularly during the initial development phase.
A compliant development process involves implementing formal software control procedures on a module-by-module basis after module verification Full system change controls, as recommended by IEC 60880, should be established once final site commissioning tests begin, ensuring adherence to the configuration control requirements outlined in subclause 7.3 of IEC 60880.
Changes to functional requirements during development should be evaluated for safety implications by users, while transparent changes in methods to meet these requirements do not require user review The review scope should align with the nature of the changes It is advised that detailed technical changes internal to software systems, which do not impact functional requirements, should not be assessed by plant engineers responsible for those requirements The review level and the reviewers must correspond to the types of changes being implemented.
When evaluating the effectiveness of a change control process, it is essential to consider the specific characteristics of the software involved For systems that permit modifications to amendable configuration data, extensive reviews or software impact analyses may not be necessary if the following conditions are met: the system requirements clearly define the allowable range of amendment items, the software's capability to reject values outside this range is confirmed during the design phase, and the software's performance is validated over a representative set of amendment values.
The contents of IEC 60880, subclause 9.1.2, and the principle of a graded application of change control implied by it, must guide the interpretation of relevant clauses in the Standard.
The Standard makes extensive reference to the specification of software reliability requirements and to the verification of these requirements, e.g IEC 60880, subclauses 4.8,
5.1.2, and particularly 6.2.1, which contains the phrase “evaluate each item of software and each phase to show whether the functional and reliability requirements specification is met”.
Such clauses require careful interpretation for although the reliability of hardware components may be determined by the measured failure rate, there is no proven way of measuring the
“reliability” of software, nor indeed hardware, design.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
Many modern safety arguments rely on probabilistic analysis, assigning nominal reliability to all safety systems, including programmed systems Instead of using the term "reliability," which is more applicable to hardware systems that experience physical degradation over time, the term "integrity level" is generally used for software This approach is exemplified by IEC 61508.
A critical issue for developers and regulatory authorities is to establish the extent of demonstration required to ensure that the software implementation process maintains the integrity of the system's software, aligning it with the declared reliability of the system.
Il n'existe aucun consensus concernant l’étendue de la démonstration appropriée En effet, il peut ờtre prộfộrable d'exclure la ôfiabilitộằ du logiciel du domaine d'application de l'ộvaluation.
When assessing reliability, it is essential to rely on the evaluator's experience and expertise to determine the credibility of the statements made Key factors to consider include operational experience, the scope of verification and validation activities, the quality of the software development lifecycle, and the overall compliance of the software development process.
CEI 60880; e) la possibilité de défaillance de mode commun du logiciel (un futur développement de la
CEI 60880 doit fournir un guide sur ce sujet).
Several design features of the plant and system can potentially lower the required integrity level for system software, such as system redundancy, online diagnostics, and component redundancy.
Purpose of assessment
Assessments against the Standard are often necessary in various scenarios, such as when design engineers evaluate available methodologies and technologies during the system development process to determine the most suitable options.
The standard can be utilized to assess the adequacy of operational systems during the reevaluation of the safety case for an existing facility Additionally, independent evaluators may need to verify that the development process adheres to the standard.
The primary goal of evaluating a system or its components is to ascertain their suitability for use Demonstrating that a system is fundamentally compliant with IEC 60880 provides confidence in its appropriateness for nuclear safety applications.
Whether a system is deemed compliant depends not only on its characteristics and development cycle but also on the evaluator's ability to interpret the requirements and recommendations outlined by the standard.
The standard offers recommendations to aid in interpreting its content, particularly in the introduction, which states that the standard should provide a general approach to software development, verification, and validation.
The standard outlines principles and guidelines related to system software and offers specific recommendations for security systems The use of such terminology indicates that the content of the standard is not intended to be applied rigidly; rather, it should be interpreted according to the requirements of specific applications.
Article 1 outlines the scope and purpose, noting that the appendices provide guidelines and additional information on how to meet the requirements of the main part of the standard Emphasis is placed on the content of Articles 3 to 10 rather than on Appendices A to F The standard mandates that if techniques other than those identified in the appendices are used, they must be documented and auditable.
The main articles of the Standard are described in various ways, such as "must," "should," "it is necessary," "it is appropriate," "it would be preferable," and "it is recommended." The significance of any deviation from the Standard depends on the level of constraint indicated in the text.
At the conclusion of a formal evaluation process, it is essential to produce a report that identifies specific items deemed either compliant or non-compliant by the evaluator This report should include documented justifications for compliance, such as explanations, references to manuals, and reports for each item claimed to be compliant In cases where the requirements or recommendations of an item have not been followed, suggested response classifications include: a) not applicable, indicating that a coding recommendation does not pertain to the language used or that a requirement exceeds the scope of the evaluation; for instance, a requirement relevant to clients or users during a system supplier evaluation, or a system requirement when the evaluation is limited to the software production process; b) not yet applicable, such as when an evaluation occurs prior to the delivery of a system, where all recommendations regarding system operation are considered.
The CEI 60880 standards fall into specific categories, including those that are undesirable, meaning that certain recommendations may not enhance safety or integrity for particular applications or development processes Additionally, there are non-mandatory recommendations, which may be qualified with optional elements.
The Standard can be utilized to evaluate the adequacy of operational systems during the re-assessment of the safety case for an existing station Additionally, independent assessors may be necessary to verify that the development process adheres to the Standard.
Assessing a system or its components is crucial to ensure they are fit for use Demonstrating compliance with IEC 60880 significantly boosts confidence in the system's suitability for nuclear safety applications.
Assessment process
The compliance of a system is determined by its characteristics, development life cycle, and the assessor's ability to interpret the requirements and guidance outlined by the Standard.
The Standard offers guidance for interpreting its contents, emphasizing a "general approach" to software development, verification, and validation It discusses essential software principles and provides specific recommendations for safety systems This terminology suggests that the Standard should not be applied rigidly; instead, it should serve as a flexible guide tailored to the needs of specific applications.
Clause 1 outlines the scope and purpose, indicating that the appendices offer supplementary guidance on meeting the main requirements of the Standard The focus is primarily on clauses 3 to 10, rather than on appendices A to Z.
F The Standard requires that if techniques other than those identified in the appendices are used they are to be documented and auditable.
Clauses in the main body of the Standard are qualified in a number of ways, for example “may”,
“shall”, “required”, “should be”, “should be preferred”, “is recommended” The significance of any deviations from the Standard depends upon the degree of compulsion implied by the text.
The end result of a formal assessment process should be a report identifying the particular clauses which are, in the opinion of the assessor, addressed or not addressed by a system.
Compliance justifications must be documented through explanations and references to manuals and reports for each claimed clause If a clause's requirements or recommendations are not followed, responses can be classified as: a) not applicable, indicating a coding recommendation irrelevant to the language used or outside the assessment's scope; b) not yet applicable, such as when an assessment occurs before system delivery, making operational recommendations irrelevant; c) not desirable, referring to recommendations that do not enhance safety or integrity for specific applications; and d) not compulsory, which includes recommendations that are optional, indicated by the term "may."
Licensed to MECON Limited for internal use in Ranchi and Bangalore, this document outlines two types of non-conformities A minor non-conformity refers to a clear deviation from the standard that has little to no impact on the quality or safety of a system, such as using an alternative technique that is equivalent or superior to the recommended standard In contrast, a major non-conformity indicates a significant deviation from the standard that could have serious implications for quality and safety.
Quand des non-conformités sont identifiées, il convient de fournir une justification incluant une description des facteurs atténuants.
For enhanced clarity, it is recommended to include a summary/conclusions chapter in the evaluation report that considers overall compliance and identifies aspects of the system that exceed the requirements of IEC 60880 It is essential to assess the system's suitability for its intended use and its general compliance with the standard Given the broad scope of the standard and the need for interpretation in specific applications, determining compliance is rarely binary, and a qualified judgment may be necessary.
Il faut prendre en compte un certain nombre de sujets clés lors de l'évaluation de la conformité d'un système.
The standard outlines a chronological progression from user requirements to the final integrated and tested system Each phase must conclude with a critical review, as detailed in IEC 60880, paragraph 3.1.6 to article 6 of this report.
In large systems with a distributed architecture, significant parallel work occurs, making the design process inherently iterative Users often identify new requirements during development that must be integrated into the design It is essential to ensure that no major non-conformities arise regarding the timing of various design activities, provided that the fundamental principles of the standard are considered Ultimately, the final system should reflect user requirements, and the verification and validation processes must be detailed, comprehensive, controlled, and auditable.
Many requirements of the standard implicitly assume a traditional top-down development cycle for new projects Most new systems incorporate components from legacy systems, necessitating a certain degree of bottom-up design to effectively integrate these elements.
A typical design process for a modern protection system involves several key steps First, users create a set of functional requirements Next, the supplier develops a system design specification that outlines how standard components from a generic system will be utilized to meet the requested functionality It is important to note that the generic system may have its own design documentation, and its development should generally adhere to the guidelines set forth by IEC 60880.
The functionalities requiring system software development are identified, and the entire new system software is developed in accordance with the same standards, or better, than the existing generic software This includes independent verification of software modules, ensuring high-quality development practices are maintained.
This document is licensed to MECON Limited for internal use in Ranchi and Bangalore, as supplied by the Book Supply Bureau It outlines two types of non-compliance: minor non-compliance, which refers to a clear breach of the Standard that has little to no impact on the quality or safety of a system, often due to the use of an alternative technique; and major non-compliance, which indicates a significant breach of the Standard that could have serious implications for quality and safety.
Where non-compliance is identified a justification should be provided, to include a description of any mitigating factors.
To enhance clarity, the assessment report should include a summary or conclusions section that evaluates overall compliance and highlights any system aspects that exceed the requirements of IEC 60880.
A judgment must be made regarding the suitability of a system for its intended application and its overall compliance with the Standard Given the extensive scope of the Standard and the necessity for interpretation in specific contexts, assessing compliance is often not straightforward, necessitating a qualified judgment.
There are a number of key issues to be considered when assessing the compliance of a system.
Life cycle
The Standard outlines a sequential progression from user requirements to the final integrated and tested system, with each phase requiring a critical review However, in practice, especially for large systems with distributed processing, the design process is often iterative and involves significant parallel work Users may introduce new requirements during development that must be incorporated into the design As long as the core principles of the Standard are upheld—ensuring the final system reflects user requirements and that verification and validation processes are thorough, controlled, and auditable—timing discrepancies in design activities should not be deemed major non-compliance.
The Standard's requirements often presuppose a traditional top-down development life cycle for custom systems However, most new systems integrate elements from existing systems, necessitating a certain level of bottom-up design to effectively incorporate these components.
A typical design process for a modern protection system involves users defining functional requirements, followed by the supplier creating a system design specification This specification outlines the use of standard components from a generic system "kit" to achieve the desired functionality The generic system should be supported by its own design documentation and developed in accordance with the IEC 60880 recommendations.
The functionality that necessitates the development of system software is clearly identified, and all new system software is created to meet or exceed the standards of the existing generic software, as outlined in the previous section.
The functional requirements of the system are depicted through diagrams and converted into application software using a validated software tool, meaning this aspect of the system requirements is not included in traditional text-based design documentation, which encompasses system requirements, system specifications, and software specifications Additionally, testing is conducted at the levels of software modules, hardware components, cabinets, and the overall system.
System-level testing is conducted on a generic system prototype, performed at the factory assembly stage and again once the system is installed on-site, typically occurring twice—first when disconnected and then when connected to the central unit.
This design process does not directly align with the IEC 60880 development cycle, and it is essential to interpret certain articles of the standard carefully to apply them to the relevant parts of the development process.
S’il y a des déviations majeures par rapport au cycle de développement de référence de la
The design documentation produced under CEI 60880 will significantly differ from the specifications outlined in Annex F of the Standard While the Standard is highly prescriptive in this area, as long as the information required by the Standard is included in the system design documents, no major non-conformity should be declared.
If a generic design with numerous existing system components is to serve as the foundation for the new system, any additional necessary components can be developed using the initial development language and tools Not all features may be identified in Section 5.2 of the Standard The inherent advantages of utilizing a proven system design should be weighed against the drawbacks of employing less advanced development techniques Provided that the use of established techniques is adequately justified, only minor non-conformities should be noted, and it is important to address the use of pre-existing software within the context of new developments as outlined in IEC 60880.
De nombreux articles de la Norme demandent une interprétation prudente quand on considère des systèmes distribués modulaires contenant un grand nombre de sous-systèmes
Each component contains a processor, and the term "system" should be interpreted in some instances as referring to the entire distributed system, while in other cases, it applies to each of the subsystems.
The integration of hardware and software can initially occur on a component-by-component basis, with a component typically being a processor card that manages the input/output of a control system A system usually consists of multiple subsystems, each containing many identical components If a system modification only impacts the internal functioning of a component, and provided that the interface between subsystems remains unchanged, an impact analysis may not necessitate further testing beyond component control tests and subsystem integration tests In this scenario, the subsystem would be regarded as a "system" according to IEC 60880, section 7.5.
It is important to recognize that the evaluation process can be significantly prolonged if the software developed for various subsystems follows different life cycles In such cases, it may be advisable to summarize the compliance of the different life cycles instead of conducting a detailed analysis of each development cycle against every item in the standard.
In summary, while many non-conformities may arise due to discrepancies between the recommended lifecycle and the lifecycle implemented, as well as between the prescribed documentation and the actual documents produced, the principles that the Standard aims to enforce are clear Major non-conformities should only be declared in cases of deviations from these principles.
The system functional requirements are visually represented and transformed into application software through a validated software tool, which means this part of the system requirements is not included in traditional text-based design documentation Additionally, testing is conducted at various levels, including software module, hardware component, cubicle, and system level.
System level testing is conducted on a generic system prototype, on the factory-assembled system, and once more at the installation site This testing typically occurs twice: first with the plant unconnected and then with it connected.
Software types
The software components of a system are often defined as being either “system” software
(communications, memory management, standard functions) or “application” software
Application software leverages the capabilities of system software, minimizing code duplication across modules This approach not only decreases the overall software volume but also reduces the likelihood of errors, enhancing the reliability of interlock logic, control loops, display formats, and alarm logic.
Design documentation can be categorized into two distinct sets: one for generic system software and another for application software While application software is typically tailored to a specific project, system software has broader applicability and can be utilized across multiple projects.
Verifying the correctness of data is typically easier than that of code, leading many system designs to rely heavily on configuration data to enhance integrity and flexibility This approach aligns with the principles outlined in IEC 60880 Configuration data can be linked to either system or application software and is categorized into unamendable and amendable data, with the latter including alarm limits, setpoints, and calibration data for instrumentation.
In summary, software for a system can be categorized into several types: existing system software, system software that is yet to be developed, application software that needs development, non-amendable configuration data to be created, and amendable configuration data that will also be developed.
The Standard frequently lacks clarity in differentiating between various software and data types, leading to some requirements being irrelevant for certain software categories Notably, when it comes to modifying amendable configuration data, many of the requirements outlined in clause 9 of the Standard do not apply, as discussed in subclause 5.3.
An assessor must possess extensive experience and knowledge of IEC 60880 requirements, enabling them to effectively interpret the Standard while considering the unique characteristics of various software and data types within a system.