Требования к архитектуре

Архитектура автоматизированной системы - это наиболее абстрактное ее представление, которое включает в себя идеализированные модели компонентов системы, а также модели взаимодействий между компонентами. Элементы* архитектуры находятся во взаимосвязи, образуя единую автоматизированную систему и обеспечивая решение поставленной задачи автоматизации на архитектурном уровне. В то же время архитектура оставляет достаточно свободы для выбора конкретных технических решений [Клир]. Поэтому правильно спроектированная архитектура допускает множество технических реализаций путем выбора различных компонентов архитектуры и методов взаимодействия между ними.

Элементами архитектуры являются модели (абстракции) датчиков, устройств ввода-вывода, измерительных преобразователей, ПЛК, компьютеров, интерфейсов, протоколов, промышленных сетей, исполнительных устройств, драйверов, каналов передачи информации.

Архитектуру создает архитектор [Клир]. Основным требованием к архитектору является знание предметной области (принципов функционирования объекта автоматизации) и знание технических характеристик аппаратных и программных средств, используемых для построения системы.

При построении архитектуры должны быть заложены следующие свойства будущей автоматизированной системы:

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

o тестируемость (возможность установления факта правильного функционирования);

o диагностируемость (возможность нахождения неисправной части системы);

o ремонтопригодность (возможность восстановления работоспособности за минимальное время при экономически оправданной стоимости ремонта);

o надежность (например, путем резервирования);

o простота обслуживания и эксплуатации (минимальные требования к квалификации и дополнительному обучению эксплуатирующего персонала);

o безопасность (соответствие требованиям промышленной безопасности и технике безопасности);

o защищенность системы от вандалов и неквалифицированных пользователей;

o экономичность (экономическая эффективность в процессе функционирования);

o модифицируемость (возможность перенастройки для работы с другими технологическими процессами);

o функциональная расширяемость (возможность ввода в систему дополнительных функциональных возможностей, не предусмотренных в техническом задании);

o наращиваемость (возможность увеличения размера автоматизированной системы при увеличении размера объекта автоматизации);

o открытость (см. раздел "Понятие открытой системы");

o возможность переконфигурирования системы для работы с новыми технологическими процессами;

o максимальная длительность жизненного цикла системы без существенного морального старения, достигаемая путем периодического обновления аппаратных и программных компонентов, а также путем выбора долгоживущих промышленных стандартов;

o минимальное время на монтаж и пуско-наладку (развертывание) системы.

Архитектура системы может быть различной в зависимости от решаемой задачи автоматизации. Такими задачами могут быть:

o мониторинг (продолжительные измерение и контроль с архивированием полученной информации);

o автоматическое управление (в системе с обратной связью или без нее);

o диспетчерское управление (управление с помощью человека-диспетчера, который взаимодействует с системой через человеко-машинный интерфейс);

o обеспечение безопасности.

Любая из перечисленных задач может выполняться на большом расстоянии между объектом автоматизации и системой. В этом случае говорят о задачах телемеханики(дистанционные измерение, управление, сигнализация). Однако, в связи с тем, что каналы дистанционной связи (интернет, радиоканал, оптико-волоконный канал, проводной канал) органично входят практически в любую систему автоматизации, задачу телемеханики все реже выделяют как самостоятельную.

Построение любой АСУ** начинается с декомпозиции (деления на части) системы на подсистемы. Декомпозиция может быть функциональной (алгоритмической) или объектной.

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

Объектная декомпозиция объекта автоматизации используется в современных SCADA-пакетах, см., например [Аблин]. Она аналогична объектной декомпозиции, используемой вобъектно-ориентированном программировании (ООП), основными признаками которой являются абстрагирование, инкапсуляция, модульность, иерархическая организация [Буч]. Классам ООП соответствуют контроллеры (ПЛК), объектам - контроллеры с заданными свойствами (параметрами), инкапсуляция соответствует сокрытию конкретной реализации (например, с помощью функциональных блоков языка IEC 61131-3 (см. раздел"Программное обеспечение")); благодаря инкапсуляции существенно упрощается структура системы с точки зрения системного интегратора и тем самым уменьшается количество возможных ошибок. Модульность обеспечивается модульностью аппаратного обеспечения системы, иерархичность естественным путем вытекает из требований заказчика.

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

Программные модули, реализующие отдельные функции в разных контроллерах, могут взаимодействовать между собой по промышленной сети с помощью технологии СОМфирмы Microsoft, CORBA консорциума OMG [Причард] или SOAP консорциума W3C[Ньюкомер]. Для разработки заказного программного обеспечения распределенных систем управления используют специальную среду разработки систем реального времени [Kim] или стандартное программное обеспечение на основе технологии DCOM фирмы Microsoft(см. раздел "Программное обеспечение"). В статье [Perez-Aragon] приводится пример системы, в которой разные функции управления представлены в виде компонентов, написанных с помощью CORBA, распределенных между разными контроллерами либо сгруппированных в одном из них. В работе [Sunder] предлагается способ построения архитектуры системы на основе "ячеек автоматизации", при котором на разных уровнях иерархии используются одни и те же ячейки с одним и тем же программным обеспечением, что делает систему однородной несмотря на иерархичность и поэтому снижает трудоемкость ее проектирования и обслуживания.

Более подробно программное обеспечение систем автоматизации будет рассмотрено в разделе "Программное обеспечение".