Короткі характеристики найбільш поширених ОСРЧ (стр. 2 из 9)

Засоби портування. Всі апаратно-залежні частини VxWorks винесені в окремі модулі для того, щоб розробник вбудовуваної комп'ютерної системи міг сам портувати VxWorks на свій нестандартний цільовий комп'ютер. Цей комплект конфігураційних і ініціалізаціонних модулів називається BSP (Board Support Package) і поставляється для стандартних комп'ютерів (VME-процесор, PC або Sparcstation) у вихідних текстах. Розробник нестандартного комп'ютера може взяти за зразок BSP найбільш близького за архітектурі стандартного комп'ютера і портувати VxWorks на свій комп'ютер шляхом розробки власного BSP за допомогою BSP Developer's Kit.

Проміжне ПЗ (middleware). Модель компонентних об'єктів COM (Component Object Model) та її розширення для розподілених систем DCOM (Distributed COM) є стандартними інтерфейсами обміну між додатками для Windows. VxDCOM - DCOM для операційної системи VxWorks - це перша реалізація моделі розподілених компонентних об'єктів для систем реального часу. Тепер немає необхідності в розробці спеціалізованих драйверів вводу / виводу при інтеграції нижнього і верхніх рівнів розподіленої системи управління. VxDCOM підтримує також OPC-інтерфейси (OLE for Process Control), що дозволяє розробляти OPC-сервери для вбудованих систем, що працюють під управлінням ОСРВ VxWorks.

Файлова система для флеш-пам'яті. Файлова система TrueFFS призначена для емуляції жорсткого диска, що працює під управлінням файлових систем VxWorks: DOS-FS і NFS (Network File System). TrueFFS підтримує стандарт PCMCIA FTL (Flash Translation Level) і підтримує PC-cards, MiniatureCards і мікросхеми флеш-пам'яті Intel 28F0xx, AMD 29F0xx, і Samsung 29Vxx000.

2. QNX Neutrino RTOS

Операційна система QNX Neutrino Realtime Operating System (RTOS) [QNXNeutrino] корпорації QNX Software Systems є мікроядерного операційною системою, яка забезпечує багатозадачність з пріоритетами. QNX Neutrino RTOS має клієнт-серверну архітектуру. У середовищі QNX Neutrino кожен драйвер, додаток, протокол і файлова система виконуються поза ядром, у захищеному адресному просторі. У разі збою будь-якого компонента він може автоматично перезапуск без впливу на інші компоненти або ядро. Хоча система QNX є конфігурується, тобто окремі модулі можна завантажувати статично або динамічно, не можна сказати, що вона використовує підхід, заснований на компонентах. Всі модулі покладаються на базове ядро і спроектовані таким чином, що не можуть використовуватися в інших середовищах.

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

Ядро QNX Neutrino RTOS виконується на рівні 0, керуючі програми і драйвери пристроїв виконуються на рівні 1 та 2, здійснюючи операції вводу / виводу. Програми виконуються на рівні 3.

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

Володіючи які витісняють мікроядром і планувальником з пріоритетним обслуговуванням, QNX Neutrino RTOS здатна швидко і з високою передбачуваністю реагувати на події реального часу. Високопріоритетні потоки обробляють дедлайни своєчасно навіть при великій завантаженні системи (див. мал.2)

Рис.2. Продуктивність реального часу QNX Neutrino RTOS.

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

3. RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) - це некомерційна операційна система реального часу для глибоко вбудованих систем [RTEMS]. Розробник системи компанія OAR (On-Line Applications Research Corporation, США). Система була створена на замовлення міністерства оборони США для використання в системах управління ракетними комплексами. Система розробляється для багатопроцесорних систем на основі відкритого вихідного коду на противагу аналогічним системам з закритим кодом. Система розрахована на платформи MS-Windows і Unix (GNU / Linux, FreeBSD, Solaris, MacOS X).

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

мультизадачність обробка;

робота в гомогенних і гетерогенних системах;

планування, кероване подіями, на основі пріоритетів;

планування з монотонною швидкістю;

взаємодію задач і синхронізація;

пріоритетне спадкування;

управління у відповідь перериванням;

розподіл динамічної пам'яті;

конфігурування системи для уповноважених користувачів;

переносимість на багато цільові платформи.

Ядро RTEMS відповідає за управління основною пам'яттю комп'ютера і віртуальною пам'яттю виконуваних процесів, за керування процесором і планування розподілу процесорних ресурсів між спільно виконуваними процесами, за управління зовнішніми пристроями і, нарешті, за забезпечення базових засобів синхронізації та взаємодії процесів. При цьому ядро використовує відповідні менеджери. До складу RTEMS входить набір наступних менеджерів: ініціалізації, завдань, переривань, годинника реального часу, таймер, семафорів, повідомлень, подій, сигналів, розділів, регіонів, двухпортової пам'яті, вводу / виводу, невиправних помилок, монотонною частоти, розширень користувача, багатопроцесорними. Прив'язка ОСРВ до апаратури проводиться за допомогою спеціальної бібліотеки підпрограм BSP (board support package) і спеціалізованих підпрограм для різних архітектур. До складу BSP входять програма ініціалізації апаратури і драйвери пристроїв. Підтримка в RTEMS мультипроцесорних систем дозволяє використовувати її для управління як однорідними, так і неоднорідними системами Ядро RTEMS автоматично враховує відмінності в архітектурі використовуваних процесорів, виконуючи у разі необхідності перестановку байтів і інші процедури. Це дозволяє здійснювати перехід на інше сімейство процесорів без значних змін системи.

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

У ОСРВ RTEMS реалізуються наступні види міжпроцесорного взаємодії:

обмін даними між завданнями;

обмін даними між завданнями і програмами обробки переривань;

синхронізація між завданнями;

синхронізація між завданнями і програмами обробки переривань.

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

Менеджер семафорів. RTEMS підтримує стандартні виконавчі і семафори з лічильниками, що забезпечують синхронізацію і монопольний доступ до ресурсів.

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

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

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

Менеджер завдань. Забезпечує повний набір функцій для створення, видалення і управління завданнями. З точки зору RTEMS, завданням є найменша послідовність команд, яка може самостійно конкурувати за використання системних ресурсів. Кожній задачі відповідає блок контролю завдання TCB (Task Control Block). Цей блок є структурою, яка містить всю інформацію, що стосується виконання завдання. У процесі ініціалізації RTEMS виділяє TCB для кожного завдання, що є в системі. Елементи TCB змінюються відповідно до системними викликами, які виконуються додатком у відповідь на зовнішні запити. Блок TCB - це єдина внутрішня структура даних RTEMS, доступна додатком через додаткові процедури користувача. При перемиканні задач у TCB зберігається контекст завдання. При поверненні управління задачі її контекст відновлюється. При перезапуску завдання вихідний контекст завдання відновлюється відповідно зі стартовим контекстом, що зберігається в TCB. Завдання може знаходитися в одному з п'яти станів: виконання; готовність до виконання (управління може бути передано задачі); зупинка (завдання заблокована); сплячий режим (створена, але не запущена завдання); відсутність завдання (завдання не створена або видалена).