AUTomotive Open System ARchitecture (AUTOSAR) Standardized Interfaces

AUTomotive Open System ARchitecture (AUTOSAR) Standardized Interfaces

Standardized AUTOSAR interfaces are one of three types of interfaces between individual modularized software components that are utilized in the AUTOSAR programming platform. This type of interface is predefined by the AUTOSAR standard. The differences between all three of the separate and specific types of software interfaces determine how they are used when programming AUTOSAR-compliant electronic control units (ECUs).

Contents

• Standardized application programming interfaces (APIs) and service interfaces
• Facilitate encapsulation of functional software components
• Definition of data types of software components
• Summary

All three interfaces (AUTOSAR interface, standardized interface, and standardized AUTOSAR interface) work together within an ECU’s programming to allow the various software components to communicate and interact. They all operate by their own defined individual rules. To differentiate the types of software component interfaces found in AUTOSAR, we can look at what data they provide within the programming interface, and at the ports they are allowed to use, or the ports they are restricted from using. Because they all operate within an ECU’s code and their names are quite similar, a closer look at their distinct separate tasks is in order. Some of this information is available in the AUTOSAR document, “Layered Software Architecture¹.”

• An AUTOSAR Interface is considered a “generic” interface and is the least specific of the three types. These are found at the ports of software components (SWCs), whether an application, sensor, or actuator component. These interfaces are how SWCs communicate with each other and with the ECU’s firmware (the “BIOS” or low-level hardware control software for an ECU’s specific hardware configuration).
• A Standardized Interface is an application programming interface (API) that the AUTOSAR standard has predefined with specific rules, conventions, and roles. This must be in the C programming language. This interface is used for basic software modules – those below the runtime environment (RTE) – to communicate with one another, as well as for information exchange between the RTE and the operating system.
• The Standardized AUTOSAR Interface is also defined and given standardized, unique syntax and semantics in the AUTOSAR standard. Standardized AUTOSAR interfaces are specialized AUTOSAR interfaces typically used for communication between the Basic Software layer and individual service software components, or between basic layer services and the AUTOSAR runtime environment.

The reason these software module interfaces are defined in the AUTOSAR standard, and the reason that they appear in the “layered architecture” publication from the AUTOSAR organization, is that these interfaces are the way the separate AUTOSAR layers interact with one another. Modules located in different layers need to exchange data for the ECU to operate, and AUTOSAR layered architecture with abstraction, or “hiding” of the low-level ports and other components, requires unique and specific ways for this data communication to take place.

Next, we will examine the qualities and benefits which this architecture entails.

Standardized APIs and service interfaces

Standardized APIs, or application programming interfaces, such as the three types of standardized AUTOSAR interfaces, assist in making ECU programs more universal. APIs largely process and relay requests, from either a user or from another software component within the ECU, and send that request to either a component, the RTE, or microcontrollers in the basic layer. The more these interfaces are standardized, the more scalable, flexible, and maintainable the ECU software becomes.

Not only can the software components be scaled up or down to fit specific unique applications, and reused with minimal effort in subsequent projects or even different vehicle platforms, but the standardized interfaces mean that there will be very little need for duplicated effort or time in development for an interface or module which already exists in the standard library. Standardized interfaces are also flexible enough to be used in applications they were not originally developed for, as communication coordinators between new function or feature components.

Standardization of the APIs in AUTOSAR also improves the efficiency, compatibility, and error control of code maintenance within the entire ECU. If software or a particular software component using a standardized interface requires updating or replacement, this can often be done without disrupting the rest of the software in that ECU. This is because, provided the standardized interface stays the same, other components that also communicate through that interface will mostly not require modification.

Facilitate encapsulation of functional software components

Encapsulation is a software architecture feature, related to abstraction, which also similarly works to restrict access or “hide” some data or function portion of a software component. Encapsulation bundles or wraps certain data together with functions that perform actions on that same data into a single body or unit. This function assists in abstracting complex details by wrapping or confining all the relevant details within the software component and then providing access to the component through standardized interfaces.

Encapsulation can help secure the data of the software component. This works to assist functional safety and cybersecurity efforts, partly by making sure that the code within the component is not necessarily affected by code external to the component, except in predictable and expected ways. When using encapsulation, the function of the component is described in a single location, rather than multiple locations, leaving fewer possible points of error intrusion.

Additionally, encapsulation not only contributes to cybersecurity (by “hiding” data and ensuring only specific, defined, and standardized interfaces are used) but also to the AUTOSAR tenets of flexibility and reusability. This is due to the independent and individual design of the software component modules. As long as the standardized interfaces are consistent with the original design, the modules can be reused in new ECU projects, reducing rework and new design work.

Encapsulation maintains the modularity of AUTOSAR software components, meaning breaking down and organizing a large complex software system into relatively small, independent components with well-defined boundaries. This is another basic tenet of AUTOSAR, contributing to the flexibility and reusability of software components, as well as to the accelerated speed of development since the functions of the reusable software component modules are well-defined and can be pulled from the AUTOSAR library and reused in multiple ECUs as their functions dictate.

Definition of data types of software components

The three varieties of AUTOSAR standardized interfaces are especially important to define the data types within individual software components, what functions they are meant to perform, and how they interact in the larger scope of the ECU code. All data types are expected to be compatible with the application layer, however.

Because AUTOSAR provides a specific definition for two out of the three standardized interfaces used in programming AUTOSAR-compliant ECU code, the AUTOSAR framework also provides a template for each type of interface. The templates help define the type of data each specific interface type will be able to handle, and what types of operations the interface and data will then be called upon to support.

The AUTOSAR standard associates operations and communication patterns with particular data types and particular interfaces, then defines communication contracts for each type, outlining expected behaviors and rules for information exchange. For example, one such set of communication rules (or template) within the AUTOSAR standard is the client-server interaction, wherein a client sends a request and a server sends a response. As in all AUTOSAR interface templates, the client and server in this case must send data that is formatted to comply with the expected AUTOSAR-compliant data types.

The case of the client-server interaction, or, for example, the publish-subscribe rule set, where “publisher” interfaces send data out to “subscriber” interfaces set to receive it, are simple examples of the multiple versions of AUTOSAR-type interface mechanisms.

Summary

AUTOSAR standardized interfaces provide communication and data exchange between the modularized software components in an automotive electronic control unit (ECU). The three separate types of interface all have specific roles defined in the AUTOSAR standard and perform specific functions within the ECU’s code.

Whether to aid in standardizing the APIs and service interfaces, support the encapsulation of modularized software componentry, or help define the data types within those software components, AUTOSAR standardized interfaces hold a crucial place in any developer or programmer’s toolkit.

Standardized interfaces are integral to the layered architecture of AUTOSAR-compliant software code, and they comprise part of the framework that works to ensure that functional safety and cybersecurity, especially, are supported in an AUTOSAR-compliant ECU software component. These standardized interfaces are also partly responsible for the easy maintainability, flexibility, and reusability of AUTOSAR code. Though they are only one small part of the entire bulk of ECU code produced within the AUTOSAR framework, their impact cannot be overstated.

1. AUTOSAR.org. "Layered Software Architecture." 30. November 2020. https://www.autosar.org/fileadmin/standards/R20‑11/CP/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf