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

|Панель «Отказ |Содержит два связанных элемента: |

|ПЭ» |Переключатели задания вида отказа ПЭ, при этом |

| |«Фатальный отказ» означает полное прекращение |

| |функционирования (например зависание), а «Отказ ФЗ» - |

| |неправильный расчет ФЗ, с сохранением функций обмена и |

| |голосования. |

| |Поле «ПЭ» задает номер ПЭ для моделирования отказа. |

| |Кнопка «Задать» активизирует передачу управляющей |

| |информации заданному ПЭ. |

|Поле вывода |Обеспечивает отображение текущей топологической |

|(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К х 32 двойного доступа без такта ожидания

. Два блока ОЗУ 1К х 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 нулем; маска контрольных битов

выбирается произвольно, например - 80200003(Н).

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

C++. Выбор данной среды разработки был обусловлен следующими фактороми:

. сочетание интегрированной среды разработки с симулятором и мощной

системой отладки;

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

. большой набор настроек проекта, в том числе настройка карт памяти;

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

. наличие мощной системы отладки.

Для реализации аппаратно-зависимых участков программ, используется

Ассемблер данной архитектурной группы.

6.5. Тестирование и отладка

На этапе разработки и программирования были выбраны следующие методы и

средства тестирования и отладки:

. встроенный отладчик интегрированной среды разработки Visual C++ 6.0;

. отладочно-демонстрационная программа моделирования отказов ВС;

. сквозной структурный контроль на всем этапе программирования.

. встроенный отладчик интегрированной среды разработки Соde Composer 3.0;

6.5.1. Метод сквозного структурного контроля

Основная идея сквозного структурного контроля - регулярная взаимная

проверка программных модулей на этапе программирования. Такой контроль

необходим для обнаружения и исправления ошибок как можно раньше, пока

стоимость исправления ошибок минимальна. При отладки написанных программ

важно тщательно провести тестирование программного продукта. Цель

тестирования состоит в том, чтобы убедиться, что программа решает

действительно ту задачу, для которой предназначена, и выдает правильный

результат при любых условиях.

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

Visual C++ 6.0

Встроенный отладчик предоставляет следующие возможности:

. Возможность пошагового исполнения программы,

. Возможность установки брейкпоинтов (точек останова программы) в

необходимых местах,

. Возможность просмотра и изменения значений переменных,

. Возможность приостановки и запуска процессов и др.

С его помощью отслеживалась правильность выполнения различных функций

в составе ПО, вложенных вызовов, достоверность передачи информации внутри

сложных функций, правильность преобразования типов и т.п. Встроенный

отладчик использовался на промежуточных этапах разработки ПО, главным

образом для отладки отдельных модулей в составе модели ВС.

6.5.3. Встроенный отладчик интегрированной среды разработки Code Composer

3.0

Встроенный отладчик предоставляет следующие возможности:

. Возможность пошагового исполнения программы,

. Возможность установки брейкпоинтов;

. просмотр состояния процессора (содержимое регистров и флагов,

сегменты кода и данных);

. просмотр значений локальных и глобальных переменных;

. просмотр содержимого стека и истории вызовов;

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

. возможность подключения в ключевых точках программы ввода-вывода с

помощью текстовых файлов, таким образом симулируется трансфер данных

через память процессора;

. возможность подключения графического аппарата, представленного 4-мя

различными вариантами диаграмм для построения графиков различной

сложности и отслеживания сигналов реального времени;

. наличие профайлера, позволяющего производить замер

производительности процессора на критических участках кода и др.

С его помощью отслеживалась правильность выполнения модулей ОСРВ,

переносимых на платформу TMS320C30, и процедуры аппаратно-зависимой

диагностики.

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

Отладочная программа была написана для проверки работы модулей,

обеспечивающих системе свойства отказоустойчивости, в комплексной форме, то

есть при одновременной параллельной работе нескольких ПЭ вычислительной

системы.

С помощью отладочной программы проводилось следующее тестирование:

. проверка правильности реакции системы на отказ или сбой каналов

связи;

. проверка правильности реакции системы на отказ или сбой ПЭ;

. проверка правильности перестройки (реконфигурации) системы после

отказа;

. проверка правильности выдаваемых системой результатов в условиях

постоянной деградации системы.

6.5.5. Отладка и тестирование модулей ОСРВ

На первом этапе для всех модулей тестировались все разветвления на

графе управления программой как с помощью встроенного отладчика (правильная

обработка всех команд), так и стохастически, то есть с помощью генерации

различной последовательности входных данных, и проверки результатов

сравнением с эталонными значениями. Далее проверка производилась

комплексно, исследовалась реакция и взаимодействие модулей.

Приведем описание процесса тестирования для некоторых модулей.

Модуль маршрутизации: Отладка и тестирование этого модуля проводилась

сначала с помощью отладчика, на вход подавалась простейшая топология сети,

при этом отслеживалось правильное выполнение статических команд и команд

перехода и ветвления. После получения удовлетворительных результатов,

тестирование продолжалось стохастически, проверкой модуля на различных

входных топологиях. Дальнейшее тестирование проводилось комплексно, с

подключением модуля реконфигурации.

Модуль реконфигурации: Проверка выполнения всех ветвей проводилась с

помощью отладчика, на вход алгоритма подавались нужные значения и с помощью

трассировки проверялась правильность выбора и выполнения нужной ветви.

Дальнейшая стохастическая отладка модуля проводилась как с использованием

отладчика, так и отладочной программы, с помощью генерации различного рода

информации об отказах и проверкой результатов работы данного модуля

сравнением с ожидаемым результатом.

Отладка и тестирование других модулей проводилась по той же схеме,

причем особое внимание уделялось комплексной отладке программы.

Комплексная отладка модулей проводилась организацией взаимодействия

модулей в соответствии с логикой работы ВС, отслеживались данные

межзадачного взаимодействия, синхронизация, и последовательность действий с

помощью специально вводимых текстовых сообщений в ключевых узлах программ.

-----------------------

PN(m)(t): Вероятность отказа системы за время t =

Страницы: 1, 2, 3, 4, 5