Сбор данных SCADA(Supervisory Control and Data Acquisition)-системы является её неотъемлемой частью, которая занимается получением данных из источников различного происхождения. Природа данных, с которыми работает SCADA, характеризуется сигналами базовых типов значений (целое, вещественное, логическое и строка). Сигналы изменяются во времени и обладает историей — жизнью. В теории управления технологическими процессами (ТП), под сигналом понимается значение датчика установки ТП в коде АЦП — "сырой" сигнал или в реальном значении — инженерный. Сигналы могут объединяться в группы по смысловой нагрузке, часто называемые параметрами или комплексным тегом. Например, развитые источники данных могут предоставлять структуры параметров с предопределённым набором связанных сигналов. Кроме непосредственного сбора данных, в функции этого механизма также входит и передача воздействий на исполнительные устройства управления ТП, обычно это: задвижки, насосы и регулирующие клапаны. Совокупно, это оборудование получило название — Устройство Сопряжения с Объектом (УСО).
Источники данных характеризуются большим разнообразием, которое можно условно разделить на три группы:
Разнообразие источников данных породило большой спектр механизмов доступа к ним. Локальные источники данных различаются интерфейсами программирования приложения (API), а сетевые источники, в свою очередь, транспортным и протокольным уровнями взаимодействия. В целом, это привело к тому, что добавление поддержки нового источника данных требует создание модуля сопряжения или драйвера. Учитывая же большое разнообразие источников, это крайне накладно и фактически нереально охватить весь спектр рынка таких устройств. Ситуация несколько упрощается с сетевыми источниками, благодаря наличию ряда стандартных и свободных протоколов взаимодействия, однако многие источники всё же используют собственные протоколы: закрытые коммерческие или протоколы, завязанные на закрытые механизмы коммерческих операционных систем (ОС).
В терминах OpenSCADA, предоставляются следующие объекты модели данных обслуживания механизма сбора данных:
Для учёта особенностей различных устройств сбора данных, а также различных механизмов взаимодействия, в OpenSCADA предусмотрена подсистема "Сбор данных", которая является модульной. В качестве модуля подсистемы выступает драйвер сопряжения с источником данных отдельного типа. Каждый модуль может содержать конфигурацию нескольких устройств этого типа в виде объектов контроллера. Общая схема объектов подсистемы "Сбор данных" изображена на рисунке 1.
Учитывая различные свойства источников данных, а также возможные варианты взаимодействия, методы сбора данных можно разделить на: простой синхронный, простой асинхронный, пакетный и пассивный.
В рассмотрении механизмов ниже будут участвовать следующие объекты:
Механизм характеризуется запросами к источнику данных синхронно с запросом к атрибуту параметра (рис.2). Данный механизм обычно применяется при работе с локальными источниками данных, характеризующимися низкой латентностью, т.е. задержкой в ответе на запрос. С помощью этого метода можно получить актуальные данные непосредственно с запросом, однако время запроса объекта будет включать время транспортировки и обработки запроса источником данных.
В соответствии с диаграммой выше, мы получаем следующую последовательность запросов получения данных и их передачи:
В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных":
Механизм характеризуется запросами к источнику данных независимо от запроса к атрибуту параметра (рис.3). Обычно, запросы к источнику данных осуществляются периодически, в собственной задаче опроса отдельно взятого контроллера и блоками по несколько сигналов. При этом, запросом к атрибуту параметра возвращается значение, полученное последним сеансом связи с источником данных. Данный механизм обычно применяется при работе с удалёнными (сетевыми) источниками данных, характеризующимися высокой латентностью, то есть задержкой в ответе на запрос.
С помощью этого метода можно обеспечить оптимизацию временного ресурса, затраченного на один сигнал, и тем самым увеличить максимальное количество опрашиваемых сигналов за интервал времени опроса.
В качестве показательного примера рассмотрим промышленный ПЛК "Siemens S7-315", при опросе его по шине ProfiBus (1,5 Мбит/с). Среднее время обработки MPI-запроса этим контроллером составляет 30 мс. Если использовать синхронный механизм для каждого сигнала, т.е. один запрос на каждый сигнал, то в течении одной секунды мы сможем получить около 33 сигналов. А если применить асинхронный механизм, т.е. в одном MPI-пакете получать до 220 байт или 110 сигналов целочисленного типа на 16-разрядов, то мы сможем за одну секунду получить до 3630 сигналов. Как можно видеть, эффективность асинхронного механизма в данном случае составляет 110 раз, а именно значение максимальной ёмкости MPI-пакета.
Недостатком асинхронного механизма является то, что запрос значения атрибута параметра возвращает неактуальное на момент запроса значение, а значение последнего сеанса опроса контроллера. Впрочем, если учесть, что источник данных может обновляться с периодичностью аппаратных ограничений АЦП, да и сами датчики могут иметь определённые ограничения в скорости реакции, то применение асинхронного механизма сбора может иметь серьёзные основания.
Применение асинхронного механизма для записи значений в ПЛК является достаточно редким явлением, поскольку запись значений обычно подразумевает влияние оператора на ТП. Оператор, по факту, достаточно редко вносит коррективы в процесс, следовательно запись можно выполнять синхронно. Однако, существуют ситуации, например, управление ТП регуляторами на SCADA-системе, выполняющей функции среды исполнения ПЛК.
В соответствии с диаграммой выше, мы получаем следующую картину:
В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных":
Пакетный механизм сбора характерен сбором данных каждого сигнала пакетом, включающим историю его изменения. Т.е. за один сеанс опроса получается несколько значений истории сигнала. Пакетный механизм работает совместно с синхронным и асинхронными механизмами.
В случае работы с синхронным механизмом, выполняется фактический переброс архива источника данных для оперативной работы в системе (рис. 2). Как и простой синхронный механизм, его желательно применять только на низколатентных источниках данных или с источниками, работа которых является сеансовой, например, в сфере коммерческого учёта для чтения значений счётчиков.
При работе совместно с асинхронным механизмом, история полученных сигналов обычно прямо помещается в архивы (рис. 4), а текущее значение атрибута параметра устанавливается в последнее значение пакета. Данная комбинация эффективна при сборе быстрых данных или при синхронизации архивов после потери связи с удалённым источником данных.
В соответствии с диаграммой выше, мы получаем следующее поведение пакетного механизма при асинхронных запросах:
В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных":
Пассивный механизм сбора характерен инициативой предоставления данных в SCADA-систему со стороны источника данных. Этот механизм является редким явлением, однако может иметь место в случае определённых условий или ограничений в возможности использования прямых механизмов сбора данных, рисунок 5. Примером такой ситуации могут служить географически рассредоточенные системы сбора данных посредством мобильных сетей GPRS/EDGE/3G/4G. В таких сетях, наделение всех клиентских узлов отдельными реальными и статическими IP-адресами или формирование корпоративной мобильной сети может оказаться дорогим удовольствием, поэтому доступнее оказывается инициатива сеанса передачи данных с клиентских динамических IP-адресов на один реальный IP-адрес сервера SCADA-системы. Воздействия на модификацию передаются источнику данных в момент сеанса передачи данных источником — читания. Хотя, тут возможны типовые запросы через VPN подключение от источника данных и работа через сетевую СУБД-посредника.
В соответствии с диаграммой выше, мы получаем следующее поведение пассивного механизма:
Промежуточным вариантом является инициатива установки TCP-подключения от источника данных и, далее осуществляются стандартные запросы по этому подключению от сервера, что входной транспорт модуля "Сокети" на данный момент поддерживает. Основной библиотекой предоставляется шаблон службы обработки ассоциативных выходных транспортов, создаваемых для входных подключений.
В случае когда хост, который инициирует подключение, имеет динамический адрес который не является "серым", т.е. по нему можно подключиться прямо, тогда инициативное подключение можно использовать только для получения обратного адреса, по которому прямо и подключаться, а в контроллере таких подключений осуществлять только обновление динамического адреса.
OpenSCADA также поддерживает инициацию таких подключений, т.е. может выступать в роли источника данных за "серым" и динамическим IP. Так, входной транспорт модуля "Сокети", в режиме 2, выступает инициатором подключения после чего отправляет идентифицирующую последовательность и переходит в обычный режим получения запросов от хоста к которому подключился.
Кроме сбора физических данных, актуальной является функция виртуального сбора данных. Виртуальные данные представляют собой данные, полученные внутри системы как независимо, так и на основе физических данных. Практически, механизмы формирования виртуальных данных реализуются совместно с механизмом пользовательских вычислений. В среде промышленных контроллеров и SCADA-систем используются различные языки программирования. В случае с контроллерами, в качестве таких языков часто используются языки низкого уровня (ассемблеры), однако, в последнее время, всё чаще используются языки высокого уровня (C, Pascal и другие), а также формальные языки МЭК 61131-3 (схемы потоков состояний SFC, блочные схемы FBD, релейные схемы LD и текстовые ST, IL). В случае со SCADA-системами, вычисления чаще обеспечиваются языками программирования высокого уровня и формальными языками.
В OpenSCADA могут быть реализованы интерфейсы программирования и виртуальных источников данных на основе различных языков, в отдельных модулях подсистемы "Сбор данных". На текущий момент доступны модули виртуальных вычислителей:
В ядро OpenSCADA интегрирован механизм пользовательских функций или API пользовательского программирования. Пользовательские функции могут предоставляться любым объектом программы, в том числе и модулями, в соответствии со своей функциональностью, тем самым предоставляя пользователю некий набор функций контроля за тем или иным объектом. Функции пользовательского API могут быть как статическими, т.е. реализующими фиксированную функциональность отдельного объекта, так и динамическими, т.е. формируемые пользователем под нужную ему задачу на внутреннем языке пользовательского программирования высокого уровня.
Модуль JavaLikeCalc предоставляет в OpenSCADA механизм создания динамических пользовательских функций и их библиотек на Java-подобном языке. Описание функции на Java-подобном языке заключается в обвязке параметров функции алгоритмом. Кроме этого, модуль наделен функциями непосредственных вычислений, путём создания вычислительных контроллеров с ассоциированной вычислительной функцией. Модулем предоставляется механизм прекомпиляции контекстно-зависимых функций, что используется для встраивания пользовательских алгоритмов непосредственно в контекст различных компонентов OpenSCADA, это, например, шаблоны параметров подсистемы "Сбор данных" и движок среды визуализации и управления (СВУ).
Модуль BlockCalc предоставляет в OpenSCADA механизм создания пользовательских вычислений, который основывается на формальном языке блочных схем. Языки блочного программирования основываются на понятии блочных схем и функциональных блоков. Причём, в зависимости от сущности блока, блочные схемы могут быть: логическими схемами, схемами релейной логики, моделью технологического процесса и другое. Суть блочной схемы состоит в том, что она содержит список блоков и связи между ними. С формальной точки зрения блок — это элемент (функция), который имеет входы, выходы и алгоритм вычисления. Исходя из концепции среды программирования, блок — это кадр значений, ассоциированный с объектом функции. Входы и выходы блоков нужно соединять для получения цельной блочной схемы.
С целью наполнения API пользовательского программирования функциями, созданы следующие специализированные модули статических функций API пользовательского программирования:
Выше мы отмечали, что тип источника данных может колебаться от "сырого" до комплексного. Под "сырым" подразумевается источник, который предоставляет только элементарные сигналы (целое, вещественное, логическое, строка, ...), причём отдельно. Под комплексным подразумевается источник, который группирует сигналы и, в параметре подсистемы "Сбор данных", предоставляет атрибуты дополнительного назначения, покрывающие практически все диагностические задачи, т.е. параметр является законченным объектом, не требующим дополнения.
Учитывая такой разброс, может возникнуть ситуация, когда информации в параметре контроллера от источника данных недостаточно для описания реального объекта ТП в целом и нужен производный объект более высокого уровня абстракции. Решением этой ситуации может быть формирование дополняющих параметров, что является ненаглядным и вносит путаницу. Более правильным решением является использование прослойки "Логического уровня", выполняющей функции гибкого формирования параметров-контейнеров сигналов необходимой структуры и включающей пост-обработку.
Функционально, "Логический уровень" предназначен для предоставления в OpenSCADA механизма свободного формирования параметров-контейнеров сигналов нужной структуры.
Эксплуатационным назначением "Логического уровня" является:
Концепция "Логического уровня" основана на шаблонах параметров, для которых, в подсистеме "Сбор Данных", предусмотрен контейнер библиотек шаблонов (рис.1). Каждая библиотека содержит шаблоны параметров, которые могут использоваться модулями подсистемы "Сбор Данных" для реализации параметров на основе шаблонов. Модулями OpenSCADA, которые используют шаблоны в своей работе, являются:
Общий механизм работы "Логического уровня", на примере модуля LogicLev, изображён на рисунке 7.
Исходя из этого изображения видно, что параметры контроллера логического уровня выполняют функцию отражения других параметров подсистемы "Сбор данных" (на примере параметров 1 и 4) и произвольное формирование параметров на основе шаблонов 1, 2 и других параметров подсистемы "Сбор данных" (на примере параметров 2, 3 и 5).
Структура параметров с шаблоном в основе имеет структуру, изображённую на рисунке 8.
Как можно видеть из структуры, параметр логического уровня состоит из объекта функции, атрибутов и конфигурации шаблона. Объект функции это экземпляр исполнения функции шаблона с набором входов/выходов и программой вычисления шаблона на одном из языков пользовательского программирования, обычно это Java-подобный язык пользовательского программирования модуля DAQ.JavaLikeCalc. Впрочем, шаблон может быть вообще без программы, предоставляя только структуру проброса входов/выходов. Атрибуты в структуре изображают перечень атрибутов результирующего параметра в соответствии с шаблоном. Конфигурация в структуре предоставляет конфигурацию свойств шаблона и его внешних связей.
Логику работы логического уровня параметров можно записать следующим образом:
Шаблон параметров, в целом, предоставляет следующее:
На рисунке 9 представлено изображение вкладки конфигурации шаблона параметров подсистемы "Сбор данных" в виде таблицы с конфигурацией входов/выходов и текста программы пользовательского программирования.
Вкладкой входы/выходы "ВВ" шаблона параметра предусмотрены следующие свойства специализированного назначения: "Атрибут", "Конфигурация" и "Значение".
Свойство "Атрибут" выступает признаком отражения входа/выхода шаблона на результирующий атрибут параметра. Предусмотрены следующие варианты этого свойства:
Свойство "Конфигурация" выступает признаком, указывающим на использование входа/выхода функции шаблона в результирующей конфигурации шаблона на логическом уровне. Предусмотрены следующие варианты этого свойства:
Поле "Значение" описывает предустановленное значение для постоянных и шаблонов внешних связей. Шаблон внешних связей используется в целях описания механизма группировки и автоматического распределения внешних связей. Структура шаблона внешних связей однакова в части подключения к атрибутам параметров подсистемы "Сбор данных" и расширяется специфическим форматом адреса отдельного модуля подсистемы "Сбора данных", который использует механизм шаблонов. Подключение к параметрам подсистемы "Сбор данных" — шаблон конфигурации внешней связи имеет вид {Параметр}|{атрибут}, где
Само дальнейшее связывание в целом может осуществляться:
В качестве примера использования шаблона на рисунке 10 приведено изображение параметра "F3" модуля логического уровня, где представлена вкладка "Конфигурация шаблона" для конфигурации шаблона параметра, включая связывание. На рисунке 11 представлена вкладка "Атрибуты" с перечнем атрибутов и их значений, созданных посредством шаблона.
Следующим уровнем, основанным на Логическом Уровне, является концепция доступа к данным через пользовательский протокол, что реализуется или прямо в коде шаблона или как отдельный объект Пользовательского Протоколу в модуле Protocol.UserProtocol, где, на данный момент, также можно использовать DAQ-шаблоны.
Концепцию доступа к данным через пользовательский протокол можно изобразить как на рисунке 1.
Как можно видеть с рисунка 1, взаимодействие с устройством происходит через некоторый транспорт на котором они физически базируются. Запрос к транспорту Вы можете отправить:
Этот последний метод развит к возможности формирования протокольной части кода непосредственно в том-же коде шаблона, как отдельная встроенная функция через вызовом функции запроса первого метода, если нет необходимости повторного использования, или даже если такая необходимость есть и тут имеет смысл создание комплексного шаблона, который сможет объединять роль и выходного протокола, через его подключение также к модулю пользовательского протокола. И оно будет полностью храниться в одной библиотеке шаблонов. Прямая работа с выходным транспортом функции string messIO( string mess, real timeOut = 0 ); не предусматривает блокирования транспорта поза вызовом этой функции, а соответственно, для сложных протоколов с посылками ответа более чем в одном пакете, что предусматривает процесс "дожидания", не можно использовать общий транспорт, по которому возможна отправка пакетов различных протоколов или даже один, но в различных задачах (объектах контроллеров). Соответственно, если есть необходимость использования совместного транспорта, то размещайте параметры опроса по протоколу в одном объекте контроллера (задаче) или используйте модуль пользовательского протокола, к которому это замечание не имеет отношения, поскольку он осуществляет такое блокирование на время вызова процедуры обработки, как и остальные модульные протоколы OpenSCADA.
Созданы следующие библиотеки с использованием концепции доступа к данным через пользовательский протокол:
Резервирование вообще, и источников данных в частности, служит для повышения общего уровня отказоустойчивости решения путём включения дублирующих узлов в совместную работу с основным узлом. В случае сбоя основного узла происходит подхват функций основного узла резервным. Часто, схема резервирования может работать и в режиме распределения нагрузки между совместно работающими узлами.
В случае с подсистемой "Сбор данных", резервирование данных (рис.12) выполняет функции:
Резервирование рекомендуется настраивать таким образом чтобы БД резервных станций сохранялись одинаковыми, что в дальнейшем позволит безболезненно копировать их, при восстановлении, на любую станцию и, соответственно, в резервной копии можно хранить только один набор БД. При этом, настройки, специфичные для отдельной станции, будут сохраняться в конфигурационном файле и можно будет легко конфигурировать и менять нужную станцию через выбор соответствующего конфигурационного файла.
Настройка резервирования начинается с добавления резервных станций в список станций OpenSCADA на вкладке "Подсистема" подсистемы "Транспорты" (Рис.13). Причём, добавлять тут нужно не только резервные станции к текущей, но и саму эту текущую станцию с её внешним адресом, т.е. своеобразная петля. В дальнейшем эти настройки будут сохранены в общую БД резервированной системы и сама БД с этого момента будет использоваться при создании всех резервных станций. Соответственно важно на этом этапе внести все нужные изменения в общую БД вокруг проекта в целом!
Далее, на конкретной станции с копией общей БД, настраиваем её специфические параметры во вкладке "Резервирование" главной страницы (Рис.14), которые будут сохранены в конфигурационном файле.
После этого вся конфигурация резервирования осуществляется во вкладке "Резервирование" подсистемы "Сбор данных" (Рис.15). Если установить параметр "Передача локальных первичных команд" (Рис.14) то эта конфигурация, как и любая другая общего характера, может осуществляться на одной из станций, а внесённые изменения попадут на все резервные, конечно если они будут доступны.
Задача обслуживания механизма резервирования запускается всегда и исполняется с периодичностью, установленной в соответствующем конфигурационном поле. Реальная работа по осуществлению резервирования осуществляется при наличии хотя бы одной резервной станции в списке станций и предполагает:
Для контроля за временем, затраченным на выполнение цикла обслуживания резервирования, предусмотрено поле статуса. При приближении реального времени выполнения к циклу задачи обслуживания резервирования, рекомендуется увеличить периодичность исполнения этой задачи!
Для объекта контроллера подсистемы "Сбор данных" предусмотрены режимы резервирования "Асимметричное" и "Только нарушения". Асимметричное резервирование работает с той конфигурацией контроллера удалённой станции, какая есть и не пытается её обобщать. Для этого режима работают все ранее описанные функции и свойства резервирования. Резервирование "Только нарушения" предусматривает фактическую работу без резервирования, но с подавлением нарушений от резервного объекта контроллера с целью исключения дублирующих сообщений о нарушениях.
Фактически все источники данных, которые поддерживаются OpenSCADA, в качестве метки времени оперативных-текущих данных используют время компьютера где работает OpenSCADA и осуществляется опрос этого источника данных, даже в случае возможности получения времени сервера или источника у источника данных, и часто даже в случае когда таким источником выступает другая станция-ПЛК из OpenSCADA.
Такой подход определён с нескольких причин, а именно:
На данный момент известен один способ, когда от метки времени источника данных есть практическая ценность, это работа с историей-архивом на стороне источника данных, когда при обнаружении пробелов в данных, например, на время отсутствия связи, вместо текущих-оперативных данных запрашивается участок истории-архива, который соответствует этому пробелу. И этот метод реализован в модуле DAQ.DAQGate, при работе OpenSCADA на стороне источника данных или ПЛК.
| Documents/DAQ/ru - GFDL | February 2022 | OpenSCADA 1+r2802 |