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

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

Архітектура TinyOS об'єднує таке звичну складову, як планувальник завдань (scheduler), і оригінальне поняття - компонентний граф. Термін "компонент" тут одночасно і відповідає загальноприйнятому розумінню, і суттєво розширює його. Так, інтерфейс компонента TinyOS складається з двох множин - верхнього, що надається цим компонентом, і нижнього, необхідного для його функціонування. Кожне з цих множин містить описи команд і подій - синхронних і асинхронних процесів.

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

Написана TinyOS з використанням структурованого підмножини мови C. Використання статичного розподілу пам'яті дозволяє визначати вимоги до пам'яті на рівні компіляції та уникати накладних витрат, пов'язаних з динамічним розподілом. Крім того, цей підхід дозволяє скорочувати час виконання завдяки статичному розміщення змінних під час компіляції замість доступу до них за вказівником під час виконання.

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

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

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

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

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

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

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

7. OSEK / VDX

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

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

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

Завдання в ОС OSEK може бути

базової або розширеної,

витісняється або невитискаючої.

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

Рис.5. Рівні обробки в ОС OSEK.

Концепція двох типів завдань зажадала введення нового поняття - клас відповідності (conformance class) для опису своєрідною реалізації ОС OSEK і системних сервісів. Визначаються чотири класи відповідності - два для базового відповідності (BCC1 і BCC2 - Basic conformance Classes 1 і 2) і два для розширеного (ECC1 і ECC2 - Extended Conformance Classes 1 і 2). Реалізації, які відповідають базовим класам, вимагають використання тільки базових завдань, у той час як для розширених класів потрібні як розширені, так і базові завдання. Числа 1 і 2 в іменах класів вказують кількість запитів на завдання для базових завдань і кількість завдань на пріоритет для всіх завдань. Таким чином, в BCC1 і ECC1 є тільки одне завдання на пріоритет, і базові завдання можуть бути запитані тільки один раз. У BCC2 і ECC2 допускається множинність завдань на пріоритет і множинне запрашіваніе базових завдань.

Кожна задача повинна знаходитися в одному з чотирьох станів

Виконуються - тільки одне завдання може бути в цьому стані,