7.6. Обсуждение альтернативных архитектур

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

Но в многопроцессорной среде для каждого прибора допустимо иметь свой про­цессор, на котором будут выполняться экземпляры задач Интерфейс кнопок, Интерфейс дат­чика функционирования шлюза, Интерфейс дат­чика исправления ошибок и Диспетчер. Задачи Монитор контроля функционирования шлюзов и Монитор контроля исправления ошибок удобно разместить на отдельном процес­соре. В случае нескольких ЦП с общей памятью объект абстрагирования данных Состояние по-прежнему хранился бы в разделяемой памяти.

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

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

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

В распределенной конфигурации нет разделяемой памяти, а значит, Диспетчер и экземпляры Подсистемы управления исправлением ошибок не могут напрямую обратиться к объ­екту абстрагирования данных Состояние, как было в предыдущем случае. Один из способов решить проблему - поместить такой объект в серверную задачу. Вместо того чтобы вызывать операцию объекта абстрагирова­ния данных, клиентская задача отправит синхронное сообщение с ответом задаче Сервер Состояния и Плана работы системы исправления ошибок. Но при этом сервер может стать узким местом, поскольку у него есть довольно много клиентов. Альтернативное решение – применение репликации данных. Каждый экземпляр Подсистемы управления исправлением ошибок хранит собственный локальный объект Локальное Состояние и План работы системы исправления ошибок. Есть такой объект и у Диспетчера, толь­ко в нем содержатся состояния и называется он Сводное Состояние и План работы системы исправления ошибок.

Рис. 16. Архитектура распределенного ПО

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

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

Архитектура задач для Подсистемы управления исправлением ошибок показана на рис.17. Она ана­логична архитектуре для нераспределенного решения с тем отли­чием, что экземпляров подсистем существует несколько.

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

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

Рис.17. Архитектура задач для подсистемы управления исправлением ошибок

Рис.18. Архитектура задач для подсистемы управления исправлением ошибок: интерфейсы задач