Различия между жесткими реальными, мягкими в реальном времени и устойчивыми в реальном времени?

Ответ 1

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

Фирменные/мягкие системы реального времени могут пропустить некоторые крайние сроки, но в конечном итоге производительность ухудшится, если слишком много пропущено. Хорошим примером является звуковая система на вашем компьютере. Если вы пропустите несколько бит, неважно, но пропустите слишком много, и вы собираетесь в конечном итоге разрушить систему. Аналогичными могут быть сейсмические датчики. Если вы пропустите несколько данных, неважно, но вы должны поймать большинство из них, чтобы понять данные. Что еще более важно, никто не умрет, если они не работают правильно.

Линия нечеткая, потому что даже кардиостимулятор может быть выключен на небольшое количество, не убивая пациента, но это общий смысл.

Это похоже на разницу между горячей и теплой. Там нет реального разрыва, но вы это знаете, когда чувствуете это.

Ответ 2

Hard Real-Time

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

Примеры:

• Air France Flight 447 врезался в океан после сбоя датчика, вызвавшего ряд системных ошибок. Пилоты застопорили самолет, отвечая на устаревшие показания прибора. Все 12 членов экипажа и 216 пассажиров были убиты.

• Космический корабль Mars Pathfinder был почти потерян, когда инверсия приоритета вызвала перезагрузку системы. Задача с более высоким приоритетом не была завершена вовремя из-за блокировки задачей с более низким приоритетом. Проблема была исправлена, и космический корабль успешно приземлился.

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

Фирма в режиме реального времени

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

<сильные > Примеры:

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

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

Soft Real-Time

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

<сильные > Примеры:

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

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

^{Siewert: Встроенные системы и компоненты реального времени.
Лю и Лейленд: Планирование алгоритмов для мультипрограммирования в жесткой среде реального времени.
Marchand и Silly-Четто: Динамическое планирование мягких апериодических задач и периодических задач с помощью пропусков.}

Ответ 3

После прочтения страницы Википедии и других страниц в режиме реального времени. Я сделал следующие выводы:

1 > Для жесткой системы реального времени, если система не соответствует сроку даже после того, как система считается ошибочной.

2 > Для Системы реального времени, даже если система не соответствует сроку, возможно, более одного раза (т.е. для нескольких запросов), система не считается неудачной. Кроме того, ответы на запросы (ответы на запрос, результат задачи и т.д.) Бесполезны после истечения крайнего срока для этого конкретного запроса (Полезность результата равна нулю после его срока). Гипотетическим примером может быть система прогноза шторма (если шторм предсказывается до прибытия, то система выполнила свою работу, предсказание после того, как событие уже произошло или когда оно происходит, не имеет значения).

3 > Для Системы в режиме реального времени, даже если система не соответствует сроку, возможно, более одного раза (то есть для нескольких запросов), система не считается неудачной. Но в этом случае результаты запросов не являются бесполезными значением для результата после его крайнего срока, не равна нулю, а скорее ухудшаются по прошествии времени после истечения срока. Например: Потоковое аудио-видео.

Здесь - ссылка на ресурс, который был очень полезен.

Ответ 4

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

Фирма и soft просто не могут быть автоматически объявлены сломанными при невозможности выполнить один крайний срок.

Для справедливого примера жесткого реального времени со страницы, которую вы указали:

Ранние системы видеоигр, такие как векторная графика Atari 2600 и Cinematronics, имели жесткие требования в режиме реального времени из-за характера графики и оборудования времени.

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

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

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

Ответ 5

Самый простой способ различать разные типы систем реального времени - это ответить на вопрос:

Возможно ли отложенный ответ системы (после крайнего срока) полезен или нет?

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

• Жесткий: Нет, и отложенные ответы считаются сбоем системы.

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

2. Фирма: Нет, но отложенные ответы не нужны для сбоя системы.

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

3. Софт: Да, но системная служба ухудшена

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

Ответ 6

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

Говоря небрежно, у большинства людей подразумевается неформальная ментальная модель, которая рассматривает информацию или событие как "в реальном времени"

• если или в той степени, в которой он проявляется к ним с задержкой (латентностью), которая может быть связана с воспринимаемой ею валютой

то есть в течение времени, когда информация или событие имеют приемлемо удовлетворительное значение для них.

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

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

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

• не более 10% задач пропускают свои сроки
• или нет задачи более 20% опоздания
• или средняя задержка всех задач составляет не более 15%
• или максимальная прочность среди всех задач составляет менее 10%

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

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

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

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

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

Основным краеугольным камнем систем реального времени является "предсказуемость". Жесткий случай в реальном времени интересуется только одним особым случаем предсказуемости, т.е. Что задачи будут соответствовать их предельным срокам, и максимально возможное значение будет достигнуто этим событием. Этот специальный случай называется "детерминированным".

Существует спектр предсказуемости. Детерминированный (детерминизм) - это одна конечная точка (максимальная предсказуемость) по спектру предсказуемости; другая конечная точка - минимальная предсказуемость (максимальный недетерминизм). Метрика спектра и конечные точки должны интерпретироваться в терминах выбранной модели предсказуемости; все между этими двумя конечными точками является степенью непредсказуемости (= степени недетерминированности).

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

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

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

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

• вероятность того, что задача не упустит свой срок более чем на 5%, больше, чем 0,87. (Обратите внимание на количество критериев планирования, выраженных там.)

В заявке на противоракетную оборону, учитывая тот факт, что в бою преступление всегда имеет преимущество перед защитой, какой из этих двух вычислительных сценариев реального времени вы предпочитаете:

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

• жалуются, что это не проблема в режиме реального времени, поскольку она динамическая, а не статическая, а традиционные концепции и методы реального времени не применяются, и это звучит сложнее, чем статическое жесткое в реальном времени, поэтому вас это не интересует.

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

Чтобы напрямую ответить на вопрос OP:

Жесткая система реального времени может обеспечить детерминированные гарантии - чаще всего, что все задачи будут соответствовать их срокам, время отклика или времени отклика системного вызова всегда будет меньше x и т.д. - ЕСЛИ И ТОЛЬКО ЕСЛИ сделаны очень сильные предположения и правильны, что все, что имеет значение, является статическим и известно "априори" (в общем, такие гарантии для жестких систем реального времени являются открытой исследовательской проблемой, за исключением довольно простых случаев)

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

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

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

У меня есть более подробное подробное обсуждение реального времени, жесткого реального времени, мягкого реального времени, предсказуемости, детерминизма и смежных тем на моем веб-сайте real-time.org.

Ответ 7

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

Пример: веб-браузер. Мы запрашиваем определенный URL-адрес, для загрузки страницы требуется некоторое время. Если система занимает больше ожидаемого времени, чтобы предоставить нам страницу, полученная страница не считается недействительной, мы просто говорим, что производительность системы не соответствует значению (система дала низкую производительность!).

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

Пример: в случае, если робот выполняет определенную работу, например, трассировку строки и т.д. Если помеха идет по его пути, и робот не обрабатывает эту информацию в течение некоторого запрограммированного срока (почти мгновенно!), робот называется не удалось выполнить свою задачу (робот-система также может быть полностью уничтожена!).

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

Пример: Спутниковая связь для мониторинга положения противника или какая-то другая задача. Если наземная компьютерная станция, на которую спутники отправляют кадры периодически, перегружается, и текущий кадр (пакет) не обрабатывается вовремя, а следующий кадр появляется, текущий пакет (тот, кто пропустил крайний срок) не имеет значения была ли обработка выполнена (или сделана половина или почти завершена), отбрасывается/отбрасывается. Но наземный компьютер не называется полностью неудачным.

Ответ 8

в режиме реального времени. В зависимости от системы или режима работы, в которых вычисление выполняется в течение фактического времени, когда происходит внешний процесс, чтобы результаты вычислений могли использоваться для управления, мониторинга или реагирования на внешний процесс своевременно. [Стандарт IEEE 610.12.1990]

Я знаю, что это определение старое, очень старое. Однако я не могу найти более новое определение IEEE (Институт инженеров по электротехнике и электронике).

Ответ 9

Возможно, определение ошибочно.

По моему опыту, я бы отделил их как зависящие от оборудования и программного обеспечения.

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

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

Взгляд на него с точки зрения UX не помогает. Skoda не может быть сломан, если он глючит, но BMW уверен, что черт возьми.

Ответ 10

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

Чтобы не сказать, что время не представляет интереса к системам без реального времени, это просто означает, что временные требования в таких системах не приводят к принципиально неправильным результатам.

Ответ 11

Рассмотрим задачу, которая вводит данные из последовательного порта. Когда новые данные поступают, последовательный порт запускает событие. Когда программное обеспечение обслуживает это событие, оно считывает и обрабатывает новые данные. Последовательный порт имеет аппаратное обеспечение для хранения входящих данных (2 на MSP432, 16 на TM4C123), так что если буфер заполнен и поступает больше данных, новые данные теряются. Является ли эта система жесткой, твердой или мягкой в ​​реальном времени?

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

Рассмотрим слуховой аппарат, который вводит звуки из микрофона, манипулирует звуковыми данными, а затем выводит данные на динамик. Обычно система имеет небольшой и ограниченный джиттер, но иногда другие задачи в слуховом аппарате заставляют некоторые данные опоздать, вызывая шум на динамике. Является ли эта система жесткой, твердой или мягкой в ​​реальном времени?

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

Рассмотрим задачу, которая выводит данные на принтер. Когда принтер находится в режиме ожидания, принтер запускает событие. Когда программное обеспечение обслуживает это событие, оно отправляет на принтер больше данных. Является ли эта система жесткой, твердой или мягкой в ​​реальном времени?

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

UTAustinX: UT.RTBN.12.01x сети Bluetooth в реальном времени