Novel Features of the 2nd Ed. of Iec 61508

Copyright exida.com 2007..2009

Rainer FallerGerman IEC 61508 memberMünchen, Germany +49-89-49000547Sellersville, PA., USA+1-215-453-1720

Novel features of the 2Novel features of the 2ndnd Ed. of IEC 61508Ed. of IEC 61508

excellence in dependable automationexcellence in dependable automation

Presenter: Rainer FallerCo-founder of exida.com– The Functional Safety consulting company25 years of professional functional safety experienceDevelopment engineer at MAN for a driverless bus/truckFormer business unit manager at TÜV SüdConvener of the German IEC 61508 committee (DKE GK914) Member of the international IEC 61508 committee

Copyright exida.com 2007..2009 2

IEC 61508 – Major ExtensionsIEC 61508 maintenance project took much more time than expected – Changes are many and substantialIEC 61508 all parts

Extended scope from complete safety functions to (partial) safety functions performed by devices such as logic solver and field devicesNew terms: Overall safety function, Element safety function

Compliant Item, Systematic Capability Safety Manual for Compliant Item, Safety Justification

Mathematically more profound termsAverage probability of dangerous failure on demand – PFDAverage frequency of dangerous failure – PFHTerms in IEC 61508 and IEC 61511 are now the same – demand / continuous mode, dangerous failure rate, etc.


IEC 61508 – Major ExtensionsIEC 61508-1

Functional safety management clauses extended – Competence now normative, previously informativeMore clean splitting between

Overall Safety Requirements Specification (Part 1)– obligation of user and system designerSystem Design Requirements Specification (Part 2 + 3)– obligation of system designer and product designer

Clarification on SIL 4Content of the Assessment reportSecurity – few high level requirements, waiting for future ISA S99


IEC 61508 – Major ExtensionsIEC 61508-2

Clear definition of Compliance RoutesProven-in-Use – refined and tightenedNo effect and no part failures Definition of SFF made more preciseSynthesis of elements to achieve the required systematic capability(Application Specific) Integrated Circuits, FPGA, etc.Soft-errors for VLSI ICs

IEC 61508-3Properties to provide better deduction of the descriptive measures and techniques in the annexes A and BTools and Pre-existing softwareLast minute change: Proven-in-Use for pre-existing software


IEC 61508 – Major ExtensionsIEC 61508-4 – Terms & Definition

Mathematically more profoundMore, most needed definitionse.g. subsystem, element, compliant item, tools, …

IEC 61508-5 – SIL determination methodsNew excellent explanation of safety principles

IEC 61508-6 – Guideline on Part 2 and Part 3Most wanted background on probabilistic modelingAll major probabilistic modeling techniques explained: Reliability Blocks (RBD), Fault trees (FTA), Markov, Monte Carlo and Petri-Nets

IEC 61508-7 BibliographyThe desired rework has not happened due to huge effort required,but outdated literature has been removed


IEC 61508 – Extended Scope System, Subsystem, Element, Compliant Item

SensorSensor Logic solverLogic solver ActorActor

Process connection

Each item can be claimed to be a Compliant Item, if it complies with the relevant requirements of IEC 61508


previous IEC 61508

IEC 61508 – Compliant Item

Element Safety function of a Compliant ItemPart of a safety function which is implemented by an element.

Systematic CapabilityMeasure (scale of SC 1 to SC 4) of the confidence that the systematic safety integrity of an element meets the requirements of the specified SIL, in respect of the specified element safety function, when the element is applied in accordance with the instructions specified in the compliant item safety manual.

Safety Manual of a Compliant Itemprovides all the information relating to the functional safety of an element that is required to ensure that the system meets the requirements of IEC 61508.All safety manual claims shall be justified by evidence.


IEC 61508 – Compliance Routes

Systematic Integrity Compliance Route, see next slide

Hardware Integrity Compliance Route7.4.2.2 The design of the safety-related system shall meet all of the requirements a) to e)as follows: a) the requirements for hardware safety integrity comprising (HW Compliance Routes)

– the architectural constraints on hardware safety integrity, and – the requirements for quantifying the effect of random failures;

b) the special architecture requirements for ASICs with on-chip redundancy, whererelevant;

c) the requirements for systematic safety integrity (systematic capability), which can bemet by achieving one of the following systematic safety integrity compliance routes:see next slide

d) the requirements for system behaviour on detection of a fault;

e) the requirements for data communication processes.


Systematic Integrity Compliance Routes

Route 1S: Compliance with the requirements for the avoidance of systematic faults and the requirements for the control of systematic faults, or

Route 2S: Compliance with the requirements for evidence that the equipment is proven in use, or

Route 3S: Compliance with the requirements of IEC 61508-3 for pre-existing software components;

… Now also applicable

to Software !!


Proven-in-Use Elements7.4.10.1 An element shall only be regarded as proven in use when it has a clearly restricted andspecified functionality and when there is adequate documentary evidence to demonstrate that thelikelihood of any dangerous systematic faults is low enough that the required SIL … is achieved. Evidence shall be based on analysis of operational experience of a specific configuration of the elementtogether with suitability analysis and testing within the intended application. 7.4.10.2 The documentary evidence shall demonstrate that a) the previous conditions of use of the specific element are the same as, or sufficiently close to, those

that will be experienced by the element in the safety-related system; b) the dangerous failure rate has been achieved in previous operation.

NOTE 3 The collection of evidence for proven in use requires an effective system for reporting failures. Conservatively, itshould be assumed that users return faulty elements only during the warranty period.

7.4.10.3 When there is any difference between the previous conditions of use and those that will beexperienced in the safety-related system, then an impact analysis on the differences shall be carried out ...

7.4.10.4 A proven in use safety justification shall be documented that the element supports therequired safety function with the required systematic safety integrity. This shall include a) the suitability analysis and testing of the element for the intended application; b) the demonstration of equivalence between the intended operation and the previous operation

experience, including the impact analysis on the differences; c) the statistical evidence. … 7.4.10.7 Any future modification of a proven in use element shall comply with the requirements of 7.8and IEC 61508-3.


Very unclear for SW items such as operating systems

11

Old controversy from 1st release re-openedTwo schools “Probability” vs. “Architecture” cannot meet

“Probability only” school – argues that SFF has no mathematical meaning.(primarily France and Japan)“Architectural constraints” school – will not accept probabilistic safety targets only, as the input data is too weak.(primarily Germany and United Kingdom)

HW Compliance Routes


7.4.4 … the highest safety integrity level that can be claimed for a safety function is limited bythe hardware safety integrity constraints which shall be achieved by implementing one of twopossible routes:

– Route 1H based on hardware fault tolerance and safe failure fraction concepts (as in the previous release)

or

– Route 2H based on component reliability data from feedback from end users, increasedconfidence levels and hardware fault tolerance (similar to IEC 61511) for specifiedsafety integrity levels; – SIL4: HFT = 2; Type B : DC >= 60% – SIL3: HFT = 1; Type B : DC >= 60% – SIL2: High demand and continuous mode : HFT = 1; Type B : DC >= 60% – SIL2: Low demand : HFT = 0; Type B : DC >= 60%

7.4.4.3.3 If route 2H is selected, then the reliability data uncertainties shall be taken intoaccount when calculating the target failure measure (i.e. PFDavg or PFH) and the system shallbe improved until there is a confidence greater than 90 % that the target failure measure isachieved.

HW Compliance Routes

Requires Monte Carlo simulation to my knowledge


Classified Failure Rates

Current definitions were not sufficientDangerous (D) failure: failure of an element / system that plays a part in implementing the safety function that:

a. prevents a safety function from operating when required (demand mode) or causes a safety function to fail (continuous mode) such that the EUC is put into a hazardous or potentially hazardous state; or,

b. decreases the probability that the safety function operates whenrequired.

Safe (S) failure: failure of an element / system that plays a part in implementing the safety function that:

a. results in the spurious operation of the safety function to put the EUC into a safe state or maintain a safe state; or,

b. increases the probability of the spurious operation of the safety function to put the EUC into a safe state or maintain a safe state.

No Effect failure: failure rate of an element that plays a part in implementing the safety function. It does not contribute to the failure rate of the safety function.


Safe Failure Fraction

Current definitions was imprecise because of incomplete failure classification

Safety Failure Fraction (SFF): property of a safety related element that is defined by the ratio of the average failure rates of safe plus dangerous detected failures and safe plus dangerous failures. This ratio is represented by the following equation:

The no effect failure is not used for SFF calculations, even being part of the safety function.

This is the most severe interpretation of IEC 61508:1998The German national comment has not been accepted !


IEC 61508-2 – Systematic IntegrityGrowing understanding that Architecture is equally important to master systematic faults as random faultsAllow the Synthesis of Elements to achieve the required Systematic Capability (former term: Safety Criticality)

7.4.3.1 To meet the requirements for systematic safety integrity, the safety-related system may, in the circumstances described in this section, be partitioned into elements of different systematic capability.

7.4.3.2 For an element of systematic capability SIL N (N=1, 2, 3), where a systematic fault of thatelement does not cause a dangerous failure of a safety function but does so only in combination with asecond systematic fault of another element of systematic capability SIL N, the systematic capability of the parallel combination of the two elements can be treated as having a systematic capability of SIL (N + 1)providing that sufficient independence exists between the two elements.

7.4.3.3 The systematic capability that can be claimed for a combination of elements each of systematic capability SIL N can at most be SIL (N+1).

7.4.3.4 Sufficient independence, in the design between elements and in the application of elements, shall be justified by common cause failure analysis to show that the likelihood of interference between elements and between the elements and the environment is sufficiently low in comparison with the safety integrity level of the safety function under consideration.


IEC 61508-1 – SIL 4

7.6.2.11 In cases where the allocation process results in the requirement for a safety-related system implementing a SIL 4 safety function then the following shall apply:

a) There shall be a reconsideration of the application to determine if any of the riskparameters can be modified so that the requirement for a SIL 4 safety function is avoided.The review shall consider whether:

Additional safety-related systems or other risk reduction measures, not based on safety-related systems, could be introduced;

The severity of the consequence could be reduced; The likelihood of the specified consequence could be reduced.

b) If after further consideration of the application it is decided to implement the SIL 4 safetyfunction then a further risk assessment shall be carried out using a quantitative method thattakes into consideration potential common cause failures between the safety-related systemand:

any other systems whose failure would place a demand on it; or, any other safety-related systems.

Explicit requirement to reconsider the applicationExplicit requirement for Common Cause analysis


Application Specific Integrated CircuitsV-model lifecycle similar to softwareExtensive Annex F describes methods and techniques for the Application Specific IC lifecycle phases

Descriptive requirements for the implementation of redundant architectures on a single substrateExamples: Dual-core µC in use in automotive and machinery industry


1. Identify potential common cause initiators (CCI). 1.1 Start with the list in CDV IEC 61508‐2 Annex E.1.1.2 Consider other foreseeable physical CCI 1.3 Consider other foreseeable logical CCI (such as shared resources and signals)

2. Identify the redundant blocks on the IC/ASIC/FPGA which will suffer from CCI amongst them.

3. Qualitatively evaluate the safety measures against the individual CCI identified in step 1 for each pair of redundant blocks identified in step 2.

3.1 Identify Open Items

4. Quantitatively answer the tables E.1 and E.2 of CDV IEC 61508‐2 Annex E for each pair of redundant blocks identified in step 2 and evaluate the specific ß factor.

5. Use the specific ß factors in the probabilistic modelling (FTA)

6. Identify the derived design requirements6.1 Collect the derived design requirements in a requirements management system such as exida

SafetyCaseDB

Analysis of Dependent Failure (“CCA”)


Common Cause InitiatorsTypical Common Cause by external Initiator

Environmental stress, e.g. TemperatureEMI(Radiation)

Common Cause by internal InitiatorPhysical dependencies

Lake of cellsLogical dependencies

Shared resources, access to outputsHidden dependencies

Clock treePower supplyTest circuitry


CCA – IEC 61508-2 2nd EdTable E.1 – Techniques and measures that increase βB-IC

Technique/measure Delta β-factor [%]

Remark

1 Watchdog on-chip used as monitoring element

5 Monitoring elements used for watchdog function and necessary to guarantee the required DC or SFF should be realised external to the IC preferably under the aspect of common cause failures. The use of a watchdog(s) on-chip may result in a higher DC or SFF compared to external realization.

2 Monitoring elements on-chip other than watchdog, for example clock monitoring

5 - 10 Monitoring elements used for example for clock monitoring and necessary to guarantee the required DC or SFF should be realised external to the IC preferably under the aspect of common cause failures. The use of a monitoring element(s) on-chip may result in a higher DC or SFF compared to external realization.

3a Internal connections between blocks by wiring between output and input cells of different blocks without cross-over

2 Comparison of conditions and results between different blocks should be realised external to the IC preferably.

Analysis of possible common cause failures including FMEA of stuck-at-faults of internal connections is required. Effects of temperature increase due to faults shall be taken into account in particular.

3b Internal connections between blocks by wiring between output and input cells of different blocks with cross-over

4 Comparison of conditions and results between different blocks should be realised external to the IC preferable.

Analysis of possible common cause failures including FMEA of stuck-at-faults and short circuit of internal connections is required. Effects of temperature increase due to faults shall be taken into account in particular.

b) Techniques and measures listed in this table are not exhaustive. Other techniques and measures may be used, provided evidence is given to support the claimed delta β-factor.

c) If evidence can be provided that measures were taken to mitigate the impact of common cause failures other delta β-factors may be used.

Table E.2 – Techniques and measures that decrease βB-IC Technique/measure Delta

β-factor [%] Remark

1a Diverse measures to control failures in different channels

4

1b Diversity in function and measures to control failures in different channels

6

2 Testing the E/E/PE system for electromagnetic compatibility with additional safety margin not interfering the function of the E/E/PE system (for example performance criterion A)

5

3 Providing each block with its own power supply pins so that no block is supplied via the power supply of another block (for example via internal connections) and not connecting wells of different blocks inside the IC.

6 External measures have to be taken to avoid dangerous failures that might be caused by different voltages of the wells.

4 Structures that isolate and decouple physical locations

2 - 4 Useful to decouple different blocks

5 Ground pin between pin-out of different blocks 2 If not implemented, short circuit between adjacent lines of different blocks shall be carried out ...

6a High diagnostic coverage (DC ≥ 99 %) of each channel, failure detection by the technical process and achievement of safe state in adequate short time

7 May be appropriate only in exceptional case

6b Temperature sensors between blocks with permanent shut-down (internal or external) to safe state in adequate short time; low effectiveness without diagnostics

2

6c Temperature sensors between blocks with permanent shut-down (internal or external) to safe state in adequate short time; high effectiveness with diagnostics

9

6d Analysis/test of the effects of faults (for example increase of temperature). Depending on the result of the analysis/test comparison between channels inclusive fault detection and achievement of safe state in adequate short time can be required

9

6e Design of the monitoring circuit functional at the increased temperature

7

b) Techniques and measures listed in this table are not exhaustive. Other techniques and measures may be used, provided evidence is given to support the claimed delta β-factor.


ßIC = 33% + (increase ∆ßIC) – (decrease ∆ßIC) < 25%!

IEC 61508-3 SoftwareLess controversial changes

Certain topics strengthenedPre-existing software componentsToolsImproved definition of independence in the software context

More controversial subjectsProperties: More systematic deduction of the annex tablesData-driven Software-Design (Rail, Air-traffic control)Evidence for meeting the claims in the Safety Manual must be available else the element is not suitable for safety use.

No agreementObject-Oriented Software; UML techniques are, however, consideredLast minute change: Proven-in-Use for pre-existing software


IEC 61508-3 – ToolsTools

Online support tools: a software tool that can directly influence the safety-related system during its run time.

Offline support tools: a software tool that supports a phase of the software development lifecycle and that cannot directly influence the safety-related system during its run time.T1 – generates no outputs which can directly or indirectly contribute to the executable code (including data) of the safety related system,T2 – supports the test or verification of the design or executable code, where errors in the tool can fail to reveal defects but cannot directly create errors in the executable softwareT3 – generates outputs which can directly or indirectly contribute to the executable code of the safety related system


7.4.4.1 Software on-line support tools shall be treated as software belonging tothe Safety-related System.

IEC 61508-3 – Tools7.4.4.5 An assessment shall be carried out for offline support tools in classes T2and T3 to determine the level of reliance placed on the tools, and the potentialfailure mechanisms of the tools that may affect the executable software. Wheresuch failure mechanisms are identified, appropriate mitigation measures shall betaken.

7.4.4.6 For each tool in class T3, evidence shall be available that the toolconforms to its specification or manual. Evidence may be based on a suitablecombination of history of successful use in similar environments and for similarapplications, and of tool validation.

7.4.4.8 Where the conformance evidence of 7.4.4.6 is unavailable, there shallbe effective measures to control failures of the executable safety related systemthat result from faults that are attributable to the tool.

7.4.4.15 Configuration management shall ensure that the use of off-line supporttools of classes T2 and T3 to generate each baselined item is recorded. …

7.4.4.17 Configuration management shall ensure that only tools compatible witheach other and with the SRS are used.


IEC 61508-3 Annexes A+B – TablesCertain topics strengthened:

More rigorous requirements tracking


Table A.2 – Software design and development – software architecture design

Technique/Measure * Ref. SIL 1 SIL 2 SIL 3 SIL 4

Architecture and design feature

…

9 Forward traceability between the software safety requirements specification and software architecture

C.2.11 R R HR HR

10 Backward traceability between the software safety requirements specification and software architecture

C.2.11 R R HR HR

…

Forward traceability required in ALL tables A.*

Backward traceability additionally required in tables A.1, A.2, A.7

25

IEC 61508-3 Annexes A+B – TablesCertain topics strengthened:

Structural test coverage quantified


Table B.2 – Dynamic analysis and testing

Technique/Measure * Ref SIL 1 SIL 2 SIL 3 SIL 4

…

7a Structural test coverage (entry points) 100% ** C.5.8 HR HR HR HR

7b Structural test coverage (statements) 100% ** C.5.8 R HR HR HR

7c Structural test coverage (branches) 100% ** C.5.8 R R HR HR

7d Structural test coverage (conditions, MC/DC) 100% ** C.5.8 R R R HR

26

IEC 61508-3 Annexes A+B – TablesNew term: Properties – examples:

Completeness, Correctness, ConsistencyFreedom from intrinsic specification and design faultsIndependence to avoid Common Cause failuresAvoidance of what is not related to safetyClear, unambiguous documentation – trustworthy, credible Testability, repeatablePredictable, defensive, modifiable designAssessable

Problem: They are very abstractSolution: They are meant to justify the measures specified by IEC 61508-3, and helpful for people who want to justify alternative measures not specified by IEC 61508-3.


Security – Clash of CulturesSafety

Precise targets because of well understood threats

SecurityMoving targets because of new threads from malicious peopleresult in less practical guidanceApplication engineers ask, however, for more practical guidelines


Security – Clash of CulturesConsequence

IEC 61508 will wait for ISA S99IEC 61508 will not specify the requirements for the development,implementation, maintenance and/or operation of security policies or security services that may be required by the safety-related system.If the hazard analysis identified security needs, then a security threats and vulnerability analysis following ISO/IEC 13335 and IEC 62443should be undertaken and security requirements should be developed and implemented for all relevant safety lifecycle phases.


Security – Clash of CulturesISA 99ISA 99 generates many documents. The most interesting technical results are as of today Security Assurance Level 1..4 (ISA 99.03.03).the ZONE and CONDUIT concept for security (ISA 99.03.02).


Well, Success and World-wide Acceptance of IEC 61508 means each country wants to have their way accepted.

Thanks to Ron Bell and Ed Fergus and all the members for their time and effort.

Lots of stuff ?

Thank youCopyright exida.com 2007..2009

Documents

Novel Features of the 2nd Ed. of Iec 61508