diplom (664611), страница 14

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 14)

Таким образом, ПО узла должно обеспечивать:

1. Определение статических маршрутов передачи информации в ВС, исходя из текущей топологии ВС;

2. Расчет функциональной задачи на очередном цикле;

3. Обмен функциональной и системной информацией внутри ВС:

• прием и передача функциональной информации после завершения расчета функциональной задачей;

• прием и передача информации о результатах элементарных проверок функциональной информации;

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

• прием и передача информации инициализации при замене отказавшего элемента;

• обеспечение транзитной передачи информации при отказе канала связи.

1. Сравнение поступающей функциональной информации (элементарная проверка) и формирование промежуточного решения о состоянии системы.

2. Голосование и принятие консолидированного решения о наличии (отсутствия) отказов в системе.

3. Реконфигурацию ВС в соответствии с результатами голосования.

4. Синхронизацию работы ВС.

5. Обмен информацией с объектом управления:

• прием функциональной информации от объекта управления в начале очередного цикла;

• выдачу функциональной информации в конце очередного цикла;

• прием управляющего сигнала на моделирование отказа ПЭ или одного изи каналов связи;

1. Диагностирование состояния ПЭ.

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

Разработка алгоритмов велась с учетом построенной на этапе системных исследований структурой ПО (см. рис. 6.2) и требований к нему.

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

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

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

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

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

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

Алгоритмы и функционирование модулей ОСРВ детально рассмотрены в главе 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. Отладка и тестирование модулей ОСРВ

На первом этапе для всех модулей тестировались все разветвления на графе управления программой как с помощью встроенного отладчика (правильная обработка всех команд), так и стохастически, то есть с помощью генерации различной последовательности входных данных, и проверки результатов сравнением с эталонными значениями. Далее проверка производилась комплексно, исследовалась реакция и взаимодействие модулей.

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

Модуль маршрутизации: Отладка и тестирование этого модуля проводилась сначала с помощью отладчика, на вход подавалась простейшая топология сети, при этом отслеживалось правильное выполнение статических команд и команд перехода и ветвления. После получения удовлетворительных результатов, тестирование продолжалось стохастически, проверкой модуля на различных входных топологиях. Дальнейшее тестирование проводилось комплексно, с подключением модуля реконфигурации.

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

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

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

Характеристики

Список файлов реферата