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

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

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

Применение компьютерной техники в АСУ-ТП вообще, и на рабочих местах операторов в частности, привело к зарождению класса программного обеспечения (ПО), известного как SCADA (Supervisory control and data acquisition).

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

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

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

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

Предметом данного подпроекта является разработка концепции среды визуализации и управления (СВУ) и реализаций СВУ на основные способы представления, для 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 Диаграмма использования СВУ в режиме исполнения.

Исходя из требований и общих соображений можно следующим образом изобразить структуру СВУ рис.4.2.3.

Рис.4.2.3 Обобщённая структура СВУ.

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

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

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

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

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

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

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

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

Рис.4.3 Пример структуры производного виджета.

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

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

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

4.4 Проект

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

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

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

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

Рис.4.4 Иерархическое представления компонентов проекта классического интерфейса ВУ технологического процесса.

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

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

4.5 Стили

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Механизм «Сценарии управления открытием страниц» основан на базовом атрибуте виджета “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 — имя новой страницы, в общем пути без префикса. Игнорируется при обнаружении предыдущей открытой страницы;
• * — страница берётся из имени предыдущей открытой страницы или подставляется первая доступная страница, в случае если предыдущая открытая страница отсутствует;
• $ — указывает на место открытой страницы, относительно которой необходимо искать следующую или предыдущую.

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

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

Содержимое атрибута “event” является списком событий формата <event>:<evSrc>, с событием в отдельной строке. Приведём пример процедуры обработки событий на Java-подобном языке пользовательского программирования OpenSCADA:

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

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

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

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

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

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

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

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

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

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

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

Пример скрипта для работы с сигналами приведён ниже:

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

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

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

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

В режиме исполнения работают права описанные в компонентах интерфейса.

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

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

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

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

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

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

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

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

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

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

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

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

• <Параметр> - группа атрибута;
• <Идентификатор> - идентификатор атрибута, именно это значение сопоставляется с атрибутами параметров DAQ при автоматическом связывании, после указания групповой связи.

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

• val: - Прямая загрузка значения через механизм связей. Например, связь: "val:100" загружает в атрибут виджета значение 100. Часто используется в случае отсутствия конечной точки связи с целью прямой установки значения.
• prm: - Связь на атрибут параметра или параметр в целом, для группы атрибутов, подсистемы "Сбор данных". Например, связь "wdg:/ses_AGLKS/pg_so/pg_1/pg_ggraph/pg_1/a_bordColor ==ЇЇ" осуществляет доступ атрибута одного виджета к атрибуту другого. На данный момент этот тип связи не предназначен для установки пользователем вручную, а устанавливается автоматически в режиме динамического связывания!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.4.10.2 Карта «использующего» наследования компонентов концепции/движка

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

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

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

В таблице 4.11.a приведён перечень примитивов виджетов(базовых элементов отображения).

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

Каждый примитив, и виджет вообще, содержит общий набор свойств/атрибутов в составе приведенном в таблице 4.11.b:

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

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

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

Перечень дополнительных свойств/атрибутов данного примитива приведён в таблице 4.11.1.

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

Id	Имя	Номер	Значение
lineWdth	Line:width	20	Ширина линии.
lineClr	Line:color	21	Цвет линии.
lineStyle	Line:style	22	Стиль линии (сплошная, пунктир, точечная).
bordWdth	Border:width	23	Ширина бордюра линии. Нулевая ширина указывает на отсутствие бордюра.
bordClr	Border:color	24	Цвет бордюра.
fillColor	Fill:color	25	Цвет заливки.
fillImg	Fill:image	26	Изображение заливки.
orient	Orientation angle	28	Угол поворота содержимого виджета.
elLst	Element's list	27	Список графических примитивов в формате: Линия. Форма записи в списке: <line:p1 | (x | y):p2 | (x | y):[width | w{n}]:[color | c{n}]:[border_width | w{n}]:[border_color | c{n}]:[line_style | s{n}]> Дуга. Форма записи в списке: <arc:p1 | (x | y):p2 | (x | y):p3 | (x | y):p4 | (x | y):p5 | (x | y):[width | w{n}]:[color | c{n}]:[border_width | w{n}]:[border_color | c{n}]:[line_style | s{n}]> Кривая Безье. Форма записи в списке: <bezier:p1 | (x | y):p2 | (x | y):p3 | (x | y):p4 | (x | y):[width | w{n}]:[color | c{n}]:[border_width | w{n}]:[border_color | c{n}]:[line_style | s{n}]> Заливка. Форма записи в списке: <fill:p1 | (x | y),p2 | (x | y),...,pn | (x | y):[fillClr | c{n}]:[fillImg | i{n}]>
Атрибуты для каждой точки из списка графических фигур elLst
p{n}x	Point {n}:x	30+n*6	Координата "x" точки {n}.
p{n}y	Point {n}:y	30+n*6+1	Координата "y" точки {n}.
w{n}	Width {n}	30+n*6+2	Ширина {n}.
с{n}	Color {n}	30+n*6+3	Цвет {n}.
i{n}	Image {n}	30+n*6+4	Изображение {n}.
s{n}	Style {n}	30+n*6+5	Стиль {n}.

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

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

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

Id	Имя	Номер	Значение
elType	Element type	20	Тип элемента (Строка редактирования; Редактор текста; Флажок; Кнопка; Выбор из списка; Список; Слайдер; Полоса прокрутки). От его значения зависит перечень дополнительных атрибутов.
Строка редактирования:
value	Value	21	Содержимое строки.
view	View	22	Вид строки редактирования (Текст; Комбобокс; Целое; Вещественное; Время; Дата; Дата и время).
cfg	Config	23	Конфигурация строки. Формат значения данного поля для различных видов строки: Текст -- указывается шаблон ввода в формате библиотеки QT. Комбобокс -- содержит список значений редактируемого комбобокса. Целое -- содержит конфигурацию поля ввода целочисленного представления в формате: <Минимум>:<Максимум>:<Шаг изменения>:<Префикс>:<Суффикс>. Вещественное -- содержит конфигурацию поля ввода вещественного представления в формате: <Минимум>:<Максимум>:<Шаг изменения>:<Префикс>:<Суффикс>:<Число знаков после запятой>. Время, Дата, Дата и время -- формировать дату по шаблону с параметрами: d -- номер дня (1-31); dd -- номер дня (01-31); ddd -- сокращённое наименование дня ('Mon' ... 'Sun'); dddd -- полное наименование дня ('Monday' ... 'Sunday'); M -- номер месяца (1-12); MM -- номер месяца (01-12); MMM -- сокращённое имя месяца ('Jan' ... 'Dec'); MMMM -- полное имя месяца ('January' ... 'December'); yy -- последние две цифры года; yyyy -- год полностью; h -- час (0-23); hh -- час (00-23); m -- минуты (0-59); mm -- минуты (00-59); s -- секунды (0-59); ss -- секунды (00-59); AP,ap -- отображать AM/PM или am/pm.
font	Font	25	Шрифт текста в полной записи {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Редактор текста:
value	Value	21	Содержимое редактора.
wordWrap	Word wrap	22	Автоматический перенос текста по словам.
font	Font	25	Шрифт текста в полной записи {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Флажок:
name	Name	26	Имя/метка флажка.
value	Value	21	Значение флажка.
font	Font	25	Шрифт текста в полной записи {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Кнопка:
name	Name	26	Имя, надпись на кнопке.
value	Value	21	Значение для фиксированной кнопки.
img	Image	22	Изображение на кнопке.
color	Color	23	Цвет кнопки.
colorText	Color:text	27	Цвет текста.
checkable	Checkable	24	Признак функционирования как фиксированная кнопка.
font	Font	25	Шрифт текста в полной записи {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Выбор из списка:
value	Value	21	Текущее значение списка.
items	Items	22	Перечень элементов списка.
font	Font	25	Шрифт текста в полной записи {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Список:
value	Value	21	Выбранное значение списка.
items	Items	22	Перечень элементов списка.
font	Font	25	Шрифт текста в полной записи {<Family> <Size> <Bold> <Italic> <Underline> <Strikeout>}.
Слайдер и полоса прокрутки:
value	Value	21	Положение слайдера.
cfg	Config	22	Конфигурация слайдера в формате: <VertOrient>:<Min>:<Max>:<SinglStep>:<PageStep>. Где: VertOrient -- признак вертикальной ориентации, по умолчанию ориентация горизонтальная; Min -- минимальное значение; Max -- максимальное значение; SinglStep -- размер одиночного шага; PageStep -- размер страничного шага.

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

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

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

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

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

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

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

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

• "График" -- позволяет строить одномерные графики из значений параметров подсистемы "Сбор данных" по времени, а также прямое использование архивных данных для построения графиков. Поддерживается режим отслеживания как текущих значений, так и значений по архиву. Поддерживается, также, возможность построения графиков параметров не имеющих архива значений.
• "Спектр" -- строит частотный спектр из значений параметров подсистемы "Сбор данных". Окно данных частотного спектра формируется исходя из размера виджета по горизонтали, в пикселах, и доступных данных параметров, наложенных на сетку горизонтального размера. В связи с этим минимальная частота определяется значением атрибута tSize (1/tSize), а максимальная частота выделяемых частот определяется половинной шириной графика в пикселах умноженной на минимальную частоту ( width/(2*tSize) ). Поддерживается возможность формирования спектра в режиме слежения.

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

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

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

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

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

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

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

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

/Doc / Концепция Среды Визуализации / part 4 / part 11 / doc  :: (edit)

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

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

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

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

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

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

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

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

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

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

Кроме специальных атрибутов в XHTML шаблоне зарезервированы теги и атрибуты тегов специального назначения (табл. 4.11.7.1).

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

Имя	Назначение
Атрибуты
rez	Атрибут результата исполнения процедуры содержимое которого помещается дерево документа.
lTime	Время последнего формирования. Если документ формируется впервые то <lTime> равен <bTime>.
rTime	Содержит время для перебираемых значений в секундах. Определяется внутри тегов с атрибутом 'docRept'.
rTimeU	Содержит время для перебираемых значений в микросекундах. Определяется внутри тегов с атрибутом 'docRept'.
rPer	Содержит периодичность перебора значений (атрибут 'docRept').
mTime, mLev, mCat, mVal	Определяются внутри тегов с атрибутом 'docAMess' при разборе сообщений архива сообщений: mTime - время сообщения; mLev - уровень сообщения; mCat - категория сообщения; mVal - значение сообщения.
Специальные теги
<docRes attr="ResAttr"/>	Вставка ресурса (изображение, звук ...) из контейнера данного виджета с именем 'ResAttr'
<docDiagram h="400" v="200" tm="time" sz="size" vl1="atr1" vl2="atr2" vl3="atr3"/>	Вставка диаграммы (тренда) размером 400x200 на время 'time' и глубиной 'size' для атрибутов параметров: atr1, atr2 и atr3.
<docKeyword pos="up"> ... </docKeyword>	Колонтитул документа. Описывает общую часть документа размещаемую сверху и снизу каждой печатной страницы. Содержит атрибут 'pos' принимающий значения 'up' или 'down'.
<docPage/>	Вставляет номер текущей страницы при формировании печатного документа.
<docPages/>	Вставляет количество страниц при формировании печатного документа.
<docEnter tp="str" attr="attr1"/>	Поле ввода значения атрибута <attr1> виджета с типом <str>. Предусматриваются типы: str(Строка), dec(Десятичное), hex(Шестьнадцатеричное), oct(Восьмеричное), bool(Логичный)
Специальные атрибуты стандартных тегов
body.docProcLang	Язык исполняемых процедур документа. По умолчанию это JavaLikeCalc.JavaScript.
*.docRept="1s"	Тег с указанным атрибутом при формировании размножается путём смещения времени в атрибуте 'rTime' на значение указанное в данном атрибуте.
*.docAMess="1:PLC*"	Указывает на необходимость размножения тега с атрибутом сообщениями из архива сообщений за указанный интервал времени и в соответствии с уровнем (1) и шаблоном запроса (PLC*). Для данного тега, в процессе размножения, определяются атрибуты: mTime, mLev, mCat и mVal
*.docRevers="1"	Указывает на инвертирование порядок размножения, последний сверху.
*.docAppend="1"	Признак необходимости добавления результата выполнения процедуры в тег процедуры. Иначе результат исполенеия заменяет содержимое тега.
body.docTime	Время формирования документа. Используется для установки атрибута <lTime> при следующем формировании документа. Не устанавливается пользователем!

/Doc / Концепция Среды Визуализации / part 4 / part 11 / doc  :: (edit)

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

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

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

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

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

• Libs( ID, NAME, DSCR, DB_TBL, ICO ) — Библиотеки виджетов <ID>.
  ID — идентификатор;
  NAME — имя;
  DSCR — описание;
  DB_TBL — БД с виджетами;
  ICO — закодированное (Base64) изображение иконки библиотеки.
  
• LibWigets( ID, ICO, PARENT, PROC, PROC_PER, USER, GRP, PERMIT, ATTRS) — Виджеты <ID> библиотеки.
  ID — идентификатор;
  ICO — закодированное (Base64) изображение иконки виджета;
  PARENT — адрес виджета основы в виде /wlb_originals/wdg_Box ;
  PROC — внутренний сценарий и язык сценария виджета;
  PROC_PER — периодичность вычисления сценария виджета;
  USER — владелец виджета;
  GRP — группа пользователей виджета;
  PERMIT — права доступа к виджету;
  ATTRS — перечень атрибутов виджета, модифицированных пользователем.
  
• LibWidgetIO( IDW, ID, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) — Рабочие атрибуты <ID> виджета <IDW>.
  IDW — идентификатор виджета;
  ID — идентификатор IO;
  IO_VAL — значение атрибута;
  SELF_FLG — внутренние флаги IO;
  CFG_TMPL — шаблон элемента конфигурации, основанного на данном атрибуте;
  CFG_VAL — значение элемента конфигурации (ссылка, константа ...).
  
• LibWidgetUserIO( IDW, ID, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) — Пользовательские атрибуты <ID> виджета <IDW>.
  IDW — идентификатор виджета;
  ID — идентификатор IO;
  NAME — имя IO;
  IO_TP — тип и главные флаги IO;
  IO_VAL — значение IO;
  SELF_FLG — внутренние флаги IO;
  CFG_TMPL — шаблон элемента конфигурации, основанного на данном атрибуте;
  CFG_VAL — значение элемента конфигурации (ссылка, константа ...).
  
• LibWidgetIncl( IDW, ID, PARENT, ATTRS, USER, GRP, PERMIT ) — Включенные в контейнер <IDW> виджеты <ID>.
  IDW — идентификатор виджета;
  ID — идентификатор экземпляра вложенного виджета;
  PARENT — адрес виджета основы в виде /wlb_originals/wdg_Box ;
  ATTRS — перечень атрибутов виджета, модифицированных пользователем;
  USER — владелец виджета;
  GRP — группа пользователей виджета;
  PERMIT — права доступа к виджету.
  
• LibWidgetMime( ID, MIME, DATA ) — Audio, video, media и другие ресурсы виджетов библотеки.
  ID — Идентификатор ресурса.
  MIME — Mime тип данных ресурса (в формате – <mimeType;Size>).
  DATA — Данные ресурса кодированные Base64.
  
• Project( ID, NAME, DSCR, DB_TBL, ICO, USER, GRP, PERMIT, PER, FLGS ) — Проекты интерфейсов визуализации <ID>.
  ID — идентификатор проекта;
  NAME — имя проекта;
  DSCR — описание проекта;
  DB_TBL — БД со страницами проекта.
  ICO — закодированное (Base64) изображение иконки проекта;
  USER — владелец проекта;
  GRP — группа пользователей проекта;
  PERMIT — права доступа к проекту;
  PER — периодичность вычисления проекта;
  FLGS — флаги проекта.
  
• ProjPage( OWNER, ID, ICO, PARENT, PROC, PROC_PER, USER, GRP, PERMIT, FLGS, ATTRS ) — Страницы <ID> содержащиеся в проекте/странице <OWNER>.
  OWNER — проект/страница – владелец данной страницы (в виде – «/AGLKS/so/1/gcadr»)
  ID — идентификатор страницы;
  ICO — закодированное (Base64) изображение иконки страницы;
  PARENT — адрес виджета основы страницы в виде /wlb_originals/wdg_Box ;
  PROC — внутренний сценарий и язык сценария страницы;
  PROC_PER — периодичность вычисления сценария виджета;
  USER — владелец страницы;
  GRP — группа пользователей страницы;
  PERMIT — права доступа к странице;
  FLGS — флаги страницы;
  ATTRS — перечень атрибутов виджета, модифицированных пользователем.
  
• ProjSess( IDW, ID, IO_VAL ) — Таблица проекта <IDW> для хранения данных сеансов, исполняющих проект.
  IDW — полный путь элемента проекта;
  ID — атрибут элемента;
  IO_VAL — значение атрибута.
  
• ProjPageIO( IDW, ID, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) — Рабочие атрибуты страниц. Структура фактически совпадает с таблицей LibWidgetIO.
• ProjPageUserIO( IDW, ID, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL ) — Пользовательские атрибуты страниц. Структура фактически совпадает с таблицей LibWidgetUserIO.
• ProjPageWIncl( IDW, ID, PARENT, ATTRS, USER, GRP, PERMIT ) — Включенные на страницы виджеты. Структура фактически совпадает с таблицей LibWidgetIncl.

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

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

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

Список виджетов (WdgList)

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

Присутствие узла (NodePresent)

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

Список атрибутов (AttrList)

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

Запрос атрибута (AttrGet)

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

Установка атрибута (AttrSet)

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

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

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

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

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

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

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

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

Результат:
<el id="{attr}" p="{a_id}">{val}</el> -- Элементы с результатами атрибутов. В элементе указываются: строковых идентификатор {attr} атрибута, индекс {a_id} атрибута и его значение {val}.
<w id="{wid}" lnkPath="{lnk_path}">{childs+attrs}</w> -- Элементы с дочерними виджетами и их атрибутами. В элементе указываются идентификатор дочернего виджета {wid} и путь виджета на который ссылается данный виджет если он является ссылкой {lnk_path}.

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

С целью унификации и оптимизации доступа к страницам предусмотрена сервисная функция сеанса "/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"/>).

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

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

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

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

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

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

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

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

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

• «Библиотека виджетов (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.15 Заложенные функциональные возможности

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

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

6.1 Виджеты и их библиотеки -- Выполнено

Целями данного этапа является:

• Реализация основы архитектуры "Модель данных" - "Представление" в лице модулей системы OpenSCADA: "UI.VCAEngine" - "UI.Vision".
• Реализация базовых функций модели данных СВУ в модуле UI.VCAEngine:
  • Организация хранилища данных модели, модуля UI.VCAEngine, в БД, доступных OpenSCADA.
  • Написание сценариев управления моделью данных, модуля UI.VCAEngine, посредством интерфейса управления OpenSCADA.
  • Создание абстрактного класса виджета (VCA::Widget).
  • Создание класса библиотеки виджетов (VCA::WdgLib).
  • Создание представительских классов библиотечного (VCA::LWidget) и контейнерного (VCA::CWidget) виджета.
  • Создание представительского класса терминального виджета (VCA::PrWidget - конечного элемента визуализации).
  • Создание первичной версии библиотеки терминальных виджетов, модели данных примитивов визуализации.
• Реализация базовых функций среды разработки пользовательского интерфейса в модуле представления UI.Vision:
  • Построение основы пользовательского интерфейса разработки на библиотеке QT.
  • Формирование навигатора по библиотекам виджетов и механизмы управления ими.
  • Формирование инспектора атрибутов виджета.
  • Формирование диалога редактирования свойств библиотеки.
  • Формирование диалога редактирования свойств виджета.
  • Формирование графического редактора кадров и основы графического редактирования елементов конечной визуализации (примитивов).

В результате проделанной работы созданы модули модели данных (UI.VCAEngine) и представления (UI.Vision). На данном этапе модулями реализуются механизмы формирования элементов пользовательского интерфейса. На следующий этапе данные элементы будут использованы для формирования цельных интерфейсов визуализации и управления.

Рассмотрим по пунктам результаты реализации данного этапа:

Реализация основы архитектуры "Модель данных"-"Представление"

В соответствии со статической диаграммой классов (рис.4.10.1) и общими требованиями были реализованы модули "UI.VCAEngine" и "UI.Vision" для системы OpenSCADA. Модуль "UI.VCAEngine" реализует модель данных СВУ и является источником для последующего представления этих данных различными механизмами визуализации. Модуль "UI.Vision" реализует способ представления данных, основанный на библиотеке QT версии 4 фирмы Trolltech.

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

Реализация базовых функций модели данных СВУ, в модуле UI.VCAEngine

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

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

• {DB_TBL} -- Таблица с виджетами, принадлежащими библиотеке (структура "LibWigets", раздела БД ).
• {DB_TBL}_io -- Таблица с рабочими свойствами виджетов этой библиотеки и вложенных виджетов контейнерных виджетов (структура "LibWidgetIO", раздела БД ).
• {DB_TBL}_uio -- Таблица с пользовательскими свойствами виджетов этой библиотеки и вложенных виджетов контейнерных виджетов (структура "LibWidgetUserIO", раздела БД ).
• {DB_TBL}_incl -- Таблица с перечнем вложенных виджетов в виджеты-контейнеры данной библиотеки (структура "LibWidgetIncl", раздела БД ).
• {DB_TBL}_mime -- Таблица с ресурсами библиотеки и её виджетов (структура "LibWidgetMime", раздела БД ).

Для управления библиотеками виджетов и отдельными виджетами были написаны сценарии конфигурации на языке интерфейса управления ~OpenSCADA. На данный момент эти сценарии призваны выполнять только функции централизованной конфигурации элементов движка СВУ, однако, в последствии их планируется расширить и наделить функциями обработки запросов к модели данных от модулей представления с целью организации "слабых связей" между "Моделью данных" и "Представлением".

Основой практически всех элементов движка стал объект абстрактного элемента визуализации (VCA::Widget). На своём, абстрактном, уровне объект наделён следующими свойствами:

• "Использующего" наследования - механизма наследования отдельных свойств другого экземпляра объекта. Используется для организации механизма вторичного использования, переопределения и доопределения элементов визуализации.
• Хранение свойств(атрибутов) виджетов с механизмами "использующего" наследования значений. Механизм "использующего" наследования выполняет наследования значений свойств с самого корневого элемента и до верхнего, с возможностью переопределения значений на каждом из уровней. При этом, в БД хранятся только значения изменённых свойств.
• Поддержка режима контейнера. В этом режиме виджет может включать другие(дочерние) виджеты, как библиотека виджетов содержит виджеты. Используется в библиотечных виджетах, которые наследуют свойства примитива-контейнера, например примитив кадра "Box". Также, это свойство планируется использовать в сеансе проекта, для построения иерархического дерева виджетов (примитивов) при формирование конечного образа визуализации кадров.
• Поддержка режима простой связи. Данный режим используется для вложенных виджетов библиотеки. Особенностью этого режима является то, что он не наследует свойства контейнера, а значит не может прямо содержать вложенные виджеты (рис. 4.10.2).
• Содержит процедуру внутренней логики виджета на одном из языков системы OpenSCADA. Логика этой процедуры может использоваться для организации взаимодействия вложенных виджетов и контейнера друг с другом, формируя требуемое поведение.
• Предоставление доступа к ресурсам, mime-данным, с учётом иерархии "использующего" наследования.

Для представления библиотеки виджетов реализован класс (VCA::WdgLib). Основными его функциями является содержание библиотечных виджетов, хранение и загрузка их с БД, предоставление доступа к ресурсам (Mime-данные), а также разделение доступа.

Специально для включения в библиотеку виджетов был создан класс библиотечного виджета (VCA::LWidget), который основан на классе абстрактного виджета (VCA::Widget) и предоставляет дополнительные функции: хранения данных виджета в таблицах библиотеки, переопределения доступа к ресурсам на таблицу с mime-данными библиотеки и хранение вложенного контейнерного виджета (VCA::CWidget).

В свою очередь класс контейнерного виджета (VCA::CWidget) предоставляет функции: хранения данных контейнерного виджета в таблицах библиотеки, переопределения доступа к ресурсам на таблицу с mime-данными библиотеки, а также принудительный режим простой ссылки для всех контейнерных виджетов.

На основе класса библиотечного виджета (VCA::LWidget) был сформирован абстрактный класс терминального виджета (VCA::PrWidget). А уже на его основе сформированы реализации примитивов базовых виджетов, которые и сформировали библиотеку базовых виджетов, создаваемую модулем при инициализации. Значения свойств базовых виджетов также могут сохраняться в БД (таблицы библиотеки виджетов), формируя нужные шаблоны. Кроме того, базовая библиотека примитивов может доопределяться расширенными примитивами из модулей интерфейсов представления, которым базовых недостаточно. Но в этом случае нужно учитывать, что подобные действие - путь к несовместимости между модулями интерфейсов представления!

Реализация базовых функций среды разработки пользовательского интерфейса в модуле представления UI.Vision

Интерфейс разработки пользовательских интерфейсов модуля основан на MDI(Multi Document Interface) интерфейсе. Данный подход позволяет одновременно редактировать несколько кадров различных размеров. Использованы следующие механизмы управления разработкой: панели инструментов, пункты меню и контекстное меню. Большинство действий дублируются в разных механизмах, что позволяет быстро найти инструмент предпочитаемым способом. Навигационные интерфейсы реализованы присоединяемыми окнами. Конфигурация панелей инструментов и присоединяемых окон сохраняется при выходе и восстанавливается при старте, что позволяет настраивать интерфейс под себя.

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

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

Для визуального редактирования кадров реализована первичная поддержка редактирования виджетов и кадров. Уже сейчас редактор позволяет редактировать кадры, основанные на примитиве "Box" и полноценно отображать примитив текстового поля "Text". В редакторе кадров реализованы функции:

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

Вид окна разработки приведён на рис. 6.1.1. На рисунке можно видеть: панели инструментов, навигатор виджетов, инспектор атрибутов, окно редактирования кадра и строка статуса.

Рис.6.1.1 Окно разработки модуля UI.Vision

Для настройки объектов виджетов и их библиотек разработаны два диалога, диалог настройки виджета (рис.6.1.2) и диалог настройки библиотеки виджетов (рис.6.1.3). Диалог настройки библиотеки позволяет установить основные свойства и поместить mime-данные в БД, для последующего использования в виджетах библиотеки. Диалог настройки виджета позволяет установить: основные свойства виджета, индивидуально установить значения атрибутов и сконфигурировать внутреннюю процедуру вычислений виджета с дополнительными (пользовательскими) свойствами.

Рис.6.1.2 Диалог настройки библиотеки виджетов.

Рис.6.1.3 Диалог настройки виджета.

6.2 Проекты интерфейсов визуализации -- Выполнено

Целями данного этапа является:

• Реализация проектов интерфейсов визуализации на уровне модели данных СВУ в модуле UI.VCAEngine:
  • Разработка ссылочных механизмов кадра в составе: внутри-кадровых локальных ссылок, внешних ссылок на параметры подсистемы сбора данных OpenSCADA и действия интерфейса по событиям.
  • Разработка дерева страниц проекта и их взаимосвязей.
• Реализация проектов интерфейсов визуализации в модуле представления UI.Vision(QT):
  • Формирование навигатора по проектам.
  • Формирование диалога настройки страницы проекта;
  • Реализация поддержки возможности непосредственного графического формирования страницы на уровне проекта с возможностью визуального наложения ссылок (включая логических).

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

На данном этапе реализовано:

• Ссылочный механизм. Только на параметры источников данных! Внутренние связи будут реализованы на последующих этапах.
• Инспектор связей модуля Vision, используя сценарии интерфейса управления OpenSCADA.
• Механизм формирования дерева страниц, основанный на терминах: страница-шаблон и страница-контейнер. Данный механизм позволяет достаточно просто описать зависимости между страницами большинства известных типов пользовательского интерфейса с эффективной адресацией и ссылками на страницы как по отдельности, так и по шаблону.
• Навигатор по дереву проекта, как на языке сценариев интерфейса управления, так и в модуле Vision, используя тот же сценарий интерфейса управления.
• Диалог конфигурации проекта и страниц проекта. Фактически диалоги конфигурации элементов проекта и библиотеки совмещены, а также выполнен переход на слабые связи интерфейса управления OpenSCADA.
• Благодаря унификации интерфейса доступа к элементам библиотеки и проекта, реализована и возможность прямого формирования страниц на уровне проекта.

6.3 Сессии исполнения проектов -- Выполнено

Целями данного этапа является:

• Реализация сеансов исполнения проектов на уровне модели данных СВУ в модуле UI.VCAEngine:
  • Формирование иерархического дерева виджетов конечной визуализации на основе проекта, для которого открывается сеанс.
  • Формирование кадров значений для процедур обсчёта виджетов конечной визуализации.
  • Обработка ссылок на параметры источников данных OpenSCADA.
  • Реализация иерархического обсчёта процедур и обновления ссылок виджетов.
  • Формирование механизма прохождения и обработки событий по иерархическому дереву.
• Реализация визуализации сеансов проектов в модуле представления UI.Vision(QT) как полноценного пользовательского интерфейса с элементами визуализации динамики, истории и управления:
  • Формирование окна исполнения проекта (RunTime).
  • Визуализация кадров проекта в режиме "RunTime" с периодическим обновлением содержимого.
  • Реализация передачи и обработки событий.
  • Реализация механизма переключения/открытия/замещения/навигации по страницам проекта с учётом сценариев обработки.

На данном этапе был добавлен механизм исполнения проекта в сеансах модели данных модуля VCAEngine, а также визуализация сеанса проекта, режим "RunTime" в модуле визуализации на библиотеке QT Vision с элементами обновления данных и интерактивного взаимодействия с пользователем.

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

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

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

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

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

В сессии реализована поддержка специальных свойств страниц:

На основе этих свойств реализованы следующие типы страниц:

Формирование кадров значений для процедур обсчёта виджетов конечной визуализации.

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

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

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

Обработка ссылок на параметры источников данных OpenSCADA.

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

Заложена поддержка следующих типов ссылок:

• Значение константы ("V"). Переменная для определения в момент конфигурации страницы в проекте.
• Атрибут параметра подсистемы "Сбор данных" ("P"). Механизм доступа к значениям параметра подсистемы "Сбор данных" системы OpenSCADA.
• Атрибут вложенного виджета ("W"). Внутренняя прямая связь между вложенными виджетами.

На данный момент реализованы первые два типа ссылок. Последняя будет реализована вместе с реализацией базового виджета "Link".

Формирование окна исполнения проекта (RunTime).

На стороне визуализации (модуль Vision) для визуализации процесса исполнения проекта реализован объект VisRun. При запуске он шлёт запрос на создание и инициализацию сессии. Далее выполняется запрос на перечень открытых страниц. Исходя из информации об открытых страницах VisRun и их связности, формируется результирующий интерфейс. На рис. 6.3 приведён пример классического SCADA интерфейса с объектами сигнализации, где главное окно содержит страницу внутри, которая замещается по нажатию на кнопки объектов сигнализации и листания.

Рис.6.3 Окно визуализации исполнения проекта. Режим "RunTime".

Визуализация кадров проекта в режиме "RunTime" с периодическим обновлением содержимого.

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

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

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

Реализация передачи и обработки событий.

Визуализатор сессии ("RunTime"), в виду своего непосредственного контакта с пользователем, собирает различные события. Часть событий обрабатывается образами базовых виджетов (Text, Box, Document и т.д.), в результате чего могут формироваться другие события. Другая часть прямо передаётся в модель данных, где они и обрабатываются.

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

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

Переключение, открытие, замещение и навигация по страницам реализовано на основе обработки событий по сценарию, в атрибуте активного виджета "evProc". Сценирий этого атрибута записывается в виде списка команд с синтаксисом: <event>:<srcWdg>:<com>:<prm>
где:

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

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

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

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

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

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

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

6.4 Проектирование и реализация примитивов отображения — Реализация

На данном этапе планируется реализация моделей данных и образов визуализатора Vision для всех базовых элементов: “ElFigure", «FormEl", “Text”, “Media”, “Diagram”, “Protocol”, “Document”, “Function”, “Box”, “Link”.

6.4.1 Примитив элементарная фигура (ElFigure)

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

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

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

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

Добавить фигуру можно с помощью мыши:

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

Удалить фигуру можно нажатием DEL, имея выделенную(ые) фигуру(ы).

Передвинуть/изменить габариты фигуры можно с помощью мыши или клавиатуры:

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

Существует возможность копировать выделенную(ые) фигуру(ы).

Можно выделить все фигуры, нажав CTRL+A. С выделенными таким образом фигурами доступны все вышеперечисленные действия.

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

1. Убедиться, что кнопка “Holds” нажата или нажать её.
2. Выделить одну из фигур и, удерживая нажатой левую кнотпку мыши, переместить её, её начальную или конечную точку к желаемой начальной или конечной точке другой фигуры так, чтобы она попадала в появившуюся окружность и отпустить левую кнопку мыши. Связанные фигуры перемещаются также, как и отдельные; общая точка перемещается для всех фигур, к котрым она относится(приоритет отдается дуге). Дуги нельзя связывать непосредственно друг с другом.

Залить замкнутый контур из фигур можно следующим образом:

1. Активировать привязки(нажатием кнопки Holds).
2. Создать замкнутый контур.
3. Два раза клацнуть мышкой внутри его.

Удалить заливку замкнутого контура можно, разорвав контур либо клацнув два раза левой кнопкой мыши по залитому контуру.

Поворот фигуры осуществляется вокруг центра виджета.

На рис. 6.4.1 представлена часть экрана с кадром, содержащим вышеперечисленные элементарные фигуры.

Рис.6.4.1 Реализация элементарных фигур в Vision.

6.4.2 Примитив элементов формы (FormEl)

Реализована поддержка элементов формы на кадрах СВУ. Реализованы заложенные свойства, включая следующие элементы формы:

Были реализованы режимы: «Включен» и «Активен», а также передача изменений и событий в модель данных СВУ (движок).

На рис. 6.4.2 представлена часть экрана с кадром, содержащим вышеперечисленные элементы формы.

Рис.6.4.2 Реализация элементов формы в Vision.

6.4.3 Примитив текста (Text)

Реализована поддержка элемента текста со свойствами:

• Шрифт со свойствами: типа/класса шрифта, размера, усиления, наклонности, подчёркивания и перечёркивания.
• Цвет текста.
• Ориентация текста.
• Автоматический перенос по словам.
• Выравнивание текста по горизонтали и вертикали со всеми вариантами.
• Отображение фона в виде цвета и/или изображения.
• Отображение бордюра вокруг текста, с указанным цветом, шириной и стилем.
• Формирование текста из атрибутов различного типа и свойств.

На рис.6.4.3 представлена часть экрана с кадром, содержащим примеры текста с использованием различных параметров.

Рис.6.4.3 Реализация базового элемента текста в Vision.

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

Реализована поддержка элемента отображения медиа-материалов со свойствами:

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

На рис.6.4.4 представлена часть экрана с кадром, содержащим примеры просмотра/проигрывания медиа-данных.

Рис.6.4.4 Реализация базового элемента отображения медиа-материалов в Vision.

6.4.5 Примитив построения диаграм/графиков (Diagram)

Реализована поддержка элемента построения диаграм/трендов со свойствами:

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

На рис.6.4.5 представлена часть экрана с кадром, содержащим примеры диаграммы-тренда.

Рис.6.4.5 Реализация базового элемента отображения диаграммы-тренда в Vision.

6.4.6 Примитив формирования протокола (Protocol)

Реализована поддержка элемента формирования протокола со свойствами:

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

На рис.6.4.6 представлена часть экрана с кадром, содержащим примеры протоколов со слежением и фиксированным указанием времени.

Рис.6.4.6 Реализация базового элемента отображения протоколов в Vision.

6.4.7 Примитив контейнера (Box)

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

6.7 Реализация слабых связей между моделью данных и представлением — Выполнено

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

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