Because design tools can introduce errors and verification tools can miss them, each tool is assessed before use and the result, and any qualification, recorded; only the functions actually used are assessed, and a tool used for both design and verification is assessed as a design tool unless the functions are separated. Following Figure 11-1: identify the tool (name, source, version, host; track updates and their impact); identify the process supported, limitations, outputs and known problems with justification; if the output is independently assessed (for example by verification of the item, or review or comparison with another tool) no more is needed; if used only for Level D, as a Level C verification tool, or to assess verification completion such as elemental analysis, no more is needed; if relevant history shows acceptable results in comparable use, no more is needed; otherwise establish a tool baseline and problem reporting and perform basic qualification confirming correct outputs by analysis or test; Level A or B design tools need design tool qualification by Appendix B strategies, the DO-178B/ED-12B development tool approach or other accepted means, independent of tool development; finally document the assessment, justifications and qualification data with references.
This control maps to 3 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 3 it maps to, and the evidence behind each claim, over MCP and REST.