The system is implemented to the design requirements specification. Every subsystem and element used by a safety function is identified and documented as safety-related. For each, the available information covers its functional specification, application instructions and constraints to prevent systematic failures, its systematic capability, its hardware and software configuration identification for configuration management, and evidence it was verified against its functional requirements and systematic capability. For elements liable to random hardware failure it also covers failure modes undetected and detected by internal or external diagnostics with a failure rate for each under stated conditions, environmental and lifetime limits that keep those rates valid, proof test and maintenance needs, diagnostic coverage per Annex C and diagnostic test interval for internally detected modes, the failure rate of the diagnostics, information for deriving MRT, everything needed to derive the SFF including type A or B classification, and the element's fault tolerance. Failure rates come from an FMEA using recognised industry failure data or from previous use in a similar environment. Suppliers claiming compliance supply a compliant-item safety manual per Annex D and document a justification for everything in it.
This control maps to 1 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 1 it maps to, and the evidence behind each claim, over MCP and REST.