ISO/PAS 8926: The Documentation Crisis in Pre-Existing Software Qualification
The new standard demands rigorous documentation for qualifying legacy automotive software. Here's why most organizations are struggling—and how AI-powered documentation generation changes the equation.
A Standard the Industry Has Been Waiting For
In January 2024, ISO published a standard that every automotive software engineer should understand: ISO/PAS 8926:2024—"Road vehicles — Functional safety — Use of pre-existing software architectural elements." [1]
This matters because it addresses a fundamental reality the industry has been dancing around for years: 90% of automotive software comes from external sources—legacy code, open-source libraries, commercial off-the-shelf components, and software inherited through acquisitions. [2] Yet ISO 26262, the cornerstone functional safety standard, was designed primarily for newly developed components with documented development processes.
PAS 8926 bridges this gap. But in doing so, it exposes a documentation crisis that threatens to derail software reuse economics across the industry.
The Scale of Software Reuse
Modern vehicles contain between 100 and 200 million lines of code—and that number is growing roughly 4x per decade. [3] Volkswagen's Board Member Christian Senger acknowledged that only 10% of their software is developed in-house. The rest comes from dozens of suppliers, acquired companies, and open-source projects. [2]
At the current pace, software maintenance alone will consume all software R&D resources if complexity continues growing.
— Auto Company Executive to McKinsey [4]The economics are brutal: developing software from scratch to meet ASIL D requirements costs $60,000 to $300,000+ per component and takes 9-18 months. [5] Reusing proven-in-use software should be the obvious answer. But here's the catch—ISO 26262's existing provisions assume you have documentation that legacy software rarely possesses.
What PAS 8926 Actually Requires
The standard introduces a classification framework based on two dimensions: provenance-related uncertainty (how was the software developed?) and complexity-related uncertainty (how hard is it to find systematic faults?). [6][7]
The Classification Framework
Provenance ratings (P1, P2, P3) assess development process evidence:
- P1: Evidence exists that development followed a recognized standard (ISO/IEC/IEEE 12207, IEC 61508, RTCA DO-178C)
- P2: Gaps between actual development and standards are believed sufficiently small
- P3: Everything else—typically legacy software with unknown development history
Complexity ratings (C1, C2, C3) evaluate fault detection difficulty:
- C1: Complexity measures show software is not highly complex
- C2: High complexity exists but is deemed acceptable
- C3: Everything else
Classification Determines Qualification Path
Class I PSAEs (combinations like C1+P1 or C1+P2) can follow standard ISO 26262 Part 8 Clause 12 guidance. Class II PSAEs require expanded rigor—including refined safety requirements, operational context evaluation, and increased verification. Combinations of P3 and C3 are explicitly not recommended for functional safety use.
Required Documentation
Regardless of classification, you need baseline documentation before qualification can even begin:
- Software Safety Requirements Specification — What safety requirements must the pre-existing element fulfill?
- Safety Analysis Report — What are the failure modes, and how are they managed?
- Software Architecture Documentation — How does the software structure support safety goals?
- Design Documentation with Bidirectional Traceability — Can you trace from requirements through design to implementation?
- Development Environment Documentation — What tools, compilers, and processes produced this software?
The Documentation Gap Crisis
Here's the uncomfortable truth: most legacy software lacks this documentation entirely. It was developed before ISO 26262 existed, or by teams that have since disbanded, or by acquired companies whose processes were never integrated. The code works—it's been running in millions of vehicles for years—but the paper trail doesn't exist.
Why Traditional Approaches Don't Scale
Industry consultants will tell you that without proper documentation, "you will essentially have to reverse-engineer your software after the fact to document development and test processes." [7]
This is bound to be error-prone, will take additional resources and developer time, and will delay time-to-market.
— Industry Functional Safety Expert [7]Manual reverse-engineering creates several problems:
- Time: Reconstructing documentation for a complex module can take months of engineering effort
- Accuracy: Human interpretation introduces errors and inconsistencies
- Traceability: Manually created documentation inevitably drifts from actual code
- Cost: Senior engineers—the only ones who can do this work credibly—are your most expensive resource
- Scalability: You can't apply this approach to every legacy component in your codebase
The result? Organizations make tough choices. They limit software reuse to avoid qualification burden. They redevelop software from scratch at enormous cost. Or they take compliance shortcuts that create audit risk and, more importantly, safety risk.
The Stakes: Why This Matters for Safety
Let's be clear: documentation isn't just bureaucratic overhead. It's how safety engineers understand what software does, identify potential failure modes, and verify that safety requirements are met.
In 2024, 44% of all recalled vehicles involved software issues—15 million units in the US alone, a 4x increase from 2023's 3.2 million vehicles. [13][14] Recent high-profile software recalls include:
- Honda: 256,600 Accord Hybrids for software errors causing potential drive power loss [13]
- Ford: Over 1 million vehicles for backup camera software issues [13]
- Tesla: 2 million vehicles for Autopilot software that didn't adequately prevent driver misuse [13]
Civil penalties from NHTSA range up to $200 million. [13] The V-model depends on alignment: if the left side (requirements, architecture, detailed design) is broken, the right side (verification, validation, testing) is compromised.
A Different Approach: Generate Documentation from Code
What if you could generate draft documentation that PAS 8926 requires—directly from your existing codebase—and then have engineers review and approve it?
This is exactly what GapLensAI does. Our platform analyzes proven-in-use source code and generates regulatory-grade documentation including Software Requirements Specifications (SRS), Software Architecture Documents (SAD), and Software Detailed Design (SDD)—with 100% traceability between documentation and implementation. Every generated artifact goes through human review and approval before becoming part of your compliance baseline.
The GapLensAI Approach
Rather than reverse-engineering documentation manually, GapLensAI extracts design intent directly from code structure, function signatures, data flows, and architectural patterns. Engineers review the generated documentation, validate accuracy, and approve before release. The result is accurate, traceable documentation that reflects what the software actually does—verified by the people who know it best.
Mapping GapLensAI to PAS 8926 Challenges
| PAS 8926 Challenge | GapLensAI Solution |
|---|---|
| Legacy code lacks requirements documentation | Generates draft SRS from code analysis for engineer review |
| No architecture documentation exists | Produces SAD showing actual software structure and interfaces |
| Design-to-code traceability is missing | Creates bidirectional traceability maintained automatically |
| Manual reverse-engineering is error-prone | Deterministic code analysis ensures accuracy |
| Documentation drifts from implementation | Regeneration on code changes with human review keeps docs synchronized |
| Complexity assessment (C-rating) requires analysis | Computes Annex B metrics: cyclomatic complexity, LOC, coupling/cohesion |
| Impact analysis requires interface documentation | Extracts interfaces, data flows, and timing patterns from code |
| Class II PSAEs need suitability evaluation | Generated docs provide foundation for safety analysis inputs |
How GapLensAI Helps with PAS 8926 Compliance
As researchers from Vector Informatik noted in their SAFECOMP 2023 analysis: "Proprietary legacy software may lack active development support and sufficient documentation. This scarcity of available resources can hinder the reusability process." [16] This documentation scarcity is exactly what GapLensAI addresses.
📄 Generate Documentation for Legacy Code
Pre-existing software elements typically lack the SRS, SAD, and SDD documents that PAS 8926 requires as prerequisites for qualification. GapLensAI generates draft work products directly from source code analysis, which engineers then review and approve—eliminating months of manual reverse-engineering while maintaining human oversight.
🔗 Establish Bidirectional Traceability
Safety argumentation requires demonstrating that the PSAE fulfills allocated requirements with traceable evidence. GapLensAI maintains 100% traceability between generated documentation and source code—flagging updates for human review when code changes.
📊 Support Complexity Classification
PAS 8926's C-rating requires analyzing code complexity to determine qualification approach. The standard's Annex B explicitly lists complexity measures including cyclomatic complexity, lines of code, Halstead complexity, maintainability index, coupling/cohesion metrics, control and data flow analysis, and fan-in/fan-out. GapLensAI automatically computes these metrics, providing the quantitative evidence needed to justify C1, C2, or C3 classifications.
🔍 Enable Impact Analysis (Section 4.4.3)
PAS 8926 requires impact analysis covering external interfaces, scheduling/timing aspects, and concurrency behavior. GapLensAI extracts interface definitions, identifies data flows between components, and documents timing-related code patterns—providing the foundation for operational context evaluation required by the standard.
🔄 Keep Documentation Synchronized
Documentation fails when it becomes a separate job from engineering. GapLensAI integrates into the development workflow—VS Code, GitHub Copilot, CI/CD pipelines—detecting changes and generating updated documentation for engineer review and approval before committing.
The Qualification Workflow, Transformed
Traditional Approach
Identify pre-existing software element for reuse, search for existing documentation (usually incomplete or missing)
Assign senior engineers to reverse-engineer the software, manually create requirements, architecture, and design documents
Attempt to establish traceability (often incomplete), submit for safety assessment
Discover gaps, iterate, maintain documentation manually as code evolves
Timeline: 3-6 months per major component
GapLensAI-Enabled Approach
Identify pre-existing software element, run GapLensAI analysis on the codebase
Engineers review generated SRS, SAD, and SDD; validate accuracy and approve artifacts
Use complexity metrics to support C-rating classification, submit approved documentation for safety assessment
Code changes trigger documentation updates; engineers review and approve before committing
Timeline: Days to weeks per component (with human review at each stage)
Industry Context: Linux, Open Source, and SDVs
The push toward software-defined vehicles makes PAS 8926 compliance even more critical. The Linux Foundation's ELISA Project (Enabling Linux in Safety Applications) has seen major automotive players join—Honda and KernelCI in March 2025, Canonical and EMQ in 2024—all working to qualify Linux for automotive safety applications. [8][9][10]
These organizations face the same documentation challenge at massive scale. The Linux kernel alone contains tens of millions of lines of code developed over decades by thousands of contributors. [11] Qualifying it for ASIL applications requires exactly the kind of documentation that GapLensAI generates.
Looking Ahead: ISO 26262 Third Edition
PAS 8926 content is expected to be integrated into ISO 26262 Third Edition, projected for Q2 2027. [6] Organizations that develop efficient qualification workflows now will have a significant competitive advantage as the industry transitions.
Getting Started
If you're working with pre-existing software elements and facing PAS 8926 qualification challenges, here's our recommended approach:
- Inventory your PSAEs: Identify which pre-existing software elements need qualification for your target ASIL level
- Assess documentation gaps: Determine which required work products exist and which need to be created
- Evaluate your options: Compare manual reverse-engineering costs against automated generation
- Pilot with high-value targets: Start with components where reuse value is highest and documentation gaps are largest
- Establish sustainable workflows: Implement processes that keep documentation synchronized as code evolves
GapLensAI is designed specifically for safety-critical software teams facing these challenges. Our platform integrates into your existing development environment and generates documentation that meets ISO 26262 and ASPICE work product requirements.
Close the Documentation Gap
See how GapLensAI transforms pre-existing software qualification from a months-long burden into a streamlined, automated process.
Learn MoreAuthor: Krishna Koravadi
References:
[1] ISO/PAS 8926:2024: ISO Official Standard Page
[2] 90% external software sources: Volkswagen Group - Car.Software Organization Press Release
[3] Automotive software complexity: IEEE Spectrum - How Software Is Eating the Car
[4] McKinsey automotive software analysis: Coherent Market Insights - SDV Market Report
[5] Development costs: TopDevelopers Cost Breakdown, Sphinx Solution Analysis
[6] PAS 8926 standard overview & ISO 26262 3rd Edition: INVENSITY Analysis, ELISA Technical Overview Video
[7] Pre-existing software qualification challenges: Wipro - Proposed Safety Qualification for Reusable Software, SecuRESafe ISO 26262 OSS Analysis
[8] Honda & KernelCI join ELISA (March 2025): ELISA Announcement
[9] Linux Foundation ELISA: Linux Foundation Press Release
[10] Canonical & EMQ join ELISA (2024): PR Newswire Announcement
[11] Linux functional safety: Red Hat Blog, Bosch Open Source Automotive
[12] PAS 8926 complexity tooling: exida Safety Function Analyzer
[13] Software recalls 2024-2025: WardsAuto Recall Roundup, Sibros State of Recalls
[14] Software as root cause of recalls: Profilence Analysis
[15] AUTOSAR adoption: ResearchGate Survey
[16] SAFECOMP 2023 research: Toennemann, J. "Qualification of Complex Pre-existing Software for Safety-critical Automotive Systems," SAFECOMP 2023, Vector Informatik GmbH