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

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

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

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

У коментарях Чарльз попросив відправити теги wikis для нових тегів. Приклад "фірмової системи в реальному часі" передбачав

66
В основному, визначення не є реальною фірмою.
додано Автор Hot Licks, джерело
Я відновив оригінальні теги. Я думаю, що корисно мати змогу розмістити більш конкретну мітку на запитання щодо жорсткого або м'якого реального часу. Вона змінює спосіб відповіді на запитання. Теги автоматично видалятимуться, якщо теги не використовуються через 6 місяців.
додано Автор jxh, джерело
Якщо ви збираєтеся наполягати на три нові теги для цього запитання і лише на це запитання, принаймні додайте вікі та спробуйте знайти інші запитання, до яких вони будуть застосовуватися.
додано Автор Charles, джерело

11 Відповіді

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

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

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

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

82
додано
Те, як я це бачу: різниця полягає в тому, як вказана система, а не те, як вона використовується. Контролер кардіостимулятора або подушки безпеки визначається як необхідний для того, щоб потрапити у будь-який крайній термін, тоді як програмне забезпечення для звуку в цілому не є.
додано Автор Mark K Cowan, джерело
@jxh Відсутність кінцевого терміну може не обов'язково суттєво порушити синхронізацію, доки наступні пакети знову синхронізуються
додано Автор Mark K Cowan, джерело
@jxh специфікація, що дозволяє відсутність кожного кінцевого терміну, можливо, не вважатиметься "реальним часом"
додано Автор Mark K Cowan, джерело
"не потрібно натискати на кожну" ≠ ", що дозволяється пропускати кожен". Існують інші реалі між 0 і 1 - це може бути, що потрібно натиснути "99,9% термінів".
додано Автор Mark K Cowan, джерело
Майте на увазі, що це континуум. Практично кожна комп'ютерна система є "реальним часом" на певному масштабі часу. Система виставлення рахунків компанії повинна отримати достатньо швидку оплату рахунків для підтримки потоку грошових коштів у компанію, або компанія помре, так само, як пацієнт помре, якщо кардіостимулятор промахнеться на кілька сотень мілісекунд.
додано Автор Hot Licks, джерело
Як зазначалося, розділові лінії досить нечіткі. Одна м'яка система в реальному часі, на якій я працювала, мала відхилення в декілька секунд, так що ось я малюю лінію.
додано Автор Joel, джерело
Вимоги в реальному часі знаходяться в контексті даної системи, не властивої цій проблемі. У наведеному вами прикладі все ще пошкоджується звук (він прискорюється) і тимчасове невідповідність звуку та відео.
додано Автор Joel, джерело
@MarkKCowan: Тоді ми погоджуємося з тим, що я сказав: "повинна бути якась вимога, зазначена".
додано Автор jxh, джерело
@MarkKCowan: Я відповідав на ваш коментар "аудіо програмне забезпечення, як правило, не [вказано, як почати потрібно для досягнення кожного терміну]". Для мене це означало, що ви дозволили йому пропустити кожен термін. Незважаючи на це, це все ще в реальному часі, оскільки аудіо все ще має бути розшифровано людським вухом.
додано Автор jxh, джерело
@MarkKCowan: Відсутність одного з них може не бути поміченим, але відсутній.
додано Автор jxh, джерело
@MarkKCowan: Необхідно вказати певну вимогу, оскільки рух слова та губи "завжди" синхронізовані. Ви можете подати запит на повернення коштів на квиток у фільмі, якщо вони не були.
додано Автор jxh, джерело
Я розумію, що пропущені терміни можуть бути допустимими для деяких систем, але це моє розуміння системи м'якого реального часу. Я шукаю практичний приклад критеріїв: Корисність результату дорівнює нулю після кінцевого терміну. аудіопакети будуть мати нульову корисність? Але є деякі системи відтворення фільмів, які прискорюють аудіо, щоб наздогнати відео.
додано Автор jxh, джерело
Ваш "твердий" приклад здається мені "м'яким".
додано Автор jxh, джерело
Просто хотілося б запитати, чи існує щось подібне "жорсткий RTOS" або "Soft-Time RTOS" себе або це дизайнер, який визначає систему, як жорсткий час або в реальному часі, незалежно від будь-якого RTOS використовується?
додано Автор Akay, джерело

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

The Жорсткий реальний час definition considers any missed deadline to be a system failure. This scheduling is used extensively in mission critical systems where failure to conform to timing constraints results in a loss of life or property.

Приклади.

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

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

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


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

The Фірма реального часу definition allows for infrequently missed deadlines. In these applications the system can survive task failures so long as they are adequately spaced, however the value of the task's completion drops to zero or becomes impossible.

Приклади.

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

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


М'який реальний час

The М'який реальний час definition allows for frequently missed deadlines, and as long as tasks are timely executed their results continue to have value. Completed tasks may have increasing value up to the deadline and decreasing value past it.

Приклади.

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

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


Siewert: Real-Time Embedded Systems and Components.
Liu & Layland: Scheduling Algorithms for Multiprogramming in a Жорсткий реальний час Environment.
Marchand & Silly-Chetto: Dynamic Scheduling of Soft Aperiodic Tasks and Periodic Tasks with Skips.

57
додано
який приємний список прикладів!
додано Автор Erik Allik, джерело
Один з кращих прикладів
додано Автор Vishnu N K, джерело
У випадку з катастрофою 447, не було багато пропущених термінів до того, як літак завалився? Здається, всі системи є твердими в цьому сенсі.
додано Автор Josiah Yoder, джерело
Дуже хороший список, однак приклад струменевого принтера не відповідає вимогам жорсткого реального часу.
додано Автор Ab Irato, джерело

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

1> For a Hard real-time system, if the system fails to meet the deadline even once the system is considered to have Failed.

2> For a Firm real-time system, even if the system fails to meet the deadline, possibly more than once (i.e. for multiple requests), the system is not considered to have failed. Also, the responses for the requests (replies to a query, result of a task, etc.) are worthless once the deadline for that particular request has passed (The usefulness of a result is zero after its deadline). A hypothetical example can be a storm forecast system (if a storm is predicted before arrival, then the system has done its job, prediction after the event has already happened or when it is happening is of no value).

3> For a Soft real-time system, even if the system fails to meet the deadline, possibly more than once (i.e. for multiple requests), the system is not considered to have failed. But, in this case the results of the requests are not worthless value for a result after its deadline, is not zero, rather it degrades as time passes after the deadline. Eg.: Streaming audio-video.

Here is a link to a resource that was very helpful.

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

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

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

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

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

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

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

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

11
додано
Якщо ніхто не бачить, що ви порушуєте правила (або якщо вони це зробили, але вони померли, не сказавши нікому), і ніхто не може довести, що ви порушили правила після цього, то це те ж саме, як якщо б ви не зламали правила! ... Ok, HAL. А тепер, будь ласка, відкрийте двері буксирувальника?
додано Автор Basic, джерело

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

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

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

  1. Hard: No, and delayed answers are considered a system failure

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

  1. Firm: No, but delayed answers are not necessary a system failure

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

  1. Soft: Yes, but the system service is degraded

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

7
додано

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

Example: Web browser- We request for certain URL, it takes some time in loading the page. If the system takes more than expected time to provide us with the page, the page obtained is not considered as invalid, we just say that the system's performance wasn't up to the mark (system gave low performance!).

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

Example: In case of a robot doing some job like line tracing, etc. If a hindrance comes on its path, and the robot doesn't process this information within some programmed deadline (almost instant!), the robot is said to have failed in its task (the robot system may also get completely destroyed!).

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

Example: Satellite communication for enemy position monitoring or some other task. If the ground computer station to which the satellites send the frames periodically is overloaded, and the current frame (packet) is not processed in time and the next frame comes up, the current packet (the one who missed the deadline) doesn't matter whether the processing was done (or half done or almost done) is dropped/discarded. But the ground computer is not termed to have completely failed.

5
додано

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для прямої відповіді на питання ОП:

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

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

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

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

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

5
додано
"Перша революція - це коли ви передумаєте про те, як ви дивитеся на речі і бачите, що може бути інший спосіб подивитися на це, що ви не були показані". --Gil Scott-Heron, "Революція не буде телевізором"
додано Автор E. Douglas Jensen, джерело

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

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

2
додано
Власне, 1990 рік зовсім не старий. Я обговорював це питання в 70-х роках, і це визначення було приблизно таким же.
додано Автор Hot Licks, джерело

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

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

1
додано

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

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

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

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

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

1
додано
що ти маєш проти Шкодас!
додано Автор Erik Allik, джерело

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

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


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

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


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

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

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

1
додано