. выдачу функциональной информации в конце очередного цикла;
. прием управляющего сигнала на моделирование отказа ПЭ или одного изи каналов связи; 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, 6, 7, 8, 9, 10, 11, 12, 13, 14
