How to identify tools according to ISO 26262

The obvious trend of increasingly complex embedded software and the increasing use of software for security critical applications. In this case, the ISO 26262 standard has played an important role in providing recommendations for the development process of embedded systems. In addition to the process, ISO 26262 also discusses the tools used for developing and testing systems, as well as the qualifications of these tools.
But in reality, not all tools require tool identification. This article will introduce how to determine whether a tool needs to be qualified and how to perform ISO 26262 tool qualification. I will also provide some examples in the context of model-based software development and testing.
Do tools need to be qualified?
The answer to this question depends on the use case and project specific workflow. It is possible that specific tools need to be identified in one project, while tool identification is not required in another project.
The main question is: "Will the tool be responsible for errors in the final product (=embedded software/system)?" This includes "the possibility that a faulty software tool may... be unable to detect safety related errors in the project..." (ISO 26262-8, 11.2). If the answer is yes, then we need to have a high level of confidence in the tool, so we need tool qualifications.
Therefore, whether a tool needs to be evaluated actually depends on our confidence in this specific tool. ISO 26262 defines three levels of tool confidence. For the lowest level (TCL1), the actual path to achieving this answer largely depends on use case analysis