СТАТЬИ ПО ТЕМАМ

ВСЕ СТАТЬИ

2010   2009   2008   2007   2006   2005   2004   2003   2002   2001   1999   1998  

ПОИСК ПО СТАТЬЯМ


»»»

НОВОСТИ



 
 

Программные продукты

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

ИСУП №1/2011
   

Статья опубликована в журнале ИСУП №1/2011

Прошин Дмитрий Иванович, к.т.н., начальник отдела Департамента «Программное обеспечение»
Гурьянов Лев Вячеславович, к.т.н., ведущий специалист Департамента «Программное обеспечение»

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

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

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

С точки зрения распределения функций управления, регулирования, сбора и обработки данных автоматизированные системы образуют следующие группы:

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

Среди распределённых и клиент-серверных систем в зависимости от характеристик коммуникационной инфраструктуры будем различать системы:

  • Работающие по быстрым и надёжным каналам связи (рисунок 1)
  • Использующие медленную и ненадёжную связь (рисунок 2).

Принимая во внимание распределение супервизорных функций между пользователями системы, получим ещё две группы автоматизированных систем:

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

В зависимости от степени ответственности можно выделить следующие автоматизированные системы:

  • Критичные к временной потере данных и управления (рисунок 1)
  • Некритичные к временной потере данных и управления (рисунок 2).

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

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

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

Рисунок 1 – АСУ ТП установки риформинга

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

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

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

Преимущества такого подхода налицо:

  • Общая база значений тегов позволяет автоматически отследить целостность и синхронность баз тегов на всех распределённых компонентах системы (контроллерах, серверах)
  • Единый язык и среда программирования даёт возможность с минимальными затратами на обучение в едином стиле разрабатывать технологические программы для контроллеров и серверов
  • Чёткое распределение функций между узлами системы, что позволяет легко контролировать их выполнение на каждом узле. К таким функциям относятся, например, сигнализация, ведение истории процесса, различные технологические алгоритмы сбора и обработки данных, алгоритмы регулирования
  • Обеспечение необходимого уровня надёжности системы за счет реализации сложных схем резервирования (контроллеров, связи, серверов и источников данных), а также использования внутреннего протокола обмена данными с контролем доставки команд управления.

Рисунок 2 – АИИС ТУЭ

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

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

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

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

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

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

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

Обычно выделяют клиентов двух видов:

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

Преимущества в использовании Web-клиента следующие:

  • Минимальные настройки и административные разрешения для работы в Intranet/Internet сетях
  • Легкая интеграция в общую информационную систему предприятия (web-портал)
  • Значительное снижение затрат на техническое обслуживание конечных АРМов, так как для функционирования клиента нужен только Web-браузер
  • Использование различных платформ, где возможно функционирование только web-браузера. Например, мониторинг/управление системой через наладонный или планшетный компьютер.

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

С приходом новых технологий, таких как ASPNET и SilverLight, Web-ориентированные SCADA набирают всё большую популярность.

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

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

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

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

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

  • Системы отчётов
  • Необходимых форматов импорта и экспорта данных
  • Возможности сохранения и ведения базы тегов в стандартной СУБД
  • Встроенной системы тревог и событий
  • Средств ведения трендов и архивирования истории изменения параметров
  • Развитых графических возможностей для визуализации
  • Скриптовой подсистемы
  • Возможности масштабирования системы на нужное количество тегов.

Успешный, многолетний опыт построения SCADA-систем в различных отраслях промышленности даёт нам право рекомендовать к применению программные средства, разработанные НПФ «КРУГ»:

В таблице 1 показаны примеры систем в различных областях промышленной автоматизации и выбранные для их реализации SCADA.

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

1. Прошин Д.И., Гурьянов Л.В. Проблемы выбора инструментальных средств построения SCADA-систем, ИСУП №1 2010 г.