Overview of Real-Time OS
What do you think of when you hear the word “computer”? Personal computers, servers, and supercomputers are truly computer-like computers. They are information-processing computers that can be used for general purposes. However, not all computers are like this.
For example, computers are found in many things around us, such as mobile phones, video cameras, digital cameras, copiers, fax machines, automobiles, car navigation systems, portable music players, HDD recorders, and vending machines. These computers work in concert with other mechanical systems, such as sensors and actuators, to provide purpose-built services in response to real-world movements. This type of computer system is called an embedded system.
An embedded system is a specialized system to achieve a specific function. Nowadays, they are indispensable in our lives. On the other hand, there are some systems that can cause serious problems if they malfunction. Car control systems, for example, can easily be considered to be life-threatening. For this reason, it is important that these systems function properly, and a very high degree of reliability is required of embedded systems. In addition, as computers have become embedded in everything around us, cost reduction has become an important issue. In order to keep costs as low as possible, embedded systems are generally slow and have small memory sizes, and are severely limited in terms of available resources. In addition, they must be able to operate stably for a long period of time because of the high cost of system upgrades.
Above all, embedded systems must be able to operate in the real world. Unlike information-processing computers, embedded systems do not perform mere computational processing, but mainly input/output processing and communication processing to control devices. In the real world, the situation is constantly changing, so high response performance is required in order to perform processing in line with real-world movements.
So, is a computer fast enough to achieve the high response performance required by embedded systems? In fact, it’s not enough. Even if you can complete a process in a short amount of time, unless you can always complete that process in a short amount of time, it won’t be able to provide you with the functionality you expect. For example, many people have experienced using a computer and suddenly some process moves and stops accepting the keyboard. This means that if it’s a music player, the sound will be cut off, or if it’s a car, the power steering will suddenly stop working. To achieve a high level of responsiveness, it is important to keep time constraints so that processing can always be completed in a short period of time.
To achieve this, it is essential to be able to predict the processing time, which is called real-time performance. If the processing time can be predicted, strategies (algorithms) can be formulated to protect the time constraint by adjusting the order of processing. An operating system that provides functions to help achieve such real-time performance is called a Real Time Operating System (RTOS).
The difference between a real-time OS and an information-oriented OS
Real-time OSs can predict the time it takes to switch between a group of processes, called tasks, and the time it takes to perform the functions provided by a real-time OS, as well as the time it takes to respond quickly to events as they occur. In order to achieve processing that requires real time, it is necessary to be able to prioritize the execution of a process so that it is not interrupted by other processes. In this way, the execution time becomes more predictable. If you are interrupted by other processes, it is difficult to predict when a process will finish. For this reason, task scheduling, which determines the order in which tasks are executed in a real-time OS, has the following characteristics.
- Processes (tasks) must be prioritized
- Higher priority processing (tasks) should not be interrupted by lower priority processing (tasks)
- Higher priority processes (tasks) can sidestep the execution rights of lower priority processes (tasks) (preemption)
Thanks to such priority-based scheduling, it is possible to assign high priority to processes that require real-time performance and improve the responsiveness of the system.
On the other hand, conventional information systems use round-robin scheduling, in which processes are switched at regular intervals. With round-robin scheduling, even if you want to execute a process immediately, you have to wait until other processes are completed before you can proceed, and you cannot prioritize high-priority processes like in real-time OS task scheduling. Although recent information systems are adopting scheduling that can handle priorities, the priorities may change automatically according to the execution time of a process. Therefore, it is still difficult to predict the processing time. However, in the world where microsecond response performance is required, mainly for machine control and communication control, an information-oriented OS has technical limitations and a real-time OS is necessary.
Merits and demerits of using a real-time OS
Using a real-time OS makes it easy to create programs that are real-time in nature. Each function required of a device is implemented as a task, and each task is assigned a priority so that it is executed at its intended timing. In practice, when multiple tasks are processed in parallel, a function for synchronizing the timing of operations between tasks (synchronization) and a function for exchanging information between tasks (inter-task communication) are also required. These functions can be easily achieved by using the following functions provided by a real-time OS.
- Task Management Function
- Task Synchronization Management Functionality
- Synchronization and Communication Capability
- Memory Management Functionality
- Time Management Functionality
- Interrupt management function
It also increases the reusability of the program. For example, let’s say you are porting an application that was running on hardware A to hardware B. If the same real-time OS runs on hardware A, you can run the application on hardware B with very little modification. If hardware B runs the same real-time OS as hardware A, the application can be run with almost no modifications. In the unlikely event that there is no real-time OS running on hardware B, the same application can still be run as long as the real-time OS is ported to hardware A. Although it may seem difficult to port a real-time OS, there is no need to modify the entire real-time OS; only the hardware-dependent parts of the OS can be ported to run.
Furthermore, using a real-time OS improves maintainability and scalability. The modularity of the entire system is improved and can be maintained on a per-module basis, allowing application developers to focus solely on the application. In addition, related products such as middleware, various software assets, and development support tools are also available. However, if a real-time OS is not used, the application developer must also take responsibility for tasks that a real-time OS is responsible for, such as task management and hardware control.
On the other hand, using a real-time OS has the disadvantage of increasing memory consumption. For very simple applications, there may be no problem without a real-time OS. However, embedded systems often execute multiple processes in parallel, and they must be implemented so that each process can be successfully processed within a specified time. For example, a music player needs to read music data from a storage medium, output the read music data to a sound device, accept user input for operations, switch screen displays, and many other processes. In the end, you need a function to manage each of these processes, and you have to add functions that are equivalent to those of a real-time OS by yourself. It would be a waste of time and money. In addition, a real-time OS was originally designed to work in an environment with limited resources, so it is very compact. Therefore, you don’t have to worry so much about memory consumption by a real-time OS when you consider the overall system you are building.
The Future of Embedded Systems and Real-Time OSs
I hope the above explanation has helped you understand the vital importance of a real-time OS for embedded systems. On the other hand, if we look at recent embedded systems, we find that they have become significantly more informatized and larger in scale. The list of examples is endless, but the following is an example.
Some products have a web browser similar to a PC, or have the ability to play YouTube videos.
Cooking appliances (microwave ovens and refrigerators)
Some products automate the cooking process to some extent by suggesting and displaying recipes and automatically setting the cooking time, temperature, etc. according to those recipes.
Some of them can upload weight and body fat information to a cloud service and record it for you.
These examples make me think that the shift from real-time OSs to information-based OSs in embedded devices will continue to progress rapidly. There is no doubt that high-end information appliances and information equipment will continue to develop in this direction. However, it is important to note that these embedded devices are not simply information systems, they are also embedded systems, and therefore the concept of a real-time OS cannot be ignored when it comes to device control. For example, taking the washing machine as an example, if the motor cannot be controlled in real time due to the use of an information system OS for the purpose of upgrading its functions, it would be a recipe for disaster if the machine cannot be used for its intended purpose. In other words, what is required here is a platform that can take the “best of both worlds” – an information-based OS and a real-time OS.
On the other hand, it is unlikely that all embedded devices will follow the directions of sophistication described above. In recent years, new paradigms such as ubiquitous computing, machine-to-machine (M2M), and the Internet of Things (IoT) have emerged one after another, but the fundamental idea behind them is the distribution of functions between devices. In other words, instead of making a single device more and more powerful and capable of doing anything, the idea is to have multiple devices doing different tasks in coordination with each other to provide better services as a whole.
As a concrete example, think of a smart house (electronic house). For example, consider a system that automatically opens windows and exhaust fans to provide ventilation when you are cooking on the stove, or automatically closes the windows and turns on the air conditioning when the outside temperature gets cold or hot. In this example, at least the windows and exhaust fans and the cooking equipment, such as the air conditioning and stove, need to work in conjunction with each other in some way. Naturally, this is very different from the conventional type of equipment where one device alone does it all.
As the functions of embedded devices become increasingly distributed, it is no longer necessary to improve the performance of devices to be able to do everything. Advanced processing can be left to high-performance machines, and only the work that needs to be done by the device can be done well. For example, in the window opening/closing example mentioned earlier, the decision logic for opening and closing the window can be placed in a server in the cloud, and the window simply opens and closes according to demand. Rather than making all devices high-performance, distributing functions appropriately in this way is more advantageous from the point of view of reducing the power consumption of the devices as well as the cost of the devices. In other words, a system that is based on the premise of functional decentralization will develop in the opposite direction to making each device more functional.
Embedded devices are still developing today, and as a result, real-time OSs need to respond to new requirements such as higher functionality, higher performance, and more distributed functions.
T-Engine Project and T-Kernel Series
T-Engine project was started in 2002 to respond to the new applications that have emerged in the 21st century, and was initiated by Professor Ken Sakamura of the University of Tokyo, the father of TRON, to build on the achievements of the TRON project, which has a track record of more than 20 years in the field of embedded systems, and to integrate the achievements to date. project.
The T-Engine project is a project that promotes the realization of an operating system-centered platform mainly for the embedded field with the following characteristics
Open architecture and open source
- The technical information and source code are open to the public.
- This allows more companies to participate freely, which speeds up the creation of new technologies.
License suitable for commercial use
- In many cases of embedded systems, there are cases where it is necessary to keep details of the product hardware secret or to combine it with commercial middleware. For this reason, the T-Engine project established a license agreement called the T-Engine License, which allows free reproduction or modification of the product while keeping the modified portions secret.
- The T-Engine project proactively proposes standard specifications to international standardization organizations such as ITU and ISO, and contributes to the international standardization of fundamental technologies.
- In 2012, a standard specification on ubiquitous computing with a focus on ucode(*1) was established as an ITU international standard (H.642).
T-Engine project is promoting a wide range of activities including ubiquitous computing as well as real-time OSs for embedded systems. Kernel is a series of real-time OSs designed to support new applications in embedded systems based on the embedded real-time OS “ITRON” in the TRON project. are each offered to meet a number of requirements.
You can easily understand the correspondence between T-Kernel family and Arm processors as shown in the figure below for the correspondence with CPUs. In this article, I would like to introduce μT-Kernel, T-Kernel 2.0, and T2EX in the T-Kernel family. (For detailed information on T-Kernel family including T-Kernel Standard Extension and MP T-Kernel, please refer to the T-Engine Forum website.
(*1) ucode is a unique identification number to identify various “objects” and “places” in the real world. Please refer to uID Center for details.
μT-Kernel is a real-time OS targeted at small-scale embedded systems, and is suitable for the applications targeted by Cortex-M in terms of Arm’s processors. It is a very compact OS and is designed to run on hardware with only 8 KB ROM and 4 KB of RAM, for example. Generally, what is called “embedded Linux” uses several MB or more of RAM, no matter how small the setting is, and you can see how compact the OS is compared to this.
Even though it is such a compact OS, it has quite a substantial API compared to other real-time OSs. In particular, its task-related APIs and APIs for inter-task synchronization and communication are considerably more extensive than those of other real-time OSs, such as FreeRTOS and μC/OS-II. This is very important because the essence of a real-time OS is to optimally allocate the CPU’s computation time to the processes you want to execute. This is because a reasonable set of APIs is needed to allow this control over time allocation to be done efficiently from the program. (A detailed discussion of this point is presented objectively by a third party in a paper, so if you’re interested, please refer to http://dx.doi.org/10.1109/MM.2009.86 (Please see below).
Specifically, μT-Kernel provides the following functions. For unused functions, you can remove them individually to save ROM and RAM.
- Task Management Function
- Task Attached Synchronization Feature
- Synchronization and communication features
- Extended synchronization and communication features
- Memory Pool Management Feature
- Time Management Function
- Interrupt management function
- Sub-system Management Function
- Device management features
- Debugger Support Feature
We’ll discuss how to use these features in more detail in future articles.
T-Kernel 2.0 can be described in one word as a real-time OS for high-performance, highly functional embedded systems, and in Arm’s case, it is suitable for the application fields targeted by Cortex-A. It has been designed and implemented to support the functions of an information-oriented OS on top of the basic functions of a real-time OS like μT-Kernel.
The “subsystem management function” is important from the viewpoint of “taking the best out of information system OSs”. This is a mechanism for adding OS functions on top of a real-time OS called T-Kernel 2.0. By using this, information-related functions such as file management functions and network communication functions, for example, can be added as OS functions based on a real-time OS. In fact, T-Kernel Standard Extension is an OS extension that realizes complete OS functions, and there are other examples of POSIX extensions, etc. that have been developed by member companies.
In addition, although μT-Kernel explained in the previous section actually has a function called “subsystem management” listed, this function is different from T-Kernel 2.0, it is only a simple one and is provided for compatibility. In this way, the T-Kernel family is designed with the compatibility of APIs between each of them in mind, even though the realization method, internal operation, configuration, etc. are all significantly different. As a result, the common API called “T-Kernel” can be used in a scalable manner from small embedded systems to large ones.
The current μT-Kernel is designed in the form of T-Kernel 1.0, the predecessor of T-Kernel 2.0, in a lightweight and simple configuration while maintaining compatibility, and it has almost the same features as T-Kernel. However, as T-Kernel 2.0 is designed for use in a relatively large configuration that requires the function of an information-related OS, the following functions have been added to μT-Kernel.
Time Management in Microseconds
- In controlling devices in embedded systems, microsecond-level time management is often required, and we support microsecond-level time management to achieve this.
- With the increase in processing speed, as seen in the Cortex-A processor, we have created an environment in which microsecond-level control can be practically applied.
Support for Large Capacity Devices
- The number of cases in which large capacity devices such as SD cards and other embedded devices are used has been increasing, and we have added a function for handling these large capacity devices. In addition, we have added functions to handle these large capacity devices.
Expanding the scope of standardization
- Expanded the range of functions defined in the T-Kernel 2.0 specification, such as physical timers and cache control.
- With this, the APIs for using these features will be standardized and middleware distribution will be improved. This makes it possible to share APIs for using these features and improves middleware distribution.
T2EX stands for T-Kernel 2.0 Extension, which directly translates to “T-Kernel 2.0 (of) Extension. As the name suggests, T2EX is an OS extension for T-Kernel 2.0 and is a collection of OS add-ons (extensions) to bring the best parts of an information-based OS to a real-time OS.
In the section “The T-Engine Project and the T-Kernel Series,” we discussed the fact that embedded systems are becoming more sophisticated, high-performance, or functionally distributed. By adding advanced OS functions in a form lighter than an information-oriented OS, T2EX supports the increasing sophistication and performance of embedded systems, while the network communication function enables support for decentralized functions from the OS level.
The main features of T2EX are as follows
Adding Information OS Functions for Advanced Embedded Systems
- Adds information-related OS functions such as file management and network communication functions. This provides strong support for the development of highly functional embedded systems.
- To achieve a high level of embedded systems within a limited amount of ROM/RAM, the OS function is made independent.
- By configuring at the time of building, you can select only the necessary ones for development. For example, if you want to develop T-Kernel 2.0 in a configuration where only the network communication function is added, you can build a system by adding or removing extended functions independently and efficiently develop a compact embedded system.
Support for memory protection features
- In the development of highly functional embedded systems, the ability to protect the OS from applications is essential.
- It enables the development of efficient and secure systems by providing memory protection over a single space, which is different from an information-based OS.
- It is possible to develop very compact embedded systems while still achieving the functions of an information system OS.
- For example, it is possible to develop a device (e.g., a digital camera) that includes a file system with less than 100 KB of RAM, which is extremely compact for achieving the same processing, since Linux, for example, consumes at least a few MB.
The main functions of T2EX are listed below. These functions can be used together with the API of T-Kernel 2.0 to realize advanced processing while achieving high real-time performance.
- Network communication function
- File Management Function
- Standard C-compatible library (including standard input/output features)
- Calendar function
- Program load function
- Memory Protection Feature
By the way, the architecture of T2EX is shown below, and it is possible to add or remove the above-mentioned functions as long as the dependencies between the functions shown in the figure are met.
This post is also available in: Japanese
You might also like
More from RTOS
Variable-length memory pools are for managing blocks of memory of any size. Fixed-length memory pools are used to manage memory …