*Author: Nanlian Hong
When reading books on “Computer Operating Systems,” one will generally encounter the concepts of processes and threads. However, in embedded RTOS, such as the OSEK/VDX Operating System Specification 2.2.3 standard used in automotive software, these two concepts are not present. Instead, the concept of tasks is used.
So, what is the relationship between these three concepts? This article explains the author’s understanding.
Concept of Processes
A process is an activity where a program with independent functionality is run on a specific set of data. It can request and own system resources and is the fundamental unit for the allocation and scheduling of resources. A process is a dynamic concept and an active entity.
“Independent functionality” implies that a process is defined with the user in mind, which concerns what it does. For example, if I want to write an article on my computer using Microsoft Word, the computer creates a process for Microsoft Word. If I want to write two articles simultaneously, I have to open another Word document. The computer then creates another process for Microsoft Word.
Ordinary computers can do several things simultaneously, such as “surfing the internet,” “watching movies,” and “playing games,” meaning they can run many processes. However, embedded computers are designed to do only one thing, such as VCU for controlling the vehicle, ECU for controlling fuel injection and ignition, TCU for controlling gearshift, and BCM for controlling the vehicle body.
By analogy, the traditional electronic control unit ECU is equivalent to running only one process. In the future, XCU will be able to run multiple processes in ECU.
“Resource allocation” refers to the object of a process operation, which concerns what it is done with. For example, for the VCU, it includes:
-
Input resources: acceleration pedal sensor, brake pedal sensor, etc.
-
Output resources: PWM module that drives the water pump, etc.
-
Communication resources: CAN communication for exchanging data with TCU and EMS.
Each specific electrical resource is abstracted into a concrete object (variable) in the software.
“Resource scheduling” refers to the method of process operation objects, which concerns how it is done. Scheduling is the core of the operating system. Without scheduling, even if ECU is powered, the actuator cannot move, and the control function cannot be achieved.The process of scheduling is diverse, and how to schedule for the most effective use of resources is a question that software designers must consider. Among all resources, “CPU” resources are the most core resources. If there are not enough sensors, an additional circuit can be added to expand it.
However, in a single CPU system, especially with only one core, it is impossible to simply add another CPU. This is equivalent to redesigning an ECU system. Adding a core to the original CPU is not something that ECU developers can do. Around how to effectively use “CPU resources,” threads were introduced.
Concept of Threads
A thread is the smallest unit of computation that an operating system can schedule. It is included in the process and is the actual operational unit of the process. A thread refers to a single sequential control flow in the process, and multiple threads can be concurrent in a process, with each thread executing different tasks.
-
“Computation scheduling” means that the thread is oriented towards the calculator, i.e., the CPU. At this level, it only concerns the CPU resource, and other resources are not considered.
-
“Smallest unit” means that once it is defined as a thread, it should not be further divided into sub-threads. If it can be divided, it should be done when designing the program. For example, if a Thread10ms() is analyzed and some of the logic execution cycles should be 2ms, it should be split into Thread10ms() and Thread_2ms().
-
“Single sequential flow” means that once a thread is started, it should be executed from start to finish in order. If it is paused in the middle, the pause point should be recorded, and execution should continue from the pause point after resuming. If it does not continue to execute from the pause point after resuming, it should be considered an error.
-
“Different tasks” means that only one task can be assigned to one thread for execution. Otherwise, unexpected results may occur. For example, there is a task Task_Printf(“Hello World”). When it is hung on a 10ms process alone, “Hello World” is output to the screen every 10ms. When it is hung on a 2ms process alone, “Hello World” is output to the screen every 2ms. However, in a pre-emptive operating system, if both of them are hung on 2 threads, the 2ms task may pre-empt the 10ms task. Strange strings like “Hello Wo Hello World rld” may be output to the screen.
Concept of Tasks
After researching many materials and articles, the author found that the definition of tasks is diverse, for example:
- Definition from Baidu:In a multi-program or multi-process environment, the basic work element that needs to be completed by the computer is a sequence of one or more instructions processed by the control program.
Definition of OSEK OS 2.2.3:
Complex control software can be easily subdivided into components that are executed according to their real-time requirements. These components can be implemented through tasks. Tasks provide a framework for executing functions.
The operating system provides concurrent and asynchronous execution of tasks. The scheduler organizes the order of task execution.
Definition of μCOS-III:
A task (also known as a thread) is a simple program that is assumed to have its own central processing unit (CPU). On a single CPU, only one task can be executed at any given time.
A task looks like any other C function except for a few minor differences. Tasks come in two flavors: run-to-completion (Listing 5-1) and infinite loop (Listing 5-2).
In most embedded systems, tasks typically take the form of an infinite loop. Also, no task is allowed to return like any other C function. Given that a task is a regular C function, it can declare local variables.
Definition of TASKING-OS:
A task is a semi-independent program segment with a specific purpose. Most modern real-time applications require multiple tasks. Tasks provide a framework for executing functions. The RTOS provides concurrent and asynchronous execution of tasks.
The scheduler organizes the order of task execution, including a mechanism that is active when there is no other system or application functionality: the idle mechanism.
Tasks have static priority, whether they can be preempted or not, whether they can or cannot enter a waiting state, whether they are or are not the sole owner of a priority, and so on.
Definition of SylixOS:
## Summary
In general-purpose computer operating systems, the concepts of processes and threads are emphasized. However, in embedded operating systems, tasks mean threads. This is because an embedded system is designed to implement only one specific function which is a specialized computer system, while in general-purpose computer systems, it is equivalent to a process. Moreover, one process in general-purpose computers can spawn several independent processes, just like how you can open two Word documents for interactive editing.
However, it is impossible for an automotive ECU to control two engines through software duplication. Therefore, processes have no meaning in most embedded systems (except for multi-purpose devices like smartphones).
Many professionals involved in embedded development are not computer science graduates, but rather electronic engineering graduates who turned to embedded computer systems research because hardware development requires it. Since the term “thread” is a computer science term, without the backing of processes, it is difficult for the average person to understand. On the other hand, “task” is a word that is oriented towards people, so most RTOS in most embedded systems only talk about tasks.
However, the author still believes that it is necessary to have a clear understanding of these concepts from a computer science perspective. There are two reasons for this:
- Embedded systems are becoming more and more powerful and are approaching general-purpose computer functionality, such as smartphones. In the field of automotive electronics, XCU is the direction of development, and an XCU is definitely multi-process. Defining tasks alone is not enough, and it is necessary to define that they belong to engines or transmissions, for example.
- Tasks are still different from threads. For example, consider the following two sentences:
- The boss tells the employee, “Come to my office.”
- The boss tells the employee, “Come to my office at 5 o’clock.”
Defining “come to the office” is a task. The first sentence has no concept of scheduling or thread, and when “come to the office” is not specified (it is assumed to mean now), the employee can go to the office at any time. Therefore, the execution of this task is uncertain.
In the second sentence, the scheduling time “5 o’clock” is added, and the task becomes clear. Thus, we can strictly define the relationship between processes, threads, and tasks.
Application Modes of OSEK OS:
The author does not intend to overturn the concept of RTOS in embedded systems, nor is it necessary. When dealing with computers, software engineers generally know what they want to do, although the expression may differ. Just like some people call it “cat” and some people call it “kitty,” they refer to the same thing. Note that in OSEK OS, there is a concept of application modes.
Application mode is intended to allow the OSEK operating system to run in different operating modes. Many ECUs may execute completely independent applications, such as factory tests, flash programming, or normal operation. The application mode is a way of constructing software that runs within the ECU based on these different conditions and is a concise mechanism for developing completely independent systems.
Typically, each application mode uses its own subset of all tasks, ISRs, alarms, and timing conditions, although tasks or ISRs can run unrestricted in different modes. If the same functionality is required again, it is recommended to share tasks/ISRs/alarms between different modes.
This looks a bit like the concept of “processes”. Earlier we said that an ECU that performs a specific function only has one process, but this is just the main process. The functionality of an ECU that only has a main process is still limited. For example, before leaving the factory, the ECU needs to test its function, and the program that runs the test must be different from the program that runs during normal operation.
Old programs need to be updated to new ones, and to do so, they need to switch to run in the boot program. This is actually a different process. It’s just that the processes in embedded software are different from those in general-purpose computers.
Processes in general-purpose computers can be switched halfway through, such as typing halfway through and switching to watching a movie without closing Word.
In a car, can the engine control program pause halfway through, run in boot mode for a while, and then switch back to the engine control program to continue running? Technically, this could be done, but it certainly wouldn’t be done. There are several reasons for this:
-
Security issues
-
The boot and app programs need to allocate separate RAM spaces to save their respective states, wasting resources.
-
It’s unnecessary. Running the app program from the beginning to a breakpoint takes only tens to hundreds of milliseconds, and switching to protect the running process saves very little time.
-
It cannot achieve the control objective. If a program in automotive software stops running while in operation, whether it is an active behavior or a passive exception, it will cause the loss of current functionality. The program must be restarted before the function can be restarted.
The fourth reason is the main function, so there are only three states for the processes in automotive software. This means that there is no need for a process control block or a process stack. One process must be terminated before switching to another process.
OsApplication in AutoSar OS
The concept of OsApplication is introduced in the AutoSarOS standard, which at first glance is similar to the Application modes of OSEK OS. AutoSar OS must be able to support a set of operating system objects (tasks, ISRs, alarms, schedules, counters) that constitute cohesive functional units.
This set of objects is called the OS application. However, they are fundamentally different.
The purpose of introducing OS-Application in AutoSarOS is to prevent error propagation in programs and to meet functional safety requirements for Trusted OS-A and Non-Trusted OS-A.
Non-Trusted OS-A can access Trusted OS-A, but the reverse is not possible. This is similar to the “public” and “private” properties of object-oriented programming, where private objects can access public ones, but not vice versa.
Under an OS Application mode, there can be many OS-Applications, but they are not runnable entities. They define only the resource ownership relationships. When a scheduling table/task accesses a resource, it must first check whether it has permission to do so. This permission comes from an OS Application table that is statically defined.
Similarly, different session modes in automotive diagnostic specifications define the permissions of diagnostic services that can be accessed. For example, Service $27 cannot be called in the default session. However, session mode is neither a process nor an OS Application; it is purely a software design logic and is not related to the choice of operating system.
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.