The system safety requirements spec (SRS) is derived from the 7.6 allocation plus all relevant application information and is handed to whoever develops the safety system. It holds the safety functions with their SILs, stated so the specification is clear and precise, free of ambiguity, verifiable, testable, maintainable and feasible, understandable to those using it at any lifecycle stage, and expressed in natural or formal language, or in diagram form (logic, sequencing, cause and effect) with each safety function defined individually. The functions part describes every safety function in enough detail for design, how a safe state is reached or kept, whether continuous control is needed and for how long, and the demand mode; response times; system and operator interfaces; all functional safety information that may affect design; interfaces with other systems; all EUC operating modes; and all required behaviours including failure behaviour and the response to failure (alarms, automatic shutdown). The integrity part holds the SIL and, where needed, the target failure measure per function; the demand mode; duty cycle and lifetime; requirements and facilities for proof testing; environmental extremes across manufacture, storage, transport, test, installation, commissioning, operation and maintenance; electromagnetic immunity limits; and constraints arising from common cause failure.
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.