Real-time operating systems for avionics: a review. Features of development using OSV

All tips

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 fails software the other part continued 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, each of which specifies a set of software requirements designed to ensure the functionality of the entire system when failures occur. this level:

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 topics such as previously developed software, commercial software products, verification processes, historical references, 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 processes of the hardware life cycle and describes ways to ensure the required properties of products in order to certify them in accordance with the requirements.

ARINC 653 - Avionics Application Software Standard Interface. Developed by ARINC in 1997 and defines a universal APEX (APplication/EXecutive) programming interface between the operating system on-board computer 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.

General criteria for assessing privacy information technologies(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 the US National Institute of Standards and Technology, as well as relevant authorities in other countries (currently 13 other 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 imposing four mandatory groups of requirements on systems (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 the source level. 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 conform to 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 I/O 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 of possible sources Interrupts are timers that control the dispatch of events 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 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 additional equipment on the aircraft, including software.

"General criteria" for assessing secrecy

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 fast decision problems. 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 incorporated already at the design stage, using special means of 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 a very high cost 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 on the Intel and PowerPC platforms.

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. In addition, 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 meeting 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 considered requirements for real-time operating systems are very significant for many other industries, such as the navy, military and space systems, communication systems, life support equipment, systems intended for use in emergency situations - wherever a quick response to events, high reliability, durability and safety of the tools used, including software, are needed.

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 modernize 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 hardware, developed by Rockwell Collins, provides computing and networking capabilities that can be used to perform a variety of 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 various concepts, and in this article we will use safety as a synonym for security, and security for secrecy. - Note auto

Distinctive features of an RTOS from a general-purpose OS

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

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

Hard and soft real-time systems

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

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

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

the cost of being late can be infinite.

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

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

Operating system kernel

The kernel is the central part of the operating system (OS), providing applications with coordinated access to computer resources, memory, external hardware, external input and output devices, translating application language commands into binary code language that the computer understands. As a fundamental element of the OS, the kernel represents the lowest level of abstraction for applications to access the system resources needed for their operation. Typically, the kernel provides such access to the executing processes of the corresponding applications through the use of inter-process communication mechanisms and application calls to OS system calls.

Monolithic core

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

Advantages: Speed of operation, simplified development of modules.

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

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

Microkernel

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

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

Flaws: Passing data between processes requires overhead.

Runtime environment

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

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

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

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

The kernel can provide different types of services:

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

Overview of RTOS architectures

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

level OS (Figure 2). An example of such an OS is 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. Disadvantage

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

Figure 2. Layered OS architecture

One of the most effective architectures for building real-time operating systems is the client-server architecture. 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

reboot the system.

Figure 3. Building an OS using client-server architecture

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

List of used literature:

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

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

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

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

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

(Real Time Operating Systems - RTOS) refer to software and are intended for servicing digital systems in cases where:

● the system must provide not only the result of processing the received information, but also the length of time to obtain the result. The RTOS is required, along with obtaining the required result, to implement specified time parameters: time intervals between events and responses or a specified frequency of receiving external data and issuing results;

● the system is capable of performing several tasks simultaneously. Typical multitasking The operating system allocates the same amount of time to each task (program), giving the user the impression that all programs are running simultaneously. A real-time operating system is a special case of a multitasking operating system optimized for implementing control processes. It quickly responds to external events and allows you to simulate the operation of several processors, each of which controls one device. Therefore, to control a complex system using a single processor, it is advisable to use an RTOS that is capable of coordinating the execution of various tasks. An example of an RTOS is an elevator control system.

Operating principle of RTOS

When a request is received, the input data for solving the problem is checked. If they are present, the task begins to be executed. IF the required input data is missing, the RTOS moves on to the next task (if there is a request to execute it). Interrupts are used to receive input data and run the corresponding task. A task is typically started by moving it from a queue of pending tasks to a queue of tasks to be executed.

Each task has an input queue of messages, which it can only process during an allotted time interval or when an interrupt request is made. If the response takes too long, the task is placed back into the execution queue and control is transferred to the next task.

System resources (disk drives, timers, I/O devices, etc.) are usually available only for certain tasks. This allows you to organize a queue of requests for resources in such a way as to prevent simultaneous access to one resource by several tasks.

Requirements for RTOS.

Modern PB OS must meet the following requirements:

● short response time (getting results);

● implementation of multitasking mode with a flexible priority mechanism;

● small amount of memory (sufficient to be placed in the resident memory of the application system);

● availability of service functions and support tools for the development of application programs and a number of others.

Currently, RTOSes that have various characteristics and tested in such areas of application as production automation systems, instrumentation systems, telecommunications equipment, aerospace and military equipment, transport, security systems, etc.

Types of RTOS

There are two types of RTOS:

● hard real time systems, which occupy a small amount of memory and have minimal response time, but have very limited service tools. They are implemented according to modular principle, which allows you to use only those tools that are needed in a given application. The result is a significant reduction in memory requirements and response time for a given application;

● soft real-time systems, which require more memory, have a longer response time, but satisfy a wide range of user requirements in terms of task servicing mode and level of service provided. Interface tools for soft real-time systems enable the use of highly efficient debuggers or integrated development environments.

Soft real time system.

Let us consider this type of system using the example of the OS–9 system from Microwave Systems. OS-9 uses IBM-PC as an instrumental computer, running in Windows environment, or Sun, HP, IBM RS/6000 workstations with UNIX-type operating systems. Characteristics OS-9:

● modularity, which provides the ability to configure the target RTOS in accordance with the class of tasks being solved. By eliminating unused modules, you can reduce memory footprint and reduce system cost;

● flexibility of the structure, providing reconfiguration of the system and expansion of its functionality. Functional components OS–9:

● real-time kernel (OS –9 kernel);

● general input/output facilities (I/O man);

● file managers;

● software development tools.

OS –9 functional components are designed as self-contained modules that can be removed or added using simple commands that do not require recompilation or relinking. By combining modules, you can create target operating systems with different functionality.

Let's look at the functional components listed above.

Real-time kernel

The system contains two types of kernels:

● Atomic core, which implements a minimum number of service functions (remote loading, communication with local network, control of slave microcontrollers). The core is used in systems embedded in various equipment, has a small volume (24 KB) and provides minimal response time (3 μs at a clock frequency of 25 MHz);

● Standard core, which provides a wide range of service functions and application program development, the implementation of which requires a larger amount of memory (up to 512K bytes of ROM and 38K bytes of RAM). By changing the functional modules of the kernel, it is possible to implement systems of varying complexity and purpose: from controllers built into hardware with resident software and simple input/output facilities to complex functional workstation-class systems with advanced network support and providing a variety of service functions, including multimedia.

The OS –9 system provides the user with the ability to select a kernel depending on the functional purpose of the system. General means input/output. The physical interface of OS –9 with a variety of external devices is provided by a large a set of drivers, created both by Microwave Systems and numerous developers of equipment that use this operating system for specific applications. File managers. These include modules that control logical data flows. Each of the modules has a specific functional purpose and specification. File managers can be divided into three groups:

● standard managers designed to perform such basic exchange functions with external devices as organizing a queue of incoming commands, managing byte and block serial exchange and exchange with direct memory access;

● network and communication managers that ensure operation of OS –9 with various networks and data exchange via communication channels with the most common communication protocol standards;

● graphical interface and multimedia application managers. Program development tools. OS-9 includes a software package (BSP) to support development boards, which provides working together OS–9 with a number of SBCs (Single Board Computer). The combined use of BSP and OS–9 allows you to configure the target system for a specific application.

The OS–9 system contains programming support tools: Ultra C/C++ compilers, EM ACS text editor, three types (including symbolic) debuggers, a set of utilities for organizing the control and assembly of software products. In addition, there is a large set of (OS-9 compatible) programming support tools that are developed by other companies. FastraTo. The FasTrak environment comes with OS-9 and provides the user with the most complete set of programming and debugging tools. Some of the FasTrak software is installed on the tool computer, and some is installed on the user's target system. The FasTrak environment integrates all the tools needed to support the design/debugging of target systems. The version of the FasTrak environment for working on an IBM PC contains:

● a text editor with keyboard transcoding tools, which allows editing in a user-friendly format;

● Ultra C/C++ compilers;

● debuggers providing two debugging modes: custom- to create application programs, and systemic- for servicing interrupts, system calls and accessing core real time;

● means of interface with the company's logic analyzers.

The FasTrak environment has extensive functionality what makes her effective means creating software for various microcontroller systems.

Microware Systems supplies a number of system packages focused on various application areas:

● Wireless OS –9 - for the development of wireless communication devices: cell phones, pagers, portable digital assistants (PDA);

● Internet OS –9 - for developing devices with access to Internet networks ;

● Digital Audio / Video Interactive Decoder (DAVID) OS –9 - for the development of distributed digital interactive television systems.

Hard Real Time System

Let's look at the features of this type of system using the example of the VxWorks system from WindRiver Systems, designed to work with families of microprocessors from many manufacturers. The VxWorks system is installed on the target system being debugged and works in conjunction with the Tornado integrated development environment running on the tool computer. IBM PCs running in Windows, or SUN, HP, etc. workstations are used as an instrument computer. Short description systemsVxWorks. The lower level of the hierarchical organization of the system is the real-time microkernel, which performs the basic functions of scheduling tasks and managing their communication and synchronization. The minimum set of kernel modules takes 20–40K bytes of memory. All other functions - memory management, input/output, network exchange and others - are implemented by additional modules. To support graphical applications, VxWorks provides a VX-Windows graphical interface.

If the target system's memory is limited, you can use the RTGL graphics library, which contains basic graphics primitives, sets of fonts and colors, drivers for typical input devices and graphics controllers. VxWorks also includes various tools to support a variety of network protocols. Trace given events and their accumulation in buffer memory for subsequent analysis are performed in real time by special debugging tools, and tracing systemic events - WindView dynamic analyzer. The WindView analyzer works similarly to a logic analyzer, displaying on-screen timing diagrams of task switches, message queue entries, and other processes. The Stethoscope Data Monitor allows you to analyze dynamic changes in user and system variables, including a procedure profiler. VxWorks includes:

● software package to support development boards;

● VxSim simulator, which allows you to simulate the multitasking VxWorks environment and the interface with the target system on an instrumental computer, as well as develop and debug software without connecting the target system.

For comprehensive debugging of target systems, VxWorks provides an interface with circuit emulators and ROM emulators. Integrated Development EnvironmentTornado . Tornado includes the VxWorks 5.3 system, which includes a real-time kernel and system libraries, programming tools, a high-level debugger and a number of other system tools. Additional tools of the Tornado environment provide control of the debugging process, visualization of the state of the target system, and other service functions. The open architecture of the Tomado environment allows the user to connect their own specialized tools and expand opportunities standard means.

The VxWorks real-time operating system together with the Tornado integrated environment is a powerful tool implementation of target systems operating under strict restrictions on the amount of memory used and response time to external events.

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

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

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

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. In theory, hundreds of different input and output devices can be connected to a single computer. 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 type hardware has no meaning for 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 for the file required by the application

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 at the 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 in one way or another 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, text files or clips from a flash drive. 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 (like 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.

3. The stability of the OS also depends on the applications themselves installed on the OS by the user: the more stable they are in operation and the more compatible with the software itself Windows shell, the fewer failures we will be able to observe in the operation of the main 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.

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 automated systems management

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 under the worst external conditions, which differs sharply from the requirements for performance and speed 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 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 during the operation of such a system. Additionally, it is not possible to distribute the OS on a multiprocessor system.

In a multilayer structure, changes in one layer affect adjacent layers, 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 concept of a process, which comes from the UNIX world, is poorly implemented in a multitasking system because 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;

*interruption of the process occurs within a limited time.

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

In EDF, priority is assigned dynamically, and the highest priority is assigned to the process that has the shortest execution time remaining. At large downloads EDF systems have 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. Second, 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 RTOSes 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 be addressed:

*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 virtual memory management);

*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 system and user pages. User 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 the previous model, a 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, dynamic memory allocation is possible, without virtual memory and without 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 keeps track of the current time, certain time starts tasks and threads and pauses them at specified 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 whether a process or thread is running over time, allowing it to dynamically detect 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

Large differences in RTOS specifications and great amount 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 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 structure is a collection of optional features, OS vendors can implement only part of the standard interface and still claim 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 viewed as 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 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 intended 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 designed 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 open source based vs. similar systems with closed code. 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.

The RTOS is linked to the hardware using a special library of BSP (board support package) subroutines and specialized subroutines for various architectures.

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

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

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,

*graphical 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). procedure call), whose priority 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 Windows kernel NT and uses the Windows NT service and the WIN32 API to provide the necessary functions. 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 results in fast context switching, 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 meets the requirements POSIX standards and ARINC-653, 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 tools and applications within OS-9 for various classes of devices.

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 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 execution of a task can be suspended indefinitely, for a specified interval, or not suspended. All objects in the system can be created and deleted dynamically.

Conclusion

For many years, real-time operating system-based applications have been used in specialty embedded systems, and more recently they have found their way into everything from aircraft on-board control systems to home 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 parameters input and create new output results in 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, can hardly 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 short time with the 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-based one. oriented approach, 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

Real-time operating systems for avionics: a review. Features of development using OSV

Requirements regulation system

Isolated partition concept

DO-178B standard

"General criteria" for assessing secrecy

LynxOS-178 system

Literature

Operating principle of RTOS

Requirements for RTOS.

Types of RTOS

Soft real time system.

Real-time kernel

Hard Real Time System

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

Similar documents

Popular articles

Latest articles

Sections

Pages

Special projects

Contacts