Introduction to AUTOSAR OS operating system architecture and startup process

01.

Preface

In the field of traditional automotive electronics development, the OS used in the early days was OSEK OS, which is a real-time single-core operating system (RTAOS) designed to meet the requirements of automotive electronics reliability, real-time performance, and cost sensitivity.

Classic platform AUTOSAR OS inherits OSEK OS. On the basis of OSEK OS, it specifically specifies the following system services that AUTOSAR OS needs to provide at least:

Priority-based scheduling;

Ability to handle interrupts in a timely manner;

The interrupt priority must be higher than Task;

Create a startup interface through StartOS() and StartOSHook();

Create a shutdown interface through ShutdownOS() and ShutdownOSHook();

Apps that can run in OSEK OS can naturally also run in AUTOSAR OS, but at the same time, AUTOSAR OS also limits some basic uses of OSEK OS.

02.

AUTOSAR OS Operating System Architecture

2.1 Processing levels of OS layer 3

(1) Interrupt level

(2) Logic level

(3) Task level

At the task level, tasks are scheduled according to their user assigned priority (none, full or mixed preemptive scheduling), runtime-wise, they are occupied at the start of their execution time, and are released again when the task is completed.

The following are the precedence rules definitions:

(1) Interrupts take precedence over Tasks;

(2) The interrupt processing level consists of one or more interrupt priority levels;

(3) The interrupt service process has a static priority standard for allocating interrupts;

(4) The priority of the interrupt service routine depends on the execution and hardware structure;

(5) Task priority is statically assigned by the user;

(6) 0 is the lowest priority, and the larger the value, the higher the priority.

2.2 Task Conformance Class

AUTOSAR OS defines four compliance classes, namely BCC1, BCC2, ECC1 and ECC2, based on different software and hardware requirements, the number of tasks that may be available at each priority level, and whether basic tasks or extended tasks are required.

BCC1 and ECC1 do not support multiple task activation requests and each priority level can only have one task; BCC2 and ECC2 support multiple task activation requests and also support multiple tasks at each priority level. The compatibility relationship between various compliance classes is shown in the following figure:

(1) BCC1 (only for basic tasks, all tasks have different priorities, and are restricted to only one request to activate each task and only one task of each priority);

(2) BCC2 (like BCC1, but each priority can have multiple tasks and allow multiple requests to activate tasks);

(3) ECC1 (like BCC1, with additional extended tasks);

(4) ECC2 (like ECC1, but each priority can have multiple tasks and allows multiple requests to activate the Basic Task);

03.

Task Management

3.1 Task State Mode

There are two types of tasks in AUTOSAR OS: Basic Task and Extended Task. Basic tasks have the following three states:

(1) Running state: A task in the running state may be preempted by a high-priority task or interrupt and enter the ready state. In the same Core, there is only one task in the running state at any time. After the task is finished running, it will suspend itself and enter the blocked state.

(2) Ready state: The scheduler decides whether to start a task in the Ready state and whether to start it in the Running state. This state is the prerequisite for the task to switch to the Running state.

(3) Blocked state (Suspend): The task in the blocked state is passive and can be activated by the API function or Alarm to enter the ready state;

(4) Waiting state: Compared with extended tasks, extended tasks have this state. When the execution of a task needs to wait for one or more events to be set, the task enters the ready state.

The state machine switching between basic tasks and extended tasks is shown in the following figure:

Basic tasks have no waiting state, so they can only be synchronized when the task is started and ended. The advantage of basic tasks is that they take up less task and execution time.

Extended tasks contain multiple synchronization points without the hassle of synchronization requests. When further conditions cannot be met, the task will switch to a waiting state. Its disadvantage is also obvious, and it will take up more memory and execution time.

3.2 Task Scheduling Strategy

3.2.1 Fully Preemptive Scheduling

For a fully preemptive task scheduling strategy, the currently running task can be interrupted by a high-priority task at any time and forced to release processor control. The task with the highest priority switches from the ready state to the running state, and the current task is preempted and enters the ready state, while retaining the on-site environment and restoring it at the next run.

The following figure shows a fully preemptive task scheduling strategy. TaskA is an extended task, TaskB and TaskC are basic tasks, and the priority is TaskA > TaskB > TaskC.

Scenario 1:

Currently, TaskC is in the running state. When TaskB is activated and enters the ready state, TaskC is forced to release the processor control right because TaskB has a higher priority than TaskC. The scheduler starts to schedule TaskB from the ready state to the running state. After TaskB finishes running, TaskC is scheduled to continue running.

Scenario 2:

Currently TaskC is in the running state, and TaskA and TaskB are activated to enter the ready state. Since TaskA has a higher priority than TaskB, TaskA preempts the kernel to run. However, since Resource1 is still occupied by TaskC, TaskA cannot access the shared resource Resource1, so it is forced to enter the waiting state, and TaskB starts running. After TaskB finishes running and hangs up, TaskC is re-run. After TaskC finishes running, Resource1 is released, and TaskA is able to enter the running state from the waiting state.

At this point you will find that the high-priority task TaskA cannot run before TaskB because shared resources are occupied. This phenomenon is also called priority inversion.

In order to solve this problem, it is necessary to mention the priority ceiling mode of AUTOSAR OS: the priority of tasks accessing shared resources is raised to the highest priority of shared resource tasks during the process of occupying resources, thereby avoiding the occurrence of priority inversion.

That is, if TaskC occupies the shared resource Resource1 during its execution, even if a high-priority task TaskA that also needs to occupy shared resources is activated, TaskA must be executed only after TaskC is finished running. This means that before important code is executed, a resource protection mechanism should be adopted to avoid being interrupted by high-priority tasks.

3.2.2 Non-preemptive scheduling

Using a non-preemptive scheduling strategy, the currently running task will not be preempted by other high-priority tasks at any time, and task switching will only occur when the task is completed.

The problem with the non-preemptive scheduling strategy is that the task execution time is uncertain and the real-time performance of the system scheduling is poor. The following figure shows the non-preemptive scheduling strategy. It can be seen that even if the high-priority task TaskB is activated and switched to the ready state, it must wait until TaskC is executed before it can be scheduled.

04.

Task Scheduling

4.1 AUTOSAR Task Scheduling Timing Diagram

When designing the software architecture, in order to ensure the CPU load rate and the prerequisites of the task, it is necessary to define the Runnable of each SWC and design it according to the properties of the SWC, as shown in the following figure.

In principle, some main rules need to be defined:

(1) If SWC does not have high time requirements, try to extend the Runnable time.

(2) For the same Task Runnable, you can design multiple Tasks and set Offsets to avoid running Tasks in the same cycle at the same time.

Task scheduling sequence diagram

4.2 AUTOSAR Task Scheduling Structure Diagram

In software architecture design, in order to make the software architecture clearer, it can be divided into three categories:

(1) ECU task processing at idle and idling;

(2) Task processing when the ECU is powered on or awakened, powered off or asleep, as well as bus communication tasks and message processing tasks;

(3) Task processing when the ECU is running in Normal mode (here it mainly processes and executes the tasks required for the function);

Task scheduling structure diagram

05.

AUTOSAR OS system startup

5.1 Introduction to the OS boot process in the OSEK specification

After the processor is reset, the initialization process is implemented, but the OS provides a standard method to support initialization. The OS and the application must clearly define the hardware initialization function.

After the OS is initialized, the OS does not force a special task to be started, but allows the user to specify automatically started tasks and alarms when the system is created. After the CPU is reset, the hardware standard application function is executed (without the intervention of the operating system).

For example, after the OS is initialized (the scheduler is not running), StartOS calls the hook function StartupHook(), where the user can add some initialization code for his OS. Based on

the application mode started, in order to structure the initialization code in StartupHook(), a GetActiveApplicationMode service is provided for this purpose . After returning from the hook function, the OS starts the interrupt and starts the scheduler

. After this, the system runs and executes the user's Tasks.