В предыдущей статье, опубликованной в журнале (1_2010), авторы обсудили критерии выбора инструментальных средств построения SCADA-систем. В данной работе рассматриваются аспекты выбора SCADA в зависимости от архитектуры и назначения автоматизированных систем контроля и управления.
НПФ «КРУГ», Россия, г. Пенза
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.
Рис.1. Блок-схема АСУ ТП установки риформинга
Применяя этот подход, необходимо помнить, что база данных тегов для каждого распределенного узла (контроллера/сервера) создается и настраивается индивидуально. При изменении одной из баз необходимо отслеживать целостность ссылок и в других базах. При увеличении количества тегов в системе обеспечение целостности баз тегов становится очень трудоемкой задачей. Не говоря уже о том, что разбираться в нескольких разных системах программирования и проводить их отладку по отдельности крайне неудобно.
Если вы все же используете различные средства для программирования контроллера и создания SCADA-проекта верхнего уровня, то необходимо убедиться в поддержке соответствующих протоколов обмена между контроллером и SCADA-сервером, например в наличии соответствующих OPC-серверов и OPC-клиентов. Необходимо учитывать характер и формат данных для обмена с контроллером. Например, отсутствие возможности передать сигнальную информацию из контроллера приведет к необходимости (возможно, повторного) отслеживания событий и тревог в SCADA-сервере. В рамках данного подхода также возможны проблемы с поддержкой программного резервирования источников данных в SCADA-сервере, поскольку реализуемые открытые протоколы могут не поддерживать резервирование в нужном объеме.
Несмотря на все эти сложности, такой подход имеет право на существование благодаря следующим достоинствам:
- независимость от аппаратных платформ и легкая взаимозаменяемость отдельных элементов;
- низкая стоимость ПО. Стоимость сред разработки зачастую уже включена в стоимость приобретаемого контроллера либо невысока;
- применение типовых сред разработки. Производители контроллеров адаптируют для работы со своими устройствами такие популярные среды разработки, как Isograph, CodeSys, Klogic. При этом, если пользователь имел опыт работы с подобным ПО, ему нет нужды изучать его повторно.
Второй подход, более популярный, состоит в применении интегрированных SCADA, в которых среда разработки объединяет в себе средства для программирования контроллеров, серверов и графических станций. Это достигается за счет поддержки собственной среды исполнения контроллеров и собственного (специализированного) протокола обмена между серверами и контроллерами.
Преимущества такого подхода налицо:
- общая база значений тегов позволяет автоматически отследить целостность и синхронность баз тегов на всех распределенных компонентах системы (контроллерах, серверах);
- единый язык и среда программирования дают возможность с минимальными затратами на обучение в едином стиле разрабатывать технологические программы для контроллеров и серверов;
- четкое распределение функций между узлами системы, что позволяет легко контролировать их выполнение на каждом узле. К таким функциям относятся, например, сигнализация, ведение истории процесса, различные технологические алгоритмы сбора и обработки данных, алгоритмы регулирования;
- обеспечение необходимого уровня надежности системы за счет реализации сложных схем резервирования (контроллеров, связи, серверов и источников данных), а также использования внутреннего протокола обмена данными с контролем доставки команд управления.
В качестве недостатков следует указать жесткую привязку системы реального времени к конкретным аппаратным платформам, а соответственно и производителям. Таким образом, выбирая второй подход для разработки системы, вы изначально ограничиваете себя определенной номенклатурой устройств (контроллеров).
В любом случае при принятии решения о выборе подхода к созданию распределенной SCADA следует учитывать целый ряд факторов, например: номенклатуру уже приобретенного и работающего оборудования (устройств, контроллеров, каналов связи и т.д.), наличие и опыт разработчиков, возможное наращивание системы по функционалу и по информационной мощности, планируемые затраты на разработку системы.
В сосредоточенных системах, где функции управления, регулирования и обработки данных совмещены в рамках одного рабочего места, обычно применяются отдельные среды разработки для каждой из частей системы, что позволяет минимизировать затраты на разработку SCADA.
Рис. 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) или планшетный компьютер.
через КПК (Palm PC) или планшетный компьютер.
К недостаткам Web-клиента можно отнести низкую интерактивность Web-браузера: недостаточно быструю реакцию элементов пользовательского интерфейса и медленное обновление динамических элементов, связанных с ограничением Web-технологий.
Кроме того, выбирая данный вид клиентов для управляющей системы, необходимо убедиться в наличии у производителя SCADA Web-клиента c функциями управления. Далеко не все SCADA-системы поддерживают такие функции.С приходом новых технологий, таких, как ASPNET и SilverLight, Web-ориентированные SCADA набирают все большую популярность.
Локальные клиенты в отличие от Web-клиентов гарантируют своевременную доставку на сервер управляющих воздействий и обладают повышенной интерактивностью.
Однако не следует забывать, что эти клиенты требуют установки дополнительного программного обеспечения на каждый «клиентский» компьютер и функционируют только в рамках конкретных операционных систем.
Таблица 1 (часть 1)
Таблица 1 (часть 2)
Критичность к временной потере данных и управления
В системах управления, критичных к временной потере данных и управления, к которым предъявляются повышенные требования надежности и безопасности, необходимо предусмотреть поддержку SCADA-системой необходимых видов резервирования и контроля прохождения управляющих сигналов. Это достигается в большинстве случаев использованием интегрированных SCADA.
Другие факторы
Помимо архитектурных особенностей автоматизированной системы при выборе SCADA также необходимо учитывать наличие в ней:
- системы отчетов;
- необходимых форматов импорта и экспорта данных;
- возможности сохранения и ведения базы тегов в стандартной СУБД;
- встроенной системы тревог и событий;
- средств ведения трендов и архивирования истории изменения параметров;
- развитых графических возможностей для визуализации;
- скриптовой подсистемы;
- возможности масштабирования системы на нужное количество тегов.
Успешный многолетний опыт построения SCADA-систем в различных отраслях промышленности дает нам право рекомендовать к применению программные средства, разработанные НПФ «КРУГ»:
- модульная, интегрированная с СРВК, SCADA КРУГ-2000® [2];
- SCADA/HMI DataRate™ [3];
- сервер консолидации технологических данных WideTrack™ [4];
- OPC-серверы для различных систем, приборов и устройств [5].
В табл. 1 показаны примеры систем в различных областях промышленной автоматизации и выбранные для их реализации SCADA.
Разработчики НПФ «КРУГ» всегда очень внимательно относятся к запросам и пожеланиям своих клиентов и открыты к новым предложениям и сотрудничеству. Надеемся, что изложенная в статье информация поможет вам правильно определиться с выбором средств разработки автоматизированных систем.
Литература
1_Прошин Д.И., Гурьянов Л.В. Проблемы выбора инструментальных средств построения SCADA-систем.ИСУП. 2010. № 1.
Статья опубликована в журнале «ИСУП», № 1(31)_2011
Д.И. Прошин, к.т.н., начальник отдела Департамента «Программное обеспечение»;
Л.В. Гурьянов, к.т.н., ведущий специалист Департамента «Программное обеспечение»,
НПФ «КРУГ», г. Пенза,
тел.: (8412) 499-775,
e-mail: krug@krug2000.ru
_big.jpg'); "6(114)_small.jpg")
