Export translations

Settings

Group
Language
Format	Export for off-line translation Export in native format

{{DISPLAYTITLE:Документы/Сбор данных}}<languages/>
{{Info|* '''Автор:''' [[User:RomanSavochenko|Роман Савоченко]] }}

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

Источники данных характеризуются большим разнообразием, которое можно условно разделить на три группы:
* Источники "сырых" данных, предоставляющие код АЦП или уровни дискретных сигналов, а также включающие простейшую обработку. Обычно это модули рассредоточенного УСО или простейшие промышленные программируемые логические контроллеры (ПЛК).
* Мощные промышленные ПЛК, обладающие значительной вычислительной мощностью и возможностью формирования сложных параметров с различной структурой.
* Локальные или сопутствующие источники данных. Например, УСО в виде плат расширения, а также данные аппаратного и программного окружения в котором функционирует система.

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

В терминах OpenSCADA, предоставляются следующие объекты модели данных обслуживания механизма сбора данных:
* "Атрибут" — объект отражения данных сигнала, включает текущее значение определённого типа сигнала и доступ к истории изменения этих значений;
* "Параметр" — объект группы атрибутов со структурой, соответствующей особенностям отдельно взятого источника данных;
* "Объект контроллера" — объект отдельного устройства данных. Как правило это отдельный модуль УСО или устройство промышленного ПЛК.

Для учёта особенностей различных устройств сбора данных, а также различных механизмов взаимодействия, в OpenSCADA предусмотрена [[Special:MyLanguage/Documents/Program_manual#DAQ|подсистема "Сбор данных"]], которая является модульной. В качестве модуля подсистемы выступает драйвер сопряжения с источником данных отдельного типа. Каждый модуль может содержать конфигурацию нескольких устройств этого типа в виде объектов контроллера. Общая схема объектов подсистемы "Сбор данных" изображена на рисунке 1.

[[File:Oscada subsys daq str_ru.png|center|frame|Рис. 1. Схема подсистемы "Сбор данных".]]

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

В рассмотрении механизмов ниже будут участвовать следующие объекты:
* "ObjectSCADA" — любой объект SCADA-системы, обращающийся за значением сигнала, например, архивы и визуализаторы;
* "DAQParamAttribute" — атрибут параметра подсистемы "Сбор данных", выступающий посредником в доступе к значению сигнала источника данных;
* "DAQParamAttributeArch" — объект архива атрибута;
* "HardwarePLC" — объект источника данных, например, модули рассредоточенного УСО или промышленные ПЛК.

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

[[File:DAQ_simpleSync.png|center|frame|Рис. 2. Диаграмма последовательности взаимодействия при синхронных запросах.]]

В соответствии с диаграммой выше, мы получаем следующую последовательность запросов получения данных и их передачи:
* объект SCADA-системы шлёт запрос значения к объекту атрибута параметра '''DAQParamAttribute::getVal()''';
* объект атрибута параметра, получив запрос, шлёт его источнику данных '''HardwarePLC::valueRequest()''';
* источник данных, обработав запрос, возвращает результат;
* объект атрибута параметра, получив результат, возвращает его объекту SCADA-системы.

В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных":
* ''[[Special:MyLanguage/Modules/JavaLikeCalc|JavaLikeCalc]]'' — вычислитель на Java-подобном языке высокого уровня. В качестве источника данных выступает пользовательская программа на Java-подобном языке. Атрибуты параметров модуля синхронно обращаются к входам/выходам вычислительного контекста пользовательской функции.
* ''[[Special:MyLanguage/Modules/LogicLev|LogicLev]]'' — модуль логического уровня параметров сбора данных, детальнее о нём в разделе 3. В качестве источника данных этого модуля выступают другие параметры подсистемы "Сбор данных" и контекст исполнения шаблона параметров. Атрибуты параметров модуля синхронно обращаются к атрибутам других параметров, в режиме отражения параметров подсистемы "Сбор данных", или к входам/выходам контекста исполнения шаблона, в режиме работы по шаблону.
* ''[[Special:MyLanguage/Modules/BlockCalc|BlockCalc]]'' — вычислитель на языке блочных схем. В качестве источника данных выступает пользовательская блочная схема. Атрибуты параметров модуля синхронно обращаются к входам/выходам блоков блочной схемы.
* ''[[Special:MyLanguage/Modules/DAQGate|DAQGate]]'' — модуль отражения объектов контроллеров удалённых OpenSCADA-станций на локальную. В модуле реализован синхронный режим записи данных.
* ''[[Special:MyLanguage/Modules/ModBus|ModBus]]'' — модуль доступа к данным источников посредством семейства протоколов "ModBus". В модуле реализован синхронный режим записи данных.
* ''[[Special:MyLanguage/Modules/DiamondBoards|DiamondBoards]]'' — модуль доступа к данным PC/104 плат фирмы Diamond Systems. Платы PC/104 размещаются на ISA-шине, следовательно являются локальными и доступны сравнительно быстро. В режиме сбора данных не по прерыванию доступ к значениям АЦП осуществляется синхронно. Режим записи значения ЦАП всегда работает синхронно.

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

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

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

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

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

[[File:DAQ_simpleAsync.png|center|frame|Рис. 3. Диаграмма последовательности взаимодействия при асинхронных запросах.]]

В соответствии с диаграммой выше, мы получаем следующую картину:
* атрибут параметра, или вышестоящий объект контроллера, выполняет периодические запросы '''HardwarePLC::valueRequest()''' для получения значения сигнала или группы сигналов;
* полученные значения сигналов размещаются локально в атрибутах параметров;
* объект SCADA-системы шлёт запрос значения к атрибуту параметра '''DAQParamAttribute::getVal()''' и получает сохранённое локально значение предыдущего сеанса опроса источника данных.

В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных":
* ''[[Special:MyLanguage/Modules/DAQGate|DAQGate]]'' — модуль отражения объектов контроллеров удалённых OpenSCADA-станций на локальную. В модуле реализован асинхронный режим чтения данных.
* ''[[Special:MyLanguage/Modules/System|System]]'' — модуль доступа к данным окружения исполнения OpenSCADA. В модуле реализован асинхронный режим чтения данных.
* ''[[Special:MyLanguage/Modules/ModBus|ModBus]]'' — модуль доступа к данным источников посредством семейства протоколов "ModBus". В данном модуле асинхронный режим реализован как для чтения данных, так и для их записи (опционально) на ПЛК.
* ''[[Special:MyLanguage/Modules/SNMP|SNMP]]'' — модуль доступа к данным устройств сети посредством "Simple Network Management Protocol". В модуле реализован асинхронный режим чтения данных.
* ''[[Special:MyLanguage/Modules/Siemens|Siemens]]'' — модуль доступа к данным контроллеров фирмы Siemens серии S7. В данном модуле асинхронный режим реализован как для чтения данных, так и для их записи (опционально) на ПЛК.

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

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

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

[[File:DAQ_packAsync.png|center|frame|Рис. 4. Диаграмма последовательности взаимодействия при асинхронных запросах пакетного механизма.]]

В соответствии с диаграммой выше, мы получаем следующее поведение пакетного механизма при асинхронных запросах:
* атрибут параметра, или вышестоящий объект контроллера, выполняет периодические запросы '''HardwarePLC::valuesRequest()''' получения пакетов значений сигнала или группы сигналов;
* полученные пакеты значений сигналов помещаются в архив запросом '''DAQParamAttributeArch::setValues()''', а последнее значение пакетов размещается в атрибуте параметра;
* объект SCADA-системы шлёт запрос фрагмента архива к атрибуту параметра '''DAQParamAttribute::getValues()''', а тот перенаправляет запрос к архиву '''DAQParamAttributeArch::getValues()'''. В результате, возвращается фрагмент архива, доступный после предыдущего сеанса опроса источника данных;
* объект SCADA-системы шлёт запрос последнего значения к атрибуту параметра '''DAQParamAttribute::getVal()''' и получает сохранённое локально значение предыдущего сеанса опроса источника данных.

В OpenSCADA такой механизм реализуют следующие модули подсистемы "Cбор данных":
* ''[[Special:MyLanguage/Modules/DAQGate|DAQGate]]'' — модуль отражения объектов контроллеров удалённых OpenSCADA-станций на локальную. Реализует синхронный и асинхронный пакетный режимы отражения архивов удалённых OpenSCADA-станций.
* ''[[Special:MyLanguage/Modules/DiamondBoards|DiamondBoards]]'' — модуль доступа к данным PC/104 плат фирмы Diamond Systems. Платы PC/104 размещаются на ISA-шине, следовательно являются локальными и доступны сравнительно быстро. В режиме сбора данных по прерыванию осуществляется ожидание пакетов быстрых значений (до 200 кГц) за одну секунду (до 200000 значений в пакете) и последующее размещение данных пакетов в архивах атрибутов параметров DAQ.

=== {{Anch|PassiveAndInitiative|Пассивный механизм сбора и инициативные подключения}} ===
Пассивный механизм сбора характерен инициативой предоставления данных в SCADA-систему со стороны источника данных. Этот механизм является редким явлением однако может иметь место в случае определённых условий или ограничений в возможности использования прямых механизмов сбора данных, рисунок 1.4a. Примером такой ситуации могут служить географически рассредоточенные системы сбора данных посредством мобильных сетей GPRS/EDGE/3G/4G/... . Наделение всех узлов отдельными реальными и статическими IP-адресами, или формирование корпоративной мобильной сети, может оказаться дорогим удовольствием в таких сетях, поэтому доступнее оказывается инициатива сеанса передачи данных из-за динамических IP-адресов на один реальный IP-адрес сервера SCADA-системы. Воздействия на модификацию передаются источнику данных в момент сеанса передачи данных источником — читания.
Хотя тут возможны типовые запросы через VPN подключение от источника данных и работа через сетевую СУБД-посредника.

[[File:DAQ_passive.png|center|frame|Рис.1.4a. Диаграмма последовательности взаимодействия при пассивном механизме работы.]]

В соответствии с диаграммой выше, мы получаем следующее поведение пассивного механизма:
* объект источника данных осуществляет периодические сеансы связи с атрибутом параметра '''DAQParamAttributeArch::setVal()''' для передачи своих данных и получения команд воздействия;
* объект SCADA-системы шлёт запрос последнего значения атрибута параметра '''DAQParamAttribute::getVal()''' и получает сохранённое локально значение предыдущего сеанса связи источника данных.

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

[[file:at.png]] A special case is the initiative of the TCP-connection establishing from the data source and the standard requests do next by the server through the connection, that the input transports of [[Special:MyLanguage/Modules/Sockets|the module "Sockets"]] and [[Special:MyLanguage/Modules/SSL|the module "SSL"]] are currently supported. This mode is currently even the most popular!

OpenSCADA also supports the initiation of such connections itself, that is, it can act as a data source for "gray" and dynamic IP. So, the input transport of [[Special:MyLanguage/Modules/Sockets|the module "Sockets"]] and [[Special:MyLanguage/Modules/SSL|the module "SSL"]] in the mode 2 initiates the connection and then sends an identifying sequence and enters the normal mode of receiving requests from the host to which it is connected. [[file:at.png]] Regarding what is currently especially useful is the remote control of OpenSCADA stations in "gray" networks with such a connection.

[[File:Oscada_initCon.png|center|frame|Fig.1.4b. Initiative connection of the Data Sources.]]

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

В OpenSCADA могут быть реализованы интерфейсы программирования и виртуальных источников данных на основе различных языков, в отдельных модулях подсистемы "Сбор данных". На текущий момент доступны модули виртуальных вычислителей:
* Вычислитель на Java-подобном языке: [[Special:MyLanguage/Modules/JavaLikeCalc|JavaLikeCalc]];
* Блочный вычислитель: [[Special:MyLanguage/Modules/BlockCalc|BlockCalc]].

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

Модуль [[Special:MyLanguage/Modules/JavaLikeCalc|JavaLikeCalc]] предоставляет в OpenSCADA механизм создания динамических пользовательских функций и их библиотек на Java-подобном языке. Описание функции на Java-подобном языке заключается в обвязке параметров функции алгоритмом. Кроме этого, модуль наделен функциями непосредственных вычислений, путём создания вычислительных контроллеров с ассоциированной вычислительной функцией. Модулем предоставляется механизм прекомпиляции контекстно-зависимых функций, что используется для встраивания пользовательских алгоритмов непосредственно в контекст различных компонентов OpenSCADA, это, например, [[Special:MyLanguage/Documents/Program_manual#DAQ|шаблоны параметров подсистемы "Сбор данных"]] и [[Special:MyLanguage/Modules/VCAEngine|движок среды визуализации и управления (СВУ)]].

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

С целью наполнения API пользовательского программирования функциями, созданы следующие специализированные модули статических функций API пользовательского программирования:
* Библиотека функций системного API: [[Special:MyLanguage/Modules/FLibSYS|FLibSYS]];
* Библиотека стандартных математических функций: [[Special:MyLanguage/Modules/FLibMath|FLibMath]];
* Библиотека функций совместимости со SCADA Complex1: [[Special:MyLanguage/Modules/FLibComplex1|FLibComplex1]].

[[File:DAQ_progCompon_ru.png|center|frame|Рис. 6. Общая структура компонентов среды программирования.]]

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

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

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

Эксплуатационным назначением "Логического уровня" является:
* расширение сферы применения OpenSCADA за счёт увеличения гибкости описания параметров подсистемы "Сбор данных";
* сокращение трудозатрат на создание сложных автоматизированных систем.

Концепция "Логического уровня" основана на шаблонах параметров, для которых, в подсистеме "Сбор Данных", предусмотрен контейнер библиотек шаблонов (рис.1). Каждая библиотека содержит шаблоны параметров, которые могут использоваться модулями подсистемы "Сбор Данных" для реализации параметров на основе шаблонов. Модулями OpenSCADA, которые используют шаблоны в своей работе, являются:
* [[Special:MyLanguage/Modules/LogicLev|LogicLev]] — модуль реализации классической концепции "Логического уровня".
* [[Special:MyLanguage/Modules/ModBus|ModBus]] — модуль доступа к данным источников посредством семейства протоколов "ModBus". Кроме типа параметра прямого описания перечня регистров, модуль поддерживает и логический тип, где регистры "ModBus" описываются в связях шаблона.
* [[Special:MyLanguage/Modules/Siemens|Siemens]] — модуль сбора данных контроллеров фирмы Siemens серии S7. Благодаря высокой гибкости и функциональности контроллеров этой серии, которая позволяет формировать комплексные типы данных различной структуры, все параметры этого модуля работают по шаблонам.
* [[Special:MyLanguage/Modules/OPC_UA|OPC-UA]] — модуль доступа к данным источников посредством протокола "OPC-UA". Кроме типа параметра прямого описания перечня узлов, модуль поддерживает и логический тип, где узлы "OPC-UA" описываются в связях шаблона.

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

[[File:DAQ_loglevel_ru.png|center|frame|Рис. 7. Механизм работы "Логического уровня" на примере модуля "LogicLev".]]

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

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

[[File:DAQ_str_prmtmpl_ru.png|center|frame|Рис. 8. Структура параметров с шаблоном в основе.]]

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

Логику работы логического уровня параметров можно записать следующим образом:
* Параметр связывается с шаблоном, из которого получается структура атрибутов, в соответствии с функцией шаблона.
* Выполняется связывание объекта функции параметра с функцией из шаблона.
* Формируется структура связей в соответствии с шаблоном функции. Исходя из структуры связей формируется форма связывания параметра и пользователем устанавливаются связи.
* При доступе к атрибутам полученного параметра производится проверка на наличие прямой связи. В случае наличия прямой связи, запрос перенаправляется по этой связи, в противном случае, значение берётся из объекта функции параметра.
* Параллельно работает вычисление функции шаблона по объекту функции параметров. При этом, перед вычислением, производится чтение значений по связям, а после вычисления запись изменений по этим связям.

Шаблон параметров, в целом, предоставляет следующее:
* структуру входов/выходов функции шаблона;
* признаки конфигурации и связывания шаблона (константа, связь);
* предварительные значения конфигурации постоянных и шаблонов связей;
* признаки атрибутов результирующего параметра логического уровня, типов: не атрибут, атрибут с полным доступом, атрибут с доступом только на чтение; 
* механизм вычисления входов/выходов функции шаблонов языком пользовательского программирования OpenSCADA.

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

[[File:DAQ_prmtmpl_ru.png|center|frame|Рис. 9. Вкладка конфигурации шаблона параметров подсистемы "Сбор данных".]]

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

Свойство "Атрибут" выступает признаком отражения входа/выхода шаблона на результирующий атрибут параметра. Предусмотрены следующие варианты этого свойства:
* ''Не атрибут'' — вход/выход функции шаблона не отражается на атрибут;
* ''Только чтение'' — вход/выход функции шаблона отражается на атрибут с доступом только на чтение;
* ''Полный доступ'' — вход/выход функции шаблона отражается на атрибут с полным доступом.

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

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

{{Anch|LogicLevLnks|The further linking}} in general can be carried out by:
* general definition-selecting the address-attribute of the subsystem "DAQ"; for example, the link "LogicLev.experiment.Pi.var" or "prm:/LogicLev/experiment/Pi/var" performs the access of the parameter attribute to the other parameter attribute; sign "(+)" at the end of the address indicate about successful linking and presence of the target; for the object-type attributes there permissible hierarchical access to a specific property of the object, by specifying its path through the symbol '#', for example: "LogicLev.experiment.Pi.var#pr1.pr2" or "prm:/LogicLev/experiment/Pi/var#pr1.pr2"; in the path with the "prm:" prefix you can use items of the relativity "." and "..";
* definition of the specific address of a separate module of the subsystem "DAQ";
* direct setting a constant value in the format "'''val:Constant value'''";
* empty or erroneous address when the value by the link is set to '''EVAL'''.

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

[[File:DAQ_wprm_tmpl_ru.png|center|frame|Рис. 10. Вкладка "Конфигурация шаблона" параметра "F3" модуля логического уровня.]]

[[File:DAQ_wprm_a_ru.png|center|frame|Рис. 11. Вкладка "Атрибуты" параметра "F3" модуля логического уровня.]]

=== {{Anch|UserPrt|Концепция доступа к данным через пользовательский протокол}} ===
Следующим уровнем, основанным на Логическом Уровне, является концепция доступа к данным через пользовательский протокол, что реализуется или прямо в коде шаблона или как отдельный объект Пользовательского Протоколу в [[Special:MyLanguage/Modules/UserProtocol|модуле Protocol.UserProtocol]], где, на данный момент, также можно использовать DAQ-шаблоны.

<section begin=userPrt />Концепцию доступа к данным через пользовательский протокол можно изобразить как на рисунке 1.

[[File:UserPrtDevs_concept_ru.png|center|frame|Рис.1. Концепция доступа к данным через пользовательский протокол.]]

Как можно видеть с рисунка 1, взаимодействие с устройством происходит через некоторый транспорт на котором они физически базируются. Запрос к транспорту Вы можете отправить:
# Непосредственно с помощью функции системного API OpenSCADA объекта транспорта ''[[Special:MyLanguage/Documents/User_API#SYSTransport|string messIO( string mess, real timeOut = 0 );]]'', если протоколоспецифическая часть очень проста и данные Вам нужно лишь извлечь.
# Завёрнутый запрос данных ''req'', функцией ''[[Special:MyLanguage/Documents/User_API#SYSTransport|int messIO( XMLNodeObj req, string prt );]]'' и для протокола ''prt'', если протокольная часть достаточно сложная и уже представлена в OpenSCADA.
# Завёрнутый запрос данных специфический к пользователю с помощью функции ''[[Special:MyLanguage/Documents/User_API#SYSTransport|int messIO( XMLNodeObj req, "UserProtocol" );]]'' и реализации [[Special:MyLanguage/Modules/UserProtocol|пользовательского протокола]], если протокольная часть достаточно сложная и ещё отсутствует в OpenSCADA. Пользователь реализует тут саму протоколоспецифическую часть в [[Special:MyLanguage/Modules/UserProtocol|модуле UserProtocol]] и часть специфическую к данным в шаблоне для [[Special:MyLanguage/Modules/LogicLev|модуля Логического Уровня]] или непосредственно в процедуре контролера на внутреннем языке программирования [[Special:MyLanguage/Modules/JavaLikeCalc|модуля JavaLikeCalc]].
:: [[File:at.png]] Этот последний метод развит к возможности формирования протокольной части кода непосредственно в том-же коде шаблона, как отдельная встроенная функция через вызовом функции запроса первого метода, если нет необходимости повторного использования, или даже если такая необходимость есть и тут имеет смысл создание комплексного шаблона, который сможет объединять роль и выходного протокола, через его подключение также к модулю пользовательского протокола. И оно будет полностью храниться в одной библиотеке шаблонов.

[[file:at.png]] Прямая работа с выходным транспортом функции [[Special:MyLanguage/Documents/User_API#SYSTransport|string messIO( string mess, real timeOut = 0 );]] не предусматривает блокирования транспорта поза вызовом этой функции, а соответственно, для сложных протоколов с посылками ответа более чем в одном пакете, что предусматривает процесс "дожидания", не можно использовать общий транспорт, по которому возможна отправка пакетов различных протоколов или даже один, но в различных задачах (объектах контроллеров). Соответственно, если есть необходимость использования совместного транспорта, то размещайте параметры опроса по протоколу в одном объекте контроллера (задаче) или используйте [[Special:MyLanguage/Modules/UserProtocol|модуль пользовательского протокола]], к которому это замечание не имеет отношения, поскольку он осуществляет такое блокирование на время вызова процедуры обработки, как и остальные модульные протоколы OpenSCADA. <section end=userPrt />

Созданы следующие библиотеки с использованием концепции доступа к данным через пользовательский протокол:
* [[Special:MyLanguage/Libs/Devices|Библиотека промышленных устройств]]
* [[Special:MyLanguage/Libs/LowLevelDevices|Библиотека низкоуровневых сенсоров и чипов]]

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

[[File:DAQ_red_ru.png|center|frame|Рис. 12. Горизонтальное и вертикальное резервирование.]]

В случае с подсистемой "Сбор данных", резервирование данных (рис.12) выполняет функции:
* '''Резервирование механизма сбора данных'''. Обычно эта функция реализуется без особых механизмов, путём простого запуска параллельных резервных станций с одинаковой конфигурацией и работающих независимо. Однако, в случае выполнения станцией функции ПЛК, такое поведение недопустимо по причине одновременной выдачи управляющих воздействий и отсутствия синхронизации данных вычислителей.
* '''Компенсация потери данных на время простоя узла''' за счёт архива резервного. Предусмотрены два механизма компенсации. Первый и основной механизм осуществляет загрузку участков архива из резервной станции в момент запуска станции в целом или отдельных объектов контроллеров. Участок архива запрашивается с момента последней записи в локальном архиве и по текущее время. Глубина запроса, при этом, ограничивается указанием предельного времени в конфигурации резервирования. Второй, дополняющий механизм, осуществляет заполнение "дыр" в архиве значений в момент фактического запроса пользователя к этим данным. Такой подход, с одной стороны, позволяет осуществить прогнозируемую по времени синхронизацию при старте, а с другой стороны, фактически исключает потерю данных при условии работы хотя бы одной станции в течение всего рабочего времени.
* '''Распределение нагрузки по сбору данных между узлами'''. При создании сложных распределённых систем может оказаться важным вопрос прогнозирования и оптимизации общей производительности системы. С учётом таких задач, механизм резервирования предусматривает исполнение задач сбора данных отдельных источников (объектов контроллеров OpenSCADA) только на одной станции. При этом, задачи остальных станций переходят в режим синхронизации данных с исполняющей станцией. В случае потери связи с исполняющей станцией, запускается задача локального сбора данных. Предусмотрена, также, возможность оптимального распределение нагрузки исполнения задач сбора данных группы объектов контроллеров, между станциями.
* '''Оптимизация нагрузки на внешние источники данных''' за счёт запроса (обмена) данных у внешнего источника только одним узлом. На практике часто встречаются высоко-нагруженные источники данных, или интерфейсы доступа к источникам данных, для которых даже сбор данных одной станцией может быть проблемой и потребует снижения периодичности сбора, т.е. качества данных. Механизм резервирования, кроме распределения нагрузки между станциями по описанной выше схеме, позволяет снять дополнительную нагрузку на источник данных и его интерфейсы, тем самым повысив качество данных. Запись в атрибуты резервного объекта контроллера приводит к отправке запроса модификации на основной, т.е. — через основной.
* '''Предотвращение некоторого отличия данных на разных узлах''', связанное с несовпадением моментов времени при независимом сборе данных отдельными узлами, осуществляется путём получения данных у станции с активным объектом контроллера. В системах высокой отчётности с резервированием должно быть исключено, или сведено к минимуму, расхождение в данных на разных станциях, что подразумевает реальный сбор данных одной станцией и синхронизацию с этими данными остальных станций.

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

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

[[File:DAQ_tr_extHst_ru.png|center|frame|Рис. 13. Вкладка "Подсистема" подсистемы "Транспорты".]]

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

[[File:DAQ_sys_rd_ru.png|center|frame|Рис. 14. Вкладка "Резервирование" главной страницы.]]

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

[[File:DAQ_rd_ru.png|center|frame|Рис. 15. Вкладка "Резервирование" подсистемы "Сбор данных".]]

Задача обслуживания механизма резервирования запускается всегда и исполняется с периодичностью, установленной в соответствующем конфигурационном поле. Реальная работа по осуществлению резервирования осуществляется при наличии хотя бы одной резервной станции в списке станций и предполагает:
* Контроль за соединением с внешними станциями. В процессе контроля осуществляются запросы к удалённым станциям, за обновлением информации о них и проверки связи. В случае потери связи со станцией, повтор подключения к ней осуществляется через промежуток времени, указанный в конфигурационном поле интервала времени восстановления соединения. В поле "Жив", станции, отображается текущее состояние связи. В поле "Счётчик" представлено количество запросов, осуществлённых к удалённой станции, или же время, оставшееся до осуществления следующей попытки соединения с потерянной станции.
* Локальное планирование исполнения объектов контроллеров в резерве. Планирование осуществляется в соответствии с уровнями станций и предпочтениями исполнения объектов контроллеров.
* Вызов функции синхронизации данных локальных объектов контроллеров, работающих в режиме синхронизации данных из внешних станций.

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

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

== {{Anch|TimeStamp|Метка времени источника данных}} ==
Фактически все источники данных, которые поддерживаются OpenSCADA, в качестве метки времени оперативных-текущих данных используют время компьютера где работает OpenSCADA и осуществляется опрос этого источника данных, даже в случае возможности получения времени сервера или источника у источника данных, и часто даже в случае когда таким источником выступает другая станция-ПЛК из OpenSCADA.

Такой подход определён с нескольких причин, а именно:
* различение и выделение отличия времени оперативных значений источника данных и ПК сбора данных не имеет ни одной практической цели кроме диагностической с выявления самого расхождения времени, поскольку текущие данные архивируются в архив периодических значений, где метка времени так или иначе притягивается и округляется к этой периодичности, т.е. часть времени точнее за период данных архива теряется;
* редко какой источник данных вообще имеет часы реального времени, а когда и имеет то до него сразу ставится требование синхронизации времени с внешним источником образцового времени, что в свою очередь требует разрешения сложностей с прямым подключением GPS приёмника или доступом к NTP-серверу в интернет или локальной сети; согласно-же этого подхода образцовым временем становится время ПК сбора данных, даже когда он сам не синхронизирован, поскольку он один;
* метка времени источника данных может меняться с собственной периодичностью или это обновление вообще может быть апериодическим, что в случае использования этой метки при опросе приведёт к пробелам в архиве, и даже когда периодичности опроса-архивирования и обновления метки времени источника одинаковы такие пробелы будут иметь место из-за отсутствия синхронности, что придётся компенсировать уменьшением периодичности опроса и, соответственно, увеличением нагрузки на сеть и источник; итак это сделает архив мало полезным, хотя сейчас предоставляется возможность считать такие пробелы (проходные) не фактом отсутствия или ошибочностью данных.

На данный момент известен один способ, когда от метки времени источника данных есть практическая ценность, это работа с историей-архивом на стороне источника данных, когда при обнаружении пробелов в данных, например, на время отсутствия связи, вместо текущих-оперативных данных запрашивается участок истории-архива, который соответствует этому пробелу. И этот метод реализован в модуле [[Special:MyLanguage/Modules/DAQGate|DAQ.DAQGate]], при работе OpenSCADA на стороне источника данных или ПЛК.

== Links ==
* [[:File:Oscada_subsys_daq_str.odg|Diagram: Hierarchical structure of the subsystem "DAQ".]]
* [[:File:daq.xmi.gz|UML: Sequence diagrams of the subsystem "DAQ".]]
* [[:File:Oscada_initCon.odg|Diagram: Initiative connection of the Data Sources.]]
* [[:File:daq_loglevel.dia|Diagram: The mechanism of the "Logic Level" on the example of LogicLev module.]]
* [[:File:loglev_prm.dia|Diagram: Structure of the parameters, with a template in their basis.]]
* [[:File:daq_progcompon.dia|Diagram: The overall structure of the programming area components.]]
* [[:File:UserPrtDevs_concept.odg|Diagram: Conception of custom accessing to services and device's data.]]
* [[:File:daq_red.odg|Diagram: Horizontal and vertical redundancy.]]

Export translations

Views

Navigation menu

OpenSCADA

OpenSCADA Wiki

Search

Tools

MediaWiki

Personal tools