Реферат: Особливості операційних систем реального часу

Стандарт 1003.1c (Threads) стосується функцій підтримки багатопотокового обробки всередині процесу - управління потоками, планування з урахуванням пріоритетів, мьютекс (спеціальні синхронізуючі об'єкти в взаємодії між процесами, що подають сигнал, коли вони не захоплені яких-небудь потоком), пріоритетне спадкування у мьютекса, змінні стану (condition variables).

Стандарт 1003.1d включає підтримку додаткових розширень реального часу - семантика породження нових процесів (spawn), спорадичні серверне планування, моніторинг процесів і потоків часу виконання, таймаут функцій блокування, управління пристроями і переривань.

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

Стандарт 1003.2h стосується сервісів, що відповідають за працездатність системи.

DO-178B Стандарт DO-178B, створено радіотехнічний комісією з аеронавтики (RTCA, Radio Technical Commission for Aeronautics) для розробки ПЗ бортових авіаційних систем [DO178B]. Перша його версія була прийнята в 1982 р., друга (DO-178A) - в 1985-м, поточна DO-178B - в 1992 р. Готується прийняття нової версії, DO-178C. Стандартом передбачено п'ять рівнів серйозності відмови, і для кожного з них визначено набір вимог до програмного забезпечення, які повинні гарантувати працездатність всієї системи в цілому при виникненні відмов даного рівня серйозності

Даний стандарт визначає такі рівні сертифікації:

· А (катастрофічний),

· В (небезпечний),

· С (істотний),

· D (несуттєвий)

· Е (що не впливає).

ARINC-653 Стандарт ARINC-653 (Avionics Application Software Standard Interface) розроблений компанією ARINC в 1997 р. Цей стандарт визначає універсальний програмний інтерфейс APEX (Application / Executive) між ОС авіаційного комп'ютера і прикладним ПЗ. Вимоги до інтерфейсу між прикладним ПЗ і сервісами операційної системи визначаються таким чином, щоб дозволити прикладного ПЗ контролювати диспетчеризацію, зв'язок і стан внутрішніх оброблюваних елементів. У 2003 р. прийнята нова редакція цього стандарту. ARINC-653 в якості одного з основних вимог для ОСРВ в авіації вводить архітектуру ізольованих (partitioning) віртуальних машин.

OSEK Стандарт 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 помилково сприймається як стандарт ОСРВ. Хоча ОС і є велика порція даного стандарту, потужність його полягає в інтеграції всіх його компонент.

У даній роботі розглядається тільки стандарт для операційної системи, і його опис наводиться в розділі 2.7.

Стандарти безпеки

У зв'язку до стандартів для ОСРВ варто відзначити широко відомий стандарт критеріїв оцінки придатності комп'ютерних систем (Trusted Computer System Evaluation Criteria - TCSEC) [DoD85]. Цей стандарт розроблений Міністерством оборони США і відомий також під назвою "Помаранчева книга" (Orange Book - через колір обкладинки).

У ряді інших країн були розроблені аналогічні критерії, на основі яких був створений міжнародний стандарт "Загальні критерії оцінки безпеки інформаційних технологій" (далі просто - Загальні критерії) (Common Criteria for IT Security Evaluation, ISO / IEC 15408) [CC99].

В "Помаранчевої книзі" перераховані сім рівнів захисту:

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

· В3 - домени безпеки. Цей рівень призначений для захисту систем від досвідчених програмістів.

· В2 - структурована захист. У систему з цим рівнем захисту не можна допустити проникнення хакерів.

· В1 - мандатний контроль доступу. Захист цього рівня, можливо, вдасться подолати досвідченому хакеру, але ніяк не рядовим користувачам.

· С2 - дискреційний контроль доступу. Рівень С2 забезпечує захист процедур входу, дозволяє проводити контроль за подіями, що мають відношення до безпеки, а також ізолювати ресурси.

· С1 - виборча захист. Цей рівень дає користувачам можливість захистити особисті дані чи інформацію про проект, встановивши засоби управління доступом.

· D - мінімальна захист. Цей нижній рівень захисту залишений для систем, які проходили тестування, але не змогли задовольнити вимогам більш високого класу.

Що стосується Загальних критеріїв, то в них введено схожі вимоги забезпечення безпеки у вигляді оціночних рівнів (Evaluation Assurance Levels - EAL). Їх також сім:

· EAL7 - найвищий рівень припускає формальну верифікацію моделі об'єкта оцінки. Він застосовний до систем дуже високого ризику.