Предыдущая страница реферата | 15  16  17  18  19  20  21  22  23  24  25 | Следующая страница реферата

Рис. 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++. Выбор данной среды разработки был обусловлен следующими фактороми:

Рекомендуем скачать другие рефераты по теме: российская федерация реферат, изложение.





Предыдущая страница реферата | 15  16  17  18  19  20  21  22  23  24  25 | Следующая страница реферата