AUTOSAR, is it worth it?

AUTOSAR, is it worth it? A bare-metal guy’s perspective.

Let’s start with a little background about me to give some context to my opinion: I've been designing embedded systems for over 20 years, and I’ve written software for various industries, including aerospace, defense, rail, commercial tooling, and automotive. Most of the products I’ve designed have safety-related implications and run on a simplified task scheduler to meet all timing requirements. The applications have ranged from those needing precise real-time control, like three-phase motor inverters, to those with much more relaxed timing, such as user interface keypads. I have worked on a few projects that run embedded Linux or commercial RTOS, but the bare-metal approach is the lion’s share of my experience.

Advertised AUTOSAR Benefits

Standardized Architecture: One of the advertised benefits of AUTOSAR is its standardized architecture, which promotes compatibility, interoperability between software suppliers, modularity, scalability, and maintainability. These features help reduce development time and costs.

Competing Software Vendors: Standardization allows various vendors to produce off-the-shelf software packages (e.g., OS, encryption, drivers, communication protocols, etc.) at different levels of the AUTOSAR architecture that can be easily integrated. Competition among vendors should also drive software costs down as they strive to provide value to AUTOSAR customers. This approach allows software vendors to reduce their prices and profit through the volume of sales across the automotive industry.

Software Reuse: The standardization also promotes software reuse, which should allow the reuse of software as new products are introduced from generation to generation.

Reduced Development Time: The availability of off-the-shelf software components cuts down development time, and the standardized architecture should also reduce integration time. Since software vendors are selling pre-developed packages, these products are presumably well-tested and free from defects. This should make the verification phase of a project run quickly and smoothly.

The AUTOSAR Reality

Wow, so what’s not to like? I’m a big fan of well-defined, modular architectures because they do promote ease of maintainability and reuse. But with my first project involving AUTOSAR, I noticed some downsides.

Beefy Microcontrollers (MCU): To start, the AUTOSAR package has a very large memory footprint—North of 500 kB without any application code! I’ve worked on several applications with hard real-time constraints and very computationally intensive algorithms, and I’ve never created a memory footprint anywhere near this size. The size of the AUTOSAR memory footprint forces you to move up to a more capable microcontroller family that supports sufficiently large memory. If you add the ability to do field updates, you’ll need space for a bootloader and likely the ability to store multiple application images, pushing you over the 2 MB range. So, even if your application is relatively simple and could be handled by an 8-bit microcontroller, you’re forced to use a 32-bit MCU capable of running at speeds upwards of 300 MHz, which naturally drives up the cost of your bill of materials.

Execution Overhead: All those AUTOSAR packages in your large memory footprint aren't just sitting idle. They're busy managing data and processes at their respective level, utilizing all the attributes you’d expect in a full-featured RTOS. If you need your application to run at a 1 msec interval, you’re going to face challenges. And forget about it if you need sub-1 msec resolution. The best you can realistically do is partition a few tasks to run at the 1 msec rate and have the rest of your application run at the slowest rate it can tolerate. Running power train functions, performing vision processing, or handling high-bandwidth sensor data with AUTOSAR is pretty much off the table.

AUTOSAR Vendor Monopoly: Aside from the silicon vendors who supply MCALs (drivers) for their MCUs, there are only a few vendors providing AUTOSAR solutions. These vendors offer complete AUTOSAR stack solutions, and their individual packages often don’t integrate well with each other. This means you’re essentially locked into a single vendor for the most productive integration experience. To make matters worse, some OEMs are also mandating the use of a specific AUTOSAR vendor. Having one vendor provide the entire AUTOSAR stack doesn’t create a competitive environment, leading to very high off-the-shelf software costs—the highest I’ve ever seen. If you need functional safety-rated software, you can expect costs to be even higher.

Compromised Capabilities:

During initial software integration, we faced several hurdles in configuring the hardware to meet the required specifications. For instance, the OEM had specific requirements for the CAN bus. While a quick look at the datasheet helped determine the necessary settings, these options weren’t available through the AUTOSAR tools. We had to submit a service ticket with the AUTOSAR vendor to find a workaround solution. Three weeks later, we received a workable solution, although it wasn’t our first choice.

In another instance, we had a UART interface to an onboard device requiring a “non-standard” baud rate not included in the MCALs' standard settings. Our workaround involved bypassing the MCAL code and manually configuring the MCU registers.

It's understandable that we run into these situations because higher-end microcontrollers offer a plethora of options, making it challenging to cover every possible valid combination in a configuration tool. The tool vendor must make assumptions and create general options to cover most scenarios. Both cases emphasized the need for engineers to be comfortable with referencing datasheets and programming manuals, understanding hardware, and occasionally deviating from the standard AUTOSAR workflow.

Difficult to get started early: I’m all for a structured development process where requirements are established upfront, guiding architecture design prior to coding. In the initial stages of a project, there’s often a clear understanding of IO requirements and core functionalities before finer details, like diagnostics, are fully fleshed out. This allows for a structured approach to kickstart development early and enhance the application incrementally as requirements mature. However, acquiring an AUTOSAR package can complicate this workflow. AUTOSAR vendors typically require a high level of definition maturity to accurately quote their packages. Additionally, adding extra packages later can be costlier.

Specialized AUTOSAR guys: Now, I could be wrong here, but it seems like one of the implied benefits of AUTOSAR is that it reduces the need for specialized embedded software engineers. So, if we generalize this, perhaps the goal is to eliminate the need for specialized software talent altogether. However, in reality, you still end up needing specialized AUTOSAR experts, who will readily admit that integrating all the software packages is not a trivial task. So, does it truly eliminate the need for specialized software staff, or does it merely shift the area of specialization? As we've observed, you can't go completely without specialized embedded software folks because they still need to figure out what needs to happen at the hardware level when workarounds are necessary.

Revisiting the Benefits

If we take a quick look back at the benefits of AUTOSAR and compare them to a bare-metal or non-AUTOSAR approach, you can still achieve a modular, scalable, and maintainable architecture through good software engineering practices. As for reducing development time and promoting software reuse, these goals can also be achieved with a quality development process.

While AUTOSAR software may be reusable, it comes at a cost. AUTOSAR vendors license their software for a specific model year and using it for different models or model years incurs additional expenses. In-house designed software doesn’t have this cost burden for reuse. Additionally, in-house developed software is more tailored to the end application, which reduces the memory footprint and, consequently, the cost of the microcontroller. Tailored bare-metal software is also less complex, which is crucial during the verification process when aiming for Functional Safety. Less complex software is easier to verify, further reducing associated costs.

So, is it worth it?

So why are OEMs mandating the use of AUTOSAR? Maybe some tools and processes make functional architecture at the vehicle level easier, or perhaps OEMs have invested in its use and are looking to get a return on their investment.

AUTOSAR may make sense for certain types of applications, but so far, I don’t see where it fits best. It doesn’t seem well-suited for timing-critical applications that require executing complex algorithms quickly. It also seems to be overkill for simple applications, as it drives up hardware and software costs. So, what’s left? Perhaps vehicle-level controllers manage the interaction of other ECUs?

What do you think? Am I off base here? What have you observed in your AUTOSAR development?