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

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol "\ s 14 ѕ SYMBOL 190 \ f" Symbol "\ s 14 ѕ SYMBOL 190 \ f" Symbol "\ s 14 ѕ SYMBOL 190 \ f" Symbol "\ s 14 ѕ SYMBOL 190 \ f" Symbol "\ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ SYMBOL 190 \ f "Symbol" \ s 14 ѕ

 

ПОЯСНЮВАЛЬНА ЗАПИСКА
до курсового проекту на тему:
Розробка системи реального часу у вигляді планувальника
виконання завдань.
Москва 2004

Реферат.
Виконана робота по проектуванню системи реального часу. Створена система містить два основних компоненти: планувальник завдань реального часу і прикладне додаток - протокол A.415 ARINC. Робота містить 39 сторінок, 14 діаграм, 3 таблиці та 2 малюнки. Використано 13 посилань на технічну літературу.
Розділ 1. Описуються відмінності систем реального часу від звичайних систем (поділу часу). Наведено характерні особливості управління завданнями в подібних системах. Проведено класифікацію та аналіз вимог, що пред'являються до сучасних СРВ. Дано приклади систем даного класу (представлених в Росії). Розглянуто необхідність використання спеціальної методології розробки програмного забезпечення.
Розділ 2. Задані визначення, що використовуються в даній роботі. Розглянуто принципова структура СРВ. Наведено класифікацію підходів до планування та огляд методів його реалізації. Розглянуто об'єктно-орієнтована методологія розробки програмного забезпечення.
Розділ 3. Описана реалізація планувальника завдань реального часу: досягаються можливості, використовувані алгоритми, загальна схема функціонування. Наведено документація за додатком-протоколу, складена відповідно до вимог методології Real.

Зміст.
Реферат .. 2
Зміст .. 3
Введення .. 5
1. Огляд вимог проблемної області .. 7
1.1. Особливості систем реального часу .. 7
1.1.1. Обмежений час відповіді .. 7
1.1.2. Статична основа проектування .. 7
1.1.3. Портування .. 8
1.1.4. Вбудовані системи реального часу .. 8
1.1.5. Висновок .. 9
1.2. Особливості управління завданнями .. 9
1.2.1. Управління часом .. 9
1.2.2. Управління пам'яттю .. 9
1.2.3. Управління доступом (синхронізація) .. 9
1.2.4. Висновок .. 10
1.3. Класифікація систем реального часу .. 10
1.3.1. Класифікація за структурним характеристикам .. 10
1.3.1.1. Виконавчі системи реального часу. 10
1.3.1.2. Ядра реального часу .. 11
1.3.1.3. UNIX "и реального часу .. 11
1.3.2. Класифікація за програмному середовищі .. 12
1.3.2.1. Програмування на рівні мікропроцесорів. 12
1.3.2.2. Мінімальна ядро ​​системи реального часу. 12
1.3.2.3. Ядро системи реального часу і інструментальне середовище. 12
1.3.2.4. ОС з повним сервісом. 12
1.3.3. Технічні характеристики ОС РВ .. 12
1.3.3.1. Час реакції системи. 12
1.3.3.2. Час перемикання контексту. 13
1.3.3.3. Розміри системи. 13
1.3.3.4. Можливість виконання системи з ПЗУ (ROM). 14
1.3.4. Висновок .. 14
1.4. Сучасні представники ринку ОС РВ в Росії .. 14
1.4.1. LynxOS ® 4.x фірми LinuxWorks, Inc .. 14
1.4.1.1. Основні властивості LynxOS:. 14
1.4.1.2. Підтримка програм жорсткого реального часу. 15
1.4.2. OS-9/Hawk фірми Microware Systems .. 15
1.4.2.1. Основні властивості OS-9/Hawk. 15
1.4.2.2. Підтримка програм жорсткого реального часу. 16
1.4.3. VxWorks фірми Wind River Systems .. 16
1.4.3.1. Основні властивості VxWorks. 16
1.4.4. QNX4 фірми ОРАКУЛ .. 17
1.4.4.1. Основні властивості QNX4. 17
1.4.4.2. Підтримка програм жорсткого реального часу. 17
1.4.5. Висновок .. 17
1.5. Методологія розробки програмного забезпечення .. 17
1.5.1. Історія розвитку .. 18
1.5.2. Розробка програмного забезпечення систем реального часу .. 18
1.5.3. Висновок .. 19
1.6. Постановка завдання курсового проекту .. 19
2. Моделі та методи предметної області .. 21
2.1. Визначення .. 21
2.2. Принципова структура .. 22
2.2.1. Середовище виконання .. 22
2.2.2. Ядро систем реального часу .. 22
2.2.2.1. Синхронізація ресурсів. 23
2.2.2.2. Межзадачного обмін. 23
2.2.2.3. Поділ даних. 23
2.2.2.4. Обробка запитів зовнішніх пристроїв. 23
2.2.2.5. Обробка особливих ситуацій. 23
2.2.3. Пікоядро .. 24
2.3. Методи управління завданнями в ОС РВ .. 24
2.3.1. Класифікація підходів .. 24
2.3.1.1. Статичний планування. 24
2.3.1.2. Динамічне планування. 24
2.3.1.3. Планування, засноване на часі. 25
2.3.1.4. Планування апериодических завдань. 25
2.3.1.5. Планування, кероване пріоритетами. 25
2.3.2. Огляд методів .. 26
2.3.2.1. Rate-monotonic (RM). 26
2.3.2.2. Deadline Monotonic (DM). 26
2.3.2.3. Планування апериодических завдань. 27
2.3.2.4. EDF. 27
2.3.2.5. Сервер, припускає затримку (DS) і Алгоритм обміну пріоритетами (PE). 28
2.4. Методологія розробки програмного забезпечення .. 28
2.4.1. Основи методології Real .. 28
2.4.2. Модель вимог .. 29
2.4.3. Динамічна модель .. 29
2.4.4. Статична модель .. 30
3. Реалізація прототипу системи реального часу .. 31
3.1. Життєвий цикл розробки .. 31
3.2. Планувальник завдань .. 31
3.2.1. Вибір алгоритму планування .. 31
3.2.1.1. Види вимог РВ, підтримувані планувальником. 31
3.2.1.2. Використовувані алгоритми. 32
3.2.2. Опис функціонування програми .. 33
3.2.2.1. Підготовка до запуску планувальника. 33
3.2.2.2. Робота. 33
3.2.2.3. Управління завданнями. 34
3.3. Реалізація протоколу ARINC A.415 на основі розробленого модуля СРВ. 34
3.3.1. Модель вимог до системи .. 34
3.3.1.1. Описова модель. 34
3.3.1.2. Модель випадків використання. 35
3.3.1.3. Функціональна модель. 35
3.3.2. Динамічна модель .. 35
3.3.2.1. Модель об'єктів. 35
3.3.2.2. Модель взаємодій. 35
3.3.2.3. Поведінкова модель. 36
3.3.3. Статична модель .. 37
3.3.3.1. Модель класів. 37
Висновок .. 39
Література .. 40
Додаток .. 41

Введення.
Новий етап науково-технічної революції був обумовлений повсюдним поширенням обчислювальної техніки. Зараз вже важко знайти вид діяльності, який тим чи іншим способом не підтримувався б не просто автоматизованими, але і комп'ютеризованими пристроями. Така організація життєдіяльності дозволяє не тільки виконувати заздалегідь задані алгоритми управління виробництвом, але й вносити в нього елементи автоматизації інтелектуальної діяльності, елементи штучного інтелекту. Використання таких технологій у життєво важливих галузях, таких як авіація, банківська справа та інших, які потребують жорстко заданих вимог до прийняття рішень, що накладаються на час, точність і безпеку діяльності даних систем, обумовлює необхідність створення особливо надійних їх видів - систем реального часу.
Управління процесом надання ресурсів системи завданням, ниткам, процедурам обробки переривань і т.д. є однією з основних функцій будь-якої операційної системи та здійснюється за допомогою такого механізму, як планування. Даний механізм забезпечує системі можливість паралельного виконання кількох завдань. У системах реального часу планування має також гарантувати передбачувану поведінку, безпека, можливість тривалої, безвідмовної роботи, виконання завдань до поставленого терміну. Від методу планування багато в чому залежить успішна робота системи в цілому.
З іншого боку, збільшення обсягів виробництва й різноманітності мікропроцесорної техніки, розширення сфер їх застосування призводить до необхідності розробок різних операційних систем реального часу - від компактних, розрахованих на обслуговування одночіпових мікро-контролерів, до потужних мережевих систем. Шлях до задоволення вимог високої ефективності й надійності цих систем лежить через підвищення ясності і стрункості їх логічної організації.
Ця обставина висуває актуальні завдання розробки раціонально організованих базових структур, які представляли б в узагальненому вигляді ключові принципи організації варіантів операційних систем, орієнтованих на досягнення того чи іншого типу ефективності. Для цієї мети висуваються різні методології розробки відповідних систем. Особливу актуальність набули об'єктно-орієнтовані методології, яка спирається на вигоди розробки за допомогою об'єктних мов високого рівня (зокрема, С + +).
У даній роботі необхідно буде провести аналіз предметної області ОС РВ. У вигляді фокус-групи логічно було б вибрати вмонтовані системи реального часу, пропоновані в даний момент на ринку програмного забезпечення Росії, відомості за якими розміщені в мережі Internet. Аналіз проводиться за результатами прес-релізів подібних систем, в яких підкреслено опції, які є найбільш важливими для сучасних споживачів. Дане дослідження дозволить встановити вимоги до систем реального часу, затребувані розробниками в даний час, і загальні методики задоволення цих вимог.
У зв'язку з просторістю проблемної області має сенс дати основоположні визначення та розгорнуті тлумачення окремих термінів, що мають особливу важливість. У зв'язку з цим буде розглянута принципова структура систем реального часу і виділена найбільш поширена і загальновизнана в даний момент.
У даній роботі будуть розглянуті підходи до задачі вибору прийнятного алгоритму планування на основі відомостей про алгоритми, передбачуваної моделі задач і структурних характеристик майбутньої системи. Передбачається виділити алгоритм планування, орієнтований на розробку програмного забезпечення систем контролю реального часу, і використовувати його при створенні прототипу модуля-диспетчера для завдань реального часу, який буде підключатися до програми користувача. Даний модуль буде надавати інтерфейс для формування завдань з певними вимогами до часу виконання.
На основі спроектованого планувальника з використанням спеціальної методології можна буде реалізовувати прикладні програми реального часу. Зокрема, буде реалізований протокол A.415 ARINC, використовуваний у вбудованих системах реального часу літаків провідних авіаперевізників. Це протокол опитування бортових пристроїв, дозволяє в заздалегідь визначений проміжок часу від них інформацію і сигналізувати про несправності в обладнанні. Такий додаток найбільшою мірою підходить як для аналізу прототипу створюваної СРВ, так і для використовуваної методології.
При проектуванні реалізації протоколу основний акцент планується зробити на принципах його функціонування, відповідно заявленим вимогам і достигаемом рівні надійності. Апаратні вимоги, які пред'являються до використовуваного обладнання, і, в цілому, проблеми портування розглянуті не будуть. Надалі при втіленні проекту в життя може бути аналіз цих параметрів для оптимізації обчислень в найбільш ресурсномістких точках роботи планувальника.
SHAPE \ * MERGEFORMAT
код
верифікація
архітектура
валідація
планувальник
вимоги / функції
додаток
системні вимоги
архітектура
кодування
інтеграція
тестування / верифікація

Діаграма 1. Етапи життєвого циклу розробки.

1. Огляд вимог проблемної області.
1.1. Особливості систем реального часу.
Для початку варто дати визначення операційних систем реального часу. Воно взято з [13]. Дане визначення не є класичним, проте володіє тим перевагою, що дозволяється в загальних рисах уявити собі відмінності ОС, що розглядаються в даній роботі від інших аналогічних програм.
Операційні системи реального часу (ОС РВ) - керуюче ПО особливого типу, часто використовується для організації роботи вбудованих комп'ютерних програм, для яких характерні обмеженість ресурсів пам'яті, невисока продуктивність, а також вимоги гарантованого часу відгуку, високого рівня готовності і наявність коштів автомониторинга.
А тепер розглянемо згадане у визначенні більш докладно.
1.1.1. Обмежений час відповіді.
По суті, система реального часу - це апаратно-програмний комплекс, що реагує в передбачувані часи на непередбачуваний потік зовнішніх подій. Це означає, що:
· Вона повинна встигнути відреагувати на подію, що сталася на об'єкті, протягом часу, критичного для цієї події (meet deadline). Величина критичного часу для кожної події визначається об'єктом і самою подією, і, природно, може бути різною, але час реакції системи має бути передбачено (обчислено) при створенні системи. Відсутність реакції в передбачене час вважається для СРВ помилкою.
· Система повинна встигати реагувати на одночасно відбуваються. Навіть якщо два або більше зовнішніх подій відбуваються одночасно, система повинна встигнути зреагувати на кожне з них протягом інтервалів часу, критичного тих подій.
За наслідками виходу за межі інтервалу СРВ діляться на м'які і жорсткі.
Системи жорсткого реального часу не дозволяють жодних затримок реакції системи ні за яких умов, тому що:
· Результати можуть виявитися не допомагають у разі запізнення;
· Може статися катастрофа у разі затримки реакції;
· Вартість запізнення може бути нескінченно велика.
Системи м'якого реального часу характеризуються тим, що затримка реакції не критична, хоча і може призвести до увеличинию вартості результатів і зниження продуктивності системи в цілому.
Основна відмінність між системами жорсткого і м'якого реального часу можна сформулювати так: система жорсткого реального часу ніколи не запізниться з реакцією на подію, система м'якого реального часу - не має спізнюватися з реакцією на подію.
У таблиці 3 наведені часи відгуку для декількох ОС РВ.
1.1.2. Статична основа проектування.
Крім того, застосування операційних систем реального часу завжди конкретно. Якщо ОС загального призначення зазвичай сприймається користувачами (не розробниками) як вже готовий набір додатків, то операційна система реального часу служить тільки інструментом для створення конкретного апаратно-програмного комплексу реального часу.
Для більшості СРВ передбачається, що основна частина оброблюваних даних апріорно відома. Тому найбільш широкий клас користувачів операційних систем реального часу - розробники комплексів реального часу, люди які проектують системи управління та збору даних. Проектуючи і розробляючи конкретну систему реального часу, програміст знає точно які події можуть відбутися на об'єкті, знає критичні терміни обслуговування кожного з цих подій.
1.1.3. Портування.
Управління прокатними станами, роботами, рух на автомагістралях, контроль за станом навколишнього середовища, управління атомними і космічними станціями та багато іншого - область завдань реального часу. Для різних областей застосування ОС РВ існують різні апаратні платформи і для кожної необхідно портування, тобто процес «стикування» програмної частини ОС і її апаратного забезпечення.
При виборі апаратної платформи для систем реального часу основними моментами є жорсткі вимоги до тимчасових характеристиках і гнучкості системи. Вимоги до апаратного забезпечення в даний час досить чітко визначені. Більшість проектів реального часу здійснюється в рамках архітектурних рішень магістрально-модульних систем (ММС).
Однак, як би не була важлива сама ОС РВ, зараз в умовах доступності сумісних апаратних засобів основна увага приділяється розробці і налагодженню прикладного програмного забезпечення, чия частка у витратах на розробку систем реального часу складає до 70%.
По середовищі в якій функціонують системи їх можна розділити на класи: програмування на рівні мікроконтролерів, мінімальне ядро ​​СРВ, ядро ​​СРВ та інструментальне середовище, ОС з повним сервісом.
1.1.4. Вбудовані системи реального часу.
Наступна відмінність - застосування операційної системи реального часу завжди пов'язані з апаратурою, з об'єктом, з подіями, що відбуваються на об'єкті. Система реального часу, як апаратно-програмний комплекс, включає в себе датчики, які реєструють події на об'єкті, модулі введення-виведення, змінюють показання датчиків в цифровий вигляд, придатний для обробки цих показань на комп'ютері, і, нарешті, комп'ютер з програмою, яка реагує на події, що відбуваються на об'єкті. Операційна система реального часу орієнтована на обробку зовнішніх подій. Саме це призводить до корінних відмінностей (у порівнянні з ОС загального призначення) в структурі системи, у функціях ядра, у побудові системи введення-виведення. Операційна система реального часу може бути схожа за призначеною для користувача інтерфейсу на ОС загального призначення (до цього, до речі, прагнуть майже всі виробники операційних системах реального часу), проте влаштована вона абсолютно інакше - більш докладно про це в пункті 2.2.
Останнім часом високопродуктивні мікропроцесори, а з ними і операційні системи реального часу, все частіше використовуються в так званих "глибоко вбудованих" (deeply embedded) застосуваннях. До таких комп'ютерних систем пред'являються дві основні вимоги: малі габарити і низька вартість. Тому глибоко вбудовані мікропроцесорні системи ставлять дві проблеми на шляху застосування серійних ОС РВ: невеликі обсяги використовуваної пам'яті і відсутність "зайвих" інтерфейсів, за якими можна було б пов'язати цільову та інструментальну машини на етапі розробки вбудованого ПЗ.
За структурними характеристиками програмно-апаратні комплекси можна розділити на класи: виконавчі системи реального часу, ядра реального часу, UNIX "и реального часу.
1.1.5. Висновок.
Були розглянуті центральні відмінності систем реального часу від систем поділу часу. В основі цих відмінностей лежить головна вимога до подібних систем - передбачуваність. Користувачі СРВ повинні бути заздалегідь впевнені в тому, що відгук на зовнішній вплив буде отриманий в означений період часу. Це тягне за собою необхідність уявляти собі які обсяги даних несуть у собі зовнішні впливи і якими апаратними можливостями по обробці цих даних має система. Цілком логічно, що системи реального часу не орієнтовані на взаємодію з людиною, а припускають самостійну роботу в критичних точках інженерних систем.
1.2. Особливості управління завданнями.
1.2.1. Управління часом.
Одним з основних властивостей операційних систем реального часу є їхня здатність ізолювати один від одного додатка, тому якщо в програмі виникає збій або виконуються якісь нелегальні операції, ОС може швидко блокувати програму, ініціювати відновлення і захист інших програм або самої системи від серій шкідливих команд .
Якщо не виконується обробка критичних ситуацій або вона відбувається недостатньо швидко, система жорсткого реального часу перериває операцію і блокує її, щоб не постраждала надійність і готовність решти системи. Системи м'якого реального часу більш «поблажливі» і «зазнають» певні, некритичні помилки.
Особливу важливість набувають такі інструменти як засоби роботи з таймерами, необхідні для систем з жорстким тимчасовим регламентом. Розвиненість цих коштів - необхідний атрибут операційних систем реального часу. Вони, як правило, дозволяють:
· Вимірювати і задавати різні проміжки часу (від 1 мкс і вище),
· Генерувати переривання після закінчення тимчасових інтервалів,
· Створювати разові і циклічні будильники.
1.2.2. Управління пам'яттю.
Система реального часу повинна вміти керувати пам'яттю в залежності від критичності завдань. Для стійкої роботи процесів потрібні механізми виділення пам'яті при їх породження, використання пам'яті при життєдіяльності та звільнення.
ОС дозволяє програмістам ізолювати спільно використовувані бібліотеки, дані та системне програмне забезпечення, а також додатки. Та ж сама захист запобігає переповнення стеків пам'яті, викликаного діями будь-яких програм.
1.2.3. Управління доступом (синхронізація).
При одночасній роботі декількох процесів в багатозадачному системі реального часу операційна система повинна забезпечити стійкий механізм для обміну інформацією між запущеними процесами. Зв'язок між процесами (Interprocess communication, скорочено IPC) є ключем до розробки додатків як сукупності процесів, в яких кожен процес виконує відведену йому частину загальної задачі.
Для операційних систем реального часу характерна розвиненість IPC-механізмів. До таких механізмів відносяться: семафори, події, сигнали, засоби для роботи з пам'яттю, що, канали даних (pipes), черги повідомлень. Багато хто з подібних механізмів використовують і в ОС загального призначення, але їх реалізація в операційних системах реального часу має свої особливості - час виконання системних викликів майже не залежить від стану системи, і в кожній операційній системі реального часу є принаймні один швидкий механізм передачі даних від процесу до процесу.
1.2.4. Висновок.
Так само як самі системи реального часу істотно відрізняються від звичайних ОС, так і способи виконання завдань у них мають свою специфіку. Робота з управління їх виконанням перетворюється в складну інженерну задачу, яка включає в себе створення алгоритмів поділу ресурсів системи, планування їх незалежного виділення і звільнення для завдань системи.
1.3. Класифікація систем реального часу.
Кількість операційних систем реального часу, незважаючи на їх специфіку, дуже велике. В огляді журналу "Real-Time Magazine" ще за березень 1997 було згадано близько шістдесяти систем. За минулі роки цих систем стало ще більше. Якщо ж додати до їх числа некомерційні операційні системи реального часу, то ми отримаємо цілком солідне число, що відображає зацікавленість сучасного суспільства в подібних системах. Проте сама специфіка застосування операційних систем реального часу вимагає гарантій надійності, причому гарантій в тому числі і юридичних, - цим, мабуть, можна пояснити той факт, що серед некомерційних систем реального часу немає скільки-небудь популярних.
На рис. 5 дано компактне подання класифікації систем за трьома різними ознаками: клас (відсутність РВ, м'яке РВ, жорстке РВ), складність (одноадресної простір, багатоадресне / захищене), стандартизація (приватне рішення, підмножина POSIX, тільки POSIX, UNIX і POSIX).
1.3.1. Класифікація за структурним характеристикам.
У світі операційних систем реального часу, як втім і в будь-який інший динамічно розвивається галузі, в якій ще немає усталеної досить суворої теорії, існує декілька різноманітних підходів до побудови подібних систем.
1.3.1.1. Виконавчі системи реального часу.
Ознаки систем цього типу - різні платформи для систем розробки і виконання. Додаток реального часу розробляється на host-комп'ютері (комп'ютері системи розробки), потім компонується з ядром і завантажується в цільову систему для виконання. Як правило, додаток реального часу - це одне завдання і паралелізм тут досягається за допомогою ниток (threads).
Системи цього типу мають ряд переваг, серед яких головне - швидкість і реактивність системи. Головна причина високої реактивності систем цього типу - наявність тільки ниток (потоків) і, отже, маленький час перемикання контексту між ними (на відміну від процесів).
З цим головним достоїнством пов'язаний і ряд недоліків: зависання всієї системи при зависанні нитки, проблеми з динамічною підвантаженням нових додатків.
Крім того, системи розробки для продуктів цього класу традиційно дороги (близько $ 20000). Хоча, треба відзначити, що якість і функціональність систем розробки у цьому класі традиційно хороші, так як вони були спочатку кросовими.
Найбільш яскравим представником систем цього класу є операційна система VxWorks. Область застосування - компактні системи реального часу з хорошими часом реакцій.
1.3.1.2. Ядра реального часу
У цей клас входять системи з монолітним ядром, де і міститься реалізація всіх механізмів реального часу цих операційних систем. Історично системи цього типу були добре спроектовані. На відміну від систем інших класів, які з'являлися як тимчасові компроміси і потім "нарощували м'язи" завдяки першим вдалим реалізаціям (виконавчі системи реального часу і UNIX "и реального часу), розробники систем цього класу мали час для розробки систем саме реального часу і не були спочатку обмежені у виборі засобів (наприклад фірма "Microware" мала в своєму розпорядженні три роки для розробки першого варіанту OS-9).
Одна з їхніх особливостей - високий ступінь масштабованості. На базі цих ОС можна побудувати як компактні системи реального часу, так і великі системи серверного класу.
Як правило, ядра реального часу мають два типи систем розробки - кросову і резидентну.
Системи цього класу, як правило, модульні, добре структуровані, мають найбільш розвинений набір специфічних механізмів реального часу, компактні і передбачувані. Найбільш популярні системи цього класу: OS9, QNX.
1.3.1.3. UNIX "и реального часу
Історично системи реального часу створювалися в епоху розквіту і буму UNIX'а і тому багато з них містять ті чи інші запозичення з цієї красивої концепції операційний системи (призначений для користувача інтерфейс, концепція процесів і т.д.).
Частина розробників операційних систем реального часу спробувала просто переписати ядро ​​UNIX, зберігши при цьому інтерфейс користувача процесів з системою, наскільки це було можливо. Реалізація цієї ідеї не була занадто складною, оскільки не було перешкоди в доступі до вихідних текстів ядра, а результат виявився чудовим. Отримали і реальний час, і відразу весь набір призначених для користувача додатків - компілятори, пакети, різні інструментальні системи.
У цьому сенсі творцям систем перших двох класів довелося потрудитися не тільки при створенні ядра реального часу, але і просунутих систем розробки.
Однак UNIX "и реального часу не позбавлені наступних недоліків: системи реального часу виходять досить великими і реактивність їх нижче, ніж реактивність систем перших двох класів.
Найбільш популярним представником систем цього класу є операційна система реального часу LynxOS.
1.3.2. Класифікація за програмному середовищі.
Стає очевидним те, що завдання реального часу необхідно реалізовувати в рамках специфічної системної програмної середовища. Відповідно до [12] системи реального часу можна розділити на 4 класи.
1.3.2.1. Програмування на рівні мікропроцесорів.
У даному випадку програми для програмованих мікропроцесорів, вбудованих в різні пристрої, дуже невеликі і зазвичай написані на мові низького рівня типу асемблера або PLM. Внутрішньосхемного емулятори придатні для налагодження, але високорівневі засоби розробки й налагодження програм не застосовні. Операційне середовище зазвичай недоступна.
1.3.2.2. Мінімальна ядро ​​системи реального часу.
На більш високому рівні знаходяться системи реального часу, щоб забезпечити мінімальну середовище виконання. Передбачені лише основні функції, а управління пам'яттю і диспетчер часто недоступні. Ядро являє собою набір програм, що виконують типові, необхідні для вбудованих систем низького рівня функції, такі, як операції з плаваючою комою і мінімальний сервіс введення / виводу. Прикладна програма розробляється в інструментальному середовищі, а виконується, як правило, на вбудованих системах.
1.3.2.3. Ядро системи реального часу і інструментальне середовище.
Цей клас систем володіє багатьма рисами ОС з повним сервісом. Розробка ведеться в інструментальному середовищі, а виконання - на цільових системах. Цей тип систем забезпечує набагато більш високий рівень сервісу для розробника прикладної програми. Сюди включені такі засоби, як дистанційний символьний відладчик, протокол помилок та інші засоби. Часто є паралельне виконання програм.
1.3.2.4. ОС з повним сервісом.
Такі ОС можуть бути застосовані для будь-яких додатків реального часу. Розробка і виконання прикладних програм ведуться в рамках однієї і тієї ж системи.
Системи 2 і 3 класів прийнято називати системами "жорсткого" реального часу, а 4 класу - "м'якого". Очевидно, це можна пояснити тим, що в першому випадку до системи пред'являються більш жорсткі вимоги щодо часу реакції і необхідного обсягу пам'яті, ніж у другому. Як ми бачимо, середовище розробки і середовище виконання в системах реального часу можуть бути розділені, а вимоги, які пред'являються до них, дуже різні. Розглянемо їх більш докладно.
1.3.3. Технічні характеристики ОС РВ.
1.3.3.1. Час реакції системи.
Майже всі виробники систем реального часу наводять такий параметр, як час реакції системи на переривання (interrupt latency).
У самому справі, якщо головним для системи реального часу є її здатність вчасно відреагувати на зовнішні події, такий параметр, як час реакції системи є ключовим. Однак у даний момент немає, на жаль, загальноприйнятих методологій вимірювання цього параметра, тому він є полем битви маркетингових служб виробників систем реального часу. Є надія, що незабаром ситуація зміниться, тому що вже стартував проект порівняння операційних системах реального часу, який включає в себе в тому числі і розробку методології тестування.
Події, що відбуваються на об'єкті, реєструються датчиками, дані з датчиків передаються в модулі введення-виведення (інтерфейси) системи. Модулі вводу-виводу, отримавши інформацію від датчиків і перетворивши її, генерують запит на переривання в керуючий комп'ютер, подаючи йому тим самим сигнал про те, що на об'єкті відбулася подія. Отримавши сигнал від модуля введення-виведення, система повинна запустити програму обробки цієї події. Інтервал часу - від події на об'єкті і до виконання першої інструкції в програмі обробки цієї події і є часом реакції системи на події, і, проектуючи систему реального часу, розробники повинні вміти обчислювати цей інтервал.
Час виконання ланцюжка дій - від події на об'єкті до генерації переривання - ніяк не залежить від операційних систем реального часу і повністю визначається апаратурою, а ось інтервал часу - від виникнення запиту на переривання і до виконання першої інструкції обробника визначається цілком властивостями операційної системи та архітектурою комп'ютера . Причому цей час потрібно вміти оцінювати в найгіршій для системи ситуації, тобто в припущенні, що процесор завантажений, що в цей час можуть відбуватися інші переривання, що система може виконувати якісь дії, що блокують переривання.
Непоганим підставою для оцінки часів реакції системи можуть служити результати тестування з докладним описом архітектури цільової системи, в якій проводилися вимірювання, засобів вимірювання і точним зазначенням, які проміжки часу вимірювалися. Деякі виробники операційних систем реального часу результати такого тестування надають. Їх не побачиш у рекламних проспектах, але можна відшукати на WEB-сторінках, у документах технічної підтримки, в публікаціях фірм, які проводять незалежне тестування.
Час реакції на переривання, характерне для деяких операційних систем реального часу, представлено на діаграмі 6.
1.3.3.2. Час перемикання контексту.
У операційні системи реального часу закладено паралелізм, можливість одночасної обробки декількох подій, тому всі операційні системи реального часу є багатозадачними (багатопроцесорний, многонітіевимі). Для того щоб вміти оцінювати накладні витрати системи при обробці паралельних подій, необхідно знати час, який система витрачає на передачу управління від процесу до процесу (від завдання до завдання, від нитки до нитки), тобто час перемикання контексту (діаграма 7).
1.3.3.3. Розміри системи.
Для систем реального часу важливим параметром є розмір системи виконання, а саме сумарний розмір мінімально необхідного для роботи програми системного набору (ядро, системні модулі, драйвери і т. д.). Хоча, треба визнати, що з плином часу значення цього параметра зменшується, проте він є важливим і виробники систем реального часу прагнуть до того, щоб розміри ядра і обслуговуючих модулів системи були невеликі.
Приклади: розмір ядра операційної системи реального часу OS-9 на мікропроцесорах МС68xxx - 22 KB, VxWorks - 16 KB.
1.3.3.4. Можливість виконання системи з ПЗУ (ROM).
Це властивість операційних систем реального часу - одне з базових. Воно дозволяє створювати компактні вбудовані СРВ підвищеної надійності, з обмеженим енергоспоживанням, без зовнішніх накопичувачів.
1.3.4. Висновок.
На такому широкому полі діяльності як системи реального часу цілком закономірним виявилося виникнення безлічі підходів до їх створення. В основному вони відрізняються структурою створюваної системи та апаратною платформою, на якій їй передбачається функціонувати. В даний час використовуються чотири основних параметри, які можуть характеризувати правильність обраного підходу.
1.4. Сучасні представники ринку ОС РВ в Росії.
Серед комерційних систем реального часу можна виділити групу провідних систем - за обсягами продажів і за популярністю. Ці системи: VxWorks, OS9, LynxOS, QNX, pSOS, VRTX. У таблиці 8 дані відомості про існуючі в даний час СРВ та їх характерні особливості. У таблиці 4 наведені основні характеристики деяких систем.
Чотири з перерахованих систем будуть розглянуті далі докладно. У системі, яка буде створена в рамках даної роботи, не передбачені функції роботи з роботи з локальними або глобальними мережами. Тому в числі порівняльних параметрів не були згадані ці можливості, які є важливою частиною сучасних ОС РВ.
1.4.1. LynxOS ® 4.x фірми LinuxWorks, Inc.
Призначена для розробки ПЗ вбудованих систем, що працюють в режимі жорсткого реального часу, виробниками комплектного устаткування (OEM) і телекомунікаційного устаткування (TEM), зокрема, виробниками бортових систем військового застосування.
1.4.1.1. Основні властивості LynxOS:
· Підтримує багатозадачні і багатопотокових додатки.
· LynxOS забезпечує сумісність з Linux на рівні ABI (Application Binary Interface), рівні форматів об'єктних файлів, викликів API, що динамічно підключаються бібліотек (DLL), компонування і завантаження на етапі виконання. Це властивість LynxOS є унікальним для систем реального часу і дуже корисним для користувачів (наприклад, у разі відсутності вихідних текстів). Система працює так само з Unix і Java.
· Повністю підтримується стандарт POSIX.1003-1, а також підрозділи POSIX.1003-1b і POSIX.1003-1c, визначають розширення реального часу і роботи з нитками (потоками).
· Багатоплатформність. Підтримує безліч апаратних архітектур (IA-32, PowerPC, MIPS, ARM, XScale, IBM) для обладнання різних фірм виробників.
· Розробка може здійснюватися як на самій цільовій системі (self-hosted), так і на інструментальному комп'ютері (host).
· Є ОС для відповідальних додатків. Має все необхідне для створення сучасних систем, здатних до "гарячої заміни" / "високої доступності" (Hot Swap, High Availability), і пристроїв з високим коефіцієнтом резервування.
· LynxOS-178 - це версія LynxOS, сертифікована відповідно до стандарту DO-178. Це означає повну відповідність з точки зору надійності суворим вимогам для мобільних систем військового та аерокосмічного застосування. Крім того, LynxOS-178 має сертифікований стек TCP / IP для відповідальних додатків в області авіоніки, медицини, атомної промисловості та зв'язку.
· Велика кількість коштів розробок як в рамках самої LynxOS, так і host-систем (Linux, Windows, Solaris).
1.4.1.2. Підтримка програм жорсткого реального часу.
· Кількість завдань: необмежено;
· Кількість пріоритетів: 256;
· Диспетчеризація завдань: витіснення за пріоритетами. 4 алгоритму диспетчеризації (FIFO, Priority Quantum, Round Robin, невитискаючої);
· Детерміноване час перемикання контексту завдяки ефективному алгоритму диспетчеризації реального часу;
· Кошти межзадачного взаємодій як у стандарті POSIX (семафори, колективна пам'ять, сокети, сигнали, канали, м'ютекси, умовні змінні), так і в термінах Unix SystemV (черги повідомлень, семафори, колективна пам'ять);
· Підтримка таймерів реального часу і годин POSIX;
· Конфігурування квантів часу для різних рівнів пріоритетів і для дозволу значення одиниці (tick) таймера;
· Виконання завдань у захищеному режимі, повна підтримка MMU (Memory Management Unit).
1.4.2. OS-9/Hawk фірми Microware Systems.
Багатозадачна, розрахована на багато користувачів операційна система для вбудованих додатків, що працюють в режимі реального часу. Для виробників продуктів у таких областях, як мобільні телекомунікаційні пристрої, що вбудовуються термінали доступу в Інтернет, інтерактивні цифрові телевізійні приставки.
1.4.2.1. Основні властивості OS-9/Hawk.
· Портативна версія OS-9 дозволяє застосовувати в проекті найбільш підходящі мікропроцесорні пристрої (Motorola ColdFire; Motorola M-CORE; Intel Pentium; Intel StrongARM; PowerPC; ARM; Hitachi SuperH; MIPS; MicroSPARC).
· Система введення-виведення ОС підтримує різні формати пристроїв масової пам'яті і основних інтерфейсів периферійних пристроїв: Raw, MS-DOS, True FFS, CardSoft PCMCIA, USB, IrDA.
· У середовищі OS-9 користувач може вибирати кілька програмних комунікаційних платформ: mwSoftStax (Microware), Harris & Jeffries, Trillium, - що раніше було виключно прерогативою спеціалізованих ОС.
· У інструментальний пакет Hawk вбудована бібліотека Tools.h з бібліотеки Rogue Wave C + + Classes Lib.
· Hawk - інтегрована крос-середовище розробки додатків для OS-9 - функціонує на платформі MS Windows NT.
· Hawk є відкритим середовищем і надає стороннім розробникам інструментальних засобів більш сотні API, що дозволяють включати в рамках Hawk Partners Program до складу середовища Hawk продукти відомих фірм розробників інструментального ПО.
· Засіб верифікації програмного забезпечення CodeTEST (Applied Microsystems) вбудовано в Hawk і являє собою зручний та ефективний інструментарій трасування вбудованого ПЗ та контролю його характеристик, а також ходу виконання тестів і розподілу пам'яті.
1.4.2.2. Підтримка програм жорсткого реального часу.
· Масштабується, повністю витісняється ядро ​​ОС;
· Підтримує функціонування до 65535 процесів;
· Надає 65535 рівнів пріоритету;
· Забезпечує роботу до 255 користувачів;
· Більше 90 системних викликів ядра надають можливість керувати динамічними режимами диспетчеризації, розподілом пам'яті, межпроцессорной комунікацією і т.д. аж до управління вбудованим в ядро ​​ОС режимом економічного споживання харчування.
· Характеристики продуктивності: 5.6 мкс Interrupt Latence Time, 14 мкс для часу перемикання контексту процесу (MC68040, 30MHz).
1.4.3. VxWorks фірми Wind River Systems.
ОС РВ VxWorks призначена для застосування на вбудованих комп'ютерах, що працюють в системах "жорсткого" реального часу. VxWorks є системою з крос-засобами розробки прикладного програмного забезпечення.
1.4.3.1. Основні властивості VxWorks.
· Підтримувані цільові архітектури (targets): Motorola 680х0 і CPU32, PowerPC; Intel 386/486/Pentium, Intel 960; Sparc, Mips R3000/4000; AMD 29K, Motorola 88110; HP PA-RISC; Hitachi SH7600; DEC Alpha.
· Підтримувані інструментальні платформи (hosts): Sun SPARCstation (SunOS та Solaris); HP 9000/400, 700 (HP-UX); IBM RS6000 (AIX); Silicon Graphics (IRIX); DEC Alpha (OSF / 1); PC (Windows) .
· Усе апаратно-залежні частини VxWorks винесені в окремі модулі для того, щоб розробник вбудованої комп'ютерної системи міг сам портувати VxWorks на свою нестандартну цільову машину.
· В останній версії VxWorks 5.2 реалізовані сумісні з розширеннями POSIX для додатків реального часу (POSIX Real-Time Extensions 1003.1b) функції асинхронного вводу-виводу, лічильні семафори, черги повідомлень, сигнали, управління пам'яттю (блокування сторінок), управління диспетчеризацією, годинник і таймери.
· Стандартним мовою програмування в інструментальному комплексі VxWorks є мова С. Система програмування на мові C + + не входить в стандартну конфігурацію інструментального комплексу VxWorks і поставляється як додатковий продукт. Система програмування на мові Ada для VxWorks поставляється майже всіма Ada-виробниками.
· Можливість дослідження динаміки виконання програм і зміни даних надають спеціальні засоби налагодження в реальному масштабі часу, які трасує цікавлять користувача події і накопичують їх у буфері для подальшого аналізу.
1.4.3.2. Підтримка програм жорсткого реального часу.
· Побудовано за технологією мікроядра.
· Являє собою архітектуру високої готовності з розподіленою передачею повідомлень і підтримкою відмовостійкості.
· ОС дозволяє програмістам ізолювати спільно використовувані бібліотеки, дані та системне програмне забезпечення, а також додатки.
1.4.4. QNX4 фірми ОРАКУЛ.
QNX4 - багатозадачна багатокористувацька операційна система жорсткого реального часу (ОСРВ) з архітектурою на основі мікроядра і підтримкою ряду стандартів сімейства POSIX.
1.4.4.1. Основні властивості QNX4.
· Складається з мікроядра і набору необов'язкових модулів.
· Надає сервіси стандарту POSIX.1 і його розширення для систем реального часу POSIX.1b (POSIX.4).
· Можна використовувати для розширення функціональних можливостей як штатні модулі, так і свої власні.
· Надаване QNX4 оточення захищеного режиму дає можливість легко і безпечно тестувати свої нові модулі розширення.
· Можливості високошвидкісної трасування діагностичних подій.
· Дозволяє запускати процеси по мережі з повним спадкуванням оточення, включаючи відкриті файли, поточний каталог, файлові дескриптори та ідентифікатор користувача.
1.4.4.2. Підтримка програм жорсткого реального часу.
· Будучи істинно мікроядерної ОС, QNX4 будується навколо компактного високонадійного «стрижня» - має мікроядро розміром всього 10 Кбайт.
· Мікроядро QNX4 має досить малими розмірами для вбудовування в ПЗУ.
· Має досить великою потужністю для управління розподіленою мережею, що містить кілька сотень процесорів.
· Менеджер пристроїв є високопродуктивним і вносять дуже малі накладні витрати серверним процесом, що забезпечує інтерфейс між процесами і термінальними пристроями.
1.4.5. Висновок.
Системи реального часу зараз є затребуваним продуктом на ринку програмного забезпечення. Існує ціла гамма засобів даного напрямку, що покриває практично весь спектр можливих застосувань подібних систем підвищеної надійності.
1.5. Методологія розробки програмного забезпечення.
Зростаюча складність сучасного програмного забезпечення призвела до створення спеціальної наукової дисципліни - комп'ютерної інженерії (Software Engineering), основним завданням якої є створення ефективних методів розробки складних програмних систем.
1.5.1. Історія розвитку.
Об'єктно-орієнтовані методології розробки програмного забезпечення (перший напрямок) стали інтенсивно розвиватися з кінця 80-х років. У 1997 р. OMG (Object Management Group) прийняла UML, що з'явився в результаті злиття кількох відомих методологій, як стандарт мови об'єктно-орієнтованого моделювання. Ще одним об'єктно-орієнтованим підходом є методологія ROOM, створена для розробки систем реального часу. Одночасно протягом останніх 20 років міжнародним комітетом ITU розвиваються стандарти для розробки телекомунікаційних систем (другий напрямок): SDL, MSC і т.д. Крім того, з 70-х років розвиваються структурні методології розробки програмного забезпечення (третій напрямок): SADT, IDEF-стандарти, метод Йордана і т.д. В даний час ці методології міцно закріпилися в області розробки інформаційних систем. Вони є ефективним засобом аналізу систем в цілому та успішно застосовуються.
У даній роботі описується об'єктно-орієнтована методологія Real. Методологія Real грунтується, головним чином, на UML, SDL, ROOM і відображає перераховані інтеграційні тенденції. Крім стандартних для об'єктно-орієнтованого підходу рис у Real додані додаткові можливості, спрямовані на дві спеціальні області програмного забезпечення: для інформаційних систем і для систем реального часу.
Природно, що Real не претендує на те, щоб покрити всі можливості програмних продуктів відповідних областей. У той же час, враховуючи сучасний рівень розвитку локальних і глобальних інформаційних мереж і зростаючу складність програмного забезпечення, в інформаційних системах все більшої популярності набуває технологія клієнт-сервер, тобто багато інформаційних системи набувають яскраво виражений подієво-орієнтований аспект, який глибоко опрацьовано в методологіях розробки програмного забезпечення систем реального часу. З іншого боку, великі розподілені системи реального часу потребують, як правило, у зберіганні, доступі та передачі величезної кількості інформації (наприклад, тарифікаційної і аутентификационной), а не тільки керуючих сигналів і даних трафіку. Таким чином, методологія Real підходить для розробки програмного забезпечення обох областей, але найбільш ефективна для їх перетину.
1.5.2. Розробка програмного забезпечення систем реального часу
Основне призначення Real стосовно до систем реального часу - проектування складної керуючої логіки з подальшою можливістю автоматичної генерації коду. Відзначимо, що методологія Real не орієнтована спеціальним чином на розробку обладнання і програмного забезпечення, безпосередньо з ним контактує (драйверів пристроїв тощо), а також мережевих протоколів нижнього рівня. Однак ми вважаємо, що для цих завдань вона підходить приблизно в тій же мірі, як і UML.
Як показує практика, прямі гілки складних алгоритмів досить зручно і наочно визначити за допомогою сценаріїв. На початкових етапах розробки системи потрібно чітко визначити логіку всіх взаємодій. При цьому правила поведінки системи в помилкових ситуаціях в більшості випадків можна доопрацювати пізніше. За сценаріями можна згенерувати STD-або SDL-діаграми і продовжити створення специфікацій вже в цьому стилі, враховуючи всі допустимі варіанти поведінки системи.
У термінах Real основною структурною одиницею системи реального часу є об'єкт. Об'єкти взаємодіють один з одним через інтерфейси. Під взаємодією розуміється посилка повідомлень, виклик методів і звернення до атрибутів інтерфейсу. Оскільки останнім часом все більше число систем реального часу стають розподіленими і мережевими, поняття інтерфейсу набуває особливої ​​важливості. Раніше ситуація була іншою, прикладом чого служать ранні версії мови SDL, в яких інтерфейси були відсутні. Інтерфейси Real сильно відрізняються від портів (gate) SDL (складом, способом зв'язку з класами) та інтерфейсів UML (складом, способом зв'язку з класами, способом зображення), а також інтерфейсів в ROOM (складом і способом зображення).
У системах реального часу важливу роль відіграють абстракції точок входу і виходу у різних компонент програмного забезпечення. Тому в модель класів Real був доданий з ROOM спеціальний елемент - порт.
Компонента програмного забезпечення, визначена у вигляді класу з портами і інтерфейсами, може мати кінцево-автоматне поведінка, що описується в термінах поведінкової моделі Real. Поведінкова модель, у свою чергу, представляється двома альтернативними нотаціями: перша заснована на варіанті STD, представленому в ROOM, друга - на розширеному кінцевому автоматі SDL. За допомогою STD-нотації зручно визначати поведінку компонент системи на ранніх етапах розробки: безліч дрібних деталей можна тимчасово прибрати з поля зору. У той же час на SDL-діаграмах можна наочно зобразити найдрібніші подробиці алгоритмів.
Ця можливість стає корисною на пізніх етапах проектування. При цьому інформацію, зображену на STD-діаграмах, можна "завантажити" на SDL-діаграми, таким чином, результати ранніх етапів при переході до більш формальної специфікації не будуть втрачені. У рамках Real, STD і SDL нотації призначені для опису єдиної поведінкової моделі, так що завжди можливо і зворотне - завантаження на STD-діаграму результатів роботи з SDL-редактором. На поведінкову модель Real сильно вплинула технологія SDL / PLUS 20: як і не використовуються типи даних і вирази SDL, але застосовується більш гнучка стратегія зв'язку з мовами реалізації [7] замість заздалегідь фіксованого мови [11].
1.5.3. Висновок.
Використання спеціальної подієво-орієнтованої методології розробки програмного продукту допоможе покращити стрункість організації прикладного програми і, в цілому, добре відіб'ється на надійності створюваної системи реального часу.
1.6. Постановка завдання курсового проекту.
Перед створенням програмної системи реального часу було проведено аналіз діючих в даний момент розробок даного напрямку. Він показав, що існуючий спектр ОС може забезпечити всі потреби завдань реального часу. Вибір системи (якщо абстрагуватися від ціни, умов поставки і т.д.) диктується тільки тією обставиною, чи задовольняє вона умов стоїть завдання. Наприклад, якщо необхідна хороша операційна підтримка мережевих засобів, то доцільно використовувати QNX - многозадачную операційну систему жорсткого реального часу з архітектурою на основі мікроядра. Якщо необхідна дуже висока швидкість реакції системи, можна використовувати VxWorks. У даній роботі при створенні дуже невеликий, не дуже складної, вбудованої прикладної програми було вирішено орієнтуватися LynxOS, що відноситься до класу Unix'ов реального часу.
У розробці будуть використані тільки базові, обов'язкові механізми ОСРВ. Крім того, майже в кожній операційній системі реального часу можна знайти цілий набір додаткових, специфічних тільки для неї механізмів, що стосуються системи введення-виведення, управління переривань, роботи з пам'яттю. Кожна система містить також ряд засобів, які забезпечують її надійність, наприклад, вбудовані механізми контролю цілісності кодів.
Головний же висновок полягає в тому, що будь-яке завдання реального часу вимагає операційної підтримки реального часу, та інші системні рішення при цьому неприйнятні. На основі ОС загального призначення UNIX, орієнтованої на оптимальний розподіл ресурсів комп'ютера між користувачами і завданнями (система поділу часу) буде створена програмна розробка планувальника завдань, у якому головною метою є встигнути зреагувати на події, що відбуваються в жорстко заданий інтервал часу (система реального часу).
На основі планувальника буде реалізований протокол, що вимагає підтримки реального часу. Для проектування його реалізації буде використана об'єктно-орієнтована методологія. Така методологія характеризує скоріше підхід до планування програми, ніж використовувані засоби мови, тому що в авіаційних системах, до яких і належить реалізований протокол A415 ARINC, не дозволено використання пам'яті з «купи». У той час як динамічне виділення пам'яті є важливою частиною використання мов, подібних C + + або Java.

2. Моделі і методи предметної області.
2.1. Визначення.
Спочатку розглянемо основне визначення, навколо якого і побудована дана робота. Воно дано американським вченим Дональдом Гілліс (Donald Gillies).
· Система реального часу - це система, в якій правильність обчислень залежить не тільки від логічної коректності результату, але і від часу, протягом якого цей результат отриманий. Система працює невірно, якщо її часові параметри не відповідають заданим.
Розглянемо найпростіші визначення, що використовуються в даній галузі знань. Наведено їх неформальне визначення, яке переслідує своєю метою дати загальне уявлення про використовуваних термінах і уточнити мається на увазі під ними в даній роботі значення.
· Стан - стабільне положення об'єкта, коли він готовий до прийняття запитів на взаємодію з боку інших об'єктів. Зі станом може бути пов'язана деяка діяльність об'єкта (наприклад, вхідна і вихідна). Стан може бути складним, тобто містити підстани.
· Подія - отримання повідомлення чи закінчення терміну дії таймера.
· Дія - посилка повідомлення, установка таймера, блок коду на цільовому мовою.
· Час прибуття завдання - час, коли виникає необхідність у виконанні даного завдання.
· Виклик завдання - початок виконання даного завдання після прибуття.
· Планувальник - механізм, який визначає, який результат повинен бути обчислений і в який час. Результат роботи планувальника називається розкладом.
· Політикою планування (або управління) називається набір правил, які визначають те, як планувальник вибирає наступний процес для запуску, як утворюється черга процесів на виконання і скільки часу виділяється кожному процесу на виконання.
Визначення, що безпосередньо зачіпають специфіку даної роботи.
· Масштабована ОС - операційна система, що характеризується високим рівнем модульності, при якому окремі функції системи можна динамічно відключати / підключати без шкоди для загальної функціональності системи. Така ОС в залежності від розв'язуваної задачі, може бути встановлена ​​як на FLASH-носій, так і на гігабайтний жорсткий диск.
· Мікроядерна ОС - операційна система, в основу архітектури якої покладена спеціальна частина виконуваного коду - мікроядро, що реалізує базові функції.
· Розрахована на багато користувачів ОС - операційна система, орієнтована на одночасну роботу з декількома користувачами.
· Багатозадачна ОС - операційна система, орієнтована на паралельне виконання системою кількох завдань. Істинно багатозадачного ОС може бути тільки при наявності більш ніж одного мікропроцесора, але сучасні операційні системи мають прийнятними механізмами забезпечення псевдопаралельною роботи.
· Мережева ОС - операційна система, орієнтована не тільки на роботу з використанням ресурсів свого апаратного забезпечення, але і на взаємодію з віддаленими ресурсами з використання спеціальних протоколів.
2.2. Принципова структура.
2.2.1. Середовище виконання.
Основне призначення будь-якої операційної системи - це раціональне управління ресурсами комп'ютера під час його роботи. Всі дії операційної системи із забезпечення успішного діалогу з користувачем або користувачами зводяться до наступних простих дій - управлінню виконанням програм і роботою служб, запису та читання файлів з диска, обміну інформацією з мережі. Причому, всі ці прості дії повинні виконуватися злагоджено і не створювати конфліктних ситуацій при роботі системи. Для цього потрібно звернути увагу на середу, в якій функціонує додаток реального часу. Вимоги, що пред'являються до середовища виконання систем реального часу, наступні:
· Невелика пам'ять системи - для можливості її вбудовування;
· Система повинна бути повністю резидентної в пам'яті, щоб уникнути заміщення сторінок пам'яті або підкачки;
· Система повинна бути многозадачной - для забезпечення максимально ефективного використання всіх ресурсів системи;
· Ядро з пріоритетом на обслуговування переривання.
Пріоритет на переривання означає, що готовий до запуску процес, у якого деяким пріоритетом, обов'язково має перевагу в черзі по відношенню до процесу з більш низьким пріоритетом, швидко заміняє останній і надходить на виконання. Ядро закінчує будь-яку сервісну роботу, як тільки надходить завдання з вищим пріоритетом. Це гарантує передбачуваність системи;
· Диспетчер з пріоритетом.
Дає можливість розробнику прикладної програми присвоїти кожному завантажувальному модулю пріоритет, непідвладний системі. Присвоєння пріоритетів використовується для визначення черговості запуску програм, готових до виконання. Альтернативним такого типу диспетчеризації є диспетчеризація типу "карусель", при якій кожної готової до продовження програмі дається рівний шанс запуску. При використанні цього методу немає контролю за тим, яка програма і коли буде виконуватися. У середовищі реального часу це неприпустимо. Диспетчеризація, в основу якої покладено принцип присвоєння пріоритету, і наявність ядра з пріоритетом на переривання дозволяють розробнику прикладної програми повністю контролювати систему. Якщо настає подія з вищим пріоритетом, система припиняє обробку завдання з нижчим пріоритетом і відповідає на знову надійшов запит.
Поєднання описаних вище властивостей створює потужну і ефективну середу виконання в реальному часі.
2.2.2. Ядро систем реального часу.
Крім властивостей середовища виконання, необхідно розглянути також сервіс, що надається ядром ОС реального часу. Ядро або диспетчер є основою будь-якого середовища виконання в реальному часі. Мікроядро реалізує базові функції операційної системи, на які спираються системні сервіси і додатки. У системі реального часу диспетчер займає місце між апаратними засобами цільового комп'ютера і прикладним програмним забезпеченням. У результаті, такі важливі компоненти ОС як файлова система, мережева підтримка і т.д. перетворюються у по-справжньому незалежні модулі, які функціонують як окремі процеси і взаємодіють з ядром і один з одним на загальних підставах. Всі компоненти системи використовують кошти мікроядра для обміну повідомленнями, але взаємодіють безпосередньо. Наданий ядром сервіс дає прикладним програмам доступ до таких ресурсів системи, як, наприклад, пам'ять або пристрої вводу / виводу.
Ядро може забезпечувати сервіс п'яти типів:
2.2.2.1. Синхронізація ресурсів.
Метод синхронізації вимагає обмежити доступ до загальних ресурсів (даним та периферійного обладнання). Найбільш поширений тип примітивної синхронізації - двійковий семафор, що забезпечує виборчий доступ до загальних ресурсів. Так, процес, що вимагає захищеного семафором ресурсу, змушений чекати до тих пір, поки семафор не стане доступним, що свідчить про звільнення очікуваного ресурсу, і, захопивши ресурс, встановити семафор. У свою чергу, інші процеси також будуть очікувати доступу до ресурсу аж до того моменту, коли семафор поверне відповідний ресурс системі розподілу ресурсів. Системи, що володіють більшою ошібкоустойчівостью, можуть мати рахунковий семафор. Цей вид семафора дозволяє одночасний доступ до ресурсу лише певній кількості процесів.
2.2.2.2. Межзадачного обмін.
Часто необхідно забезпечити передачу даних між програмами всередині однієї і тієї ж системи. Крім того, у багатьох програмах виникає необхідність взаємодії з іншими системами через мережу. Внутрішній зв'язок може бути здійснена через систему передачі повідомлень. Зовнішню зв'язок можна організувати або через датаграму (найкращий спосіб доставки), або по лініях зв'язку (гарантована доставка). Вибір того чи іншого способу залежить від протоколу зв'язку.
2.2.2.3. Поділ даних.
У прикладних програмах, що працюють у реальному часі, найбільш тривалим є збір даних. Дані часто необхідні для роботи інших програм або потрібні системі для виконання будь-яких своїх функцій. У багатьох системах передбачений доступ до загальних розділам пам'яті. Широко поширена організація черги даних. Застосовується багато типів черг, кожен з яких володіє власними достоїнствами.
2.2.2.4. Обробка запитів зовнішніх пристроїв.
Кожна прикладна програма в реальному часі пов'язана із зовнішнім пристроєм певного типу. Ядро має забезпечувати служби вводу / виводу, що дозволяють прикладним програмам здійснювати читання з цих пристроїв та запис на них. Для додатків реального часу звичайним є наявність специфічного для цього додатка зовнішнього пристрою. Ядро має надавати сервіс, який полегшує роботу з драйверами пристроїв. Наприклад, давати можливість запису на мовах високого рівня - таких, як Сі чи Паскаль.
2.2.2.5. Обробка особливих ситуацій.
Особлива ситуація є подія, що виникає під час виконання програми. Вона може бути синхронною, якщо її виникнення передбачувано, як, наприклад, розподіл на нуль. А може бути і асинхронної, якщо виникає непередбачено, як, наприклад, падіння напруги. Надання можливості обробляти події такого типу дозволяє прикладним програмам реального часу швидко і передбачувано відповідати на внутрішні та зовнішні події. Існують два методи обробки особливих ситуацій - використання значень стану для виявлення помилкових умов та використання обробника особливих ситуацій для переривання хибних умов та їх коригування.
2.2.3. Пікоядро.
Базові вимоги сучасних систем реального часу стали настільки великі, що назріла необхідність у структуризації вже самого мікроядра. Була висунута ідея так званого «пікоядра». Пікоядро - в даному випадку це ядро, що має такі властивості:
· Не має будь-яких станів (початкових, кінцевих або проміжних), ядро ​​без стану. Не вимагає ініціалізації і деініціалізацію.
· Реалізує і містить в собі дуже мала кількість функцій і даних - тільки функції для роботи з об'єктами.
· Надає об'єктно-орієнтований інтерфейс системі у вигляді невеликої кількості системних викликів для роботи з об'єктами.
· Є повністю пасивною частиною коду операційної системи - код ядра виконується тільки під час системних викликів.
· У більшості випадків є звичайною статичною бібліотекою, яка компонується з головної системної частиною ОС - менеджером процесів.
2.3. Методи управління завданнями в ОС РВ.
2.3.1. Класифікація підходів.
Існує велика кількість різних методів управління завданнями. Кожен з них призначений для використання в певному класі систем, кожна з яких заснована на деякій множині обмежень.
2.3.1.1. Статичний планування.
Більшість всіх існуючих методів відносяться до статичного планування. У цьому випадку вважається, що все безліч завдань системи і всі їх характеристики відомі заздалегідь. У цьому випадку розклад роботи завдань будується на початок роботи системи і залишається постійним під час її функціонування. У цьому розкладі визначені часи старту для всіх задач системи. Протягом роботи системи планувальник вибирає таку задачу для запуску відповідно до цього розкладу. Розклад циклічно повторюється.
Однак у реальних системах одне подібне розклад не може передбачити всі можливі ситуації, які можуть виникнути. Крім того, в системі може бути декілька незалежних режимів роботи, перемикання між якими може відбуватися в наперед визначений час. Тому зазвичай на практиці до початку роботи складається декілька розкладів для різних випадків. Потім під час функціонування системи розкладу змінюються. Це може відбуватися або в непередбачувані або в заздалегідь певні моменти часу, коли потрібна була зміна режиму роботи.
2.3.1.2. Динамічне планування.
При динамічному ж плануванні планувальник в кожен момент часу володіє повними знаннями лише про поточний безлічі завдань. У момент планування даної множини, він не має жодних відомостей про ті завдання, які можуть з'явитися в майбутньому. Тому розклад змінюється з часом. Динамічних алгоритмів планування існує значно менше, ніж статичних.
2.3.1.3. Планування, засноване на часі.
У цьому випадку проводиться статичний аналіз системи, в результаті чого будується розклад, який потім використовується під час роботи для того, щоб вирішити, коли і яке завдання повинна почати своє виконання. Цей розклад містить фіксований час старту для кожного прикладу завдань, грунтуючись на часі виконання в гіршому випадку і всіх взаимозависимостях між завданнями. Потім цей розклад може змінитися.
Планувальник повинен містити всю додаткову інформацію про всі прикладах всіх завдань. Коли прибуде нове завдання необхідно визначити, грунтуючись на існуючому розкладі, чи можна її туди додати, і якщо так, то побудувати новий розклад.
Даний клас методів застосовуються для періодичних завдань, або для завдань, які можуть бути зведені до періодичним. Основним критерієм для статичного планування періодичних завдань можна вважати передбачуваність, тобто визначення исполнимого розкладу, в якому всі завдання задовольняють всім своїм обмеженням.
Так як в цьому підході, виходячи із заданих характеристик, будується таблиця, яка визначає час запуску і час виконання для кожного завдання, після чого завдання розташовуються відповідно до цього розкладом, то, як наслідок, те, коли і де виконуються завдання, суворо фіксоване . Цей підхід не є достатньо гнучким, оскільки будь-яка зміна характеристик якої-небудь задачі може вимагати повної перебудови всієї таблиці.
Так як завдання можуть мати безліч різних обмежень, то для знаходження исполнимого розкладу застосовуються різні методи, наприклад, математичного програмування. Найчастіше використовується метод гілок і меж.
2.3.1.4. Планування апериодических завдань
Використовуючи даний принцип можна планувати і апериодические завдання. При цьому вони плануються під час роботи. На початку крайні терміни всіх прикладів завдань сортуються, після чого розклад ділиться на безліч непересічних інтервалів роботи. Потім для цих інтервалів визначаються запасні проміжки часу, які можуть бути використані для планування новоприбулих апериодических завдань.
Інший метод заснований на використанні того факту, що виконання завдання може бути динамічно зрушено вліво або вправо по часовій шкалі до тих пір, поки всі тимчасові обмеження для всіх завдань все ще здійсненні. Завдання мають бути переривається.
2.3.1.5. Планування, кероване пріоритетами.
У цьому випадку також проводиться статичний аналіз, але на відміну від попереднього випадку чіткий розклад не будується, а лише встановлюються пріоритети для всіх завдань. Під час роботи системи активізується перша готова до запуску завдання з найвищим пріоритетом. При цьому якщо в цей момент виконується завдання з більш низьким пріоритетом, то вона призупинить своє виконання і процесор буде відданий нової задачі з більш високим значенням пріорату.
Пріоритети призначаються виходячи з тимчасових обмежень завдань. Вони можуть бути статичними або динамічними. Статичні пріоритети, на відміну від динамічних, задаються один раз і не змінюються з плином часу.
2.3.2. Огляд методів.
2.3.2.1. Rate-monotonic (RM).
Метод призначає статичні пріоритети завданням грунтуючись на їх періодах. У цьому методі пріоритети визначаються наступним чином: завдання з найменшим періодом отримує найвищий пріоритет.
Вони також показали, що ця схема є оптимальною серед всіх статичних алгоритмів. Під оптимальним розуміється те, що якщо безліч завдань може бути сплановано будь-яким іншим статичним алгоритмом, заснованому на пріоритетах, то воно також може бути сплановано і цим методом.
Вихідний RM підхід має ряд обмежень:
· Всі завдання повинні бути незалежні один від одного, тобто між ними немає ні взаємодії, ні загальних ресурсів.
· Всі завдання повинні бути періодичними.
· Усі завдання можуть бути припинені іншими завданнями з більш високими пріоритетами. Однак жодне завдання не може блокуватися, очікуючи зовнішнього події.
· Час виконання постійно.
· Для завдань визначено час виконання у гіршому випадку.
· Усі завдання мають крайній термін, еквівалентний їх періоду.
Було проведено велику кількість досліджень для розширення цих методів. У результаті цих робіт були зняті або ослаблені обмеження, що накладаються на завдання у вихідної моделі.
Так в протоколі пріоритетних кордонів (Priority Ceiling Protocol) і деяких інших схожих (Stack Resource Protocol) вдалося позбутися від обмеження на взаємодію задач. Також було запропоновано багато методів приведення неперіодичних завдань до періодичним.
2.3.2.2. Deadline Monotonic (DM).
Метод може бути використаний для планування завдань, які мають крайні терміни менші або рівні періодів. Він послаблює обмеження на величину крайнього терміну у схемі планування RM. У цьому випадку пріоритет, призначений задачі, обернено пропорційна величині її крайнього терміну, тобто завдання з найкоротшим крайнім терміном має найвищий пріоритет незалежно від її періоду. Якщо два завдання мають однакові крайні терміни, то вони отримують пріоритети в довільному порядку відносно один одного. Метод може обслуговувати як періодичні, так і спорадичні завдання.
Такий метод розстановки пріоритетів буде оптимальним, якщо виконуються наступні умови:
· Безліч завдань - фіксований безліч жорстких завдань;
· Завдання періодичні або спорадичні;
· Завдання мають певне (відоме) час виконання у гіршому разі;
· Для завдань визначено критичний момент, тобто час виконання у гіршому випадку.
Оптимальність тут також означає, що якщо будь-який планувальник з фіксованими пріоритетами може спланувати безліч завдань, які мають крайні терміни менші або рівні періоду, і виконані відповідні обмеження, то і цей планувальник теж може.
2.3.2.3. Планування апериодических завдань.
2.3.2.3.1. Метод фонового виконання.
Найпростіший підхід - це обробляти апериодические завдання у фоновому режимі і запускати їх тільки тоді, коли процесор не зайнятий виконанням якої-небудь з періодичних завдань.
2.3.2.3.2. Метод опитування.
Метод використовує окрему періодичну задачу з високим пріоритетом для підтримки виконання апериодических завдань.
Обидва цих методу неефективні, коли час відповіді апериодической завдання важливо.
2.3.2.3.3. Алгоритм невідкладного сервера (IS)
Це також підхід збереження пропускної здатності. Він також використовує періодичний сервер, який має найвищий пріоритет, але не обов'язково найбільш короткий період. Сервер призупиняється, якщо не залишилося жодної апериодической завдання, і активізується негайно при прибутті апериодической завдання.
2.3.2.3.4. Останній шанс.
Цей алгоритм є глобально оптимальним у тому сенсі, що забезпечує мінімальний час відповіді для апериодических завдань (за умови виконання всіх крайніх термінів періодичних завдань) серед всіх можливих методів планування періодичних і апериодических завдань.
Планування полягає в тому, що якщо ще залишається апериодическая завдання, яке має бути виконана, наступна періодична завдання не буде запущена до самого останнього можливого моменту, званого часом повідомлення, коли ще зберігається гарантія виконання її крайнього терміну (також як і всіх інших періодичних завдань) .
Цей метод гарантує своєчасність виконання періодичних завдань і максимізує відповідну реакцію апериодических завдань.
При використанні цього методу спочатку застосовується будь-який алгоритм з фіксованими пріоритетами для планування періодичних завдань до початку роботи системи. Всі періодичні задачі мають більш високі пріоритети, ніж апериодические.
2.3.2.4. EDF.
У методі EDF пріоритети завданням призначаються виходячи з їх крайніх термінів на поточний момент. У цьому випадку завдання з найближчий крайнім терміном отримує найвищий пріоритет. Цей метод також є оптимальним у тому сенсі, що якщо можна знайти здійсненне розклад для даної безлічі завдань з фіксованими пріоритетами, то завжди можна знайти здійсненне розклад і з використанням цього методу. Однак він є оптимальним лише за недовантаження системи, але в умовах перевантаження веде себе досить погано.
Він часто вважається небезпечним через те, що за умови перевантаження системи він може показати небажану поведінку. Проте під час роботи жорстких систем реального часу перевантажень не повинно виникати, тому що невиконання крайнього терміну завдання може призвести до серйозних наслідків. Тому для таких систем необхідно проводити апріорне доказ того, що коли в усіх завдань у системі одночасно виникнуть потреби в системних ресурсах, то всі їхні обмеження за часом, як і раніше будуть виконані.
2.3.2.5. Сервер, припускає затримку (DS) і Алгоритм обміну пріоритетами (PE).
Ці методи зберігають доступними ресурси системи, спочатку виділені для апериодических завдань.
Ці методи покращують середній час відповіді системи і відрізняються один від одного способом збереження пропускної здатності. PE алгоритм роздає час виконання, виділений для роботи найпріорітетніше періодичного сервера, іншим періодичних задач з меншим пріоритетом, якщо воно не потрібно для роботи апериодических завдань.
На відміну від нього DS не віддає час виконання цього завдання, коли не залишилося жодної апериодической завдання. Замість цього він зберігає це найпріорітетніше час виконання або поки не прибуде апериодическая завдання, або поки не закінчиться період сервера.
Цей метод простіший в реалізації, але гірше в виконанні.
2.4. Методологія розробки програмного забезпечення.
2.4.1. Основи методології Real.
Не зупиняючись, загалом, на процесі розробки програмного забезпечення, перелічимо, які моделі використовуються в Real для опису системи, що розробляється:
· Модель вимог до системи:
Описова модель - у текстовому вигляді описує деякі вимоги до системи.
Модель випадків використання - описує вимоги, що пред'являються до системи її оточенням, тобто відповідає на питання "що і для кого повинна робити система?".
Функціональна модель - описує розбиття випадків використання і функцій на підфункції. Дає відповідь на питання "як повинні реалізовуватися функції системи в термінах своїх підфункцій?".
· Динамічна модель:
Модель об'єктів - описує ролі об'єктів системи та відповідає на питання "які об'єкти взаємодіють при виконанні функцій системи?".
Модель взаємодій - описує сценарії взаємодії об'єктів системи між собою і з користувачами, тобто дає відповідь на питання "як об'єкти взаємодіють один з одним для виконання функцій системи?".
Поведінкова модель - описує алгоритми поведінки об'єктів системи, тобто відповідає на питання "як повинен вести себе кожен об'єкт для реалізації функцій системи?".
· Статична модель:
Модель класів - описує внутрішню структуру системи, структури даних, що використовуються в ній, тобто відповідає на питання "як повинна виглядати система зсередини?".
У Real великий упор був зроблений на зв'язність моделей, на контроль цілісності інформації про проект, представленої всередині як однієї моделі, так і в декількох.
2.4.2. Модель вимог.
Робота над системою в Real починається з побудови описової моделі, у якому, насамперед, входять первинні вимоги замовника. Серед них можуть бути як функціональні вимоги, так і будь-які інші (ефективність, вартість і т.п.). Описова модель зберігається в Real у вигляді звичайного тексту і формально не пов'язана з іншими моделями. Ця модель може бути використана і для остаточної специфікації нефункціональних вимог.
На основі вимог замовника формулюється повний перелік функціональних вимог до системи, які оформляються у термінах моделі випадків використання та моделі функцій. Остаточне технічне завдання на систему може бути згенеровано за моделлю вимог Real у тому вигляді, який потрібен замовнику (ГОСТ, який-небудь міжнародний або внутрішньокорпоративний стандарт і т.п.).
Модель випадків використання в Real призначена для опису стику системи з оточенням. У її термінах описуються всі користувачі системи, а також всі її функції (випадки використання), помітні з точки зору цих користувачів. Надалі з використанням можуть бути пов'язані класи. Для випадків використання, у свою чергу, можна створювати діаграми цього ж типу, тобто піддавати випадки використання подальшої декомпозиції в рамках тієї ж моделі.
Функціональна модель призначена для подальшої декомпозиції функцій системи. Вона складається з набору дерев функцій, корінням яких є випадки використання. Дерево може містити вузли двох видів: власне функції і використання описаних раніше функцій. Крім того, функція може мати властивість груповий, це означає, що її "діти" фактично перебувають замість неї на тому ж місці. Зв'язок батьківського вузла з дочірніми може мати позначку, що описує характер у зв'язку.
Відзначимо, що модель випадків використання в Real є підмножиною однойменної моделі UML. Те, що в UML робиться за допомогою не увійшла в Real частини моделі випадків використання, в Real пропонується робити за допомогою моделі функцій, яка є варіацією функціональної моделі із структурних методологій розробки програмного забезпечення. Модель функцій Real заснована на моделі функцій SDL, однак звідти були прибрані деякі деталі (в Real не передбачається так широко використовувати модель функцій, оскільки не хотілося б підштовхувати розробника до алгоритмическому методу розробки системи) і додані використання функцій, групи функцій, а також зв'язок з моделлю випадків використання.
2.4.3. Динамічна модель.
Вона описує поведінку системи - взаємодія між різними її компонентами, взаємодія системи з її оточенням і поведінка самих компонент.
На початкових етапах розробки можна дотримуватись однієї з двох стратегій. Перша: спочатку специфікувати класи системи, а потім об'єкти і сценарії взаємодії. Вона буде використовуватися з більшою ймовірністю, якщо розробникам добре знайома предметна область. Можлива й інша стратегія - у тому випадку, якщо на етапі аналізу доводиться вивчати незнайому предметну область. Основне призначення моделі об'єктів - опис різних ролей, які можуть грати екземпляри класів системи. Кожній функції з функціональної моделі Real можна зіставити діаграму об'єктів, призначення якої - описати типову "конфігурацію" об'єктів, задіяних у виконанні даної функції, а також описати зв'язки між ними. При використанні об'єктно-орієнтованого підходу виконання функцій системи реалізується як спільна діяльність декількох об'єктів. Основними її елементами є об'єкти-ролі і відносини між ними.
Динаміку взаємодії об'єктів для реалізації функції (модель взаємодії) зручно представляти у вигляді сценаріїв. У цих сценаріях беруть участь об'єкти-ролі, визначені на діаграмі об'єктів для даної функції або її надфункцій. Сценарій представляє собою впорядковану у часі послідовність подій, якими, як правило, є посилки і прийоми повідомлень об'єктами.
Побудова сценаріїв для функції починається з визначення "прямих гілок", тобто ідеального виконання функції. При цьому з розгляду виключаються граничні, помилкові ситуації, окремі випадки і т.п., для них згодом теж будуються сценарії або вони специфицируются іншими засобами.
Поведінкова модель описує поведінку складають систему класів за допомогою розширеного кінцевого автомата і представлена ​​в Real двома нотаціями: у стилі STD і SDL. Фактично, поведінкова модель визначає процеси, що протікають в системі в термінах станів, подій і дій. Надалі будемо говорити про поведінкову моделі окремого класу. Побудова такої моделі можна почати з аналізу всіх сценаріїв, в яких беруть участь об'єкти-ролі даного класу. Проектування поведінки системи (поведінки її класів) на основі сценаріїв, а не безпосередньо, дозволяє в більш наочному вигляді представляти загальні процеси, що протікають в програмному забезпеченні, і, відштовхуючись від них, конструювати внутрішнє поведінка учасників цих процесів.
2.4.4. Статична модель.
Після того, як створено основні сценарії системи, можна переходити до специфікації їх учасників - об'єктів, тобто до побудови моделі класів. Ця модель класів будується протягом всього процесу розробки програмного забезпечення.
У Real в моделі класів можуть бути наступні види сутностей:
• клас - опис групи однорідних об'єктів;
• шаблон - параметризованих клас з можливістю отримання з нього звичайного класу підстановкою значень параметрів;
• інтерфейс - опис правил взаємодії класів;
• подання - аналог конструкції VIEW мови SQL.
Модель класів Real реалізує досить повне підмножина моделі класів UML. Крім того, в ній є інтерфейси і порти з ROOM, при цьому останні суттєво розширені. Модель класів Real містить також засоби моделювання схеми баз даних.

3. Реалізація прототипу системи реального часу.
3.1. Життєвий цикл розробки.
Розробка складається з двох основних частин: планувальника завдань РВ і прикладного застосування. Прямих залежностей між етапами проектування даних систем немає. Однак, існують логічні зв'язки. Додаток будується на основі створеного планувальника, що передбачає знання про їхніх інтерфейсах. Планувальник, у свою чергу, будується з урахуванням особливостей додатку, який є додатком контролю, тобто орієнтованим на обробку зовнішніх стохастичних подій.
На діаграмі 1 представлено етапи розробки програмної системи. Виконані в рамках даної роботи, виділені чорним кольором, передбачувані до виконання в подальшому - сірим.
Для планувальника обрана V - образна модель життєвого циклу. Вона застосовується для додатків, при проектуванні яких розробникам доводиться досліджувати нову проблемну область. Відмінною особливістю цієї моделі життєвого циклу є наявність зворотних зв'язків вже на етапах тестування та верифікації. Передбачається, що це дозволить створити більш гнучку в плані наданих можливостей систему.
Для програми-протоколу обрана каскадна модель життєвого циклу. Вона застосовується для додатків в добре досліджених областях знань. У даному випадку системні вимоги на протокол вже описані в технічній документації.
У даній роботі будуть виконані етапи створення системних і функціональних вимог до планувальником, а також визначення його архітектури. Для протоколу буде виконана функціональна модель і модель класів.
3.2. Планувальник завдань.
3.2.1. Вибір алгоритму планування.
3.2.1.1. Види вимог РВ, підтримувані планувальником.
У багатьох системах можна заздалегідь встановити безліч завдань, які будуть використовуватися, і їх характеристики роботи в гіршому випадку. При цьому можна або провести фіксований планування, яке задовольнятиме вимогам системи, або визначити попередні пріоритети завдань.
Наступні обмеження буде можливо задавати з допомогою створюваного планувальника. Вони засновані на тимчасовому поведінці завдань.
3.2.1.1.1. Абсолютні обмеження.
· Інтервал виконання.
Висловлює інтервал, що надається задачі для виконання. Задається в мікросекундах або як частина інтервалу виконання всіх завдань. Визначає пріоритетність певного завдання на даному етапі обчислень. Може динамічно змінюватися.
· Час реакції.
Характеризує час, за який повинен бути отриманий відгук на зовнішній вплив. При перевищенні даного часу задачі виділяється більше ресурсів за допомогою призупинення менш пріоритетних завдань.
· Час виконання.
Висловлює час виконання завдань у гіршому випадку. При перевищенні часу виконання завдання зупиняється. До спеціального стек «неуложівшіхся в строк» ​​записується її ідентифікатор. Для м'яких завдань даний параметр не фіксований. Цей показник також важливий для розподілених (багатопроцесорних) систем, де час виконання завдання може залежати від вузла, на якому вона виконується.
· Періоди.
Період показує, як часто завдання має виконуватися. Період може обмежувати час реакції завдання, тому час реакції передбачається меншим періоду.
3.2.1.1.2. Відносні обмеження.
Обмеження даного класу також називають локальними. Вони виражають те, як два завдання пов'язані один з одним.
· Пріоритетні обмеження.
Дані обмеження визначають які завдання передбачається блокувати при загрозі невиконання терміну даної задачі. У першу чергу блокуються м'які завдання.
· Обмеження відстані.
Визначають мінімальну відстань у часі між виконанням двох завдань.
· Поновлення.
Цей тип обмежень протилежний попередньому. Дані обмеження впливають на те, в якому порядку повинні виконуватися завдання. Для взаємопов'язаних завдань можна задати виділення інтервалу виконання першої перед другою. Ці обмеження також залежать від архітектури системи, так як поведінка системи моделюється як послідовність дій.
Це може бути необхідно у разі, коли одне завдання використовує результати роботи іншого, і якщо між ними пройде відносно великий проміжок часу, то результати можуть виявитися застарілими.
· Гармонійні обмеження
Ці обмеження пов'язані з періодами двох взаємодіючих завдань. Вони мають місце, наприклад, коли період однієї задачі (наприклад, одержувача) залежить від періоду інший (відправника).
3.2.1.1.3. Непідтримувані обмеження.
· Відносини.
Дані обмеження висловлюють максимальний інтервал часу між часом завершення двох завдань.
· Розділові обмеження.
Ці обмеження висловлюють інтервал, якому має належати період завдання. Період може бути обмежений мінімальним і / або максимальним значеннями, які гарантують, що необхідні дії будуть виконані в отриманий інтервал.
3.2.1.2. Використовувані алгоритми.
Вибір того чи іншого методу планування залежить від призначення системи. У системах контролю, на які орієнтований планувальник, всі дані повинні бути чітко визначені заздалегідь. У цьому випадку статичний алгоритм більш доречний. Однак, статичні методи планування не є достатньо гнучкими, тому що для забезпечення коректної роботи системи заздалегідь необхідно передбачити всі можливі ситуації.
Трохи більш гнучким є підхід, в якому розклад генерується оперативно. У цьому випадку для кожного завдання заздалегідь визначаються: час реакції і час виконання. У даній розробці буде використано планування, засноване на часі. Час реакції задає інтервал, протягом якого передбачається відповідь системи і після якого виникає загроза пропуску терміну, що вимагає виділення додаткових ресурсів для завдання. Час виконання задає інтервал, після виходу за межі якого завдання вважається невиконаним і потрібно вже призупинення виконання завдання для збереження стабільності всієї системи в цілому.
Для динамічного перерозподілу ресурсів системи буде використана політика управління - round-robin. У цьому випадку процес виконується або поки виділений йому квант часу не закінчиться, або поки не буде припинений іншим процесом з більш високим пріоритетом. Після того, як час, виділений для даного процесу, закінчиться, активується наступний готовий до запуску процес.
Коли процес отримує більш високий пріоритет і призупиняє виконання поточного, планувальник зберігає контекст призупиненого процесу для того, щоб потім продовжити його виконання з місця зупинки. Призупинений процес залишається готовим до запуску.
Процеси в списку готових до запуску завдань впорядковані, згідно з методом EDF - у порядку зростання часу реакції. При наявності блокування запускаються тільки завдання з пріоритетом вище або рівним пріоритету ініціювала блокування завдання.
3.2.2. Опис функціонування програми.
Схема взаємодії об'єктів створюваної системи показана на діаграмі 10.
3.2.2.1. Підготовка до запуску планувальника.
Головна програма запускає функцію ініціалізації планувальника, в яку передається масив структур, що складається з покажчиків на плановані процедури і з параметрів виконання. У число параметрів входять: ідентифікатор (задається головною програмою), пріоритет, інтервал / квант виконання, час реакції, час виконання (для м'яких завдань може не визначатися), період (для періодичних функцій), кількість запусків або час роботи (для спорадичних завдань) , порядок, щодо інших завдань. Також можлива передача покажчика на вхідні параметри процедури.
У планувальнику створюється список завдань. Створюється процес-таймер, який буде формувати послідовність повідомлень для планувальника.
3.2.2.2. Робота.
Головна програма виконує виклики функції, що відсилає повідомлення про початок роботи певної задачі. Планувальник створює окремі процеси для кожного завдання. Запущені завдання самі можуть викликати функції планування для себе або інших завдань.
Таймер отримує від планувальника повідомлення і створює відповідні мітки відсилання повідомлень для планувальника. Надалі після досягнення позначки таймер посилає планировщику повідомлення ініціювати роботу певного завдання. Якщо це мітка періодичної чи спорадичної завдання, то таймер створює через "період" наступну. Планувальник посилає процесам-завданням сигнали початку кванта часу для виконання.
При виході певного завдання за межі часу реакції, таймер посилає повідомлення про блокування тих завдань, які мають пріоритет менше. Якщо вихід за межі у двох однаково пріоритетних одночасно, то вони продовжать виконуватися разом.
3.2.2.3. Управління завданнями.
У багатьох системах можна заздалегідь встановити безліч завдань, які будуть використовуватися, і їх характеристики роботи в гіршому випадку. При цьому можна або провести фіксований планування, яке задовольнятиме вимогам системи, або визначити попередні пріоритети завдань. Проте неминуче виникає необхідність зміни поточного режиму / стану системи. Можна виділити наступні типи операцій зі зміни режиму:
· Додавання завдання.
Планувальник приймає повідомлення про активацію завдання, і поміщає до числа готових до запуску з урахуванням абсолютних і відносних обмежень. Додається запис в процес-таймер.
· Зміна інтервалу виконання завдання.
Приймається повідомлення про зміну інтервалу. Якщо завдання, для якої він повинен бути зрад, активна, то вона припиняється. Інтервал змінюється. Потім цикл обчислень триває, починаючи з цього завдання.
· Зміна періоду виконання періодичної задачі.
Планувальник приймає повідомлення і посилає до процесу-таймером сигнал на зміну позначки часу, відповідної даної задачі.
· Зміна часу реакції, часу виконання або пріоритету.
Приймається повідомлення про необхідність зміни параметра. Якщо завдання, для якої він повинен бути зрад, активна, то вона припиняється. Видаляється відповідна позначка в таймері. Параметр змінюється. Встановлюється нова мітка в таймері. Якщо час реакції дорівнює 0, то блокуються завдання з пріоритетом меншим, ніж у даної.
· Видалення завдання.
Завдання завершує своє виконання і посилає планировщику повідомлення на видалення її зі списку готових до виконання. Або планувальник видаляє завдання, що вийшла за межі виділеного їй часу виконання.
3.3. Реалізація протоколу ARINC A.415 на основі розробленого модуля СРВ.
3.3.1. Модель вимог до системи.
3.3.1.1. Описова модель.
Протоколу A.415 ARINC, використовується у вбудованих системах реального часу літаків провідних авіаперевізників, таких як Airbus, McDonnel Douglas та ін Це протокол опитування бортових пристроїв, дозволяє в заздалегідь визначений проміжок часу від них інформацію і сигналізувати про несправності в обладнанні.
Бортові системи літака через жорстко задані проміжки часу формують спеціальні повідомлення, в яких можуть повідомляти про виникнення всередині них несправностей і описувати їх. Спеціальні підсистеми літака повинні отримувати повідомлення бортових систем і відправляти звіти про несправності на діалогову систему, призначену для взаємодії з оператором у літаку. Оператор, у свою чергу, повинен мати можливість акцентувати свою увагу на одній з контрольованих систем і вступити з нею у взаємодію.
3.3.1.2. Модель випадків використання.
Дана модель представлена ​​на малюнку 11.
У розроблюваної системи буде 2 види взаємодій з «зовнішнім оточенням»: у Діалоговому режимі і в Звичайному режимі. Діалоговий режим використовується при взаємодії з оператором у літаку. Звичайний режим використовується при стандартній роботі інтерфейсної підсистеми з індикації несправностей.
3.3.1.3. Функціональна модель.
Функціональна модель системи представлена ​​у вигляді діаграм 12 і 13.
У Звичайному режимі система реалізує наступні функції: початок роботи (ініціалізація), теплий старт, отримання повідомлення від бортової системи, опитування APM (у разі необхідності), відсилання повідомлень до CFDIU, перехід в діалоговий режим.
У Діалоговому режимі система реалізує наступні функції: отримання повідомлення від бортової системи, відсилання повідомлень до CFDIU, отримання команд від CFDIU, перехід в Нормальний режим.
3.3.2. Динамічна модель.
3.3.2.1. Модель об'єктів.
· Повідомлення від бортової системи.
Бортова система ↔ OMSI І Бортова система ↔ Незалежна пам'ять
· Отримати настройки з APM.
APM ↔ OMSI
· Надіслати звіт до CFDIU.
OMSI ↔ Шина передачі даних ↔ CFDIU
АБО
General Format Manager
· Запуск діалогового режиму.
CFDIU ↔ Шина передачі даних ↔ OMSI
· Початок роботи.
Ініціалізація АБО Теплий старт
· General Format Manager.
Шина передачі даних ↔ OMSI
· Отримати команду.
Шина передачі даних ↔ OMSI
· Ініціалізація.
OMSI ↔ APM
· Тепла старт.
Незалежна пам'ять ↔ OMSI І APM ↔ OMSI
· Отримати команду від CFDIU.
CFDIU ↔ Шина передачі даних ↔ OMSI
· Запуск Звичайного режиму.
CFDIU ↔ Шина передачі даних ↔ OMSI
3.3.2.2. Модель взаємодій.
· Повідомлення від бортової системи.
OMSI à розпочав роботу. Бортова система à почала роботу. Бортова система à зберегла повідомлення про несправності в Енергонезалежної пам'яті. Бортова система à відправила повідомлення про несправності.
· Отримати настройки з APM.
OMSI à розпочав роботу. OMSI à запросив настройки у APM. APM à передало необхідні настройки.
· Надіслати звіт до CFDIU.
CFDIU à розпочав роботу. OMSI à розпочав роботу. Шина передачі даних à активна. OMSI à перевірив активність Шини передачі даних. OMSI à відправив звіт. Шина передачі даних à переправила звіт до CFDIU. CFDIU à отримав звіт.
АБО
General Format Manager.
· Запуск діалогового режиму.
CFDIU à розпочав роботу. OMSI à розпочав роботу. Шина передачі даних à активна. CFDIU à відправив команду ENQ. Шина передачі даних à передає команду на потрібний OMSI. OMSI à переходить у діалоговий режим.
· Початок роботи.
Ініціалізація АБО Теплий старт
· General Format Manager.
OMSI à розпочав роботу. Шина передачі даних à неактивна. OMSI à перевірив активність Шини передачі даних.
· Отримати команду.
Шина передачі даних à активна. Шина передачі даних à передає команду на OMSI. OMSI à робить дію, у відповідності з командою.
· Ініціалізація.
OMSI à розміщення в пам'яті, ініціалізація змінних, запит настройок. APM à пошук і передача необхідних налаштувань.
· Тепла старт.
OMSI à розміщення в пам'яті, ініціалізація змінних, запит настройок. APM à пошук і передача необхідних налаштувань. OMSI à відновлення раніше передавалося повідомлення з Енергонезалежної пам'яті.
· Отримати команду від CFDIU.
CFDIU à розпочав роботу. OMSI à розпочав роботу. Шина передачі даних à активна. CFDIU à відправив команду. Шина передачі даних à передає команду на потрібний OMSI. OMSI à робить дію, у відповідності з командою.
· Запуск Звичайного режиму.
CFDIU -> почав працювати. OMSI -> почав працювати. Шина передачі даних -> активна. CFDIU -> відправив команду Log Off. Шина передачі даних -> передає команду на потрібний OMSI. OMSI -> переходить в номально режим.
3.3.2.3. Поведінкова модель.
· OMSI.
Діаграма 14. Старт à Перевірити Енергозалежну пам'ять. à Вибір: Чи очікують повідомлення в Енергонезалежної пам'яті? Так - Ініціалізація; Ні - Теплий старт. Теплий старт à Забрати повідомлення з Енергонезалежної пам'яті à Завантажити настроювання з APM. Ініціалізація à Завантажити настроювання з APM à Робота à Прийняти повідомлення à Отримати команду à Сформувати звіт à Перевірити активність Шини передачі даних à Вибір: Шина активна? Так - Відіслати питання; Ні - Чекати активізації Шини передачі даних. Надіслати звіт à Прийняти повідомлення. Чекати активізації шини à Надіслати звіт.
· CFDIU.
Діаграма 15. Старт à Включено à Направити команду (необов'язкове дію) à Отримати звіт à Відобразити звіт à Вибір: Закінчити роботу? Так - Вимкнено; Ні à Направити команду (необов'язкове дію).
· APM.
Діаграма 16. Старт à Отримання запиту à Передати налаштування à Отримання запиту.
· Шина передачі даних.
Діаграма 17. Старт à Неактивна à Включення CFDIU => Активна à Вибір: Перенаправлення команди; Передача звіту. à Вибір: Вимкнення CFDIU => Неактивна; Активна.
· Бортова система.
Діаграма 18. Старт à Працює à Відправлення повідомлення в енергонезалежну пам'ять à Відправка повідомлення до OMSI à Працює.
· Незалежна пам'ять.
Діаграма 19. Старт à Активна à Записати повідомлення від Бортовий системи à Передати збережені повідомлення OMSI (необов'язкове дію) à Знищити повідомлення, непотрібні OMSI à Активна.
3.3.3. Статична модель.
3.3.3.1. Модель класів.
На діаграмі 9 представлені основні класи створюваної системи: OMSI, CFDIU, Шина передачі даних, APM, Незалежна пам'ять, бортова система.
· OMSI - інтерфейсна система, що забезпечує взаємозв'язок функціональної системи, (наприклад, T2CAS - системи попередження зближення літаків, правильніше «запобігання зіткнення») з центральним пристроєм відображення даних CFDIU.
· Завдання CFDIU надавати екіпажу літака дані про функціонування всіх бортових систем. За допомогою меню екіпаж (або технік на землі) може вступити у взаємодію з конкретної функціональної бортовою системою (онлайн). В інших випадках CFDIU просто відображає (нормальний режим) стан бортових систем, які через свої OMSI повідомляють CFDIU свої статки, посилаючи повідомлення Label350.
· Процес взаємодії OMSI і CFDIU відбувається через Шину передачі даних. Якщо шина не активна, то це може означати, що бортова система до CFDIU не підключена, а, отже, нікому слати повідомлення.
· APM - це підсистема (таблиця даних з інтерфейсом) зберігає налаштування даного літака. Бортова система типу T2CAS може ставитися на різні літаки, і повинна підлаштовуватися до роботи конкретного борту. Зокрема, CFDIU не єдиний варіант пристрою відображення даних для екіпажу. Можуть бути й інші (на різних типах літаків), тоді і протокол обміну реалізується з урахуванням відповідної центральної системи.
· Після збою в електроживленні OMSI повинен отримати звіт про несправності з енергонезалежної пам'яті, яка в даному випадку буде представлена ​​окремим об'єктом створюваної програмної системи.
· Об'єкт Бортова система моделює ті відомості, які повинна мати інтерфейсна система про функціональну для взаємодії.

Висновок.
Був проведений аналіз предметної області систем реального часу. Визначено основні відмінності систем даного типу від інших подібних систем та особливості управління виконанням завдань. Були розглянуті використовувані класифікації та відмінні риси сучасних систем.
На основі проведеного аналізу була спроектована система, що складається з двох основних підсистем: планувальника завдань реального часу і прикладного програми - авіаційного протоколу.
Для обох підсистем виконані етапи створення системних і функціональних вимог, визначені використовувані алгоритми та архітектури.
Для протоколу використана сучасна методологія розробки ПЗ та створена модель класів системи. В цілому варто відзначити, що класи в проектованої системі володіють простотою проектування за рахунок відсутності ієрархічних зв'язків, проте застосовується метод дозволяє з відносною простотою ускладнювати структурні зв'язки і розширювати область проектування.
На основі знайдених при проектуванні прикладного докладання недоліків використовуваної платформи в подальшому можуть бути змінені функціональні або архітектурні особливості планувальника. Так само передбачається використання прикладного програми для безпосереднього тестування планувальника.

Література.
1. С. Кузнєцов «Механізми IPC в операційній системі Unix». навчальні матеріали конференції «Індустрія Програмування 96», Центр Інформаційних Технологій, 1996.
2. Олексій Биков «Системне адміністрування IBM AIX 4. X ».
3. Dr. Jurgen Sauermann, Melanie Thelen «Real-time Operating Systems. Concepts and Implementation of Microkernels for Embedded Systems ».
4. See-Mong Tan, David K. Raila, Roy H. Campbell «A case for nano-kernels». Department of Computer Science, University of Illinois at Urbana-Champaign, 1996, 11 стор
5. Michel Gien «Micro-kernel Architecture. Key to Modern Operating Systems Design ». Chorus systems, 1990, 10 стор
6. Booch G. «Object-oriented analysis and design with application, second edition». The Benjamin / Cummings Publishing Company, Inc, 1994, 589 стор
7. Романовський К., Іванівський Б., підступи Дм., Долгов П. «Огляд нотацій методології Real». / / Http://www.tepcom.ru/produkts/real/Report_Notations_A. Asp.
8. ITU «SDL methodology guidelines and bibliography». Appendices i to recommendation Z.100, 1993,107 стор
9. Selic B., Gullekson G., Ward PT «Real-time object-oriented modeling». John Wiley & Sons. Inc, 1994, 525 стор
10. ITU «Recommendation Z.100: Specification and Description Language (SDL)». 1993, 204 стор
11. Бардзінь Я.М., Калкіньш А.А., Стродс Ю.Ф., Сицко В.А. «Мова специфікацій SDL / PLUS і його застосування ». Рига, 1988, 313 стор
12. IEEE Standards Project P1003.4a «Thread Extension for Portable Operating Systems. Draft 6». Draft 6.-IEEE, 1992.
13. Алан Джок «ОС реального часу».

Додаток

Діаграма 2. Стандартні прикладні інтерфейси.

Таблиця 3. Час відгуку.

Таблиця 4. Порівняння різних операційних систем.

Малюнок 5. ОС в просторі "адресація-клас-стандартизація".

Діаграма 6. Час реакції різних систем на переривання

Діаграма 7. Час перемикання контексту
ОСРВ
Розробник
Область застосування
Web-адреса
Коментарі
C Executive
JIMI Software Systems
Комерційна
www.jmi.com
Система реального часу для програм на Сі; підтримує процесори архітектур CISC і RISC
ITRON
ITRON Committee, TRON Association
Комерційна
www.itron.gr.jp / home-e.html
Специфікація розроблена японської технологічної асоціацією; орієнтована на промислові додатки
LynxOS
LynuxWorks
Комерційна
www.lynuxworks.com
Сумісна з Linux; підтримує Unix і Java
OS-9
Microware Systems
Комерційна
www.microware.com
Підтримує мікроархітектуру Intel XScale; модульна структура стимулює додавання до системи нових пристроїв
QNX
QNX Software Systems
Комерційна
www.qnx.com
Ізолює програми, бібліотеки, дані та системне програмне забезпечення
VxWorks, VxWorks AE
Wind River Systems
Комерційна
www.windriver.com
Дозволяє ізолювати спільно використовувані програми, бібліотеки, дані та системне ПЗ
Chimera
Університет Карнегі-Меллона
Експери-
ментальна
www.cs.cmu.edu/afs/ cs.cmu.edu / project / chimera / www / chimera / chimera.html
Підтримка багатозадачності і багатопроцесорних систем; призначена для роботів і автоматизованих систем
Maruti
Університет шт. Меріленд
Експери-
ментальна
www.cs.umd.edu/
Підтримує режими "жорсткого" та "м'якого" реального часу
Таблиця 8. Сучасні представники систем реального часу.
SHAPE \ * MERGEFORMAT
GeneralFormatManager
CFDIU
Незалежна пам'ять
APM
Бортова система
Шина активна
Шина неактивна
Шина передачі даних
Отримання команди
Отримано
Передача команди
Передано
Отримання звіту
Отримано
Отримано
Отримання збереженого
Отримано
Неполучітся
Отримання повідомлення
Отримано
Отримання установок
Збереження повідомлення
Збережено
Незбереження
OMSI

Діаграма 9. Основні класи системи протоколу.
SHAPE \ * MERGEFORMAT
Процесс1
Таймер
Планувальник
ПроцессN
...
Головна програм ма
Подія-час
Запуск
ФункціяК
Запуск / Кінець ФункціяК
Планувати точку
Функції
Активні
процеси

Діаграма 10. Схема взаємодії об'єктів СРВ.
SHAPE \ * MERGEFORMAT
Діалоговий режим
Звичайний режим
CFDIU
OMSI

Малюнок 11. Модель випадків використання.
SHAPE \ * MERGEFORMAT
Звичайний режим
Отримати дані з APM
Надіслати звіт до CFDIU
Запуск діалогового режиму
Почати роботу
Теплий старт
Ініціалізація
General Format Manager
Отримати команду
Отримати повідомлення від бортової системи

Діаграма 12. Звичайний режим.
SHAPE \ * MERGEFORMAT
Діалоговий режим
Надіслати звіт до CFDIU
Запуск звичайного режиму
General Format Manager
Отримати команду від CFDIU
Отримати повідомлення від бортової системи

Діаграма 13. Діалоговий режим.
SHAPE \ * MERGEFORMAT
Старт
Чи очікують повідомлення?
Ні
Так
Забрати спільнота-ня з Енергоза-ний пам'яті
Завантажити настроювання з APM
Теплий старт
Ініціалізація
Перевірити Енергозалежну пам'ять
Прийняти повідомлення
Отримати команду
Сформувати звіт
Перевірити активність Шини передачі даних
Шина активна?
Ні
Так
Чекати активізації Шини передачі даних
Робота
Надіслати звіт

Діаграма 14. OMSI.
SHAPE \ * MERGEFORMAT
Старт
Так
Отримати звіт
Відобразити звіт
Включено
Вимкнено
Направити команду
Закінчити роботу?
Ні

Діаграма 15. CFDIU.
SHAPE \ * MERGEFORMAT
Старт
Передати налаштування
Отримання запиту

Діаграма 16. APM.
SHAPE \ * MERGEFORMAT
Старт
Неактивна
Включення CFDIU
Активна
Перенаправлення команди
Передача звіту
Вимкнення CFDIU

Діаграма 17. Шина передачі даних.
SHAPE \ * MERGEFORMAT
Старт
Працює
Відправлення повідомлення в Енергозалежну пам'ять
Відправка повідомлення до OMSI

Діаграма 18. Бортова система.
SHAPE \ * MERGEFORMAT
Старт
Активна
Записати повідомлення від Бортовий системи
Передати збережені повідомлення OMSI
Знищити повідомлення, непотрібні OMSI

Діаграма 19. Енергозалежна пам'ять.
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
222.9кб. | скачати


Схожі роботи:
Реалізація системи управління реального часу в ОС Windows
Особливості операційних систем реального часу
Основні поняття та програмне забезпечення систем реального часу
Виконання покарання у вигляді штрафу
Виконання покарання у вигляді обов`язкових робіт
Виконання покарання у вигляді позбавлення волі неповнолітніх
Проблеми виконання покарання у вигляді арешту та обмеження волі
Особливості виконання покарання у вигляді позбавлення волі в воспитати
Виконання кримінального покарання у вигляді позбавлення свободи укладення в
© Усі права захищені
написати до нас