Відмінності між версіями «Операційна система реального часу»
| (не показано одну проміжну версію цього учасника) | |||
| Рядок 14: | Рядок 14: | ||
[[Файл:Снимокааааа.PNG |1101 × 212 ]] | [[Файл:Снимокааааа.PNG |1101 × 212 ]] | ||
<h2>Стандарти ОСРЧ</h2> | <h2>Стандарти ОСРЧ</h2> | ||
| + | Великі розходження в специфікаціях ОСРЧ і величезна кількість існуючих мікроконтролерів висувають на передній план проблему стандартизації в області систем реального часу. | ||
| + | |||
| + | Найбільш раннім і поширеним стандартом ОСРЧ є '''стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1'''). Початковий варіант стандарту POSIX з'явився в 1990 р. і був призначений для UNIX-систем, перші версії яких з'явилися в 70-х роках минулого століття. Специфікації POSIX визначають стандартний механізм взаємодії прикладної програми і операційної системи і в даний час включають набір більш ніж з 30 стандартів. Для ОСРЧ найбільш важливі сім з них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), але широку підтримку в комерційних ОС отримали тільки три перших. | ||
| + | |||
| + | Незважаючи на явно застарілі положення стандарту POSIX і велику затребуваність оновлень стандартизації для ОСРЧ, помітного просування в цьому напрямку не спостерігається. | ||
| + | |||
| + | Деякі найбільш успішні компанії в області систем реального часу оголошують про своє рішення прийняти в якості стандарту специфікації одній зі своїх просунутих ОСРЧ. Так вчинила компанія '''TRON (the RTOS Nucleus)''', яка в 1987р. випустила в світ перші ITRON специфікації - '''ITRON1'''. Далі в 1989р. вона розробила і випустила специфікації μITRON для 8 - і 16 - бітових мікроконтролерів, а також специфікації ITRON2 для 32-бітових процесорів. ОСРВ ITRON описується нижче у відповідному розділі. Цей стандарт є дуже поширеним в Японії. | ||
| + | |||
| + | Військова і аерокосмічна галузі висувають жорсткі вимоги до обчислювальних засобів, що впливає на ступінь безпеки цільової системи. В даний час є такі стандарти для ОСРВ в авіації - стандарт DO-178B і стандарт ARINC-653. Оскільки ці стандарти розроблені в США, варто відзначити ще європейський стандарт ED-12B, який є аналогом DO-178B. | ||
| + | |||
| + | Поширеним також є '''стандарт OSEK / VDX [OSEK]''', який спочатку розвивався для систем автомобільної індустрії. | ||
| + | |||
| + | '''POSIX''' | ||
| + | Стандарт POSIX був створений як стандартний інтерфейс сервісів операційних систем. Цей стандарт дає можливість створювати Переносимі програми. Згодом цей стандарт був розширений особливостями режиму реального часу [POSIX]. | ||
| + | |||
| + | Специфікації POSIX задають стандартний механізм взаємодії програми і ОС. Необхідно відзначити, що стандарт POSIX тісно пов'язаний з ОС Unix; тим не менш, розробники багатьох ОСРВ намагаються витримати відповідність цьому стандарту. Відповідність стандарту POSIX для ОС і апаратної платформи повинне бути сертифіковане за допомогою прогону на них тестових наборів [POSIXTestSuite]. Однак, якщо ОС не є Unix-подібної, витримати це вимога стає непростим завданням. Тестові набори існують тільки для POSIX 1003.1a. Оскільки структура POSIX є сукупністю необов'язкових можливостей, постачальники ОС можуть реалізувати лише частина стандартного інтерфейсу, і при цьому говорити про POSIX-компліантності своєї системи. | ||
| + | |||
| + | Незважаючи на те, що стандарт POSIX виріс з Unix'а, він зачіпає основоположні абстракції операційних систем, а розширення реального часу застосовні до всіх ОСРЧ. | ||
| + | |||
| + | До теперішнього часу стандарт POSIX розглядається як сімейство споріднених стандартів: '''IEEE Std 1003.n''' (де n - це номер). | ||
| + | |||
| + | '''Стандарт 1003.1a (OS Definition)''' містить базові інтерфейси ОС - підтримку єдиного процесу, підтримку багатьох процесів, управління завданнями, сигналами, групами користувачів, файловою системою, файловими атрибутами, управління файловими пристроями, блокуваннями файлів, пристроями вводу / виводу, пристроями спеціального призначення, системними базами даних, каналами, чергами FIFO, а також підтримку мови C. | ||
| + | |||
| + | '''Стандарт 1003.1b (Realtime Extensions)''' містить розширення реального часу - сигнали реального часу, планування виконання (з урахуванням пріоритетів, циклічне планування), таймери, синхронний і асинхронний ввід / вивід, ввід / вивід з пріоритетами, синхронізація файлів, блокування пам'яті, колективна пам'ять, передача повідомлень, семафори. Щоб стати POSIX-компліантной, ОС повинна реалізувати не менше 32 рівнів пріоритетів. POSIX визначає три політики планування обробки процесів: | ||
| + | |||
| + | *SCHED_FIFO - процеси обробляються в режимі FIFO і виконуються до завершення, | ||
| + | |||
| + | *SCHED_RR - round robin - кожному процесу виділяється квант часу, | ||
| + | |||
| + | *SCHED_OTHER - довільна реалізаційно-залежна політика, яка не переносяться на інші платформи. | ||
| + | |||
| + | '''Стандарт 1003.1c (Threads''') стосується функцій підтримки багатопотокового обробки всередині процесу - управління потоками, планування з урахуванням пріоритетів, мьютекс (спеціальні синхронізуючі об'єкти в взаємодії між процесами, що подають сигнал, коли вони не захоплені яких-небудь потоком), пріоритетне спадкування у мьютекса, змінні стану (condition variables). | ||
| + | |||
| + | '''Стандарт 1003.1d''' включає підтримку додаткових розширень реального часу - семантика породження нових процесів (spawn), спорадичні серверне планування, моніторинг процесів і потоків часу виконання, таймаут функцій блокування, управління пристроями і переривань. | ||
| + | |||
| + | '''Стандарт 1003.21''' стосується розподілених систем реального часу і включає функції підтримки розподіленого взаємодії, організації буферизації даних, посилки керуючих блоків, синхронних і асинхронних операцій, обмеженою блокування, пріоритетів повідомлень, міток повідомлень, і реалізацій протоколів. | ||
| + | |||
| + | '''Стандарт 1003.2h''' стосується сервісів, що відповідають за працездатність системи. | ||
| + | |||
| + | '''Стандарт DO-178B''', створено радіотехнічний комісією з аеронавтики (RTCA, Radio Technical Commission for Aeronautics) для розробки ПЗ бортових авіаційних систем [DO178B]. Перша його версія була прийнята в 1982 р., друга (DO-178A) - в 1985-м, поточна DO-178B - в 1992 р. Готується прийняття нової версії, DO-178C. Стандартом передбачено п'ять рівнів серйозності відмови, і для кожного з них визначено набір вимог до програмного забезпечення, які повинні гарантувати працездатність всієї системи в цілому при виникненні відмов даного рівня серйозності. | ||
| + | '''Даний стандарт визначає такі рівні сертифікації:''' | ||
| + | |||
| + | * А (катастрофічний), | ||
| + | * В (небезпечний), | ||
| + | * С (істотний), | ||
| + | * D (несуттєвий), | ||
| + | * Е (що не впливає). | ||
| + | |||
| + | '''Стандарт ARINC-653''' (Avionics Application Software Standard Interface) розроблений компанією ARINC в 1997 р. Цей стандарт визначає універсальний програмний інтерфейс APEX (Application / Executive) між ОС авіаційного 'ютера і прикладним ПЗ. Вимоги до інтерфейсу між прикладним ПЗ і сервісами операційної системи визначаються таким чином, щоб дозволити прикладного ПЗ контролювати диспетчеризацію, зв'язок і стан внутрішніх оброблюваних елементів. У 2003 р. прийнята нова редакція цього стандарту. ARINC-653 в якості одного з основних вимог для ОСРВ в авіації вводить архітектуру ізольованих (partitioning) віртуальних . | ||
| + | |||
| + | '''Стандарт OSEK / VDX''' є комбінацією стандартів, які спочатку розроблялися в двох окремих консорціумах, згодом злилися. OSEK бере свою назву від німецького акроніми консорціуму, до складу якого входили провідні німецькі виробники автомобілів - BMW, Bosch, Daimler Benz (тепер Daimler Chrysler), Opel, Siemens і Volkswagen, а також університет в Карлсруе (Німеччина). Проект VDX (Vehicle Distributed eXecutive) розвивався спільними зусиллями французьких компаній PSA і Renault. Команди OSEK і VDX злилися в 1994р. | ||
| + | |||
| + | Спочатку проект OSEK / VDX призначався для розробки стандарту відкритої архітектури ОС і стандарту API для систем, що застосовуються в автомобільній промисловості. Проте розроблений стандарт вийшов більш абстрактним і не обмежується використанням тільки в автомобільній індустрії. | ||
| + | |||
| + | Стандарт OSEK / VDX складається з трьох частин - стандарт для операційної системи (OS), комунікаційний стандарт (COM) і стандарт для мережевого менеджера (NM). На додаток до цих стандартів визначається якийсь реалізаційний мова (OIL). Першим компонентом стандарту OSEK є стандарт для ОС, тому часто стандарт OSEK помилково сприймається як стандарт ОСРВ. Хоча ОС і є велика порція даного стандарту, потужність його полягає в інтеграції всіх його компонент. | ||
| + | |||
<h2>Приклади ОСРЧ</h2> | <h2>Приклади ОСРЧ</h2> | ||
Слід зробити зауваження, що в списку відсутні системи, розроблені в СРСР для систем військового та космічного призначення - з цілком зрозумілих причин, пов'язаних з режимом секретності. Однак, їх існування та використання протягом десятків років є безперечним фактом, який слід враховувати. | Слід зробити зауваження, що в списку відсутні системи, розроблені в СРСР для систем військового та космічного призначення - з цілком зрозумілих причин, пов'язаних з режимом секретності. Однак, їх існування та використання протягом десятків років є безперечним фактом, який слід враховувати. | ||
Поточна версія на 14:57, 26 травня 2014
Зміст
Визначення
Операційна система реального часу, ОСРЧ (англ. Real-Time Operating System) — один із типів операційної системи.Операційні системи реального часу (ОСРЧ) призначені для забезпечення інтерфейсу до ресурсів критичних за часом систем реального часу. Основним завданням в таких системах є своєчасність (timeliness) виконання обробки даних.
В якості основної вимоги до ОСРЧ висувається вимога забезпечення передбачуваності або детермінованості поведінки системи в найгірших зовнішніх умовах, що різко відрізняється від вимог до продуктивності та швидкодії універсальних ОС. Гарна ОСРЧ має передбачувану поведінку при всіх сценаріях системної завантаження (одночасні переривання і виконання потоків.
- Операційна система, в якій успішність роботи будь-якої програми залежить не тільки від її логічної правильності, а й від часу, за який вона отримала цей результат. Якщо система не може задовольнити тимчасовим обмеженням, повинен бути зафіксований збій в її роботі;
- ОС, яка реагує за передбачуваний час на непередбачувану появу зовнішніх подій;
- Стандарт POSIX 1003.1 дає визначення «Реальний час в операційних системах — це здатність операційної системи забезпечити рівень сервісу, який вимагається за визначений проміжок часу»;
- Інтерактивні системи постійної готовності. До категорії ОСРЧ їх відносять виходячи з маркетингових міркувань і якщо інтерактивну програму називають «працюючою в реальному часі», то це означає лиш те, що запити від користувача обробляються із затримкою, непомітною для людини.
Системи м'якого (soft) і жорсткого (hard)
Прийнято розрізняти системи м'якого (soft) і жорсткого (hard) реального часу. У системах жорсткого реального часу нездатність забезпечити реакцію на будь-які події в заданий час веде до відмов і неможливості виконання поставленого завдання. У більшості російськомовної літератури такі системи називають системами з детермінованим часом. При практичному застосуванні час реакції має бути мінімальним. Системами м'якого реального часу називаються системи, що не підпадають під визначення "жорсткі", тому що в літературі чіткого визначення для них поки немає. Системи м'якого реального часу можуть не встигати вирішувати завдання, але це не призводить до відмови системи в цілому. У системах реального часу необхідне введення деякого директивного терміну (в англомовній літературі - deadline), до закінчення якого задача повинна обов'язково (для систем м'якого реального часу - бажано) виконатися. Цей директивний термін використовується планувальником завдань як для призначення пріоритету задачі при її запуску, так і при виборі задачі на виконання.
Відмінні риси ОСРЧ
Стандарти ОСРЧ
Великі розходження в специфікаціях ОСРЧ і величезна кількість існуючих мікроконтролерів висувають на передній план проблему стандартизації в області систем реального часу.
Найбільш раннім і поширеним стандартом ОСРЧ є стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Початковий варіант стандарту POSIX з'явився в 1990 р. і був призначений для UNIX-систем, перші версії яких з'явилися в 70-х роках минулого століття. Специфікації POSIX визначають стандартний механізм взаємодії прикладної програми і операційної системи і в даний час включають набір більш ніж з 30 стандартів. Для ОСРЧ найбільш важливі сім з них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), але широку підтримку в комерційних ОС отримали тільки три перших.
Незважаючи на явно застарілі положення стандарту POSIX і велику затребуваність оновлень стандартизації для ОСРЧ, помітного просування в цьому напрямку не спостерігається.
Деякі найбільш успішні компанії в області систем реального часу оголошують про своє рішення прийняти в якості стандарту специфікації одній зі своїх просунутих ОСРЧ. Так вчинила компанія TRON (the RTOS Nucleus), яка в 1987р. випустила в світ перші ITRON специфікації - ITRON1. Далі в 1989р. вона розробила і випустила специфікації μITRON для 8 - і 16 - бітових мікроконтролерів, а також специфікації ITRON2 для 32-бітових процесорів. ОСРВ ITRON описується нижче у відповідному розділі. Цей стандарт є дуже поширеним в Японії.
Військова і аерокосмічна галузі висувають жорсткі вимоги до обчислювальних засобів, що впливає на ступінь безпеки цільової системи. В даний час є такі стандарти для ОСРВ в авіації - стандарт DO-178B і стандарт ARINC-653. Оскільки ці стандарти розроблені в США, варто відзначити ще європейський стандарт ED-12B, який є аналогом DO-178B.
Поширеним також є стандарт OSEK / VDX [OSEK], який спочатку розвивався для систем автомобільної індустрії.
POSIX Стандарт POSIX був створений як стандартний інтерфейс сервісів операційних систем. Цей стандарт дає можливість створювати Переносимі програми. Згодом цей стандарт був розширений особливостями режиму реального часу [POSIX].
Специфікації POSIX задають стандартний механізм взаємодії програми і ОС. Необхідно відзначити, що стандарт POSIX тісно пов'язаний з ОС Unix; тим не менш, розробники багатьох ОСРВ намагаються витримати відповідність цьому стандарту. Відповідність стандарту POSIX для ОС і апаратної платформи повинне бути сертифіковане за допомогою прогону на них тестових наборів [POSIXTestSuite]. Однак, якщо ОС не є Unix-подібної, витримати це вимога стає непростим завданням. Тестові набори існують тільки для POSIX 1003.1a. Оскільки структура POSIX є сукупністю необов'язкових можливостей, постачальники ОС можуть реалізувати лише частина стандартного інтерфейсу, і при цьому говорити про POSIX-компліантності своєї системи.
Незважаючи на те, що стандарт POSIX виріс з Unix'а, він зачіпає основоположні абстракції операційних систем, а розширення реального часу застосовні до всіх ОСРЧ.
До теперішнього часу стандарт POSIX розглядається як сімейство споріднених стандартів: IEEE Std 1003.n (де n - це номер).
Стандарт 1003.1a (OS Definition) містить базові інтерфейси ОС - підтримку єдиного процесу, підтримку багатьох процесів, управління завданнями, сигналами, групами користувачів, файловою системою, файловими атрибутами, управління файловими пристроями, блокуваннями файлів, пристроями вводу / виводу, пристроями спеціального призначення, системними базами даних, каналами, чергами FIFO, а також підтримку мови C.
Стандарт 1003.1b (Realtime Extensions) містить розширення реального часу - сигнали реального часу, планування виконання (з урахуванням пріоритетів, циклічне планування), таймери, синхронний і асинхронний ввід / вивід, ввід / вивід з пріоритетами, синхронізація файлів, блокування пам'яті, колективна пам'ять, передача повідомлень, семафори. Щоб стати POSIX-компліантной, ОС повинна реалізувати не менше 32 рівнів пріоритетів. POSIX визначає три політики планування обробки процесів:
- SCHED_FIFO - процеси обробляються в режимі FIFO і виконуються до завершення,
- SCHED_RR - round robin - кожному процесу виділяється квант часу,
- SCHED_OTHER - довільна реалізаційно-залежна політика, яка не переносяться на інші платформи.
Стандарт 1003.1c (Threads) стосується функцій підтримки багатопотокового обробки всередині процесу - управління потоками, планування з урахуванням пріоритетів, мьютекс (спеціальні синхронізуючі об'єкти в взаємодії між процесами, що подають сигнал, коли вони не захоплені яких-небудь потоком), пріоритетне спадкування у мьютекса, змінні стану (condition variables).
Стандарт 1003.1d включає підтримку додаткових розширень реального часу - семантика породження нових процесів (spawn), спорадичні серверне планування, моніторинг процесів і потоків часу виконання, таймаут функцій блокування, управління пристроями і переривань.
Стандарт 1003.21 стосується розподілених систем реального часу і включає функції підтримки розподіленого взаємодії, організації буферизації даних, посилки керуючих блоків, синхронних і асинхронних операцій, обмеженою блокування, пріоритетів повідомлень, міток повідомлень, і реалізацій протоколів.
Стандарт 1003.2h стосується сервісів, що відповідають за працездатність системи.
Стандарт DO-178B, створено радіотехнічний комісією з аеронавтики (RTCA, Radio Technical Commission for Aeronautics) для розробки ПЗ бортових авіаційних систем [DO178B]. Перша його версія була прийнята в 1982 р., друга (DO-178A) - в 1985-м, поточна DO-178B - в 1992 р. Готується прийняття нової версії, DO-178C. Стандартом передбачено п'ять рівнів серйозності відмови, і для кожного з них визначено набір вимог до програмного забезпечення, які повинні гарантувати працездатність всієї системи в цілому при виникненні відмов даного рівня серйозності. Даний стандарт визначає такі рівні сертифікації:
- А (катастрофічний),
- В (небезпечний),
- С (істотний),
- D (несуттєвий),
- Е (що не впливає).
Стандарт ARINC-653 (Avionics Application Software Standard Interface) розроблений компанією ARINC в 1997 р. Цей стандарт визначає універсальний програмний інтерфейс APEX (Application / Executive) між ОС авіаційного 'ютера і прикладним ПЗ. Вимоги до інтерфейсу між прикладним ПЗ і сервісами операційної системи визначаються таким чином, щоб дозволити прикладного ПЗ контролювати диспетчеризацію, зв'язок і стан внутрішніх оброблюваних елементів. У 2003 р. прийнята нова редакція цього стандарту. ARINC-653 в якості одного з основних вимог для ОСРВ в авіації вводить архітектуру ізольованих (partitioning) віртуальних .
Стандарт OSEK / VDX є комбінацією стандартів, які спочатку розроблялися в двох окремих консорціумах, згодом злилися. OSEK бере свою назву від німецького акроніми консорціуму, до складу якого входили провідні німецькі виробники автомобілів - BMW, Bosch, Daimler Benz (тепер Daimler Chrysler), Opel, Siemens і Volkswagen, а також університет в Карлсруе (Німеччина). Проект VDX (Vehicle Distributed eXecutive) розвивався спільними зусиллями французьких компаній PSA і Renault. Команди OSEK і VDX злилися в 1994р.
Спочатку проект OSEK / VDX призначався для розробки стандарту відкритої архітектури ОС і стандарту API для систем, що застосовуються в автомобільній промисловості. Проте розроблений стандарт вийшов більш абстрактним і не обмежується використанням тільки в автомобільній індустрії.
Стандарт OSEK / VDX складається з трьох частин - стандарт для операційної системи (OS), комунікаційний стандарт (COM) і стандарт для мережевого менеджера (NM). На додаток до цих стандартів визначається якийсь реалізаційний мова (OIL). Першим компонентом стандарту OSEK є стандарт для ОС, тому часто стандарт OSEK помилково сприймається як стандарт ОСРВ. Хоча ОС і є велика порція даного стандарту, потужність його полягає в інтеграції всіх його компонент.
Приклади ОСРЧ
Слід зробити зауваження, що в списку відсутні системи, розроблені в СРСР для систем військового та космічного призначення - з цілком зрозумілих причин, пов'язаних з режимом секретності. Однак, їх існування та використання протягом десятків років є безперечним фактом, який слід враховувати.
Вільні : ChibiOS / RT; XOberon - ОСРВ для БПЛА, написана на Обероне SA; RTLinux - ОС жорсткого РВ на основі Linux; RTEMS - ОС з відкритим вихідним кодом, розроблена DARPA МО США; Embox - конфігурується модульні ОС для вбудованих систем; ERIKA Enterprise - ОСРВ з відкритим вихідним кодом, OSEK сертифіковані, пов'язуючи винятком GPL; Fiasco (клон L4); OSA [14] - кооперативна багатозадачна ОСРВ з відкритим вихідним кодом для мікроконтролерів PIC (Microchip), AVR (Atmel) і STM8 (STMicroelectronics); FreeRTOS; KURT (KU Real Time Linux) - ОС м'якого РВ на основі Linux; Phoenix-RTOS; Nut / OS; Prex; RTAI; scmRTOS - Single-Chip Microcontroller RTOS; SHaRK; TNKernel; uOS; TRON Project; Xenomai; BeRTOS - ОСРВ для вбудованих систем з відкритим вихідним кодом, поширюється по ліцензії GPL; ART-Linux - ОС жорсткого РВ на основі Linux для використання у робототехніці. API режиму реального часу складається всього з п'яти функцій.
Пропрієтарні : Automation Runtime - ОС жорсткого РВ для контролерів B & R; QNX - з відкритим вихідним кодом (починаючи з версії QNX Neutrino 6.3.2); RTOS-32 - ОС з відкритим вихідним кодом; Ardence RTX; ChorusOS; CMX RTOS; DNIX; DMERT; DSOS; embOS (Segger); FlexOS; HP-1000/RTE [20]; INTEGRITY; ITRON; LynxOS; MERT; MicroC / OS-II; MQX RTOS [21]; Nucleus; OS-9; OSE; OSEK / VDX; OSEKtime; PDOS; Phar Lap ETS; PikeOS; Portos; pSOS; REX; RMX; RSX-11 (її радянський клон - ОСРВ СМ ЕОМ); RT-11; RTOS-UH; RTXC; Salvo RTOS; SINTRAN III; ThreadX; VRTX; VxWorks / Tornado; Windows CE; μnOS; UNIX-RTR; Virtuoso - ОСРВ для сигнальних процесорів DSP; Багет - ОСРВ розроблена НИИС РАН за замовленням МО РФ.
