The first ISO 26262 certified blog post!

With ISO 26262 getting so much attention it is little wonder that ISO terms like Qualification and Tool Confidence Level (TCL) and related non-ISO terms such as certification, are becoming the celebrities on tool vendors commercials. Though the adoption of ISO and the growing popularity of these terms is a positive thing overall, experience shows that overused terminology can quickly lose its meaning, or find itself attached to objects whose essence represents the exact opposite. So, here’s a short reminder of the basics that you can always refer back to when your head starts spinning.

To spice this somewhat dull topic up, let’s assume a user would like to use this very blog post in an ISO 26262 flow, ignoring the fact that it is not a software tool. The first step that needs to be taken is to assess (1) the likelihood that this post will insert a bug or prevent the detection of a bug in the safety critical parts of the design and (2) the likelihood that an error in this post will be detected. Since this post, like many other tools used in a typical flow such as editors or browsers has no chance of directly impacting the hardware or software of the product, we can say its Tool Impact (TI) is low. Also, it is highly likely that if there’s an error in this post, the user will detect it when reading other sources or the standard itself. Hence, the probability of detection (TD) is pretty high. Putting TI and TD together we get the Tool Confidence Level (TCL), which in our case will be the highest, TCL1.

So can I go out and claim that this blog post is TCL1 already? Though some marketing guys might do just that, this is only half true, since according to ISO the real Tool Confidence Level assessment can only take place in the context of a specific design flow. If, for example, some of the readers of this post will trust it so much that they don’t bother double-checking it against the standard, its impact (TI) might go up hence bringing the TCL level down. To take a more common example, if you’re stretching a formal or logic simulator tool with the newest and most rarely used options, you will be bringing your tool confidence down. Just like a hammer would be totally safe in the hands of a skilled workman and unsafe in the hand of a child, a tool confidence level can only be determined in the context in which the tool is employed.

How about if I say this blog post is qualified? Is that ok? Once again, the answer is no, but this time an underlined bold NO. The reason why tool vendors like TCL1 so much is exactly because a TCL1 graded tool is basically exempt from undergoing the long, laborious and expensive process called tool qualification. ISO describes 4 different options for qualifying a software tool, but trust me, fun is not one of them. They all require significant changes in the way you develop or support your product, or extensive field research. If I say that this blog post is TCL1 and qualified, it is pretty much like trying to eat the cake and have it too.

Ok, can I at least say it is certified? Certification basically means that a 3^rd party is asked to assess any claim I’m making, be it that this blog post is TCL1, or fully qualified. Like most ISO standards, ISO 26262 is mute about the certification process or about who the 3^rd party needs to be, though ISO as a whole provides some guidelines that can be found here.  Though certification has marketing value (you’re reading this post aren’t you?) its real life value remains contested as the testing/certification bodies involved are usually somewhat disconnected from the way tools are really employed in an IC design flow. If you have any insights about the value that certification, qualification or a TCL1 claim is able to bring to your flow, I would love to hear your comments.