This year, Xiaoyi opened a CLASSIC AUTOSAR series science popularization column, which will carry out basic science popularization on AUTOSAR content, hoping to bring help to engineers in different backgrounds. This issue mainly describes the os module, let’s take a look!
Table of contents
1. Classification and development of automotive operating systems
3. AUTOSAR OS contact with OSEK OS
4. Basic objects of AUTOSAR OS
01
Classification and Development of Automotive Operating Systems
Before officially entering the topic, let's sort out the operating system used in the car and lead to our protagonist today. From the application scenarios, we can divide the vehicle control operating system into two categories: one is the embedded real-time operating system , which is used for traditional vehicle control, and is suitable for power system and chassis control and other fields; the other is based on the POSIX standard. The operating system is suitable for high-performance computing and high-bandwidth communication required for autonomous driving.
The embedded real-time operating system is the core and cornerstone of the vehicle electronic control system, which can process multiple tasks in a timely manner with limited resources. The most basic requirement of the vehicle chassis control and power system for the operating system is high real-time performance, and the system needs to complete specified actions such as resource allocation and task synchronization within the specified time. The embedded real-time operating system has the advantages of high reliability, timeliness, interactivity and multi-channel, and the system response is extremely high, usually at the microsecond level, which meets the requirements of high real-time performance.
In Europe, the OSEK/VDX Association was established in 1994, and reached a consensus in 1995 to release its specification OSEK/VDX standard and propose OSEK OS; AUTOSAR OS is proposed on the basis of OSEK OS.
02
What is AUTOSAR OS?
What is AUTOSAR OS? AUTOSAR OS is an Operating System, that is, an operating system. Everyone should have used the operating system, whether it is Windows, Linux or Android. However, due to the resource limitation of vehicle control controllers and the difference in main scenarios, it is quite different from the operating systems we usually use. In terms of tasks, AUTOSAR OS is still very limited compared to general-purpose OS. .
Anyone who has used Windows should know that the general-purpose operating system is very powerful. It can install software, run multiple programs at the same time, connect to printers, game controllers, surf the Internet, save files, and of course have a beautiful graphical interface.
And what does AUTOSAR OS do? Its core function is to manage the scheduling of tasks and events , the synchronization flow between different tasks, and provide monitoring and error handling functions. Or in the simplest understanding it is a function scheduler. Some students asked: What is a scheduler? In fact, it can be compared to a scene at work:
For example, the boss of a company has a lot of to-do items every day, and may have to attend several meetings at the same time, and each meeting has its own different meeting materials and reports to prepare. If you let the boss arrange these things by himself, even if you are energetic, you will feel in a hurry. At this time, if there is a secretary who can help him manage these things, arrange the meeting time with his subordinates in advance, and prepare meeting materials for different meetings. Much easier.
This is exactly the same concept as task management or function scheduling. That is to say, it is also managed based on an urgency or priority. Our ECU may need to collect A/D signals with multiple sampling frequencies at the same time, may need to drive PWM actuators with different frequencies, or may need to process various Bus signals with different periods. The programmer manually arranges when and what tasks should be performed. I guess he will go crazy. At this time, our "Monkey King" appeared: all these tasks can be automatically completed by our AUTOSAR OS!
Let's see what it is not. As mentioned earlier, our AUTOSAR OS has limited functions, and it can almost only do the above tasks. Then some students asked again: Almost all of our automotive ECUs have to be connected to the Internet (CAN, LIN, Ethernet), also have to store data (Flash, EEPROM), and have to connect some sensor actuators (motor, temperature sensor).... ..if AUTOSAR OS can't do it, then who will do it? These are general requirements. If AUTOSAR does not have these functions, then it is a bit tasteless!
Don't worry, let the AUTOSAR organization tell you what it means to send Buddha to the west! Please see the picture below:
03
AUTOSAR OS Contact OSEK OS
Closer to home, we mentioned when discussing development that AUTOSAR is developed on the basis of OSEK, and the corresponding AUTOSAR OS is also developed from OSEK OS, so the relationship between them is: egg and egg yolk.
AUTOSAR OS is fully compatible with OSEK. Anyone who can run on OSEK can run on AUTOSAR OS; however, the documentation of AUTOSAR OS almost only introduces functions that are not available on OSEK. If you need to understand AUTOSAR OS, you must understand OSEK OS. As can be seen from the Scalability Class diagram of AUTOSAR OS below, AUTOSAR OS includes all the functions supported by OSEK OS.
04
Basic objects of AUTOSAR OS
Well, we have already understood the main functions of the OS, so how do we accomplish these tasks? Of course, OS completes its functions by operating a series of elements (data structures). The figure below shows the main core elements of AUTOSAR OS, mainly including: Task, ISR, Counter, Alarm, Event, Schedule Table, Application.
4.1
Scheduling entity—Task & ISR
As we just mentioned, the main function of AUTOSAR OS is scheduling. So what exactly should be scheduled? In OS, there is a professional term called scheduling entity; and in OS, we have two kinds of entities that can be scheduled, one of which is Task (task), and the other is called ISR (Interrupt Service Routine). The so-called tasks are some of the work we routinely perform, such as the control logic designed in our ECU, etc.; and interrupts are almost all associated with hardware (excluding soft interrupts), which are executed when some of our MCU peripherals trigger events. Some functions, such as periodic sampling triggered when our timer runs out, or processing functions triggered by events such as receiving a specific message.
Task
There are two types of Task, one is Basic Task; the other is Extended Task. The difference between the two is that the Extend type has one more Waiting state than Basic:
The Waiting state is also called the Suspended state, which allows the Task to suspend the execution of its own Task if it finds that some preconditions are not met during the execution process, and then release the CPU for other tasks to execute, increasing the CPU utilization. .
The Basic task does not allow Waiting, which means that this kind of function will not actively give up CPU resources during execution, unless it stops itself or is preempted by a high-priority task; Extend allows this scenario to happen.
In addition, the other three states are:
Running state : Running state, that is, the Task is occupying the CPU to run;
Suspend state : Suspended state, that is, the Task is preempted by other Tasks or ISRs, or ends by itself;
Ready state: Ready state, that is, the preconditions for running this Task have been met, but it may be due to a high-priority task that is running;
The following figure is a screenshot of a section of Task code, you can experience it in detail:
ISR
ISR, that is, interrupt service routine, means that it provides a mechanism that does not need to check the occurrence of events (polling) in a loop, but predicts in advance the task item (ISR) that needs to be executed when the event occurs, etc. After the event comes, the CPU is notified, and then the CPU performs actions according to my pre-arrangement;
ISRs are divided into two categories: Category 1 and Category 2 . Category 1 means that it is not allowed to execute any function function (API) provided by the OS in this function of the service routine. Category 1 is for faster response. Because if some functions of the OS are executed, it will inevitably cause some environment switching, etc., and there may be some delay. Category 2 can execute the function function (API) provided by the OS accordingly, and after execution, it may trigger Task scheduling;
4.2
Counter & Alarm
Alarm literally means an alarm clock. For example, ring the bell at 9 o'clock to remind me to go to work; ring again at 6 o'clock to remind me to leave work. The same function is also played in the OS alarm, such as periodic sampling, periodic execution of a certain task and other scenarios; when the alarm is implemented at the bottom layer, it will bind a counter counter, the principle is also very simple, the period of the Counter is fixed, and the time interval is determined by counting the number of cycles.
4.3
Schedule Table
Similar to the alarm application scenario, the OS also provides a schedule table element. Its intuitive understanding is to combine multiple alarms into a group. There is a statically defined relative position relationship between alarms, which is the so-called synchronization relationship. Of course, the Schedule Table does not have an alarm, it expresses a similar concept with an expire point. As shown in the figure, between Expiry point 1 and Expiry point 2, you can use a delay to link them together. As for why this element is added, there are two main reasons: 1. There is room for optimization in terms of performance; 2. Better synchronization between time points.
4.4
Event
The concept of Event actually serves for scheduling, mainly for the scenario of Extended Task introduced earlier. As mentioned earlier, the Extended Task has a state that can be Waiting, so what is waiting for? The most common case is to wait for the occurrence of Event. For example, the task first executes a C program statement, and finds that if it wants to continue executing the next statement, it must receive a certain message. If it does not receive it, the task needs to stop and wait until it receives the message. The method is also very simple, "put the elephant in the refrigerator" in three steps:
Create an Event and associate this Event with the Extend Task (need to be set in the configuration tool)
Use WaitEvent to wait for events where you need to wait in the Task
In the interrupt processing function of the received message, set the Event through SetEvent
What Event accomplishes here is a function similar to the flag bit Flag. After completing these three steps, after receiving the message, the OS will automatically set the status of the Event to "Occurrence", and set the status of the Task associated with the Event to Ready, and the Task becomes schedulable. .
4.5
Application
OS application is actually a boundary or a protection function. The ECU developed based on AUTOSAR can contain functional safety-related and functional safety-independent SWCs. ISO 26262 requires software components of different ASIL levels to avoid mutual interference (Freedom from interference).
AUTOSAR OS avoids memory-related interference by placing OS-Application in an independent memory area. This mechanism is called Memory Partitioning. Put a series of all the objects mentioned before into a container, and then only the elements inside can access each other by default. If the elements in other applications want to access, they must be explicitly authorized (IOC, etc.), that is, they need Associated through configuration, this element is actually somewhat similar to the process concept in a general-purpose operating system.
05
conclusion
This article introduces the classification and development of automotive operating systems, the main functions of AUTOSAR OS and the key elements of AUTOSAR OS. These are other mechanisms to master and understand the operating system, such as resource allocation and access, task scheduling methods and functional safety protection measures, tool chain integration After that, we will continue to launch a series of AUTOSAR topics to explain various aspects of it, remember to pay attention.
If you like this article, please comment, bookmark, share and support the editor~