Відмінності між жорстким режимом реального часу, м'яким режимом реального часу та твердим режимі реального часу?

Я прочитав визначення для різних понять у реальному часі , і приклади, надані для жорстких і м'яких систем реального часу, мають сенс для мене. Але реального пояснення чи прикладу твердої системи в режимі реального часу немає. За посиланням вище:

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

Чи є чітке розмежування між твердим або м'яким реальним часом у режимі реального часу та чи є хороший приклад, який ілюструє це відмінність?

У коментарях Чарльз попросив я надіслати вікі з тегами для нових тегів. Приклад "твердої системи в режимі реального часу" я наводив дофірма в режимі реального часуТег був системою подачі молока. Якщо система постачає молоко після його закінчення, то молоко вважається "не корисним". Можна переносити їжу крупи без молока, але якість досвіду погіршується.

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

Жорсткий в режимі реального часу означає, що ви повинні абсолютно дотримуватися кожного строку. Дуже мало систем мають цю вимогу. Деякі приклади - ядерні системи, деякі медичні програми, такі як кардіостимулятори, велика кількість застосувань для захисту, авіоніка тощо.

Фірмові / м'які системи в режимі реального часу можуть пропустити деякі строки, але з часом продуктивність погіршиться, якщо занадто багато буде пропущено. Хороший приклад - звукова система вашого комп’ютера. Якщо ви пропустите декілька біт, нічого страшного, але занадто багато пропустіть, і згодом ви погіршите систему. Подібні були б сейсмічні датчики. Якщо вам не вистачає декількох точок даних, нічого серйозного, але вам доведеться зловити більшість з них, щоб зрозуміти дані. Що ще важливіше, ніхто не помре, якщо вони не працюють належним чином.

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

Це як би різниця між гарячим і теплим. Немає справжнього розколу, але ти це знаєш, коли відчуєш.

Жорсткий в режимі реального часу

У жорсткому визначенні в реальному часі будь-який пропущений термін вважається збоєм у системі. Цей графік широко застосовується в критичних системах місії, коли невідповідність тимчасовим обмеженням призводить до втрати життя або майна.

Приклади:

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

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

• Струйний принтер має друкувальну головку з програмним забезпеченням для управління для нанесення потрібної кількості чорнила на певну частину паперу. Якщо термін пропущено, то завдання друку буде порушено.

Фірма в режимі реального часу

Фірма в реальний час визначення дозволяє рідко пропущені терміни. У цих програмах система може переживати збої задачі до тих пір, поки вони не мають достатнього розміщення, однак значення виконання завдання падає до нуля або стає неможливим.

Приклади:

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

• Цифрова кабельна приставка декодує часові позначки часу, коли кадри повинні з’являтися на екрані. Оскільки кадри залежать від часового порядку, пропущений термін спричиняє тремтіння, зменшуючи якість обслуговування. Якщо пропущений кадр пізніше стане доступним, він лише спричинить його більше тремтіння, тому він марний. Переглядач все ще може насолоджуватися програмою, якщо тремтіння трапляється не надто часто.

М'який в режимі реального часу

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

Приклади:

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

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

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

Після прочитання сторінки Вікіпедії та інших сторінок обчислень у режимі реального часу. Я зробив такі умовиводи:

1> Для жорсткої системи в режимі реального часу , якщо система не дотримується встановленого терміну, навіть коли система вважається такою, що не працює.

2> Для фірмової системи в режимі реального часу , навіть якщо система не дотримується граничного терміну, можливо, більше одного разу (тобто для декількох запитів), система не вважається невдалою. Крім того, відповіді на запити (відповіді на запит, результат завдання і т. Д.) Марні, як тільки минув граничний термін для цього конкретного запиту ( Корисність результату дорівнює нулю після його строку ). Гіпотетичним прикладом може бути система прогнозу штормів (якщо перед прилетом прогнозується шторм, тоді система зробила свою роботу, прогнозування після події вже відбулося або коли воно відбувається - не має значення).

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

Ось посилання на ресурс, який був дуже корисним.

Популярне асоціювати якусь велику катастрофу з визначенням жорсткого реального часу, але це не має значення. Будь-яке невиконання жорсткого обмеження в режимі реального часу просто означає, що система зламана. Тяжкість результату, коли щось позначено "зламаним", не є визначальним для визначення.

Міцні та м'які просто не можуть бути автоматично оголошені порушеними, якщо не виконати єдиний термін.

На справжній приклад важкого реального часу зі сторінки, на яку ви пов’язали:

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

Якщо щось у циклі генерації відео пропустило лише один термін, то весь дисплей блякнув, що було б нестерпно, навіть якщо це було рідко. Це була б зламана система, і ви повернете її до магазину для повернення коштів. Тож у режимі реального часу важко.

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

І давайте не забувати, що іноді є неявна умова роботи "поки хтось дивиться". Якщо ніхто не бачить, як ви порушили правила (або якщо вони це зробили, але вони вмирають вогнем, перш ніж сказати комусь), і ніхто не може довести, що ви порушили правила після факту, то це все одно, що як ніколи ви не порушували правила!

Найпростіший спосіб розрізнити різні види систем у реальному часі - це відповідь на питання:

Чи все-таки корисна відповідь системи (після закінчення терміну) все ж корисна чи ні?

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

1. Важко : Ні, а відкладені відповіді вважаються збоєм у системі

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

2. Фірма : Ні, але відкладені відповіді не потрібні збою системи

Це випадок, коли пропущений термін є допустимим, але це вплине на якість послуги. Як простий приклад розглянемо систему шифрування відео. Зазвичай пароль шифрування генерується на сервері (Video Head End) та надсилається на прийом клієнтів. Цей процес повинен бути синхронізований, тому звичайно телеприймач отримує парольперед початком прийому зашифрованих кадрів відео. У цьому випадку затримка може призвести до виникнення збоїв у відео, оскільки телевізор не в змозі розшифрувати кадри, оскільки він ще не отримав пароль. У цьому випадку на службу (фільм, цікавий футбольний матч тощо) може вплинути не дотримання терміну. Отримання паролю із запізненням у цьому випадку не корисне, оскільки зашифровані з ним кадри вже спричинили збої.

3. Програмне забезпечення : Так, але системна служба принижена

Оскільки з опису вікіпедії корисність результату погіршується після його терміну . Це означає, що отримання відповіді від системи поза граничним терміном все ще корисно для кінцевого користувача, але її корисність погіршується після досягнення граничного терміну. Простий приклад для цього випадку - це програмне забезпечення, яке автоматично контролює температуру приміщення (або будівлі). У цьому випадку, якщо система має певні затримки зчитування датчиків температури, реагувати на різкі зміни температури буде трохи повільніше. Однак, врешті-решт, він врешті-решт відреагує на зміну і відповідно регулює температуру, щоб зберегти її постійною, наприклад. Тож у цьому випадку затримка реакції є корисною, але вона погіршує якість обслуговування системи.

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

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

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

Приклад: Якщо робот виконує таку роботу, як відстеження рядків і т. Д. Якщо на шляху до нього перешкоджає перешкода, і робот не обробляє цю інформацію протягом певного запрограмованого терміну (майже миттєво!), Робота, як вважається, не відбулася. у своєму завданні (робота також може повністю знищитися!).

У твердій системі в режимі реального часу , якщо результат виконання процесу настає після закінчення терміну, ми відкидаємо цей результат, але система не називається невдалою.

Приклад: супутниковий зв’язок для моніторингу позиції противника або якесь інше завдання. Якщо наземна комп'ютерна станція, на яку супутники періодично надсилають кадри, перевантажена, а поточний кадр (пакет) не обробляється вчасно і з'являється наступний кадр, поточний пакет (той, хто пропустив термін) не має значення чи було оброблено (або наполовину виконано, або майже виконано), відмовляється / відкидається. Але наземний комп'ютер не називається повністю вийшов з ладу.

Для визначення "м'якого режиму реального часу" найлегше порівняти його з "жорстким у режимі реального часу". Нижче ми побачимо, що термін "фірма в режимі реального часу" являє собою непорозуміння щодо "м'якого реального часу".

Якщо говорити випадково, то більшість людей неявно мають неформальну ментальну модель, яка розглядає інформацію чи подію як "в реальному часі"

• якщо або в тій мірі, що це виявляється для них із затримкою (затримкою), яка може бути пов'язана з її сприйнятою валютою

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

Існує чимало різних спеціальних визначень "жорсткого реального часу", але в цій ментальній моделі жорсткий реальний час представлений терміном "якщо". Зокрема, якщо припустити, що дії в режимі реального часу (такі як завдання) мають терміни завершення, прийнятна задовільна цінність події, що всі завдання виконуються, обмежується окремим випадком, коли всі завдання відповідають їх термінам.

Жорсткі системи в режимі реального часу роблять дуже сильні припущення, що все щодо програми та системи та оточення є статичним і відомим «апріорі», наприклад, які завдання, що вони періодичні, час їх приходу, періоди, терміни, що вони виграли не матимуть конфліктних ресурсів та загальну еволюцію часу в системі. У системі управління польотом літака або автомобільній гальмівній системі та багатьох інших випадках ці припущення, як правило, можуть бути виконані, щоб усі строки були дотримані.

Ця ментальна модель навмисне і дуже корисно досить загальна, щоб охоплювати як жорсткий, так і м'який в режимі реального часу - м'який розміщений фразою "настільки, наскільки це". Наприклад, припустимо, що подія виконання завдання має неоптимальне, але прийнятне значення, якщо

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

Це всі поширені приклади м'яких справ у реальному часі у багатьох програмах.

Розгляньте застосування одноосібного підбору дитини після школи. Це, мабуть, не має фактичного строку, натомість є певна цінність для вас та вашої дитини залежно від того, коли відбудеться ця подія. Занадто рано витрачає ресурси (наприклад, ваш час) і занадто пізно має певне негативне значення, оскільки ваша дитина може залишитися в спокої і, можливо, нашкодити (або принаймні незручно).

На відміну від статичного жорсткого спеціального випадку в режимі реального часу, м'який режим реального часу робить лише мінімально необхідні припущення щодо завдань та системи, а також очікуються невизначеності. Щоб забрати дитину, вам доведеться їхати до школи, а час на це є динамічним, залежно від погоди, дорожнього руху тощо. Можливо, ви будете спокушені надмірно забезпечити свою систему (тобто дозволити, на що ви сподіваєтесь, це найгірший час за кермом), але знову-таки це витрата ресурсів (ваш час та зайняття сімейного автомобіля, можливо, відмова від використання іншими членами сім'ї).

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

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

Основним каменем систем реального часу є "передбачуваність". Важкий випадок у реальному часі зацікавлений лише в одному окремому випадку передбачуваності - тобто, що ці завдання будуть дотримуватися своїх термінів і максимально можлива цінність буде досягнута в рамках цієї події. Цей особливий випадок названий "детермінованим".

Існує спектр передбачуваності. Детермінований (детермінізм) - це одна кінцева точка (максимальна передбачуваність) на спектрі передбачуваності; інша кінцева точка - мінімальна передбачуваність (максимальний недетермінізм). Метрику та кінцеві точки спектру слід інтерпретувати через обрану модель передбачуваності; все між цими двома кінцевими точками - це ступеня непередбачуваності (= ступеня недетермінованості).

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

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

Програмне забезпечення в режимі реального часу вимагає вибору конкретної моделі імовірності (не загальної частотистської моделі), а відтак і моделі передбачуваності для міркування про затримки подій та отримані значення.

Посилаючись на вищенаведений перелік подій, які надають прийнятне значення, тепер ми можемо додати недетерміновані випадки, такі як

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

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

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

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

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

Щоб безпосередньо відповісти на питання ОП:

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

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

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

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

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

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

Я знаю, що це визначення давнє, дуже давнє. Однак я не можу знайти більш свіжого визначення IEEE (Інституту інженерів електротехніки та електроніки).

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

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

Розглянемо слуховий апарат, який вводить звуки з мікрофона, маніпулює звуковими даними, а потім виводить дані на динамік. У системі зазвичай є невелике і обмежене тремтіння, але іноді інші завдання у слуховому апараті затримують деякі дані, викликаючи імпульс шуму на динаміку. Ця система є жорсткою, міцною чи м'якою в режимі реального часу?

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

Розглянемо завдання, яке виводить дані на принтер. Коли принтер не працює, принтер запускає подію. Коли програмне забезпечення надає події, воно надсилає більше даних на принтер. Ця система є жорсткою, міцною чи м'якою в режимі реального часу?

Це м'який реальний час, оскільки чим швидше він реагує, тим краще, але значення системи (пропускна здатність - кількість даних, що друкуються в секунду) зменшується із затримкою.

UTAustinX: UT.RTBN.12.01x Bluetooth в реальному часі

Можливо, визначення винне.

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

Якщо у вас є 200 мс для обслуговування апаратного переривання, саме це у вас є. Ви вставляєте 300ms коду там, і система не зламана, вона не була розроблена. Ви вимкнетесь, перш ніж закінчите. Ваш код не працює або не відповідає призначенню. Багато систем мають жорстко визначені періоди обробки. Відео, телекомунікації тощо

Якщо ви пишете заявку в режимі реального часу, це може вважатися м'яким . Якщо у вас не вистачає часу, ви можете сподіватися на менший навантаження наступного разу, ви можете налаштувати ОС, додати трохи пам’яті або навіть оновити обладнання. У вас є варіанти.

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

Визначення розширилось з роками на шкоду терміну. Те, що зараз називається "жорстким" у реальному часі, - це те, що раніше називалося просто в режимі реального часу. Таким чином, системи, в яких відсутні проміжки часу (а не односторонні терміни) призводять до неправильних даних або неправильної поведінки, повинні розглядатися в режимі реального часу. Системи без такої характеристики вважатимуться нереальними.

Це не означає, що час не цікавить систем, що не є в реальному часі, це просто означає, що вимоги до часу в таких системах не призводять до принципово неправильних результатів.

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