Как коммуникационное промежуточное ПО может поддерживать программные приложения реального времени?

Question

В настоящее время понятие "в реальном времени" имеет много разных толкований. В этом вопросе даны два определения:

Жесткое определение в реальном времени рассматривает любой пропущенный срок как системный сбой. Это планирование широко используется в критически важных системах, где несоблюдение временных ограничений приводит к потере жизни или имущества.

а также

Мягкое определение в реальном времени учитывает часто пропущенные сроки, и пока задачи выполняются своевременно, их результаты продолжают иметь значение. Завершенные задачи могут иметь возрастающую ценность до истечения срока и снижающуюся стоимость после него.

В своем исследовании я пришел к следующим выводам:

• Промежуточное программное обеспечение поддерживает жесткий режим реального времени, если оно обеспечивает предсказуемый и эффективный сквозной контроль над системными ресурсами. Как установка приоритета всех потоков, созданных промежуточным программным обеспечением.
• Мне кажется, что хорошая производительность является наиболее важным фактором для поддержки программ в реальном времени.

Это правда? Существуют ли другие соответствующие функции коммуникационного промежуточного программного обеспечения, которые поддерживают программные приложения реального времени?

Answer 1

Во-первых, для точного определения принципов и терминов в реальном времени, основанных на первых принципах и ментальных моделях, я отсылаю вас к real-time.org.

Вычислительное сообщество практиков в реальном времени использует множество непоследовательных и неполных "определений" "реального времени","жесткого реального времени" и "мягкого реального времени". Сообщество исследователей компьютерных вычислений в режиме реального времени имеет консенсус по поводу "жесткого реального времени", но не понимает "мягкого реального времени".

Суть "жесткой" вычислительной модели реального времени исследовательского сообщества состоит в том, что задачи имеют жесткие сроки, и все эти сроки должны быть пропущены, в противном случае система выйдет из строя. Соблюдение сроков является критерием "своевременности", а гарантия того, что все сроки будут соблюдены, является критерием "предсказуемости" - что предсказуемость является "детерминированной".

(В некоторых из этих моделей задачи без сроков допускаются в фоновом режиме, если они не мешают выполнению сложных задач в реальном времени; обычно они также предотвращаются от голода.)

Эта модель требует, чтобы все, что связано с трудными задачами реального времени, было статичным (известно заранее), т. Е. Требуется, чтобы эволюция системы во времени была известна заранее. Это требование очень строгое, и в большинстве случаев оно неосуществимо. Существуют важные жесткие системы реального времени, в которых это требование (по крайней мере предполагается) должно быть выполнено. Хорошо известные примеры включают управление полетом цифровой авионики, некоторые медицинские приборы, управление электростанциями, управление железнодорожными переездами и т. Д. Эти примеры являются критически важными для безопасности, но не все жесткие системы реального времени (и мы увидим ниже, что большинство критические системы не являются и не могут быть жесткими в режиме реального времени, хотя некоторые могут включать простые низкоуровневые жесткие компоненты реального времени).

Мягкое реальное время относится к классу систем реального времени, которые являются обобщениями жестких систем реального времени. Обобщения включали более слабые критерии своевременности и / или более слабые критерии предсказуемости.

Например, рассмотрим модель с задачами, имеющими сроки, как это делают сложные задачи в реальном времени. В этой конкретной модели критерий своевременности состоит в том, что любое количество задач может быть запоздалым до 15%, а критерий предсказуемости - это то, что это должно быть гарантировано (то есть детерминировано), как и для жестких систем реального времени. Если одна или несколько из этих задач запаздывают более чем на 15%, система вышла из строя. Эта модель не является обычной жесткой в ​​режиме реального времени, хотя она может быть критичной для безопасности.

Рассмотрим другую модель: критерий своевременности состоит в том, что не более 20% задач может быть запоздалым более чем на 5%, а критерий предсказуемости заключается в том, что он гарантированно будет удовлетворен с вероятностью не менее 0,9. Нарушение критериев своевременности и / или предсказуемости означает, что система вышла из строя. Это не жесткая система реального времени, хотя она может быть критичной для безопасности.

Но подумайте: что, если полезность этой системы ухудшается в соответствии с несоответствием одному или любому из этих критериев - скажем, 23% были более 5% запоздалыми, или менее 20% задач были запоздалыми, но 10% из них были запоздалыми более 5%, или все критерии были выполнены, за исключением того, что предсказуемость составляет всего 0,8. Существует много систем реального времени, обладающих такими динамическими свойствами.

Нам нужно указать, как эта деградация системы (скажем,"полезность" или "ценность" системы) связана с тем, сколько и в какой степени любой из этих критериев своевременности и предсказуемости был или не был выполнен. Фактически, эта модель является условным примером многих существующих существующих систем реального времени, которые настолько критичны для безопасности, насколько это возможно, например, для защиты от ядерных вооруженных вражеских ракет (и многих других военных боевых систем, поскольку все они имеют различные присущие динамические неопределенности).

Теперь вернемся к этой необходимости, чтобы указать, как своевременность и предсказуемость системы в реальном времени связаны с ее полезностью. Успешно используемое решение для этого называется "функциями времени / полезности" (или "функциями времени / значения") и подробно описано на real-time.org. Функции для каждой задачи вытекают из физической природы системных приложений. Своевременность и предсказуемость своевременности системы основаны на задачах, например, путем взвешенного начисления их индивидуальных утилит.

Мягкие системы реального времени (в точно определенном смысле, описанном на real-time.org) являются общим случаем, а жесткие системы реального времени - частным случаем, который применяется к гораздо меньшей области задач реального времени. Все жесткие и мягкие системы реального времени могут быть определены и созданы с помощью функций времени / полезности.

Все, что прояснилось, теперь мы можем ответить на ваш вопрос о промежуточном программном обеспечении в реальном времени.

Одним из очевидных источников ответа является стандарт CORBA в реальном времени (RTC) для открытых групп (Google, существует БОЛЬШАЯ подробная информация).

RTC может быть реализован как инфраструктура с фиксированным приоритетом с 15-разрядным общесистемным приоритетом, который отображается на приоритеты узла. В этом случае минимальными требованиями являются: соблюдение приоритетов потоков между клиентом и сервером для разрешения конфликта ресурсов во время обработки вызовов CORBA; ограничение продолжительности инверсий приоритетов потоков во время сквозной обработки; ограничение задержек вызовов операций. Можно построить жесткие распределенные системы RTC в реальном времени в соответствии с этими тремя требованиями (и многие из них существуют), но очевидно, что базовое QoS сети влияет на поведение в реальном времени. Таким образом, RTC обеспечивает подключаемые специализированные сети, такие как те, которые имеют детерминированное QoS (так что жесткий уровень реального времени возможен на уровнях RTC и ниже), и те, которые имеют недетерминированное QoS (но все же уровни RTC имеют три основных фиксированных приоритетные свойства в реальном времени).

В более общем смысле, RTC обеспечивает мягкое в реальном времени (в техническом смысле, определенном на real-time.org) на уровнях CORBA. Это достигается путем предоставления абстракции планирования первого порядка, называемой "распределенными потоками". И это обеспечивает структуру планирования, которая поддерживает не только фиксированные приоритеты, но также функции времени / полезности, которые являются достаточно общими, чтобы выразить очень общий класс "накапливающихся" алгоритмов мягкого планирования в реальном времени. Такие алгоритмы (или обычно эвристика) необходимы для распределенных систем, состоящих из программных моделей в реальном времени для конкретных приложений, таких как я описал выше.

Что делать, если вы не хотите использовать RTC? Хорошая новость заключается в том, что принципы RTC впервые появились публично в другой распределенной системе реального времени (описанной на real-time.org) и могут (и были) перенесены на другое промежуточное программное обеспечение реального времени как для жесткого, так и для мягкого реального времени. системы времени.

Для мягкого промежуточного программного обеспечения реального времени (опять же, в точно определенном смысле из real-time.org) принципы динамической своевременности и предсказуемости своевременности должны применяться к управлению ресурсами на каждом узле системы промежуточного программного обеспечения, включая применение к планирование сети промежуточного программного обеспечения (например, доступ, маршрутизация и т. д.). Примеры этого подхода появляются в нескольких Ph.D. тезисы, а также были реализованы в ряде боевых распределенных систем реального времени.