Volvo EX90: When Software Authority Exceeds Platform Limits
Volvo EX90: When Software Authority Exceeds Platform Reality
Introduction: When Software Authority Exceeds Platform Reality
Software-defined vehicles promise flexibility, rapid feature deployment, and continuous improvement through over-the-air updates. That promise rests on an implicit assumption: software authority can expand safely within the limits of the underlying platform.
The Volvo EX90 challenges that assumption.
Less than a year after launch, Volvo made the rare decision to replace the central compute platform across the EX90 fleet. This was not a sensor recall, not a defect campaign, and not an OTA rollback. It was a platform-level intervention prompted by a fundamental mismatch between software authority and platform reality.
This article examines the EX90 case as a systemic boundary enforcement event, not a failure of software execution. It explains why OTA mitigation reached its limits, how platform headroom and integration envelopes were exceeded under real-world conditions, and why restoring architectural margin became the only credible path to re-establish verified system behavior.
What Happened
The Volvo EX90 was positioned as a flagship software-defined vehicle, built around a centralized computing architecture intended to support advanced safety, perception, and in-cabin intelligence. The vehicle launched with a clear roadmap of features, many of which were to be enabled or refined through OTA updates post-sale.
In practice, early customer experience revealed persistent instability. Owners reported intermittent system resets, unavailable or delayed features, inconsistent behavior across infotainment and connectivity, and higher-than-expected standby energy consumption. Several advanced functions, including LiDAR-linked safety capabilities, were postponed beyond launch.
Volvo responded in the expected way. Multiple large OTA updates were deployed to stabilize the system and gradually roll out missing functionality. Despite these efforts, instability persisted. The system reached a plateau where additional software tuning no longer produced meaningful improvement.
At that point, Volvo made a rare decision: replace the central computer across the active model year with a more capable platform originally intended for later vehicles.
Why OTA Could Not Solve It
It is tempting to frame this outcome as a software execution problem. That framing is incomplete.
OTA updates are effective when instability is rooted in logic defects, incomplete feature integration, or tunable performance inefficiencies. They are not effective when the execution environment itself is constrained beyond what the software roadmap requires.
In this case, the repeated application of OTA updates did not converge toward stability. That pattern strongly suggests the system was not failing because of incorrect behavior, but because it was being asked to operate outside the sustainable envelope of the underlying platform.
- Firstly, OTA cannot create compute margin
- Then, OTA cannot eliminate thermal limits
- Finally, OTA cannot simplify cross-domain integration once architectural complexity exceeds manageable bounds
At some point, additional software optimization produces diminishing returns. When that point is reached, continued reliance on OTA becomes an exercise in symptom management rather than restoration of verified behavior.
Why Platform Limits Are Invisible Until They’re Crossed
Platform limits rarely announce themselves clearly. Long before a system fails outright, it typically exhibits ambiguous symptoms: intermittent instability, feature deferrals, sensitivity to timing, or increasing dependence on favorable operating conditions. None of these signals, on their own, conclusively indicate that architectural limits have been exceeded.
In complex, centralized systems, performance degradation is often non-linear. Early stress appears manageable and correctable through tuning. Software optimizations, task reprioritization, and feature gating can temporarily stabilize behavior, reinforcing the belief that further OTA refinement will succeed. Meanwhile, traditional validation metrics remain largely green. Individual subsystems behave as expected, diagnostics report nominal status, and no discrete fault condition demands escalation.
The underlying issue is that platform saturation emerges from integration effects, not component failure. Compute contention, thermal margins, timing interference, and cross-domain dependencies accumulate silently until the system crosses a threshold beyond which stability can no longer be recovered through software alone.
Generally, by the time that threshold becomes unmistakable, the platform is already operating outside its verified envelope. What appears sudden in the field is often the delayed manifestation of limits that were present but obscured by incremental mitigation.
The Boundary That Was Crossed
The core issue was not feature ambition. It was authority.
The software roadmap assumed a level of execution authority — in perception, fusion, UI responsiveness, connectivity, and background services — that the original platform could not reliably sustain under real-world workloads. Integration across multiple compute domains, shared power and thermal constraints, and asynchronous feature activation created a level of complexity that exceeded the original headroom assumptions.
From a systems perspective, this represents a classic boundary violation:
- Software authority expanded beyond the platform’s verified capacity.
- Execution became non-deterministic under normal operating conditions.
- Stability depended increasingly on favorable timing rather than enforceable limits.
At that point, the system could no longer be considered equivalent to its validated state. Software behavior may have remained nominal in isolation, but the integrated system was no longer operating within a provable envelope.
Software Authority vs. Platform Authority
The EX90 case highlights a distinction that is often blurred in software-defined systems: the difference between software authority and platform authority.
Software authority describes what the system is permitted to attempt. It reflects feature scope, functional ambition, and execution intent expressed through code. Platform authority defines what the underlying hardware and architecture can reliably guarantee under real-world conditions, including compute headroom, thermal limits, timing determinism, and integration stability.
Problems arise when software authority expands faster than platform authority. In early stages, this imbalance can be masked through optimization and mitigation. Over time, however, execution becomes increasingly dependent on favorable conditions rather than enforceable guarantees.
At that point, stability is no longer a property of the system—it is an assumption. Once software authority exceeds platform authority, continued operation relies on optimism rather than verification. Restoring alignment requires either constraining behavior or expanding the platform itself. In the EX90 case, Volvo chose the latter.
Why the Hardware Swap Matters
Replacing a central compute platform across an active model year is an extraordinary action. It carries significant financial cost, logistical complexity, and reputational risk. OEMs generally avoid such decisions unless no credible alternative remains.
What makes this decision particularly instructive is how strongly it runs against organizational and cultural inertia. OEMs are structurally incentivized to avoid hardware intervention once vehicles are in the field. Hardware replacement is expensive, operationally complex, and highly visible. Software mitigation, by contrast, is incremental, reversible, and far easier to normalize—even when it fails to restore stability.
For that reason, many platforms remain in a prolonged state of partial correction. Features are suppressed, behavior is narrowed, and expectations are adjusted downward, all while the underlying architectural mismatch persists. Over time, this normalization of instability becomes indistinguishable from design intent.
By choosing to replace the central compute platform, Volvo rejected that path. The decision acknowledged that stability and safety cannot be negotiated indefinitely through mitigation alone. It recognized that some limits are architectural, not procedural, and that restoring system equivalence sometimes requires changing the execution substrate itself.
What makes this case significant is not that Volvo encountered platform limits—many OEMs will—but that Volvo acknowledged those limits and enforced them.
Rather than indefinitely suppressing features, deferring functionality, or normalizing instability through successive OTA updates, Volvo restored margin at the platform level. In doing so, it re-established a clean architectural baseline from which software authority could once again be exercised safely.
This was not an admission of failure. It was an enforcement decision.
In systems engineering terms, it was a deliberate act of boundary restoration.
Centralized SDV Architectures Under Real Load
The EX90 case highlights a broader industry reality: first-generation centralized SDV architectures are encountering real-world constraints faster than anticipated.
On paper, centralized compute offers compelling advantages:
- simplified E/E architectures
- flexible feature deployment
- scalable software development
In practice, centralization concentrates risk. Compute saturation, thermal contention, timing interference, and cross-domain dependencies all converge in the same execution environment. Without sufficient margin and clear authority boundaries, stability becomes probabilistic rather than guaranteed.
The challenge is not vendor selection or silicon capability in isolation. It is lifecycle alignment:
- hardware generation timing
- feature roadmap ambition
- integration maturity
- verification scope
When those elements drift out of alignment, software authority expands into territory the platform cannot safely govern.
Enforcement Versus Optimism
Most organizations respond to platform stress with optimism:
- further optimization
- feature gating
- deferred rollouts
- selective disablement
Those measures can buy time, but they do not restore equivalence. They rely on operational discipline rather than enforceable constraints.
Volvo’s decision represents the opposite posture. It accepts that certain boundaries are physical and architectural, not procedural. When those boundaries are crossed, the correct response is not to push harder, but to refuse execution until the platform can support it.
That refusal is not conservative. It is responsible.
What This Means for the Industry
This case will not be unique.
As SDV architectures mature, OEMs will increasingly encounter moments where software ambition outpaces platform reality. The decision paths will vary:
- eventually, some will quietly narrow behavior
- possibly, some will normalize instability
- and then, some will defer features indefinitely
A few will enforce boundaries.
The EX90 case demonstrates that enforcement may require physical intervention, not just software governance. It also demonstrates that transparency, while uncomfortable, preserves trust far better than perpetual mitigation.
Most importantly, it reframes success in the SDV era. Success is not defined by how many features can be enabled post-sale, but by whether the system remains controllable, verifiable, and stable as intelligence increases.
Early Warning Signs OEMs Should Watch For
Cases like the EX90 rarely emerge without precursor signals. The challenge is that those signals are often normalized long before they are recognized as architectural warnings.
One common indicator is increasing OTA cadence without corresponding gains in stability. When updates grow larger and more frequent but system behavior plateaus, it may signal that optimization is compensating for structural limits rather than correcting defects. Another is growing interdependence between domains that were originally intended to remain loosely coupled, such as safety-critical functions becoming increasingly sensitive to infotainment load or connectivity behavior.
Feature suppression is another warning sign. When roadmap capabilities are repeatedly deferred, narrowed, or permanently disabled to maintain baseline stability, the system may already be operating near its platform ceiling. Rising standby energy consumption without a clear fault condition can also indicate background contention and integration strain that diagnostics are not designed to flag.
Individually, these symptoms appear manageable. Collectively, they often indicate that software authority is approaching—or has exceeded—platform reality. Recognizing this pattern early creates options. Ignoring it narrows them.
Conclusion:
This was not an OTA failure.
It was not:
- a recall in the traditional sense
- a supplier defect
- a moment when software authority exceeded platform reality.
Volvo chose to make that boundary visible and correct it at the architectural level. That decision should not be interpreted as weakness, but as a signal of maturity. Software-defined vehicles still live in physical systems. When those systems reach their limits, ethics and engineering align on the same answer: enforce the boundary.
This case is a preview. More OEMs will face similar decisions as centralized architectures encounter real workloads and evolving expectations. The ones that recognize and enforce limits early will define what responsible SDV deployment looks like in practice.
Systems Engineering References
- https://georgedallen.com/new-engineering-ethics-fundamentals-of-product-development/
- https://georgedallen.com/objectivist-philosophy-in-new-engineering-ethics/
- https://georgedallen.com/working-model-craft-new-tech-for-system-content/
- https://arstechnica.com/cars/2025/09/forget-ota-volvo-is-upgrading-the-core-computer-in-the-ex90-for-free/
Copyright Notice
© 2025 George D. Allen.
Excerpted and adapted from Applied Philosophy III – Usecases (Systemic Failures Series).
All rights reserved. No portion of this publication may be reproduced, distributed, or transmitted in any form or by any means without prior written permission from the author.
For editorial use or citation requests, please contact the author directly.
About George D. Allen Consulting:
George D. Allen Consulting is a pioneering force in driving engineering excellence and innovation within the automotive industry. Led by George D. Allen, a seasoned engineering specialist with an illustrious background in occupant safety and systems development, the company is committed to revolutionizing engineering practices for businesses on the cusp of automotive technology. With a proven track record, tailored solutions, and an unwavering commitment to staying ahead of industry trends, George D. Allen Consulting partners with organizations to create a safer, smarter, and more innovative future. For more information, visit www.GeorgeDAllen.com.
Contact:
Website: www.GeorgeDAllen.com
Email: inquiry@GeorgeDAllen.com
Phone: 248-509-4188
Unlock your engineering potential today. Connect with us for a consultation.
