БФКС

БМН ССК

Интерфейс

СШ

Рисунок 2.2 – Блок контроля со схемой сравнения кодов (БФСК - блок формирования стробов команд, БРЭС – блок регистрации эталонного слова, БМН – блок матрицы неисправностей, БФКС – блок формирования контрольного слова, БРК – блок регистра команд)

БФСК – собирает всю конструктивную информацию в БРК (т.е записывает команды)

БРЭС – реально происходит выполнение команды out[БРЭС], что приведет к записи 0 или 1 в БМН, что, в свою очередь, зависит от результата на выходе ССК.

Алгоритм работы данного метода приведен на рис.2.3.

НАЧАЛО

ЗАГРУЗКА

БРКС

ЛИНЕЙНЫЙ

УЧАСТОК

ЗАГРУЗКА

БРКС

КОНЕЦ

Рисунок 2.3 – Алгоритм работы блока контроля со ССК.

При выходе ПМ из строя, на выходе блока контроля формируется сигнал ошибки, который представляет собой 8-битовую последовательность, каждый бит которой несет информацию о текущем состоянии соответствующего ПМ (0-ПМ в рабочем состоянии, 1-ПМ вышел из строя) и выставляет его на СМ каждый раз по срабатыванию таймера ПМ. Блок Выбора Мастера(БВМ) каждый раз анализирует вышеописанный сигнал ошибки, и в случае обнаружения отказа ПМ-Мастера назначает Мастером любой другой работоспособый ПМ, о чем объявляет выставлением на БК ПМ сигнала НМ(номер мастера).

3 Разработка программного обеспечения

3.1 Общие принципы построения ОС

Для проектируемой МВС в качестве основной выбрана ОС, построенная по принципу Ведущий-Ведомый(Master-Slave), поэтому все процессоры системы делятся на две категории:

1.Главный процессор – Ведущий (Master)

2.Вспомогательный процессор – Ведомый (Slave)

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

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

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

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

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

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

3.2 Примеры алгоритмов программ

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

- пересылка данных из глобальной памяти в локальную (см. Рисунок 3.2.1)

- реконфигурация системы (см. Рисунок 3.2.2)

НАЧАЛО

R1  Адрес

Источника

R2  Адрес

Приемника

да

Сч = 1?

Нет

Сч = 1 INC(R1)

(R1) (R2) INC(R2)

DEC R3

R3 = 0?

Сч := 0

КОНЕЦ

Рисунок 3.2.1 – Алгоритм пересылки данных из локальной памяти в глобальную.

НАЧАЛО

Обнулить счетчик

Изменить контр.перемен.

Считать текущее значение

Контр.перем.Ведущего ПМ

Нов.знач.=Стар.знач.? нет

Да

Установка семафора

По доступу к ГП

Изменить контр.значение

Глобальной переменной

Загрузить в R1 адрес ядра

ОС из ЛП

Загрузить в R2 адрес ядра

ОС из ГП

Загрузить в R3 размер ядра

Подпрограмма

пересылки данных

из ГП в ЛП

Сбросить семафор

Перейти на начало ядра

ОС в ЛП

КОНЕЦ

Рисунок 3.2.2 – Алгоритм реконфигурации системы.

4 Разработка принципиальной схемы

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

4.1 Централизованный арбитр доступа к ОР

Параметры арбитра:

Тип арбитра – централизованный

Приоритет ПМ – абсолютный географический

Автомат – синхронный

4.1.1 Струткурная схема арбитра

ВУ ОП

СМ

РШ ПБ1 ПБ2 ПБ3

ТШ

Арбитр

ДЗ

Рисунок 4.1.1 – Структурная схема централизованного арбитра доступа

4.1.2 Построение закодированного графа арбитра

11 А3 ТПД А1 00

ППД или ДЗ a

РШ ТПД

А2

ТШ 10

Рисунок 4.1.2 – Закодированный граф арбитра

4.1.3 Определение операторных форм временных переменных и функций выходных сигналов.

Таблица 4.1 – Структурная таблица кодирования сигнала