При плануванні на основі пріоритетів необхідно вирішити дві обов'язкові проблеми:
забезпечити виконання процесу з найвищим пріоритетом,
не допустити інверсії пріоритетів, коли завдання з високими пріоритетами очікують ресурси, захоплені завданнями з більш низькими пріоритетами.
Для боротьби з інверсією пріоритетів у ОСРВ часто використовується механізм успадкування пріоритетів, однак при цьому доводиться відмовлятися від планування на основі RMS, оскільки пріоритети стають динамічними.
4. Пам'ять
Як вже згадувалося вище, затримка на перемикання контексту потоку безпосередньо залежить від конфігурації пам'яті, тобто від моделі захисту пам'яті. Розглянемо чотири найбільш поширених в ОСРВ моделі захисту пам'яті.
· Модель без захисту - системне і користувацьким простору не захищені один від одного, використовується два сегменти пам'яті: для коду та для даних; при цьому від системи не потрібно ніякого управління пам'яттю, не потрібно MMU (memory management unit - спеціальне апаратний пристрій для підтримки управління віртуальною пам'яттю).
· Модель захисту система / користувач - системне адресний простір захищене від адресного простору користувача, системні і користувальницькі процеси виконуються в загальному віртуальному адресному просторі, при цьому потрібно MMU. Захист забезпечується сторінковим механізмом захисту. Розрізняються системні і користувальницькі сторінки. Користувальницькі програми ніяк не захищені один від одного. Процесор знаходиться в режимі супервізора, якщо поточний сегмент має рівень 0, 1 або 2. Якщо рівень сегмента - 3, то процесор знаходиться в режимі користувача. У цій моделі необхідні чотири сегменти - два сегменти на рівні 0 (для коду та даних) і два сегменти на рівні 3. Механізм сторінкової захисту не додає накладних витрат, тому що захист перевіряється одночасно з перетворенням адреси, яке виконує MMU; при цьому операційна система не потребує в управлінні пам'яттю.
· Модель захисту користувач / користувач - до моделі система / користувач додається захист між користувацькими процесами; потрібно MMU. Як і в попередній моделі, використовується механізм сторінкової захисту. Усі сторінки позначаються як привілейовані, за винятком сторінок поточного процесу, які позначаються як користувацькі. Таким чином, виконують потік не може звернутися за межі свого адресного простору. ОС відповідає за оновлення прапора привілейованості для конкретної сторінки в таблиці сторінок при перемиканні процесу. Як і в попередній моделі використовуються чотири сегменти.
· Модель захисту віртуальної пам'яті - кожен процес виконується у своєї власної віртуальної пам'яті, потрібно MMU. У кожного процесу має свої власні сегменти і, отже, своя таблиця описувачів. ОС несе відповідальність за підтримку таблиць описувачів. Адресуються простір може перевищувати розміри фізичної пам'яті, якщо використовується сторінкова організація пам'яті спільно з підкачкою. Проте в системах реального часу підкачка зазвичай не застосовується через її непередбачуваності. Для вирішення цієї проблеми доступна пам'ять розбивається на фіксоване число логічних адресних просторів рівного розміру. Число одночасно виконуються процесів у системі стає обмеженим.
Фундаментальне вимога до пам'яті в системі реального часу полягає в тому, що час доступу до неї повинно бути обмежене (чи, іншими словами, передбачувано). Прямим наслідком стає заборону на використання для процесів реального часу техніки виклику сторінок за запитом (підкачка з диска). Тому системи, що забезпечують механізм віртуальної пам'яті, повинні вміти блокувати процес в оперативній пам'яті, не допускаючи підкачки. Отже, підкачка недопустима в ОСРВ, тому що непередбачувана.
Якщо підтримується сторінкова організація пам'яті (paging), відповідне відображення сторінок у фізичні адреси повинно бути частиною контексту процесу. Інакше знову з'являється непередбачуваність, неприйнятна для ОСРВ.
Для процесів, що не є процесами жорсткого реального часу, можливе використання механізму динамічного розподілу пам'яті, однак при цьому ОСРВ повинна підтримувати обробку таймауту на запит пам'яті, тобто обмеження на передбачуване час очікування.
У звичайних ГР при використанні механізму сегментації пам'яті для боротьби з фрагментацією застосовується процедура ущільнення після збирання сміття. Однак такий підхід непридатний в середовищі реального часу, оскільки під час ущільнення переміщувані задачі не можуть виконуватися, що веде до непередбачуваності системи. У цьому полягає основна проблема застосовності об'єктно-орієнтованого підходу до систем реального часу. До тих пір, поки проблема ущільнення не буде вирішена, C + + і JAVA залишаться не самим кращим вибором для систем жорсткого реального часу.
У системах жорсткого реального часу зазвичай застосовується статичний розподіл пам'яті. У системах м'якого реального часу можливо динамічний розподіл пам'яті, без віртуальної пам'яті і без ущільнення.
5. Переривання
При описі управління переривань зазвичай розрізняють дві процедури, а саме:
програма обробки переривання (ISR - interrupt servicing routine) - програма низького рівня в ядрі з обмеженими системними викликами,
потік обробки переривання (IST - interrupt servicing thread) - потік рівня програми, який управляє перериванням, з доступом до всіх системним викликам.
Зазвичай ISR реалізуються виробником апаратури, а драйвери пристроїв виконують управління переривань за допомогою IST. Потоки обробки переривань діють як будь-які інші потоки і використовують ту ж саму систему пріоритетів. Це означає, що проектувальник системи може надати IST більш низький пріоритет, ніж пріоритет потоку програми.
6. Годинники і таймери
У ОСРВ використовуються різні служби часу. Операційна система відстежує поточний час, в певний час запускає завдання і потоки і припиняє їх на певні інтервали. У службах часу ОСРВ використовуються годинник реального часу. Зазвичай використовуються високоточні апаратні годинник. Для відліку часових інтервалів на основі годин реального часу створюються таймери.
Для кожного процесу й потоку визначаються годинник процесорного часу. На базі цих годин створюються таймери; які вимірюють перевитрата часу процесом або потоком, дозволяючи динамічно виявляти програмні помилки або помилки обчислення максимально можливого часу виконання. У високонадійних, критичних до часу системах важливо виявлення ситуацій, при яких завдання перевищує максимально можливий час свого виконання, тому що при цьому робота системи може вийти за рамки допустимого часу відгуку. Годинники часу виконання дозволяють виявити виникнення перевитрати часу й активізувати відповідні дії по обробці помилок.
Більшість ОСРВ оперують відносним часом. Щось відбувається "до" і "після" деякого іншої події. У системі, повністю керованої подіями, необхідний часовий механізм (ticker), тому що там немає квантування часу (time slicing). Однак, якщо потрібні тимчасові мітки для деяких подій або необхідний системний виклик типу "чекати одну секунду", то потрібний тактовий генератор і / або таймер.
Синхронізація в ОСРВ здійснюється за допомогою механізму блокування (або очікування) до настання деякого події. Абсолютна час не використовується.
Реалізації в ОСРВ інших концептуальних абстракцій подібні їх реалізація в традиційних ОС.
7. Стандарти ОСРВ
Великі розходження в специфікаціях ОСРВ і величезна кількість існуючих мікроконтролерів висувають на передній план проблему стандартизації в області систем реального часу.
Найбільш раннім і поширеним стандартом ОСРВ є стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Початковий варіант стандарту POSIX з'явився в 1990 р. і був призначений для UNIX-систем, перші версії яких з'явилися в 70-х роках минулого століття. Специфікації POSIX визначають стандартний механізм взаємодії прикладної програми і операційної системи і в даний час включають набір більш ніж з 30 стандартів. Для ОСРВ найбільш важливі сім з них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), але широку підтримку в комерційних ОС отримали тільки три перших.
Незважаючи на явно застарілі положення стандарту POSIX і велику затребуваність оновлень стандартизації для ОСРВ, помітного просування в цьому напрямку не спостерігається.
Деякі найбільш успішні компанії в області систем реального часу оголошують про своє рішення прийняти в якості стандарту специфікації одній зі своїх просунутих ОСРВ. Так вчинила компанія TRON (the RTOS Nucleus), яка в 1987р. випустила в світ перші ITRON специфікації - ITRON1. Далі в 1989р. вона розробила і випустила специфікації μITRON для 8 - і 16 - бітових мікроконтролерів, а також специфікації ITRON2 для 32-бітових процесорів. ОСРВ ITRON описується нижче у відповідному розділі. Цей стандарт є дуже поширеним в Японії.
Військова і аерокосмічна галузі висувають жорсткі вимоги до обчислювальних засобів, що впливає на ступінь безпеки цільової системи. В даний час є такі стандарти для ОСРВ в авіації - стандарт DO-178B і стандарт ARINC-653. Оскільки ці стандарти розроблені в США, варто відзначити ще європейський стандарт ED-12B, який є аналогом DO-178B.
Поширеним також є стандарт OSEK / VDX [OSEK], який спочатку розвивався для систем автомобільної індустрії.
POSIX
Стандарт POSIX був створений як стандартний інтерфейс сервісів операційних систем. Цей стандарт дає можливість створювати Переносимі програми. Згодом цей стандарт був розширений особливостями режиму реального часу [POSIX].
Специфікації POSIX задають стандартний механізм взаємодії програми і ОС. Необхідно відзначити, що стандарт POSIX тісно пов'язаний з ОС Unix; тим не менш, розробники багатьох ОСРВ намагаються витримати відповідність цьому стандарту. Відповідність стандарту POSIX для ОС і апаратної платформи повинне бути сертифіковане за допомогою прогону на них тестових наборів [POSIXTestSuite]. Однак, якщо ОС не є Unix-подібної, витримати це вимога стає непростим завданням. Тестові набори існують тільки для POSIX 1003.1a. Оскільки структура POSIX є сукупністю необов'язкових можливостей, постачальники ОС можуть реалізувати лише частина стандартного інтерфейсу, і при цьому говорити про POSIX-компліантності своєї системи.