Реферат з теми випускної роботи

Зміст

• Вступ
• 1. Мета та задачі розробки й дослідження
• 2. Основні положення про системи реального часу
  • 2.1 Основні поняття
  • 2.2 Структура систем реального часу
  • 2.3 Процеси, потоки, задачі
  • 2.4 Механізми реального часу
  • 2.5 Годинники та таймери
• 3. Особливості налагодження додатків в системах реального часу
• Висновки
• Список літератури

Вступ

Управління процесом надання ресурсів системи задачам, ниткам, процедурам обробки переривань і так далі є однією з основоположних функцій будь-якої операційної системи та здійснюється за допомогою механізму планування. Даний механізм забезпечує системі можливість паралельного виконання декількох завдань. У системах реального часу планування має також гарантувати передбачувану поведінку, безпеку, можливість тривалої, безвідмовної роботи, виконання завдань до поставленого терміну. Від методу планування багато в чому залежить успішна робота системи в цілому [1].

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

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

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

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

1. Мета та задачі розробки й дослідження

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

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

2. Основні положення про системи реального часу

2.1 Основні поняття

Існує кілька визначень систем реального часу (СРЧ), більшість з яких суперечать один одному. Наведемо декілька з них, щоб продемонструвати різні погляди на призначення та основні завдання СРЧ.

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

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

2. Стандарт POSIX 1003.1 визначає СРЧ наступним чином: Реальний час в операційних системах — це здатність операційної системи забезпечити необхідний рівень сервісу в заданий проміжок часу.

3. Іноді системами реального часу називається системи постійної готовності (on-line системи), або інтерактивні системи з достатнім часом реакції. Зазвичай це роблять з маркетингових міркувань. Дійсно, якщо інтерактивну програму називають працює в реальному часі, то це просто означає, що вона встигає обробити запити від людини, для якої затримка в сотні мілісекунд навіть непомітна.

4. Іноді поняття система реального часу ототожнюють з поняттям швидка система. Це не завжди правильно. Час затримки СРЧ на подію не так вже й важливо (воно може досягати декількох секунд). Головне, щоб цей час було достатньо для розглянутого програми та гарантовано. Дуже часто алгоритм з гарантованим часом роботи менш ефективний, ніж алгоритм, який такою дією не володіє. Наприклад, алгоритм швидкого сортування в середньому працює значно швидше інших алгоритмів сортування, але його гарантована оцінка складності значно гірша.

5. У багатьох сферах додатки СРЧ вводять свої поняття реального часу. Наприклад, процес цифрової обробки сигналу називають таким, що йде в реальному часі, якщо аналіз (при введенні) та/або генерація (при виведенні) даних може бути проведений за той же час, що і аналіз та/або генерація тих самих даних без цифрової обробки сигналу. Наприклад, якщо при обробці аудіо даних потрібно 2.01 секунд для аналізу 2.00 секунд звуку, то це не процес реального часу. Якщо ж потрібно 1.99 секунд, то це процес реального часу.

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

1) Система повинна встигнути відреагувати на подію, що сталася на об’єкті протягом часу, критичного для цієї події (meet deadline). Величина критичного часу для кожної події визначається об’єктомі самою подією, і, звичайно, може бути різною, але час реакції системи має бути передбачений (обчислений) при створенні системи. Відсутність реакції в передбачений час вважається помилкою для систем реального часу.

2) Система повинна встигати реагувати на події, що одночасно відбуваються. Навіть якщо дві або більше зовнішніх подій відбуваються одночасно, система повинна встигнути зреагувати на кожне з них протягом інтервалів часу, критичних для цих подій. Хорошим прикладом задачі, де потрібно СРЧ, є управління роботом, що беруть деталь з стрічки конвеєра. Деталь рухається, і робот має лише маленьке тимчасове вікно, коли він може її взяти. Якщо він запізниться, то деталь вже не буде на потрібній ділянці конвеєра, і, отже, робота не буде зроблена, незважаючи на те, що робот знаходився в правильному місці. Якщо він позиціонується раніше, то деталь ще не встигне під’їхати і робот заблокує їй шлях.

Розрізняють системи реального часу двох типів — системи жорсткого реального часу й системи м’якогореального часу. Системи жорсткого реального часу не допускають ніяких затримок реакції системи ні за яких умов, оскільки:

• результати можуть виявитися марними в разі запізнення,
• може статися катастрофа у разі затримки реакції,
• вартість запізнення може бути нескінченно велика.

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

Системи м’якогореального часу характеризуються тим, що затримка реакції не критична, хоча і може призвести до збільшення вартості результатів і зниження продуктивності системи в цілому. Наприклад — робота мережі. Якщо система не встигла обробити черговий прийнятий пакет, це призведе до таймаут на передавальній стороні і повторної передачі (залежно від протоколу, звичайно). Дані при цьому не втрачаються, але продуктивність мережі знижується.

Основна відмінність між системами жорсткого і м’якогореального часу можна виразити так: система жорсткого реального часу ніколи не запізниться з реакцією на подію, система м’якогореального часу — має спізнюватися з реакцією на подію.

2.2 Структура систем реального часу

Будь-яка система реального масштабу часу може бути описана як та, що складається з трьох основних підсистем, як зображено на рисунку 1.

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

Керована підсистема представлена задачами, які використовують обладнання, кероване підсистемою контролю. Ця остання підсистема може бути побудована з дуже великої кількості процесорів, керуючими такими місцевими ресурсами, як пам’ятьта пристрої зберігання, і доступ до локальної мережі в реальному масштабі часу. Ці процесори та ресурси управляються системою програмного забезпечення, яку і називають операційною системою реального масштабу часу (RTOS — real time operating system) [2].

2.3 Процеси, потоки, задачі

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

Прийнято розрізняти два різновиди задач: процеси і потоки. Процес є окремий програмний модуль (файл), що завантажується і який, як правило, під час виконання має в пам’ятісвої незалежні області для коду та даних. На відміну від цього потоки можуть користуватися загальними ділянками коду і даних в рамках єдиного програмного модуля.

Хорошим прикладом багатопотокової програми є редактор тексту Word, де в рамках однієї програми може одночасно відбуватися і набір тексту, і перевірка правопису.

Переваги потоків
1. Так як безліч потоків здатне розміщуватися всередині одного ЕХЕ модуля, це дозволяє економити ресурси як зовнішньої, так і внутрішньої пам’яті
2. Використання потоками загальної області пам’ятідозволяє ефективно організувати межзадачний обмін повідомленнями (достатньо передати покажчик на повідомлення). Процеси не мають спільної області пам’яті тому ОС повинна або цілком скопіювати повідомлення з області пам’ятіодного завдання в область пам’ятіінший (що для великих повідомлень досить накладно), або передбачити спеціальні механізми, які дозволили б одній задачі отримати доступ до повідомлення з області пам’ятііншої задачі.
3. Як правило, контекст потоків менше, ніж контекст процесів, а значить, час перемикання між завданням і іпотокамі менше, ніж між завданнями і процесами.
4. Так як всі потоки, а іноді і саме ядро РЧ розміщуються в одному ЕХЕ модулі, значно спрощують використання програмо-відладчиків (debugger).

Недоліки потоків
1. Як правило, потоки не можуть бути довантажені динамічно. Щоб додати новий потік, необхідно провести відповідні зміни у вихідних текстах і перекомпілювати додаток. Процеси, на відміну від потоків, підгружаємі, що дозволяє динамічно змінювати функції системи в процесі її роботи. Крім того, так як процесам відповідають окремі програмні модулі, вони можуть бути розроблені різними компаніями, чим досягається додаткова гнучкість й можливість використання раніше напрацьованого ПЗ.
2. Те, що потоки мають доступ до областей даних один одного, може призвести до ситуації, коли некоректно працюючий потік здатний зіпсувати дані іншого потоку. На відміну від цього процеси захищені від взаємного впливу, а спроба запису в не свою пам’ятьпризводить, як правило, до виникнення спеціального переривання з обробки виняткових ситуацій. Реалізація механізмів управління процесами і потоками, можливість їх взаємного співіснування та взаємодії визначаються конкретним ПЗРЧ.

Як правило, вся важлива, з точки зору операційної системи, інформація про завдання зберігається в уніфікованій структурі даних — керуючому блоці (Task Control Block, TCB). У блоці зберігаються такі параметри, як ім’ята номер задачі, верхня та нижня межі стека, посилання на чергу повідомлень, статус задачі, пріоритет та ін.

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

Контекст завдання — це набір даних, що містить всю необхідну інформацію для відновлення виконання завдання з того місця, де вона була раніше перервана. Часто контекст зберігається в ТСВ і включає в себе такі дані, як лічильник команд, покажчик стека, регістри СРU і FPU та ін. Планувальник задач у разі потреби зберігає контекст поточної активної задачі та відновлює контекст задачі, призначеної до виконання. Таке переключення контекстів і є, по суті, основним механізмом ОСРЧ при переході від виконання однієї задачі до виконання іншої.

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

1. Активна задача — це задача, що виконується системою в поточний момент часу.
2. Готова задача — це задача, готова до виконання і чекає у планувальника своєї черги .
3. Блокована задача — це задача, виконання якої призупинено до настання певних подій. Такими подіями можуть бути звільнення необхідної задачі ресурсу, надходження очікуваного повідомлення, завершення інтервалу очікування і т.п.

Порожня задча (Idle Task) — це задача, що запускається самою операційною системою в момент ініціалізації і виконується тільки тоді, коли в системі немає інших готових для виконання задач. Порожня задача запускається з найнижчим пріоритетом і, як правило, являє собою нескінченний цикл нічого не робити. Наявність порожній задачі надає операційній системі зручний механізм відпрацювання ситуацій, коли немає жодної готової до виконання задачі.

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

Реєнтерабельність (повторна входимість) означає можливість без негативних наслідків тимчасово перервати виконання якої-небудь функції або підпрограми, а потім викликати цю функцію або підпрограму знову. Приватним проявом реєнтерабельності є рекурсія, коли тіло підпрограми містить виклик самої себе. Класичним прикладом нереєнтерабельності системи є DOS, а типовою причиною нереєнтерабельності служить використання глобальних змінних [3].

2.4 Механізми реального часу

Найважливішими характеристиками ОСРЧ є закладені в операційну систему механізми реального часу.

Процес проектування конкретної системи реального часу починається з ретельного вивчення об’єкта Розробники проекту досліджують об’єкт вивчають можливі події на ньому, визначають критичні терміни реакції системи на кожну подію і розробляють алгоритми обробки цих подій. Потім йде процес проектування і розробки програмних додатків. Які ж механізми в операційних системах реального часу роблять систему реального часу (СРЧ) передбачуваною?

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

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

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

Алгоритми кругової диспетчеризації неможливо застосувати в чистому вигляді в ОСРЧ. Основний недолік — безперервний квант часу, протягом якого процесором володіє тільки один процес. Планувальники ж операційних систем реального часу мають можливість змінити процес до закінчення time slice, якщо в цьому виникла необхідність. Один з можливих алгоритмів планування при цьому пріоритетний з витісненням. Світ ОСРЧ відрізняється багатством різних алгоритмів планування: динамічні, пріоритетні, монотонні, адаптивні та ін., мета ж завжди переслідується одна — надати інструмент, що дозволяє в потрібний момент часу виконувати саме той процес, який необхідний.

Інший набір механізмів реального часу відноситься до засобів синхронізації процесів і передачі даних між ними. Для операційних систем реального часу характерна розвиненість цих механізмів. До таких механізмів відносяться: семафори, м’ютекси події, сигнали, засоби для роботи з пам’яттю що розділяється, канали даних (pipes), черги повідомлень. Багато хто з подібних механізмів використовують і в ОС загального призначення, але їх реалізація в операційних системах реального часу має свої особливості — час виконання системних викликів майже не залежить від стану системи, і в кожній операційній системі реального часу є принаймні один швидкий механізм передачі даних від процесу до процесу.

Такі інструменти, як засоби роботи з таймерами, необхідні для систем з жорстким часовим регламентом, тому розвиненість засобів роботи з таймерами — необхідний атрибут ОСРЧ. Ці засоби, як правило, дозволяють:

• вимірювати і задавати різні проміжки часу (від 1 мкс і вище),
• генерувати переривання після закінчення тимчасових інтервалів,
• створювати разові і циклічні будильники.

Тут описані лише базові, обов’язковімеханізми, які використовуються в ОСРЧ. Крім того, майже в кожній операційній системі реального часу є цілий набір додаткових, специфічних тільки для неї механізмів, що стосується системи введення-виведення, управління перериваннями, роботи з пам’яттю Кожна система містить також ряд засобів, що забезпечують її надійність.

2.5 Годинники та таймери

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

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

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

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

3. Особливості налагодження додатків в системах реального часу

Налагодження в системах реального часу спрямовано на виявлення та виправлення помилок в прикладному коді. Воно є одним з етапів крос-розробки, схему якої можна представити таким чином. Розробка програми ведеться як мінімум на двох машинах: інструментальній та цільовій. На інструментальній платформі відбувається написання вихідного тексту, компіляція та збирання. На цільовій — завантаження програми, її тестування і налагодження.

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

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

Другий спосіб — дистанційне налагодження (крос-налагодження). Крос-налагодження дозволяє використовувати ресурси інструментальної системи при вивченні поведінки деякого процесу в цільовій системі.

Ефективність віддаленого налагодження залежить від типу зв’язківінструментальної та цільової машин, а також від підтримки засобів налагодження з боку цільової архітектури.

Ключовою вимогою до засобів налагодження є можливість спостерігати і аналізувати весь процес виконання задач, що відлагоджуюються, а також системи в цілому. В цілому можна розглянути два методи налагодження: активне налагодження та моніторинг.

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

Під моніторингом розуміється збір даних про задачу (значення регістрів, змінних, і т.д.) або про систему в цілому (стадії виконання задач, події, що відбуваються, і т.д.).

Здійснювати збір даних допомагає псевдо-агент (набір інструкцій, вбудованих в код задачі). Зазвичай його додають на етапі проектування. Простий приклад псевдо-агента — виклик assert, що дозволяє вести діагностику роботи задачі.

У процесі моніторингу відладчик практично не втручається в роботу системи, забезпечуючи нормальне її функціонування, але разом з тим не має можливості впливати на хід виконання додатки, що відлагоджується [5].

Висновки

Існуючі активні отладчики відіграють важливу роль у розробці ПЗ при пошуку логічних помилок, надаючи широкий набір засобів, що включають підтримку вихідних текстів, трасування виконання додатку, динамічну модифікацію пам’яті і т.д. Однак вони не дозволяють виявляти специфічні помилки СРЧ.

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

Список літератури

1. Братуха М.А., Шевченко О.Г. Исследование точности отсчёта временных интервалов в системе Windows
2. Системы реального времени: учебно пособие — СПб.: Владикавказ, 2013. — 65 с.
3. Сорокин С. Системы реального времени // Современные технологии автоматизации. 1997. № 2.
4. Бурдонов И.Б., Косачев А.С., Пономаренко В.Н. Операционные системы реального времени [електронний ресурс]. — Режим доступу: http://citforum.ru/operating_systems/rtos/, вільний.
5. Костюхин К.А. Отладка систем реального времени [електронний ресурс]. — Режим доступу: http://citforum.ru/programming/digest/rtsdebug.shtml, вільний.
6. Операционная система реального времени / Материал из Википедии — свободной энциклопедии [електронний ресурс]. — Режим доступу: https://ru.wikipedia.org/wiki/Операционная_система_реального_времени, вільний.
7. ОСи реального времени / журнал Хакер [електронний ресурс]. — Режим доступу: http://www.xakep.ru/post/17912/, вільний.
8. Операционные системы реального времени (обзор) А.А. Блискавицкий, С.В. Кабаев, АО "РТСофт", Москва [електронний ресурс]. — Режим доступу: http://www.mka.ru/?p=40774, вільний.