It is shown that a tool failure cannot corrupt the output of the integrated toolset in a way that harms safety and escapes the technical or organisational checks applied outside the tool. Software tools are classified T1 (output cannot contribute to an error: editors), T2 (can fail to reveal a defect: test tools, static analysers) or T3 (can introduce an error into the executable: compilers, code generators); every tool is selected as part of a consistent set, has a manual, is under configuration management with each version identified, and T2 and T3 tools carry evidence that their output is correct or that failures in their output are detected: for T3 a validation report or the evidence of a suitable history of use, and for a new version of a T2 or T3 tool renewed evidence (6.7.4.1-11). The programming language is chosen for the SIL with a translator or compiler that has a certificate of validation, an assessment report of fitness for purpose or a redundant signature control detecting translation errors; the language contains features that help reveal programming errors and supports the design method, with any alternative justified in the architecture specification or SQAP; coding standards are developed and referenced in the SQAP; automated test tools and integrated development environments are used where applicable, taking into account what the verifier and validator need (2001 10.4.7 to 10.4.11).
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.