Закрыть
Регистрация
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Разделы документации
Техническое регулирование. Стандартизация
Метрология
Подтверждение соответствия
Справочники
Учебно-методическая литература

Архитектура автоматизированной системы управления технологическим процессом - АСУ ТП

Автоматизированные системы управления (АСУ ТП)

Архитектура автоматизированной системы управления технологическим процессом - АСУ ТП

1.1.1. Требования к архитектуре АСУ ТП

Архитектура автоматизированной системы управления  — это наиболее абстрактное ее представление, которое включает в себя идеализированные модели компонентов системы, а также модели взаимодействий между компонентами. Элемен­ты*

(* «Компонент» и «элемент» в данном контексте являются синонимами)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

наращиваемость (возможность увеличения размера автоматизированной

системы при увеличении размера объекта автоматизации);

открытость (см. п. 1.3);

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

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

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

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

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

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

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

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

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

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

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

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

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

Программные модули, реализующие отдельные функции в разных контрол­лерах, могут взаимодействовать между собой по промышленной сети с помощью технологии СОМ фирмы Microsoft, CORBA консорциума OMG [4] или SOAP консорциума W3C [5]. Для разработки заказного программного обеспечения распределенных систем управления используют специальную среду разработ­ки систем реального времени [8] или стандартное программное обеспечение на основе технологии DCOM фирмы Microsoft (см. главу 9). В статье [6] приво­дится пример системы, в которой разные функции управления представлены в виде компонентов, написанных с помощью CORBA, распределенных между разными контроллерами либо сгруппированных в одном из них. В работе [7] предлагается способ построения архитектуры системы на основе «ячеек авто­матизации», при котором на разных уровнях иерархии используются одни и те же ячейки с одним и тем же программным обеспечением, что делает систе­му однородной, несмотря на иерархичность и поэтому снижает трудоемкость ее проектирования и обслуживания.

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


Возврат к списку

ON-LINE версия