Comparing Certification under IEC 61508 1st Edition and 2nd ...The IEC 61508 standard is based on two fundamental concepts: 1. The Safety Lifecycle (SLC), a detailed engineering design

The document was prepared using best effort. The authors make no warranty of any kind and shall not be liable in any event for incidental or consequential damages in connection with the application of the document.

© All rights reserved.

White Paper

Project:

Comparing Certification under IEC 61508 1st Edition and 2nd Edition

Version 1, Revision 5, November 15, 2016 Rudolf P. Chalupa

© exida V1R5 White Paper IEC 61508 Editions_LLS.doc, November 15, 2016 Rudolf P. Chalupa Page 2 of 15

Management Summary

An updated version of IEC 61508, Functional Safety of Electrical/Electronic and Programmable Electronic Systems was issued in September 2010 [N1]. This Second Edition is generally thought to clarify common interpretations of the first edition [N2] and add some refinements that had accumulated in the ten years since the first edition. The fundamental concepts and requirements did not change.

IEC 61508 is a basic safety publication of the International Electrotechnical Commission (IEC). It is intended that industry specific versions of the standard be created based on the general principles of IEC 61508. One of the first industry specific standard was IEC 61511 [N3] for the process industries. Designers of Safety Instrumented Systems (SIS) in specific industries where an industry standard exists are expected to follow that industry standard, not IEC 61508. However, IEC 61508 is to be used whenever an industry specific standard does not exist. For the process industries, SIS designers should follow IEC 61511.

In the control systems market, manufacturer's products are often "certified" for functional safety applications using IEC 61508. This is most often done by a Certification Body (CB) which is accredited to do this work by an Accreditation Body (AB). Each country has one or more AB organizations. An AB is audited and authorized by the world association of Conformity Assessment Accreditation Bodies, International Accreditation Forum (IAF). Most countries in world are signatories of the IAF Multilateral Recognition Agreement recognizing the equivalence of other members' accreditations to their own. The IEC 61508 standard does not require certification by a CB but states that independent, third party assessment is recommended and must be done for SIL 3/4.

Product certifications have been done per IEC 61508 since the standard was first released. A functional safety certification done per IEC 61508 is a verification of product design integrity given the system design meets specifications and maintenance is done per manufacturer's specifications. Therefore, once a given design is procured, the product does not become unsafe as a result of a new version of a standard or even a new version of the product. If the product under consideration has not changed and its certificate has not been withdrawn, one can continue to use it confidently for its entire stated useful life.

AnupdatedversionofIEC61508,FunctionalSafetyofElectrical/ElectronicandProgrammableElectronicSystemswasissuedin

September2010


Table of Contents Management Summary .................................................................................................... 21 Introduction to the IEC 61508 Standard ..................................................................... 42 Changes to IEC 61508 2nd edition ............................................................................. 6

2.1 Functional Safety Management .................................................................................... 62.2 Safety Requirements .................................................................................................... 62.3 Requirements Traceability ............................................................................................ 72.4 Proven in Use ............................................................................................................... 72.5 Systematic Capability ................................................................................................... 82.6 Detailed Hardware Design ............................................................................................ 82.7 Detailed Software Design and Implementation ............................................................. 92.8 Software Integration Testing ....................................................................................... 102.9 Cybersecurity .............................................................................................................. 10

3 Certification programs and how they function ........................................................... 104 The validity of the certification against previous versions of the standard ................ 125 Process and Roles .................................................................................................... 13

5.1 exida ........................................................................................................................... 135.2 Reference documents ................................................................................................. 13

5.2.1 Industry Standards ............................................................................................. 135.2.2 Technical References .......................................................................................... 14

6 Terms and Definitions ............................................................................................... 147 Status of the document ............................................................................................. 15

7.1 Liability ........................................................................................................................ 157.2 Releases ..................................................................................................................... 15


1 Introduction to the IEC 61508 Standard IEC 61508 is an international standard for the “Functional Safety” of electrical/electronic/ programmable electronic (E/E/PE) systems. IEC 61508 defines functional safety as “part of the overall safety relating to the Equipment Under Control (EUC) and the EUC control system which depends on the correct functioning of the E/E/PE Safety-Related Systems, other technology safety-related systems and external risk reduction facilities”. Thus the basic purpose of IEC 61508 is to create requirements intended to achieve reliable systems that work properly or fail in a predictable manner. IEC 61508 does not cover safety issues such as flammable gas ignition, electric shock, hazardous falls, long-term exposure to a toxic substance, etc.; these issues are covered by other standards. While it is clear that the standard covers electrical, electronic and programmable electronic systems, it is clearly implied and well accepted that the standard also covers the associated mechanical devices needed as part of any safety function.

Development of this standard began in the mid-1980’s when the International Electrotechnical Commission Advisory Committee of Safety set up a task force to consider standardization issues raised by the use of programmable electronic systems (PES) in automatic protection systems. At that time, many regulatory bodies prohibited the use of any software-based equipment in safety critical applications. Work began within IEC SC65A/Working Group 10 on a standard for PES used in safety related systems (SRS). This group merged with Working Group 9 where a standard on software safety was in progress. The combined group treated safety as a system issue.

The complete IEC 61508 standard is divided into seven parts. Parts 1-4 are normative, meaning the requirements must be met for compliance with the standard. The normative parts of the standard have thousands of requirements, i.e., sentences including the term “shall” or “must” which need to be correctly addressed for compliance with the standard. All of these normative requirements are intended to help designers create systems that work correctly (are reliable) or fail in a predictable (usually fail-safe) manner. Many designers consider most of the requirements of IEC 61508 to be classical, common sense practices that come directly from prior quality standards and general software engineering practices.

IEC 61508 Parts 5-7 are informative, meaning that they only provide examples, guidelines, and information originally deemed useful by the committee. The informative parts of the standard have no requirements and should never be interpreted as anything but informative. The informative parts of the standard are not reviewed extensively and have not been updated to the latest developments in the 2010 version of IEC 61508.


IEC 61508 is called a basic safety publication of the IEC. Lacking industry-specific language, it is an “umbrella” document covering multiple industries and applications. A primary goal of the standard is to help individual industries develop supplemental standards, tailored specifically to those industries based on the original 61508 standard. Several such industry specific standards have now been developed with more on the way. IEC 61511 [N3] has been written for the process industries. IEC 62061 [N4] addresses machinery safety. IEC 61513 [N5] covers the nuclear industry. ISO 26262 [N6] covers the automotive industry. There are even product specific standards now being released that follow the framework and the concepts IEC 61508. One of these is IEC 61800-5-2 [N7], Safety Requirements – Functional Safety, for variable speed motor controllers. All of these standards build directly on IEC 61508 and reference it accordingly.

The IEC 61508 standard is based on two fundamental concepts:

1. The Safety Lifecycle (SLC), a detailed engineering design process, intended to reduce or eliminate failures due to systematic errors, and

2. Probabilistic failure performance analysis, quantified in order of magnitude levels - called safety integrity levels (SIL) - intended to address random failures

The safety lifecycle is defined as an engineering process that includes all of the steps necessary to achieve required functional safety. The safety lifecycle is included in the standard to provide sufficient protection against systematic errors, errors resulting in failures that are deterministically related to a certain cause. Systematic errors are typically design mistakes. The safety lifecycle concepts apply to the entire system and all of its equipment including sensors, logic solver(s), and final elements.

Probabilistic failure performance analysis is the second fundamental concept. IEC 61508 recognizes that all failures are not equal. Two primary failure modes are defined, fail-safe (FS) and fail-danger (FD). IEC 61508 defines four, quantitative, order of magnitude levels of safety integrity (Table 1.1), based on several variables including the FD failure rate [T1]. These levels are called safety integrity levels (SIL). In the SLC for an SIS custom project, quantitative failure targets are established and dangerous failure probability calculations are performed for the entire set of equipment including sensors, logic solver and final elements in any given design. This is one of the three steps done to verify that each safety function design meets its target [T2]. This performance-based approach allows the standard to avoid prescriptive rules for redundancy and self-test capability that so often become obsolete soon after they are published. Table 1.1 Safety Integrity Levels

Safety Integrity Level

Average probability of failure on demand (Low Demand mode of

operation)

Probability of dangerous failure per hour

(Continuous or High Demand mode of operation)

SIL 4 ≥ 10-5 to < 10-4 ≥ 10-9 to < 10-8 SIL 3 ≥ 10-4 to < 10-3 ≥ 10-8 to < 10-7 SIL 2 ≥ 10-3 to < 10-2 ≥ 10-7 to < 10-6 SIL 1 ≥ 10-2 to < 10-1 ≥ 10-6 to < 10-5


2 Changes to IEC 61508 2nd edition A new version of the IEC 61508 standard was introduced in 2010. This is the 2nd edition of the standard; the first edition was released in 1998/2000. The International Electrotechnical Commission requires that all standards be updated or at least reaffirmed every five years. A reaffirmation was done in 2005. A maintenance update was done in 2010. Many consider the changes to the second edition to be clarifications confirming interpretations of the major Certification Bodies (exida, TÜV Süd, etc). The standard was not re-written nor were any fundamental concepts changed. In effect this means that many of the certificates done prior to 2010 were based on virtually identical requirements. However, there were specific changes to several areas.

2.1 Functional Safety Management Although very little has changed in the area of functional safety management, one clarification is in the area of competency management. The standard has always required that anyone involved in any phase of the safety lifecycle must be competent in whatever roles that they have been assigned on the project. However, the 1st edition does not provide any detail on what is required in order to show competence. The 2nd edition clarifies this to some degree. Specifically, the 2nd edition requires that the responsibilities of the person and the level of supervision required must be considered. The 2nd edition defines some specific types of knowledge that must be considered when assessing competence. It also describes a number of conditions where the specification of competence shall be more rigorous; however, the different levels of rigor are never defined and therefore left up to the assessor.

The impact of this change to a manufacturer using IEC 61508 to certify a product is that more detailed competency documentation may be required for the personnel performing safety critical roles. Most Certification Bodies already required strong documentation of competency and most manufacturers already met this requirement.

This change would have no impact on any owner-operator of a plant or a system designer in the process industries if they are using IEC 61511. Any owner-operator of a plant using IEC 61508 may have to provide more detailed competency documentation. Many plants are asking their lead safety personnel to get personal competency certification such as the CFSE (www.cfse.org) program [T5].

2.2 Safety Requirements Minor clarifications have been made in the area of safety requirements in the 2nd edition of the standard. The 1st edition did not distinguish between safety requirements for a product versus a bespoke (complete, turnkey) SIS system. The 2nd edition provides definitions for these two conceptually different types of documents (product safety requirements specification and system safety requirements specification). The product safety requirements specification contains the safety functions and safety integrity requirements that a product must meet, while the system safety requirements contains the details of the hardware and software necessary to implement the required safety functions” [N1, Part 1 section 7.2.3.2]. Some of the requirements of the E/E/PE system safety requirements specification, located in 7.2 of IEC 61508-2 ed. 1.0 have remained in IEC 61508-2 ed. 2.0 and some have been transferred into IEC 61508-1 ed. 2.0. However, this change did not affect the content of the requirements, only the organization of these requirements.


Overall the details of what must be included in both the product safety requirements document and the system safety requirements, and the software safety requirements document have not changed much between the two versions. Thus there has been no impact to product manufacturers. A few items have been added, but none of these changes have much effect on the development process as most items are just clarifying items that were already required or were typically being followed even though they were not explicitly required.

2.3 Requirements Traceability The 2nd edition of the standard specifically details requirements traceability. The 1st edition of the standard called for traceability between requirements and design, and traceability between validation testing and safety requirements, but no detail was provided. The 2nd edition explicitly states which documents must be traceable to each other and in which direction. The traceability requirements are only documented in the software portion of the standard (part 3). Therefore, these requirements mostly apply to software safety requirements. Many development projects already followed detailed traceability and the new changes mostly represent clarification. Therefore, this change will have little impact on manufacturers existing certification.

2.4 Proven in Use Proven in Use is a method that can be used to justify the design quality of pre-existing products that were not developed with a process compliant with IEC 61508. Such products still have to meet many requirements (such as the probability of failure requirements). However, sufficient evidence of field use without systematic defects being found can be accepted as evidence that such defects are not likely to occur in the future. This allows existing products that meet this criterion to be used in safety related systems. In the 1st edition of IEC 61508, there is a clear definition on what is required from a hardware development standpoint for a proven in use product. However, there was little indication in the 1st edition as to what is required from a software development point of view.

As a result, there have been varied interpretations on whether proven in use applies to products with software. A good argument could be made that it does not apply or that it does apply and it was left up to the interpretation of the assessor to determine if these arguments were accepted or not. The 2nd edition of the standard clears up this situation, by clearly stating that software is may use the proven in use concept as partial evidence of design integrity.

In addition, the 2nd edition defines the requirements for using a product that was not developed with a compliant process, but does not qualify for proven in use either. In this case the non-compliant process can be analyzed and if it can be shown that the process used to develop the product is sufficiently compliant to IEC 61508, then the product can be considered. What is sufficient in this case is well defined by the standard; however, almost all of the requirements from the standard must be met, so there is little difference between a sufficiently compliant process and a compliant process.

Depending of the previous interpretation of the Certification Body, this clarification could allow more proven in use evidence to be used in part to show systematic integrity.

This change would have no impact on any owner-operator of a plant or a system designer in the process industries if they are using equipment certified under IEC 615098 and are adhering to the steps defined in the Safety Lifecycle.


2.5 Systematic Capability In the 1st edition of IEC 61508, safety integrity level (SIL) is defined as applying to safety functions. Furthermore, the 1st edition states that in order to implement those safety functions to a given SIL, hardware and software must be designed, developed, tested, and documented following certain processes that vary in rigor based on the SIL level. That statement inferred that a "SIL X capable product" meant that the product was developed with a SIL X compliant process. However, because this was not explicitly stated in the standard others felt that there was no such thing as a SIL X compliant product. The 2nd edition has cleared up this argument by defining a new term called "systematic capability" that means that the product meets the requirements for avoidance and control of systematic faults which is achieved by following a SIL X compliant development process.

Any product with a systematic capability rating must have a safety manual to document all of the information required to enable integration of that item into the safety related system. Although this requirement was not explicitly stated in the 1st edition of the standards, products that were certified to IEC 61508 almost always had such a manual as it was required to fulfill the operation and maintenance requirements of the standard. The required content of the safety manual is now defined for both hardware and software products. This change would have no impact on a manufacturer unless they did not previously provide a compliant safety manual.

The definition of systematic capability will help owner-operators and system designers by providing a clearer way to show that their designs meet the required SIL level.

2.6 Detailed Hardware Design In IEC 61508 2nd edition, products may now comply with one of two alternative approaches for meeting architecture constraints [T2]. Route 1H utilizes the Safe Failure Fraction (SFF) calculation to determine minimum levels of safety redundancy. For products with high confidence failure rate data, Route 2H provides two simple methods to determine minimum redundancy for each element without an SFF calculation. The 2H method appears to be identical to the “prior use” method from IEC 61511:2003 except with more detail and definition of the needed documentation.

One of the most significant changes to the standard is the handling of no effect failures from a Failure Modes Effects and Diagnostic Analysis (FMEDA), [T6]. In the 1st edition of the standard, these failures were forced to be counted as safe failures when calculating an SFF for route 1H because of the definition of "safe" which included anything that is not dangerous. An artificial increase in SFF was the result. However, in the 2nd edition the definition of a safe failure was changed to anything that caused a false trip in a non-redundant architecture. This new definition provides a way to clearly calculate false trip rates which is a strong improvement. But the new definition excludes no effect failures from the safe failure fraction calculation. This means that a product which previously met IEC 61508 SFF requirements for a particular SIL may no longer meet the SFF requirement and, therefore, must be downgraded by one level if assessed against the 2nd edition of the standard per route 1H. Therefore, all such products should be evaluated per the Route 2H method.

This change may impact manufacturers with SFF ratings near a SIL level threshold and limited field failure history. They may need to add diagnostics to their products. The change will have no impact on any manufacturer with a solid SFF or sufficient field failure history. Those with a sufficient field failure history, can be evaluated per the Route 2H method which does not use the SFF metric.


Another very significant change is the treatment of ASICs and programmable logic development. These components tend to be very complex and the process used to develop them is akin to the software development process. Yet, in the 1st edition of the standard there were no specific requirements for the development of such devices. Recognizing the complexity of these devices, IEC 61508 2nd edition now defines a rigorous development process that must be followed when designing such devices. The process is very similar to that required for software development.

The impact of this change on a manufacturer will depend on the procedures preciously in use for ASIC development. Many manufacturers have been using high quality procedures for many years. In those cases, no changes are needed. Some Certification Bodies, like exida, already recognized the need for detailed procedures and interpreted sentences in IEC 61508 1st edition as requiring good procedures for ASICs.

There is also a change in the area of component de-rating. In the 1st edition of IEC 61508 component de-rating was required as the requirement stated that “de-rating shall be used as far as possible for all components.” In the 2nd edition, this has been changed to a recommendation as the requirement states that “de-rating should be considered for all components.”

The impact of this change is not significant as prudent de-rating has been a common practice in manufacturers electronic and mechanical hardware design procedures for several decades.

2.7 Detailed Software Design and Implementation In the 1st edition of the standard, software development tools were called out as important to safety, but the criticality of the tools was not considered. Thus all tools from the critical compiler to the non-critical word processing tool would require justification based on certification or tools in which confidence from prior usage could be established. The 2nd edition of the standard recognizes that different tools have different criticality to safety and therefore must be treated differently. It also introduces the concept of tool failure analysis so that failure modes of tools are understood and steps can be taken to mitigate the consequence of such failures. In addition, the 2nd edition introduces alternatives that can be used for critical tools if confidence from use cannot be established.

In the 1st edition of the standard, for SIL 3, software test coverage must be achieved during module and/or integration testing to insure that all or most of the code is covered by the tests. In the 2nd edition of the standard this is required for SIL 1 and higher, although the level of code coverage varies by SIL. For SIL 1, only entry points to all functions must be covered. This means that all functions must be called during the testing, but there is no requirement for code coverage within a given function. For SIL 2 all statements must be covered, and for SIL 3 all statements including both sides of all branches must be covered. This means that for SIL 2, an if-then-else statement would be considered covered if either the “if” part of the statement or the “else” part executed. For SIL 3 both the “if” part and the “else” part must be executed.

The 2nd edition of the standard requires measurement of module complexity for all software modules. Modules above a certain complexity size must be addressed by re-design to reduce the complexity, breaking the module into multiple modules, or perform extra measures such as a code walkthrough or full path coverage testing on that module to ensure that the complexity does not present a problem.

This change may require more extensive software module testing when a manufacturer creates new software.


2.8 Software Integration Testing If a model was created to specify the safety requirements, then integration tests based on that model should be included. Examples of models used to describe requirements include state transition diagrams, sequence diagrams, and truth tables. These models are created if warranted by the complexity of the requirements. In addition, test management and automation tools must now be used to manage the test process. These tools will support tracking of test cases, test scripts and test results in order to support a more systematic test process.

This change may require a manufacturer to implement more systematic software integration testing.

2.9 Cybersecurity Cybersecurity is not mentioned in the 1st edition of IEC 61508. In the 2nd edition, cybersecurity is addressed at a very high level. While there are no detailed requirements for cybersecurity, “malevolent and unauthorized actions have to be addressed during the hazard and risk analysis. If a security threat is seen as being reasonably foreseeable, then a security threats analysis should be carried out and if security threats have been identified then a vulnerability analysis should be undertaken in order to specify security requirements.”

What this means from a product certification point of view is that more cybersecurity requirements will be specified for products going forward. Such requirements could include cybersecurity features that the product supports (e.g. requiring user authentication to access to system) as well as requirements that the product be free of cybersecurity vulnerabilities. This latter requirement is similar to a safety integrity requirement in that it is difficult to quantify and demonstrate. Whereas safety integrity requirements can be demonstrated by conformance to a standard such as IEC 61508, similar standards exist and are being developed for cybersecurity [N8] and development processes that reduce the chance of cybersecurity vulnerabilities have been defined [T7]. There is significant overlap between the types of processes that are followed in order to minimize dangerous failures and to minimize cybersecurity vulnerabilities. As these cybersecurity standards become more prevalent, it is recommended that the cybersecurity development lifecycle be closely intertwined with the safety development lifecycle. This will reduce the impact of the cybersecurity requirements by leveraging the commonalities with the safety development lifecycle.

The impact to a manufacturer will depend on how the Certification Body interprets the requirement. Some Certification Bodies like exida are accredited to perform cybersecurity certification and are proceeding with product cybersecurity certification as part of their functional safety program.

3 Certification programs and how they function Certification Bodies (CB) are officially authorized to operate product certification programs by a nationally designated Accreditation Body (AB). National Accreditation Bodies for IEC standards are typically designated for each country. In the United States, the American National Standards Institute (ANSI) is the IEC liason organization and performs accreditation. Deutsche Akkreditierungsstelle (DAkkS) is the national Accreditation Body for the Federal Republic of Germany. Most product certification programs are operated IEC/ISO 17065 a standard for operation of a product certification program. Each CB operates per a "scheme" which references all required standards and any other program requirements.


A Certification Body that has achieved accreditation and operates under the accredited program is authorized to use the AB logo on each certificate as indicated in Figure 2.1 where clips from four Certification Bodies are shown with their AB logo..

Figure 2.1 Clips of certificates with AB logo to show validity of accreditation.

A product could receive IEC 61508 certification if the detailed assessment by a CB shows that the product meets all relevant requirements of the scheme. In general, this certification is an indication of high design quality for hardware and software and high manufacturing quality. IEC 61508 can be used at various levels of integration from the “component” level (microprocessor) to the systems level (integrated automatic protection system).

The IEC 61508 standard states: “To conform to this standard it shall be demonstrated that the requirements have been satisfied to the required criteria specified (e.g., SIL) and therefore, for each clause or sub-clause, all the objectives have been met”. This is often demonstrated by the use of a “Safety Case.”


The Safety Case / Safety Justification methodology provides a systematic and complete way to show compliance to one or more functional safety standards. The methodology was established in industries which deal with functional safety of computerized automation in nuclear and avionics applications. For the IEC 61508 standard, all requirements from IEC 61508 are typically compiled into a proprietary tool done by each CB. Each requirement should be precisely documented along with the reasoning behind the requirement. “Arguments / Solutions” provide a description of how each requirement is met by listing design arguments, verification activities and test cases relevant to that requirement. For full traceability, each design argument and verification/test activity is linked with evidence documents showing the results of the work.

When a safety case for an IEC 61508 compliance scheme is completed it must show all requirements along with an argument for each requirement as to how the system / product meets the requirement. A link to the evidence document that supports the argument is also provided. Additional fields are provided for the independent assessor to record the results of the assessment and to communicate their expectations with other assessors and the certifying individuals. Overall, the safety case concept provides a single place to store compliance information in an organized manner. The use of a safety case provides a systematic means to ensure completeness of any assessment. The Safety Case method supports company learning over multiple projects by establishing a knowledge base consisting of patterns of fundamental requirements and related design arguments. A Safety Case can be constructed to cover multiple standards from the IEC 61508 family making it easier to show compliance with multiple standards. Templates and previous examples of evidence documents provide the ability to reduce effort on subsequent projects.

4 The validity of the certification against previous versions of the standard

When a new edition of a standard is released, it’s reasonable to ask, “What about the products that were designed or approved under the previous edition?”

A functional safety certification done per IEC 61508 is a verification of product design integrity given the system design meets specifications and maintenance is done per manufacturer's specifications. Therefore, once a given design is procured, the product does not become unsafe as a result of a new version of a standard or even a new version of the product. If the product under consideration has not changed and its certificate has not been withdrawn, one can continue to use it confidently for its entire stated useful life. Different CBs have different policies with respect to the updating of standards. However, some general features are held in common by all CBs. These generally conform to the rule of thumb that if a product has a certificate that is still in force and no safety critical changes have been made, that product is still certified, even if the certificate is to a previous edition of the relevant standard. Since it is rare that the new edition of a standard is the result of anything other than an incremental update, the issuing of a new edition does not change the behavior of existing products; they continue to function as before.


5 Process and Roles

5.1 exida exida is one of the world’s leading accredited Certification Bodies and knowledge companies specializing in automation system safety, cybersecurity and availability with over 400 man-years of cumulative experience in these fields. Founded by several of the world’s top reliability and safety experts from assessment organizations, end-users, and manufacturers, exida is a global corporation with offices around the world. exida offers training, coaching, project oriented consulting services, safety lifecycle engineering tools, detailed product assurance, cyber-security and functional safety certification, and a collection of on-line safety and reliability resources. exida maintains a comprehensive failure rate and failure mode database on process equipment based on field failure data of over 150 billion unit operating hours.

5.2 Reference documents

5.2.1 Industry Standards

Item Identification Description

N1 IEC 61508: ed2, 2010 Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, International Electrotechnical Commission, Geneva, Switzerland

N2 IEC 61508: ed1, 1998/2000

Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, International Electrotechnical Commission, Geneva, Switzerland

N3 IEC 61511: ed1, 2003 Functional Safety: Safety Instrumented Systems for the process industry sector, International Electrotechnical Commission, Geneva, Switzerland

N4 IEC 62061: ed 1, 2005 Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems, International Electrotechnical Commission, Geneva: Switzerland.

N5 IEC 61513: ed. 1, 2001 Nuclear power plants - Instrumentation and control for systems important to safety - General requirements for systems, International Electrotechnical Commission, Geneva: Switzerland.

N6 ISO 26262, 2011 Road vehicles -- Functional safety, International Organization for Standardization, Geneva: Switzerland

N7 IEC 61800-5-2, 2007 Adjustable speed electrical power drive systems, Part 5-2: Safety Requirements – Functional, International Electrotechnical Commission, Geneva: Switzerland.

N8 EDSA-312: 2010 Embedded Device Security Assurance - Software Development Security Assessment, ISA Security Compliance Institute, Research Triangle Park, NC, USA


5.2.2 Technical References

Item Identification Description

T1 White Paper, July 2014 The Key Variables in PFDavg Calculation, exida, Sellersville, PA, USA, www.exida.com

T2 White Paper, June 2014 Three Steps in SIF Design Verification, exida, Sellersville, PA, USA, www.exida.com

T3 2nd Edition, 1998 Goble, W. M., Control Systems Safety Evaluation and Reliability, ISA, Research Triangle Park, NC, USA

T4 Web Survey, 2014 Survey on Interpretations of Random versus Systematic Failures, exida, Sellersville, PA, USA, www.exida.com

T5 www.cfse.org CFSE Program

T6 White Paper, February 2007

FMEDA – Accurate Product Failure Metrics, exida, Sellersville, PA, USA, www.exida.com

T7 2006 Howard, Michael and Lipner, Steve, The Security Development Lifecycle, Redmond, Washington, Microsoft Press

6 Terms and Definitions

AB Accreditation Body

ANSI American National Standards Institute

CB Certification Body

E/E/PE Electrical / Electronic / Programmable Electronic

EUC Equipment Under Control

HFT Hardware Fault Tolerance

IAF International Accreditation Forum

IEC International Electrotechnical Commission

ISO International Organization for Standardization

PES Programmable Electronic System

SFF Safe Failure Fraction

SIF Safety Instrumented Function

SIL Safety Integrity Level

SIS Safety Instrumented System

SLC Safety Lifecycle

SRS Safety Related System


7 Status of the document

7.1 Liability exida provides services and analyses based on methods advocated in international and national standards. exida accepts no liability whatsoever for the correct and safe functioning of a plant or installation developed based on this analysis or for the correctness of the standards on which the general methods are based.

7.2 Releases Version: 1 Revision: 5 Version History: V0, R1: First Internal Draft, May 6, 2014 V1, R1: Edits and clarifications V1, R5: LLS, Edits and clarifications, 11/15/16 Author: Rudolf P. Chalupa Reviews: V0, R1: William Goble, December 19, 2014 Release Status: Released to web publication

Documents

Comparing Certification under IEC 61508 1st Edition and 2nd ...The IEC 61508 standard is based on two fundamental concepts: 1. The Safety Lifecycle (SLC), a detailed engineering design