Лекції - Частина 3-1

n1.doc (1 стор.)
Оригінал



3. Огляд деяких операційних систем реального часу


До недавнього часу для вирішення завдань автоматизації в основному використовувалися операційні системи (ОС) реального часу (РВ). Це компактні системи, засновані на мікроядерної архітектурі, - такі так VxWorks, OS -9, PSOS, QNX, LynxOS. Ці системи володіють швидким часом реакції на події і переривання, компактністю коду, хорошою встраїваємость та іншими перевагами, характерними для операційних систем з микроядерной архітектурою.

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

Звичайно, без ОСРВ поки не можна обійтися в багатьох застосуваннях, і вони виправдовують себе в високо технологічних проектах (тренажери, унікальне обладнання) або при масовій кількості поставок (стільникові телефони, аналізатори). У той же час існують завдання, для вирішення яких потрібна підтримка реального часу, але при цьому великі витрати на розробку не окупляться.

Напевно, класичні операційні системи реального часу залишаються найнадійнішим рішенням при побудові систем жорсткого реального часу підвищеної надійності. Однак систем з такими вимогами не так багато в світі, який нас оточують. Чи можливі інші рішення?

В даний час відбувається активний процес злиття універсальних OC та ОС реального часу. На програмному ринку з'являються різні інструменти підтримки режиму реального часу, що вбудовуються в звичні операційні системи. Цей клас продуктів має значними перевагами з боку користувачів і програмістів, поєднуючи в собі звичний для користувача інтерфейс, засоби розробки програм і API-інтерфейс реального часу. Правда, поки що немає підстав стверджувати, що подібні рішення повністю замінять собою звичайні системи реального часу. У традиційних ОС реального часу є поки велика перевага - встраїваємость і компактність. Однак і на цьому ринку відбуваються зміни: корпорація Microsoft випустила Windows NT Embedded (NTE), використання якої дозволяє "стиснути" NT до 8-10 Мбайт. Вже з'явилися і продукти реального часу, розраховані на цю операційну систему, наприклад, RTX.

А що ж Unix? Традиційно, у багатьох ОС реального часу використовуються підмножини API-інтерфейсів Unix, що зближує ці операційні системи з Unix. Існують також повнофункціональні Unix-системи, що підтримують режим реального часу.

3.1. Linux реального часу


Бурхливе зростання популярності Linux спонукає розробників уважніше придивитися до цієї операційній системі [11]. У Linux багато достоїнств: відкритість коду; велика кількість супутнього програмного забезпечення, поки в основному орієнтованого на серверні застосування; наявність непоганий документації на API-інтерфейс і ядро операційної системи; робота на процесорах різних класів. В даний момент ця ОС готова до стабільної роботи, а відкритість її вихідних текстів і архітектури поряд зі зростаючою популярністю змушує програмістів переносити свої напрацювання на багато апаратні платформи: SGI, IBM, Intel, Motorol a і т.д. Зокрема, Motorola активно працює у своїй традиційній сфері вбудованих систем і просуває на ринок продукт LinuxEmbedded. Взагалі кажучи, Linux прекрасно підходить для компактних вбудованих застосувань; на ринку вже з'явилися постачальники, що пропонують усічені варіанти цієї операційної системи, які займають 1-2 Мбайт на жорсткому диску. В якості прикладу можна навести проект Linux Router Project.

Для задач реального часу співтовариство розробників Linux активно застосовує спеціальні розширення - RTLinux, KURT і UTIME, що дозволяють отримати стійку середу реального часу. RTLinux являє собою систему "жорсткого" реального часу, а KURT (KU Real Time Linux) відноситься до систем "м'якого" реального часу. Linux-розширення UTIME, що входить до складу KURT, дозволяє домогтися збільшення частоти системних годин, що призводить до більш швидкому переключенню контексту завдань.

Проект KURT характеризується мінімальними змінами ядра Linux і передбачає два режими роботи - нормальний (normal mode) і режим реального часу (real-time mode). Процес, що використовує бібліотеку API-інтерфейсів KURT, в будь-які моменти часу може перемикатися між цими двома режимами. Програмний пакет KURT оформлений у вигляді окремого системного модуля Linux - RTMod, який стає додатковим планувальником реального часу. Даний планувальник доступний в декількох варіантах і може тактіроваться від будь-якого системного таймера або від переривань стандартного паралельного порту. Так як всі процеси працюють у спільному просторі процесів Linux, програміст використовує у своїх програмах стандартні API-інтерфейси Linux і може перемикатися з одного режиму в інший по подіях, або в певних місцях програми. При перемиканні в режим реального часу всі процеси в системі "засипають" до моменту звільнення гілки процесу реального часу. Це досить зручно при реалізації завдань з великим об'ємом обчислень, за своєю суттю вимагають механізмів реального часу, наприклад у задачах обробки аудіо-та відеоінформації.

Стандартно такти планувальника RTMod задаються від системного таймера - час перемикання контексту завдань реального часу (time slice) дорівнює 10 мс. Використовуючи ж KURT спільно з UTIME, можна довести час перемикання контексту завдань до 1 мс. Переривання обробляються стандартним для ОС Linux чином - через механізм драйверів.

API-інтерфейс KURT розділяється на дві частини - прикладну і системну. Прикладна частина дозволяє програмісту керувати поведінкою процесів, а системний API-інтерфейс призначений для маніпулювання користувацькими процесами і програмування власних планувальників. Прикладна частина API-інтерфейсу KURT складається всього з чотирьох функцій:

set_rtparams дозволяє додати процес в ядро з маскою SCHED_KURT. Тільки процеси, чия політика в планувальнику встановлена ​​як SCHED_KURT, зможуть працювати в режимі реального часу;

get_num_rtprocs отримує ідентифікатор "rt_id" процесу з планувальника реального часу RTMod;

rt_suspend дозволяє призупинити планувальник реального часу;

get_rt_stats отримує статус процесу з таблиці планувальника процесів реального часу.

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

RTLinux - це доповнення до ядра Linux, що реалізовує режим "жорсткого" реального часу, який дозволяє управляти різними чутливими до часу реакції системи процесами. По суті справи, RTLinux - це операційна система, в якій маленьке ядро реального часу співіснує зі стандартним POSIX-ядром Linux.

Розробники RTLinux пішли по шляху запуску з ядра реального часу Linux-ядра як завдання з найменшим пріоритетом. У RTLinux всі переривання обробляються ядром реального часу, а в разі відсутності обробника реального часу - передаються Linux-ядра. Фактично Linux-ядро є простоює (idle) завданням операційної системи реального часу, що запускається тільки в тому випадку, якщо жодна задача реального часу не виконується. При цьому на Linux-задачу накладаються певні обмеження, які, втім, для програміста прозорі.

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

Всі апаратні переривання перехоплюються ядром операційної системи реального часу. Коли відбувається переривання, ядро RTLinux вирішує, що робити. Якщо це переривання має відношення до задачі реального часу, ядро ​​викликає відповідний обробник. В іншому випадку, чи якщо обробник реального часу говорить, що хоче розділяти це переривання з Linux, обробникові присвоюється стан очікування (pending). Якщо Linux зажадала дозволити переривання, то переривання, які перебувають у стані "pending", емулюються. Ядро RTLinux спроектовано таким чином, що ядру реального часу ніколи не доводиться очікувати звільнення ресурсу, зайнятого Linux-процесом (рис.3.1).


Рис.3.1. Механізм роботи RTLinux - Linux-розширення

жорсткого реального часу
Для обміну даними між операційними системами реального часу і Linux можуть використовуватися такі механізми:

поділювані області пам'яті;

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

Ключовий принцип побудови RTLinux - якомога більше використовувати Linux і якомога менше власне RTLinux. Дійсно, саме Linux піклується про ініціалізації системи і пристроїв, а також про динамічний виділенні ресурсів. "На плечі" RTLinux лягає тільки планування завдань реального часу і обробка переривань. Для простоти запуску в контексті ядра, збереження модульності і розширюваності системи процеси реального часу реалізовані у вигляді завантажуваних модулів Linux. Як правило, додаток реального часу з RTLinux складається з двох незалежних частин: процесу, виконуваного ядром RTLinux, і звичайного Linux-додатки.

Для ілюстрації роботи додатка реального часу розглянемо прикладної модуль, який використовує ядро реального часу RTLinux у вигляді завантажуваного модуля Linux:

# Define MODULE

# Include <linux / module.h>

/ * Необхідно для задач

реального часу * /

# Include <linux / rt_sched.h>

# Inlcude <linux / rt_fifo.h>

RT_TASK mytask;
У заголовку модуля визначається структура RT_TASK, яка містить покажчики на структури даних модуля, а також керуючу інформацію. У нашому випадку, для зв'язку між процесами, використовуються черги повідомлень FIFO (рис.3.2).

Модуль реального часу читає дані з пристрою і кладе їх в чергу повідомлень, звідки їх потім забирає звичайне додаток Linux.




Рис.3.2. Механізм межпроцессного зв'язку через черги повідомлень FIFO
Як і кожен модуль Linux-ядра, процес реального часу повинен виконати процедури ініціалізації і завершення аналогічні модулям Linux:
int init_module (void)

{

/ * Визначити номер

черги повідомлень * /

# Define RTFIFODESC 1

/ * Взяти локальний час * /

RTIME now = rt_get_time ()

rt_task_init (& mytask, mainloop,

RTFIFODESC, 3000, 4);

rt_task_make_periodic (& mytask,

now +1000, 25000);

return 0;

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

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




Навчальний матеріал
© ukrdoc.com.ua
При копіюванні вкажіть посилання.
звернутися до адміністрації