SCADA, АСУ ТП, контроллеры – основная тематика журнала «ИСУП»
Журнал «Информатизация и Системы Управления в Промышленности» публикует тематические материалы посвященные SCADA, АСУ ТП, контроллерам, автоматизации в промышленности.

Учет архитектурных особенностей автоматизированных систем при выборе SCADA

В предыдущей статье, опубликованной в журнале (1_2010), авторы обсудили критерии выбора инструментальных средств построения SCADA-систем. В данной работе рассматриваются аспекты выбора SCADA в зависимости от архитектуры и назначения автоматизированных систем контроля и управления. 

НПФ «КРУГ», Россия, г. Пенза

krug.gif


SCADA (Supervisory Control And Data Acquisition: диспетчерское управление и сбор данных) – это название класса систем для комплексной автоматизации промышленного производства. Термин «SCADA» имеет двоякое толкование. Часто под SCADA-системой подразумевают программно-аппаратный комплекс. В настоящее время наиболее распространено понимание SCADA как программного комплекса, обеспечивающего выполнение функций диспетчерского управления и сбора данных, а также инструментальных средств для разработки этого программного обеспечения.

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

С точки зрения распределения функций управления, регулирования, сбора и обработки данных автоматизированные системы образуют следующие группы:
- распределенные системы (DCS\РСУ), характеризующиеся построением распределенной системы ввода/вывода и децентрализацией обработки данных (рис. 1);
- сосредоточенные автоматизированные системы, все функции в которых выполняются в рамках одной рабочей станции/сервера/контроллера (рис. 2).

Среди распределенных и клиент-серверных систем, в зависимости от характеристик коммуникационной инфраструктуры, будем различать системы:
- работающие по быстрым и надежным каналам связи (рис. 1);
- использующие медленную и ненадежную связь (рис. 2).

Принимая во внимание распределение супервизорных функций между пользователями системы, получим еще две группы автоматизированных систем:
- однопользовательские. Все управление и мониторинг ведется на одной рабочей станции (например, АРМ-диспетчера) (рис. 2);
- многопользовательские. Система предоставляет множество АРМ, каждое из которых выполняет свою функцию (рис. 1).

В зависимости от степени ответственности можно выделить следующие автоматизированные системы:
- критичные к временной потере данных и управления (рис. 1);
- некритичные к временной потере данных и управления (рис. 2).

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


Распределение функций между элементами системы

Распределенная (DCS\РСУ) система управления характеризуется наличием нескольких децентрализованных узлов ввода/вывода и обработки данных. Существует несколько подходов к созданию подобных систем. Каждый из подходов характеризуется своей себестоимостью ПО, включающей как стоимость разработки SCADA-проекта, так и стоимость самого SCADA-инструментария.

Первый подход состоит в применении отдельных сред разработки для каждой из распределенных частей системы. Для программирования контроллеров в этом случае используется специализированное ПО, поставляемое производителем контроллера, например Isograph, CodeSys, Klogic. Для связи с верхним уровнем (SCADA-сервером) используется либо OPC-технология, либо стандартные открытые протоколы типа Modbus. 

pic1.gif

Рис.1. Блок-схема АСУ ТП установки риформинга

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

Если вы все же используете различные средства для программирования контроллера и создания SCADA-проекта верхнего уровня, то необходимо убедиться в поддержке соответствующих протоколов обмена между контроллером и SCADA-сервером, например в наличии соответствующих OPC-серверов и OPC-клиентов. Необходимо учитывать характер и формат данных для обмена с контроллером. Например, отсутствие возможности передать сигнальную информацию из контроллера приведет к необходимости (возможно, повторного) отслеживания событий и тревог в SCADA-сервере. В рамках данного подхода также возможны проблемы с поддержкой программного резервирования источников данных в SCADA-сервере, поскольку реализуемые открытые протоколы могут не поддерживать резервирование в нужном объеме.

Несмотря на все эти сложности, такой подход имеет право на существование благодаря следующим достоинствам:
- независимость от аппаратных платформ и легкая взаимозаменяемость отдельных элементов; 
- низкая стоимость ПО. Стоимость сред разработки зачастую уже включена в стоимость приобретаемого контроллера либо невысока;
- применение типовых сред разработки. Производители контроллеров адаптируют для работы со своими устройствами такие популярные среды разработки, как Isograph, CodeSys, Klogic. При этом, если пользователь имел опыт работы с подобным ПО, ему нет нужды изучать его повторно.

Второй подход, более популярный, состоит в применении интегрированных SCADA, в которых среда разработки объединяет в себе средства для программирования контроллеров, серверов и графических станций. Это достигается за счет поддержки собственной среды исполнения контроллеров и собственного (специализированного) протокола обмена между серверами и контроллерами.

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

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

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

Ris2.jpg

Рис. 2. Блок-схема точек учета электрической энергии


Коммуникационная инфраструктура

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

Поскольку циклический режим обмена данными в таких случаях неприемлем, в системе должны быть реализованы спорадические (в произвольные моменты времени) режимы обмена по инициативе контроллера и SCADA-сервера.

Дополнительным требованием к SCADA является поддержка «исторических» интерфейсов и протоколов обмена между SCADA-сервером и контроллером, т.е. обмен данными должен включать в себя возможность надежной передачи целого тренда за указанный временной период. Например, если в качестве основного стандарта обмена данными принят OPC, то необходимо убедиться в поддержке OPC HDA спецификации контроллером и SCADA-сервером. В интегрированной SCADA необходимо удостовериться, что внутренний протокол обмена также обладает необходимыми свойствами.


Уровень использования

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

Также важным является наличие в SCADA функций межсерверного обмена данными и диспетчерского управления с возможностью ручного и автоматического переключения между серверами.

Необходимым требованием к SCADA является возможность SCADA-сервера обеспечить доступ к данным в реальном времени для множества клиентов.

Обычно выделяют клиентов двух видов:
- Web-клиент, который предоставляет возможность мониторинга и управления системой через обычный Web-браузер; 
- локальный клиент, для функционирования которого необходимо устанавливать специализированный программный компонент – клиент – от производителя SCADA.

Преимущества в использовании Web-клиента следующие:
- минимальные настройки и административные разрешения для работы в Intranet/Internet-сетях;
- легкая интеграция в общую информационную систему предприятия (Web-портал);
- значительное снижение затрат на техническое обслуживание конечных АРМов, так как для функционирования клиента нужен только Web-браузер;
- использование различных платформ, где возможно функционирование только Web-браузера. Например, мониторинг/управление системой
 через КПК (Palm PC) или планшетный компьютер.

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

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

Локальные клиенты в отличие от Web-клиентов гарантируют своевременную доставку на сервер управляющих воздействий и обладают повышенной интерактивностью.

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

Таблица 1 (часть 1)

Tab1_1.jpg

Таблица 1 (часть 2)

Tab1_2.jpg



Критичность к временной потере данных и управления

В системах управления, критичных к временной потере данных и управления, к которым предъявляются повышенные требования надежности и безопасности, необходимо предусмотреть поддержку SCADA-системой необходимых видов резервирования и контроля прохождения управляющих сигналов. Это достигается в большинстве случаев использованием интегрированных SCADA.


Другие факторы 

Помимо архитектурных особенностей автоматизированной системы при выборе SCADA также необходимо учитывать наличие в ней:
- системы отчетов;
- необходимых форматов импорта и экспорта данных;
- возможности сохранения и ведения базы тегов в стандартной СУБД;
- встроенной системы тревог и событий;
- средств ведения трендов и архивирования истории изменения параметров;
- развитых графических возможностей для визуализации;
- скриптовой подсистемы;
- возможности масштабирования системы на нужное количество тегов.

Успешный многолетний опыт построения SCADA-систем в различных отраслях промышленности дает нам право рекомендовать к применению программные средства, разработанные НПФ «КРУГ»: 
- модульная, интегрированная с СРВК, SCADA КРУГ-2000® [2];
- SCADA/HMI DataRate™ [3];
- сервер консолидации технологических данных WideTrack™ [4];
- OPC-серверы для различных систем, приборов и устройств [5].

В табл. 1 показаны примеры систем в различных областях промышленной автоматизации и выбранные для их реализации SCADA.
Разработчики НПФ «КРУГ» всегда очень внимательно относятся к запросам и пожеланиям своих клиентов и открыты к новым предложениям и сотрудничеству. Надеемся, что изложенная в статье информация поможет вам правильно определиться с выбором средств разработки автоматизированных систем.


Литература

1_Прошин Д.И., Гурьянов Л.В. Проблемы выбора инструментальных средств построения SCADA-систем.ИСУП. 2010. № 1.
2_www.krug2000.ru
3_www.datarate.krug2000.ru
4_www.opcserver.ru
5_www.krug2000.ru/widetrack.phtml. 

Статья опубликована в журнале «ИСУП», № 1(31)_2011

Д.И. Прошин, к.т.н., начальник отдела Департамента «Программное обеспечение»;
Л.В. Гурьянов, к.т.н., ведущий специалист Департамента «Программное обеспечение»,
НПФ «КРУГ», г. Пенза,
тел.: (8412) 499-775,
e-mail: krug@krug2000.ru