4 Проектирование

4.1 Постановка задачи

4.1.1 Задачи SCADA системы

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

Применение компьютерной техники в "АСУ ТП" вообще, и на рабочих местах операторов в частности, привело к зарождению класса программного обеспечения (ПО), известного как SCADA (Supervisory Control and Data Acquisition) и HMI (Human Machine Interface).

Таким образом, важнейшей задачей ПО SCADA и HMI является предоставление интерфейса взаимодействия между оператором и системой управления ТП. Часто на SCADA и HMI возлагают такие задачи, как: формирование сигнализации про отклонение в ТП, ведения архивов параметров ТП и протоколов событий.

Поэтому программное обеспечение SCADA и HMI удобно рассматривать как совокупность подсистем: базы данных параметров ТП и связи с системами управления ТП (контроллерами), формирования сигнализации про отклонение ведения ТП, архивирования, протоколирования, визуализации оперативных и архивных данных.

В дополнении, к вышеперечисленным задачам можно отнести разделение прав доступа на чтение-изменение тех или иных параметров ТП, реализованное в подсистеме безопасности.

Таким образом современные SCADA и HMI системы представляют собой достаточно сложные программные комплексы.

Предметом данного под-проекта является разработка концепции среды визуализации и управления (СВУ) и реализаций СВУ на основные способы представления, для SCADA системы OpenSCADA.

Под визуализацией подразумевается следующий набор задач:

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

СВУ должна работать в двух режимах — редактирования (разработка) и исполнения (исполнение). На первом этапе планируется реализация режима разработки только для Qt-версии СВУ!

В процессе функционирования СВУ должна использовать данные других подсистем:

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

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

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

4.1.2 Задачи систем мониторинга

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

В системах мониторинга, как правило, отсутствует возможность управления, однако элементы интерактивного взаимодействия должны присутствовать.

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

4.2 Формализация

Концептуальную модель СВУ опишем языком UML с помощью диаграмм вариантов использования (use case diagram).

В качестве актёра, в случае разработки, выступает инженер настройки верхнего уровня "АСУ ТП", в случае исполнения — оператор.

В режиме разработки выделим такие варианты использования СВУ:

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

Диаграмма вариантов использования при функционировании СВУ в режиме разработки приведена на рис. 4.2.1.

Рис.4.2.1 Диаграмма вариантов использования СВУ в режиме разработки.

Варианты использования в режиме исполнения:

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

Диаграмма использования СВУ в режиме исполнения приведена на рис.4.2.2.

Рис.4.2.2 Диаграмма использования СВУ в режиме исполнения.

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

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

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

Описанная структура СВУ приведена на рисунке.

Данная архитектура СВУ позволяет реализовать поддержку трёх уровней сложности процесса разработки интерфейсов управления:

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

4.3 Кадры и элементы отображения(виджеты)

Кадр это окно, непосредственно предоставляющее информацию пользователю в графической и/или текстовой форме. Группа взаимосвязанных кадров формирует цельный пользовательский интерфейс ВУ.

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

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

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

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

Виджет является элементом, посредством которого обеспечивается:

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

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

4.4 Проект

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

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

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

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

Предусмотрены следующие специальные свойства страниц:

• Контейнер — страница является контейнером для вложенных страниц.
• Шаблон — страница является шаблоном для вложенных страниц.
• Пусто — пустая и неактивная страница. Это свойство используется совместно со свойством Контейнер для организации логических контейнеров страниц.

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

• Стандарт — стандартная страница (не установлено ни одно из свойств), является полноценной конечной страницей.
• Контейнер — полноценная страница со свойством контейнера (Контейнер).
• Логический контейнер — логический контейнер, фактически сам не являющийся страницей (Контейнер|Пустой), выполняет роль промежуточного и группирующего элемента в дереве страниц.
• Шаблон — страница-шаблон (Шаблон). Чистая шаблонная страница, используется для описания общих свойств и доопределения их в частном порядке во вложенных страницах.
• Контейнер и шаблон — страница шаблон и контейнер (Шаблон|Контейнер), совмещает функции шаблона и контейнера.

На стороне визуализации (RunTime), на следующих атрибутах базового элемента "Box", построена логика, регулирующая каким образом открывать страницы:

• pgOpen — признак "Страница открыта";
• pgNoOpenProc — признак "Исполнять страницу даже если она не открыта";
• pgOpenSrc — содержит адрес виджета или страницы, открывшей текущую страницу; в случае вложенного контейнерного виджета здесь содержится адрес включаемой страницы; для открытия страницы из скрипта достаточно здесь указать адрес виджета-источника открытия;
• pgGrp — группа страниц, используется для связки контейнеров страниц со страницами в соответствии с общей группой.

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

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

4.5 Сеанс исполнения проекта

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

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

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

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

• выбираются события, доступные на момент вычисления, из атрибута "event" виджета;
• события загружаются в параметр "event" объекта вычисления;
• загружаются значения по входным связям в объект вычисления;
• загружаются значения специальных переменных в объект вычисления (f_frq, f_start и f_stop);
• загружаются значения выбранных параметров виджета в объект вычисления;
• вычисление;
• выгрузка значений объекта вычисления в выбранные параметры виджета;
• выгрузка событий из параметра "event" объекта вычисления;
• обработка событий и передача необработанных на уровень выше.

Объекты сеанса проекта наследуются от абстрактного объекта "Widget" и используют соответствующие объекты проекта. Так, сеанс ("Session") использует проект ("Project") и формирует развёрнутое дерево на основе него. Страница проекта "Page" прямо используется страницей сессии "SessPage". Остальные объекты ("SessWdg") разворачиваются в соответствии с иерархией элементов страницы.

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

• "Страница верхнего уровня" -> "Страница нижнего уровня"
• "Виджет нижнего уровня" -> "Виджет верхнего уровня"

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

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

4.6 Стили

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

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

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

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

Рисунок. Вкладка "Стили" страницы конфигурации проекта.

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

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

4.7 События, их обработка и карты событий

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

Менеджер событий должен работать, используя карты событий. Карта событий — это список именованных событий с указанием его происхождения. Происхождением события может быть клавиатура, манипулятор мыши, джойстик и т.д. При возникновении события менеджер событий ищет его в активной карте и сопоставляет с именем события. Сопоставленное имя события помещается в очередь на обработку. Виджеты, в этом случае, должны обрабатывать полученную очередь событий.

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

В целом предусмотрены четыре типа событий:

• события образов-примитивов СВУ (префикс: ws_), например, событие нажатия экранной кнопки — "ws_BtPress";
• клавишные события (префикс: key_) — все события от клавиатуры и мыши в виде "key_presAlt1";
• пользовательские события (префикс: usr_) генерируются пользователем в процедурах обсчёта виджетов;
• мапированные события (префикс: map_) — события, полученные из карты событий, в планах.

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

В таблице 3.5 приведён перечень стандартных событий, поддержка которых должна быть обеспечена в визуализаторах СВУ.

Таблица 3.5. Стандартные события

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

• Первичный — сценарии управления открытием страниц.
• Вторичный — вычислительная процедура виджета.

Механизм "Сценарии управления открытием страниц" основан на базовом атрибуте виджета "evProc", в котором может описываться переключение, открытие, замещение и навигация по страницам. Сценарий этого атрибута записывается в виде списка команд с синтаксисом: "{event}:{evSrc}:{com}:{prm}". Где:

• event — ожидаемое событие;
• evSrc — путь вложенного виджета-источника события;
• com — команда сеанса;
• prm — параметр команды.

Реализованы следующие команды:

• open — открытие страницы; открываемая страница указывается в параметре prm как на прямую, так и в виде шаблона (например: /pg_so/1/*/*);
• next — открытие следующей страницы; открываемая страница указывается в параметре prm в виде шаблона (например: /pg_so/*/*/$);
• prev — открытие предыдущей страницы; открываемая страница указывается в параметре prm в виде шаблона (например: /pg_so/*/*/$).

Специальные символы шаблона расшифровываются следующим образом:

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

Для большего и правильного понимания работы механизма шаблонов выбора страницы приведём несколько реальных примеров:

• Переключение объекта сигнализации:
  Исходно: /pg_so/pg_1/pg_mn/pg_1
  Команда: open:/pg_so/2/*/*
  Результат: /pg_so/pg_2/pg_mn/pg_1
  
• Переключение вида отображения:
  Исходно: /pg_so/pg_1/pg_mn/pg_1
  Команда: open:/pg_so/*/gkadr/*
  Результат: /pg_so/pg_1/pg_gkadr/pg_1
  
• Следующая/предыдущая страница вида отображения:
  Исходно: /pg_so/pg_1/pg_mn/pg_1
  Команда: next:/pg_so/*/*/$
  Результат: /pg_so/pg_1/pg_mn/pg_2

В качестве примера приведём сценарий обеспечения работы главной страницы интерфейса пользователя:

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

Содержимым атрибута "event" является списком событий формата "{event}:{evSrc}", с событием в отдельной строке. Приведём пример процедуры обработки событий на Java-подобном языке пользовательского программирования OpenSCADA:
for(ev_rez = "", off = 0; (sval=event.parse(0,"\n",off)).length; ) { if(sval == "ws_BtPress:/cvt_light") alarmSt = 0x1000001; else if(sval == "ws_BtPress:/cvt_alarm") alarmSt = 0x1000002; else if(sval == "ws_BtPress:/cvt_sound") alarmSt = 0x1000004; else ev_rez += sval+"\n"; } event = ev_rez;

4.8 Сигнализация

Важным элементом любого интерфейса визуализации является уведомление пользователя про нарушения — сигнализация. Для упрощения восприятия, а также в виду тесной связности визуализации и уведомления (как правило уведомление дополняет визуализацию) решено интегрировать интерфейс уведомления в интерфейс визуализации. Для этого во всех виджетах предусматриваются два дополнительных атрибута (уровня сеанса): "alarm" и "alarmSt". Атрибут "alarm" используется для формирования сигнала виджетом в соответствии с его логикой, а атрибут "alarmSt" используется для контроля за фактом сигнализации ветви дерева сеанса проекта.

Атрибут "alarm" является строкой и имеет следующий формат: "{lev}|{categ}|{message}|{type}|{tp_arg}"
Где:

• lev — уровень сигнализации: число от 0 до 255;
• categ — категория сигнала: параметр подсистемы сбора, объект, путь или комбинация;
• message — сообщение сигнализации;
• type — типы уведомления, указываются в виде целого числа (0...7), содержащего флаги способов уведомлений; типовые способы уведомления:
  • 1 — визуальная;
  • 2 — гудок, часто производится через PC-speaker;
  • 4 — звуковой сигнал из файла звука или синтез речи; если в tp_arg указано имя ресурса звукового файла, то воспроизводится именно он, иначе выполняется синтез речи из текста указанного в message.
• tp_arg — аргумент типа; часто используется в случае осуществления звуковой сигнализации для прямого указания ресурса звукового сигнала (файл звукового формата).

Атрибут "alarmSt" является целым числом, которое отражает максимальный уровень сигнала и факт квитирования ветви дерева сеанса проекта. Формат числа имеет следующий вид:

• первый байт (0...255) характеризует уровень сигнала ветви;
• второй байт указывает тип уведомления (также как и в атрибуте "alarm");
• третий байт указывает тип несквитированного уведомления (также как и в атрибуте "alarm");
• четвёртый байт имеет специальное значение, определяемое отдельными битами:
  • бит 0 — указывает, установкой, на факт квитирования уведомлений в первом байте;
  • бит 1 — указывает, при установке его и бита 0, на возврат квитирования — включение уведомления.

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

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

Хотя механизм сигнализации и построен в среде визуализации, возможность формирования невизуальных элементов сигнализации остаётся, например, путём создания страницы, которая никогда не будет открываться.

Квитирование
Квитирование — процесс принятия нарушения(й) с уведомлением к сведению, отключение уведомления и принятие мер по устранению нарушения(й). В контексте экрана пользовательского интерфейса квитирование предполагает только отключение уведомления.

Квитирование производится путём указания корня ветви виджетов и типов уведомления. Это позволяет реализовать квитирование на стороне визуализатора как по группам, например, по объектам сигнализации, так и индивидуально по объектам. При этом можно независимо квитировать разные типы сигнализаций. Установка квитирования производится простой модификацией атрибута "alarmSt".

Пример скрипта для работы с сигналами приведён ниже:
//Выделение факта наличия сигнализаций разных способов-типов уведомления cvt_light_en = alarmSt&0x100; cvt_alarm_en = alarmSt&0x200; cvt_sound_en = alarmSt&0x400; //Выделение факта наличия несквитированных сигнализаций разных способов уведомления cvt_light_active = alarmSt&0x10000; cvt_alarm_active = alarmSt&0x20000; cvt_sound_active = alarmSt&0x40000; //Обработка событий кнопок квитирования и квитирование разных способов уведомлений for(ev_rez = "", off = 0; (sval=event.parse(0,"\n",off)).length; ) { if(sval == "ws_BtPress:/cvt_light") alarmSt = 0x1000001; else if(sval == "ws_BtPress:/cvt_alarm") alarmSt = 0x1000002; else if(sval == "ws_BtPress:/cvt_sound") alarmSt = 0x1000004; else ev_rez += sval + "\n"; } event = ev_rez;

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

Для осуществления такой возможности внешние способы уведомления и соответствующие им типы уведомления свободно описываются для сервера визуализации и самого визуализатора. На стороне сервера визуализации описывается формирование/получение ресурса уведомления и само уведомление. На стороне визуализатора описывается уведомление согласно ресурсам сервера визуализации.

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

• Для сервера/движка визуализации атрибутом "notify{N}" в формате:

• Для визуализатора атрибутом "notifyVis[Vision|WebVision]{N}" в формате:

Флаги:

• notify[{DL}] — включает уведомление c повтором через время DL, если указано; для DL = 0 повтор производится сразу.
• resource — запрашивать-формировать (принудительно) ресурс уведомления у сервера визуализации, может быть звуковым файлом, текстом или другими данными для формирования уведомления.
• queue — ресурсы уведомления определяются не только по глобальному признаку нарушения и квитации, а и согласно приоритетной очереди источников уведомления-ресурсов. Очередь формируется на стороне сервера визуализации, а для визуализаторов указывается необходимость работы с ней при запросе ресурсов.
• qMergeMess — объединять уведомления в очереди по равенству сообщения.
• quittanceRet — возможность визуализатора отзыва-возврата квитирования, т.е. по сути обратного включения уведомления.

Переменные обмена:

• en[0,1] — уведомление включить (1) или выключить (0);
• doNtf[0,1] — вызов сценария для уведомления;
• doRes[0,1] — вызов сценария для формирования ресурса;
• res — содержимое или имя файла с содержимым (для внешних сценариев) ресурса;
• mess — сообщение-параметры для формирования ресурса и уведомления.
• lang — язык текущего пользователя или системы.

Примеры и комментарии к работе типовых способов уведомлений:

• Бузер на стороне визуализатора или сервера визуализации:
  • alarm = "10|Prm||0x02"
  • notifyVisVision1 | notify1 =
  //flags=notify if(en) SYS.system("beep -f 1000 -l 1000000 &", true); else if((beepPID=SYS.system("pidof beep")).toInt()) SYS.system("kill "+beepPID);
  
  • notifyVisVision1 | notify1 =
  #!/bin/sh #flags=notify if test $en = 1; then beep -f 1000 -l 1000000 & else beepPID=$(pidof beep) if test "x$beepPID" != "x"; then kill $beepPID; fi fi
  
• Повторяющееся проигрывание готового звукового файла, одного общего, на стороне визуализатора или сервера визуализации:
  • alarm = "10|Prm||0x04"
  • notify2 | notifyVisVision2 =
  //flags=notify2 if(en) SYS.system("play -q alarm.ogg");
  
  • notify2 | notifyVisVision2 =
  #!/bin/sh #flags=notify2 if test $en = 1; then play -q alarm.ogg; fi
  
• Проигрывание индивидуального для источника звукового файла, на стороне визуализатора:
  • alarm = "10|Prm||0x04|res:al_prm1"
  • notify2 =
  //flags=queue
  
  • notifyVisVision2 =
  //flags=notify2|queue if(doNtf && en && res.length) { SYS.fileWrite("tmpPlay", res); SYS.system("play -q tmpPlay"); SYS.fileRemove("tmpPlay"); }
  
  • notifyVisVision2 =
  #!/bin/sh #flags=notify2|queue if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
  
• Синтез речи индивидуального сообщения для источника, на стороне визуализатора:
  • alarm = "10|Prm|Текстовое сообщение для синтеза речи|0x04"
  • notify2 =
  //flags=queue
  
  • notifyVisVision2 =
  //flags=notify2|queue if(doNtf && en && mess.length) { SYS.fileWrite("tmpForSpeech", mess); SYS.system("festival --tts tmpForSpeech"); SYS.fileRemove("tmpForSpeech"); }
  
  • notifyVisVision2 =
  #!/bin/sh #flags=notify2|queue if test $doNtf = 1 -a $en = 1 -a "x" != "x$mess"; then echo $mess > tmpForSpeech festival --tts tmpForSpeech rm tmpForSpeech fi
  
• Подготовка звукового файла, одного общего, и его проигрывание на стороне визуализатора или сервера визуализации:
  • alarm = "10|Prm||0x04"
  • notify2 =
  //flags=notify2|resource if(doRes) res = SYS.fileRead("alarm.ogg"); //Вставить сюда другой метод генерации if(doNtf && en && res.length) { SYS.fileWrite("tmpPlay", res); SYS.system("play -q tmpPlay"); SYS.fileRemove("tmpPlay"); }
  
  • notify2 =
  #!/bin/sh #flags=notify2|resource if test $doRes = 1; then cp -f alarm.ogg $res; fi #Вставить сюда другой метод генерации if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
  
  • notifyVisVision2 =
  //flags=notify2|resource if(en && res.length) { SYS.fileWrite("tmpPlay", res); SYS.system("play -q tmpPlay"); SYS.fileRemove("tmpPlay"); }
  
  • notifyVisVision2 =
  #!/bin/sh #flags=notify2|resource if test $en = 1 -a -s $res; then play -q $res; fi
  
• Подготовка индивидуального для источника уведомления звукового файла через синтез речи, на стороне визуализатора или сервера визуализации:
  • alarm = "10|Prm|Текстовое сообщение для синтеза речи|0x04"
  • notify2 =
  //flags=notify2|queue if(doRes && mess.length) { SYS.fileWrite("tmpText", mess); SYS.system("text2wave tmpText -o tmpWAV"); res = SYS.fileRead("tmpWAV"); SYS.fileRemove("tmpText"); SYS.fileRemove("tmpWAV"); } if(doNtf && en && res.length) { SYS.fileWrite("tmpPlay", res); SYS.system("play -q tmpPlay"); SYS.fileRemove("tmpPlay"); }
  
  • notify2 =
  #!/bin/sh #flags=notify2|queue if test $doRes = 1 -a "x" != "x$mess"; then echo $mess > tmpText text2wave tmpText -o $res rm tmpText fi if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
  
  • notifyVisVision2 =
  //flags=notify2|queue if(en && res.length) { SYS.fileWrite("tmpPlay", res); SYS.system("play -q tmpPlay"); SYS.fileRemove("tmpPlay"); }
  
  • notifyVisVision2 =
  #!/bin/sh #flags=notify2|queue if test $en = 1 -a -s $res; then play -q $res; fi

4.9 Управление правами

Для разделения доступа к интерфейсу ВУ и его составляющим каждый виджет содержит информацию о владельце, его группе и правах доступа. Права доступа записываются, как принято в системе OpenSCADA, в виде триады: "{пользователь}{группы}{остальные}", где каждый элемент состоит из трёх признаков доступа. Перечень групп записывается через символ ','. Для элементов СВУ принята следующая их интерпретация:

• 'r' — право на просмотр виджета;
• 'w' — право на контроль над виджетом.

В режиме разработки используется простая схема доступа "root.UI:RWRWR_", что означает — все пользователи могут открывать и просматривать библиотеки, их компоненты и проекты; а редактировать могут все пользователи группы "UI" (пользовательские интерфейсы).

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

4.10 Связывание с динамикой

Для предоставления актуальных данных в интерфейс визуализации должны использоваться данные подсистемы "Сбор данных (DAQ)". Природа этих данных следующая:

1. параметры, содержащие некоторое количество атрибутов;
2. атрибуты параметра могут предоставлять данные пяти типов: Логический, Целый, Вещественный, Строковый и Объект;
3. атрибуты параметра могут иметь историю (архив);
4. атрибуты параметра могут быть на чтение, запись и с полным доступом.

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

В соответствии с пунктом 2 связи обеспечивают прозрачное преобразование типов и не требуют специальной конфигурации.

Для удовлетворения возможности доступа к архивам, в соответствии с пунктом 3, связи выполняют проверку типа атрибута и, в случае подключения к "Адресу", в значение помещается адрес связи.

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

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

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

Если в колонке "Обработка" стоит true, то в вычислительной процедуре становится доступной переменная {идентификатор виджета}_{идентификатор строки}, например cw_value.

Колонка "Конфигурация" позволяет указать тип связи для атрибута виджета:

• Постоянная — во вкладке связей виджета появляется поле указания постоянной, например, особого цвета или заголовка для шаблонных кадров.
• Входная связь — связь с динамикой только для чтения.
• Выходная связь — связь с динамикой только для записи.
• Полная связь — полная связь с динамикой (чтение и запись).
• Из стиля — брать значение из стиля проекта.

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

• Для постоянной: прямо значение атрибута.
• Для связи: "{параметр}|{идентификатор}", где:
  • параметр — группа атрибута;
  • идентификатор — идентификатор атрибута; именно значение в этом поле сопоставляется с атрибутами параметров DAQ при автоматическом связывании после указания групповой связи;
• Для стиля: идентификатор-имя поля стиля.

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

• val: — Прямая загрузка значения через механизм связей. Например, связь: "val:100" загружает в атрибут виджета значение 100. Часто используется в случае отсутствия конечной точки связи с целью прямой установки значения.
• prm: — Связь на атрибут параметра или параметр в целом, для группы атрибутов, подсистемы "Сбор данных". Например, связь "prm:/LogicLev/experiment/Pi/var" осуществляет доступ атрибута виджета к атрибуту параметра подсистемы "Сбор данных". Знак "(+)", в конце адреса, указывает на успешную линковку и присутствие целевого объекта. Для атрибутов объектного типа допустим иерархический доступ к конкретному свойству объекта путём указания его пути через символ '#', например: "prm:/LogicLev/experiment/Pi/var#pr1/pr2".
• wdg: — Связь на атрибут другого виджета или виджет в целом для группы атрибутов. Например, связь "wdg:/ses_AGLKS/pg_so/pg_1/pg_ggraph/pg_1/a_bordColor" осуществляет доступ атрибута одного виджета к атрибуту другого. Поддерживаются как абсолютные, так и относительные пути связей. Точкой отсчёта адреса абсолютной связи выступает объект корня модуля "VCAEngine", а значит первым элементом абсолютного адреса является идентификатор сеанса или проекта. На стороне сеанса первый элемент опускается, поэтому связи установленные в проекте там работают. Относительные связи берут отсчёт от виджета где связь указана. Специальным элементом относительной связи является элемент вышестоящего узла "..".
• arh: — Особый тип связи доступный только для отдельного атрибута типа "Адрес", который позволяет подключиться прямо к архиву значения ("arh:CPU_load"). Может быть полезен для указания архива в качестве источника данных для примитива "Диаграмма".

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

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

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

Рисунок. Вкладка "Связи" страницы конфигурации виджета c групповым назначением атрибутов путём указания только параметра.

Рисунок. Вкладка "Связи" страницы конфигурации виджета c индивидуальным назначением атрибутов.

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

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

Из вышесказанного видно, что связи устанавливаются пользователем в процессе конфигурации интерфейса. Однако, для предоставления возможности создания кадров общего назначения с функцией предоставления детализированных данных разных источников одного типа необходим механизм динамической установки связей. Такой механизм предусматривается посредством зарезервированного ключевого идентификатора "<page>" группы атрибутов связей у кадров общего назначения и динамическое назначение связей с идентификатором "<page>" в процессе открытия кадра общего назначения сигналом от другого виджета.

Рассмотрим пример, когда имеется кадр общего назначения "Панель контроля графиком" и множество "Графиков" на разных кадрах. "Панель контроля графиком" имеет связи с шаблонами:

• tSek -> "<page>|tSek"
• tSize -> "<page>|tSize"
• trcPer -> "<page>|trcPer"
• valArch -> "<page>|valArch"

При этом каждый виджет "График" имеет атрибуты tSek, tSize, trcPer и valArch. В случае вызова сигнала открытия "Панели контроля графиком" из любого виджета "График" происходит связывания атрибутов "Панели контроля графиком" в соответствии атрибуту, указанному в шаблоне, с атрибутом виджета "График". Как результат, все изменения на "Панели контроля графиком" будут отражаться на графике посредством связи.

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

Для наглядного изображения этого механизма приведена таблица.

Таблица. Механизм динамической линковки.

4.11 Архитектура

Исходя из вышеизложенных, архитектурных, соображений сформируем статическую диаграмму классов СВУ, учитывая разделение на концептуальную часть (движок) и часть индивидуальной реализации СВУ (рис. 4.11.1). В таблице 4.11 представлено описание классов диаграммы классов.

Рис.4.11.1 Статическая диаграмма классов.

Таблица 4.11. Классы СВУ

Статическая диаграмма классов не раскрывает всей иерархии взаимодействия объектов, основанных на абстрактном объекте VCA::Widget. Это связано с неявным наследованием данных свойств виджетов через все слои движка, а также тонкостями наследования, выстроенного путём использования данных одних виджетов в других. Для разъяснения этих особенностей изображена исчерпывающая карта "использующего" наследования в разделе 4.5.

4.12 Примитивы виджетов

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

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

Таблица. Библиотека примитивов виджетов (базовых элементов отображения)

Таблица. Общий набор свойств/атрибутов в виджете

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

Элементарные графические фигуры (ElFigure)

Примитив является основой для отрисовки элементарных графических фигур со всевозможной комбинацией их в одном объекте. Учитывая широкий спектр всевозможных фигур, которые должен поддерживать примитив, и в тоже время являться достаточно простым в использовании и, по возможности, в реализации, решено было ограничить перечень базовых фигур, используемых для построения результирующих графических объектов до таких фигур: линия, дуга, кривая Безье и заливка замкнутых контуров. Основываясь уже на этих базовых фигурах, можно строить производные фигуры, комбинируя базовые. В рамках примитива существует возможность задания прозрачности цвета в диапазоне [0...255], где '0' — полная прозрачность.

Таблица. Набор дополнительных свойств/атрибутов в примитиве "ElFigure"

Элементы формы (FormEl)

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

Таблица. Набор дополнительных свойств/атрибутов в примитиве "FormEl"

Элемент текста (Text)

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

Таблица. Набор дополнительных свойств/атрибутов в примитиве "Text"

Элемент отображения медиа-материалов (Media)

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

Таблица. Набор дополнительных свойств/атрибутов в примитиве "Media"

Элемент построения диаграмм/трендов (Diagram)

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

• "График" — строит график значений параметра от времени.
• "Спектр" — строит частотный спектр из значений параметров. Окно данных частотного спектра формируется исходя из размера виджета по горизонтали, в пикселах, и доступных данных параметров, наложенных на сетку горизонтального размера. В связи с этим минимальная частота определяется значением атрибута "tSize" — "1/tSize", а максимальная выделяемая частота определяется половинной шириной графика в пикселах умноженной на минимальную частоту "width/(2*tSize)".
• "XY" — строит двумерный график значений параметров, парами на график, где чётные по оси Y (0,2,4...) и нечётные по оси X (1,3,5...). Указанный временной диапазон данных используется в получении значений параметров оси X и Y, с последующей сортировкой по оси X и изображения.

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

• параметра подсистемы "Сбор Данных";
• архива значений;
• прямого блока данных пользователя.

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

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

Таблица. Набор дополнительных свойств/атрибутов в примитиве "Diagram"

Элемент построения протоколов, на основе архивов сообщений (Protocol)

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

Таблица. Набор дополнительных свойств/атрибутов в примитиве "Protocol"

Элемент формирования отчётной документации (Document)

Примитив предназначен для формирования отчётной, оперативной и иной документации на основе шаблонов документов.

Таблица. Набор дополнительных свойств/атрибутов в примитиве "Document"

Возможности примитива "Документ":

• Гибкое формирования структуры документа на основе языка гипертекстовой разметки.
• Формирования документов по команде или по плану в архив с последующим просмотром архива.
• Формирование документа в режиме реального времени полностью динамически и на основе архивов реальных данных за указанное время.
• Использование атрибутов виджета для передачи значений и адресов на архивы реальных данных в документ. Позволяет использовать виджет документа как шаблон для формирования отчётов с другими входными данными.

В основе любого документа лежит XHTML-шаблон. XHTML-шаблон это тег "body" WEB-страницы, содержащий статику документа в стандарте XHTML 1.0 и элементы исполняемых инструкций на одном из языков пользовательского программирования OpenSCADA в виде <?dp {procedure} ?>. Результирующий документ формируется путём исполнения процедур и вставки их результата в документ.

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

На рис. 3.8.7.a изображена структурная схема виджета примитива "Документ". Согласно этой структуре "Документ" содержит: XHTML-шаблон, результирующие документы и скрипт обработки данных. Источником данных для скрипта и результирующих документов являются атрибуты виджета.

Рис.3.8.7.a Структурная схема примитива "Документ".

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

Генерация документа всегда производится в момент установки атрибута времени time относительно установленного начального времени документа в атрибуте bTime. При выключенном архиве результирующий документ помещается непосредственно в атрибут doc. При включенном архиве результирующий документ помещается в ячейку под курсором, атрибут aCur, а так-же в doc если значение курсора архива aCur и курсора визуализируемого документа vCur совпадают. Атрибуты архивных курсоров предусматривают несколько командных значений:

• "aCur < 0" — Перемещает курсор архиватора на следующую позицию, тем самым оставляя предыдущий документ в архиве и очищая документ под курсором (если кольцевой архив замкнулся).
• "vCur == -1" — Выбор следующего документа для отображения, выбранный документ копируется в атрибут doc.
• "vCur == -2" — Выбор предыдущего документа для отображений, выбранный документ копируется в атрибут doc.

Как было указано выше динамика шаблона документа определяется вставками исполняемых инструкций вида "<?dp {procedure} ?>". В процедурах могут использоваться одноимённые атрибуты виджета и функции пользовательского интерфейса программирования OpenSCADA. Кроме атрибутов виджета зарезервированы специальные атрибуты (табл. 3.8.7.a).

Таблица 3.8.7.a. Специальные и зарезервированные элементы шаблона.

Контейнер (Box)

Примитив контейнера используется для формирования составных виджетов и/или страниц пользовательского интерфейса.

Таблица. Набор дополнительных свойств/атрибутов в примитиве Box

4.13 Использование БД для хранения библиотек виджетов и проектов

Хранение данных виджетов, библиотек виджетов и проектов реализовано в БД, доступных системе OpenSCADA. БД организована по принадлежности данных к библиотеке-проекту. Т.е. отдельная библиотека-проект хранится в отдельной группе таблиц одной или разных БД. Перечень библиотек виджетов хранится в индексной таблице библиотек с именем "VCALibs", со структурой "Libs", а перечень проектов в индексной таблице "VCAPrjs", со структурой "Projs". Экземпляр этих таблиц создаётся в каждой БД, где хранятся данные этого модуля с перечнем библиотек, содержащихся в конкретно взятой БД. В состав таблиц, принадлежащих библиотеке виджетов и проектов, входят следующие:

• "{DB_TBL}" — таблица с виджетами, принадлежащими библиотеке (структура "LibWigets"), или страниц принадлежащих проекту (структура "ProjPages");
• "{DB_TBL}_io" — таблица с рабочими свойствами виджетов этой библиотеки и вложенными виджетами контейнерных виджетов (структура "LibWidgetIO"), или свойствами страниц (структура "ProjPageIO");
• "{DB_TBL}_uio" — таблица с пользовательскими свойствами виджетов этой библиотеки и вложенными виджетами контейнерных виджетов (структура "LibWidgetUserIO"), или с пользовательскими свойствами страниц (структура "ProjPageUserIO");
• "{DB_TBL}_incl" — таблица с перечнем вложенных виджетов в виджеты-контейнеры данной библиотеки (структура "LibWidgetIncl") или проекта (структура "ProjPageWIncl");
• "{DB_TBL}_mime" — таблица с ресурсами библиотеки и её виджетов (структура "LibWidgetMime"), или проекта и его страниц (структура "ProjMime");
• "{DB_TBL}_stl" — таблица для хранения значений стилевых параметров проекта (структура "PrjStlIO");
• "{DB_TBL}_ses" — таблица для хранения данных режима исполнения проектов, т.е. сеансов (структура "PrjSesIO").

Проекции (структуры) основных таблиц таковы:

• Libs(ID, NAME, DSCR, DB_TBL, ICO) — Библиотеки виджетов ID.
  ID — идентификатор;
  NAME — имя;
  DSCR — описание;
  DB_TBL — корень таблиц БД с виджетами;
  ICO — закодированное (Base64) изображение иконки библиотеки.
  
• LibWigets(__ID__, ICO, PARENT, PROC, PROC_PER, ATTRS, TIMESTAMP) — Виджеты ID библиотеки.
  ID — идентификатор;
  ICO — закодированное (Base64) изображение иконки виджета;
  PARENT — адрес виджета основы в виде /wlb_originals/wdg_Box;
  PROC — внутренний сценарий и язык сценария виджета;
  PROC_PER — периодичность вычисления сценария виджета;
  ATTRS — перечень атрибутов виджета, модифицированных пользователем;
  TIMESTAMP — метка времени последней модификации.
  
• LibWidgetIO(__IDW__, ID, IDC, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — Рабочие атрибуты ID виджета IDW.
  IDW — идентификатор виджета;
  ID — идентификатор IO;
  IDC — идентификатор дочернего виджета;
  IO_VAL — значение атрибута;
  SELF_FLG — внутренние флаги IO;
  CFG_TMPL — шаблон элемента конфигурации, основанного на данном атрибуте;
  CFG_VAL — значение элемента конфигурации (ссылка, константа ...).
  
• LibWidgetUserIO(__IDW__, ID, IDC, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — Пользовательские атрибуты ID виджета IDW.
  IDW — идентификатор виджета;
  ID — идентификатор IO;
  IDC — идентификатор дочернего виджета;
  NAME — имя IO;
  IO_TP — тип и главные флаги IO;
  IO_VAL — значение IO;
  SELF_FLG — внутренние флаги IO;
  CFG_TMPL — шаблон элемента конфигурации, основанного на данном атрибуте;
  CFG_VAL — значение элемента конфигурации (ссылка, константа ...).
  
• LibWidgetIncl(__IDW__, ID, PARENT, ATTRS) — Включенные в контейнер IDW виджеты ID.
  IDW — идентификатор виджета;
  ID — идентификатор экземпляра вложенного виджета;
  PARENT — адрес виджета основы в виде /wlb_originals/wdg_Box;
  ATTRS — перечень атрибутов виджета, модифицированных пользователем.
  
• LibWidgetMime(__ID__, MIME, DATA) — Audio, video, media и другие ресурсы виджетов библиотеки.
  ID — Идентификатор ресурса.
  MIME — Mime тип данных ресурса (в формате — "{mimeType};{Size}").
  DATA — Данные ресурса кодированные Base64.
  
• Projs(ID, NAME, DSCR, DB_TBL, ICO, USER, GRP, PERMIT, PER, FLGS, STYLE) — Проекты ID интерфейса визуализации.
  ID — идентификатор проекта;
  NAME — имя проекта;
  DSCR — описание проекта;
  DB_TBL — корень таблиц БД со страницами;
  ICO — закодированное (Base64) изображение иконки проекта;
  USER — имя владельца проекта;
  GRP — имя группы пользователей проекта;
  PERMIT — права доступа к проекту;
  PER — период вычисления проекта, в миллисекундах;
  FLGS — флаги проекта;
  STYLE — типовой стиль проекта.
  
• ProjPages(__OWNER__, ID, ICO, PARENT, PROC, PROC_PER, FLGS, ATTRS, TIMESTAMP) — Страницы ID содержащиеся в проекте/странице OWNER.
  OWNER — проект/страница — владелец данной страницы (в виде — "/AGLKS/so/1/gcadr");
  ID — идентификатор страницы;
  ICO — закодированное (Base64) изображение иконки страницы;
  PARENT — адрес виджета основы в виде /wlb_originals/wdg_Box;
  PROC — внутренний сценарий и язык сценария страницы;
  PROC_PER — периодичность вычисления сценария страницы;
  FLGS — флаги типов страницы;
  ATTRS — перечень атрибутов страницы, модифицированных пользователем;
  TIMESTAMP — метка времени последней модификации.
  
• ProjPageIO(__IDW__, ID, IDC, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — Рабочие атрибуты страниц. Структура фактически совпадает с таблицей "LibWidgetIO".
• ProjPageUserIO(__IDW__, ID, IDC, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — Пользовательские атрибуты страниц. Структура фактически совпадает с таблицей "LibWidgetUserIO".
• ProjPageWIncl(__IDW__, ID, PARENT, ATTRS) — Включенные на страницы виджеты. Структура фактически совпадает с таблицей "LibWidgetIncl".
• ProjMime(__ID__, MIME, DATA) — Audio, video, media и другие ресурсы страниц проектов. Структура фактически совпадает с таблицей "LibWidgetMime".
• PrjStl(__ID__, V_0, V_1, V_2, V_3, V_4, V_5, V_6, V_7, V_8, V_9) — Значения поля стиля ID проекта.
  ID — идентификатор поля стиля;
  V_{N} — значение поля стиля для стиля N.
  
• ProjSess(__IDW__, ID, IO_VAL) — Таблица проекта IDW для хранения данных сеансов, исполняющих проект.
  IDW — полный путь элемента проекта;
  ID — атрибут элемента;
  IO_VAL — значение атрибута.

4.14 API пользовательского программирования и сервисные интерфейсы OpenSCADA

API пользовательского программирования

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

Объект "Сеанс" ( this.ownerSess() )

• string user( ) — текущий пользователь сеанса.
• int alrmQuittance( int quit_tmpl, string wpath = "", bool ret = false ) — квитирование нарушений wpath с шаблоном quit_tmpl. Если wpath пустая строка то производится глобальное квитирование. В строке wpath, через символ ';', могут быть перечислены адреса нескольких виджетов. При установке ret осуществляется возврат квитирования.
• int reqTm( ) — время последнего запроса.
• string reqUser( ) — пользователь последнего запроса.
• string reqLang( ) — язык последнего запроса.
• int userActTm( ) — время последнего действия пользователя.

Объект "Виджет" (this)

• TCntrNodeObj ownerSess( ) — получить объект сеанса данного виджета.
• TCntrNodeObj ownerPage( ) — получить объект родительской страницы данного виджета.
• TCntrNodeObj ownerWdg( bool base = false ) — получить родительский виджет данного виджета. При указании base будет возвращены и объекты страниц.
• TCntrNodeObj wdgAdd( string wid, string wname, string parent ) — добавление виджета wid с именем wname на основе библиотечного виджета parent.

• bool wdgDel( string wid ) — удаление виджета wid.
• TCntrNodeObj wdgAt( string wid, bool byPath = false ) — подключение к дочернему или глобальному, посредством пути byPath, виджету. В случае глобального подключения можно использовать абсолютный или относительный путь к виджету. Точкой отсчёта абсолютного адреса выступает объект корня модуля "VCAEngine", а значит первым элементом абсолютного адреса является идентификатор сеанса, который опускается. Относительный адрес берёт отсчёт от текущего виджета. Специальным элементом относительного адреса является элемент вышестоящего узла "..".
• bool attrPresent( string attr ) — проверка атрибута виджета attr на факт присутствия.
• ElTp attr( string attr, bool fromSess = false ) — получение значения атрибута виджета attr или из сеанса fromSess. Для отсутствующих атрибутов возвращается пустая строка.
• TCntrNodeObj attrSet( string attr, ElTp vl, bool toSess = false ) — установка атрибута виджета attr в значение vl, или в сеанс toSess. Возвращается текущий объект для конкатенации функций установки.
• string link( string attr, bool prm = false ) — получение ссылки для атрибута виджета attr. При установке prm запрашивается ссылка для группы атрибутов (параметр), представленных указанным атрибутом.
• string linkSet( string attr, string vl, bool prm = false ) — установка ссылки для атрибута виджета attr. При установке prm осуществляется установка ссылка для группы атрибутов (параметр), представленных указанным атрибутом.

• string mime( string addr, string type = "" ) — получение "mime" объекта по адресу addr (прямая ссылка на ресурс или атрибут виджета с этой ссылкой) с типом в type, из таблицы сеанса или источника. Предназначено для редактирования "mime" объекта и подстановки его в контексте сеанса, например, изображений SVG.
• int mimeSet( string addr, string data, string type = "" ) — установка "mime" объекта data с типом type по адресу addr.
• int messDebug( string mess ); int messInfo( string mess ); int messNote( string mess ); int messWarning( string mess ); int messErr( string mess ); int messCrit( string mess ); int messAlert( string mess ); int messEmerg( string mess ); — формирование системного сообщения mess с категорией как путь к данному виджету.

Объект "Виджет", примитива "Документ" (this)

• string getArhDoc( int nDoc) — получить текст документа архива на глубине nDoc (0-{aSize-1}).

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

Список виджетов (WdgList)
Описание: Возвращает список виджетов в контейнере виджетов или список дочерних виджетов. Если установлено pg, то возвращается список страниц для проектов и сеансов.
Параметры:

Присутствие узла (NodePresent)
Описание: Проверка на присутствие узла, включая виджеты, атрибуты и другие.
Параметры:

Список атрибутов (AttrList)
Описание: Возвращает список атрибутов виджета. Если установлен noUser тогда возвращаются только не пользовательские атрибуты.
Параметры:

Запрос атрибута (AttrGet)
Описание: Запрос значения атрибута виджета. Запрос может осуществляться как указанием полного адреса атрибута в addr, так и отдельно адреса виджета в addr, а идентификатора атрибута в attr.
Параметры:

Установка атрибута (AttrSet)
Описание: Установка значения атрибута виджета. Установка может осуществляться как указанием полного адреса атрибута в addr, так и отдельно адреса виджета в addr, а идентификатора атрибута в attr.
Параметры:

Пользователь сеанса (SesUser)
Описание: Возвращает пользователя сеанса по пути к виджету сеанса.
Параметры:

Сервисные интерфейсы OpenSCADA

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

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

С целью предоставления унифицированного, группового и сравнительно быстрого доступа к значениям атрибутов визуальных элементов предусмотрена сервисная функция визуального элемента "/serv/attr" и команды получения/установки значений атрибутов: <get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> и <set path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/>.

Таблица. Атрибуты команд получения/установки атрибутов визуальных элементов

Групповой доступ к значениям атрибутов элементов визуализации (виджетам)

С целью оптимизации трафика сетевого взаимодействия путём исключения мелких запросов, а использования одного, но большого запроса предусмотрен групповой запрос значений атрибутов визуальных элементов. Группировка данного запроса подразумевает запрос атрибутов всей ветви виджета, включая и вложенные элементы. Для данного запроса предусмотрена сервисная команда "/serv/attrBr". Запрос данной сервисной команды эквивалентен сервисной команде "/serv/attr" и выглядит следующим образом:
<get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattrBr"/>

Результат:

Доступ к страницам сеанса

С целью унификации и оптимизации доступа к страницам предусмотрена сервисная функция сеанса "/serv/pg" и команды запроса перечня открытых страниц <openlist path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>; открытия страницы <open path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>; и закрытия страницы <close path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>.

Результатом запроса перечня открытых страниц являются дочерние элементы <el>{OpPage}</el>, содержащие полный путь открытой страницы. Кроме перечня открытых страниц запрос возвращает значение текущего счётчика вычисления сеанса в атрибуте tm. Если данный атрибут устанавливается при запросе, то для каждой открытой страницы возвращается список изменённых с момента указанного значения счётчика виджетов открытой страницы.

Управление сигнализацией

Для предоставления механизма глобального контроля за сигнализацией сеанса предусмотрена сервисная функция сеанса "/serv/alarm" и команды запроса статуса сигналов <get path="/UI/VCAEngine/ses_{Session}/%2fserv%2falarm"/>; и квитирование сигналов <quittance path="/UI/VCAEngine/ses_{Session}/%2fserv%2falarm"/>.

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

Запрос на квитирование выполняет квитирование указанного виджета, атрибут wdg, в соответствии с шаблоном, атрибут tmpl.

Манипуляция сеансами проектов

Для предоставления унифицированного механизма манипуляции сеансами визуализаторам СВУ в модуле движка СВУ (VCAEngine) предусмотрена сервисная функция "/serv/sess" и команды запроса перечня открытых сеансов, подключения/создания нового сеанса и отключения/удаления сеанса: <list path="/UI/VCAEngine/%2fserv%2fsess"/>, <connect path="/UI/VCAEngine/%2fserv%2fsess"/> и <disconnect path="/UI/VCAEngine/%2fserv%2fsess"/> соответственно.

Таблица. Атрибуты команд механизма манипуляции сеансами

Групповой запрос дерева библиотек виджетов

С целью оптимизации производительности локального и особенно сетевого взаимодействия предусмотрена сервисная функция "/serv/wlbBr" и команда запроса дерева библиотек виджетов: <get path="/UI/VCAEngine/%2fserv%2fwlbBr"/>. Результатом запроса является дерево с элементами библиотек виджетов, теги wlb. Внутри тегов библиотек виджетов содержаться тег иконки ico и теги виджетов библиотеки w. Теги виджетов, в свою очередь, содержат тег иконки и теги дочерних виджетов cw.

4.15 Копирование элементов

Для ускорения процесса разработки пользовательских интерфейсов визуализации и управления нужно предусмотреть функцию копирования элементов. Что-бы заложить поддержку различных вариантов копирования запишим их по пунктам:

• "Библиотека виджетов (wlb_SrcLib)" -> "Библиотека виджетов (wlb_NewLib)" -- Копируются параметры самой библиотеки, а также все виджеты/кадры в ней содержащиеся.
• "Проект (prj_SrcPrj)" -> "Проект (prj_NewPrj)" -- Копируются параметры проекта, все страницы по иерархии, а также виджеты/кадры, содержащихся в активных страницах.
• "Страница проекта (prj_WPrj.pg_SrcPg)" -> Страница проекта (prj_WPrj.pg_WPg.pg_NewPg)" -- Копирование параметров страницы, вложенных страниц и вложенных виджетов
• "Кадр библиотеки виджетов (wlb_Lib.wdg_SrcWdg)" -> "Кадр библиотеки виджетов(wlb_LibN.wdg_NewWdg)" -- Копирование параметров виджета и вложенных виджетов.
• "Элемент кадра/страницы (prj_WPrj.pg_WPage.wdg_SrcWdg" -> "Кадр библиотеки виджетов(wlb_Lib.wdg_NewWdg)" -- Копирование параметров виджета и вложенных виджетов.
• "Элемент кадра/страницы (prj_WPrj.pg_WPage.wdg_SrcWdg" -> "Элемент кадра/страницы (wlb_Lib.wdg_WWdg.wdg_NewWdg)" -- Копирование параметров виджета.

4.16 Заложенные функциональные возможности

Перечислим возможности, которые сможет обеспечить СВУ, построенная на основе данного проекта:

• три уровня сложности в формировании интерфейса визуализации, позволяющие органично осваивать и применять инструментарий по методике от простого к сложному:
  1. формирование из шаблонных кадров путём назначения динамики (без графической конфигурации);
  2. графическое формирование новых кадров путём использования готовых элементов визуализации из библиотеки (мнемосхемы);
  3. формирование новых кадров, шаблонных кадров и элементов отображение в библиотеки.
• построение интерфейсов визуализации практически любой сложности, начиная от простых плоских интерфейсов мониторинга, и заканчивая полноценными иерархическими интерфейсами, используемыми в SCADA системах;
• предоставление различных способов формирования и конфигурации пользовательского интерфейса, основанных на различных интерфейсах графического представления (QT, Web, Java ...), или же посредством стандартного интерфейса управления системой OpenSCADA;
• смену динамики в процессе исполнения;
• построение новых шаблонных кадров на уровне пользователя и формирование специализированных, под область применения, библиотек кадров (например, включение кадров параметров, графиков и других элементов с увязкой их друг с другом) в соответствии с теорией вторичного использования и накопления;
• построение новых пользовательских элементов визуализации и формирование специализированных под область применения библиотек кадров в соответствии с теорией вторичного использования и накопления;
• описание логики новых шаблонных кадров и пользовательских элементов визуализации как простыми связями, так и лаконичным, полноценным языком пользовательского программирования;
• возможность включение в пользовательские элементы визуализации функций (или кадров вычисления функций) объектной модели OpenSCADA, практически связывая представление с алгоритмом вычисления (например, визуализируя библиотеку моделей аппаратов ТП для последующего визуального построения моделей ТП);
• разделение данных пользовательских интерфейсов и интерфейсов представления этих данных, позволяющее строить интерфейс пользователя в одной среде, а исполнять во многих других (QT, Web, Java ...);
• возможность подключения к исполняющемуся интерфейсу для наблюдения и коррекции действий (например, при обучении операторов и контроля в реальном времени за его действиями);
• визуальное построение различных схем с наложением логических связей и последующим централизованным исполнением в фоне (визуальное построение и исполнение математических моделей, логических схем, релейных схем и иных процедур);
• предоставление функций объектного API в систему OpenSCADA, может использоваться для управления свойствами интерфейса визуализации из пользовательских процедур;
• построение серверов кадров, элементов визуализации и проектов интерфейсов визуализации с возможностью обслуживания множественных клиентских соединений;
• простая организация клиентских станций на различной основе (QT, Web, Java ...) с подключением к центральному серверу;
• полноценный механизм разделения полномочий между пользователями, позволяющий создавать и исполнять проекты с различными правами доступа к его компонентам;
• гибкое формирование правил сигнализаций и уведомления с учётом и поддержкой различных способов уведомления;
• поддержка пользовательского формирования палитры и шрифтовых предпочтений для интерфейса визуализации;
• поддержка пользовательского формирования карт событий под различное оборудование управления и пользовательские предпочтения;
• поддержка профилей пользователей, позволяющая определять различные свойства интерфейса визуализации (цветовая гамма, шрифтовые особенности, предпочтительные карты событий);
• гибкое хранение и распространение библиотек виджетов, кадров и проектов интерфейсов визуализации в БД, поддерживаемых системой OpenSCADA; практически пользователю нужно только зарегистрировать полученную БД с данными.