The specification holds design requirements for the safety functions and for safety integrity. For each safety function it details the hardware and software needed: requirements for subsystems and their hardware and software elements and for their integration; throughput to meet response times; accuracy and stability of measurement and control; system and operator interfaces; interfaces with other systems inside or outside the EUC; all modes of behaviour, especially failure behaviour and the required response; the significance of hardware and software interactions and any constraints between them; limiting conditions such as timing or common cause constraints; and start-up and restart requirements. For integrity it details the subsystem architectures needed to meet the architectural constraints (7.4.4); reliability modelling parameters such as proof test frequency for every hardware element; actions on detection of a dangerous failure by diagnostics; facilities for proof testing; equipment capability for environmental extremes across manufacture, storage, transport, test, installation, commissioning, operation and maintenance; required electromagnetic immunity levels; and quality assurance and control measures. The specification is completed in detail as design progresses and updated after modification; techniques and measures from Table B.1 are used to avoid mistakes while writing it; and its implications for the architecture are considered.
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.