Незважаючи на те, що стандарт 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 Стандарт 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 - найвищий рівень припускає формальну верифікацію моделі об'єкта оцінки. Він застосовний до систем дуже високого ризику.
· EAL6 визначається, як напівформально Верифікований і протестований. На рівні EAL6 реалізація повинна бути представлена в структурованому вигляді, аналіз відповідності поширюється на проект нижнього рівня, проводиться суворий аналіз покриття, аналіз і тестування небезпечних станів.
· EAL5 визначається, як напівформально спроектований і протестований. Він передбачає створення напівформально функціональної специфікації та проекту високого рівня з демонстрацією відповідності між ними, формальної моделі політики безпеки, стандартизованої моделі життєвого циклу, а також проведення аналізу прихованих каналів.
· EAL4 визначається, як методично спроектований, протестований і переглянутий. Він припускає наявність автоматизації управління конфігурацією, повної специфікації інтерфейсів, описового проекту нижнього рівня, підмножини реалізацій функцій безпеки, неформальної моделі політики безпеки, моделі життєвого циклу, аналіз валідації, незалежний аналіз вразливостей. По всій імовірності, це найвищий рівень, якого можна досягти на даному етапі розвитку технології програмування з прийнятними витратами.
· EAL3 визначається, як методично протестований і перевірений. На рівні EAL3 здійснюється більш повне, ніж на рівні EAL2, тестування покриття функцій безпеки, а також контроль середовища розробки й управління конфігурацією об'єкта оцінки.
· EAL2 визначається, як структурно протестований. Він передбачає створення описового проекту верхнього рівня об'єкта оцінки, опис процедур інсталяції і постачання, інструкцій адміністратора та користувача, функціональне та незалежне тестування, оцінку міцності функцій безпеки, аналіз вразливостей розробниками.
· EAL1 визначається, як функціонально протестований. Він забезпечує аналіз функцій безпеки з використанням функціональної специфікації і специфікації інтерфейсів, керівної документації, а також незалежне тестування. На цьому рівні загрози не розглядаються як серйозні.
Відповідно до вимог Загальних критеріїв, продукти певного класу (наприклад, операційні системи) оцінюються на відповідність ряду функціональних критеріїв і критеріїв довіри - профілів захисту. Існують різні визначення профілів захисту щодо операційних систем, брандмауерів, смарт-карт і інших продуктів, які повинні відповідати певним вимогам у сфері безпеки. Наприклад, профіль захисту систем з розмежуванням доступу (Controlled Access Protection Profile) діє відносно операційних систем і покликаний замінити старий рівень захисту С2, визначається відповідно до американським стандартом TCSEC. Згідно з оцінними рівнями довіри сертифікація на відповідність більш високому рівню означає більш високу ступінь впевненості в тому, що система захисту продукту працює правильно і ефективно, і, згідно з умовами Загальних критеріїв, рівні 5-7 розраховані на тестування продуктів, створених із застосуванням спеціалізованих технологій безпеки.