OS of AUTOSAR Basics (Part 1)

OS of AUTOSAR Basics (Part 1)

foreword

First of all, I would like to ask you a few small questions, you know:

• Why does the automotive electronic ECU need to use the OS, and where is its necessity?
• How to realize task switching during the running of ECU software?
• How does the multi-core system OS start or shut down cooperatively?
• 。。。。。。

Today, let's explore and answer these questions together. For ease of understanding, here is an outline of the topic of this article :

---

text

Why use OS?

We know that the traditional " bare metal programming " is programming without an operating system, and bare metal programming can meet the requirements when the system requirements are relatively simple. However, as the system requirements become more and more complex, modular design methods and multi-task programming ideas are required at this time, otherwise the maintenance cost of later software upgrades will increase sharply.

Although we can use traditional programming methods (such as counters and state machines) to achieve simple scheduling of multiple tasks, when it comes to state switching between multiple tasks, priority, on-site protection, execution time control, etc. It's laborious, development inefficient and extremely error-prone.

At this time, a mechanism is urgently needed to complete the scheduling function between various tasks for us, so that developers can pay more attention to the development of application software and improve the efficiency of software development. For this reason, **OS (Operation System)** came into being. pregnancy! In fact, the OS mainly solves the following basic problems for us:

• Change the execution frequency of each task;
• Change the execution time of each task;
• Set the priority of each task to ensure that high-priority tasks can be executed in time;
• On-site protection and recovery during task switching;
• Security access mechanism for shared resources, etc.;

The scheduling function is the core component of the OS, and the main function is to switch tasks. In a single-core system, multitasking can only be executed concurrently. The time slice rotation method is used to switch tasks, and a clock interrupt or soft interrupt is used to trigger a task switch, thereby interrupting the current execution task, and the scheduler grabs CPU control. to perform task scheduling and switch to a new task to start execution, as shown in Figure 1 below:

Figure 1 OS scheduler function

In the field of traditional automotive electronics development, OSEK OS was used in the early days , of which OSEK is the abbreviation of "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug" in German, which translates to automotive electronics open system and interface . OSEK OS is a real-time single-core operating system (RTAOS) built to meet the needs of automotive electronics reliability, real-time, and cost sensitivity .

The real-time single-core operating system has the following basic features and basic system services, as shown in Figure 2 below:

Figure 2 Basic features of OSEK OS

AUTOSAR OS contacts OSEK OS

First of all, AUTOSAR OS is based on the inheritance and development of OSEK OS, so the basic features of OSEK OS mentioned above can be satisfied in AUTOSAR OS, so AUTOSAR OS is backward compatible, which means that applications that can run on OSEK OS Programs can also run on AUTOSAR OS.

In addition, AUTOSAR OS also has some unique basic characteristics of its own. The following will start from the basic attributes of the OS and the basic services of the system:

Basic properties

On the basis of OSEK OS, AUTOSAR OS still needs to ensure the following important attributes in addition to the above-mentioned basic features:

• It is static configuration and scaling expansion;
• Support real-time performance inference;
• Provide priority-based scheduling policy;
• Provides protection functions (memory, timing, etc.) at runtime;
• Manageable on low-end controllers;

system service

AUTOSAR OS inherits OSEK OS, and on the basis of OSEK OS, it is particularly clear that the system services that AUTOSAR OS needs to provide at least are as follows:

• priority-based scheduling;
• Ability to handle interruptions in a timely manner;
• The interrupt priority must be higher than the 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;

AUTOSAR OS basic objects

AUTOSAR OS contains the following 6 basic objects: Counter, Alarm, Schedule Table, Task, ISRs, Resource . These 6 basic objects must belong to an OS Application, which can be simply understood as the OS Application is the container of the above-mentioned 6 basic objects , and the basic objects belonging to the same OS Application can access each other, and the basic objects from other OS Applications need to be Restricted access by configuration.

As shown in Figure 3 below, the basic meanings of the six basic objects are listed:

Figure 3 6 basic objects of AUTOSAR OS

These six basic objects, OS Application and Core, have a certain relationship. In order to better understand the relationship between them, Figure 4 below clearly describes the relationship between the three.

Figure 4 Basic object relationship in Core

As shown in the figure above, taking a single core as an example, each Core can contain 1~N OS Applications, and each OS Application can contain 0~N basic objects . Each base object must belong to an OS Application, otherwise an error will occur. At the same time, OS Application can be divided into two types: Trusted and Not Trusted.

The OS Application of Trusted and Not Trusted can configure the corresponding monitoring and protection mechanism during the running process. The access to the memory and API of the OS basic objects belonging to the Not Trusted OS Application will be limited, and the mode management main functions of some basic software are usually mapped to the tasks in the Not Trusted OS Application, such as EcuM_Mainfunction, BswM_Mainfunction, Can_Mainfunction_Mode(), etc. Periodic status query function, of course, the premise is that the security level of these software modules is QM.

Next, the basic characteristics and uses of each object will be described separately for these 6 basic objects, so that everyone can have a clearer understanding of the OS configuration process.

Task

• Basic and extended tasks

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

  • Running state (Running) : A task in the running state may be preempted by a high-priority task or interrupt to enter the ready state, and there is only one task in the running state at any time in the same Core, and after the task is finished, it will suspend itself and enter the state. blocking state;
  • Ready state (Ready): the task in the ready state is determined by the scheduler whether to start into the running state, and the premise of the task switching to the running state in this state;
  • Blocking state (Suspend): The task in the blocking state is passive and can be activated by the API function or Alarm to enter the ready state;

  Compared with the extended task, there is one more waiting state (Waiting), which is explained as follows:

  • Waiting state (Waiting): When the operation of the task needs to wait for one or some events to be set, the task enters the ready state.

  A code example for a basic task is as follows:

  #include “OS.h”
  TASK(BasicTask)
  {
        
        
      ...
      /*User Code*/
      ...
      TerminateTask();
  }
  

  The code example of the extension task is as follows

  #include “OS.h”
  TASK(ExtendedTask)
  {
        
        
     for(; ;)
     {
        
        
         WaitEvent(Event1);
         /*Perform some actions in specific condition*/
         ClearEvent(Event1);
     }
  }
  

  The state machine switching between basic tasks and extended tasks is shown in Figure 5 below:

  

  Figure 5 State switching diagram of basic tasks and extended tasks

  As shown in the figure above, the basic task has no waiting state, so it can only be synchronized when the task starts and ends. The advantage of the basic task is that it takes up less task and execution time.

  The advantage of the extended task is that it contains multiple synchronization points, without the trouble of synchronization requests. When further conditions cannot be met, the task will switch to the waiting state. The disadvantage is also obvious, which will occupy more memory and execution time.

• Task's Conformance Class (CC for short)

  According to different software and hardware requirements, AUTOSAR OS defines four types of conformance classes, namely BCC1, BCC2, ECC1 and ECC2 , according to the number of tasks that each priority may have and whether basic tasks or extended tasks are required . The classes and attributes are as follows in Table 1:

As can be seen from the above table, basic conformance classes BCC1 and BCC2 only support basic tasks, and extended conformance classes ECC1 and ECC2 support both basic tasks and extended tasks; BCC1 and ECC1 do not support multiple task activation requests and each priority can only have one task ;BCC2 and ECC2 not only support multiple task activation requests, but also support multiple tasks per priority. The compatibility relationship between various conforming classes is shown in Figure 6 below:

Figure 6 Compatibility relationship of each conformity class

• Task scheduling strategy

  AUTOSAR OS carries out tasks based on priority, so each task must have a priority, and each task defines a priority according to its own characteristics and needs to configure its preemptible attributes.

  Preemptible attributes can be divided into non-preemptive and full preemption. The preemption mentioned here refers to kernel preemption. AUTOSAR OS can provide different scheduling strategies according to the preemptible attribute configuration of each task. The scheduling strategies can be divided into the following three types:

  • Fully preemptive : all tasks of the OS are preemptible;
  • Non-preemptive : All tasks in the OS are not preemptible;
  • Hybrid preemption : some tasks of the OS are preemptible, and some tasks are non-preemptible;

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

  Figure 7 below 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.

Figure 7 Fully preemptive scheduling strategy

​ Case1：

​ Currently TaskC is in the running state. When TaskB is activated to enter the ready state, since TaskB has a higher priority than TaskC, TaskC is forced to release the processor control. The scheduler starts to schedule TaskB from the ready state to the running state until TaskB runs. After completion, continue running in Scheduled TaskC.

​ Case2：

​ Currently TaskC is in the running state, and TaskA and TaskB are activated to enter the ready state respectively. Since TaskA has a higher priority than TaskB, TaskA preempts the kernel to run. However, since Resource1 is still temporarily used by TaskC, and TaskA cannot access the shared resource Resource1, it is blocked. Forced into the waiting state, TaskB starts running.

​ After TaskB runs and suspends, it re-runs TaskC. After TaskC finishes running, it releases Resource1 and enters TaskA to change from the waiting state to the running state. At this point, you will find that the high-priority task TaskA cannot run before TaskB due to the occupation of shared resources. This phenomenon is also known as the priority inversion phenomenon .

​ In order to solve this problem, the priority ceiling mode of AUTOSAR OS needs to be mentioned here : the priority of tasks that access shared resources is raised to the highest priority of shared resource tasks in the process of occupying resources, so as to avoid priority inversion. The occurrence of turning phenomenon.

​ That is, if TaskC occupies the shared resource Resource1 during the running process, even if there is a high-priority task TaskA that needs to occupy the shared resources and is activated, it must be ensured that TaskA can be executed after the running of TaskC is completed, which means that before the important code is executed, Resource protection mechanisms should be employed to avoid being interrupted by high-priority tasks.

​ 2. If the non-preemptive scheduling strategy is adopted, the task in the current running state will not be preempted by other high-priority tasks at any time, and the task switching will only occur when the task is completed. The problem of non-preemptive scheduling strategy is that the task execution time is uncertain, and the system scheduling has poor real-time performance. Figure 8 below 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 the execution of TaskC is completed before it can be scheduled.

<center>图8 非抢占式调度策略</center>

​ 3. If hybrid preemption is used, the scheduling policy of the OS depends on the preemptible attribute of the current task. If it is non-preemptive, the non-preemptive scheduling policy is executed, and if it is preemptive, the fully preemptive scheduling policy is executed.

Counter

The introduction of the concept of Counter is to realize the management of hardware counters and software counters, and provide support for Alarm and Schedule table. That is, multiple Alarms can share a Counter, and a Schedule Table can only be driven by one Counter. Counter can be divided into the following two types according to the AUTOSAR definition:

• Hardware Counter: The increase of the Counter is driven by hardware peripherals, such as Gpt or timer, etc.;
• Software Counter: The increase of the Counter is realized by calling the API function IncrementCounter, and it can only increase by 1 each time;

Basic principle: Use Hardware Counter first, because meaningless clock interrupts can be reduced according to the activation status of the Task;

As shown in Figure 9 below, it clearly shows the relationship between Counter, Schedule Table and Alarm.

Figure 9 The relationship between OS Counter, Schedule Table, and Alarm

Alarm

On the basis of the counter, AUTOSAR OS provides an alarm clock mechanism for application software. Multiple alarm clocks can be connected to a Counter. When the set value of the counter corresponding to the Alarm is reached, a task can be activated, an event can be set, and a callback or Add functions like counters, but only one-to-one.

Unlike Schedule Table, multiple Tasks or multiple Events can be set at the same time at the Expiry point, which is why Schedule Table was introduced.

A software Counter + multiple Alarm queues can implement a statically defined task activation mechanism. But with the introduction of Schedule Table, it is generally recommended not to use Alarm if Schedule Table can be used.

Schedule Table

As mentioned above Alarm, when the count value of the counter reaches the count value set by each Alarm in turn, each Alarm is triggered, but it is difficult to ensure that each Alarm has a specific time interval, and each Alarm can only activate one Task or Event, Therefore, multiple Alarms are needed to cooperate to trigger multiple Tasks or Events at the same time, so Schedule Table came into being!

The Schedule Table defines a series of endpoints (Expiry Point), and each schedule table has a duration (Duration) in ticks. Each endpoint is the offset (Offset) from the starting point in units of Ticks, and multiple Task or Event settings can be implemented at each endpoint.

Similar to the alarm, a schedule table can only be driven by one Counter, and the schedule table has the following two scheduling methods:

• Single-Shot: After the schedule table is started, it will only run once, and it will be terminated when it reaches the end point of the schedule table, that is, each endpoint will only run once;
• Repeating: After the schedule table is started, it can be executed repeatedly. After reaching the end point of the schedule table, the execution starts again, and each end point will be executed periodically. Generally, this mode is used to activate the task.

As shown in Figure 10 below, the timing relationship between Expiry Point and Task and Event activation in the schedule table is clearly described.

Figure 10 Schedule Table sequence diagram

be careful:

• Each endpoint must be configured with at least one Task or Event;
• Each schedule has at least one endpoint (Expiry Point);
• In each Expiry Point, the Task is activated first, and then the Event is set;

ISRs

Two types of interrupt service routines (Interrupt Service Routine) are defined in AUTOSAR. They are Category I and Category II. The difference between the two is defined as follows:

• Category I : This type of interrupt service routine cannot use the system services provided by the OS. When the interrupt execution is completed, it will re-jump to the place where the interrupt occurred to continue execution, which will not affect the execution of the task, so it occupies less system resources.
• Category II : This type of interrupt can call OS system services, such as activating tasks or setting events.

In AUTOSAR OS, the priority of interrupts is always higher than the priority of tasks, that is, interrupts of the lowest priority can interrupt the task of the highest priority, even if the task is not preemptible. Therefore, the execution time of the interrupt service subroutine should not be too long, otherwise it will affect the real-time performance of the entire system.

Resource Management

As a very important object in the OS scheduling process, Resource management is particularly important. Resource management is to coordinate multiple tasks with different priorities or interrupt concurrent access to shared memory (such as memory or hardware, etc.).

Fortunately, AUTOSAR OS adopts the above-mentioned priority ceiling mode to avoid task priority inversion and deadlock problems, that is, the upper limit priority of a resource must be higher than the priority of all tasks and interrupts of the resource, but it should be lower The lowest priority for tasks that do not access the resource.

Among them, the lock mechanism proposed in order to protect shared resources - spin lock (Spin Lock). The spin lock is generally used in a multi-core operating system to solve the problem of mutual exclusion of resources. When kernel control must access a shared data structure or enter a critical section, if the spin lock is already held by another execution unit, the caller keeps looping there to see if the holder of the spin lock has released the lock, thus achieving Mutual exclusion of a shared resource.

Common function interface

In order to facilitate your daily software debugging, I will describe the common OS-related API function interfaces and their corresponding functions as shown in Figure 11 below:

Figure 11 List of common function interfaces

Due to the large amount of content and limited space, the writing of a thousand words is finally here, please bear with me. In order to prevent visual fatigue for everyone, please listen to the next decomposition of exciting content such as multi-core startup and shutdown, inter-core communication, memory and time protection, and please pay more attention!

For more exciting content, please scan the following QR code to directly follow the official account: My Views on ADAS and ECU:

If you reply to the keyword "add group" in the background of the official account, you can join the AUTOSAR technical exchange group for free to discuss the hot topics of the foreword such as CP, AP, SOA, information and functional safety!