By Joe Drzewiecki, associate director of development tools, and Steve Vernier, manager of product engineering, automotive products at Microchip Technology
It may seem paradoxical that qualifying a tool for use in a functional safety application cannot fall to the tool provider. A closer look at the ISO 26262 qualification process will explain this apparent paradox. The process starts with determining the ASIL (Automotive Safety Integrity Level) of your application and the TCL (Tool Confidence Level) required of each tool that you plan to use. Determining the ASIL of your application is outside the scope of this article.
Determining TCL required of tools to be used
When developing an item with ISO 26262 safety requirements, the standard requires that all software tools used in that item’s development have documented evidence as to why each tool is unlikely to introduce an error that will cause unsafe operation. A perfectly good design intent can be made unsafe by mis-operating tools. The description “unlikely,” as opposed to “impossible,” is key. The intent is to increase confidence that the tool does not create safety relevant errors, not guarantee that it works perfectly. In the case of C compilers, there may be several to choose from and many considerations involved in the final selection. Confidence that the compiler chosen does not introduce errors into the design is essential.
To help determine the level of detail to which a tool should be analyzed, a risk assessment (Tool Classification) is performed. Tool classification considers two aspects for each use case (see Table 1): its impact on the safety of the design (Tool Impact or TI), and the probability that an error could be generated and go undetected (Tool error Detection or TD). TI and TD are not affected by how often the tool has been used, or what company made the tool. Risk is not limited to only what goes directly into the item, but also the information that affects design choices (ex: simulations) or test results. Error detection can of course be built into the tool, but TD determination should also include the evaluation and testing of the item later in the development process. Risk can be minimized by using only tools for their intended purpose and usage conditions, which is usually described in a tool’s user guide and/or safety manual. Note: TCL1 tools require no qualification.
Tool Qualification based on ASIL and TCL
ISO 26262 recognizes four qualification methods for each TCL, each ranked by the ASIL of the application (see Table 2).
Increased confidence from use is restrictive in that it applies only for exactly the same version of the same tool in the same application. However, if that applies to your situation, it’s there to use. The second method, evaluation of the development process requires deep insight into the development processes of your tool provider. That may be possible, but it is not likely to be used except for the mitigating influence of a third-party certification body, which could gain access to this usually proprietary information during certification audits. The third method is validation of the software tool. Validation is a tried-and-true method for ensuring proper operation of software. Depending on the tool, however, the degree of expertise necessary to validate the tool may be excessive. Certainly, compilers fall into that category. Finally, qualification gets easier if the tool has been developed in compliance with a safety standard. Processes that comply with safety standards are still fairly new and many tools are mature enough that this qualification method is too new to apply to them.
Validating the qualification
Of course, you must be comfortable with the thoroughness of the qualification that you performed when you present it to an auditor. As mentioned, one would have to be a qualified compiler validation expert to determine if the hundreds of thousands of tests performed on the compilers, such as MPLAB XC functional safety compilers, were necessary and sufficient.
One sure way to validate a tools qualification is to leverage third-party certification from an accredited body like TÜV SÜD. Such an organization can bring a vast array of experience and expertise in both functional safety and tool certification. Utilizing comprehensive information and incisive on-site audits, a third-party organization uses information by the tools provider, including process definition and documentation, validation methodologies and results, a safety plan, Failure Mode and Effects Analysis (FMEA) and functional safety manual, to ensure that any provisional classification and qualification documents provided by a tool vendor meet a rigorous, high standard of attainment.
Microchip simplifies meeting your Functional Safety requirements
Along with the certificate from TÜV SÜD and the reports that substantiate it, Microchip provides all of the above-mentioned documentation along with our just-released MPLAB XC Compilers for Functional Safety – in one convenient package. Also included in the package are classification and qualification documents for MPLAB X IDE and MPLAB debuggers and programmers to Tool Confidence Level 1 (TCL 1). Since the MPLAB XC compiler products support all of Microchip’s microcontrollers (MCUs), every MCU Microchip offers is included in this functional safety solution. Microchip helps customers simplify the development tool qualification process for their functional safety requirements.