Rethinking AUTOSAR Classic: What It Solved, What It Didn’t, and What Comes Next

Two weeks ago, I kicked off a discussion on alternatives to AUTOSAR Classic for microcontrollers—and the response was massive! Clearly, many of us in the embedded software community are questioning whether it's time to rethink how we build software for automotive MCUs.

But before diving into alternatives, I believe it’s critical to understand what we’re leaving behind. If we don’t grasp the original motivation for AUTOSAR, how can we evaluate whether a replacement truly meets the same needs? And more importantly, how do we know we are actually doing better?

This thought crossed my mind during a rather chaotic business trip—one that involved nine airport transits across six different cities and a missing luggage situation that made everything even more "fun." In between client workshops and key meetings, I had the chance to sit down with colleagues over dinner. Interestingly enough, some of them made strong arguments in favor of AUTOSAR Classic.

At the same time, I came across a rather provocative post by Robert Fey (link in comments), where he calls AUTOSAR Classic:

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

🔥 Harsh? Definitely. 🎯 Entirely wrong? Not quite.

Robert highlights many of the frustrations engineers face daily—XML complexity, tooling lock-in, and the rigid nature of AUTOSAR’s architecture. But in my view, this critique misses the bigger picture.

Why Was AUTOSAR Classic Created?

Back in the early 2000s, automotive software was becoming a tangled mess. Every OEM and supplier had its own way of developing software for ECUs, leading to:

🔹 Massive duplication of effort – Every new function meant reinventing software from scratch.

🔹 Vendor-specific chaos – Software was deeply tied to specific hardware, making portability nearly impossible.

🔹 E/E system complexity skyrocketing – More ECUs meant more interconnections, making system integration a nightmare.

To address these challenges, AUTOSAR was founded in 2003 by leading OEMs and Tier 1s, including BMW, Bosch, Continental, DaimlerChrysler, Siemens VDO, and Volkswagen. Their goal was simple in theory (though complex in execution):

✅ Standardize software interfaces – Ensuring that software components could be reused across different ECUs and suppliers.

✅ Decouple software from hardware – Making it easier to switch microcontrollers without rewriting entire applications.

✅ Improve software quality – Introducing modularity, structured architecture, and well-defined integration points.

✅ Enable collaboration across the industry – Creating a common language for software development between OEMs and suppliers.

✅ Integration-Oriented Design – AUTOSAR intentionally leaves many things to be solved during integration.Instead of enforcing one-size-fits-all solutions, it provides the foundation while allowing different players in the ecosystem to make system-wide decisions at a later stage. This was necessary for the modular supply chain model in the automotive industry, but it also means that a lot of effort is required to get everything working together at the end.

🔹 And as we can see, the focus was never on writing software itself. It was also not designed to enable modern software development practices like Continuous Integration, Continuous Delivery (CI/CD), or DevOps methodologies. AUTOSAR was born in an era where software was simply a means to control hardware, not the primary focus of innovation.

💡 For those familiar with Software-Defined Vehicles (SDV), don’t some of these goals sound familiar?Standardized software interfaces, hardware abstraction, and improved portability—aren’t these some of the same objectives being discussed in the SDV era? The difference is that AUTOSAR was created in a time when software was not a strategic priority, whereas today, software defines the vehicle experience.

AUTOSAR and the Role of ARXML

One of the most debated aspects of AUTOSAR is the ARXML files.

💡 On the positive side: They serve as comprehensive architectural artifacts—capturing software components, interfaces, configurations, and dependencies in a single format. This provides traceability, structure, and a formalized approach to system design.

💥 On the downside: ARXML is used for too many things at once. It attempts to be a documentation tool, a configuration file, a software description, and an integration artifact— all at the same time. This lack of separation of concerns is one of the reasons why working with AUTOSAR can feel overwhelming.

Beyond Just an OS – AUTOSAR is an Ecosystem

One of the biggest misconceptions about AUTOSAR Classic is that it's just an OS. It’s not.

Building an alternative to AUTOSAR Classic is not just about choosing the right safety-certified RTOS. You still need:

🛠 Standardized software services – AUTOSAR provides a structured way to handle diagnostics, power management, memory handling, and more. 🛠 A defined communication stack – Including CAN, LIN, FlexRay, and Ethernet-based protocols. 🛠 Middleware components – Necessary for integrating different applications within the vehicle architecture. Hint: DDS alone won't be enough.

Ignoring these aspects and just replacing the OS won’t work.

Did AUTOSAR Classic Go Wrong?

For its intended purpose, AUTOSAR Classic didn’t go wrong. It was built to bring order to the growing complexity of E/E architectures—and for nearly two decades, it has delivered on that promise.

However, its way of working left many things to be solved at the integration phase. While this made sense in the traditional automotive supply chain, where different suppliers provided different parts of the system, it also created additional friction:

❌ More effort required in final system integration.

❌ Late discovery of incompatibilities between components.

❌ Difficulties in ensuring system-wide consistency across multiple suppliers.

In an era where software needs to be developed and validated as a whole system from the start, rather than stitched together at the end, this approach no longer fits as well as it used to.

So, What’s My Take?

For its intended purpose, AUTOSAR Classic did its job well. It successfully provided structure to an industry that desperately needed standardization.

🚀 But the game rules have changed.

🚀 Software is no longer just a supporting function—it is the main driver of vehicle innovation.

🚀 Speed, modularity, and continuous updates weren’t major concerns in the AUTOSAR era, but they are now.

So while AUTOSAR Classic fulfilled its mission, the industry is evolving, and a new approach is needed to keep up.That said, I don’t believe AUTOSAR Classic will be completely replaced overnight. Classic ECUs will continue to exist in vehicles for a long time, and any new approach must consider coexistence strategies rather than assuming a full migration all at once.

💡 In my next post of this series, I’ll explore what a viable alternative to AUTOSAR Classic could look like. If you’re interested, hit like and let’s continue this discussion! 🚀

#AUTOSAR #EmbeddedSoftware #Automotive #SoftwareArchitecture #SDV #RTOS #Innovation