it-swarm.com.ru

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

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

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

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

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

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

77
jxh

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

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

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

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

95
Joel

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

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

Примеры: 

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

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

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


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

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

Примеры:

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

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


Soft Real-Time

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

Примеры:

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

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


Siewert: Встроенные системы и компоненты реального времени.
Liu & Layland: Алгоритмы планирования мультипрограммирования в жестких условиях реального времени.
Marchand & Silly-Chetto: Динамическое планирование мягких апериодических задач и периодических задач с пропусками .

68
John E Harriss

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

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

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

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

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

42
Meghendra

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

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

Яркий пример жесткого реального времени со страницы, на которую вы ссылаетесь:

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

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

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

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

11
sh1

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

Отложенный ответ системы (после истечения срока) все еще полезен или нет?

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

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

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

  1. Фирма : Нет, но отсроченные ответы не нужны при сбое системы 

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

  1. Софт : Да, но системный сервис ухудшен 

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

7
rkachach

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

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

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

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

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

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

5
Rubal

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have a more detailed much more precise discussion of real-time, hard real-time, soft real-time, predictability, determinism, and related topics on my web site real-time.org.

5
E. Douglas Jensen

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

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

2
Mike Jablonski

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

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


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

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


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

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

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

1
Mohamed Abd El Raouf

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

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

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

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

Смотреть на это с точки зрения UX не полезно. Шкода, возможно, не сломается, если она даст сбой, но БМВ, конечно, как черт будет.

1
Steve

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

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

1
user1671787

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

0
Kishor Bhoyar