An architecture is developed that achieves the software requirements at the SIL, and how much the software's interactions with the hardware matter is identified and evaluated. The software architecture specification is established by the supplier, considers the feasibility of achieving the requirements at the SIL, identifies, evaluates and details the significant hardware/software interactions (the preliminary ones already in the system safety requirements per EN 50126 and EN 50129), identifies all software components and for each whether it is new, existing or proprietary, previously validated and under what conditions, and its SIL, minimises the safety part of the application, treats components of different SIL at the highest level unless independence is evidenced, is complete, clear, exact, unambiguous, verifiable, testable, maintainable, achievable and traceable to the requirements, justifies the balance between fault avoidance and fault handling and that the techniques chosen (Table A.3, with its approved combinations) satisfy the requirements at the SIL; the use of COTS and previously developed software is restricted by SIL (at SIL 1 and 2 included in validation testing; at SIL 3 and 4 also a failure analysis, a protection strategy that is itself validated, error logs, and only the necessary functions used), and existing verified modules are reused where possible (7.3.4.1-17). A software interface specification defines every interface, mandatory at every SIL at the outer boundary of the whole software (7.3.4.18 and 7.3.4.19). The software design specification describes the decomposition into components traced to the architecture with their SIL, the interfaces to the environment and between components, data structures, partitioning of requirements, main algorithms and sequencing and diagrams, keeping size and complexity to a minimum with modularity, information hiding and encapsulation for maintainability (7.3.4.20-24; Table A.4); coding standards are chosen (7.3.4.25 to 7.3.4.28; Table A.12); the software integration test specification and the software/hardware integration test specification are written (7.3.4.29-39; Table A.5); all outputs are verified in the verification report on architecture and design for adequacy against the requirements, consistency and completeness, the test specifications as a set of test cases, and internal consistency (7.3.4.40-43).
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.