Table of contents
1. Real-time operating system (RTOS)
2.3, OSEK task compliance category
2.4, OSEK priority ceiling mode
3.1. Inheritance and extension of AUTOSAR OS to OSEK OS
3.2. Schedule table of AUTOSAR OS
3.3. Time protection of AUTOSAR OS
3.4. Memory protection of AUTOSAR OS
1. Real-time operating system (RTOS)
A real-time system (Real-Time System) usually refers to a system that has strict time requirements for the execution of tasks . In this type of system, the actions performed by applications and the responses to external events should be timely and predictable , otherwise, tasks will miss deadlines or lose data. Real-time systems usually include hard real-time systems and soft real-time systems. Hard real-time systems require that tasks must be completed before the deadline , otherwise, the system will fail; soft real-time systems expect tasks to be completed within a predetermined time , but a certain delay is not fatal to the system. Real-time systems usually have the following characteristics:
High input and output throughput;
Fast response to external asynchronous signals;
Fast task scheduling;
It has a secure communication mechanism between tasks, etc.
The automotive electronic control system is a real-time system, which requires all tasks to be predictable. Usually, it includes hard real-time tasks and soft real-time tasks. There are many tasks and the system is relatively complex. In the past , the real-time system design method is to use the control loop method to query the execution of tasks. This method requires programmers to have strict control over the execution time and execution order of tasks, which makes programming difficult. At the same time, it increases the difficulty of software transplantation. Larger and less reusable.
Real-time operating system (Real Time Operation System, RTOS) is an operating system applied to real-time systems, which provides users with a structured and convenient task execution environment, and can well meet real-time requirements. RTOS has the following advantages :
Eliminates the need for processor allocation in application software;
Correction or addition of tasks can be done in the application software without affecting the responsiveness of the system;
In addition to task management, most RTOS provide task communication, task synchronization, timer and memory management mechanisms;
RTOS hides the specific characteristics of the underlying hardware and provides users with a real-time operating environment that does not depend on the processor;
Can be easily ported to other processors supported by the RTOS vendor.
To sum up, most of the current embedded operating systems are real-time operating systems.
2. OSEK operating system
2.1 Overview of OSEK
The OSEK operating system (OS) is a single-core operating system defined for distributed embedded systems . In order to meet the needs of reliability, real-time performance and cost sensitivity of automotive electronics, the OSEK operating system has the following characteristics:
Tasks, resources, and services in the operating system are statically configured;
Support for running on ROM;
The tasks in the application are very portable;
Actions defined in the operating system are predictable and recordable.
The OSEK operating system provides the following services:
Task management: including activation and termination of tasks, switching of task states;
Synchronization service: mainly realized through resource scheduling and event control (there will be examples below);
Interrupt service routine: including a class I interrupt and a class II interrupt;
Alarm mechanism (ALARM): including relative alarm and absolute alarm;
Inter-process communication: used for the exchange of data between processes;
Error handling: used to support various error handling.
AUTOSAR OS inherits all the above features.
2.2, OSEK processing level
The OSEK operating system defines three levels of processing: task level, logical level for scheduler and interrupt level . The task layer is divided into full preemption, non-preemption and mixed preemption (preemption full/non/mixed). The execution timing of tasks is determined by the Scheduler according to the scheduling rules. Some of the interrupts in the processor are interrupts that are not controlled by the operating system, called type I interrupts, and interrupts controlled by the operating system are called type II interrupts . The priority and execution timing of each layer are shown in the figure below. 
From the above figure, the priority rules of the OSEK operating system can be summarized as follows:
Interrupt priority is always higher than task priority;
Different interrupts and tasks can have one or more priorities;
Interrupt and task priorities are statically assigned (configured);
The execution order of tasks with the same priority is determined according to the FIFO principle;
The priority ceiling mode (ceiling priority) can be realized through resource scheduling to avoid priority inversion.
AUTOSAR OS fully inherits the above features.
2.3, OSEK task compliance category
According to different hardware and software requirements, OSEK OS defines four conformance classes (CC), which are BCC1, BCC2, ECC1 and ECC2, and the various conformance classes and their attributes are shown in the figure below.
As can be seen from the figure above, basic conformance classes BCC1 and BCC2 only support basic tasks , extended conformance classes ECC1 and ECC2 support basic tasks and extended tasks; class one conformity classes BCC1 and ECC1 do not support multiple task activation requests, each priority can only There is one task; the second class conforms to the class BCC2 and ECC2 to support multiple task activation requests, and each priority can have multiple tasks. The compatibility relationship between various compliance classes is shown in the figure below.
Basic tasks and extended tasks of OSEK
There are two types of tasks in the OSEK operating system: Basic Task and Extended Task. The basic task has three different states, which are running state ( running) , ready state ( ready) and blocking state (suspending) . The tasks in the blocked state are activated by the API function or the alarm (Alarm) and enter the ready state. The task in the ready state is determined by the scheduler to start and enter the running state. The tasks in the running state may be preempted by high-priority tasks or interrupts. Enter the ready state, and after the task runs, it will hang itself and enter the blocking state. Compared with the basic task, the extended task has more waiting states . When the operation of the task needs to wait for one or some events, it enters the waiting state (waiting). When the event the task is waiting for is set, the task enters the ready state . The state machines of basic tasks and extended tasks and the switching between them are shown in the figure below.
Because the basic task has no waiting state, it can only be synchronized when the task is started and terminated. The advantage of the basic task is that it occupies less memory and execution time. The advantage of an extended task is that it contains multiple synchronization points, without the trouble of synchronous requests. When information is missing in further work, the task switches to the waiting state; its disadvantage is that it takes up more memory and execution time.
2.4, OSEK priority ceiling mode
If Task1, Task2, and Task3 are extended tasks in full preemptive mode, Task1 and Task3 have shared resources, if Task1 occupies the resource Sourcel during operation, Task2 and Task3 are activated and are in the ready state, and the scheduler makes Task3 Enter the running state. Since the resource Sourcel that Task3 needs to access has not been released by Task1, it enters the waiting state, and the priority of Task2 is higher than that of Task1, so Task2 preempts Task1 and enters the running state. After running, it will suspend itself, and Task 1 will continue to run. , Task 3 runs. Its running sequence is shown in the figure below.
The figure below shows priority inversion (priority task3 >task2 >task1)
As can be seen from the figure above, the task that should have been run before Task2 runs after Task2. This phenomenon is called priority inversion (Priority inversion). This phenomenon is contrary to the intention of the system designer. To avoid this phenomenon, the OSEK operating system adopts the priority ceiling mode (ceiling priority). That is, the priority of the task that accesses the shared resource is raised above the highest priority of the shared resource task during the process of occupying the resource, so as to avoid the phenomenon of priority inversion, as shown in the figure below.
3、AUTOSAR OS
3.1. Inheritance and extension of AUTOSAR OS to OSEK OS
AUTOSAR OS is modified and expanded on the basis of OSEK OS, and is backward compatible. Applications running on OSEKOS can run on AUTOSAR OS.
AUTOSAR supports multi-core OS from version 4.0 . AUTOSAR multi-core OS adopts a partition mechanism, and each core of a multi-core processor has at least one OS-Application . Task (Task), Interrupt Service (ISR), Alarm (Alarm), Schedule Tables (Schedule Tables) and Counters (Counters) are collectively referred to as operating system objects (OS Object). Each OSObject must belong to an OS Application , otherwise an error will occur . OS-Application is divided into Trusted and Non-Trusted. Both Trusted and Non-Trusted OS-Application can be configured with corresponding monitoring and protection mechanisms during operation. The OS Object belonging to Non-Trusted OS-Application has limited access to memory and API. Usually, the mode management main function of some basic software layer modules is mapped to the tasks in Non-Trusted OSApplication, such as: EcuM_MainFuction (), BswM -MainFuction (), CanMainFuction_Mode() and other periodic query functions, provided that the security level of these modules is QM
AUTOSAR OS has four types of tailorable types (OsScalabilityClass), which are SC1-SC4. According to different processor characteristics, users can choose different cutable types. Compared with OSEK OS, SC1 has a schedule table (Schedule Tables), SC2 has a schedule table and time protection (Timing Protection) features, SC3 has a schedule table and memory protection (Memory Protection) mechanism, SC4 has a schedule table, time protection and memory protection mechanism. The schematic diagram of the four is shown in the figure below.
3.2. Schedule table of AUTOSAR OS
The scheduler is used to arrange complex tasks or event sequences , which can be regarded as a one-way axis. Tasks or events are activated by setting one or more static endpoints (Expiry Point) on the axis. Each endpoint can be set Single or multiple tasks or events, the time interval between the endpoints is in the Tick of Counter, so each schedule corresponds to a Counter . Schedules can be set to run in a cyclic or acyclic manner . The schedule table structure is shown in the figure below.
3.3. Time protection of AUTOSAR OS
As mentioned above, a real-time operating system needs to complete some tasks within a predetermined time, but in some cases, a timeout error will occur. Therefore, the operating system must take certain measures to prevent the generation of timeout errors. This measure is called time protection. A method of time protection is time monitoring , that is, when it is detected that the running time of a certain task exceeds its deadline, the operating system reports an error and calls the corresponding hook (Hook) function. AUTOSAR OS does not implement time protection by monitoring the cut-off time , because the monitoring of the cut-off time cannot identify the cause of the error . When the execution of the task exceeds the deadline, the execution of the task itself may not have an error, but an error derived from being preempted too frequently by other tasks or interrupts or accessing too long blocked resources. In this case, if the way of monitoring the deadline is adopted, it is possible to end the correct task, while the wrong task is still allowed to run.
Assuming that all tasks are ready at time 0, the expected timing is shown in the table and figure below. Since task A has the highest priority, task A is executed first, task B is executed after 1 Tick, and task C is executed after 3 Ticks. When task C executes 1 Tick, task A interrupts it. After task A is executed , Task C continues to run until the 10th Tick task C is executed, and it goes round and round. There is no timeout phenomenon in the whole process, and there is an idle state of 1 Tick.
The figure below shows the status of the task error running. The second cycle of task A and the first cycle of task B both run too long, but do not exceed their deadlines. Task B enters the running state ahead of schedule in the second cycle, but the deadline is not exceeded. Task C runs in the correct way, but due to errors in tasks A and B, task C runs overtime, and a timeout error occurs. Using the timeout monitoring mechanism can only detect that task C is overtime. At this time, the operating system calls the hook function, but the cause of the error has not been detected, so the measures taken by the operating system cannot effectively solve the error.
The task timeout diagram is as follows:
In a real-time operating system, whether a task or interrupt can meet its deadline depends on the following three factors:
1. The upper limit of the execution time of static tasks or interrupts;
2. Blocking time caused by low-priority tasks locking shared resources or shielding interrupts;
3. Interval execution time between tasks or interrupts.
In response to the above three factors, AUTOSAR OS adopts three time protection mechanisms:
For 1, AUTOSAR OS sets the upper limit of running time for tasks and second-class interrupt services;
For 2, AUTOSAR OS sets the upper limit of time when shared resources are locked by tasks or second-type interrupts, sets the upper limit of time for OS interrupts to be suspended by tasks or second-type interrupts, and sets the upper limit for all interrupts to be suspended by tasks or second-type interrupts. The upper limit of the time limit for activation or blocking;
For 3, AUTOSAR OS sets the lower limit of the execution interval of the task or the second type of interrupt.
When the task or interrupt service function does not meet the above requirements during operation, AUTOSAR OS calls the corresponding hook (HOOK) function to make corresponding error handling.
3.4. Memory protection of AUTOSAR OS
Memory protection requires specific hardware support, that is, there should be an MPU (Memory Protection Unit) on the processor, and the Infineon AURIX MCU has this feature. Memory protection prevents certain faulty applications from affecting other modules. Memory protection is divided into the following three forms:
1. Stack Protection: Each OS Application and its OS Objects have their own private stacks , and there is no shared stack among different OS Objects . Stack protection can detect stack overflow and stack underflow more quickly. At the same time, stack protection is a method and basis for dividing OS Applications.
2. Data Protection: OS Application and its Objects have their own private data, and the OS Application's private data area is the shared data area of the OS Application's Objects.
3. Code Protection: The code area can be privately owned by OS Application or shared. In the absence of code protection, erroneous code execution can lead to memory, timing, and service errors.
The OS monitors the access rights of the memory through the MPU. The access rights in AUTOSAR are divided into two levels: trusted Object and non-trusted Object (Trusted and Non Trusted). Trusted Objects have permission to read and write most of the memory, but not to read other inactive stacks. Untrusted Objects only have permission to read and write a small amount of memory, including the currently active stack, data of the current OS Application, and shared data in the LMU.