AUTOSAR Modularity and Configurability

AUTOSAR Modularity and Configurability

One very human mechanism for managing a complex issue is to divide and subdivide it into manageable components. These smaller and simpler parts can then be addressed individually or by teams, allowing for the possible division of labor while also reducing the difficulty of the entire project.

Likewise, modularity in software is the capacity for a program to be logically partitioned into manageable components. This allows relatively small “chunks” of code to be developed individually, but remain interrelated, because of the way their function is interpreted and used by the whole.

The AUTOmotive Open Software Architecture (AUTOSAR) development platform and standard were first released in June 2005. One main reason for the development of the original standard was to manage the exponentially increasing complexity of automotive electronic control unit (ECU) software. For developers and programmers of electrical and electronic (E/E) systems, one factor that has driven the adoption of the standard over the years is the modularity and configurability of the AUTOSAR platform.

Modularity allows AUTOSAR developers the flexibility to reuse program components and chunks of code. Modular software architecture also works to permit interoperability, the ability of different systems, even non-AUTOSAR systems, to communicate and exchange data in real-time with no additional layers of code. Modular architecture in software also allows multiple components to be developed simultaneously, which can significantly shorten the time to market for large and complex programs.

Contents

• Hardware independence by a layered basic software architecture for automotive ECUs
• Transferability of functional software components within an E/E system
• Resource-optimized configuration of the software infrastructure of each ECU
• Scalability of the E/E system across the entire range of vehicle product lines
• Summary

Hardware independence by a layered basic software architecture for automotive ECUs

Automotive ECUs control the operation of nearly everything in modern Software-Defined Vehicles (SDVs). Safety equipment like airbags, as well as powertrain, brakes, and multiple sensors for Advanced Driver Assistance Systems (ADAS), are just a few examples of systems within a vehicle that depend on ECUs. Over the entire vehicle, there may be over one hundred million lines of program code that define the operation and interoperation of all these systems. In a non-AUTOSAR ECU, this code can be organized according to the developer’s practice. For a developer who has adopted AUTOSAR, this code architecture is organized in a specific standardized manner.

AUTOSAR software is layered in several ways. Overall, in Classic AUTOSAR architecture, there are three main layers called:

• Runtime Environment (RTE),
• Application Layer, and
• Basic Software.

The Basic Software layer is then modularized further again, with modules grouped into layers defined by their similar or related functions.

The stacking of these function layers, with abstraction layers in between, is what makes the Basic Software Layer hardware-independent. Abstraction conceals the Application Programming Interface (API) which allows applications to inter-communicate. The abstraction layer shields underlying hardware information from the layers above and offers a specific set of services without referencing the hardware. In practice this means that an AUTOSAR-compliant ECU program can run on hardware from multiple sources; in other words, it is not dependent on one specific hardware architecture. Hardware designers and Original Equipment Manufacturers (OEMs) find this AUTOSAR feature especially useful in porting code between hardware platforms, or in between entire vehicles, with very little work involved regarding coding changes.

This ability to be independent from specific hardware leads us to another aspect of modularity. Not only is AUTOSAR basic software independent of customer-specific hardware, but also customer hardware is not necessarily dependent on AUTOSAR. This is to say, that if a developer builds a tool in the AUTOSAR framework, that tool can be used in any AUTOSAR system.

Transferability of functional software components within an E/E system

In modular architecture, software components can be reused or transferred into multiple modules to fit whatever need arises. This often means a new component would not necessarily need to be written; a programmer could just pull one from a tool library or transfer an existing component from one module to another. This makes adding a new function much easier and also aids in speeding up the development of the entire project.

Within the AUTOSAR programming framework, transferability is a direct result of modularity. This is because modularity is in effect “all the way down.” What this means is that not only is the entire program divided into modules, but also that the self-contained software component units are designed to be modular, interoperable, and transferable. They can almost be thought of as individual units of a specific function, rather than as packets of programming code. The interfaces of software components, which determine and specify how those components communicate and interoperate, are specific to the software components and not to the underlying hardware infrastructure. This allows software components to be transferred from one type of ECU to another, or from one vehicle to another.

Transferability gives developers and programmers the ability to reuse a software tool or component between multiple ECUs and even multiple vehicle platforms. A new software component does not always need to be developed for a particular function when an existing one can be brought in from the AUTOSAR library. This is especially helpful when considering that a vehicle may contain ECUs from multiple suppliers with differing hardware configurations or interfaces. AUTOSAR’s transferability and hardware abstraction help reduce development costs by saving time in designing tools or software components for every application.

Resource-optimized configuration of the software infrastructure of each ECU

AUTOSAR’s modularity abstracts hardware above the basic software level to remain independent of hardware configuration. However, there are ways in which the AUTOSAR programming framework specifically deals with ECU hardware configuration. In the AUTOSAR document, “Specification of ECU Configuration¹,” the concept of optimizing software component configurations to specific ECU resources is explained in detail. This optimization customizes the software component to use the available hardware resources in the most efficient way. This way, the ECU software will run effectively with minimized usage of memory and processing power. This can still be accomplished while abstracting hardware details from the upper software layers. As the AUTOSAR Configuration document states:

“…It is possible to describe AUTOSAR-standardized and vendor-specific ECU Configuration Parameters with the same set of language elements. This eases the development of tools and introduces the possibility to standardize vendor-specific ECU Configuration Parameters at a later point in time.”

The multiple hardware configuration parameters built into the AUTOSAR framework can aid programmers in optimizing a wide range of resources and aspects of programming for the ECU and the eventual usage in the vehicle. These include:

• Selection of components: Helps to avoid the inclusion of redundant or unnecessary components, as well as selecting the best-performing components for the task or function.
• Adaptation of hardware: Identifying the hardware capability of the ECU’s architecture and matching those specific capabilities to capitalize on its strengths within the software component’s configuration.
• Managing memory and processing power: Configuring software components to use the ECU’s available resources with greater efficiency, leading to cost-efficient performance improvement.
• Safety and security, including cybersecurity: Software configurations using resource optimization are valuable for quality control regarding safety-critical functions.
• ECU build documentation: Complete and clear records of the software in use, including justifications and change tracking, assist in not only performing diagnostics but in upgrading and scaling efforts, as well.

Optimizing AUTOSAR software component infrastructure configuration for the particular build and resources available in each ECU contributes to better performance with more efficient resource usage, effective diagnostics capabilities, and improved scalability.

Scalability of the E/E system across the entire range of vehicle product lines

The scalability of the electrical and electronic (E/E) systems, especially within a scope as large as a manufacturer’s entire vehicle product range, can be affected by several details. However, AUTOSAR’s modularity and configurability are significant factors in making this possible.

Modules of AUTOSAR software components can be adapted to different ECU models, especially with resource-optimized configuration (see above). One thing this means is that software components can be reused across the range of vehicle products, adapting to the functional requirements of different ECUs as required.

Scaling software components versus building new modules can lead to faster development time and cost savings. Using AUTOSAR’s scalability also improves the diagnostic behavior of the ECU and its programming because the software, by the time it has been “scaled up,” has already been proven in earlier iterations. As a known and familiar entity to programmers, scaled-up ECU software is easy to use and this familiarity helps speed time to market. In addition, it may even seem familiar to customers, for a consistent user experience across vehicle models and even across product lines.

Summary

While automotive electronic control units (ECUs) are becoming increasingly complex at a rapid rate, the AUTOSAR programming framework and manufacturing standards are valuable tools to assist developers and programmers in taming this complexity and finding a clear path to success in the future. The modularity and configurability of AUTOSAR programming are invaluable central aspects of the programming framework, allowing massive ECU programs to be understood and developed in smaller, more controllable component pieces. Developing modular programs for automotive ECUs allows these programs to get to market as fast, efficient software that can be easily adapted and scaled as functions change and new needs arise.

1. AUTOSAR, “Specification of ECU Configuration.” 30. November 2020. https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_TPS_ECUConfiguration.pdf