Background<\/h2>\n\n\n\n
ISO 26262 dictates that tools used in the development of safety-critical electronics be assessed, and it guides this analysis by defining three terms:<\/p>\n\n\n\n The classification of a tool starts by first deciding on TI and TD for the tool under analysis. The setting of TI and TD ultimately determines the TCL for the tool based on the table below, found in ISO 26262-8:2018 Clause 11.4.5. It is important to note that TCL determination is not based only on the tool but also on its use in the context of the process step for the end product.<\/p>\n\n\n\n FURTHER QUALIFICATION METHODS ARE REQUIRED when TCL is determined to be TCL2 or TCL3. The ISO 26262 standard provides four methods for performing tool qualification (ISO 26262-8:2018 Clause 11.4.6). The standard also indicates the suitability of each method based on the ASIL target.<\/p>\n\n\n The determination of TCL is required for software tools purchased from an EDA vendor and tools developed internally to support the development of the product. <\/p>\n\n\n\n Now that we have covered some of the fundamental concepts, let’s discuss areas where misconceptions and misinformation often lead to confusion among practitioners.<\/p>\n\n\n\n You may come across language that states a tool has achieved TCL# certification (i.e., Achieved TCL2 certification). This is confusing and often misleading because TCL is not something that is achieved. TCL is a classification of the tool by its function performed in the context of the project activities. As shown above, this classification is based on TI and TD. During a tool suitability assessment, the tool is classified, and subsequent qualified. It is this classification and qualification method that is certified, as previously shown in Figure-X above.<\/p>\n\n\n\n Often, you\u2019ll see claims that TCL2 is better than TCL1. The common misconception is that because TCL2 requires additional rigor, TCL2 is considered safer than TCL1. It is important to remember that the setting of TCL is simply based on a classification of the tool, established through the evaluation of TI and TD. TI2 is a typical result in EDA tools because of their usage in the development lifecycle. Synthesizers, Simulators, BIST Insertion, Physical placement, verification, etc\u2026 are all TI2 because of the impact they could potentially have on the end product. TD is subjective, and we believe it\u2019s challenging for an EDA provider to claim TD1 without providing sufficient rationale and evidence supporting this claim.<\/p>\n\n\n\n Often hidden in the text of qualification reports are claims that current tool versions and all future versions<\/strong> are covered under the certification. Logically, this is a falsehood. Ask yourself, is there some future product one can claim is certified because one certified a past variant? Software tools are no different than any other product in that they change and evolve. This includes new use cases, new features, new processes, and changes to other aspects of tool development (issue management, regression systems, etc\u2026). Minimally, these changes require a re-classification of the rationale supporting the qualification method, and that classification may result in the need to recertify.<\/p>\n\n\n\n Are you assuming responsibility for all of the tools in your toolchain? Does the qualification report you receive from your vendor provide the maximum value, or are there disguised risks? Does your vendor take ownership and responsibility for the validation evidence? All of these are great questions to ask! There are two hidden costs to mention here.<\/p>\n\n\n\n As stated earlier, the standard defines four methods for tool qualification. Tool vendors providing certifications will choose which methods to adhere to. Specific methods aren\u2019t suitable for the higher ASIL targets. Note that in ISO 26262:2018, method \u20181d\u2019 is no longer highly recommended for tools classified as TCL2.<\/em><\/p>\n\n\n\n Simply put, not all tool vendors are equal. Some vendors will add disclaimer clauses stating the product team is responsible for confirming all evidence, and communicating the evidence is not the vendor\u2019s responsibility.<\/p>\n\n\n\n Often, EDA vendors will certify tools in a prescribed design flow and toolchain. Deploying design flows as a means of independent assessment is a widely used and acceptable tactic to validate tool behavior. By deploying checks and balances in the design flow, one can reasonably set the TCL as TCL1, thereby avoiding any need for tool qualification.<\/p>\n\n\n\n Before accepting this wholesale, it is important to ask a couple of questions:<\/p>\n\n\n\n If the answer is no, it\u2019s essential to understand the impact, for even the slightest difference will void the certification. This will result in additional cost in re-validating the use cases to your design flow.<\/p>\n\n\n\n After careful analysis, we concluded that \u20181c\u2019 is the best approach as it delivers the most value to our customers. <\/p>\n\n\n When evaluating which method to pursue and have certified, we concluded that \u20181d\u2019 provides an indirect method of providing confidence. What I mean is, if a process is in place and that process is audited to ensure it complies with a standard, there is no guarantee a process was followed. Earlier in my career as a Quality Engineer, the number one reason for defects in a product was because people did not follow the process. If people do not always follow the process, how can that process provide the highest confidence in a tool? In the end, \u201c1c\u201d provides a direct method for providing confidence in a software tool and is also \u201chighly recommended\u201d for the most stringent ASIL targets.<\/p>\n\n\n\n Tool qualification is often murky, with a lot of information and claims being made. Make sure you understand your design tool flow and how 3rd<\/sup> party certifications apply.\u00a0Unfortunately, that may require you to bring out your inner Sherlock Holmes. Hopefully, the information provided here gives you a couple of key things to look out for when tackling tool qualification. Please reach out if you\u2019d like to learn more about the Siemens approach, the collateral we provide, and the products currently ISO 26262 certified.<\/p>\n\n\n\nISO 26262 Term<\/td> Definition<\/td><\/tr> Tool Impact (TI):<\/td> This is an evaluation of the potential of a tool to introduce or fail to detect errors. The standard defines:
TI1<\/strong>: Selected when there is an argument that there is no such possibility.
TI2<\/strong>: All other cases. Practically speaking, many EDA tool use cases will be TI2.<\/td><\/tr>Tool Detection (TD)<\/td> This is an evaluation of the confidence that the tool will prevent the malfunctioning of a software tool, and the standard defines:
TD1<\/strong>: High confidence that a malfunction will be prevented or detected.
TD2<\/strong>: Medium confidence that a malfunction will be prevented or detected.
TD3<\/strong>: All other cases <\/td><\/tr>Tool Confidence Level (TCL)<\/td> An establishment of tool confidence based on TI and TD and the standard defines:
TCL1<\/strong>: High level of confidence. No further qualification methods are required.
TCL2<\/strong>: Medium level of confidence. Further qualification methods are required.
TCL3<\/strong>: Low level of confidence. Further qualification methods are required.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2022\/04\/tcl_tool_qual_table.png\")
<\/figure>\n<\/figure>\n\n\n\n![\"ISO](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2022\/04\/tcl_tool_assess2-1024x667.png\")
<\/figure><\/div>\n\n\nClearing the fog<\/h2>\n\n\n\n
Statements regarding the \u201cAchievement of TCL#\u201d<\/h3>\n\n\n\n
Best Practice:<\/em><\/strong> When evaluating a purchased software tool, focus on the qualification method and determine if the method is a highly recommended technique for your ASIL target. If no method is applied because the tool was evaluated as TCL1, review the rationale behind the TI, TD, and TCL and confirm the rationale conforms to your development process.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n TCL# is better than TCL#<\/h3>\n\n\n\n
Best Practice:<\/em><\/strong> Don\u2019t believe one TCL is better than another TCL. When evaluating a purchased software tool, identify the TCL of the tool and the rationale behind the TI and TD classification match your tool use case. If a tool is declared TCL2\/3, pay close attention to the qualification method deployed to ensure that method is suitable for your ASIL target.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Certification of future versions<\/h3>\n\n\n\n
Best Practice:<\/em><\/strong> When evaluating 3rd<\/sup> party vendor reports, pay close attention to claims of future software versions covered.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The hidden cost of ownership<\/h3>\n\n\n\n
The qualification method<\/h4>\n\n\n\n
Best Practice:<\/em><\/strong> Review which method was followed and whether that method is highly recommended based on your ASIL target. This would also be an excellent time to evaluate future projects and whether there is an expected evolution to a higher ASIL in a future product variant (i.e., ASIL-B -> ASIL-D). If ASIL-D is on the horizon, it makes sense to ensure your design flow is future-proofed.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Who is accepting liability?<\/h4>\n\n\n\n
Best Practice:<\/em><\/strong> Review the certification work products for disclaimers that absolve the vendor of responsibility or statements passing the burden of validating the evidence. If your vendor evades responsibility, understand the impact this may have on your team if re-validation of your design flow and toolchain is required. Additionally, verify the vendor is maintaining and keeping this evidence for 20 years past the release date. <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The nuances in the certification of flows<\/h3>\n\n\n\n
\n
Best Practice:<\/em><\/strong> When evaluating 3rd<\/sup> party vendor reports, pay close attention to requirements around the usage of specific tools in a prescribed flow. When flows are used as part of a certification, look for flows that allow flexibility in the tools used and their configurations.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The Siemens Approach to Tool Qualification<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2022\/04\/tcl_siemens_approach-600x190.png\")
<\/figure><\/div>\n\n\nWhy \u20181c\u2019?<\/h3>\n\n\n\n
Other key points:<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2022\/04\/siemens_sfty_tool_pkg-600x425.png\")
<\/figure><\/div>\n\n\nConclusion<\/h2>\n\n\n\n
Other Topics<\/h2>\n\n\n\n