FENNECSystematic Capability vs SIL: Read the Certificate Carefully
A SIL 3 capable device does not make a SIL 3 safety function. Here is where systematic capability limits the claim, including the diversity exception.
)
A certificate arrives with “SIL 3” in the heading, and the architecture slide inherits the same label. In a component review, we would circle that label and ask what the certificate actually says the element can support.
The certificate tells you what the component can support, under conditions. Your claim belongs to the function: sensor, logic, final element, wiring, integration, and the work your own team did between them.
This distinction usually surfaces late because the failure-rate calculation looks fine. PFH or PFD is inside the target band, the diagnostic coverage is credible, and the architecture has the expected redundancy. Then somebody asks for the systematic capability of each element.
The certificate covers one part of the claim
Random hardware failure has a rate because contacts wear, sensors drift, and power supplies fail. Architecture and diagnostics can reduce the probability that one of those failures defeats the safety function.
A systematic fault was designed in. Perhaps the requirement omitted a mode, the software mishandles a particular transition, or the integration assumes a sensor condition that is not true in service. There is no useful random rate for a fault present in every unit from day one.
IEC 61508 handles that second problem through evidence about how the element was developed. Systematic capability runs from SC1 to SC4. An SC3 element was developed with methods and controls intended to support a SIL 3 systematic integrity claim, subject to its certificate and conditions of use.
That is why a good PFH result cannot repair an SC shortfall. The two pieces answer different questions.
The exception people miss
The usual shorthand says that the lowest SC in the chain caps the function. It is a safe starting rule, but it leaves out an important route in IEC 61508-2.
Suppose a subsystem uses two SC2 elements. If they are copies of the same device, running the same design and exposed to the same systematic fault, adding the second channel improves the random hardware result while leaving the systematic limitation largely where it was. The standard does not forbid a claim here, but it puts the burden on you: the argument has to show that systematic faults are actually avoided and controlled, and a shared design gives that argument very little to stand on.
Change the example to two elements using diverse technology or design, with sufficient independence demonstrated by the team. Under the conditions in IEC 61508-2:2010, Clause 7.4.3.3, the subsystem may support SC(N+1). Two diverse, independent SC2 elements can therefore support an SC3 subsystem claim.
Either way the ceiling is one level. A subsystem never claims more than SC(N+1) over its elements, and the uplift is never automatic. A shared specification error, common software lineage, common environmental assumption, or common integration mistake can defeat the argument, which is why diversity carries it more easily than duplication.
What to record before choosing the architecture
For every safety function, put the claimed SC beside each element and keep the conditions of use with it. Proof-test intervals, diagnostics, environmental limits, configuration rules, and integration assumptions are part of what the certificate means. Filing the certificate without those pages is how an apparently qualified component gets used outside its qualification.
The project also owns the systematic integrity of its integration. Supplier certificates cannot show that your requirement was complete, that your logic implements it correctly, or that your verification challenged the right boundary conditions.
We would resolve this while the architecture is still a diagram. If the claim needs SIL 3 and one proposed element supports SC2, the team can select another element or build a defensible diverse subsystem. At assessment, those options have turned into hardware rework, repeated verification, or a reduced claim.
What we would expect in the review file
ASAP keeps the component evidence beside the hazard and the project records that used it. A reviewer can see the requirement, architecture decision, calculation, verification result, and applicable conditions without treating SC as one unexplained number in a report.
The methodology was developed over five years inside Amazon Robotics and supports a large autonomous mobile robot fleet in continuous operation. That history does not raise a component's SC. It explains why versioned conditions of use and integration evidence need to survive long after the design review where they were first discussed.
If the only systematic evidence in your file is a folder of component certificates, Fennec can help trace what the function actually supports.
Frequently asked questions
What is systematic capability in IEC 61508?
Systematic capability, rated SC1 through SC4, addresses confidence that an element's development controlled systematic faults to a level consistent with a SIL claim. It is about development rigor, not random failure frequency.
How is systematic capability different from SIL?
SIL belongs to a safety function. Systematic capability belongs to an element or subsystem used in that function. A valid SIL claim needs both the random hardware calculation and the systematic argument.
Can I use an SC2 device in a SIL 3 safety function?
A single SC2 element does not support SIL 3 by itself. IEC 61508-2:2010, Clause 7.4.3.3 permits a subsystem claim of at most SC(N+1) when the stated conditions are met. Diverse, sufficiently independent elements are the stronger route. Identical redundancy is not ruled out, but it carries a heavier burden of justification that systematic faults are avoided and controlled, because a common fault defeats both channels at once.
Does a SIL 3 certificate on a component make my function SIL 3?
No. The certificate describes what the component can support under stated conditions. The function includes sensing, logic, final elements, integration, and the project's own development evidence.
Does redundancy improve systematic capability?
Not on its own. Under IEC 61508-2:2010, Clause 7.4.3.3 a subsystem can claim at most one level above its elements, and only where the argument for avoiding and controlling systematic faults holds. Diversity and demonstrated independence make that argument far easier to sustain than identical duplication.
)