How Non-AUTOSAR BSPs Enable ECUs on Small Microcontrollers

Software defined vehicles are pushing High-performance Computing (HPC) and zonal controllers into the spotlight. At the same time, a large part of a car still runs on tiny ECUs built on 8-bit, 16-bit, or low-end 32-bit microcontrollers, often below 512 kB of flash.

These handle climate flaps, seat functions, window lifts, simple sensors, battery monitoring and dozens of other “small” tasks that must never fail.

Classic AUTOSAR basic software is extremely powerful, but its layered architecture, extensive communication stack, and configuration tooling can become heavy on very small controllers.

Experts have pointed out that running the full AUTOSAR stack on 8- or 16- bit controllers is challenging because of code size, RAM footprint and CPU overhead.

For these ECUs, reliability, determinism, and cost efficiency matter more than architectural completeness. This reality has led many OEMs and Tier 1 suppliers to look beyond full Classic AUTOSAR stacks and adopt non-AUTOSAR Board Support Packages as the foundation for basic software.

Non-AUTOSAR Board Support Packages are increasingly adopted for small automotive microcontrollers below 512 kB, especially in ECUs where basic software efficiency, low memory footprint, and deterministic execution are critical.

In contrast to full Classic AUTOSAR Basic Software stacks, a lightweight BSP architecture enables optimized use of flash and RAM while maintaining compatibility with automotive communication protocols and OEM configuration artefacts.

Why Small Microcontrollers Need a Different Basic Software Model

Classic AUTOSAR provides a comprehensive and standardized framework, but it also introduces significant overhead. On small microcontrollers, this often translates into increased memory consumption, higher CPU load, and complex configuration workflows that are disproportionate to the ECU’s functional scope.

Many small ECUs do simple, specific tasks and don’t need much communication. Engineers focus on making them start and run predictably, use less memory, integrate quickly, and work smoothly with OEM diagnostics and network setups. The goal is simple – controlled and reliable operation.

When these constraints define the development strategy, the next logical question becomes what exactly a non-AUTOSAR Board Support Package provides at the technical level.

What’s Included In a Non-AUTOSAR Board Support Package?

A Board Support Package is the lowest reusable software layer that enables an ECU to operate on a specific microcontroller and hardware platform. In non-AUTOSAR implementations for small ECUs, a BSP typically includes several well-defined elements.

At its core are low level drivers that directly control microcontroller peripherals. These drivers handle clock and power initialization, interrupts, watchdogs, timers, GPIO, ADC, PWM, and communication controllers such as CAN, LIN, SPI, I2C, and UART.

Board Support Package Architecture

In the context of microcontrollers below 512 kB, basic software typically refers to:

Application logic, control algorithms, and feature behaviour remain outside the BSP boundary. This separation ensures long-term reuse and maintainability of the platform layer.

When communication drivers are included, they generally operate at the controller level. For example, CAN or LIN drivers provide register access, interrupt handling, and frame transmission and reception. They do not automatically include higher level protocol stacks such as ISO TP, UDS, OBD, or J1939. These protocol layers are added only when required by the ECU’s role in the vehicle network.

Above the drivers sits a hardware abstraction layer that shields the rest of the software from microcontroller specific details. It provides stable APIs for application and middleware layers. Most production-ready BSPs also include boot and memory services such as startup code, flash programming support, non-volatile memory abstraction, and basic self-tests.

Understanding this layered structure naturally leads to a deeper look at how communication functionality is separated and scaled within BSP-based architectures.

Low-level Drivers in BSP vs Full Communication Stack

Licensing expectations for BSP based platforms

In automotive programs, BSPs are treated as platform software rather than per-unit components. They are tailored, validated, and reused across multiple ECU variants and vehicle projects.

As a result, licensing models commonly focus on one time platform licensing, full source code availability, internal reuse across programs and products, and optional long-term maintenance or support. This model aligns with the cost structure of small ECUs, where recurring royalties are often not acceptable.

Beyond licensing, the next architectural decision typically concerns how scheduling and task management are handled on top of the BSP.

Configuration of BSP using OEM artefacts

Even without full AUTOSAR tooling, BSP-based ECUs can be configured using standard OEM artefacts.

LIN Description Files (LDF) define LIN clusters and schedules. CAN DBC files describe messages and signals and support automated generation of communication tables. Diagnostic definitions derived from CANdela or ODX files ensure consistency with OEM diagnostic tools. AUTOSAR ECU Extracts are often used as reference inputs to stay aligned with system level network definitions.

This ability to reuse OEM artefacts ensures that BSP-based ECUs remain fully integrated within vehicle development processes.

With configuration, integration, and architecture clarified, the final question becomes when such an approach is the right engineering choice.

What non-AUTOSAR architecture means in practice

Non-AUTOSAR does not mean isolated from AUTOSAR based vehicle architectures. It simply means that the ECU does not run the full AUTOSAR Runtime Environment and Basic Software stack.

In practical terms, this implies no AUTOSAR RTE, no mandatory AUTOSAR Basic Software modules, and no dependency on ARXML driven configuration for internal software. At the same time, many non-AUTOSAR BSPs follow AUTOSAR inspired design principles. Driver interfaces often resemble MCAL concepts, layering is clearly defined, and communication and diagnostic behaviour aligns with AUTOSAR-based systems.

This alignment becomes especially important when examining how configuration data from OEM ecosystems is applied in BSP-based systems.

Operating system considerations for non-AUTOSAR BSPs

A BSP does not include an operating system by default. It provides the foundation on which either a bare metal application or a real time operating system can run.

For very simple ECUs, a deterministic super loop architecture on top of the BSP is still widely used. Bare metal designs offer minimal overhead and straightforward verification. As complexity increases, the use of a lightweight RTOS becomes beneficial. Multiple concurrent tasks, higher communication loads, diagnostic requirements, or safety constraints often justify an RTOS. The BSP supports this by providing timer services, interrupt handling, and safe driver interfaces.

How the BSP interacts with broader vehicle architectures then brings us to the meaning of non-AUTOSAR in practical terms.

When Non-AUTOSAR BSPs Are the Right Choice

For microcontrollers below 512 kB, non-AUTOSAR BSP-based architectures are suitable when:

It is important to note:

Closing perspective

As vehicles continue to evolve, architectural diversity will remain a reality. High performance controllers and small microcontrollers will coexist, each serving different roles.

For small ECUs, the goal is not architectural purity. It is reliability, efficiency, and long-term maintainability. In many cases, a well-designed non-AUTOSAR Board Support Package remains the most effective way to achieve that balance.

Frequently Asked Questions About Non-AUTOSAR BSP for Small ECUs