OpenSCADAWiki: Doc/ El Figure ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
This is an old revision of Doc/ElFigure from 2011-04-28 10:46:58..
English (1 Kb) English version?
Ukrainian (1 Kb) Українська версія?

Векторный графический редактор в OpenSCADA.

Автор: Максим Лысенко


Contents

Введение

SCADA системы ‑ это комплекс программных средств, применяющихся при создании автоматизированных систем управления (АСУ) промышленными объектами. В настоящее время основным элементом АСУ являются программируемые логические контроллеры, применение которых минимизирует участие человека в управлении техническими комплексами. Однако необходимость мониторинга и технологического процесса грамотными операторами-технологами остается. Для этого с помощью SCADA систем осуществляется связь контроллера с компьютером и предоставляется так называемый человеко-машинный интерфейс (HMI). При этом специалистам недостаточно получать численные значения тех или иных характеристик объекта (температуры, давления, расхода и т. д.). Опыт показывает, что наиболее информативной формой представления технологических процессов являются мнемосхемы ‑ совокупность сигнальных устройств и сигнальных изображений оборудования и внутренних связей контролируемого объекта, выполняемые на персональном компьютере. Для их создания можно использовать любой из существующих графических редакторов. Однако полученные таким образом мнемосхемы являются статическими и не отражают динамику изменения характеристик процесса, а следовательно, они неадекватны и неудобны для восприятия. Таким образом, одной из задач, стоящих перед разработчиками SCADA систем, является создание графического редактора для изображения объектов, характеристики которых могут быть динамически изменены.

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

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


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

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

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


file:simpleSync.png
Рис. 2. Диаграмма последовательности взаимодействия при синхронных запросах.

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


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

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

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


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


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


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


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


file:simpleAsync.png
Рис. 3. Диаграмма последовательности взаимодействия при асинхронных запросах.

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


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

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

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


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


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


file:packAsync.png
Рис. 4. Диаграмма последовательности взаимодействия при асинхронных запросах пакетного механизма.

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


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

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

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


Воздействия на модификацию передаются источнику данных в момент сеанса передачи данных источником.


file:passive.png
Рис. 5. Диаграмма последовательности взаимодействия при пассивном механизме работы.

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


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

2. Виртуальные источники данных

Кроме сбора физических данных актуальной является функция виртуального сбора данных. Виртуальные данные представляют собой данные, полученные внутри системы как независимо, так и на основе физических данных. Практически механизмы формирования виртуальных данных реализуются совместно с механизмом пользовательских вычислений. В среде промышленных контроллеров и SCADA-систем используются различные языки программирования. В случае с контроллерами в качестве таких языков часто используются языки низкого уровня (ассемблеры), однако в последнее время всё чаще используются языки высокого уровня (C, Pascal и другие), а также формальные языки МЭК 61131-3 (схемы потоков состояний SFC, блочные схемы FBD, релейные схемы LD и текстовые ST, IL). В случае со SCADA-системами вычисления чаще обеспечиваются языками программирования высокого уровня и формальными языками.


В системе OpenSCADA могут быть реализованы интерфейсы программирования и виртуальных источников данных на основе различных языков в отдельных модулях подсистемы "Сбор данных". На момент версии 0.6.3.2 доступны модули виртуальных вычислителей:


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


Модуль /Doc/JavaLikeCalc предоставляет в систему механизм создания динамических пользовательских функций и их библиотек на Java-подобном языке. Описание функции на Java-подобном языке сводится к обвязке параметров функции алгоритмом. Кроме этого модуль наделен функциями непосредственных вычислений путём создания вычислительных контроллеров с ассоциированной вычислительной функцией. Модулем предоставляется механизм прекомпиляции контекстно-зависимых функций, что используется для встраивания пользовательских алгоритмов непосредственно в контекст различных компонентов OpenSCADA. Например, это механизм шаблонов параметров подсистемы "Сбор данных" и движок среды визуализации и управления (СВУ).


Модуль /Doc/BlockCalc предоставляет в систему OpenSCADA механизм создания пользовательских вычислений. Механизм вычислений основывается на формальном языке блочных схем (функциональных блоков). Языки блочного программирования основываются на понятии блочных схем (функциональных блоков). Причём в зависимости от сущности блока блочные схемы могут быть: логическими схемами, схемами релейной логики, моделью технологического процесса и другое. Суть блочной схемы состоит в том, что она содержит список блоков и связи между ними. С формальной точки зрения блок - это элемент (функция), который имеет входы, выходы и алгоритм вычисления. Исходя из концепции среды программирования, блок - это кадр значений, ассоциированный с объектом функции. Входы и выходы блоков нужно соединять для получения цельной блочной схемы.


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


file:progCompon.png
Рис. 6. Общая структура компонентов среды программирования

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

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


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


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


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


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


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


file:loglevel.png
Рис. 7. Механизм работы "Логического уровня" на примере модуля LogicLev.

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


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


file:str_prmtmpl.png
Рис. 8. Структура параметров, с шаблоном в основе.

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


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


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


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


file:prmtmpl.png
Рис. 9. Вкладка конфигурации шаблона параметров подсистемы "Сбор данных".

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


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


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


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


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


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

file:wprm_a.png
Рис. 11. Вкладка "Атрибуты" параметра "F3" модуля логического уровня.

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

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


file:daq_red.png
Рис. 12. Горизонтальное и вертикальное резервирование.

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


Настройка резервирования начинается с добавления резервных станций в список системных станций OpenSCADA на вкладке "Подсистема" подсистемы "Транспорты" (рис.13). Далее вся конфигурация резервирования производится во вкладке "Резервирование" подсистемы "Сбор данных" (рис.14).


file:tr_extHst.png
Рис. 13. Вкладка "Подсистема" подсистемы "Транспорты".

file:daq_rd.png
Рис. 14. Вкладка "Резервирование" подсистемы "Сбор данных".

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


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


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

Ссылки

There are no referring pages


 
There are no files on this page.[Display files/form]
There is no comment on this page. [Display comments/form]