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

Жесткий В Режиме Реального Времени

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

примеры:

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

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

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

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

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

примеры:

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

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

Мягкий В Режиме Реального Времени

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

примеры:

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

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

^{Сюарт: в реальном масштабе времени врезанные системы и Комплектующие.
Liu & Layland: алгоритмы планирования для мультипрограммирования в жесткой среде реального времени.
Маршан И Глупый-Четто: динамическое планирование мягких Апериодических задач и периодических задач с пропусками.}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. фирма: нет, но отложенные ответы не обязательно сбой системы

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

1. софт: да, но системная служба деградирует

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

возможно, определение ошибается.

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

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

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

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

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

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

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

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

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

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

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

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

UTAustinX: UT.РТРС.12.01 X сети Bluetooth в реальном времени