?? Rethinking the Real-Time Platform for Automotive – Let’s Build It Together

The Industry’s Unspoken Truth: AUTOSAR Classic Became the Scapegoat

It all started with a bold statement from Robert Fey , who described AUTOSAR Classic as:

“The rotting corpse of automotive software development—kept alive only by inertia, outdated procurement rules, and a fear of real innovation.”

?? Harsh? Yes. ?? Entirely wrong? Not quite.

OEMs and Tier 1s, in their push toward Software-Defined Vehicles (SDVs), have often treated AUTOSAR Classic as one of the scapegoats for slow innovation.

But let’s be honest. The real issue isn’t just AUTOSAR itself—it’s how we’ve used it.

? AUTOSAR Classic was designed for a different era—when software was just a tool to control hardware.

? It brought standardization to a fragmented industry, helping reduce duplication and manage increasing E/E complexity.

? It did what it was meant to do. But the game changed.

Software is no longer a supporting function—it is the core of vehicle innovation. And AUTOSAR Classic was never built for agile development, cloud-native architectures, or CI/CD pipelines.

So, if we need an alternative, the question is: What must it include?

?? The Journey So Far: A Series on What Comes Next

Over the past few weeks, I’ve been writing a series of articles to explore this shift. Here’s what we covered:

?? Part 0: Rethinking AUTOSAR Classic – What it aimed to solve, what it didn’t, and why the industry is reconsidering it.

?? Part 1: What Must Stay? – Why AUTOSAR Classic was created and what an alternative must preserve.

?? Part 2: Key Design Considerations – The biggest challenges: balancing modularity with real-time determinism, safety compliance vs. development speed, and eliminating rigid XML-based workflows.

?? Part 3: The Essential Building Blocks – Translating these concepts into architecture—what a modern RT platform must contain.

This article brings all these insights together into one place. ?? Links to the full series will be in the comments.

?? From First Principles: What’s the Purpose of a Real-Time Core?

A real-time control platform in modern vehicles isn’t just software—it’s the digital nervous system.

It must:

• Execute safety-critical functions with strict real-time guarantees.
• Scale across different architectures, from simple MCUs to high-performance zonal ECUs.
• Ensure modularity—no forced full-stack adoption.
• Support a mixed-criticality approach, allowing safety and non-safety applications to coexist.
• Be future-proof—designed for evolution, not just standardization.

The challenge isn’t whether we need an alternative—it’s about building one that actually solves modern software problems.

?? The Hard Part: Key Design Considerations

1?? Real-Time Determinism Without Unnecessary Complexity

• Should we stick with static scheduling like AUTOSAR OS, or move to more flexible models?
• How do we balance strict timing guarantees with software adaptability?

2?? Communication That Serves the Future, Not Just the Past

• CAN, LIN, and Ethernet must all be supported, but how do we integrate modern service-oriented approaches?
• Should we fully abstract communication, or allow fine-grained control for efficiency?

3?? Functional Safety Without Slowing Innovation

• How do we allow ASIL-D and QM applications to coexist without separate development flows?
• Can we streamline safety certification without increasing overhead?

4?? Configuration & Integration – Breaking Free from XML Hell

• Static XML configurations vs. API-driven, dynamic approaches—what’s the balance?
• Can we introduce runtime configurability without compromising safety guarantees?

If we don’t get these design aspects right, we risk repeating history—just with a new name.

?? The Essential Building Blocks of an Alternative

We’ve defined what’s needed and the critical design challenges—now, let’s talk architecture.

1?? Real-Time OS (RTOS)

The foundation of deterministic execution, memory management, and safety compliance.

2?? Standardized Communication Stack

Supporting CAN, LIN, Ethernet, and future networking protocols without vendor lock-in.

3?? Diagnostics & Fault Management

Health monitoring, fault handling, UDS support, and cloud-based diagnostics.

4?? Memory & Storage Management

Scalable, fault-tolerant handling of flash, RAM, and persistent logging.

5?? Security & Cryptographic Services

Secure boot, encryption, and runtime integrity checks.

6?? Hardware Abstraction Layer (HAL)

A flexible, modular approach to decouple software from hardware.

7?? Application & Middleware Separation

Well-defined APIs that allow modularity and rapid development.

8?? OTA & Software Update Mechanisms

Fail-safe updates that support incremental deployment.

9?? Developer Tooling & Configuration

API-driven configuration to replace rigid, XML-heavy workflows.

These are non-negotiables—not optional features. Without them, any “new” platform will just be a reinvention of past mistakes.

?? Let’s Build It Together

This isn’t just my perspective. It’s a call to action.

?? What’s missing?

?? Which challenges are the hardest to solve?

?? How do we turn this vision into reality?

Because if this transition happens, it won’t be by mandate—it will be by the collective decision of the engineers shaping the future.

?? Drop a comment, challenge my ideas, and share your insights. Let’s build this, together.

?? Links to all previous articles are in the comments.

#AUTOSAR #SoftwareDefinedVehicles #RTOS #AutomotiveSoftware #SoftwareArchitecture #FutureOfMobility #EmbeddedSystems