OpenSCADAWiki: Doc/DAQ ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
English (1 Кб) English
Ukrainian (1 Кб) Українська

 (2 Кб) Страница заморожена, актуальная тут.


29366

Сбор данных в OpenSCADA

Автор: Роман Савоченко


Contents

Введение

Сбор данных SCADA(Supervisory Control and Data Acquisition)-системы является её неотъемлемой частью, которая занимается получением данных из источников различного происхождения. Природа данных, с которыми работает SCADA, характеризуется сигналами базовых типов значений (целое, вещественное, логическое и строка). Сигналы изменяются во времени и обладает историей, жизнью. В теории управления технологическими процессами (ТП) под сигналом понимается значение датчика установки ТП в коде АЦП, "сырой" сигнал или в реальном значении. Сигналы могут объединяться в группы по смысловой нагрузке, часто называемые параметрами. Например, развитые источники данных могут предоставлять структуры параметров с предопределённым набором связанных сигналов. Кроме непосредственного сбора данных в функции этого механизма также входит и передача воздействий на исполнительные устройства управления ТП; обычно это задвижки, насосы и регулирующие клапаны. В совокупности это оборудование получило название Устройство Сопряжения с Объектом (УСО).


Источники данных характеризуются большим разнообразием, которое можно условно разделить на три группы:


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


В терминах системы OpenSCADA предоставляются следующие объекты для обслуживания механизма сбора данных:


Для учёта особенностей различных устройств сбора данных, а также различных механизмов взаимодействия в OpenSCADA предусмотрена подсистема "Сбор данных", которая является модульной. В качестве модуля подсистемы выступает драйвер для сопряжения с источником данных отдельного типа. Каждый модуль может содержать конфигурацию нескольких устройств этого типа в виде объектов "Контроллер" системы OpenSCADA. Общая схема объектов подсистемы "Сбор данных" изображена на рисунке 1.


Схема подсистемы \'Сбор данных\'. (25 Кб)
Рис. 1. Схема подсистемы "Сбор данных".

1. Методы сбора данных

Учитывая различие свойств источников данных, а также возможные варианты взаимодействия, методы сбора данных можно разделить на простой синхронный, простой асинхронный, пакетный и пассивный.


В рассмотрении механизмов ниже будут участвовать следующие объекты:

1.1. Простой синхронный механизм сбора

Механизм характеризуется запросами к источнику данных синхронно с запросом к атрибуту параметра (рис.2). Данный механизм обычно применяется при работе с локальными источниками данных, характеризующимися низкой латентностью, т.е. задержкой в ответе на запрос. С помощью этого метода можно получить актуальные данные непосредственно с запросом, однако время запроса объекта будет включать время транспортировки и обработки запроса источником данных.


Диаграмма последовательности взаимодействия при синхронных запросах. (10 Кб)
Рис. 2. Диаграмма последовательности взаимодействия при синхронных запросах.

В соответствии с диаграммой выше мы получаем следующую последовательность запросов получения данных и их передачи:


В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных".

1.2. Простой асинхронный механизм сбора

Механизм характеризуется запросами к источнику данных независимо от запроса к атрибуту параметра (рис.3). Обычно запросы к источнику данных осуществляются периодически в собственной задаче опроса отдельно взятого контроллера и блоками по несколько сигналов. При этом запросом к атрибуту параметра возвращается значение, полученное последним сеансом связи с источником данных. Данный механизм обычно применяется при работе с удалёнными (сетевыми) источниками данных, характеризующимися высокой латентностью, то есть задержкой в ответе на запрос.


С помощью этого метода можно обеспечить оптимизацию временного ресурса, затраченного на один сигнал, и тем самым увеличить максимальное количество опрашиваемых сигналов за интервал времени опроса.


В качестве примера рассмотрим промышленный ПЛК Siemens S7-315 при опросе его по шине ProfiBus (1,5 Мбит/с). Среднее время обработки MPI-запроса этим контроллером составляет 30 мс. Если использовать синхронный механизм для каждого сигнала, т.е. один запрос на каждый сигнал, то в течении одной секунды мы сможем получить около 33 сигналов. А если применить асинхронный механизм, т.е. в одном MPI-пакете получать до 220 байт или 110 сигналов целочисленного типа на 16-разрядов, то мы сможем за одну секунду получить до 3630 сигналов. Как можно видеть, эффективность асинхронного механизма в данном случае составляет 110 раз, а именно значение максимальной ёмкости MPI-пакета.


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


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


Диаграмма последовательности взаимодействия при асинхронных запросах. (15 Кб)
Рис. 3. Диаграмма последовательности взаимодействия при асинхронных запросах.

В соответствии с диаграммой выше мы получаем следующую картину:


В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных".

1.3. Пакетный механизм сбора

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


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


При работе совместно с асинхронным механизмом история полученных сигналов обычно прямо помещается в архивы (рис. 4), а текущее значение атрибута параметра устанавливается в последнее значение пакета. Данная комбинация эффективна при сборе быстрых данных или при синхронизации архивов после потери связи с удалённым источником данных.


Диаграмма последовательности взаимодействия при асинхронных запросах в пакетного механизма. (16 Кб)
Рис. 4. Диаграмма последовательности взаимодействия при асинхронных запросах пакетного механизма.

В соответствии с диаграммой выше мы получаем следующее поведение пакетного механизма при асинхронных запросах:


В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных".

1.4. Пассивный механизм сбора

Пассивный механизм сбора данных характерен инициативой предоставления данных в SCADA-систему со стороны источника данных. Этот механизм является достаточно редким явлением, однако может иметь место в случае определённых условий или ограничений в возможности использования прямых механизмов сбора данных, рис. 5. Примером такой ситуации могут служить географически рассредоточенные системы сбора данных посредством мобильных сетей GPRS/EDGE. В таких сетях наделение клиентских узлов отдельными/реальными IP-адресами или формирование корпоративной мобильной сети может оказаться дорогим удовольствием, поэтому доступнее оказывается инициатива сеанса передачи данных с клиентских динамических IP-адресов на один реальный IP-адрес сервера SCADA-системы. Хотя возможна работа и через сетевую СУБД-посредника. Воздействия на модификацию передаются источнику данных в момент сеанса передачи данных источником.


Промежуточным вариантом является инициатива установки TCP-подключения от источника данных и типовые запросы далее от сервера по этому подключению, что входной транспорт OpenSCADA Transport.Sockets на данный момент поддерживает.


Диаграмма последовательности взаимодействия при пассивном механизме работы. (12 Кб)
Рис. 5. Диаграмма последовательности взаимодействия при пассивном механизме работы.

В соответствии с диаграммой выше мы получаем следующее поведение пассивного механизма:


В OpenSCADA такой механизм ещё не использован, однако принципиальная возможность его реализации в системе есть, например, через запись посредством стандартных протоколов "ModBus", "OPC-UA".

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 пользовательского программирования:


Общая структура компонентов среды прогр& (78 Кб)
Рис. 6. Общая структура компонентов среды программирования.

3. Логический уровень обработки данных

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


Учитывая такой разброс может возникнуть ситуация, когда информации в объекте параметра контроллера источника данных недостаточно для описания реального объекта ТП в целом и нужен производный объект более высокого уровня абстракции. Решением такой ситуации может быть формирование дополняющих параметров, что является ненаглядным и вносит путаницу. Более правильным решением является использование прослойки, так называемого "Логического уровня", выполняющего функции гибкого формирования параметров, контейнеров сигналов, необходимой структуры и включающего пост-обработку.


Функционально "Логический уровень" предназначен для предоставления в системе OpenSCADA механизма свободного формирования объектов параметров, контейнеров сигналов, нужной структуры.


Эксплуатационным назначением "Логического уровня" является:


Концепция "Логического уровня" основана на шаблонах параметров, для которых в подсистеме "Сбор данных" предусмотрен контейнер библиотек шаблонов (рис. 1). Каждая библиотека содержит шаблоны параметров, которые могут использоваться модулями подсистемы "Сбор данных" для реализации параметров на основе шаблонов. Модулями системы OpenSCADA, которые используют шаблоны в своей работе, являются:


Общий механизм работы "Логического уровня" на примере модуля LogicLev изображён на рисунке 7.


Механизм работы «Логического уровня» на примере модуля LogicLev. (28 Кб)
Рис. 7. Механизм работы "Логического уровня" на примере модуля LogicLev.

Исходя из изображения видно, что параметры контроллера логического уровня выполняют функцию отражения других параметров подсистемы "Сбор данных" (на примере параметров 1 и 4) и произвольное формирование параметров на основе шаблонов 1, 2 и других параметров подсистемы "Сбор данных" (на примере параметров 2, 3 и 5).


Структура параметров с шаблоном в основе имеет структуру, изображённую на рисунке 8.


Структура параметров, с шаблоном в основе. (15 Кб)
Рис. 8. Структура параметров, с шаблоном в основе.

Как можно видеть из структуры, параметр логического уровня состоит из объекта функции, атрибутов и конфигурации шаблона. Объект функции это экземпляр исполнения функции шаблона с набором входов/выходов и программой вычисления шаблона на одном из языков пользовательского программирования, обычно это Java-подобный язык пользовательского программирования модуля DAQ.JavaLikeCalc. Впрочем шаблон может быть вообще без программы, предоставляя только структуру проброса входов/выходов. Атрибуты в структуре изображают перечень атрибутов результирующего параметра в соответствии с шаблоном. Конфигурация в структуре предоставляет конфигурацию свойств шаблона и его внешних связей.


Логику работы логического уровня параметров можно записать следующим образом:


Шаблон параметров в целом предоставляет следующее:


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


Вкладка конфигурации шаблона параметров подсистемы "Сбор данных". (142 Кб)
Рис. 9. Вкладка конфигурации шаблона параметров подсистемы "Сбор данных".

Вкладкой входа/выхода шаблона параметра предусмотрены следующие свойства специализированного назначения: "Атрибут", "Доступ" и "Значение".


Свойство "Атрибут" выступает признаком отражения входа/выхода шаблона на результирующий атрибут параметра. Предусмотрены следующие варианты этого свойства:


Свойство "Доступ" выступает признаком, указывающим на использование входа/выхода функции шаблона в результирующей конфигурации шаблона на логическом уровне. Предусмотрены следующие варианты этого свойства:


Поле "Значение" описывает предустановленное значение для постоянных и шаблон конфигурации внешних связей. Шаблон конфигурации внешних связей используется в целях описания механизма группировки и автоматического распределения внешних связей. Структура шаблона конфигурации внешних связей специфична для каждого модуля подсистемы "Сбор данных", который использует механизм шаблонов. В случае с модулем логического уровня распределение производится над внешними атрибутами параметров с шаблоном конфигурации внешней связи вида: {Параметр}|{атрибут}. Где "Параметр" используется для объединения параметров и помещения на форму конфигурации, а атрибут для ассоциативного связывания атрибутов при назначении параметра.


В качестве примера использования шаблона на рис.10 приведём изображения параметра модуля логического уровня "F3". На рис.10 представлена вкладка "Конфигурация шаблона" для конфигурации, включая связывание, шаблона параметра. На рис.11 представлена вкладка "Атрибуты" с перечнем атрибутов и их значений, созданных посредством шаблона.


Вкладка "Конфигурация шаблона" параметра "F3" модуля логического уровня. (84 Кб)
Рис. 10. Вкладка "Конфигурация шаблона" параметра "F3" модуля логического уровня.

Вкладка "Атрибуты" параметра "F3" модуля логического уровня. (114 Кб)
Рис. 11. Вкладка "Атрибуты" параметра "F3" модуля логического уровня.

4. Резервирование источников данных

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


Горизонтальное и вертикальное резервирование. (44 Кб)
Рис. 12. Горизонтальное и вертикальное резервирование.

В случае с подсистемой "Сбор данных" системы OpenSCADA резервирование данных (рис.12) выполняет функции:


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


Настройка резервирования начинается с добавления резервных станций в список системных станций OpenSCADA на вкладке "Подсистема" подсистемы "Транспорты" (рис.13). Причём добавлять тут нужно не только резервные станции к текущей, но и саму эту текущую станцию с её внешним адресом, т.е. своеобразная петля. В дальнейшем эти настройки будут сохранены в общую БД резервированной системы, а сама БД с этого момента будет использоваться при создании всех резервных станций. Соответственно важно на этом этапе внести все нужные изменения в общую БД вокруг проекта в целом!


Вкладка "Подсистема" подсистемы "Транспорты". (69 Кб)
Рис. 13. Вкладка "Подсистема" подсистемы "Транспорты".

Далее на конкретной станции, с копией общей БД, настраиваем её специфические параметры во вкладке "Резервирование" главной страницы (рис.14), которые будут сохранены в конфигурационном файле.


Вкладка "Резервирование" главной страницы. (83 Кб)
Рис. 14. Вкладка "Резервирование" главной страницы.

После этого вся конфигурация резервирования сбора данных производится во вкладке "Резервирование" подсистемы "Сбор данных" (рис.15), а если установить параметр "Передача локальных первичных команд" (рис.14) то эта конфигурация, как и любая другая конфигурация общего характера, может осуществляться на одной из станций, а внесённые изменения попадут и на все резервные, конечно если они будут доступны.


Вкладка "Резервирование" подсистемы "Сбор данных". (129 Кб)
Рис. 15. Вкладка "Резервирование" подсистемы "Сбор данных".

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


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


Для объекта контроллера подсистемы "Сбор данных" предусмотрены режимы резервирования "Асимметричное" и "Только нарушения". Асимметричное резервирование работает с той конфигурацией контроллера удалённой станции, какая есть и не пытается её обобщать, для которой работают все ранее описанные функции и свойства резервирования. Резервирование "Только нарушения" предусматривает фактическую работу без резервирования, но с подавлением нарушений от резервного объекта контроллера с целью исключения дублирующих сообщений о нарушениях.

Ссылки

Referring pages: Doc
Doc/VCA/part4/part10
Doc/Vision


 
Files[Hide files/form]
2011-04-08 10:38:25    (30 Kb)  daq.odt Документ в формате OpenDocument
2009-05-20 09:28:54    (39 Kb)  daq.xmi UML: Диаграммы последовательности
2016-10-04 13:20:09    (129 Kb)  daq_rd.png Вкладка "Резервирование" подсистемы "Сбор данных".
2009-05-20 11:34:45    (24 Kb)  daq_red.odg Диаграмма: Горизонтальное и вертикально&
2011-10-24 15:29:55    (44 Kb)  daq_red.png Горизонтальное и вертикальное резервирование.
2009-03-04 17:10:59    (25 Kb)  daq_str.png Схема подсистемы \'Сбор данных\'.
2009-03-06 15:02:21    (4 Kb)  loglevel.dia Диаграмма: Механизм работы «Логического уровня» на примере модуля LogicLev.
2009-03-06 17:02:05    (28 Kb)  loglevel.png Механизм работы «Логического уровня» на примере модуля LogicLev.
2009-03-05 17:59:18    (16 Kb)  packasync.png Диаграмма последовательности взаимодействия при асинхронных запросах в пакетного механизма.
2009-03-06 11:00:16    (12 Kb)  passive.png Диаграмма последовательности взаимодействия при пассивном механизме работы.
2016-10-17 12:50:57    (142 Kb)  prmtmpl.png Вкладка конфигурации шаблона параметров подсистемы "Сбор данных".
2009-04-28 17:50:59    (78 Kb)  progcompon.png Общая структура компонентов среды прогр&
2009-03-05 11:04:38    (15 Kb)  simpleasync.png Диаграмма последовательности взаимодействия при асинхронных запросах.
2009-03-05 09:45:00    (10 Kb)  simplesync.png Диаграмма последовательности взаимодействия при синхронных запросах.
2009-03-06 17:03:39    (15 Kb)  str_prmtmpl.png Структура параметров, с шаблоном в основе.
2016-10-04 13:17:13    (83 Kb)  sys_rd.png Вкладка "Резервирование" главной страницы.
2016-10-04 12:41:44    (69 Kb)  tr_exthst.png Вкладка "Подсистема" подсистемы "Транспорты".
2016-10-04 12:05:11    (114 Kb)  wprm_a.png Вкладка "Атрибуты" параметра "F3" модуля логического уровня.
2016-10-04 12:03:09    (84 Kb)  wprm_tmpl.png Вкладка "Конфигурация шаблона" параметра "F3" модуля логического уровня.
There is no comment on this page. [Display comments/form]