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

МІНІСТЕРСТВООСВІТИ І НАУКИ УКРАЇНИ

КРАСНОДОНСЬКИЙПРОМИСЛОВО ЕКОНОМІЧНИЙ КОЛЕДЖ

Реферат зпредмету: «Операційні системи»

на тему:

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

Студента групи1ОКІСМ-06

Петренко Михайла

Перевірила: ДрокінаТ.М.

Краснодон

2009


Зміст

1. Вступ

2. Процеси, потоки,завдання

3. Планування, пріоритети

4. Пам'ять

5. Переривання

6. Годинники і таймери

7. Стандарти ОСРВ

8. Настроюваністьопераційних систем


1. Вступ

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

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

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

Прийняторозрізняти системи м'якого (soft) і жорсткого (hard) реального часу. У системахжорсткого реального часу нездатність забезпечити реакцію на будь-які події взаданий час веде до відмов і неможливості виконання поставленого завдання. Убільшості російськомовної літератури такі системи називають системами здетермінованим часом. При практичному застосуванні час реакції має бутимінімальним. Системами м'якого реального часу називаються системи, що непідпадають під визначення «жорсткі», тому що в літературі чіткоговизначення для них поки немає. Системи м'якого реального часу можуть невстигати вирішувати завдання, але це не призводить до відмови системи в цілому.У системах реального часу необхідне введення деякого директивного терміну (вангломовній літературі — deadline), до закінчення якого задача повиннаобов'язково (для систем м'якого реального часу — бажано) виконатися. Цейдирективний термін використовується планувальником завдань як для призначенняпріоритету задачі при її запуску, так і при виборі задачі на виконання.

МартінТіммерман сформулював наступні необхідні вимоги для ОСРВ [DEDSYS]:

·         ОС повинна бутибагатозадачного і допускає витіснення (preemptable),

·         ОС повинна мати поняттямпріоритету для потоків,

·         ОС повинна підтримуватипередбачувані механізми синхронізації,

·         ОС повинна забезпечуватимеханізм успадкування пріоритетів,

·         поведінка ОС повинно бутивідомим і передбачуваним (затримки обробки переривань, затримки перемиканнязавдань, затримки драйверів і т.д.); це означає, що у всіх сценаріях робочогонавантаження системи має бути визначено максимальний час відгуку.

Протягомостанніх 25-30 років структура операційних систем еволюціонувала від монолітноїдо багатошаровій структурі ОС і далі до архітектури клієнт-сервер. Примонолітній структурі ОС складається з набору модулів, і зміни одного модулявпливають на інші модулі. Чим більше модулів, тим більше хаосу при експлуатаціїтакої системи. Крім того, неможливо розподілити ОС багатопроцесорні системи. Убагатошаровій структурі зміни одного шару впливають на сусідні шари; крім того,звернення через шар неможливо. Для систем реального часу має бути забезпеченопряме звернення до кожного шару ОС, а іноді безпосередньо до апаратури.

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

Клієнт-сервернатехнологія дозволяє створювати масштабовані ОС і спрощує розподілбагатопроцесорні системи. При експлуатації системи заміна одного модуля невикликає ефекту «сніжного кома»; крім того, збій модуля не завждитягне за собою відмову системи в цілому. З'явилася можливість динамічногозавантаження і відвантаження модулів. Головною проблемою в цій моделі є захистпам'яті, оскільки серверні процеси повинні бути захищені. При кожному запитісервісу система повинна перемикатися з контексту програми на контекст сервера.За підтримки захисту пам'яті час перемикання з одного процесу на іншийзбільшується.

Якправило, більшість сучасних ОСРВ побудовано на основі мікроядра (kernel абоnucleus), яке забезпечує планування і диспетчеризацію завдань, а також здійснюєїх взаємодію. Незважаючи на зведення до мінімуму в ядрі ОС абстракцій,Мікроядро все ж таки повинно мати уявлення про абстракції процесу. Всі іншіконцептуальні абстракції операційних систем винесені за межі ядра, викликаютьсяза запитом та виконуються як додатки.

Розглянемоконцептуальні абстракції операційної системи через призму вимог до системреального часу.


2. Процеси, потоки, завдання

Концепціябагатозадачності (псевдопараллелізм) є суттєвою для системи реального часу зодним процесором, програми якої повинні бути здатні обробляти численні зовнішніподії, що відбуваються практично одночасно. Концепція процесу, що прийшла зсвіту UNIX, погано реалізується в багатозадачному системі, оскільки процес маєважкий контекст. Виникає поняття потоку (thread), який розуміється якпідпроцесу, або легкий процес (light-weight process). Потоки існують в одномуконтексті процесу, тому перемикання між потоками відбувається дуже швидко, апитання безпеки не беруться до уваги. Потоки є легковажно, тому що їхрегістровий контекст менше, тобто їхні управляючі блоки набагато компактнішим.Зменшуються накладні витрати, викликані збереженням та відновленням керуючихблоків перериваються потоків. Обсяг керуючих блоків залежить від конфігураціїпам'яті. Якщо потоки виконуються в різних адресних просторах, система повиннапідтримувати відображення пам'яті для кожного набору потоків.

Отже,в системах реального часу процес розпадається на завдання або потоки. Убудь-якому випадку кожен процес розглядається як додаток. Між цими додатками неповинно бути занадто багато взаємодій, і в більшості випадків вони мають різнуприроду — жорсткого реального часу, м'якого реального часу, не реального часу.

3. Планування, пріоритети

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

Узв'язку з проблемами планування в ОСРВ вивчаються і розвиваються два підходи — статичні алгоритми планування (RMS — Rate Monotonic Scheduling) [LL73] ідинамічні алгоритми планування (EDF — Earliest Deadline First).

RMSвикористовується для формального докази умов передбачуваності системи. Дляреалізації цієї теорії необхідне планування на основі пріоритетів, перериваютьобслуговування (preemptive priority scheduling). У теорії RMS пріоритетзаздалегідь призначається кожному процесу. Процеси повинні задовольняти такимумовам:

·         процес має бути завершенийза час його періоду,

·         процеси не залежать один відодного,

·         кожному процесу потрібнооднакове процесорний час на кожному інтервалі,

·         у неперіодичних процесівнемає жорстких термінів,

·         переривання процесувідбувається за обмежений час.

Процесивиконуються відповідно до пріоритетів. При плануванні RMS перевага віддаєтьсязавданням із самими короткими періодами виконання.

УEDF пріоритет надається динамічно, і найбільший пріоритет виставляєтьсяпроцесу, у якого залишилося найменше час виконання. При великих завантаженняхсистеми у EDF є переваги перед RMS.

Увсіх системах реального часу потрібно політика планування, керована дедлайну(deadline-driven scheduling). Однак цей підхід знаходиться у стадії розробки.

Зазвичайв ОСРВ використовується планування з пріоритетами, переривають обслуговування,яке засноване на RMS. Пріоритетне переривання обслуговування (preemption) єневід'ємною складовою ОСРВ, тому що в системі реального часу повинні існуватигарантії того, що подія з високим пріоритетом буде оброблено перед подією більшнизького пріоритету. Все це веде до того, що ОСРВ потребує не тільки вмеханізмі планування на основі пріоритетів, переривають обслуговування, алетакож і у відповідному механізмі управління переривань. Більш того, ОСРВповинна бути здатна забороняти переривання, коли необхідно виконати критичнийкод, який не можна переривати. Тривалість обробки переривань повинна бутизведена до мінімуму.

ОСРВповинна володіти розвиненою системою пріоритетів. По-перше, це потрібно тому,що система сама може розглядатися як набір серверних додатків, щопідрозділяються на потоки, і кілька високих рівнів пріоритетів має бутивиділено системним процесам і потокам. По-друге, в складних додатках необхідновсі потоки реального часу поміщати на різні пріоритетні рівні, а потоки нереального часу розміщувати на один рівень (нижче, ніж будь-які потоки реальногочасу). При цьому потоки не реального часу можна обробляти в режимі циклічногопланування (RRS — round-robin scheduling), при якому кожному процесу надаєтьсяквант часу процесора, а коли квант закінчується, контекст процесу зберігається,і він ставиться в кінець черги. У багатьох ОСРВ для планування завдань наодному рівні використовується RRS. Пріоритетний рівень 0 зазвичай використовуєтьсядля холостого режиму.

Приплануванні на основі пріоритетів необхідно вирішити дві обов'язкові проблеми:

забезпечитивиконання процесу з найвищим пріоритетом,

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

Дляборотьби з інверсією пріоритетів у ОСРВ часто використовується механізмуспадкування пріоритетів, однак при цьому доводиться відмовлятися відпланування на основі RMS, оскільки пріоритети стають динамічними.


4. Пам'ять

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

·         Модель без захисту — системне і користувацьким простору не захищені один від одного,використовується два сегменти пам'яті: для коду та для даних; при цьому відсистеми не потрібно ніякого управління пам'яттю, не потрібно MMU (memorymanagement unit — спеціальне апаратний пристрій для підтримки управліннявіртуальною пам'яттю).

·         Модель захисту система /користувач — системне адресний простір захищене від адресного просторукористувача, системні і користувальницькі процеси виконуються в загальномувіртуальному адресному просторі, при цьому потрібно MMU. Захист забезпечуєтьсясторінковим механізмом захисту. Розрізняються системні і користувальницькісторінки. Користувальницькі програми ніяк не захищені один від одного. Процесорзнаходиться в режимі супервізора, якщо поточний сегмент має рівень 0, 1 або 2.Якщо рівень сегмента — 3, то процесор знаходиться в режимі користувача. У ціймоделі необхідні чотири сегменти — два сегменти на рівні 0 (для коду та даних)і два сегменти на рівні 3. Механізм сторінкової захисту не додає накладнихвитрат, тому що захист перевіряється одночасно з перетворенням адреси, якевиконує MMU; при цьому операційна система не потребує в управлінні пам'яттю.

·         Модель захисту користувач /користувач — до моделі система / користувач додається захист міжкористувацькими процесами; потрібно MMU. Як і в попередній моделі,використовується механізм сторінкової захисту. Усі сторінки позначаються якпривілейовані, за винятком сторінок поточного процесу, які позначаються яккористувацькі. Таким чином, виконують потік не може звернутися за межі свогоадресного простору. ОС відповідає за оновлення прапора привілейованості дляконкретної сторінки в таблиці сторінок при перемиканні процесу. Як і впопередній моделі використовуються чотири сегменти.

·         Модель захисту віртуальноїпам'яті — кожен процес виконується у своєї власної віртуальної пам'яті,потрібно MMU. У кожного процесу має свої власні сегменти і, отже, своя таблицяописувачів. ОС несе відповідальність за підтримку таблиць описувачів.Адресуються простір може перевищувати розміри фізичної пам'яті, якщовикористовується сторінкова організація пам'яті спільно з підкачкою. Проте всистемах реального часу підкачка зазвичай не застосовується через їїнепередбачуваності. Для вирішення цієї проблеми доступна пам'ять розбиваєтьсяна фіксоване число логічних адресних просторів рівного розміру. Число одночасновиконуються процесів у системі стає обмеженим.

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

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

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

Узвичайних ГР при використанні механізму сегментації пам'яті для боротьби зфрагментацією застосовується процедура ущільнення після збирання сміття. Однактакий підхід непридатний в середовищі реального часу, оскільки під часущільнення переміщувані задачі не можуть виконуватися, що веде донепередбачуваності системи. У цьому полягає основна проблема застосовностіоб'єктно-орієнтованого підходу до систем реального часу. До тих пір, поки проблемаущільнення не буде вирішена, C + + і JAVA залишаться не самим кращим виборомдля систем жорсткого реального часу.

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

 

5. Переривання

 

Приописі управління переривань зазвичай розрізняють дві процедури, а саме:

програмаобробки переривання (ISR — interrupt servicing routine) — програма низькогорівня в ядрі з обмеженими системними викликами,

потікобробки переривання (IST — interrupt servicing thread) — потік рівня програми,який управляє перериванням, з доступом до всіх системним викликам.

ЗазвичайISR реалізуються виробником апаратури, а драйвери пристроїв виконуютьуправління переривань за допомогою IST. Потоки обробки переривань діють якбудь-які інші потоки і використовують ту ж саму систему пріоритетів. Цеозначає, що проектувальник системи може надати IST більш низький пріоритет, ніжпріоритет потоку програми.

 

6. Годинники і таймери

 

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

Длякожного процесу й потоку визначаються годинник процесорного часу. На базі цихгодин створюються таймери; які вимірюють перевитрата часу процесом або потоком,дозволяючи динамічно виявляти програмні помилки або помилки обчисленнямаксимально можливого часу виконання. У високонадійних, критичних до часусистемах важливо виявлення ситуацій, при яких завдання перевищує максимальноможливий час свого виконання, тому що при цьому робота системи може вийти зарамки допустимого часу відгуку. Годинники часу виконання дозволяють виявитивиникнення перевитрати часу й активізувати відповідні дії по обробці помилок.

БільшістьОСРВ оперують відносним часом. Щось відбувається «до» і«після» деякого іншої події. У системі, повністю керованої подіями,необхідний часовий механізм (ticker), тому що там немає квантування часу (timeslicing). Однак, якщо потрібні тимчасові мітки для деяких подій або необхіднийсистемний виклик типу «чекати одну секунду», то потрібний тактовийгенератор і / або таймер.

Синхронізаціяв ОСРВ здійснюється за допомогою механізму блокування (або очікування) донастання деякого події. Абсолютна час не використовується.

Реалізаціїв ОСРВ інших концептуальних абстракцій подібні їх реалізація в традиційних ОС.

 

7. Стандарти ОСРВ

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

Найбільшраннім і поширеним стандартом ОСРВ є стандарт POSIX (IEEE Portable OperatingSystem 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 СтандартDO-178B, створено радіотехнічний комісією з аеронавтики (RTCA, Radio TechnicalCommission 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 SystemEvaluation Criteria — TCSEC) [DoD85]. Цей стандарт розроблений Міністерствомоборони США і відомий також під назвою «Помаранчева книга» (OrangeBook — через колір обкладинки).

Уряді інших країн були розроблені аналогічні критерії, на основі яких бувстворений міжнародний стандарт «Загальні критерії оцінки безпекиінформаційних технологій» (далі просто — Загальні критерії) (CommonCriteria 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 розраховані на тестуванняпродуктів, створених із застосуванням спеціалізованих технологій безпеки.

Слідзазначити, що більшість зусиль з оцінки продуктів безпеки зосереджені на рівні4 стандарту Загальних критеріїв і нижче, що говорить про обмежений застосуванніформальних методів у цій області.

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

8. Налаштовуваність операційних систем

Останнімчасом однією з головних тем дослідницьких робіт в області операційних системстало дослідження настроюваність (customizability) або адаптованостіопераційної системи. Настроюваної або адаптується операційною системоюназивається операційна система, що допускає гнучку модифікацію основнихмеханізмів, стратегій і політик системи. Залежно від контексту, налаштовуваністьсистеми може переслідувати різні цілі. В операційних системах загальногопризначення, як правило, такою метою є продуктивність системи в цілому. Длявбудованих систем настроюваність служить цілям енергозбереження та / абоскорочення обсягу програмного забезпечення. Детальний систематичний огляддослідних операційних систем з точки зору їх настроюваність дається в роботіДениса та ін [DPM02].

Уранніх ОС була присутня якась форма налаштування; найчастіше вона полягала вможливості настроювати систему на етапі її створення. Проте останнім часомз'явилися дослідження та інших способів адаптації ОС — це стосується ініціатораналаштування та час її здійснення. Ініціатором адаптації може бутиадміністратор або проектувальник ОС (тобто чоловік), програму або самаопераційна система. В останньому випадку адаптація називається автоматичним. Щостосується часу налаштування, то вона може відбуватися на етапі проектування,компонування або інсталяції (статична адаптація), а також під час завантаженняі навіть під час виконання (динамічна адаптація).

еще рефераты
Еще работы по информатике, программированию