Документы/Руководство по программе

Данный документ является руководством программы с открытыми исходными текстами именуемую "OpenSCADA". OpenSCADA представляет собой открытую SCADA систему, построенную по принципам модульности, многоплатформенности и масштабируемости.

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

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

OpenSCADA может и применяться на/в:

• промышленных объектах в качестве полнофункциональной SCADA системы и телемеханике;
• динамических моделях, имитаторах и тренажерах технологических процессов в реальном времени;
• станках и промышленных роботах;
• системах сельско-хозяйственной диспетчеризации и управления, птичниках;
• встроенных и мобильных системах — окружениях исполнения Программируемого Логического Контролера (ПЛК), роботах, ...;
• мониторинге оборудования серверов;
• умных домах и автоматике зданий.

В качестве основной операционной системы (программной платформы) для разработки и использования выбрана ОС Linux, которая является оптимальным решением в вопросах:

• надёжности — большая доля серверов и кластеров работает на GNU/Linux;
• гибкости/масштабируемости — ввиду своей открытости и модульности позволяет строить решения под любые требования;
• доступности — благодаря использованию лицензии GPL это ПО является полностью свободной операционной системой, а при высокой квалификации пользователя и бесплатной;
• популярности, развитости, поддержке, распространённости — система активно развивается множеством энтузиастов, фирм и государственными учреждениями во всем мире и получает всё большую поддержку на пользовательском и корпоративном рынке.

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

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

Серверные конфигурации программы предназначены для выдачи управляющих воздействий, сбора, обработки, архивирования, протоколирования информации от различных источников, а также предоставления этой информации клиентам (UI, GUI, TUI ...). Модульная архитектура позволяет расширять функциональность сервера без его перегрузки.

Клиентские конфигурации могут строиться на основе различных графических библиотек (GUI/TUI ToolKits), как используя ядро программы и его модули (путём добавления к нему модуля пользовательского интерфейса), так и в качестве самостоятельного приложения, подключая ядро OpenSCADA как библиотеку.

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

1 Архитектура и функции

Про фактические функции и требования OpenSCADA Вы можете прочитать на странице "Функции и требования", а в этом документе мы рассмотрим общие функции и свойства программы.

Рис. 1. Блочная схема OpenSCADA.

1.1 Модульность

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

Модули OpenSCADA хранятся в динамических библиотеках. Каждая динамическая библиотека может содержать множество модулей различного типа. Наполнение динамических библиотек модулями определяется функциональной связностью самих модулей. Динамические библиотеки допускают горячую замену, что позволяет производить обновление отдельных частей программы в процессе функционирования. Метод хранения кода модулей в динамических библиотеках является основным для OpenSCADA, поскольку поддерживается практически всеми современными операционными системами(ОС). Однако это не исключает возможности разработки других методов хранения кода модулей.

На основе модулей реализованы следующие функциональные части OpenSCADA:

• базы данных;
• коммуникационные интерфейсы, транспорты;
• протоколы коммуникационных интерфейсов;
• источники данных и сбор данных;
• архивы-история (сообщений и значений);
• интерфейсы пользователя (GUI, TUI, WebGUI, speach, signal ...);
• дополнительные модули, специальные.

Управление модулями осуществляется подсистемой "Диспетчер модулей". Функциями подсистемы является: подключение, отключение, обновление и другие операции, связанные с модулями и библиотеками модулей.

1.2 Подсистемы

Архитектурно OpenSCADA делится на подсистемы. Подсистемы могут быть двух типов: обычные и модульные. Модульные подсистемы обладают свойством расширения посредством модулей. Каждая модульная подсистема может содержать множество модульных объектов. Например, модульная подсистема "Базы данных" содержит модульные объекты типов баз данных. Модульный объект является корнем внутри модуля.

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

• Безопасность.
• Диспетчер модулей.
• Базы данных (модульная).
• Транспорты (модульная).
• Транспортные протоколы (модульная).
• Сбор данных (модульная).
• Архивы-История (модульная).
• Интерфейсы пользователя (модульная).
• Специальные (модульная).

1.3 ПЛК и другие источники динамических данных, подсистема "Сбор данных"

Подсистема "Сбор данных" (Рис.1.3) предусмотрена для предоставления поддержки источников динамических данных, будь то: ПЛК, платы УСО, виртуальные источники и другое. В функции этой подсистемы входит предоставление полученных данных в структурированном виде — модель данных и обеспечение управления этими данными, например — модификация данных.

Рис. 1.3. Иерархическая структура подсистемы "Сбор данных".

Подсистема "Сбор данных" является модульной и, как следствие, содержит модульные объекты типов источников динамических данных. Например, OpenSCADA сейчас предоставляет более чем двадцать модулей и библиотечных элементов источников логических типов. Наиболее значимые и проработанные с которых:

• Вычислитель на Java-подобном языке;
• Логический уровень;
• Блочный вычислитель;
• Шлюз источников данных;
• Сбор данных ОС;
• ModBus;
• DCON клиент;
• Клиент OPC-UA;
• Сбор данных Siemens;
• MMS(IEC-9506);
• SNMP клиент;
• Оборудование ICP DAS;
• Diamond платы сбора данных.

Каждый тип источника нелогического типа реализуется в отдельном модуле, который может содержать множество источников (объектов контроллеров) и каждый этот источник обычно выполняется в отдельном потоке-задаче.

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

Отдельные типы источников данных сами могут продуцировать данные как полностью их генерируя, так и обрабатывая физические данные и даже полностью реализуя получение этих данных в окружении OpenSCADA и на её внутреннем языке. Такие источники данных называются логическими. Полностью логические источники данных представлены модулями: LogicLev и BlockCalc. Существует ряд модулей, которые объединяют в себе логические данные как результат непосредственной обработки физических: ModBus, Siemens и OPC-UA.

Источники динамических данных могут быть удалёнными, т.е. формироваться или получаться на удалённой станции OpenSCADA. Для связи с такими источниками данных используется модуль шлюзования DAQGate. Функцией этого типа источников данных является отражение источников данных удалённой OpenSCADA станции на локальную.

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

1.4 Базы данных, подсистема "Базы данных"

Для хранения данных программы повсеместно используются базы данных (БД). С целью унификации доступа и управления базами данных в OpenSCADA предусмотрена подсистема "Базы данных" (Рис.1.4). Для обеспечения поддержки различных БД/СУБД подсистема выполнена модульной.

Рис. 1.4. Иерархическая структура подсистемы "БД".

В роли модульного объекта, который содержится в подсистеме, выступает тип БД/СУБД, т.е. модуль подсистемы "Базы данных" практически содержит реализацию доступа к определённому типу БД. OpenSCADA предоставляет следующие наиболее значительные и проработанные модули: SQLite, MySQL, PostgreSQL, FireBird.

Тип БД/СУБД в свою очередь содержит перечень объектов отдельных БД этого типа, а объект БД содержит перечень объектов таблиц, которые и содержат данные в табличном виде.

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

Для организации централизованного доступа распределённой программы к единой БД предусматривается два способа. Первый это использование сетевых СУБД, например — MySQL. Второй способ это использование транспортного типа БД на локальных станциях, для доступа к единой центральной БД другой OpenSCADA станции, через пересылку запросов к БД на этой удалённой станции — не реализовано ещё в OpenSCADA.

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

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

1.5 Архивы и история, подсистема "Архивы-История"

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

Рис. 1.5. Иерархическая структура подсистемы "Архивы-История".

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

Особенностью архивов значений является их периодичность, которая определяется промежутком времени между двумя смежными значениями. Архивы значений применяются для архивирования истории непрерывных процессов. Поскольку процесс непрерывный то и архивировать его можно только путём введения понятия квантования опроса значений, иначе мы получим архивы бесконечных размеров, в соответствии с непрерывностью самой природы процесса. Кроме того, практически мы можем получить значения с периодом ограниченным самими источниками данных. Например, довольно качественные источники данных в промышленности редко позволяют получать данные с частотой более 1 кГц, и это без учёта самих датчиков которые имеют менее качественные частотные характеристики.

Для решения задач архивирования потоков данных в OpenSCADA предусмотрена подсистема "Архивы-История" (Рис.1.5), которая является модульной и позволяет вести архивы сообщений и значений. Модульным объектом, который содержится в подсистеме "Архивы-История", выступает тип архиватора. Тип архиватора определяет способ хранения данных т.е. хранилище — файловая система, СУБД. Каждый модуль подсистемы "Архивы-История" соответственно может реализовывать архивирование сообщений и значений, а сама подсистема может содержать множество архивов, которые обслуживаются различными модулями.

1.5.1 Сообщения

Сообщения в OpenSCADA характеризуются датой, уровнем важности, категорией и непосредственно текстом сообщения. Дата сообщения соответственно указывает на дату и время его создания. Уровень важности указывает на степень важности сообщения. Категория определяет адрес или условный идентификатор-ключ источника сообщения. Часто категория содержит полный путь к источнику сообщения в программе. Текст сообщения соответственно и несет главную смысловую нагрузку сообщения.

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

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

Уровней сообщений предусмотрено 8, но каждый из этих уровней, от 1(первого), может быть расширен подуровнями, т.е. фактически быть группой из 10 подуровней, что осуществляется простым добавлением цифры после основного уровня, например, 5 — это основной уровень, а 50...59 это расширения уровня 5. Что общее количество уровней устанавливает в 80. Семь основных уровней имеют названия, и соответствию которым желательно придерживаться:

• 0 — Отладка;
• 1[X] — Информация;
• 2[X] — Замечание;
• 3[X] — Предупреждение;
• 4[X] — Ошибка;
• 5[X] — Критически;
• 6[X] — Тревога;
• 7[X] — Авария.

Ввиду схожести природы сообщений и нарушений подсистема "Архивы-История" содержит буфер текущий нарушений, который содержит активные на текущее время нарушения с категорией сообщения в роли ключа-идентификатора нарушения. Доступ к перечню-буферу текущих нарушений осуществляется путём указания отрицательного значения уровня сообщений. Так, формирование сообщений с отрицательным уровнем -2 вызывает помещение этого сообщений в буфер активных нарушений с уровнем 2, а также дублирование его непосредственно в архиве сообщений (буфере общих сообщений). При формировании сообщения в такой-же категории, но с положительным уровнем — скажем 1, будет осуществлено удаление указанного нарушения из буфера нарушений, а само сообщений также попадёт в архив сообщений (буфер общих сообщений). Такой механизм позволяет одновременной вести учёт активных нарушений и протоколировать их прохождение в архиве сообщений. При запросе к архиву сообщений, указание положительного уровня осуществляет запрос к архиву сообщений (через общий буфер сообщений), а отрицательного к буферу-перечню текущих нарушений.

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

• Системные, генерируются объектами-узлами OpenSCADA:

КАТЕГОРИЯ: определяет типовой путь к узлу сообщения, например — "/sub_DAQ/mod_LogicLev/cntr_gen/", где:

• "/*/*" — типовой шаблон-признак системного сообщения на основе символа-разделителя элементов пути, который может быть непосредственно использован в фильтре категории для определения чисто архива системных сообщений.

ТЕКСТ: содержит путь наименований узла сообщения и само сообщение в формате "{NodeNmPath}: {message}", например — "AGLKS > Сбор Данных > LogicLev > gen: Запуск контроллера.".

• Шлюзованные, сообщения, которые были получены из иерархически низшей станции OpenSCADA (вроде ПЛК) или передано высшей станцией:

КАТЕГОРИЯ: в начало категории полученного сообщения добавляется идентификатор объекта контроллера модуля DAQ.DAQGate, который осуществил получение, например — "loop:alModBus:testTCP" или "TopStat(DAQCntr):alModBus:testTCP", где:

• "loop:*" — типовой шаблон-признак удалённого нижшего сообщения на основе идентификатора объекта контроллера модуля DAQ.DAQGate, который может быть непосредственно использован в фильтре категории для определения исключительно архива удалённых сообщений этого источника;
• "TopStat(DAQCntr):*" — типовой шаблон-признак удалённого высшего сообщения на основе названия проекта (или идентификатора) TopStat и идентификатора объекта контроллера модуля DAQ.DAQGate, который может быть непосредственно использован в фильтре категории для определения исключительно архива удалённых сообщений этого источника.

• Унифицированные структуры с источником данных в категории, генерируются источником данных или его процедурами с помощью функции messSet() API OpenSCADA и пользовательского API:

КАТЕГОРИЯ: определяет ID-адрес источника нарушения в формате "{ID}{ModId}:{CntrId}[.{PrmId}][:{SpecPrms}]", где:

• ID — двухсимвольный идентификатор структуры;
• ModId — идентификатор модуля;
• CntrId — идентификатор объекта контроллера;
• PrmId — идентификатор параметра;
• SpecPrms — специфические параметры структуры ID.

• Нарушение, генерируется источником данных или его процедурами с помощью функции alarmSet() API OpenSCADA и пользовательского API:

КАТЕГОРИЯ: определяет ID-адрес источника нарушения в формате "al{ModId}:{CntrId}[.{PrmId}]", например — "alLogicLev:gen.F_PP1", где:

• "al*" — типовой шаблон-признак сообщения нарушения на основе двух первых символов слова "alarm", который может быть непосредственно использован в фильтре категории для определения чисто архива сообщений.

ТЕКСТ: "{CntrNm} > {PrmNm}: {MessText}", например — "Общестанционка > F_PP1: Расход газа через диафрагму PP1: НОРМА", где:

• CntrNm — название объекта контроллера;
• PrmNm — название параметра;
• MessText — текст сообщения, которое имеет подструктуру "{Viol}: {Value}[: {QuietTime}[: {NormTime}[: {Comment}]]]", где:

• Viol — описание нарушения, которое отдельные кадры, вроде Main.alarmsAct и Main.alarmsSt, могут расширять пользовательскими полями в форме "[[{CustFld0} => {CustFld1} => ... => {CustFldN}]]";
• Value — значение нарушения;
• QuietTime — время подтверждения (квитации);
• NormTime — время возврата к состоянию НОРМА, устанавливается тут после квитации-возврата сообщения уже в НОРМА;
• Comment — комментарий к этому случаю.

• Действия пользователя-оператора с источником данных, генерируются процедурой виджетов при определении действий пользователя-оператора, которые должны быть зафиксированы в протоколе пользователя-оператора и когда доступнен объект параметра источника данных:

КАТЕГОРИЯ: определяет пользователя и характерный источник (обычно параметр подсистемы "Сбор данных") для которого осуществлено действия, в формате "OP{ModId}:{CntrId}[.{PrmId}]:{user}", например — "OPLogicLev:gen.PC_PCV1:roman", где:

• "OP*" — типовой шаблон-признак сообщения действия пользователя-оператора на основе двух первых символов слова "operator", который может быть непосредственно использован в фильтре категории для определения чисто архива действий оператора.

TEXT: такое самое как и при структуре "Действия пользователя-оператора".

• Действия пользователя-оператора, генерируются процедурой виджетов при определении действий пользователя-оператора, которые должны быть зафиксированы в протоколе пользователя-оператора:

КАТЕГОРИЯ: определяет пользователя и характерный источник (обычно параметр подсистемы "Сбор данных") для которого осуществлено действия, в формате "OP:{user}:{src}", например — "OP:roman:PC КРД1", где:

• "OP:*" — типовой шаблон-признак сообщения действия пользователя-оператора на основе двух первых символов слова "operator", который может быть непосредственно использован в фильтре категории для определения чисто архива действий оператора;
• user — пользователь OpenSCADA;
• src — характерный источник, обычно параметр подсистемы "Сбор данных", при необходимости дополненный иерархией DAQ-параметров до объекта контроллера.

ТЕКСТ: описание действия в формате "{src} : {name} : [{oldVal}] : {newVal}", например — "'PC КРД1'. Задание : Регулятор давления на входе КС : 5.8 : 6.0", где:

• src — название источнике, обычно объекта параметра с детализацией, и при необходимости дополненный иерархией DAQ-параметров до объекта контроллера;
• name — название источника, обычно объекта параметра;
• oldVal — старое значение, может отсутствовать;
• newVal — новое значение или действие.

• Значение в сообщении — измеренные значения, которые введены вручную, что первично внедрено в кадре документа "Ручной отчёт месячных значений (docRepYear)":

КАТЕГОРИЯ: определяет ID источника SrcID в формате "val{SrcID}", где:

• "val*" — типовой шаблон-признак значения, который может быть непосредственно использован в фильтре категорий для определения чисто значения в сообщениях;
• SrcID — идентификатор источника.

ТЕКСТ: название Name и значение Value параметра в формате "{Name}: {Value}".

• Исполнение рецептов — генерирует сообщения действий в течении исполнения рецепта на предмет:

КАТЕГОРИЯ: определяет идентификатор пользовательского рецепта-программы ProgNM в формате "uprg{ProgNM}", где:

• "uprg*" — типовой шаблон-признак пользовательского рецепта-программы, который может быть непосредственно использован в фильтре категории для определения чисто пользовательских рецептов-программ;
• ProgNM — имя рецепта-программы.

ТЕКСТ: описание действия в формате "{ActDescr} "{ProgNM}" : {StartTm} : {ActTm}", где:

• ActDescr — описание действия:

• "Текущий узел отсутствует";
• "Прерванный пользователем сеанс программы";
• "Прерванный ошибкой сеанс программы";
• "Успешный сеанс программы".

• ProgNM — имя рецепта-программы;
• StartTm — время запуска рецепта-программы, в формате "2020-03-14 16:05:01";
• ActTm — время действия рецепта-программы, в формате "2020-03-14 16:05:52".

1.5.2 Значения

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

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

Для организации удалённых архиваторов в распределённых конфигурациях используется транспортный тип архиватора, на данный момент не реализовано в OpenSCADA. Функцией транспортного типа архиваторов является отражение удалённого центрального архиватора OpenSCADA в локальной конфигурации. Как следствие, архиваторы транспортного типа выполняют передачу данных между локальной конфигурацией и архиватором удаленной конфигурации программы, скрывая от подсистем локальной конфигурации реальную природу архиватора.

1.6 Коммуникации, подсистемы "Транспорты" и "Транспортные протоколы"

Поскольку OpenSCADA является высоко-масштабируемой то поддержка коммуникаций должна быть достаточно гибкой, для чего она реализована в подсистемах "Транспорты" и "Транспортные протоколы" (Рис.1.6), которые являются модульными.

Рис. 1.6. Иерархическая структура подсистемы "Транспорты" и "Протоколы".

Подсистема "Транспорты" предназначена для обеспечения обмена неструктурированными данными между OpenSCADA и внешними системами, в роли которых также могут выступать удалённые станции OpenSCADA. Под неструктурированными данными подразумевается поток символов определённой длины. Модульным объектом, который содержится в подсистеме "Транспорты", выступает тип транспорта, который и определяет механизм передачи неструктурированных данных. Например, это могут быть и есть:

• сокеты (TCP/UDP/UNIX);
• последовательные интерфейсы;
• шифрованные каналы.

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

Подсистема "Транспортные протоколы" предназначена для структуризации данных, полученных от подсистемы "Транспорты", является продолжением подсистемы "Транспорты", от чего имеет такое название, и осуществляет функции проверки структуры и целостности полученных данных. В глобальной нотации, эта подсистема содержит и реализует КОММУНИКАЦИОННЫЕ протоколы! Для указания протокола, вмести с которым должен работать транспорт, предусмотрено специальное конфигурационное поле. Модульным объектом, который содержится в подсистеме "Протоколы", является сам протокол. Например, транспортными протоколами могут быть и есть:

• собственный протокол OpenSCADA;
• ModBus;
• OPC-UA;
• DCON;
• протокол передачи гипертекста (HTTP);
• пользовательские протоколы, которые реализуются в самой OpenSCADA на логическом уровне, и который, с развитием внутреннего языка, стал приоритетным.

Полную последовательность сеанса входной связи для типовых протоколов режима "запрос-ответ" можно записать следующим образом:

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

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

Transports have a possibility to holding additional parameters, whose can be parameters of used protocols, that is protocols can be individually configured to each connection. [PLAN] In further this function will be used for the wrapping protocols.

Благодаря стандартному доступу к транспортам в OpenSCADA, можно легко менять способ обмена данными не затрагивая самих программ, которые обмениваются. Например, в случае локального обмена, можно использовать более быстрый транспорт на основе UNIX-сокетов, а в случае обмена через интернет и локальную сеть использовать TCP- или UDP-сокеты.

1.7 Интерфейсы пользователя, подсистема "Интерфейсы пользователя"

SCADA-системы, как класс, предусматривают наличие интерфейсов пользователя. В OpenSCADA для предоставления пользовательских интерфейсов предусмотрена подсистема "Пользовательские интерфейсы" под которой предусматривается не только среда визуализации, с которой должен работать конечный пользователя, но и всё, что имеет отношение к пользователю, например:

• Среда визуализации: Движок Среды Визуализации, визуализаторы Qt и Web;
• Конфигураторы: Qt и Web;
• Сигнализаторы.

Подсистема "Пользовательские интерфейсы" является модульной и её модульным объектом выступает собственно конкретный интерфейс пользователя. Модульность подсистемы позволяет создавать различные интерфейсы пользователя на разных GUI/TUI библиотеках и использовать наиболее оптимальное решения в конкретно взятом случае, например, для среды исполнения программируемых логических контроллеров можно использовать конфигураторы и визуализаторы на основе Web-технологий (WebCfg, WebCfgD, WebVision, WebUser), а в случае стационарных рабочих станций использовать те-же конфигураторы и визуализаторы, но на основе библиотек вроде Qt (QTCfg, Vision).

1.8 Безопасность программы, подсистема "Безопасность"

OpenSCADA является разветвлённой программой, которая состоит из десятка подсистем и может включать множество модулей. Следовательно предоставление всем неограниченного доступа к этим ресурсам является как минимум неосторожным. Для разграничения доступа в OpenSCADA предусмотрена подсистема "Безопасность" основными функциями которой является:

• хранение учётных записей пользователей и групп пользователей;
• аутентификация пользователей;
• проверка прав доступа пользователя к тому или иному ресурсу.

1.9 Управление модулями, подсистема "Диспетчер модулей"

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

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

1.10 Непредусмотренные возможности, подсистема "Специальные"

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

• тесты OpenSCADA и её модулей;
• библиотеки функций пользовательского программирования: функции системного API, математические функции.

1.11 Функции, объектная модель и среда программирования пользователя

Современная SCADA система должна содержать механизмы которые предоставляют возможность программирования на пользовательском уровне, т.е. — среду программирования пользователя. OpenSCADA содержит такое окружение и с его помощью можно реализовывать:

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

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

• объектная модель;
• модули библиотек функций;
• внутренние языки программирования, на данный момент:

JavaLikeCalc, BlockCalc;

• динамические вычисления: объекты вычислительных контроллеров подсистемы "Сбор данных", процедуры и протоколы сбора данных уровня пользователя, процедуры виджетов "Среды Визуализации и Управления" и другое.

Модули библиотек функций предоставляют статические функции определённой направленности, которые расширяют объектную модель программы и представляют собой интерфейс доступа к средствам модуля на уровне пользователя. Например, "Среда Визуализации и Управления" может предоставлять функции для выдачи различных сообщений, используя которые пользователь может реализовывать интерактивные алгоритмы взаимодействия с программой. Библиотеки функций в целом могут реализовываться как набором функций фиксированного типа — статические, так и функциями, которые допускают свободную модификацию и дополнение — динамические.

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

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

2 SCADA системы и их структура

Рис. 2. Иерархическая SCADA-система.

SCADA (Supervisory Control And Data Acquisition) в общем виде имеют распределённую архитектуру вроде изображённой на рисунке 2. Элементы SCADA систем, в смысле программного обеспечения, выполняют следующие функции:
Сервер сбора: представляет собой задачу или группу задач, занимающихся сбором данных из источников данных, или же сам выступает в роли источника данных. В задачи сервера входит:

• получение и/или формирование данных;
• обработка данных;
• обслуживание запросов на доступ к данным;
• обслуживание запросов на модификацию данных.

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

• архивирование или ведение истории данных SCADA-систем;
• обслуживание запросов на доступ к архивным данным или истории;
• импорт/экспорт архивов-истории.

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

• архивирование или ведение истории сообщений SCADA-систем;
• обслуживание запросов на доступ к архивным сообщениям или истории;
• импорт/экспорт архивов-истории.

Сервер сигнализации: представляет собой задачу или группу задач, выполняющих функции сервера протоколирования в отношении узкой категории сообщений сигнализации.
Рабочее место оператора: представляет собой постоянно функционирующее GUI(Grafical User Interface) приложение, выполненное в одномониторном, многомониторном или панельном режиме и выполняющее функции:

• предоставление пользовательского интерфейса для контроля за состоянием технологического процесса;
• предоставление возможности формирования управляющих воздействий;
• предоставление возможности изучения и анализа истории технологического процесса;
• предоставление инструментария для формирования отчётной документации.

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

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

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

• предоставление пользовательского интерфейса для контроля за состоянием технологических процессов;
• предоставление инструментария для изучения и анализа истории технологических процессов как непосредственно с активных серверов, так и на основе отдельных архивов;
• предоставление инструментария для формирования отчётной документации.

Рабочее место технолога: полностью включает в себя функции рабочего места оператора плюс модели технологических процессов (без непосредственной связи с технологическим процессом).
Рабочее место технолога-программиста: полностью включает в себя функции рабочего места технолога плюс инструментарий для создания моделей технологических процессов.

3 Варианты конфигурации и использования

3.1 Простое серверное подключение

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

• опрос источников данных (контроллеров);
• архивирование значений параметров источников данных;
• обслуживание клиентских запросов на получение различных данных сервера;
• предоставление конфигурационного WEB-интерфейса;
• удалённая конфигурация из OpenSCADA, посредством Qt или другого локального интерфейса.
• вторичное регулирование — регулирование в объектах вычислительных контроллеров;
• моделирующие, корректирующие и дополняющие в объектах вычислительных контроллеров.

Рис. 3.1. Простое серверное подключение.

3.2 Дублированное серверное подключение

Для повышения надёжности и производительности OpenSСADA допускает множественное резервирование (Рис.3.2), при котором источники данных (контроллеры) и архивы-история одного экземпляра отражаются в другом. При использовании подобной конфигурации возможно распределение нагрузки опроса/вычисления по различным станциям. Данная конфигурация позволяет выполнять функции:

• опрос источников данных (контроллеров);
• архивирование значений параметров источников данных;
• обслуживание клиентских запросов на получение различных данных сервера;
• резервирование параметров источников данных;
• резервирование архивов-истории;
• распределение нагрузки опроса по серверам;
• предоставление конфигурационного WEB интерфейса;
• вторичное регулирование — регулирование в объектах вычислительных контроллеров;
• моделирующие, корректирующие и дополняющие вычисления в объектах вычислительных контроллеров с возможностью распределения нагрузки по серверам.

Рис. 3.2. Дублированное серверное подключение.

3.3 Дублированное серверное подключение на одном сервере

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

Рис. 3.3. Дублированное серверное подключение на одном сервере.

3.4 Клиентский доступ посредством Web-интерфейса. Место руководителя

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

• опрос сервера на предмет получения данных визуализации и конфигурации;
• визуализация данных в доступном для понимания виде;
• формирование протоколов, отчётов;
• манипуляция параметрами, допускающими изменение.

Рис. 3.4. Клиентский доступ посредством Web-интерфейса. Место руководителя.

3.5 Автоматизированное рабочее место (место руководителя/оператора)

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

• опрос сервера на предмет обновления текущих значений;
• визуализация опрошенных данных в доступном для понимания виде;
• формирование протоколов и отчётов;
• манипуляция параметрами, допускающими изменения.

Рис. 3.5. Автоматизированное рабочее место (место руководителя/оператора).

3.6 АРМ с сервером сбора и архивирования на одной машине (место оператора, модель-тренажёр ...)

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

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

Рис. 3.6. АРМ с сервером сбора и архивирования на одной машине (место оператора, модель-тренажер ...).

3.7 Простейшее смешанное подключение (модель, демонстрация, тренажёр, конфигуратор ...)

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

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

Рис. 3.7. Простейшее смешанное подключение (модель, демонстрация, конфигуратор ...).

3.8 Устойчивая распределённая конфигурация

Данная конфигурация является одним из вариантов устойчивого-надёжного соединения (Рис.3.8). Устойчивость достигается путём распределения функций по:

• серверам опроса;
• центральному серверу архивирования и обслуживания клиентских запросов;
• клиентам: АРМы и WEB-клиенты.

Рис. 3.8. Устойчивая распределённая конфигурация.

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

Центральный сервер архивирования и обслуживания клиентских запросов выполняет функцию централизованного сбора и обработки параметров серверов опроса и их значений. Доступ к серверам опроса выполняется посредством одного из доступных в OpenSCADA транспортов+протоколов (на примере это Sockets). Для предоставления единого интерфейса доступа к параметрам и контроллерам используется модуль DAQGate, который отражает данные серверов опроса на структуру локальных параметров сбора данных.

Для выполнения внутренних вычислений и дополнительного анализа параметров используются объекты вычислительных контроллеров.

Для разностороннего и глубокого архивирования используются различные модули архивов-истории.

Для доступа клиентов к серверу используются доступные у OpenSCADA сетевые транспорты, на примере — Sockets; и транспортные протоколы, на примере — протокол OpenSCADA "SelfSystem".

Конфигурация центрального сервера хранится в одной из доступных БД (на примере это сетевая СУБД MySQL).

Для предоставления пользовательского WEB-интерфейса используется модуль WebCfgD посредством транспортного протокола "HTTP".

Различные клиенты, в их числе АРМ и WEB-клиенты, выполняются на отдельных машинах в необходимом количестве. АРМ реализуется на основе OpenSCADA. В его функции входит опрос значений параметров из центрального сервера и их визуализация на GUI интерфейсе(ах). Для получения параметров сбора данных в АРМ также используется модуль отражения удалённых параметров DAQGate. Для предоставления доступа к архивам-истории может использоваться модуль архива сетевого типа. Конфигурация АРМ может храниться в одной из доступных БД (в примере это сетевая СУБД MySQL, расположенная на машине центрального сервера архивирования).

4 Конфигурация и настройка

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

При описании механизмов конфигурации и способов её хранения в этом разделе будет делаться упор на общие механизмы. Особенности конфигурации и использования модулей подсистем OpenSCADA предоставляются в собственной документации этих модулей.

В OpenSCADA используется декларативный подход к описанию конфигурационных интерфейсов, основанный на языке XML. Фактически, особенности конфигурации компонента программы предоставляется самим компонентом, пронизывая тем самым всю программу как нервная система организма. В терминах OpenSCADA это называется интерфейсом контроля и управления OpenSCADA (Control interface). На основе интерфейса контроля формируются графические интерфейсы конфигурации пользователя посредством модулей OpenSCADA. Такой подход имеет следующие важные преимущества:

• Масштабируемость: можно подключать только нужные модули конфигурирования или вообще использовать только удалённые механизмы.
• Исключение необходимости обновления конфигураторов с добавлением нового модуля-функции, а также исключение его "распухания" через прямое обеспечение поддержки всей истории уже ненужных и устаревших модулей-функций.
• Относительная простота создания графических интерфейсов конфигурации на различной основе за счёт чёткой формализации.
• Предоставление возможности динамической конфигурации, т.е. конфигурацию можно выполнять непосредственно при работе программы как локально, так и удалённо, непосредственно контролируя результат.
• Простая и целевая расширяемость конфигурационного интерфейса путём добавления полей конфигурации на языке описания интерфейса управления только в компонентах этого требующих.

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

OpenSCADA предоставляет три модуля конфигурации на разной основе визуализации. Отметим их и их возможности конфигурации:

• Модуль конфигурации на основе библиотеки графического интерфейса Qt — UI.QTCfg. Предоставляет развитый интерфейс конфигурации, позволяющий управлять как локальными, так и удалёнными станциями в локальной и глобальной сетях, включая безопасное соединение.
• Модуль конфигурации на основе динамических WEB-технологий (DHTML) — UI.WebCfgD. Предоставляет развитый интерфейс конфигурации, позволяющий управлять как локальными станциями сервера, так и удалёнными станциями в локальной и глобальной сетях, включая работу по безопасному соединению. Клиентское подключение осуществляется посредством обычного Web-браузера.
• Модуль конфигурации на основе статических WEB-технологий (XHTML) — UI.WebCfg. Предоставляет достаточный интерфейс конфигурации, позволяющий управлять локальными станциями сервера посредством обычного Web-браузера.

Конфигурация в целом может поступать тремя способами и согласно порядка: командная строка вызова программы, Конфигурационный Файл и База Данных. Из которых доступны для изменения Конфигурационный Файл и База Данных, где и сохраняются значения конфигурации, которые изменены в конфигураторах.

Типовым именем конфигурационного файла OpenSCADA является {sysconfdir}/oscada.xml (где sysconfdir типично — "/etc"), для конфигураций за проектами OpenSCADA, и {Proj}/oscada.xml для проекта "Proj". Формат конфигурационного файла и параметры командной строки рассмотрим в отдельном разделе.

Учитывая модульность подсистемы "БД", БД могут быть различными. Причем предоставляется возможность сохранения различных частей OpenSCADA как в разных БД одного типа, так и в БД разных типов.

Many OpenSCADA nodes provide the ability to select a storage to store their data and which can be specified as:

• Configuration File (<cfg>);
• {DB Module}.{DB Name} — Data Base;
• Generic Storage (<gen>) — the Generic Storage (combined) consisting of the Configuration File and the work Data Base specified in the "Work DB" configuration field; where the Configuration File is primary for the data already existing there, ie their changes, but everything new is created in the Data Base.

Nodes that do not provide the ability to select a storage work fixedly with the Generic Storage (<gen>), and those that do so also track the availability of their data in different storages and offer a mechanism for sequentially removing duplicates or simply detecting them in different libraries, which are formed by separate databases. You can read more about the mechanisms for transferring the configuration and extracting it to the library in the appropriate "How To".

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

Ряд настроек и конфигураций узлов OpenSCADA, которые исполняются или уже включены, не применяются сразу-же по внесению изменений, поскольку конфигурация читается/применяется обычно только при включении или запуске. Следовательно, для применения изменений в таких случаях, достаточно включить/выключить включенный объект или перезапустить исполняющийся — остановить/запустить. На данный момент большинство настроек, не предусматривающих непосредственного применения, просто недоступны для редактирования.

Дальнейшее рассмотрение конфигурации OpenSCADA будет производиться на основе интерфейса конфигуратора UI.QTCfg, однако принципы работы будут полностью соответствовать остальным конфигураторам, благодаря использованию общего интерфейса контроля OpenSCADA.

Let's start the observing with configuration of the OpenSCADA system parameters that are placed in the six tabs of the root page of the station:

• The tab "Station" contains basic information and configuration fields of the station, Figure 4a. List the fields provided and comment on them:
  • Station — contains information about the station's identifier and indicates the localized station's name. The identifier is specified by the command line parameter "--station"; when loading it is sought a section in the configuration file appropriate to the station identifier, and if not detected, it uses the first available one. The name is specified by the command line parameter "--statName".
  • Configuration file — contains information about the configuration file used by the program. Set by the command-line parameter "--config" or the project.
  • Work directory — contains information of the working directory of the station. This is used in relative addressing of objects in the file system, for example, database files. This is installed by the project manager at startup or directly in configuration the program launch.
  • Modules directory — contains information of directories of modules of OpenSCADA, separated by ';', they can include a files' template in the end (/my/modules/path/lib*.so). If the value of this field is incorrect then when the program is started, the program ends with a message in the console that the configuration is incorrect.
  • Icons directory — contains information of directories of the program icons, separated by ';'. If the configuration navigation tree have no icons then the value of this field is incorrect.
  • Documents directory — contains information of directories of the program documents, separated by ';'. If you can not to call local documents then the value of this field is incorrect or the documentation is not installed.
  • Work DB — indicates the working Data Base, that is the Data Base part of the combined storage (Generic Storage) used to store main data of the program; which may be the Configuration File (<cfg>) also for excluding completely the Data Base from the data storage.
  • Save the program at exit, with the period — points to the need to save the changed data at finishing of the program and indicates the periodicity in seconds with which to save the changed program's data.
  • Set modification for the calculated objects — most suitable for the production systems together with the previous configuration properties, for the calculation context saving. But it is inconvinient in the development mode, all time reminding for the saving need.
  • Messages — indicates the level of messages beginning from which they are to be processed and directions of the messages sending. Messages below this level will be ignored. The level "Debug (0)" have special sense, it set will enable debug messages generation by different parts of the program. To control the parts debug messages generation you can use the tab "Debug" (Fig.4d), which will be appeared in this case. The directions indicate the need of the message sending to the system logger, to the standard output, error and to the archive:
    • the system logger is a mechanism of operation system for work with messages of the system and software; when this option is enabled the possibility appears to manage and control the OpenSCADA messages by the mechanisms of OS;
    • the standard output and error direct the messages to console in the corresponded level; or to the standard log for some specific embedded systems;
    • the archive of OpenSCADA messages is represented by the message buffer; this option is usually enabled and its disabling leads to the actual disabling of the archiving at the station; saving the message buffer to the storage is carried out by the appropriate message archiver whose creation and configuration can be found in detail in the configuration section of the subsystem "Archives-History".
  • Environment — section of the environment information and configuration:
    • Program — contains information of the program name and version. Usually it is OpenSCADA or name of a solution based on OpenSCADA.
    • System — contains information of name and version of the Operational System (OS), OS kernel on which the program is executed.
    • System time — contains information of the actual system time with the timezone.
    • System planning clock — contains information of the used tasks planning clock and its resolution on the operation system. It allows you to orient with the minimum interval of time of periodic tasks, for example, for tasks of the data acquisition.
    • System user — contains information of the user from whose the program is executed in OS.
    • Language — contains information about the charset in which text messages are stored within the program and indicates the complete locale information with language, country and charset in the view "en_GB.UTF-8". Changing the complete locale is acceptable but leads to a change of messages' language for the interface and dynamic messages mostly.
    • Host name — contains information of the machine name that runs the station.
    • CPU — contains the CPU operative information and indicates the main CPUs set for use by OpenSCADA tasks. The CPU information represents the accessible CPU/core number and the frequency, which runs the program. Value of frequency is checked every 10 seconds (for X86) and allows you to monitor its change by the power management mechanisms for example. The main CPUs set contains in round brackets a list of used currently CPUs.
    • Number of phases of the task invoking — to set up phasing of the task invoking in the determined phases number, <= 0 to set optimal, 1 to disable the tasks phasing.
• The tab "Subsystems" contains the list of subsystems (Fig.4b) and allows you to jump directly to them using the context menu.
• The tab "Redundancy" (Fig.4c) contains the configuration of redundancy of the station with the following settings:
  • Status — contains information on the redundancy mechanism, that is current and maximum time spent on the execution of one cycle of the task of redundancy processing.
  • Station level — indicates the level of the station in a scheme of redundancy (0-255).
  • Redundant task period, seconds — indicates the period of execution of the redundancy task in seconds (1-255).
  • Restore connection timeout, seconds — indicates over the which period of time to attempt to reconnect with a lost redundant station in seconds (0-255).
  • Local primary commands transfer — enables of local primary commands transfer to redundant stations for the local changes automatic sync.
  • Stations — contains a table with information about the redundant stations. The stations can be added and removed via contextual menu. Id of the added stations is to be chosen from the list of available OpenSCADA stations. Presence into the table at last one enables the redundancy in whole and opens access to pages of the redundancy configuration at level of the subsystems, if a subsystem supports the redundancy. The table provides the following information about the station:
    • Identifier — Identifier of the OpenSCADA station, should be changed after the addition by choosing from the list of available ones;
    • Name — name of the OpenSCADA station;
    • Live — sign of establishing of a connection with the redundant station;
    • Level — level of the remote station in the redundancy scheme;
    • Counter — requests' counter to the redundant station or waiting time, in the case of the absence of connection.
  • Go to remote stations list configuration — command to go to the configuration page of the remote OpenSCADA stations in the subsystem "Transports".
• The tab "Translations" contains elements of the manager of central translation of text messages of the program (Fig.4f) and activates at the multi-language mode enabling by the base language of text variables set:

You can learn more about the details and specifics of creating multilingual projects in the appropriate "How To".

• Status — current status of the project messages translation, where can be:

• "SINGLELANGUAGE, only use the already multilanguage DBs with their modification";
• "MULTILANGUAGE, creating or modification the configuration DBs as multilanguage ones with the pointed base language '{language}';
• "MULTILANGUAGE-DYNAMIC, and dynamic translation".

• Base language - locales list — enables the multilingual support for text variables in the configuration DBs by entry the base language and the project whole locales (like to "en_US.UTF-8") list (optional) separated by ';'. Further for the text variables in the non basic language in the tables of the database it will be created separate columns. Under the text variables the all text fields of configurator, which can be translated in another language, are meant. Numbers and other special symbols are not in their count and are not translated. The whole locales list is not an obligatory part and used mostly for conversion the language code to whole locale for system functions and in the locale selection lists.

You can entry here other language besides English(en) as the base, but take in your mind that all standard OpenSCADA libraries formed for the base language English(en), so other base languages will break these DBs at change!

• , dynamic translation — planed state of the dynamic text messages translation. The dynamic text messages translation causes the text messages translation cache enabling and requests to the translations to the DB depends to the OpenSCADA part's language, mostly for multi-language dynamic user interfaces when user has self-preferred language and users of the program a lot, as a rule, are end-users-operators.
• Enable the manager — enables the generic translation manager which cause full reloading for all built messages obtain, however this does not form the full messages index by deny to reload some objects during their execution. For the full messages index loading you ought to save the manager into the enabled mode and to restart OpenSCADA. Ongoing next start the program will form the full messages index.
• Languages of managing — list of the processing languages separated by the character ';'. If the translations for the specified language in the source are presented then the language column will contain them otherwise it will be empty.
• Source filter — source filter of limiting the manager work in some DBs, the source just must contain such substring.
• , check/fix — enable for checking the base messages translation equality in different sources and fixing by: propagation the translations to empty sources, clearing the double to base translations. And the separated-second check for fixing by merging the base messages as the translations, since this operation can be some wrong in complex environments.
• , pass — pass the specified number of the table items from the top, useful for very big projects which are limited in time of the table complete processing.
• Messages — same the messages table with columns: the base language, managing translation languages, the message sources. To modify there are allowed the languages columns and at result the changes will be set to the message sources.

• The tab "Tasks" contains a table with opened tasks of OpenSCADA components (Fig.4d). From the table you can get several information about the tasks, and also assign CPUs used by the tasks of multiprocessing systems and set the task invoking phase.
• The tab "Debug" contains elements for control to debug (Fig.4e) and activates at select the messages level "Debug (0)" or at the objects counters using.

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

Нужно отметить ещё один важный момент! Поля идентификаторов всех объектов OpenSCADA недопустимы для прямого редактирования поскольку являются ключом для хранения данных объектов в БД. Однако поменять идентификатор объекта можно с помощью команды переноса и последующей вставки объекта (Cut->Paste) в конфигураторе.

Рис. 4a. Вкладка "Станция" корневой страницы конфигурации станции.

Рис. 4b. Вкладка "Подсистемы" корневой страницы конфигурации станции.

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

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

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

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

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

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

Рис. 4c. Вкладка "Резервирование" корневой страницы конфигурации станции.

Рис. 4d. Вкладка "Задачи" корневой страницы конфигурации станции.

Для отладки различных особенностей работы OpenSCADA может потребоваться включение генерации дополнительных-отладочных сообщений, что осуществляется установкой минимального уровня сообщений, на вкладке "Станция", в "Отладка (0)". В результате этого появится вкладке "Отладка" (Рис.4e) где доступны счётчики объектов для контроля за утечками, а также таблица с перечнем категорий поступающий отладочных сообщений. В таблице категорий можно выбрать только те источники отладочных сообщений, которые нужны, тем самым не перегружая подсистему вывода и архивирования сообщений, а так-же не понижая сильно производительность программы в целом. Можно выбирать категории высших уровней, вплоть до корневой категории подсистемы, что выключит детальный выбор и включит генерацию всех сообщений по уровню или подсистеме. Для изучения отладочных сообщений нужно перейти в подсистему "Архивы" (Рис.4.6c), для чего предусмотрена кнопка "Просмотр сообщений". Выбранный режим отладки и перечень категорий отладки может быть сохранён в конфигурационном файле стандартным образом и при следующем старте режим отладки активируется сразу, что важно в первую очередь для счётчиков объектов.

Рис. 4e. Вкладка "Отладка" корневой страницы конфигурации станции.

Рис. 4f. Вкладка "Переводы" корневой страницы конфигурации станции.

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

4.1 Подсистема "БД"

Подсистема является модульной и содержит иерархию объектов, изображённую на рисунке 1.4. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "БД", содержащая вкладку "Подсистема" и вкладку "Модули". Вкладка "Подсистема" (Рис.4.1a) на данный момен содержит только конфигурационное поле установки времени жизни открытых таблиц, в секундах. Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "БД", доступных на станции.

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

Рис. 4.1a. Вкладка "Подсистема" корневой страницы подсистемы "БД".

Рис. 4.1b. Вкладка "Модули" корневой страницы подсистемы "БД".

Каждый модуль подсистемы "БД" предоставляет конфигурационную страницу с вкладками "БД" и "Модуль". Вкладка "БД" (Рис.4.1c) содержит список объектов БД, зарегистрированных в модуле и флажок признака полного удаления БД при выполнении команды удаления. В контекстном меню списка БД пользователю предоставляется возможность добавления, удаления и перехода к нужной БД. Во вкладке "Модуль" содержится информация о модуле подсистемы "БД" в качестве информационных полей каждого модуля (Рис.4.1d):

• Модуль — идентификатор модуля.
• Имя — имя модуля.
• Тип — тип модуля, идентификатор подсистемы к которой модуль относится.
• Источник — разделяемая библиотека или *bd_{ModId}, для встраивания, что характеризует источник данного модуля.
• Версия — версия модуля.
• Автор — автор модуля.
• Описание — краткое описание модуля.
• Лицензия — лицензионное соглашение распространения модуля.

Модули подсистемы "БД" содержат также специфическое информационное поле "Свойства" с ключевыми словами поддерживаемых свойств:

• LIST — перечень таблиц-контейнеров в БД-хранилище;
• GET, SEEK, SET, DEL — соответствующие запросы записей данных OpenSCADA;
• STRUCT — получение структуры полей БД в отражении на типы данных OpenSCADA;
• PRELOAD — предварительная загрузка записей данных OpenSCADA при SEEK-запросе, груповым SQL SELECT запросом;
• SQL — SQL-запросы;
• FIX — исправление-изменение структуры хранилища согласно структуре запросов данных OpenSCADA;
• TR — обработка данных перевода структуры записи OpenSCADA;
• ERR — проверенная обработка и регистрация ошибок окружения вроде RO-режима, подключения и подобное.

Для хранения конфигурации OpenSCADA, модуль реализации хранилища должен предоставлять по крайней мере следующие свойства: GET, SEEK, SET, DEL. И чтобы быть многоязычным хранилищем должен также предоставлять свойство TR.

Рис. 4.1c. Вкладка "БД" модуля подсистемы "БД".

Рис. 4.1d. Вкладка "Модуль" модуля подсистемы "БД".

Каждый объект БД содержит собственную страницу конфигурации с вкладками "База данных", "Таблицы" и "SQL", в случае поддержки SQL-запросов. Кроме основных операций можно выполнять копирование содержимого БД стандартной функцией копирования объектов в конфигураторе. Операция копирования содержимого БД подразумевает копирование исходной БД в БД назначения, при этом содержимое БД назначения не очищается перед операцией копирования. Копирование содержимого БД производится при условии включения обоих БД, иначе будет выполняться простое копирование объекта БД!

Вкладка "База данных" (Рис.4.1e) содержит основные настройки объекта БД, в составе:

• Раздел "Состояние" — содержит свойства, характеризующие состояние объекта БД:
  • Включен — состояние "Включен", объекта БД. Для сетевых БД это состояние предусматривает подключение к СУБД, соответственно и отражает факт наличия подключения и которое, при установке "Включать", периодически восстанавливается.
  • Доступные таблицы — перечень таблиц, которые содержит БД. Контекстным меню данного свойства предоставляется возможность физического удаления таблиц из БД.
  • Загрузить программу из этой БД — команда для выполнения загрузки из данной БД. Может использоваться при переносе данных в БД между станциями. Например, можно сохранить участок одной станции в экспортную БД, физически перенести БД на другую станцию, подключить её в этой подсистеме и вызвать данную команду.
• Раздел "Конфигурация" — непосредственно содержит поля конфигурации:
  • Идентификатор — содержит информацию об идентификаторе объекта БД.
  • Имя — указывает имя объекта БД.
  • Описание — краткое описание и назначение объекта БД и самой БД в программе.
  • Адрес — адрес БД в специфичном для типа БД (модуля) формате. Описание формата записи адреса БД как правило доступно во всплывающей подсказке этого поля.
  • Кодовая страница — указывает на кодовую страницу, в которой хранятся и предоставляются текстовые значения БД. Значение кодовой страницы БД в связке с внутренней кодировкой станции используется для прозрачного перекодирования текстовых сообщений при обмене между станцией и БД.
  • Включать — указывает на состояние "Включен", в которое переводить БД при загрузке.
  • Приоритет в списке — приоритет БД [0...99] в общем перечне баз данных используемых в загрузке, полезно для библиотек размещённых в нескольких базах данных для определения приоритетных — используемых.
  • Закрытие транзакции: после открытия, секунд — время закрытия транзакции после её открытия.
  • Закрытие транзакции: после запроса, секунд — время закрытия транзакции после последнего запроса. Если время меньше SERV_TASK_PER (10), тогда для обработки транзакций БД будет открыт независимый поток-задачу с определённым следующим параметром приоритетом, иначе процесс будет осуществляться сервисной задачей.
  • Закрытие транзакции: приоритет отдельной задачи — приоритет независимого потока-задачи, открытой для предыдущего времени меньше SERV_TASK_PER (10).

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

Вкладка "SQL" (Рис.4.1g) доступна только для баз данных, поддерживающих SQL-запросы, и содержит поле ввода запроса, кнопку отправки запроса и таблицу с результатом запроса. Для управления режимом транзакции запроса предусмотрено отдельное конфигурационное поле.

Рис. 4.1e. Вкладка "База данных" объекта БД модуля подсистемы "БД".

Рис. 4.1f. Вкладка "Таблицы" объекта БД модуля подсистемы "БД".

Рис. 4.1g. Вкладка "SQL" объекта БД модуля подсистемы "БД".

Страница изучения содержимого таблицы содержит только одну вкладку "Таблица". Вкладка "Таблица" (Рис.4.1h) содержит поле названия таблицы и таблицу с содержимым. Таблицей содержимого предоставляются функции:

• редактирование содержимого ячеек таблицы;
• добавление записи (строки);
• удаление записи (строки).

Рис. 4.1h. Вкладка "Таблица" таблицы БД модуля подсистемы "БД".

4.2 Подсистема "Безопасность"

Подсистема не является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Безопасность", содержащая вкладку "Пользователи и группы пользователей". Вкладка "Пользователи и группы пользователей" (Рис.4.2a) содержит списки пользователей и групп пользователей. Пользователь в группе "Security" или с правами привилегированного пользователя может добавить, удалить пользователя или группу пользователей. Все остальные пользователи могут переходить к страницам пользователей или групп пользователей и изменять ряд персональных параметров на собственной странице пользователя.

Рис. 4.2a. Вкладка "Пользователи и группы пользователей" корневой страницы подсистемы "Безопасность".

For user configuration, a page that contains only the "User" tab (Fig.2.4b) is provided. This tab contains configuration data of the user profile, which can be changed by the user, the user in the "Security" group or the privileged user:

• Name — information about the name (identifier) of the user.
• Full name — specifies the full name of the user.
• Description — description and arbitrary information about the user.
• Password — the field to change the user's password. It always displays "********".
• Language — user's language for the dynamic messages context and for text to speech of the user interface. Empty to the system language.
• User picture — specifies the user's picture. Picture can be loaded and saved.
• Groups — the table with a list of user groups and a sign of the user's belonging to the corresponding group.
• Storage — the user's data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.

Рис. 4.2b. Вкладка "Пользователь" страницы пользователя подсистемы "Безопасность".

To configure a group of users, a page is provided that contains only the "Group" tab (Fig.4.2c). This tab contains configuration data of the user group profile that can only be changed by the privileged user:

• Name — information about the name (identifier) of the user's group.
• Full name — specifies the full name of the user's group.
• Description — description and arbitrary information about the users group.
• Users — list of users included into this group. With the context menu of the list you can add or remove the user in the group.
• Storage — the user group data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.

Рис. 4.2c. Вкладка "Группа" страницы группы пользователей подсистемы "Безопасность".

4.3 Подсистема "Транспорты"

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

The tab "Subsystem" (Fig.4.3a) contains a configuration table for external, for this, OpenSCADA stations. External stations may be "System", "User" or both these are selected by the appropriate column. System's external stations are available only to the super user and are used in purpose of components of the system, for example, the horizontal redundancy mechanism and the module DAQ.DAQGate. User's external stations are tied to the user who created them, and thus the list of user's external stations is individual for each user. User's external stations are used by components of the graphical interface, for example, UI.QTCfg, UI.WebCfgD and UI.Vision. In this table of external stations it is possible to add and delete records about the stations, as well as their modification. Each station contains the following fields:

• Identifier — identifier of the external station.
• Name — name of the external host.
• Transport — selection for the transport type or address directly from list of the network transports, output transports directly and input transports allowed to creation associated output connections.
• Address — additional address to the previous field used at creation the missed or automatic output transports and as the remote initiative connection ID for the input transports. Address of the external station through the output connection is specific to the module of the subsystem "Transports" selected in the previous field.
• User — name/identifier of the user of the external station on behalf of whom to perform the connection.
• Password — password of the user of the external station.
• Mode — host mode: "User", "System", "User and System".
• Uprising level — uprising hosts level of the pointed host for possibility of requests re-transmission.

Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Транспорты" и идентична для всех модульных подсистем.

Рис. 4.3a. Вкладка "Подсистема" корневой страницы подсистемы "Транспорты".

Каждый модуль подсистемы "Транспорты" предоставляет конфигурационную страницу с вкладками "Транспорты" и "Модуль".

Вкладка "Транспорты" (Рис.4.3b) содержит список входных и выходных транспортов, зарегистрированных модулем. В контекстном меню списков транспортов пользователю предоставляется возможность добавления, удаления и перехода к нужному транспорту. Выходные транспорты также предоставляют функцию времени жизни, которая предусматривает закрытие транспортов по неактивности. Установите это поле в 0 для выключения этой функции!

Во вкладке "Модуль" содержится информация о модуле подсистемы "Транспорты" (Рис.4.1d), состав которой идентичен для всех модулей.

Рис. 4.3b. Вкладка "Транспорты" модуля подсистемы "Транспорты".

Each transport contains its own generic configuration dialogues in the tab "Transport" and "Additional". The "Transport" tab contains basic transport settings. Input transport (Fig.4.3c) contains:

• Section "State" — contains the settings that characterize the state of the transport:
  • Status — information on the current transport's status and statistics of its work. Most modules provide advanced diagnostics in this field when enabled with the debugging mode.
  • Connect — operative state/command of the transport.
  • Storage — the transport's data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.
  • Active connections — active and actual connections list of the input transport.
• Section "Configuration" — directly contains the configuration fields:
  • Identifier — information on the transport's identifier.
  • Name — specifies the transport's name.
  • Description — brief description of the transport and its appointment.
  • Address — transport address in a specific type of transport (module) format. Description of the format of the address of the transport, as a rule, is available in the tooltip for this field.
  • Transport protocol — indicates the transport protocol modules (the subsystem "Transport protocols") those should work in conjunction with the input transport. That is, received unstructured data this module will sent to the structuring and processing to the specified modules of the transport protocol.
  • To connect — indicates the state/command "Connect", in which to transfer the transport at startup.

Fig. 4.3c. The tab "Transport" and "Additional" of the page of an input transport of the module of the subsystem "Transports".

Output transport (Fig.4.3d) contains:

• Section "State" — contains the settings that characterize the state of the transport:
  • Status — information on the current transport's status and statistics of its work. Most modules provide advanced diagnostics in this field when enabled with the debuging mode.
  • Connect — operative state/command of the transport. Given the network nature of the transports, this state often involves connecting to a remote network node and accordingly reflecting the fact that the connection is present. For output transports, there is no need for the user to be obliged to set this state because it is used by an external entity of the communication protocols, often by the data sources, that try to connect the transport beforehand, so by establishing a connection for further exchange, moreover, the transport may be disconnected by that entity.
  • Transport DB — the transport's data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.
• Section "Configuration" — directly contains the configuration fields:
  • Identifier — information on the transport's identifier.
  • Name — specifies the transport's name.
  • Description — brief description of the transport and its appointment.
  • Address — transport address in a specific type of transport (module) format. Description of the format of the address of the transport, as a rule, is available in the tooltip for this field.

Fig. 4.3d. The tab "Transport" and "Additional" of the page of an output transport of the module of the subsystem "Transports".

The tab "Additional" of both input and output transports contains specific parameters of the transport type and protocols' specific custom parameters. Also there can be reset all the additional parameters to default values and be cleaned the protocols' specific custom parameters.

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

• Время — информация о времени, затраченном на запрос и получение ответа.
• Режим — указывает режим данных, из списка: "Бинарный", "Текст(LF)", "Текст(CR)", "Текст(CR/LF)"; в котором будет формироваться запрос и предоставляться ответ. В бинарном режиме данные записываются парами чисел в шестнадцатеричном исчислении, т.е. байтами, разделёнными пробелами.
• Ожидать таймаут — признак ожидания таймаута при получении ответа. Многие системы при ответе на различных протоколах (например, HTTP) могут слать данные ответа несколькими кусками. Без этого флага будет получен и отображён только первый кусок. При установке флага будет осуществлено ожидание всех кусков ответа, вплоть до отсутствия данных в течении таймаута дожидания транспорта.
• Размер входного буфера, байт — контролирует размер входного буфера или выключает чтение (0) вообще — только запись.
• Отправить — команда отправить запрос.
• Запрос — содержит данные запроса в выбранном режиме представления.
• Ответ — предоставляет данные ответа в выбранном режиме представления.

Рис. 4.3e. Вкладка "Запрос" страницы выходного транспорта модуля подсистемы "Транспорты".

Both input and output transports also contain the tab "IO log" (Fig.4.3f). The tab is provided for generic control, observing and learning the traffic through the transports and includes the log length, block limit, type, aggregation time and the same text area of the log. For the log disable you can the log length field set to zero (0) and -1 for writing to a file.

Рис. 4.3f. Вкладка "Лог ВВ" страницы входного транспорта модуля подсистемы "Транспорты".

4.4 Подсистема "Транспортные протоколы"

Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Транспортные протоколы", содержащая вкладку "Модули". Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Транспортные протоколы" и идентична для всех модульных подсистем.

Каждый модуль подсистемы "Транспортные протоколы" предоставляет конфигурационную страницу с вкладкой "Модуль". Во вкладке "Модуль" содержится информация о модуле подсистемы "Транспортные протоколы" (Рис.4.1d), состав которой идентичен для всех модулей.

4.5 Подсистема "Сбор данных"

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

Для получения доступа на модификацию объектов этой подсистемы необходимы права пользователя в группе "DAQ" или права привилегированного пользователя.

Объектом резервирования подсистемы "Сбор Данных" выступает объект контроллера в рамках которого резервирование данных выполняет функции:

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

Вкладка "Резервирование" (Рис.4.5a) доступна только если в резерве указана хотя-бы одна станция (Рис.4c) и содержит конфигурацию резервирования источников данных подсистемы "Сбор данных", в составе настроек:

• Глубина восстановления данных при запуске — указывает на максимальную глубину архивных данных для восстановления из архива удалённой станции при запуске, в часах (0-12).
• Контроллеры — содержит таблицу с перечнем объектов контроллеров, доступных для резервирования, и текущее их состояние:
  • Контроллер — полный идентификатор объекта контроллера;
  • Имя — имя объекта контроллера;
  • Запущен — признак исполнения объекта контроллера локальной станцией;
  • Резервирование — режим резервирования объекта контроллера, может быть выбран из перечня:
    • "Выключено" — совершенно независимая работа объекта контроллера.
    • "Асимметричное" — полное резервирование с доступной конфигурацией объекта контроллера удалённой станции и без попыток её обобщать.
    • "Только нарушения" — фактическая работа без резервирования, но с подавлением нарушений от резервного объекта контроллера с целью исключения дублирующих сообщений о нарушениях.
  • Предпочтение исполнения — конфигурация предпочтительного исполнения на указанной станции; зарезервированные значения указывают на:
    • <Высокий уровень> — исполнение на станции с самым высшим уровнем.
    • <Низкий уровень> — исполнение на станции с самым низким уровнем.
    • <Оптимально> — выбор для исполнения наименее нагруженной станции — станции которая исполняет наименьшее количество объектов контроллеров.
  • Удалённый — признак, указывающий на исполнение объекта контроллера удалённой станцией и работу локальной станции в режиме синхронизации данных с удалённой.

Рис. 4.5a. Вкладка "Резервирование" подсистемы "Сбор данных".

Вкладка "Библиотеки шаблонов" (Рис.4.5b) содержит список библиотек шаблонов для параметров этой подсистемы. В контекстном меню списка библиотек шаблонов пользователю предоставляется возможность добавления, удаления и перехода к нужной библиотеке. Вкладка "Модули" (Рис.4.1c) содержит список модулей подсистемы "Транспорты" и идентична для всех модульных подсистем.

Рис. 4.5b. Вкладка "Библиотеки шаблонов" подсистемы "Сбор данных".

Each template library of the subsystem "Data acquisition" provides a configuration page with the tabs "Library" and "Parameter templates". The tab "Library" (Fig.4.5d) contains the basic settings of the library:

• Section "State" — contains properties that characterize the state of the library:

• Accessing — state of library "Accessing".
• Storage — the library and templates data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.

The object still supports of specifying the spare storage addresses with tables before you rename the table in the standard form "tmplib_{ObjID}".

• Date of modification — date and time for the object last modification.

• Section "Config" — directly contains the configuration fields:

• Identifier — information on the Id of the library.
• Name — specifies the name of the library.
• Description — short description of the library and its purpose.

Вкладка "Шаблоны параметров" (Рис.4.5d) содержит список шаблонов в библиотеке. В контекстном меню списка пользователю предоставляется возможность добавления, удаления и перехода к нужному шаблону.

Рис. 4.5c. Основная вкладка конфигурации библиотеки шаблонов подсистемы "Сбор данных".

Рис. 4.5d. Вкладка списка шаблонов в библиотеке шаблонов подсистемы "Сбор данных".

Каждый шаблон библиотеки шаблонов предоставляет конфигурационную страницу с вкладками "Шаблон" и "ВВ". Вкладка "Шаблон" (Рис.4.5e) содержит основные настройки шаблона в составе:

• Раздел "Состояние" — содержит свойства, характеризующие состояние шаблона:
  • Доступен — состояние шаблона "Доступен".
  • Использовано — количество использования шаблона. Позволяет определить факт использования и, как следствие, возможность структурных изменений шаблона.
  • Дата модификации — дата и время последней модификации объекта.
• Раздел "Конфигурация" — непосредственно содержит поля конфигурации:
  • Идентификатор — информация об идентификаторе шаблона.
  • Имя — указывает имя шаблона.
  • Описание — краткое описание шаблона и его назначения.

Рис. 4.5e. Главная вкладка конфигурации шаблона параметров подсистемы "Сбор данных".

Вкладка "ВВ" (Рис.4.5f) содержит конфигурацию атрибутов (Вход-Выход) шаблонов и текст программы шаблона на языке пользовательского программирования OpenSCADA, например, "JavaLikeCalc.JavaScript". Признак "Переводить программу" указывает на сохранение и перевод текста программы для каждого языка (человеческого) отдельно, что усложняет поддержание алгоритма одинаковым для многоязычных конфигураций. Этот признак в целом внедрён для совместимости со старыми версиями OpenSCADA, не рекомендуется для установки и на данное время практикуется перевод конкретных текстовых сообщений в тексте программы, через функцию tr().

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

• Идентификатор — идентификатор атрибута.
• Имя — имя атрибута.
• Тип — выбор типа значения атрибута из списка: "Вещественный", "Целый", "Логический", "Строка", "Строка (перевод)", "Текст", "Текст (перевод)", "Объект", "Выбор целых чисел", "Выбор вещественных чисел", "Выбор строк".
• Режим — выбор режима из списка: "Вход", "Выход". Обычно используется для указания направления передачи данных посредством связи. Т.е. для значения "Вход" данные по связи будут только получаться, а для "Выход" также будут передаваться, в случае модификации.
• Атрибут — режим атрибута параметра реализованного на основе шаблона, из списка: "Не атрибут", "Только для чтения", "Полный доступ". Для атрибутов шаблона у которых это поле установлено будет создаваться соответствующий атрибут у параметра контроллера этой подсистемы.
• Конфигурация — режим конфигурации атрибута во вкладке конфигурации шаблона у параметра контроллера этой подсистемы, из списка: "Переменная", "Константа", "Связь". В режимах "Константа" и "Связь" во вкладке конфигурации шаблона будут добавлены эти атрибуты для установки константы или указания внешней связи параметра.
• Значение — значение атрибута по умолчанию или шаблон ссылки для доступа по ссылке:
  • Формат шаблона ссылки зависит от компонента который его использует. Общий формат ссылок записывается в виде: {Parameter}|{attribute}. Поле Parameter — указывает имя параметра как контейнера атрибутов. Атрибуты с одинаковым значением Parameter будут группироваться и позволят назначаться указанием только контейнера атрибутов, а отдельные атрибуты будут связаны с атрибутами контейнера в соответствии с полем attribute.
  • Для выборных типов это поле также может содержать перечень значений, во второй строке, и перечень наименований, в третьей строке, с разделением элементов символом ";".

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

Рис. 4.5f. Вкладка конфигурации атрибутов и программы шаблона подсистемы "Сбор данных".

Каждый модуль подсистемы "Сбор данных" предоставляет конфигурационную страницу с вкладками "Контроллеры" и "Модуль". Вкладка "Контроллеры" (Рис.4.5g) содержит список объектов контроллеров, зарегистрированных в модуле. В контекстном меню списка пользователю предоставляется возможность добавления, удаления и перехода к нужному объекту контроллера. Во вкладке "Модуль" содержится информация о модуле подсистемы "Сбор данных" (Рис.4.1d), состав которой идентичен для всех модулей.

Рис. 4.5g. Вкладка "Контроллеры" модуля подсистемы "Сбор данных".

Каждый объект контроллера содержит собственную страницу конфигурации с вкладками "Контроллер", "Параметры" и "Диагностика".

The tab "Controller" (Fig.4.5h) contains the basic settings. Content of these settings may differ slightly from one module of this subsystem to another, as you can find in the own documentation of the modules. As an example, let's examine the settings of a controller object in the module of the logical level controller DAQ.LogicLev:

• Section "State" — contains the properties, which characterize the state of the controller object and the controller itself:

• Status — specifies the controller object status. In our case, the controller is running and the current computation time is 1.15 milliseconds and the maximum one is 2.42 milliseconds.
• Enabled — state of the controller object "Enabled". When enabled, the controller object provides the possibility of creating the parameters and their configuration.
• Running — State of the controller object "Running". The running controller object performs the physical data acquisition and/or includes mechanisms for access to these data.

Some data source types provides a possibility of performing some part of the function of coming to the Enabled state — hot updating the data configuration at the manual starting and that you can see in the field tooltip.

• Storage — data storage of the controller object and its parameters, with tracking the availability of the data in different storages and providing the sequentially removing duplicates. Parameters of different types are stored in different tables with own structure and unified name "{ModId}{TypeId}_{CntrId}", which can be specific for some modules.
• Date of modification — date and time for the object last modification.

• Section "Configuration" — directly contains the configuration fields:

• Identifier — information on the controller object identifier.
• Name — specifies the controller name.
• Description — brief description of the controller and its purpose.
• To enable — indicates the state of "Enabled", in which to transfer the controller object at the program startup.
• To start — indicates the state of "Running", in which to transfer the controller object at the program startup.
• Schedule of the calculation — defines whether periodic or scheduled character of the calculations is. In our example the template calculation is periodic in one second.
• Priority of the acquisition task — sets priority of the data acquisition of this controller. It is used when scheduling the operating system tasks. In the case of proper access availability this field enables the planning of the controller task in real time and with the specified priority otherwise it modifies the parameter "nice" of the task.

Рис. 4.5h. Главная вкладка конфигурации объекта контроллера подсистемы "Сбор данных".

Вкладка "Параметры" (Рис.4.5i) содержит список параметров в объекте контроллера, предоставляет выбор типа создаваемых по умолчанию параметров, а также информацию об общем количестве и количестве включенных параметров. В контекстном меню списка параметров пользователю предоставляется возможность добавления, удаления и перехода к нужному параметру.

Рис. 4.5i. Вкладка "Параметры" страницы конфигурации объекта контроллера подсистемы "Сбор данных".

Вкладка "Диагностика" (Рис.4.5j) содержит форму диагностических сообщений источника данных. Поскольку многие источники данных представляют собой внешние устройства с доступом к данным посредством сетевого обмена или системной шины то возможны различные нештатные ситуации при доступе к данным. Вывод всех их в поле "Статус" объекта контроллера невозможен поскольку он отображает только текущее состояние доступа к данным. С помощью диагностики можно проследить все нештатные ситуации в виде сообщений, сформированных данным объектом контроллера за указанный промежуток времени и с выбранным уровнем сообщения. Кроме непосредственно рабочей диагностической информации ряд модулей источников данных могут предоставлять здесь различные отладочные дампы обмена, на уровне сообщений "Отладка (0)".

Рис. 4.5j. Вкладка "Диагностика" страницы конфигурации объекта контроллера подсистемы "Сбор данных".

Параметры объектов контроллеров подсистемы "Сбор данных" предоставляют конфигурационную страницу с вкладками "Параметр", "Атрибуты", "Архивация", "Включение" и "Конфигурация шаблона".

Вкладка "Параметр" (Рис.4.5k) содержит основные настройки в составе:

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

Рис. 4.5k. Главная вкладка конфигурации параметра объекта контроллера подсистемы "Сбор данных".

Вкладка "Атрибуты" (Рис.4.5l) содержит атрибуты параметра и их значения в соответствии с конфигурацией используемого шаблона и вычисления его программы.

Рис. 4.5l. Вкладка "Атрибуты" параметра объекта контроллера подсистемы "Сбор данных".

Вкладка "Архивация" (Рис.4.5m) содержит таблицу с атрибутами параметра в строках и архиваторами в колонках. Пользователь имеет возможность установить архивацию нужного атрибута требуемым архиватором просто изменив ячейку на пересечении.

Рис. 4.5m. Вкладка "Архивация" параметра объекта контроллера подсистемы "Сбор данных".

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

Fig. 4.5n. Вкладка "Включение" параметра объекта контроллера подсистемы "Сбор данных".

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

Рис. 4.5o. Вкладка "Конфигурация шаблона" параметра объекта контроллера подсистемы "Сбор данных".

4.6 Подсистема "Архивы-История"

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

Для получения доступа на модификацию объектов этой подсистемы необходимы права пользователя в группе "Archive" или права привилегированного пользователя.

Объектом резервирования подсистемы "Архивы-История" выступает объект архиватора сообщений в рамках которого резервирование данных выполняет функции:

• Резервирование механизма архивации — предусматривает обобщение сообщений с резервных станций посредством трёх механизмов:
  • в основном цикле резервирования резервного архива осуществляется запрос новых сообщений архиватора на основной станции от времени последнего сообщения резервного объекта, где последнее сообщение это последняя секунда времени, что запрашивается дважды, чтобы предотвратить потерю сообщений на эту секунду времени, но предусмотрен механизм контроля дубликатов и их подавления как непосредственно после запроса, так и самим архиватором;
  • запись или перезапись сообщений в резервный архиватор приводит к перенаправлению запроса записи на основную станцию как для новых, так и перезаписывающих сообщений (также сообщения записываются локально);
  • перезапись сообщений в основной архиватор приводит к рассылке этих сообщений всем резервным станциям, где исключается создание новых записей в таблице текущих сообщений — только модификация существующих.
• Компенсация потери данных на время простоя узла за счёт архива резервного узла. Предусматривает только первичную синхронизацию путём загрузки/перегрузки участков архива из резервной станции в момент запуска станции в целом. Участок архива запрашивается с момента последней записи в локальном архиве минус значение параметра глубины принудительной перегрузки и по текущее время. Изменённые сообщения на глубину более указанной будут утеряны на запускаемой станции! Процедура первичной синхронизации в целом предусматривает:

1. запрос всех активных нарушений;
2. запрос сообщений конкретного архива на глубину, указанную параметром "Глубина принудительной перезагрузки истории резерва при запуске", и по время предыдущего запроса, т.е. когда новые активные нарушения точно не появятся;
3. переход в нормальный режим отслеживания новых сообщений и нарушений через архив.

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

Резервирование архиваторов значений не предоставляется прямо ввиду осуществления этого процесса через источники данных и подсистему сбора данных.

Вкладка "Резервирование" (Рис.4.6a) доступна только если в резерве указана хотя-бы одна станция (Рис.4c) и содержит конфигурацию резервирования архиваторов сообщений подсистемы "Архивы-История", в составе настроек:

• Глубина принудительной перезагрузки истории резерва при запуске — указывает на глубину, в сутках, запроса сообщений у резервной станции от времени последнего сообщения в локальном архиве. Иногда может быть полезным для перегрузки последних сообщений если они потенциально могут поменяться-дополниться на резервной станции при простое локальной.
• Архиваторы сообщений — содержит таблицу с перечнем архиваторов сообщений доступных для резервирования и текущее их состояние:
  • Архиватор — полный идентификатор архиватора сообщений;
  • Имя — имя архиватора;
  • Исполняется — признак исполнения архиватора локальной станцией;
  • Резервирование — режим резервирования архиватора — включение;
  • Предпочтение исполнения — конфигурация предпочтительного исполнения на указанной станции; зарезервированные значения указывают на:
    • <Высокий уровень> — исполнение на станции с самым высоким уровнем.
    • <Низкий уровень> — исполнение на станции с самым низким уровнем.
    • <Оптимально> — выбор для исполнения наименее нагруженной станции — станции которая исполняет наименьшее количество объектов архиваторов.
  • Удалённый — признак, указывающий на исполнение архиватора удалённой станцией и работу локальной станции в режиме синхронизации данных с удалённой.

Рис. 4.6a. Вкладка "Резервирование" подсистемы "Архивы-История".

Вкладка "Сообщения" (Рис.4.6b) содержит конфигурацию архива сообщений и форму запроса сообщений из него.

Configuration of the messages archive is represented by the fields:

• Buffer size, archiving period — indicates the size of the memory area reserved for the interim buffer of messages. Messages from the buffer are requested for viewing and archived with the messages archivers by the specified periodicity in seconds.
• Days of the alarms automatic clearing — after that term the alarms are meant as forgotten and inactual, so removed from the table of the active alarms. Zero disables the automatic clearing.

Форма запроса сообщений содержит конфигурационные поля запроса и таблицу результата. Конфигурационные поля запроса:

• Время, размер (секунд) и уровень — указывает время, размер или глубину (в секундах) и минимальный уровень сообщений (более или равный указанному) запроса.
• Шаблон категории — указывает категорию запрашиваемых сообщений. В категории можно указывать элементы выборки по шаблону, а именно символы "*" — для любой подстроки и "?" — для любого символа, а также регулярное выражение заключённое между символами '/' (/mod_(System|LogicLev)/).
• Архиваторы — указывает архиваторы сообщений, разделённые символом ';', для которых обрабатывать запрос. Если значение отсутствует то запрос будет обработан для буфера и всех архиваторов. Если указано "<buffer>" то запрос будет обработан для буфера сообщений.

Таблица результата содержит строки сообщений с колонками:

• Время, мкс — полная дата и время сообщения, а также микросекундная часть, отдельно.
• Категория — категория сообщения.
• Уровень — уровень сообщения.
• Сообщение — непосредственно текст сообщения.

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

Рис. 4.6b. Вкладка "Сообщения" подсистемы "Архивы-История".

The tab "Values" (Fig.4.6c) contains the general configuration of the values archiving and list of the value archives. In the context menu of the list of values the user has the opportunity to add, delete and go to the desired archive. The general configuration of the archiving is represented by the fields:

• Period of the data receiving — indicates the periodicity of the task of the active archiving, in milliseconds. Highest level of detail or minimum period of the active archives is in fact determined by this value.
• Level of priority of the data receiving task — sets priority of the task of the active archiving. It is used when scheduling the operating system tasks. In the case of proper access availability this field enables the planning of the archiving task in real time and with the specified priority otherwise it modifies the parameter "nice" of the task.
• Forced to set timestampes in the current time — timestamp of received values, on the active archiving, forces to the current time, replaces the data source time.
• Mode of forming ID of the automatic created archives — the mode of forming identifier at selecting the archiving in the tab "Archiving" of the DAQ-parameters.
• Number — detailed number of the value archives with the common statistic about ones: enabled, no source (passive), error (missing source), lost (empty DB).
• Value archives — list of the value archives itself.
• Remove all ... — group operations of removing all no source - passive, with error source - missing source, lost archives - empty DB.

Рис. 4.6c. Вкладка "Значения" подсистемы "Архивы-История".

Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Архивы-История" и идентична для всех модульных подсистем.

Архив значений подсистемы "Архивы-История" предоставляет конфигурационную страницу с вкладками "Архив", "Архиваторы" и "Значения".

The tab "Archive" (Fig.4.6d) contains the basic settings of the archive:

• Section "State" — contains the properties, which characterize the state of the archive:
  • Running — state of the parameter "Running". Running archive collects data in the buffer and is served by the archivers.
  • Begin and end of the buffer — date and time of values begin and end into the buffer.
  • Storage — the archive's data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.
• Section "Configuration" — directly contains the configuration fields:
  • Identifier — information on the archive identifier.
  • Name — specifies the archive name.
  • Description — brief description of the archive and its purpose.
  • To start — indicates the state "Running" in which to transfer the archive at the program startup.
  • Source — indicates the type and address of the source. Type of source is indicated from the list: "Passive", "DAQ Attribute" or "Active DAQ Attribute (DEPRECATED)". Passive archive does not have an associated source of values, the data to the such archive the source transfers by itself, for example from calculating procedures of users on internal programming language. Types with the attribute of the parameter in the address field indicate the parameter attribute of the subsystem "Data acquisition" as the source. Main attribute of the parameter sends data to the archive by itself with its own period of the data acquisition. Active attribute of the parameter is acquired by the archiving task of this subsystem. All real data sources work in the main archiving mode since the received data is immediately placed in the parameter attribute, sometimes by the source timestamp. The calculators (DAQ.JavaLikeCalc, DAQ.LogicLev, DAQ.BlockCalc, DAQ.Siemens, DAQ.OPC_UA) also works now in the main archiving mode and early used the active archiving mode because the data in the attribute parameter was updated only with them direct request, and was taken from the execution context. In the case of the real data sources, the difference between active and main mode of archiving by the fact that in the main mode the source can put data into the archive by timestamp, and in the active mode the timestamp is always set to the current system time.
  • Data combining mode — sets the combining mode for data writing from the high-resolution buffer (for example, 1 second) to low-resolution archiver (for example, 1 minute), when into single point of the archiver placed several values (for example, 60) from the buffer. The modes implemented: "Moving average", "Single", "Minimum" and "Maximum".
  • Value type — indicates the type of values which are stored in the archive from the list: "Boolean", "Integer", "Real", "String", "Int16", "Int32", "Int64", "Real(Float)" and "Real(Double)".
  • Buffer period — indicates the periodicity of values in the archive buffer, in seconds.
  • Buffer size — indicates the dimension or depth of the archive buffer. The dimension is automatically sets at a rate of 60 sec of the periodicity of the archiving task, with the remainder.
  • Buffer in the hard time grid — indicates the mode of the buffer. The hard time grid mode involves the memory reservation for each value, but without the timestamp. This mode eliminates the possibility of packaging the adjacently-identical values but also saves on storage of the timestamp. Otherwise, the buffer operates in the mode of storage the value and timestamp and supports the packaging of adjacently-identical values.
  • Buffer in the high time resolution — indicates the possibility of storing values at intervals and dimensions up to 1 microsecond, differently the values can be stored at intervals and dimensions up to 1 second.
  • Filling the passage points with the last value — the passage values mostly fill by EVAL but sometime data periodicity of the source greater to the archive's one and it is normal.

Рис. 4.6d. Основная вкладка конфигурации архива значений подсистемы "Архивы-История".

Вкладка "Архиваторы" (Рис.4.6e) содержит таблицу с конфигурацией процесса обработки данного архива доступными архиваторами. В строках расположены доступные архиваторы, а в колонках параметры:

• Архиватор — информация об адресе архиватора.
• Выполняется — информация о состоянии "Выполняется" архиватора.
• Обработка — признак обработки данного архива архиватором. Поле доступно для модификации пользователем.
• Период — информация о периодичности архиватора, в секундах.
• Начало — дата и время начала данных архива в архиваторе.
• Конец — дата и время конца данных архива в архиваторе.

Рис. 4.6e. Вкладка "Архиваторы" архива значений подсистемы "Архивы-История".

Вкладка "Значения" (Рис.4.6f) содержит запрос значений в архиве и результат в виде таблицы значений или изображения тренда. Запрос значений содержит поля:

• Время — указывает дату и время запроса. Содержит два поля: поле дата+время и микросекунды.
• Размер — указывает размер или глубину запроса в секундах.
• Архиватор — указывает архиватор значений для которого обрабатывать запрос. Если значение отсутствует то запрос будет обработан для буфера и всех архиваторов. Если указано "<buffer>", то запрос будет обработан только для буфера архива.
• Показать график — указывает на необходимость представления данных архива в виде графика (тренда) иначе результат представляется в таблице, содержащей только время и значение. В случае установки этого поля формируется и отображается график, кроме того появляются дополнительные конфигурационные поля настройки изображения:
  • Размер изображения — указывает ширину и высоту формируемого изображения, в пикселах.
  • Шкала значения — указывает нижнюю и верхнюю границу шкалы значений. Если оба значения установлены в 0 или равны, то шкала будет определяться автоматически в зависимости от значений.

Рис. 4.6f. Вкладка "Значения" архива значений подсистемы "Архивы-История".

Каждый модуль подсистемы "Архивы-История" предоставляет конфигурационную страницу с вкладками "Архиваторы" и "Модуль". Вкладка "Архиваторы" (Рис.4.6g) содержит списки архиваторов сообщений и значений, зарегистрированных в модуле. В контекстном меню списков пользователю предоставляется возможность добавления, удаления и перехода к нужному архиватору. На вкладке "Модуль" содержится информация о модуле подсистемы "Архивы-История" (Рис.4.1d), состав которой идентичен для всех модулей.

Рис. 4.6g. Вкладка "Архиваторы" модуля подсистемы "Архивы-История".

Архиваторы сообщений содержат собственную страницу конфигурации с вкладками "Архиватор" и "Сообщения".

The "Archiver" tab (Fig.4.6h) contains the basic settings. The structure of these settings may differ slightly from one module to another one of this subsystem as you can find in the own documentation of the modules. As an example we shall examine the settings of the message archiver from the module of the archiving on the file system Arch.FSArch Settings:

• Section "State" — contains the properties, which characterize the archiver state:
  • Running — archiver state "Running". The running archiver processes the buffer of the message archive and puts his data in its repository, but also it processes requests for access to data in the repository.
  • Storage — the archiver's data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.
  • End and Begin of the archiver — date and time of the end and start of data in the archiver repository.
  • Overall size of the archiver files — information about the total size of the archiver files with the data.
  • Archiving time — current and maximum time spent on the archiving of data of the message archive.
• Section "Configuration" — directly contains the configuration fields:
  • Identifier — information on the archiver identifier.
  • Name — indicates the archiver name.
  • Description — brief description of the archiver and its purpose.
  • To start — indicates the state "Running" in which to transfer the archiver at the program startup.
  • Message categories — list of categories of messages, separated by ';'. Messages matched with the templates or regular expressions of categories will be processed by the archiver. In the category you can specify the elements of selection by template, that is the characters '*' — for any string and '?' — for any character, as well as a regular expression enclosed between the symbols '/' (/mod_(System|LogicLev)/).
  • Messages level — indicates the level of the archiver messages. Messages with the level greater than or equal to the specified one are processed by the archiver — taken from the buffer.
  • Address — address of the storage in the specific for the type of archiver (module) format. The format description usually available in the tooltip for this field. In the example it is the relative path to the storage directory.
• Section "Additional options" — a specialized section for the module, the contents of which can be found in the documentation for the module.

Рис. 4.6h. Главная вкладка конфигурации архиватора сообщений подсистемы "Архивы-История".

Вкладка "Сообщения" (Рис.4.6i) содержит форму запроса сообщений из архива данного архиватора:

• Время, размер (секунд) и уровень — указывает дату и время, размер или глубину и минимальный уровень сообщений (более или равный указанному) запроса.
• Шаблон категории — указывает категорию запрошенных сообщений. В категории можно указывать элементы выборки по шаблону, а именно символы '*' — для любой подстроки и '?' — для любого символа, а также регулярное выражение, заключённое между символами '/' (/mod_(System|LogicLev)/).

Таблица результата содержит строки сообщений с колонками:

• Время, мкс — полная дата и время сообщения, а также микросекундная часть, отдельно.
• Категория — категория сообщения.
• Уровень — уровень сообщения.
• Сообщение — непосредственно текст сообщения.

Рис. 4.6i. Вкладка запроса сообщений "Сообщения" архиватора сообщений подсистемы "Архивы-История".

Архиваторы значений содержат собственную страницу конфигурации с вкладками "Архиватор" и "Архивы".

The "Archivator" tab (Fig.4.6j) contains the basic settings. The structure of these settings may differ slightly from one module to another one of this subsystem as you can find in the own documentation of the modules. As an example we shall examine the settings of the value archiver from the module of the archiving on the file system Arch.FSArch Settings:

• Section "State" — contains the properties, which characterize the archiver state:
  • Running — archiver state "Running". The running archiver processes the buffers of the value archives and puts their data in its repository, but also it processes requests for access to data in the repository.
  • Archiving time — current and maximum time spent on the archiving of data of the buffers of the archives. Periodicity of archiving is set in the field "Period of the archiving" in the section "Configuration" of the tab.
  • Storage — the archiver's data storage, with tracking the availability of the data in different storages and providing the sequentially removing duplicates.
  • Overall size of the archiver files — information about the total size of the archiver files with the data.
• Section "Configuration" — directly contains the configuration fields:
  • Identifier — information on the archiver identifier.
  • Name — indicates the archiver name.
  • Description — brief description of the archiver and its purpose.
  • To start — indicates the state "Running" in which to transfer the archiver at the program startup.
  • Address — address of the storage in the specific for the type of archiver (module) format. The format description usually available in the tooltip for this field. In the example it is the relative path to the storage directory.
  • Period of the values — indicates the periodicity of the values those are contained in the archiver repository, in seconds.
  • Period of the archiving — indicates the periodicity of an archiving task of data of the buffers of the archives, in seconds. The size of the buffers of the archives in the time expression must not be less, and preferably somewhat greater, then the periodicity of the of archiving task. Set a zero period to disable the use of the archiver in processing the buffer — just a direct recording.
  • Selection priority — selection of a priority of the archiver for using in the source mode "All". Set to zero for full the selection disabling.
• Section "Additional options" — a specialized section for the module, the contents of which can be found in the documentation for the module.

Рис. 4.6j. Главная вкладка конфигурации архиватора значений подсистемы "Архивы-История".

Вкладка "Архивы" (Рис.4.6k) содержит таблицу с информацией об архивах, обрабатываемых архиватором. Таблица в строках содержит архивы, а в колонках информацию:

• Архив — имя архива.
• Период, секунд — периодичность архива.
• Размер буфера — размер буфера, в единицах.
• Последнее чтение буфера — дата и время последнего чтения данных из буфера.
• Размер файлов — специфичное для модуля Arch.FSArch поле с информацией о суммарном размере файлов хранилища архиватора для архива.

В случае с модулем Arch.FSArch в этой вкладке ещё содержится форма экспорта данных архиватора.

Рис. 4.6k. Вкладка "Архивы" архиватора значений подсистемы "Архивы-История".

4.7 Подсистема "Пользовательские интерфейсы"

Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Пользовательские интерфейсы", содержащая вкладку "Подсистема" и вкладку "Модули". Вкладка "Подсистема" (Рис.4.7a) в данный момент содержит только конфигурационное поле установки шрифта подсветки синтаксису коду. Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Специальные" и идентична для всех модульных подсистем.

Fig. 4.7a. Вкладка "Подсистема" корневой страницы "Пользовательские интерфейсы".

Каждый модуль подсистемы "Пользовательские интерфейсы" предоставляет конфигурационную страницу с вкладками "Пользовательский интерфейс" и "Модуль". Вкладка "Пользовательский интерфейс" (Рис.4.7b) предоставляет параметр для контроля за состоянием "Выполняется" модуля, а также разделы конфигурации, специализированные для модулей этой подсистемы. Во вкладке "Модуль" содержится информация о модуле подсистемы "Пользовательские интерфейсы" (Рис.4.1d), состав которой идентичен для всех модулей.

Рис. 4.7b. Вкладка "Пользовательский интерфейс" модуля подсистемы "Пользовательские интерфейсы".

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

4.8 Подсистема "Специальные"

Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Специальные", содержащая вкладку "Модули". Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Специальные" и идентична для всех модульных подсистем.

Каждый модуль подсистемы "Специальные" предоставляет конфигурационную страницу с вкладками "Специальный" и "Модуль". Вкладка "Специальный" (Рис.4.8) предоставляет параметр для контроля за состоянием "Выполняется" модуля, а также разделы конфигурации, специализированные для модулей этой подсистемы. Во вкладке "Модуль" содержится информация о модуле подсистемы "Специальные" (Рис.4.1d), состав которой идентичен для всех модулей.

Рис. 4.8. Вкладка "Специальный" модуля подсистемы "Специальные".

4.9 Подсистема "Диспетчер модулей"

Подсистема не является модульной. Для конфигурации подсистемы "Диспетчер модулей" предусмотрена страница подсистемы, содержащая вкладку "Подсистема". Вкладка "Подсистема" (Рис.4.9) содержит основные настройки подсистемы в составе:

• Путь к разделяемым библиотекам (модулям) — информация о расположении директории с модулями OpenSCADA. Устанавливается параметром ModDir конфигурационного файла станции.
• Запрещённые модули — список модулей, разделённый символом ';', запрещённых для автоматического подключения и обновления. Устанавливается параметром ModDeny раздела подсистемы "sub_ModSched" конфигурационного файла станции. Список запрещённых модулей имеет больший приоритет чем разрешённых.
• Разрешённые модули — список модулей, разделённый символом ';', разрешённых для автоматического подключения и обновления. Значение '*' используется для разрешения всех модулей. Устанавливается параметром ModAllow раздела подсистемы "sub_ModSched" конфигурационного файла станции.
• Период проверки модулей — указывает на период проверки модулей на факт их обновления, в секундах. Модули, допустимые для автоматического подключения и обновления, будут автоматически обновлены.
• Проверить модули сейчас — команда выполнить проверку модулей на факт их обновления. Модули, допустимые для автоматического подключения и обновления, будут автоматически обновлены.
• Разделяемые библиотеки (модули) — таблица с перечнем разделяемых библиотек с модулями, обнаруженными OpenSCADA. В строках расположены модули, а в колонках информация о них:
  • Источник — источник модуля(ей), который или разделяемая библиотека или встроенный код.
  • Время — информация о дате и времени последней модификации файла разделяемой библиотеки.
  • Модули — информация о перечне модулей в разделяемой библиотеке.
  • Включен — состояние "Включен" разделяемой библиотеки. Привилегированным пользователям предоставляется возможность ручного включения/выключения разделяемых библиотек путём изменения этого поля.

Рис. 4.9. Главная вкладка конфигурации подсистемы "Диспетчер модулей".

4.10 Конфигурационный Файл и параметры командной строки

Конфигурационный Файл OpenSCADA предназначен для хранения основной конфигурации станции OpenSCADA. Только в Конфигурационном Файле и через параметры командной строки можно указать часть ключевых параметров станции, поэтому знакомство со структурой конфигурационного файла необходимо специалистам, разворачивающим специфические решения на основе OpenSCADA. Больше информации про запуск и исполнение OpenSCADA может быть найдено в секции "Запуск и исполнение".

<?xml version='1.0' encoding='UTF-8' ?>
<OpenSCADA>
    <!--
    This is the OpenSCADA configuration file.
    -->
    <station id="SimulatorStation">
        <!--
        Description of the internal parameters of the station.
        The station is the OpenSCADA program.
        -->
        <prm id="StName">AGLKS</prm>
        <prm id="WorkDB">SQLite.GenDB</prm>
        <prm id="LogTarget">10</prm>
        <prm id="LangBase">en_US.UTF-8;uk_UA.UTF-8;ru_RU.UTF-8</prm>
        <prm id="SaveAtExit">0</prm>
        <prm id="SavePeriod">0</prm>

        <node id="sub_BD">
            <tbl id="DB">
                <fld ID="GenDB" TYPE="SQLite" NAME="Generic DB" NAME_uk="Основна БД" NAME_ru="Основная БД" ADDR="St.db" CODEPAGE="UTF-8" />
            </tbl>
        </node>

        <node id="sub_Security">
            <tbl id="Security_user">
                <fld NAME="roman" DESCR="Roman Savochenko" PASS="$1$roman$wleNCf/uyA84cGpBn5QuG." />
                <fld NAME="root" DESCR="Administrator (superuser)!!!" DESCR_uk="Супер користувач" DESCR_ru="Супер пользователь" PASS="$1$root$lCn57dP9yzkCIAyrwJ24r1" />
                <fld NAME="test" DESCR="Test user" PASS="$1$test$pi/xDtU5WFVRqYS6BMU8X/" />
                <fld NAME="user" DESCR="Simple user" DESCR_uk="Звичайний користувач" DESCR_ru="Простой пользователь" PASS="$1$user$k8sntSoh7jhsc6lwspjsU." />
            </tbl>
            <tbl id="Security_grp">
                <fld NAME="Archive" DESCR="Archives-History" DESCR_uk="Архіви-Історія" DESCR_ru="Архивы-История" />
                <fld NAME="BD" DESCR="Databases" DESCR_uk="Бази даних" DESCR_ru="Базы данных" />
                <fld NAME="DAQ" DESCR="Data acquisition" DESCR_uk="Збір даних" DESCR_ru="Сбор данных" />
                <fld NAME="ModSched" DESCR="Modules scheduler" DESCR_uk="Диспетчер модулів" DESCR_ru="Диспетчер модулей" />
                <fld NAME="Protocol" DESCR="Transport protocols" DESCR_uk="Транспортні протоколи" DESCR_ru="Транспортные протоколы" />
                <fld NAME="Security" DESCR="Security" DESCR_uk="Безпека" DESCR_ru="Безопасность" />
                <fld NAME="Special" DESCR="Specials" DESCR_uk="Спеціальні" DESCR_ru="Специальные" />
                <fld NAME="Transport" DESCR="Transports" DESCR_uk="Транспорти" DESCR_ru="Транспорты" />
                <fld NAME="UI" DESCR="User Interfaces" DESCR_uk="Інтерфейси користувача" DESCR_ru="Интерфейсы пользователя" />
                <fld NAME="root" DESCR="Administartors group" DESCR_uk="Група адміністраторів" DESCR_ru="Группа администраторов" USERS="roman;" />
                <fld NAME="users" DESCR="Users group" DESCR_uk="Група користувачів" DESCR_ru="Группа пользователей" USERS="test;user;" />
                <fld NAME="ITW" DESCR="IT worker" DESCR_uk="Робітник IT" DESCR_ru="Работник IT"
                    LONGDESCR="Information Technology or service worker."
                    LONGDESCR_uk="Робітник Інформаційних Технологій та сервісу."
                    LONGDESCR_ru="Работник Информационных Технологий и сервиса." />
                <fld NAME="op" DESCR="Operator" DESCR_uk="Оператор" DESCR_ru="Оператор" />
            </tbl>
        </node>

        <node id="sub_ModSched">
            <prm id="ModAllow">*</prm>
            <prm id="ModDeny" />
            <prm id="ChkPer">0</prm>
        </node>

        <node id="sub_Transport">
            <tbl id="ExtTansp">
                <fld OP_USER="roman" ID="loop" NAME="Loop" NAME_uk="Петля" NAME_ru="Петля" TRANSP="Sockets" ADDR="TCP:localhost:10005" USER="roman" PASS="roman" />
                <fld OP_USER="*" ID="loop" NAME="Loop" NAME_uk="Петля" NAME_ru="Петля" TRANSP="Sockets" ADDR="TCP:localhost:10005" USER="roman" PASS="roman" />
                <fld OP_USER="roman" ID="loopSSL" NAME="Loop SSL" NAME_uk="Петля SSL" NAME_ru="Петля SSL" TRANSP="SSL" ADDR="localhost:10045" USER="roman" PASS="roman" />
                <fld OP_USER="*" ID="loopSSL" NAME="Loop SSL" NAME_uk="Петля SSL" NAME_ru="Петля SSL" TRANSP="SSL" ADDR="localhost:10045" USER="roman" PASS="roman" />
            </tbl>
            <tbl id="Transport_in">
                <fld ID="Self" MODULE="Sockets" NAME="Self system" DESCRIPT="Main transport of OpenSCADA self protocol."
                        DESCRIPT_uk="Основний транспорт власного протоколу OpenSCADA." DESCRIPT_ru="Основной транспорт собственного протокола OpenSCADA." ADDR="TCP::10005:1" PROT="SelfSystem" START="1">
                    <A_PRMS>&amp;lt;prms MaxQueue="10" MaxClients="20" MaxClientsPerHost="5" BufLen="5" KeepAliveReqs="0" KeepAliveTm="60" /&amp;gt;</A_PRMS>
                </fld>
                <fld ID="WEB_1" MODULE="Sockets" NAME="WEB 1" DESCRIPT="Main transport of the WEB interfaces."
                        DESCRIPT_uk="Основний транспорт WEB інтерфейсів." DESCRIPT_ru="Основной транспорт WEB интерфейсов." ADDR="TCP::10002:0" PROT="HTTP" START="1">
                    <A_PRMS>&amp;lt;prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /&amp;gt;</A_PRMS>
                </fld>
                <fld ID="WEB_2" MODULE="Sockets" NAME="WEB 2" DESCRIPT="Reserve transport of the WEB interfaces."
                        DESCRIPT_uk="Резервний транспорт WEB інтерфейсів." DESCRIPT_ru="Резервный транспорт WEB интерфейсов." ADDR="TCP::10004:0" PROT="HTTP" START="1">
                    <A_PRMS>&amp;lt;prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /&amp;gt;</A_PRMS>
                </fld>
            </tbl>
            <!--
            <tbl id="Transport_out">
                <fld
                    ID="testModBus"
                    MODULE="Sockets"
                    NAME="Test ModBus"
                    NAME_uk="Тест ModBus"
                    NAME_ru="Тест ModBus"
                    DESCRIPT="ModBus protocol exchange test."
                    DESCRIPT_uk="Тест обміну за протоколом ModBus."
                    DESCRIPT_ru="Тест обмена по протоколу ModBus."
                    ADDR="TCP:localhost:10502"
                    START="1"/>
            </tbl>-->
        </node>

        <node id="sub_DAQ">
            <!--
            <tbl id="tmplib">
                <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" DB="tmplib_test2"/>
            </tbl>
            <tbl id="tmplib_test2">
                <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                    PROGRAM="JavaLikeCalc.JavaScript&amp;#010;cnt=5*i;"/>
            </tbl>
            <tbl id="tmplib_test2_io">
                <fld TMPL_ID="test2" ID="i" NAME="I" NAME_uk="I" NAME_ru="I" TYPE="4" FLAGS="160" VALUE="" POS="0"/>
                <fld TMPL_ID="test2" ID="cnt" NAME="Cnt" NAME_uk="Cnt" NAME_ru="Cnt" TYPE="4" FLAGS="32" VALUE="" POS="0"/>
            </tbl>-->

            <node id="mod_LogicLev">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="test2"
                        NAME="Test 2"
                        NAME_uk="Тест 2"
                        NAME_ru="Тест 2"
                        DESCR=""
                        ENABLE="1"
                        START="1"
                        PRM_BD="test2prm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                        EN="1" MODE="2" PRM="test2.test2"/>
                </tbl>-->
            </node>

            <node id="mod_System">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="dataOS"
                        NAME="OS data"
                        NAME_uk="Дані ОС"
                        NAME_ru="Даные ОС"
                        DESCR="Data of services and subsystems of OS."
                        DESCR_uk="Дані сервісів та підсистем ОС."
                        DESCR_ru="Данные сервисов и подсистем ОС."
                        ENABLE="1"
                        START="1"
                        AUTO_FILL="0"
                        PRM_BD="DataOSprm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="DataOSprm">
                    <fld SHIFR="CPU" NAME="CPU load" NAME_uk="Навантаження CPU" NAME_ru="Нагрузка CPU" DESCR=""
                        EN="1" TYPE="CPU" SUBT="gen"/>
                    <fld SHIFR="MEM" NAME="Memory" NAME_uk="Пам'ять" NAME_ru="Память" DESCR="" EN="1" TYPE="MEM"/>
                </tbl>
                -->
            </node>

            <node id="mod_DiamondBoards">
                <!--
                <tbl id="DAQ">
                    <fld ID="Athena" NAME="Athena board" NAME_uk="Плата Athena" NAME_ru="Плата Athena" DESCR=""
                        ENABLE="1" START="0" BOARD="25" PRM_BD_A="AthenaAnPrm" PRM_BD_D="AthenaDigPrm" ADDR="640" INT="5"
                        DIO_CFG="0" ADMODE="0" ADRANGE="0" ADPOLAR="0" ADGAIN="0" ADCONVRATE="1000"/>
                </tbl>
                <tbl id="AthenaAnPrm">
                    <fld SHIFR="ai0" NAME="AI 0" NAME_uk="AI 0" NAME_ru="AI 0" DESCR="" EN="0" TYPE="0" CNL="0" GAIN="0"/>
                </tbl>
                <tbl id="AthenaDigPrm">
                    <fld SHIFR="di0" NAME="DI 0" NAME_uk="DI 0" NAME_ru="DI 0" DESCR="" EN="0" TYPE="0" PORT="0" CNL="0"/>
                </tbl>
                -->
            </node>

            <node id="mod_BlockCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="Model" NAME="Model" NAME_uk="Модель" NAME_ru="Модель" DESCR=""
                        ENABLE="1" START="1" PRM_BD="Model_prm" BLOCK_SH="Model_blcks" PERIOD="1000" PRIOR="0" PER_DB="0" ITER="1"/>
                </tbl>
                <tbl id="Model_blcks">
                    <fld ID="Klap" NAME="Klapan" NAME_uk="Клапан" NAME_ru="Клапан" DESCR=""
                        FUNC="DAQ.JavaLikeCalc.lib_techApp.klap" EN="1" PROC="1"/>
                </tbl>
                <tbl id="Model_blcks_io">
                    <fld BLK_ID="Klap" ID="l_kl1" TLNK="0" LNK="" VAL="50"/>
                    <fld BLK_ID="Klap" ID="l_kl2" TLNK="0" LNK="" VAL="20"/>
                </tbl>
                <tbl id="Model_prm">
                    <fld SHIFR="l_kl" NAME="Klap level" NAME_uk="Положення клапану" NAME_ru="Положение клапана" DESCR=""
                        EN="1" IO="Klap.l_kl1"/>
                </tbl>
                -->
            </node>

            <node id="mod_JavaLikeCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="CalcTest" NAME="Calculation test" NAME_uk="Тест обчислення" NAME_ru="Тест вычисления" DESCR=""
                        ENABLE="1" START="1" PRM_BD="CalcTest_prm" FUNC="TemplFunc.d_alarm" SCHEDULE="1" PRIOR="0" ITER="1"/>
                </tbl>
                <tbl id="CalcTest_val">
                    <fld ID="in" VAL="0"/>
                    <fld ID="alrm" VAL=""/>
                    <fld ID="alrm_md" VAL="1"/>
                    <fld ID="alrm_mess" VAL="Error present."/>
                </tbl>
                <tbl id="CalcTest_prm">
                    <fld SHIFR="alrm" NAME="Alarm" NAME_uk="Аварія" NAME_ru="Авария" DESCR="" EN="1" FLD="alrm"/>
                </tbl>
                <tbl id="lib">
                    <fld ID="TemplFunc" NAME="" DESCR="" DB="lib_TemplFunc"/>
                </tbl>
                <tbl id="lib_TemplFunc">
                    <fld ID="d_alarm" NAME="Digit alarm" NAME_uk="Аварія за дискретним" NAME_ru="Авария по дискретному" DESCR=""
                        FORMULA="alrm=(in==alrm_md)?&amp;quot;1:&amp;quot;+alrm_mess:&amp;quot;0&amp;quot;;"/>
                </tbl>
                <tbl id="lib_TemplFunc_io">
                    <fld F_ID="d_alarm" ID="in" NAME="Input" NAME_uk="Вхід" NAME_ru="Вход" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
                    <fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_uk="Аварія" NAME_ru="Авария" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
                    <fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_uk="Режим аварії" NAME_ru="Режим аварии"
                        TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
                    <fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_uk="Повідомлення аварії" NAME_ru="Сообщение аварии"
                        TYPE="0" MODE="0" DEF="" HIDE="0" POS="3"/>
                </tbl>-->
            </node>

            <node id="mod_Siemens">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" CIF_DEV="0" ADDR="5" ASINC_WR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" TMPL="S7.ai_man"/>
                </tbl>-->
            </node>

            <node id="mod_SNMP">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                        ENABLE="1" START="1" PRM_BD="test2prm" PERIOD="1000" PRIOR="0" ADDR="localhost" COMM="public" PATTR_LIM="20"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" OID_LS="system"/>
                </tbl>-->
            </node>

            <node id="mod_ModBus">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" TRANSP="Sockets" ADDR="exlar.diya.org" NODE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1"
                        ATTR_LS="321:0:tst:Test"/>
                </tbl>-->
            </node>

            <node id="mod_DAQGate">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" SYNCPER="60" STATIONS="loop" CNTRPRM="System.AutoDA"/>
                </tbl>-->
            </node>

            <node id="mod_DCON">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" ADDR="" REQ_TRY="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" MOD_TP="0"
                        MOD_ADDR="1" CRC_CTRL="1"/>
                </tbl>-->
            </node>

            <node id="mod_ICP_DAS">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" BUS="1" BAUD="115200" LP_PRMS="" REQ_TRY="3"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1"
                        MOD_TP="552985" MOD_ADDR="0" MOD_SLOT="1" MOD_PRMS="0"/>
                </tbl>-->
            </node>

            <node id="mod_OPC_UA">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" SCHEDULE="1" PRIOR="0" SYNCPER="60" ADDR="" EndPoint="opc.tcp://localhost:4841" SecPolicy="None"
                        SecMessMode="1" Cert="" PvKey="" AttrsLimit="100"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" ND_LS=""/>
                </tbl>-->
            </node>

            <node id="mod_SoundCard">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" CARD="" SMPL_RATE="8000" SMPL_TYPE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" CHANNEL="0"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Archive">
            <prm id="MessBufSize">1000</prm>
            <prm id="MessPeriod">5</prm>
            <prm id="ValPeriod">1000</prm>
            <prm id="ValPriority">10</prm>
            <!--
            <tbl id="Archive_mess_proc">
                <fld
                    ID="StatErrors"
                    MODUL="FSArch"
                    NAME="Errors"
                    NAME_uk="Помилки"
                    NAME_ru="Ошибки"
                    DESCR="Archive of local errors"
                    DESCR_uk="Архів локальних помилок"
                    DESCR_ru="Архив локальных ощибок"
                    START="1"
                    CATEG="/DemoStation*"
                    LEVEL="4"
                    ADDR="ARCHIVES/MESS/stError/"/>
                <fld
                    ID="NetRequsts"
                    MODUL="FSArch"
                    NAME="Network requests"
                    NAME_uk="Мережеві запити"
                    NAME_ru="Сетевые запросы"
                    DESCR="Requests to the server via Sockets transport."
                    DESCR_uk="Запити до сервера через транспорт Sockets."
                    DESCR_ru="Запросы к серверу через транспорт Sockets."
                    START="1"
                    CATEG="/DemoStation/Transport/Sockets*"
                    LEVEL="1"
                    ADDR="ARCHIVES/MESS/Net/"/>
            </tbl>
            <tbl id="Archive_val_proc">
                <fld
                    ID="1h"
                    MODUL="FSArch"
                    NAME="1hour"
                    NAME_uk="1година"
                    NAME_ru="1час"
                    DESCR="Averaging at hour"
                    DESCR_uk="Усереднення за годину"
                    DESCR_ru="Усреднение за час"
                    START="1"
                    ADDR="ARCHIVES/VAL/1h/"
                    V_PER="360"
                    A_PER="60"/>
            </tbl>
            <tbl id="Archive_val">
                <fld
                    ID="test1"
                    NAME="Test 1"
                    NAME_uk="Тест 1"
                    NAME_ru="Тест 1"
                    DESCR="Test 1"
                    DESCR_uk="Тест 1"
                    DESCR_ru="Тест 1"
                    START="1"
                    VTYPE="1"
                    BPER="1"
                    BSIZE="200"
                    BHGRD="1"
                    BHRES="0"
                    SrcMode="0"
                    Source=""
                    ArchS=""/>
            </tbl>-->
        </node>

        <node id="sub_Protocol">
        </node>

        <node id="sub_UI">
            <node id="mod_QTStarter">
                <prm id="StartMod">QTCfg</prm>
                <prm id="CloseToTray">0</prm>
                <prm id="Style"></prm>
                <prm id="Palette"></prm>
                <prm id="StyleSheets"></prm>
                <tbl id="LookFeel">
                    <fld NAME="Typical TDE" STYLE="" STL_SHTS="">
                        <PALETTE>#000000, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #000000, #ffffff, #000000, #ffffff, #efefef, #000000, #678db2, #ffffff, #0000ee, #52188b
#808080, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #c7c7c7, #ffffff, #808080, #ffffff, #efefef, #000000, #567594, #ffffff, #0000ee, #52188b
#000000, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #000000, #ffffff, #000000, #ffffff, #efefef, #000000, #678db2, #ffffff, #0000ee, #52188b</PALETTE>
                    </fld>
                    <fld NAME="Blue Slate" STYLE="" STL_SHTS="">
                        <PALETTE>#000000, #9db9c8, #f6fcff, #c9dae3, #4e5c64, #697b85, #000000, #bfe2f4, #000000, #c3c3c3, #9db9c8, #000000, #558097, #ffffff, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000
#808080, #9db9c8, #f6fcff, #b5d5e6, #4e5c64, #697b85, #808080, #bfe2f4, #808080, #c3c3c3, #9db9c8, #000000, #558097, #808080, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000
#000000, #9db9c8, #f6fcff, #b5d5e6, #4e5c64, #697b85, #000000, #bfe2f4, #000000, #c3c3c3, #9db9c8, #000000, #558097, #ffffff, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000</PALETTE>
                    </fld>
                    <fld NAME="Blue Darkness" STYLE="" STL_SHTS="">
                        <PALETTE>#ffffff, #426794, #5788c3, #4871a2, #162231, #37567b, #dcdcdc, #5788c3, #ffffff, #002a4e, #426794, #000000, #5cb3ff, #000000, #00ffff, #c0c0ff
#555555, #426794, #5788c3, #4871a2, #162231, #37567b, #37567b, #5788c3, #555555, #002a4e, #426794, #000000, #4c95d4, #ffffff, #00ffff, #c0c0ff
#ffffff, #426794, #5788c3, #4871a2, #162231, #37567b, #dcdcdc, #5788c3, #ffffff, #002a4e, #426794, #000000, #5cb3ff, #000000, #00ffff, #c0c0ff</PALETTE>
                    </fld>
                </tbl>
            </node>
            <node id="mod_QTCfg">
                <prm id="StartUser">roman</prm>
            </node>
            <node id="mod_Vision">
                <prm id="StartUser">roman</prm>
            </node>
            <node id="mod_WebCfg">
                <prm id="SessTimeLife">20</prm>
            </node>
            <node id="mod_VCAEngine">
                <!--
                <tbl id="LIB">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                        DB_TBL="wlib_test2" ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2">
                    <fld ID="test2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2_io">
                    <fld IDW="test2" ID="name" IO_VAL="Test 2" IO_VAL_uk="Тест 2" IO_VAL_ru="Тест 2" SELF_FLG="" CFG_TMPL="" CFG_VAL=""/>
                    <fld IDW="test2" ID="dscr" IO_VAL="Test of the module 2" IO_VAL_uk="Тест модуля 2" IO_VAL_ru="Тест модуля 2" SELF_FLG="" CFG_TMPL="" CFG_VAL=""/>
                </tbl>
                <tbl id="PRJ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" DB_TBL="prj_test2" ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="prj_test2">
                    <fld OWNER="/test2" ID="pg1" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_PER="-1" USER="root" GRP="UI" PERMIT="436" FLGS="1"/>
                    <fld OWNER="/test2/pg1" ID="pg2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_PER="-1" USER="root" GRP="UI" PERMIT="436" FLGS="0"/>
                </tbl>
                <tbl id="prj_test2_incl">
                    <fld IDW="/prj_test2/pg_pg1" ID="wdg1" PARENT="/wlb_originals/wdg_Box"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Special">
            <node id="mod_SystemTests">
                <prm id="Param" on="0" per="5" name="LogicLev.experiment.F3" />
                <prm id="XML" on="0" per="10" file="/etc/oscada.xml" />
                <prm id="Mess" on="0" per="10" arhtor="DBArch.test3" depth="10" />
                <prm id="SOAttach" on="0" per="20" name="../../lib/openscada/daq_LogicLev.so" mode="0" full="1" />
                <prm id="Val" on="0" per="1" name="LogicLev.experiment.F3.var" arch_len="5" arch_per="1000000" />
                <prm id="Val" on="0" per="1" name="System.AutoDA.CPULoad.load" arch_len="10" arch_per="1000000" />
                <prm id="DB" on="0" per="10" type="MySQL" addr="server.diya.org;roman;123456;oscadaTest" table="test" size="1000" />
                <prm id="DB" on="0" per="10" type="DBF" addr="./DATA/DBF" table="test.dbf" size="1000" />
                <prm id="DB" on="0" per="10" type="SQLite" addr="./DATA/test.db" table="test" size="1000" />
                <prm id="DB" on="0" per="10" type="FireBird" addr="server.diya.org:/var/tmp/test.fdb;roman;123456" table="test" size="1000" />
                <prm id="TrOut" on="0" per="1" addr="TCP:127.0.0.1:10001" type="Sockets" req="time" />
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:10001" type="Sockets" req="time" />
                <prm id="TrOut" on="0" per="1" addr="UNIX:./oscada" type="Sockets" req="time" />
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:daytime" type="Sockets" req="time" />
                <prm id="SysContrLang" on="0" per="10" path="/Archive/FSArch/mess_StatErrors/%2fprm%2fst" />
                <prm id="ValBuf" on="0" per="5" />
                <prm id="Archive" on="0" per="30" arch="test1" period="1000000" />
                <prm id="Base64Code" on="0" per="10" />
            </node>
        </node>
  </station>

</OpenSCADA>

Детально рассмотрим структуру конфигурационного файла. Один конфигурационный файл может содержать конфигурацию нескольких станций в секциях <station id="SimulatorStation"/>. Атрибутом "id" указывается идентификатор станции — класс станции. Использование той или иной секции станции указывается параметром командной строки --station=SimulatorStation, при вызове. Секция станции непосредственно содержит параметры станции и секции подсистем. Параметры конфигурации секции записываются в виде <prm id="StName">AGLKS</prm>, где атрибутом "id" указывается идентификатор параметра, а в теле тега "prm" указывается значение параметра "AGLKS". Перечень доступных параметров и их описание для станции и всех остальных секций можно получить в консоли, посредством вызова OpenSCADA с параметром --help.

Секции подсистем <node id="sub_DAQ" /> содержат: параметры подсистемы, секции модулей и секции таблиц отражения данных баз данных в конфигурационном файле. Секции модулей <node id="mod_DiamondBoards" /> содержат индивидуальные параметры модулей и секции таблиц отражения данных баз данных в конфигурационном файле.

Default values of the command-line options and generic parameters you can pass through environment variables in form "OSCADA_{OPT}={VAL}" after enabling by the environment variable OSCADA_CMD_EN, like to — OSCADA_CMD_EN=1 OSCADA_log=0 OSCADA_limObjDscr_SZ=1000 OSCADA_sub_UI_mod_QTStarter_Style=Fusion ./openscada_AGLKS. That is you can prepare individual default environment of OpenSCADA execution for your system in whole in a file of the folder /etc/profile.d/ or for concrete user in the file {USER-HOME}/.profile.

Секции таблиц отражения данных баз данных предназначены для размещения в конфигурационном файле записей таблиц БД для компонентов OpenSCADA. Рассмотрим таблицу входных транспортов "Transport_in" подсистемы "Транспорты" <node id="sub_Transport"> из приведенного выше примера конфигурационного файла. Таблица содержит три записи с полями: ID, MODULE, NAME, DESCRIPT, ADDR, PROT, START. После загрузки с такой секцией и вообще без БД в подсистеме "Транспорты" модуля "Sockets" появятся три входных транспорта. Форматы структур таблиц основных компонентов включены в демонстрационные конфигурационные файлы — модели технологических процессов. За деталями структур таблиц БД обращайтесь к документации соответствующих модулей или просто сохраните нужный объект в конфигурационный файл.

***************************************************************************
********** OpenSCADA v0.9+r2535 (Linux-4.9.0-0.bpo.5-amd64). *********
***************************************************************************

===========================================================================
==================== Generic options ======================================
===========================================================================
-h, --help              This help text about the program command-line options and configuration file parameters.
    --projName=<name>   OpenSCADA project name to switch it.
                        For this feature there also uses an environment variable "OSCADA_ProjName" and the program binary name "openscada_{ProjName}".
    --projUserDir={dir} Directory of user projects (writeable) of OpenSCADA, "~/.openscada" by default.
    --projLock={per}    Uses the projects locking by creation the \"lock\" file in the project folder and update it in the period <per>,
                        by default it is enabled and the updating period <per> is 60 seconds. To disable set the updating period <per> to zero.
    --lang=<LANG>       Station language, in the view "en_US.UTF-8".
    --config=<file>     Station configuration file.
    --station=<id>      Station identifier.
    --statName=<name>   Station name.
    --modDir=<path>	Directories with the modules, separated by ';', they can include a files' template at the end.
    --messLev=<level>   Level of the processing messages (0-7).
    --log=<direct>      Direct messages to, by the bitfield:
                          0x1 - syslogd;
                          0x2 - stdout;
                          0x4 - stderr;
                          0x8 - the messages archive.
    --consoleCharSet={CharSet} Forcing to the console <CharSet> for the console messages, by default it is system one.
    --demon, --daemon   Run in the daemon mode.
    --pidFile=<file>    File for the program process ID placing here.
    --noCoreDump        Prevents from the core dump creation at crashes - don't set the limit to the unlimited value.
    --permCrtFiles={perm} Permissions of the created OpenSCADA files, by default it is 0755 (RWXRW_RW_).
----------- Station 'AGLKS(SimulatorStation)' settings in the configuration file -----------
StName     <nm> Station name.
WorkDB     <Type.Name> Working DB (<type> and <name>).
WorkDir    <path>       Working directory.
ModDir     <path>       Directories with the modules, separated by ';', they can include a files' template at the end.
IcoDir     <path>       Icons directory.
DocDir     <path>       Documents directory.
MessLev    <level>      Level of the processing messages (0-7).
SelDebCats <list>       Debug categories list, separated by ';'.
LogTarget  <direction> Direct messages to, by the bitfield:
                          0x1 - syslogd;
                          0x2 - stdout;
                          0x4 - stderr;
                          0x8 - the messages archive.
Lang       <lang>       Station language-locale in the view "en_US.UTF-8".
LangBase   <lang>       Base language and the project whole locales (like to "en_US.UTF-8") list (optional) separated by ';', for the multilanguage mode.
MainCPUs   <list>       Main list of the using CPUs, separated by ':'.
TaskInvPhs <n>          Number of phases of the task invoking, 1 to disable the phasing.
ClockRT    <0|1>        Sets the clock source to use to REALTIME (otherwise MONOTONIC), which is problematic one at the system clock modification.
SaveAtExit <0|1>        Save the program at exit.
SavePeriod <seconds>    Period of the program saving, 0 to disable.
ModifCalc  <0|1>        Set modification for the calculated objects.
RdStLevel  <lev>        Level of the redundancy of the current station.
RdTaskPer  <seconds>    Call period of the redundancy task.
RdRestConnTm <seconds>  Time to restore connection to "dead" reserve station.
RdStList   <list>       Redundant stations list, separated symbol ';' (st1;st2).
RdPrimCmdTr <0|1>       Enables the transmission of primary commands to the reserve stations.
    Global configurable limits:
limObjID_SZ     [*20..50] ID size of the OpenSCADA objects.
                WARNING! Big size can cause the key limit error on MySQL like DB!
                         Change that once before use on DBs with the fixed type "char({N})"!
limObjNm_SZ     [*100...200] NAME size of the OpenSCADA objects.
                WARNING! Change that once before use on DBs with the fixed type "char({N})"!
limObjDscr_SZ	[300...*1000...1000000] DESCR size of the OpenSCADA objects.
limArchID_SZ    [*50...90] ID size of the value archive objects.
                WARNING! Increase it only, else you can get problems on Archive.FSArch!
                         Change that once before use on DBs with the fixed type "char({N})"!
limUserFile_SZ  [1MB...*10MB...1000MB] The files size limit at loading and processing in the userspace
                and the part size of the big files transferring.
limUserIts_N    [1000...*1000000...1000000000] The limit on count of creating user items, like to array items.
limCacheIts_N   [*100...100000] The limit on count of the caching items.
limCacheIts_TM	[10...*60...1000] The limit on the caching items time, seconds.
    Global configurable parameters:
prmStrBuf_SZ    [1000...*10000...1000000] Length of string buffers, no string class.
prmWait_DL      [0.001...*0.1...1] Quantum of the waiting time cycles, seconds.
prmWait_TM      [*5...10] Standard waiting timeout length, seconds.
prmInterf_TM    [*7...15] Time of waiting for the interface reaction, seconds.
prmServTask_PER [1...*10...120] Service task period, seconds.

========================= Опции подсистемы "БД" =========================
---------- Параметры секции '/sub_BD/' конфигурационного файла ----------
TblLifeTime  <секунд>   Время жизни открытых таблиц (по умолчанию 600 секунд).

==================== Опции подсистемы "Безопасности" ====================

====================== Опции подсистемы "Транспорты" ====================

======================= Module <Transport:Sockets> options =======================
    --getaddrinfo[=<lev>] Use getaddrinfo() for resolving all addresses.
                        <lev> - level of using:
                                1(default) - with global resource locking;
                                2 - without the locking.

========================== Опции модуля <Transport:Serial> ==========================
------ Параметры модульной секции '/sub_Transport/mod_Serial/' конфигурационного файла ------
OutLifeTime  <секунд>   Время жизни выходного транспорта (по умолчанию 0 секунд), 0 - для выключения функции.

======================= Module <Transport:SSL> options =======================
    --getaddrinfo[=<lev>] Use getaddrinfo() for resolving all addresses.
                        <lev> - level of using:
                                1(default) - with global resource locking;
                                2 - without the locking.

============== Опции подсистемы "Транспортные Протоколы" ================

======================= Опции модуля <Protocol:HTTP> =============================
------ Параметры модульной секции '/sub_Protocol/mod_HTTP/' конфигурационного файла ------
AuthTime   <мин>        Время жизни сеанса аутентификации, минут (по умолчанию 10).

=================== Опции подсистемы "Сбор данных" ======================
---------- Параметры секции '/sub_DAQ/' конфигурационного файла ----------
RdRestDtTm <час>        Глубина восстановления данных архива из резервной станции, при включении, в часах.

======================== Subsystem "Archives-History" options ===================
------ Parameters of the section '/sub_Archive/' of the configuration file ------
MessBufSize  <items>    Size of the messages buffer.
MessPeriod   <seconds>  Period of the messages archiving.
ClrAlrmDays  <days>     Days of the alarms automatic clearing.
ValPeriod    <mseconds> Period of active archiving of values.
ValPriority  <level>    Level of priority of the task of active archiving of values.
RdRestDtOverTm <days>   Depth of the forced overloading of the reserve history at startup, in days.

======================= Опции модуля <Archive:FSArch> =============================
    --noArchLimit       Отключить лимит на количество файлов.
                        Используйте для режима просмотра архивов, не для работы.

===================== Опции подсистемы "Специальные" ====================

========================== Опции модуля <Special:SystemTests> ==========================
------ Параметры модульной секции '/sub_Special/mod_SystemTests/' конфигурационного файла ------
       *** Общие опции всех тестов ***
  id                    идентификатор теста;
  on                    флаг включения теста;
  per                   период повторения, секунд.
       *** Опции тестов ***
  1) Param      Тест DAQ параметров. Вычитывает атрибуты и конфигурационные поля параметра.
    1:name      Адрес DAQ параметра
  2) XML        Тест разбора файла XML. Разбирает и отображает структуру указанного файла.
    1:file      XML файл
  3) Mess       Тест архива сообщений. Периодически вычитывает новые сообщения из архива, для указанного архиватора.
    1:arhtor    Архиватор
    2:categ     Шаблон категории сообщения
    3:depth     Глубина сообщения, секунд
  4) SOAttach   Тест подключения/отключения модулей.
    1:name      Путь к модулю
    2:mode      Режим (1-подключение;-1-отключение;0-изменение)
    3:full      Полное подключение(при старте)
  5) Val        Тест значений атрибута параметра.
Выполняет периодический опрос последнего значения указанного атрибута, а также опрос архива на указанную глубину.
    1:name      Путь к атрибуту параметра
    2:arch_len  Глубина получения архивных значений, секунд
    3:arch_per  Глубина получения архивных значений, микросекунды
  6) DB Полный тест БД. Выполняет:
  - создание/открытие БД;
  - создание/открытие таблицы;
  - создание множества записей (строк) предопределённой структуры;
  - модификация множества записей;
  - получение и проверка значений множества записей;
  - модификация структуры записи и таблицы;
  - удаление записей;
  - закрытие/удаление таблицы;
  - закрытие/удаление БД.
    1:type      Тип БД
    2:addr      Адрес БД
    3:table     Таблица БД
    4:size      Количество записей
  7) TrOut      Тест выходных и/или входных транспортов.
Выполняет тестирование выходного транспорта путём отправки запроса к указанному входному транспорту.
    1:addr      Адрес
    2:type      Модуль транспорта
    3:req       Текст запиту
  8) SysContrLang       Тест языка управления программой.
Производит запрос элементов языка посредством полного пути.
Полный путь к элементу языка имеет вид </Archive/%2fbd%2fm_per>.
Полный путь состоит из двух вложенных путей.
Первый </Archive/> это путь к узлу дерева контроля.
Второй </bd/m_per> это путь к конкретному элементу узла.
    1:path      Путь к элементу языка
  9) ValBuf     Тесты буфера значений.
Содержит 13 тестов всех аспектов буфера значений (подсистема "Архивы").
  10) Archive   Тесты размещения в архиве значений.
Содержит 7(8) тестов архиватора значений на проверку корректности функционирования последовательного механизма упаковки.
    1:arch      Архив значений
    2:period    Период значений, микросекунды
    3:archtor   Архиватор
  11) Base64Code        Тесты кодирования Mime Base64 алгоритмом.

============= Опции подсистемы "Пользовательские интерфейсы" ============
---------- Параметры секции '/sub_UI/' конфигурационного файла ----------
FontSnthHglCode <шрифт>  Шрифт использованный в подсветке синтаксиса кода, по умолчанию "monospace".

======================== Опции модуля <UI:Vision> ============================
------ Параметры модульной секции '/sub_UI/mod_Vision/' конфигурационного файла ------
StartUser  <польз>      Стартовый, беспарольный, пользователь.
UserPass   <пароль>     Пароль пользователя для нелокального запуска.
RunPrjs    <список>     Перечень запускаемых при старте проектов.
ExitLstRunPrjCls <0|1>  Выход при закрытии последнего исполняющегося проекта (по умолчанию = 1).
CachePgLife <часы>      Время жизни страниц в кеше (по умолчанию = 1).
CachePgSz  <кол.>       Максимальное количество страниц в кеше (по умолчанию 10).
CachePgLife <часы>      Время жизни страниц в кеше.
VCAstation <id>         Станция с движком СВУ ('.' - локальная).
RestoreTime <секунды>   Время восстановления подключения.

======================= Module <UI:QTStarter> options =======================
    --QtInNotMainThread Starts Qt into a different from the main thread.
    --showWin=<0,1,2>   Window display mode, initial and which is allowed to change from: 0-typical window, 1-maximized window, 2-full screen.
    --simulRightMKeyTm  Timeout, in seconds, to simulate the right mouse key and context menu at holding the left mouse key in the time - more to zero.
----------- Qt debug commandline options ----------
    --noX11             Prevent the launch of Qt, preferably for a clean console.
    --sync              Switch to Sync X11 for debugging.
    --widgetcount       Print debug messages at output, the number of widgets
                        left unselected and their maximum number.
----------- Qt commandline options ----------------
    --qws               Do this with Qt server software for embedded Linux.
    --style=<name>      Sets the GUI style to <name> (windows, platinum, plastique, ...).
    --stylesheet=<path> Set the style sheet from the file by <path>.
    --session=<name>    Restore from the previous session with the specified <name>.
    --reverse           Set the layout in Qt::RightToLeft.
    --graphicssystem=<nm> Install rendering mechanism for screen widgets and QPixmaps (raster, opengl).
    --display=<nm>      Set the X display (typically $DISPLAY).
    --geometry=<geom>   Set the client geometry of the first display window.
---- Parameters of the module section '/sub_UI/mod_QTStarter/' of the configuration file ----
StartMod   <moduls>     List of the modules that are started, separated ';'.
CloseToTray <0|1>       Closing all windows or starting without Qt modules to the system tray.
SessCntr   [0...*3]     Sessions control-restart: 0-if running, 1-anyway, 2-immediately, 3-never.
Style      <name>       The GUI style of Qt.
Font       <font>       Common Qt font.
Palette    <colors>     Twenty colors of the palette separated by symbol ',' in three lines for active, disabled and inactive groups.
StyleSheets <CSS>       Rules of the Cascade Style Sheets.

======================= Опции модуля <UI:QTCfg> =============================
------ Параметры модульной секции '/sub_UI/mod_QTCfg/' конфигурационного файла ------
StartPath  <path>       Путь первичной страницы конфигуратора.
StartUser  <user>       Стартовый пользователь, беспарольный.

======================== Опции модуля <UI:WebVision> ============================
------ Параметры модульной секции '/sub_UI/mod_WebVision/' конфигурационного файла ------
SessTimeLife <мин>      Время жизни сеансов в минутах (по умолчанию 10).
SessLimit    <кол.>     Максимальное количество сеансов (по умолчанию 5).
CachePgLife  <часы>     Время жизни страниц в кеше (по умолчанию = 1).
CachePgSz    <кол.>     Максимальное количество страниц в кеше (по умолчанию 10).
PNGCompLev   <уров.>    Уровень сжатия [-1..9] создаваемых PNG-фафлов.
ImgResize    <0|1>      Изменение размера растровых изображений на стороне сервера.

=================== Опции подсистемы "Планировщик модулей" ====================
    --ModPath=<путь>    Директории модулей, разделённые ';', и в конце могут содержать шаблон файлов.
---------- Параметры секции '/sub_ModSched/' конфигурационного файла ----------
ModPath    <путь>       Директории модулей, разделённые ';', и в конце могут содержать шаблон файлов.
                        Это синоним параметра уровня станции "ModDir".
ModAllow   <список>     Список разделяемых библиотек допустимых для автоматической загрузки, подключения и запуска (bd_DBF.so;daq_JavaLikeCalc.so).
                        Использовать значение '*' для разрешения всех модулей.
ModDeny    <список>     Список разделяемых библиотек запрещённых для автоматической загрузки, подключения и запуска (bd_DBF.so;daq_JavaLikeCalc.so).
ChkPer     <секунд>     Период поиска новых разделяемых библиотек (модулей), 0 для отключения.

5 Запуск и исполнение

OpenSCADA изначально является программой, которая может быть запущена из консоли или терминала, набрав openscada. В такой способ программа запустится с сообщениями её действий в эту консоль и блокированием консоли на ожидании действий пользователя, что является типовым режимом запуска в консоль-терминал и может использоваться для оперативной отладки и контроля результата действий и ошибок. Кроме типового режима предусмотрено также ещё три режима, которые определяются передачей параметров в команду запуска:

1. Режим получения помощи по параметрам командной строки — openscada --help.
2. Режим демона — openscada --demon, фонового или сервисного исполнения. Предусматривает отключение от консоли запуска и фоновое исполнение, т.е. визуально программа вроде сразу завершается, консоль освобождается и блокируются все модули локального графического интерфейсу вроде Qt. Используется для запуска и исполнения программы в режиме обслуживания сервисов вроде: сервера SCADA, среды исполнения ПЛК, сервера визуализации, сервера WEB-интерфейсов. Обычно эта команда помещается в файлы описания-формирования сервиса операционной системы и несколько готовых на данный момент поставляются вместе с OpenSCADA.
3. Режим отладки сервиса-демона — openscada --noX11, по сути является обычным режимом с сообщениями о действиях в консоли, но с предотвращением запуска модулей локального графического интерфейса, что невозможно в чистой консоли и недоступным X-сервером.

OpenSCADA является модульной и имеет модули локальных графических интерфейсов, а следовательно может запускаться в графическом интерфейсе, что производится одновременно при типовом запуске из консоли и при наличии доступного X-сервера. Для запуска исключительно в и с графического интерфейса команда типового запуска может и используется: в конфигурации иконок-ярлыков, запуска программ (также автоматического) из окружения графической среды — рабочего стола (DE). Сам модуль запуска локального графического окружения может предусматривать несколько режимов про что можно узнать из документации на этот модуль, которым сейчас является UI.QTStarter и который предусматривает режимы:

• основной режим исполнения проекта OpenSCADA с:
  • открытием определённых модулей Qt;
  • открытием собственного диалогового окна пускателя (Рис.5a);
  • запуском-свёртыванием в системный лоток (Рис.5b) — фактически является режимом фонового исполнения, но с доступом из графического окружения.
• режим инициирующего запуска (Рис.5c) — выбор проекта для переключения в основной режим исполнения проекта OpenSCADA.

Рис.5a. Диалоговое окно пускателя модуля QTStarter.

Рис.5b. Проект "АГЛКС", запущенный или свёрнутый в системный лоток.

Рис.5c. Диалоговое окно пускателя модуля QTStarter в режиме инициирующего запуска — выбора проекта.

Простой запуск является малополезным, неудобным и предусматривает использование и работу только с одной конфигурацией, это — конфигурационный файл {sysconfdir}/oscada.xml, как первичное хранилище конфигурации. Для предоставления возможности выбора конфигурации при запуске программы предусмотрен параметр командной строки --config и изменение рабочей папки программы перед запуском или параметром "WorkDir" этого конфигурационного файла, что может быть использовано и исключительно использовалось OpenSCADA до версии 0.9 через создание отдельного сценария командной строки (Shell) для отдельной конфигурации. В версии OpenSCADA 0.9 добавлено понятие "Проекта OpenSCADA", которое сначала реализовывалось отдельным сценарием командной строки openscada_start, а затем было интегрировано в ядро OpenSCADA и модуль запуска локального графического интерфейса.

5.1 Проекты OpenSCADA

В OpenSCADA 0.9 бала определена, внедрена и окончательно сформирована суть проекта OpenSCADA, как отдельное место (папка) с конфигурацией и всеми данными отдельного проекта-решения SCADA-системы — объект технологического процесса, ПЛК, сервер визуализации, сервер Web и другое.

Данные отдельного проекта-папки обычно предусматривают:

• сам конфигурационный файл ("oscada.xml");
• файлы БД проекта и библиотек (папка "LibsDB") в режиме полного доступа и/или ссылки на только для чтение;
• архивы сообщений и значений на файловую систему (папка "ARCHIVES");
• изображения и медиа-данные (папка "icons");
• документация (папка "docs");
• специфические файлы конфигурации, ресурсы модулей OpenSCADA и внутренних процедур проекта.

Название папки проекта равно названию проекта и размещается в рабочей папке OpenSCADA. Рабочая папка OpenSCADA делится на системную ("{datadir}/openscada", где "datadir" обычно — "/usr/share"), которая обычному-непривилегированному пользователю доступна только для чтения, и пользовательская ("{HOME}/.openscada"), которая, при необходимости, создаётся в домашней папке пользователя. В системную рабочую папку обычно помещаются предварительно-установленные проекты и библиотеки OpenSCADA, которые устанавливаются соответствующими пакетами дистрибутива Linux. Соответственно, для обеспечения полноценной работы, проекты и библиотеки из системной рабочей папки копируются в пользовательскую, что менеджер проектов осуществляет автоматически.

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

1. Определение конфигурационного файла, папки с данными и имя по указанному названию проекта, где название проекта можно указать:

• параметром командной строки "--ProjName={ИмяПроекта}";
• переменной окружения "OSCADA_ProjName={ИмяПроекта}";
• именем символьной ссылки openscada_{ИмяПроекта} на openscada_start.

2. Запуск OpenSCADA через вызов первичного бинарного файла openscada и с параметрами командной строки определённого проекта.

3. Проверку корректности завершения программы и генерацию отчёта про аварийное завершение в случае наличия файла предсмертного дампа памяти в папке проекта и отладчика "gdb".

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

5. Формирование диалогов выбора и создания нового проекта, если не указано нужного для запуска, в одной из программ диалогового типа: dialog, kdialog, zenity или Xdialog.

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

• создание папки проекта;
• копирование шаблона конфигурационного файла "oscada_start.xml" в "oscada.xml" папки проекта;
• создание ссылки на локальную копию папки библиотек (которая, при необходимости, копируется из зоны "Только для чтения");
• создание папок архивов на файловую систему "ARCHIVES/MESS" для сообщений и "ARCHIVES/VAL" для значений;
• создание на рабочем столе файла запуска проекта OpenSCADA из графического окружения (иконки-ярлыка), путём создания файла "openscada_{ИмяПроекта}.desktop" по шаблонному файлу "openscada.desktop".

С целью унификации и расширения функциональности, и по опыту эксплуатации openscada_start, сущность проекта позже была интегрирована в ядро OpenSCADA и модуль запуска локального графического интерфейса UI.QTStarter. Соответственно, ядро OpenSCADA, а именно первичный бинарный файл openscada, предусматривает определение конфигурационного файла, папки с данными и имя по указанному названию проекта и переключение на эту конфигурацию согласно пунктам 1, 2 и 4 выше-перечисленных функций менеджера проекта. Формирование элементов интерфейса для выбора и создания новых проектов, пункт 5, осуществляет модуль запуска локального графического интерфейса UI.QTStarter (Рис.5a,5c). Пункты 3 и 6 вынесены в отдельный сценарий командной строки openscada-proj из-за специфичности этих операций к программной платформе, а соответственно и необходимость в простой адаптации к этой специфики.

Соответственно, сейчас OpenSCADA можно запустить как в режиме демона-сервиса, так и графического интерфейса просто указав имя присутствующего проекта четырьмя способами:

1. параметром командной строки — openscada --projName={ИмяПроекта};
2. переменной окружения — OSCADA_ProjName={ИмяПроекта} openscada;
3. именем символьной ссылки — openscada_{ИмяПроекта} на openscada.
4. выбором присутствующего проекта из перечня локального графического интерфейса UI.QTStarter, который предоставляется по простому вызову первичного бинарного файла openscada — инициирующий режим (Рис.5c), и если не указаны графические модули Qt автоматического запуска — режим исполнения проекта OpenSCADA (Рис.5a).

Создать новый проект можно из локального графического интерфейса UI.QTStarter (Рис.5c) и через сценарий командной строки менеджера проектов openscada-proj, который собственно и вызывается из локального графического интерфейса.

Projects management script of OpenSCADA mostly designed to call from OpenSCADA but also can be used independently.
The script is mostly software platform specific and relates now for Linux.
openscada-proj list
openscada-proj proc|create|remove|update {ProjName}
 Commands:
  list   - allowed projects list;
  proc   - proceed for copy RO projects to WR, create desktop links, process core dumps;
  create - create new projects or copy RO projects to WR, create desktop links;
  remove - remove project;
  update - update from 0.8.0 LTS;
 Arguments:
  ProjName - project name;
 Environment variables:
  dPrj     - directory of projects OpenSCADA, can be RO;
  dPrjUser - directory of projects OpenSCADA of the user, WR;
  dSysCfg  - directory of system configuration;
  dData    - directory of system data;

openscada-proj backup|backupRestore {ProjName} [{BackupName}]
openscada-proj backupList {ProjName}
 Commands:
  backup - backup the selected project <ProjName> to the name <BackupName>, or to the current date at missing;
  backupRestore - restore the selected project <ProjName> from the pointed backup name <BackupName>, or from the last one at missing;
  backupList    - list the project <ProjName> backups.
 Arguments:
  ProjName   - project name;
  BackupName - the backup archive name.
 Environment variables:
  OSCD_TAR_ComprPrg - TAR compression program, by default gzip;
  OSCD_TAR_Args     - TAR extra arguments, by default \"--exclude=lock --exclude=ARCHIVES\";
  OSCD_BackLim      - Backups limit, by default 10.

В целом сценарий командной строки менеджера проектов openscada-proj предусматривает функции и команды над проектами:

• list — перечень присутствующих проектов;
• proc — обработка на предмет: копирования RO проекта в RW, создания иконки-ярлыка на рабочем столе, генерации отчёта об аварийном завершении и т.д.;
• create — создание нового проекта, дополнительно ко всем функциям proc;
• remove — удаление существующего проекта.

Дополнительно сценарий командной строки содержит команды менеджера резервного копирования проектов:

• backup — резервное копирование выбранного проекта ProjName в BackupName, или на текущую дату при отсутствии;
• backupRestore — восстановление выбранного проекта ProjName из резервной копии с указанным названием BackupName, или из последнего при отсутствии;
• backupList — перечень резервных копий проекта ProjName.

Backup is generally done in the OpenSCADA working folder along with the folders of the projects themselves, for which packed folder files are created with the name {ProjName}_{BackupName}.backup, for example — "Boiler_2020-06-24_20.09.backup". By default, project folders are compressed with "gzip", which can be changed by setting the environment variable "OSCD_TAR_ComprPrg". The backup files limit is set by default to 10 and you may change that by the environment variable "OSCD_BackLim". You also can append some specific arguments to the TAR archiver by the environment variable "OSCD_TAR_Args", which by default set to "--exclude=lock --exclude=ARCHIVES" for excluding the file "lock" and folder "ARCHIVES" from the backup. The backup can be done from the outside, for example, from the established schedule with CRON, in addition to doing it manually from the graphical interface of the project manager (Fig.5a).

5.2 Исполнение готового проекта OpenSCADA в пространстве сервиса-фоне

Организация проекта OpenSCADA в отдельном каталоге делает простым запуск готовых проектов в пространстве сервиса — исполнение в фоне, а также дальнейшее обновление и сопровождение этого проекта без прямого удаленного контроля. Фактически, вы можете разрабатывать проект локально, держа его каталог в пользовательском рабочем каталоге (типично "{HOME}/.openscada"), а для запуска в пространстве сервиса только копировать или паковать, передавать на удалённое рабочее устройство и распаковывать в системный рабочий каталог (типично "/usr/share/openscada").

Сервисное-фоновое исполнение программ в Linux обслуживается соответствующим образом сформированным сценарием-скриптом, который размещается в каталоге "/etc/ini.d" и должен быть отдельным на каждый проект OpenSCADA, который запускается в сервисном пространстве. Для упрощения и исключения необходимости заниматься созданием собственных сценариев, OpenSCADA предоставляет соответствующие для стандартных случаев-профилей и которые обычно поставляются пакетами openscada-server и openscada-plc (openscada-lts-server и openscada-lts-plc для LTS).

Соответственно, для запуска в пространстве сервиса скажем библиотечного проекта "АГЛКС" мы:

• устанавливаем пакет openscada-model-aglks (openscada-lts-model-aglks для LTS) и openscada-server (openscada-lts-server для LTS), если их ещё не установлено и это не окружение Живого Диска или Linux Автоматизации от установки этого Диска;
• запускаем проект "АГЛКС", для получения его каталога в пользовательском рабочем каталоге;
• копируем каталог проекта "АГЛКС" в системный рабочий каталог с переименованием в "server", предварительно остановив фоновое исполнение проекта "server" и удалив его каталог проекта; например следующим образом из консоли:

# Подключиться от суперпользователя
su -
# ... для живого диска и некоторых других окружений Linux
sudo bash
# Остановить исполнение предыдущей конфигурации сервера и удалить его каталог
service openscada-server stop; rm -R /usr/share/openscada/server
# ... для LTS
service openscada-lts-server stop; rm -R /usr/share/openscada/server
# Скопировать проект "АГЛКС" из домашнего каталога пользователя "{HOME}" с переименованием в "server"
cp -R {HOME}/.openscada/AGLKS /usr/share/openscada/server 
# Запустить сервер уже с проектом "АГЛКС"
service openscada-server start
# ... для LTS
service openscada-lts-server start

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

Отличие исполнения проекта в среде сервиса-фона от пользовательской среды рабочего стола собственно одно, естественно кроме отсутствия локального графического интерфейса, это — отсутствие в фоне определения локали, т.е. язык интерфейса там будет Английский. И что можно просто исправить сменой или добавлением конфигурационного параметра <prm id="Lang">ru_RU.UTF-8</prm> в секции-теге "station" файла oscada.xml фонового проекта.

6 Ссылки

• Диаграмма: Блочная схема OpenSCADA.
• Диаграмма: Иерархическая структура подсистемы "Сбор данных".
• Диаграмма: Иерархическая структура подсистемы "БД".
• Диаграмма: Иерархическая структура подсистемы "Архивы".
• Диаграмма: Иерархическая структура подсистемы "Транспорты" и "Протоколы".
• Диаграмма: Иерархическая SCADA-система.
• Диаграмма: Набор использования OpenSCADA.