
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
- User Application vs. BSW Application
- Structure of an Adaptive Application
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.

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).
All Adaptive Applications are designed to communicate with one another, which is essential for ensuring the effective functioning of an ECU.
User Applications (blue)
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.
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.

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.

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
.

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.

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

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.
