Системы реального времени: аппаратное и программное обеспечение с временными ограничениями.

Введение

Изучение аппаратных и программных систем, имеющих ограничение по времени реального времени.

Вычисления в реальном времени (RTC) – это термин в информатике, обозначающий аппаратные и программные системы, подверженные ограничению по времени реального времени, например, время между событием и реакцией системы. Программы, работающие в реальном времени, должны гарантировать реакцию в пределах заданных временных ограничений, часто называемых «дедлайнами» (сроками). Термин «реальное время» также используется в моделировании для обозначения того, что системные часы идут с той же скоростью, что и реальные часы. Реакции в реальном времени обычно измеряются миллисекундами, а иногда и микросекундами. Система, не предназначенная для работы в реальном времени, обычно не может гарантировать реакцию в течение какого-либо определенного промежутка времени, хотя могут быть указаны типичные или ожидаемые времена отклика. Обработка в реальном времени считается неудачной, если она не завершена в пределах установленного дедлайна относительно события; дедлайны всегда должны соблюдаться, независимо от загрузки системы. Система реального времени описывается как система, которая «управляет окружением, получая данные, обрабатывая их и возвращая результаты достаточно быстро, чтобы оказать влияние на окружение в данный момент времени». Термин «реальное время» используется в системах управления процессами и корпоративных системах для обозначения «работы без значительной задержки». Программное обеспечение, работающее в реальном времени, может использовать один или несколько из следующих компонентов: синхронные языки программирования, операционные системы реального времени (RTOS) и сети реального времени, каждый из которых предоставляет основные платформы для разработки приложений реального времени. Системы, используемые во многих критически важных приложениях, должны работать в реальном времени, например, системы управления полетом самолета или антиблокировочные тормоза, которые требуют немедленного и точного механического отклика.

История

Термин "реальное время" возник из его использования в раннем моделировании, где процесс реального мира имитировался со скоростью, соответствующей скорости реального процесса (сейчас это называется моделированием в реальном времени, чтобы избежать неоднозначности). Аналоговые компьютеры, как правило, могли моделировать гораздо быстрее, чем в реальном времени, и такая ситуация могла быть столь же опасной, как и медленное моделирование, если это не было распознано и учтено. Миникомпьютеры, особенно начиная с 1970-х годов, при интеграции во встроенные системы, такие как сканеры DOG (цифровые графические дисплеи), повысили потребность в откликах с низкой задержкой и приоритетным обслуживанием важных взаимодействий с поступающими данными. Поэтому операционные системы, такие как RDOS (операционная система дисков реального времени) от Data General и RTOS с фоновым и передним планом планирования, а также RT 11 от Digital Equipment Corporation, относятся к этой эпохе. Планирование с разделением на передний и задний планы позволяло задачам с низким приоритетом использовать время процессора, когда задачи переднего плана не требовали выполнения, и обеспечивало абсолютный приоритет в пределах переднего плана потокам/задачам с наивысшим приоритетом. Операционные системы реального времени также использовались для организации совместного доступа нескольких пользователей. Например, Data General Business Basic мог работать на переднем или заднем плане RDOS и вносить дополнительные элементы в алгоритм планирования, чтобы сделать его более подходящим для пользователей, взаимодействующих через "глупые" терминалы. Когда MOS Technology 6502 (используемый в Commodore 64 и Apple II) и позже Motorola 68000 (используемый в Macintosh, Atari ST и Amiga) были популярны, любой мог использовать свой домашний компьютер как систему реального времени. Возможность отключения других прерываний позволяла использовать жестко заданные циклы с определенным временем выполнения, а низкая задержка прерываний позволяла реализовать операционную систему реального времени, при этом пользовательский интерфейс и дисководы имели более низкий приоритет, чем потоки реального времени. По сравнению с ними программируемый контроллер прерываний процессоров Intel (8086, 80586) генерирует очень большую задержку, а операционная система Windows не является операционной системой реального времени и не позволяет программе полностью захватить процессор и использовать свой собственный планировщик, не прибегая к машинному коду и, таким образом, обходя весь прерывающий код Windows. Однако существует несколько библиотек кодирования, которые предлагают возможности реального времени на языке высокого уровня в различных операционных системах, например, Java Real Time. Motorola 68000 и последующие модели семейства (68010, 68020 и т.д.) также стали популярны среди производителей промышленных систем управления. Эта область применения – одна из тех, в которой управление в реальном времени обеспечивает реальные преимущества с точки зрения производительности и безопасности процессов.

The term real time derives from its use in early simulation, in which a real world process is simulated at a rate that matched that of the real process (now called real time simulation to avoid ambiguity). Analog computers, most often, were capable of simulating at a much faster pace than real time, a situation that could be just as dangerous as a slow simulation if it were not also recognized and accounted for. Minicomputers, particularly in the 1970s onwards, when built into dedicated embedded systems such as DOG (Digital on screen graphic) scanners, increased the need for low latency priority driven responses to important interactions with incoming data and so operating systems such as Data General's RDOS (Real Time Disk Operating System) and RTOS with background and foreground scheduling as well as Digital Equipment Corporation's RT 11 date from this era. Background foreground scheduling allowed low priority tasks CPU time when no foreground task needed to execute, and gave absolute priority within the foreground to threads/tasks with the highest priority. Real time operating systems would also be used for time sharing multiuser duties. For example, Data General Business Basic could run in the foreground or background of RDOS and would introduce additional elements to the scheduling algorithm to make it more appropriate for people interacting via dumb terminals. Once when the MOS Technology 6502 (used in the Commodore 64 and Apple II), and later when the Motorola 68000 (used in the Macintosh, Atari ST, and Amiga) were popular, anybody could use their home computer as a real time system. The possibility to deactivate other interrupts allowed for hard coded loops with defined timing, and the low interrupt latency allowed the implementation of a real time operating system, giving the user interface and the disk drives lower priority than the real time thread. Compared to these the programmable interrupt controller of the Intel CPUs (8086 80586) generates a very large latency and the Windows operating system is neither a real time operating system nor does it allow a program to take over the CPU completely and use its own scheduler, without using native machine language and thus surpassing all interrupting Windows code. However, several coding libraries exist which offer real time capabilities in a high level language on a variety of operating systems, for example Java Real Time. The Motorola 68000 and subsequent family members (68010, 68020 etc.) also became popular with manufacturers of industrial control systems. This application area is one in which real time control offers genuine advantages in terms of process performance and safety.

Критерии вычислений в режиме реального времени

Система считается системой реального времени, если общая корректность операции зависит не только от ее логической корректности, но и от времени, в течение которого она выполняется. Системы реального времени, а также их сроки выполнения, классифицируются в зависимости от последствий пропуска срока:
Жесткие системы реального времени: пропуск срока приводит к полной неработоспособности системы. В системах с фиксированными сроками пропуски сроков допустимы нечасто, но могут снизить качество обслуживания. Полезность результата равна нулю после истечения срока его действия. В системах с мягкими сроками полезность результата снижается после истечения срока его действия, что также снижает качество обслуживания. Таким образом, целью жесткой системы реального времени является обеспечение соблюдения всех сроков, а для мягких систем реального времени целью становится соблюдение определенного подмножества сроков для оптимизации специфических критериев приложения. Конкретные критерии оптимизации зависят от приложения, но типичные примеры включают максимизацию количества выполненных сроков, минимизацию задержки задач и максимизацию количества задач с высоким приоритетом, выполняющихся в срок. Жесткие системы реального времени используются, когда необходимо реагировать на событие в строго определенный срок. Такие строгие гарантии требуются для систем, в которых отсутствие реакции в течение определенного промежутка времени может привести к значительным потерям, особенно к физическому повреждению окружающей среды или угрозе жизни людей (хотя строгое определение заключается в том, что пропуск срока является отказом системы). Некоторые примеры жестких систем реального времени:
Система управления двигателем автомобиля является жесткой системой реального времени, поскольку задержка сигнала может привести к отказу двигателя или его повреждению. Медицинские системы, такие как кардиостимуляторы. Несмотря на простоту задачи кардиостимулятора, из-за потенциального риска для жизни человека, такие медицинские системы обычно требуют тщательного тестирования и сертификации, что, в свою очередь, требует вычислений в реальном времени для предоставления доказуемых гарантий того, что отказ маловероятен или невозможен. Промышленные контроллеры, такие как станок на сборочной линии. Если станок задерживается, деталь на конвейере может оказаться вне зоны досягаемости станка (оставляя продукт необработанным), или станок или сам продукт могут быть повреждены из-за активации робота в неподходящий момент. В случае обнаружения неисправности, оба сценария приведут к остановке конвейера, что замедлит производство. Если неисправность не обнаружена, дефектный продукт может пройти через производственный процесс или вызвать повреждения на более поздних этапах. Жесткие системы реального времени обычно взаимодействуют на низком уровне с физическим оборудованием во встроенных системах. Ранние игровые системы, такие как Atari 2600 и Cinematronics с векторной графикой, имели жесткие требования к реальному времени из-за особенностей графики и синхронизирующего оборудования. Softmodems заменяют аппаратный модем программным обеспечением, работающим на центральном процессоре компьютера. Программное обеспечение должно выполняться каждые несколько миллисекунд для генерации следующих аудиоданных для вывода. Если эти данные поступают с задержкой, принимающий модем потеряет синхронизацию, что приведет к длительному прерыванию при восстановлении синхронизации или к полной потере соединения. Многие типы принтеров имеют жесткие требования к реальному времени, такие как струйные принтеры (чернила должны быть нанесены в нужный момент, когда печатающая головка пересекает страницу), лазерные принтеры (лазер должен быть активирован в нужный момент, когда луч сканирует вращающийся барабан), и матричные и различные типы линейных принтеров (ударный механизм должен быть активирован в нужный момент, когда печатающий механизм выравнивается с желаемым результатом). Отказ в любом из этих случаев приведет к отсутствию вывода или искаженному выводу. В контексте многозадачных систем политика планирования обычно основана на приоритетах (прерывающие планировщики). В некоторых ситуациях они могут гарантировать производительность жесткого реального времени (например, если набор задач и их приоритеты известны заранее). Существуют и другие планировщики жесткого реального времени, такие как Rate Monotonic, которые не распространены в системах общего назначения, поскольку для планирования задачи требуется дополнительная информация: а именно, оценка верхней границы или наихудшего случая времени выполнения задачи. Существуют конкретные алгоритмы для планирования таких задач жесткого реального времени, как Earliest Deadline First, который, не учитывая накладные расходы на переключение контекста, достаточен для системной нагрузки менее 100%. Новые системы накладного планирования, такие как адаптивный планировщик разделов, помогают управлять большими системами со смесью задач жесткого и не жесткого реального времени. Системы с фиксированными сроками реального времени определены менее четко, и некоторые классификации не включают их, различая только жесткие и мягкие системы реального времени. Некоторые примеры систем с фиксированными сроками реального времени:
Станок на сборочной линии, описанный ранее как жесткая система реального времени, может вместо этого рассматриваться как система с фиксированными сроками. Пропуск срока все равно вызывает ошибку, которую необходимо устранить: может быть оборудование для маркировки детали как бракованной или ее выброса с конвейера, или конвейер может быть остановлен, чтобы оператор мог исправить проблему. Однако, если эти ошибки возникают нечасто, они могут быть допустимы. Системы мягкого реального времени обычно используются для решения проблем одновременного доступа и необходимости поддержания актуальности нескольких подключенных систем в меняющихся ситуациях. Некоторые примеры систем мягкого реального времени:
Программное обеспечение, которое поддерживает и обновляет планы полетов для коммерческих авиалайнеров. Планы полетов должны поддерживаться в актуальном состоянии, но они могут работать с задержкой в несколько секунд. Системы живого аудио- и видеопотока также обычно являются системами мягкого реального времени. Поздняя передача аудиокадра может вызвать кратковременный сбой в звуке (и может привести к задержке всего последующего звука, создавая впечатление, что звук воспроизводится медленнее, чем обычно), но это может быть лучше, чем альтернативы: продолжение воспроизведения тишины, статического шума, предыдущего аудиокадра или оценочных данных. Задержка видеокадра обычно вызывает еще меньше проблем для зрителей. Система может продолжать работать и восстанавливаться в будущем, используя методы прогнозирования нагрузки и реконфигурации. Аналогично, видеоигры часто являются системами мягкого реального времени, особенно когда они пытаются достичь целевой частоты кадров. Поскольку следующее изображение не может быть вычислено заранее, поскольку оно зависит от ввода данных игрока, доступно лишь короткое время для выполнения всех вычислений, необходимых для генерации кадра видео, прежде чем этот кадр должен быть отображен. Если срок не соблюдается, игра может продолжаться с более низкой частотой кадров; в зависимости от игры это может повлиять только на ее графику (в то время как игровой процесс продолжается с нормальной скоростью), или игровой процесс также может быть замедлен (что было распространено на консолях третьего и четвертого поколений).

A system is said to be real time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. Real time systems, as well as their deadlines, are classified by the consequence of missing a deadline:
Hard missing a deadline is a total system failure. Firm infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline. Soft the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service. Thus, the goal of a hard real time system is to ensure that all deadlines are met, but for soft real time systems the goal becomes meeting a certain subset of deadlines in order to optimize some application specific criteria. The particular criteria optimized depend on the application, but some typical examples include maximizing the number of deadlines met, minimizing the lateness of tasks and maximizing the number of high priority tasks meeting their deadlines. Hard real time systems are used when it is imperative that an event be reacted to within a strict deadline. Such strong guarantees are required of systems for which not reacting in a certain interval of time would cause great loss in some manner, especially damaging the surroundings physically or threatening human lives (although the strict definition is simply that missing the deadline constitutes failure of the system). Some examples of hard real time systems:
A car engine control system is a hard real time system because a delayed signal may cause engine failure or damage. Medical systems such as heart pacemakers. Even though a pacemaker's task is simple, because of the potential risk to human life, medical systems like these are typically required to undergo thorough testing and certification, which in turn requires hard real time computing in order to offer provable guarantees that a failure is unlikely or impossible. Industrial process controllers, such as a machine on an assembly line. If the machine is delayed, the item on the assembly line could pass beyond the reach of the machine (leaving the product untouched), or the machine or the product could be damaged by activating the robot at the wrong time. If the failure is detected, both cases would lead to the assembly line stopping, which slows production. If the failure is not detected, a product with a defect could make it through production, or could cause damage in later steps of production. Hard real time systems are typically found interacting at a low level with physical hardware, in embedded systems. Early video game systems such as the Atari 2600 and Cinematronics vector graphics had hard real time requirements because of the nature of the graphics and timing hardware. Softmodems replace a hardware modem with software running on a computer's CPU. The software must run every few milliseconds to generate the next audio data to be output. If that data is late, the receiving modem will lose synchronization, causing a long interruption as synchronization is reestablished or causing the connection to be lost entirely. Many types of printers have hard real time requirements, such as inkjets (the ink must be deposited at the correct time as the printhead crosses the page), laser printers (the laser must be activated at the right time as the beam scans across the rotating drum), and dot matrix and various types of line printers (the impact mechanism must be activated at the right time as the print mechanism comes into alignment with the desired output). A failure in any of these would cause either missing output or misaligned output. In the context of multitasking systems the scheduling policy is normally priority driven (pre emptive schedulers). In some situations, these can guarantee hard real time performance (for instance if the set of tasks and their priorities is known in advance). There are other hard real time schedulers such as rate monotonic which is not common in general purpose systems, as it requires additional information in order to schedule a task: namely a bound or worst case estimate for how long the task must execute. Specific algorithms for scheduling such hard real time tasks exist, such as earliest deadline first, which, ignoring the overhead of context switching, is sufficient for system loads of less than 100%. New overlay scheduling systems, such as an adaptive partition scheduler assist in managing large systems with a mixture of hard real time and non real time applications. Firm real time systems are more nebulously defined, and some classifications do not include them, distinguishing only hard and soft real time systems. Some examples of firm real time systems:
The assembly line machine described earlier as hard real time could instead be considered firm real time. A missed deadline still causes an error which needs to be dealt with: there might be machinery to mark a part as bad or eject it from the assembly line, or the assembly line could be stopped so an operator can correct the problem. However, as long as these errors are infrequent, they may be tolerated. Soft real time systems are typically used to solve issues of concurrent access and the need to keep a number of connected systems up to date through changing situations. Some examples of soft real time systems:
Software that maintains and updates the flight plans for commercial airliners. The flight plans must be kept reasonably current, but they can operate with the latency of a few seconds. Live audio video systems are also usually soft real time. A frame of audio that is played late may cause a brief audio glitch (and may cause all subsequent audio to be delayed correspondingly, causing a perception that the audio is being played slower than normal), but this may be better than the alternatives of continuing to play silence, static, a previous audio frame, or estimated data. A frame of video that is delayed typically causes even less disruption for viewers. The system can continue to operate and also recover in the future using workload prediction and reconfiguration methodologies. Similarly, video games are often soft real time, particularly as they try to meet a target frame rate. As the next image cannot be computed in advance, since it depends on inputs from the player, only a short time is available to perform all the computing needed to generate a frame of video before that frame must be displayed. If the deadline is missed, the game can continue at a lower frame rate; depending on the game, this may only affect its graphics (while the gameplay continues at normal speed), or the gameplay itself may be slowed down (which was common on older third and fourth generation consoles).

Реальное время в цифровой обработке сигналов

В процессе цифровой обработки сигналов (DSP) в реальном времени, анализируемые (входные) и генерируемые (выходные) отсчеты могут обрабатываться (или генерироваться) непрерывно за время, необходимое для ввода и вывода одного и того же набора отсчетов, независимо от задержки обработки. Это означает, что задержка обработки должна быть ограничена, даже если обработка продолжается неограниченно долго. Следовательно, среднее время обработки одного отсчета, включая накладные расходы, не должно превышать период дискретизации, который является величиной, обратной частоте дискретизации. Это является критерием, определяющим, группируются ли отсчеты в большие сегменты и обрабатываются блоками, или обрабатываются по отдельности, а также наличие длинных, коротких или отсутствующих входных и выходных буферов. Рассмотрим пример аудио DSP: если для анализа, синтеза или обработки 2,00 секунд звука требуется 2,01 секунды, то это не обработка в реальном времени. Однако, если это занимает 1,99 секунды, то это является обработкой в реальном времени или может быть реализовано как таковая. Распространенная аналогия из жизни – ожидание в очереди на кассу в продуктовом магазине. Если очередь асимптотически растет без ограничений, то процесс обслуживания не является реальным временем. Если длина очереди ограничена, клиенты "обрабатываются" и выдаются, в среднем, так же быстро, как и поступают, то этот процесс происходит в реальном времени. Продавец может обанкротиться или, по крайней мере, потерять клиентов, если не сможет обеспечить обработку в реальном времени; поэтому принципиально важно, чтобы этот процесс был реализован в реальном времени. Алгоритм обработки сигналов, который не успевает за потоком входных данных, при этом выход все больше отстает от входа, не является алгоритмом реального времени. Но если задержка выхода (относительно входа) ограничена для процесса, работающего неограниченно долго, то этот алгоритм обработки сигналов является алгоритмом реального времени, даже если задержка пропускной способности может быть значительной.

Живое и реальное время

Обработка сигнала в реальном времени необходима, но сама по себе недостаточна для живой обработки сигнала, как это требуется при поддержке прямых трансляций и мероприятий. Живая цифровая обработка сигнала требует как работы в реальном времени, так и достаточного ограничения задержки передачи, чтобы она была приемлема для исполнителей, использующих сценические или внутриканальные мониторы, и незаметна для зрителей как рассинхронизация звука и изображения. Допустимые пределы задержки для живой обработки в реальном времени являются предметом исследований и обсуждений, но оцениваются в пределах от 6 до 20 миллисекунд. Двунаправленные телекоммуникационные задержки в реальном времени менее 300 мс ("время туда и обратно", или вдвое больше однонаправленной задержки) считаются "приемлемыми", чтобы избежать нежелательных перебиваний в разговоре.

Реальное время и высокая производительность

Иногда вычисления в реальном времени ошибочно принимают за высокопроизводительные вычисления, но это неверная классификация. Например, мощный суперкомпьютер, выполняющий научное моделирование, может демонстрировать впечатляющую производительность, однако он не выполняет вычисления в реальном времени. И наоборот, как только аппаратное и программное обеспечение антиблокировочной системы тормозов спроектированы для соблюдения требуемых сроков, дальнейшее повышение производительности не является обязательным и даже полезным. Более того, если сетевой сервер сильно загружен сетевым трафиком, его время отклика может увеличиться, но (в большинстве случаев) он все равно успеет выполнить задачу до истечения времени ожидания (достижения крайнего срока). Следовательно, такой сетевой сервер нельзя считать системой реального времени: временные сбои (задержки, таймауты и т. д.) обычно незначительны и локализованы (ограничены по воздействию), но не являются критическими. В системе реального времени, такой как индекс FTSE 100, превышение допустимых временных рамок часто считается катастрофическим в контексте ее применения. Наиболее важным требованием к системе реального времени является стабильный результат, а не высокая пропускная способность. Некоторые виды программного обеспечения, например многие шахматные программы, могут относиться к любой из этих категорий. Например, шахматная программа, предназначенная для игры в турнире с таймером, должна определить ход до определенного срока, иначе она проиграет, и поэтому представляет собой вычисление в реальном времени, в то время как шахматная программа, которой разрешено работать неограниченно долго перед ходом, таковым не является. В обоих случаях, однако, высокая производительность желательна: чем больше работы турнирная шахматная программа может выполнить за отведенное время, тем лучше будут ее ходы, и чем быстрее работает шахматная программа без ограничений, тем быстрее она сможет сделать ход. Этот пример также иллюстрирует существенное различие между вычислениями в реальном времени и другими вычислениями: если турнирная шахматная программа не примет решение о следующем ходе в отведенное время, она проиграет партию, то есть потерпит неудачу как вычисление в реальном времени, в то время как в другом сценарии соблюдение сроков не считается необходимым. Высокая производительность характеризует объем обработки, выполняемой за определенный период времени, в то время как реальное время – это способность завершить обработку и получить полезный результат в доступное время.

Real time computing is sometimes misunderstood to be high performance computing, but this is not an accurate classification. For example, a massive supercomputer executing a scientific simulation may offer impressive performance, yet it is not executing a real time computation. Conversely, once the hardware and software for an anti lock braking system have been designed to meet its required deadlines, no further performance gains are obligatory or even useful. Furthermore, if a network server is highly loaded with network traffic, its response time may be slower but will (in most cases) still succeed before it times out (hits its deadline). Hence, such a network server would not be considered a real time system: temporal failures (delays, time outs, etc.) are typically small and compartmentalized (limited in effect) but are not catastrophic failures. In a real time system, such as the FTSE 100 Index, a slow down beyond limits would often be considered catastrophic in its application context. The most important requirement of a real time system is consistent output, not high throughput. Some kinds of software, such as many chess playing programs, can fall into either category. For instance, a chess program designed to play in a tournament with a clock will need to decide on a move before a certain deadline or lose the game, and is therefore a real time computation, but a chess program that is allowed to run indefinitely before moving is not. In both of these cases, however, high performance is desirable: the more work a tournament chess program can do in the allotted time, the better its moves will be, and the faster an unconstrained chess program runs, the sooner it will be able to move. This example also illustrates the essential difference between real time computations and other computations: if the tournament chess program does not make a decision about its next move in its allotted time it loses the game—i. e., it fails as a real time computation—while in the other scenario, meeting the deadline is assumed not to be necessary. High performance is indicative of the amount of processing that is performed in a given amount of time, whereas real time is the ability to get done with the processing to yield a useful output in the available time.

Почти в реальном времени

Термин "почти реальное время" (NRT) в телекоммуникациях и вычислительной технике обозначает временную задержку, вносимую автоматизированной обработкой данных или сетевой передачей между моментом возникновения события и моментом использования обработанных данных, например, для отображения, обратной связи или управления. Например, отображение в почти реальном времени показывает событие или ситуацию такой, какой она была в текущий момент времени за вычетом времени обработки, максимально приближенно к моменту события в реальном времени. Разграничение между терминами "почти реальное время" и "реальное время" достаточно размыто и должно определяться в каждом конкретном случае. Термин подразумевает отсутствие значительных задержек. Во многих случаях обработка, описываемая как "реальное время", точнее была бы названа "почти реальным временем". "Почти реальное время" также относится к задержке при передаче голоса и видео. Это позволяет воспроизводить видеоизображения практически в реальном времени, не дожидаясь полной загрузки большого видеофайла. Несовместимые базы данных могут экспортировать и импортировать данные в общие плоские файлы, которые другая база данных может импортировать и экспортировать по расписанию, чтобы синхронизировать и обмениваться общими данными друг с другом в "почти реальном времени".

Методы проектирования

Существует несколько методов, облегчающих разработку систем реального времени, одним из которых является MASCOT – старый, но весьма эффективный метод, представляющий собой конкурентную структуру системы. Среди других примеров можно назвать HOOD, Real Time UML, AADL, профиль Ravenscar и Real Time Java.