Real-time operating systems (RTOS). Requirements regulation system

Useful tips

Distinctive features of an RTOS from an OS general purpose

General-purpose operating systems, especially multi-user operating systems such as UNIX, are focused on optimally distributing computer resources among users and tasks. In real-time operating systems, such a task fades into the background - everything recedes before the main task - to have time to react to events occurring at the object. Another difference is that the use of a real-time operating system is always associated with the equipment, with the object, with the events occurring at the object. A real-time operating system is focused on processing external events. A real-time operating system may have a user interface similar to a general-purpose OS, but it is designed completely differently. In addition, the application of real-time operating systems is always specific. If a general purpose OS is generally perceived by users (not developers) as already ready set applications, then the real-time operating system serves only as a tool for creating a specific real-time hardware and software complex. And therefore, the widest class of users of real-time operating systems are developers of real-time systems, people designing control and data acquisition systems. Designing and developing specific system real time, the programmer always knows exactly what events can occur at the facility, knows the critical time frame for servicing each of these events. The RT system must have time to respond to an event that occurred at the facility within the time critical for this event. The value of the critical time for each event is determined by the object and the event itself, and can be different, but the reaction time of the system must be predicted (calculated) when creating the system. Failure to respond at the predicted time is considered an error for real-time systems. The system must be able to respond to simultaneously occurring events. Even if two or more external events occur simultaneously, the system must have time to react to each of them within the time intervals critical for these events.

	Real time OS	General purpose OS
The main task	Have time to react to events occurring on the equipment	Optimally distribute computer resources between users and tasks
What is it focused on?	Handling External Events	Processing user actions
How it is positioned	A tool for creating a specific real-time hardware and software complex	Perceived by the user as a set of applications ready to use
Who is it intended for?	Qualified developer	Intermediate user

Hard and soft real-time systems

There are two types of real-time systems - hard real-time systems and soft real-time systems.

Hard real-time systems do not allow any delay in system response under any circumstances because:

results may be useless if late
disaster may occur if the reaction is delayed

the cost of being late can be infinite.

Examples of hard real-time systems are on-board control systems, emergency protection systems, emergency event recorders.

Soft real-time systems are characterized by the fact that the response delay is not critical, although it can lead to an increase in the cost of results and a decrease in the performance of the system as a whole. An example is network operation. If the system does not have time to process the next received packet, this will lead to a timeout on the sending side and resending (depending on the protocol, of course). Data is not lost, but network performance is reduced. The main difference between hard and soft real-time systems can be expressed as follows: a hard real-time system should never be late in responding to an event, a soft real-time system should never be late in responding to an event

Operating system kernel

The kernel is the central part of the operating system (OS), providing applications with coordinated access to computer resources, memory, external Hardware, an external input and output device, translating application language commands into binary code that the computer understands. As the fundamental element of the OS, the kernel is the most low level abstractions for applications to access the system resources necessary for their operation. Typically, the kernel provides such access to the executing processes of the corresponding applications through the use of interprocess communication mechanisms and application access to system calls OS.

Monolithic core

The monolithic kernel provides a rich set of hardware abstractions. All parts of a monolithic kernel operate in the same address space. This is an operating system design in which all components of its kernel are components one program, use common data structures and interact with each other by directly calling procedures. The monolithic kernel is the oldest way to organize operating systems. An example of systems with a monolithic kernel is most UNIX systems.

Advantages: Speed of operation, simplified development of modules.

Flaws: Since the entire kernel operates in the same address space, a failure in one of the components can disrupt the entire system.

Some old monolithic kernels, especially UNIX/Linux-class systems, required recompilation whenever the hardware composition changed. Most modern kernels allow you to load modules during operation that perform part of the kernel functions. In this case, the components of the operating system are not independent modules, but components of one big program called a monolithic kernel, which is a set of procedures, each of which can call each. All procedures run in privileged mode.

Microkernel

The microkernel provides only basic process control functions and a minimal set of abstractions for working with hardware. Most of the work is done through special user processes called services. The decisive criterion for “microkernelism” is the placement of all or almost all drivers and modules in service processes.

Advantages: Resistance to hardware failures and errors in system components. The main advantage of microkernel architecture is high degree modularity of the operating system kernel. This makes it much easier to add new components to it. In a microkernel operating system, you can load and unload new drivers, file systems, etc. without interrupting its operation. The process of debugging kernel components is significantly simplified, since a new version drivers can be loaded without restarting the entire operating system. The components of the operating system kernel are no fundamentally different from user programs, so you can use ordinary tools to debug them. Microkernel architecture improves system reliability because a failure at the unprivileged program level is less dangerous than a failure at the kernel mode level.

Flaws: Passing data between processes requires overhead.

Runtime environment

The requirements for the execution environment of real-time systems are as follows:

small system memory - for the possibility of its embedding;
the system must be completely memory resident to avoid memory page swapping or swapping;
the system must be multitasking - to ensure maximum effective use all system resources;
core with priority for servicing interrupts. Interrupt priority means that a process that is ready to run and has a certain priority necessarily has priority in the queue over a process with a lower priority, quickly replaces the latter and proceeds to execution. The core finishes any service work, as soon as a task with the highest priority arrives. This ensures the predictability of the system;
priority manager - allows the application developer to assign each boot module a priority that is not subject to the system. Priority assignment is used to determine the order in which programs that are ready to be executed are executed. An alternative to this type of scheduling is carousel scheduling, in which every program that is ready to continue is given an equal chance of running. With this method, there is no control over which program will be executed and when. This is unacceptable in a real-time environment. Priority-based dispatch and an interrupt-priority kernel give the application developer full control of the system. If a higher priority event occurs, the system stops processing the lower priority task and responds to the newly received request.

The combination of the properties described above creates a powerful and efficient real-time execution environment.

In addition to the properties of the runtime environment, it is also necessary to consider the service provided by the real-time OS kernel. The core of any real-time runtime environment is the kernel or dispatcher. The kernel controls the target computer's hardware: central processor, memory and input/output devices; controls the operation of all other systems and software of an applied nature. In a real-time system, the dispatcher sits between the target computer's hardware and the application software. It provides special service, necessary for running real-time applications. The service provided by the kernel gives application programs access to system resources such as memory or input/output devices.

The kernel can provide different types of services:

Intertask exchange. It is often necessary to transfer data between programs within the same system. In addition, many applications need to communicate with other systems over a network. Internal communication can be carried out through a messaging system. External communication can be organized either through a datagram (best delivery method) or via communication lines (guaranteed delivery). The choice of one method or another depends on the communication protocol.
Data separation. IN application programs ah, working in real time, the most time-consuming is data collection. Data is often necessary for the operation of other programs or is needed by the system to perform some of its functions. Many systems provide access to shared memory sections. Data queuing is widespread. There are many types of queues in use, each of which has its own advantages.
Processing requests from external devices. Each application program is connected in real time to an external device of some type. The kernel must provide I/O services that allow application programs to read from and write to these devices. For real-time applications, it is common to have a this application external device. The kernel must provide a service that makes working with device drivers easier. For example, provide the ability to write in high-level languages - such as C or Pascal.
Handling special situations. An exception is an event that occurs during program execution. It can be synchronous if its occurrence is predictable, such as division by zero. And it can also be asynchronous if it occurs unpredictably, such as a voltage drop. Providing the ability to handle these types of events allows real-time applications to respond quickly and predictably to internal and external events. There are two methods for handling exceptions - using state values to detect error conditions and using an exception handler to trap error conditions and correct them.

Overview of RTOS architectures

Over its history, operating system architecture has undergone significant development. One of the first principles of construction, monolithic OS (Figure 1) consisted of presenting the OS as a set of modules that interact with each other in various ways within the system core and provide application programs with input interfaces for accessing hardware.

level OS (Figure 2). An example of such an OS is good known system MS-DOS. In systems of this class, application applications could access the hardware not only through the system kernel or its resident services, but also directly. RTOSs have been built on this principle for many years. Compared to monolithic operating systems, this architecture provides a significantly greater degree of predictability of system reactions, and also allows for fast access hardware applications. Disadvantage

What makes such systems so bad is their lack of multitasking. Within this architecture, the problem of processing asynchronous events was reduced to buffering messages, and then sequentially polling the buffers and processing them. At the same time, compliance with critical service deadlines was ensured by the high performance of the computing complex compared to the speed of external processes.

Figure 2. Layered OS architecture

One of the most effective architectures for building real-time operating systems is the client-server architecture. General scheme An OS running on this technology is shown in Figure 3. The main principle of this architecture is the transfer of OS services in the form of servers to the user level, and the microkernel performs the functions of a message manager between client user programs and servers - system services. This architecture provides a lot of advantages in terms of requirements for RTOS and embedded systems. Among these advantages are:

1. The reliability of the OS increases, because each service is, in essence, standalone application and it's easier to debug and track errors.

2. Such a system scales better, since unnecessary services can be excluded from the system without compromising its performance.

3. The fault tolerance of the system increases, because A frozen service can be restarted without

reboot the system.

Figure 3. Building an OS using client-server architecture

Unfortunately, today there are not many operating systems implemented on the client-server principle. Among the well-known RTOSes that implement microkernel architecture are OS9 and QNX.

List of used literature:

1) http://ru.wikipedia.org/wiki/Real_time_operating system

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5)http://www.ozon.ru/context/detail/id/3092042/

OS real time

1. Introduction: Features of real-time operating systems

1.1. Processes, threads, tasks

1.2. Planning, priorities

1.3. Memory

1.4. Interrupts

1.5. Clocks and timers

1.6. RTOS standards

1.6.1. POSIX

1.6.2. DO-178B

1.6.3. ARINC-653

1.6.4. OSEK

1.6.5. Safety Standards

1.7. Operating system customizability

2. Brief characteristics of the most common RTOS

2.1. VxWorks

2.2. QNX Neutrino RTOS

2.3. RTEMS

2.4. ChorusOS

2.5. Real-time extensions for Windows NT

2.5.1. RTXForWindows NT

2.5.2. INtime

2.5.3. Microsoft Windows Embedded

2.6. TinyOS

2.7. OSEK/VDX

2.8. OSE RTOS

2.9. Contiki

2.10. pSOS

2.11. INTEGRITY

2.12. LynxOS

2.13. Microware OS-9

2.14. GRACE-OS

2.15. C EXECUTIVE

2.16. CMX-RTX

2.16.1. CMX-TINY+

2.17. Inferno

3. OS designed specifically for portable devices

3.1. ITRON

3.2. Windows CE

3.3. JavaOS

3.4. Jbed

3.5. Nucleus RTOS

3.6. EMERALDS

3.7. CORTEX

3.8. DeltaOS

3.9. Palm OS

3.10. Symbian OS (EPOC)

4. Customizability of operating systems

4.1. Human adaptation

4.1.1. Static adaptation initiated by the designer

4.1.2. Dynamic adaptation initiated by the administrator

4.2. Application initiated adaptation

4.2.1. Adaptation from the application level

4.2.2. Kernel level adaptation

4.3. Automatic adaptation

5. Summary tables of characteristics of RTOS properties

Appendix A. List of abbreviations

Appendix B. Terminology

Literature

List of RTOS mentioned in this text, in print and on the Internet

1. Introduction: Features of real-time operating systems

Real-time operating systems (RTOS) are designed to provide an interface to the resources of time-critical real-time systems. The main task in such systems is the timeliness of data processing.

The main requirement for an RTOS is to ensure predictability or determinism system behavior in the worst external conditions, which sharply differs from the performance and speed requirements of universal operating systems. A good RTOS has predictable behavior under all system load scenarios (simultaneous interruptions and thread execution).

There is some difference between real-time systems and embedded systems. An embedded system is not always required to have predictable behavior, in which case it is not a real-time system. However, even a cursory glance at possible embedded systems suggests that most embedded systems need predictable behavior, according to at least, for some functionality, and thus, these systems can be classified as real-time systems.

It is customary to distinguish between soft and hard real-time systems. IN hard systems real-time, the inability to provide a response to any events at a given time leads to failures and the inability to complete the assigned task. In most Russian-language literature, such systems are called systems with deterministic time. In practical applications, the reaction time should be minimal. Soft real-time systems are systems that do not fall under the definition of “hard”, because There is no clear definition for them in the literature yet. Soft real-time systems may not have time to solve a problem, but this does not lead to failure of the system as a whole. In real-time systems, it is necessary to introduce a certain deadline (in English literature - deadline), before the expiration of which the task must necessarily (for soft real-time systems - preferably) be completed. This deadline is used by the task scheduler both to assign a priority to a task when it is launched and when selecting a task for execution.

Martin Timmerman formulated the following necessary requirements for an RTOS:

The OS must be multitasking and preemptable,

The OS must have a concept of priority for threads,

The OS must support predictable synchronization mechanisms,

The OS must provide a mechanism for inheriting priorities,

OS behavior must be known and predictable (interrupt processing delays, task switching delays, driver delays, etc.); this means that in all system workload scenarios, the maximum response time must be determined.

Over the past 25-30 years, the structure of operating systems has evolved from monolithic to multi-layer OS structure to client-server architecture. In a monolithic structure, the OS consists of a set of modules, and changes to one module affect other modules. The more modules, the more chaos there is during the operation of such a system. Additionally, it is not possible to distribute the OS on a multiprocessor system. In a multilayer structure, changes in one layer affect adjacent layers; in addition, inversion through the layer is not possible. For real-time systems, direct access to each layer of the OS must be provided, and sometimes directly to the hardware.

The main idea of client-server technology in an OS is to reduce the OS basis to a minimum (scheduler and synchronization primitives). All other functionality is moved to another level and implemented through threads or tasks. A set of such server tasks is responsible for system calls. Applications are clients that request services through system calls.

Client-server technology allows the creation of scalable operating systems and simplifies distribution in a multiprocessor system. When operating the system, replacing one module does not cause a “snowball” effect; In addition, a module failure does not always entail a failure of the system as a whole. There is now the ability to dynamically load and unload modules. The main issue in this model is memory protection, since server processes must be protected. Each time a service request is made, the system must switch from the application context to the server context. With memory protection support, the switching time from one process to another increases.

As a rule, most modern RTOS are built on the basis of a microkernel (kernel or nucleus), which provides scheduling and dispatching of tasks, as well as their interaction. Even though the kernel minimizes OS abstractions, the microkernel still needs to have an understanding of process abstractions. All other conceptual abstractions of operating systems are moved outside the kernel, called upon request, and executed as applications.

Let's look at the conceptual abstractions of the operating system through the prism of requirements for real-time systems.

Review presented comparative characteristics OS RV present on Russian market, with reference to use in aviation control systems.

Thanks to development computer technology V Lately It has become possible to assign to one module tasks previously performed by several processor modules, while improving the weight and size characteristics of the control system and reducing its cost. This trend in aviation technology has led to the emergence of the concept of integrated modular avionics - IMA (Integrated Modular Avionics, IMA).

The problem of integrating control functions into a single module is that it is necessary to separate the now shared resources(processor time, memory, exchange channels) between various tasks, while providing the same level of reliability and independence of functions as before. The real-time operating system plays a key role in solving this problem.

Currently, there are several commercial RTOSes for critical applications on the world market (Table 1). This article provides an overview of RTOS available on the Russian market, based on information from open sources and personal experience of the authors.

Documents regulating the requirements for RTOS

The DO-178 standard (Software Consideration in Airborne Systems and Equipment Certification) defines the requirements for the software development process and the thoroughness of its verification depending on its level of criticality. The level of software criticality is determined based on an analysis of the severity of the consequences of a software failure. There are five levels of software criticality in total (from A to E).
MILS (Multiple Independent Levels of Security) is a special approach to OS design that prevents the propagation of application software errors during runtime, and also simplifies program verification due to software modularity. All applications are placed in so-called sections (partitions). Partitions have allocated resources (memory area, processor time during each system cycle, access to communication channels, etc.). Access to allocated resources is guaranteed by the OS running in supervisor mode. Thus, application software of different levels of criticality can run on one processor module running one OS - if a failure occurs in less critical (and, accordingly, less tested) software, this will not in any way affect the operation of other sections, since attempts to “usurp” other people's resources will be blocked by the operating system. The ideas of MILS echo those of IMA and DO-178B.
The ARINC-653 (Avionics Application Software Standard Interface) standard specifies an APEX application software interface that supports a MILS-style partition concept. This interface includes functions for managing partitions, processes, time sharing, communications between and within partitions, and monitoring system status. It should be noted that the ARINC-653 standard describes a generally accepted approach to implementing MILS ideas for IMA, although there may be other implementations. An aviation RTOS that complies with ARINC-653 has advantages because this standard is well known and understood by international certification bodies, so it is easier to obtain a DO-178B certificate of conformity for a system built according to this standard.
Reusable Software Components standard. In accordance with DO-178B, the software of a particular aviation application system undergoes the entire certification procedure, even if it uses modules (components) that have already been certified previously as part of another system. One of the latest FAA initiatives ( Federal agency for civil aviation certification, USA) is to determine the criteria for the possibility of reusing software without re-certification. Components that may not be re-certified are called RSC (Reusable Software Components). To obtain a certificate for the RSC, you need to spend more effort, but then RSC provides serious savings.

Russian documents defining software requirements (including RTOS):

GOST R ISO/IEC 51904-2002 (“Embedded systems software. General requirements for development and documentation”) - an analogue of DO-178B for military aviation;
KT-178A (“Qualification requirements part 178A”) - an analogue of DO-178B for civil aviation;
GOST R ISO/IEC 12207-99 (“ Information technology. Processes life cycle software").

The comparison of the RT OS was carried out according to 13 parameters, which take into account technical criteria, ease of development and economic parameters.

OS timing parameters

One of the main requirements for RT OS is minimum time delays in processing a particular event. In practice, this means that the following parameters must be small:

interrupt response time - the time between the actual occurrence of the interrupt and the start of processing the first instruction of the interrupt handler;
control thread switching time - switching time between two threads in one process;
process context switching time (only for OSes that support the process model) - switching time between two control threads belonging to two different processes.

Unfortunately, it is impossible to objectively compare specified parameters Determining different RTOS is not easy, because these parameters depend not only on the quality of the OS, but also on the capabilities of the hardware platform used. Ideally, all operating systems being compared should be installed on the same hardware platform, after which appropriate measurements should be made. But even these measurements will not give an objective result, because different operating systems can be more or less adapted to specific hardware.

To compare timing parameters, this article uses fragmented data found on the Internet, which is often obtained when testing the OS on various equipment, while the composition and nature of the tests are not always clear.

The results obtained by the experts of the Dedicated System magazine, who conducted testing and practical comparison QNX RTOS 6.1, VxWorks AE 1.1 and Windows CE.NET on the x86 platform. Although this data is currently outdated, the authors of this article were unable to find more recent material. In table Figure 2 shows selected performance comparison data between QNX Neutrino 6.1 and VxWorks AE 1.1. The Dedicated Systems report gave preference to QNX in terms of performance, with the score ratio set at 9:5 (QNX:VxWorks), because during the testing process two errors were discovered in VxWorks, for which it was necessary to contact support to correct them.

In table 3 shows data on the characteristics of LynxOS. The composition of the tests used is not specified. As for data on the characteristics of LynxOS, the fourth column (testing on the x86 platform) is interesting. Compared to VxWorks and QNX, the LynxOS RT OS shows a huge delay in responding to interruptions (more than 5 times). The context switch time (meaning the time to switch between two threads in the same process) is the same as QNX and about 1.5 times less than VxWorks.

Stability of timing parameters

In addition to timing characteristics, the stability of these characteristics is also important for RT OS. It is this criterion that largely determines the “rigidity” of the RT OS, i.e. predictability of data processing time, the moment of issuing results, etc.

Based on data from the Dedicated System journal, QNX is ahead of VxWorks in this criterion both in terms of the spread of characteristics in a series of similar tests (the ratio of the maximum time to the average value is significantly less) and with increasing load (thread switching time when the number of threads increases from 2 to 128 units. QNX grew only 1.65 times, while VxWorks grew 2.24 times).

According to data obtained from RTSoft, it is known that LynxOS has approximately the same characteristics as VxWorks.

Managing access to resources

Let's evaluate the quality of access control offered by one or another RT OS to critical resources computing system, such as memory and CPU time.

The first question that needs to be answered is whether the OS supports the process model. A process is a logical entity that owns one or more threads, their associated resources, and context—the contents of registers and counters at any given time.

The task of the processes is:

in restricting access to random access memory between various programs in the process of execution;
in delimiting the scope of global variables at the time of compilation (critical if the application software is written in the C language, which does not support such delimitation).

Segmentation also provides separation of address spaces (in this sense, the capabilities of sharding and processes are duplicated). In addition, sharding provides each segment containing one or more processes (or threads if the OS does not support the process model) with a guaranteed time budget. This way, if a high-priority thread goes into a loop and disrupts its segment, all other segments will receive CPU time according to the design-time settings and continue to function normally.

LynxOS and QNX support both the process model and sharding. VxWorks OS has a sharding mechanism, but does not support the process model. In general, this is acceptable because sharding provides separation of address spaces. But the lack of processes brings some inconveniences. Typically, division into segments is performed based on the intended purpose of the software and its criticality. For example, some segment may contain control software for a flight navigation system that has high level criticality. But this software is also a rather complex complex, which would be logical to be divided into independent (memory) modules. VxWorks OS does not provide this feature, that is, the segment will consist of threads with shared memory, which complicates the organization of parallel development and, ultimately, reduces the reliability of the software.

Support for multiprocessor and distributed systems

The cost of multiprocessor modules has recently decreased significantly, and therefore they have become increasingly used in embedded systems. Of course, the RT OS must provide support for such boards.

Another promising direction in building self-propelled guns is distributed systems, where the modules are separated in space, and communication between them occurs through some network environment. Again, the RT OS used must have convenient and reliable means for organizing the interaction of modules: support for various network protocols, means of ensuring network transparency.

QNX RT OS offers support for multiprocessor boards. For VxWorks, such support has only just been announced. There is no aviation version of LynxOS with support for multiprocessor boards yet.

With regard to support for network protocols, it should be noted that the RT OS LynxOS, VxWorks and QNX have approximately equal (and broad) capabilities. An additional advantage The QNX RT OS is its special network subsystem architecture, which provides network “transparency” of application programs: any process can call another process on a remote module in the same way as a process on a local module.

File system support

The ability to store information in the form of files is convenient and traditional. Conversely, the lack of such a possibility creates difficulties when storing rarely changed data and creating distributed systems.

In table Figure 4 shows the file system support for each of the operating systems under consideration.

QNX has the most extensive support for file systems. In addition, its flash file system is fault-tolerant.

Documentation quality

The quality of documentation for RT OS LynxOS, VxWorks, QNX is quite high. However, there are also complaints about the documentation:

QNX is an excellent description of the architecture and design principles, but an insufficient description of the application programming interface (not all parameters are described, there are inconsistencies);
VxWorks - no explanation of how it works and insufficient description of the complex process of configuring the OS.

However, companies are working on the quality of the material. Documentation for current version QNX (6.3.2) has been significantly expanded, some parts have been reworked.

Quality of technical support

According to the quality of the official technical support the undoubted leader is LynxOS. LynuxWorks promises to answer any technical question within 4 hours of the request being posted. LynxOS is distributed in Russia by RTSoft, which has a large staff of employees capable of providing qualified assistance. The disadvantage of LynxOS is that the OS is not yet very widespread in Russia; accordingly, there is no established user community, and there is not even a Russian-language forum.

QSS (the maker of QNX) also offers good technical support, but quick response times are not guaranteed. Unlike LynxOS, the QNX RT OS has a well-organized user community both abroad and in Russia. Answers to most questions can be found on these forums. QNX in our country is distributed by SVD Embedded Systems, whose employees are able to provide competent technical support and carry out work on adapting the OS to specific processor boards. In addition, the company has direct contacts with QSS and can receive advice on complex issues from the developer of the RT OS QNX.

WindRiver, the developer of VxWorks, traditionally adheres to a closed technical policy, that is, information about the operating principles of the OS is quite difficult to obtain. This OS also does not have a Russian-language forum. The VxWorks RT OS is distributed in our country by the company AVD Systems, which is mainly engaged in sales of ready-made software and hardware solutions of foreign origin.

Open source

An open RT OS has at least three advantages:

Application software developers can understand complex problems without involving technical support;
easier to certify (no bookmarks, etc.);
more dynamic development, since the RT OS developer company often receives not only requests for error corrections, but also proposals for eliminating errors and improving the system. Communities of open source RTOS developers, as a rule, grow much faster and are better organized. Independent experts appear to help solve the problems of the technical support service and participate in the development, debugging and testing of the system.

Since September 2007, QSS has opened source codes QNX kernels (including Adaptive Partitioning package, High Availability package). A little later, the source codes of the network subsystem were opened. Currently, beta version 6.4.0 is available for download on the official website.

It should be noted that today not all QNX modules are open source (for example, there are no codes for graphics and file systems), and the license imposes a restriction on the use of the “source”: only for non-commercial use. However, the QNX user gets the above benefits for free.

LynxOS and VxWorks source codes are commercially available. The price for such a product is negotiable.

Tools

Availability of good tools largely determines the quality and speed of development of application programs for a particular OS. It should be noted that LynxOS, VxWorks and QNX currently provide good quality tools that include an integrated development environment (IDE) and application software debugging, program profiling tools (to detect bottlenecks in performance, memory, etc.). The ergonomics of the ISD for these RT OSs is generally not inferior to developed development tools for conventional OSs (for example, MS Windows).

Application software portability

The portability of application software makes it possible to use it under other operating systems (including non-RT OS). Portability gives the application software developer a certain independence from the RT OS: if necessary, you can switch to another OS at low cost.

The ability to write portable software is determined by this moment compliance with the POSIX standard. All considered RT OSs support the POSIX 1003.1 standard. LynxOS has an advantage - this OS is binary compatible with Linux. That is Linux applications can be run under LynxOS without recompiling. Conversely, LynxOS applications can be run on Linux (version 2.4.x with the glibs C language library version 2.2.2).

The rest of the RT OS require their recompilation to run Linux applications. In this case, often the transfer process even POSIX-compliant applications can become quite labor-intensive due to differences in the implementation of libraries and compilers.

Processor architecture support

Domestic developers of control systems for aviation in today's period of transition from in-house operating systems to commercial ones often find themselves in a situation where they need to select and adapt an RTOS to an existing processor board. In this case, one of the key arguments when choosing an OS is support for the processor architecture used on the board.

Compliance with aviation standards

In foreign practice, software for avionics systems must have a certificate of compliance with the DO-178B standard. If software of different levels of criticality is executed on the same processor module, then the RTOS used must support the concept of partitions. (Otherwise it is almost impossible to prove the non-propagation of the error). As already mentioned, it is better if the RTOS programming interface complies with the ARINC-653 standard, since the standard is well known to foreign certification bodies.

LynxOS is a leader when it comes to standards compliance. It supports ARINC-653, and there are many examples of DO-178B certified systems built on it. The key point is that LynuxWorks offers a set of RSC (although the authors of the article do not know anything about the price).

VxWorks complies with the ARINC-653 standard, and systems built on top of it can be certified to DO-178B (there is a large number of examples).

QNX does not comply with ARINC-653, and there are no DO-178B certified systems based on them yet.

It should be noted that QNX systems can in principle be used to build an IMA, because QNX supports its own method of providing the partition concept, which is a very good alternative to ARINC-653 and, in addition, allows you to save processor time.

Regarding similar Russian standards for military aviation (GOST R ISO/IEC 51904-2002), there is not yet a single example of a certified system, although in principle such a system can be developed based on any of the OS under consideration. For the QNX RT OS, work is currently underway to prepare the main OS modules for certification.

Development of the specialist training system

The speed and quality of training for personnel working with the RT OS and various software development and debugging tools is directly related to the speed of software development and its quality. Leading companies in the field of embedded and system software, such as WindRiver, LynuxWorks, QSS, conduct a large-scale program of courses and trainings to study the use of the company's products, including the RT OS.

Comparison results

The QNX Neutrino RTOS is the most advanced OS from a technical point of view, has a good set of tools, has relatively low price. Microkernel architecture ensures high reliability and modularity of developed systems. An additional advantage is the open source code. But there is also a “fly in the ointment”: currently QNX is practically not used anywhere in aviation, and in this respect this OS loses to its competitors (LynxOS and VxWorks). Additional disadvantage of QNX: non-compliance with the ARINC-653 standard.

It should be noted that, in principle, QNX Neutrino has all the necessary mechanisms for working in avionics systems. In addition, the reliability and high availability of QNX-based systems has been proven in other industries where the cost of error is even higher than in aviation (nuclear reactor control).

Work to prepare for the certification of QNX Neutrino according to the requirements of domestic aviation standards is currently being carried out by SWD Software.

RTOS LynxOS-178, on the contrary, has all the necessary certificates abroad, although according to many other criteria it looks less preferable than QNX Neutrino. Note that for use in the Russian aviation industry, the LynxOS-178 RTOS must also be certified according to domestic GOSTs.

VxWorks OS has a long history of use in mission-critical applications abroad. However, our analysis shows that it looks less preferable to the first two operating systems according to many criteria. In addition, VxWorks' credibility is undermined by its closed development strategy.

An overview of the comparative characteristics of the RT OS present on the Russian market is presented in relation to use in aviation control systems.

05/05/2008, Mon, 23:56, Moscow time

Thanks to the development of computer technology, it has recently become possible to assign to one module tasks previously performed by several processor modules, while improving the weight and size characteristics of the control system and reducing its cost. This trend in aviation technology has led to the emergence of the concept of integrated modular avionics - IMA (Integrated Modular Avionics, IMA).

The problem of integrating control functions into a single module is that it is necessary to share the now common resources (processor time, memory, communication channels) between various tasks, while ensuring the same level of reliability and independence of functions as before. The real-time operating system plays a key role in solving this problem.

Documents regulating the requirements for RTOS

The DO-178 standard (Software Consideration in Airborne Systems and Equipment Certification) defines the requirements for the software development process and the thoroughness of its verification depending on its level of criticality. The level of software criticality is determined based on an analysis of the severity of the consequences of a software failure. There are five levels of software criticality in total (from A to E).

MILS (Multiple Independent Levels of Security) is a special approach to OS design that prevents the propagation of application software errors during runtime, and also simplifies program verification due to software modularity. All applications are placed in so-called sections (partitions). Partitions have allocated resources (memory area, processor time during each system cycle, access to communication channels, etc.). Access to allocated resources is guaranteed by the OS running in supervisor mode. Thus, application software of different levels of criticality can run on one processor module running one OS - if a failure occurs in less critical (and, accordingly, less tested) software, this will not in any way affect the operation of other sections, since attempts to “usurp” other people's resources will be blocked by the operating system. The ideas of MILS echo those of IMA and DO-178B.

Error 404: The page cannot be found.

This may have happened for one of these reasons:

– error when typing page address (URL)
– following a “broken” (non-working, incorrect) link
– the requested page was never on the site or it was deleted

You can:

– go back using the browser’s Back button
– check the correct spelling of the page address (URL)
– use the site map or go to the main page

The ARINC-653 (Avionics Application Software Standard Interface) standard specifies an APEX application software interface that supports a MILS-style partition concept. This interface includes functions for managing partitions, processes, time sharing, communications between and within partitions, and monitoring system status. It should be noted that the ARINC-653 standard describes a generally accepted approach to implementing MILS ideas for IMA, although there may be other implementations. An aviation RTOS that complies with ARINC-653 has advantages because this standard is well known and understood by international certification bodies, so it is easier to obtain a DO-178B certificate of conformity for a system built according to this standard.

Reusable Software Components standard. In accordance with DO-178B, the software of a particular aviation application system undergoes the entire certification procedure, even if it uses modules (components) that have already been certified previously as part of another system. One of the latest initiatives of the FAA (Federal Aviation Certification Agency, USA) is to define criteria for the reusability of software without re-certification. Components that may not be re-certified are called RSC (Reusable Software Components). It takes more effort to get RSC certified, but then RSC provides significant savings.

Russian documents defining software requirements (including RTOS):

GOST R ISO/IEC 51904-2002 (“Embedded systems software. General requirements for development and documentation”) - an analogue of DO-178B for military aviation;
KT-178A ("Qualification requirements part 178A") - an analogue of DO-178B for civil aviation;
GOST R ISO/IEC 12207-99 ("Information technology. Software life cycle processes").

The comparison of the RT OS was carried out according to 13 parameters, which take into account technical criteria, ease of development and economic parameters.

OS timing parameters

One of the main requirements for RT OS is the minimum delay time for processing an event. In practice, this means that the following parameters must be small:

interrupt response time - the time between the actual occurrence of the interrupt and the start of processing the first instruction of the interrupt handler;
control thread switching time - switching time between two threads in one process;
process context switching time (only for OSes that support the process model) - switching time between two control threads belonging to two different processes.

Unfortunately, it is not easy to objectively compare these parameters of different RT OSs, because these parameters depend not only on the quality of the OS, but also on the capabilities of the hardware platform used. Ideally, all operating systems being compared should be installed on the same hardware platform, after which appropriate measurements should be made. But even these measurements will not give an objective result, because different operating systems can be more or less adapted to specific hardware.

Quite objective data can be considered the results obtained by experts from the Dedicated System magazine, who conducted testing and practical comparison of QNX RTOS 6.1, VxWorks AE 1.1 and Windows CE.NET on the x86 platform. Although this data is currently outdated, the authors of this article were unable to find more recent material. In table Figure 2 shows selected performance comparison data between QNX Neutrino 6.1 and VxWorks AE 1.1. The Dedicated Systems report gave preference to QNX in terms of performance, with the score ratio set at 9:5 (QNX:VxWorks), because during the testing process two errors were discovered in VxWorks, for which it was necessary to contact support to correct them.

In table 3 shows data on the characteristics of LynxOS. The composition of the tests used is not specified. As for data on the characteristics of LynxOS, the fourth column (testing on the x86 platform) is interesting. Compared to VxWorks and QNX, the LynxOS RT OS shows a huge delay in responding to interruptions (more than 5 times). The context switch time (meaning the time to switch between two threads in one process) is the same as QNX and is about 1.5 times less than VxWorks.

Stability of timing parameters

Based on data from the Dedicated System log, QNX is ahead of VxWorks in this criterion both in terms of the spread of characteristics in a series of similar tests (the ratio of the maximum time to the average value is significantly less) and with increasing load (thread switching time when the number of threads increases 2...128 units for QNX grew only 1.65 times, while for VxWorks - 2.24 times).

According to data obtained from RTSoft, it is known that LynxOS has approximately the same characteristics as VxWorks.

Managing access to resources

Let's evaluate the quality of access control offered by one or another RT OS to critical resources of the computing system, such as memory and processor time.

The task of the processes is:

in delimiting access to RAM between different programs during execution;
in delimiting the scope of global variables at the time of compilation (critical if the application software is written in the C language, which does not support such delimitation).

LynxOS and QNX support both the process model and sharding. VxWorks OS has a sharding mechanism, but does not support the process model. In general, this is acceptable because sharding provides separation of address spaces. But the lack of processes brings some inconveniences. Typically, division into segments is performed based on the intended purpose of the software and its criticality. For example, some segment may contain control software for a flight navigation system that has a high level of criticality. But this software is also a rather complex complex, which would be logical to be divided into independent (memory) modules. The VxWorks OS does not provide this feature, that is, the segment will consist of threads with shared memory, which complicates the organization of parallel development and, ultimately, reduces the reliability of the software.

Support for multiprocessor and distributed systems

Another promising direction in the construction of automatic control systems is distributed systems, where modules are separated in space, and communication between them occurs through some network environment. Again, the RT OS used must have convenient and reliable means for organizing the interaction of modules: support for various network protocols, means for ensuring network transparency.

QNX RT OS offers support for multiprocessor boards. For VxWorks, such support has only just been announced. There is no aviation version of LynxOS with support for multiprocessor boards yet.

With regard to support for network protocols, it should be noted that the RT OS LynxOS, VxWorks and QNX have approximately equal (and broad) capabilities. An additional advantage of the QNX RT OS is its special network subsystem architecture, which ensures network “transparency” of application programs: any process can call another process on a remote module in the same way as a process on a local module.

File system support

In table Figure 4 shows the file system support for each of the operating systems under consideration.

QNX has the most extensive support for file systems. In addition, its flash file system is fault-tolerant.

Documentation quality

The quality of documentation for RT OS LynxOS, VxWorks, QNX is quite high. However, there are also complaints about the documentation:

QNX is an excellent description of the architecture and design principles, but an insufficient description of the application programming interface (not all parameters are described, there are inconsistencies);
VxWorks - no explanation of operating principles and insufficient description of the complex process of configuring the OS.

However, companies are working on the quality of the material. The documentation for the current version of QNX (6.3.2) has been significantly expanded, and some parts have been reworked.

Quality of technical support

In terms of the quality of official technical support, the undoubted leader is LynxOS. LynuxWorks promises to answer any technical question within 4 hours of the request being posted. LynxOS is distributed in Russia by RTSoft, which has a large staff of employees capable of providing qualified assistance. The disadvantage of LynxOS is that the OS is not yet very widespread in Russia; accordingly, there is no established user community, and there is not even a Russian-language forum.

QSS (the maker of QNX) also offers good technical support, but quick response times are not guaranteed. Unlike LynxOS, the QNX RT OS has a well-organized user community both abroad and in Russia. Answers to most questions can be found on these forums. QNX in our country is distributed by SVD Embedded Systems, whose employees are able to provide competent technical support and carry out work on adapting the OS to specific processor boards. In addition, the company has direct contacts with QSS and can get advice on complex issues from the developer of the QNX RT OS.

Open source

An open RT OS has at least three advantages:

application software developers can understand complex problems without involving technical support;
easier to certify (no bookmarks, etc.);
more dynamic development, since the RT OS developer company often receives not only requests for error corrections, but also proposals for eliminating errors and improving the system. Communities of open source RTOS developers, as a rule, grow much faster and are better organized. Independent experts appear to help solve the problems of the technical support service and participate in the development, debugging and testing of the system.

Since September 2007, QSS has open sourced the QNX core (including the Adaptive Partitioning package, the High Availability package). A little later, the source codes of the network subsystem were opened. Currently, beta version 6.4.0 is available for download on the official website.

It should be noted that today not all QNX modules are open (for example, there are no codes for graphics and file systems), and the license imposes a restriction on the use of “source code”: only for non-commercial use. However, the QNX user gets the above benefits for free.

LynxOS and VxWorks source codes are commercially available. The price for such a product is negotiable.

Tools

The availability of good tools largely determines the quality and speed of development of application programs for a particular OS. It should be noted that LynxOS, VxWorks and QNX currently provide good quality tools that include an integrated development environment (IDE) and application software debugging, program profiling tools (to detect bottlenecks in performance, memory, etc.). The ergonomics of the ISD for these RT OSs is generally not inferior to developed development tools for conventional OSs (for example, MS Windows).

Application software portability

The ability to write portable software is currently determined by compliance with the POSIX standard. All considered RT OSs support the POSIX 1003.1 standard. LynxOS has an advantage - this OS is binary compatible with Linux. That is, Linux applications can be run under LynxOS without recompilation. Conversely, LynxOS applications can be run on Linux (version 2.4.x with the glibs C language library version 2.2.2).

The rest of the RT OS require their recompilation to run Linux applications. In this case, the process of porting even POSIX-compliant applications can often become quite labor-intensive due to differences in the implementation of libraries and compilers.

Processor architecture support

Compliance with aviation standards

LynxOS is a leader when it comes to standards compliance. It supports ARINC-653, and there are plenty of examples of DO-178B certified systems built on it. The key point is that LynuxWorks offers a set of RSC (although the authors of the article do not know anything about the price).

VxWorks complies with the ARINC-653 standard, and systems built on its basis can be certified to DO-178B (there is big number examples).

QNX does not comply with ARINC-653, and there are no DO-178B certified systems based on it yet.

Development of the specialist training system

Comparison results

The QNX Neutrino RTOS is the most advanced OS from a technical point of view, has a good set of tools, and has a relatively low price. Microkernel architecture ensures high reliability and modularity of developed systems. An additional advantage is the open source code. But there is also a “fly in the ointment”: currently QNX is practically not used anywhere in aviation, and in this respect this OS loses to its competitors (LynxOS and VxWorks). An additional disadvantage of QNX: non-compliance with the ARINC-653 standard.

Work to prepare for the certification of QNX Neutrino according to the requirements of domestic aviation standards is currently being carried out by SWD Software.

Expert group / R&D.CNews

Hello, Habr!
Today I will talk about this interesting thing as a real-time operating system (RTOS). I'm not sure if this will be interesting for experienced programmers, but I think newbies will like it.

What is an RTOS?

If we look at Wikipedia, we will see as many as 4 definitions.
In short, an RTOS is an operating system that responds to external events in a certain period of time. From here we can understand the main purpose of an RTOS - devices that require a quick response to events (however, in no case confuse the operation of an RTOS with interrupts).

Why do we need it?

There are quite a few reasons for this.
Firstly, RTOS supports multitasking, semaphore process priorities and much more.
Secondly, it is very light and requires almost no resources.
Thirdly, we can get all of the above on almost any hardware (for example, FreeRTOS runs even on 8-bit AtMega).
And fourthly: just play and have fun.

Review of 3 well-known RTOSs.

Please note: the following is my personal opinion.

FreeRTOS

One of the most popular RTOS today. Ported to a huge amount of hardware. Official website.

pros

1) Free
2) Ported to a large amount of hardware
3) Powerful functionality
4) There are various libraries: graphics, Internet and more.
5) Good documentation.

Minuses

1) Quite a complex process of porting to new hardware.

Conclusion: This is a truly professional RTOS with good documentation. It will be good for a beginner if his hardware already has a port.

KeilRTX

Until recently, this RTOS was commercial, but has recently become open source. Works only on arm architecture. Official website.

pros

1)Free
2) Easily ported to new hardware (within the arm architecture).
3) There are various libraries: graphics, Internet and more.

Minuses

1) It’s almost impossible to work with her at Keil
2) Slightly reduced functionality
3) Only arm is supported.
4) (from personal experience) Loses to many RTOS in terms of speed.
Conclusion: ideal for a beginner and small projects.

uc/os

Powerful commercial RTOS. Website .

pros

1) A huge number of functions and libraries.
2) Supports a lot of iron

Minuses

1) Commercial.
2) Difficult to use.

Conclusion: calling it an RTOS for a beginner is a stretch.

Other interesting RTOS

RTLinux RTOS based on regular Linux.
QNX RTOS based on Unix.

Features of development using RTOS

Well, first of all, you need to understand the following: an RTOS is not Windows. It cannot be installed. This system simply compiles with your program.
When writing programs with an RTOS, functions in the usual sense are not used. Instead of functions, processes (or tasks) are used. The difference is that processes, unlike functions, are infinite loops and never end (unless someone or he himself kills it - that is, unloads it from memory).
If several processes are enabled, the RTOS switches them, providing machine time and resources in turn. This is where the concept of process priority arises - if two processes need machine time at the same time, then the RTOS will give it to the one with the higher priority.
The RTOS has special delay functions - so that time is not wasted while one process is delayed, a second one is executed.
Now let's talk about such a thing as a semaphore - this is a thing that controls a process's access to application resources. For each resource there is a marker - when a process needs a resource, it takes it and uses this resource. If there is no token, then the process will have to wait until it is returned. Let me give you an example: different processes send information over one UART. If there were no semaphore, then they would send bytes in turn and there would be confusion. And so the first process took the token on the UART, sent a message and gave it to the second (and so on ad infinitum).

Additional RTOS libraries.

RTOS often offer various libraries for working, for example, with graphics, the Internet, etc. They are really convenient and you shouldn’t hesitate to use them. However, remember that without the RTOS for which they are written, they will not work.
Here are examples:
For RTX

Real-time operating systems (RTOS). Requirements regulation system

1. Introduction: Features of real-time operating systems

Documents regulating the requirements for RTOS

OS timing parameters

Stability of timing parameters

Managing access to resources

Support for multiprocessor and distributed systems

File system support

Documentation quality

Quality of technical support

Open source

Tools

Application software portability

Processor architecture support

Compliance with aviation standards

Development of the specialist training system

Comparison results

Error 404: The page cannot be found.

This may have happened for one of these reasons:

You can:

What is an RTOS?

Why do we need it?

Review of 3 well-known RTOSs.

FreeRTOS

pros

Minuses

KeilRTX

pros

Minuses

uc/os

pros

Minuses

Other interesting RTOS

Features of development using RTOS

Additional RTOS libraries.

Popular articles

Latest articles

Sections

Pages

Special projects

Contacts