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

Я прочитал определения различных понятий реального времени , и примеры, приведенные для жестких и мягких систем реального времени, имеют для меня смысл. Но нет реального объяснения или примера надежной системы реального времени. По ссылке выше:

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

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

В комментариях Чарльз попросил меня отправить вики-страницы для новых тегов. Пример "фирменной системы реального времени" я привел дляфирма в реальном временибирка была системой подачи молока. Если система подает молоко по истечении срока его годности, оно считается «бесполезным». Можно терпеть кашу без молока, но качество переживания ухудшается.

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

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

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

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

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

Жесткое реальное время

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

Примеры:

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

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

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

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

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

Примеры:

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

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

Мягкое в реальном времени

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

Примеры:

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

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

^{Сиверт: Встроенные системы и компоненты реального времени.
Лю и Лейланд: Алгоритмы планирования для мультипрограммирования в среде жесткого реального времени.
Marchand & Silly-Chetto: динамическое планирование мягких апериодических задач и периодических задач с пропусками.}

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

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

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

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

Вот ссылка на очень полезный ресурс.

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

Твердое и мягкое просто не может быть автоматически объявлено сломленным при невыполнении единого срока.

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

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

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

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

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

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

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

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

1. Сложно : Нет, и отложенные ответы считаются системным сбоем.

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

2. Твердо : Нет, но отложенные ответы не являются обязательными из-за сбоя системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Может быть, определение ошибочно.

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

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

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

Смотреть на это с точки зрения UX бесполезно. Skoda может и не сломаться, если даст сбой, но BMW наверняка сломается.

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

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

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