Where several parties share responsibility, the division is documented in safety planning. The supplier or developer establishes a detailed software architecture design that selects and justifies a coherent set of techniques and measures to meet the software safety requirements at the SIL, including fault avoidance and fault tolerance strategies (the latter consistent with the hardware), with redundancy and diversity where appropriate; partitions the software into elements or subsystems, stating for each whether it was previously verified and under what conditions, whether it is safety-related, and its systematic capability; identifies all software and hardware interactions and evaluates their significance; uses an unambiguously defined notation; selects design features to protect the integrity of all data (plant I/O, communications, operator interface, maintenance and internal database data); and specifies architecture integration tests showing the architecture meets the software safety requirements at the SIL. Any knock-on change to the system's safety requirements is agreed with the system developer and documented.
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.