Safety-specific analysis extends FFPA into selected circuits and components to derive and validate safety requirements on their internal operation, on the basis that a latent design error affects outputs only when particular stimuli expose it. Using user guide or internal data, the circuit and component functions contributing to Level A and B FFPs are identified from their actual usage, then F-FMEA determines the safety-sensitive, unmitigated attributes and the anomalous behaviours that would form a Level A or B FFP. Verification criteria: identify the relevant input space, set output pass/fail criteria from those attributes and behaviours, and build equivalence classes covering the input space; identify observation and stimulation means; specify test environments that cover error sources and interdependencies, testing at the highest feasible integration level; and cover arithmetic, key logic decisions, state transitions, timing and real-time behaviour. Deficiencies are resolved by design change, added architectural mitigation or added tests. Data identifies the circuits and components, their FFPs, any partial mitigation, safety-sensitive functions, attributes and anomalous behaviours, verification conditions for internal functions and for input dependencies and output behaviours, procedures and results, and traceability from procedures and conditions to the analysis. It suits COTS and custom parts alike and can complete partial architectural mitigation.
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.