Supporting the SSA, the hardware safety assessment fixes the assurance level per function and helps choose design assurance strategies. One level and strategy may cover a whole item, or separate functional failure paths (FFPs) may carry different levels or strategies, justified by FFPA. Where functions of different levels share an item, either assure the whole item at the highest level, or assure each function at its own level provided its function, interfaces and shared resources are protected from lower-level functions, with shared resources at the highest level. Safety assessment and design, iterated, should establish the derived hardware safety requirements and confirm both allocated and derived safety requirements are met; derived safety requirements cover the architecture, circuits and components, and guard against anomalous behaviour, such as redundancy, separation or electrical isolation, dissimilarity, monitoring, protection or reconfiguration, allowed random and latent failure rates, usage or installation limits, and upset prevention and recovery. Design assurance and safety assessment jointly fix the means of compliance and level per function and decide when assurance is adequate. A higher level may be chosen voluntarily, for example for reuse. Methods include FTA, common mode analysis, FMEA and statistical reliability analysis.
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.