Understanding AUTOSAR’s Basic Software Layer

Understanding AUTOSAR’s Basic Software Layer

The AUTomotive Open System Architecture (AUTOSAR) development platform is a powerful tool for programmers and developers working on automotive electronic control units (ECUs), the specialized and dedicated microcontrollers for automotive applications. The benefits of developing applications for an ECU in AUTOSAR or AUTOSAR-compliant frameworks include:

• Standardization and improved communication between components
• Compliance with customer needs
• Software standardization and interoperability of developed tools, and
• Reduced costs

However, for programmers or developers who are unused to the development tools and systems specifically in or for AUTOSAR, there might be challenges to overcome. These may include development personnel's unfamiliarity with specific AUTOSAR terminology and the fact that the standard itself can at times be abstract.

When considering whether now is the right time to undergo AUTOSAR training or request a consultation for help in achieving AUTOSAR compliance, it could be helpful to think about the way these software tools are built and integrated, and how they interact with the standard and the programming framework. Understanding AUTOSAR’s basic software layer (BSL), the architecture and components, their functions, and their interdependencies can help developers and engineers decide how much aid is needed for their organization to be able to use AUTOSAR effectively – and to achieve compliance with the standard.

The basics of AUTOSAR

The framework and its origin

AUTOSAR is an organization as well as an automotive software development standard. The AUTOSAR framework was originally released in 2003 through the efforts of a global community of partner organizations. These were the original Core Partners. This community of original equipment manufacturers (OEMs) and their suppliers came together to combine their expertise and formulate a standard that would benefit all, even as they continued to compete with one another in the market. AUTOSAR continues to help organizations that were not part of the original core partnership agreement, bringing the advantages of standardization, ease of programming, and the rapid scaling properties of the framework’s modular architecture to developers all over the world.

For context, although today’s focus is the BSW, please note that the Runtime Environment and application layer can be subdivided into components for further discussion of their internal architecture and details of operation. The RTE, with its Virtual Function Bus (VFB), provides interfaces between applications and communication between the upper and lower levels (application layer and BSW), while the application layer, fully abstracted from the hardware, gives the ECU access to other ECUs, as well as vehicle services functions.

The graphic illustrates this arrangement within ECU software architecture. Some details are combined or abstracted for simplicity, but it is important to understand the arrangement and interaction of the AUTOSAR-specific layers of software components within the ECU and how that ECU’s software interacts both with the network of other ECUs within the larger system comprising the vehicle, and with its own hardware via the lowest-level layer in AUTOSAR architecture, the basic software layer.

The layers

The AUTOSAR platform divides ECU software into three main layers: the Runtime Environment (RTE), the application software layer, and the basic software layer (BSW). Since the AUTOSAR standard favors a “from the bottom up” approach to constructing ECU software, it is fitting to spend some time examining this software at the very bottom of the stacked layers AUTOSAR builds, as it is not only the operation foundation but also the first layer to be built when developing software for a particular ECU. The BSW layer is responsible for interfacing with hardware and for executing the basic functions of the ECU. Understanding this layer of AUTOSAR’s ECU architecture will give organizations a starting place for understanding the higher-level layers of AUTOSAR, and the entire standard and framework.

What is the AUTOSAR basic software layer?

The core partners recognized that a major trend in automotive production was the increasing reliance on embedded control units (ECUs) and that the code running on those ECUs would also increase exponentially in complexity and sheer volume. Current production vehicles typically use over a hundred million lines of code, so the core partners were right about that. Further along the timeline of this trend, it was expected that automobiles would continue to evolve into a construct resembling a mobile collection of ECUs and related hardware more than they resembled the vehicles of the past. AUTOSAR is one of several industry-wide collaborative standards that appeared around the same time to help make this controller proliferation more manageable.

AUTOSAR utilizes an architecture made of three primary layers (the main pillars) to organize the operations within an ECU. At the “top” is the application layer, which is agnostic regarding what hardware it’s running on. Acting as a buffer zone between the top and bottom layers, the runtime environment (RTE) provides full interface options for all applications. Finally, at the “bottom,” is the basic software layer. It’s considered the lowest layer because, in the AUTOSAR nomenclature of layers and abstraction, the BSW is the closest to the actual microcontroller hardware. The BSW is also the layer that, of the three main components of AUTOSAR, is the most dependent on the hardware. That is, basic software must be configured for the particular microcontroller it is running on. The BSW layer then abstracts controller hardware from the RTE and application layer, hiding the details of the lower levels from the higher ones, and leaving only programming interfaces exposed for communication between levels. These interfaces (application programming interfaces or APIs) are the only avenues for communication between the main levels of AUTOSAR.

Components and functions within the basic software layer

As we "drill down" deeper into the BSW layer, we see it can be deconstructed even more, into sub-component layers, or functional groups, detailing the BSW's internal infrastructure.

The main functional groups may each be made up of multiple applications, as well.

The Services layer (the uppermost layer of BSW) for example, may include the system, memory, and communication services groups, as noted, but may also provide crypto, diagnostic, or off-board communications services, as needed. The services layer houses the BSW’s operating system (OS). The OS, in turn, sets up an application-layer interface which acts like a superhighway bypass, sending task scheduling commands and other information directly from the application layer (very top) to the microcontroller (very bottom). There are other such superhighways and “trap door” workarounds for abstraction built into the architecture of AUTOSAR, and one truth about this programming platform is that we cannot talk about the details of the subcomponent layers without considering the entirety of AUTOSAR architecture.

The ECU abstraction layer is the next level down from Services within the BSW. This layer rests atop the microcontroller abstraction layer (MCAL), abstracting the MCAL from the upper layers of the ECU’s software. Developers often leverage this “double-abstraction” effect as they work to make the upper layers of the ECU agnostic or independent of hardware configuration.

A note about the use of abstraction in AUTOSAR:

In the introduction, it was mentioned that at times the AUTOSAR standard can be abstract and theoretical. One point where difficulty may be found is in the extensive use of abstraction. Discussion of the interaction between the ECU abstraction layer, MCAL, and other components of AUTOSAR architecture are examples of this.

Abstraction, in the ECU software development sense, and especially in the AUTOSAR development sense, is a practice where the concealment of underlying details of a software component or tool’s functions is built into the design and implementation of the development platform. Abstraction conceals most of the intricate coding details of each layer from some or all the layers above it. This helps streamline the operation of the ECU, presenting the lower layers to the upper ones as isolated and insulated modular components with simple, well-defined, and standardized Application Programming Interfaces (APIs) as their means of contact and communication.

Besides streamlining the operation of the hundred-million-plus lines of code running within the full vehicle, the isolation aspect of abstraction helps in the placement of functional safety mechanisms. In addition, AUTOSAR’s use of standardized APIs between abstracted layers helps abstraction to act as a barrier to unauthorized access or manipulation of data. Abstraction and the layered architecture of AUTOSAR make this development platform especially useful when implementing cybersecurity measures or certifying development processes to the ISO 26262: Road Vehicles – Functional Safety standard.

Below the ECU abstraction layer, at the bottom of the stack of basic software, is the microcontroller abstraction layer or hardware abstraction layer (MCAL or HAL). This layer, finally, contains the interfaces, drivers, and registers for the specific hardware of the microcontroller which the ECU operates through its software. The HAL/MCAL works with the ECU abstraction layer and all the basic software to abstract as much specific information about the hardware and the base code as possible, to make most of the ECU’s software hardware-independent.

The complex drivers are not another sub-component layer or function group within the basic software layer but rather work within all the functional groups to manage complex functions, including managing the abstractions between layers and the operation of the APIs.

The BSW’s typical role and prime function in AUTOSAR architecture

AUTOSAR basic software’s abstraction-focused construction allows developers to treat the ECU somewhat like a containerization tool. The BSW secures the interface between the ECU and the microcontroller hardware, controlling the exchange of data and instructions. This ensures that modular ECU software components can be developed in a largely hardware-agnostic environment. Software components can be developed more as individual standalone units of function, rather than of code, and they will work on multiple hardware types because they’ve been developed independent of hardware concerns. The abstracted hardware adjacent layers permit the software to affect the hardware only through standardized programming interfaces which are well defined and built directly into the software.

The abstraction inherent in the BSW means that developers can build software modules or componentry for current or future functions without knowing what microcontroller they’ll be installed on, or even develop updates for software running on an existing ECU, without knowing the specifics of its hardware.

The basic software layer’s subcomponents and function groups work together to implement APIs for communication between layers and components, modularize and abstract hardware dependencies as well as software components’ access to one another throughout the ECU’s architecture. The BSW is also the focus of AUTOSAR’s compatibility with functional safety and cybersecurity standards.

Summary

The power of the AUTOSAR platform lies in its ability to produce streamlined, portable, and hardware-independent ECU operation software that is scalable, can be made functionally safe, and works well with cybersecurity standards. AUTOSAR promotes “bottom-up” development and the basic software layer, at the base of all AUTOSAR architecture, is the foundational construct of the entire platform. For organizations investigating their need for AUTOSAR-related training, engineering capacity, or consultation, we hope this look at the basic layer provides a firm foundation of understanding for that investigation.