Короткі характеристики найбільш поширених осрч




Сторінка3/8
Дата конвертації03.11.2017
Розмір0,73 Mb.
1   2   3   4   5   6   7   8

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. Завдання може знаходитися в одному з п'яти станів: виконання; готовність до виконання (управління може бути передано задачі); зупинка (завдання заблокована); сплячий режим (створена, але не запущена завдання); відсутність завдання (завдання не створена або видалена).

Ядро реального часу RTEMS підтримує 255 рівнів пріоритетів. Чим більше значення пріоритету, тим більше привілейованої є завдання. Кількість завдань, що мають однаковий пріоритет, не обмежена. Кожне завдання завжди має будь-якої рівень пріоритету, початкове значення якого присвоюється при створенні завдання і в подальшому може бути змінено. Режим виконання завдання визначається такими параметрами: витісняємість; обробка асинхронних запитів ASR (Asynchronous Signal Request); квантування часу; рівень переривання. Ці параметри використовуються для розподілу процесорного часу і зміни контексту завдання. Вони задаються користувачем при компіляції системи.

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

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

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

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

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

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

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

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

Менеджер вводу / виводу. Забезпечує певний механізм доступу до драйверів пристроїв. Якщо в системі використовується цей менеджер, то в конфігураційної Таблиця повинна бути вказана адреса таблиці драйверів пристроїв, яка містить вхідні точки кожного драйвера. Драйвер може мати такі точки входу: ініціалізації, відкриття, закриття, читання, запису, контролю.

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

Менеджер таймерів забезпечує роботу з таймерами: створення та видалення таймерів, доступ до таймерам, запуск підпрограм по події / сигналу від таймера. Цей менеджер може бути використаний для створення охоронного таймера.

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

RTEMS не підтримує динамічну завантаження додатків і модулів, тому сферою її застосування є вбудовувані системи, в яких не передбачається часта модифікація програмного забезпечення. ОСРВ RTEMS забезпечує досить слабку підтримку файлових систем, що обмежує область її можливого застосування в сфері систем централізованого збору та зберігання даних стандартними високорівневим засобами. На справжній момент RTEMS підтримує тільки файлові системи IMFS і TFTP, що явно недостатньо. Тому для створення на базі RTEMS файл-серверів потрібна розробка спеціального протоколу. Розуміючи цю проблему, розробники RTEMS ведуть активну роботу з реалізації систем підтримки широко використовуваних файлових систем (у першу чергу мережевих). У RTEMS фактично відсутні резидентні засоби відлагодження. Є тільки стандартні функції rtems_panic і printf, які дозволяють виводити налагоджувальну інформацію на термінал у процесі роботи системи. Слід, однак, відзначити, що наявність потужних засобів крос-розробки робить цей недолік не дуже істотним.


4. ChorusOS

Операційна система ChorusOS - це розширювана вбудовувана ОС, широко застосовувана в телекомунікаційній індустрії. В даний час цей бренд розвивається і поширюється корпорацією Sun Microsystems [CHORUSOS]. Для компонування і розгортання ОС ChorusOS на конкретних телекомунікаційних платформах Sun Microsystems пропонує використовувати середовище розробки Sun Embedded Workshop. Корпорація Sun Microsystems представляє ОС ChorusOS як вбудовується основу для Sun'овской мережі, керованої сервісами (Sun's Service-Driven Network). У поєднанні з широким набором сервісів, повною інтеграцією ПЗ та апаратури, зручним адмініструванням і підтримкою Java-технології, яка присвячена потребам телекомунікації, ОС ChorusOS дає можливість ефективно розгортати нові можливості та програми, підтримуючи надійність і функціональність сучасних мереж.

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

ОС ChorusOS моделює три сорти додатків:

POSIX-процеси становлять більшість додатків ChorusOS; ці програми мають доступ до чисто POSIX API, декільком POSIX-подібним розширеним API і невеликого числа обмежених системних викликів мікроядра,

Актори ChorusOS - ці програми виконуються над мікроядром і обмежуються API мікроядра, актори включають драйвери, події підсистем і протокольні стеки,

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

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

kern - реалізує інтерфейс мікроядра і містить актор KERN, допоміжну бібліотеку і заголовні файли,

менеджер приватних даних (pd) реалізує інтерфейс між підсистемами мікроядра,

менеджер постійної пам'яті (pmm) реалізує інтерфейс постійної пам'яті,

core executive забезпечує істотну частину підтримки реального часу.

Компонент диспетчера ядра (core executive) забезпечує наступну функціональність

підтримка численних незалежних додатків,

підтримка користувацьких і системних додатків,

підтримка актора - одиниці модулярізаціі додатків,

підтримка одиниці виконання - потоку,

операції управління потоками,

управління Local Access Point (LAP),

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

мінімальний сервіс управління переривань.

У core executive відсутній управління такими сутностями, як синхронізація, планування, час, пам'ять. Політики керування цими поняттями забезпечуються додатковими компонентами, які вибираються користувачем в залежності від вимог апаратних і програмних засобів. Core executive завжди присутній у виконуваному примірнику ОС ChorusOS, інші компоненти конфігуруються і додаються по необхідності. Розмір резидентної частина ядра складає 10Kb.

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

Необов'язкові компоненти ОС ChorusOS 5.0 розбиваються відповідно до функціональністю:

Управління діяльністю (Actor management) включає підтримку розширення режиму користувача, динамічні бібліотеки, управління стиснутими файлами;

Планування (Scheduling) включає планування в стилі FIFO (first-in-first-out), різностильних планування (multi-class scheduling), циклічне планування (round-robin), планування в режимі реального часу;

Управління пам'яттю включає, крім розподілу пам'яті, підтримки апаратного захисту і підкачки, ще й статистику мікроядра, події системи Solaris, метрики операційної системи;

Працездатність (High Availability) включає гарячий рестарт, сторожовий таймер (Watchdog timer), чорний ящик, дамп системи;

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

Управління часом включає періодичні таймери, потоковий віртуальний таймер, дата і час, датчик реального часу, змінні оточення;

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

Інструментальна підтримка включає системну журналізацію, реєстрацію помилок, підтримку профілювання і контрольних точок, моніторинг системи, налагодження системи, дамп ядра;

Підтримка мови C включає командний інтерпретатор на цільовому комп'ютері, віддалений shell;

Підтримка файлової системи включає іменовані канали, NFS-клієнт, NFS-сервер, файлові системи MS-DOS, PDE, / proc, UFS, ISO9000;

Управління введенням / виводом включає підтримку драйверів деяких пристроїв;

Мережева підтримка включає підтримку деяких мережевих протоколів.

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

ОС ChorusOS 5.0 лежить в основі операційного середовища Solaris і підтримує такі цільові платформи:

UltraSPARC II (CP1500 і CP20x0),

Intel x86, Pentium,

Motorola PowerPC 750 і сімейство процесорів 74x0 (mpc7xx),

Motorola PowerQUICC I (mpc8xx) і PowerQUICC II (mpc8260) (мікроконтролери).


Рис.3. Архітектура ChorusOS.


1   2   3   4   5   6   7   8


База даних захищена авторським правом ©uchika.in.ua 2016
звернутися до адміністрації

    Головна сторінка