Tooling: the engineering domain on both sides of the V-model, and why AI won't replace it
What engineering tooling is, where it sits in the V-model and the software lifecycle, why AI can't replace it, and how AI makes it stronger. With examples from 14 years of building tools for automotive development, testing, production and service.
When people think of automotive software, they think of the code in the vehicle. Behind every ECU, though, is a second world of software: the tools engineers use to specify, build, calibrate, test, release, produce and service it. I have spent more than 14 years building that second world, and I'm convinced it matters more than ever, especially now that AI is changing how software is written.
What "tooling" means
Engineering tooling is the software that engineering teams use to create and verify a product, rather than the product itself. In automotive development that includes:
- Development tools: IDEs, compilers, code generators and communication stacks.
- Data and calibration tools: managing, validating and delivering calibration parameters and measurement data.
- Test tools: test automation, test bench control, bus analysis and evaluation of results.
- Production and service tools: End-of-Line calibration, ECU flashing and workshop diagnostics.
What these tools have in common: they are where engineering methods become repeatable. A good tool turns an expert's manual process into something a whole team can run the same way, every time.
Tooling on both sides of the V
The V-model describes development as a path down the left side (from requirements to implementation) and up the right side (from unit test to acceptance). Tooling is needed at every step on both sides, and beyond the V, in production and service:
| Stage | What tools do there | Examples from my work |
|---|---|---|
| Requirements and system architecture | Check consistency, keep traceability, derive test cases | System Architecture Comparison Tool: flags inconsistencies between architecture elements in Polarion and generates test cases with generative AI |
| Software design and implementation | Compile, generate code, communicate with ECUs | Cross-compiler IDE for AVR and ARM controllers; layered CAN/UDS communication stack; C# API client generated from OpenAPI |
| Calibration and integration | Manage, validate and deliver calibration data and software builds | CRETA export modernization; calibration data delivery pipeline; CaRuMa rule-based validation of calibration labels |
| Unit and integration testing | Automate tests, control test benches, analyze bus traffic | CAN bus analyzer; CArray Creator for test bench sequences; test bench release pipeline |
| System testing and validation | Process and evaluate large measurement datasets | Measurement Class Library; xD_MapCreator for multidimensional maps; HPC processing that cut analysis from hours to minutes |
| Beyond the V: production and service | Calibrate and flash at End-of-Line, diagnose in workshops | Inverter End-of-Line calibration tool with CRC patching; bootloader flashing tool; VDO Autodiagnos Check workshop tester |
Tooling also supports the lifecycle as a whole: maturity dashboards, forecasts of remaining effort and automated reports give project leads an overview that no single engineer could assemble by hand.
That is what makes tooling a domain of its own. It needs development knowledge (how software is built), test knowledge (how it is verified) and domain knowledge (calibration, diagnostics, measurement), often in the same tool.
Why AI can't replace tooling
AI is changing how tools are built and used. It doesn't make them unnecessary, for six reasons:
- AI acts through tools. An AI agent that "runs the tests" or "flashes the ECU" calls a tool to do it. Without reliable interfaces to compilers, test benches and measurement systems, AI has nothing to act on. Better AI increases the need for good tools, not the other way round.
- Releases need reproducibility. A release, a regression test or a calibration delivery must give the same result for the same input. Deterministic tools provide that; a language model's answer can differ from one run to the next.
- Safety standards require confidence in tools. ISO 26262, the functional safety standard for road vehicles, requires a Tool Confidence Level for software tools, based on how a tool error could affect safety and how likely it is to be detected. Tools in the higher levels need qualification. For AI/ML-based tools, Renesas points out that their output is hard to verify, so a low error-detection level must usually be assumed, which makes them harder to qualify.
- The physical world has protocols and timing. ECUs, CAN and UDS communication, power analyzers and dynamometers need drivers, exact protocols and real-time behavior. That is engineering, not text generation.
- Audits need evidence. Requirements, tests and results must be traceable and documented. Tools create and store that evidence in a form that holds up in reviews and audits.
- Data at scale needs pipelines. Evaluating large measurement campaigns is a data-engineering task: formats, storage, cluster jobs and integrity checks. AI can help interpret results, but the pipeline does the work.
Where AI does fit: inside tools, and in building them
The right question is not "AI or tools?" but "where does AI make tools better?":
- AI inside tools: my architecture comparison tool uses generative AI to find inconsistencies and propose test cases, and a machine-learning model forecasts remaining engineering effort. In both cases the tool around the model handles data, validation and presentation.
- AI for building tools: I use coding agents such as Claude Code, GitHub Copilot and Gemini CLI every day for scaffolding, tests and documentation. They make tool development faster, and every change is still reviewed and tested.
The principle I follow: AI proposes, tools verify. AI is excellent at suggesting; deterministic, tested tools decide what is correct.
What this means for tooling engineers
Tooling is one of the few roles that touches every stage of the lifecycle, from the first requirement to the workshop. That breadth is its strength: tooling engineers understand how a product is built, tested, produced and serviced, and they turn that understanding into software others rely on.
As AI takes over more routine coding, I expect the value of this combination to grow: engineers who know the domain, design reliable tools and use AI to build them faster.
Takeaways
- Tooling is everywhere in the V: every stage, on both sides, plus production and service.
- AI needs tools to act: reproducibility, tool confidence, hardware access and audit evidence come from tools.
- AI makes tools stronger: inside tools as a feature, and in building them as an accelerator. AI proposes, tools verify.
References
- ISO: ISO 26262-8:2018 Road vehicles – Functional safety – Part 8: Supporting processes
- Renesas: Confidence in the use of software tools for AI/ML development (2022)
- Synopsys: Automotive tool confidence for ISO 26262 (white paper, PDF)
More about the tools mentioned here under Projects.