Aim: evidence that a tool failure cannot corrupt the combined toolset output in a safety-relevant way that escapes checks outside the tool; tools fall into classes T1, T2 and T3 (3.1). A tool replacing a manual step can be justified by the same process steps the manual output would get, or by an alternative argument that does not lower the integrity level. Tools that become part of the deployed system are treated as software, not under 6.7. Tools are chosen as part of development (transformation tools such as compilers, linkers and code generators; verification tools such as static analysers, coverage monitors, provers, simulators and model checkers; diagnostic, infrastructure, version control and application data tools), should interoperate so outputs feed the next tool automatically, must suit the application, and their availability over the software's whole life is considered. For SIL 1 to 4, choosing T2 and T3 tools is justified by identifying failures the tool could inject into its output and how each is prevented or caught, and each such tool has a specification or manual defining its behaviour and constraints. For every T3 tool at SIL 1 to 4, evidence shows its output meets the output specification or that output failures are caught, using one or more of: a checked and documented history of successful use; tool validation; tool diversity (two tools compared, a reverse tool regenerating the input, or an independent checker working on different principles); compliance with integrity levels derived from a risk analysis of the process; or other methods such as verifying the output (a note shows how an untrusted compiler can be justified by testing, checks and analysis of the object code with no recompilation afterwards). Tool validation records the activities, manual version, functions validated, equipment, pass or failure reasons, test cases and results, and discrepancies. For T3 tools doing automatic code generation or translation, suitability for safety-related development is judged when tools are selected. Configuration management allows only justified versions of T2 and T3 tools, and each new version is justified (possibly on earlier evidence if functional differences do not affect the toolset and significant new faults are unlikely). Table 1 maps each class to the applicable requirements, with lighter duties at Basic Integrity.
This control maps to 9 controls across 4 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 9 it maps to, and the evidence behind each claim, over MCP and REST.