As the automotive industry transforms into a software-driven domain, it faces a reality that the aerospace world has known for decades: safety and complexity demand discipline.
Modern vehicles now match or even exceed aircraft in terms of software volume and system integration. But while aviation engineers treat process as a cornerstone of engineering, many in automotive still see it as an obstacle.
Code Complexity and System Parity
Modern premium vehicles can exceed 100 million lines of code (McKinsey, 2020). In comparison:
- The Boeing 787 has about 14 million lines of code.
- The F-35 fighter jet: roughly 24 million.
What’s important isn’t just the size of the codebase—but the criticality and integration of the systems it supports: ADAS, powertrain, infotainment, connectivity, cybersecurity.
Two Standards, Two Mindsets
DO-178C (Aviation)
- A regulatory standard used by FAA/EASA for certifying airborne software.
- Based on Design Assurance Levels (DAL A–E), with DAL A requiring the highest safety rigor.
- Focused on software correctness and traceability.
- Emphasizes objective evidence, configuration management, and formal verification.
ASPICE & ISO 26262 (Automotive)
- ASPICE is a process capability model (aligned with ISO/IEC 15504) used widely by OEMs to assess supplier maturity.
- ISO 26262 is a functional safety standard derived from IEC 61508, focused on avoiding hazardous system behavior.
- Safety levels defined by Automotive Safety Integrity Levels (ASIL A–D).
- Adoption varies and is often OEM-driven, not regulatory-mandated.
The Sentiment Gap
- In aviation, DO-178C is viewed as part of the engineering identity—necessary, respected, and safety-driven.
- In automotive, ASPICE is frequently seen as auditor-driven, with compliance motivated by customer pressure rather than engineering value.
This cultural difference leads to a widespread perception:
DO-178C is engineering. ASPICE is overhead.
The Role of Purpose
The key difference isn’t the standards themselves—it’s the perceived purpose behind them.
In aviation:
“We do this to earn the right to fly.”
In automotive:
“We do this because the OEM requires it.”
When engineers see process as meaningful, they participate with pride. When it’s just a checkbox, compliance becomes resistance.
Process as a Pillar of Engineering, Not Overhead
Aviation’s safety record is the result of deeply embedded engineering culture:
- 0.07 accidents per million flights for commercial jet aircraft (IATA, 2023).
- Decades of experience with structured development models, formal reviews, and certification frameworks.
This didn’t happen because aviation was agile—it happened because it was disciplined.
In contrast, automotive continues to push for speed, agility, and consumer-driven innovation. That’s not a bad thing—but without a mature process culture, these forces can lead to technical debt and safety risk.
The Cultural Gap
At the heart of the issue is not tooling or training—but culture.
In aerospace:
- Process is embedded in the engineering identity.
- Standards are viewed as enablers of quality and safety.
- Certification is not an afterthought—it’s a primary design constraint.
In automotive:
- Process often feels imposed—by OEMs, auditors, or regulators.
- Standards are treated like fences, not foundations.
- Engineers feel like they’re serving process, not supported by it.
That needs to change. Because as cars become more autonomous, connected, and electrified, we don’t just need better tools—we need a better relationship with our standards.
Four Cultural Shifts Automotive Needs
1. Purpose-Driven Compliance
Rather than focusing on “what the auditor needs,” teams should connect ASPICE and ISO 26262 to real-world outcomes: fewer bugs, better test coverage, traceable changes, and safer deployments.
2. Engineer-Led Ownership
When processes are imposed top-down, engineers disengage. The best-performing aerospace teams involve developers directly in shaping how the standard is implemented—customizing without compromising.
3. Safety as Culture, Not Checkpoint
Aviation bakes safety into every phase of the lifecycle. Automotive must move beyond final-stage sign-offs and treat safety as a systemic, continuous design constraint.
4. From Resentment to Respect
Process should be treated as a set of tools—not handcuffs. When engineers understand that these standards exist to help them build trusted, certifiable, long-lifecycle systems, their mindset shifts.
Looking Ahead: What’s at Stake
As vehicles move toward Level 3+ autonomy, they will rely on complex decision-making algorithms, redundant systems, and real-time data fusion—all safety-critical. There will be no room for process shortcuts.
The challenge is no longer about whether automotive systems are safety-critical. The challenge is whether the culture is ready to treat them that way.
Conclusion: Engineering with Integrity
Aviation spent decades learning how to deliver high-assurance software—under regulation, under scrutiny, and under risk. Automotive now faces a similar journey, but with accelerated timelines and consumer expectations layered on top.
To meet the moment, we must:
- Respect the intent behind our standards.
- Equip engineers to own and evolve the process.
- Build systems that we can certify, defend, and trust.
Because in both cars and planes, it’s not just about code.
It’s about lives.
Interested in continuing the conversation?
Follow me on LinkedIn or drop a comment below—I’d love to hear how your team is adapting to the new world of software-defined vehicles.
Further Reading & References:
- RTCA DO-178C: Software Considerations in Airborne Systems and Equipment Certification
- ISO 26262: Road vehicles – Functional safety
- ASPICE Process Assessment Model (Automotive SPICE v3.1)
- McKinsey: “The case for an end-to-end automotive software platform”
- IATA Safety Report 2023