Статус: Реализовано: UI.VCAEngine, UI.Vision, UI.WebVision
Автор: Роман Савоченко
Примечание: Проект, на начальном этапе, формировался на основе дипломного проекта Зайчука Евгения и в последствии был полностью переписан с переходом на Qt4, формализацией и с созданием данной концепции.
Среда визуализации и управления (СВУ) является неотъемлемой составляющей SCADA системы. Она применяется на клиентских станциях с целью доступного предоставления информации об объекте управления и выдачи управляющих воздействий на объект. В различных практических ситуациях и условиях могут применяться СВУ, построенные на различных принципах визуализации. Например, это могут быть библиотеки виджетов Qt, GTK+, wxWidgets или гипертекстовые механизмы на основе технологий HTML, XHTML, XML, CSS и JavaScript или сторонние приложения визуализации, реализованные на различных языках программирования Java, Python и т.д. Любой из этих принципов имеет свои преимущества и недостатки, комбинация которых может стать непреодолимым препятствием в возможности использования СВУ в том или ином практическом случае. Например, технологии вроде библиотеки Qt позволяют создавать высокореактивные СВУ, что несомненно важно для станций оператора управления технологическим процессом (ТП). Однако, необходимость инсталляции данного клиентского ПО может сделать использование его невозможным в отдельных ситуациях. С другой стороны, Web-технологии не требуют инсталляции на клиентские системы и являются предельно многоплатформенными (достаточно указать ссылку на Web-сервер в любом Web-браузере), что наиболее важно для различных инженерных и административных станций. С другой стороны, реактивность и надёжность таких интерфейсов ниже, что практически исключает их использование на станциях оператора ТП.
Система OpenSCADA имеет предельно гибкую архитектуру, которая позволяет создавать внешние интерфейсы, в том числе и пользовательские, на любой основе и на любой вкус. Например, среда конфигурации системы OpenSCADA доступна как на Qt-библиотеке, так и на Web-основе.
В тоже время независимое создание реализаций СВУ на различной основе может повлечь за собой невозможность использования данных конфигурации одной СВУ в другой. Что неудобно и ограничено с пользовательской стороны, а также накладно в плане реализации и последующей поддержки. С целью избежания этих проблем, а также создания в кратчайшие сроки полного спектра различных типов СВУ и основан данный проект.
Непосредственной областью применения СВУ, как составной части SCADA-системы OpenSCADA, является мониторинг и управление распределёнными системами с локальных и удалённых рабочих мест.
Функционально разработка предназначена для создания общей концепции СВУ и использования её в разработке конкретных модулей реализации СВУ для системы OpenSCADA. Планируется разработка модулей реализации СВУ основанных на Qt-библиотеке и WEB-технологиях.
Разрабатываемые модули СВУ, в целом, предназначены для:
Эксплуатационным назначением разработки является:
Разрабатываемая концепция и модули СВУ должны быть реализованы в соответствии с требованиями к модулям системы OpenSCADA. Разработанный концептуальный механизм должен содержать все алгоритмы и данные, являющиеся общими для СВУ построенных на различных принципах, а также содержать механизм сессий исполнения проектов интерфейсов визуализации. Фактически в реализациях СВУ должны формироваться индивидуальные механизмы визуализации (отрисовки) и взаимодействия с пользователем на основе данных концепции, т.е. формировать индивидуальный интерфейс представления данных концепции СВУ в соответствии с идеологией "Модель/данные — Интерфейс".
Визуализация должна включать функции:
Управление технологическим оборудованием и параметрами ведения ТП должно обеспечить функции:
Команды оператора по управлению ТП и навигации внутри подсистемы должны производиться с помощью клавиатуры и мыши, или иного устройства ввода.
В качестве входных, реализации СВУ должны использовать данные следующих подсистем OpenSCADA:
В качестве выходной информации реализации СВУ выступают:
Конфигурация СВУ должна храниться в доступных системе OpenSCADA базах данных, позволяя, тем самым, выбирать ту или иную БД под конкретную практическую ситуацию. Изображения и другие ресурсы должны кодироваться алгоритмом Mime Base64 и храниться в БД или браться прямо с ФС.
Цикл обновления оперативной информации на экране зависит от конкретной реализации СВУ. Для быстрых интерфейсов визуализации цикл не должен превышать 1 секунды.
Обеспечение надежного функционирования и защиты от несанкционированного доступа СВУ должно быть реализовано на нескольких уровнях:
Реализации СВУ, в связке с концепцией, должны удовлетворять следующим требованиям к надежности:
В настоящее время, при построении систем автоматизированного управления технологическими процессами (АСУ ТП), интерфейс пользователя с системой управления реализуется с помощью вычислительных систем. Такой подход обусловлен несколькими причинами: компактностью (в физическом и энергетическом смысле) современной вычислительной техники, развитостью способов отображения информации, большой функциональности и изменчивости систем управления.
Применение компьютерной техники в "АСУ ТП" вообще, и на рабочих местах операторов в частности, привело к зарождению класса программного обеспечения (ПО), известного как SCADA (Supervisory Control and Data Acquisition) и HMI (Human Machine Interface).
Таким образом, важнейшей задачей ПО SCADA и HMI является предоставление интерфейса взаимодействия между оператором и системой управления ТП. Часто на SCADA и HMI возлагают такие задачи, как: формирование сигнализации про отклонение в ТП, ведения архивов параметров ТП и протоколов событий.
Поэтому программное обеспечение SCADA и HMI удобно рассматривать как совокупность подсистем: базы данных параметров ТП и связи с системами управления ТП (контроллерами), формирования сигнализации про отклонение ведения ТП, архивирования, протоколирования, визуализации оперативных и архивных данных.
В дополнении, к вышеперечисленным задачам можно отнести разделение прав доступа на чтение-изменение тех или иных параметров ТП, реализованное в подсистеме безопасности.
Таким образом современные SCADA и HMI системы представляют собой достаточно сложные программные комплексы.
Предметом данного под-проекта является разработка концепции среды визуализации и управления (СВУ) и реализаций СВУ на основные способы представления, для SCADA системы OpenSCADA.
Под визуализацией подразумевается следующий набор задач:
СВУ должна работать в двух режимах — редактирования (разработка) и исполнения (исполнение). На первом этапе планируется реализация режима разработки только для Qt-версии СВУ!
В процессе функционирования СВУ должна использовать данные других подсистем:
Изображение на экране должно формироваться из ограниченного набора базовых виджетов (примитивов). Представление и интерфейс базовых виджетов для каждого СВУ реализуется отдельно. Это сделано с целью оптимизации производительности и упрощения задачи создания библиотеки базовых виджетов. С целью совместимости между различными реализациями СВУ планируется создание общего описания библиотеки базовых виджетов (модели данных) с последующей реализацией её интерфейса в каждой СВУ.
Базовые виджеты должны группироваться и формировать производные виджеты, с дальнейшим накоплением их в пользовательских библиотеках виджетов/кадров.
Учитывая назначение системы OpenSCADA, как системы для мониторинга данных во многих смежных областях, необходимо сформулировать задачи для таких систем в целом.
В системах мониторинга, как правило, отсутствует возможность управления, однако элементы интерактивного взаимодействия должны присутствовать.
Основной задачей таких систем является непрерывное предоставление информации в доступном виде и на фоне основной работы.
Концептуальную модель СВУ опишем языком UML с помощью диаграмм вариантов использования (use case diagram).
В качестве актёра, в случае разработки, выступает инженер настройки верхнего уровня "АСУ ТП", в случае исполнения — оператор.
В режиме разработки выделим такие варианты использования СВУ:
Диаграмма вариантов использования при функционировании СВУ в режиме разработки приведена на рис. 4.2.1.
Варианты использования в режиме исполнения:
Диаграмма использования СВУ в режиме исполнения приведена на рис.4.2.2.
СВУ, в целом, может работать в двух режимах — разработки и исполнения. В режиме разработки формируется интерфейс СВУ, его компоненты и определяются механизмы взаимодействия. В режиме исполнения выполняется формирование интерфейса СВУ и производится взаимодействие с конечным пользователем на основе разработанных СВУ.
Интерфейс СВУ формируется из кадров, каждый из которых, в свою очередь, формируется из элементов примитивов или пользовательских элементов интерфейса. При этом пользовательские элементы интерфейса также формируются из примитивов или других пользовательских элементов. Таким образом обеспечивается иерархичность и повторное использования уже разработанных компонентов.
Кадры и пользовательские элементы размещаются в библиотеках виджетов. Из элементов этих библиотек формируются проекты интерфейсов конечной визуализации СВУ. На основе же этих проектов формируются сеансы визуализации.
Описанная структура СВУ приведена на рисунке.
Данная архитектура СВУ позволяет реализовать поддержку трёх уровней сложности процесса разработки интерфейсов управления:
Кадр это окно, непосредственно предоставляющее информацию пользователю в графической и/или текстовой форме. Группа взаимосвязанных кадров формирует цельный пользовательский интерфейс ВУ.
Содержимое кадра формируется из элементов отображения(виджетов). Виджеты могут быть базовыми примитивами (различные элементарные фигуры, текст, тренд и т.д.) и производными (сформированные из базовых или других производных виджетов). Все виджеты группированы по библиотекам. В процессе работы пользователь может формировать собственные библиотеки производных виджетов.
Собственно кадр также является виджетом, который используется в роли конечного элемента визуализации. А это значит, что библиотеки виджетов могут хранить и заготовки кадров, и шаблоны результирующих страниц пользовательского интерфейса.
Кадры и виджеты являются пассивными элементами, которые обычно не содержат связей с динамикой и другими кадрами, а только предоставляют информацию о свойствах виджета и характере динамики(конфигурации), подключаемой к свойствам кадра. Активированные кадры, т.е. содержащие ссылки на динамику и активные связи, формируют пользовательский интерфейс и хранятся в проектах. В некоторых случаях возможно прямое назначение динамики в заготовках кадров.
Производные кадры/виджеты могут содержать другие виджеты(вложенные), которые могут быть склеены(связаны) логикой один с другим с помощью одного из языков пользовательского программирования, доступного в системе OpenSCADA.
Виджет является элементом, посредством которого обеспечивается:
Настройка и связывание виджетов производится посредством их свойств. Родительский виджет и виджеты содержащиеся в нем могут дополняться пользовательскими свойствами. В последствии пользовательские и статические атрибуты связываются со свойствами вложенных виджетов посредством внутренней логики. Для отображения динамики (т.е. текущих и архивных данных) свойства виджетов динамизируются, т.е связываются с атрибутами параметров OpenSCADA или свойствами других виджетов. Использование для связывания вложенных виджетов внутренней логикой доступных языков пользовательского программирования системы OpenSCADA снимает вопрос реализации сложной логики визуализации, обеспечивая тем самым высокую гибкость. Практически можно создавать полностью динамизированные кадры со сложными взаимосвязями на уровне пользователя.
Непосредственная конфигурация и свойства конечного интерфейса визуализации содержатся в проекте интерфейса визуализации СВУ, которых может быть создано множество.
Каждый проект включает страницы из библиотек кадров-виджетов. В ряде режимов сама страница может включать в себя вложенные страницы как независимые от родительской, так и с использованием родительского в роли шаблона. Шаблонные страницы-виджеты позволяют предельно упростить процесс создания однотипных кадров инженером АСУ-ТП или пользователем системы OpenSCADA для простого мониторинга. Примером таких однотипных кадров могут быть: группы контуров, группы графиков, протоколы и различные сводные таблицы. Мнемосхемы технологических процессов редко подпадают под такую схему и формируются в отдельной странице-виджете.
Страница, как и виджет на котором она основана, предоставляет возможность привязки динамики к описанным в нём свойствам, связи которых в целом могут быть установлены в динамику или разрешены константами. Кроме того, связывание с динамикой именно на уровне страницы проекта является предпочтительнее чем на уровне виджетов библиотек.
Пример иерархического представления компонентов проекта классического интерфейса ВУ технологического процесса с описанием выражений стандартных вызовов приведен на рисунке.
Предусмотрены следующие специальные свойства страниц:
На комбинациях указанных специальных свойств страниц реализованы следующие их типы:
На стороне визуализации (RunTime), на следующих атрибутах базового элемента "Box", построена логика, регулирующая каким образом открывать страницы:
Логика определения способа открытия страниц работает следующим образом:
Сеанс проекта это развёрнутое дерево проекта для непосредственного его исполнения, включающего отдельную задачу иерархического исполнения процедур виджетов. Для каждого проекта может быть открыто множество сеансов. Формирование конечного интерфейса визуализации осуществляется визуализаторами исходя из данных сеанса проекта, после создания сеанса по запросу.
Между виджетами на различных уровнях иерархии, в конечном счёте, выстраиваются достаточно сложные наследственные связи, которые определяются возможностью использования одних виджетов другими, начиная с библиотечного виджета и заканчивая виджетом сеанса. Для разъяснения этих особенностей взаимодействия на рисунке изображена исчерпывающая карта "использующего" наследования.
На уровне сеансов виджет содержит объект значений процедуры обсчёта. Этот объект инициируется и используется в случае наличия у процедуры обсчёта. В момент инициализации создаётся перечень параметров процедуры и выполняется её компиляция с этими параметрами в модуле, реализующем выбранный язык программирования и закодированным полным именем виджета. Скомпилированная функция подключается к объекту значений процедуры обсчёта. Далее выполняется вычисление с периодичностью сеанса.
Вычисление и обработка виджета в целом выполняется в следующей последовательности:
Объекты сеанса проекта наследуются от абстрактного объекта "Widget" и используют соответствующие объекты проекта. Так, сеанс ("Session") использует проект ("Project") и формирует развёрнутое дерево на основе него. Страница проекта "Page" прямо используется страницей сессии "SessPage". Остальные объекты ("SessWdg") разворачиваются в соответствии с иерархией элементов страницы.
В дополнение к стандартным свойствам абстрактного виджета ("Widget") элементы страницы и сами страницы сеанса получают свойства: хранения объекта значений вычислительной процедуры, обсчёта процедур и механизм обработки событий. Страницы сеанса, в дополнение ко всему, содержат контейнер следующих по иерархии страниц. Сеанс в целом вычисляется с указанной периодичностью и в последовательности:
Такая политика позволяет обходить страницы в соответствии с их иерархией, а событиям в виджетах "всплывать" на верх за одну итерацию.
Сеансы, на уровне интерфейса управления OpenSCADA, поддерживают многоязычность, которая зависит от значения общих атрибутов "lang" и далее "user", и которые визуализатор может устанавливать в соответствии со своим языком. Эта функция включается динамическим переводом сообщений OpenSCADA.
Известно, что человек может иметь индивидуальные особенности в восприятии графической информации. Если эти особенности не учитывать то можно получить неприятие и отторжение пользователя к интерфейсу ВУ. Такое неприятие и отторжение может привести к фатальным ошибкам при управлении ТП, а также травмировать человека постоянной работой с интерфейсом. В SCADA системах приняты соглашения, которые регламентируют требования по созданию унифицированного интерфейса ВУ, нормально воспринимаемого большинством людей. При этом практически отсутствует учёт особенностей людей с некоторыми отклонениями.
С целью учесть это обстоятельство, и предоставить возможность централизованно и просто изменять визуальные свойства интерфейса, проектом реализуется менеджер стилей интерфейса визуализации.
Пользователем может быть создано множество стилей, каждый из которых будет хранить цветовые, шрифтовые и другие свойства элементов кадра. Простая смена стиля позволит быстро преобразить интерфейс ВУ, а возможность назначения индивидуального стиля для пользователя позволит учесть его особенности.
Для реализации этой возможности, при создании кадров, необходимо для свойств цвета, шрифта и других установить параметр "Конфигурация" (таблицы во вкладке "Обработка") в значение "Из стиля". А в параметре "Конфигурационный шаблон" указать идентификатор поля стиля. Далее это поле автоматически появится в менеджере стилей и его можно будет там менять. Менеджер стилей доступен на странице конфигурации проекта во вкладке "Стили". На этой вкладке можно создавать новые стили, удалять старые, изменять поля стиля и удалять ненужные.
В целом стили доступны начиная с уровня проектов. На уровне библиотек виджетов можно только определять поля стилей у виджетов. На уровне проекта, при выборе стиля, включается работа со стилями, что предполагает доступ к полям стилей вместо непосредственных значений атрибутов. Фактически это означает, что при чтении или записи атрибута виджета указанные операции будут осуществляться с соответствующим полем выбранного стиля.
При запуске проекта на исполнения будет использован установленный в проекте стиль. В последствии пользователь может выбрать стиль из перечня доступных. Выбранный пользователем стиль будет сохранён и использован при следующем запуске проекта.
Учитывая спектр задач для которых может использоваться система OpenSCADA, нужно предусмотреть механизм управления интерактивными пользовательскими событиями. Это связано с тем, что при решении отдельных задач встраиваемых систем устройства ввода и управления могут значительно отличатся. Впрочем достаточно взглянуть на обычную офисную клавиатуру и клавиатуру ноутбука чтобы снять любые сомнения о необходимости менеджера событий.
Менеджер событий должен работать, используя карты событий. Карта событий — это список именованных событий с указанием его происхождения. Происхождением события может быть клавиатура, манипулятор мыши, джойстик и т.д. При возникновении события менеджер событий ищет его в активной карте и сопоставляет с именем события. Сопоставленное имя события помещается в очередь на обработку. Виджеты, в этом случае, должны обрабатывать полученную очередь событий.
Активная карта событий указывается в профиле каждого пользователя или устанавливается по умолчанию (в планах).
В целом предусмотрены четыре типа событий:
Само событие представляет недостаточно информации, особенно если его обработка происходит на уровнях выше. Для однозначной идентификации события и его источника, событие в целом записывается следующим образом: "ws_BtPress:/curtime". Где:
В таблице 3.5 приведён перечень стандартных событий, поддержка которых должна быть обеспечена в визуализаторах СВУ.
Таблица 3.5. Стандартные события
Id | Описание |
Клавиатурные события: key_[pres|rels][Ctrl|Alt|Shift]{Key} | |
*SC#3b | Скан-код клавиши. |
*#2cd5 | Код неименованной клавиши. |
*Esc | "Esc". |
*BackSpace | Удаления предыдущего символа — "<-". |
*Return, *Enter | Ввод — "Enter". |
*Insert | Вставка — "Insert". |
*Delete | Удаление — "Delete". |
*Pause | Пауза — "Pause". |
Печать экрана — "Print Screen". | |
*Home | Дом — "Home". |
*End | Конец — "End". |
*Left | Влево — "<-". |
*Up | Вверх — '^'. |
*Right | Вправо — "->". |
*Down | Вниз — '\/'. |
*PageUp | Страницы вверх — "PageUp". |
*PageDown | Страницы вниз — "PageDown". |
*F1 ... *F35 | Функциональная клавиша от "F1" до "F35". |
*Space | Пробел — ' '. |
*Apostrophe | Апостроф — '`'. |
*Asterisk | Звёздочка на дополнительном поле клавиатуры — '*'. |
*Plus | Плюс на дополнительном поле клавиатуры — '+'. |
*Comma | Запятая — ','. |
*Minus | Минус — '-'. |
*Period | Точка — '.'. |
*Slash | Наклонная черта — '\'. |
*0 ... *9 | Цифра от '0' до '9'. |
*Semicolon | Точка с запятой — ';'. |
*Equal | Равно — '='. |
*A ... *Z | Клавиши букв латинского алфавита от 'A' до 'Z'. |
*BracketLeft | Левая квадратная скобка — '['. |
*BackSlash | Обратная наклонная линия — '/'. |
*BracketRight | Правая квадратная скобка — ']'. |
*QuoteLeft | Левая кавычка — '''. |
События клавиатурного фокуса. | |
ws_FocusIn | Фокус получен виджетом. |
ws_FocusOut | Фокус утерян виджетом. |
Мышиные события: | |
key_mouse[Pres|Rels][Left|Right|Midle] | Нажата/отпущена кнопка мыши. |
key_mouseDblClick | Двойное нажатие левой кнопки мыши. |
События квитирования на стороне визуализатора. | |
ws_alarmLev | Квитирование всех нарушений всеми способами и типами уведомления. |
ws_alarmNtf{N} | Квитирование всех нарушений уведомления типа {N} (0...7). |
События примитива элементарной фигуры ElFigure: | |
ws_Fig[Left|Right|Midle|DblClick] | Активация фигур (заливок) клавишей мыши. |
ws_Fig{N}[Left|Right|Midle|DblClick] | Активация фигуры (заливки) N клавишей мыши. |
События примитива элементов формы FormEl: | |
ws_LnAccept | Установлено новое значение в строке ввода. |
ws_TxtAccept | Изменено значение редактора текста. |
ws_ChkChange | Состояние флажка изменено. |
ws_BtPress | Кнопка нажата. |
ws_BtRelease | Кнопка отпущена. |
ws_BtToggleChange | Изменена вдавленность кнопки. |
ws_BtMenu={Item} | Выбор элемента меню по кнопке Item. |
ws_BtLoad | Выбранный файл загружен. |
ws_CombChange | Изменено значение поля выбора. |
ws_ListChange | Изменен текущий элемент списка. |
ws_TreeChange | Изменен текущий элемент дерева. |
ws_TableChangeSel | Изменён выбор элемента таблицы. |
ws_TableEdit_{colN}_{rowN} | Отредактирована ячейка таблицы ({colN}:{rowN}). |
ws_SliderChange | Изменение положения слайдера. |
События примитива медиа-контента Media: | |
ws_MapAct{N}[Left|Right|Midle] | Активирована медиа-область с номером N клавишей мыши. |
ws_MediaFinished | Окончание проигрывания Медиа-потока. |
События являются основным механизмом уведомления и активно используются для осуществления взаимодействия с пользователем. Для обработки событий предусмотрены два механизма:
Механизм "Сценарии управления открытием страниц" основан на базовом атрибуте виджета "evProc", в котором может описываться переключение, открытие, замещение и навигация по страницам. Сценарий этого атрибута записывается в виде списка команд с синтаксисом: "{event}:{evSrc}:{com}:{prm}". Где:
Реализованы следующие команды:
Специальные символы шаблона расшифровываются следующим образом:
Для большего и правильного понимания работы механизма шаблонов выбора страницы приведём несколько реальных примеров:
В качестве примера приведём сценарий обеспечения работы главной страницы интерфейса пользователя:
ws_BtPress:/prev:prev:/pg_so/*/*/$
ws_BtPress:/next:next:/pg_so/*/*/$
ws_BtPress:/go_mn:open:/pg_so/*/mn/*
ws_BtPress:/go_graph:open:/pg_so/*/ggraph/*
ws_BtPress:/go_cadr:open:/pg_so/*/gcadr/*
ws_BtPress:/go_view:open:/pg_so/*/gview/*
ws_BtPress:/go_doc:open:/pg_so/*/doc/*
ws_BtPress:/go_resg:open:/pg_so/rg/rg/*
ws_BtPress:/so1:open:/pg_so/1/*/*
ws_BtPress:/so2:open:/pg_so/2/*/*
ws_BtPress:/so3:open:/pg_so/3/*/*
ws_BtPress:/so4:open:/pg_so/4/*/*
ws_BtPress:/so5:open:/pg_so/5/*/*
ws_BtPress:/so6:open:/pg_so/6/*/*
ws_BtPress:/so7:open:/pg_so/7/*/*
ws_BtPress:/so8:open:/pg_so/8/*/*
ws_BtPress:/so9:open:/pg_so/9/*/*
ws_BtPress:*:open:/pg_control/pg_terminator
Механизм "Обработка событий с помощью вычислительной процедуры виджета" основан на атрибуте "event" и пользовательской процедуре вычисления на языке программирования OpenSCADA. События, по мере поступления, аккумулируются в атрибуте "event" до момента вызова вычислительной процедуры. Вычислительная процедура вызывается с указанной периодичностью вычисления виджета и получает значение атрибута "event" в виде списка событий. В процедуре вычисления пользователь может: проанализировать, обработать и исключить обработанные события из списка, а также добавить в список новые события. Оставшиеся, после исполнения процедуры, и новые события анализируются на предмет соответствия условиям вызова сценарием первичного механизма, после чего оставшиеся события передаются на верхний по иерархии виджет для обработки им, при этом осуществляется коррекция пути событий в соответствии с иерархией проникновения события.
Содержимым атрибута "event" является списком событий формата "{event}:{evSrc}", с событием в отдельной строке. Приведём пример процедуры обработки событий на Java-подобном языке пользовательского программирования OpenSCADA:
Важным элементом любого интерфейса визуализации является уведомление пользователя про нарушения — сигнализация. Для упрощения восприятия, а также в виду тесной связности визуализации и уведомления (как правило уведомление дополняет визуализацию) решено интегрировать интерфейс уведомления в интерфейс визуализации. Для этого во всех виджетах предусматриваются два дополнительных атрибута (уровня сеанса): "alarm" и "alarmSt". Атрибут "alarm" используется для формирования сигнала виджетом в соответствии с его логикой, а атрибут "alarmSt" используется для контроля за фактом сигнализации ветви дерева сеанса проекта.
Атрибут "alarm" является строкой и имеет следующий формат: "{lev}|{categ}|{message}|{type}|{tp_arg}"
Где:
Атрибут "alarmSt" является целым числом, которое отражает максимальный уровень сигнала и факт квитирования ветви дерева сеанса проекта. Формат числа имеет следующий вид:
Формирование сигнала и получение его визуализатором.
Формирование сигнала производится самим виджетом путём установки собственного атрибута "alarm" нужным образом, и в соответствии с ним автоматически устанавливается атрибут "alarmSt" текущего и вышестоящих виджетов. Визуализаторы получают уведомление о сигнале с помощью стандартного механизма уведомления об изменении атрибутов виджетов.
Учитывая то, что обработка условий сигнализации осуществляется в виджетах, страницы, содержащие объекты сигнализации, должны исполняться в фоне, независимо от открытости их в данный момент. Это осуществляется путём установки флага исполнения страницы в фоне.
Хотя механизм сигнализации и построен в среде визуализации, возможность формирования невизуальных элементов сигнализации остаётся, например, путём создания страницы, которая никогда не будет открываться.
Квитирование
Квитирование — процесс принятия нарушения(й) с уведомлением к сведению, отключение уведомления и принятие мер по устранению нарушения(й). В контексте экрана пользовательского интерфейса квитирование предполагает только отключение уведомления.
Квитирование производится путём указания корня ветви виджетов и типов уведомления. Это позволяет реализовать квитирование на стороне визуализатора как по группам, например, по объектам сигнализации, так и индивидуально по объектам. При этом можно независимо квитировать разные типы сигнализаций. Установка квитирования производится простой модификацией атрибута "alarmSt".
Пример скрипта для работы с сигналами приведён ниже:
Внешние методы уведомления
Основным и типовым способом уведомления является дисплейная световая сигнализация аварийными цветами и их динамикой у элементов визуализации, которая присутствует всегда и не требует специфической конфигурации. Однако часто нужны уведомления внешнего типа, например: внешней лампой, бузером PC или "ревуном", произвольным звуком, синтезированной речью и т.д.
Для осуществления такой возможности внешние способы уведомления и соответствующие им типы уведомления свободно описываются для сервера визуализации и самого визуализатора. На стороне сервера визуализации описывается формирование/получение ресурса уведомления и само уведомление. На стороне визуализатора описывается уведомление согласно ресурсам сервера визуализации.
Описание правил и сценариев внешних уведомлений осуществляется с помощью пользовательских атрибутов текстового типа для страниц проекта визуализации, которые применяются при открытии этих страниц. Т.е. потенциально для каждой открываемой страницы можно описать собственные правила уведомления, хотя обычно достаточно и описываются общие правила уведомления на главной странице проекта, странице которая открывается один раз и не закрывается при работе:
Флаги:
Переменные обмена:
Примеры и комментарии к работе типовых способов уведомлений:
Для разделения доступа к интерфейсу ВУ и его составляющим каждый виджет содержит информацию о владельце, его группе и правах доступа. Права доступа записываются, как принято в системе OpenSCADA, в виде триады: "{пользователь}{группы}{остальные}", где каждый элемент состоит из трёх признаков доступа. Перечень групп записывается через символ ','. Для элементов СВУ принята следующая их интерпретация:
В режиме разработки используется простая схема доступа "root.UI:RWRWR_", что означает — все пользователи могут открывать и просматривать библиотеки, их компоненты и проекты; а редактировать могут все пользователи группы "UI" (пользовательские интерфейсы).
В режиме исполнения работают права, описанные в компонентах интерфейса, которые предусматривают возможность наследования владельца и прав сверху вниз. Причём по умолчанию наследование включено в каждом виджете, а значит они получат владельца и права проекта. В тоже время, прямая установка прав составного виджета распространит их на все компоненты этого виджета.
Для предоставления актуальных данных в интерфейс визуализации должны использоваться данные подсистемы "Сбор данных (DAQ)". Природа этих данных следующая:
Учитывая первый пункт, нужно обеспечить возможность группового назначения ссылки. Для этого используем концепцию логического уровня.
В соответствии с пунктом 2 связи обеспечивают прозрачное преобразование типов и не требуют специальной конфигурации.
Для удовлетворения возможности доступа к архивам, в соответствии с пунктом 3, связи выполняют проверку типа атрибута и, в случае подключения к "Адресу", в значение помещается адрес связи.
В терминах СВУ, динамические связи и конфигурация динамики являются одним процессом, для описания конфигурации которого предусматривается вкладка "Обработка" виджетов. Вкладка содержит таблицу конфигурации свойств атрибутов виджета и текст процедуры вычисления виджета.
Кроме полей конфигурации атрибутов в таблице предусматривается колонка "Обработка", для избирательного использования атрибутов виджетов в вычислительной процедуре виджета, и колонки "Конфигурация", "Конфигурационный шаблон" для описания конфигурации связей.
Если в колонке "Обработка" стоит true, то в вычислительной процедуре становится доступной переменная {идентификатор виджета}_{идентификатор строки}, например cw_value.
Колонка "Конфигурация" позволяет указать тип связи для атрибута виджета:
Колонка "Конфигурационный шаблон" позволяет описать группы динамических атрибутов. Например, это могут быть разные типы параметров подсистемы "DAQ" и другие виджеты интерфейса. При корректном формировании этого поля работает механизм автоматического назначения атрибутов, при указании только параметра подсистемы "DAQ" или виджета интерфейса, что упрощает и ускоряет процесс конфигурации. Значение этой колонки имеет следующий формат:
Установка связей может быть нескольких типов, который определяется префиксом:
Обработка связей происходит с периодичностью вычисления виджета в порядке:
На рисунке представлена вкладка связей с групповым назначением атрибутов путём указания только параметра, а на следующем с индивидуальным назначением атрибутов.
При размещении виджета, содержащего конфигурацию связей, в контейнер виджетов все связи исходного виджета добавляются в список результирующих связей контейнера виджетов, однако только на глубину в один уровень вложения.
Из вышесказанного видно, что связи устанавливаются пользователем в процессе конфигурации интерфейса. Однако, для предоставления возможности создания кадров общего назначения с функцией предоставления детализированных данных разных источников одного типа необходим механизм динамической установки связей. Такой механизм предусматривается посредством зарезервированного ключевого идентификатора "<page>" группы атрибутов связей у кадров общего назначения и динамическое назначение связей с идентификатором "<page>" в процессе открытия кадра общего назначения сигналом от другого виджета.
Рассмотрим пример, когда имеется кадр общего назначения "Панель контроля графиком" и множество "Графиков" на разных кадрах. "Панель контроля графиком" имеет связи с шаблонами:
При этом каждый виджет "График" имеет атрибуты tSek, tSize, trcPer и valArch. В случае вызова сигнала открытия "Панели контроля графиком" из любого виджета "График" происходит связывания атрибутов "Панели контроля графиком" в соответствии атрибуту, указанному в шаблоне, с атрибутом виджета "График". Как результат, все изменения на "Панели контроля графиком" будут отражаться на графике посредством связи.
В случае наличия у виджета "График" внешних связей на параметры подсистемы "Сбор данных", связи "Панели контроля графиком" будут устанавливаться на внешний источник. Кроме этого, если у "Панели контроля графиком" будут заявлены связи на отсутствующие непосредственно у виджета "График" атрибуты, то будет производится поиск на наличие таких атрибутов у внешнего источника, первого на который установлена прямая связь, выполняя, тем самым, дополнение недостающих связей.
Для наглядного изображения этого механизма приведена таблица.
Таблица. Механизм динамической линковки.
Атрибуты "Панели контроля графиком" (шаблон динамической связи) | Атрибуты "Графика" | Атрибуты внешнего "Параметра" | Результирующая связь или значение связующегося атрибута |
tSek (<page>|tSek) | tSek | - | "График".tSek |
tSize (<page>|tSize) | tSize | - | "График".tSize |
trcPer (<page>|trcPer) | trcPer | - | "График".trcPer |
valArch (<page>|valArch) | valArch | - | "График".valArch |
var (<page>|var) | var | var | "Параметр".var |
ed (<page>|ed) | - | ed | "Параметр".ed |
max (<page>|max) | - | - | EVAL |
min (<page>|min) | - | - | EVAL |
Исходя из вышеизложенных, архитектурных, соображений сформируем статическую диаграмму классов СВУ, учитывая разделение на концептуальную часть (движок) и часть индивидуальной реализации СВУ (рис. 4.11.1). В таблице 4.11 представлено описание классов диаграммы классов.
Таблица 4.11. Классы СВУ
Класс | Ответственность | Связи |
TSecurity | Предоставляет информацию о пользователях, а также выполняет их аутентификацию в системе OpenSCADA. | Используется виджетами и кадрами СВУ для проверки прав на доступ к ним. |
TFunction | Используется для доступа к механизму пользовательского программирования при описании логики производных виджетов, а также для включения функций API объектной модели в производные виджеты. | Хранит структуру параметров обвязываемых логикой в производных виджетах. Передаётся модулю, предоставляющего реализацию языка пользовательского программирования, с целью подключения механизма обработки логики программы. |
TUI | Корневой объект модуля подсистемы "Пользовательские интерфейсы", используемый для интеграции в ядро системы OpenSCADA. | Наследуется корневыми объектами модуля концепции СВУ и модулями реализации интерфейса СВУ. |
VCA::Engine | Корневой объект модуля концепции/движка СВУ. Содержит контейнеры объектов движка, а также общие методы и данные. | Используется интерфейсами визуализации для доступа к данным сеансов проектов и концепции в целом. Интегрирует код концепции СВУ в систему OpenSCADA. |
VCA::WidgetLib | Объект библиотеки виджетов/кадров, содержит объекты библиотечных виджетов (VCA::LWidget). Состав библиотек виджетов может свободно формироваться пользователем. | Содержит объекты библиотечных виджетов (VCA::LWidget). |
VCA::Widget | Абстрактный объект виджета. | Наследуется объектами: библиотечного виджета (VCA::LWidget), контейнерного виджета (VCA::CWidget), кадра проекта (VCA::Win) и объектами сеанса исполнения проекта (VCA::SessWin, VCA::SessWdg). Виджет-контейнер содержит функцию связанную с реализацией языка пользовательского программирования. Использует объект "OpenSCADA API TSecurity" для управления правами доступа. Использует события из менеджера событий. Обращается к менеджеру тем для получения непосредственных значений цветов шрифтов в соответствии с текущей темой. |
VCA::LWidget | Объект библиотечного виджета/кадра. | Хранится в библиотеке (VCA::WidgetLib). Может содержать вложенные виджеты, в лице объектов контейнерных виджетов (VCA::CWidget). |
VCA::CWidget | Объект контейнерного виджета библиотечного виджета/кадра (VCA::LWidget). Фактически выполняет роль ссылки на библиотечный виджет. | Содержится в библиотечном кадре/виджете (VCA::LWidget). |
VCA::Project | Объект проекта пользовательского интерфейса. Содержит окна (VCA::Win) с иерархическим наименованием. | Содержится в контейнере объекта концепции (VCA::Engine). Содержит объекты окон (VCA::Win) проекта. |
VCA::Page | Объект страницы интерфейса ВУ. Тесно связан с кадром из библиотеки виджетов, собственно кадр и несёт в себе элементы интерфейса. Сам объект окна, в дополнении к кадру, разрешает ссылки на динамику и предоставляет механизм расслоения динамики кадра на страницы, с возможностью формирования шаблона динамики. | Содержится в контейнере проекта. Наследуется от абстрактного виджета (VCA::Widget). Связывается с кадром интерфейса (VCA::LWidget) в библиотеке виджетов. |
VCA::Theme | Объект темы интерфейса визуализации. Содержит элементы темы (VCA::ThemeEl) | Содержится в контейнере объекта концепции (VCA::ConcVCA). Хранит элементы темы (VCA::ThemeEl). |
VCA::ThemeEl | Объект элемента темы. Содержит ассоциацию имени элемента с кодом цвета и шрифта. | Содержится в контейнере темы (VCA::Theme). Используется объектом виджета (VCA::Widget) для получения значений цвета и шрифта по имени элемента темы. |
VCA::EventMap | Объект карты событий. Содержит объекты событий (VCA::Event). | Содержится в контейнере объекта концепции (VCA::ConcVCA). Хранит описания событий (VCA::Event). |
VCA::Event | Объект события, содержит ассоциацию имени объекта(события) с реальным событием. | Содержится в контейнере карты событий (VCA::EventMap). |
VCA::Session | Объект сессии исполнения проекта визуализации. Открывается модулем интерфейса визуализации и использует, в дальнейшем, данные сессии для визуализации своим методом. Все вычисления интерфейсов визуализации выполняются именно в сессии. | Содержится в проекте интерфейса визуализации. Содержит объекты окон сессии с данными исполнения. Используется модулями интерфейсов визуализации для отображения данных сессии. |
VCA::SessPage | Объект страницы сессии. Содержит динамические данные окна проекта над которыми выполняет требуемые вычисления. | Содержится в объекте сессии проекта (VCA::SessProj). Наследуется от абстрактного виджета (VCA::Widget). Использует объект страницы проекта (VCA::Page) как источник исходных параметров. |
VCA::SessWdg | Объект виджета сессии. Содержит динамические данные отдельного элемента кадра над которыми выполняет требуемые вычисления. Может вкладываться один в другой в соответствии с иерархией виджетов кадра. | Содержится в объекте окна сессии (VCA::SessPage) или в высшем по иерархии объекте этого типа. Наследуется от абстрактного виджета (VCA::Widget). Использует объект библиотечного (VCA::LWidget) и/или контейнерного (VCA::CWidget) виджета как источник исходных параметров. Используется модулем интерфейса визуализации в роли источника динамических данных для визуализации. |
Vision, WebGUI | Корневые объекты модуля интерфейса визуализации, построенные на основе библиотеки Qt и Web-технологий. Предоставляют доступ к средствам исполнения и разработки интерфейсов визуализации в среде используемой технологии. | Предоставляют доступ к среде исполнения и разработки. Интегрируют код интерфейса визуализации в систему OpenSCADA. |
VRunTime, WebRunTime | Объекты среды исполнения интерфейса визуализации на основе библиотеки Qt и Web-технологий. Непосредственно предоставляют пользовательский интерфейс визуализации и управления. | Содержаться в корневых объектах модулей визуализации. Подключаются и используют данные объекта сеанса проекта (VCA::SesProj) концепции СВУ. В соответствии со структурой сеанса содержат множество специализированных объектов непосредственного отображения. |
VDevelop, WebDevelop | Объекты среды разработки интерфейса визуализации на основе библиотеки Qt и Web-технологий. Предоставляют интерфейс инструмента над данными концепции для разработки интерфейсов ВУ. | Содержаться в корневых объектах модулей визуализации. Подключаются к объекту корня концепции СВУ (VCA::Engine) и предоставляют графический интерфейс для управления ею. В соответствии со структурой концепции содержат множество специализированных объектов управления. |
Статическая диаграмма классов не раскрывает всей иерархии взаимодействия объектов, основанных на абстрактном объекте VCA::Widget. Это связано с неявным наследованием данных свойств виджетов через все слои движка, а также тонкостями наследования, выстроенного путём использования данных одних виджетов в других. Для разъяснения этих особенностей изображена исчерпывающая карта "использующего" наследования в разделе 4.5.
Любой вновь создаваемый виджет основывается на одном из нескольких примитивов (конечный элемент визуализации) путём установки родственной связи как прямо на примитив, так и посредством нескольких промежуточных пользовательских виджетов. Каждый из примитивов содержит механизм (логику) модели данных. Экземпляр виджета хранит значения свойств конфигурирования примитива специально для себя.
В задачи интерфейса визуализации входит поддержка и работа с моделью данных примитивов виджетов. Примитивы виджетов должны быть тщательно проработаны и унифицированы с целью охватить как можно больше возможностей в как можно меньшем количестве слабо связанных друг с другом по назначению примитивов.
Таблица. Библиотека примитивов виджетов (базовых элементов отображения)
Таблица. Общий набор свойств/атрибутов в виджете
Движок среды визуализации предусматривает активацию атрибутов, специфичных для визуализатора. Процесс активации осуществляется при открытии сеанса визуализации для проекта и предусматривает в этом проекте: создание специфичного атрибута с указанными свойствами, если он отсутствует, и активацию для отслеживания движком среды визуализации его модификации, как для атрибутов формирования образов примитивов. С перечнем специфичных для визуализатора атрибутов можно ознакомиться в документации на соответствующий визуализатор.
Примитив является основой для отрисовки элементарных графических фигур со всевозможной комбинацией их в одном объекте. Учитывая широкий спектр всевозможных фигур, которые должен поддерживать примитив, и в тоже время являться достаточно простым в использовании и, по возможности, в реализации, решено было ограничить перечень базовых фигур, используемых для построения результирующих графических объектов до таких фигур: линия, дуга, кривая Безье и заливка замкнутых контуров. Основываясь уже на этих базовых фигурах, можно строить производные фигуры, комбинируя базовые. В рамках примитива существует возможность задания прозрачности цвета в диапазоне [0...255], где '0' — полная прозрачность.
Таблица. Набор дополнительных свойств/атрибутов в примитиве "ElFigure"
Примитив, предназначенный для предоставления стандартных элементов формы в распоряжение пользователя. Общий перечень атрибутов зависит от типа элемента.
Таблица. Набор дополнительных свойств/атрибутов в примитиве "FormEl"
Данный примитив предназначен для вывода простого текста, используемого в роли меток и различных подписей. С целью простого создания частых декоративных оформлений примитив должен поддерживать обвод текста рамкой.
Таблица. Набор дополнительных свойств/атрибутов в примитиве "Text"
Данный примитив предназначен для проигрывания различных медиа-материалов, начиная от простых изображений и заканчивая полноценными аудио и видео потоками.
Таблица. Набор дополнительных свойств/атрибутов в примитиве "Media"
Данный примитив предназначен для построения различных диаграмм, включая графики/тренды отображения текущего процесса и архивных данных. Реализованы следующие типы диаграмм:
Для всех типов диаграмм возможно, в качестве источника данных, указание:
Поддерживается режим слеживания текущих значений и значений с архива, а также возможно построение графиков параметров не имеющих архива значений, путём накопления текущих значений в буфере диаграммы и только на момент активного отображения этой диаграммы.
Процесс доступа к архивным данным оптимизирован путём ведения промежуточного буфера отображения, а также упаковки трафика данных при запросе, путем приведения данных к качеству достаточного для отображения.
Таблица. Набор дополнительных свойств/атрибутов в примитиве "Diagram"
Данный примитив предназначен для визуализации данных архива сообщений путём формирования протоколов с различными способами визуализации, начиная от статического сканирующего просмотра и заканчивая динамическим отслеживанием протокола сообщения.
Таблица. Набор дополнительных свойств/атрибутов в примитиве "Protocol"
Примитив предназначен для формирования отчётной, оперативной и иной документации на основе шаблонов документов.
Таблица. Набор дополнительных свойств/атрибутов в примитиве "Document"
Возможности примитива "Документ":
В основе любого документа лежит XHTML-шаблон. XHTML-шаблон это тег "body" WEB-страницы, содержащий статику документа в стандарте XHTML 1.0 и элементы исполняемых инструкций на одном из языков пользовательского программирования OpenSCADA в виде <?dp {procedure} ?>. Результирующий документ формируется путём исполнения процедур и вставки их результата в документ.
Источником значений исполняемых инструкций являются атрибуты виджета этого примитива, а также все механизмы языков пользовательского программирования OpenSCADA. Атрибуты могут добавляться пользователем и линковаться на реальные атрибуты параметров или-же являться автономными, значения которых будут формироваться в скрипте виджета. В случае со слинкованными атрибутами могут извлекаться значения из истории, архива.
На рис. 3.8.7.a изображена структурная схема виджета примитива "Документ". Согласно этой структуре "Документ" содержит: XHTML-шаблон, результирующие документы и скрипт обработки данных. Источником данных для скрипта и результирующих документов являются атрибуты виджета.
Предусматривается работа виджета в двух режимах: "Динамический" и "Архивный". Отличие архивного режима заключается в наличии архива указанной глубины и атрибутов, позволяющих управлять процессом архивирования и просмотра указанного документа в архиве.
Генерация документа всегда производится в момент установки атрибута времени time относительно установленного начального времени документа в атрибуте bTime. При выключенном архиве результирующий документ помещается непосредственно в атрибут doc. При включенном архиве результирующий документ помещается в ячейку под курсором, атрибут aCur, а так-же в doc если значение курсора архива aCur и курсора визуализируемого документа vCur совпадают. Атрибуты архивных курсоров предусматривают несколько командных значений:
Как было указано выше динамика шаблона документа определяется вставками исполняемых инструкций вида "<?dp {procedure} ?>". В процедурах могут использоваться одноимённые атрибуты виджета и функции пользовательского интерфейса программирования OpenSCADA. Кроме атрибутов виджета зарезервированы специальные атрибуты (табл. 3.8.7.a).
Таблица 3.8.7.a. Специальные и зарезервированные элементы шаблона.
Имя | Назначение |
Атрибуты | |
rez | Атрибут результата исполнения процедуры, содержимое которого помещается в дерево документа. |
lTime | Время последнего формирования. Если документ формируется впервые то <lTime> равен <bTime>. |
rTime | Содержит время для перебираемых значений в секундах, определяется внутри тегов с атрибутом "docRept". |
rTimeU | Содержит время для перебираемых значений в микросекундах, определяется внутри тегов с атрибутом "docRept". |
rPer | Содержит периодичность перебора значений (атрибут "docRept"). |
mTime, mTimeU, mLev, mCat, mVal | Определяются внутри тегов с атрибутом "docAMess" при разборе сообщений архива сообщений: mTime — время сообщения; mTimeU — время сообщения, микросекунды; mLev — уровень сообщения; mCat — категория сообщения; mVal — значение сообщения. |
Специальные теги | |
Специальные атрибуты стандартных тегов | |
body.docProcLang | Язык исполняемых процедур документа. По умолчанию это "JavaLikeCalc.JavaScript". |
*.docRept="1s" | Тег с указанным атрибутом при формировании размножается путём смещения времени в атрибуте "rTime" на значение указанное в данном атрибуте. |
*.docAMess="1:PLC*" | Указывает на необходимость размножения тега с атрибутом сообщения из архива сообщений за указанный интервал времени, в соответствии с уровнем "1" и шаблоном запроса "PLC*" по категории сообщения. В шаблоне запроса могут указываться регулярные выражения в виде "/{re}/". Для данного тега, в процессе размножения, определяются атрибуты: "mTime", "mTimeU", "mLev", "mCat" и "mVal". |
*.docAMessArchs="ArchMod0.Archivator0[;ArchModN.ArchivatorN]" | Дополняет атрибут "*.docAMess" перечнем архиваторов для чтения сообщений. |
*.docRevers="1" | Указывает на инвертирование порядка размножения, последний сверху. |
*.docAppend="1" | Признак необходимости добавления результата выполнения процедуры в тег процедуры. Иначе результат исполнения заменяет содержимое тега. |
body.docTime | Время формирования документа. Используется для установки атрибута lTime при следующем формировании документа. Не устанавливается пользователем! |
table.export="1" | Включение возможности экспорта содержимого указанной таблицы в CSV-файл и другие табличные форматы. |
Примитив контейнера используется для формирования составных виджетов и/или страниц пользовательского интерфейса.
Таблица. Набор дополнительных свойств/атрибутов в примитиве Box
Хранение данных виджетов, библиотек виджетов и проектов реализовано в БД, доступных системе OpenSCADA. БД организована по принадлежности данных к библиотеке-проекту. Т.е. отдельная библиотека-проект хранится в отдельной группе таблиц одной или разных БД. Перечень библиотек виджетов хранится в индексной таблице библиотек с именем "VCALibs", со структурой "Libs", а перечень проектов в индексной таблице "VCAPrjs", со структурой "Projs". Экземпляр этих таблиц создаётся в каждой БД, где хранятся данные этого модуля с перечнем библиотек, содержащихся в конкретно взятой БД. В состав таблиц, принадлежащих библиотеке виджетов и проектов, входят следующие:
Проекции (структуры) основных таблиц таковы:
API пользовательского программирования движка визуализации представлено непосредственно объектами OpenSCADA, формирующие пользовательский интерфейс, а именно "Сеансом" и "Виджетами/страницами". Для пользователя эти объекты предоставляют набор функций управления:
Объект "Сеанс" ( this.ownerSess() )
Объект "Виджет" (this)
Объект "Виджет", примитива "Документ" (this)
Устаревшее API представляется группой функций непосредственно в модуле движка СВУ. Вызов этих функций из скриптов виджетов может осуществляться прямо по идентификатору функции, поскольку их область имён указывается для контекста скриптов виджетов:
Список виджетов (WdgList)
Описание: Возвращает список виджетов в контейнере виджетов или список дочерних виджетов. Если установлено pg, то возвращается список страниц для проектов и сеансов.
Параметры:
ID | Имя | Тип | Режим | По умолчанию |
list | Список | Строка | Возврат | |
addr | Адрес | Строка | Вход | |
pg | Страницы | Bool | Вход | 0 |
Присутствие узла (NodePresent)
Описание: Проверка на присутствие узла, включая виджеты, атрибуты и другие.
Параметры:
ID | Имя | Тип | Режим | По умолчанию |
rez | Результат | Bool | Возврат | |
addr | Адрес | Строка | Вход |
Список атрибутов (AttrList)
Описание: Возвращает список атрибутов виджета. Если установлен noUser тогда возвращаются только не пользовательские атрибуты.
Параметры:
ID | Имя | Тип | Режим | По умолчанию |
list | Список | Строка | Возврат | |
addr | Адрес | Строка | Вход | |
noUser | Без пользовательских | Bool | Вход | 1 |
Запрос атрибута (AttrGet)
Описание: Запрос значения атрибута виджета. Запрос может осуществляться как указанием полного адреса атрибута в addr, так и отдельно адреса виджета в addr, а идентификатора атрибута в attr.
Параметры:
ID | Имя | Тип | Режим | По умолчанию |
val | Значение | Строка | Возврат | |
addr | Адрес | Строка | Вход | |
attr | Атрибут | Bool | Вход |
Установка атрибута (AttrSet)
Описание: Установка значения атрибута виджета. Установка может осуществляться как указанием полного адреса атрибута в addr, так и отдельно адреса виджета в addr, а идентификатора атрибута в attr.
Параметры:
ID | Имя | Тип | Режим | По умолчанию |
addr | Адрес | Строка | Вход | |
val | Значение | Строка | Вход | |
attr | Атрибут | Bool | Вход |
Пользователь сеанса (SesUser)
Описание: Возвращает пользователя сеанса по пути к виджету сеанса.
Параметры:
ID | Имя | Тип | Режим | По умолчанию |
user | Пользователь | Строка | Возврат | |
addr | Адрес | Строка | Вход |
Сервисные интерфейсы это интерфейсы доступа к системе OpenSCADA посредством интерфейса управления OpenSCADA из внешних систем. Данный механизм положен в основу всех механизмов обмена внутри OpenSCADA, реализованных посредством слабых связей и стандартного протокола обмена OpenSCADA.
С целью предоставления унифицированного, группового и сравнительно быстрого доступа к значениям атрибутов визуальных элементов предусмотрена сервисная функция визуального элемента "/serv/attr" и команды получения/установки значений атрибутов: <get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> и <set path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/>.
Таблица. Атрибуты команд получения/установки атрибутов визуальных элементов
Id | Имя | Значение |
Команда запроса визуальных атрибутов виджета: <get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> | ||
tm | Время/счётчик изменений | Установка времени/счётчика изменений для запроса только изменившихся атрибутов. |
<el id="{attr}" p="{a_id}">{val}</el> | Формирование дочерних элементов с результатами атрибутов | В дочернем элементе указываются: строковых идентификатор attr атрибута, индекс a_id атрибута и его значение val. |
Команда установки визуальных атрибутов виджета: <set path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr"/> | ||
<el id="{attr}">{val}</el> | Установка атрибутов | В дочерних элементах указывается идентификатор атрибута attr и его значение val. |
Команда активации-создания специфичного для визуализатора атрибута: <activate path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattr/{attrId}" aNm="{Name}" aTp="{Type} aFlg="{Flags}"/> | ||
attrId | Идентификатор атрибута | |
aNm | Имя атрибута | |
aTp | Тип атрибута | |
aFlg | Флаги атрибута |
С целью оптимизации трафика сетевого взаимодействия путём исключения мелких запросов, а использования одного, но большого запроса предусмотрен групповой запрос значений атрибутов визуальных элементов. Группировка данного запроса подразумевает запрос атрибутов всей ветви виджета, включая и вложенные элементы. Для данного запроса предусмотрена сервисная команда "/serv/attrBr". Запрос данной сервисной команды эквивалентен сервисной команде "/serv/attr" и выглядит следующим образом:
<get path="/UI/VCAEngine/{wdg_addr}/%2fserv%2fattrBr"/>
Результат:
С целью унификации и оптимизации доступа к страницам предусмотрена сервисная функция сеанса "/serv/pg" и команды запроса перечня открытых страниц <openlist path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>; открытия страницы <open path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>; и закрытия страницы <close path="/UI/VCAEngine/ses_{Session}/%2fserv%2fpg"/>.
Результатом запроса перечня открытых страниц являются дочерние элементы <el>{OpPage}</el>, содержащие полный путь открытой страницы. Кроме перечня открытых страниц запрос возвращает значение текущего счётчика вычисления сеанса в атрибуте tm. Если данный атрибут устанавливается при запросе, то для каждой открытой страницы возвращается список изменённых с момента указанного значения счётчика виджетов открытой страницы.
Для предоставления механизма глобального контроля за сигнализацией сеанса предусмотрена сервисная функция сеанса "/serv/alarm" и команды запроса статуса сигналов <get path="/UI/VCAEngine/ses_{Session}/%2fserv%2falarm"/>; и квитирование сигналов <quittance path="/UI/VCAEngine/ses_{Session}/%2fserv%2falarm"/>.
Запрос статуса сигналов возвращает обобщённое состояние сигналов, а так-же ресурс уведомления, если атрибут "mode" равен "resource". Результатом запроса ресурса уведомления обычно является звуковой файл, для воспроизведения, в это-же время обеспечивается отслеживание последовательности сигнализации и квитирования отдельных ресурсов сообщений.
Запрос на квитирование выполняет квитирование указанного виджета, атрибут wdg, в соответствии с шаблоном, атрибут tmpl.
Для предоставления унифицированного механизма манипуляции сеансами визуализаторам СВУ в модуле движка СВУ (VCAEngine) предусмотрена сервисная функция "/serv/sess" и команды запроса перечня открытых сеансов, подключения/создания нового сеанса и отключения/удаления сеанса: <list path="/UI/VCAEngine/%2fserv%2fsess"/>, <connect path="/UI/VCAEngine/%2fserv%2fsess"/> и <disconnect path="/UI/VCAEngine/%2fserv%2fsess"/> соответственно.
Таблица. Атрибуты команд механизма манипуляции сеансами
Id | Имя | Значение |
Команда запроса перечня открытых сеансов для проекта: <list path="/UI/VCAEngine/%2fserv%2fsess"/> | ||
prj | Указание проекта | Указывает проект, для которого возвращать перечень открытых сеансов. |
<el>{Session}</el> | Контроль перечня сеансов | В дочерних элементах указываются сеансы, открытые для запрошенного проекта. |
Команда подключения/открытия сеанса: <connect path="/UI/VCAEngine/%2fserv%2fsess"/> | ||
sess | Установка и контроль имени сеанса | Если атрибут определён, то производится подключение к существующему сеансу, иначе создание нового сеанса. В случае открытия нового сеанса в данный атрибут помещается его имя. |
prj | Установка имени проекта | Используется для открытия нового сеанса для указанного проекта и если атрибут sess не указан. |
Команда отключения/закрытия сеанса: <disconnect path="/UI/VCAEngine/%2fserv%2fsess"/> | ||
sess | Установка имени сеанса | Указывает имя сеанса от которого выполняется отключение или закрытие. Сеансы, не являющиеся фоновыми и к которым ни один из визуализаторов не подключен, автоматически закрываются. |
С целью оптимизации производительности локального и особенно сетевого взаимодействия предусмотрена сервисная функция "/serv/wlbBr" и команда запроса дерева библиотек виджетов: <get path="/UI/VCAEngine/%2fserv%2fwlbBr"/>. Результатом запроса является дерево с элементами библиотек виджетов, теги wlb. Внутри тегов библиотек виджетов содержаться тег иконки ico и теги виджетов библиотеки w. Теги виджетов, в свою очередь, содержат тег иконки и теги дочерних виджетов cw.
Для ускорения процесса разработки пользовательских интерфейсов визуализации и управления нужно предусмотреть функцию копирования элементов. Что-бы заложить поддержку различных вариантов копирования запишим их по пунктам:
Перечислим возможности, которые сможет обеспечить СВУ, построенная на основе данного проекта:
Цель проигрывания процесса построения различных интерфейсов визуализации на основе концепции данного проекта заключается в выявлении особенностей различных реализаций и узких мест в описании их концепцией.
Выполнено без в мыслях, без фиксации.
Реализацию будем производить поэтапно, в направлении от функций в концепции к её представлению на библиотеке Qt, и так до последнего компонента. Такой подход позволит получать результат между этапами, анализировать его и учитывать особенности на следующих этапах. Для пошаговой реализации разобьем всю задачу на логические части и выстроим их в зависимости одна от другой, в реализации.
Целями данного этапа является:
В результате проделанной работы созданы модули модели данных UI.VCAEngine и представления UI.Vision. На данном этапе модулями реализуются механизмы формирования элементов пользовательского интерфейса. На следующий этапе данные элементы будут использованы для формирования цельных интерфейсов визуализации и управления.
Рассмотрим по пунктам результаты реализации данного этапа:
В соответствии со статической диаграммой классов (рис.4.11.1) и общими требованиями были реализованы модули "UI.VCAEngine" и "UI.Vision" для системы OpenSCADA. Модуль "UI.VCAEngine" реализует модель данных СВУ и является источником для последующего представления этих данных различными механизмами визуализации. Модуль "UI.Vision" реализует способ представления данных, основанный на библиотеке Qt версии 4 фирмы Trolltech.
Связь между модулем модели данных и представления организована посредством прямых вызовов (сильные связи). Такой способ связи выбран для предварительного абстрагирования от особенностей взаимодействия и концентрации на основных задачах реализации. В последствии планируется унификация и построение этих связей посредством интерфейса управления системой OpenSCADA (слабые связи). В результате будет достигнута возможность разнесения модели данных и представления с возможностью одновременного обслуживания различных механизмов представления одной моделью данных СВУ. Кроме того, можно будет оценить степень влияния типа связи на производительность СВУ.
Модуль модели данных(движка) СВУ содержит контейнер библиотек виджетов/кадров. Модулем предоставляется предопределённая библиотека базовых виджетов(примитивов) с первичной реализацией собственных свойств и логики обработки этих свойств.
Хранение данных виджетов и библиотек виджетов реализовано в БД, доступных системе OpenSCADA. БД организована по принадлежности данных к библиотеке. Т.е. отдельная библиотека хранится в отдельной группе таблиц одной или разных БД. Перечень библиотек виджетов хранится в индексной таблице библиотек с именем "VCALibs" и структурой "Libs". Экземпляр этой таблицы создаётся в каждой БД где хранятся данные этого модуля с перечнем библиотек, содержащихся в конкретно взятой БД. В состав таблиц, принадлежащих библиотеке виджетов, входят следующие:
Для управления библиотеками виджетов и отдельными виджетами были написаны сценарии конфигурации на языке интерфейса управления OpenSCADA. На данный момент эти сценарии призваны выполнять только функции централизованной конфигурации элементов движка СВУ, однако, в последствии их планируется расширить и наделить функциями обработки запросов к модели данных от модулей представления с целью организации "слабых связей" между "Моделью данных" и "Представлением".
Основой практически всех элементов движка стал объект абстрактного элемента визуализации VCA::Widget. На своём, абстрактном, уровне объект наделён следующими свойствами:
Для представления библиотеки виджетов реализован класс VCA::WdgLib, основными функциями которого является содержание библиотечных виджетов, хранение и загрузка их с БД, предоставление доступа к ресурсам (Mime-данные), а также контроль доступа.
Специально для включения в библиотеку виджетов был создан класс библиотечного виджета VCA::LWidget, который основан на классе абстрактного виджета VCA::Widget и предоставляет дополнительные функции: хранения данных виджета в таблицах библиотеки, переопределения доступа к ресурсам на таблицу с mime-данными библиотеки и хранение вложенного контейнерного виджета VCA::CWidget.
В свою очередь класс контейнерного виджета VCA::CWidget предоставляет функции: хранения данных контейнерного виджета в таблицах библиотеки, переопределения доступа к ресурсам на таблицу с mime-данными библиотеки, а также принудительный режим простой ссылки для всех контейнерных виджетов.
На основе класса библиотечного виджета VCA::LWidget был сформирован абстрактный класс терминального виджета VCA::PrWidget. А уже на его основе сформированы реализации примитивов базовых виджетов, которые и формируют библиотеку базовых виджетов, создаваемую модулем при инициализации. Значения свойств базовых виджетов также могут сохраняться в БД (таблицы библиотеки виджетов), формируя нужные шаблоны. Кроме того, базовая библиотека примитивов может доопределяться расширенными примитивами из модулей интерфейсов представления, которым базовых недостаточно. Но в этом случае нужно учитывать, что подобные действие — путь к несовместимости между модулями интерфейсов представления!
Среда разработки пользовательских интерфейсов модуля основана на MDI(Multi Document Interface) интерфейсе. Данный подход позволяет одновременно редактировать несколько кадров различных размеров. Использованы следующие механизмы управления разработкой: панели инструментов, пункты меню и контекстное меню. Большинство действий дублируются в разных механизмах, что позволяет быстро найти инструмент предпочитаемым способом. Навигационные интерфейсы реализованы присоединяемыми окнами. Конфигурация панелей инструментов и присоединяемых окон сохраняется при выходе и восстанавливается при старте, что позволяет настраивать интерфейс под себя.
Одним из элементом пользовательского интерфейса, реализованным как присоединяемое окно, является навигатор библиотек виджетов. С помощью навигатора можно быстро найти нужный виджет или библиотеку и проделать над ними необходимые операции. Реализованы операции: добавления, удаления, настройки виджетов и библиотек, а также визуального редактирования виджетов.
Для удобного управления свойствами виджетов/кадров реализован инспектор атрибутов(свойств) виджетов. Инспектор атрибутов реализован как присоединяемое окно, которое активируется при выборе кадра или виджета. Окно инспектора атрибутов можно удобно расположить на виду, пришвартовав к одной из сторон рабочего окна. Инспектором атрибутов реализована поддержка групповой конфигурации нескольких виджетов, а также группирование однотипных свойств.
Для визуального редактирования кадров реализована первичная поддержка редактирования виджетов и кадров. Уже сейчас редактор позволяет редактировать кадры, основанные на примитиве "Box", и полноценно отображать примитив текстового поля "Text". В редакторе кадров реализованы функции:
Вид окна разработки приведён на рис. 6.1.1, где можно видеть: панели инструментов, навигатор виджетов, инспектор атрибутов, окно редактирования кадра и строка статуса.
Для настройки объектов виджетов и их библиотек разработаны два диалога, диалог настройки виджета (рис.6.1.2) и диалог настройки библиотеки виджетов (рис.6.1.3). Диалог настройки библиотеки позволяет установить основные свойства и поместить mime-данные в БД, для последующего использования в виджетах библиотеки. Диалог настройки виджета позволяет установить: основные свойства виджета, индивидуально установить значения атрибутов и сконфигурировать внутреннюю процедуру вычислений виджета с дополнительными (пользовательскими) свойствами.
Целями данного этапа является:
На данном этапе был добавлен механизм исполнения проекта в сеансах модели данных модуля VCAEngine, а также визуализация сеанса проекта, режим "Исполнение", в модуле визуализации на библиотеке Qt Vision с элементами обновления данных и интерактивного взаимодействия с пользователем.
В соответствии с рис.4.11.1 и разделом 4.5 объекты сеанса проекта наследуются от абстрактного объекта Widget и используют соответствующие объекты проекта. Так, сеанс Session использует проект Project и формирует развёрнутое дерево на основе него. Страница проекта Page прямо используется страницей сеанса SessPage. Остальные объекты SessWdg разворачиваются в соответствии с иерархией элементов страницы (раздел 4.5).
В дополнение к стандартным свойствам абстрактного виджета Widget элементы страницы и сами страницы, сеанса получают свойства хранения кадра значений вычислительной процедуры, обсчёта процедур и механизм обработки событий. Страницы сеанса, в дополнение ко всему, содержат контейнер следующих по иерархии страниц. Сеанс в целом обсчитывается с указанной периодичностью и в последовательности:
Такая политика позволяет обходить страницы в соответствии с иерархией, а событиям в виджетах всплывать наверх за одну итерацию.
В сеансе реализована поддержка специальных свойств страниц:
На основе этих свойств реализованы следующие типы страниц:
В разделе выше мы уже отмечали, что виджет сеанса содержит кадр значений процедуры обсчёта. Этот кадр инициируется и используется в случае наличия процедуры обсчёта. В момент инициализации создаётся перечень параметров процедуры и выполняется компиляция процедуры с этими параметрами в модуле, реализующем выбранный язык программирования, и закодированным полным именем виджета. Скомпилированная функция подключается к кадру значений процедуры обсчёта. Далее выполняется вычисление с периодичностью сеанса.
Вычисление и обработка виджета в целом выполняется в следующей последовательности:
При исполнении виджета сеанса необходимо выполнение обработки ссылок. На данный момент подключение по ссылкам выполняется в момент вычисления, что является небыстрой операцией. Реализация обработки ссылок будет пересмотрена и оптимизирована в дальнейшем.
Заложена поддержка следующих типов ссылок:
На стороне визуализации (модуль Vision) для визуализации процесса исполнения проекта реализован объект VisRun. При запуске он шлёт запрос на создание и инициализацию сессии. Далее выполняется запрос на перечень открытых страниц. Исходя из информации об открытых страницах VisRun и их связности, формируется результирующий интерфейс. На рис. 6.3 приведён пример классического SCADA интерфейса с объектами сигнализации, где главное окно содержит страницу внутри, которая замещается по нажатию на кнопки объектов сигнализации и листания.
Реализовано обновление содержимого открытых страниц интерфейса визуализации с периодичностью исполнения сеанса проекта. В процессе обновления выполняется:
По закрытию окна "Исполнения" производится закрытие сеанса проекта в модели данных. В дальнейшем будет реализована возможность подключения к ранее открытому сеансу и отключение от сеанса, без его закрытия.
Механизм запроса только изменённых данных основан на абсолютном счётчике исполнения сеанса. При внесении реальных изменений в атрибуты виджетов выполняется запоминание значения этого счётчика, что и позволяет идентифицировать изменённые атрибуты. Такой подход позволяет повысить производительность и уменьшить нагрузку на трафик в случае доступа к модели через сеть.
Визуализатор сеанса ("RunTime"), в виду своего непосредственного контакта с пользователем, собирает различные события. Часть событий обрабатывается образами базовых виджетов (Text, Box, Document и т.д.), в результате чего могут формироваться другие события. Другая часть прямо передаётся в модель данных, где они и обрабатываются.
В модель данных события передаются сразу после получения, где они собираются в атрибуте виджета "event" до момента следующей итерации исполнения сеанса. Далее, в процессе обсчёта сеанса, события извлекаются из атрибута "event" и обрабатываются в процедуре виджета или в соответствии со сценарием в атрибуте "evProc". Необработанные событие поднимаются к вышестоящему виджету модели.
Переключение, открытие, замещение и навигация по страницам реализовано на основе обработки событий по сценарию, в атрибуте активного виджета "evProc". Сценарий этого атрибута записывается в виде списка команд с синтаксисом: {event}:{srcWdg}:{com}:{prm}, детали в разделе 4.7 и разделе 4.4.
На данном этапе планируется реализация моделей данных UI.VCAEngine и образов визуализатора Vision, WebVision для всех базовых элементов: "ElFigure", "FormEl", "Text", "Media", "Diagram", "Protocol", "Document", "Function", "Box", "Link".
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
На рисунке представлена часть экрана с кадром, содержащим элементарные фигуры.
Фигуры, лежащие в основе данного виджета, содержат точки(начальная и конечная), которые могут стыковаться с соответствующими точками других фигур, и точки, с помощью которых изменяется геометрия фигуры.
Добавить фигуру можно с помощью мыши:
Удалить фигуру(ы) можно путём нажатия кнопки "Del", имея выделенную(ые) фигуру(ы).
Скопировать фигуру(ы) можно путём нажатия комбинации клавиш "Ctrl" + "C", имея выделенную(ые) фигуру(ы).
Передвинуть/изменить габариты фигуры можно с помощью мыши или клавиатуры:
Существует возможность перемещать несколько выделенных фигур, выбранных при помощи удержания "Ctrl"(эта опция работает при отключенной кнопке Connetcions(Привязки)) либо при помощи выделения мышкой.
Связать фигуры друг с другом можно следующим образом:
Залить замкнутый контур из фигур можно следующим образом:
Удалить заливку замкнутого контура можно из контекстного меню, клацнув правой кнопкой манипулятора "мышь" по заливке; разорвав контур заливки; двойным кликом левой кнопки манипулятора "мышь" по уже имеющемуся залитому контуру.
Поворот фигуры осуществляется вокруг центра виджета.
На рисунке представлена часть экрана с кадром, содержащим вышеперечисленные элементарные фигуры.
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
Реализованы режимы: «Включен» и «Активен», а также передача изменений и событий в модель данных СВУ (движок).
На рисунке представлена часть экрана с кадром, содержащим вышеперечисленные элементы формы.
Реализованы режимы: "Включен" и "Активен", а также передача изменений и событий в модель данных СВУ (движок). Для всех реализованных представлений поддерживается активный режим, т.е. элементы могут быть использованы для создания форм пользовательского ввода.
На рисунке представлена часть экрана с кадром, содержащим вышеперечисленные элементы формы.
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
На рисунке представлена часть экрана с кадром, содержащим примеры текста с использованием различных параметров.
На рисунке представлена часть экрана с кадром, содержащим примеры текста с использованием различных параметров.
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
На рисунке представлена часть экрана с кадром, содержащим примеры просмотра/проигрывания медиа-данных.
На рисунке представлена часть экрана с кадром, содержащим примеры просмотра/проигрывания медиа-данных.
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
Модулем визуализатора предоставляется и использует ряд специфических атрибутов данного примитива, информация о которых приведена в таблице.
Id | Имя | Назначение |
sclWin | Масштабирование участка обрамлённого окном, мышью | Логический тип атрибута, созадаваемый вручную пользователем в случае надобности. Для значения "истина" включается режим масштабирования участка тренда обрамлённого окном с помощью мыши. |
На рисунке представлена часть экрана с кадром, содержащим примеры диаграмм: "График", "Спектр" и "XY".
На рисунке представлена часть экрана с кадром, содержащим примеры диаграмм: "График", "Спектр" и "XY".
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
На рисунке представлена часть экрана с кадром, содержащим пример протокола.
На рисунке представлена часть экрана с кадром, содержащим пример протокола.
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
В основе любого документа лежит XHTML-шаблон. XHTML-шаблон это тег "body" WEB-страницы, содержащий статику документа в стандарте XHTML 1.0, и элементы исполняемых инструкций на одном из языков пользовательского программирования OpenSCADA в виде <?dp {procedure} ?>. Результирующий документ формируется путём исполнения процедур и вставки их результата в документ.
Источником значений исполняемых инструкций являются атрибуты виджета этого примитива, а также все механизмы языка пользовательского программирования. Атрибуты могут добавляться пользователем и линковаться на реальные атрибуты параметров или-же являться автономными, значения которых будут формироваться в скрипте виджета. В случае со слинкованными атрибутами могут извлекаться значения из истории, архива.
На рисунке представлен кадр, содержащий пример документа.
В основе любого документа лежит XHTML-шаблон. XHTML-шаблон это тег "body" WEB-страницы, содержащий статику документа в стандарте XHTML 1.0, и элементы исполняемых инструкций на одном из языков пользовательского программирования OpenSCADA в виде <?dp {procedure} ?>. Результирующий документ формируется путём исполнения процедур и вставки их результата в документ.
Источником значений исполняемых инструкций являются атрибуты виджета этого примитива, а также все механизмы языка пользовательского программирования. Атрибуты могут добавляться пользователем и линковаться на реальные атрибуты параметров или-же являться автономными, значения которых будут формироваться в скрипте виджета. В случае со слинкованными атрибутами могут извлекаться значения из истории, архива.
На рисунке представлен кадр, содержащий пример документа.
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.12.
Реализацию на стороне модели данных (UI.VCAEngine) описанно в этом-же документа, раздел 4.6.
С целью учесть это обстоятельство и предоставить возможность централизованно и просто изменять визуальные свойства интерфейса проектом предусматривается реализация менеджера стилей интерфейса визуализации.
Пользователем может быть создано множество стилей, каждый из которых будет хранить цветовые, шрифтовые и другие свойства элементов кадра. Простая смена стиля позволит быстро преобразить интерфейс ВУ, а возможность назначения индивидуальной стиля для пользователя позволит учесть его индивидуальные особенности.
Для реализации этой возможности, при создании кадров необходимо для свойств цвета, шрифта и других установить параметр «Конфигурация» (таблицы во вкладке «Обработка») в значение «Из стиля». А в параметре «Конфигурационный шаблон» указать идентификатор поля стиля. Далее это поле автоматически появится в менеджере стилей и его можно будет там менять. Менеджер стилей доступен на странице конфигурации проекта во вкладке «Стили» (рисунок ниже). На этой вкладке можно создавать новые стили, удалять старые, изменять поля стиля и удалять ненужные.
В целом стили доступны, начиная с уровня проектов. На уровне библиотек виджетов можно только определять поля стилей у виджетов. На уровне проекта при выборе стиля включается работа со стилями, что предполагает доступ к полям стилей вместо непосредственных значений атрибутов. Фактически это означает, что при чтении или записи атрибута виджета указанные операции будут осуществляться с соответствующим полем выбранного стиля.
При запуске проекта на исполнения будет использован установленный в проекте стиль. В последствии пользователь может выбрать стиль из перечня доступных. Выбранный пользователем стиль будет сохранён и использован при следующем запуске проекта.
В виду отсутствия инструмента разработки пользовательских интерфейсов он не нуждается в специфической реализации стилей.
Реализация данного пункта пока отсутствует и будет осуществлена по надобности.
В процессе реализации данного этапа планируется написание дополнительных сценариев интерфейса управления для покрытия задачи организации слабых связей между моделью (VCAEngine) и визуализатором (Vision). На стороне визуализатора (Vision) планируется полный переход на слабые связи с моделью данных VCA.
На данном этапе были созданы недостающие сценарии интерфейса управления и выполнен полный перевод модуля визуализации (Vision) на слабые связи. В результате этой операции удалось достичь значительной унификации визуализатора и повысить его стабильность. Вопрос производительности остался открытым и будет рассмотрен позже.
Реализация выполнена в модуле UI.WebVision и в объёме исполнения основных примитивов и их видов, для проектов разработанных в UI.Vision.
В процессе реализации неоднократно принимались меры по оптимизации, направленные на повышений производительности различных узлов СВУ и взаимодействия между ними. В данном разделе размещаются отчёты, соображения и планы таких мер.
23.08.2007
Основание: Наиболее ответственным, в вопросе производительности, является взаимодействие между моделью данный СВУ и визуализаторами, а также циклы обслуживания интерактивного взаимодействия и обновления. Данный вопрос приобретает ещё большее значение в свете того, что для взаимодействия визуализаторов с моделью данных СВУ используются слабые связи, а именно события основанные на XML-запросах, которые потенциально медленнее прямых связей. Однако возможность последующего перенаправления потока данных взаимодействия на сетевые транспортные протоколы, а также более высокая надёжность такого взаимодействия оправдывают усилия по оптимизации этого взаимодействия.
Условия: Основными объектами оптимизации являются: цикл обновления визуализатора "Vision" и цикл обсчёта сеанса на стороне модели данных СВУ. Замер временных интервалов выполнялся на вычислительной машине Athlon 64 3000+, с пониженной до 800МГц частотой процессора и тестовой странице.
Процесс | Исходное время (мс) | Результирующее время (мс) | Комментарии |
Цикл обновления визуализатора "Vision" | |||
Полный секундный цикл обновления | 43 | 10 | |
Обработка списка открытых окон | 2.3 | 2.2 | Незначительное улучшение за счёт выделение функции запроса перечня открытых окон в сервисные функции быстрого доступа. |
Обновление открытых страниц | 41 | 9 | |
Запрос атрибутов | 24 | 7 | Значительно сократилось за счёт введения общего счетчика модификации виджета и вынос запроса на обновления списка не пользовательских атрибутов в цикл обсчёта сеанса. |
Вызов функции setAttr(), для полученных атрибутов | 19 | 2 | Значительно сократилось за счёт пересмотра и доработки примитива "ElText". |
Цикл обсчета сеанса пользовательского интерфейса модели данных СВУ. | |||
Полный цикл вычисления | 53 | 21 | Значительно сократилось, за счёт пересмотра последовательности вычисления виджета и уменьшения периодичности обновления списка: слинкованых атрибутов и активных дочерних виджетов. |
11.07.2008
Основание: Для оценки потенциальных возможностей по производительности среды визуализации, а также с целью повышения производительности и возможности создания мнемосхем с большим количеством виджетов была проведена оптимизация визуализации виджетов, как в режиме разработки, так и в режиме исполнения.
Условия: Замер временных интервалов выполнялся на вычислительной машине Pentium 4 3200.
Процесс | Исходное время (мс) | Результирующее время (мс) | Комментарии |
160 эллиптических дуг по одной в каждом виджете с радиусами по 20 пискселов и толщиной линии, равной 1 | Загрузка: 497; Инициализация, отрисовка: 355 | Загрузка: 333; Инициализация, отрисовка: 273 | |
160 эллиптических дуг по одной в каждом виджете с радиусами по 20 пискселов и толщиной линии, равной 1 с заливкой в каждой | Загрузка: 492; Инициализация, отрисовка: 1379 | Загрузка: 326; Инициализация, отрисовка: 470 | |
160 эллиптических дуг по одной в каждом виджете с радиусами по 20 пискселов и толщиной линии, равной 1 с заливкой в каждой и с масштабом страницы, на которой лежат эти 160 виджетов, равным 0.5 по X и по Y | Загрузка: 495; Инициализация, отрисовка: 1430 | Загрузка: 334; Инициализация, отрисовка: 452 | Как видно, присутствие масштабных коэффиуиентов, не равных 1, существенно не влияет ни на загрузку, ни на инициализацию и отрисовку. |
160 линий по одной в каждом виджете, длиной 40 и тощиной 10 пикселов | Загрузка: 451; Инициализация, отрисовка: 70 | Загрузка: 315; Инициализация, отрисовка: 5 | |
160 прямоугольников по одном в каждом виджете, длиной 40, шириной 10 и толщиной линии 1 пиксел с заливкой в каждом | Загрузка: 486; Инициализация, отрисовка: 175 | Загрузка: 336; Инициализация, отрисовка: 38 | |
240 линий по 20 в каждом виджете(всего 12 виджетов), толщной 10 и длиной, приблизительно равной 50 пикселов | Загрузка: 58; Инициализация, отрисовка: 53 | Загрузка: 30; Инициализация, отрисовка: 8 | Время и до и после оптимизации значительно меньше в сравнении с одной линией в одном виджете (всего 160 линий) за счёт уменьшения количества виджетов |
240 четырехугольников с заливкой, шириной примерно 15 и длиной примерно 50 пикселов и с толщиной линии в 1 пиксел по 20 в каждом виджете (всего 12 виджетов) | Загрузка: 95; Инициализация, отрисовка: 272 | Загрузка: 42; Инициализация, отрисовка: 93 |