OpenSCADAWiki: Doc/API ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
English (1 Кб) English
Ukrainian (1 Кб) Українська?
 (2 Кб) Страница заморожена и не позиционируется более для перевода, актуальная тут.

API системы OpenSCADA

Автор: Роман Савоченко


Contents

Введение

Данный документ представляет собой описание интерфейса программирования приложения (API) системы OpenSCADA.


OpenSCADA это проект открытой SCADA-системы построенной по модульному принципу. В документе содержится исчерпывающее описание внутренней архитектуры системы OpenSCADA. Кроме информации об архитектуре предоставляются справочные данные по методам и атрибутам объектов системы.


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


Для понимания документа требуется знание концепции Объектно Ориентированного Программирования (ООП) и универсального языка моделирования программного обеспечения (UML), а для возможности изучения исходного кода проекта требуется знание языка программирования C++. Кроме того, в документе содержится упоминание о технологиях: реляционные БД, XML.


1. Внутренняя структура, API системы OpenSCADA.

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


Статическая диаграмма классов (177 Кб)
Рис. 1. Статическая диаграмма классов

2. Общая структура системы. Модульность (TSubSYS, TModule)

Корнем, от которого строится вся система, является объект TSYS. Корень содержит подсистемы (TSubSYS). Подсистемы могут быть: обычными и модульными. Отличие модульных подсистем четко прослеживается на рис. 1. Так, модульные подсистемы обязательно содержат список модульных объектов (TModule), например подсистема архивы TArchiveS содержит модульные объекты TTypeArchivator. В тоже время обычная подсистема таких объектов не содержит. Например, подсистема безопасности TSeсurity (рис.2).


Иерархическая структура системы OpenSCADA (21 Кб)
Рис. 2. Иерархическая структура системы OpenSCADA.

В процессе инициализации корня (TSYS) определяется глобальная переменная SYS. Переменная SYS может использоваться для прямого обращения к корню системы из любого её узла. Инициализация корня выполняется единожды из главной вызывающей функции. После запуска управление захватывается объектом системы до остановки. Корневой объект концентрирует все общесистемные функции системы OpenSCADA.


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


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


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

2.1. Корневой объект системы (TSYS)

Наследует:TCntrNode.

Данные:
Информационные переменные программы:


Способы кодирования символьных последовательностей (enum — TSYS::Code):


Виды представления целого в функциях TSYS::int2str() и TSYS::ll2str() (enum — TSYS::IntView):


Структура задачи OpenSCADA (class — TSYS::STask):


Структура резервной станции (class — TSYS::SStat):


Шаблоны/определения:


Публичные методы:


Публичные атрибуты:


Короткие вызовы глобальных функций в области имён "OSCADA":

2.2. Объект сообщений системы (TMess)

Данные:
Типы (уровни) сообщений (enum — TMess::Type):


Направления сообщений (enum — TMess::Direct):


Структура сообщения (class — TMess::SRec):


Шаблоны:


Публичные методы:

2.3. Объект подсистемы (TSubSYS)

Наследует:TCntrNode.
Наследуется:TArchiveS, TProtocolS, TBDS, TFunctionS, TSeсurity, TModShedul, TTransportS, TUIS, TSpecialS, TControllerS.

Публичные методы:

2.4. Объект модуля (TModule)

Наследует:TCntrNode.
Наследуется:TProtocol, TTypeBD, TTypeArchive, TTypeTransport, TUI, Tspecial, TTypeDAQ.

Данные:
Структура данных идентифицирующая модуль (class — TModule::SAt):


Структура экспортируемых функций (class — TModule::ExpFunc):


Публичные методы:


Защищённые атрибуты:


Защищённые методы:


3. Подсистема "Базы Данных" (TBDS)

Подсистема "Базы Данных" представлена объектом TBDS, который содержит модульные объекты типов БД TTypeBD. Каждый тип базы данных содержит объекты отдельно взятых баз данных данного типа TBD. Каждая БД, в свою очередь, содержит объекты своих таблиц TTable (рис. 3).


Иерархическая структура подсистемы БД (28 Кб)
Рис. 3. Иерархическая структура подсистемы БД.

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


Являясь модульным объектом, тип БД (TTypeBD) содержит доступ к реализации механизма той или иной БД. Доступ производится посредством открытых БД модуля отдельно взятого типа БД. Открываемые/регистрируемые БД описываются в таблице открываемых БД или в конфигурационном файле. Существует так называемая рабочая БД, которая открывается всегда и указывается в конфигурационном файле. БД, поддерживающие SQL-запросы, могут предоставлять доступ, основанный на прямых SQL-запросах.


В процессе использования компоненты системы OpenSCADA открывают таблицы (TTable) в доступных БД и работают с ними.

3.1. Объект подсистемы "Базы Данных" (TBDS)

Наследует:TSubSYS, TElem.

Данные:
Флаги запросов к системной таблице (enum – TDBS::ReqGen):


Публичные методы:

3.2. Модульный объект типов баз данных (TTypeBD)

Наследует:TModule.
Наследуется:Корневыми объектами модулей подсистемы "БД".

Публичные методы:

3.3. Объект базы данных (TBD)

Наследует:TCntrNode, TConfig.
Наследуется:Объектами баз данных модулей подсистемы "БД".

Публичные методы:


Защищённые методы:

3.4. Объект таблицы (TTable)

Наследует:TCntrNode.
Наследуется:Объектами таблиц модулей подсистемы "БД".

Публичные методы:


4. Подсистема "Сбор данных" (TDAQS)

Подсистема "Сбор данных" представлена объектом TDAQS, который содержит модульные объекты типов источников данных TTypeDAQ и объекты библиотек шаблонов параметров подсистемы "Сбор данных" TPrmTmplLib. Объект типов источников данных содержит объекты контроллеров TController и объекты типов параметров TTypeParam. Объекты типов параметров предоставляются модулем контроллера и содержат структуру БД отдельных типов параметров (аналоговые, дискретные ...). Объекты контроллеров содержат объекты параметров TParamContr. Каждый параметр ассоциируется с одним из типов параметров. Для хранения атрибутов параметр наследуется от объекта значений TValue, который и содержит значения атрибутов TVal. Библиотека шаблонов параметров данной подсистемы содержит объекты шаблонов TPrmTmpl. Пример описанной иерархической структуры приведён на рис. 4.


Иерархическая структура подсистемы сбора данных (25 Кб)
Рис. 4. Иерархическая структура подсистемы сбора данных.

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


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


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


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


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

4.1. Объект подсистемы "Сбор данных" (TDAQS)

Наследует:TSubSYS.

Публичные методы:

4.2. Модульный объект типа контроллера (TTypeDAQ)

Наследует:TModule, TElem.
Наследуется:Корневыми объектами модулей подсистемы "Сбор данных".

Публичные методы:


Защищённые методы:

4.3. Объект контроллера (TController)

Наследует:TCntrNode, TConfig.
Наследуется:Объектами контроллеров модулей подсистемы "Сбор данных".

Данные:
Режимы резервирования (enum TController::Redundant):

Командо-специфичное

Публичные методы:


Защищённые атрибуты:


Защищённые методы:

4.4. Объект типа параметров (TTypeParam)

Наследует:TElem.

Публичные методы:


Публичные атрибуты:

4.5. Объект параметра физического уровня (TParamContr)

Наследует: TConfig, TValue.
Наследуется: Объектами параметров модулей подсистемы "Сбор данных".

Публичные методы:


Защищённые методы:

4.6. Объект значения (TValue)

Наследует:TCntrNode, TValElem.
Наследуется:TParamContr.

Публичные методы:


Защищённые методы:

4.7. Объект атрибута (TVal).

Наследует:TCntrNode.

Данные:
Дополнительные флаги к объекту TFld (enum TVal::AttrFlag):


Публичные методы:

4.8. Объект библиотеки шаблонов параметров подсистемы "DAQ" (TPrmTmplLib)

Наследует:TCntrNode, TConfig.

Публичные методы:

4.9. Объект шаблона параметров подсистемы "DAQ" (TPrmTempl)

Наследует:TFunction, TConfig.

Данные:
Дополнительные флаги к объекту атрибута функции IO (enum TPrmTempl::IOTmplFlgs):


Публичные методы:


5. Подсистема "Архивы" (TArchiveS)

Подсистема "Архивы" представлена объектом TArchiveS, который содержит на уровне подсистемы модульные объекты типов архиваторов TTypeArchivator. Каждый объект типа архиватора содержит объекты архиваторов сообщений TMArchivator и архиваторов значений TVArchivator. Кроме этого объект подсистемы архивы содержит методы архива сообщений и объекты архивов значений TVArchive. Объект архива значений TVArchive содержит буфер значений путём наследования объекта буфера TValBuf. Для связи архива значений с архиваторами предназначен объект элемента значения TVArchEl. Этот объект содержится в архиваторе и на него ссылается архив. Структура подсистемы "Архивы" представлена на рис. 5.


Иерархическая структура подсистемы архивов (15 Кб)
Рис. 5. Иерархическая структура подсистемы архивов.

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


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


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


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


Объект архиватора сообщений (TMArchivator) содержит конкретную реализацию хранилища сообщений. В общем для архиваторов сообщений предоставляется интерфейс доступа к реализации механизма архивирования в модулях.


Объект архиватора значений (TVArchivator) содержит конкретную реализацию хранилища значений. В общем для архиваторов значений предоставляется интерфейс доступа к реализации механизма архивирования и назначение архивов значений на обслуживание архиватором.


Объект элемента архива TVArchEl связывает объекты архивов с архиваторами. Используется для доступа к архиваторам из архива, а также к архивам из архиватора, т.е. для перекрёстных вызовов.

5.1. Объект подсистемы "Архивы" (TArchiveS)

Наследует:SubSYS.

Публичные методы:


Публичные атрибуты:

5.2. Объект архива значений (TVArchive)

Наследует:TCntrNode, TValBuf, TConfig

Данные:
Режим сбора данных/источник (struct — TVArchive::SrcMode):


Публичные методы:

5.3. Объект буфера значений (TValBuf)

Наследуется:TVArchive

Публичные методы:


Защищённые методы:

5.4. Модульный объект типа архиватора (TTypeArchivator)

Наследует:TModule.
Наследуется:Корневыми объектами модулей подсистемы "Архивы".

Публичные методы:


Защищённые методы:

5.5. Объект архиватора сообщений (TMArchivator)

Наследует:TCntrNode, TConfig
Наследуется:Объектами архиваторов сообщений модулей подсистемы "Архивы".

Публичные методы:


Защищённые атрибуты:


Защищённые методы:

5.6. Объект архиватора значений (TVArchivator)

Наследует:TCntrNode, TConfig
Наследуется:Объектами архиваторов значений модулей подсистемы "Архивы".

Публичные методы:


Защищённые методы:


Защищённые атрибуты:

5.7. Объект элемента архива в архиваторе (TVArchEl)

Наследуется:Объектами архиваторов значений модулей подсистемы "Архивы".

Публичные методы:


Публичные атрибуты:


Защищённые методы:


6. Подсистема "Транспорты" (TTransportS)

Подсистема "Транспорты" представлена объектом TTransportS, который содержит на уровне подсистемы модульные объекты типов транспортов TTypeTransport. Каждый тип транспорта содержит объекты входящих TTransportIn и исходящих TTransportOut транспортов. Общая структура подсистемы приведена на рис. 6.


Иерархическая структура подсистемы транспортов (14 Кб)
Рис. 6. Слоистая структура подсистемы транспортов.

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


Объект входящего транспорта TTransportIn предоставляет интерфейс к реализации модульного метода входящего транспорта.


Объект исходящего транспорта TTransportOut предоставляет интерфейс к реализации модульного метода исходящего транспорта.

6.1. Объект подсистемы "Транспорты" (TTransportS)

Наследует:TSubSYS.

Данные:
Режимы внешних хостов (enum — ExtHost::Mode):


Структура внешних OpenSCADA хостов/станций (class TTransportS::ExtHost):


Публичные методы:

6.2. Модульный объект типа транспортов (TTypeTransport)

Наследует:TModule.
Наследуется:Корневыми объектами модулей подсистемы "Транспорты".

Публичные методы:


Защищённые методы:

6.3. Объект входящих транспортов (TTransportIn)

Наследует:TCntrNode, TConfig.
Наследуется:Объектами входящих транспортов модулей подсистемы "Транспорты".

Публичные методы:


Защищённые методы:


Защищённые атрибуты:

6.4. Объект исходящих транспортов (TTransportOut)

Наследует:TCntrNode, TConfig.
Наследуется:Объектами исходящих транспортов модулей подсистемы "Транспорты".

Публичные методы:


Защищённые атрибуты:


7. Подсистема "Протоколы коммуникационных интерфейсов" (TProtocolS)

Подсистема "Протоколы коммуникационных интерфейсов" представлена объектом TProtocolS, который содержит на уровне подсистемы модульные объекты отдельных протоколов TProtocol. Каждый протокол содержит объекты открытых сеансов входящих протоколов TProtocolIn.


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

7.1. Объект подсистемы "Протоколы коммуникационных интерфейсов" (TProtocolS)

Наследует:TSubSYS.

Публичные методы:

7.2. Модульный объект протокола (TProtocol)

Наследует:TModule.
Наследуется:Корневыми объектами модулей подсистемы "Протоколы".

Публичные методы:

7.3. Объект сеанса входящего протокола (TProtocolIn)

Наследует:TCntrNode.
Наследуется:Объектами сеанса входящего протокола модулей подсистемы "Протоколы".

Публичные методы:


8. Подсистема "Пользовательские интерфейсы" (TUIS)

Подсистема "Пользовательские интерфейсы" представлена объектом TUIS, который содержит на уровне подсистемы модульные объекты пользовательских интерфейсов TUI.

8.1. Объект подсистемы "Пользовательские интерфейсы" (TUIS)

Наследует: TSubSYS.

Данные:
Параметры запроса (enum — GetOpts):


Публичные методы:

8.2. Модульный объект пользовательского интерфейса (TUI)

Наследует: TModule.
Наследуется: Корневыми объектами модулей подсистемы "Пользовательские интерфейсы".

Защищённые атрибуты:


9. Подсистема "Специальные" (TSpecialS)

Подсистема "Специальные" представлена объектом TSpecialS, который содержит на уровне подсистемы модульные объекты специальных TSpecial.

9.1. Объект подсистемы "Специальные" (TSpecialS)

Наследует:TSubSYS.

Публичные методы:

9.2. Модульный объект специальных (TSpecial)

Наследует:TModule.
Наследуется:Корневыми объектами модулей подсистемы "Специальные".

Защищённые атрибуты:


10. Подсистема "Безопасность" (TSeсurity)

Подсистема безопасности представлена объектом который содержит объекты групп TGroup и пользователей TUser.


Объект пользователя TUser содержит пользовательскую информацию и выполняет проверку аутентичности пользователя в соответствии с указанным паролем.


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

10.1. Объект подсистемы "Безопасность" (TSeсurity)

Наследует:TSubSYS.

Публичные данные:


Публичные методы:

10.2. Объект пользователя (TUser)

Наследует:TCntrNode, TConfig.

Публичные методы:

10.3. Объект группы пользователей (TGroup)

Наследует:TCntrNode, TConfig.

Публичные методы:


11. Подсистема "Управление модулями" (TModSchedul)

Подсистема "Управление модулями" представлена объектом TModSchedul.


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

11.1. Объект подсистемы "Управление модулями" (TModSchedul)

Наследует:TSubSYS.

Данные:
Структура информации о разделяемой библиотеке (struct – TModSchedul::SHD):


Публичные методы:


12. Компоненты объектной модели системы OpenSCADA

Объектная модель системы OpenSCADA строится на основе объекта функции TFunction, параметрах функции IO и кадре значений функции TValFunc. В последствии объекты функции включаются в объектное дерево, формируя объектную модель системы. Использование функций объектной модели производится путём связывания кадра значений TValFunc с функцией.


Идея в целом доступно представленна на рис. 7.


Основа среды программирования системы OpenSCADA. (71 Кб)
Рис. 7. Основа среды программирования системы OpenSCADA.

Объект функции (TFunction) предоставляет интерфейс для формирования параметров функции и алгоритма вычисления в объекте, наследующем его.


Объект параметра функции (IO) содержит конфигурацию отдельно взятого параметра.


Объект кадра значений (TValFunc) содержит значения в соответствии со структурой связанной функции. При исполнении алгоритма ассоциированой функции используются значения этого объекта.

12.1. Объект функции (TFunction)

Наследует:TCntrNode
Наследуется:Модулями и узлами систем, содержащими функции для публикации в объектную модель системы.

Публичные методы:


Защищённые атрибуты:

12.2. Объект параметра функции (IO)


Данные:
Типы параметра (enum — IO::Type):


Флаги параметра (enum — IO::IOFlgs):


Публичные методы:

12.3. Объект значения функции (TValFunc).

Публичные методы:


Публичные атрибуты:


13. Данные в системе OpenSCADA и их хранение в БД (TConfig)

Хранение данных в системе основано на объектах TConfig и TElem. Эти объекты хранят структуру и значения полей БД, что позволяет выполнять прямую загрузку и сохранение конфигурации через подсистему "БД". Для специализированного хранения данных разных типов предусмотрен объект TVariant.


Объект TElem содержит структуру записи БД. Структура записи содержит исчерпывающую информацию об элементах, их типах, размерах и остальных параметрах. Информации в данной структуре достаточно для создания, контроля и управления реальной структурой БД. Элементарной единицей записи является ячейка Tfld.


Объект TСonfig является наследником от TElem и содержит реальные значения элементов. TConfig используется в качестве параметра в функциях манипуляции с записями таблиц в подсистеме "БД". Элементарной единицей записи является ячейка TCfg.


Для предоставления возможности предупреждения хранилища данных о смене структуры предусмотрен объект TValElem, от которого наследуется хранилище TConfig и список которых содержится в структуре TElem.

13.1. Объект данных (TConfig)

Наследует:TValElem
Наследуется:TParamContr, TController, TMArchivator, TPrmTempl, TPrmTmplLib, TUser, TGroup, TTransportIn, TTransportOut, TBD, TVArchive, TVArchivator, а также модульные объекты хранящие свои данные в БД.

Публичные методы:


Защищённые методы:

13.2. Ячейка данных (TCfg)

Наследует:TVariant

Данные:
Дополнительные флаги к TFld (enum — TCfg::AttrFlg):


Флаги запросов (enum — ReqFlg):


Публичные методы:

13.3. Объект структуры данных (TElem)

Наследуется:TTypeParam, TControllerS, TTypeDAQ, а также модульными объектами, совмещающими функции хранения структуры.

Публичные методы:

13.4. Ячейка структуры данных (TFld)

Данные:
Тип ячейки (enum – TFld::Type):


Флаги ячейки (enum — TFld::AttrFlg):


Публичные методы:

13.5. Объект упреждения про смену структуры (TValElem)

Наследуется:TValue, TConfig.

Защищённые методы:

13.6. Ячейка данных (TVariant)

Данные:
Значения ошибки для различных типов данных (define):


Типы данных (enum — TVariant::Type):


Публичные методы:

13.7. Пользовательский объект (TVarObj)

Наследуется:TArrayObj

Публичные методы:


14. Интерфейс управления системой и динамическое дерево объектов системы (TCntrNode)

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


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


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


Интерфейс управления системой реализован посредством составляющих:


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


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


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


Общий интерфейс управления строится из отдельных узлов динамического дерева. Иерархическое наследование от объекта TCntrNode позволяет реализовывать многоуровневое дополнение конфигурации интерфейса управления. Общий вид динамического дерева узлов представлен на рис. 8.


Пример динамического дерева узлов системы OpenSCADA. (120 Кб)
Рис. 8. Пример динамического дерева узлов системы OpenSCADA.

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


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

14.1. Синтаксис запроса и ответа интерфейса управления

Весь обмен с интерфейсом управления производится посредством языка XML. При этом внутренний обмен выполняется разобранной структурой языка XML (DOM), а внешний — посредством преобразования в поток символов сплошного XML-файла и обратно.


Запрос выполняется посредством отправки одного контейнера с некоторыми параметрами в атрибутах. Результат помещается в полученный контейнер с изменением некоторых атрибутов корневого контейнера. В общем виде контейнер запроса можно записать следующим образом:
<cmd path="/TreePath" user="user" force="1"/>
Где:

cmd — команда запроса;
path — путь к узлу или ветви узла;
user — пользователь системы от имени которого направлен запрос;
force — признак выполнить запрос без предупреждения.

В подтверждение результата запроса устанавливается атрибут результата rez в значения: 0-запрос прошел, 1-предупреждение (с возможностью выполнения), 2-ошибка. В случае ошибки и предупреждения сообщения записываются в текст контейнера и атрибут mcat (категория сообщения): <cmd path="/TreePath" user="user" force="1" rez="2" mcat="sub_DAQ/mod_BlockCalc>Невозможно удалить узел</cmd>.


Группирующий запрос "CntrReqs" обрабатываются на уровне API узла и не требуют отдельной обработки в пользовательском коде. Фактически в тег "CntrReqs" могут помещаться любые другие запросы с возможностью иерархической группировки путём включения внутренних тегов "CntrReqs". Единственным атрибутом этого тега является атрибут path, который указывает путь к узлу и является основой для внутренних запросов.


<CntrReqs path="/sub_DAQ/cntr_gate">
  <get path="/%2fprm%2fcfg%2fNAME"/>
  <get path="/%2fprm%2fcfg%2fDESCR"/>
  <list path="/%2fserv%2fattr"/>
</CntrReqs>

14.2. Тег информационной структуры для описания групп дочерних веток страницы

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

00 — доступ вообще отсутствует;
04 — присутствует доступ только на чтение;
02 — присутствует доступ только на запись, обычно такое значение не имеет смысла поскольку доступ на запись подразумевает и доступ на чтение;
06 — присутствует доступ и на чтение, и на запись.


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

14.3. Теги описания информационной структуры интерфейса управления

Информационные теги для языка XML составляют алфавит формирования описания конфигурационных диалогов. Команда запроса информационной части имеет вид: <info path="/TreePath" user="user"/>


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

14.3.1. Тег области "area"

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

<area id='base' dscr='Base information'>
  <fld id='host' dscr='Host name' tp='str'/>
  <fld id='user' dscr='Operated user' tp='str'/>
  <fld id='sys' dscr='Station system' tp='str'/>
  <area id='other' dscr='Other options'>
     <fld id='val' dscr='Value' tp='real'/>
  </area>
</area>

14.3.2. Теги данных

Теги, описывающие данные, сведены в таблице 1.


Таблица 1. Теги, описывающие данные

ТегОписание
<fld>Простейшие данные строкового, целого, вещественного и логического типов.
<list>Списки с данными строкового, целого, вещественного и логического типов.
<table>Таблицы с данными в ячейках строкового, целого, вещественного и логического типов.
<img>Изображения.

a) Тег "fld"

<fld id='host' dscr='Host name' tp='str'/>
<fld id='user' dscr='Operated user' tp='str'/>
<fld id='sys' dscr='Station system' tp='str'/>


К тегу возможен доступ как на "чтение", так и на "запись", следовательно элемент триады доступа может принимать значения:

00 — доступ вообще отсутствует;
04 — присутствует доступ только на чтение;
02 — присутствует доступ только на запись, обычно такое значение не имеет смысла поскольку доступ на запись подразумевает и доступ на чтение;
06 — присутствует доступ и на чтение и на запись.

Тип элемента, описываемого тегом "fld", указывается атрибутом tp (таблица 2).


Таблица 2. Значения атрибута tp тега "fld".

Тег tpОписание
strСтроковый тип.
<fld id='host' dscr='Host name' tp='str'/>
decЦелое число в десятичном представлении.
<fld id='debug' dscr='Debug level' tp='dec'/>
octЦелое число в восьмеричном представлении.
<fld id='cr_file_perm' dscr='Make files permissions(default 0644)' tp='oct' len='3'/>
hexЦелое число в шестнадцатеричном представлении.
realВещественное число.
boolЛогический признак ("false"|"true").
<fld id='log_sysl' dscr='Direct messages to syslog' tp='bool'/>
timeВремя в секундах (от 01/01/1970).
<fld id='v_beg' dscr='Start time' tp='time'/>

Таблица 3. Действия над элементом, описанным тегом "fld".

ОперацияДействие
ОпросЗапрос: команда "get": <get path="/fld_teg" user="user"/>.
Результат: подтверждение со значением в тексте тега или сообщение об ошибке.
МодификацияЗапрос: команда "set": <set path="/fld_teg" user="user">value</set>
Результат: подтверждение или сообщение об ошибке.
Запрос правил подсветки синтаксиса, для текстовых полей (определён атрибут "rows").Запрос: команда "SnthHgl": <SnthHgl path="/fld_teg" user="user"/>
Результат: подтверждение со списком правил подсветки синтаксиса:
<rule expr="\b(if|else|for|while|in|using|new|var|break|continue|return|Array|Object)\b" color="darkblue" font_weight="1"/>
<rule expr="(\?|\:)" color="darkblue" font_weight="1"/>
<rule expr="(\b0[xX][0-9a-fA-F]*\b|\b[+-]?[0-9]*\.?[0-9]+[eE]?[-+]?[0-9]*\b|\btrue\b|\bfalse\b)" color="blue"/>
<rule expr="&quot;[^&quot;]*&quot;" color="darkgreen"/>
<rule expr="//[^\n]*" color="gray" font_italic="1"/>
<blk beg="/\\*" end="\\*/" color="gray" font_italic="1"/>

b) Тег "list"

<list id='mod_auto' dscr='List of shared libs(modules)' tp='str' dest='file'/>


К тегу возможен доступ как на "чтение", так и на "запись"(модификацию), следовательно элемент триады доступа может принимать значения:

00 — доступ вообще отсутствует;
04 — присутствует доступ только на чтение;
02 — присутствует доступ только на запись, обычно такое значение не имеет смысла поскольку доступ на запись подразумевает и доступ на чтение;
06 — присутствует доступ и на чтение и на запись.

Тип элементов в списке указывается атрибутом tp. Значения атрибута tp приведены в таблице 1.


Таблица 4. Действия над списком.

ОперацияДействие
Опрос

Запрос: команда "get": <get path="/fld_teg" user="user"/>
Результат: подтверждение с результатом в тексте тега или сообщение об ошибке. Результат формируется в виде:

<get path="/fld_teg" user="user" rez="0">
<el id='0'>./MODULES/arh_base.o</el>
<el id='1'>./MODULES/cntr_sys.o</el>
</get>
Добавление строки

Запрос: команда "add": <add path="/fld_teg" user="user" id="tst">Test</add>

Читается, как добавить строку с идентификатором "tst" и значением "Test". Если список не индексированный, то атрибут id отсутствует.

Результат: подтверждение или сообщение об ошибке.

Вставка строки

Запрос: команда "ins": <ins path="/fld_teg" user="user" pos="3" p_id="tst1" id="tst">Test</ins>

Читается, как вставить строку с идентификатором "tst" и значением "Test" в позицию 3 со строкой "tst1". В случае индексного списка атрибут p_id содержит идентификатор, иначе — текст строки. Если список не индексирован, то атрибут id отсутствует.

Результат: подтверждение или сообщение об ошибке.

Удаление строки

Запрос: команда "del": <del path="/fld_teg" user="user" pos='3' id='tst'>Test</del>

Читается, как удалить строку с идентификатором "tst" и значением "Test" в позиции 3. Если список не индексирован, то атрибут id отсутствует.

Результат: подтверждение или сообщение об ошибке.

Изменение строки

Запрос: команда "edit": <edit path="/fld_teg" user="user" pos='3' p_id='tst1' id='tst' >Test</edit>

Читается, как заменить строку в позиции 3 с идентификатором "tst1" на строку с идентификатором "tst" и значением "Test". В случае индексированного списка атрибут p_id содержит идентификатор, иначе — текст строки. Если список не индексирован, то атрибут id отсутствует.

Результат: подтверждение или сообщение об ошибке.

Перемещение строки

Запрос: команда "move": <move path="/fld_teg" user="user" pos='3' to='5'/>

Читается, как переместить строку с позиции 3 в позицию 5.

Результат: подтверждение или сообщение об ошибке.

c) Тег "table"

<table id='a_mess' key='0' col_lst="0;1;2">
  <list id='0' dscr='Id' acs='4' tp='str'/>
  <list id='1' dscr='Name' acs='4' tp='str'/>
  <list id='2' dscr='Type' acs='4' tp='str'/>
  <list id='3' dscr='Hide' acs='4' tp='bool'/>
</table>


К тегу таблицы и колонкам отдельно возможен доступ как на "чтение", так и на "запись"(модификацию), следовательно элемент триады доступа может принимать значения:

00 — доступ вообще отсутствует;
04 — присутствует доступ только на чтение;
02 — присутствует доступ только на запись, обычно такое значение не имеет смысла поскольку доступ на запись подразумевает и доступ на чтение;
06 — присутствует доступ и на чтение и на запись.

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


Таблица 5. Действия над таблицей.

ОперацияДействие
Опрос

Запрос: команда "get": <get path="/fld_teg" user="user" cols="0;2" rows="100;1000"/>

Читается, как получить колонки 0-2 и строки в них с 100 по 1000 таблицы.

Результат: Подтверждение с данными таблицы или сообщение об ошибке. Результат формируется в виде:

<get path="/fld_teg" user="user" cols="0;2" rows="100;1000" rez="0">
<list id='0' tp='str'>
<el id='100'>Sat Feb 21 18:04:16 2004</el>

</list>
<list id='1' tp='str'>

<el id='100'>SYS</el>

</list>
<list id='2' tp='str'>

<el id='100'>*:(TSYS)Broken PIPE signal allow!</el>
</list>
</get>
Добавление строкиЗапрос: команда "add": <add path="/fld_teg" user="user"/>
Результат: подтверждение или сообщение об ошибке.
Вставка строки

Запрос: команда "ins": <ins path="/fld_teg" user="user" row='3'/>

Читается, как вставить строку в позицию 3. Команда не работает при установленном атрибуте key!

Результат: подтверждение или сообщение об ошибке.

Удаление строки


Запрос: команда "del": <del path="/fld_teg" user="user" row='3'/> или <del path="/fld_teg" user="user" key_id='Test'/> для ключевого режима

Читается, как удалить строку в позиции 3 или строку в позиции, где значение колонки id равно 'Test'.

Результат: подтверждение или сообщение об ошибке.

Перемещение строки

Запрос: команда "move": <move path="/fld_teg" user="user" row='3' to='5'/>

Читается, как переместить строку с позиции 3 в позицию 5. Данная команда не работает при установленном атрибуте key!

Результат: подтверждение или сообщение об ошибке.

Изменить ячейку

Запрос: команда "set": <set path="/fld_teg" user="user" row='3' col='id'>Test</set> или <set path="/fld_teg" user="user" key_id='Test' col='id'>Test1</set> для ключевого режима

Читается как — установить значение ячейки в строке 3 и колонке 'id' в "Test" или установка колонки с именем 'id' строки в позиции где значение колонки id равно 'Test' в значение 'Test1'. Практически данная команда переименовывает ключевой элемент указанной строки.

Результат: подтверждение или сообщение об ошибке.

d) Тег "img"

<img id='ico' descr='Иконка страницы'/>


К тегу возможен доступ как на "чтение", так и на "запись", следовательно элемент триады доступа может принимать значения:

00 — доступ вообще отсутствует;
04 — присутствует доступ только на чтение;
02 — присутствует доступ только на запись, обычно такое значение не имеет смысла поскольку доступ на запись подразумевает и доступ на чтение;
06 — присутствует доступ и на чтение и на запись.

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


Поддерживаются команды запросов:

Результатом является подтверждение с данными изображения или сообщение об ошибке.
Результатом является подтверждение или сообщение об ошибке.
e) Команды с параметрами. Тег "comm"

<comm id='add'>
  <fld id='tm' tp='time'/>
  <fld id='cat' tp='str'/>
  <fld id='lvl' tp='dec' min='0' max='7'/>
  <fld id='mess' tp='str'/>
</comm>


К тегу возможен доступ как на "чтение" или видимость+обслуживание запросов, так и на модификацию или выполнение команды, следовательно элемент триады доступа может принимать значение 00, если доступ отсутствует вообще; 04, если команду можно увидеть; и 06, если команду можно инициировать.


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


Поддерживаются команды запросов:

<set path="/fld_teg" user="user"/>
  <fld id='tm'>1023456244</fld>
  <fld id='cat'>*</fld>
  <fld id='lvl'>2</fld>
  <fld id='mess'>Test mess</fld>
</set>

<get path="/fld_teg" user="user" tp="lnk"/>"


Результатом является подтверждение или сообщение об ошибке.

f) Ветки (дочерние узлы)

<list id='k_br' dscr='Kernel branches' tp='br'/>


Ветки описываются обычным списком "list" со специальными атрибутами tp='br'. Методика запроса и модификации веток полностью совпадает с методикой работы со списком "list".


14.4 Иерархические зависимости информационных элементов языка управления

Пример страницы узла языка управления:

<oscada_cntr>
  <area id='a_gen' dscr='Generic control'>
    <fld id='config' dscr='Config file' tp='str' dest='file'/>
    <fld id='cr_file_perm' dscr='Files' tp='oct' len='3'/>
    <fld id='cr_dir_perm' dscr='Directories' tp='oct' len='3'/>
    <comm id='upd_opt' dscr='Update options(from config)'/>
    <comm id='quit' dscr='Quit'/>
  </area>
  <area id='a_kern' dscr='Kernels'>
    <list id='k_br' dscr='Kernels' tp='br'/>
  </area>
</oscada_cntr>


Таблица 6. Иерархические зависимости информационных элементов языка:

ТегОписаниеАтрибутыСодержимое
oscada_cntrКорневой элемент страницы. Является единственным и служит для идентификации принадлежности к языку интерфейса управления.id — идентификатор;
dscr — описание.
area, img, branches
branchesКонтейнер групп дочерних веток узла.id — идентификатор контейнера. Равен: br.grp
grpГруппа дочерних узлов.id — префикс группы дочерних узлов в системе;
dscr — описание группы веток;
acs — опции доступа.
areaГруппировка стандартных тегов.id — идентификатор;
dscr — описание;
acs — опции доступа.
area, fld, list, table, comm, img
commКоманды узлу.id — идентификатор;
dscr — описание;
help — помощь по команде;
tp — тип команды (lnk — ссылка);
acs — опции доступа.
fld
fldОписание данных стандартных типов.

id — идентификатор;
dscr — описание;
help — помощь;
acs — опции доступа.
tp — тип элемента:

str(len, dest, cols, rows(SnthHgl)) — строковый элемент;
dec(len, max, min, dest) — целое число в десятичном представлении;
oct(len, max, min, dest) — целое число в восьмеричном представлении;
hex(len, max, min, dest) — целое число в шестнадцатеричном;
real(len, max, min, dest) — вещественное число;
bool — логический признак;
time — время/дата в секундах (от 01/01/1970).

Связные:
len — длина значения (симв.);
min — минимум значения;
max — максимум значения;
cols — количество колонок;
rows — количество строк;
dest — способ ввода:

data — источник бинарных данных (base64).
select(select) — выборный тип;
sel_ed(select) — выборный тип с возможностью редактирования.
select — путь к скрытому списку;
sel_list — статический список (разделитель ';');
sel_id — статический список идентификаторов (разделитель ';').
listСписок данных стандартных типов.

id — идентификатор;
dscr — описание;
help — помощь по списку;
acs — опции доступа.
tp — как в fld кроме:

br(br_pref) — дочерние узлы.

idm — индексированный список (0|1);
s_com — способы модификации списка [add][,ins][,edit][,del]:

add — добавлять строки;
ins — вставлять строки;
edit — модифицировать строки;
del — удалять строки.
Связные:
br_pref — префикс дочерних узлов;
dest — как в fld.
tableТаблица данных стандартных типов.id — идентификатор;
dscr — описание;
help — помощь по таблице;
acs — опции доступа;
key — ключевые колонки (key="id,name,per");
cols — перечень колонок в атрибуте запроса;
rows — диапазон строк в атрибуте запроса;
s_com — способы модификации таблицы [add][,del][,ins][,move]:
add — добавлять строки;
ins — вставлять строки;
del — удалять строки;
move — перемещать строки.
list
imgИзображение.id — идентификатор;
dscr — описание;
help — помощь по изображению;
acs — опции доступа;
h_sz — горизонтальное ограничение;
v_sz — вертикальное ограничение.

14.5. Объект узла динамического дерева (TCntrNode)

Наследуется:Всеми динамическими и управляемыми объектами прямо или через потомков.

Данные:
Именованные права доступа к элементам управления (define):


Флаги динамического узла (enum TCntrNode::Flag):


Флаги режимов включения/отключения узла (enum TCntrNode::Flag):


Флаги модификации узла (enum TCntrNode::ModifFlag):


Публичные методы:

static XMLNode *ctrMkNode( const char *n_nd, XMLNode *nd, int pos, const char *req, const string &dscr int perm = 0777, const char *user = "root", const char *grp = "root", int n_attr = 0, ... );
static XMLNode *ctrMkNode2( const char *n_nd, XMLNode *nd, int pos, const char *req, const string &dscr, int perm = 0777, const char *user = "root", const char *grp = "root", ... );
— Добавление элемента управления на страницу. Возможно указание множества дополнительных атрибутов в количестве n_attr в виде: "{атрибут1},{значений1},{атрибут2},{значений2},..." или по нулевому указателю в конце последовательности пар.

Защищённые методы:


15. XML в системе OpenSCADA (XMLNode)

XML в системе OpenSACDA представлен объектом XML-тега — XMLNode.

15.1. XML-тег (XMLNode)

Данные:
Опции загрузки XML-файла (enum — XMLNode::LoadFlgs):


Опции функции генерации XML-файла (enum — XMLNode::SaveView):


Публичные методы:


16. Ресурсы в системе OpenSCADA (Res, ResAlloc, ResMtx, MtxAlloc, AutoHD)

Большинство узлов и подсистем системы OpenSCADA являются динамическими, т.е. допускают создание/удаление/конфигурацию в процессе функционирования системы. Учитывая многопоточность системы, данная функциональность накладывает жесткие требования к синхронизации потоков. Для синхронизации в системе используются ресурсы, функции которых локализованы в объектах "Res" и "ResAlloc". Объект "Res" предоставляет хранилище ресурса, предусматривающего функции захвата/освобождения на чтение и запись. В объекте "ResAlloc" реализованы функции автоматического освобождения ресурса. Автоматический ресурс подразумевает создание локального объекта ресурса с автоматическим его освобождением при разрушении (в деструкторе). Использование автоматических ресурсов значительно упрощает работу с ресурсами при использовании исключений.


Любой динамический объект системы наследуется от объекта "TCntrNode", который содержит механизм подключения через шаблон "AutoHD". Основной функцией шаблона является хранение ссылки на объект и захват ресурса, исключающего удаление объекта на момент использования. Шаблон поддерживает копирование ресурса и автоматическое его освобождение в случае разрушения объекта шаблона. Для наглядности доступа к объектам порождённым от "TCntrNode" шаблон "AutoHD" поддерживает приведение типов, основанное на динамическом приведении.

16.1. Объект R/W ресурса (ResRW)

Публичные методы:

16.2. Объект автоматического освобождения R/W ресурса (ResAlloc)

Публичные методы:

16.3. Шаблон (AutoHD)

Публичные методы:

16.4. Объект захвата ресурсов, мютексом (ResMtx)

Публичные методы:

16.5. Объект строки с доступом, разделённым ресурсом (ResString)

Публичные методы:

16.6. Объект условной переменной, по мютексу (CondVar)

Публичные методы:

16.7. Объект автоматического освобождения POSIX мютекса (MtxAlloc)

Публичные методы:

16.8. Объект строки с доступом, разделённым глобальным ресурсом(мютексом) данных (MtxString)

Публичные методы:


17. Организация и структура базы данных компонентов системы

Узлы и подсистемы системы OpenSCADA могут иметь собственные таблицы в БД для хранения своих данных. При этом структура таблиц индивидуальна и определяется объектом "TConfig". Узлы и подсистемы должны создавать и конфигурировать объект "TConfig" под свои требования.

17.1. Системные таблицы

Система OpenSCADA имеет две системные таблицы BD и SYS. Таблица BD содержит записи зарегистрированных БД, а таблица SYS содержит данные общесистемных параметров.


Таблица 7. Cтруктура таблицы общесистемных параметров (SYS).

Пользователь <user>Идентификатор параметра <id>Значение параметра <val>
root/DemoStation/MessLev0
user/DemoStation/Workdir/mnt/home/roman/work/OScadaD/share/OpenScada
user/DemoStation/UI/QTStarter/StartModQTCfg

Таблица 8. Cтруктура таблицы зарегистрированных БД.

Идентификатор <ID>Тип БД <TYPE>Имя <NAME>Описание <DESCR>Адрес <ADDR>Кодировка содержимого БД <CODEPAGE>Включать <EN>
LibBDMySQLБиблиотека функций server.diya.org;roman;123456;oscadaUserLibsKOI8-U1
AnastModelSQLiteМодель АГЛКС ./DATA/AGLKSModel.dbUTF81
GenDBMySQLОсновная БД server.diya.org;roman;123456;oscadaDemoStKOI8-U1

17.2. Таблицы подсистемы "Сбор данных"

Контроллеры (источники данных) подсистемы "Сбор данных" хранятся в таблицах своих подсистем с именем DQA_{ModName}. Структуры этих таблиц могут значительно отличаться, однако у всех них присутствуют обязательные поля. Общая структура таблиц контроллеров представлена в таблице 9.


Таблица 9. Общая структура таблиц контроллеров подсистемы "Сбор данных" (DQA_{ModName}).

Идентификатор <ID>Имя контроллера <NAME>Описание <DESCR>Включать<ENABLE>Запускать <START>Индивидуальные параметры
AutoDAАвтоматический источникСбор данных из активных источников с автоматическим их выявлением.11 ...

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


Таблица 10. Общая структура таблиц параметров подсистемы "Сбор данных".

Шифр параметра <SHIFR>Имя параметра <NAME>Описание параметра <DESCR>Включать <EN>Индивидуальные параметры
P3P3Давление на диафрагме1...

Кроме контроллеров и параметров подсистема "Сбор данных" содержит шаблоны параметров. Шаблоны параметров сгруппированы по библиотекам шаблонов и хранятся в таблицах трёх типов: таблица библиотек шаблонов (ParamTemplLibs) таблица 11, таблица шаблонов параметров таблица 12 и таблица параметр шаблонов таблица 13.


Таблица 11. Структура таблицы библиотек шаблонов.

Идентификатор <ID>Имя <NAME>Описание <DESCR>Таблица БД библиотеки <DB>
baseБазовые шаблоныБиблиотека базовых шаблоновtmplib_base
S7 Библиотека шаблонов для контроллеров серии Siemens S7.tmplib_S7

Таблица 12. Структура таблицы шаблонов.

Идентификатор <ID>Имя <NAME>Описание <DESCR>Текст процедуры шаблона <PROGRAM>
digAlarmДискр. сигналСигнализация по дискретному параметруJavaLikeCalc.JavaScript
simpleBoardПростые границыФормирование простых границ для аналогового сигнала.JavaLikeCalc.JavaScript

Таблица 13. Структура таблицы параметров шаблонов.

Идентификатор шаблона <TMPL_ID>Идентификатор параметра <ID>Имя <NAME>Тип <TYPE>Флаги <FLAGS>Значение <VALUE>Позиция <POS>
digAlarminВход3144 2
digitBlockcmdOpenКоманда открытия3161Параметр:com0

17.3. Таблицы подсистемы “Транспорты”

Подсистема “Транспорты” делится на входящие и исходящие транспорты. Для каждого типа транспортов существует своя таблица с собственной структурой. Имена таблиц соответственно: Transport_In и Transport_Out. Таблицы могут дополняться полями, характерными для типа транспорта.


Таблица 14. Структура таблицы входящих транспортов (Transport_in).

Идентификатор <ID>Тип <MODULE>Имя <NAME>Описание <DESCRIPT>Адрес <ADDR>Протокол <PROT>Запускать <START>Индивидуальные поля типов транспортов
web1SocketsWeb 1Work web transport for proced http requests.TCP::10002:0HTTP1...
SelfSelfSystemTCP 1Test TCP input socket!SocketsTCP::10001:11...

Таблица 15. Структура таблицы исходящих транспортов (Transport_out).

Идентификатор <ID>Тип <MODULE>Имя <NAME>Описание <DESCRIPT>Адрес <ADDR>Запускать <START>Индивидуальные поля типов транспортов
tcp_o1SocketsTCP Out 1Output TCP transport 1TCP::100011...

Для централизованного описания перечня внешних OpenSCADA станций используется таблица внешних хостов (CfgExtHosts). Структура этой таблицы приведена в таблице 16.


Таблица 16. Структура таблицы внешних OpenSCADA хостов (CfgExtHosts).

Пользователь системы <OP_USER>Идентификатор <ID>Имя <NAME>Транспорт <TRANSP>Адрес удалённого хоста <ADDR>Пользователь внешнего хоста <USER>Пароль пользователя внешнего хоста <PASS>
tcp_o1SocketsTCP Out 1Output TCP transport 1TCP::100011...

17.4. Таблицы подсистемы “Архивы”

Подсистема “Архивы” содержит три таблицы с фиксированными именами:


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


Таблица 17. Структура таблицы архивов значений (Archive_val).

Идентификатор <ID>Имя <NAME>Описание <DESCR>Запускать <START>Режим источника значений <SrcMode>Источник значений <Source>Тип значений <VTYPE>Периодичность буфера <BPER>Размер буфера <BSIZE>Жесткая сетка буфера <BHGRD>Высокое разрешение времени буфера <BHRES>Перечень обслуживающих архиваторов <ArchS>
CPULoad_load 11DAQ.System.AutoDA.CPULoad.load4110000FSArch.1s;DBArch.1m;FSArch.1m;
ai1_dP 00 40.000110011FSArch.POMP_20070301;FSArch.1s;

Таблица 18. Структура таблицы архиваторов значений (Archive_val_proc).

Идентификатор <ID>Тип архиватора <MODUL>Имя <NAME>Описание <DESCR>Запускать <START>Адрес <ADDR>Период значений <V_PER>Период архивирования <A_PER>Индивидуальные поля типов архиваторов
1sFSArch Односекундный1ARCHIVES/VAL/1s160...
POMP_20070301FSArch 0ARCHIVES/VAL/POMP_200703010.000160...

Таблица 19. Структура таблицы архиваторов сообщений (Archive_mess_proc).

Идентификатор <ID>Тип архиватора <MODUL>Имя <NAME>Описание <DESCR>Запускать <START>Шаблон категории сообщений <CATEG>Уровень сообщений <LEVEL>Адрес <ADDR>Индивидуальные поля типов архиваторов
StatErrorsFSArhОшибки станции 1/DemoStation*4ARCHIVES/MESS/stError/...
NetRequstsFSArhСетевые запросы 1/DemoStation/Transport/Sockets*1ARCHIVES/MESS/Net/...

17.5. Таблицы подсистемы “Безопасность”

Подсистема “Безопасность” содержит две таблицы: таблица пользователей системы (Security_user) и групп системы (Security_grp).


Таблица 20. Структура таблицы пользователей системы (Security_user).

Имя <NAME>Описание <DESCR>Пароль <PASS>Изображение <PICTURE>
rootСуперпользовательopenscada
userПользовательuser

Таблица 21. Структура таблицы групп пользователей системы (Security_grp).

Имя <NAME>Описание <DESCR>Пользователи в группе <USERS>
rootГруппа суперпользователейroot;user
usersГруппа пользователейtoot;user

17.6. Структура баз данных модулей

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


18. Сервисные функции интерфейса управления OpenSCADA

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

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

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


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

IdИмяЗначение
Команда запроса информации об атрибутах параметра: <list path="/sub_DAQ/mod_{SRC}/cntr_{CNTR}/prm_{PRM}/%2fserv%2fattr"/>
<el id="iatr"/> Информация атрибутов В отдельных тегах возвращается информация об атрибуте.
id
Идентификатор атрибута Символьный идентификатор отдельно взятого атрибута.
nm
Имя атрибута Имя отдельно взятого атрибута.
flg
Флаги атрибута Флаги отдельно взятого атрибута.
tp
Тип атрибута Тип отдельно взятого атрибута.
vals
Область значений атрибута. Область значений отдельно взятого атрибута.
names
Имена значений атрибута для выборочного типа. Имена значений отдельно взятого атрибута для выборочного типа.
Команда запроса значений всех атрибутов параметра: <get path="/sub_DAQ/mod_{SRC}/cntr_{CNTR}/prm_{PRM}/%2fserv%2fattr"/>
<el id="iatr">val</el> Значения атрибутов В отдельных тегах возвращается значение атрибутов.
Команда установки значений указанных атрибутов параметра: <set path="/sub_DAQ/mod_{SRC}/cntr_{CNTR}/prm_{PRM}/%2fserv%2fattr"/>
<el id="iatr">val</el> Указываются значения атрибутов В отдельных тегах указываются значение атрибутов.

18.2. Доступ к архивным данным архивов сообщений

Для запроса и установки данных архива в подсистеме архивирования объекта архива сообщений предусмотрена команда <info path="/sub_Archive/%2fserv%2fmess"/>, <get path="/sub_Archive/%2fserv%2fmess"/> и <set path="/sub_Archive/%2fserv%2fmess"/> для запроса информации об архиве, значений архива и установки значений в архив, соответственно. В объекте контроллера подсистемы "Сбор данных" предусмотрен похожий сервисный запрос сообщений генерированных источником данных <get path="/sub_DAQ/{DAQ_TP}/{DAQ_CNTR}/%2fserv%2fmess"/>. Детальное описание данных команд представлено в таблице 24.


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

IdИмяЗначение
Команда запроса информации об архиве: <info path="/sub_Archive/%2fserv%2fmess"/>
arch Установка имени архиватора архива Архиватор архива, для которого определять параметры.
end Контроль вершины архива в данном архиваторе В результате запроса указывает на реальную вершину архива сообщений в данном архиваторе <arch>.
beg Контроль глубины архива в данном архиваторе В результате запроса указывает на реальную глубину архива сообщений в данном архиваторе <arch>.
Команда запроса архивных и/или текущих данных: <get path="/sub_Archive/%2fserv%2fmess"/>
tm Установка времени Время вершины блока архива сообщений.
tm_grnd Установка времени основания/начала архива Указывает основание/начало архива.
arch Установка архиватора архива Указывает, у какого архиватора запрашивать значения. Если архиватор не указан, то запрос будет производиться последовательно у всех архиваторов с исключением дубликатов.
cat Установка категории сообщений Указывает категорю/шаблоны запрашиваемых сообщений.
lev Установка уровня важности Указывает уровень важности сообщений, для которого и выше получать сообщения.
<el>{mess}</el> Сообщения В отдельных тегах возвращаются сообщения.
time, utime
Время сообщения (секунды, микросекунды) Время отдельно взятого сообщения.
cat
Категория сообщения Категория отдельно взятого сообщения.
lev
Уровень сообщения Уровень отдельно взятого сообщения.
Команда установки архивных данных: <set path="/sub_Archive/%2fserv%2fmess"/>
<el>{mess}</el> Сообщения В отдельных тегах указываются сообщения для установки.
time, utime
Время сообщения (секунды, микросекунды) Время отдельно взятого сообщения.
cat
Категория сообщения Категория отдельно взятого сообщения.
lev
Уровень сообщения Уровень отдельно взятого сообщения.
Команда запроса архивных и/или текущих данных источника данных: <get path="/sub_DAQ/{DAQ_TP}/{DAQ_CNTR}/%2fserv%2fmess"/>
tm Установка времени Время вершины блока архива сообщений. Если значение нулевое то запрос осуществляется от текущего времени и это время возвращается.
tm_grnd Установка времени основания/начала архива Указывает основание/начало архива.
lev Установка уровня важности Указывает уровень важности сообщений, для которого и выше получать сообщения.
<el>{mess}</el> Сообщения В отдельных тегах возвращаются сообщения.
time, utime
Время сообщения (секунды, микросекунды) Время отдельно взятого сообщения.
cat
Категория сообщения Категория отдельно взятого сообщения.
lev
Уровень сообщения Уровень отдельно взятого сообщения.

18.3. Доступ к архивным данным архивов значений

Для запроса данных архива в подсистеме архивирования объекта архива значения и объекте атрибута параметра подсистемы сбора данных предусмотрена команда <info path="{a_p_addr}/%2fserv%2fval"/> и <get path="{a_p_addr}/%2fserv%2fval"/> для запроса информации об архиве и значений архива соответственно. Атрибуты данных команд, предусматривающие различные механизмы запроса, представлены в таблице 25.


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

IdИмяЗначение
Команда запроса информации об архиве: <info path="{a_p_addr}/%2fserv%2fval"/>
arch Установка имени архиватора архива Архиватор архива, для которого определять параметры.
end Контроль вершины архива в данном архиваторе В результате запроса указывает на реальную вершину архива значений в данном архиваторе <arch>. В случае отсутствия архива атрибут устанавливается в "0".
beg Контроль глубины архива в данном архиваторе В результате запроса указывает на реальную глубину архива значений в данном архиваторе <arch>. В случае отсутствия архива атрибут устанавливается в "0".
per Контроль периодичности архива в данном архиваторе В результате запроса указывает на реальную периодичность значений в данном архиваторе <arch>. В случае отсутствия архива атрибут устанавливается в "0".
vtp Контроль типа значений архива/параметра Возвращает код типа значений архивных данных: 0 — Boolean, 1 — Integer, 4 — Real, 5 — String. Только данное свойство доступно в случае запроса у параметра без архива!
Команда запроса архивных и/или текущих данных: <get path="{a_p_addr}/%2fserv%2fval"/>
tm Установка и контроль времени Время запрашиваемого значения или вершины блока архива значений. Если атрибут не указан или равен "0", то возвращается последнее значение. Значение данного атрибута устанавливается в значение времени полученного значения или вершины блока архивных данных.
tm_grnd Установка и контроль времени основания/начала архива Указывает основание/начало архива. Если атрибут не указан или равен "0", то производится запрос одного значения. Значение данного атрибута устанавливается в значение времени основания блока архивных данных.
per Установка и контроль периодичности получаемых значений Периодичность запрашиваемых значений. Если атрибут не указан, равен "0" или меньше чем реальная периодичность архива, то значения будут возвращаться с реальной периодичностью архива и значение данного атрибута установится в значение реальной периодичности. Если значение атрибута больше реальной периодичности, то значения архива будут усредняться к указанной периодичности.
arch Установка и контроль архиватора архива Указывает, у какого архиватора запрашивать значения. Если архиватор не указан, то запрос будет производиться последовательно с приоритетностью от лучшего к худшему. Имя архиватора, у которого получены значения, будет указанно в данном атрибуте при возврате результата. Если архиватор для данного параметра не установлен или такого архиватора нет, то значение данного атрибута будет обнулено. В случае выполнение запроса, пересекающего несколько архиваторов, выполняется обработка только первого архиватора с указанием его имени и размерности в соответствующих атрибутах. Для запроса данных последующих архиваторов запрос повторяется отталкиваясь от размерности предыдущего запроса.
mode Установка и контроль режима передачи данных архива

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

0 — Простая запись: одно значение — одна строка без упаковки смежных значений. В случае архива строк значения кодируются на предмет исключения символов перевода строки. Пример формы записи:
34.5678
23.6543
65.8754
34.6523

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

0 34.5678
1 23.6543
4 65.8754
6 34.6523

2 — Массив бинарных неупакованных значений, кодированный Mime Base64. Не может быть использован для строковых архивов.
real_prec Установка точности вещественных чисел Указывает, с какой точностью передавать данные значений вещественного типа в режиме "0" и "1". По умолчанию эта точность составляет 6 значащих цифр.
round_perc Установка процента округления Указывает процент округления смежных числовых значений, для режима "1".
Команда запроса имени архивного параметра или самого архива: <name path="{a_p_addr}/%2fserv%2fval"/>

19. API модулей модульных подсистем

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


Первым шагом при подключении разделяемых (SO — shared object) библиотек является подключение функций инициализации. Эти функции должны быть определены как обычные “С” функции для исключения искажения имен функций. Обычно это делается следующим образом:

//================== CUT =========================
extern "C"
{
#ifdef MOD_INCL
    //Нужно указывать только в случае поддержки модулем возможности
    //влинковки в ядро OpenSCADA
    TModule::SAt bd_DBF_module( int n_mod )
#else
    TModule::SAt module( int n_mod )
#endif
    {
    //Формирование описателей модулей из списка
    //доступных в разделяемой библиотеке.
    }

#ifdef MOD_INCL
    //Нужно указывать только в случае поддержки модулем возможности
    //влинковки в ядро OpenSCADA
    TModule *bd_Tmpl_attach( const TModule::SAt &AtMod, const string &source )
#else
    TModule *attach( const TModule::SAt &AtMod, const string &source )
#endif
    {
    //Подключить указанный модуль
    }
}
//================== CUT =========================


Функции для работы с разделяемой библиотекой:
TModule::SAt module( int n_mod );

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

TModule *attach( const TModule::SAt &AtMod, const string &source );

Подключение к указанному модулю.

Практически все функции и данные системы сведены в API-системы, описываемого в данном документе. Однако для упрощения и ускорения процесса написания модулей основные функции, переопределяемые в модулях, приведены в таблице 22.


Таблица 22. Основные функции, использующиеся при создании модулей
Общее API

API объекта (TCntrNode):

  • virtual void load_( ); — Загрузка объекта из хранилища.
  • virtual void save_( ); — Сохранение объекта в хранилище.

Общее API модулей (TModule):

Атрибуты:
  • string mId; — Идентификатор модуля.
  • string mName; — Имя модуля.
  • string mDescr; — Описание модуля.
  • string mType; — Тип модуля.
  • string mVers; — Версия модуля.
  • string mAutor; — Автор модуля.
  • string mLicense; — Лицензия модуля.
  • string mSource; — Источник/происхождение модуля.

Методы:

  • virtual void modStart( ); — Запуск модуля.
  • virtual void modStop( ); — Останов модуля.
  • virtual void modInfo( vector<string> &list ); — Список доступных элементов информации о модуле. Предусмотрены следующие информационные элементы:
    Module — идентификатор модуля;
    Name — локализованное имя модуля;
    Type — тип модуля;
    Source — источник модуля (контейнер);
    Version — версия модуля;
    Author — автора модуля;
    Description — описание модуля;
    License — лицензия модуля.
  • virtual string modInfo( const string &name ); — Запрос указанного элемента информации.
  • virtual void perSYSCall( unsigned int cnt ); — Вызов из системного потока, с периодичностью 10 секунд и секундным счётчиком cnt.
  • void postEnable( int flag ); — Подключение модуля к динамическому дереву объектов.
  • void modFuncReg( ExpFunc *func ); — Регистрация экспортируемой функции.
API модулей подсистемы “БД”.

Тип БД (потомок от TTypeBD):

  • virtual TBD *openBD( const string &id ); — Открыть/создать БД.

БД (потомок от TBD):

  • virtual void enable( ); — Включение БД.
  • virtual void disable( ); — Отключение БД.
  • virtual void allowList( vector<string> &list ) const; — Перечень таблиц в БД.
  • virtual void sqlReq( const string &req, vector< vector<string> > *tbl = NULL, char intoTrans = EVAL_BOOL ); — Отправка SQL-запроса req на БД и получение результата в виде таблицы tbl. При установке intoTrans в true для запроса будет открыта транзакция, в false будет закрыта.
  • virtual void transCloseCheck( ) — Периодически вызываемая функция для проверки транзакций и закрытия старых или содержащих много запросов.
  • virtual TTable *openTable( const string &table, bool create ); — Открыть/создать таблицу.

Таблица (потомок от TTable):

  • virtual void fieldStruct( TConfig &cfg ); — Получение структуры таблицы.
  • virtual bool fieldSeek( int row, TConfig &cfg ); — Последовательное сканирование записей таблицы.
  • virtual void fieldGet( TConfig &cfg ); — Получение указанной записи.
  • virtual void fieldSet( TConfig &cfg ); — Установка указанной записи.
  • virtual void fieldDel( TConfig &cfg ); — Удаление указанной записи.
API модулей подсистемы "Транспорты".

Тип транспорта (потомок от TTypeTransport):

  • virtual TTransportIn *In( const string &name, const string &db ); — Создать/открыть новый "Входящий" транспорт.
  • virtual TTransportOut *Out( const string &name, const string &db ); — Создать/открыть новый "Исходящий" транспорт.

Входящий транспорт (потомок от TTransportIn):

  • virtual string getStatus( ); — Статус интерфейса.
  • virtual void setAddr( const string &addr ); — Установка адреса транспорта. Может переопределяться для обработки и проверки специфического для модуля формата адреса транспорта.
  • virtual void start(); — Запуск транспорта.
  • virtual void stop(); — Останов транспорта.

Исходящий транспорт (потомок от TTransportOut):

  • virtual string getStatus( ); — Статус интерфейса.
  • virtual void setAddr( const string &addr ); — Установка адреса транспорта. Может переопределяться для обработки и проверки специфического для модуля формата адреса транспорта.
  • virtual void start( ); — Запуск транспорта.
  • virtual void stop( ); — Останов транспорта.
  • virtual int messIO( const char *obuf, int len_ob, char *ibuf = NULL, int len_ib = 0, int time = 0 ); — Отправка данных через транспорт. Время ожидания time соединения указывается в миллисекундах.
API модулей подсистемы "Протоколы".

Протокол (потомок от TProtocol):

  • virtual void itemListIn( vector<string> &ls, const string &curIt = "" ); — Перечень подєлементов у входящего протокола, если протокол их предусматривает. Используется при выборе в конфигурации объекта входящего транспорта.
  • virtual void outMess( XMLNode &io, TTransportOut &tro ); — Передача данных в дереве XML in удалённой системе посредством транспорта tro и текущего исходящего протокола.
  • virtual TProtocolIn *in_open( const string &name ) — Открыть/создать входной протокол.

Входной протокол (потомок от TProtocolIn):

  • virtual bool mess( const string &request, string &answer, const string &sender ); — Передача неструктурированного сообщения в протокол.
API модулей подсистемы “Сбор данных”.

Тип контроллера (потомок от TTypeDAQ):

  • virtual void compileFuncLangs( vector<string> &ls ); — Перечень языков пользовательского программирования, поддерживаемых модулем.
  • virtual void compileFuncSynthHighl( const string &lang, XMLNode &shgl ); — Запрос правил подсветки синтаксиса shgl указанного языка пользовательского программирования lang.
  • virtual string compileFunc( const string &lang, TFunction &fnc_cfg, const string &prog_text ); — Компиляция пользовательской процедуры и создания объекта исполнения функции для указанного языка пользовательского программирования.
  • virtual bool redntAllow( ); — Признак поддержки механизмов резервирования модулем. Должен просто переопределяться и возвращать true.
  • virtual TController *ContrAttach( const string &name, const string &daq_db ); — Открытие/подключение контроллера.

Контроллер (потомок от TController):

  • virtual string getStatus( ); — Вызов для получения специфического статуса контроллера.
  • virtual void enable_( ); — Включение контроллера.
  • virtual void disable_( ); — Отключение контроллера.
  • virtual void start_( ); — Запуск контроллера.
  • virtual void stop_( ); — Останов контроллера.
  • virtual void redntDataUpdate( bool firstArchiveSync = false ); — Выполнение операции получения данных из резервной станции. Вызывается автоматически задачей обслуживания схемы резервирования и перед запуском для синхронизации архивов с установленным параметром firstArchiveSync.
  • virtual TParamContr *ParamAttach( const string &name, int type ); — Создание/открытие нового параметра.

Параметр контроллера (потомок от TParamContr->TValue):

  • virtual void enable( ); — Включить параметр.
  • virtual void disable( ); — Отключить параметр.
  • virtual void setType( const string &tpId ); — Вызывается для смены типа параметра tpId и может быть обработан в объекте модуля, для смены собственных данных.
  • virtual TVal* vlNew( ); — Вызывается при создании нового атрибута. Может быть переопределён для реализации особого поведения в рамках своего, наследованного от TVal, класса при доступе к атрибуту.
  • virtual void vlSet( TVal &val, const TVariant &pvl ); — Вызывается для атрибута с прямым режимом записи TVal::DirWrite (синхронный режим или запись во внутренний буфер объекта) при установке значения, с целью непосредственной записи значения в физический контроллер или буфер объекта.
  • virtual void vlGet( TVal &val ); — Вызывается для атрибута с прямым режимом чтения TVal::DirRead (синхронный режим или чтение из внутреннего буфера объекта) при чтении значения, с целью непосредственного чтения значения из физического контроллера или буфера объекта.
  • virtual void vlArchMake( TVal &val ); — Вызывается при создании архива значений с атрибутом val в качестве источника с целью инициализации качественных характеристик буфера архива согласно особенностям источника данных и их опроса.
API модулей подсистемы "Архивы".

Тип архиватора (потомок от TTypeArchivator):

  • virtual TMArchivator *AMess(const string &id, const string &db ); — Создание архиватора сообщений.
  • virtual TVArchivator *AVal(const string &id, const string &db ); — Создание архиватора значений.

Архиватор сообщений (потомок от TMArchivator):

  • virtual void start( ); — Старт архиватора.
  • virtual void stop( ); — Останов архиватора.
  • virtual time_t begin( ); — Начало данных в архиваторе.
  • virtual time_t end( ); — Конец данных в архиваторе.
  • virtual void put( vector<TMess::SRec> &mess ); — Передать сообщение архиватору.
  • virtual void get( time_t b_tm, time_t e_tm, vector<TMess::SRec> &mess, const string &category = "", char level = 0, time_t upTo = 0 ); — Запросить сообщение из архиватора.

Архиватор значений (потомок от TVArchivator):

  • virtual void setValPeriod( double per ); — Установить периодичность значений архиватора.
  • virtual void setArchPeriod( int per ); — Установить периодичность архивирования.
  • virtual void start( ); — Запустить архиватор.
  • virtual void stop( bool full_del = false ); — Остановить архиватор с возможностью полного удаления, если установлен full_del.
  • virtual TVArchEl *getArchEl( TVArchive &arch ); — Получение архива arch, обслуживаемого архиватором.

Архивный элемент значений (потомок от TVArchEl):

  • virtual void fullErase( ); — Полное удаление части архива в архиваторе.
  • virtual int64_t end( ); — Время окончания архива в архиваторе.
  • virtual int64_t begin( ); — Время начала архива в архиваторе.
  • virtual TVariant getValProc( long long *tm, bool up_ord ); — Функция обработки запроса одного значения из архива.
  • virtual void getValsProc( TValBuf &buf, int64_t beg, int64_t end ); — Функция обработки запроса модулем на получение данных группы значений buf за указанный промежуток времени.
  • virtual void setValsProc( TValBuf &buf, int64_t beg, int64_t end ); — Функция обработки запроса модулем на установку данных группы значений buf за указанный промежуток времени.
API модулей подсистемы "Пользовательские интерфейсы".
Пользовательский интерфейс (потомок от TUI):
Не содержит специфических функций!
API модулей подсистемы "Специальные”.
Специальные (потомок от TSpecial):
Не содержит специфических функций!

20. Отладка и тестирование проекта OpenSCADA

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

21. Правила оформления и комментирования исходных текстов OpenSCADA и его модулей

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

indent -bli0 -i4 -ts8 -l100 -npsl -npcs -nprs -nsaf -nsai -nsaw -brs -br -cdw -nbc -lp <filename>.

Правила комментирования исходных текстов OpenSCADA:

22. Условные обозначения по тексту и в исходниках

???? — сомнение в целесообразности данного участка;
?!?! — участок не полностью реализован;
!!!! — участок требует переосмысления.

Ссылки

Referring pages: Doc
Doc/ModuleBuild
Doc/OPCUA
Doc/OpenSCADA060
Doc/SelfSystem
Doc/VCA/part4/part5
Doc/VCA/part6/part1
HomePageEn/Doc/SelfSystem
HomePageUk/Doc
HomePageUk/Doc/ModuleBuild
HomePageUk/Doc/OPCUA
HomePageUk/Doc/OpenSCADA060
HomePageUk/Doc/SelfSystem


 
There is one file on this page.[Display files/form]
There is no comment on this page. [Display comments/form]