Операційна система реального часу

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

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

Операційна система реального часу (ОСРЧ, англ. Real-time operating system, RTOS) — тип операційної системи, основним призначенням якої є надання необхідного та достатнього набору функцій для роботи систем реального часу на конкретному апаратному обладнанні.

Специфікація UNIX в редакції 2 дає таке визначення:

Реальний час в операційних системах — це здатність операційної системи забезпечити необхідний рівень сервісу при обмеженому часі на відповідь.^[1]

Оригінальний текст (англ.)

Realtime in operating systems: the ability of the operating system to provide a required level of service in a bounded response time.^[2]

Ідеальна ОСРЧ має передбачувану поведінку при всіх сценаріях навантаження, включаючи одночасні переривання і виконання потоків^[3].

Операційні системи реального часу іноді ділять на два типи — системи жорсткого реального часу та системи м'якого реального часу^[4].

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

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

В системі м'якого реального часу затримка реакції вважається відновлювальною помилкою, яка може привести до збільшення вартості результатів і зниження продуктивності, але не є фатальною. Прикладом може служити робота комп'ютерної мережі^[6]. Якщо система не встигла обробити черговий прийнятий пакет, це призведе до зупинки на стороні передачі та повторної відправки даних (в залежності від протоколу передачі даних). Дані при цьому не втрачаються, але продуктивність мережі знижується.

Основна відмінність систем жорсткого і м'якого реального часу можна охарактеризувати так: система жорсткого реального часу будь-коли запізниться з реакцією на подію, система м'якого реального часу не повинна відставати від реакції на подію^[6].

Часто операційною системою реального часу вважають лише систему, яка може бути використана для вирішення завдань жорсткого реального часу. Це визначення означає наявність у ОСРЧ необхідних інструментів, але також означає, що ці інструменти необхідно правильно використовувати^[5].

Більшість програмного забезпечення орієнтоване на «м'який» реальний час. Для подібних систем характерно:

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

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

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

Таблиця порівняння ОСРЧ і звичайних операційних систем^[5]:

У своєму розвитку ОСРЧ будувалися на основі наступних архітектур:

• Монолітна архітектура. ОС визначається як набір модулів, взаємодіючих між собою всередині ядра системи і надають прикладному ПО вхідні інтерфейси для звернень до апаратури. Основний недолік цього принципу побудови ОС полягає в поганій передбаченості її поведінки, викликаної складною взаємодією модулів між собою.
• Рівнева (шарова) архітектура. Прикладне ПО має можливість отримати доступ до апаратури не тільки через ядро системи та її сервіси, а й безпосередньо. У порівнянні з монолітною така архітектура забезпечує значно більший ступінь передбачуваності реакцій системи, а також дозволяє здійснювати швидкий доступ прикладних програм до апаратури. Головним недоліком таких систем є відсутність багатозадачності.
• Архітектура «клієнт-сервер». Основний її принцип полягає у винесенні сервісів ОС у вигляді серверів на рівень користувача та виконанні мікроядром функцій диспетчера повідомлень між клієнтськими користувача програмами і серверами — системними сервісами. Переваги такої архітектури:

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

Архітектури операційних систем реального часу

Монолітна архітектура	Рівнева (шарова) архітектура	Архітектура «клієнт-сервер»

Ядро ОСРЧ забезпечує функціонування проміжного абстрактного рівня ОС, який приховує від прикладного ПО специфіку технічного пристрою процесора (декількох процесорів) і пов'язаного з ним апаратного забезпечення^[7].

Зазначений абстрактний рівень надає для прикладного програмного забезпечення п'ять основних категорій сервісів^[7][8]:

• Керування задачами. Найголовніша група сервісів дозволяє розробникам застосунків проектувати програмні продукти у вигляді наборів окремих програмних фрагментів, кожен з яких може належати до своєї тематичної області^{[що це?]}, виконувати окрему функцію і мати свій власний квант часу, відведений йому для роботи. Кожен такий фрагмент називається задачею. Сервіси в розглянутій групі мають здатність запускати задачі і присвоювати їм пріоритети. Основний сервіс тут — планувальник задач. Він здійснює контроль над виконанням поточних завдань, запускає нові в відповідний період часу і стежить за режимом їх роботи.
• Динамічний розподіл пам'яті. Багато (але не всі) ядра ОСРЧ підтримують цю групу сервісів. Вона дозволяє завданням запозичувати області оперативної пам'яті для тимчасового використання в роботі програм. Часто ці області згодом переходять від завдання до завдання, і за допомогою цього здійснюється швидка передача великої кількості даних між ними. Деякі дуже малі за розміром ядра ОСРЧ, які передбачається використовувати в апаратних середовищах із суворим обмеженням на обсяг використовуваної пам'яті, не підтримують сервіси динамічного розподілу пам'яті.
• Управління таймерами. Так як вбудовані системи пред'являють жорсткі вимоги до тимчасових рамок виконання завдань, до складу ядра ОСРЧ включається група сервісів, які забезпечують управління таймерами для відстеження ліміту часу, протягом якого повинна виконуватися завдання. Ці сервіси вимірюють і задають різні проміжки часу (від 1 мкс і вище), генерують переривання після закінчення тимчасових інтервалів і створюють разові і циклічні будильники.
• Взаємодія між задачами та синхронізація. Сервіси даної групи дозволяють завданням обмінюватися інформацією та забезпечують її збереження. Вони також дають можливість програмним фрагментами узгоджувати між собою свою роботу для підвищення ефективності. Якщо виключити ці сервіси зі складу ядра ОСРЧ, то задачі почнуть обмінюватися спотвореною інформацією і можуть стати перешкодою для роботи сусідніх задач.
• Контроль пристрою введення-виведення. Сервіси цієї групи забезпечують роботу єдиного програмного інтерфейсу, взаємодіє з усім безліччю драйверів пристроїв, які є типовими для більшості вбудованих систем.

На додаток до сервісів ядра, багато ОСРЧ пропонують лінійки додаткових компонентів для організації таких високорівневих понять, як файлова система, мережева взаємодія, управління мережею, управління базою даних, графічний, призначений для користувача, інтерфейс і т. д. Хоча багато з цих компонентів набагато більше і складніше, ніж саме ядро ОСРЧ, вони, тим не менш, ґрунтуються на його сервісах. Кожен з таких компонентів включається через вбудовану систему, тільки якщо її сервіси необхідні для виконання вбудованої програми і тільки для того, щоб звести витрати пам'яті до мінімуму^[7].

Багато операційних систем загального призначення також підтримують зазначені вище сервіси. Однак ключовою відмінністю сервісів ядра ОСРЧ є детермінований, заснований на суворому контролі часу, характер їх роботи. В даному випадку під детермінованістю розуміється те, що для виконання одного сервісу операційної системи потрібно часовий інтервал свідомо відомої тривалості. Теоретично цей час може бути обчислено за математичними формулами, які повинні бути жорстко алгебраїчними і не повинні включати ніяких часових параметрів випадкового характеру. Будь-яка випадкова величина, яка визначає час виконання завдання в ОСРЧ, може викликати небажану затримку в роботі програми, тоді наступна задача не вкладеться в свій квант часу, що послужить причиною для помилки^[7].

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

Більшість ОСРЧ реалізує підхід планування на основі пріоритетів (preemptive priority scheduling). Кожній задачі користувача надається пріоритет відповідно до важливості завдання, формуючи чергу. Задача із найвищим пріоритетом отримує фіксований часовий інтервал (квант часу) для її часткового виконання. Після закінчення цього інтервалу процес повторюється: перевіряється поточний пріоритет завдань для виділення нового інтервалу часу. Таким чином, задача з найвищим пріоритетом буде виконуватись або до її завершення, або до моменту появи іншої задачі із більшим пріоритетом. ^[7]

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

У звичайних ОСРЧ задача може перебувати в трьох можливих станах:

• задача виконується;
• задача готова до виконання;
• задача заблокована більш пріоритетною задачею.

Велику частину часу основна маса завдань заблокована. Тільки одне завдання може виконуватися на центральному процесорі в поточний момент часу. У примітивних ОСРЧ список готових до виконання завдань, як правило, дуже короткий, він може складатися не більше ніж з двох-трьох найменувань.

Основна функція адміністратора ОСРЧ полягає в організації такого планувальника задач.

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

В даний час для вирішення завдання ефективного планування в ОСРЧ найбільш інтенсивно розвиваються два підходи^[9]:

• статичні алгоритми планування (RMS, Rate Monotonic Scheduling) — використовують пріоритетне витісняють планування, пріоритет надається кожній задачі до того, як вона почала виконуватися, перевага віддається задачам з найкоротшими періодами виконання;
• динамічні алгоритми планування (EDF, Earliest Deadline First Scheduling) — пріоритет задачам привласнюється динамічно, причому перевага віддається задачам з найбільш раннім граничним часом початку (завершення) виконання.

При великих навантаженнях системи EDF більш ефективний, ніж RMS.

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

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

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

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

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

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

Простий алгоритм з фіксованою довжиною ділянок пам'яті дуже добре працює в нескладних вбудованих системах.

Також цей алгоритм відмінно функціонує і в настільних системах, особливо тоді, коли під час обробки ділянки пам'яті одним ядром наступна ділянка пам'яті обробляється іншим ядром. Такі оптимізовані для настільних систем ОСРЧ, як Unison Operating System або DSPnano RTOS, можуть надавати таку можливість.

• Зыль С. Операционная система реального времени QNX: от теории к практике. — 2-е изд. — СПб. : БХВ-Петербург, 2004. — 192 с. — ISBN 5-94157-486-X.
• Зыль С. QNX Momentics. Основы применения. — СПб. : БХВ-Петербург, 2004. — 256 с. — ISBN 5-94157-430-4.
• Кёртен Р. Введение в QNX/Neutrino 2. — СПб. : Петрополис, 2001. — 512 с. — ISBN 5-94656-025-9.
• Ослэндер Д. М., Риджли Дж. Р., Рингенберг Дж. Д. Управляющие программы для механических систем: Объектно-ориентированное проектирование систем реального времени. — М. : Бином. Лаборатория знаний, 2004. — 416 с. — ISBN 5-94774-097-4.

• Операционные системы реального времени
• Цикл статей про FreeRTOS
• Обзор операционных систем реального времени^{[недоступне посилання з квітня 2019]}(англ.) ^{[недоступне посилання]}
• National Instruments, What is a Real-Time Operating System (RTOS)? (white paper) 2013(англ.)

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

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