Responsibility for conformance with 7.4 (platform supplier, application developer or both) is settled during safety planning. For the SIL and technical needs, the design method supports abstraction, modularity and complexity control; expression of functionality, information flow, sequencing and timing, timing constraints, concurrency and shared-resource access, data structures, design assumptions and dependencies, exception handling, and pre-conditions, post-conditions and invariants; several structural and behavioural views; comprehension; and verification and validation. Testability and safe modification are designed in, aided by modularity, information hiding and encapsulation; notations are unambiguously defined; the safety-related part is kept as simple as practicable; and control-flow and data-flow self-monitoring matched to the SIL is included with suitable action on failure. Software implementing safety and non-safety functions is all safety-related unless design measures stop non-safety failures affecting safety functions; software with functions of different SILs takes the highest SIL unless independence is shown spatially and temporally or violations are controlled, with the justification documented. An element whose systematic capability is below the function's SIL is combined with others to reach it, under the Part 2, 7.4.3 combination rules. Reused pre-existing software must follow Route 1S (compliant development), 2S (proven in use) or 3S (assessment of non-compliant development) and come with a safety manual. Route 3S needs: a software safety requirements spec (SSRS) for the new use as precise as for a new element; justification that the desired properties of the referenced subclauses were considered; design documented well enough to show compliance; evidence covering integration with the hardware; systematic, documented verification and validation of all design and code; evidence that unwanted functions cannot stop the system meeting its safety requirements; identification and mitigation of all credible failure mechanisms; planning that fixes the element, run-time and build configuration; and validity limited to uses respecting the safety manual's assumptions. These rules extend to data and data generation languages: application design matched to configurability, measures against faults in producing, loading and changing configuration data, data structures that are consistent, complete, self-consistent and protected against change or corruption, and a documented configuration process.
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.