There’s a lot of confusion about Systematic Safety Integrity in new IEC61511. We are starting to see devices certified for SIS applications to have a rated Systematic Capability (SC) of 2. What does this mean? Is this yet another hurdle I need to jump over to meet a SIL target? Let’s shine some light on Systematic Capability and decipher fact from fiction.
When the umbrella standard IEC 61508 was updated in 2010, systematic integrity got a lot of attention. This wasn’t a bad idea either. We all know that SIL is driven by Probability of Failure on Demand (PFD) and that relates to hardware failures that are considered random. what a bout failures that are built into the system — usually through human error — that don’t occur random basis. these are called Systematic Failures and the 2010 IEC 61508 standard says a lot more than it did in its 1998 first edition.
- Systematic Failure: a failure related to a pre-existing fault, which consistently occurs under particular conditions, and which can only be eliminated by removing the fault by a modification of the design, manufacturing process, operating procedures, documentation or other relevant factors.A classic systematic failure is a software “bug”, that repeats itself in every copy of the software under every set of identical circumstances. Systematic failures are generally caused by human errors either in the SIS hardware or software implementation.
As automation engineers, we should be concerned about eliminating systematic failures from the SIS we built and its component hardware. Vendors have a duty here, as well as engineering contractors, and End-Users. When the IEC 61511 committee was debating the content of the 2nd Edition of the standard for the process industries (subsequently released in 2016), this was a hot topic. You see IEC 61508 had introduced the concept of SC as a measure (expressed on a scale of SC 1 to SC 4) of the confidence that the systematic safety integrity of a device meets the requirements of the specified SIL. And now hardware vendors were touting their new devices as “SC2 Certified”. What does that meant to the integrators and the End-Users of the device? What if I use devices that don’t have any SC certification ? The most important clause in IEC61511 on this is “A qualitative approach is preferred for systematic failures“, and depending on who you ask, this is either a minor shift or major deviation from the parent standard IEC 61508. To leave no ambiguity, 61511 further states “Systematic safety integrity cannot usually be quantified (as distinct from hardware safety integrity).” The process industries standard 61511 has got it right on this account.
Safety Integrity is the goal of Functional Safety… its a multifaceted concept.
So why all the noise about SC2 certified devices? Listen, this is deep water we are about to wade into. So, if you stop here and click away, I understand. Just remember, steps should always be taken to avoid systematic failures, and qualitative methods using engineering judgment are critical to this. You are NOT required under IEC 61508 or IEC61511 to deal with math (yes math!) using SC numbers.
The term “Systematic Capability” or “SC” is used only as a definition in IEC61511 and then NO WHERE ELSE as a normative requirement.
The words “systematic safety integrity” “systematic failure” and “systematic fault” are used everywhere! the concept is important! but SC is almost relegated to the footnotes.
What does Systematic Capability even mean? its a confidence measure, like SIL , but distinct and different. It is an attribute of a device, not a Safety Instrumented Function.
- Systematic Capability: a measure (expressed on a scale of SC 1 to SC 4) of the confidence that the systematic safety integrity of a device meets the requirements of the specified SIL, in respect of the specified safety function, when the device is applied in accordance with the instructions specified in the device safety manual.
Vendor-specified SC measures the confidence we should have that the vendor’s device has incorporated measures to avoid and control systematic failures. That in no way is the end of the line for systematic failures. Even when we comply with the vendor’s safety manual, many opportunities exist to introduce systematic failures when End-Users integrate that device into a SIS.
How would I have confidence of SC 2 or SC 3 to achieve higher safety integrity objectives?
IEC61508-2 2010 Edition, Clause 7.4.3
A device with systematic capability SC N used in an architecture where (the standard says…)a systematic fault of that element does not cause a failure of the specified safety function but does so only in combination with a second systematic fault of another element of systematic capability SC N (let’s just say … fault tolerant 1oo2 or 2oo3 architecture), the systematic capability in this fault-tolerant architecture is SC (N + 1) provided that sufficient independence exists between the two elements.
- Sufficient independence: in the design between elements and in the application of elements, it 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.
NOTE 1 For systematic capability, with respect to hardware design, realization, operation and maintenance, possible approaches to the achievement of sufficient independence include:
– functional diversity: use of different approaches to achieve the same results;
– diverse technologies: use of different types of equipment to achieve the same results);
– common parts/services: ensuring that there are no common parts or services or support systems (for example power supplies) whose failure could result in a dangerous mode of failure of all systems;
– common procedures: ensuring that there are no common operational, maintenance or test procedures.
So even though we know systematic failures can defeat single devices as easily as redundant devices, the 61508 standard seems to prefer fault-tolerant devices with diversity. You will likely hear experts on this topic with a vendor bias claim systematic failures are “unlikely” when we simply use diverse devices. i personally disagree, but let’s follow that line-of-thinking for a moment.
Using Route 1s, which is achieved through means to Avoidance and Control of Systematic Failures.
- Fault Tolerant (1oo2 or 2oo3) voting between diverse devices achieves SC (N+1); however, Fault Tolerance between identical devices only achieves SC (N). How can I reach SIL 2 with identical redundancy ?
- Under Route 1s, the way to achieve SC N+1 out of identical devices Fault Tolerance (1oo2 or 2oo3) is to justify the existence of adequate means to “avoid” systematic (clause 7.4.6) and “control” systematic (clause 7.4.7) faults. Those refer to IEC 61508-1 Annex A and Annex B for techniques that are Mandatory, or Highly Recommended, or Recommended in order to avoid systematic faults with sufficient degree of confidence to claim a specified SIL. Vendors with an “SC 2” number on their certificate means they have been assessed with respect to these techniques in the 61508 standard.
- Alternatively, use Route 2s, and we claim proven-in-use for SC (N+1) of identical devices in Fault Tolerant (1oo2 or 2oo3) architecture.Importantly:
- Recognize that “Safety Integrity” includes both “hardware…” and “systematic…”, however, do not conflate the terms “Safety Integrity Level” and “Systematic Capability” and “SC”.
- “Systematic Capability” and “SC” use the same integer number scale but is the measure of confidence in achieving “Systematic Safety Integrity”. Once we arrive at the words “Systematic Safety Integrity”, the standards allows “qualitative techniques and judgements should be made with respect to the precautions to achieve systematic safety integrity”. It is treacherous to substitute vendor SC as a substitute for techniques & judgement in the 61511 lifecycle.
- “Systematic Capability” and “SC” do not appear in IEC 61508 Annex A or Annex B. Those deal with avoidance of and control of systematic failures in different ways to claim a desired “safety integrity level”. All of these measures are qualitative.
I could go into the range of measures and techniques to avoid and control systematic failures. Its not surprising that — because human error is the underlying cause — the solutions are inherent to the avoiding a single human error from propagating through to the realized system. These include:
- Rigorous verification and validation of hardware & software implementation results in a high degree of “diagnostic coverage” of human errors that could manifest as systematic failures.
- Avoiding complexity and keeping a “bright line of separation” between devices (no shared process connections, segregation of I/O) and systems (software modularization, no ability to write across systems, etc.).
Kenexis Vertigo software for SIS lifecycle management will allow the user the option of using vendor-driven Systematic Capability (SC) numbers, but this is not the default. Again, we rely on the safety lifecycle itself — with its many validation and verification steps — to root out systematic failures.
If you have questions or need further assistance with this topic, please contact Kenexis.