Abstract on the theme of master's work

Content

• Introduction
• 1. Goals and objectives of research and development
• 2. Basic provisions of the real-time systems
  • 2.1 Basic concepts
  • 2.2 The structure of real-time systems
  • 2.3 Processes, streams, tasks
  • 2.4 Mechanisms of the real time
  • 2.5 Clocks and Timers
• 3. Features of debugging applications in real-time systems
• Conclusions
• References

Introduction

Process management of system resources tasks, threads, interrupt service routines, and so on is one of the basic functions of an operating system and by using a planning tool. This mechanism allows the system to perform several tasks in parallel. In real-time systems planning should also ensure predictable behavior, safety, the possibility of a long, trouble-free operation, the tasks to set deadlines. From planning method depends largely on the successful operation of the system as a whole [1].

On the other hand, the increase in production volume and diversity of microprocessor technology, expand their spheres of application development leads to the need of various real time operating systems — from compact, designed for single-chip microcontrollers service to powerful network systems. Way to meet the demands of high performance and reliability of these systems is through increased clarity and durability of their logical organization.

This fact raises urgent task of developing rationally organized basic structures which present in summary form the key principles of operating systems options aimed at achieving a particular type of efficiency. For this purpose, different methodologies put forward the development of appropriate systems. Of particular relevance acquired object-oriented methodology, based on the benefits of developing object using high-level languages​​.

Application of real time operating system is always associated with the equipment, with the object, with events occurring at the facility. Real-time system as a hardware-software system includes sensors that record events at the facility, input-output, transforming sensor data into a digital form suitable for processing these readings on the computer, and finally, a computer program that responds to events occurring at the facility.

Realtime operating system is focused on the processing of external events. That leads to a fundamental difference (compared with the general-purpose OS) in the structure of the system, the functions of the kernel, constructing a system IO. For example, failure details of the mechanism for moving the conveyor belt, for the sole reason that it allows system resources, can lead to disastrous results, as well as the impossibility of moving parts due to the employment of the system.

1. Goals and objectives of research and development

The purpose of the master's work is to develop a user-friendly tool for debugging algorithms Manager and Scheduler for real time operating systems. To achieve the goal will be taken platform Qt, C++ language and QML, that will not only provide an intuitive interface and fast responsiveness of applications, but also give applications to run on multiple operating systems supported platform Qt. Application is developed in a modular paradigm that will without any problem to replace any part of it.

As part of the research serves to obtain information about whether the general purpose operating system, that is certainly not being opretsionnymi real-time systems, serve as a model environment for developing and debugging software for real-time systems.

2. Basic provisions of the real-time systems

2.1 Basic concepts

There are several definitions of real-time (RTS), most of which contradict each other. Here are a few of them to show different views on the purpose and main tasks of RTS.

1. Real-time system is a system in which the success of an operation depends not only upon its logical correctness, but from time to time, for which she received the result. If the time limit is not met, then it indicates a malfunction.

Thus, the time limit should be guaranteed satisfied. This requires the system to be predictable, i.e. regardless of its current state and workload give the desired result in the required time. It is desirable that the system provides the greatest possible percentage of available resources.

2. POSIX 1003.1 standard defines of RTS as follows: Real time operating systems — operating system is the ability to provide the required level of service in a given amount of time.

3. Sometimes real-time systems called constant readiness system (on-line system), or interactive systems with a sufficient reaction time. This is usually done for marketing reasons. Indeed, if an interactive program called operating in real-time, it simply means that it is time to process requests from the person for whom the delay in hundreds of milliseconds, even invisible.

4. Sometimes the concept of real-time system equated with fast system. This is not always correct. The delay time for the event Vietnam is not so important (it can reach a few seconds). The main thing that this time was sufficient for these applications and guaranteed. Very often, the algorithm with a guaranteed operating time is less efficient than an algorithm such action does not possess. For example, the algorithm fast sorting average is significantly faster than other sorting algorithms, but it is guaranteed estimate of the complexity is much worse.

5. In many application areas of RTS introduced the concepts of real time. For example, the process of digital signal processing is called a going realtime, if analysis (for input) and/or generation of (at the output) of data can be conducted during the same time that the analysis and/or the generation of the a data signal without any digital processing. For example, if the processing of audio data requires 2.01 seconds to 2.00 seconds of sound analysis, it is not real-time process. If, however, requires 1.99 seconds, this real-time process.

Called a system of real time hardware-software system that responds in a predictable flow times on unpredictable external events. This definition means that:

1) The system must have time to react to an event that occurred at the facility during the time critical for this event (meet deadline). The critical time is determined for each event object, and the event itself, and can of course be different, but the reaction time of the system should be predicted (calculated) for creating the system. Lack of response to the predicted time it is an error for real-time systems.

2) The system must have time to react to both events. Even if two or more external events occur simultaneously, the system must have time to react to each of them during the time intervals for these critical events. A good example of a problem that requires RTS is control of the robot, taking part with the conveyor belt. Moving the item, the robot has only a small window of time when he can get it. If it is late, the item is no longer on the desired portion of the conveyor, and therefore the job is done, despite the fact that the robot is in the correct location. If it is positioned before the item is not yet time to drive, and the robot will block her path.

Distinguish real-time system of two types — hard real time system, and soft real-time systems. Hard real-time systems do not allow any delays reaction system under any circumstances because:

• results may be useless in case of delay,
• can lead to a catastrophe in the case of a delayed reaction,
• cost of delay may be infinitely large.

Examples of hard real-time — onboard control systems, safety systems, fault recorders.

Soft real time system characterized in that the reaction delay is not critical, although it may increase the cost and results in a decrease in overall system performance. Example — network operation. If the system has not had time to process the next received packet, it will timeout on the transmitting side and re-sending (depending on the protocol, of course). Data is not lost, but network performance decreases.

The main difference between the systems of hard and soft real-time can be expressed as: hard real-time system will never be late with the response to the event, soft real-time system — should not be late with the response to the event.

2.2 The structure of real-time systems

Any real-time system can be described as consisting of three major subsystems, as depicted in figure 1.

Manageable, (controllable) subsystem (eg, industrial plant, a computer-driven vehicle), dictates the requirements of real-time; control subsystem (controlable) controls some computing and communication equipment for the use of controlled subsystem; subsystem operator (operating) controls the complete system activity. Interface between managed and control subsystems consists of devices such as sensors and actuators. The interface between the operator and the control subsystem connects man with computer.

Controlled system is the tasks that use the equipment controlled subsystem control. This last subsystem can be constructed of a very large number of processors, control of local resources such as memory and storage devices, and access to the local network in real time. These processors and resources are managed by a software system, which is called by the operating system and real-time [2].

2.3 Processes, streams, tasks

There are various definitions of the term task for multitasking RTOS. We assume the task set of operations (machine instructions) for performing logiicheski complete system functions. The task of competing with other tasks for control of the resources of the computer system.

Taken to distinguish between two kinds of problems: processes and threads. The process is a separate downloadable software module (file), which is typically during execution has its own independent memory areas for code and data. In contrast, the flows are shared portions of code and data within a single software module.

A good example of a multithreaded program is a text editor Word, where a single application can occur simultaneously and typing, and spelling checker.

Advantages of streams
1. Since a plurality of streams capable placed inside one executable module, it saves resources both external and internal memory.
2. Using shared memory area flows efficiently organize interprocess messaging (enough to pass a pointer to the message). Processes have no shared memory area, so the OS must either copy the entire message from the memory of a problem in another area of ​​memory (for large messages are quite expensive), or make special arrangements that would allow a problem to access the message from the other memory tasks.
3. Typically, context streams less than the context of processes, and hence when switching between tasks and threads is smaller than that between the tasks and processes.
4. Since all the streams, and sometimes the very core of PB placed in the same executable module greatly simplifies the use of debugger.

Disadvantages of streams
1. Typically, the streams can not be dynamically loading. To add a new thread, you must hold the appropriate changes in the source code and recompile the application. Processes unlike flows podgruzhaemy that can dynamically change the functions of the system during its operation. In addition, since the processes correspond separate software modules, they can be developed by different companies, thus achieving additional flexibility and the ability to use previously accumulated software.
2. That streams have access to the data area of each other can lead to a situation where a faulty data stream is able to spoil other stream. In contrast, the processes are protected from the mutual influence and attempt to write in their not memory usually leads to the emergence of a special interrupt processing exceptions. Implementation mechanisms and process management streams, the possibility of mutual coexistence and interaction are defined specifically on real time.

As a rule, all important, in terms of operating system, task information is stored in a unified data structure — the control unit (Task Control Block, TCB). In block stored settings such as the name and number of the problem, the upper and lower boundaries of the stack, a reference to the message queue, the task status, priority, etc.

Priority — is a kind of integer assigned task and is characterized by its importance in comparison with other tasks running on the system. Priority is used primarily task scheduler to determine which of the ready-to-work tasks should get control. Distinguish system with dynamic and static priority. In the first case, priority of tasks can be changed during execution, while in the second task priority is fixed at the design stage, or during the initial configuration of the system.

Task context — is a data set containing all the necessary information to resume the task from the point where it was previously interrupted. Often context is stored in the TCB and includes data such as the program counter, stack pointer, CPU and FPU registers etc. Scheduler if necessary context saves the current active task and restores the context tasks assigned for execution. Such context switching and is, in fact, the main mechanism in the transition from RTOS one task to perform another.

From an operating system perspective, the problem can be in several states. Number and name of these states differ from one operating system to another. Poovidimomu, the largest number of states tasks defined in the language Ada. Nevertheless virtually any RTOS loaded to perform the task can be, at least in three states.

1. Active task — this task performed in the current system time.
2. Ready task — a task ready to run and wait in the queue its scheduler.
3. Blocked task — it is a task that is suspended until certain events. Such events could be the release of the necessary resource problem, the expected delivery messages, the completion of the timeout period, etc.

Empty problem (Idle Task) — it is a task that runs the operating system at the time of initialization and performed only when the system has no other ready to perform tasks. Empty task starts with the lowest priority and usually represents an infinite loop "do nothing." An empty tasks operating system provides a convenient mechanism for mining situations where no one ready to fulfill the task.

Typically, multi-tasking operating system allows you to run multiple copies of the same task. In addition, for each such copy is created and released their own TSV memory area. To save memory, can be provided to share the same executable code for all running instances. In this case, the program should provide reentrant (reentrant). In addition, the program should not use temporary files with fixed names and must correctly access to global resources.

Reentrant (reentrancy) means you can without negative consequences to temporarily suspend execution of a function or subroutine, and then call that function or subroutine again. Reentrancy is a particular manifestation of recursion when the body contains a call to the subroutine itself. A classic example is the reentrant system DOS, and serves as a common cause of non-reentrant use of global variables [3].

2.4 Mechanisms of the real time

The most important characteristics are inherent in the RTOS operating system real time mechanisms.

The process of designing a specific real-time system begins with a thorough review of the facility. Project developers are exploring object studying possible events on it, define critical terms of the reaction system at every event and develop algorithms for processing these events. Followed by the design and development of software applications. What are the mechanisms in real time operating systems make real-time system (RTS) predictable?

Basic tools to develop scenarios of the system are a priority system processes (tasks) and scheduling algorithms (scheduling) of RTOS.

In multi-used general-purpose operating system, as a rule, various modifications of the scheduling algorithm circular, based on the concept of continuous time slice, provided the process to work. Scheduler after each time slice scans all active processes and decides whom to hand over control, based on the priorities of processes (numerical values ​​assigned to them).

Priorities may be fixed or vary over time — it depends on the scheduling algorithms in the OS, but sooner or later CPU time get all the processes in the system.

Scheduling algorithms circular apply in pure form in real time operating system. The main disadvantage — continuous time slot during which processor owns only one process. Planners also real time operating systems have the ability to change the process before the expiration time slice, if that became necessary. One of the possible scheduling algorithms with priority preemptive. World real time operating systems is rich in various scheduling algorithms: dynamic priority, monotone, adaptive, etc., the goal is always pursued one - provide a tool that allows you at the right time to perform exactly the process that is needed.

Another set of mechanisms for real-time provides a means of process synchronization and data transfer between them. For real time operating systems characterized by the development of these mechanisms. Such mechanisms include: semaphores, mutexes, events, signals, tools to work with shared memory, data channels (pipes), message queues. Many of these mechanisms are used in general-purpose operating system, but their implementation in real time operating system has its own characteristics — runtime system calls almost independent of the state of the system, and each real time operating system has at least one fast data transfer mechanism between processes.

Tools for working with timers. Such tools as a means to work with timers needed for systems with stringent regulation time, so the development of tools to work with timers — necessary attribute of real time operating systems. These funds usually allow you to:

• measure and set various time intervals (from 1 microseconds and above),
• generate an interrupt at the end of the time intervals,
• create a one-time alarms and cyclic.

Here we describe only the basic, mandatory mechanisms used in the RTOS. In addition, almost every real time operating system has a set of additional, specific only for her arrangements concerning system IO, interrupt control, memory operations. Each system contains a number of tools to ensure its reliability.

2.5 Clocks and Timers

In RTOS uses different service time. The operating system keeps track of the current time, at a certain time runs tasks and threads and suspends them on regular intervals. In the time services are used RTOS real-time clock. Commonly used high-precision hardware clock. For reference time intervals based on real-time clock timers are created.

For each process and thread processing time determined by the clock. On the basis of these hours are timers that measure time overruns process or thread can dynamically detect software bugs or errors calculating the maximum possible runtime. In highly time-critical systems, it is important to identify situations in which the problem is greater than the maximum time of its execution, as with operation of the system may go beyond the acceptable response time. Watch runtime can detect the occurrence of over-time and activate the appropriate actions for handling errors.

Most RTOS operate with relative time. Something happens before and after some other event. In the system, a fully event-driven needs clockwork (ticker), because there is no time slicing. However, if you need timestamps for certain events or needs a system call type wait one second, you need a clock and/or timer.

Synchronization RTOS by means of locking mechanism (or wait) until the occurrence of some event. Absolute time is not used [4].

3. Features of debugging applications in real-time systems

Debugging real-time systems designed to detect and correct errors in the application code. It is one of the stages of the cross-development scheme which can be represented as follows. Developing an application is conducted on at least two machines: tool and target. On the tool platform occurs writing source code, compiling and assembling. On target — application download, test, and debug it.

Given that the target platform, as a rule, has more limited resources than instrumental, debugging distributed real-time systems can be of two types.

The first of these — imitation of the target platform architecture, that is the ability to debug the target software without the use of the platform. Such imitation usually precludes detailed and complete testing of the software. Therefore, this type of debugging applies only in the absence of the target platform.

The second way — Remote Debugging (cross-debugging). Cross-debugging tool allows to use the system when studying the behavior of a process on the target system.

Remote debugging efficiency depends on the type of communication tool and target machines, as well as support the debugging tools from the target architecture.

A key requirement is the ability to debug tools to observe and analyze the whole process of implementation of the tasks of debugging, as well as the system as a whole. In general, we can consider two methods of debugging active debugging and monitoring.

The essence of the active debugging is that the debugger has the right to stop the execution of a task or the entire system to start or continue to perform at a certain address other than the breakpoint, modify the values ​​of variables and registers, etc. The disadvantage of this method is that the debugger can make a serious disruption to the normal operation of the system in connection with the set time limits. This can be avoided by stopping certain group of tasks or the entire system. The advantage of this method is the ability to correct the behavior problems in the process of its implementation.

Monitoring is meant to collect data on the problem (register values​​, variables, etc.) or on the system as a whole (step tasks, current events, etc.).

Collect data helps pseudo-agent (set of instructions built into the task code). Usually it is added in the design phase. A simple example of a pseudo-agent — call assert, allows for a diagnosis of tasks.

In the process of monitoring the debugger almost lets the system, providing its normal funktsirovanie, but at the same time has no influence on the progress of the application being debugged [5].

Conclusions

Existing active debuggers play an important role in software development when searching logic errors, providing a wide range of means, including support for source code tracing application execution, dynamic modification of memory, etc. However, they do not allow the identification of specific errors of RTS.

Considered monitoring tools have similar methods of collection, processing and presentation of debugging data. Thanks to them, it is possible to localize the error of RTS associated with planning and synchronization.

References

1. Братуха М.А., Шевченко О.Г. Исследование точности отсчёта временных интервалов в системе Windows
2. Системы реального времени: учебно пособие — СПб.: Владикавказ, 2013. — 65 с.
3. Сорокин С. Системы реального времени // Современные технологии автоматизации. 1997. № 2.
4. Бурдонов И.Б., Косачев А.С., Пономаренко В.Н. Операционные системы реального времени [electronic resource]. — Access mode: http://citforum.ru/operating_systems/rtos/, free.
5. Костюхин К.А. Отладка систем реального времени [electronic resource]. — Access mode: http://citforum.ru/programming/digest/rtsdebug.shtml, free.
6. Операционная система реального времени / Материал из Википедии — свободной энциклопедии [electronic resource]. — Access mode: https://ru.wikipedia.org/wiki/Операционная_система_реального_времени, free.
7. ОСи реального времени / журнал Хакер [electronic resource]. — Access mode: http://www.xakep.ru/post/17912/, free.
8. Операционные системы реального времени (обзор) А.А. Блискавицкий, С.В. Кабаев, АО "РТСофт", Москва [electronic resource]. — Access mode: http://www.mka.ru/?p=40774, free.