Переваги використання RTOS, таких як QNX або VxWorks замість Linux?

Розробляючи рішення, яке вимагає операційної системи в режимі реального часу, які переваги матиме операційна система, така як QNX або VxWorks, перед Linux?

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

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

Якщо ви не можете змінити обладнання, ви можете вимкнути Linux та використовувати щось інше:

• Можливо, у процесора навіть немає MMU, що робить неможливим запуск Linux (крім uClinux, і, наскільки я знаю, uClinux не є в режимі реального часу).
• Можливо, процесор відносно повільний, і найгірший затримка переривання в Linux не відповідає певній жорсткій вимозі, а деякі інші RTOS, налаштовані на надзвичайно низькі затримки переривання в гіршому випадку, можуть задовольнити цю вимогу.
• Можливо, у системі дуже мало оперативної пам’яті. Кілька років тому для мінімальної установки Linux потрібно було близько 2 Мб оперативної пам’яті; мінімальна настройка eCos (із шаром сумісності, що дозволяє їй запускати деякі програми, спочатку розроблені для роботи на Linux), необхідна близько 20 кБ оперативної пам’яті.
• Можливо, для вашого обладнання немає порту Linux, і не вистачає часу для порту Linux, перш ніж запустити (каламбур!) Вашу систему. Багатьом простішим RTOS потрібен набагато менше часу для порту на нове обладнання, ніж Linux.

Я взагалі не робив жодної роботи в реальному часі, тому візьміть це з зерном солі ...

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

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

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

В останній ситуації ви використовуєте RTOS. RTOS часто гарантує доставку перерви менш ніж стільки інструкцій, годинників та інших.

Іншим моментом може бути те, що RTOS був розроблений, випробуваний та / або "доведено", щоб він не використовував стек простору без обмежень. Він може жити всередині певного мінімального обсягу пам’яті, а таких речей, як «OOM Killer» не існує, оскільки вони, очевидно, ніколи не потрібні. Деякі особливості гуферу раннього FORTRAN випливають із цього типу вимог. Коли ви складали програму FORTRAN II, ви точно знали, скільки стека і скільки купи це потрібно, оскільки ви не могли повторити, і ви не могли динамічно виділити нічого.

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

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