Title: ISO 26262 Software Tool Evaluation: EPS Static Analyzer Guide URL: https://iso26262.academy/blog/evaluating-software-tools-in-iso-26262-a-practical-eps-example Description: Learn how to evaluate software tools for ISO 26262 compliance using a practical Electronic Power Steering static analyzer example. Get qualification tips. --- [Technical](https://iso26262.academy/blog/category/technical) # Evaluating Software Tools in ISO 26262: A Practical EPS Example ![Evaluating Software Tools in ISO 26262: A Practical EPS Example](https://iso26262.academy/_next/image?url=https%3A%2F%2Fiso26262.academy%2Fedge-media%2Fp%2Fblog%2Fimages%2F2026%2F04%2Fa1d68fc0-07c6-4651-961c-f438e2712c24.jpg&w=1920&q=75) Learn to systematically evaluate software tools for ISO 26262 compliance through a real Electronic Power Steering static analyzer example, covering tool impact assessment and qualification requirements. ![ISO 26262 Academy](https://iso26262.academy/logo.png) ISO 26262 Academy By [Paul Danci](https://iso26262.academy/about) 30 March 2026 8 min read Share Text size Imagine deploying an ASIL D Electronic Power Steering (EPS) system, only to discover later that a critical buffer overflow caused a sudden loss of steering assist. Your engineering team ran rigorous static code analysis, but the analyzer silently missed the violation due to a misconfiguration. How much confidence do you actually have in the software tools you use to develop safety-critical code? As automotive systems grow exponentially in complexity, engineering teams rely heavily on automated software tools to design, simulate, generate, and verify code. However, if these tools are flawed, they can introduce catastrophic errors or fail to detect existing ones. This is why establishing confidence in the use of software tools is a cornerstone of functional safety. In this article, we will scratch the surface of tool evaluation by walking through a practical, real-world example. We will look at what specific data is needed to evaluate a tool and how to determine the required level of qualification to ensure your tools support, rather than compromise, your safety goals. ## The Role of Software Tools in Functional Safety When developing an automotive system under functional safety guidelines, you must ensure that every part of your development lifecycle is robust. Software tools act as force multipliers, but they also introduce a layer of indirect risk. If a compiler generates incorrect machine code from valid source code, or if a testing tool reports a "pass" for a failed test case, the integrity of the entire system is at risk. To mitigate this risk, you must systematically evaluate and classify your tools. The goal is not to prove that a tool is perfect. Instead, the objective is to build sufficient confidence that the tool will not introduce an undetected error into your safety-critical system. This process involves determining the Tool Impact (TI), assessing the Tool Error Detection (TD) capabilities, and ultimately calculating the Tool Confidence Level (TCL). Once the TCL is established, you can select the appropriate Qualification method. ## Evaluating Tools: The EPS Static Code Analyzer Example | Data Category | Specific Example Data Required | | --- | --- | | **Tool Identification** | Vendor Name, Tool Name (e.g., AnalyzerPro), Exact Version Number | | **Execution Environment** | OS Version, Hardware Architecture, Build Server Specs | | **Configuration Data** | Active MISRA rule sets, suppressed warnings, command-line arguments | | **Use Case Description** | Pre-compilation code scan in the CI/CD pipeline for ASIL D C-code | | **Known Anomalies** | Vendor errata sheets, documented false negatives, bug reports | A checklist table detailing the specific data required to evaluate the static code analyzer for the EPS project. To understand how this works in practice, let us look at a specific example: a static code analysis tool used during the development of an Electronic Power Steering (EPS) system. The EPS system is classified as ASIL D because a failure could lead to unintended steering interventions. The engineering team uses a commercial static code analyzer to verify that the motor control software complies with MISRA C guidelines. The tool scans the source code automatically during the continuous integration build process. If it finds a violation, it flags the build as failed. If it finds no violations, the code moves on to the compiler. ### Scratching the Surface: What Data is Needed? Before you can determine the Tool Confidence Level, you must gather specific data about the tool and its exact use case. You do not need the tool's proprietary source code, but you do need a clear, documented understanding of how it operates within your specific environment. For our static code analyzer example, the required data includes several key elements. - **Tool Identification:** The exact name, vendor, and version number of the static analyzer (e.g., AnalyzerPro v4.2.1). - **Execution Environment:** The operating system and hardware where the tool runs (e.g., Ubuntu 22.04 LTS on a cloud-based build server). - **Configuration Data:** The specific rule sets enabled during the scan. For example, are you checking all mandatory MISRA C rules, or have some been disabled? What command-line flags are used? - **Use Case Description:** A precise definition of what the tool is expected to do. In this case, it is analyzing C source code for rule violations prior to compilation. - **Known Bugs:** Access to the vendor's errata or known issue list to see if there are documented scenarios where the tool produces false negatives. > To build confidence in software tools, you must evaluate them exactly as they are configured and used in your specific project environment. A tool qualified for one configuration is not automatically qualified for another. Keep learning [Free course preview Confidence in the Use of Software Tools](https://iso26262.academy/features/concepts/tool-confidence) [Or test yourself with the 7-question demo exam](https://iso26262.academy/demo-exam) ## Determining Tool Impact and Error Detection With the data gathered, the next step is to classify the tool. This begins with analyzing two distinct parameters: Tool Impact (TI) and Tool Error Detection (TD). ### Assessing Tool Impact (TI) Tool Impact asks a simple question: If this tool misbehaves, could that put an error into the safety-related product, or hide one that is already there? There are two possible classifications. - **TI1:** There is no way a tool malfunction could add an error or hide one. - **TI2:** Anything else, meaning a malfunction could add an error or hide one. In our EPS example, the static code analyzer does not generate code, so it cannot directly introduce an error into the EPS software. However, its entire purpose is to detect coding violations. If the tool malfunctions, it might fail to detect a critical buffer overflow. Therefore, the Tool Impact for our static analyzer is clearly **TI2**. ### Assessing Tool Error Detection (TD) Tool Error Detection evaluates the probability that an error caused by the tool will be detected or prevented by subsequent measures in your development process. There are three levels. - **TD1:** You are highly confident that a mistake by the tool would be caught or prevented. - **TD2:** You are moderately confident that it would be caught or prevented. - **TD3:** All other cases (low or unknown confidence). For our static analyzer, we must ask: If the tool misses a MISRA violation, will a downstream process catch it? The team might conduct manual code reviews, but human review is prone to error. They also run dynamic testing, but dynamic testing might not trigger the specific edge case caused by the coding violation. Because the team cannot guarantee a high or medium probability of detecting the tool's failure downstream, they must conservatively assign a classification of **TD3**. ## Calculating the TCL for Software Tools The combination of Tool Impact (TI) and Tool Error Detection (TD) determines the Tool Confidence Level (TCL). The TCL dictates how much rigor is required for tool Qualification. The levels range from TCL1 (lowest rigor required) to TCL3 (highest rigor required). Based on our EPS static analyzer example, we combine a Tool Impact of TI2 with a Tool Error Detection of TD3. This combination results in a classification of **TCL3**. A TCL3 classification means the tool requires rigorous qualification, especially since the target system is ASIL D. ### Selecting a Qualification Method Because our tool is classified as TCL3 for an ASIL D project, the team must select an appropriate Qualification method to prove the tool is fit for purpose. The standard provides four primary methods for tool Qualification. 1. **Increased confidence from use:** Proving the tool has a long, documented history of flawless operation in identical use cases. 2. **Evaluation of the tool development process:** Auditing the tool vendor to ensure they developed the tool using a rigorous quality management system. 3. **Validation of the software tool:** Creating a specialized test suite to validate the tool against its requirements. 4. **Development in accordance with a safety standard:** Treating the tool itself as a safety-critical software project. For a commercial static analyzer, the most practical approach is often _Validation of the software tool_. The EPS engineering team would create a suite of dummy C code files containing known MISRA violations. They would then run the static analyzer against this test suite to prove that the tool successfully detects every known error under their exact configuration and execution environment. ## Conclusion Building confidence in software tools is a mandatory and highly structured process in modern automotive engineering. By systematically identifying the required tool data, assessing the Tool Impact, and determining the Tool Error Detection capabilities, you can accurately classify your tools. As demonstrated with the EPS static analyzer example, even tools that do not generate code can require rigorous Qualification if they fail to detect safety-critical errors. Mastering tool qualification ensures that your toolchain acts as a reliable foundation for your safety goals, rather than a hidden source of risk. If you are ready to master the intricacies of TCL calculations, tool validation methods, and compliance documentation, we invite you to explore the resources available on our platform. Dive deeper with our comprehensive Confidence in the Use of Software Tools course at the ISO 26262 Academy, and ensure your engineering toolchain is truly ready for ASIL D development. ## Abbreviations & Key Definitions - **ASIL** - Automotive Safety Integrity Level, a risk classification scheme defined by ISO 26262. - **CI/CD** - Continuous Integration / Continuous Deployment, a method to frequently deliver apps to customers by introducing automation into the stages of app development. - **EPS** - Electronic Power Steering, an automotive system that reduces the steering effort by using an electric motor. - **MISRA C** - The coding rules for safer C, published by the MISRA consortium and used across the automotive industry to keep C code predictable and analysable. - **TCL** - Tool Confidence Level, a classification from TCL1 to TCL3 indicating the required rigor for tool qualification. - **TD** - Tool Error Detection, how likely it is that later steps in your process would catch a mistake the tool makes. - **TI** - Tool Impact, whether a fault in the tool could put an error into the product or let one go unnoticed. - **Qualification** - The process of providing evidence that a software tool is suitable for its intended use in a safety-critical development process. Last updated: 5 November 2026 Tags [tool-qualification](https://iso26262.academy/blog/tag/tool-qualification) [tcl](https://iso26262.academy/blog/tag/tcl) [functional-safety](https://iso26262.academy/blog/tag/functional-safety) [iso-26262](https://iso26262.academy/blog/tag/iso-26262) [software-tools](https://iso26262.academy/blog/tag/software-tools) Share this article ## Comments ## Go deeper: Confidence in the Use of Software Tools Open the free course preview to see what the full course covers. Or check yourself against exam-style questions, graded like the real exam. [Open the course preview](https://iso26262.academy/features/concepts/tool-confidence) [Take the 7-question demo exam](https://iso26262.academy/demo-exam) Ready for a full course? [Start free with the complete Functional Safety Concept guide](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Ffunctional-safety-concept&utm_source=website&utm_medium=cta&utm_campaign=blog_end) ## Stuck on this in your project? Send one question to a functional safety engineer. You get a written answer with the clause references. From **$290** with a written quote before any charge [See how we can help](https://iso26262.academy/features/consulting?service=question#sample) Keep learning ## Guides on this topic. The guide this article draws on, and where the topic leads next. [Browse all guides](https://iso26262.academy/features/concepts#library) - Software [Confidence in the Use of Software Tools](https://iso26262.academy/features/concepts/tool-confidence) Learn how to classify tools by TCL (1-3) based on Tool Impact, Tool Error Detection, and ASIL requirements. Covers qualification methods, practical guidelines, and worked examples for common toolchains. [Pro](https://iso26262.academy/pricing#plan-basic) [Expert](https://iso26262.academy/pricing#plan-advanced) 8 chapters - Software [Reuse and Legacy Software Safety](https://iso26262.academy/features/concepts/reuse-legacy-software) How to argue safety for what you did not develop this time: reuse routes, delta and impact analysis, carryover of unchanged elements, ISO/PAS 8926 qualification, wrappers, assumptions of use, and the rules for reusing verification evidence honestly. [Expert](https://iso26262.academy/pricing#plan-advanced) 12 chapters - Software [Product Lines and Variant Safety](https://iso26262.academy/features/concepts/product-line-variant-safety) Keeping ISO 26262 evidence valid across a family of vehicles: variability models a safety argument can trust, family HARA scope, feature interaction screening, Annex C configuration and calibration data, constraints that make unsafe configurations unbuildable, and a modular safety case. [Expert](https://iso26262.academy/pricing#plan-advanced) 13 chapters ## Related Articles [![A friendly white robot works at a laptop; two glowing paths lead from it, one to a car driving on a road at dusk and one to a second laptop showing source code](https://iso26262.academy/edge-media/p/blog/images/2026/10/415f35e3-f612-447b-bb1a-ce388d946926-1672.webp) Technical ### AI Coding Agents and ISO 26262: Classify the Use, Not the Tool 7 min Oct 22](https://iso26262.academy/blog/ai-coding-agents-iso-26262-classify-the-use-not-the-tool) [![Confidence in Software Tools: A Guide to ISO 26262 Qualification](https://iso26262.academy/_next/image?url=https%3A%2F%2Fiso26262.academy%2Fedge-media%2Fp%2Fblog%2Fimages%2F2026%2F03%2Fea8e5401-aad7-4bc7-a33d-ddbfce45f263.jpg&w=1920&q=75) ### Confidence in Software Tools: A Guide to ISO 26262 Qualification 8 min Mar 5](https://iso26262.academy/blog/confidence-in-software-tools-a-guide-to-iso-26262-qualification) [![Three engineers at a lab workbench: one points at a measurement plot on a laptop, a senior colleague listens and another takes notes, with a prototype car on a lift and test equipment behind them.](https://iso26262.academy/edge-media/p/blog/images/2026/10/5ab3c51b-1a48-413c-8990-7713591278c7-1200.webp) Technical ### Evaluating ISO 26262 Safety Culture: Evidence Over Slogans 7 min Oct 8](https://iso26262.academy/blog/evaluating-iso-26262-safety-culture-evidence-over-slogans)