RTOS or not RTOS is the question

A long comment line prompted me to write this article (unfortunately, I cannot call it a discussion) to my recent article “The diverse world of embedded systems and the place of Embox in it” . In several places I was reproached for confusing RTOS and Embedded OS, what I called LynxOS, QNX and VxWorks not RTOS, although in my opinion I didn’t, of course, do this. I suggested several times to the author of these comments to write an article in which he would set forth his vision of the concept of “real-time operating system”, but for some reason he refused. Well, I will set out my vision of this term, and let's discuss what can be called RTOS, and what can not. In the end, this question is often asked for Embox .

The term OS RT (RTOS) refers to the field of marketing!

I thought to start in a scientific way, with the introduction of terms, but I decided that this provocative thesis would be most welcome. So, why do I say that the term RTOS (real-time operating system) refers to marketing, or rather, is a marketing (advertising) slogan? It's simple. When a product is produced, it must be sold. But if you try to sell just the operating system, there will be difficulties. This is where market positioning comes to the rescue. For example, one might say “we are faster than they are”.





But for this you can get on trial! And there will be required to provide evidence. But how to prove that you are faster in all cases? This is not a race contest. But of course, this is not quite correct competition slightly out of the normal positioning in the market.



Normal positioning involves the formation of a portrait of the consumer identifying the properties of the product, which are more in demand, and focusing on these properties. Well, or form the user these needs. For example, our processor has such a frequency, the smartphone has a N-core processor, and so on.

')

Since the classics of the genre have already formulated that operating systems are needed not only for user systems, but also for managing various technological processes in automatic mode and even introduced the concept of real-time operating system, then, you know, it's a sin not to use. Introducing the concept of real-time systems, the classics talked about a kind of critical time threshold. That is, it differs from conventional systems, where if a user waits for something, then he can wait, a hard real-time system, for example, managing a turbine, cannot wait, otherwise you can get to something bad.



Thus, the user can be told that, unlike conventional operating systems, the user will be provided with a system that guarantees the system response time. Naturally, the smaller it is, the greater the number of different technological processes the system can control. And there is a set of tables, where various time parameters of RTOS are given as a key parameter.



How are they received? This process is honestly described! Here we take such a model task, such a hardware platform, and this is how we give effect. Well, marketing, of course, can simplify and simply give, the reaction time is 1 μc. But we do not take this into account, we believe that everything is honestly described.



But sorry, what if there is another task? 10 tasks, 100 tasks? And if a drunk programmer zalochit interrupts? And if in the system the programmer did not correctly prioritize the tasks?



There was a case when Embox was tested for real-timeness. We sat and thought how to prove that this is a real-time operating system. There is a laboratory, there is a customer who wants this to be so. We find out that real-timeness for a customer means a system response time of 1 µs. I ask if the following experiment will be evidence:

• We take some kind of hardware platform
• Send a signal to one of the GPIO inputs
• Programmatically catch the event
• At the output of the GPIO software signal
• Measurements are performed using an oscilloscope, the reaction time will be the difference between the input and output fronts.

The customer confirms that this is exactly what is needed. I ask a clarifying question, and we design the model system and we can not run (not load) it with other tasks. That is, it is normal that the system will do only such a simple test task. The customer said, for this and need test problems. Probably you understand that the test system has passed! Naturally with the confirmation of the characteristics, that is, the impact was multiple.



This section is written in no way in order to diminish any OS or some developers. And only to show the entire incompleteness of the picture. I did not claim that the characteristics of some operating systems do not allow them to refer to the RTOS, but that the term is just used by marketers. I saw other tests when I ordered the choice of the operating system of an independent laboratory based on the requirements of the task. There was a complex set of model tasks, and network interaction was considered, and how the parameters change if the system is loaded and the behavior in various abnormal situations.

Definition of the term “Real-Time Operating System”

Now I will introduce the term “Real-Time Operating System”. No, I'd rather not. The fact is that there are a large number of definitions of this term. Take at least the comments to the original article:

In real-time systems, a person is generally superfluous and, accordingly, the speed of a real-time system should be compared with the processes that it controls, whether it is an autonomous car or a process control system in a factory.

RTB / RTOS is exclusively a ranking for the predictability of response to critical events.

An RTOS is an OS in which the correctness of the task is characterized not only by logical correctness, but by the time it takes to complete the task.

Set the criterion time of the context switch of any task in 1 μs per 100 MHz processor with a float-point coprocessor with 0.1 μs determinism and everything will fall into place.

You will clearly see where the RTOS, and where not.

Well, and, I can not ignore the opinion about which I spoke in the article , sounded at one of the OSDAY conferences :

The system can be considered as a hard real-time system if there are no places in it where there are loops with an unknown number of iterations with interrupted interrupts.

But maybe all these are just particulars, and as suggested in the commentary, you should just use the classics and not invent bicycles. I will cite this classic (Andrew Tanenbaum, if someone did not guess):

“Another type of operating system is the real-time system. These systems are characterized by a key parameter. For example, it can be used in industrial process control systems. Often there are hard deadlines that must be met. For example, there is a need to place a car on the line. If the car will be ruined. If this is the case, it must be a hard real-time system. Found in industrial process control, military, and similar application areas. There must be certain guarantees.



There is no need for any real time damage. Digital audio or multimedia systems fall in this category. Digital telephones are also soft real-time systems.



It has been noted that it has been in the process of meeting its requirements. An example of this type of real-time system is e-Cos.



The categories of handhelds, embedded systems, real-time systems overlap. Nearly all the real-time aspects. The software is embedded in the system designers; users cannot add their own software, which makes protection easier. The handhelds and embedded systems are for industrial usage. Nevertheless, they have a certain amount in common. ”

But even from this description it follows only that systems can be used in systems where the absence of a reaction in a given period of time can lead to disastrous consequences. Well, in order to achieve the key parameter (not exceeding the reaction time), the OS can be a library, an example of eCos.

How to achieve real-time characteristics

I could not give a strict definition (if someone is willing to give, write in the comments). But in all of the above definitions, a couple of properties can be seen (this time and predictability). If we translate time into the predictability option (the weight of the arc when going from one state to another), then only predictability remains!



Let's think about how to achieve this.



It is obvious to remove all unnecessary from the critical system. A universal system is unlikely to make stable. Even Comrade Tanenbaum talked about this, I mean, when he spoke about eCos.



Another approach that increases the predictability of the system, again proposed by Tanenbaum , is the use of special (simple) algorithms for resource planning, primarily processor time, that is, special task schedulers. He proposed several approaches to planning, but I would like to first focus on a static planning table (Static table-driven).



The developer must ensure that all tasks have time to complete in their own quantum of time. To this end, it is proposed to statically analyze the critical task and determine its threshold values. This approach is laid down in the standard ARINC-653. The standard for onboard systems, and you know, if something suddenly does not have time to work out for an airplane, a catastrophe can happen.



The next approach is a static schedule, but based on priorities. That is, the developer must again analyze all situations and, assigning priorities to all tasks in the system, ensure that critical tasks are executed at a specified time.



I do not want to continue, because there is an original! He wrote, of course, better than I can do, well, and besides, they can again be accused of distorting the facts. I cited these very approaches in order to show that in any case, the developer of the final system is responsible for ensuring the characteristics of the system. And the operating system should only provide the appropriate features.



Continuing the reasoning on methods of increasing predictability, I want to give one more comment.

“You can get real time on Malinka, but not with RTOS, but with a small state machine that fits into its cache.”

Here I want to draw attention to the following points:

• increase of predictability (real-time properties) due to exclusion of any RTOS from the system at all
• representation of the program by the state machine
• Well, the dependence of real-time systems, not only on the properties of the software, but also hardware.

With a decrease in the number of unpredictability in the case of a decrease in the number of lines of code, I think everyone agrees. Although, as always, I do not agree, but more on that later.



What is the influence of the hardware, too, most likely no doubt. In particular, when it was said about the absence of cycles with an arbitrary number of iterations in the state of locked interrupts, it sounded that on some cortex-m in the described RTOS there are no interrupts at all. This is a little slyness, because there the interrupt controller disables interrupts with an equal or lower priority, independently, but the fact of influence is evident. And of course, the presence of cache, translation of addresses (or rather page misses), contributes to the uncertainty. Especially, I would like to draw attention to the fact that generally one hundred percent guarantee the correct operation of the equipment no one can. Well, you fell off the wiring, as the presence of RTOS will avoid catastrophic outcome of events?



Presentation of the program as a state machine, I would like to offer to consider from the non-obvious side. Namely, that a program to increase predictability can be analyzed. And since we are talking about all states, it should be analyzed, and statically, for all possible situations. Well, since functional programming languages ​​are much better suited to static analysis, it is possible to develop a program in some special language, or add the use of special programming languages. The first approach is used, for example, in the verified seL4 core. An example of the second approach is the same ARINC-653 standard, with its mandatory formation of requirements in the XML language.



There are other methods that increase predictability or, if you prefer, factors affecting the predictability of a system. I gave a report on this topic at an OSDay conference. In particular, besides those already listed, I also highlighted the architectural approach. After all, it is well known that, for example, micronuclear architecture can increase the predictability of the system. But even in the same report a slightly unobvious organizational approach was highlighted. Here we are talking about the moment where I did not agree that the lack of RTOS leads to an increase in predictability. If you think about it, then in general the concept of the operating system has significantly reduced the number of errors due to reuse of the code. That is, if you do not have a code that really fits into one switch / case, then it is better to use ready-made modules. After all, the parameter “the number of errors per 1000 lines of code” has not been canceled, and no matter how debugged your new code is, there are errors.

Does RTOS exist at all?

Having stopped on the previous section, on the statement that there is an error in any code, I want to make one more provocative thesis. Does RTOS exist at all?



Let's see. Discussing with a friend about real-time systems, we agreed that the real-time operating system (we are talking about hard real-time systems) can hardly exist. He proposed to present the entire system as a state machine or graph describing the maximum transition time from one state to another. In this case, the system can be considered stable if it is proved that for all input and internal states, there is an arc leading to a given state with a time limit. Well, you know, this is only possible for a very small system, just the very state machine mentioned in the commentary, but in the modern world few people need such a system.



But we do not doubt that real-time systems exist. And of course, RTOS too. If this were not so, then the first flowering woodpecker would have destroyed civilization, then there would be no avionics, astronautics, robotics, automated control systems, and much more.



How to get out of the situation. Very simple, although in general a problem, most likely not solved, but for a particular problem, you can introduce constraints that make it solvable, with some sensible probability of error.



For example, standards are introduced: realtime POSIX , ARINC-653 , ITRON . These standards, in fact, distinguish a class of tasks that can be solved if you follow this standard. Or research is carried out by independent laboratories that study whether the properties of a particular operating system are suitable for solving the target problem.

So Embox RTOS or non RTOS?

In my opinion, the answer to a similar question, both for Embox and for any other OS, can only be with the question: “What do you mean?”. More precisely: "What do you mean by the concept of real time?". That is, if you are interested in the interrupt handling time, and whether it is possible to call the interrupt handler directly, this is one thing, if you need to increase the reliability of work, albeit slowly, but it’s definitely much less likely to fail, is another Verification is the fourth. It is not by chance that the great classic Andrew Tanenbaum, although he proposed methods for increasing predictability, used the very concept of a real-time system, but refrained from some strict definitions.



PS At the time of writing this article, no RTOS was affected.