Различия между жестким в реальном времени, мягким в реальном времени и устойчивым в реальном времени?
Я прочитал определения для различных понятий реального времени, и примеры, представленные для жестких и мягких систем реального времени, имеют для меня смысл. Но нет никакого реального объяснения или примера надежной системы реального времени. По ссылке выше:
Фирма: нерегулярные пропуски сроков допустимы, но могут ухудшить качество обслуживания системы. Полезность результата равна нулю после его крайнего срока.
Есть ли четкое различие между твердым в реальном времени и жестким или мягким в реальном времени, и есть ли хороший пример, который иллюстрирует это различие?
В комментариях Чарльз попросил, чтобы я отправил вики-теги для новых тегов. Примером "фирменной системы реального времени", которую я привел для фирменного ярлыка реального времени, была система подачи молока. Если система доставляет молоко после истечения срока годности, то молоко считается "бесполезным". Можно есть зерновые без молока, но качество опыта ухудшается.
Это просто идея, которая возникла у меня в голове, когда я сначала прочитал определение. Я ищу гораздо лучший пример и, возможно, лучшее определение фирмы в реальном времени, которое улучшит мое представление об этом.
12 ответов
Тяжелая работа в режиме реального времени означает, что вы обязательно должны соблюдать каждый срок Очень немногие системы имеют это требование. Некоторыми примерами являются ядерные системы, некоторые медицинские приложения, такие как кардиостимуляторы, большое количество приложений для защиты, авионика и т. Д.
Фирмы / мягкие системы реального времени могут пропустить некоторые сроки, но в конечном итоге производительность будет ухудшаться, если пропущено слишком много. Хорошим примером является звуковая система на вашем компьютере. Если вы пропустите несколько битов, ничего страшного, но пропустите слишком много, и вы в конечном итоге ухудшите систему. Похоже были бы сейсмические датчики. Если вы пропустите несколько точек данных, ничего страшного, но вы должны поймать большинство из них, чтобы разобраться в данных. Что еще более важно, никто не умрет, если они не будут работать правильно.
Линия нечеткая, потому что даже кардиостимулятор может быть отключен небольшим количеством, не убивая пациента, но это общая суть.
Это как разница между горячим и теплым. Там нет реального разрыва, но вы знаете это, когда вы чувствуете это.
Жесткий в реальном времени
Жесткое определение в реальном времени рассматривает любой пропущенный срок как системный сбой. Это планирование широко используется в критически важных системах, где несоблюдение временных ограничений приводит к потере жизни или имущества.
Примеры:
Рейс 447 Air France потерпел крушение в океане после сбоя датчика, вызвавшего ряд системных ошибок. Пилоты заглохли в самолете, отвечая на устаревшие показания приборов. Все 12 членов экипажа и 216 пассажиров погибли.
Космический аппарат Mars Pathfinder был почти потерян, когда перестановка приоритетов вызвала перезапуск системы. Задача с более высоким приоритетом не была выполнена вовремя из-за блокировки задачи с более низким приоритетом. Проблема была исправлена, и корабль успешно приземлился.
Струйный принтер имеет печатающую головку с управляющим программным обеспечением для нанесения необходимого количества чернил на определенную часть бумаги. Если крайний срок пропущен, то задание на печать разрушается.
Фирма в режиме реального времени
Точное определение в реальном времени учитывает редко пропущенные сроки. В этих приложениях система может пережить сбои задачи, если они находятся на достаточном расстоянии друг от друга, однако значение завершения задачи падает до нуля или становится невозможным.
Примеры:
Производство систем с роботизированными сборочными линиями, где несоблюдение сроков приводит к неправильной сборке детали. Пока разрушенные детали встречаются достаточно редко, чтобы их можно было контролировать с помощью контроля качества, и при этом они не слишком дороги, производство продолжается.
Цифровая кабельная телевизионная приставка декодирует метки времени, когда кадры должны появляться на экране. Поскольку кадры чувствительны к временному порядку, пропущенный срок вызывает дрожание, что снижает качество обслуживания. Если пропущенный кадр станет доступен позже, это вызовет больше дрожания, поэтому он бесполезен. Зритель все еще может наслаждаться программой, если дрожание не происходит слишком часто.
Soft Real-Time
Мягкое определение в реальном времени учитывает часто пропущенные сроки, и пока задачи выполняются своевременно, их результаты продолжают иметь значение. Завершенные задачи могут иметь возрастающую ценность до истечения срока и снижающуюся стоимость после него.
Примеры:
Метеостанции имеют много датчиков для считывания температуры, влажности, скорости ветра и т. Д. Показания следует снимать и передавать через регулярные промежутки времени, однако датчики не синхронизированы. Даже если показание датчика может быть ранним или поздним по сравнению с другими, оно все равно может быть актуальным, если оно достаточно близко.
Консоль видеоигры запускает программное обеспечение для игрового движка. Есть много ресурсов, которые должны быть распределены между его задачами. В то же время задачи должны быть выполнены в соответствии с графиком для игры, чтобы играть правильно. Пока задачи выполняются относительно относительно вовремя, игра будет приятной, а если нет, то может немного отставать.
Siewert: встроенные системы и компоненты реального времени.
Liu & Layland: Алгоритмы планирования мультипрограммирования в жестких условиях реального времени.
Marchand & Silly-Chetto: динамическое планирование мягких апериодических задач и периодических задач с пропусками.
После прочтения страницы Википедии и других страниц по вычислениям в реальном времени. Я сделал следующие выводы:
1> Для жесткой системы реального времени, если система не может уложиться в срок, даже если считается, что в системе произошел сбой.
2> Для устойчивой системы реального времени, даже если система не может уложиться в срок, возможно, более одного раза (то есть для нескольких запросов), система не считается сбойной. Кроме того, ответы на запросы (ответы на запрос, результат задачи и т. Д.) Становятся бесполезными после истечения крайнего срока для этого конкретного запроса (полезность результата равна нулю после его крайнего срока). Гипотетическим примером может служить система прогнозирования шторма (если шторм прогнозируется до прибытия, то система выполнила свою работу, прогнозирование после того, как событие уже произошло или когда оно происходит, не имеет значения).
3> Для мягкой системы реального времени, даже если система не может уложиться в срок, возможно, более одного раза (то есть для нескольких запросов), система не считается сбойной. Но в этом случае результаты запросов не являются бесполезной ценностью, поскольку результат после его крайнего срока не равен нулю, а скорее ухудшается с течением времени после крайнего срока. Например: потоковое аудио-видео.
Вот ссылка на ресурс, который был очень полезен.
Самый простой способ различить различные типы типов систем реального времени - это ответить на вопрос:
Отложенный ответ системы (после истечения срока) все еще полезен или нет?
Таким образом, в зависимости от ответа, который вы получите на этот вопрос, ваша система может быть включена в одну из следующих категорий:
- Жесткий: Нет, и отложенные ответы считаются системным отказом
Это тот случай, когда пропущенный крайний срок сделает систему непригодной для использования. Например, система, управляющая автомобильной системой подушек безопасности, должна обнаруживать столкновение и быстро надувать мешок. Весь процесс занимает более или менее одну двадцать пятую секунды. Таким образом, если система реагирует, например, с задержкой в 1 секунду, последствия могут быть смертельными, и разгрузка мешка не будет выгодна после того, как автомобиль уже разбился.
- Фирма: нет, но отсроченные ответы не нужны при сбое системы
Это тот случай, когда несоблюдение установленного срока допустимо, но это повлияет на качество обслуживания. В качестве простого примера рассмотрим систему шифрования видео. Обычно пароль шифрования генерируется на сервере (видео головное устройство) и отправляется в абонентскую приставку. Этот процесс должен быть синхронизирован, поэтому обычно приставка получает пароль перед началом приема зашифрованных видеокадров. В этом случае задержка может привести к сбоям в работе видео, поскольку приставка не может декодировать кадры, поскольку еще не получила пароль. В этом случае обслуживание (фильм, интересный футбольный матч и т. Д.) Может зависеть от несоблюдения установленного срока. Получение пароля с задержкой в этом случае бесполезно, так как кадры, зашифрованные с тем же самым, уже вызвали сбои.
- Софт: Да, но системный сервис ухудшен
Начиная с описания в Википедии, полезность результата снижается после истечения его срока. Это означает, что получение ответа от системы в установленные сроки все еще полезно для конечного пользователя, но его полезность снижается после достижения указанного срока. Простым примером для этого случая является программное обеспечение, которое автоматически контролирует температуру в помещении (или здании). В этом случае, если система имеет некоторые задержки при считывании датчиков температуры, она будет немного медленнее реагировать на резкие изменения температуры. Однако, в конце концов, он в конечном итоге отреагирует на изменение и, соответственно, отрегулирует температуру для поддержания ее постоянной. Так что в этом случае задержанная реакция полезна, но ухудшает качество обслуживания системы.
Популярно связывать какую-то великую катастрофу с определением жесткого реального времени, но это не имеет значения. Любая неспособность выполнить жесткие ограничения в реальном времени просто означает, что система сломана. Серьезность результата, когда что-то помечено как "сломанное", не является существенной для определения.
Твердые и мягкие просто не могут быть автоматически объявлены нарушенными при несоблюдении единого срока.
Яркий пример жесткого реального времени со страницы, на которую вы ссылаетесь:
Ранние системы видеоигр, такие как Atari 2600 и векторная графика Cinematronics, предъявляли жесткие требования в реальном времени из-за природы графики и оборудования для синхронизации.
Если что-то в цикле генерации видео пропустит только один крайний срок, тогда весь дисплей будет зависать, что было бы невыносимо, даже если это было редко. Это будет сломанная система, и вы возьмете ее обратно в магазин за возмещением. Так что это сложно в режиме реального времени.
Очевидно, что любая система может быть подвержена ситуациям, с которыми она не может справиться, поэтому необходимо ограничить определение нахождением в ожидаемых условиях эксплуатации, отмечая, что в критических для безопасности приложениях люди должны планировать ужасные условия ("охлаждающая жидкость испарилась", "" тормоза вышли из строя ", но редко" солнце взорвалось ").
И давайте не будем забывать, что иногда существует неявное "пока кто-то наблюдает" рабочее состояние. Если никто не видит, что вы нарушаете правила (или если они это сделали, но они умирают в огне, прежде чем говорить кому-либо), и никто не может доказать, что вы нарушили правила по факту, то это похоже на то, как если бы вы никогда не нарушали правила!
Чтобы определить "мягкое в реальном времени", проще всего сравнить его с "жестким в реальном времени". Ниже мы увидим, что термин "фирма в реальном времени" представляет собой недоразумение о "мягком режиме реального времени".
Говоря небрежно, большинство людей неявно имеют неформальную ментальную модель, которая рассматривает информацию или событие как "в реальном времени"
• если или в той степени, в которой это проявляется для них с задержкой (задержкой), которая может быть связана с его предполагаемой валютой
• т. Е. В тот период времени, когда информация или событие имеют для них приемлемо удовлетворительное значение.
Существует множество различных специальных определений "жесткого реального времени", но в этой ментальной модели жесткое реальное время представлено термином "если". В частности, если предположить, что действия в реальном времени (например, задачи) имеют крайние сроки завершения, приемлемо удовлетворительное значение события, когда все задачи выполнены, ограничивается особым случаем, когда все задачи соответствуют их срокам.
Жесткие системы реального времени делают очень сильные предположения о том, что все в приложении, системе и среде статично и известно априори - например, какие задачи, периодичность, время прибытия, периоды, сроки выполнения, которые они выиграли не имеют конфликты ресурсов, и в целом время эволюции системы. В системе управления полетом самолета или в автомобильной тормозной системе и во многих других случаях эти предположения обычно могут быть соблюдены, так что все сроки будут соблюдены.
Эта ментальная модель преднамеренно и очень полезна достаточно обобщенно, чтобы охватить как жесткое, так и мягкое реальное время - мягкое воспринимается фразой "до такой степени". Например, предположим, что событие завершения задачи имеет неоптимальное, но приемлемое значение, если
- не более 10% задач не укладываются в сроки
- или нет задачи более 20%
- или среднее опоздание всех заданий не более 15%
- или максимальное опоздание среди всех задач составляет менее 10%
Все это типичные примеры мягких кейсов в реальном времени во многих приложениях.
Рассмотрим одно задание: забрать ребенка после школы. Это, вероятно, не имеет фактического срока, вместо этого есть некоторая ценность для вас и вашего ребенка, основанная на том, когда это событие происходит. Слишком ранняя трата ресурсов (таких как ваше время) и слишком поздно имеют какую-то негативную ценность, потому что ваш ребенок может остаться один и потенциально пострадать (или, по крайней мере, получить неудобства).
В отличие от статического жесткого особого случая в реальном времени, мягкое реальное время делает только минимально необходимые специфические для приложения предположения о задачах и системе, и ожидаются неопределенности. Чтобы забрать своего ребенка, вам нужно ехать в школу, и время для этого является динамичным, в зависимости от погоды, условий движения и т. Д. У вас может возникнуть соблазн чрезмерного обеспечения вашей системы (т. Е. Позволить то, что, как вы надеетесь, является наихудшее время вождения), но опять же это напрасная трата ресурсов (ваше время и занятие семейного автомобиля, возможно, отказ в использовании другими членами семьи).
Этот пример может показаться не дорогостоящим с точки зрения потерянных ресурсов, но рассмотрим другие примеры. Все военные боевые системы работают в режиме реального времени. Например, рассмотрите возможность выполнения воздушной атаки на вражеское наземное транспортное средство, используя ракету, управляемую с обновлениями, в качестве маневров цели. Максимальное удовлетворение выполнением задач по обновлению курса достигается прямым разрушительным ударом по цели. Но попытка перерасхода ресурсов, чтобы убедиться в этом, обычно слишком дорога и даже может быть невозможна. В этом случае вы можете быть менее, но достаточно удовлетворены, если ракета наносит удар достаточно близко к цели, чтобы отключить ее.
Очевидно, что боевые сценарии имеют множество возможных динамических неопределенностей, которые должны быть учтены управлением ресурсами. Мягкие системы реального времени также очень распространены во многих гражданских системах, таких как промышленная автоматизация, хотя очевидно, что военные являются наиболее опасными и неотложными для достижения приемлемой удовлетворительной ценности.
Краеугольным камнем систем реального времени является "предсказуемость". Трудный случай в реальном времени интересует только один особый случай предсказуемости - то есть, что все задачи будут соответствовать их срокам, и максимальное событие будет достигнуто этим событием. Этот особый случай называется "детерминированным".
Существует спектр предсказуемости. Детерминизм (детерминизм) - это одна конечная точка (максимальная предсказуемость) в спектре предсказуемости; другая конечная точка - минимальная предсказуемость (максимальный недетерминизм). Метрика и конечные точки спектра должны интерпретироваться с точки зрения выбранной модели предсказуемости; все, что находится между этими двумя конечными точками, является степенями непредсказуемости (= степени недетерминированности).
Большинство систем реального времени (а именно, мягких) имеют недетерминированную предсказуемость, например, время завершения задач и, следовательно, значения, полученные из этих событий.
В целом (теоретически) предсказуемость и, следовательно, приемлемо удовлетворительная ценность могут быть сделаны настолько близкими к детерминированной конечной точке, насколько это необходимо - но по цене, которая может быть физически невозможной или чрезмерно дорогой (как в бою или, возможно, даже в забрать вашего ребенка из школы).
Мягкое реальное время требует специфического для приложения выбора вероятностной модели (а не модели распространенных частот) и, следовательно, модели предсказуемости для рассуждений о задержках событий и результирующих значениях.
Возвращаясь к приведенному выше списку событий, которые обеспечивают приемлемое значение, теперь мы можем добавить недетерминированные случаи, такие как
- вероятность того, что ни одно задание не пропустит срок выполнения более чем на 5%, превышает 0,87. (Обратите внимание на количество критериев планирования, указанных там.)
В приложении противоракетной обороны, учитывая тот факт, что в бою преступник всегда имеет преимущество перед защитой, какой из этих двух сценариев вычислений в реальном времени вы бы предпочли:
поскольку идеальное уничтожение всех вражеских ракет маловероятно или невозможно, назначьте свои защитные ресурсы, чтобы максимизировать вероятность того, что многие из наиболее угрожающих (например, в зависимости от их целей) враждебных ракет будут успешно перехвачены (близкий перехват учитывается, поскольку может сдвинуть вражескую ракету с курса);
жаловаться, что это не проблема вычислений в реальном времени, потому что она динамическая, а не статическая, и традиционные концепции и методы в реальном времени не применяются, и это звучит сложнее, чем статическое жесткое в реальном времени, поэтому вас это не интересует,
Несмотря на различные недоразумения относительно мягкого реального времени в компьютерном сообществе реального времени, мягкое реальное время является очень общим и мощным, хотя и потенциально сложным по сравнению с жестким в реальном времени. Мягкие системы реального времени, кратко изложенные здесь, имеют долгую успешную историю использования вне компьютерного сообщества реального времени.
Чтобы напрямую ответить на вопрос ОП:
Жесткая система реального времени может обеспечить детерминированные гарантии - чаще всего, что все задачи будут соответствовать их срокам, время ответа на прерывание или системный вызов всегда будет меньше, чем x, и т. Д. - ЕСЛИ И ТОЛЬКО ЕСЛИ сделаны очень строгие предположения, и они верны, что все, что имеет значение, является статичным и известно априори (в общем, такие гарантии для жестких систем реального времени являются открытой проблемой исследования, за исключением довольно простых случаев)
Мягкая система реального времени не дает детерминированных гарантий, она предназначена для обеспечения максимально возможной аналитически заданной и достигнутой вероятностной своевременности и предсказуемости своевременности, которые возможны в текущих динамических обстоятельствах, в соответствии с критериями, специфичными для приложения.
Очевидно, что жесткое в реальном времени является простым частным случаем мягкого реального времени. Очевидно, что мягкие аналитические недетерминированные заверения в реальном времени могут быть очень сложными для предоставления, но они обязательны в наиболее распространенных случаях в реальном времени (включая наиболее опасные критические для безопасности, такие как боевые действия), поскольку большинство случаев в реальном времени не являются динамическими. статичный.
"Фирменное реальное время" - это плохо определенный частный случай "мягкого реального времени". В этом термине нет необходимости, если термин "мягкий режим реального времени" понимается и используется должным образом.
На моем сайте real-time.org есть более подробное, более подробное обсуждение проблем реального времени, жесткого реального времени, мягкого реального времени, предсказуемости, детерминизма и связанных с ними тем.
Мягкое реальное время легче всего понять, в котором, даже если результат получен после установленного срока, результаты все равно считаются действительными.
Пример: веб-браузер - мы запрашиваем определенный URL, загрузка страницы занимает некоторое время. Если системе требуется больше времени, чем ожидалось, чтобы предоставить нам страницу, полученная страница не считается недействительной, мы просто говорим, что производительность системы была не на должном уровне (система показала низкую производительность!).
В жесткой системе реального времени, если результат получен после крайнего срока, считается, что система полностью провалилась.
Пример: если робот выполняет какую-либо работу, такую как трассировка линии и т. Д. Если на его пути возникает препятствие, и робот не обрабатывает эту информацию в течение некоторого запрограммированного срока (почти мгновенно!), Говорят, что робот потерпел неудачу в своей задаче (система робота также может быть полностью разрушена!).
В устойчивой системе реального времени, если результат выполнения процесса наступает после крайнего срока, мы отбрасываем этот результат, но система не считается отказавшей.
Пример: спутниковая связь для мониторинга позиции противника или какой-либо другой задачи. Если наземная компьютерная станция, на которую спутники периодически отправляют кадры, перегружена, и текущий кадр (пакет) не обрабатывается во времени, и появляется следующий кадр, текущий пакет (тот, который пропустил крайний срок) не имеет значения была ли выполнена обработка (или сделана наполовину, или почти сделана), отбрасывается / отбрасывается. Но наземный компьютер не считается полностью неисправным.
Рассмотрим задачу, которая вводит данные из последовательного порта. Когда поступают новые данные, последовательный порт запускает событие. Когда программное обеспечение обслуживает это событие, оно считывает и обрабатывает новые данные. Последовательный порт имеет оборудование для хранения входящих данных (2 на MSP432, 16 на TM4C123), так что если буфер заполнен и поступает больше данных, новые данные теряются. Является ли эта система жесткой, твердой или мягкой в реальном времени?
В реальном времени трудно, потому что, если ответ задерживается, данные могут быть потеряны.
Рассмотрим слуховой аппарат, который вводит звуки из микрофона, манипулирует звуковыми данными, а затем выводит данные на динамик. Система обычно имеет небольшой и ограниченный джиттер, но иногда другие задачи в слуховом аппарате приводят к задержке некоторых данных, вызывая импульсный шум на динамике. Является ли эта система жесткой, твердой или мягкой в реальном времени?
Это твердое реальное время, потому что оно вызывает ошибку, которая может быть воспринята, но эффект безвреден и существенно не влияет на качество опыта.
Рассмотрим задачу, которая выводит данные на принтер. Когда принтер находится в режиме ожидания, принтер запускает событие. Когда программное обеспечение обслуживает это событие, оно отправляет больше данных на принтер. Является ли эта система жесткой, твердой или мягкой в реальном времени?
Это мягкое реальное время, потому что чем быстрее оно реагирует, тем лучше, но ценность системы (пропускная способность - количество данных, печатаемых в секунду) уменьшается с задержкой.
UTAustinX: UT.RTBN.12.01x Сети Bluetooth в реальном времени
В режиме реального времени - относится к системе или режиму работы, в которых вычисления выполняются в течение фактического времени, когда происходит внешний процесс, чтобы результаты вычислений могли быть использованы для своевременного управления, мониторинга или реагирования на внешний процесс манера. [Стандарт IEEE 610.12.1990]
Я знаю, что это определение старое, очень старое. Однако я не могу найти более свежее определение IEEE (Институт инженеров по электротехнике и электронике).
В жестких системах реального времени используется приоритетная версия планирования приоритетов, так что критические задачи планируются немедленно, тогда как в мягких системах реального времени используется не преимущественная версия планирования приоритетов, что позволяет завершить текущую задачу до того, как управление переходит к более высокому приоритету. задание, вызывающее дополнительные задержки. Таким образом, в жестких системах реального времени критически соблюдаются сроки выполнения задач, тогда как в мягких системах реального времени они обрабатываются не так серьезно.
Может быть, определение виноват.
Исходя из своего опыта, я бы выделил их как аппаратно-программную зависимость.
Если у вас есть 200 мс для обслуживания аппаратного прерывания, это то, что у вас есть. Вы вставляете туда 300 мс кода, и система не сломана, она не разработана. Вы будете отключены, прежде чем вы закончили. Ваш код не работает или не подходит для цели. Многие системы имеют жестко определенные периоды обработки. Видео, телекоммуникации и т. Д.
Если вы пишете приложение, работающее в режиме реального времени, это можно считать мягким. Если у вас не хватит времени, вы можете надеяться на меньшую загрузку в следующий раз, вы можете настроить ОС, добавить немного памяти или даже обновить оборудование. У вас есть варианты.
Смотреть на это с точки зрения UX не полезно. Шкода, возможно, не сломается, если она даст сбой, но БМВ, конечно, как черт будет.
Определение расширилось с годами в ущерб термину. То, что сейчас называется "жестким" в реальном времени, - это то, что раньше называлось просто в реальном времени. Поэтому системы, в которых пропущенные временные окна (а не односторонние сроки) могут привести к неверным данным или неправильному поведению, должны рассматриваться в режиме реального времени. Системы без этой характеристики будут считаться не в реальном времени.
Это не означает, что время не представляет интереса для систем не в реальном времени, это просто означает, что требования к синхронизации в таких системах не приводят к принципиально неверным результатам.