Every safety-related function meets its TFFR in the event of a random fault, and systems at SIL 3 and SIL 4 stay safe under any single hazardous random hardware fault recognised as possible (faults of demonstrated negligible effect may be ignored). Fail-safety is achieved by composite fail-safety (each function performed by at least two independent items, non-restrictive action only when the required number agree, and a hazardous fault in either item detected and negated before a coincident fault in another in relation to the TFFR, dormant faults found by online periodic monitoring), reactive fail-safety (one item performs the function with rapid detection and negation by an independent checking function, for example encoding, multiple computation and comparison or continual testing) or inherent fail-safety (one item whose credible failure modes are all non-hazardous, each credible failure mode and relevant combination identified per Annex C and shown non-hazardous by test, justification or simulation, any incredible failure mode justified by the Annex C procedure). Whichever technique, assurance that no single random failure mode of a hardware component is hazardous is demonstrated by structured analysis: a top-down method such as fault tree analysis supported where necessary by FMEA, qualitative, and quantitative as well where credible data are available, failure rates based on field data where possible and the apportionment of a component's failure rate between its failure modes justified.
This control maps to 2 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 2 it maps to, and the evidence behind each claim, over MCP and REST.