BluSkyi·Engineering Insight Article
Autonomous Driving · Functional Safety · Tool Qualification
Aviation's Tool Qualification Rules Score Highest for Transfer to Autonomous Driving
A stage-by-stage comparison of aviation and automotive software development finds that stricter tool qualification, earlier authority involvement and tighter requirements discipline are the aviation habits most worth importing into driverless vehicle programmes.
- Source Journal
- Journal of Autonomous Vehicles and Systems
- Lead Institution
- Daimler Truck AG
- Published
- 29 June 2026
- Discipline
- Automotive
- Focus Area
- Autonomous & Connected Mobility
- Research Type
- Theoretical
- Licence
- CC BY 4.0
- Authors
- Akkus et al.
The Bottom Line
Autonomous driving is pushing vehicle software into territory where automotive safety processes look thin beside aviation's. Walking both industries along the V-model, the authors identify ten transferable practices and score nine for feasibility. DO-330-style tool qualification scores 9.42 out of 10, far ahead of the rest; requirements practices follow. Making authority involvement mandatory is the only proposal to score below the neutral mark of 5. The weightings come from one manufacturer, so the ranking is indicative.
Key Findings · At a Glance
- Aviation developers meet certification authorities at least five times per project; automotive meets them once, at homologation.
- DO-330-style tool qualification scored 9.42 out of 10, the highest feasibility of any transfer proposal.
- Requirements-engineering proposals scored between 6.15 and 6.69; system-level proposals ranged from 4.54 to 6.38.
- Mandatory enhanced authority involvement, at 4.54, was the only proposal falling below the neutral score of 5.
- Coding is the one V-model stage where automotive guidance is more prescriptive than aviation's, through MISRA C.
- Both industries spend roughly 30–40% of total costs on verification, with similar defect detection and removal metrics.
- An aviation-derived dependent failure identification method perfectly matched a parallel supplier-side analysis.
Opportunity
Vehicle software has outgrown the processes built to govern it. The authors note that automotive code bases now exceed 100 million lines, surpassing aviation on that measure, while autonomous functions add tight coupling between perception, decision and actuation layers and stricter safety demands. Aviation, by contrast, has spent decades managing fly-by-wire and high automation under a regime of early standardisation and heavy regulatory oversight, and its safety record per distance travelled reflects that.
The question for vehicle makers is not whether aviation is safer but which of its habits would survive contact with automotive cost, volume and supplier structures. Earlier comparative studies mapped the two industries' standards against each other without producing concrete, quantified transfer proposals for autonomous driving. That is the gap this work sets out to close.
Yusuf Akkus of Daimler Truck and Björn Annighöfer of the University of Stuttgart compared ISO 26262 with DO-178C (and its companion guidance ARP4754, ARP4761 and DO-330) stage by stage along the V-model, from system level through requirements, design, coding and verification. At each stage they compared normative guidance first, then industry practice, and turned promising differences into transfer proposals. Each proposal was then scored for feasibility against cost, quality and time, using expert impact ratings and weightings from an internal survey of 126 employees.
Results
The sharpest contrast sits at system level. Through mandatory stages of involvement, aviation projects meet the authorities at least five times; automotive does so once, at homologation, and in the US even that step does not require authority involvement. The authors offer two options: more authority meetings, or a mandatory checkpoint immediately after system and software planning, mirroring aviation's first stage of involvement. They propose the same soft and rigorous pair for ASPICE process audits, which manufacturers typically run once, near the start of a project, to check supplier readiness.
Requirements engineering yields four proposals: a mandatory two-level split between high-level and low-level requirements; a tool-enforced rule that forces engineers to record rationale (at least 20 characters) whenever a requirement deviates from its default alignment state; automatic resetting of requirement attributes after changes so reviews are not skipped; and more intensive early prototyping. At the coding stage the pattern reverses: ISO 26262 strongly recommends MISRA C while DO-178C mandates no coding standard, so nothing is proposed there. Tool qualification is the largest gap, with ISO 26262 Part 8 covering in a few pages what aviation treats in a full separate standard, DO-330.
Verification proved a dead end for transfer. Both industries spend roughly 30–40% of total costs on it, and literature values for defect detection efficiency, defect removal efficiency and test case effectiveness were similar across domains.
Feasibility scores
On a 0–10 scale where 5 is neutral, DO-330-style tool qualification scored 9.42, with impact ratings of 9.66, 10 and 8.66 on cost, quality and time. Rationale forcing (6.69), prototyping (6.65), attribute conditioning (6.32) and the two-level hierarchy (6.15) followed. The recommended ASPICE enhancement reached 6.38 and its mandatory version 6.31, while recommended authority involvement scored 5.79 and its mandatory form 4.54. The dependent failure method, already in use, recorded an actual score of 5.83, and the forecasting method achieved a 14% estimation accuracy figure that the authors class as good.
What This Enables
Autonomous vehicle developers
The scored list gives programme leaders a prioritised starting point, with tool qualification for both development and verification tools the obvious first move and requirements discipline close behind.
Tier-one suppliers
Supplier-side safety teams gain an aviation-derived dependent failure checklist whose output matched their own analysis, and could expect more frequent or mandatory ASPICE assessments during system design.
Engineering tool vendors
The rationale-forcing and attribute-conditioning concepts were built on a commercial lifecycle platform, pointing to configurable enforcement features that requirements management tools could offer.
Vehicle type-approval bodies
The mandatory checkpoint proposal sketches what earlier regulatory engagement could look like, though its low feasibility score signals resistance within the surveyed manufacturer.
Assessment
The authors are explicit that the numbers are indicative. Weightings come from one manufacturer's survey, impact ratings from as few as three experts per proposal, and they concede that expert error margins cannot be quantified; in their words the results should be read as "indicative rather than representative of the entire automotive industry". They call for future work across multiple organisations and supply chain tiers, and flag architecture centralisation as a topic for further comparison.
Analysts should also weigh the framing. Feasibility here blends cost, quality and time, so a low score for mandatory authority involvement reflects internal preference as much as safety value, and the proposal the authors argue matters most for governance is the one the surveyed manufacturer's weightings rate least feasible. Most proposals remain untested in live autonomous programmes. Even so, the study makes a credible case that selective transfer offers "a viable path toward higher safety assurance for future automotive technologies", with tool qualification the most defensible place to begin.
About the Research
Conducted by Yusuf Akkus of Daimler Truck AG, Germany, with Björn Annighöfer of the Institute of Aircraft Systems, University of Stuttgart. Published open access in the Journal of Autonomous Vehicles and Systems (ASME) under a Creative Commons Attribution 4.0 licence.
Citation
Akkus, Y., & Annighöfer, B. (2026). A synoptic comparative analysis of aviation and automotive software development processes along the V-model to deduct transfer proposals for autonomous driving. Journal of Autonomous Vehicles and Systems, 6(4), 041002.