notice

AUTOSAR Adaptive Platform and MICROSAR Adaptive

MICROSAR Adaptive is a product of Vector that supports the AUTOSAR Adaptive Platform.

The development of an Adaptive Application differs from the development of a Classic Application. Learn more about how an Adaptive Application is structured and organized:

Organization of an Adaptive Application

The illustration below is a schematic drawing of an Adaptive ECU on the left side and a Classic ECU on the right that are connected via Ethernet.

They are designed in a very different way to see the differences at a glance. The folder symbols in the Adaptive Application are chosen to emphasize that its structure is similar to a file explorer on a PC.

Conceptual Illustration
Conceptual Illustration

AUTOSAR Classic

In AUTOSAR Classic an ECU is organized via different software components (SWC), connected to the Basic Software via the runtime environment (RTE). This means that there can be many software components that use one AUTOSAR stack organized by an AUTOSAR Operating System with predefined tasks, events, alarms, etc.

AUTOSAR Adaptive

The organization of program code within adaptive software is different as it utilizes a POSIX-like OS for example Linux, QNX or PikeOs. Program code is organized in a folder structure that resembles app development for mobile devices. An Adaptive Application is conceptually a directory situated at a specific location in the POSIX-OS file system, housing the necessary executables.

User Application vs. BSW Application

In the Adaptive AUTOSAR Platform, applications can be categorized into two main types: User Applications (blue) and Basic Software (BSW) Applications (red).

PPTX_MoreThanExecutables

All Adaptive Applications are designed to communicate with one another, which is essential for ensuring the effective functioning of an ECU.

User Applications (blue)

PPTX_UserApplications

From the functional point of view, you can compare the User Applications with the Software Components (SWC) in AUTOSAR Classic. These applications are responsible for the actual function of the ECU like e.g., Seat Adjustment or Lane Assist. They consist of the functional customer software and the functional necessary parts of the BSW.

These parts of the BSW either implement a complete functionality or just enable communication to other User Applications or to other parts of the BSW that are implemented as BSW Applications.

PPTX_BSWApplication

BSW Applications (red)

BSW Applications are Adaptive Application that are provided by Vector as part of the MICROSAR Adaptive delivery.

In AUTOSAR Classic these are the Basic Software Modules.

In Adaptive, several basic software modules are implemented as Software Components in their own Applications. These BSW Applications can in turn make use of other BSW functionality in the same way as already mentioned for the User Applications above.

notice

A good saying!

With MICROSAR Classic you embed the User Application (Software Components) into the Basic Software.

With MICROSAR Adaptive you embed parts of the Basic Software once into each individual Adaptive Application, where you need the provided functionality.

Structure of an Adaptive Application

Executable of a User Application

The Executable of a User Application encapsulates the Application Logic with the necessary interfaces and implementation details provided by the BSW package for example COM, PHM, LOG, OS and vac. See MICROSAR Adaptive Clusters.

Some components of the BSW offer a direct interface to the User Application Logic (see illustration: ara:: connected with a line) and some components map internal implementation details.

Lane Assist Executable contains the application logic as well as the necessary interfaces and implementation details from the BSW package.
Lane Assist Executable contains the application logic as well as the necessary interfaces and implementation details from the BSW package.

Main function

Any User Application needs to have the function main{} that is also its entry point. This function must be provided by the application developer.

To use the services of the BSW one of the tasks of the main{} function is to initialize the BSW. During the initialization phase, the BSW reads in its configuration data that is stored within JSON files (see light blue boxes in Figure 1).

Folders

The following illustration gives insight in a real folder structure of an Adaptive Application. Basically, there are three folders: bin, etc and var.

DriverAssistance File View with the typical folder structure of an Adaptive Application.
DriverAssistance File View with the typical folder structure of an Adaptive Application.

bin

The system expects the executables within the bin folder.

etc

All configuration files like above mentioned JSON files are stored in the etc folder.

var

Volatile data of the Adaptive Application (data that is forgotten when the application is stopped) should be stored to the folder var.

notice

Per configuration you can set the var folder as necessary for your Adaptive Application.

notice

someipd-posix-application.json of folder etc

This configuration file describes which ara::com services the application offers and which services it needs from outside (for more information about services oriented communication see Service Oriented - a Flexible Communication Concept.

Which files must be in this folder depend on the BSW services that are used by the Adaptive Application. As an example, PER (Persistency) is only included when the function persistency is needed.

Executable of a BSW Application

A BSW Application follows the same rules as already described for User Applications. The Executable of a BSW Application contains the actual application logic as well as the necessary interfaces and implementation details from the BSW package. In the case of PhM this is PhM Application Logic and vac.

Phm Executable encapsulates the application logic with the necessary details from the BSW.
Phm Executable encapsulates the application logic with the necessary details from the BSW.