Software Tools

A software tool is a computer program used to develop, test, analyze, produce, or modify other software, hardware, or the system itself during the safety lifecycle, as defined in functional safety standards like ISO 26262 (automotive), IEC 61508 (general), or DO-178C (aerospace). Software tools act as instruments for developers, testers, analysts, and system administrators, enabling them to perform specific tasks within the software development lifecycle. Think of them as the drawing board, pencil, hammers, screwdrivers, and measuring tapes of the digital construction world.

Tools are key enablers of the development process. Even though tools themselves do not execute in the final embedded system, they play a critical role in shaping the quality and correctness of the final system.

Software tools range from simple spreadsheet programs for documentation and organization, to sophisticated simulators that can model complex system behavior for testing and analysis. They also encompass compilers, testing utilities, and management platforms for collaboration and progress tracking.

Essentially, any software application that helps in the creation, maintenance, or management of other software can be considered a software tool.

Here are some examples:

ool Name: Clang-Tidy
Category: Static Code Analysis Tool
Description: A static analysis tool that checks C++ code for style violations, programming errors, and potential bugs, often integrated into the Clang compiler.

Tool Name: ETAS ASCET
Category: Modeling and Simulation
Description: Environment for model-based development of automotive embedded systems.

Tool Name: IBM-ELM
Category: Engineering Lifecycle Management
Description: Managing requirements, design, testing, and collaboration in complex systems development.

Tool Name: MATLAB / Simulink
Category: Modeling and Simulation
Description: Powerful platform for modeling, simulating, and analyzing dynamic systems in vehicles.

Tool Name: PCLint with MISRA-Checker
Category: Static Code Analysis Tool
Description: Analyzes C/C++ code for bugs and enforces MISRA standards for automotive safety.

Tool Name: Texas Instruments C/C++ Compiler
Category: Compiler
Description: Compiler for Texas Instruments microcontrollers, common in automotive ECUs.

Tool Name: GoogleTest
Category: Unit Testing Framework (C++)
Description: Open-source testing framework for C++, providing a rich set of features for writing and running unit tests.

Software tools are used to create, transform, analyze, and test the actual safety-critical software and hardware systems so they influence the product, even indirectly.

For example:

A compiler translates source code into binary code. If the compiler misinterprets or incorrectly optimizes a section of code, the final system may behave unpredictably, a potentially hazardous failure in an automotive system.

Software tools can:

• Introduce errors (e.g., code generators producing incorrect code)

• Fail to detect errors (e.g., a static analyzer missing a buffer overflow)

• Mask errors (e.g., tools that format or restructure code might hide issues)

If these errors go undetected, they may propagate into the safety-critical system and cause unsafe behavior, which is why tools must meet ISO 26262’s rigorous error-detection and prevention requirements.

Because of their influence, software tools are subject to a systematic evaluation process defined in Part 8, Clause 11 of ISO 26262. This includes:

• Classifying tools based on their potential to impact the system

• Determining the required confidence level based on how critical the tool’s role is and available tool error detection mechanisms

• Qualifying the tool if necessary, to ensure it can be trusted in the safety development lifecycle

No, the software tool itself is not part of the final embedded system in ISO 26262 development. Software tools are used during the development process, for coding, testing, analysis, or generating artifacts, but the tool’s executable does not run on the final target hardware.

Some tools (like compilers or code generators) produce outputs such as binaries or source code that do end up in the final system. In such cases, these as development tools, require higher levels of confidence and possibly qualification (as defined in Part 8, Clause 11 of ISO 26262), because their outputs directly influence safety.

On the other hand, verification tools (e.g., static analyzers, simulators) only assist in ensuring correctness but do not produce deliverables used in the final embedded system. Their errors can still impact the safety argument, but their outputs are not embedded in the vehicle’s software.

While the output of a software tool may be included in the final product, the tool itself is not. Its influence must still be rigorously evaluated within the ISO 26262 safety lifecycle.

Category: Embedded System
Ends up in final system? Yes
ISO 26262 Relevance: Part 4 (System), Part 5 (HW) & Part 6 (SW)

Category: Tool
Ends up in final system? No
ISO 26262 Relevance: Part 8, Clause 11

Category: Library
Ends up in final system? Yes
ISO 26262 Relevance: Part 8, Clause 12