Os rv in aviation service. Real-time operating systems for avionics: an overview

Selection for aviation service is extremely strict and concerns not only flight personnel, but also real-time operating systems (RT OS). Let's consider what requirements are imposed on commercial aviation systems by organizations responsible for flight safety. Without a doubt, this will help to understand the requirements that are essential for many other industries - wherever a quick response to events, high reliability, survivability and safety of the tools used, including software, are needed.

The US Federal Aviation Administration, one of the authoritative organizations responsible for flight safety, has strict requirements for commercial real-time operating systems adopted for operation (especially for civil aviation, where the lives of hundreds of passengers depend on their work). Among them:

“hard” real-time requirements; deterministic behavior under various system loads, required in mission-critical applications and high-availability systems;
high “survivability” so that if any part of the software fails, the other part continues to function normally;
strict quality requirements, which means compliance with various industry, national and international standards;
reliability requirements; the probability of a program failure should be very small;
requirements for data security and secrecy; The system must provide means to protect the most important information.

Requirements regulation system

Let us list the main documents regulating the requirements for real-time operating systems in the field of aviation.

Standard DO-178 - Software Consideration in Airborne Systems and Equipment Certification. Developed and maintained by the Radio Technical Commission for Aeronautics (RTCA, www.rtca.org). The standard defines five levels of failure severity, for each of which a set of software requirements is specified, designed to guarantee the operability of the entire system as a whole when failures of this level occur:

level A- protection against failures leading to catastrophic consequences;

level B- protection against failures leading to dangerous consequences;

level C- protection against failures leading to large consequences;

level D- protection against failures leading to minimal consequences;

level E- protection against failures that do not lead to any consequences.

Standard ED-12B. European analogue of DO-178B. Determined by the association The European Organization for Civil Aviation Equipment (EUROCAE, www.eurocae.org).

RTCA DO-248B - Final Annual Report For Clarification Of DO-178B. Explanatory document for DO-178B. Its main topics include areas such as previously developed software, commercial software products, verification processes, historical information, automated tools, etc.

Standard DO-254 - Design Assurance Guidance for Airborne Electronic Hardware. Developed and maintained by the RTCA. The document is designed to help aircraft manufacturers and avionics suppliers ensure that their electronic equipment safely performs its required functions. The document regulates the hardware life cycle processes and describes ways to ensure required properties products for the purpose of their certification in accordance with the requirements.

ARINC 653 - Avionics Application Software Standard Interface. Developed by ARINC in 1997 and defining the universal software interface APEX (APplication/EXecutive) between the on-board computer operating system and application software. Interface requirements are defined to allow application programs to control the dispatch, communication, and state of internal processing elements. As one of the core requirements for real-time operating systems in aviation, ARINC 653 introduces a partitioning virtual machine architecture.

Common Criteria for Information Technology Security Evaluation. A set of requirements and conditions of secrecy ( www.commoncriteria.org), approved by the US National Security Agency and National Institute US standards and technologies, as well as relevant authorities in other countries (currently 13 countries besides the US). In 1999, the “General Criteria” received the status of international standard ISO 15408.

MILS - Multiple Independent Levels of Security/Safety. It is being developed through the efforts of interested organizations, such as the US Air Force Research Laboratory, Lockheed Martin, the US National Security Agency, etc. The MILS project makes it possible to mathematically verify the software core of a system by reducing functionality by introducing four mandatory groups requirements (Information Flow, Data Isolation, Period Processing, Damage Limitation). The MILS architecture is a system with isolated partitions, each of which includes the kernel, middleware, and application (Figure 1).

Rice. 1. MILS architecture

POSIX - Portable Operating System interface for unIX. Defines a portable operating system interface at level source texts. The core specification is developed as IEEE 1003.1 and adopted as the international standard ISO/IEC 9945-1:1990. From the point of view of real-time operating systems, three standards are of greatest interest: 1003.1a (OS Definition), 1003.1b (Realtime Extensions) and 1003.1c (Threads).

Isolated partition concept

In many aspects, regulatory documents overlap, complementing each other. As a result of numerous studies, the concept of isolated partitions was adopted as the main one. Satisfaction of hard isolation requirements must be “proven” by software solution providers in accordance with the certification methodology outlined in DO-178B. There are various approaches to implementing isolated partitions, but today the architecture adopted is ARINC 653, which defines isolation support for a real-time operating system and uses C and Ada-95 as a description language.

From a user's perspective, ARINC 653 is an APEX (APplication/EXecutive) interface specification and does not define its implementation. Thus, some software vendors implement dispatch using a single-level dispatcher, others using a two-level dispatcher, when the first level manages partitions and the second manages processes within each partition. This situation with ARINC 653 support entails difficulties in certifying software products that comply only with ARINC 653 - the same API may map to different implementation approaches. As a result, many very different real-time operating systems have emerged that nevertheless comply with the ARINC 653 specification.

In Fig. Figure 2 shows the architecture of a system with several isolated partitions, each of which represents an independent application. All data and code in each section are collected together and executed in user mode. The Module Operating System (MOS) and Board Support Package (BSP) components run in supervisor mode. Additionally, there may be one special section with some special capabilities, such as input/output and mode switching facilities.

ARINC 653 precisely defines the interface for exchanging information between partitions, each of which represents an application plus the partition operating system (POS). This interface must ensure isolation of the following elements.

RAM. Each partition is allocated a contiguous linear physical address space, the boundaries of which cannot change during system operation. For each partition, memory allocation and deallocation is performed and controlled by MOS. The real-time operating system must provide isolation of information in the address space within a linear “chunk” allocated to each section. This applies to program code, constants, static data, the stack, and the heap (the area where memory is taken from when requested).

CPU usage time. Processes in one partition may either not affect the behavior of processes in another partition at all, or they may influence them in a predetermined and controlled way (for example, by setting some flags or conditions). ARINC 653 requires that processor time be allocated to each partition on a strictly cyclic basis, and the processor ownership time for each partition must be specified in advance in the configuration table. Within each partition, processes can compete for CPU time based on priorities (“preempt”) using priority preemption scheduling.

Program code. For some memory areas, MOS sets the "execute-only" attribute in supervisor mode. This means that user mode applications cannot destroy the code region.

Interrupts. Interrupts are asynchronous events that require special care to ensure section isolation. It is important that they do not “encroach” on time and memory in another section. One possible source of interruption is timers that control event dispatching both within the POS and within the MOS.

A number of conventions have been adopted to provide interrupt isolation. Timer interrupts only occur in supervisor mode; Direct access to the clock in user mode is not possible. If POS and MOS are at different security levels, then a mechanism must be provided to distribute information about temporary events to application partitions running in user mode. At those moments when the section is active (owns processor time), all time events related to it should be transmitted to it. When a partition is inactive, all temporary events related to it must be stored and then transferred to it when activated.

Another source of interrupts is external I/O devices. In accordance with ARINC 653 requirements, it is recommended to use a device polling algorithm for devices with synchronous data transfer. However, some devices require interrupt handling. These interrupts must be handled by the MOS and then transmitted to the POS when the partition is activated. Obviously, time delays and even loss of information may occur, and therefore the designer must take this into account.

ARINC 653 defines not only the requirements for isolating partitions, but also the mechanisms for interaction between them. The following functions for interaction between sections have been introduced:

message exchange by establishing a communication channel, which must be described in advance in the system configuration table;

exchange via buffer, in which only one partition can write to a particular buffer, and all others can only read; this provides the ability to broadcast information between partitions.

DO-178B standard

The DO-178B standard describes techniques and methods to ensure the integrity and reliability of software, covering all stages of its life cycle - planning, requirements development, design, coding, integration and testing.

DO-178B planning must include the following plans: a plan for the programmatic aspects of certification; software project plan; software verification plan; software configuration management plan; software quality assurance plan. Throughout the entire life cycle, compliance with the DO-178 standard must be ensured in the areas of requirements statement, design, coding, verification and documentation. Software requirements (high-level requirements), software design (requirements and architecture), program code in source and object form must be developed. Each of the developed components must be verified according to various criteria. Verification of high-level software requirements includes checking the following conditions: the requirements meet the system requirements and are available for analysis along with the system requirements; requirements are precise and consistent; the requirements are compatible with the hardware and therefore must be supported by results.

Software design verification involves verifying that the design requirements meet high-level requirements and can be analyzed, are accurate and consistent, and therefore can be supported by results. Likewise, the software architecture and code must be verified and must also meet the requirements set out in DO-178B. This standard defines the verification process of the software integration stage, checking the completeness of the verification process itself, providing configuration management (including version control), and qualifying automated tools.

The standard defines three levels of structural code testing:

Statement coverage means that every statement in a program is called at least once;
decision coverage means that every entry and exit point in the program was executed at least once, and that every decision in the program took on all possible (Boolean) output values at least once;
Covering solutions with a modifiable condition means that each entry and exit point in the program was executed at least once, that each decision in the program took all possible (Boolean) output values at least once, and that each condition in the solution resulted in an independent change in the output meanings.

The certification levels defined in DO-178B differ in the number of requirements (depth of verification) that the software must satisfy. The theoretical aspects of code verification are presented in various fundamental monographs, in particular, in the work.

Certification to DO-178B must be conducted by so-called Designated Engineering Representatives, who are appointed by the FAA to review the data used in the certification. The developer seeks to obtain certification of its software in accordance with DO-178B in order to obtain permission to use its software (including the real-time operating system) in aviation. The permission applies not only to the software, but to the entire product (project) as a whole. To begin the certification process, a developer must first “open” a project and obtain an official project number from the FAA, or join an existing project with an already issued project number. To “open” a project, you must obtain a type certificate or an additional type certificate. Typically, a type certificate is assigned to an aircraft, and all equipment on it comes with that certificate. An additional type certificate is given to additional equipment on the aircraft, including software.

"General criteria" for assessing privacy

The Common Criteria define Evaluation Assurance Levels (EALs) and evaluate not only the security and reliability of products, but also their development and support processes to ensure that problems are quickly resolved. For operating systems, the requirements of the General Criteria are detailed in . There are seven levels of privacy guarantee:

EAL1 (functionally tested)- applicable where minimal confidentiality is required, but secrecy is not considered an important requirement;

EAL2 (structurally tested)- applicable in circumstances where developers or users require a medium level of guaranteed secrecy in the absence of complete information about all development procedures;

EAL3 (methodically tested and checked)- applicable where developers or users require a medium level of guaranteed secrecy and require an exhaustive study of the operating system and the stages of its development, but without resorting to significant reworking of the OS;

EAL4 (methodically designed, tested and reviewed)- applicable in circumstances where developers or users require a high level of guaranteed secrecy of the operating system and require special modification of the existing OS to meet these requirements;

EAL5 (semi formally designed and tested)- applicable where developers or users require a high level of guaranteed secrecy of the operating system and a strict approach to design, so that these properties are included already at the design stage, using special means ensuring secrecy;

EAL6 (semi formally verified, designed and tested)- applicable where there is a high level of dangerous situations and where high costs of protection against unauthorized access are justified;

EAL7 (formally verified, designed and tested)- should be used in applications with very at a high price in case of unauthorized access.

The EAL level is confirmed by a special laboratory, the Common Criteria Testing Lab.

The table shows a list of the maximum security guarantee requirements that the system must satisfy at EAL7 level.

LynxOS-178 system

LynxOS-178 is based on the LynxOS v.3 real-time operating system, which runs in an isolated partition. LynxOS v.3 is certified to POSIX 1003.1-1996 Intel platform and PowerPC.

A key feature of LynxOS-178 is support for multiple partitions that are completely separated in time, memory and resources in accordance with the requirements of ARINC 653. LynxOS-178 (version 2.0) supports: up to 16 partitions (virtual machines), including the root partition; up to 64 processes; up to 51 threads within each process; dispatching of threads within a partition in real time; interprocess communication functions within a partition.

Each partition is completely isolated, making it impossible for faults to propagate between partitions.

With LynxOS-178, fixed partitions are served as LynxOS virtual machines. Each application process operates within its own operating system environment as if it were running on its own processor. This applies to all CPU resources and named spaces. This abstraction protects the application developer from additional effort when programming a complex system. Partition management is controlled through the Virtual-Machine Configuration Table (VCT) and is mandatory in the LynxOS-178 environment, allowing the application developer to concentrate on developing applications rather than partitioning the system. Additionally, LynxOS-178 supports partitioning of RTCA DO-255 compliant systems, allowing software with different DO-178B security levels to run on different partitions ( virtual machines). This means that the operating system can run a Level A (DO-178B) application on one virtual machine and a Level C application on another, with both applications running on the same processor within the same system.

The version of LynxOS-178 included in various products (for example, the Bombardier Challenger 300 aircraft from Rockwell Collins) is certified to the DO-178B standard, and the architecture of the operating system itself ( rice. 3) meets ARINC 653 requirements.

LynxOS-178 provides the following groups of system services in accordance with ARINC 653: Partition Management - partition management, Process Management - process management, Time Management - time management, Interpartition Communication - interaction of processes in different sections (Sampling Port Services and Queuing Port Services), Intrapartition Communication - interaction of processes within one partition (Buffer Services, Blackboard Services, Semaphore Services, Event Services), Health Monitoring - monitoring the health of the operating system or equipment.

A prototype operating system compliant with EAL7 is due to be released in 2006; A new MILS-compliant LynxSecure kernel is being developed, which will contain only 8 thousand lines of source code and will comply with EAL7 requirements.

Without a doubt, the discussed requirements for real-time operating systems are very significant for many other industries, such as the navy, military and space systems, communications systems, life support, systems intended for use in emergency situations - wherever fast response to events, high reliability, durability and safety of the tools used, including software.

Literature

Commercial Off-The-Self Real-Time Operating System and Architectural Consideration. Final Report, U.S. Federal Aviation Administration, DOT/FAA/AR-03/77, February 2004.
Partitioning in Avionics. Architecture: Requirements, Mechanics, and Assurance. Final Report, National Aeronautics and Space Administration, DOT/FAA/AR-99/58, NASA/CR-1999-209347, March 2000.
Study of Commercial Off-The-Self (COTS) Real-Time Operating System (RTOS) in Aviation Application. Final Report, U.S. Federal Aviation Administration, DOT/FAA/AR-02/118, December 2002.
Evaluation of real time operating systems - the role of standards. Avionic Systems Standardization Committee (ASSC), Doc No: ASSC/330/2/141, March 1997.
G. Mayers, The art of Software Testing. John Wiley & Sons, 1979.
COTS Security Protection Profile - Operating Systems (CSPP-OS), NISTIR 6985, April 2003.
Common Criteria for Information Technology Security Evaluation. Part 3: Security Assurance Requirements. August 1999, Version 2.1, CCIMB-99-033.

Sergey Zolotarev ( [email protected]) - employee of the RTSoft company (Moscow).

It was decided to upgrade the KC-135 Stratotanker long-range strategic bomber refueler to ensure compliance with international Global Air Traffic Management regulations and the requirements of the DO-178B standard. The Integrated Processing Center, developed by Rockwell Collins, provides computing and network functions, which can be used to perform many different tasks (mission support, flight control, display support). The basic functionality is expanded to allow additional applications to be implemented. Data exchange with other equipment is carried out via the “aviation” version of the Ethernet network. There are several Line Replaceable Modules available inside the Integrated Processing Center. The certified real-time operating system LynxOS-178 runs on the Common Computing Module and the Input/Output Concentrator Module.

The KC-767 tanker aircraft, which also runs the LynxOS-178 operating system, is poised to take the Air Force's aerial refueling to the next level and retire the legacy KC-135E tankers that have been in service for more than four decades. The new vessel is not only more spacious, but also more reliable, making it suitable for a wider range of operations. In fact, the KC-767 is four different aircraft in one. The deck where the crew cabin is located can be easily equipped to carry passengers or cargo without compromising the functionality of the tanker. Moreover, it can be done so that, depending on the situation, the ship is either a passenger, or a cargo, or a mixed carrier.

In English-language literature, two terms are used - safety and security, which can be similarly translated into Russian. However, they mean different things, and in this article we will use safety as a synonym for security, and security as a synonym for secrecy. - Note auto.

Send your good work in the knowledge base is simple. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Federal Agency for Education

Department of Automated Control Systems

Real-time systems

Introduction

1. Real-time operating systems

1.1 Types of RTOS

1.2 Structure of an RTOS

1.3 Processes, threads, tasks

1.4 Planning, priorities

1.5 Memory

1.6 Interrupts

1.7 Clocks and timers

2. Standards for real-time operating systems

2.1 POSIX standard

2.2 DO-178B standard

2.3 ARINC-653 standard

2.4 OSEK standard

2.5 Safety standards

3. Brief characteristics of common real-time operating systems

3.2 QNX Neutrino RTOS

3.5 RTX (Real Time Extension for Windows NT)

3.6 INtime (Windows NT Real Time Extension)

3.8 MicroWare OS-9

3.11 Nucleus RTOS

Conclusion

Bibliography

Introduction

The concepts underlying most real-time operating systems today date back to the late 1970s and early 1980s.

Real-time operating systems and embedded systems operate in "constrained" environments where memory and processor power are limited. They must provide services to users and the world they interact with within strict time frames.

Real-time systems are distinguished by very modest user interface capabilities, since the system being transferred to operation is a “black box”. Very important part and the main feature of a real-time operating system is to manage the computer's resources in such a way that a certain operation is performed for exactly the same period of time every time it should be carried out and which cannot be exceeded.

In a complex machine, moving a part faster than necessary, just because system resources allow it, can lead to catastrophic results, as well as the inability to move this part due to the system being busy.

Usually, when designing a real-time system, the composition of the programs (tasks) it executes is known in advance. Many of their parameters are also known, which must be taken into account when allocating resources (for example, the amount of memory, priority, average execution time, opened files, devices used, etc.). Therefore, task descriptors are created for them in advance so as not to subsequently waste precious time organizing the descriptor and searching for the necessary resources for it.

For true real-time implementation, multiprogramming is required. Multiprogramming is the main means of increasing the performance of a computing system, and for solving real-time problems, performance becomes the most important factor.

The best performance characteristics for real-time systems are provided by single-terminal real-time operating systems.

1. Real-time operating systems

A real-time operating system is a type of operating system.

There are many definitions of the term. The most common of them:

*An operating system in which the success of any program depends not only on its logical correctness, but also on the time it took to obtain this result. If the system cannot satisfy the time constraints, a failure must be recorded;

*POSIX 1003.1 defines: “ Real time in operating systems, this is the ability of the operating system to provide the required level of service in a certain period of time”;

*An operating system that responds at predictable times to unpredictable external events;

*Interactive systems of constant readiness. They are classified into the RTOS category based on marketing considerations, and if an interactive program is called “real-time,” this only means that requests from the user are processed with a delay that is imperceptible to humans.

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 of system behavior in the worst case scenarios. external conditions, which differs sharply 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 quick glance at possible embedded systems suggests that most embedded systems require predictable behavior for at least some functionality, and thus these systems can be classified as real-time systems.

Martin Timmerman (director of Real-Time Consult and Real-Time User's Support International (RTUSI), which provides hardware and software support and develops real-time system projects) formulated the following necessary requirements for an RTOS:

*the operating system must be multitasking and preemptible;

*the operating system must have the concept of priority for threads;

*the operating system must support predictable synchronization mechanisms;

*the operating system must provide a mechanism for inheriting priorities;

*the behavior of the operating system 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.

1.1 Types of RTOS

It is customary to distinguish between soft and hard real-time systems.

In hard real-time systems, 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-language 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.

1.2 Structure of an RTOS

Over the past 25-30 years, the structure of operating systems (OS) 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 when operating 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, and in addition, reversal through a 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, the failure of a module 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.

1.3 Processes, threads, tasks

The concept of multitasking (pseudo-parallelism) is essential for a single-processor real-time system whose applications must be able to handle multiple external events, occurring almost simultaneously.

The process concept, which comes from the UNIX world, is poorly implemented in multitasking system, since the process has a heavy context. The concept of a thread arises, which is understood as a subprocess, or a light-weight process. Threads exist in the same process context, so switching between threads is very fast and security issues are not taken into account. Streams are lightweight because their register context is smaller, i.e. their control units are much more compact. The overhead caused by saving and restoring control blocks of interrupted threads is reduced. The size of control blocks depends on the memory configuration. If threads are running in different address spaces, the system must support memory mapping for each set of threads.

So, in real-time systems, the process is divided into tasks or threads. In either case, each process is treated as an application. There should not be too much interaction between these applications and in most cases they are of different nature - hard real time, soft real time, non real time.

1.4 Planning, priorities

The main problem in an RTOS is task scheduling, which would ensure predictable system behavior under all circumstances. In connection with scheduling problems in RTOS, two approaches are studied and developed - static scheduling algorithms (RMS - Rate Monotonic Scheduling) and dynamic scheduling algorithms (EDF - Earliest Deadline First).

RMS is used to formally prove the predictability conditions of a system. To implement this theory, preemptive priority scheduling is required. In RMS theory, priority is assigned in advance to each process. Processes must satisfy the following conditions:

*the process must be completed within its period;

*processes do not depend on each other;

*each process requires the same CPU time at each interval;

*non-periodic processes do not have strict deadlines;

*process interruption occurs within a limited time.

Processes are executed according to priorities. When scheduling RMS, preference is given to tasks with the shortest execution periods.

In EDF, priority is assigned dynamically, and the highest priority is assigned to the process that has the shortest execution time remaining. At high system loads, EDF has advantages over RMS.

All real-time systems require a deadline-driven scheduling policy. However, this approach is under development.

RTOS typically uses service interruption priority scheduling, which is based on RMS. Priority interruption of service (preemption) is an integral component of an RTOS, because In a real-time system, there must be guarantees that a high priority event will be processed before a lower priority event. All this leads to the fact that the RTOS not only needs a scheduling mechanism based on interruption priorities, but also an appropriate mechanism for managing interruptions. Moreover, the RTOS must be able to disable interrupts when critical code needs to be executed that cannot be interrupted. The duration of interrupt processing should be kept to a minimum.

The RTOS must have a developed system of priorities. First, this is required because the system itself can be viewed as a collection of server applications divided into threads, and several high priority levels must be allocated to system processes and threads. Secondly, in complex applications All real-time threads should be placed at different priority levels, and non-real-time threads should be placed at the same level (lower than any real-time threads). In this case, non-real-time threads can be processed in the round-robin scheduling mode (RRS), in which each process is given a processor time slice, and when the slice ends, the process context is saved and it is placed at the end of the queue. Many RTOSs use RRS to schedule tasks at one level. Priority level 0 is typically used for idle mode.

When planning based on priorities, there are two imperative issues to solve:

*ensure the execution of the process with the highest priority,

*prevent priority inversion, when tasks with high priorities wait for resources captured by tasks with lower priorities.

To combat priority inversion, RTOS often uses a priority inheritance mechanism, but this eliminates RMS-based scheduling because priorities become dynamic.

1.5 Memory

As mentioned above, the delay for thread context switching directly depends on the memory configuration, i.e. from the memory protection model. There are four most common memory protection models in RTOS:

*Model without protection - the system and user address spaces are not protected from each other, two memory segments are used: for code and for data, while the system does not require any memory management, does not require an MMU (memory management unit - a special hardware device to support management virtual memory);

*System/user security model - the system address space is protected from the user address space, system and user processes run in a common virtual address space, and an MMU is required. Protection is provided by the page protection mechanism. There are different system and custom pages. Custom Applications are not protected from each other in any way. The processor is in supervisor mode if the current segment is level 0, 1, or 2. If the segment level is 3, then the processor is in user mode. In this model, four segments are required - two segments at level 0 (for code and data) and two segments at level 3. The page protection mechanism does not add overhead because security is checked simultaneously with the address translation performed by the MMU; in this case, the OS does not need memory management.

*User/user security model - adds security between user processes to the system/user model, requires MMU. As in previous model, the page protection mechanism is used. All pages are marked as privileged, except for the pages of the current process, which are marked as user pages. Thus, the executing thread cannot access the limits of its address space. The OS is responsible for updating the privilege flag for a particular page in the page table when a process switches. As in the previous model, four segments are used.

*Virtual memory protection model - each process runs in its own virtual memory, MMU required. Each process has its own segments and therefore its own descriptor table. The OS is responsible for maintaining handle tables. The addressable space may exceed the size of physical memory if paged memory is used in conjunction with paging. However, real-time systems generally do not use paging because of its unpredictability. To solve this problem, the available memory is divided into a fixed number of logical address spaces of equal size. The number of concurrently running processes in the system becomes limited.

A fundamental requirement for memory in a real-time system is that access time must be limited (or, in other words, predictable). A direct consequence is a ban on the use of on-demand page calling techniques (disk paging) for real-time processes. Therefore, systems that provide a virtual memory mechanism must be able to lock a process in RAM, preventing swapping. So, swapping is not allowed in an RTOS because it is unpredictable.

If paging is supported, the appropriate mapping of pages to physical addresses must be part of the process context. Otherwise, unpredictability again appears, which is unacceptable for an RTOS.

For processes that are not hard real-time processes, it is possible to use a dynamic memory allocation mechanism, but the RTOS must support timeout processing for memory requests, i.e. limitation on predictable waiting times.

In conventional operating systems, when using a memory segmentation mechanism, compaction after garbage collection is used to combat fragmentation. However, this approach is not applicable in a real-time environment, because During compaction, moved tasks cannot be executed, leading to system unpredictability. This is the main problem with the applicability of the object-oriented approach to real-time systems. Until the compaction problem is solved, C++ and JAVA will remain poor choices for hard real-time systems.

Hard real-time systems typically use static memory allocation. In soft real-time systems it is possible dynamic distribution memory, no virtual memory and no compaction.

1.6 Interrupts

When describing interrupt management, two procedures are usually distinguished, namely:

*interrupt servicing routine (ISR) - a low-level program in the kernel with limited system calls,

*interrupt servicing thread (IST - interrupt servicing thread) - application level thread that manages the interruption, with access to all system calls.

Typically, ISRs are implemented by the hardware manufacturer, and device drivers perform interrupt management using ISTs. Interrupt threads act like any other thread and use the same priority system. This means that the system designer can give the IST a lower priority than the application thread.

1.7 Clocks and timers

RTOS uses various time services. The operating system monitors current time, starts tasks and threads at certain times and suspends them at certain intervals. RTOS time services use real-time clocks. Typically, high-precision hardware clocks are used. Timers are created to count time intervals based on the real time clock.

Each process and thread is assigned a CPU clock. These clocks are used to create timers that measure time overruns by a process or thread, allowing it to be dynamically detected. software errors or errors in calculating the maximum possible execution time.

In highly reliable, time-critical systems, it is important to identify situations in which a task exceeds the maximum possible execution time, because in this case, the system operation may exceed the acceptable response time. Runtime clocks allow you to identify when time overruns occur and initiate appropriate error handling actions.

Most RTOS operate with relative time. Something happens “before” and “after” some other event. In a system that is completely event-driven, a clock mechanism (ticker) is needed, because there is no time slicing. However, if you need timestamps for some events or you need a system call like “wait one second,” then you need a clock generator and/or a timer.

Synchronization in an RTOS is carried out using a blocking (or waiting) mechanism until a certain event occurs. Absolute time is not used.

RTOS implementations of other conceptual abstractions are similar to their implementations in traditional operating systems.

2. Standards for real-time operating systems

2.1 POSIX standard

The large differences in RTOS specifications and the huge number of existing microcontrollers bring to the fore the problem of standardization in the field of real-time systems.

The earliest and most widespread RTOS standard is the POSIX standard (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). The original version of the POSIX standard appeared in 1990 and was intended for UNIX systems, the first versions of which appeared in the 70s of the last century. The POSIX specifications define a standard mechanism for interaction between an application program and the operating system and currently includes a set of more than 30 standards. For RTOS, seven of them are the most important (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), but only the first three are widely supported in commercial operating systems.

Despite the clearly outdated provisions of the POSIX standard and the great demand for standardization updates for RTOS, there has been no noticeable progress in this direction.

The POSIX standard was created as a standard interface for operating system services. This standard makes it possible to create portable applications. This standard was subsequently expanded to include real-time features.

The POSIX specifications define a standard mechanism for interaction between an application and the OS. It should be noted that the POSIX standard is closely related to the Unix operating system, however, the developers of many RTOSs try to comply with this standard.

Compliance with the POSIX standard for the OS and hardware platform must be certified by running test cases on them. However, if the OS is not Unix-like, meeting this requirement becomes a challenge. Test suites exist only for POSIX 1003.1a. Because the POSIX framework is a collection of optional features, OS vendors can implement only part of the standard interface and still claim that their system is POSIX-compliant.

Although the POSIX standard grew out of Unix, it addresses the fundamental abstractions of operating systems, and the real-time extensions apply to all RTOSes.

By now, the POSIX standard is considered to be a family of related standards: IEEE Std 1003.n (where n is a number).

2.2 DO-178B standard

The DO-178B standard was created by the Radio Technical Commission for Aeronautics (RTCA) for the development of software for on-board aircraft systems.

Its first version was adopted in 1982, the second (DO-178A) - in 1985, the current DO-178B - in 1992. Adoption is being prepared new version, DO-178C. The standard provides five levels of failure severity, and for each of them a set of software requirements is defined that must guarantee the functionality of the entire system when failures of this severity level occur.

This standard defines the following certification levels:

*A (catastrophic),

*B (dangerous),

*С (substantial),

*D (not significant)

*E (not influencing).

Until all the stringent requirements of this standard are met, security-sensitive computing systems will never take off.

2.3 ARINC-653 standard

The ARINC-653 (Avionics Application Software Standard Interface) standard was developed by ARINC in 1997. This standard defines a universal APEX (Application/Executive) software interface between the aircraft computer OS and application software.

The interface requirements between application software and operating system services are defined to allow the application software to control dispatch, communication, and the state of internal processing elements. In 2003, a new edition of this standard was adopted. ARINC-653 introduces the architecture of partitioned virtual machines as one of the main requirements for RTOS in aviation.

2.4 OSEK standard.

The OSEK/VDX standard is a combination of standards that were originally developed in two separate consortia that later merged. OSEK takes its name from the German acronym for a consortium that included leading German car manufacturers BMW, Bosch, Daimler Benz (now Daimler Chrysler), Opel, Siemens and Volkswagen, as well as the University of Karlsruhe (Germany). The VDX (Vehicle Distributed eXecutive) project was developed jointly by the French companies PSA and Renault. The OSEK and VDX teams merged in 1994.

The OSEK/VDX project was originally intended to develop an open OS architecture and API standard for systems used in the automotive industry. However, the developed standard turned out to be more abstract and is not limited to use only in the automotive industry.

The OSEK/VDX standard consists of three parts - the operating system (OS) standard, the communications standard (COM) and the network manager (NM) standard. In addition to these standards, an implementation language (OIL) is defined. The first component of the OSEK standard is the OS standard, which is why the OSEK standard is often mistakenly perceived as an RTOS standard. Although the OS is a large portion of this standard, its power lies in the integration of all its components.

2.5 Safety standards

In connection with standards for RTOS, it is worth noting the well-known standard of criteria for assessing the suitability of computer systems (Trusted Computer System Evaluation Criteria - TCSEC). This standard was developed by the US Department of Defense and is also known as the Orange Book because of the color of the cover.

A number of other countries have developed similar criteria, on the basis of which the international standard “Common Criteria for IT Security Evaluation” (ISO/IEC 15408) was created.

The Orange Book lists seven levels of protection:

*A1 - verified development. This level requires that the protection of classified and other sensitive information by security controls is guaranteed by formal verification methods.

*B3 - security domains. This level is designed to protect systems from experienced programmers.

*B2 - structured protection. A system with this level of protection cannot be penetrated by hackers.

*B1 - mandatory access control. An experienced hacker may be able to overcome this level of protection, but not ordinary users.

*C2 - discretionary access control. Level C2 provides security for login procedures, allows for monitoring of security-related events, and isolates resources.

*C1 - selective protection. This level gives users the ability to protect personal data or project information by setting access controls.

*D - minimum protection. This lower level of protection is reserved for systems that have been tested but could not meet the requirements of a higher class.

3. Brief characteristics of the most common real-time operating systems

3.1 VxWorks

Real-time operating systems of the VxWorks family of WindRiver Systems Corporation are intended for the development of software for embedded computers operating in hard real-time systems.

The VxWorks operating system has a client-server architecture and is built in accordance with microkernel technology, i.e. the lowest non-interruptible kernel layer (WIND Microkernel) handles only task scheduling and task communication/synchronization management. All other functionality of the operating kernel - memory management, input/output, etc. - is provided at a higher level and is implemented through processes. This ensures the performance and determinism of the kernel, as well as system scalability.

VxWorks can be configured for small embedded systems with tight memory constraints to complex, feature-rich systems.

Although the VxWorks system is configurable, i.e. Individual modules can be loaded statically or dynamically; it cannot be said to use a component-based approach. All modules are built on top of the base kernel and are designed in such a way that they cannot be used in other environments.

3.2 QNX Neutrino RTOS

The QNX Neutrino Real-time Operating System (RTOS) from QNX Software Systems is a microkernel operating system that provides prioritized multitasking.

QNX Neutrino RTOS has a client-server architecture. In the QNX Neutrino environment, every driver, application, protocol, and file system runs outside the kernel, in a protected address space. If any component fails, it can automatically restart without affecting other components or the kernel. Although the QNX system is configurable, i.e. While individual modules can be loaded statically or dynamically, it cannot be said to use a component-based approach. All modules rely on the base kernel and are designed in such a way that they cannot be used in other environments.

QNX Neutrino RTOS consists of a kernel, a process manager, and advanced user-level services. As a true microkernel operating system, QNX Neutrino RTOS implements only the most fundamental services in the OS kernel, such as message passing, signals, timers, thread scheduling, and synchronization objects. All other OS services, drivers and applications run as separate processes that communicate through synchronous message passing.

QNX Neutrino RTOS has short interrupt processing times and fast context switching. Priority inversion is overcome using distributed priority inheritance. Simplified modeling of real-time activities is carried out through synchronous message transmission. Nested interrupts and a fixed upper bound on interrupt processing time ensure that high-priority interrupts are processed quickly with predictable timing.

3.3 RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) is a non-commercial real-time operating system for deeply embedded systems.

The system developer is OAR (On-Line Applications Research Corporation, USA). The system was created by order of the US Department of Defense for use in control systems for missile systems. The system is being developed for multiprocessor systems based on open source code, as opposed to similar closed-source systems. The system is designed for MS-Windows and Unix platforms (GNU/Linux, FreeBSD, Solaris, MacOS X).

The RTEMS core provides the basic functionality of real-time systems. These features include

*multitasking processing;

*work in homogeneous and heterogeneous systems;

*event-driven planning based on priorities;

*planning at monotonous speed;

*task interaction and synchronization;

*priority inheritance;

*response interrupt control;

*dynamic memory allocation;

*system configuration for authorized users;

*portable to many target platforms.

Linking the RTOS to the equipment is done using special library BSP (board support package) routines and specialized routines for various architectures.

RTEMS does not support dynamic loading applications and modules, therefore its scope of application is embedded systems in which frequent software modification is not expected.

The RTEMS RTOS provides rather weak support for file systems, which limits the scope of its possible application in the field of centralized data collection and storage systems to standard high-level tools.

3.4 ChorusOS

The ChorusOS operating system is a scalable embedded OS widely used in the telecommunications industry. Currently, this brand is developed and distributed by Sun Microsystems Corporation.

To build and deploy ChorusOS on specific telecommunications platforms, Sun Microsystems offers the use of the Sun Embedded Workshop development environment. Sun Microsystems is introducing ChorusOS as the embedded foundation for Sun's Service-Driven Network. Combined with a wide range of services, seamless software and hardware integration, easy administration and support for Java technology that is dedicated to the needs of telecommunications, ChorusOS allows you to efficiently deploy new features and applications, maintaining the reliability and functionality of modern networks.

ChorusOS supports a wide range of telecommunications protocols, legacy applications, real-time applications and Java technologies on a single hardware platform.

ChorusOS models three types of applications:

*POSIX processes make up the majority of ChorusOS applications, these applications have access to the POSIX API, several POSIX-like extended APIs, and a small number of limited microkernel system calls;

*ChorusOS Actors - these applications run on top of the microkernel and are limited by the microkernel API, actors include drivers, subsystem events and protocol stacks;

*Legacy ChorusOS apps are supported for compatibility with apps developed for earlier versions of ChorusOS.

The architecture of the ChorusOS OS is multi-layered, component-based. The microkernel contains the minimum set of components necessary for the operation of the OS. The size of the resident part of the kernel is 10Kb.

The concept of “actor” in ChorusOS is defined as a unit of loading for an application. It also serves as an encapsulation unit to map all the system resources used by the application and the threads running inside the actor. Examples of such resources are threads, memory regions, and communication endpoints.

ChorusOS 5.0 powers the Solaris operating environment and supports the following target platforms:

*UltraSPARC II (CP1500 and CP20x0);

*Intel x86, Pentium;

*Motorola PowerPC 750 and 74x0 family of processors (mpc7xx);

*Motorola PowerQUICC I (mpc8xx) and PowerQUICC II (mpc8260) (microcontrollers).

3.5 RTX (Real Time Extension for Windows NT)

Windows NT was designed and is primarily used as a general-purpose OS. However, in the real-time systems market there is a clear trend to use Windows NT and its extensions in specialized systems. There are several reasons for this:

*Windows NT was designed according to modern OS technologies,

*application programming interface (API) for Win32 has become the de facto standard for programmers,

*graphic user interface(GUI) has become so popular that other operating systems are trying to provide a similar interface,

*a large number of device drivers are available,

*Many powerful integrated development environments are available.

Windows NT itself is not suitable for use in real-time systems, because it has too few priority levels and there is no mechanism for inheriting priorities. To minimize interrupt service time (ISR), Windows NT introduced the concept of deferred procedure call (DPC), the priority of which is higher than the priority of user and system threads, while all DPCs have the same priority. This causes all DPCs to be queued into a FIFO queue, and a DPC with a high-level interrupt will only be able to execute after all other DPCs queued before it have completed. Such situations lead to unpredictable response times, which is incompatible with RTOS requirements. Memory management in Windows NT is based on a virtual memory mechanism. This entails memory protection, address translation and swapping, which is unacceptable in an RTOS.

The RTX (Real-Time Extension) for Windows NT (developed by VenturCom Corporation) allows you to create high-speed control applications with deterministic response times to external events.

RTX is deeply integrated into the Windows NT kernel and provides necessary functions uses Windows NT service and WIN32 API. The real-time kernel (nucleus) is integrated into the NT kernel (kernel). Each RTX process runs as an NT kernel device driver, and the processes are not protected from each other. This implementation leads to fast switching context, but is not secure from a privacy perspective.

3.6 INtime (Windows NT Real Time Extension)

INtime is a Windows real-time extension that was developed by Radisys Corporation and is currently maintained by TenAsys Corporation.

INtime combines the capabilities of a hard real-time RTOS with standard Windows operating systems, including Windows XP, Windows XP Embedded, Windows 2000, Windows NT and Windows NT Embedded, without requiring additional hardware. INtime is specially designed for x86 processor architecture.

INtime, unlike RTX, is weakly related to NT. The INtime architecture is based on the hardware tasking mechanism provided by the Intel processor. It turns out that two cores are running on the same hardware. Since they share the same hardware, some modifications to the NT HAL were required. This approach allows you to protect and separate the runtime and memory area from Windows. Within INtime, each application process has its own address space. In addition, the kernel and applications run at different priority levels, which helps protect them from each other.

INtime exhibits predictable behavior, but its complex architecture does not allow the system to achieve good performance. Due to segmentation restrictions, INtime is not suitable for all real-time systems.

3.7 LynxOS

The LynxOS RTOS operating system (LynuxWorks, Inc.) is a hard real-time operating system that is designed for specialized and telecommunications equipment. This OS is completely deterministic and has POSIX, UNIX and Linux compatibility. Areas of application for LynxOS are also complex security systems.

The latest released version of this brand, LynxOS-178 2.0, is characterized by the manufacturer as a commercial operating system that provides a high level of reliability and responsiveness required for embedded applications with special security requirements. LynxOS-178 2.0 implements support for the APEX interface (Application/EXecutive - application/control program interface) of the ARINC-653 specification. This means that this operating system meets the most stringent requirements for the security and reliability of electronic systems for military and civil aviation. LynxOS-178 2.0 is fully compliant with Level A of the DO-178B specification.

RTOS LynxOS-178 2.0 complies with the requirements of the POSIX and ARINC-653 standards, as well as DO-178B, which means a guarantee of portability of application code of embedded systems, reuse of created programs, as well as compliance with the most stringent operating system standards with increased security requirements. Using LynxOS-178 2.0 allows you to use any previously certified programs and developments.

3.8 MicroWare OS-9

Microsoft System's OS-9 real-time operating system is a multitasking, multi-user operating system for real-time embedded applications. This system is designed to work in systems such as mobile telecommunications devices, embedded Internet access terminals, and interactive digital television set-top boxes.

OS-9 runs on processors such as Motorola 68K, ARM/StrongARM, Intel IXP1200 Network Processor, MIPS, PowerPC, Hitachi SuperH, x86 or Intel Pentium, Intel IXC1100 XScale.

The OS-9 kernel is scalable, fully preemptible, supports up to 65,535 processes, provides 65,535 priority levels, and supports up to 255 users. The OS-9 kernel contains more than 90 system calls that make it possible to control dynamic scheduling, memory allocation, interprocessor communication, etc. - up to managing the power saving mode built into the OS kernel.

Microware was one of the first to license Java for embedded applications and is a leader in offering a variety of OS-9 tools and applications for a variety of device classes.

As an integrated cross-application development environment for OS-9, Microware has developed the Hawk environment, which runs on the MS Windows NT platform.

3.9 OSE RTOS

The real-time operating system OSE RTOS, developed by ENEA Corporation, has a priority scheduling kernel. This kernel is highly optimized for high performance and is compact enough for use in embedded systems. OSE has a message-driven architecture with simple system calls. Message passing in OSE serves as a conceptual gateway in distributed multiprocessor embedded systems. Tasks send messages to each other directly through the OS without support for queues, mailboxes, or other intermediate mechanisms. OSE RTOS supports paging, duplication, dynamic code updating and many communication protocols.

The OSE RTOS architecture is based on a multi-layer model.

The unit of execution in OSE RTOS is the process. Processes can be grouped into a block, which can have its own memory pool. In the OSE RTOS kernel, an address space belongs to a segment, which can include one or more blocks. Mapping blocks to segments and mapping pools to regions makes it possible to achieve complete memory protection and program isolation. Blocks and pools can be located in one or more shards.

In OSE RTOS, process separation is understood as dynamic and static: static processes are created by the kernel when the system starts and exist throughout the life of the system, dynamic processes are created and destroyed during execution.

3.10 Windows CE

The Windows CE RTOS is modular with a small kernel and optional modules that run as independent processes. Scheduling in Windows CE is based on priorities. Protection of the kernel and processes from each other is supported. In addition, a mode of operation is possible when there is no protection between processes and the kernel. It should be noted that interrupts are processed as threads and have thread priority levels. Windows CE also supports threads, which are threads that the kernel does not manage. Each thread runs in the context of the thread that created it; they can be used to create a scheduler within a thread. Such threads are useful in exotic or legacy applications, but they are not suitable for real-time systems.

Windows CE has a physical memory limit of 512MB. Microsoft introduced this limitation so that Windows CE could run on a wide range of embedded processors without compatibility issues, since some of these processors are capable of managing 512MB of physical memory. Windows CE implements virtual memory paging. Page size varies by platform, but 4KB is used whenever possible. It is possible to prohibit paging, which is important for real-time systems. In this mode, the module is completely loaded into memory before execution. Then paging(paging) will not affect the execution of the application.

Unlike other RTOSs, Windows CE supports generic wait functions for various types of objects (mutexes, semaphores, events, processes, and threads). The advantage of such functions is that many objects can be expected at once until one of them gives a signal. Critical sections can only be used within a single process. Computational semaphores and mutexes can be used both within one process and between processes. Windows CE uses priority inheritance to avoid the priority inversion problem.

3.11 Nucleus RTOS

The Nucleus operating system, developed by Accelerated Technology Corporation, is designed for embedded applications.

Nucleus is a cross-system, i.e. a software product is created on one software and hardware platform and executed on another.

The Nucleus RTOS comes with open source code.

The core of the Nucleus RTOS, Nucleus PLUS, provides multitasking, portability and scalability. The kernel is implemented as a library of functions in C.

Nucleus PLUS provides features such as task interaction management ( mailboxes, queues, pipelines, semaphores, events, signals), as well as memory management, timers, interrupts. Task scheduling is carried out based on priorities, as well as using the FIFO algorithm.

When a system call is executed, the task can be suspended indefinitely, for a specified interval, or not suspended. All objects in the system can be created and deleted dynamically.

Conclusion

Real-time operating system based applications have been used in embedded systems for many years special purpose, and more recently they have begun to be used everywhere, from on-board control systems aircraft, to household appliances.

The most important property of real-time systems is the predictability of the system's time reactions to external events. Only based on this property can we talk about the consistency and validity of the solutions embedded in a specific real-time operating system.

Real-time systems must respond to external input parameters and produce new output results within a limited time. Response time should be limited. Very long response times can cause real-time systems to fail.

There is no doubt that most traditional real-time operating systems were designed with a single CPU on a single board in mind. Nowadays, support for multiprocessor systems is increasingly required.

It is obvious that operating systems with a monolithic architecture, due to their focus on specific processor platforms and the nature of interaction with the kernel, are unlikely to be used as relatively universal real-time operating systems for high availability systems.

Modern real-time operating systems are based on new architectural approaches, complemented by tools for developing application systems that allow them to be created in a reduced time frame with best characteristics In addition, those created on the basis of a microkernel have a number of advantages compared to a monolithic architecture, and in combination with an object-oriented approach, they allow the system to become hardware independent and provide a quick response to external events.

It is in light of temporal predictability that an RTOS must be carefully designed to support real-time applications.

Bibliography

1. Burdonov I.B., Kosachev A.S., Ponomarenko V.N. Real-time operating systems. Preprint: Institute of System Programming RAS. Irkutsk, 2006.

2. Olifer V.G., Olifer N.A. Network operating systems: Textbook for universities. 2nd ed. - St. Petersburg: Peter, 2008. - 669 pp.: ill.

3. www.ru.wikipedia.org

4. www.intuit.ru

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.

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 is not always clear.

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 testing 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

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 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 increased 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 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 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).

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 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

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 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 of ensuring network transparency.

QNX RTOS 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 QNX RT OS is its special network subsystem architecture, providing network “transparency” 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 operating principles 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

In terms of the quality of official technical support, the undoubted leader is LynxOS. LynuxWorks promises to answer any technical question within 4 hours from the moment the request is published. 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.

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

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 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 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 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, the process of porting even POSIX-compliant applications can often become quite labor-intensive due to differences in the implementation of libraries and compilers.

Support for processor architectures

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 different levels criticality is executed on one 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 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 top of it can be certified to DO-178B (there are many examples).

QNX does not comply with ARINC-653, and there are no DO-178B certified systems based on it 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, 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.

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.

Expert group / R&D.CNews

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.

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.
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.

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

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 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).

Support for multiprocessor and distributed systems

QNX RTOS 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 how it works 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.

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, 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

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).

Support for processor architectures

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 DO-178B certified (there are many examples).

QNX does not comply with ARINC-653, and there are no DO-178B certified systems based on them 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). 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.

Ministry of Education and Science of the Russian Federation

Volga State Technological University

Abstract on the discipline

“Real-time operating systems: features and applications”

Completed by: EF student (group PI-12)

Mikushov Yu. V.

[email protected]

Teacher: Borodin A.V.

Yoshkar-Ola

●Introduction

●Definition

●Development of modern operating systems

●Current state of the subject area

●Differences from general purpose operating systems

●RTOS architecture

●Types of OS tasks

●Five most important invisible OS tasks

●Features

●Application

●Operating systems market

●The future of RTOS

●Conclusion

●List of sources used

Introduction

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).

It is customary to distinguish between soft and hard real-time systems. In hard real-time systems, 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.

Definitions

A real-time system is a type of operating system, the main purpose of which is to provide a necessary and sufficient set of functions to ensure the software development of real-time systems on specific hardware.

A system is called a real-time system if the correctness of its functioning depends not only on the logical correctness of the calculations, but also on the time during which these calculations are performed. That is, for events occurring in such a system, when these events occur is as important as the logical correctness of the events themselves.

Components of a real-time system.

Application software		Dispatching
		Inter-thread communication
Real-time operating system		Interrupt handling
	Priority Inversion Protection	Thread management
		Memory management
Hardware			Devices

Mac OS X decryption:

“Mac” refers to the Macintosh company name.

“OS” – operating system, that is, operating system.

“X” is the Roman numeral ten, indicating the OS version number.

Development of modern operating systems

In the development of modern operating systems, there is a tendency towards further transfer of code to the upper levels and at the same time removing everything that is possible from the kernel mode, leaving a minimal microkernel. This is usually done by offloading most of the operating system's tasks to user processes.

When receiving a request for an operation, such as reading a block of a file, the user process (now called the served process or client process) sends the request to the server (server) process, which processes it and sends back a response.

By dividing the operating system into parts, each of which manages just one element of the system (file system, processes, terminal or memory), all parts become small and manageable.

Additionally, since all servers run as user-mode processes rather than kernel-mode processes, they do not have direct access to the hardware. Therefore, if an error occurs on the file server, the file request processing service may crash, but this usually does not cause the entire machine to stop.

Another advantage of the client-server model is that it can be easily adapted for use in distributed systems. If a client communicates with a server by sending it messages, the client does not need to know whether its message is being processed locally on its own machine or whether it was sent over the network to a server on a remote machine. From the client's point of view, the same thing happens in both cases: the request was sent and a response was received.

The above story about the kernel managing the transfer of messages from clients to servers and back is not entirely realistic. Some operating system functions, such as loading instructions into physical I/O device registers, are difficult, if not impossible, to execute from user space programs. There are two ways to resolve this problem.

The first is that some critical server processes (such as I/O device drivers) actually run in kernel mode, with full access to the hardware, but at the same time communicate with other processes using the usual message passing scheme.

The second option is to build a minimal information processing mechanism into the kernel, but leave policy decisions to the servers in user space. For example, the kernel can recognize messages sent to specific addresses. For the kernel, this means that it needs to take the contents of the message and load it into, say, some disk I/O registers to trigger a disk read operation.

In this example, the kernel may not even examine the message bytes if they happen to be valid or meaningful; it can blindly copy them to disk registers. (Obviously, some scheme must be used to limit the range of processes that have the right to send such messages.)

Current state of the subject area

Associations, companies and products

Microsoft and Apple Inc. are the most popular manufacturers of operating systems and software for them in the modern world.

Modern operating systems from Microsoft:

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

Modern operating systems from Apple Inc:

Modern mobile operating systems:

Linux systems (Android)

Differences from general purpose operating systems

The key difference between RTOS core services is the deterministic nature of their work, based on strict time control. IN in this case By determinism we mean that the execution of one operating system service requires a time interval of a known duration. Theoretically, this time can be calculated using mathematical formulas, which should be strictly algebraic and should not include any time parameters of a random nature. Any random variable that determines the execution time of a task in an RTOS can cause an unwanted delay in the application, then the next task will not meet its time quantum, which will cause an error.

In this sense, general purpose operating systems are not deterministic. Their services may allow occasional delays in their operation, which can lead to a slowdown in the application's response to user actions at an unknown point in time. When designing conventional operating systems, developers do not focus their attention on the mathematical apparatus for calculating the execution time of a specific task and service. This is not critical for this type of system

RTOS architecture

Over its history, operating system architecture has undergone significant development. One of the first principles of construction, the so-called. monolithic OS (Figure 1), was to present the OS as a set of modules that interact with each other in various ways within the system kernel and provide application programs with input interfaces for accessing hardware. The main disadvantage of this architecture is the poor predictability of its behavior, caused by the complex interaction of system modules with each other.

However, most modern operating systems, both real-time and general-purpose, are built precisely on this principle.

In automation tasks, level OSs are widely used as RTOS (Figure 2). An example of such an OS is the well-known MS-DOS system. 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 application applications to quickly access the hardware. The disadvantage of such systems 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.

One of the most effective architectures for building real-time operating systems is the client-server architecture. The general diagram of an OS operating using this technology is presented 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 fact, an independent application and is 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 rebooting the system.

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

Types of tasks

Every process contains one or more tasks. The operating system allows a task to spawn new tasks. Tasks can be divided into 3 categories based on their manner of action.

1. Cyclic tasks. Characteristic of control processes and interactive processes.

2. Periodic tasks. Typical for many technological processes and synchronization tasks.

3. Impulse tasks. Typical for signaling problems and asynchronous technological processes.

Five Most Important Invisible Tasks of the Operating System

1. Provides hardware-software “coupling”

The operating system serves as a kind of “translator” between the computer hardware and its software. If you open the computer case, you can see various boards, chips, cables and other components. This is the physical basis that makes the execution of the program possible. But a program cannot simply take and use the computer's hardware resources. It does this through the operating system.

Recently, operating systems have become increasingly called “platforms”. And this name very accurately reflects the essence. The OS is the platform on which programs are located. Or, as they say now, applications to the operating system. It is the operating system that allows the software to “talk” to the hardware. This also applies to input and output devices. The simplest example of an input device is a keyboard, and an output device is a monitor.

This is very important work. Theoretically, hundreds of devices can be connected to one computer various devices input and output. Let's take a regular mouse. But “mouse” is a general concept. There are dozens of different models of this manipulator. It would be an overwhelming task to provide separate software support for each type of mouse so that it communicates directly with the computer's resources. But the solution is the driver database contained in the operating system. For the user, it looks as if he simply connected any mouse to his computer, and it immediately started working.

2. Forces the same application to work on different hardware

It is the operating system that allows the software to run on different computers, and not just on one specific configuration. Once upon a time, programs were written for a specific computer model. The programming language actually acted as the operating system of the predecessors of modern PCs, microcomputers of the late seventies of the last century.

But these days, the OS has taken on the role of a kind of “adapter” between programs and computer hardware. If you take any two computer models, the sets of components from which they are assembled will differ. This applies even to Macintoshes that are famous for their similarity to each other, not to mention all the huge variety that can be found on the modern PC market.

The operating environment creates a so-called abstract environment for the program. This can be represented as a dialogue between the OS and the program. During this “conversation”, incomprehensible to humans, the program “tells” the platform about its needs, and the operating system has to “think” about how to rationally satisfy them. The point is that you need to think very quickly. The modern gamer is not ready to wait an hour or two for his favorite game to load.

So, the program “tells” the operating system what exactly it needs in order to work correctly. After all, the application is not directly familiar with computer resources. And the OS, in turn, distributes the tasks assigned to it by the program among the resources of the digital device. And the type of hardware does not matter to the program. The platform will take care of everything! The operating system can “speak”, if not with all, then with many devices and hardware modules.

If it were not for this valuable operating system skill, programmers would have to rewrite their programs for each specific computer configuration, for each set of components. And, if not for the operating system, the program might not work at all on a computer whose characteristics differ from those envisaged by the programmer when creating the program.

Today, developers create their applications for platforms, and not for some known hardware configuration. Simply put, not for a specific computer, but for a specific operating system. This is, of course, much easier. Millions of devices can run the same OS. Therefore, tens and even hundreds of thousands of applications have become possible, available to the modern user of each of the popular platforms.

3. Search required by the application file

The physical resources of a computer alone would not be enough for programs to correctly cope with their tasks. All information is stored in files and these files must obey certain rules. These rules cover how to name and store files. We call this general set of rules a “file management system” or simply a “file manager”.

Different operating systems implement different approaches to file management. In addition, the user can install additional software that allows him to manage files more efficiently. It is the operating system that “remembers” the files that are stored on the computer. When an application wants to access a particular file, the OS will show the program the way to it.

Without a file management system, digital information on a computer is simply a meaningless collection of data. Chaos, in which nothing can be found. And even more so, find it in the shortest fractions of a second.

The operating system follows its own rules invisibly to us, so you don’t have to manually access those memory cells where the file you need is physically stored. But, most importantly, the user of a modern operating system does not necessarily need to know these rules in order to work on a computer.

4. Efficient allocation of available RAM

Since we are talking about memory, it makes sense to remember about random access memory (RAM). About that very storage that is always “at hand” of the processor.

It must be emphasized that this most important computer resource is also managed by the operating system. RAM is a resource greatly underestimated by many users. How to make your computer run faster? Many people believe that they urgently need a more powerful processor. But in practice, it is often enough to simply increase the amount of RAM to experience a significant increase in computer performance.

In RAM, the computer stores the information that may be required by the processor performing the calculations. Consider this type of memory simply as a temporary storage device for information that needs to be "closer to the processor."

When we work with a computer, we sometimes have several programs running at the same time. The operating system allocates a certain amount of memory to each task. If the processor needs information that it doesn't find in RAM, it will have to look elsewhere for it. In particular, on the computer's hard drive. This will take longer than retrieving data from RAM. For the user, this situation will look like a temporary “freeze” of the application. In such cases, it is customary to say that “the computer thinks.”

One of the tasks that the operating system takes on, invisibly for the user, is minimizing lag time, that is, that very unpleasant time during which the computer is busy with its own business and does not respond to your calls to it. The problem is that at any given time the operating system

has a certain amount of RAM, which is always limited. This volume also depends on how many programs you are running at the same time. The operating system must “know” every moment how much RAM it has left in order to allocate it in time to the process that needs this important resource.

The operating system "evaluates" the requirements of each running process and decides how to intelligently satisfy them. Ideally, this should be done in such a way that the user does not experience any delays at all. But in practice, the OS simply tries to reduce such delays to a minimum, rationally distributing the resources that it actually has.

There are no computers on Earth with unlimited RAM. Therefore, the system always has to choose which process is considered priority at a given moment and which is secondary. Who should allocate memory urgently, and who will manage and be patient for the time being. The user may not always agree with the rules that the operating system follows when allocating memory. But independently allocating free RAM to processes would be much more difficult and time-consuming than entrusting this to a software platform.

5. Focuses the processor’s attention on a particular task

The central processing unit (CPU) is the physical module that solves the tasks that the user sets for his computer. Another thing is that a rare user speaks the language that the processor understands. What’s more, not every programmer is closely familiar with machine code. A person may not even think about the fact that any program is a complex set of mathematical problems.

The central processor does the calculations, that is, it finds solutions to these problems, and it gives you ready-made results that do not even closely resemble formulas from an algebra textbook. The average user is simply not interested in all this mathematics. He wants his game character to jump over an obstacle in a split second or wants to check the spelling of the text he just wrote. Behind these seemingly far from boring problems lies the most complex mathematics.

Every running program requires a portion of the processor's processing power. The more programs you run at the same time, the closer the processor load is to maximum. The task of the operating system is to coordinate the delivery of information for processing to the processor so that everything goes smoothly and unnoticed by the user. The OS can switch the processor's attention from one task to another.

One of the important roles of the operating system is that of a resource manager. If it copes well with this task, then we do not even know at what moment the processor put aside one task and turned its attention to another.

An invisible and irreplaceable assistant

The hardest job of an operating system is to get you to ignore it and focus on the applications that interest you. And while everything is going well, the user does not think about the platform at all. And only when software failures begin does the user realize how important the mission of the operating system is.

Those “differences” between operating systems that are noticeable to most users are purely cosmetic. It is a rare user who understands programming enough to see behind the graphical interface shell what actually distinguishes one operating system from another. Neither the appearance of the desktop nor the design of application icons has anything to do with the internal essence of the operating system.

The tasks described above are performed by each modern operating system, which controls any computer device. Regardless of what the operating system looks like and on what device it is installed: on a PC, mobile device or game console.

Peculiarities

Positive Features

Widespread product availability

In the vast majority of cases, Windows is installed on computers. Therefore, when you come to visit a friend or your place of work, you can easily transfer a couple of pictures from a flash drive, text files

or clips. The ease of use and support of OS Windows for any hardware and any programs has contributed to the global distribution of this OS.

Nice interface

Modern operating systems have a pretty nice and intuitive interface. This promotes quick perception of information, ease of use of the computer, and quick learning to work with the OS.

OS stability

In general, the stability of a modern OS can be called acceptable. However, the word “acceptable” here must be accompanied by a lot of reservations:

1. The stability of the OS becomes acceptable only after its high-quality and competent configuration - there is no point in talking about an untuned system (as well as an untuned guitar) here.

2. The stability of a modern OS also largely depends on the version of the product and the presence of installed service packs and add-ons - alas, without their presence, frequent failures occur in the operation of the OS.

4. The stability of a modern OS is greatly influenced by the hardware itself, which is used in conjunction with the running OS.

5. Also, device drivers have a significant impact on the stable operation of a modern OS. These are mini-programs responsible for pairing certain software with certain hardware.

Good compatibility with products from different developers (aboutO.C. Windows)

A modern OS is capable of correctly understanding any file types that appeared in its early reincarnations. If we recall the same file extensions, it will become clear that their ancestor, in fact, is that same primitive and archaic OS, once purchased from a third-party developer and brought to mind by Microsoft - MS-DOS. This continuity of file formats runs like a thread through all versions of Windows, which in itself is simply wonderful.