Difference between revisions of "Real-time operating system"

From Bauman National Library
This page was last modified on 28 December 2016, at 10:20.
 
Line 51: Line 51:
 
* QueryHome [Web page]: Soft Real-time Operating System Vs Hard Real-time Operating System / Retrieved: 24.12.2016. — Access mode: http://tech.queryhome.com/47882/soft-real-operating-system-hard-real-time-operating-system
 
* QueryHome [Web page]: Soft Real-time Operating System Vs Hard Real-time Operating System / Retrieved: 24.12.2016. — Access mode: http://tech.queryhome.com/47882/soft-real-operating-system-hard-real-time-operating-system
 
* Wikipedia [Web page]: Real-time operating system / Retrieved: 24.12.2016. — Access mode: https://en.wikipedia.org/wiki/Real-time_operating_system
 
* Wikipedia [Web page]: Real-time operating system / Retrieved: 24.12.2016. — Access mode: https://en.wikipedia.org/wiki/Real-time_operating_system
* Национальная библиотека им. Н.Э. Баумана [Web page]: Операционная система реального времени / Retrieved: 24.12.2016. — Access mode: http://ru.bmstu.wiki/%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%80%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8
+
* Национальная библиотека им. Н. Э. Баумана [Web page]: Операционная система реального времени / Retrieved: 24.12.2016. — Access mode: http://ru.bmstu.wiki/%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%80%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8
 +
 
 +
[[ru:Операционная система реального времени]]

Latest revision as of 10:20, 28 December 2016

A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time applications which process data as it comes in, typically without buffering delays. Processing time requirements (including any OS delay) are measured in tenths of seconds or shorter increments of time. They either are event driven or time sharing. Event driven systems switch between tasks based on their priorities while time sharing systems switch the task based on clock interrupts.

Kinds of RTOS

  • Hard Real-Time System. Hard real time means timeliness of a computation in the system. If computation is not completed within the specified time then there is no value to a computation and the effects of a late computation may be catastrophic to the system.
  • Soft Real-time System. Soft real time is a property of the timeliness of a computation where the value diminishes according to its tardiness. A soft realtime system can tolerate some late answers to soft realtime computations, as long as the value hasn't diminished to zero. A soft realtime system will often carry meta requirements such as a stochastic model of acceptable frequency of late computations.

Requirements

RTOS should have:

  • multitasking and preemptability
  • concept of stream priority
  • support of predictable synchronization mechanisms
  • provision of mechanism for priority inheritance
  • predictable behavior of the operating system

Architecture

Structure of RTOS has evolved from a monolithic multilayer structure of the operating system and then to the client-server architecture:

  • The monolithic structure - operating system consists of a set of modules and one module changes affect other modules. The more units, the more chaotic the operation of such a system. Furthermore, it is impossible to distribute a multi-OS system.
  • The multilayer structure - changes in one layer affect the adjacent layers; moreover, through a treatment layer possible. For real-time systems, direct appeal to every layer of the operating system must be ensured, and sometimes directly to the hardware.
  • Client-server structure - data base OS to a minimum (the scheduler and synchronization primitives). All other functionality imposed on another level and implemented through threads or tasks. The set of server tasks is responsible for system calls. Applications are clients who request services via system calls. Client-server technology allows you to create a scalable operating system and simplifies the distribution in a multiprocessor system. When operating system replacing a module does not cause the effect "snowball"; In addition, module failure does not always result in a failure of the system as a whole. Now you can dynamically load and shipping units. The main problem in this model is a memory protection, because server processes must be protected. Each service request system must switch from the application context on the server context. Supported memory protection switching time from one process to the other increases.

As a rule, most of the modern RTOS is built on a microkernel, which provides planning and scheduling problems, and also provides their interaction.

Despite the reduction to a minimum in the core abstractions OS microkernel must still have an understanding of the process of abstraction. All other conceptual abstraction operating system placed outside the nucleus, called on-demand and run as an application.

Kernel features

All today are multitasking RTOS systems. Tasks share the resources of a computer system, including the processing time.

A clear boundary between the kernel (KERNEL) and no operating system. They are distinguished as a rule, feature set. The cores provide the user with basic functions such as scheduling synchronization tasks, interprocess communication, memory management, and so on. D. Operating systems, in addition, have a file system, network support, the interface with the operator, and other high-level tools.

An important part of any RTOS is a task scheduler, whose function - to determine which tasks should be performed in the system at any given point in time. The main planning methods typically include: round robin (in round robin style), splitting time with fairness (time sharing with fairness), cooperative multitasking. The most commonly used RTOS planning principle - the priority multitasking preemptive. The basic idea is that a top priority as soon as the work appears to her, immediately interrupts (replacing) low priority. However, real-time systems, the range is very wide, ranging from completely static system where all of the tasks and priorities of pre-defined, to dynamical systems, where a set of tasks, their priorities, and even scheduling algorithms may change during operation. There are, for example, a system where each individual task can participate in any of the three scheduling algorithms, or combinations thereof (displacement, time-sharing, cooperative). Furthermore, priorities can be assigned to the same of different. In general, scheduling algorithms need to meet the criteria for the optimal functioning of the system. However, if the hard real-time systems, this criterion is obvious << EVER and everything is done in time >>, then the soft real-time systems, this can be, for example, minimum or average maximum delay timely completion of operations. Depending on the optimality criteria task scheduling algorithms may be used that differ from those considered. For example, it may be that the planner should analyze the time of issue of time-critical control actions and start to perform that task, which is responsible for the nearest of them (algorithm earliest deadline first, EDF).

Although each task in the system, usually perform any particular function, it is often necessary to harmonize (sync) actions performed by the different tasks. This synchronization is necessary, mainly in the following cases:

  • Functions performed by the various tasks related to each other. For example, if one prepares the initial challenge data to the other, the latter is not executed until until it receives from the first task corresponding message. A variation in this case - when under certain conditions the problem gives rise to one or more new tasks.
  • It is necessary to organize multiple tasks access to the shared resource.
  • The need to synchronize tasks with external events. As a rule, it uses the interrupt mechanism.
  • The need to synchronize tasks on time. A range of different options in this case is quite wide, from the binding date of issuance of any impact to the exact astronomical time delay to a simple task for a certain period of time. To address these issues ultimately used special hardware called a timer.

Examples

  • QNX
  • OS-9
  • VxWorks/Tornado
  • IA-SPOX
  • RTX
  • Falcon
  • Hyperkernel

Sources