Розробка відмовостійкої ОС реальної години для обчислювальних систем з максимальним рангом відмовостійкості

Упродовж багатьох років докладання з урахуванням ОС реального часу використовувалися у вбудованих системах спеціального призначення, і з останнього часу вони почали застосовуватися всюди, від бортових систем управління ЛА, до побутових приборов.

Розробка багатопроцесорних обчислювальних систем (ЗС) зазвичай, має на меті підвищення або рівня надійності, або рівня продуктивності системи до значень недоступних чи труднореализуемых в традиційних ЭВМ.

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

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

Ця дипломна робота присвячена розробці спеціалізованої розподіленої ОС реального часу для отказоустойчивых ВР із рангом отказоустойчивости 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). прикладного рівня: складається з працюючих прикладних процесів;. системного рівня: складається з монолітного ядра ОС, де можна виокремити такі частини: інтерфейс між додатками і ядром (АПІ), власне ядро системи, інтерфейс між ядром і теплопостачальним обладнанням (драйвери устройств).

[pic].

Рис. 1.1. ОСРВ з монолітною архитектурой.

Інтерфейс в системах грає подвійну роль:

1. управління взаємодією прикладних процесів і системы,.

2. забезпечення безперервності виконання коду системи (тобто. відсутність перемикання завдань під час виконання коду системы).

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

Недоліки монолітною архитектуры.

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

2. Ядро може бути перервано користувальницької завданням (nonpreemptable). Це може спричинить тому, що высокоприоритетная завдання може отримати управління роботу низкоприоритетной.

3. Складність перенесення нові архітектури процесора через значних ассемблерных вставок.

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

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

Тепер микроядро грає подвійну роль (рис 1.2):

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

[pic].

Рис. 1.2. ОСРВ з урахуванням микроядра.

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

Объектная архітектура з урахуванням объектов-микроядер

У цьому архітектурі інтерфейс між додатками і ядром відсутня взагалі (рис. 1.3). Взаємодія між компонентами системи (микроядрами) і користувальницькими процесами здійснюється з допомогою звичайного виклику функцій, бо система, і додатки написані однією мовою (зазвичай З++). Це забезпечує максимальну швидкість системних вызовов.

[pic].

Рис. 1.3. Приклад объектно-ориентированной ОСРВ.

Фактичне рівноправність всіх компонент системи забезпечує можливість перемикання завдань у час. Объектно-ориентированный підхід забезпечує модульність, безпеку, легкість модернізації існуючих і використання кода.

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

1.5. Огляд деяких комерційних ОСРВ.

Операційна система OS-9.

OS-9 фірми Microware належить до класу UNIX-подобных операційних систем реального часу. За своєю суттю OS-9 є многозадачной ОС з вытесняющей пріоритетною диспетчеризацией, яка припускає можливість многопользовательской роботи. Объектно-ориентированный модульний дизайн системи дозволяє конфіґурувати систему на вельми широкому діапазоні від які вбудовуються систем до великих мережевих додатків. Відповідно до цю концепцію все функціональні компоненти OS-9, включаючи ядро, ієрархічні файлові менеджери, драйвера пристроїв тощо. буд., реалізовані як незалежних модулів. Усі модулі ОС позиционно-независимы і може бути розміщені в ПЗУ, і навіть можуть віддалятися із системи у її функціонування було без будь-якої повторної інсталяції чи перекомпоновки. На малюнку 1.4 приведено спрощена структурна схема операційній системы.

Структура ОС OS-9.

[pic].

Рис. 1.4. Структура ОС OS-9.

Ядро забезпечує основний системний сервіс, включаючи управління процесами і розподіл ресурсов.

До основних рис: 1. Архітектура: з урахуванням мікроядра 2. Стандарт: власний, виклики нагадують UNIX.

Властивості як ОСРВ:. Многозадачность: многопроцессность. Многопроцессорность: так. Рівнів пріоритетів: 65 535. Час реакції: 3 мкс. Планування: пріоритетне, FIFO, спеціальний механізм планування; preemptive ядро.

ОС розробки (host): UNIX/Windows.

3. Процесорам (target): Motorola 68xxx, Intel 80×86, 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 80×86, Intel 80 960, PowerPC, SPARC, Alpha, MIPS, ARM.

6. Лінії зв’язку host-target: послідовний канал, ethernet, шина VME.

7. Мінімальний розмір: 22Kb.

8. Кошти синхронізації і взаємодії: семафори POSIX 1003, черги, сигналы…

Операційна система QNX.

Операційна система QNX канадської компанії QNX Software System Ltd. побудовано основі ієрархічної микроядерной архітектури. Спрощена структурна схема цієї ОС приведено малюнку 1.5.

[pic].

Рис. 1.5. Микроядерная структура QNX.

Микроядро QNX виконує такі функції: межпроцессорный обмін; низкоуровневый мережевий обмін; диспетчеризація завдань; низкоуровневая обробка переривань. Основні характеристики:

1. Архітектура: з урахуванням микроядра.

2. Стандарт: POSIX 1003.

3. Властивості як ОСРВ:. Многозадачность: POSIX 1003 (многопроцессность і многозадачность). Многопроцессорность: так. Рівнів пріоритетів: 32. Час реакції: 4,3 мкс. Час перемикання контексту: 13 мкс. Планування: FIFO, round robin, адаптивне; preemptive ядро.

4. Процесорам (target): Intel 80×86.

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 80×86, 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 80×86, Intel 80 960, 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]. На відміну від отказоустойчивости, де із відмовою від не пов’язано якість роботи ЗС, порівняно складні кошти забезпечення живучості дозволяють більш раціонально витрачати обчислювальні ресурси, і збільшувати середнє час напрацювання до фатального відмови. Забезпечення живучості зазвичай включає три основні функції: діагностика виникнення відмови, локалізація несправності і перебудова системи. У основі толерантності лежить надмірність як апаратного, і програмного забезпечення. Тому многопроцессорные системи із притаманною їм апаратної надмірністю потенційно дозволяють створювати як високопродуктивні, а й высоконадежные системы.

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

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

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

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

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

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

Проте задля систем в останній стадії деградації (у відмові передостаннього вузла мережі) першому плані як діагностичної інформації виходять ознаки исправности-неисправности, формовані різними программно-аппаратными засобами контролю, такі як:. функціональний контроль обчислень з допомогою спеціальних контрольних операторів і знання кількох версій програм;. функціональний контроль вхідний і вихідний інформації;. контроль вхідний інформації з спеціальним ознаками і контрольним сумам;. контроль вихідний інформації з квитанції від приймача — абонента системного інтерфейсу;. контрольний тест апаратури процесора;. контрольні тести апаратури зовнішнього й внутрішнього інтерфейсів.. вбудовані апаратні засіб контролю процессорных елементів і контролерів системного интерфейса.

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

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

4. Концепція побудови й досвід роботи системи з рангом отказоустойчивости N-1.

У отказоустойчивых системах, побудованих на N процессорных елементах, рангом отказоустойчивости називатимемо якомога більше відмов функціональних елементів (ПЭ), після застосування яких система продовжує свою функціонування. Введемо позначення — N (m), яке означає, що систему містить N вузлів (ПЭ) і «тримає» m відмов, тобто. нормально функціонують до того часу, наразі залишаються справними (N-m) вузлів. Слід зазначити, що системи класу N (0) — ставляться до швидкодіючим системам, а N (N-1) — до отказоустойчивым.

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

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

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

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

— результатів «голосування» (порівняння) що надходить у даний ПЭ функціональної информации;

— результатів оцінки що надійшла з інших ОС узлов;

— «результатів голосування» (тобто. «висновок» даного ПЭ про стан інших ПЭ).

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

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

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

4. ОС повинна мати властивістю масштабируемости, що у вузькому значенні означає забезпечення її настраиваемости ось на підтримку функціонування мережевих ЗС різної розмірності N (для реальних систем не більше 3 (N (10). Причому права кордон зміни N (Nmax = 10) обрано з практичних міркувань побудови ВР із високим рівнем связности вузлів мережі при використанні конкретних процессорных модулів кількістю лінків (L) не понад шість (L (6). При L=6 семиузловая мережу є полносвязанной і з збільшення N ступінь связности вузлів мережі уменьшается.

5. Часу до виконання усіх дій має хапати з запасом 20−30% з урахуванням продуктивності апаратної платформы.

З огляду на це факту (достатності ресурсу продуктивності) диспетчеризація обчислень зводиться підтримувати наступних процедур:. синхронізація обчислень — по циклам видачі управляючих сигналов.

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

Надалі цей перелік вимог до ОСРВ продовжать і детализирован.

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

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

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

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

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

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

2.4.1. Опис системних таблиц.

Основна інформацію про функціонуванні ОС цьому ПЭ розміщена в системних таблицах.

Граф інформаційної связности процессорных елементів ставиться в вигляді модифікованої матриці связности. Відмінність від стандартної матриці связности у тому, у межах рядка, яка описує зв’язність даного ПЭ коїться з іншими, використовується число «-1» у разі, коли цей процесорний елемент не пов’язані з ПЭ, який задається стовпцем, і номер каналу зв’язку (линка) яким здійснюється ця зв’язність інакше, причому нумерацію лінків для зручності можна починати з m+1 вузла, тобто для вузла m зв’язку з вузлом m+1 здійснюватиметься лінком з найменшою номером.

Таблиця 2.1.

Приклад таблиці связности для полносвязной мережі ПЭ.

|№/№ |1 |2 |3 |4 |… |N | |1 |-1 |0 |1 |2 |… |N-2 | |2 |N-2 |-1 |0 |1 |… |N-3 | |3 |N-3 |N-2 |-1 |1 |… |N-4 | |4 |N-4 |N-3 |N-2 |-1 |… |N-5 | |… |… |… |… |… |… |… | |N |0 |1 |2 |3 |… |-1 |.

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

Наведемо приклад таблиць розсилки. Для наочності візьмемо мережа з чотирьох ПЭ, подану малюнку 2.1.

[pic].

Рис. 2.1. Приклад неполносвязной сети Цифры в кіл — номери процессорных елементів, поза — номери лінків (фізичних каналів зв’язку). Отже таблиця связности має вигляд (таблиця 2.2).

Таблиця 2.2.

Таблиця связности приміром малюнку 2.1 |№/№ |1 |2 |3 |4 | |1 |-1 |0 |-1 |1 | |2 |1 |-1 |0 |-1 | |3 |1 |-1 |-1 |0 | |4 |0 |-1 |1 |-1 |.

Таблицы розсилки кожному за ПЭ може мати вид (див. Таблицю 2.3, 2.4, 2.5, 2.6).

Таблиця 2.3.

Таблиця розсилки для ПЭ № 1 |№ ПЭ |1 |2 |3 |4 | |№ Линка |-1 |0 |0 |1 |.

Таблиця 2.4.

Таблиця розсилки для ПЭ № 2 |№ ПЭ |1 |2 |3 |4 | |№ Линка |1 |-1 |0 |0 |.

Таблиця 2.5.

Таблиця розсилки для ПЭ № 3 |№ ПЭ |1 |2 |3 |4 | |№ Линка |0 |1 |-1 |0 |.

Таблиця 2.6.

Таблиця розсилки для ПЭ № 4 |№ ПЭ |1 |2 |3 |4 | |№ Линка |0 |0 |1 |-1 |.

2.4.2. Модуль маршрутизатора.

Як у підрозділі 2.4.1 маршрутизатор виконує такі функції:. зберігання поточної топології многопроцессорной системи;. встановлення оптимальних статичних маршрутів передач даних у системі і таблиць розсилки;. обробка сигналів зміни топології системи від реконфигуратора. При ініціалізації потрібно вихідна топологія системи. Отже, модуль маршрутизації можна як наступній спрощеної схемы:

[pic].

Рис. 2.2. Модуль маршрутизации.

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

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

Алгоритм визначення статичних маршрутів і заповнення таблиці рассылки:

1. Заповнюємо таблицю розсилки в соотвествие зі рядком з номером, рівним номера процесорного елемента. Заповнюємо відповідну таблицю відстаней одиницями (лічильник довжини маршруту) у його осередках, де є прямий зв’язок в таблиці связности (>0).

2. Якщо оброблені все ПЭ, закончить.

3. Збільшуємо лічильник довжини маршруту на 1 одиницю (передачу).

4. По таблиці розсилки знаходимо черговий ПЭ, яка має в зв’язку зі локальним. Якщо таких більше немає, крок 8.

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

6. Якщо вона має зв’язку з за потрібне ПЭ, запам’ятовуємо номер линка для зв’язку його з локальним ПЭ і завантаження линка. Крок 5.

7. Сортуємо знайдені лінки по наменьшей завантаженості і заносимо їх у таблицю розсилки і таблицю відстаней. Якщо оброблені все ПЭ, закінчити, інакше крок 3.

2.4.3. Модуль реконфигурации.

Модуль реконфигурации активізується і виконує перебудову системних таблиць ОС з урахуванням інформації про конкретне відмову. Розглянемо обробку відмови функціональної завдання, відмови каналу зв’язку й відмови процесора целиком.

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

У цьому визначається, чи є який відмовив канал зв’язку ставлення до цього процесорному елементу. Що стосується, коли після відмови каналу зв’язку, будь-якої процесор виявляється ізольованим, виконується відключення процесорного елемента.. Відмова процесорного елемента. Обробка відмови всього процесорного елемента виконується у вигляді корекції матриці связности ПЭ, видалення всіх каналів зв’язку.. Відмова функціональної завдання трактується як і, як й відмова процесорного элемента.

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

[pic].

Рис. 2.3. Модуль реконфигурации.

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

1. У таблиці связности який відмовив лінк чи лінки який відмовив ПЭ позначаються як недоступные.

2. Перевіряється, залишилися чи ізольованими решта вузли, якщо так, всі вони отключаются.

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

4. Виробляється активізація резервного ПЭ через передачу йому коду активізації, поточної таблиці связности і контексту завдання від «старшого ПЭ у ВР (наприклад, від ПЭ із меншим номером).

2.4.4. Модуль коммуникации.

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

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

(голосування);. виявлення голосуванням відмови компонент системи та посилка відповідного сигналу модулю реконфигурации;. передача узгоджених даних ФЗ;. передача/прием системних сообщений.

Модуль пересилки інформації:. формування формату переданого повідомлення;. ідентифікація прийнятих повідомлень;. діагностика цілісності прийнятих повідомлень (перевірка контрольної суми);. визначення відмов фізичної середовища передачі (перевірка підтверджень прийому даних — «квитанцій»);. формування сигналу модулю ОС — реконфигуратору про несправності середовища передачи.

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

[pic].

Рис. 2.4. Структура модулів коммуникации.

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

Формат посилки складається з заголовка і самої тіла посилки. У заголовку використовуються такі поля:

. Одержувач (номер ПЭ);

. Отправитель;

. Тип посилки (інформаційна чи системная);

. Розмір інформаційної частини посилки (то, можливо нулевой);

. Контрольна сума пакета.

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

2.4.5. Процедура голосования.

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

За результатами порівняння формується вектор проміжного стану (попередній висновок про стан системи). Наприклад, вектор може складатися з 0, якщо відповідний вузол все гаразд за результатами порівняння чи -1, при розбіжності результатів порівняння. У цьому, якщо ці поточного вузла не збігаються з результатами сусідніх ПЭ, то поточний вузол може прогнозувати власний сбой.

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

Розбіжність результатів порівняння може бути викликане збоєм чи відмовою фізичного каналу зв’язку. Цьому може передувати сигнал про несправності каналу зв’язку від модуля комунікації. Інакше (при відсутності сигналу), збій в лінії зв’язку то, можливо визначено за отриманими векторах стану. Наприклад ПЭ отримані такі вектора: (0,-1,0), (- 1,0,0), (0,0,0), де кожному вектору і кожному елементу вектора поставлене відповідність номер ПЭ (тобто ПЭ1, ПЭ2, ПЭ3). Аналіз порівняння цих проміжних результатів може сказати про несправності каналу зв’язок між ПЭ1 і ПЭ2.

За такої побудові системи зроблено неявний припущення у тому, що у протязі одного циклу може відмовити трохи більше одного елемента системи, інакше поведінка їх у цьому випадку слід сказати недетерминировано. Втім дане припущення можна буде аргументувати тим, що час напрацювання на відмова окремого елемента системи становить по крайнього заходу кілька тисяч годин, і вважаючи виникнення відмов незалежними подіями, ймовірність відмови одночасно двох елементів протягом циклу (порядку 10 — 100 мс) величина порядку 10−17 — 10−18. Проте за виникненні цій ситуації виходом то, можливо застосування методів помехоустойчивого статистичного оцінювання результатів розрахунку [10], проведення діагностичних тестів і т.ін. для вибору коректного результату прийняття рішення про видачу тієї чи іншої управляючого на поточному цикле.

2.5. Організація отказоустойчивых вычислений.

У розділі приймемо до уваги запроваджене раніше припущення про ординарности потоку відмов, цебто в протязі одного циклу (такту) роботи системи множинні відмови не возникают.

Зазначимо, що реакція систем діагностування відмов такова:

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

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

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

4. Розбіжність контрольної суми чи тайм-аут прийому даних сприймається як збій ПЭ чи каналу зв’язку ПЭ.

5. Відсутність квитанції сприймається як збій ПЭ чи каналу зв’язку ПЭ.

6. Зрадливий код квитанції сприймається як збій каналу зв’язку ПЭ.

Нагадаємо, ідея організації отказоустойчивых обчислень полягає в використанні трьох типів надмірності: апаратної, програмної і інформаційної. Тобто. задана завдання реалізується понад трьох процессорных елементах мережі. Робоча конфігурація мережі складається з трьох ПЭ, результати рахунки копія завдання відсилає не більше робочої конфігурації. На основі результатів голосування формується інформацію про ході обчислювального процесу про стан апаратури (справна — несправна) ЗС. Цією інформації досить (зазвичай з більшою надмірністю) для ухвалення рішення про перебудові (реконфигурации) мережі у разі виникнення відмов апаратури ВС.

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

2.5.1 Приклад організації отказоустойчивых вычислений.

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

[pic].

Рис 2.5. Топологія ВС.

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

2.5.1. Инициализация.

Для ініціалізації роботи процессорных елементів використовуються конфігураційні файли, містять номер ПЭ і таблицю связности (таблиця 2.8).

Таблиця 2.8.

| |№/№ |1 |2 |3 |4 |5 | | |1 |-1 |0 |1 |2 |3 | | |2 |3 |-1 |0 |1 |2 | | |3 |2 |3 |-1 |0 |1 | | |4 |1 |2 |3 |-1 |0 | | |5 |0 |1 |2 |3 |-1 |.

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

1. ПЭ1 -> ПЭ2 і ПЭ3;

2. ПЭ2 -> ПЭ3 і ПЭ4;

3. ПЭ3 -> ПЭ4 і ПЭ5;

4. ПЭ4 -> ПЭ5 і ПЭ1;

5. ПЭ5 -> ПЭ1 і ПЭ2;

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

Уявімо тепер, що відбувся перший відмова апаратури. Нехай відмовив канал зв’язок між ПЭ1 і ПЭ3. Якщо за якомусь відмову процесорний елемент взагалі видає результати рахунки, то голосування здійснюється з допомогою відповідних результатів систем діагностування (перевірка КС, квитанций).

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

Таблиця 2.9 |№ ПЭ |Отримано |Дані від |Не збігаються з |Можлива причина: | | |дані від |ПЭ № |даними від ПЭ № |Несправність | | |ПЭ № | | |ПЭ № чи Лінк № | |1 |4, 5 | | |Ні несправності | |2 |5, 1 | | |Ні несправності | |3 |1, 2 |1 |2, 3 |1 | | | | | |1−3 | |4 |2, 3 | | |Ні несправності | |5 |3, 4 | | |Ні несправності |.

Обмінявшись результатами голосування, в вузлах може бути суперечлива інформація, представлена таблицею 2.10. Слід уточнити, що у кожну нову такті область пам’яті зарезервована під результати голосування сусідніх ПЭ переинициализируется, тобто містить «сміття» до занесення знову оновленої информации.

Аналіз інформації ПЭ1 дозволяє зробити висновок про працездатності ПЭ3, оскільки повідомлення про його несправності не підтвердили ПЭ4 і ПЭ5, і виявити збій в каналі зв’язку 3−1. Аналіз ПЭ2, ПЭ3, ПЭ4, ПЭ5 отриманої інформації показує на несправність линка 3−1, оскільки працездатність ПЭ1 підтверджується вузлом ПЭ2 і наявністю у пам’яті достовірну інформацію про що відбулося сеансі зв’язки Польщі з ПЭ1.

Таблиця 2.10 |ПЭ|Данные |Можлива причина|Вывод |Консолідоване| |№ |голосування |несправності | |рішення | | |від ПЭ № |ПЭ № чи Лінк | | | | | |№ | | | | |1 | Ні | | | | | |несправності | | | | |2 | Ні | | | | | |несправності | | | |1 |3 | «сміття «| Несправний | | | | | |Лінк 3−1 | | | |4 | Ні | | | | | |несправності | | | | |5 | Ні | | | | | |несправності | | | | |1 | Ні | | | | | |несправності | | | | |2 | Ні | | | | | |несправності | | | |2 |3 | 1 | Несправний | | | | |1−3 |Лінк 3−1 | | | |4 | Ні | | | | | |несправності | | | | |5 | Ні | | | | | |несправності | | | | |1 | | | | | | | «сміття «| | | | |2 | Ні | | | | | |несправності | | | |3 |3 | 1 | Несправний | Несправний | | | |1−3 |Лінк 3−1 |Лінк 3−1 | | |4 | Ні | | | | | |несправності | | | | |5 | Ні | | | | | |несправності | | | | |1 | Ні | | | | | |несправності | | | | |2 | Ні | | | | | |несправності | | | |4 |3 | 1 | Несправний | | | | |1−3 |Лінк 3−1 | | | |4 | Ні | | | | | |несправності | | | | |5 | Ні | | | | | |несправності | | | | |1 | Ні | | | | | |несправності | | | | |2 | Ні | | | | | |несправності | | | |5 |3 | 1 | Несправний | | | | |1−3 |Лінк 3−1 | | | |4 | Ні | | | | | |несправності | | | | |5 | Ні | | | | | |несправності | | |.

При появу цій ситуації виникатимуть такі трудности:

1. Недостовірність переданої інформації спричинило короткочасним збоєм, у своїй ПЭ1 отримав достовірні результати рахунки, а ПЭ3 — недостоверные.

Рішення: відключенні каналу зв’язку 3−1 відбувається за троєкратному повторенні сбоя.

2. Збій виник на етапі обміну результатами голосования.

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

Після прийняття своє рішення про відмову від зв’язку 3−1, ініціюється реконфигуратор, що вносить відповідні зміни до таблицю связности (див таблицю 2.11).

Таблиця 2.11.

| |№/№ |1 |2 |3 |4 |5 | | |1 |-1 |0 |-1 |2 |3 | | |2 |3 |-1 |0 |1 |2 | | |3 |-1 |3 |-1 |0 |1 | | |4 |1 |2 |3 |-1 |0 | | |5 |0 |1 |2 |3 |-1 |.

Далее реконфигуратор проводить перевірку порушення связности у робітничій мережі. У разі змінюються статичні маршрути ПЭ і зв’язок між ПЭ1 і ПЭ3 здійснюється через ПЭ2.

Припустимо тепер, що відмовив ПЭ4. У цьому ПЭ4 може поводитися подвійно: або настав фатальний відмову і ПЭ видає результатів, або видає спотворені результати. У другий випадок як і то, можливо два варіанта: ПЭ зберігає здатність правильно здійснювати міна й голосування. І тут ПЭ здатний діагностувати свою помилку. Інакше вважається, що сбойный вузол видає результати, не які мають інформативною навантаження («сміття»). Проілюструємо все случаи.

Після етапу порівняння інформації, у системі може бути наступна інформація (таблиця 2.12).

Таблиця 2.12 |№ ПЭ |Отримано |Дані |Не збігаються з |Можлива причина:| | |дані від ПЭ|от |даними від ПЭ №| | | |№ |ПЭ № | |Несправність | | | | | |ПЭ № чи Лінк| | | | | |№ | |1 |4, 5 |4 |1, 5 | 4 | | | | | |1−4 | |2 |5, 1 | | |Ні несправності | |3 |1, 2 | | |Ні несправності | |4 Варіант |2, 3 | | |"сміття" | |1 | | | | | |4 Варіант |2, 3 |4 |2, 3 | 4 | |2 | | | |4−3, 4−2 | |5 |3, 4 |4 |3, 5 | 4 | | | | | |5−4 |.

После обміну результатами голосування, переважають у всіх вузлах може бути інформація, представлена таблицею 2.13.

Таблиця 2.13.

|Данные |Можлива причина |Висновок |Консолідоване | |голосування |несправності | |рішення | |від ПЭ № |ПЭ № чи | | | | |Лінк № | | | |1 | 4 | | | | |4−1 | | | |2 | Ні | | | | |несправності | | | |3 | Ні | | | | |несправності | | | | 4 Варіант |"сміття" | Несправність ПЭ4 |Несправність ПЭ4 | |1 | | | | | 4 Варіант | 4 | | | |2 |4−3, 4−2 | | | |5 | 4 | | | | |5−4 | | |.

Вариант 1: Повідомлення від ПЭ4, містить «сміття», що свідчить про несправності ПЭ4 або його каналів зв’язку. Проте ПЭ1 і ПЭ5 прийняли рішення про несправності ПЭ4 чи каналів зв’язку 5−4, 4−1. Оскільки відмова відразу всіх каналів зв’язку ПЭ4 й відмова ПЭ4 події рівнозначні, приймають рішення про несправності ПЭ4. Варіант 2: Повідомлення ПЭ4 підтверджує результати голосування у трійці ПЭ4, ПЭ5, ПЭ1 і законодавців береться рішення про відмову від ПЭ4. Після двох відмов (линка 3−1 і ПЭ4) ЗС має вигляд (рис. 2.6).

[pic].

Рис. 2.6. Топологія ЗС після 2-х відмов Таблиця связности, змінена реконфигуратором, представлена таблицею 2.14. Обмін результатами рахунки тепер здійснюється наступним образом:

1. ПЭ1 -> ПЭ2 і ПЭ3;

2. ПЭ2 -> ПЭ3 і ПЭ5;

3. ПЭ3 -> ПЭ5 і ПЭ1;

4. ПЭ5 -> ПЭ1 і ПЭ2;

Таблиця 2.14.

Оновлена таблиця связности.

| |№/№ |1 |2 |3 |4 |5 | | |1 |-1 |0 |-1 |-1 |3 | | |2 |3 |-1 |0 |-1 |2 | | |3 |-1 |3 |-1 |-1 |1 | | |4 |-1 |-1 |-1 |-1 |-1 | | |5 |0 |1 |2 |-1 |-1 |.

Рассмотрим подальший процес деградації системи. Відмова ПЭ5 аналогічно легко діагностується, завдяки зв’язків із кожним ПЭ у системі. Припустимо тепер, що відбувся відмова каналу зв’язку 2−3. Нагадаємо, що зв’язок ПЭ1 і ПЭ3 здійснюється через ПЭ2.

Отже, врешті на вузлах мережі фіксуються такі факти розбіжності результатів рахунки, представлені у таблиці 2.15.

Таблиця 2.15 |№ ПЭ |Отримано |Дані від |Не збігаються з |Можлива причина: | | |дані від |ПЭ № |даними від ПЭ № |Несправність | | |ПЭ № | | |ПЭ № чи Лінк №| |1 |3,5 |3 |1, 5 |2 чи 3 2−1 | | | | | |чи 2−3 | |2 |1,5 | | |Ні несправності | |3 |1,2 | |Ні збігів |Недостатньо даних | |5 |2,3 | | |Ні несправності |.

После обміну результатами голосування, в вузлах може бути інформація, представлена таблицею 2.16.

Таблиця 2.16 |ПЭ|Данные |Можлива причина|Вывод |Консолідоване| |№ |голосування |несправності | |рішення | | |від ПЭ № |ПЭ № чи Лінк| | | | | |№ | | | | |1 |2 чи 3 | | | | | |2−1 чи 2−3 | | | | |2 | Ні | | | | | |несправності | | | |1 |3 | «сміття «| Несправний | | | | | |Лінк 2−3 | | | |5 | Ні | | | | | |несправності | | | | |1 |2 чи 3 | | | | | |2−1 чи 2−3 | | | | |2 |Ні несправності| | | |2 |3 | | Несправний | | | | | «сміття «|Лінк 2−3 | | | |5 | Ні | |Несправний Лінк | | | |несправності | |2−3 | | |1 | | | | | | | «сміття «| | | | |2 | | | | | | | «сміття «| | | |3 |3 |Недостатньо | Несправний Лінк| | | | |даних |2−3 | | | |5 | Ні | | | | | |несправності | | | | |1 |2 чи 3 | | | | | |2−1 чи 2−3 | | | | |2 | Ні | | | | | |несправності | | | |5 |3 | Недостатньо | Несправний | | | | |даних |Лінк 2−3 | | | |5 | Ні | | | | | |несправності | | |.

Анализ ПЭ1, ПЭ2 і ПЭ5 можливі причини несправності, показывает:

1. 1 Результати голосування від ПЭ2 підтверджують працездатність ПЭ1,.

ПЭ5, каналів 2−1 і 2−5.

2. 1 Результати голосування від ПЭ5 підтверджують працездатність ПЭ3,.

ПЭ2, каналів 3−5 і 2−5.

3. Дані ПЭ5 від ПЭ3 говорять про справності каналу зв’язку 3−5. Отже ПЭ1, ПЭ2 і ПЭ5 роблять висновок про несправності каналу 2−3, маскуючи несправності за даними від ПЭ1. Аналіз ПЭ3 можливі причини несправності, показывает:

1. 1 Результати голосування від ПЭ5 підтверджують працездатність ПЭ3,.

ПЭ2, каналів 3−5 і 2−5.

2. «Сміття» від ПЭ1 означатиме, що несправний ПЭ1 чи ПЭ2, чи канал 1−2, чи канал 2−3.

3. «Сміття» від ПЭ2 означатиме несправність ПЭ2 чи каналу 2−3. З умови ординарности потоку відмов, одночасна несправність ПЭ1 і ПЭ2 неможлива, як неможливо й поєднання 1−2 і 2−3. Отже, з пунктів 2 і трьох слід відмова або ПЭ2, або каналу 2−3. Пункт 1 спростовує відмова ПЭ2. Робиться висновок про відмову від каналу 2−3.

Конфігурація, зображена на рис. 2.6 в певною мірою критичною, бо я вживаю транзитна зв’язок через ПЭ2. Розглянемо відмова ПЭ2 у цій самій топології. У цьому, інтерфейс обміну такий, що ПЭ2 в разі фатального відмови не передасть транзитну інформацію (передасть «сміття»), інакше передасть її без изменений.

Через війну обміну результатами рахунки, в вузлах мережі можуть фіксуватися такі факти розбіжності, представлені у таблиці 2.17.

Таблиця 2.17 |№ ПЭ |Получены|Данные |Не збігаються з |Можлива причина: | | |дані |від |даними від ПЭ № |Несправність | | |від ПЭ № |ПЭ № | |ПЭ № чи Лінк | | | | | |№ | |1 Варіант |3,5 |3 |1, 5 | 2 чи 3 2−1 | |1 | | | |чи 2−3 | |1 Варіант |3,5 | | |Ні несправності | |2 | | | | | |2 Варіант |1,5 | | |"сміття" | |1 | | | | | |2 Варіант |1,5 |2 |1, 5 | 2 | |2 | | | |1−2, 1−5 | |3 Варіант |1,2 | |Ні збігів |Недостатньо даних | |1 | | | | | |3 Варіант |1,2 |2 |1, 3 | 2 | |2 | | | |2−3 | |5 |2,3 |2 |3, 5 | 2 | | | | | |2−5 |.

После обміну результатами голосування на залежність від ступеня відмови ПЭ2, в працездатних вузлах може бути інформація, представлена таблицею 2.18.

Таблиця 2.18 |ПЭ№ |Дані |Можлива причина|Вывод |Консолідований| | |голосов|неисправности | |ное рішення | | |ания от|ПЭ № чи Лінк| | | | |ПЭ № |№ | | | | |1 |2 чи 3 | | | | | |2−1 чи 2−3 | | | |1 Вариант|2 | «сміття «| | | |1 | | | | | | |3 | «сміття «| | | | |5 | 2 | | | | | |2−5 | | | | |1 |Ні несправності| Несправний | | | | | |ПЭ2 | | |1 Вариант|2 |2 | | | |2 | |1−2, 2−5 | | | | |3 |2 | | | | | |2−3 | | | | |5 |2 | | | | | |2−5 | | | | |1 | «сміття «| | | |3 Вариант|2 | «сміття «| | | |1 | | | | | | |3 |Недостатньо | | | | | |даних | | | | |5 |2 | |Несправний | | | |2−5 | |ПЭ2 | | |1 |Ні неисправности|Неисправен | | | | | |ПЭ2 | | |3 Вариант|2 | 2 | | | |2 | |1−2, 2−5 | | | | |3 | 2 | | | | | |2−3 | | | | |5 | 2 | | | | | |2−5 | | | | |1 | 2 чи 3 | | | | | |2−1 чи 2−3 | | | |5 Вариант|2 | «сміття «| | | |1 | | | | | | |3 |Недостатньо | | | | | |даних | | | | |5 |2 | | | | | |2−5 | | | | |1 |Ні несправності| | | |5 Вариант|2 |2 | Несправний | | |2 | |1−2, 2−5 |ПЭ2 | | | |3 |2 | | | | | |2−3 | | | | |5 |2 | | | | | |2−5 | | |.

Розглянемо процес прийняття рішень ПЭ1: Варіант 1: «Сміття» від ПЭ3 і такі ПЭ2 говорять про несправності ПЭ2 чи линка 2−1. Діагноз ПЭ5 підтверджує несправність ПЭ2. Отже кожна запис в ПЭ1 безпосередньо чи опосередковано говорить про несправності ПЭ2 або його зв’язків. З огляду на ординарности потоку відмов приймають рішення про відмову від ПЭ2. Варіант 2: Один суперечливий результат маскується трьома підтвердженнями несправності ПЭ2, оскільки одночасну відмову всіх лінків трактутся також як й відмова всього ПЭ2.

Аналогічно в ПЭ3 і ПЭ5 у разі виявляється мінімум два повідомлення про відмову від ПЭ2 або його зв’язків. Як відзначалося вища ймовірність відмови одночасно кількох каналів зв’язку значно коротші ймовірності відмови ПЭ, і внаслідок припущення про ординарности потоку відмов, роблять висновок про відмову від ПЭ2.

Розглянемо деградацію системи після відмови линка 2−3. Топологія системи представлена на рис. 2.7.

[pic].

Рис. 2.7. Топологія ЗС після відмови линка 2−3. Маршрутизатором було визначено нові статичні маршрути, для зв’язку ПЭ1 і ПЭ3 і ПЭ2 через ПЭ5. У разі відмова ПЭ3 чи линка 3−5 можна знайти легко з допомогою ПЭ5. Аналогічно виявляються відмови ПЭ1 і ПЭ2.

Розглянемо відмова ПЭ5. Через війну обміну результатами рахунки, в вузлах мережі можуть фіксуватися такі факти розбіжності, представлені у таблиці 2.19.

Таблиця 2.19 |№ ПЭ |Получены|Данные |Не збігаються з |Можлива причина: | | |дані |від |даними від ПЭ № |Несправність | | |від ПЭ № |ПЭ № | |ПЭ № чи Лінк | | | | | |№ | |1 Варіант |3,5 |5 |1, 3 |5 | |1 | | | |1−5 | |1 Варіант |3,5 | |Ні збігів | Недостатньо даних| |2 | | | | | |2 |1,5 |5 |1, 2 |5 | | | | | |2−5 | |3 Варіант |1,2 | | |Ні несправності | |1 | | | | | |3 Варіант |1,2 | |Ні збігів |Недостатньо даних | |2 | | | | | |5 Варіант |2,3 |5 |2, 3 |5 | |1 | | | |1−5, 3−5 | |5 Варіант |2,3 | | |"сміття" | |2 | | | | |.

После обміну результатами голосування на залежність від ступеня відмови ПЭ5, в працездатних вузлах може бути інформація, представлена таблицею 2.20.

Таблиця 2.20 |ПЭ№ |Дані |Можлива причина|Вывод |Консолідований| | |голосова|неисправности | |ное рішення | | |ния від |ПЭ № чи Лінк| | | | |ПЭ № |№ | | | | |1 | Недостатньо | | | | | |даних | | | |1 Вариант|2 |5 | | | |1 | |2−5 | | | | |3 | «сміття «| | | | |5 | «сміття «| | | | |1 |5 | Несправний | | | | |1−5 |ПЭ5 | | |1 Вариант|2 |5 | | | |2 | |2−5 | | | | |3 |Ні несправності| | | | |5 |5 | | | | | |1−5, 3−5 | | | | |1 |Недостатньо | | | | | |даних | | | |2 Вариант|2 |5 | | | |1 | |2−5 | | | | |3 | «сміття «| | | | |5 | «сміття «| |Несправний | | | | | |ПЭ5 | | |1 |5 |Несправний | | | | |1−5 |ПЭ5 | | |2 Вариант|2 |5 | | | |2 | |2−5 | | | | |3 |Ні несправності| | | | |5 |5 | | | | | |1−5, 3−5 | | | | |1 | «сміття «| | | |3 Вариант|2 | «сміття «|Недостатньо | | |1 | | | | | | |3 |Недостатньо |даних | | | | |даних | | | | |5 | «сміття «| | | | |1 |5 | | | | | |1−5 | | | |3 Вариант|2 |5 | Несправний | | |2 | |2−5 |ПЭ5 | | | |3 |Ні несправності| | | | |5 |5 | | | | | |1−5, 3−5 | | |.

Аналіз працездатними вузлами причин відмови показывает:

1. За повної відмову ПЭ5:

. Аналіз ПЭ1 і ПЭ2: «сміття» від ПЭ3 і ПЭ5 говорить про несправності ПЭ5 чи каналу 1−5, а дані ПЭ2 однозначно говорять про відмову ПЭ5.

. Аналіз ПЭ3: «сміття» від ПЭ2, ПЭ3 і ПЭ5 говорить про несправності ПЭ5 чи каналу 3−5. У разі це не є важливо, оскільки результатами голосування ПЭ3 обмінятися ні з ким зможе. У разі цій ситуації ПЭ аналізує - скільки вузлів залишається у системі, окрім неї самого. Якщо більше двох, він самостійно припиняє видачу даних. 2. При відмову ПЭ5, зі збереженням здібності обміну, інформації щодо його діагностування вистачає з головою. Обмінявшись остаточними висновками ПЭ1 і ПЭ2 вирішили про відключенні ПЭ5. Після реконфигурации, маршрутизатор виявляє ізольованість ПЭ3 і посилає сигнал реконфигуратору про відключення ПЭ3.

Розглянемо тепер функціонування ЗС у складі трьох ПЭ. Нехай залишилися функціонувати ПЭ1, ПЭ2 і ПЭ5.

[pic].

Розглянемо відмова зв’язку 2−5. У результаті вузлах мережі фіксуються такі факти розбіжності результатів рахунки, представлені у таблиці 2.21.

Таблиця 2.21 |№ ПЭ |Отримано |Дані від |Не збігаються з |Можлива причина: | | |дані від |ПЭ № |даними від ПЭ № |Несправність | | |ПЭ № | | |ПЭ № чи Лінк | | | | | |№ | |1 |2,5 | | |Ні несправності | |2 |1,5 |5 |1, 2 |5 | | | | | |2−5 | |5 |1,2 |2 |1, 5 |2 | | | | | |2−5 |.

После обміну результатами голосування, в вузлах може бути інформація, представлена таблицею 2.22.

Таблиця 2.22 |ПЭ№ |Дані |Можлива причина|Вывод |Консолідований| | |голосова|неисправности | |ное рішення | | |ния від |ПЭ № чи Лінк| | | | |ПЭ № |№ | | | | |1 |Ні несправності| | | |1 |2 |5 |Несправний | | | | |2−5 |2−5 | | | |5 |2 | | | | | |2−5 | | | | |1 |Ні несправності| | | |2 |2 |5 |Несправний |Несправний | | | |2−5 |2−5 |2−5 | | |5 | «сміття «| | | | |1 |Ні несправності| | | |5 |2 | «сміття «|Несправний | | | | | |2−5 | | | |5 |2 | | | | | |2−5 | | |.

Анализ ПЭ1 попередньої інформації підтверджує відмова линка 2−5, оскільки справність ПЭ2 і ПЭ5 підтверджується інформацією від ПЭ1. Аналіз ПЭ2 і ПЭ3 що надійшла інформації говорить про несправності линка 2−5, через те, що ПЭ1 підтверджує правильність результатів ПЭ2 і ПЭ5.

Розглянемо подальше функціонування системи (рис. 2.9).

[pic].

Відмова ПЭ5 і ПЭ2 діагностується як і засвідчили вище, оскільки не порушується зв’язність між двома ПЭ. Відмова зв’язку 1−5 сприймається ПЭ1 і ПЭ2, як відмова ПЭ5. Аналогічно, відмова зв’язку 1−2 рівнозначний відмови ПЭ2.

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

У цьому варіанті може виникнути ситуація, коли ПЭ2 у відмові линка 1−2 приймають рішення про відмову від ПЭ1 і ГЗК стає старшим елементом, як ПЭ із меншим номером. Заодно він приймають рішення про відключення ПЭ5. Одночасно ПЭ1 і ПЭ5 вирішили про відмову від ПЭ2 й у своє чергу виключають його із поточного конфігурації. Тоді настає ситуація, коли одночасно для виходу подаються два, можливо, й різних варіанта. Щоб уникнути такої ситуації, необхідні спецальные апаратні чи програмноапаратні кошти, які у рамках даної роботи рассматриваются.

Якщо зробити припущення щодо равновероятности відмов у системі, зображеною на рис. 2.9, то ймовірність відмови линка 2−1, яка веде до невизначеності у системі, дорівнює 0.2. Однак у реальних ЗС ймовірність відмови каналу зв’язку вважається величиною значно меншою, аніж ймовірність відмови ПЭ цей самий період времени.

Відмова каналу 1−5 не призведе до невизначеності. ПЭ5 стане старшим у разі і буде відключений. Відмова ПЭ1 теж призведе до невизначеності, управління візьме він ПЭ2.

На передостанньому етапі деградації системи у системі залишається 2 справних ПЭ, з'єднаних одним каналом зв’язку. При першому плані в ролі діагностичної інформації виходять ознаки исправности/неисправности, формовані різними програмноапаратними засобами контролю, такі як функціональний контроль обчислень з допомогою спеціальних контрольних операторів, контроль вхідний інформації з спеціальним ознаками і контрольним сумам, контроль вихідний інформації з квитанції від приймача і тд.

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

2.5.2. Методика аналізу отказов.

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

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

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

ПЭ з номерами (m-1) mod N і (m-2) mod N.. При розбіжності даних при елементарної перевірці результатів рахунки, отримані з використанням транзитної передачі, під сумнів ставляться весь ланцюжок, задіяна під час передачі.. При розбіжності жодного результату рахунки під сумнів ставляться все брали участь у обміні ПЭ та зв’язку.. Розбіжність контрольної суми чи тайм-аут прийому даних сприймається як збій ПЭ чи каналу зв’язку ПЭ.. Відсутність квитанції сприймається як збій ПЭ чи каналу зв’язку ПЭ.. Зрадливий код квитанції сприймається як збій каналу зв’язку ПЭ.

Для ухвалення рішення про відмову (збої) тієї чи іншої елемента ЗС (ПЭ, каналу зв’язку) по набору висновків від кожної вузла мережі, було запропоновано наступний евристичний алгоритм, і під час умови про ординарности потоку отказов:

1. Складається матриця стану ЗС, яка размерностью ідентична модифікованої матриці связности ПЭ, але з головною діагоналі перебувають даних про ПЭ, а осередках матриці - про каналах связи.

2. Матриця стану ЗС инициализируется единицами.

3. Обмінявшись попередніми результатами голосування, у каждого.

ПЭ виявляється результатів голосування від усіх ПЭ ВР і діагностична інформація від модуля коммуникации.

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

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

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

7. Якщо така значення є, то відповідний елемент визнається несправним, інакше приймають рішення про відсутність оказов. Цей алгоритм створено отож у матриці станів після завершення, бракуватиме більше двох мінімальних негативних значень, причому ці значення ні належати однаковим функціональним елементам (тобто одночасно 2-му ПЭ чи 2-му різноманітних каналах зв’язку). Що стосується присутності однакових мінімальних значень, робиться вибір на користь каналу связи.

Проілюструємо його за прикладі ЗС, зображеною на рис. 2.7, і ПЭ5 у цій конфігурації. Обмін для голосування на мережі здійснюється наступним образом:

ПЭ1->ПЭ2, ПЭ3;

ПЭ2->ПЭ3, ПЭ5;

ПЭ3->ПЭ5, ПЭ1;

ПЭ5->ПЭ1, ПЭ2. Обмін результатами голосування до ухвалення консолідованого рішення — по всієї ЗС. Наведемо логіку аналізу несправності з погляду обраної эвристики.

Варіант 1: ПЭ5 продовжує функціонування, міна й голосування, але функціональна завдання виконується не так. Отже, сигналів про несправності від модулів комунікації ПЭ мережі надходити не будет.

У таблиці 2.23 представлені записі від всіх ПЭ, розшифровані в відповідність до обраної логикой.

Таблиця 2.23.

|ПЭ№ |Дані |Інформація від |Можлива причина |Висновок | | |голосования|модуля |несправності | | | |від ПЭ № |комунікації |ПЭ № чи Лінк | | | | | |№ | | | |1 |Ні |5 | | | | | |1−5 | | |1 |2 |Ні |5 |Несправний | | | | |2−5 |ПЭ5 | | |3 |Ні |Ні несправності | | | |5 |Ні |5 | | | | | |1−5, 3−5 | | | |1 |Ні |5 | | | | | |1−5 | | |2 |2 |Ні |5 |Несправний | | | | |2−5 |ПЭ5 | | |3 |Ні |Ні несправності | | | |5 |Ні |5 | | | | | |1−5, 3−5 | | | |1 |Ні |5 | | | | | |1−5 | | |3 |2 |Ні |5 | Несправний | | | | |2−5 |ПЭ5 | | |3 |Ні |Ні несправності | | | |5 |Ні |5 | | | | | |1−5, 3−5 | |.

Составим матрицю стану ЗС, отриману у ПЭ1 (див. таблицю 2.24).

Таблиця 2.24.

|№/№ |1 |2 |3 |5 | |1 |2 |1 |2 |-1 | |2 |1 |2 |2 |0 | |3 |2 |2 |2 |0 | |5 |-1 |0 |0 |-2 |.

Отже, роблять висновок про несправності ПЭ5. Аналогічний висновок, судячи з таблиці 1, роблять ПЭ1 і ПЭ2.

Варіант 2: Настав фатальний відмова ПЭ5, коли припиняє обмін з ЗС, або видає неінформативні данные.

Таблиця 2.25 містить розшифровку записів всіх ПЭ у тому случае.

Таблиця 2.25.

|ПЭ№ |Дані |Інформація від |Можлива причина |Висновок | | |голосования|модуля |несправності | | | |від ПЭ № |комунікації |ПЭ № чи Лінк № | | | |1 |Ні | 1 чи 3 чи 5 | | | | | |3−5 чи 1−5 | | |1 |2 |Ні |5 |Несправний | | | | |2−5 |ПЭ5 | | |3 |Тайм-аут чи | 3 чи 5 | | | | |КС |3−5 чи 1−5 | | | |5 |Тайм-аут чи |5 | | | | |КС |1−5 | | | |1 |Ні | 1 чи 3 чи 5 | | | | | |3−5 чи 1−5 | | |2 |2 |Ні |5 |Несправний | | | | |2−5 |ПЭ5 | | |3 |Тайм-аут чи | 3 чи 5 | | | | |КС |3−5 чи 2−5 | | | |5 |Тайм-аут чи |5 | | | | |КС |2−5 | | | |1 |Тайм-аут чи |1 чи 5 3−5 чи | | | | |КС |1−5 | | |3 |2 |Тайм-аут чи |2 чи 5 |Несправний | | | |КС |3−5 чи 2−5 |3−5 | | |3 |Ні |1 чи 2 чи 3 чи 5 | | | | | |3−5 чи 1−5 чи 2−5 | | | |5 |Тайм-аут чи |5 | | | | |КС |3−5 | |.

Таким чином :

. У ПЭ1 виявляється 4 голоси проти ПЭ5 і трьох голоси проти каналу зв’язку 1−5. Рішення — відмова ПЭ5.

. У ПЭ2 виявляється 4 голоси проти ПЭ5 і трьох голоси проти каналу зв’язку 2−5. Рішення — відмова ПЭ5.

. У ПЭ3 виявляється 4 голоси проти ПЭ5 і 4 голоси проти каналу зв’язку 3−5. Рішення — відмова каналу зв’язку 3−5. Ситуація, аналогічна приходу в ПЭ3, виникає, коли в ПЭ залишається лише одне канал зв’язку. Після його втрати ПЭ стає ізольованим і отключается.

2.6. Оцінка надежностных характеристик отказоустойчивой ВС.

Обрана концепція побудови спеціалізованої розподіленої ОС реального часу дозволить однорідної системі функціонувати у разі виникнення N -1 відмови ПЭ в системе.

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

Будемо припускати, що потік відмов у кожному вузлі системи є найпростішим, тобто. стаціонарним, ординарним і наслідки, з показовим законом розподілу довжини інтервалу між сусідніми подіями (отказами):

[pic] (1) де: [pic] - можливість, що за t станеться рівно «K» подій (отказов);

(- параметр потоку, інтенсивність потоку отказов;

T0 — математичне очікування довжини інтервалу між сусідніми подіями — середнє час напрацювання на отказ;

P0(t) — можливість, що за t не станеться жодного події (відмови), ймовірність безвідмовною работы.

Означимо через [pic]- середнє час напрацювання відмовитися одного вузла системи. Для отказоустойчивых систем під станом відмови усвідомимо стан фатального відмови, тобто. для ОС-N (m), цей стан, у якому стався відмова більш як «m» вузлів системи (m+1, m+2, …).

У довільний час t ми можемо застати систему у одному з двох состояний:

— працездатному, з імовірністю R (t),.

— може фатального відмови, з імовірністю P (t).

Якщо на систему з урахуванням станів працездатності кожного з N її елементів (вузлів), то довільний час t ми можемо застати систему у одному з 2N станів (див. рис. 2.10).

[pic].

Рис 2.10. Стану N-узловой системы.

Якщо експортувати відповідність кожному вузлу системи розряд двоичного N разрядного числа (0 — вузол працює, 1 — вузол відмовив), то кожній такій стану системи можна експортувати відповідність свій номер, рівний значенням введеного двоичного N разрядного числа і кожній такій стану відповідає деяка ймовірність перебування системи в останній момент часу t в цьому состоянии.

Усі 2N станів системи може бути розбитий сталася на кілька груп станів, кожна з яких відрізняється з інших кількістю відмовили вузлів. Нульова група (група з номером 0) містить одне стан ([pic]= 1), в якому всі вузли системи нині напівживі працездатності, тобто. є рівно 0 відмовили елементів. Перша група включає у собі все стану, у яких відмовив рівно один вузол (двоичные номери цих станів містять лише один одиницю в N розрядному двоичном коді). Кількість станів, які входять у першу групу одно [pic]=N — числу поєднань з N по 1 ([pic]).

Другу групу становлять стану, яких у системі є два відмовили елемента, таких станів рівно [pic] і т.д.

У i-ю групу охоплюють усі стану, яких у системі відмовило рівно і вузлів, таких станів [pic].

Передостання (N-1) -я група включає у собі [pic]состояний, тобто. N состояний.

Остання N-я група містить одне стан ([pic]=1), у якому відмовили все N вузлів системы.

Т.к. в довільний час система може знаходиться лише в одному із усіх 2N станів, то ці події є несовместными. Тому ймовірність перебування системи у будь-якому з станів, які стосуються одній з згаданих вище груп можна як суму ймовірностей перебування системи переважають у всіх станах цієї групи. Тим паче, що в кожної i-го групи їхні капітали характеризуються наявністю рівно і відмовили вузлів, то ймовірності всім станів однієї групи рівні між собою, поэтому:

[pic] (2) де: Pi — ймовірність перебування системи (в довільний момент часу t) у будь-якій з станів, віднесених до i-го группе;

[pic]- ймовірність перебування системи щодо одного конкретному стані, перенесеному до i-го группе.

Усі стану, віднесені до i-го групі характеризуються наявністю в системі (в довільний час t) рівно і відмовили вузлів і рівно (N-i) справних узлов.

Відповідно до запровадженим вище припущенням про найпростішому потоці відмов (1) ймовірність [pic]можно оцінити наступним образом:

[pic] (3) де перша дужка відповідає з того що (N-i) елементів перебувають у працездатному стані, а друга з того що і елементів відмовили. Підставляючи (3) в (2) можна було одержати вираз для обчислення ймовірностей Pi.

Вочевидь, що з системи ОС-N (m) (N вузловий системи з рангом отказоустойчивости m) їхні капітали системи, що входять до групи 0,1,2,…m ставляться до тих станам, у яких система нормально функціонує. У цьому разі ймовірність R (t) можна оцінити наступним образом:

[pic] (4).

Можливість фатального відмови системи ОС — N (m) можна оцінити як суму ймовірностей перебування системи в станах, віднесених їх до груп m+1, m+2, … N-1, N:

[pic] (5).

Критерієм правильності запропонованої методики є виконання умови R (t)+P (t)=1 для будь-яких систем і будь-яких значень t.

Об'єднуючи висловлювання (2) (3) (4) і (5), одержимо остаточні формули для обчислення ймовірностей безвідмовної роботи — RN (m)(t) і фатального відмови -PN (m)(t) систем ОС-N (m) для довільного моменту часу t:

[pic] (6).

Для практичних розрахунків доцільно використовувати з цих формул, саме ту, що має (залежно від значень N і m) менше суммируемых членів, тобто. при [pic] доцільно використовувати формулу PN (m)(t) інакше — формулу RN (m)(t). У цьому другий параметр виходить з співвідношення RN (m)(t)+PN (m)(t)=1.

Отже для систем типу N (N-1) висловлювання (6) приймають вид:

[pic] (6а).

Розглянемо тепер визначення середнього часу напрацювання відмовитися T0N (m) отказоустойчивых систем ОС-N (m).

Невосстанавливаемая N-узловая отказоустойчивая система m-го рангу (ОСN (m)) то, можливо представлена марковської моделлю з кількістю станів (N+1):

[pic] де: 0 — стан, у якому жоден вузол системи не отказал;

1 — стан (об'єднує групу з [pic] станів системи — див. рис. 2.4), у якому відмовив рівно 1 узел;

2 — стан (об'єднує групу з [pic] станів системи), в якому відмовили рівно 2 вузла; m — стан (об'єднує групу з [pic] станів системи), в якому відмовило рівно m вузлів і т.д.

Перехід вже з стану до іншого (принаймні поступової деградації системи) визначається інтенсивністю потоку відмов, які впливають на систему, розташовану за відповідному стані. Інтенсивність потоку відмов, які впливають на систему, розташовану за 1-му стані, визначається кількістю працездатних вузлів (N-i). Т.а. середнє час перебування системи в 1-му стані визначається наступним образом:

[pic] (7) де: [pic]- інтенсивність потоку відмов одного вузла системы.

Фатальний відмова системи ОС-N (m) можливе лише під час переходу системи зі стану m до стану m+1, тому середнє час напрацювання системи ОС-N (m) відмовитися одно середньому часу послідовного перебування системи в станах 0,1,2…m:

[pic] (8).

Вислів (8) отримано виходячи з одного фундаментального властивості показового закону розподілу: «якщо проміжок часу, розподілений по показовому закону, вже тривав кілька днів t, то це зовсім впливає на закон розподілу решти проміжку: він буде так ж, як і закон розподілу всього промежутка"[12]. Це властивість показового закону є, сутнісно, жодну з формулювань для «відсутності післядії», що є основним властивістю найпростішого потоку, прийнятого нами як модель потоку отказов.

Якщо запровадити обозначение:

[pic] (8а) цей «коефіцієнт надійності» відповідно до (8) представляє собою ставлення T0N (m) до T0y:

[pic], і, скільки раз проти T0y — середнім часом напрацювання відмовитися одного вузла, змінилося середнє час напрацювання відмовитися системи ОС-N (m) в целом.

Використовуючи формули (6-а) і (8а) можна робити оцінку надежностных характеристик отказоустойчивых систем типу N (N-1). Приймемо середнє час напрацювання відмовитися вузла [pic]=105 годин. У таблиці 2.26 наведено характеристики, розраховані по формулам (6-а) і (8а).

Таблиця 2.26.

Харктиристики отказоустойчивых систем типу N (N-1).

|№№ |N (N-1) — тип системи |1(0) |3(2) |4(3) |5(4) |6(5) |7(6) |8(7) |9(8) |10(9) | |п/п|/ Характеристика | | | | | | | | | | |1 | |4 години |4?10−5 |6,4?10−14 |2,56?10−18|1,0?10−2|4,1?10−2|1,6?10−3|6,5?10−3|2,62?10-|1,05?10| | | | | | | |2 |7 |1 |6 |40 |-44 | |2 | |24 години |2.4?10-|1,38?10−11|3,31?10−15|8,0?10−1|1,9?10−2|4,6?10−2|1,1?10−2|2,64?10-|6,3?10-| | | | |4 | | |9 |2 |6 |9 |33 |37 | |3 | |1год= |0.084 |5,91?10−4 |4,96?10−5 |4,2?10−6|3,5?10−7|2,9?10−8|2,46?10-|2?10−10 |1,7?10-| | | | | | | | | | |9 | |11 | | | |8766 годину| | | | | | | | | | |4 | |5лет= |0.355 |0,047 |1,586?10−2|5,6?10−3|2?10−3 |7,1?10−4|2,5?10−4|8,9?10−5|3,16?10| | | | | | | | | | | | |-5 | | | |43 830 | | | | | | | | | | | | |годину | | | | | | | | | | |5 | |10лет= |0.584 |0,2 |0,116 |0,068 |0,04 |0,023 |0,0135 |7,9?10−3|4,6?10-| | | | | | | | | | | | |3 | | | |87 660час| | | | | | | | | | |6 | |11,4 г.= |0.632 |0,252 |0,16 |0,1 |0,064 |0,04 |0,025 |0,016 |0,01 | | | |105час | | | | | | | | | | |7 | |15лет= |0.73 |0,391 |0,286 |0,21 |0,153 |0,11 |0,082 |0,06 |0,044 | | | |131 490ча| | | | | | | | | | | | |з | | | | | | | | | | |8 |KN (N-1) |1 |1,83 |2,08 |2,28 |2,45 |2,59 |2,72 |2,82 |2,92 |.

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

[pic].

Рис. 2.10. Коефіцієнт надежности.

[pic].

Рис 2.11. Можливість відмови ЗС типу N (N-1) за 10 лет.

Аналіз кривих показує, що середнє час безвідмовної роботи збільшується в 2−3 разу порівняно з середнім часом безвідмовною роботи одного ПЭ при нарощуванні обчислювальних ресурсів у 5−7 разів, і далі стабілізується зростає незначно. Можливість відмови систем з рангом отказоустойчивости N (N-1) різко зменшується під час розгляду ЗС типу 5(4) — 7(6) і далі її зниження незначительно.

Отже, при побудові отказоустойчивых обчислювальних систем рекомендується вибирати системи з характеристиками 5(4) — 7(6), з урахуванням обмеження маси, енергоспоживання та інших. характеристик.

2.7. Висновки до глави 2.

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

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

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

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

Наприкінці зроблена оцінка надежностных характеристик ВР із рангом отказоустйчивости N (N-1) і характеристики систем 1(0) — 10(9). Аналіз характеристик виявив значительне збільшення часу безвідмовної роботи системи зі збільшенням числа ПЭ і зменшення ймовірності відмови всієї системи. Наприклад, вроятность відмови системи 5(4) за 10 років із часом безвідмовної роботи одного ПЭ 10 000 годин становила 0,068, що менше ймовірності відмови одного ПЭ за ж період 8,5 раз. З цих результатів було зроблено рекомендації за вибором типу ЗС у її проектировании.

3. Програмне забезпечення моделі отказоустойчивой ВС.

Основними завданнями розробки програмної моделі отказоустойчивой ЗС, функціонуючої під керівництвом розподіленої ОСРВ, стали следующие:

1. Реалізувати аппаратно-независимые модулі забезпечення отказоустойчивости ОСРВ.

2. Моделювати ЗС будь-який топології (3−10 ПЭ).

3. Можливість забезпечити логіку перевірки модулів ОСРВ з допомогою команд оператора.

4. Забезпечити роботу моделі у умовах «м'якого» реального времени.

Отже, програмне забезпечення розбили на дві части:

1. ПО вузла ЗС Proc.

2. ПО підсистеми перевірки Host.

3.1 Програмне забезпечення моделі вузла ВС.

Структура програмного забезпечення моделі вузла ЗС представлена на рис 3.1. Загалом вигляді функціонування ПО вузла ЗС здійснюється за графу управління (циклограмме), представленої на рис. 6.3 технологічної частини, а логіка роботи докладно описано на главі 2.

Задля реалізації моделі було обрано ОС Windows 98/2000, бо в цьому етапі не ставилося завдання тестування ПО ЗС у умовах жорсткого реального часу, а семантично механізми забезпечення многопроцессности, синхронізації, вводу-виводу практично ідентичні механізмам більшості ОСРВ.

[pic].

Рис. 3.1. Взаємодія модулів вузла ВС.

ПО вузла ЗС розбите на модулі, структура яких представленій у таблиці 3.1. Опис функцій, що реалізують дані модулі, представлено в таблицях 3.2, 3.3, 3.4, 3.5.

Таблиця 3.1.

Опис складових модулів текстового редактора |Модуль |Опис | |Main.cpp |Центральний модуль. Запуск ініціалізації системи. Запуск| | |маршрутизатора. Запуск модуля эмуляции каналів зв’язку. | | |Запуск ФЗ. | |Router.cpp |Функції маршрутизатора | |Commun.cpp |Функції модуля комунікації | |Vote.cpp |Функції голосування та аналізатора відмов. | |task.cpp |Функціональна завдання. |.

Таблиця 3.2.

Функції, реалізують маршрутизатор

|Ім'я |Опис | |void router () |Формування таблиць розсилки методом хвилі | |void GetRoute (int |Пошук всіх найкоротших за кількістю транзитних | |CpuNum) |передач шляхів в графі ЗС до вузла CpuNum. |.

Таблиця 3.3.

Функції, реалізують модуль коммуникации.

|Ім'я |Опис | |int InitLinkEmul (const|Инициализация модуля эмуляции каналів зв’язку з | |char *IniFile) |файлу ініціалізації IniFile, виділення буферів | | |прийому інформації кожному за каналу, створення | | |і поєднання каналів зв’язку (неіменовані | | |канали чи сокеты). | | |Повертає 0 при успішному ході, -1 — у разі | | |помилки у файлі IniFile. | |void FinishLinkEmul |Завершення роботи модуля эмуляции каналів | |(void) |зв'язку. | |static SOCKET |Створення клієнтського сокета номером Port і | |ConnectServerSocket |з'єднання його з сервером. | |(const char *ServName, | | |int Port) | | |static SOCKET |Створення серверного сокета номером Port і | |CreateServerSocket |очікування з'єднання з клієнтом. | |(SOCKET *PrimSock, int | | |Port) | | |static int |Створення серверного неіменованого каналу з | |CreatePipeServer (int |номером Port. По покажчикам pipeRead і | |Port, HANDLE *pipeRead,|pipeWrite повертаються файлові дескриптори на | |HANDLE *pipeWrite) |читання і запис. | |static int |Створення клієнтського неіменованого каналу з | |CreatePipeClient (int |номером Port. По покажчикам pipeRead і | |Port, HANDLE *pipeRead,|pipeWrite повертаються файлові дескриптори на | |HANDLE *pipeWrite) |читання і запис. | |int LinkOut (int Link, |Посилка даних із заданому каналу зв’язку Link, | |void *Addr, int Length)|начиная з адреси Addr, Length байт з прийомом | | |квитанції від адресата. | |int LinkIn (int Link, |Прийом даних із заданому каналу зв’язку Link, в | |void *Addr, int Length)|буфер починаючи з адреси Addr, Length байт з | | |контролем цілісності пакета і відправкою | | |квитанції. | |int Receive (int Chan, |Вибірка даних із канального буфера Chan, | |int From, void |які прийшли від ПЭ From, починаючи з адреси Addr, | |*DataAddr, int |Length байт. | |DataLength) | | |int Send (int Chan, |Посилка даних із каналу Chan, починаючи з адреси| |void *DataAddr, int |DataAddr, довжиною DataLength байт. | |DataLength) | | |static DWORD WINAPI |Завдання прослуховування каналу зв’язку lpvThreadParm| |LinkThreadFunc (LPVOID |в фоновому режимі, розшифровка заголовка пакета,| |lpvThreadParm) |прийом інформаційних частин посилки, запис в | | |канальний буфер, видача сигналу прихід | | |даних. |.

Таблиця 3.4.

Функції, реалізують модуль голосування та аналізатора отказов.

|Ім'я |Опис | |void |Переинициализация буферів голосування | |InitializeVoteBuffers ()| | |void RestoreCpuFault () |Скидання інформації про накопичених відмовах ПЭ | |void RestoreLinkFault ()|Сброс інформації про накопичених відмовах каналів | | |зв'язків | |int compare (struct |Провести елементарну перевірку (порівняння) | |BUFFER b1, struct BUFFER|буферов функціональної інформації | |b2) | | |int TrippleFault () |Визначення збою однієї й тієї ж елемента ЗС | | |протягом трьох циклів. | |void consolidate () |Функція аналізу відмов, прийняття | | |консолідованого рішення, активізації | | |реконфигуратора. | |void VoteThread () |Завдання голосування, яка активізується по | | |заповнення канальних буферів, активизирующая | | |обмін у мережі результатами голосування та | | |передає управління аналізатору відмов. |.

Таблиця 3.5.

Функції, реалізують реконфигуратор

|Ім'я |Опис | |static int |Перевірка ізольованості ПЭ Cpu. | |CheckCpuLinks (int Cpu)| | |void reconfig (struct |Процедура реконфигурации, шляхом зміни | |SYSTEM* M) |системних таблиць за інформацією про відмову від. | | |Активізація маршрутизатора для перебудови | | |системних таблиць. |.

Таблиця 3.6.

Функції, реалізують функціональну задачу.

|Ім'я |Опис | |void TaskLoop () |Функція виконання ФЗ (поки що ФЗ — | | |набір послідовних найпростіших операторів) | | |за інформацією від об'єкта управління. | | |Завершується відсиланням результатів для | | |голосування іншим ПЭ і передачею управління | | |завданням прослуховування і голосування. |.

Дополнительные функції, щоб забезпечити моделювання відмов у межах свого ПЭ, представлені у таблиці 3.7.

Таблиця 3.7.

Функції, реалізують моделювання отказа.

|Ім'я |Опис | |void KillCpu (int |type=1 — фатальний відмова ПЭ, припинення всіх | |Cpu, int type) |канальних потоків і ФЗ. | | |type=0 — відмова ФЗ, внесення спотворень при | | |обчисленні ФЗ. | |void KillLink (int |Завершує відповідний канальний потік, в | |Link, int type) |разі фатального відмови (type=0), чи дає | | |вказівку модулю комунікації відсилати помилкові | | |пакети (type=1). |.

Диспетчеризация процесів в ПЭ відбувається лише на рівні ОС, передача управління твориться з допомогою таких механізмів, як семафори і події. Під час очікування прийом управління завдання перебувають у сплячки, майже займаючи процесорного часу. Процес передачі управління наведено на рис. 3.2. При этом:

Процес 1: Функціональна задача;

Процес 2: Прослуховування каналу зв’язки Польщі з ОУ;

Процес 3: Процес голосування та аналізу отказов;

Процес 4: Реконфигурация;

Процес 5: Відправлення узгоджених данных;

Процес 6. N+6: Прослуховування N каналів зв’язки Польщі з ПЭ ВС;

[pic].

Рис. 3.2. Диспетчеризація процессов.

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

3.2 Програмне забезпечення підсистеми проверки Данный модуль покликаний забезпечити такі функции:

. Відображення поточної топологічної інформації ВС.

. Відображення обчислювального процесу у ВС.

. Можливість моделювання різних відмов ЗС. Задля більшої зручного інтерфейсу, додаток було зроблено на вигляді діалогового вікна з допомогою бібліотеки класів Windows MFC (Microsoft Foundation Classes). [pic].

Рис. 3.3. Діалогове вікно програми Host.

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

Таблиця 3.6.

Призначення і функції елементів диалога.

|Елемент |Опис | |Панель «Відмова |Містить три пов’язаних елемента: | |линка» | | | |Перемикачі (Radio Group) завдання виду відмови линка, | | |у своїй «Фатальний відмова» означає повне припинення | | |передачі, а «Некоректна передача» — | | |спотворення переданих пакетів. | | |Поля «ПЭ» і «Лінк» задають номер ПЭ і номер каналу зв’язку| | |для моделювання відмови. | | |Кнопка «Поставити» активізує передачу керуючої | | |інформації заданому ПЭ. | |Панель «Відмова |Містить два пов’язаних елемента: | |ПЭ» |Перемикачі завдання виду відмови ПЭ, у своїй | | |"Фатальний відмова" означає повне припинення | | |функціонування (наприклад зависання), а «Відмова ФЗ» — | | |неправильний розрахунок ФЗ, зі збереженням функцій обміну і | | |голосування. | | |Поле «ПЭ» задає номер ПЭ для моделювання відмови. | | |Кнопка «Поставити» активізує передачу керуючої | | |інформації заданому ПЭ. | |Поле виведення |Забезпечує відображення поточної топологічної | |(Rich Edit) |інформацією вигляді модифікованої матриці связности | |"Топологія" |(текстовий вид), оновлення кожному такті роботи | | |ЗС. | |Поле виведення |Забезпечує висновок в текстовому чи графічному вигляді | |"Процес" |узгоджених результатів рахунки ФЗ. | |Кнопко «ПУСК» |По натискання забезпечує створення конфігураційних | | |файлів кожному за ПЭ, запуск процесів, моделюючих | | |ЗС, зв’язування каналів в зв’язку зі кожним ПЭ та виведення з | | |сплячки канальних потоків прослуховування. | |Кнопка «Вихід» |Забезпечує звільнення пам’яті, знищення потоків | | |виконання, завершення програми. |.

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

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

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

4. Портирование ОСРВ на платформу TMS320C30.

Під портированием (від анг. porting) розуміється зміна програмного забезпечення для функціонування услвиях різних архітектур процессорных элементов.

4.1 Основні характиристики і науковотехнологічна галузь застосування процесора TMS320C30.

Унивеpсальность і pабота в pеальном масштабі вpемени пpоцессоpов сімейства TMS320 використовувати в шиpоком кpуге pазpаботок, таких как:

ЦГЗ СПІЛЬНОГО НАЗНАЧЕНИЯ:

. цифpовая фильтpация;

. свертка;

. коppеляция;

. пpеобpазование Гильбеpта;

. быстpое пpеобpазование Фуpье;

. адаптивна фильтpация і др.

ІНСТРУМЕНТАЛЬНІ ЗАСОБИ :

. спектpальный анализ;

. генеpиpование функций;

. сейсмічна обpаботка;

. аналіз перехідних процессов;

. цифpовая фильтpация і др.

ВІЙСЬКОВА ТЕХНІКА, управляючі системи та др.

. секpетная связь;

. обpаботка сигналів pадаpа;

. навигация;

. упpавление pакетами;

. автоматичні системы;

. бортові системи та др.

Поддеpжка мов високого уpовня легко pеализуется благодаpя використанню заснованої на pегистpах аpхитектуpы, великому адpесному пpостpанству, потужної системі адpесации, гнучкому набоpу команд і поддеpжке аpифметики з плаваючою точкой.

Нижче пеpечислены основні параметри TMS320C30:. 60 нс вpемя виконання однотактной команды.

— 33.3 MFLOPS (мільйон операцій із плаваючою точкою в секунду).

— 16.7 MIPS (мільйон інструкцій в секунду). Блок ПЗУ 4К x 32 подвійного доступу без такту очікування. Два блоку ОЗУ 1К x 32 подвійного доступу без такту очікування. Кеш-пам'ять команд 64×32. 32-pазpядные слова даних, і команд, 24-pазpядный адpес. 40/32-бит плаваюча точка/целые числа умножитель і АЛУ. 32-pазpядный кільцевої сдвиговый pегистp. Вісім pегистpов pасшиpенной точності (аккумулятоpы). Два адpесных генеpатоpа з вісьома допоміжними pегистpами і двоє аpифметических блоку допоміжних pегистpов. Внутpикpистальный контpоллеp пpямого доступу на згадку про (DMA) для незалежних опеpаций ввода/вывода і центpального пpоцессоpного блоку. Целочисленные, з плаваючою точкою і логічні опеpации. Двохі тpехопеpандные команди. Паpаллельная pабота АЛУ і умножителя щодо одного такті. Можливість повтоpения блоків команд. Цикли з нульовими непродуктивними витратами і пеpеходы за цикл. Умовні переходи і повернення. Команди для поддеpжки мультипpоцессоpной pаботы. Два послідовних порту обмінюватись 8/16/32 — pазpядными повідомленнями. Два 32-pазpядных таймера. Два зовнішніх прапора загального призначення, чотири зовнішніх прерывания.

4.2 Огляд базових ОСРВ для платформи TMS320C30.

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

Операційна система SPOX.

SPOX підтримує кілька різних варіантів архітектур:. додаткові обчислювальні середовища для робочих станцій;. однорідні встраиваемые системи;. неоднорідні встраиваемые системи;. персональні комп’ютери з процесором Intel Pentium під управлением.

Microsoft Windows 95. Середовище SPOX складається з чотирьох основних компонентів (рис. 4.1):. ядро SPOX (SPOX-KNL) забезпечує вытесняющую пріоритетну многозадачность, високошвидкісну обробку переривань, розподіл пам’яті, використовувала різні механізми межзадачного обміну інформацією між і синхронізації, і навіть незалежний від пристроїв вхід-видобуток. Результатами тестування SPOX-KNL стали такі цифри: > Час захоплення семафори — 7.9 мкс; > Час перемикання завдань однакового пріоритету — 15 мкс; > Час реакцію переривання — 33 мкс; > Час завершення переривання — 1.4 мкс; > Затримка диспетчеризації (час витіснення завдання з великим пріоритетом завдання за меншим) — 12.24 мкс; > Час перемикання контексту — 7 мкс; > Мінімальний розмір системи 1532 слова.. модуль SPOX-LINK підтримує «прозоре» взаємодія між цільової платформою і хост-системой і дає доступом до основним ресурсів хостмашини, таких як консолі, файлові системи та мережі;. бібліотека (SPOX-MATH) містить понад 175 математичних функцій;. высокоуровневый отладчик SPOX-DBUG.

[pic].

Рис. 4.1. Структурна схема ОС SPOX.

Усі чотири підсистеми реалізовані як бібліотеки C-вызываемых переміщуваних модулів. У цьому системні функції SPOX підключаються до об'єктному коду докладання на етапі связывания.

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

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

4.3 Аппаратно-зависимые компоненти ОСРВ.

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

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

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

4.3.1. Модуль діагностики ПЭ.

Модуль діагностики, реалізований як набору функцій, повертають код помилки, покладено такі: 1. На етапі ініціалізації:. Тестування регістрів загального призначення процесора;. Перевірка правильності виконання арифметичних, логічних та інших. операцій;. Занесення в відповідну таблицю контрольних сум незмінних під час виконання програм областей пам’яті (виконуваний код, константи), розміщення що у пам’яті проводиться на етапі складання робочого коду відповідно до картою пам’яті; 2. Під час робочого циклу, тестування можна проводити і з перериванням обчислень функціональних завдань, і безпосередньо під час їхньої виконання, якщо передбачено процессорное час виконання цих тестів. У цьому може здійснюватися:. Тестування регістрів загального призначення;. Перевірка правильності виконання арифметичних, логічних та інших. операцій;. Обчислення контрольних сум зазначених областей пам’яті і зіставлення його з обчисленими на етапі инициализации.

4.3.1.1. Тестування регістрів загального назначения.

Цей тест виконується першим для перевірки регістрів підвищеної точності (R0-R7) та допоміжних регістрів (АR0-АR7). Тестування зводиться до перевірки регістрів на запись/чтение з памяти/в пам’ять і перевірці правильності переміщення даних із регістру в регістр. Тест розбивається на два етапу:. Перевірка допоміжних регістрів (целочисленные значення). Перевірка реалізована з такого алгоритму:

1. Форматувати дві целочисленные перемінні початковим і очікуваним значенням тестирования;

2. Завантажити початкова значення в регістри (АR0-АR7).

3. Виробити операцію складання отож у кожному наступному регістрі виявилася сума предыдущих.

4. Запис в стік модифікованих регистров.

5. Виробити операцію зсуву вліво вмісту стека на N розрядів відповідно до номером записаного регистра.

6. Записати дані з стека в регистры.

7. Виробити операцію складання отож у кожному наступному регістрі виявилася сума предыдущих.

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

Функція register_test реалізована мовою Асемблер відповідно до архітектурою і безконтактною системою команд TMS320C30.

4.3.1.2. Перевірка правильності виконання арифметичних, логічних та інших. операций.

Цей тест розділений втричі різних модуля. Спільно вони перевіряють такі числові операции:

1. Логічні, зрушення, циклічний сдвиг.

2. Операції з плаваючою коми, виконані над одним значенням відповідні паралельні команды.

3. Операції з плаваючою коми і целочисленные, виконують складання, віднімання, і множення відповідні паралельні команды.

У тестах перевіряються команди, перелічені в Таблиці 4.1.

Таблиця 4.1.

Перелік тестируемых команд.

| Тест |Команди | |1 |2 | |Тест 1|ROL — циклічний зрушення вліво, | | |ROLC — циклічний зрушення вліво через перенесення, | | |ROR — циклічний зрушення вправо, | | |RORC — циклічний зрушення вправо через перенесення, | | |AND3 || STI — поразрядное логічне І зі збереженням, | | |LSH3 || STI — логічний зрушення зі збереженням, | | |NOT || STI — доповнення зі збереженням, | | |OR3 || STI — поразрядное логічне АБО зі збереженням, | | |XOR3 || STI — поразрядное який виключає АБО зі збереженням, | | |ABSI || STI — абсолютне значення цілого зі збереженням, | | |NEGI || STI — заперечення цілого зі збереженням, | | |ASH3 || STI — арифметичний зрушення зі збереженням, | |1 |2 | | |NOT — поразрядное логічне доповнення, | | |ABSI — абсолютне значення цілого числа, | | |NEGB — заперечення цілого з заемом, | | |ASH — арифметичний зрушення, | | |NEGI — заперечення цілого, | | |TSTB3 — перевірка бітових полів, | | |CMPI3 — порівняння цілих, | | |STI || STI — збереження цілих, | | |LDI || LDI — завантаження цілих, | | |XOR — поразрядное який виключає АБО. | |Тест 2|STF — зберегти значення з плаваючою точкою, | | |LDF — завантажити значення з плаваючою точкою, | | |LDE — завантаження значення експоненти з плаваючою точкою, | | |LDM — завантаження значення мантиси з плаваючою точкою, | | |FIX — перетворення на ціле, | | |FLOAT — перетворення на значення з плаваючою точкою, | | |ABSF — абсолютне значення числа з плаваючою точкою, | | |NEGF — заперечення значення з плаваючою точкою, | | |NORM — нормування значення з плаваючою точкою, | | |RND — округлення значення з плаваючою точкою, | | |POPF — виштовхування значення з плаваючою точкою з стека, | | |PUSHF — завантаження в стік значення з плаваючою точкою, | | |ABSF || STF — абсолютне значення числа з плаваючою точкою з | | |збереженням значення з плаваючою точкою, | | |FIX || STI — перетворення на ціле зі збереженням, | | |FLOAT || STF — перетворення на значення з плаваючою точкою з | | |збереженням значення з плаваючою точкою, | | |PUSH — завантаження цілого в стік, | | |POP — виштовхування цілого з стека, | | |LDF || STF — завантажити значення з плаваючою точкою з | | |збереженням значення з плаваючою точкою, | |1 |2 | | |NEGF || STF — заперечення значення з плаваючою точкою з | | |збереженням значення з плаваючою точкою, | | |STF || STF — збереження значень з плаваючою точкою, | | |LDF || LDF — завантаження значень з плаваючою точкою. | |Тест 3|SUBF3 — віднімання значень з плаваючою точкою, | | |SUBF3 || STF — значення з плаваючою точкою зі збереженням | | |значення з плаваючою точкою, | | |SUBB — віднімання цілих з заемом, | | |SUBC — умовне віднімання цілих, | | |SUBF — віднімання значень з плаваючою точкою, | | |SUBRB — віднімання цілих у порядку з заемом, | | |SUBRF — віднімання з плаваючою точкою у порядку, | | |SUBI3 || STI — віднімання цілих зі збереженням, | | |ADDC — складання цілих з перенесення, | | |ADDF — складання значень з плаваючою точкою, | | |ADDF3 — складання значень з плаваючою точкою, | | |ADDF3 || STF — значень з плаваючою точкою зі збереженням | | |значення з плаваючою точкою, | | |ADDI3 || STI — складання цілих зі збереженням, | | |MPYFмноження значень з плаваючою точкою, | | |MPYF3 — множення значень з плаваючою точкою, | | |MPYI — множення цілих, | | |MPYF3 || STF — множення значень з плаваючою точкою з | | |збереженням значення з плаваючою точкою, | | |MPYF3 || ADDF3 — множення додавання з плаваючою точкою, | | |MPYF3 || SUBF3 множення і віднімання з плаваючою точкою, | | |MPYI3 || STI — множення цілих зі збереженням, | | |MPYI3 || ADDI3 — множення додавання цілих, | | |MPYI3 || SUBI3 — множення і віднімання цілих, | | |CMPF — порівняння значень з плаваючою точкою, | | |CMPF3 — порівняння значень з плаваючою точкою. |.

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

4.3.1.3. Перевірка вмісту памяти.

Цей тест формує однієї зі найпростіших алгоритмів так званий CRC (Cyclic Redundancy Check) блоку пам’яті, вказаний у параметрах тесту. Правильний (очікуваний) CRC підтверджує правильність даних (коду) у зазначеній, незмінною (nonvolatile) у процесі виконання завдань області памяти.

Формування CRC іде за рахунок наступному алгоритму: 1. Ініціалізація початкового значення CRC нулем; маска контрольних бітов вибирається довільно, наприклад — 8 020 0003(Н). 2. Накласти маску на CRC і підсумовувати по модулю два значення контрольних бітов. 3. Зрушити CRC вліво на 1 розряд і додати результат кроку 2. 4. Скласти результат з черговою словом блоку тестируемых даних. 5. Якщо блок закінчився крок 6, інакше крок 2. 6. Порівняти отриманий CRC з ожидаемым.

Очікувані значення можна отримати на етапі ініціалізації. Функція crc_test реалізована мовою Асемблер відповідно до архітектурою і системою команд TMS320C30.

5. Перспективи розвитку спеціалізованих отказоустойчивых ОСРВ.

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

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

Подальше нарощування функцій ОСРВ можна вести у кількох напрямах: 1. Голосування, проведене лише на рівні елементарної перевірки, у випадку може задовольняти умовам функціонування управляючих систем внаслідок похибок і можливому відмінності функціональної інформації, котра надходить на обробку в ФЗ різних ПЭ. Тому, за голосуванні, особливо у останніх стадіях деградації доцільно застосовувати помехоустойчивое оцінювання, наприклад методом найменших квадратів (МНК).

Основні труднощі пов’язані з помилковими вимірами чи неправильним результатом ФЗ при викликає збій комбінації вхідних даних. Застосування методів стійкого оцінювання до вирішення цієї проблеми допоможе уникнути втрат часу на повторні вимірювання, і розрахунок ФЗ, і навіть допоможе внести визначеність при неузгодженості даних у процесі голосування. 2. Удосконалення підсистеми збирання й аналізу відмов у діагностуванні багатьох відмов однією такті роботи системы.

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

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

Заключение

.

У межах рішення поставленого завдання, за результатами аналітичних досліджень, виділили основні властивості і механізми розподілених операційними системами реального часу, необхідні роботи критично важливих додатків. Це:. Час реакції системи;. Час перемикання контексту;. Наявність коштів диспетчеризації;. Наявність коштів синхронізації, межзадачного і межпроцессорного взаимодействия;

Проте вимоги, які пред’являються надійності обчислювальних систем, такі, цих коштів найчастіше бракує. У результаті аналітичної роботи, було доведено необхідність, і описана структура таких вбудованих механізмів забезпечення отказоустойчивости ОСРВ, як:. Кошти маршрутизації пакетів даних у мережі ПЭ;. Кошти высокоуровневого межпроцессорного обміну;. Протокол голосування, аналізу відмов у ВР, й терміни прийняття консолідованого рішення;. Кошти реконфигурации ВС.

У результаті подальших досліджень, розглянуто приклад організації отказоустойчивых обчислень, на основі логіки прийняття консолідованого рішення, запропонований евристичний алгоритм аналізу результатів голосування вузлів (ПЭ) ВР і коштів диагностики.

Далі було запропоновано імовірнісна модель отказоустойчивой ЗС, розраховані її надежностные характеристики, показали посилення середньої часу напрацювання ЗС відмовитися в 2,5 — 3,5 разом із розширенням ЗС до 5−7 вузлів, дано рекомендації за вибором типу ЗС у її проектировании.

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

Реалізація моделі дозволила виділити ключові особливості системного ПО, властивого організації отказоустойчивых обчислень в целом:

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

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

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

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

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

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

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

На закінчення, перераховані основні перспективи нарощування можливостей системного ПЗ проведено та ускладнення принципів його работы.

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

Технологічна часть.

6.Технологическая часть.

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

Програмне забезпечення моделі ЗС і двох частин, розроблених для функціонування з урахуванням самого персонального комп’ютера з процесором Pentium-100 і від з операційній системою Windows 98 і від. Перша частина варта генерації системних файлів процессорных елементів ЗС з урахуванням заданої топології, запуску моделі ЗС, імітації об'єкта управління і генерації системної інформації про збої ЗС. Друга частина варта моделювання вузла ВС.

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

6.1. Системні исследования.

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

Загальна структура системи, моделируемая розроблюваним програмним продуктом, представлена на рис. 6.1.

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

[pic].

Рис. 6.1. Структура ВС.

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

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

[pic]Рис. 6.2. Структура розподіленої ОС.

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

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

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

6.2.1. Вимоги до ПО керуючої части.

Програмне забезпечення служить для ініціалізації роботи ЗС, імітації об'єкта управління, демонстрації роботи ЗС у умовах виникнення відмов це має складатися з модулів, які забезпечують: 1. Аналіз топології моделируемой ВС:

. введення і зчитування модифікованої матриці связности ВС;

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

. видача інформації в обробці ЗС на черговому цикле;

. прийом обробленою інформації від ЗС на черговому циклі. 4. Моделювання відмов і збоїв компонент ВС:

. формування сигналу на повна певного каналу зв’язку ПЭ.

(припинення функционирования);

. формування сигналу на збій певного каналу зв’язку ПЭ.

(спотворення інформації при передаче);

. формування сигналу на повна ПЭ (припинення функціонування, «зависание»);

. формування сигналу на збій ПЭ (зрадливий розрахунок функціональної задачи).

6.2.2. Вимоги до ПО вузлів сети.

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

Отже, ПО вузла має забезпечувати: 1. Визначення статичних маршрутів передачі у ВР, з поточної топології ЗС; 2. Розрахунок функціональної завдання на черговому циклі; 3. Обмін функціональної і системної інформацією всередині ВС:

. приймання і передача функціональної інформації після завершення розрахунку функціональної задачей;

. приймання і передача інформації про результати елементарних перевірок функціональної информации;

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

(консолідованого решения).

. приймання і передача інформації ініціалізації при заміні який відмовив элемента;

. забезпечення транзитної передачі у відмові каналу зв’язку. 4. Порівняння котра надходить функціональної інформації (елементарна перевірка) процес формування проміжного рішення про стан системи. 5. Голосування і прийняття консолідованого рішення про наявність (відсутності) відмов у системі. 6. Реконфігурацію ЗС у відповідність до результатами голосування. 7. Синхронізацію роботи ЗС. 8. Обмін інформацією з об'єктом управления:

. прийом функціональної інформації від об'єкта управління у початку чергового цикла;

. видачу функціональної інформацією кінці чергового цикла;

. прийом управляючого сигналу на моделювання відмови ПЭ чи одного ізі каналів зв’язку; 9. Діагностування стану ПЭ.

6.3. Розробка алгоритмов.

Розробка алгоритмів велася з урахуванням побудованої на етапі системних досліджень структурою ПО (див. рис. 6.2) й виконання вимог до нему.

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

6.3.1. Структура программы.

Розробка структури ПО отказоустойчивой ЗС проводилася з допомогою комбінації низхідного і вранішнього підходів. Спочатку була виділено загальний принцип роботи ЗС у цілому, що можна у вигляді наступного графа управління (див. рис. 6.3). [pic].

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

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

Внутрішня структура модулів проектувалась структуроване, по критерію мінімізації межмодульных зв’язків і циклів. Модулі оперують системної інформацією незалежно від характеру вихідних даних попередніх модулей.

Алгоритми і функціонування модулів ОСРВ детально розглянуті у розділі 2 і 3.

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

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

6.4. Кодирование.

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

Задля реалізації моделі отказоустойчивой ЗС використовувався мову З повагою та середовище розробки Microsoft Visual З++ 6.0. Вибір середовища розробки обумовлений наявністю в неї широких можливостей використанню механізмів Windows 98/2000 як підтримки базових функцій ОСРВ. Windows 98/2000 не є операційній системою реального часу, однак має досить потужні механізми (pipes — обмін даними між процесами, многозадачность і многопоточность, кошти синхронізації - семафори, мьютексы, події, таймери) багато в чому схожі з її механізмами ОСРВ, і достатні для реалізації модели.

Мова З, підтримуваний більшістю середовищ розробки та трансляторів різних ОСРВ, використовуваний розробки моделі, дозволяє створювати апаратно і операционно-независимые фрагменти програм, не прив’язаних до механізмам Windows.

Вибір мови З пов’язана з також такими факторами:

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

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

. навичками розробників. Для програмування платформи TMS320C30 використовувалася середовище розробки Code Composer 3.0 з транслятором мови З, багато в чому нагадує Visual З++. Вибір даної середовища розробки пов’язана з такими фактороми:

. поєднання інтегрованої середовища розробки з симулятором і сильною системою отладки;

. Windows-интерфейс;

. великий набір настройок проекту, зокрема настроювання карт памяти;

. стимулятор із широкою набором возможностей;

. наявність потужної системи налагодження. Задля реалізації аппаратно-зависимых ділянок програм, використовується Асемблер даної архітектурної группы.

6.5. Тестування і налагодження На етапі розробки та програмування було обрано такі методи лікування й кошти тестування і налагодження:. вмонтований отладчик інтегрованої середовища розробки Visual З++ 6.0;. отладочно-демонстрационная програма моделювання відмов ЗС;. наскрізний структурний контроль по всьому етапі програмування.. вмонтований отладчик інтегрованої середовища розробки Соde Composer 3.0;

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

6.5.2. Вмонтований отладчик інтегрованої середовища розробки Microsoft.

Visual З++ 6.0.

Вмонтований отладчик надає такі возможности:

. Можливість покрокового виконання программы,.

. Можливість установки брейкпоинтов (точок зупинки програми) у необхідних местах,.

. Можливість перегляду та значень переменных,.

. Можливість припинення і запуску процесів і др.

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

3.0.

Вмонтований отладчик надає такі возможности:

. Можливість покрокового виконання программы,.

. Можливість установки брейкпоинтов;

. перегляд стану процесора (вміст регістрів і прапорів, сегменти коду і данных);

. перегляд значень локальних і глобальних переменных;

. перегляд вмісту стека й історію вызовов;

. дизассемблирование программы;

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

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

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

6.5.4. Отладочная программа.

Отладочная програма писалася під перевірки роботи модулів, які забезпечують системі властивості отказоустойчивости, в комплексної формі, то є за одночасної паралельну роботу кількох ПЭ обчислювальної системы.

З допомогою отладочной програми проводилося таке тестирование:

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

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

. перевірка правильності перебудови (реконфигурации) системи після отказа;

. перевірка правильності видавали системою успіхів у умовах постійної деградації системы.

6.5.5. Налагодження і тестування модулів ОСРВ.

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

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

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

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

———————————;

PN (m)(t): Можливість відмови системи під час t =.