Операційні системи реального часу - приклади. Відмінні риси осрв. VxWorks від компанії WindRiver

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

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

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

Системи жорсткого реального часу не допускають затримок реакції системи, оскільки це може призвести до:

  • втрати актуальності результатів
  • великим фінансовим втрат
  • аваріям та катастрофам

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

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

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

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

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

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

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

Відмінні риси ОСРВ

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

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

Архітектури ОСРВ

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

  • . ОС визначається як набір модулів, що взаємодіють між собою всередині ядра системи та надають прикладному ПЗ вхідні інтерфейсидля звернень до апаратури. Основний недолік цього принципу побудови ОС полягає у поганій передбачуваності її поведінки, викликаної складною взаємодією модулів між собою.
  • . Прикладне ПЗ має можливість отримати доступ до апаратури не тільки через ядро ​​системи та її послуги, а й безпосередньо. У порівнянні з монолітною така архітектура забезпечує значно більший ступінь передбачуваності реакцій системи, а також дозволяє здійснювати швидкий доступ прикладних додатківдо апаратури. Головним недоліком таких систем є відсутність багатозадачності.
  • Архітектура «клієнт-сервер». Основний її принцип полягає у винесенні сервісів ОС у вигляді серверів на рівень користувача та виконанні мікроядром функцій диспетчера повідомлень між клієнтами користувальницькими програмамита серверами - системними сервісами. Переваги такої архітектури:
  1. Підвищена надійність, оскільки кожен сервіс є, по суті, самостійним додатком та його легше налагодити та відстежити помилки;
  2. Поліпшена масштабованість, оскільки непотрібні послуги можуть бути виключені із системи без шкоди до її працездатності;
  3. Підвищена стійкість до відмов, оскільки «завислий» сервіс може бути перезапущений без перезавантаження системи.

Особливості ядра

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

Основні послуги

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

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

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

Відмінності від операційних систем загального призначення

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

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

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

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

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

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

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

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

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

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

Виконання завдання

У звичайних ОСРВ завдання може бути в 3-х можливих станах:

  1. Завдання виконується;
  2. Завдання готове до виконання;
  3. Завдання заблоковане.

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

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

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

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

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

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

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

  • Тимчасове блокування переривань
  • Двійкові семафори
  • Посилання сигналів

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

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

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

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

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

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

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

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

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

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

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

Примітки

Література

  • Зиль С.Операційна система реального часу QNX: від теорії до практики. - 2-ге вид. - СПб. : БХВ-Петербург, 2004. – 192 с. - ISBN 5-94157-486-Х
  • Зиль С. 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

Посилання

  • Огляд операційних систем реального часу (англ.)

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

Основними ресурсами є процесор (процесорний час), оперативна пам'ятьта периферійні пристрої.

Управління ресурсами зводиться до виконання таких завдань: спрощення доступу до ресурсів, розподіл їх між процесами.

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

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

В даний час існує велика різноманітність ОС, які класифікуються за такими ознаками:

o кількість користувачів, що одночасно обслуговуються системою;

o кількість процесів, які можуть одночасно виконуватися під керуванням ОС;

o тип доступу користувача до системи;

o тип апаратно-програмного комплексу.

Відповідно до першої ознаки розрізняються одно-і розраховані на багато користувачів ОС.

Друга ознака ділить ОС на одно- та багатозадачні.

Відповідно до третьої ознаки ОС поділяються на:

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

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

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

Четверта ознака ділить ОС на одно-і багатопроцесорні, мережеві та розподілені. Для розрахованих на багато користувачів і багатозадачних ОС важливим показником є ​​дисципліна обслуговування. Відповідно до цього розрізняють витісняючий та узгоджуючий режими багатозадачної роботи. При витісняючої організації виділенням задачам процесорного часу займається лише ОС (наприклад, кожної завдання процесор виділяється по черзі, причому на суворо фіксований проміжок часу, але можливе і пріоритетне обслуговування). Що стосується узгоджувальної організації кожне завдання, отримавши управління, сама визначає, коли їй " віддати " процесор іншого завдання. У випадку узгодження ефективніше і надійніше витіснення, але визначальним чинником під час реалізації програм стає те що, що дана програмамає монопольно використовувати процесорний час.

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

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

1.1 Що таке система реального часу

У Останнім часомвсе частіше доводиться стикатися із завданнями, що вимагають управління складними процесами чи обладнанням за допомогою ЕОМ. При цьому всі події у цих процесах відбуваються тоді, коли вони відбуваються. Комп'ютер може виконувати лише кінцеве число операцій у кінцевий час, тому виникає питання: а чи встигне комп'ютер з потрібною швидкістюобрахувати ситуацію та видати конкретні керуючі дії, які були б адекватні саме в певний моментчасу. На мій погляд, проблеми подібного роду виникли через використання дуже великих швидкостейв сучасне виробництво. Зрозуміло, що сигнали у природі поширюються з кінцевою швидкістю, швидкість роботи теж кінцева, тому миттєвих дій (викликаних певною подією) від комп'ютера очікувати неможливо. Адже яким би сучасним (читай – потужним за продуктивністю, тобто високою швидкістю обробки команд та операцій) комп'ютер би не був – йому фізично потрібні хоча б частки секунди, щоб виконати невелику просту групукоманд, а іноді цього часу надто багато. Таким чином, час реакції системи на деяку подію строго більший за нуль. Реальні завдання допускають деякого запізнення дій, і якщо система має час реакції менше, ніж ця допустима затримка, її справедливо називати системою реального часу. Бо в природі різні процесипротікають з різною швидкістю, одна і та сама система може укладатися в задані рамки для одного процесу і не вкладатися для іншого. Таким чином, про систему реального часу має сенс говорити стосовно конкретного завдання. Наприклад, щоб побудувати залежність середньої температури повітря за день від дня тижня як система реального часу зійде практично будь-який комп'ютер з практично будь-яким ПЗ. Якщо ж ми керуємо посадкою літака, де істотну роль відіграють мілісекунди, було б правильніше уважно вибирати апаратне та програмне забезпечення.

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

Реальний час (RTOS) - це ОС, яка гарантує певну здатність протягом заданого часового відрізка. Наприклад, вона може бути спроектована так, щоб відображати, що об'єкт став доступний для робота на складальному конвеєрі. Такі оболонки класифікуються на «жорсткі» та «м'які».

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

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

Перш ніж наводити приклади операційних систем реального часу, необхідно дати раду особливостям їх використання. Одні такі ОС створюються спеціального застосування, інші - більш загального. Крім того, деякі оболонки загального призначення також іноді використовуються для роботи в режимі реального часу. Як такого типу можуть бути загальновідомі Windows 2000 або IBM Microsoft/390. Тобто навіть якщо ОС не відповідає деяким вимогам, вона може мати характеристики, які дозволяють розглядати її як рішення для конкретного завдання додатку в режимі реального часу.

Приклади операційних систем та їх характеристика

У цілому нині реального часу мають такі характерні риси:

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

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

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

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

VxWorks від компанії WindRiver

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

VxWorks підтримує Intel (x86, включаючи новий варіант IntelQuarkSoC та x86-64), MIPS, PowerPC, SH-4 та ARM-архітектуру. Дана ОСРВ поставляється з потужним ядром, проміжним програмним забезпеченням, підтримкою платних додаткових пакетівта апаратних технологій сторонніх виробників. У своєму останньому випуску – VxWorks 7 – система була модернізована для модульності та апгрейду так, що ядро ​​ОС міститься окремо від проміжного програмного забезпечення, додатків та інших пакетів.

QNX Neutrino

Також класичні приклади операційних систем зазначеного типу – деякі Unix-подібні оболонки. Такою є QNX Neutrino, спочатку розроблена на початку 1980-х канадською компанією Quantum Software Systems. Зрештою, розробка була придбана BlackBerry у 2010 році. QNX є одним з перших комерційно успішних операційних систем мікроядра, яка використовується в різних пристроях, включаючи авто- та мобільні телефони.

FreeRTOS

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

Windows CE

Windows Embedded Compact – це операційна система підродини, розроблена корпорацією «Майкрософт» у рамках сімейства продуктів Windows Embedded. На відміну від Windows Embedded Standard, заснованого на Windows NT, ці приклади операційних систем використовують ексклюзивне гібридне ядро. Компанія «Майкрософт» надає ліцензії Windows CE для виробників оригінального обладнання, які можуть змінювати і створювати свої власні інтерфейси користувача, забезпечуючи технічну основудля цього.

p align="justify"> Операційні системи реального часу (ОСРВ) призначені для забезпечення інтерфейсу до ресурсів критичних за часом систем реального часу. Основним завданням у таких системах є своєчасність (timeliness) виконання обробки даних.

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

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

Прийнято розрізняти системи м'якого (soft) та жорсткого (hard) реального часу. У системах жорсткого реальногочасу нездатність забезпечити реакцію на будь-які події в заданий часведе до відмов та неможливості виконання поставленого завдання. У більшості російськомовної літератури такі системи називають системами з детермінованим часом. При практичному застосуваннічас реакції має бути мінімальним. Системами м'якого реального часу називаються системи, які під визначення " жорсткі " , т.к. у літературі чіткого визначення їм поки немає. Системи м'якого реального часу можуть не встигати вирішувати завдання, але це не призводить до відмови системи загалом. У системах реального часу необхідно запровадження деякого директивного терміну (в англомовній літературі – deadline), до закінчення якого завдання має обов'язково (для систем м'якого реального часу – бажано) виконатися. Цей директивний термін використовується планувальником завдань як призначення пріоритету завдання під час її запуску, і під час вибору завдання виконання.

Мартін Тіммерман сформулював такі необхідні вимоги для ОСРВ:

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

Протягом останніх 25-30 років структура операційних систем еволюціонувала від монолітної до багатошарової структури ОС і далі до архітектури клієнт-сервер. При монолітній структурі ОС складається з набору модулів і зміни одного модуля впливають на інші модулі. Чим більше модулів, тим більше хаосу під час експлуатації такої системи. Крім того, неможливо розподілити ОС у багатопроцесорній системі. У багатошаровій структурі зміни одного шару впливають сусідні шари; крім того, звернення через шар неможливе. Для систем реального часу має бути забезпечене пряме звернення до кожного шару ОС, інколи ж безпосередньо до апаратури.

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

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

Як правило, більшість сучасних ОСРВ побудовано на основі мікроядра (kernel або nucleus), яке забезпечує планування та диспетчеризацію завдань, а також здійснює їхню взаємодію. Незважаючи на зведення до мінімуму в ядрі абстракцій ОС, мікроядро все ж таки повинно мати уявлення про абстракцію процесу. Всі інші концептуальні абстракції операційних систем винесені за межі ядра, викликаються на запит і виконуються як додатки.

Відмінні рисиОСРВ від ОЗ загального призначення

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

ОС реального часу

ОС загального призначення

Основна задача

Встигнути зреагувати на події, що відбуваються на обладнанні

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

На що орієнтована

Обробка зовнішніх подій

Обробка дій користувача

Як позиціонується

Інструмент для створення конкретного апаратно-програмного комплексу реального часу

Сприймається користувачем як набір додатків, готових до використання

Кому призначена

Кваліфікований розробник

Користувач середньої кваліфікації

Системи жорсткого та м'якого реального часу

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

Системи жорсткого реального часу не допускають жодних затримок реакції системи за жодних умов, оскільки:

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

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

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

Ядро операційної системи

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

Монолітне ядро

Монолітне ядро ​​надає багатий набір обладнання абстракції. Усі частини монолітного ядра працюють у одному адресному просторі. Це така схема операційної системи, коли всі компоненти її ядра є складовими частинамиоднієї програми, використовують загальні структуриданих та взаємодіють один з одним шляхом безпосереднього виклику процедур. Монолітне ядро ​​- найстаріший спосіборганізації операційних систем Прикладом систем із монолітним ядром є більшість UNIX-систем.

Переваги: Швидкість роботи, спрощена розробка модулів

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

Деякі старі монолітні ядра, особливо систем класу UNIX/Linux, вимагали перекомпіляції за будь-якої зміни складу устаткування. Більшість сучасних ядердозволяють під час роботи підвантажувати модулі, які виконують частину функцій ядра. У цьому випадку компоненти операційної системи не є самостійними модулями, а складовими частинами однієї великий програми, Називається монолітним ядром (monolithic kernel), яке являє собою набір процедур, кожна з яких може викликати кожну. Усі процедури працюють у привілейованому режимі.

Мікроядро

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

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

Недоліки: Передача даних між процесами потребує накладних витрат.

Середовище виконання

Вимоги до середовища виконання систем реального часу наступні:

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

Поєднання описаних вище властивостей створює потужне та ефективне середовище виконання у реальному часі.

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

Ядро може забезпечувати обслуговування різних типів:

  • Міжзадачний обмін. Часто необхідно забезпечити передачу даних між програмами всередині однієї і тієї ж системи. Крім того, у багатьох додатках виникає необхідність взаємодії з іншими системами через мережу. Внутрішній зв'язокможе бути здійснена через систему передачі повідомлень. Зовнішній зв'язокможна організувати або через датаграму ( найкращий спосібдоставки), або лініями зв'язку (гарантована доставка). Вибір тієї чи іншої способу залежить від протоколу зв'язку.
  • Розподіл даних. У прикладних програмах, що працюють у реальному часі, найбільш тривалим є збір даних. Дані часто необхідні для роботи інших програм або потрібні системі для виконання своїх функцій. У багатьох системах передбачено доступ до загальним розділампам'яті. Широко поширена організація черги даних. Застосовується багато типів черг, кожен з яких має власні переваги.
  • Обробляє запити зовнішніх пристроїв. Кожна прикладна програма в реальному часі пов'язана із зовнішнім пристроєм певного типу. Ядро повинно забезпечувати служби вводу/виводу, що дозволяють прикладним програмам здійснювати читання з цих пристроїв та запис на них. Для додатків реального часу звичайним є наявність специфічного для цього додатку зовнішнього пристрою. Ядро має надавати сервіс, що полегшує роботу з драйверами пристроїв. Наприклад, давати можливість запису мовами високого рівня- таких, як Сі чи Паскаль.
  • Обробка особливих ситуацій. Особлива ситуація є подією, що виникає під час виконання програми. Вона може бути синхронною, якщо її виникнення передбачуване, як, наприклад, поділ на нуль. А може бути і асинхронною, якщо виникає непередбачувано, як, наприклад, падіння напруги. Надання можливості обробляти події такого типу дозволяє прикладним програмам реального часу швидко та передбачувано відповідати на внутрішні та зовнішні події. Існують два методи обробки особливих ситуацій - використання значень стану виявлення помилкових умов і використання оброблювача особливих ситуацій для переривання помилкових умов та його коригування.

Огляд архітектур ОСРВ

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

рівневі ОС (рисунок 2). Прикладом такої ОС є добре відома система MS-DOS. У системах цього класу прикладні програми могли отримати доступ до апаратури не лише за допомогою ядра системи або її резидентних сервісів, а й безпосередньо. За таким принципом будувалися ОСРВ багато років. Порівняно з монолітними ОС така архітектура забезпечує значно більший рівень передбачуваності реакцій системи, а також дозволяє здійснювати швидкий доступ прикладних додатків до апаратури. Недоліком

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

Рисунок 2. Архітектура рівневої ОС

Однією з найефективніших архітектур побудови операційних систем реального часу вважається архітектура клієнт – сервер. Загальна схемаОС працює за цією технологією представлена ​​малюнку 3. Основним принципом такої архітектури є винесення сервісів ОС як серверів до рівня користувача, а микроядро виконує функції диспетчера повідомлень між клієнтськими користувальницькими програмами і серверами – системними сервісами. Така архітектура дає масу плюсів з точки зору вимог до ОСРВ і систем, що вбудовуються. Серед цих переваг можна відзначити:

1. Підвищується надійність ОС, т.к. кожен сервіс є, по суті, самостійним додатком та його легше налагодити та відстежити помилки.

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

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

перезавантаження системи.

Малюнок 3. Побудова ОС із використанням архітектури клієнт-сервер

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

Список використаної литературы:

1) http://ua.wikipedia.org/wiki/Операційна_система_реального_часу

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5) http://www.ozon.ru/context/detail/id/3092042/