If the safety-related software requirements were already specified under Part 2 they need not be repeated. Otherwise they are derived from the safety system's specified safety requirements and from safety planning, and made available to the software developer; they must be detailed enough for design and implementation to reach the required integrity (including any independence requirement) and for functional safety to be assessed. Independence is addressed by a common cause failure analysis, with defensive measures where credible failure mechanisms are found. The software developer evaluates the input for adequacy, considering safety functions, system configuration or architecture, hardware integrity requirements, software systematic capability requirements, capacity and response time, and equipment and operator interfaces including foreseeable misuse. The specification details every relevant operating mode (of the EUC, the system and connected equipment) where not already defined, and documents any safety-related constraints between hardware and software. As far as the hardware architecture requires, it considers software self-monitoring, monitoring of hardware, sensors and actuators, online periodic testing of safety functions, testability while the EUC operates, and software to execute proof and diagnostic tests. Non-safety functions are clearly identified. It states product safety properties, not project ones, covering as appropriate: functions to reach or hold a safe state; detection, annunciation and handling of faults in the programmable hardware, in sensors and actuators, and in the software itself; online and offline periodic testing; safe modification of the PE system; interfaces to non-safety functions; capacity and response time; software to PE interfaces; and safety communications; plus the SIL of each function and independence between functions. Configuration data expressing requirements must be consistent with system safety requirements, stated as permitted ranges and authorised combinations, and compatible with the underlying software. Data interfaces with external systems consider consistent data definitions, values that are invalid, out of range or late, response time and throughput at maximum load, execution time bounds (best and worst case), deadlock, and storage overflow and underflow. Operational parameters are protected against values that are invalid, out of range or late, unauthorised change and corruption.
This control maps to 2 controls across 2 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.