Введення
Протягом багатьох років додатки на базі ОС реального часувикористовувалися у вбудованих системах спеціального призначення, а знедавнього часу вони стали застосовуватися всюди, від бортових системуправління ЛА, до побутових приладів.
Розробка багатопроцесорних обчислювальних систем (НД), як правило,має своєю метою підвищення або рівня надійності, або рівняпродуктивності системи до значень недоступних або важкореалізоване втрадиційних ЕОМ.
У першому випадку на передній план постає питання про наявність спеціальнихзасобів забезпечення відмовостійкості обчислювальних систем, основноюособливістю (і гідністю) яких є відсутність будь-якогоєдиного ресурсу, вихід з ладу якого призводить до фатального відмовивсієї системи.
Таким чином, об'єктом дослідження в рамках мережевої відмовостійкоїтехнології стає ОСРВ - керуюче програмне забезпечення особливоготипу, що використовується для організації роботи вбудованих додатків,для яких характерні обмеженість ресурсів пам'яті, невисокапродуктивність, а також вимоги гарантованого часу відгуку,високого рівня готовності та наявності коштів автомоніторінга.
Дана дипломна робота присвячена розробці спеціалізованоїрозподіленої операційної системи реального часу для відмовостійких
НД з рангом відмовостійкості N (N-1), що означає здатність системифункціонувати навіть у тому випадку, якщо відбудуться відмови всіх елементівсистеми за винятком одного. Для повного висвітлення обраної теми булипоставлені наступні завдання:
1. Провести аналіз існуючих операційних систем реального часу, виділити основні функціональні вимоги до них, дати порівняльну характеристику.
2. Розкрити концепцію побудови ОСРВ з рангом відмовостійкості N-1, виділити основні модулі операційної системи, функціональні вимоги до них і алгоритми роботи.
3. Розкрити логіку організації відмовостійких обчислень на прикладі конкретної реалізації.
4. Провести аналіз надійності відмовостійкої НД і дати рекомендації з організації НД
5. Створити програмну модель обчислювальної системи з розподіленою операційною системою реального часу і відпрацювати на ній різні режими роботи.
6. Розглянути можливість портування (перенесення) ОСРВ на платформу
TMS320c30, розглянути специфічні проблеми і складнощі при здійсненні портаціі.
У першій частині роботи розміщено короткий опис відомих ОСРВ, описані їхфункціональні можливості, структура, їх спрямованість (специфічніособливості). Також наведено порівняльну характеристику та відзначені тірішення, які можна було б використати для розробки власноїспеціалізованої ОСРВ.
У другому розділі описана концепція побудови розподіленої ОСРВ, булисформульовані основні принципи функціонування перспективноїобчислювальної системи, що включають у себе багатопроцесорні, забезпеченняживучості, адаптацію до змін внутрішніх умов середовища, підтримкуреального масштабу часу, мобільність і відкритість програмногозабезпечення. Запропоновано приклад організації відмовостійких обчислень наприкладі п'яти-вузловий повно-мережі ПЕ в умовах постійної деградаціїсистеми.
Далі розглянута програмна модель НД і операційної системи,логіка роботи і взаємозв'язок модулів.
В останньому розділі розглядаються особливості апаратної платформи
TMS320c30, питання реалізації вищенаведених ідей за допомогою цієїплатформи, доповнення ОС специфічними для даної архітектури модулями.
Спеціальна частина
Операційні системи реального часу.
ОС загального призначення, особливо багатокористувацькі, орієнтовані наоптимальний розподіл ресурсів комп'ютера між користувачами ізавданнями (системи поділу часу), В операційних системах реальногочасу (ОСРВ), подібна завдання відходить на другий план - все відступаєперед головним завданням - встигнути зреагувати на події, що відбуваються наоб'єкті.
1 Опис і загальні вимоги до систем реального часу.
Застосування операційної системи реального часу завжди пов'язане запаратурою, з об'єктом, з подіями, що відбуваються на об'єкті. Системареального часу, як апаратно-програмний комплекс, що включає в себедатчики, які реєструють події на об'єкті, модулі вводу-виводу,перетворюють показники датчиків в цифровий вигляд, придатний для обробкицих свідчень на комп'ютері, і, нарешті, комп'ютер з програмою,реагує на події, що відбуваються на об'єкті. ОСРВ орієнтована наобробку зовнішніх подій. Саме це призводить до корінних відмінностей (запорівняно з ОС загального призначення) в структурі системи, у функції ядра, впобудові системи вводу-виводу. ОСРВ може бути схожа подля користувача інтерфейсу на ОС загального призначення, однак вона влаштованазовсім інакше - про це мова попереду.
Крім того, застосування ОСРВ завжди конкретно. Якщо ОС загальногопризначення зазвичай сприймається користувачами (не розробниками) як вжеготовий набір додатків, то ОСРВ служить тільки інструментом для створенняконкретного апаратно - програмного комплексу реального часу. І томунайбільш широкий клас користувачів ОСРВ - розробники комплексівреального часу, люди проектують системи управління та збору даних.
Проектуючи і розробляючи конкретну систему реального часу, програмістзавжди знає точно, які події можуть відбутися на об'єкті, знаєкритичні терміни обслуговування кожного з цих подій.
Назвемо системою реального часу (СРВ) апаратно-програмнийкомплекс, що реагує в передбачувані часи на непередбачуваний потікзовнішніх подій.
Це визначення означає, що:
. Система повинна встигнути відреагувати на подію, що сталася на об'єкті, протягом часу, критичного для цієї події. Величина критичного часу для кожної події визначається об'єктом і самим подією, і, природно, може бути різною, але час реакції системи повинне бути передбачене (обчислено) при створенні системи. Відсутність реакції в передбачене час вважається помилкою для систем реального часу.
. Система повинна встигати реагувати на події, що відбуваються одночасно. Навіть якщо два або більше зовнішніх подій відбуваються одночасно, система повинна встигнути зреагувати на кожне з них протягом періодів часу, критичного для цих подій.
Розрізняють системи реального часу двох типів - системи жорсткогореального часу і системи м'якого реального часу.
Системи жорсткого реального часу не допускають ніяких затримокреакції системи ні за яких умов, тому що:
. результати можуть виявитися марні в разі запізнення,
. може статися катастрофа у разі затримки реакції,
. вартість запізнення може виявитися нескінченно велика.
Приклади систем жорсткого реального часу - бортові системиуправління, системи аварійного захисту, реєстратори аварійних подій.
Системи м'якого реального часу характеризуються тим, що затримкареакції не критична, хоча й може призвести до збільшення вартостірезультатів і зниження продуктивності системи в цілому.
Основна відмінність між системами жорсткого і м'якого реального часуможна виразити так: система жорсткого реального часу ніколи не запізнитьсяз реакцією на подію, система м'якого реального часу - не повинназапізнюватися з реакцією на подію.
Тоді операційна система реального часу - це така ОС,яка може бути використана для побудови систем жорсткого реальногочасу. Це визначення виражає відношення до ОСРВ як до об'єкта,містить необхідні інструменти, але також означає, що цимиінструментами ще необхідно правильно скористатися.
1.2. Параметри ОСРВ
1.2.1. Час реакції системи
Майже всі виробники систем реального часу наводять такийпараметр, як час реакції системи на переривання (interrupt latency).
Справді, якщо головним для системи реального часу є їїздатність вчасно відреагувати на зовнішні події, то такий параметр,як час реакції системи є ключовим.
Події, що відбуваються на об'єкті, реєструються датчиками, дані здатчиків передаються в модулі вводу-виводу (інтерфейси) системи. Модулівводу-виводу, отримавши інформацію від датчиків і перетворивши її, генеруютьзапит на переривання в керуючому комп'ютері, подаючи йому тим самим сигналпро те, що на об'єкті відбулася подія. Отримавши сигнал від модуля вводу -виводу, система повинна запустити програму обробки цієї події.
Інтервал часу - від події на об'єкті і до виконання першогоінструкції в програмі обробки цієї події і є часом реакціїсистеми на події.
Зазвичай час реакції систем на переривання становить близько 4-10мкс.
1.2.2. Час перемикання контексту
У операційні системи реального часу закладений паралелізм,можливість одночасної обробки декількох подій, тому всі ОСРВє багатозадачними (многопроцесснимі, многонітіевимі).
Контекст завдання це набір даних, які задають стан процесора привиконання завдання. Зазвичай співпадає з набором регістрів, доступних длязміни прикладної задачі.
При перемиканні задач (процесів) необхідно:
1. коректно зупинити працюючу завдання; для цього а) виконати інструкції поточного завдання, вже завантажені у процесор,але ще не виконані; б) зберегти в оперативній пам'яті регістри поточного завдання;
2. знайти, підготувати і завантажити викликану завдання;
3. запустити нове завдання, для цього а) відновити з оперативної пам'яті регістри нового завдання
(збережені раніше, якщо вона до цього вже працювала); б) завантажити в процесор інструкції нового завдання.
Кожна з цих стадій вносить свій внесок у затримку при перемиканніконтексту. Оскільки будь-який додаток реального часу має забезпечитивидачу результату в заданий час, то ця затримка повинна бути мала,детермінована і відома. Це число є однією з найважливішиххарактеристик ОСРВ. Зазвичай час перемикання контексту в ОСРВ становить
10-20 мкс.
3 Розміри системи
Для систем реального часу важливим параметром є розмірсистеми виконання, а саме сумарний розмір мінімально необхідного дляроботи програми системного набору (ядро, системні модулі, драйвери і т.д.). Хоча, треба визнати, що з плином часу значення цього параметразменшується, тим не менше, він залишається важливим і виробники системреального часу прагнуть до того, щоб розміри ядра і обслуговуючихмодулів системи були невеликі.
3 Механізми реального часу
Важливим параметром при оцінці ОСРВ є набір інструментів,механізмів реального часу, що надаються системою.
1.3.1. Система пріоритетів і алгоритми диспетчеризації
Базовими інструментами розробки сценарію роботи системи єсистема пріоритетів процесів (завдань) і алгоритми планування
(диспетчеризації) ОСРВ.
У багатозадачних ОС загального призначення використовуються, як правило,різні модифікації алгоритму кругової диспетчеризації, засновані напонятті безперервного кванта часу ( "time slice"), що надаєтьсяпроцесу для роботи. Планувальник після закінчення кожного кванта часупереглядає чергу активних процесів і приймає рішення, кому передатиуправління, грунтуючись на пріоритетах процесів (чисельних значеннях, їмпривласнених). Пріоритети можуть бути фіксованими або змінюватися з часом
- Це залежить від алгоритмів планування в цієї ОС, але рано чи пізнопроцесорний час отримають всі процеси в системі.
Алгоритми кругової диспетчеризації незастосовні в чистому вигляді в ОСРВ.
Основний недолік - безперервний квант часу, протягом якогопроцесором володіє тільки один процес. Планувальники ж ОСРВ маютьможливість змінити процес до закінчення "time slice", якщо в цьому виникланеобхідність. Один з можливих алгоритмів планування при цьому
"пріоритетний з витісненням". Світ ОСРВ відрізняється багатством різнихалгоритмів планування: динамічні, пріоритетні, монотонні, адаптивніі пр., мета ж завжди переслідується одна - надати інструмент,що дозволяє в потрібний момент часу виконувати саме той процес, якийнеобхідний.
1.3.2. Механізми межзадачного взаємодії
Інший набір механізмів реального часу відноситься до засобівсинхронізації процесів і передачі даних між ними. Для ОСРВ характернарозвиненість цих механізмів. До таких механізмів відносяться: семафори,мьютекс, події, сигнали, засоби для роботи з пам'яттю, що розділяється,канали даних (pipes), черги повідомлень. Багато хто з подібних механізміввикористовуються і в ОС загального призначення, але їх реалізація в ОСРВ має своїособливості - час виконання системних викликів майже не залежить відстану системи, і в кожній ОСРВ є принаймні один швидкиймеханізм передачі даних від процесу до процесу.
3 Засоби для роботи з таймерами
Такі інструменти, як засоби роботи з таймерами, необхідні длясистем з жорстким тимчасовим регламентом, тому розвиненість засобів роботи зтаймерами - необхідний атрибут ОСРВ. Ці кошти, як правило, дозволяють:
. вимірювати і задавати різні проміжки часу (від 1 мкс і вище),
. генерувати переривання після закінчення тимчасових інтервалів,
. створювати разові і циклічні будильники
Тут описані тільки базові, обов'язкові механізми, що використовуютьсяв ОСРВ. Крім того, майже в кожній ОСРВ можна знайти цілий набірдодаткових, специфічних тільки для неї механізмів, що стосується системивводу-виводу, управління переривань, роботи з пам'яттю. Кожна системамістить також ряд засобів, що забезпечують її надійність: вбудованімеханізми контролю цілісності кодів, інструменти для роботи з таймером.
4 Класи систем реального часу
Монолітна архітектура
ОСРВ з монолітною архітектурою можна представити у вигляді (рис. 1.1)
. прикладного рівня: складається з працюючих прикладних процесів;
. системного рівня: складається з монолітного ядра операційної системи, в якому можна виділити наступні частини: інтерфейс між додатками і ядром (API), власне ядро системи, інтерфейс між ядром та обладнанням (драйвери пристроїв).
Рис. 1.1. ОСРВ з монолітною архітектурою
Інтерфейс в таких системах відіграє подвійну роль:
1. управління взаємодією прикладних процесів та системи,
2. забезпечення безперервності виконання коду системи (тобто відсутністьперемикання завдань під час виконання коду системи).
Основною перевагою монолітної архітектури є їївідносна швидкість роботи в порівнянні з іншими архітектурою. Однак,досягається це, в основному, за рахунок написання значних частин системина асемблері.
Недоліки монолітної архітектури.
1. Системні виклики, що вимагають перемикання рівнів привілеїв (відкористувацької завдання до ядра), повинні бути реалізовані як переривання абоспеціальний тип винятків. Це сильно збільшує час їхньої роботи.
2. Ядро не може бути перервано користувача завданням (non -preemptable). Це може призвести до того, що високопріоритетні завданняможе не отримати управління через роботу низькопріоритетним.
3. Складність перенесення на нові архітектури процесора череззначних асемблерних вставок.
4. Негнучкість і складність розвитку: зміна частини ядра системивимагає його повної перекомпіляції.
Це архітектура (на основі мікроядра)
Модульна архітектура з'явилася, як спроба прибрати інтерфейс міждодатками і ядром і полегшити модернізацію системи і перенесення її на новіпроцесори.
Тепер Мікроядро відіграє подвійну роль (рис 1.2):
1. управління взаємодією частин системи (наприклад, менеджерівпроцесів і файлів),
1. забезпечення безперервності виконання коду системи (тобто відсутність перемикання завдань під час виконання мікроядра).
Рис. 1.2. ОСРВ на основі мікроядра
Недоліки модульної архітектури фактично ті ж, що і умонолітною. Проблеми перейшли з рівня інтерфейсу на рівень мікроядра.
Системний інтерфейс як і раніше не допускає перемикання завдань під часроботи мікроядра, тільки скоротився час перебування в цьому стані,проблеми з перенесенням мікроядра зменшилися (у зв'язку зі скороченням йогорозміру), але залишилися.
Об'єктна архітектура на осно?? е об'єктів-мікроядер
У цій архітектурі інтерфейс між додатками і ядром відсутнійвзагалі (рис. 1.3). Взаємодія між компонентами системи (мікроядра)і призначеними для користувача процесами здійснюється за допомогою звичайного дзвінкафункцій, оскільки і система, і програми написані на одній мові (зазвичай
C + +). Це забезпечує максимальну швидкість системних викликів.
Рис. 1.3. Приклад об'єктно-орієнтованої ОСРВ
Фактичне рівноправність всіх компонент системи забезпечуєможливість перемикання завдань у будь-який час. Об'єктно-орієнтованийпідхід забезпечує модульність, безпека, легкість модернізації таповторного використання коду.
На відміну від попередніх систем, що не всі компоненти самій операційнійсистеми повинні бути завантажені в оперативну пам'ять. Якщо Мікроядро вжедодано для іншої програми, то воно повторно не завантажується, авикористовується код і дані вже наявного мікроядра. Всі ці прийомидозволяють скоротити обсяг необхідної пам'яті. Оскільки різні програмиподіляють одні мікроядра, то вони повинні працювати в одному адресномупросторі. Отже, система не може використовувати віртуальнупам'ять і тим самим працює швидше (тому що виключаються затримки натрансляцію віртуального адреси у фізичний).
1.5. Огляд деяких комерційних ОСРВ
Операційна система OS-9
OS-9 фірми Microware відноситься до класу UNIX-подібних операційнихсистем реального часу. За своєю суттю OS-9 є багатозадачною ОС звитісняючої пріоритетною диспетчеризацією, що допускає можливістьрозрахованої на багато роботи. Об'єктно-орієнтований модульний дизайнсистеми дозволяє конфігурувати систему в дуже широкому діапазоні відвбудованих систем до великих мережевих додатків. Згідно з цією концепцієювсі функціональні компоненти OS-9, включаючи ядро, ієрархічні файловіменеджери, драйвера пристроїв і т. д., реалізовані у вигляді незалежнихмодулів. Всі модулі операційної системи позиційно-незалежні і можуть бутирозміщені в ПЗУ, а також можуть вилучатися із системи в процесі їїфункціонування без будь-якої повторної інсталяції або перекомпонування.
На малюнку 1.4 приведена спрощена структурна схема операційної системи.
Структура операційної системи OS-9
Рис. 1.4. Структура операційної системи OS-9
Ядро забезпечує основний системний сервіс, включаючи управлінняпроцесами і розподіл ресурсів.
Основні характеристики:
1. Архітектура: на основі мікроядра
2. Стандарт: власний, виклики схожі на UNIX
Властивості як ОСРВ:
. Багатозадачність: многопроцессность
. Багатопроцесорна: так
. Рівнів пріоритетів: 65535
. Час реакції: 3 мкс
. Планування: пріоритетне, FIFO, спеціальний механізм планування; preemptive ядро
ОС розробки (host): UNIX/Windows
3. Процесори (target): Motorola 68xxx, Intel 80x86, ARM, MIPS, PowerPC
4. Лінії зв'язку host-target: послідовний канал і ethernet
5. Мінімальний розмір: 16Kb
6. Засоби синхронізації і взаємодії: Колективна пам'ять, сигнали, семафори, події.
Операційна система VxWorks
VxWorks відноситься до операційних систем «жорсткого» реальногочасу. Характерною рисою цієї ОС є те, завдяки її розвинутиммережним можливостям, вся розробка ПЗ ведеться на інструментальномукомп'ютері (хост-системі) з використанням крос-коштів для подальшоговиконання на цільовій машині під управлінням VxWorks.
Відмінна риса системи - можливість керувати роботою складнихкомплексів реального часу та бортових пристроїв, що використовуютьпроцесорні елементи різних постачальників. Три основні компоненти даної
ОС РВ утворюють єдине інтегроване середовище: власне ядро системи,здійснює управління процесором; набір засобів міжпроцесорного взаємодії;комплект комунікаційних програм для роботи з Ethernet абопослідовними каналами зв'язку.
Основні характеристики:
1. Архітектура: монолітна
2. Стандарт: власний і POSIX 1003
3. Властивості як ОСРВ:
. Багатозадачність: многопроцессность і багатозадачність
. Багатопроцесорна: так
. Рівнів пріоритетів: 256
. Час реакції: 4 мкс
. Час перемикання контексту: 15 мкс
. Планування: пріоритетне; preemptive ядро
4. ОС розробки (host): UNIX/Windows
5. Процесори (target): Motorola 68xxx, Intel 80x86, Intel 80960,
PowerPC, SPARC, Alpha, MIPS, ARM
6. Лінії зв'язку host-target: послідовний канал, ethernet, шина
VME
7. Мінімальний розмір: 22Kb
8. Засоби синхронізації і взаємодії: семафори POSIX 1003,черги, сигнали ...
Операційна система QNX
Операційна система QNX канадської компанії QNX Software System Ltd.побудована на основі ієрархічної мікроядерної архітектури. Спрощенаструктурна схема цієї ОС наведена на малюнку 1.5.
Рис. 1.5. Мікроядерної структура QNX
Мікроядро QNX виконує такі функції:міжпроцесорних обмін;низькорівневий мережевий обмін;диспетчеризація задач;низькорівневий обробка переривань.
Основні характеристики:
1. Архітектура: на основі мікроядра
2. Стандарт: POSIX 1003
3. Властивості як ОСРВ:
. Багатозадачність: POSIX 1003 (многопроцессность і багатозадачність)
. Багатопроцесорна: так
. Рівнів пріоритетів: 32
. Час реакції: 4,3 мкс
. Час перемикання контексту: 13 мкс
. Планування: FIFO, round robin, адаптивне; preemptive ядро
4. Процесори (target): Intel 80x86
5. Мінімальний розмір: 60Kb
6. Засоби синхронізації і взаємодії: POSIX 1003 (семафори,mutex, condvar)
Операційна система LynxOS
Система LynxOS випускається фірмою Lynx Real Time Systems (Los Gatos,
USA). ОСРВ з клона UNIX-систем, що забезпечує детерміноване часвідгуку за запитами.
Основні характеристики:
1. Архітектура: на основі мікроядра
2. Стандарт: POSIX 1003
3. Властивості як ОСРВ:
. Багатозадачність: POSIX 1003 (многопроцессность і багатозадачність)
. Багатопроцесорна: так
. Рівнів пріоритетів: 255
. Час реакції: 7 мкс
. Час перемикання контексту: 17 мкс
. Планування: FIFO, round robin, Quantum, preemptive ядро
4. Процесори (target): Intel 80x86, Motorola 68xxx, SPARC, PowerPC
5. Мінімальний розмір: повної системи: 256Kb усіченої системи: 124Kb тільки ядра: 33Kb
Систему можна записати в ROM.
6. Засоби синхронізації і взаємодії: POSIX 1003 (семафори,mutex, condvar)
Операційна система pSOS
Система pSOS випускається Integrated Systems (Santa Clara, USA).
Основні характеристики:
1. Архітектура: на основі мікроядра
2. Стандарт: власний
3. Властивості як ОСРВ:
. Багатозадачність: многопроцессность і багатозадачність
. Багатопроцесорна: так
. Рівнів пріоритетів: 255
. Час реакції: 4 мкс
. Час перемикання контексту: 12мкс
. Планування: пріоритетне; preemptive ядро
4. ОС розробки (host): UNIX/Windows
5. Процесори (target): Motorola 68xxx, Intel 80x86, Intel 80960,
ARM, MIPS, PowerPC
6. Мінімальний розмір: 15Kb
7. Засоби синхронізації і взаємодії: семафори, mutex, події, і тд.
1.6. Висновки до глави 1
Основними відмінностями ОСРВ від ОС загального призначення є:
. Орієнтація на обробку зовнішніх подій;
. Детерміноване час реакції на зовнішнє подія;
. Модульна організація;
. Невеликий розмір системи.
У главі були розглянуті найважливіші параметри і механізми ОСРВ, такіяк:
. Час реакції системи;
. Час перемикання контексту;
. Види диспетчеризації;
. Механізми синхронізації і межзадачного взаємодії
Класифікація ОСРВ дозволяє виділити найбільш оптимальну структурупобудови ОСРВ. Очевидно, що операційні системи з монолітноюархітектурою, внаслідок їх спрямованості на конкретні процесорніплатформи і характеру взаємодії з ядром, навряд чи можуть бутивикористані як щодо універсальних ОСРВ для систем високоїготовності. ОСРВ на основі мікроядра має переваги упорівняно з монолітною архітектурою, а комбінація з об'єктно -орієнтованим підходом, дозволить системі стати апаратно-незалежною ізабезпечити швидку реакцію на зовнішні події.
У висновку були перераховані основні властивості деякихпоширених ОСРВ. На жаль, жодну з розглянутих операційнихсистем не можна назвати мережевий в широкому сенсі цього слова, тому що рівеньмережевого обміну, закладений у багатьох з них відповідає рівню локальноїмережі. Багатопроцесорна підтримка, введена в VxWorks орієнтована тількина системи зі спільною пам'яттю. Відсутність механізму відмовостійкості,подібним як відмови сполук (зачатки цього є в QNX), так і відмовипроцесорних елементів, необхідного для відмовостійкихспеціалізованих обчислювальних систем, немає ні в одній з цихопераційних систем. Таким чином, завданням розробників єдодавання таких модулів існуючим ОСРВ, які дозволили б забезпечитивідмовостійкість розподілених обчислювальних систем.
2. Підтримка відмовостійкості обчислювальних систем засобами операційних систем реального часу
Специфіка застосування деяких систем обумовлює особливі вимоги,пропоновані до надійності їх функціонування. Відмова або збій у їхній роботі,потягли за собою неправильні результати обчислень (або повне їхвідсутність), можуть призвести до катастрофічних наслідків. Перевагивикористання стійких до відмов обчислювальних систем безпосередньовипливають з необхідності тривалої роботи системи в умовах, колитехнічне обслуговування (ремонт, заміна і тд.) неможливі,важкореалізоване або зв'язані з великими економічними витратами. Тому
Нд та спеціалізовані операційні системи розробляються таким чином,щоб система була толерантна (терпима) до виникаючих відмов. Особливо цеактуально для автономних ЛА (наприклад, космічних апаратів).
Складність сучасних обчислювальних засобів така, що практичнонеможливо перевірити готові вироби при всіх передбачуваних умовах ірежимах їх роботи. Тому в обчислювальних системах можуть бути приховані --не виявили при перевірці - помилки програмного забезпечення і (або)несправності апаратури, але завдяки відмовостійкості збій, відмоваокремого елемента як правило не призводять до спотворення вихідних даних.
На відміну від апаратної частини обчислювальної системи поява помилоку програмі не пов'язано з фізичними процесами. Отримання результатів,відмінних від очікуваних відбувається в результаті виконання неперевіреноючастини програми або в результаті помилки в програмі.
Таким чином, отримання відповіді, відмінного від очікуваного, в деякиймомент часу є результат виконання неперевіреною частини програми,що містить помилку, завдання вхідних даних, для яких поведінку програминеспеціфіціровано, а також впливу відмов в апаратурі на роботупрограми.
При розгляді надійності обчислювальної системи слід матина увазі, що вона визначається надійністю апаратної частини і надійністюпрограмного забезпечення. Однак, поняття надійності програмногозабезпечення неконструктивно, це означає, що на етапі тестуванняпрограми не були виявлені всі помилки. У даній роботі вважається, щопрограма не містить помилок, та отримання результату, відмінних відочікуваного залежить від збоїв або відмов апаратної частини чи інших факторів
(наприклад, вплив ЕМІ на зміст оперативної пам'яті), а тому питання пронадійності програмного забезпечення не ставиться. Таким чином, надійністьобчислювальної системи визначається надійністю апаратури і впливомвідмов у ній на відмови в обчислювальної системи в цілому.
Попередні дослідження показали, що для елементної базисередньої якості (надійність 0.999 - "три дев'ятки після коми") приоптимальному поєднанні швидкості отримання результату на його надійність вобчислювальної середовищі теоретично досяжна достовірність отриманняправильних результатів машинного рахунку в "двісті дев'яток після коми" приуповільнення темпу їх отримання в 300-400 разів [1], що еквівалентнозбільшення надійності до 200 порядків величини при введенні порівняноневеликий обчислювальної надмірності, що приводить до втратипродуктивності не більше ніж на 2-3 порядки, що вже на сучасномурівні може компенсуватися підбором комп'ютерів необхідноїпродуктивності.
1. Поняття відмовостійкості НД
Відмовостійкість будемо називати властивість системи, що дозволяєпродовжити виконання заданих програмою дій після виникненняодного або декількох збоїв або відмов компонентів НД
Відмовою називається подія, що полягає в порушенніпрацездатності компоненту системи. Наслідки відмови можуть бутирізними. Відмова системи може бути викликаний відмовою (невірнимспрацьовуванням) якихось її компонентів (процесор, пам'ять, пристроївведення/виводу, лінії зв'язку, або програмне забезпечення). Відмова компонентаможе бути викликаний помилками при конструюванні, при виробництві абопрограмуванні. Він може бути також викликаний фізичним ушкодженням,зношуванням обладнання, некоректними вхідними даними, і багатьмаіншими причинами.
Відмови можуть бути випадковими, періодичними або постійними.
Випадкові відмови (збої) при повторенні операції зникають. Причиною такогозбою може служити, наприклад, електромагнітна завада. Інший приклад --рідкісна ситуація в послідовності звернень до операційної системи відрізних завдань. Періодичні відмови повторюються часто протягом якогосьчасу, а потім можуть довго не відбуватиметься. Приклади - поганий контакт,некоректна робота ОС після обробки аварійного завершення завдання.
Постійні (стійкі) відмови не припиняються до усунення їх причини --руйнування диска, виходу з ладу мікросхеми або помилки в програмі.
2.2. Причини та класифікація відмов і збоїв
Відмови за характером свого прояву підрозділяються на візантійські
(система активна і може проявляти себе по-різному, навіть злочинно) іпропажа ознак життя (часткова або повна). Перші розпізнати набагатоскладніше, ніж друге.
Апаратна реалізація вузлів (процесорних модулів) дозволяєвиділити основні класи відмов апаратури:
- Відмова процесора (центральної частини ПЕ);
- Відмова лінку - зв'язки між ПЕ;
Ідентифікація відмови процесора будь-якого вузла мережікласифікується, як відмова всього сайту: він ізолюється від іншої мережі налогічному рівні і за наявності відповідної підтримки відключається наапаратному рівні (вимикається харчування).
Ідентифікація відмови лінка (зв'язку) призводить лише до зменшення ступенязв'язності вузлів мережі. Відмовив, лінк ізолю на логічному рівнішляхом зміни маршрутів передачі повідомлень між вузлами мережі.
Відмова при виконанні функціонального програмного забезпечення можепроявитися внаслідок:
- порушення кодів запису програм в пам'яті команд;
- стирання або перекручування даних в оперативній або довготривалої пам'яті;
- порушення нормального ходу обчислювального процесу.
Перераховані викривлення можуть діяти спільно. Відмова можевиявлятися у вигляді програмного зупину або зациклення, систематичногопропуску виконання певної групи команд, одноразового абосистематичного перекручування даних і тд. Програмні відмови призводять доприпинення видачі абонентам інформації і керуючих впливів, чи дозначного спотворення її змісту і темпу видачі, відповіднихпорушення працездатності.
Основна особливість (і гідність) мережевий відмовостійкоїтехнології - відсутність будь-якого (навіть самого незначного)єдиного компонента (ресурсу), вихід з ладу якого призводить дофатального відмови всієї системи. Така система не може містити будь -або "центрального" (головного) вузла, розміщеного в одному з процесорнихелементів системи, вона може складатися тільки з "рівноправних" частин,розміщених в кожному вузлі мережі. Таким чином можна говорити лише продеградації якості системи при відмові одного або більше її елементів. Утакій системі повна відмова настає після виходу з ладу тількипевної кількості ресурсів, визначеного на етапі проектування.
3. Методи і засоби забезпечення відмовостійкості
Для забезпечення надійного вирішення завдань в умовах відмов системизастосовуються два принципово розрізняються підходу - відновленнярішення після відмови системи (або її компоненту) та запобігання відмовисистеми (відмовостійкість).
Відновлення може бути прямим (без повернення до минулого стану)і зворотний.
Пряме відновлення засноване на своєчасному виявленні збою іліквідації його наслідків шляхом приведення некоректного стану системив коректнотобто Таке відновлення можливо тільки для певного наборузаздалегідь передбачених збоїв.
При зворотному відновлення відбувається повернення процесу (абосистеми) з некоректного стану в якийсь з попередніхкоректних станів. При цьому виникають наступні проблеми:
. Втрати продуктивності, викликані запам'ятовуванням станів, відновленням запомненного стану і повторенням раніше виконаної роботи, можуть бути дуже високі.
. Немає гарантії, що збій знову не повториться після відновлення.
. Для деяких компонентів системи відновлення до попереднього стан може бути неможливо (торговий автомат).
Для відновлення стану в традиційних ЕОМ застосовуються дваметоду (та їх комбінація), засновані на проміжній фіксації стануабо веденні журналу виконуваних операцій. Вони розрізняються об'ємомзапам'ятовувати інформацію і часом, необхідним для відновлення.
Застосування подібних методів у розподілених системах наштовхуєтьсяна наступні труднощі:
. Для розподілених систем запам'ятовування узгодженого глобального стану є серйозною проблемою теоретичної;
. методи відновлення після відмов для деяких систем непридатні через переривання нормального функціонування та ін;
Щоб уникнути ці неприємності, створюють системи, стійкі довідмов. Такі системи або маскують відмови, або ведуть себе у випадкувідмови заздалегідь певним чином.
У міру того як операційні системи реального часу і вбудованікомп'ютери все частіше використовуються в критично важливих додатках,розробники створюють нові ОС реального часу високої готовності. Ціпродукти включають в себе спеціальні програмні компоненти, якіініціюють попередження, запускають системну діагностику для того, щобдопомогти виявити проблему, або автоматично перемикаються на резервнусистему.
Забезпечення живучості - це використання спеціальних засобів,що дозволяють системі продовжувати правильне функціонування привиникненні відмов її програмних і апаратних компонентів зможливістю деградації якості функціонування [2]. На відміну відвідмовостійкості, де з відмовою не пов'язане якість роботи ВС,порівняно складні засоби забезпечення живучості дозволяють більшраціонально витрачати обчислювальні ресурси та збільшувати середній часнапрацювання до настання фатального відмови. Забезпечення живучості зазвичайвключає три основні функції: діагностика виникнення відмови,локалізація несправності і перебудова системи. В основі толерантностілежить надмірність як апаратного, так і програмного забезпечення. Томубагатопроцесорні системи з притаманною їм апаратної надмірністюпотенційно дозволяють створювати не тільки високопродуктивні, але йвисоконадійні системи.
Іншим основним вимогою є наявність механізму,дозволяє агентам в кожному пристрої обмінюватися топологічноїінформацією зі своїми сусідами поср
