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

Операційна система реального часу (ОСРЧ, англ. 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].

Планування задач

Робота планувальника

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

Можлива ситуація, коли задача з низьким пріоритетом вже запущена, а планувальник отримує повідомлення, що інша задача з більш високим пріоритетом готова до запуску. Причиною цього може стати будь-яка зовнішня дія (переривання від устаткування), як, наприклад, зміна стану перемикача пристрою під керуванням ОСРЧ. У такій ситуації планувальник задач діє згідно підходу планування на основі пріоритетів таким чином. Задачі з низьким пріоритетом буде дозволено виконати до кінця поточну машинну команду (але не команду, описану в програмі мовою високого рівня), після чого виконання завдання призупиняється[7]. Далі запускається задача з високим пріоритетом. Після того, як вона відпрацьовує, планувальник запускає перервану першу задачу з машинної команди, наступної за останньою виконаною.

Щоразу, коли планувальник задач отримує сигнал про настання певної зовнішньої події (тригер), причина якого може бути як апаратна, так і програмна, він діє за таким [[алгоритм]ом[7]:

  1. Визначає, чи повинна поточна задача, що виконується, продовжувати працювати.
  2. Встановлює, яка задача повинна запускатися наступною.
  3. Зберігає контекст зупиненої задачі (щоб вона потім відновила роботу з місця зупинки).
  4. Встановлює контекст для наступного завдання.
  5. Запускає цю задачу.

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

Виконання задачі

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

  • задача виконується;
  • задача готова до виконання;
  • задача заблокована.

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

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

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

Алгоритми планування

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

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

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

Взаємодія між завданнями та розподіл ресурсів

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

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

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

Виділення пам'яті

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

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

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

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

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

Примітки
  1. С. Золотарев. Операционные системы реального времени для 32-разрядных микропроцессоров
  2. The Open Group The Single UNIX Specification, version 2
  3. What makes a good RTOS, Dedicated Systems Experts NV, June 11, 2001
  4. И. Б. Бурдонов, А. С. Косачев, В. Н. Пономаренко. Операционные системы реального времени п. 1. Введение: Особенности операционных систем реального времени
  5. А. А. Жданов. Операционные системы реального времени Архівовано 12 листопада 2017 у Wayback Machine.
  6. Е. Хухлаев. Операционные системы реального времени и Windows NT
  7. D. Kalinsky. Basic concepts of real-time operating systems. Архів оригіналу за 28 січня 2013.(англ.)
  8. А. А. Блискавицкий, С. В. Кабаев. Операционные системы реального времени (обзор)
  9. И. Б. Бурдонов, А. С. Косачев, В. Н. Пономаренко. Операционные системы реального времени п. 1.2. Планирование, приоритеты

Література
  • Зыль С. Операционная система реального времени 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.

Див. також
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.