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

Готова до виконання - планувальник може вибрати її на виконання на підставі пріоритетів і правил витіснення,

Стані очікування - завдання чекає на появу події,

Призупинена - завдання в пасивному стані і чекає активації.

Рис.6. Модель станів завдання в ОС OSEK.

Кожне завдання має пріоритет. Стандарт ОС OSEK не обмежує максимальну кількість пріоритетів - це визначає реалізація.

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

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

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

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

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

8. OSE RTOS

Операційна система реального часу OSE RTOS, розроблена в корпорації ENEA, має ядро з пріоритетним плануванням [OSERTOS]. Це ядро сильно оптимізовано для забезпечення високої продуктивності і досить компактно для використання у вбудованих системах. OSE має архітектуру, керовану повідомленнями, з простими системними викликами. Передача повідомлень в OSE служить концептуальним шлюзом в розподілених багатопроцесорних вбудованих системах. Завдання посилають повідомлення один одному напряму через ОС без підтримки черг, поштових скриньок або інших проміжних механізмів. OSE RTOS підтримує підкачування, дублювання, динамічне оновлення коду і багато комунікаційні протоколи.

OSE RTOS пропонує три варіанти ядра, побудовані за одним принципом. OSE Epsilon - для глибоко вбудовуваної і SoC (system-on-chip) розробки. OSEck - компактне ядро для DSP. OSE Link Handler - для численних змішаних CPU / DSP проектів. Всі вони підтримують дуже маленька кількість системних викликів - від шести до восьми.

Архітектура OSE RTOS заснована на багатошарової моделі (рис.7).

Одиницею виконання в OSE RTOS є процес. Процеси можуть бути згруповані в блок, який може мати власний пул пам'яті. У ядрі OSE RTOS адресний простір належить сегменту, який може включати один або більше блоків. Відображення блоків у сегменти і відображення пулів у регіони дає можливість досягти повного захисту пам'яті та ізоляції програми. Блоки й пули можуть розміщуватися в одному або декількох сегментах.

OSE RTOS оперує різними типами і категоріями процесів.

Типи процесів:

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

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

пріоритетні процеси є найпоширенішими процесами в OSE RTOS і виконуються до тих пір, поки не будуть витіснені процесом переривання або процесом з більш високим пріоритетом,

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

Рис.7. Багатошарова архітектура OSE RTOS.

Під категоріями процесів у OSE RTOS розуміється поділ процесів на динамічні та статичні. Статичні процеси створюються ядром, коли система стартує, і існують на всьому протязі існування системи. Динамічні процеси створюються і знищуються під час виконання.

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

9. Contiki

Операційна система Contiki [DGV04] розроблена в Швеції (Swedish Institute of Computer Science) для систем з обмеженою пам'яттю. Система Contiki дозволяє динамічно завантажувати і відвантажувати програми та сервіси. З метою мінімізації розмірів операційної системи було спроектовано ядро Contiki, яке засноване на моделі управління подіями [HSW00].

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

Багатопотоковий режим з пріоритетами в системі Contiki реалізований з допомогою бібліотеки додатків, які виконуються над ядром, керованим подіями. Додатки, що забезпечують багатопоточну обробку, компонуються з виконуючим додатком у міру необхідності, тобто якщо воно явно вимагає багатопотокового моделі обчислень. Виконувати система Contiki розділяється на дві частини - серцевину (core) та завантажені програми. Серцевина (core) складається з власне ядра (kernel), базових сервісів і фрагментів бібліотек підтримки, в тому числі мовної підтримки часу виконання. Колективна функціональність реалізується через сервіси як деяка форма спільних бібліотек. Ці сервіси можна оновлювати або заміщати динамічно незалежно один від одного під час виконання, що, на думку розробників, веде до гнучку структуру системи.

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

Системи, керовані подіями, мають свої проблеми. Модель програмування, керована станами, складна для програмістів. До того ж не всі програми укладаються в кінцево-автоматну модель.

Contiki не підтримує жодних механізмів захисту, тому що апаратура, для якої вона проектувалася, не підтримує захист пам'яті.

Рис.8. Серцевина Contiki та завантажені програми.

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