OpenSCADA

Документи/API

This page is a translated version of the page Documents/API and the translation is 32% complete.
English • ‎mRussian • ‎Українська

Ця сторінка описує інтерфейс програмування (API) додатку OpenSCADA.

OpenSCADA це проєкт відкритої SCADA-системи побудованої за модульним принципом. У документі міститься вичерпна інформація зі внутрішньої архітектури об'єктів OpenSCADA. Також надаються довідкові дані з методів та атрибутів цих об'єктів.

At.png Цей документ призначено для програмістів які бажають розібратися у архітектурі OpenSCADA та розробляти розширення до неї. Документ переважно не призначено для користувачів та інтеграторів OpenSCADA, хоча окремі речі можуть бути корисні і їм для розуміння роботи.

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

Contents

1 Внутрішня структура

З метою наочного та доступного сприйняття архітектури OpenSCADA на рисунку 1 зображено статичну діаграму класів OpenSCADA на універсальній мові моделювання (UML).

Із діаграми видно, що OpenSCADA містить модульні підсистеми: "Архіви-Історія", "Бази Даних", "Транспорти", "Транспортні протоколи", "Користувацькі Інтерфейси", "Збір Даних" та "Спеціадьні", а також підсистеми: "Безпека" та "Управління Модулями". На діаграмі наведено взаємозв'язки між модульними підсистемами та модулями відповідних типів.

Рис.1. Статична діаграма класів.

2 Загальна структура програми — модульність

Коренем, із якого будується вся програма, є об'єкт #TSYS. Корінь містить підсистеми #TSubSYS. Підсистеми можуть бути звичайними та модульними. Відмінність модульних підсистем чітко відстежується на рисунку 1. Таким чином, модульні підсистеми обов'язково містять перелік модульних об'єктів #TModule, наприклад, підсистема архівів-історії #TArchiveS містить модульні об'єкти #TTypeArchivator. Тим часом, звичайна підсистема таких об'єктів не містить, наприклад, підсистема безпеки #TSecurity (рис.2).

Рис.2. Ієрархічна структура OpenSCADA.

У процесі ініціалізації кореня #TSYS визначається глобальна змінна "SYS", яка може використовуватися для прямого звернення до кореню програми із будь якого її вузла. Ініціалізація кореню виконується одноразово із головної функції виклику. Після запуску, управління захоплюється кореневим об'єктом програми до зупинки. Кореневий об'єкт концентрує всі загальні функції OpenSCADA.

Продовженням кореневого об'єкту #TSYS, що здійснює функції обслуговування потоку повідомлень програми, виступає об'єкт #TMess, який доступний посередництвом глобальної змінної "Mess" ініціалізованої коренем програми. Об'єкт містить функції кодування, декодування та локалізації повідомлень.

У підсистемах #TSubSYS реалізуються функції, що індивідуальні до кожної підсистеми, та із загальним для всіх підсистем доступом через об'єкт #TSubSYS. Модульна підсистема має можливість розширення функціональності посередництвом модулів, для чого вона надає доступ до модулів свого типа у вигляді модульних об'єктів.

Модуль, це складова частина модульної підсистеми. Модуль надає інформацію про себе, своє походження та функції, що експортуються. Окремо взятий модуль реалізує функціонал відповідно до власних потреб.

2.1 The root object system (TSYS)

Inherits: TCntrNode.

Data:
Information variables of the program:

Methods for coding of symbol sequences (enum — TSYS::Code):

Types of representations of the integer in the function TSYS::int2str(), and TSYS::ll2str() (enum — TSYS::IntView):

Structure of redundant station (class — TSYS::SStat):

Structure of OpenSCADA task (class — TSYS::STask):

Templates/definitions:

Public methods:

Public attributes:

Short calls for global functions into "OSCADA" namespace:

2.2 Object of the messages system (TMess)

Data:
Types (levels) of messages (enum — TMess::Type):

Direction for the messages (enum — TMess::Direct):

The structure of the message (class — TMess::SRec):

Templates:

Public methods:

1 — to syslog;
2 — to stdout;
4 — to stderr;
8 — to the archive.

2.3 Object subsystem (TSubSYS)

Inherits: TCntrNode
Inherited: TArchiveS, TProtocolS, TBDS, TFunctionS, TSesurity, TModShedul, TTransportS, TUIS, TSpecialS, TControllerS.

Public methods:

2.4 Object Module (TModule)

Inherits: TCntrNode
Inherited: TProtocol, TTypeBD, TTypeArchive, TTypeTransport, TUI, TSpecial, TTypeDAQ

Data:
The data structure which identifies the module (class — TModule::SAt):

The structure of exported functions (class — TModule::ExpFunc):

Public methods:

Protected Attributes:

Protected methods are:

3 Subsystem "DB"

Subsystem "Databases" is represented by the object TBDS, which contains a modular objects of the following types of DB TTypeBD. Each type of database contains objects of individual databases of that type TBD. Each database in its turn, contains the objects of their tables TTable (Fig. 3).

Fig. 3. Hierarchical structure of the subsystem "DB".

The subsystem provides the basic functions to access the type of database, as well as generalized functions for the manipulation of the databases and tables. For example, to hide the source of data, which may be a configuration file, the functions of an abstract access to the data source are provided. For the storage system-wide data the system table and the function of the abstract to access it are provided. Consequently, system-wide data can be stored in the configuration file and in the database table. More about the data organisation conception you can read in the Data in OpenSCADA and their storage section.

Being a modular object, the type of database (TTypeBD) provides access to the implementation of the mechanism of one or another database. Access is made through a public databases of the module of a given type of database. Open/registered database is described in the table of databases to be opened or in the configuration file. There is, the so-called, the working database, which is always opens and is shown in the configuration file. DB which support the SQL-queries can grant access based on direct SQL-queries.

While working, the components of OpenSCADA open tables (TTable) available in the database and work with them.

3.1 Object of subsystem "Database" (TBDS)

Inherits: TSubSYS

Data:
Flags of the function dbList() (enum – TDBS::DBLsFlg):

Flags of the queries to the storage (enum – TDBS::ReqGenFlg):

Specific flags

Public generic static methods:

Public methods:

3.2 Modular object of types of databases (TTypeBD)

Inherits: TModule
Inherited: By root objects of the modules of subsystem "DB".

Public methods:

3.3 The object of the database (TBD)

Inherits: TCntrNode, TConfig
Inherited: By the database objects of the modules of subsystem "DB".

Public methods:

Protected attributes:

Protected methods:

3.4 The object of the table (TTable)

Inherits: TCntrNode
Inherited: By tables objects of the modules of subsystem "DB".

Data:
Flags of the SQL requests (enum – TTable::SQLFeqFlag):

Item of the table structure (class — TTable::TStrIt):

Public methods:

Protected attributes:

4 Subsystem "Data acquisition"

The subsystem "Data acquisition" is represented by the TDAQS object which contains modular objects of the data sources' types TTypeDAQ and the objects of the libraries of parameters' templates of subsystem "Data acquisition" TPrmTmplLib. Object of the data sources types contains objects of the controllers TController and objects of the parameters' types TTypeParam. Parameters' types objects are provided by the controller module and contain the DB structure of the separate parameters' types (analog, digital ...). Controllers' objects contain parameters' objects TParamContr. Each parameter is associated with only one type of the parameter. For the attribute storage parameter is inherited from the values object TValue, which contains the attributes' values TVal. The library of the parameters' templates of this subsystem contains templates' objects TPrmTmpl. An example of the described hierarchical structure is shown in Fig. 4.

Fig. 4. Hierarchical structure of the subsystem "Data acquisition".

Subsystem contains the types of data sources. The source may be virtually any substance providing any data. Type of source can be divided into individual sources (controllers) within the limits of the particular type. For example, if we take the data from the operating system (OS), then the single source can be the separate operating system of the separate PC.

Data source (controller) is further divided (contains) into the parameters. The parameter is the part of the data source. In the case of the OS it will be, for example,: used RAM, the processor's frequency and many other parts.

Parameter, in its turn, contains the attributes, which provide the data. In addition to the basic data attributes can provide the related or detailing data. In the case of the same operating system and the memory usage, the attributes may not only provide the used memory, and also how much it all, how much in the swap, etc.

Some of the implementation of the data sources may provide the possibility of setting the structure of the parameter based on previously developed parameters' templates. For this purpose subsystem contains templates' libraries, which, in their turn, provide the parameters' templates . The example shows a library of templates "base" with the templates "digAlrm" and "smplBrd".

At the level of the subsystem the redundancy mechanism for data sources is provided. Redundancy means the possibility of coordinated work of several OpenSCADA stations to perform common task of data acquisition from the same data sources.

4.1 Object of subsystem "Data acquisition" (TDAQS)

Inherits: TSubSYS

Public methods:

4.2 Modular object of the controller's type (TTypeDAQ)

Inherits: TModule, TElem
Inherited: Root object of the modules of subsystem "Data acquisition".

Public methods:

Protected methods:

4.3 Controller's object (TController)

Inherits: TCntrNode, TConfig
Inherited: Objects of the modules of subsystem "Data acquisition".

Data:
Redundancy modes (enum TController::Redundant):

Command specific

Public methods:

Protected attributes:

Protected methods:

4.4 Parameters' type object (TTypeParam)

Inherits: TElem

Public methods:

At.png Will be removed in v1.0, use TController::tbl() instead.
At.png Will be removed in v1.0.

Public attributes:

4.5 Object of the physical level parameter (TParamContr)

Inherits: TConfig, TValue
Inherited: Objects of the module's parameters of subsystem "Data acquisition".

Data:
Flags of the enabling/disabling modes of the node (enum TParamContr::EnDisFlag):

Public methods:

Protected methods:

4.6 Object of the value (TValue)

Inherits: TCntrNode, TValElem
Inherited: TParamContr

Public methods:

Protected methods:

4.7 Attribute's object (TVal)

Inherits: TCntrNode

Data:
Additional flags to the object #TFld (enum TVal::AttrFlag):

Public methods:

4.8 Object of the templates library of parameters of the "DAQ" subsystem (TPrmTmplLib)

Inherits: TCntrNode, TConfig

Public methods:

4.9 The object of the parameter's template of the "DAQ" subsystem (TPrmTempl)

Inherits: TFunction, TConfig

Data:
Additional flags to the attribute's object of the function IO (enum TPrmTempl::IOTmplFlgs):

Public methods:

4.9.1 The object of the implementation of the template's parameters of the "DAQ" subsystem (TPrmTempl::Impl)

Inherits: TValFunc

Data:
Structure of template links (class — TPrmTempl::Impl::SLnk):

Public methods:

Protected attributes:

Protected methods:

5 Subsystem "Archives-History"

Subsystem "Archives" is represented by an object TArchiveS, which contains at the subsystem level the modular objects of the archivers types TTypeArchivator. Each object of the archiver type contains objects of the messages' archivers TMArchivator and values' archivers TVArchivator. In addition, the subsystem object contains the methods of the messages archive and objects of the values' archives TVArchive. The object of the values' archive TVArchive contains the buffer of values through the inheritance of the buffer object TValBuf. To connect the archive of values with the archivers the object of the value element TVArchEl is provided. This object is contained in the archiver and it is referenced by the archive. Structure of the subsystem "Archives" is presented in Fig. 5.

Fig. 5. Hierarchical structure of the subsystem "Archives".

Subsystem "Archives" contains the mechanisms for archiving of messages and values. It directly contains the messages' archive together with its buffer. Contains methods for accessing the archives of the values and for the archivers of values and messages. Besides it performs the actively data acquisition from sources of values for the archives of values, as well as archiving the archive of messages by the archivers.

Archive of values (TVArchive) contains the buffer (TValBuf) for intermediate values' accumulation before archiving. It is connected with the source of values in the person of OpenSCADA parameters in active or passive mode, as well as with other sources in the passive mode. To archive to the physical storage it is connected with the values' archivers of various types.

Object of the buffer TValBuf contains an array of values of the main types of OpenSCADA: string, integer, real and boolean. It is supported the storage of values in the modes of hard, soft grid and in the free access mode. It is also provided the mode of high-resolution time (microseconds). It is used for direct storage of large arrays of values, and for the exchange of large arrays by the frame-accurate method of access.

Root object of the module of subsystem "Archives" (TTypeArchivator) contains information about the specific type of module. Within the individual modules it can implement their own module-wide functions. In general, for modules of this type it contains methods to access the repositories of values and messages.

Object of the messages' archiver (TMArchivator) contains the specific implementation of the message storage. In general, for messages' archivers the interface of access to the implementation of an archiving mechanism in modules is provided.

Object of the values' archiver (TVArchivator) contains the specific implementation of the repository of values. In general, for the values' archivers the access interface to implementation of the archiving mechanism and the appointment of archives of values for service by archiver are provided.

Object of the archive element TVArchEl links the archive objects with the archivers. It is used to access the archiver from the archive, as well as to archives from the archiver, ie for cross-calls.

5.1 The object of the subsystem "Archives" (TArchiveS)

Inherits: TSubSYS

Modes of forming ID of the automatic created archives:

Public methods:

Public methods:

5.2 The object of the values' archive (TVArchive)

Inherits: TCntrNode, TValBuf, TConfig

Data:
The data acquisition mode/source (enumeration — TVArchive::SrcMode):

The data combination mode (enumeration — TVArchive::CombMode):

Data modes of the service request "Requesting for values of the specified value archive" (enumeration — TVArchive::ServReqDtMode):

Public methods:

5.3 Object of the values' buffer (TValBuf)

Inherited: TVArchive

Public methods:

Protected methods:

5.4 The modular object of the archiver's type (TTypeArchivator)

Inherits: TModule
Inherited: By the root objects of the modules of subsystem "Archives".

Public methods:

Protected methods:

5.5 The object of the messages' archiver (TMArchivator)

Inherits: TCntrNode, TConfig
Inherited: By the objects of the archivers of messages of modules of the subsystem "Archives".

Public methods:

Protected attributes:

Protected methods:

5.6 The object of the values' archiver (TVArchivator)

Inherits: TCntrNode, TConfig
Inherited: By the objects of the archivers of values of modules of the subsystem "Archives".

Public methods:

Protected methods:

Protected attributes:

5.7 The object of the archive's element in the archiver (TVArchEl)

Inherited: By the objects of the archivers of values of modules of the subsystem "Archives".

Public methods:

Public methods:

Protected methods:

6 Subsystem "Transports"

"Transports" subsystem is represented by the TTransportS object, which contains modular objects of the transports' types TTypeTransport on the subsystem-level. Each type of transport contains objects TTransportIn of the input and TTransportOut of the output transports. The overall structure of the subsystem is shown in Fig. 6.

Fig. 6. Hierarchical structure of the subsystem "Transports".

The root object of the "Transports" subsystem's module provides information about the specific type of module and about the external OpenSCADA hosts/stations. As part of the single module it can be implemented the own general-module functionality. In general, for all modules, the access methods for both: inbound and outbound transports of the specific module are contained.

The object of the input transport TTransportIn provides an interface to the implementation of the modular method of input transport.

The object of the output transport TTransportOut provides an interface to the implementation of the modular method of output transport.

6.1 The object of the "Transports" subsystem (TTransportS)

Inherits: TSubSYS

Data:
Definitions of space the Transport subsystem (definition):

External hosts mode (enum — TTransportS::ExtHost::Mode):

The structure of the external OpenSCADA hosts/stations (class TTransportS::ExtHost):

Data types of the IO logs (enum — TTransportS::LogType):

Public methods:

"{TrModule}.[out_]{TrID}[:{TrAddr}]" — typical output with automatic creation TrID at it missing and allowing TrAddr;
"{TrModule}.in_{TrID}:{RemConId}" — initiative input with the connection identifier in RemConId.

6.2 The modular object of the transports' type (TTypeTransport)

Inherits: TModule
Inherited: By the root object of the subsystem's "Transports" modules..

Public methods:

Protected methods:

6.3 The object of the input transports (TTransportIn)

Inherits: TCntrNode, TConfig
Inherited: By the objects of input transports of the subsystem's "Transports" modules.

Data:
Stages of the new Associated Output Transports processing (enum — TTransportIn::AssociateTrStage):

Public methods:

Protected methods:

Protected attributes:

6.4 The object of the output transports (TTransportOut)

Inherits: TCntrNode, TConfig
Inherited: By the objects of output transports of the subsystem's "Transports" modules.

Public methods:

Protected methods:

Protected attributes:

7 Subsystem "Transport protocols"

Subsystem "Communication interfaces' protocols" is presented by the TProtocolS object, which contains modular objects of the separate protocols TProtocol on the a subsystem's level. Each protocol contains objects of the opened sessions of the input protocols TProtocolIn.

TProtocolS object provides an access to the both: the input and the output protocols of the individual types of transport protocols. The inner side of output protocol based on the steaming principle with the individual structure of the stream for each implementation of the protocol.

7.1 The object of the "Communication interfaces' protocols" subsystem (TProtocolS)

Inherits: TSubSYS

Public methods:

7.2 The modular object of the protocol (TProtocol)

Inherits: TModule
Inherited: By the root object of the subsystem's "Protocols" modules.

Public methods:

7.3 The object of the input protocol's session (TProtocolIn)

Inherits: TCntrNode
Inherited: By the session objects of the input modules' protocol of the subsystem "Protocols".

Public methods:

8 Subsystem "User interfaces"

The subsystem "User Interfaces" is presented by the TUIS object, which contains modular objects of the TUI user interfaces' on the subsystem's level.

8.1 The object of the "User interfaces" subsystem (TUIS)

Inherits: TSubSYS

Data:
Requests parameters (enum — GetOpts):

Public methods:

8.2 The modular object of the user interface (TUI)

Inherits: TModule
Inherited: By the root objects of the "User interfaces" subsystem.

Protected attributes:

9 Subsystem "Specials"

The subsystem "Specials" is presented by TSpecialS object, which contains modular objects of TSpecial special on the subsystem's level.

9.1 The object of the "Specials" subsystem (TSpecialS)

Inherits: TSubSYS

Public methods:

9.2 The modular object of the specials (TSpecial)

Inherits: TModule
Inherited: By the root objects of the subsystem's “Specials” modules.

Protected attributes:

10 Subsystem "Security"

Security subsystem is presented by an object TSesurity, which contains group objects of TGroup and users TUser.

User object TUser contains user information and checks the authenticity of the user in accordance with the specified password.

TGroup user object contains information about the group of users and checks the user's belonging to the group.

10.1 The object of the "Security" subsystem (TSecurity)

Inherits: TSubSYS

Data (definition):

Public methods:

10.2 The user's object (TUser)

Inherits: TCntrNode, TConfig

Public methods:

10.3 The users' group object (TGroup)

Inherits: TCntrNode, TConfig

Public methods:

11 Subsystem "Modules scheduler"

Subsystem “Modules' sheduling” is presented by the object TModSchedul.

The subsystem contains the control mechanism for modules contained in shared libraries.

11.1 The object of the subsystem "Modules' sheduling" (TModSchedul)

Inherits: TSubSYS

Data:
The structure of information about the shared library (struct – TModSchedul::SHD):

Public methods:

12 Components of the object model of OpenSCADA

Object model of OpenSCADA is based on the function object TFunction, on the parameters of the function IO and on the values' frame of the function TValFunc. Later the function's objects are included in the object tree, forming an object model of the system. Using the functions of the object model is made by linking the frame of values TValFunc with function.

The idea in general is shown in Fig. 7.

Fig. 7. Basis of the programming area of OpenSCADA.

Object of the function (TFunction) provides an interface for the formation of function parameters and algorithm of the computing in the object which inherits it.

Object of the function's parameter (IO) contains the configuration of the single parameter.

Object of the values' frame (TValFunc) contains values in accordance with the structure of the linked function. While the execution of the algorithm by the associated function the values of this object are used.

12.1 The function object (TFunction)

Inherits: TCntrNode
Inherited: By the modules and nodes of the systems, which contains the functions for publication in the object model of the system.

Public methods:

Protected attributes:

12.2 The object of the function's parameter (IO)

Data:
Parameter's type (enum — IO::Type):

Parameter's flags (enum — IO::IOFlgs):

Public methods:

12.3 The object of the function's value (TValFunc)

Public methods:

Public attributes:

13 Data in OpenSCADA and their storage

Storing data in the program is based on the objects TConfig and TElem. These objects store the structure and field values of the storage, allowing for direct loading and saving the configuration via the "DB" subsystem. For the specialised different types of the data storage the TVariant object is provided.

The TElem object contains the structure of database record. Structure of the record contains extensive information about the elements, their types, sizes and other parameters. Information in that structure is enough to create, control and manage the real structure of the database. Elementary unit of the record is the cell TFld.

The TConfig object is the heir of TElem and contains the actual values of elements. TConfig is used as the parameter in the functions of the manipulating with the table records in the "DB" subsystem. Elementary unit of the record is the cell TCfg.

To provide an opportunity to inform the data storehouse about the changes in the structure it is provides an object TValElem, from which it is inherited the storehouse TConfig and the list of which is contained in the TElem structure.

13.1 Data storing conception

OpenSCADA commonly defines and uses as the storage only the Configuration File and the Data Bases of different types of the "DB" subsystem. Where the Configuration File has the highest priority as an obligatory and always present storage.

The Generic Storage is a common system configuration field of selection a storage for common program data and as default storage value of OpenSCADA nodes to store. As the Generic Storage there can be selected whether the Configuration File "<cfg>" or a DB "{DB module}.{DB name}", and the same is pointed as "<gen>" for enabling the implicit data accessing method in OpenSCADA nodes.

There are provided two variants of the data accessing:

  1. directly and exclusively at the specified storage name;
  2. implicitly at specifying the Generic Storage name "<gen>", what commonly means of accessing to the Configuration File firstly and the Generic Storage DB secondary, at the data missing in the Configuration File.

The "DB" subsystem (the class TBDS) provides the functions dataSeek(), dataGet(), dataSet(), dataDel() of accessing the data which perform the data accessing variants in such ways:

  1. seeking data only the directly specified storage;
  2. throughout seeking the Configuration File and the Generic Storage DB.
  1. getting data only the directly specified storage;
  2. getting the present data in the Configuration File, next the Generic Storage DB data at missing in the Configuration File.
  1. setting data only to the directly specified storage;
  2. setting the present data in the Configuration File, next the Generic Storage DB data at missing in the Configuration File; provides the flag TBDS::OnlyCfg support to force the new data creation in the Configuration File.
  1. deleting data only in the directly specified storage;
  2. deleting the data both in the Configuration File and the Generic Storage DB.

The testing scenarios of the data accessing:

13.2 Data object (TConfig)

Inherits: TValElem
Inherited: TParamContr, TController, TMArchivator, TPrmTempl, TPrmTmplLib, TUser, TGroup, TTransportIn, TTransportOut, TBD, TVArchive, TVArchivator, as well as modular objects that store their data in the DB.

Public methods:

Protected methods:

13.3 Data cell (TCfg)

Inherits: TVariant

Data:
Additional flags to #TFld (enum — TCfg::AttrFlg):

Requests flags (enum — ReqFlg):

Public methods:

13.4 Data structure object (TElem)

Inherited: By the TTypeParam, TControllerS, TTypeDAQ, as well as by the modular objects, combining the functions of the structure storage .

Public methods:

13.5 Data structure cell (TFld)

Data:
Cell's type (enum – TFld::Type):

Cell's flags (enum — TFld::AttrFlg):

Public methods:

13.6 The object which preacts about changing of the structure (TValElem)

Inherited: TValue, TConfig

Protected methods:

13.7 Data cell (TVariant)

Data:
Error values for the different data types (definition):

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

Public methods:

13.8 User object (TVarObj)

Inherited: TArrayObj

Public methods:

14 Інтерфейс Управління та динамічне дерево об'єктів програми (TCntrNode)

Для повного покриття ключових компонентів програми мережею об'єктів єдиної структури призначено об'єкт вузла динамічного дерева #TCntrNode. На цей об'єкт покладаються наступні функції:

Будь який об'єкт, що має необхідність у наданні динамічного доступу до себе або своїх компонентів, має успадковуватися від об'єкту вузла динамічного дерева #TCntrNode. Така спорідненість автоматично включає вузол до динамічного дерева об'єктів, яке охоплене як прямим, так і зворотнім зв'язком, а також надає можливість створення контейнерів під власні дочірні вузли. На додаток до цього, вузол отримує можливість попередження про включення та виключення/видалення вузла із дерева з можливістю відхилення виключення/видалення.

Інтерфейс Управління включено до складу об'єкту #TCntrNode та він охоплює всі вузли динамічного дерева програми, дозволяючи одноманітно керувати програмою незалежно від використаного клієнтського інструменту. Інтерфейс Управління виконано на основі мови розмітки XML та до якого можна придумати багато способів щодо використання, наприклад, відзначимо наступні найбільш показові рішення:

Інтерфейс Управління реалізовано посередництвом складових:

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

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

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

Загальний Інтерфейс Управління будується із окремих вузлів динамічного дерева. Ієрархічне спадкування від об'єкту #TCntrNode дозволяє реалізовувати багаторівневе доповнення конфігурації Інтерфейсу Управління. Вигляд динамічного дерева вузлів наведено на рисунку 8.

Fig.8. Приклад динамічного дерева вузлів в OpenSCADA.

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

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

14.1 Синтаксис запиту та відповіді Інтерфейсу Управління

Весь обмін із Інтерфейсом Управління відбувається посередництвом мови XML. При цьому, внутрішній обмін виконується розібраною структурою мови XML, а зовнішній — посередництвом перетворення у потік символів суцільного XML-файлу та назад.

Запит виконується посередництвом надсилання тегу з параметрами в атрибутах. Результат поміщається до отриманого тегу зі зміною деяких атрибутів. У загальному випадку тег запиту можна записати <{req} path="{path}" user="{user}">{text}</{req}>. Де:

Результат запиту маркується у відповіді встановленням атрибуту rez в значення: 0-вдалий, 1-попередження, 2-помилка. У випадку помилки повідомлення записується до тексту text тегу та атрибуту mcat (категорія повідомлення) — <{req} path="{path}" user="{user}" rez="2" mcat="/sub_DAQ/mod_BlockCalc">Неможливо видалити вузол</{req}>. У випадку попередження повідомлення записується до атрибуту "mtxt" та атрибуту mcat (категорія повідомлення) зі збереженням основних даних тегу — <{req} path="{path}" user="{user}" rez="1" mcat="/sub_DAQ/mod_BlockCalc" mtxt="Перезапустити після операції!">{основні дані}</{req}>.

Запит групування "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 Запит інформаційної структури контролю — <info user='{user}' lang='{lang}' path='{path}' />

Інформаційний запит повертає ієрархічну структуру конфігурації, що надає вузол. Запит зазвичай не містить атрибуту шляху "path" та розповсюджується на весь вузол, хоча у складних випадках запиту частини інформаційного дерева можна вказувати шлях елементу гілки від якої отримувати конфігурацію.

У результаті запиту буде отримано інформаційну структуру сторінки відповідно до привілеїв користувача запиту — поля якої вважаються уніфікованими та описані нижче щодо специфіки інформації тут, а також доступних команд. Усе поза уніфікацією вважається сервісними запитами зі специфічною структурою, які відповідно описано у розділі сервісних функцій.

Теги інформаційних елементів передбачають обов'язкові атрибути:

  • 0 — доступ взагалі відсутній, поля видаляються з такими правами;
  • 4 (SEC_RD) — доступ на читання;
  • 2 (SEC_WR) — доступ на запис, зазвичай таке значення не має сенсу, оскільки доступ на запис передбачає і доступ на читання;
  • 6 (SEC_RD|SEC_WR) — доступ на читання та запис.
At.png Тобто, молодші три біти числа атрибуту "acs" містять актуальний доступ визначеного користувача, а наступні три біти (3..5) містять максимально можливі права, наприклад, 064(52) — максимальний повний доступ та актуальний лише на читання.

Таблиця. Таблиця всіх можливих елементів у структурі.

Тег (вміст) Опис
oscada_cntr

(img, branches, area)

Представляє вузол в цілому, який, єдиний — є КОРЕНЕМ і включається безпосередньо у тег info та містить інформаційні теги елементів і полів. Атрибути:
  • id — НЕМАЄ;
  • dscr — визначає локалізований опис вузла;
  • doc — адреса сторінки документації цього вузла у вигляді "{WikiPage}|{OffLinePage}".

At.png Тег img безпосередньо у цьому має бути одним, із ідентифікатором (id) "ico" та він представляє іконку сторінки.

branches

(grp)

Контейнер груп дочірніх гілок вузла. Атрибути:
  • id — ідентифікатор контейнеру, ЗАВЖДИ "br";
  • dscr — НЕМАЄ.
grp Група дочірніх вузлів. Атрибути:
  • id — префікс групи дочірніх вузлів у програмі;
  • dscr — визначає локалізований опис групи вузлів;
  • acs — доступ: SEC_RD — видимість (get), SEC_WR — додання (add) та видалення (del) елементів групи.
  • idm — ознака наявності назви у елементів групи та дозволений розмір назви за значення > 1;
  • idSz — дозволений розмір ідентифікаторів елементів.
area

(area, fld, list, table, comm, img)

Візуальні області. Сторінка із кінцевими елементами-полями конфігурації має містити хоча-б одну область візуального відображення тегом, де перші за ієрархією у конфігураторах це вкладки, а решта то вкладені групи. Атрибути:
  • acs — доступ: SEC_RD — видимість.
comm

(fld)

Команди до вузла. Надається для передавання команд та дій до вузла, а також може бути використане для створення посилань на інші сторінки. Команди можуть включати параметри-аргументи, які описано із "fld". Атрибути:
  • acs — доступ: SEC_RD — видимість, SEC_WR — виклик команд (set);
  • help — допомога команди;
  • tp — тип команди, відсутній для звичайних команд або "lnk" для посилань (get для SEC_RD).
fld Представлення та введення стандартних типів даних. Атрибути:
  • acs — доступ: SEC_RD — видимість (get), SEC_WR — модифікація (set);
  • help — допомога до поля;
  • tp — тип елементу:
    • "str" (len, dest, cols, rows) — елемент рядку;
    • "dec" (len, max, min, dest) — елемент десяткового цілого;
    • "oct" (len, max, min, dest) — елемент вісімкового цілого;
    • "hex" (len, max, min, dest) — елемент шістнадцяткового цілого;
    • "real" (len, max, min, dest) — реальне число;
    • "bool" — логічна-дискретна ознака [0|1];
    • "time" — час-дата в секундах, від 01/01/1970.

Пов'язане:

  • len — довжина значення у символах;
  • min — мінімум значення;
  • max — максимум значення;
  • cols — обмеження кількості стовпчиків;
  • rows (SnthHgl) — мінімальна кількість рядків, > 1 вказує текстові поля із правилами підсвітлення синтаксису за "SnthHgl";
  • dest — метод введення:
    • "select" (select або sel_list, sel_id) — вибірний тип;
    • "sel_ed" (select або sel_list, sel_id) — вибірний тип із можливістю редагування.
  • select — шлях запиту динамічного переліку вибору (get);
  • sel_list — статичний перелік імен, поділено ';';
  • sel_id — статичний перелік ідентифікаторів до імен у "sel_list", поділено ';';
  • SnthHgl — ознака наявності правил підсвітлення синтаксису для текстових полів, отримання правил командою SnthHgl.
list Перелік стандартних типів даних. Атрибути:
  • acs — доступ: SEC_RD — видимість (get), SEC_WR — виклик команд із "s_com" (add, ins, del, edit, move);
  • help — допомога до переліку;
  • tp — так само як у fld окрім:
    • "br" (br_pref) — дочірні вузли.
  • idm — ознака індексованого (із ідентифікаторами) переліку (0|1);
  • idSz — допустимий розмір ідентифікаторів елементів;
  • s_com — шляхи модифікації переліку зі списку "[add][,ins][,edit][,del][,move]":
    • "add" — додання рядків;
    • "ins" — вставка рядків;
    • "edit" — модифікація рядків;
    • "del" — видалення рядків;
    • "move" — пересування рядків.

Пов'язане:

  • br_pref — префікс репрезентації дочірніх вузлів;
  • dest — так само як у fld.
table

(list)

Таблиця стандартних типів даних. Атрибути:
  • acs — доступ: SEC_RD — видимість (get), SEC_WR — виклик команд із "s_com" (add, ins, del, move, {user}) та дозвіл зміни вмісту клітинки (set);
  • help — допомога до таблиці;
  • key — перелік ключових стовпців, якщо атрибут визначено та він перелічує стовпці, то дії із таблицею переводяться у режим адресування за значеннями визначених стовпців як ключа.
  • rows — мінімальна висота таблиці у рядках;
  • s_com — шляхи модифікації переліку зі списку "[add][,ins][,del][,move][,{user}]":
    • "add[:{CustName}]" — додання рядків, із користувацькою назвою елементу меню "CustName";
    • "ins[:{CustName}]" — вставка рядка, із користувацькою назвою елементу меню "CustName";
    • "del[:{CustName}]" — видалення рядка, із користувацькою назвою елементу меню "CustName";
    • "move" — пересування рядка;
    • "{user}[:{name}]" — користувацька команда user до рядка або таблиці в цілому із назвою елементу меню "name".
img Зображення. Надається для передавання зображень клієнтам Інтерфейсу Управління. У якості зображень можуть бути: іконки сторінок, діаграми та інші дані, що можуть бути представлені у графічній формі. Атрибути:
  • acs — доступ: SEC_RD — видимість (get), SEC_WR — доступний до завантаження та очищення (set);
  • help — допомога до зображення;
  • h_sz — обмеження горизонтального розміру;
  • v_sz — обмеження вертикального розміру.

Комплексний приклад інформаційної структури: 

<info lang="uk" user="roman" rez="0"><oscada_cntr acs="36" dscr="OpenSCADA станція: &quot;АГЛКС&quot;" doc="Program_manual|Documents/Program_manual">
  <branches id='br'>
    <grp id='in_' descr='Вхідний транспорт' acs='52' idSz='30' idm='50'/>
    <grp id='out_' descr='Вихідний транспорт' acs='52' idSz='30' idm='50'/>
  </branches>
  <img id="ico" acs="36" />
  <area id="gen" acs="36" dscr="Станція">
    <fld id="id" acs="36" dscr="Станція" tp="str" help="Ідентифікатор" />
    <fld id="stat" acs="54" tp="str" help="Ім'я" />
    <fld id="config" acs="36" dscr="Конфігураційний файл" tp="str" />
    <fld id="workdir" acs="36" dscr="Робоча тека" tp="str" dest="sel_ed" select="/gen/workDirList" />
    <fld id="moddir" acs="36" dscr="Тека модулів" tp="str" dest="sel_ed" select="/gen/modDirList" />
    <area id="env" acs="36" dscr="Оточення">
      <fld id="prog" acs="36" dscr="Програма" tp="str" />
      <fld id="sys" acs="36" dscr="Система" tp="str" len="30" />
      <fld id="time" acs="36" dscr="Системний час" tp="str" />
      <fld id="clk" acs="36" dscr="Системний годинник планування" tp="str" />
      <fld id="user" acs="36" dscr="Системний користувач" tp="str" />
      <fld id="in_charset" acs="36" dscr="Мова" tp="str" help="Системне кодування локалі." />
      <fld id="lang" acs="54" tp="str" dest="sel_ed" sel_list="en_US.UTF-8;uk_UA.UTF-8;ru_RU.UTF-8"
           help="Повна інформація щодо локалі із мовою, країною та кодуванням у вигляді &quot;uk_UA.UTF-8&quot;." />
      <fld id="host" acs="36" dscr="Ім'я хосту" tp="str" />
      <fld id="CPU" acs="36" dscr="ЦП" tp="str" />
      <fld id="mainCPUs" acs="54" tp="str"
           help="Основний набір процесорів.&#010;Для встановлення використовуваних процесорів записуйте рядок номерів, поділених символом &#039;:&#039;.&#010;
Номера процесорів починаються з 0." />
      <fld id="taskInvPhs" acs="54" dscr="Кількість фаз виклику задач" tp="dec"
           help="Для встановлення фазування виклику завдань у визначену кількість фаз,&#010; &lt;= 0 для встановлення оптимально, 1 для вимкнення фазування задач." />
    </area>
  </area>
  <area id="subs" acs="54" dscr="Підсистеми">
    <list id="br" acs="36" dscr="Підсистеми" idm="1" tp="br" br_pref="sub_" />
  </area>
  <area id="arch" acs="54" dscr="Архіви">
    <table id="arch" acs="36" dscr="Архіви">
      <list id="0" acs="36" dscr="Архів" tp="str" />
      <list id="1" acs="36" dscr="Період, секунд" tp="real" />
      <list id="2" acs="36" dscr="Розмір буферу" tp="dec" />
      <list id="3" acs="36" dscr="Останнє читання буферу" tp="str" />
      <list id="4" acs="36" dscr="Розмір файлів" tp="str" />
    </table>
    <comm id="exp" acs="54" dscr="Експорт">
      <fld id="arch" acs="54" dscr="Архів" tp="str" dest="select" select="/arch/lst" />
      <fld id="beg" acs="54" dscr="Початок" tp="time" />
      <fld id="end" acs="54" dscr="Кінець" tp="time" />
      <fld id="tfl" acs="54" dscr="Тип" tp="str" dest="select" select="/arch/tpflst" />
      <fld id="file" acs="54" dscr="До файлу" tp="str" />
    </comm>
  </area>
</oscada_cntr></info>

14.3 Надсилання команд стандартних елементів — <{cmd} path='{path}'>{text}</{cmd}>

Кінцеві конфігураційні поля надають декілька команд, починаючи із запиту динамічної інформації та завершуючи командами контролю. Всі ці команди може бути використано у ваших внутрішніх процедурах незалежно від запиту інформаційної структури та для гнучкого керування OpenSCADA як локально, так і віддалено у будь ієрархії, за допомогою функції Користувацького API SYS.cntrReq().

Окрім опису уніфікованих команд, для стандартних елементів вам може знадобитися лише шлях цього елементу та який ви можете отримати у будь якому конфігураторі OpenSCADA, що відображає шлях у рядку статусу або контекстній допомозі. At.png Будь яка неуніфікована поведінка окремих стандартних полів передбачає сервісні запити та про які ви можете дізнатися у секції сервісних функцій!

14.3.1 Конфігураційне поле — "fld"

Отримання даних
ЗАП: <get path="{path}" />
ВІДП: <get path="{path}" rez="0">{value}</get> 

<get path="/sub_Security/usr_user/%2fprm%2fDESCR" rez="0" user="root">Простий користувач</get>

Встановлення поля
ЗАП: <set path="{path}">{value}</set> 

<set path="/sub_Security/usr_user/%2fprm%2fDESCR">Перейменований користувач</set>

Отримання правил підсвітлення синтаксису текстового поля
Доступне за встановлення атрибуту "SnthHgl" у відповідному інформаційному полі.
ЗАП: <SnthHgl path="{path}" />
ВІДП: <SnthHgl path="{path}" rez="0">{rules tree}</get> 

<SnthHgl font="monospace" path="/sub_DAQ/tmplb_base/tmpl_anUnif/%2fio%2fprog" rez="0" user="root">
  <rule color="darkgreen" expr="(&quot;(|\\{2}|\\{4}|\\{6}|\\{8})&quot;|&quot;.*[^\\](|\\{2}|\\{4}|\\{6}|\\{8})&quot;)" min="1">
    <rule color="green" expr="\\([xX][a-zA-Z0-9]{2}|[0-7]{3}|.{1})" font_weight="1" />
  </rule>
  <blk beg="/\*" color="gray" end="\*/" font_italic="1" />
  <rule color="gray" expr="//.*$" font_italic="1" />
  <rule color="darkblue" expr="\b(if|else|for|while|using|new|delete|break|continue|return|function|Array|Object|RegExp)\b" font_weight="1" />
  <rule color="darkblue" expr="\b(var|in)(?=\s+\w)" font_weight="1" />
  <rule color="darkblue" expr="(\?|\:)" font_weight="1" />
  <rule color="darkorange" expr="\b(0[xX][0-9a-fA-F]*|[0-9]*\.?[0-9]+|[0-9]*\.?[0-9]+[eE][-+]?[0-9]*|true|false)\b" />
  <rule color="darkblue" expr="(\=|\!|\+|\-|\&gt;|\&lt;|\*|\/|\%|\||\&amp;|\^|\~)" font_weight="1" />
  <rule color="blue" expr="(\;|\,|\{|\}|\[|\]|\(|\))" />
</SnthHgl>

14.3.2 Поле переліку — "list"

Отримання даних
ЗАП: <get path="{path}" />
ВІДП: <get path="{path}" rez="0">{elements list}</get> 

<get path="/sub_BD/mod_SQLite/%2fdb%2fodb" rez="0" user="root">
  <el id="GenDB">Основна БД</el>
  <el id="OscadaLibs">OscadaLibs</el>
  <el id="vcaBase">vcaBase</el>
  <el id="vcaElectroEls">vcaElectroEls</el>
  <el id="vcaTest">vcaTest</el>
</get>

Додання елементу
Дозволено за "add" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <add path="{path}" id="{itId}">{itName}</add> 

  <add path="/sub_BD/mod_SQLite/%2fdb%2fodb" id="test">Тест</add>

Вставка елементу
Дозволено за "ins" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <ins path="{path}" pos="{pos}" p_id="{posId}" id="{itId}">{itName}</ins> 

  <ins path="/sub_BD/mod_SQLite/%2fdb%2fodb" pos="1" p_id="OscadaLibs" id="test">Test</ins>

Видалення елементу
Дозволено за "del" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <del path="{path}" pos="{pos}" id="{itId}">{itName}</del> 

  <del path="/sub_BD/mod_SQLite/%2fdb%2fodb" id="test" />

Редагування елементу
Дозволено за "edit" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <edit path="{path}" pos="{pos}" p_id="{posId}" id="{itId}">{itName}</edit> 

  <edit path="/sub_BD/mod_SQLite/%2fdb%2fodb" p_id="test" id="test1">Тест 1</edit>

Переміщення елементу
Дозволено за "move" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <move path="{path}" pos="{pos}" to="{toPos}" /> 

  <move path="/sub_BD/mod_SQLite/%2fdb%2fodb" pos="5" to="4" />

14.3.3 Поле таблиці — "table"

Отримання даних
ЗАП: <get path="{path}" />
ВІДП: <get path="{path}" rez="0">{elements lists}</get> 

<get path="/sub_DAQ/tmplb_base/tmpl_digitBlockUnif/%2fio%2fio" rez="0" user="root">
  <list acs="54" id="0">
    <el>com</el>
    <el>close</el>
    <el>stop</el>
    <el>st_open</el>
    <el>st_close</el>
    <el>tCmd</el>
    <el>last_cmd</el>
    <el>w_tm</el>
  </list>
  <list acs="54" id="1">
    <el>Команда "Відкрити"</el>
    <el>Команда "Закрити"</el>
    <el>Команда "Стоп"</el>
    <el>Стан "Відкрито"</el>
    <el>Стан "Закрито"</el>
    <el>Час утримання команди, секунди</el>
    <el>Остання команда</el>
    <el>Лічильник обробки команди</el>
  </list>
  <list acs="54" id="2">
    <el>3</el>
    <el>3</el>
    <el>3</el>
    <el>3</el>
    <el>3</el>
    <el>1</el>
    <el>1</el>
    <el>2</el>
  </list>
  <list acs="54" id="3">
    <el>1</el>
    <el>1</el>
    <el>1</el>
    <el>0</el>
    <el>0</el>
    <el>0</el>
    <el>1</el>
    <el>1</el>
  </list>
  <list acs="54" id="4">
    <el>32</el>
    <el>32</el>
    <el>32</el>
    <el>16</el>
    <el>16</el>
    <el>0</el>
    <el>0</el>
    <el>0</el>
  </list>
  <list acs="54" id="5">
    <el>128</el>
    <el>128</el>
    <el>128</el>
    <el>128</el>
    <el>128</el>
    <el>64</el>
    <el>0</el>
    <el>0</el>
  </list>
  <list acs="54" id="6">
    <el>Кран|com</el>
    <el>Кран|close</el>
    <el>Кран|stop</el>
    <el>Кран|st_open</el>
    <el>Кран|st_close</el>
    <el>5</el>
    <el>0</el>
    <el>0</el>
  </list>
</get>

Встановлення значення клітинки визначеного рядка та стовпчика
Дозволено за прав SEC_WR.
ЗАП: <set path="{path}" row="{row}" key_{keyId}="{keyVal}" col="{colId}">{value}</set>

<set path="/sub_DAQ/tmplb_base/tmpl_digitBlockUnif/%2fio%2fio" row="3" col="1">Стан "Відкрито" 1</set>

Додання рядка
Дозволено за "add" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <add path="{path}" />

<add path="/sub_DAQ/tmplb_base/tmpl_digitBlockUnif/%2fio%2fio" />

Вставка рядка
Дозволено за "ins" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <ins path="{path}" row="{row}" /> 

<ins path="/sub_DAQ/tmplb_base/tmpl_digitBlockUnif/%2fio%2fio" row="3" />

Видалення рядка
Дозволено за "del" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <del path="{path}" row="{row}" key_{keyId}="{keyVal}" /> 

<del path="/sub_DAQ/tmplb_base/tmpl_digitBlockUnif/%2fio%2fio" row="3" />

Переміщення рядка
Дозволено за "move" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <move path="{path}" row="{row}" to="{toRow}" /> 

<move path="/sub_DAQ/tmplb_base/tmpl_digitBlockUnif/%2fio%2fio" row="12" to="3" />

Користувацька команда до рядка
Дозволено за "{user}" у атрибуті "s_com" відповідного інформаційного поля.
ЗАП: <{user} path="{path}" row="{row}" key_{keyId}="{keyVal}" /> 

<remTrs path="/%2ftr%2fmess" key_base="BaseMess" />

14.3.4 Поле зображення — "img"

Отримання даних
ЗАП: <get path="{path}" />
ВІДП: <get path="{path}" rez="0" tp="{dataType}">{Base64 data}</get> 

<get path="/sub_DAQ/%2fico" rez="0" tp="png" user="root">iVBORw0KGgoAAAANSUhEUgAAA...AABJRU5ErkJggg==</get>

Встановлення даних
Дозволено за прав SEC_WR.
ЗАП: <set path="{path}">{Base64 data}</set> 

<set path="/sub_DAQ/%2fico">iVBORw0KGgoAAAANSUhEUgAAA...AABJRU5ErkJggg==</set>

14.3.5 Поле команди — "comm"

Отримання значення посилання
Актуальне лише для посилань — атрибут "tp" це "lnk" відповідного інформаційного поля.
ЗАП: <get path="{path}" />
ВІДП: <get path="{path}" rez="0">{lnkVal}</get> 

<get path="/sub_DAQ/mod_DAQGate/cntr_test/%2fcntr%2fcfg%2fhost_lnk" lang="uk" user="roman" rez="0">/Transport</get>

Виклик команди
Дозволено за прав SEC_WR.
ЗАП: <set path="{path}">{fields}</set>

<set path="/sub_Archive/mod_FSArch/val_1s/%2farch%2fexp" lang="uk">
  <fld id="arch">CPULoad_load</fld>
  <fld id="beg">1673942400</fld>
  <fld id="end">1673944800</fld>
  <fld id="tfl">ascii</fld>
  <fld id="file">testComm</fld>
</set>

14.4 Сервісні команди-функції

Сервісні функції — це інтерфейс доступу до OpenSCADA із зовнішніх систем посередництвом Інтерфейсу Управління. Цей механізм покладено в основу усього обміну всередині OpenSCADA, реалізованого шляхом слабких зв'язків та власного протоколу обміну OpenSCADA. Основною його перевагою є пріоритетна обробка та можливість використання нестандартного пакування даних. Для доступу до звичайних даних можна використовувати стандартні команди Інтерфейсу Управління.

At.png Не всі сервісні функції-запити тут описано, тож для ознайомлення з усіма наявними або деталізації, ви маєте поглянути в функцію cntrCmdProc() відповідних частин OpenSCADA у вихідних кодах проєкту.

14.4.1 Кореневий Вузол та загальне для всіх вузлів

Отримання загального статусу резервування станції
ЗАП: <st path="/%2fserv%2fredundant" />
ВІДП: <st path="/%2fserv%2fredundant" rez="0" StLevel="{lev}" />

Сканування конфігураційного файлу
ЗАП[root-root]: <scan path="/%2fgen%2fconfig" />

Запити вузла-об'єкту

Отримання прапорця модифікації вузла
ЗАП: <modify path="/{nPath}/%2fobj" />
  • nPath — шлях до потрібного вузла.
ВІДП: <modify path="/{nPath}/%2fobj" rez="0">{flag}</modify>
  • flag — статус-прапорець модифікації вузла, для деталей дивіться перелічення TCntrNode::ModifFlag.
<modify path="/Security/user/%2fobj" rez="0" user="roman">1</modify>
Завантаження вузла
ЗАП: <load path="/{nPath}/%2fobj" force="{force}">{CfgCtx}</load>
  • nPath — шлях до потрібного вузла;
  • force — прапорець примусового завантаження [0|1], вузол може бути не позначеним модифікованим;
  • CfgCtx — конфігураційний контекст у тегах "fld" для завантаження із нього, використовується для віддаленого копіювання конфігурації вузла.
Збереження вузла
ЗАП: <save path="/{nPath}/%2fobj" force="{force}" ctx="{toCfgCtx}" />
  • nPath — шлях до потрібного вузла;
  • force — прапорець примусового збереження [0|1], вузол може бути не позначеним модифікованим;
  • toCfgCtx — ознака [0|1] збереження конфігурації вузла до конфігураційного контексту, використовується для віддаленого копіювання конфігурації вузла.
ВІДП: <save path="/{nPath}/%2fobj" force="{force}" ctx="{toCfgCtx}" rez="0">{CfgCtx}</save>
Локальне копіювання визначеного вузла
ЗАП: <copy path="/{nPath}/%2fobj" src="{source}" dst="{destination}" />
  • nPath — шлях до потрібного вузла, у цій операції може бути будь яким вузлом;
  • source — шлях до вузла джерела;
  • destination — шлях до вузла призначення.
Отримання дочірніх вузлів визначеного вузла, оптимізовано для мереж
ЗАП: <chlds path="/{nPath}/%2fobj" grp="{group}" icoCheck="{icoCheck}" />
  • nPath — шлях до потрібного вузла;
  • group — група-префікс дочірніх вузлів;
  • icoCheck — ознака [0|1] лише перевірки наявності піктограми встановленням атрибуту "icoSize".
ВІДП: <chlds path="/{nPath}/%2fobj" grp="{group}" icoCheck="{icoCheck}" rez="0">{nodes}</chlds>
  • nodes — вузли у тегах "el", де ім'я у тексті тегу та ідентифікатор у атрибуті "id" для вузлів із ідентифікаторами; теги "el" містять додаткові теги і атрибути:
    • ico — тег із даними іконки при невстановленні "icoCheck";
    • icoSize — розмір піктограми вузла за її наявності та встановленні "icoCheck";
    • grp — теги груп дочірніх вузлів із додатковими атрибутами:
      • chPresent — ознака наявності дочірніх вузлів для групи.
<chlds grp="mod_" icoCheck="1" path="/Transport/%2fobj" rez="0" user="roman">
  <el icoSize="10348" id="Sockets">Сокети
    <grp acs="54" chPresent="1" dscr="Вхідний транспорт" id="in_" idSz="20" idm="100" />
    <grp acs="54" chPresent="1" dscr="Вихідний транспорт" id="out_" idSz="20" idm="100" />
  </el>
  <el icoSize="7148" id="Serial">Послідовні інтерфейси
    <grp acs="54" chPresent="1" dscr="Вхідний транспорт" id="in_" idSz="20" idm="100" />
    <grp acs="54" chPresent="1" dscr="Вихідний транспорт" id="out_" idSz="20" idm="100" />
  </el>
  <el icoSize="8944" id="SSL">SSL
    <grp acs="54" chPresent="1" dscr="Вхідний транспорт" id="in_" idSz="20" idm="100" />
    <grp acs="54" chPresent="1" dscr="Вихідний транспорт" id="out_" idSz="20" idm="100" />
  </el>
</chlds>

Загальні переліки

Отримання переліку БД або таблиць
ЗАП: <get path="/{nPath}/%2fdb%2flist[:onlydb]" />
<get path="/{nPath}/%2fdb%2ftblList[:onlydb]" />
  • nPath — шлях до потрібного вузла, у цій операції може бути будь яким вузлом;
  • "onlydb" — доповнення адреси для вказання на перелічення лише баз даних без групових маркувань.
ВІДП: <get path="/{nPath}/%2fdb%2flist[:onlydb]" rez="0">{list}</get>
<get path="/{nPath}/%2fdb%2ftblList[:onlydb]" rez="0">{list}</get>
  • list — елементи у тегах "el".
<get path="/%2fdb%2flist:onlydb" rez="0" user="roman">
  <el>SQLite.vcaTest</el>
  <el>SQLite.vcaBase</el>
  <el>SQLite.vcaAGLKS</el>
  <el>MySQL.vcaTest</el>
  <el>MySQL.vcaBase</el>
  <el>PostgreSQL.testRelease</el>
  <el>PostgreSQL.test</el>
  <el>FireBird.testRelease</el>
  <el>FireBird.testFB</el>
  <el>FireBird.arch</el>
  <el>DBF.testRelease</el>
</get>
Отримання переліку підтримуваних внутрішніх мов програмування
ЗАП: <get path="/{nPath}/%2fplang%2flist" />
  • nPath — шлях до потрібного вузла, у цій операції може бути будь яким вузлом.
ВІДП: <get path="/{nPath}/%2fplang%2flist" rez="0">{list}</get>
  • list — елементи у тегах "el".
<get path="/%2fplang%2flist" rez="0" user="roman">
  <el />
  <el>JavaLikeCalc.JavaScript</el>
</get>

14.4.2 Підсистема "Бази Даних (DB)"

Надсилання SQL запиту до БД
ЗАП[root-BD]: <call path="/BD/{MOD}/{DB}/%2fserv%2fSQL" withRez="{withResult}" intoTrans="{intoTrans}">{request}</call>

ВІДП: <call path="/BD/{MOD}/{DB}/%2fserv%2fSQL" withRez="{withResult}" intoTrans="{intoTrans}" rez="0">{result}</call> 

<call path="/BD/SQLite/GenDB/%2fserv%2fSQL" rez="0" user="roman" withRez="1">
  <list>
    <el>user</el>
    <el>root</el>
    <el>root</el>
    <el>roman</el>
    <el>roman</el>
    <el>roman</el>
  </list>
  <list>
    <el>id</el>
    <el>/sub_Protocol/mod_HTTP/AuthTime</el>
    <el>/sub_Protocol/mod_HTTP/AutoLogin</el>
    <el>/sub_UI/mod_QTCfg/st</el>
    <el>/sub_UI/mod_VCAEngine/wdgAttr</el>
    <el>/sub_BD/mod_SQLite/ReqTm</el>
  </list>
  <list>
    <el>val</el>
    <el>10</el>
    <el>&lt;aLog&gt;&lt;it addrs="*" user="user" /&gt;&lt;/aLog&gt;</el>
    <el>1272:942:AAAA/wAAAAEAAAACAAABTwAABh8B/////wEAAAABAA==</el>
    <el>doc</el>
    <el>204us</el>
  </list>
</call>

Запит структури поля визначеної таблиці БД
ЗАП: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldStruct" tbl="{table}" />

ВІДП: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldStruct" tbl="{table}" rez="0">{structure}</call>

  • TP — тип клітинки, дивіться об'єкт #TFld;
  • FLAG — прапорці клітинки, дивіться об'єкт #TCfg;
  • LEN — повний розмір клітинки, дивіться lenS() об'єкту #TFld;
  • DEF — типове значення клітинки, дивіться def() об'єкту #TFld;
  • FView, FKeyUse, FNoTransl, FReqKey, FExtVal — динамічні прапорці об'єкту #TCfg: view(), keyUse(), noTransl(), reqKey(), extVal().
<call path="/BD/SQLite/GenDB/%2fserv%2ffieldStruct" rez="0" tbl="SYS" user="roman">
  <fld id_str="5:512:16777215.0::1:0:0:0:0" uk#val_str="5:0:16777215.0::1:0:0:0:0" user_str="5:512:16777215.0::1:0:0:0:0" val_str="5:0:16777215.0::1:0:0:0:0" />
</call>

Перебір-сканування полів визначеної таблиці БД
ЗАП: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldSeek" tbl="{table}" row="{row}" cacheKey="{cacheKey}">{field}</call>

ВІДП: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldSeek" tbl="{table}" row="{row}" cacheKey="{cacheKey}" rez="0" fRez="{fRez}">{field}</call> 

<call path="/BD/SQLite/GenDB/%2fserv%2ffieldSeek" tbl="SYS" row="5" cacheKey="0x7f17c8fcd5e0" user="roman" rez="0" fRez="1">
  <fld user="roman" user_str="5:512:16777215.0::1:0:0:0:0" 
       id="/sub_BD/mod_SQLite/ReqTm" id_str="5:512:16777215.0::1:0:0:0:0" 
       val="204us" val_str="5:0:16777215.0::1:0:0:0:0" uk#val_str="5:0:16777215.0::1:0:0:0:0" />
</call>

Отримання поля визначеної таблиці БД
ЗАП: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldGet" tbl="{table}">{field}</call>

ВІДП: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldGet" tbl="{table}" rez="0">{field}</call> 

<call path="/BD/SQLite/GenDB/%2fserv%2ffieldGet" rez="0" tbl="SYS" user="roman">
  <fld id="/sub_BD/mod_SQLite/ReqTm" id_str="5:512:16777215.0::1:0:0:0:0"
       user="roman" user_str="5:512:16777215.0::1:0:0:0:0"
       val="204us" val_str="5:0:16777215.0::1:0:0:0:0" uk#val_str="5:0:16777215.0::1:0:0:0:0" />
</call>

Встановлення поля визначеної таблиці БД
ЗАП[root-BD]: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldSet" tbl="{table}">{field}</call> 

<call path="/BD/SQLite/GenDB//%2fserv%2ffieldSet" tbl="SYS">
  <fld user_ext="roman" user_str="5:512:16777215.0::0:1:0:0:1"
       id_ext="/sub_BD/mod_SQLite/ReqTm" id_str="5:512:16777215.0::0:1:0:0:1"
       val="205us" val_str="5:0:16777215.0::1:0:0:0:0" />
</call>

Видалення поля визначеної таблиці БД
ЗАП[root-BD]: <call path="/BD/{MOD}/{DB}/%2fserv%2ffieldDel" tbl="{table}">{field}</call> 

<call path="/BD/SQLite/GenDB//%2fserv%2ffieldDel" tbl="SYS">
  <fld user="roman" user_str="5:512:16777215.0::0:1:0:0:0"
       id="/sub_BD/mod_SQLite/ReqTm" id_str="5:512:16777215.0::0:1:0:0:0" />
</call>

14.4.3 Підсистема "Збір Даних (DAQ)"

Отримання підсистемного статусу резервування станції
ЗАП: <st path="/DAQ/%2fserv%2fredundant" />
ВІДП: <st path="/DAQ/%2fserv%2fredundant" rez="0" inProc="1" StLevel="{lev}">{status}</st> 

<st StLevel="10" inProc="1" path="/DAQ/%2fserv%2fredundant" rez="0" user="roman">
  <cntr id="BlockCalc.CM101" run="1" />
  <cntr id="BlockCalc.CM102" run="1" />
  <cntr id="BlockCalc.CM102cntr" run="1" />
  ...
  <cntr id="ModBus.testTCP" run="1" />
  <cntr id="OPC_UA.test" run="1" />
  <cntr id="System.AutoDA" run="1" />
</st>

Отримання переліку параметрів та атрибутів Збору Даних для навігації
Запит відзеркалює функцію TDAQS::ctrListPrmAttr() у мережу.
ЗАП: <list path="/DAQ/%2fserv%2fPrmAttr" base="{base}" toPrm="{forPrm}" sep="{sep}" pref="{pref}" />

ВІДП: <list path="/DAQ/%2fserv%2fPrmAttr" base="{base}" toPrm="{forPrm}" sep="{sep}" pref="{pref}" rez="0">{prmAttrs}</list> 

<list base="BlockCalc.gen.F3" path="/DAQ/%2fserv%2fPrmAttr" pref="prm:" rez="0" sep="." toPrm="0" user="roman">
  <el>prm:</el>
  <el>prm:BlockCalc</el>
  <el>prm:BlockCalc.gen</el>
  <el>prm:BlockCalc.gen.F3</el>
  <el>=== Attributes ===</el>
  <el>prm:BlockCalc.gen.F3.SHIFR</el>
  <el>prm:BlockCalc.gen.F3.NAME</el>
  <el>prm:BlockCalc.gen.F3.DESCR</el>
  <el>prm:BlockCalc.gen.F3.err</el>
  <el>prm:BlockCalc.gen.F3.var</el>
</list>

Об'єкти контролеру

Отримання повідомлень пов'язаних із об'єктом контролеру
Це повідомлення, згенеровані джерелами даних та запитані TArchiveS::messGet() із відповідними категоріями джерела даних.
ЗАП: <get path="/DAQ/{MOD}/{CNTR}/%2fserv%2fmess" tm="{TmUNIX}" tm_grnd="{TmGrndUNIX}" lev="{level}" />
  • MOD, CNTR — модуль Збору Даних та об'єкт контролеру;
  • TmUNIX, TmGrndUNIX — мітка часу UNIX від 01.01.1970 для кінця та початку повідомлень; за нульового "tm" використовується або поточний час системи або час останнього резервованого повідомлення для резервованих систем;
  • level — мінімальний рівень запитуваних повідомлень, від 0[X] до 7[X].
ВІДП: <get path="/DAQ/{MOD}/{CNTR}/%2fserv%2fmess" tm="{TmUNIX}" tm_grnd="{TmGrnUNIX}" lev="{level}" rez="0">{messages}</get>
  • TmUNIX — встановлюється у час останнього резервованого повідомлення або системний - 1, за нуля у запиті;
  • messages — повідомлення у тегах "el": <el time="{time}" utime="{utime}" cat="{cat}" lev="{lev}">{mess}</el>
    • time — час повідомлення, як мітка часу UNIX від 01.01.1970;
    • utime — мікросекундна частина часу повідомлення;
    • cat — категорія повідомлення;
    • lev — рівень повідомлення;
    • mess — текст повідомлення.
<get lev="1" path="/DAQ/LogicLev/gen/%2fserv%2fmess" rez="0" tm="1674401446" tm_grnd="1674401300" user="roman">
  <el cat="alLogicLev:gen.F3" lev="-2" time="1674401357" utime="386070">
Загальностанційка &gt; F3: Витрати газу через трубу на Глінськ: Помилка нижньої поперджув. границі
  </el>
</get>
Встановлення повідомлення пов'язаного із об'єктом контролеру
Генерація-встановлення повідомлення джерела даних трансферного типу із запитом TController::messSet().
ЗАП: <set path="/DAQ/{MOD}/{CNTR}/%2fserv%2fmess" lev="{level}" type2Code="{type2Code}" prm="{prm}" cat="{cat}">{mess}</set>
  • MOD, CNTR — модуль Збору Даних та об'єкт контролеру;
  • level — рівень повідомлення;
  • type2Code — двосимвольний ІД трансферного повідомлення у категорії;
  • prm — ідентифікатор параметру джерела, який може бути доповнений відповідним ІД атрибуту у вигляді "{PrmID}.{AttrId}";
  • cat — доповнення до уніфікованої категорії із інформацією про користувача та подібне;
  • mess — текст повідомлення із адресою ім'ям перед ним.
<set path="/DAQ/LogicLev/gen/%2fserv%2fmess" lev="1" type2Code="OP" prm="F3" cat="roman">Значення змінене : 0 : 1</set>

Параметри Збору Даних (DAQ)

Отримання переліку атрибутів параметру Збору Даних (#TValue) із детальною інформацією
ЗАП: <list path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2fattr" />
  • MOD, CNTR, PRM — модуль Збору Даних, об'єкт контролеру та параметри.
ВІДП: <list path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2fattr" rez="0">{attributes}</list>
  • attributes — атрибути у тегах "el" із детальною інформацією: <el id="{id}" nm="{name}" tp="{type}" flg="{flags}" vals="{values}" names="{names}" />
    • id — ідентифікатор атрибуту;
    • name — назва атрибуту;
    • type — тип атрибуту, дивіться типи в об'єкті #TFld;
    • flags — прапорці атрибуту, дивіться прапорці в об'єкті #TVal;
    • values — значення атрибуту для вибірних типів;
    • names — назви значень для вибірних типів.
<list path="/DAQ/LogicLev/gen/prm_F3/%2fserv%2fattr" rez="0" user="roman">
  <el flg="516" id="SHIFR" nm="Ідентифікатор" tp="5" />
  <el flg="16" id="NAME" nm="Ім&#039;я" tp="5" />
  <el flg="24" id="DESCR" nm="Опис" tp="5" />
  <el flg="260" id="err" nm="Помилка" tp="5" />
  <el flg="772" id="var" nm="Змінна" tp="4" />
  <el flg="784" id="ed" nm="Одиниця виміру" tp="5" />
  <el flg="768" id="min" nm="Шкала: мінімум" tp="4" />
  <el flg="768" id="max" nm="Шкала: максимум" tp="4" />
  <el flg="768" id="scSqr" nm="Шкала: квадратична" tp="0" />
  <el flg="769" id="subMode" names="немає;останнє;підстановка" nm="Заміна: режим" tp="1" vals="0;1;2" />
  <el flg="768" id="subVar" nm="Заміна: змінна" tp="4" />
  <el flg="768" id="alSup" nm="Придушення порушень" tp="0" />
  <el flg="768" id="alDelay" nm="Затримка порушень, секунди" tp="4" />
  <el flg="768" id="alNormForceStart" nm="Примусове порушення НОРМА при запуску" tp="0" />
  <el flg="768" id="aMin" nm="Границя нижня аварійна" tp="4" />
  <el flg="768" id="aMax" nm="Границя верхня аварійна" tp="4" />
  <el flg="768" id="wMin" nm="Границя нижня попереджув." tp="4" />
  <el flg="768" id="wMax" nm="Границя верхня попереджув." tp="4" />
  <el flg="768" id="HystBnd" nm="Гистерезис порушення границь" tp="4" />
  <el flg="768" id="speed" nm="Швидкість зміни, %/цикл" tp="4" />
  <el flg="768" id="prec" nm="Точність, знаків" tp="1" />
  <el flg="768" id="log" nm="Логарифмічна шкала" tp="0" />
  <el flg="768" id="Tf" nm="Час фільтру, секунд" tp="4" />
</list>
Запит значень атрибутів параметру Збору Даних (#TValue)
Дуже загальний запит значень атрибутів із поточними значеннями та архівом-історією.
ЗАП: <get path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2fattr" sepReq="{sepReq}" hostTm="{hostTm}" prcTm="{prcTm}">{attributes}</get>
  • MOD, CNTR, PRM — модуль Збору Даних, об'єкт контролеру та параметри;
  • sepReq — ознака запиту атрибутів окремо [0|1];
  • hostTm — використовувати час хосту для поточних значень, тож не додавати атрибут "tm", [0|1];
  • prcTm — час опрацювання попереднього виклику, переважно використовується у резервуванні;
  • attributes — безпосередньо запитані атрибути у тегах:
    • "el": <el id="{id}" />
      • id — ідентифікатор атрибуту.
    • "ael" (для архіву-історії): <ael id="{id}" tm="{time}" />
      • time — час початку запиту архіву-історій у мікросекундах та частина секунд як мітка часу UNIX від 01.01.1970, тобто це час останнього значення від попереднього запиту.
ВІДП: <get path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2fattr" sepReq="{sepReq}" hostTm="{hostTm}" rez="0" prcTm="{prcTm}">{attributes}</get>
  • prcTm — системний час хосту, як мітка часу UNIX від 01.01.1970;
  • attributes — атрибути у тегах:
    • "el": <el id="{id}" tm="{time}">{value}</el>
      • time — час значення у мікросекундах та частина секунд як мітка часу UNIX від 01.01.1970;
      • value — поточне значення або на визначений час архіву у формі рядка.
    • "ael": <ael id="{id}" tm="{time}" per="{period}">{values}</ael>
      • period — періодичність архіву у мікросекундах;
      • values — значення архівної частини у тегах "v": <v>{value}</v>
    • "del" (лише для конфігурації нових динамічних): <del id="{id}" name="{name}" type="{type}" flg="{flags}" values="{values}" selNames="{names}" />
      • type — тип динамічного атрибуту, дивіться типи в об'єкті #TFld;
      • flags — прапорці динамічного атрибуту, дивіться прапорці в об'єкті #TVal;
      • values — значення динамічного атрибуту вибіркових типів;
      • names — назви значень для вибіркових типів динамічного атрибуту.
<get hostTm="1" path="/DAQ/LogicLev/gen/prm_F3/%2fserv%2fattr" prcTm="1674546677" rez="0" user="roman">
  <ael id="var" per="1000000" tm="1674546650000000">
    <v>45.1063015741995</v>
    <v>45.1021080127945</v>
    <v>45.0979561451232</v>
    <v>45.0938498037577</v>
  </ael>
  <el id="SHIFR">F3</el>
  <el id="NAME">F3</el>
  <el id="DESCR">Витрати газу через трубу на Глінськ</el>
  <el id="err">0</el>
  <el id="var">45.0139468054579</el>
  <el id="ed">т/год</el>
  <el id="min">0</el>
  <el id="max">100</el>
  <el id="scSqr">0</el>
  <el id="subMode">0</el>
  <el id="subVar">0</el>
  <el id="alSup">0</el>
  <el id="alDelay">0</el>
  <el id="alNormForceStart">0</el>
  <el id="aMin">10</el>
  <el id="aMax">90</el>
  <el id="wMin">35</el>
  <el id="wMax">80</el>
  <el id="HystBnd">0</el>
  <el id="speed">0</el>
  <el id="prec">2</el>
  <el id="log">0</el>
  <el id="Tf">2</el>
</get>
Встановлення значень багатьох атрибутів параметру Збору Даних (#TValue)
ЗАП[root-DAQ]: <set path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2fattr">{attributes}</set>
  • MOD, CNTR, PRM — модуль Збору Даних, об'єкт контролеру та параметри;
  • attributes — атрибути в тегах "el": <el id="{id}">{value}</el>
    • id — ідентифікатор атрибуту;
    • value — встановлюване значення у формі рядка.
<set path="/DAQ/LogicLev/gen/prm_F3/%2fserv%2fattr">
  <el id="ed">т/год</el>
  <el id="alDelay">1</el>
</set>

Атрибути параметру Збору Даних

Запит інформації атрибуту параметру Збору Даних (#TVal)
Переспрямування до запиту архіву "<info path='/Archive/va_{ARCH}/%2fserv%2fval' />" при зв'язувані із архівом, тож щодо додаткових атрибутів та результату дивіться там.
ЗАП: <info path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/a_{ATTR}/%2fserv%2fval" />
  • MOD, CNTR, PRM, ATTR — модуль Збору Даних, об'єкт контролеру, параметри та атрибут.
ВІДП: <info path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/a_{ATTR}/%2fserv%2fval" rez="0" end="0" beg="0" per="0" vtp="{valTp}" />
  • "0" — архівні параметри за відсутності архіву встановлюються у 0;
  • valTp — тип значення, дивіться до об'єкту #TFld.
<info beg="0" end="0" path="/DAQ/LogicLev/gen/prm_F3/a_ed/%2fserv%2fval" per="0" rez="0" user="roman" vtp="5" />
Запит значення атрибуту параметру Збору Даних (#TVal)
Переспрямування до запиту архіву "<get path='/Archive/va_{ARCH}/%2fserv%2fval' />" при зв'язувані із архівом, тож щодо додаткових атрибутів та результату дивіться там.
ЗАП: <get path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/a_{ATTR}/%2fserv%2fval" tm="{time}" />
  • MOD, CNTR, PRM, ATTR — модуль Збору Даних, об'єкт контролеру, параметри та атрибут;
  • time — час запитаного значення у мікросекундах та частина секунд як мітка часу UNIX від 01.01.1970; для нульового значення використовується системний поточний час та ви отримаєте поточне значення за відсутності архіву.
ВІДП: <get path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/a_{ATTR}/%2fserv%2fval" tm="{time}" rez="0">{value}</get>
  • time — встановлюється у час реально запитаного значення;
  • value — значення атрибуту.
<get path="/DAQ/LogicLev/gen/prm_F3/a_var/%2fserv%2fval" rez="0" tm="1675449270029270" user="roman">45.141100502986</get>
Запит назви атрибуту для архіву зв'язаного із ним
ЗАП: <name path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/a_{ATTR}/%2fserv%2fval" />
  • MOD, CNTR, PRM, ATTR — модуль Збору Даних, об'єкт контролеру, параметри та атрибут.
ВІДП: <name path="/DAQ/{MOD}/{CNTR}/prm_{PRM}[/prm_{PRM}]/a_{ATTR}/%2fserv%2fval" rez="0">{name}</get>
  • name — назва архіву.
<name path="/DAQ/LogicLev/gen/prm_F3/a_var/%2fserv%2fval" rez="0" user="roman">F3.Змінна</name>
14.4.3.1 Модуль JavaLikeCalc

Отримання значень ВВ функції об'єкту контролеру
ЗАП: <get path="/DAQ/JavaLikeCalc/{CNTR}/%2fserv%2ffncAttr" />

ВІДП: <get path="/DAQ/JavaLikeCalc/{CNTR}/%2fserv%2ffncAttr" rez="0">{IOs}</get> 

<get path="/DAQ/JavaLikeCalc/testCalc/%2fserv%2ffncAttr" rez="0" user="roman">
  <a id="f_frq">0.1</a>
  <a id="f_start">0</a>
  <a id="f_stop">0</a>
  <a id="this">&lt;TCntrNodeObj path="/sub_DAQ/mod_JavaLikeCalc/cntr_testCalc/"/&gt;</a>
  <a id="offset">100</a>
  <a id="out">50</a>
  <a id="test">1</a>
  <a id="rez" />
  <a id="inFarg">3</a>
</get>

Встановлення значень ВВ функції об'єкту контролеру
ЗАП[root-DAQ]: <set path="/DAQ/JavaLikeCalc/{CNTR}/%2fserv%2ffncAttr">{IOs}</set> 

<set path="/DAQ/JavaLikeCalc/testCalc/%2fserv%2ffncAttr">
  <a id="out">50</a>
  <a id="test">1</a>
</set>


14.4.3.2 Модуль LogicLev

Отримання значень ВВ шаблону параметру Логічного Рівня об'єкту контролеру
ЗАП: <get path="/DAQ/LogicLev/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2ftmplAttr" />

ВІДП: <get path="/DAQ/LogicLev/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2ftmplAttr" rez="0">{IOs}</get> 

<get path="/DAQ/LogicLev/gen/prm_F3/%2fserv%2ftmplAttr" rez="0" user="roman">
  <ta id="in">44.9998202036118</ta>
  <ta id="inProc" />
  <ta id="var">44.9999585116556</ta>
  <ta id="ed">ton/h</ta>
  <ta id="min">0</ta>
  <ta id="max">100</ta>
  <ta id="scSqr">0</ta>
</get>

Встановлення значень ВВ шаблону параметру Логічного Рівня об'єкту контролеру
ЗАП[root-DAQ]: <set path="/DAQ/LogicLev/{CNTR}/prm_{PRM}[/prm_{PRM}]/%2fserv%2ftmplAttr">{IOs}</set> 

<set path="/DAQ/LogicLev/gen/prm_F3/%2fserv%2ftmplAttr">
  <ta id="in">44.9998202036118</ta>
  <ta id="var">44.9999585116556</ta>
</set>


14.4.3.3 Модуль BlockCalc

Отримання значень всіх атрибутів блоку об'єкту контролеру
ЗАП: <get path="/DAQ/BlockCalc/{CNTR}/blk_{BLK}/%2fserv%2fattr" />

ВІДП: <get path="/DAQ/BlockCalc/{CNTR}/blk_{BLK}/%2fserv%2fattr" rez="0">{attributes}</get> 

<get path="/DAQ/BlockCalc/CM101/blk_AT101_1/%2fserv%2fattr" rez="0" user="roman">
  <a id="Fi">50.3839725707191</a>
  <a id="Pi">10.2588208891757</a>
  <a id="Ti">331.149550201738</a>
  <a id="Si">0.071</a>
  <a id="li">10</a>
</get>

Встановлення значень переліку атрибутів блоку об'єкту контролеру
ЗАП[root-DAQ]: <set path="/DAQ/BlockCalc/{CNTR}/blk_{BLK}/%2fserv%2fattr">{attributes}</set> 

<set path="/DAQ/BlockCalc/CM101/blk_AT101_1/%2fserv%2fattr">
  <a id="Fi">50.3839725707191</a>
  <a id="Pi">10.2588208891757</a>
</set>


14.4.4 Підсистема "Архіви-історія"

Отримання підсистемного статусу резервування станції
ЗАП: <st path="/Archive/%2fserv%2fredundant" />
ВІДП: <st path="/Archive/%2fserv%2fredundant" rez="0" inProc="1" StLevel="{lev}">{status}</st> 

<st StLevel="10" inProc="1" path="/Archive/%2fserv%2fredundant" rez="0" user="roman">
  <archM id="DBArch.test" run="1" />
  <archM id="FSArch.NetRequsts" run="1" />
  <archM id="FSArch.StatErrors" run="1" />
  <archM id="FSArch.test" run="1" />
</st>

Архів повідомлень

Отримання інформації архівування повідомлень
ЗАП: <info path="/Archive/%2fserv%2fmess" arch="{archiver}" />
  • archiver — повний ідентифікатор архіватору повідомлень для запиту цієї інформації або порожньо для архіву повідомлень загалом.
ВІДП: <info path="/Archive/%2fserv%2fmess" arch="{archiver}" rez="0" end="{end}" beg="{begin}" />
  • end — час останнього повідомлення в архіві, як мітка часу UNIX від 01.01.1970;
  • begin — час першого повідомлення в архіві, як мітка часу UNIX від 01.01.1970.
<info beg="1639859386" end="1674549889" path="/Archive/%2fserv%2fmess" rez="0" user="roman" />
Запит повідомлень архіву повідомлень
Дуже загальний запит повідомлень архіву.
ЗАП: <get path="/Archive/%2fserv%2fmess" tm="{time}" tm_grnd="{tmGrnd}" arch="{archiver}" cat="{catTmpl}" lev="level" />
  • time — час останнього запитаного повідомлення, як мітка часу UNIX від 01.01.1970; за нульового значення використовується системний поточний час - 1;
  • tmGrnd — час першого запитаного повідомлення, як мітка часу UNIX від 01.01.1970;
  • archiver — повний ідентифікатор архіватору повідомлень для запиту або порожньо для архіву повідомлень загалом;
  • catTmpl — шаблон запитуваних повідомлень;
  • level — мінімальний рівень запитуваних повідомлень.
ВІДП: <get path="/Archive/%2fserv%2fmess" tm="{time}" tm_grnd="{tmGrnd}" arch="{archiver}" cat="{catTmpl}" lev="level" rez="0" >{messages}</get>
  • time — тут розташовується час останнього опрацьованого повідомлення (найбільше), як мітка часу UNIX від 01.01.1970;
  • messages — запитані повідомлення у тегах "el": <el time="{time}" utime="{utime}" cat="{category}" lev="{level}">{mess}</el>
    • time — час повідомлення, як мітка часу UNIX від 01.01.1970;
    • utime — мікросекундна частина часу повідомлення;
    • cat — категорія повідомлення;
    • lev — рівень повідомлення;
    • mess — текст повідомлення.
<get cat="/*" lev="1" path="/Archive/%2fserv%2fmess" rez="0" tm="0" tm_grnd="1674549800" user="roman">
  <el cat="/sub_UI/mod_QTCfg/" lev="1" time="1674549865" utime="856668">
roman| '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fio%2fin' змінено у: '&lt;info path="/Archive" /&gt;'!
  </el>
  <el cat="/sub_UI/mod_QTCfg/" lev="1" time="1674549867" utime="640815">
roman| Натиснуто '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fcalc'!
  </el>
  <el cat="/sub_UI/mod_QTCfg/" lev="1" time="1674549888" utime="266062">
roman| '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fio%2fin' змінено у: '&lt;info path="/Archive/%2fserv%2fmess" /&gt;'!
  </el>
  <el cat="/sub_UI/mod_QTCfg/" lev="1" time="1674549889" utime="843894">
roman| Натиснуто '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fcalc'!
  </el>
</get>
Встановлення групи повідомлень до архіву повідомлень
ЗАП[root-Archive]: <set path="/Archive/%2fserv%2fmess">{messages}</set>
  • messages — повідомлення у тегах "el": <el time="{time}" utime="{utime}" cat="{category}" lev="{level}">{mess}</el>
    • time — час повідомлення, як мітка часу UNIX від 01.01.1970;
    • utime — мікросекундна частина часу повідомлення;
    • cat — категорія повідомлення;
    • lev — рівень повідомлення;
    • mess — текст повідомлення.
<set path="/Archive/%2fserv%2fmess">
  <el cat="/sub_UI/mod_QTCfg/" lev="1" time="1674549865" utime="856668">
roman| '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fio%2fin' змінено у: '&lt;info path="/Archive" /&gt;'!
  </el>
  <el cat="/sub_UI/mod_QTCfg/" lev="1" time="1674549867" utime="640815">
roman| Натиснуто '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fcalc'!
  </el>
</set>

Архіватори повідомлень

Запит повідомлень архіватору повідомлень
ЗАП: <get path="/Archive/{MOD}/mess_{ARCHR}/%2fserv%2fmess" eTm="{endTime}" bTm="{begTime}" cat="{catTmpl}" lev="level" />
  • MOD, ARCHR — модуль архівації повідомлень та ідентифікатор архіватору;
  • endTime — час останнього запитаного повідомлення, як мітка часу UNIX від 01.01.1970; за нульового значення використовується системний поточний час;
  • begTime — час першого запитаного повідомлення, як мітка часу UNIX від 01.01.1970;
  • catTmpl — шаблон запитуваних повідомлень;
  • level — мінімальний рівень запитуваних повідомлень.
ВІДП: <get path="/Archive/{MOD}/{ARCHR}/%2fserv%2fmess" eTm="{endTime}" bTm="{begTime}" cat="{catTmpl}" lev="level" rez="0" tm="{time}" >{messages}</get>
  • time — тут розташовується час останнього опрацьованого повідомлення (найбільше), як мітка часу UNIX від 01.01.1970;
  • messages — запитані повідомлення у тегах "it": <it tm="{time}" tmu="{utime}" cat="{category}" lev="{level}">{mess}</it>
    • time — час повідомлення, як мітка часу UNIX від 01.01.1970;
    • utime — мікросекундна частина часу повідомлення;
    • cat — категорія повідомлення;
    • lev — рівень повідомлення;
    • mess — текст повідомлення.
<get bTm="1674549800" cat="/*" eTm="1674549889" lev="1" path="/Archive/FSArch/mess_SYS/%2fserv%2fmess" rez="0" tm="1674549889" user="roman">
  <it cat="/sub_UI/mod_QTCfg/" lev="1" tm="1674549865" tmu="856668">
roman| '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fio%2fin' змінено у: '&lt;info path="/Archive" /&gt;'!
  </it>
  <it cat="/sub_UI/mod_QTCfg/" lev="1" tm="1674549867" tmu="640815">
roman| Натиснуто '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fcalc'!
  </it>
  <it cat="/sub_UI/mod_QTCfg/" lev="1" tm="1674549888" tmu="266062">
roman| '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fio%2fin' змінено у: '&lt;info path="/Archive/%2fserv%2fmess" /&gt;'!
  </it>
  <it cat="/sub_UI/mod_QTCfg/" lev="1" tm="1674549889" tmu="843894">
roman| Натиснуто '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fcalc'!
  </it>
</get>
Встановлення групи повідомлень до архіватору повідомлень
ЗАП[root-Archive]: <put path="/Archive/{MOD}/mess_{ARCHR}/%2fserv%2fmess" redundancy="{redundancy}">{messages}</put>
  • MOD, ARCHR — модуль архівації повідомлень та ідентифікатор архіватору;
  • redundancy — ознака надсилання повідомлень до резервних станцій [0|1];
  • messages — встановлювані повідомлення у тегах "it": <it tm="{time}" tmu="{utime}" cat="{category}" lev="{level}">{mess}</it>
    • time — час повідомлення, як мітка часу UNIX від 01.01.1970;
    • utime — мікросекундна частина часу повідомлення;
    • cat — категорія повідомлення;
    • lev — рівень повідомлення;
    • mess — текст повідомлення.
<put path="/Archive/FSArch/mess_SYS/%2fserv%2fmess">
  <it cat="/sub_UI/mod_QTCfg/" lev="1" tm="1674549865" tmu="856668">
roman| '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fio%2fin' змінено у: '&lt;info path="/Archive" /&gt;'!
  </it>
  <it cat="/sub_UI/mod_QTCfg/" lev="1" tm="1674549867" tmu="640815">
roman| Натиснуто '/SimulatorStation/sub_DAQ/mod_JavaLikeCalc/lib_Controller/fnc_test1/%2fexec%2fcalc'!
  </it>
</put>

Архіви значень

Отримання інформації архіву значень
ЗАП: <info path="/Archive/va_{ARCH}/%2fserv%2fval" arch="{archiver}" />
  • ARCH — ідентифікатор архіву значень;
  • archiver — повний ідентифікатор архіватору значень або порожньо для буферу значень.
ВІДП: <info path="/Archive/va_{ARCH}/%2fserv%2fval" arch="{archiver}" rez="0" end="{end}" beg="{begin}" per="{period}" vtp="{valTp}" />
  • end — час останнього значення у архіві в мікросекундах та частина секунд як мітка часу UNIX від 01.01.1970;
  • begin — час першого значення у архіві в мікросекундах та частина секунд як мітка часу UNIX від 01.01.1970;
  • period — періодичність архіватору або буферу значень за відсутності архіватору, у мікросекундах;
  • valTp — тип значення, дивіться до об'єкту #TFld.
<info arch="FSArch.1s" beg="1665239503000000" end="1674581638000000" path="/Archive/va_F3_var/%2fserv%2fval" per="1000000" rez="0" user="roman" vtp="4" />
Запит значень архіву значень
Дуже загальний запит значень архівів значень.
ЗАП: <get path="/Archive/va_{ARCH}/%2fserv%2fval" tm="{time}" tm_grnd="{tmGrnd}" arch="{archiver}" local="{localReq}" per="{period}" mode="{mode}" round_perc="{rndPerc}" real_prec="{realPrec}" />
  • ARCH — ідентифікатор архіву значень;
  • time — час останнього запитуваного значення в мікросекундах та частина секунд як мітка часу UNIX від 01.01.1970; для нульового значення використовується поточний системний час;
  • tmGrnd — час першого запитуваного значення в мікросекундах та частина секунд як мітка часу UNIX від 01.01.1970; для нульового значення здійснюється лише запит поточного;
  • archiver — повний ідентифікатор архіватору значень або порожньо для пріоритетного запиту за пріоритетом обрання від кращого до гіршого;
  • localReq — ознака [0|1] локального запиту без запиту резервної станції щодо відсутніх даних;
  • period — період у якому запитувати значення, у мікросекундах; використовується максимальний із архівом період;
  • mode — режим запиту значень архіву, дивіться перелічення ServReqDtMode об'єкту #TVArchive;
  • DMSimple(0) — простий запис, один елемент на рядок; значення у випадку строкового типу архіву кодуються щодо виключення символів нового рядка;
34.5678
23.6543
65.8754
34.6523
  • DMPack(1) — упакований запис, одне суміжне рівне (округлене) значення на рядок; перед кожним значенням вказується його позиційний номер відокремлений пробілом від значення;
0 34.5678
1 23.6543
4 65.8754
6 34.6523
  • DMBin(2) — масив неупакованих бінарних значень, закодований Base64; не може бути використано для строкових архівів.
  • rndPerc — відсоток округлення реальних значень, тобто які вважаються однаковими;
  • realPrec — точність реальних значень при перетворені у рядок, типово 15.
ВІДП: <get path="/Archive/va_{ARCH}/%2fserv%2fval" tm="{time}" tm_grnd="{tmGrnd}" arch="{archiver}" local="{localReq}" per="{period}" mode="{mode}" round_perc="{rndPerc}" real_prec="{realPrec}" rez="0" vtp="{valType}">{values}</get>
  • archiver — встановлюється в обраний архіватор за порожнього значення тут у запиті;
  • time — встановлюється у час реально запитаного значення при одиничному запиті або у час останнього-кінцевого значення блоку значень;
  • tmGrnd — встановлюється у час першого-базового значення блоку значень;
  • period — встановлюється у реальний період даних у блоку значень;
  • valType — встановлюється у тип даних у блоку значень;
  • values — одне значення для одиничного запиту або блок значень, відформатований відповідно до "mode".
<get arch="FSArch.1s" mode="1" path="/Archive/va_F3_var/%2fserv%2fval" per="10000000" real_prec="7" rez="0" round_perc="0.1"
     tm="1674581630000000" tm_grnd="1674581500000000" user="roman" vtp="4">
0 &lt;EVAL&gt;
7 45.23046
11 45.16198
13 45.08281
</get>
Запит назви архіву залежно від зв'язування із атрибутом Збору Даних
ЗАП: <name path="/Archive/va_{ARCH}/%2fserv%2fval" />
  • ARCH — ідентифікатор архіву значень.
ВІДП: <name path="/Archive/va_{ARCH}/%2fserv%2fval" rez="0">{name}</name>
  • name — назва запитуваного архіву.
<name path="/Archive/va_F3_var/%2fserv%2fval" rez="0" user="roman">F3.var</name>

14.4.5 Підсистема "Користувацькі Інтерфейси (UI)"

14.4.5.1 Модуль VCAEngine

Сервісні функції — це інтерфейс доступу до OpenSCADA із зовнішніх систем посередництвом Інтерфейсу Управління. Цей механізм покладено в основу усього обміну всередині OpenSCADA, реалізованого шляхом слабких зв'язків та власного протоколу обміну OpenSCADA.

Загальні віджети

Отримання значень визначених або всіх візуальних атрибутів віджету
ЗАП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattr">{attributes}</get>
  • wAddr — локальна адреса віджету, на кшталт "/wlb_AGLKS/wdg_CM101/wdg_ElFigure1";
  • attributes — лише запитані атрибути у тегах "el" із тільки одним атрибутом ідентифікатору "id"; можлива цілковита відсутність тегів атрибутів для запиту усіх наявних.
ВІДП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattr" rez="0">{attributes}</get>
  • attributes — опрацьовувані атрибути у тегах "el": <el id="{ID}" p="{pos}" act="{active}">{value}</el>
    • ID — ідентифікатор атрибуту;
    • pos — позиція-індекс атрибуту для стандартних;
    • active — стан активності атрибуту, лише для прямого запиту;
    • value — значення атрибуту.
<get path="/UI/VCAEngine/wlb_AGLKS/wdg_CM101/wdg_ElFigure1/%2fserv%2fattr" rez="0" user="roman">
  <el id="id">ElFigure1</el>
  <el id="path">/wlb_AGLKS/wdg_CM101/wdg_ElFigure1</el>
  <el id="parent">/wlb_originals/wdg_ElFigure</el>
  <el id="owner">root:UI</el>
  <el id="perm">948</el>
  <el id="root" p="1">ElFigure</el>
  <el id="name" />
  <el id="dscr" />
</get>
Встановлення групи значень визначених атрибутів віджетів
ЗАП[root-UI]: <set path="/UI/VCAEngine/{wAddr}/%2fserv%2fattr">{attributes}</set>
  • wAddr — локальна адреса віджету у модулі, на кшталт "/wlb_AGLKS/wdg_CM101/wdg_ElFigure1";
  • attributes — атрибути зі значеннями у тегах "el": <el id="{ID}">{value}</el>
    • ID — ідентифікатор атрибуту;
    • value — встановлюване значення атрибуту.
<set path="/UI/VCAEngine/wlb_AGLKS/wdg_CM101/wdg_ElFigure1/%2fserv%2fattr">
  <el id="name">Нова назва</el>
  <el id="dscr">Новий опис</el>
</set>
Отримання значень візуальних атрибутів гілки віджетів, оптимізовано для мереж
ЗАП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattrBr" />
  • wAddr — локальна адреса віджету у модулі, на кшталт "/wlb_AGLKS/wdg_CM101/wdg_ElFigure1".
ВІДП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattrBr" rez="0">{attributes} {widgets}</get>
  • attributes — опрацьовані атрибути у тегах "el": <el id="{ID}" p="{pos}">{value}</el>
    • ID — ідентифікатор атрибуту;
    • pos — позиція-індекс атрибуту для стандартних;
    • value — значення атрибуту.
  • widgets — дочірні віджети у тегах "w": <w id="{ID}" lnkPath="{lnkPath}">{attributes} {widgets}</w>
    • ID — ідентифікатор віджету;
    • lnkPath — шлях до пов'язаного віджету для дочірніх віджетів бібліотек віджетів.
<get path="/UI/VCAEngine/wlb_AGLKS/wdg_CM101/%2fserv%2fattrBr" rez="0" user="roman">
  <el id="id">CM101</el>
  <el id="path">/wlb_AGLKS/wdg_CM101</el>
  <el id="parent">/wlb_originals/wdg_Box</el>
  <el id="owner">root:UI</el>
  <el id="perm">948</el>
  <el id="root" p="1">Box</el>
  <el id="name">КМ101</el>
  <w id="AT101_1" lnkPath="/wlb_mnEls/wdg_cooler">
    <el id="id">AT101_1</el>
    <el id="path">/wlb_AGLKS/wdg_CM101/wdg_AT101_1</el>
    <el id="parent">/wlb_mnEls/wdg_cooler</el>
    <el id="owner">root:UI</el>
    <el id="perm">948</el>
    <el id="root" p="1">ElFigure</el>
    <el id="name">АТ101 1</el>
  </w>
</get>

Бібліотеки віджетів

Отримання дерева віджетів бібліотек, оптимізовано для мереж
ЗАП: <get path="/UI/VCAEngine/%2fserv%2fwlbBr" item="{item}" disIconsW="{disIconsW}" disIconsCW="{disIconsCW}" />
  • item — елемент бібліотеки отримання, як шлях "wlb_{WLib}[/wdg_{Wdg}[/wdg_{ChildWdg}]]", для порожнього отримуватиметься все дерево;
  • disIconsW — вимкнути отримання даних іконки для віджетів [0|1];
  • disIconsCW — вимкнути отримання даних іконки для дочірніх віджетів [0|1].
ВІДП: <get path="/UI/VCAEngine/%2fserv%2fwlbBr" item="{item}" disIconsW="{disIconsW}" disIconsCW="{disIconsCW}" rez="0">{wlibs}</get>
  • wlibs — бібліотеки віджетів у тегах "wlb": <wlb id="{ID}" doc="{doc}">{name} {icon} {widgets}</wlb>
    • icon — тег "icon" із даними цієї іконки кодоване Base64;
    • widgets — теги "w" із описом бібліотек віджетів: <w id="{ID}" doc="{doc}" parent="{parent}">{name} {icon} {widgets}</w>
      • parent — адреса батька віджету;
      • widgets — теги "сw" із описом дочірніх віджетів: <cw id="{ID}" doc="{doc}">{name} {icon}</cw>
<get disIconsCW="1" disIconsW="1" item="/wlb_AGLKS" path="/UI/VCAEngine/%2fserv%2fwlbBr" rez="0" user="roman">
  <wlb id="AGLKS">АГЛКС
    <ico>iVBORw0KGgoAA...AAAElFTkSuQmCC</ico>
    <w id="CM101" parent="/wlb_originals/wdg_Box">КМ101
      <cw id="AT101_1">АТ101 1</cw>
      <cw id="AT101_2">АТ101 1</cw>
      <cw id="C101_1">C101/1</cw>
      <cw id="C101_2">C101/1</cw>
      <cw id="C101_3">C101/1</cw>
      <cw id="CM101">CM101</cw>
      <cw id="CM101_1">CM101_1</cw>
      <cw id="CM101_2">CM101_2</cw>
      <cw id="ElFigure1">ElFigure1</cw>
      <cw id="ElFigure2">ElFigure2</cw>
      <cw id="ElFigure3">ElFigure3</cw>
      <cw id="ElFigure4">ElFigure4</cw>
      <cw id="ElFigure5">ElFigure5</cw>
      <cw id="ElFigure6">ElFigure6</cw>
      <cw id="ElFigure7">ElFigure7</cw>
    </w>
    <w id="KCH_MN1" parent="/wlb_originals/wdg_Box">KCH_MN1
      <cw id="BC1">Кульовий кран</cw>
      <cw id="BC2">Кульовий кран</cw>
      <cw id="BC21">Кульовий кран</cw>
      <cw id="BC22">Кульовий кран</cw>
    </w>
    <w id="comprEn" parent="/wlb_originals/wdg_ElFigure">Робота компресора</w>
  </wlb>
</get>

Проєкти СВУ

Отримання переліку проєктів розширене деякими опціями
ЗАП: <get path="/UI/VCAEngine/[%2fbr%2fprj_|%2fprm%2fcfg%2fprj]" chkUserPerm="{chkUserPerm}" getChPgN="{getChPgN}" noName="{noName}" />
  • chkUserPerm — перевірка прав користувача перед включенням до переліку [0|1];
  • getChPgN — запит кількості дочірніх сторінок у проєктах [0|1];
  • noName — не повертати назви сторінок [0|1].
ВІДП: <get path="/UI/VCAEngine/[%2fbr%2fprj_|%2fprm%2fcfg%2fprj]" chkUserPerm="{chkUserPerm}" getChPgN="{getChPgN}" noName="{noName}" rez="0">{projects}</get>
  • projects — перелік проєктів у тегах "el", де назва у тексті тегу та ідентифікатор у атрибуті "id". Розширено додатковими атрибутами:
    • "chPgN" — кількість дочірніх сторінок у проєкті за встановлення "getChPgN".
<get getChPgN="1" path="/UI/VCAEngine/%2fbr%2fprj_" rez="0" user="roman">
  <el chPgN="2" id="AGLKS">АГЛКС</el>
  <el chPgN="2" id="archBrowser">Огляд архівів</el>
  <el chPgN="2" id="tmplSO">Групи сигналізації (шаблон)</el>
</get>
Перевірка доступу на читання проєкту від користувача запиту
ЗАП: <read path="/UI/VCAEngine/prj_{proj}/%2fserv%2faccess" />
  • proj — ідентифікатор проєкту.
ВІДП: <read path="/UI/VCAEngine/prj_{proj}/%2fserv%2faccess" rez="0">{access}</get>
  • access — статус наявності доступу [0|1].
<read path="/UI/VCAEngine/prj_AGLKS/%2fserv%2faccess" rez="0" user="roman">1</read>

Сеанси проєктів

Отримання переліку сеансів розширене деякими параметрами
REQ: <get path="/UI/VCAEngine/[%2fbr%2fses_|%2fses%2fses]" chkUserPerm="{chkUserPerm}" onlyMy="{onlyMy}" />
  • chkUserPerm — перевірка прав користувача перед доданням до переліку [0|1];
  • onlyMy — додавати до переліку лише мої власні сеанси [0|1].
RESP: <get path="/UI/VCAEngine/[%2fbr%2fses_|%2fses%2fses]" chkUserPerm="{chkUserPerm}" onlyMy="{onlyMy}" rez="0">{sessions}</get>
  • sessions — перелік сеансів у тегах "el", де ідентифікатор у тексті тегу. Розширено додатковими атрибутами:
    • "user" — користувач сеансу;
    • "proj" — проєкт сеансу.
<get path="/UI/VCAEngine/%2fses%2fses" rez="0" onlyMy="1" user="roman">
  <el user="roman" proj="AGLKS">AGLKS</el>
  <el user="roman" proj="AGLKS">AGLKS0</el>
</get>
Отримання переліку сеансів визначеного проєкту СВУ
ЗАП: <list path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" />
  • project — ідентифікатор запитаного проєкту.
ВІДП: <list path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" rez="0">{sessions}</list>
  • sessions — сеанси у тегах "el".
<list path="/UI/VCAEngine/%2fserv%2fsess" prj="AGLKS" rez="0" user="roman">
  <el>AGLKS</el>
</list>
Підключення до визначеного проєкту СВУ або сеансу проєкту
ЗАП: <connect path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" sess="{session}" userChange="{userChange}" onlyMy="{onlyMy}" />
  • project — ідентифікатор запитаного проєкту, порожнє при підключені до наявного сеансу;
  • session — ідентифікатор вже наявного сеансу, порожнє для створення нового сеансу;
  • onlyMy — ознака підключення-перепідключення до сеансу лише якщо він мій;
  • userChange — ознака зміни користувача [0|1], тобто для оновлення інформації користувача.
ВІДП: <connect path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" sess="{session}" userChange="{userChange}" onlyMy="{onlyMy}" rez="0" conId="{conId}" userIsRoot="{userIsRoot}" />
  • conId — ідентифікатор підключення сеансу, використовується у подальших запитах;
  • project — ідентифікатор проєкту успішно підключеного сеансу;
  • session — ідентифікатор новоствореного сеансу успішно підключеного проєкту;
  • userIsRoot — користувач має права суперкористувача [0|1].
<connect conId="50860885" path="/UI/VCAEngine/%2fserv%2fsess" prj="AGLKS" rez="0" sess="AGLKS" user="roman" userIsRoot="1" />
Відключення від визначеного сеансу проєкту СВУ
Сеанси із нульовою кількістю підключень тут також закриваються.
ЗАП: <disconnect path="/UI/VCAEngine/%2fserv%2fsess" sess="{session}" conId="{conId}" />
  • session — ідентифікатор наявного сеансу;
  • conId — ідентифікатор підключення сеансу.
<disconnect path="/UI/VCAEngine/%2fserv%2fsess" sess="AGLKS" conId="50860885" />
Отримання переліку відкритих сторінок сеансу проєкту
ЗАП[{owner}-{grp}]: <openlist path="/UI/VCAEngine/ses_{session}/%2fserv%2fpg" conId="{conId}" tm="{clock}" />
  • owner, grp — доступ на читання для власника проєкту або користувача у групі та відповідно до прав проєкту;
  • session — ідентифікатор сеансу;
  • conId — ідентифікатор підключення сеансу;
  • clock — значення внутрішнього лічильника (цикл життя) від попереднього опрацьованого запиту, для перевірки змінених.
ВІДП: <openlist path="/UI/VCAEngine/ses_{session}/%2fserv%2fpg" conId="{conId}" tm="{clock}" rez="0">{pages}</openlist>
  • clock — значення внутрішнього лічильника (цикл життя) - 1 на час запиту;
  • pages — сторінки у тегах "pg": <pg pgGrp="{pgGrp}" updWdg="{nUpdWdgs}">{ID}</pg>
    • ID — ідентифікатор сторінки;
    • pgGrp — група сторінок для раннього обчислення включення сторінок;
    • nUpdWdgs — кількість оновлених віджетів після останнього запиту та для непорожнього "clock".
<openlist conId="52760577" path="/UI/VCAEngine/ses_AGLKS/%2fserv%2fpg" rez="0" tm="1403" user="roman">
  <pg>/ses_AGLKS/pg_so</pg>
  <pg pgGrp="so">/ses_AGLKS/pg_so/pg_1/pg_mn/pg_1</pg>
  <pg pgGrp="cntr">/ses_AGLKS/pg_control/pg_ElCadr</pg>
</openlist>
Відкриття або закриття визначеної сторінки сеансу проєкту
ЗАП[{owner}-{grp}]: <[open|close] path="/UI/VCAEngine/ses_{session}/%2fserv%2fpg" pg="{page}" />
  • owner, grp — доступ на запис для власника проєкту або користувача у групі та відповідно до прав проєкту;
  • session — ідентифікатор сеансу;
  • page — адреса сторінки у контексті сеансу, на кшталт "/ses_AGLKS/pg_so/pg_1/pg_mn/pg_1".
Отримання статусу сигналізації та ресурсу сповіщення для сеансу проєкту
ЗАП[{owner}-{grp}]: <get path="/UI/VCAEngine/ses_{session}/%2fserv%2falarm" mode="{mode}" tp="{typeNtf}" wdg="{widget}" />
  • owner, grp — доступ на читання для власника проєкту або користувача у групі та відповідно до прав проєкту;
  • session — ідентифікатор сеансу;
  • mode — режим запиту, лише "resource" для отримання ресурсів сповіщення та пусто тільки статус;
  • typeNtf — тип сповіщення для отримання ресурсу, дивіться секцію сигналізації;
  • widget — адреса віджету для формування ресурсу сповіщення, порожньо для глобального.
ВІДП: <get path="/UI/VCAEngine/ses_{session}/%2fserv%2falarm" mode="{mode}" tp="{typeNtf}" rez="0" alarmSt="{alarmSt}" tm="{clock}" wdg="{widget}" resTp="{resTp}" mess="{message}" lang="{language}">{resource}</get>
  • alarmSt — статус сигналізації як описано у секції сигналізації;
  • clock — значення внутрішнього лічильника (цикл життя) при формуванні ресурсу сповіщення;
  • widget — адреса віджету джерела при формуванні ресурсу сповіщення;
  • message — повідомлення сповіщення із тексту;
  • language — мова сповіщення, переважно для "message";
  • resTp — тип ресурсу сповіщення;
  • resource — ресурс сповіщення кодований Base64 для бінарних даних.
<get path="/UI/VCAEngine/ses_AGLKS/%2fserv%2falarm" mode="resource" tp="1" rez="0" user="roman"
     alarmSt="460554" tm="0" resTp="audio/ogg;73.3428" lang="en_US.UTF-8">
T2dnUwACA...Dg6gwAjo+PAQ==
</get>
Стишення-квітація сповіщення сигналізації сеансу проєкту
ЗАП[{owner}-{grp}]: <quietance path="/UI/VCAEngine/ses_{session}/%2fserv%2falarm" wdg="{widget}" tmpl="{template}" ret="{return}" />
  • owner, grp — доступ на читання для власника проєкту або користувача у групі та відповідно до прав проєкту;
  • session — ідентифікатор сеансу;
  • widget — адреса віджету для стишення сповіщення, пусто для глобального;
  • template — шаблон сповіщення, тобто бітова збірка відповідно до типів стишуваних сповіщень;
  • return — ознака повернення сповіщення, тобто стишення вимикається.
<quietance path="/UI/VCAEngine/ses_AGLKS/%2fserv%2falarm" tmpl="7" />
Отримання значень модифікованих візуальних атрибутів віджету сеансу
Перевизначає загальний сервісний запит віджетів "<get path='/UI/VCAEngine/{wAddr}/%2fserv%2fattr' />" щодо специфіки сеансу.
ЗАП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr" tm="{clock}" />
  • wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
  • clock — значення внутрішнього лічильника (цикл життя) від попереднього опрацьованого запиту, для перевірки змінених; за нульового значення примусово додаються сервісні-віртуальні атрибути: "perm", "name".
ВІДП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr" tm="{clock}" rez="0">{attributes}</get>
  • attributes — модифіковані від "clock" атрибути у тегах "el": <el id="{ID}" p="{pos}">{value}</el>
    • ID — ідентифікатор атрибуту;
    • pos — позиція-індекс атрибуту для стандартних;
    • value — значення атрибуту.
<get path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1/%2fserv%2fattr" rez="0" tm="0" user="roman">
  <el id="perm" p="-3">6</el>
  <el id="root" p="1">ElFigure</el>
  <el id="en" p="5">1</el>
  <el id="active" p="6">0</el>
  <el id="geomX" p="7">488</el>
  <el id="geomY" p="8">250</el>
  <el id="geomW" p="9">16</el>
  <el id="geomH" p="10">100</el>
  <el id="geomXsc" p="13">1</el>
  <el id="geomYsc" p="14">0.75</el>
  <el id="geomZ" p="11">-9</el>
</get>
Встановлення групи значень визначених атрибутів віджету сеансу
Перевизначає загальний сервісний запит віджетів "<set path='/UI/VCAEngine/{wAddr}/%2fserv%2fattr' />" щодо специфіки сеансу на кшталт опрацювання атрибуту "event" та виявлення активності-неактивності користувача.
ЗАП[{owner}-{grp}]: <set path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr" noUser="{noUser}">{attributes}</set>
  • owner, grp — доступ на запис для власника проєкту або користувача у групі та відповідно до прав проєкту;
  • wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
  • noUser — не маркувати це як активність користувача;
  • attributes — атрибути зі значеннями у тегах "el": <el id="{ID}">{value}</el>
    • ID — ідентифікатор атрибуту;
    • value — встановлюване значення атрибуту.
<set path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1/%2fserv%2fattr">
  <el id="name">Нова назва</el>
  <el id="dscr">Новий опис</el>
</set>
Активація атрибуту для використання у якості візуального та його створення за відсутності
ЗАП: <activate path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr%2f{aID}" aNm="{aName}" aTp="{aType}" aFlg="{aFlags}" aVls="{aValues}" aNms="{aNames}">{aDef}</activate>
  • wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
  • aID — ідентифікатор атрибуту сеансу;
  • aName — ім'я атрибуту при його створені;
  • aType — тип атрибуту при його створені, дивіться об'єкт TFld;
  • aFlags — прапорці атрибуту при його створені, дивіться об'єкт TFld;
  • aDef — типове значення атрибуту при його створені;
  • aValues — значення атрибуту для вибіркових типів при його створені;
  • aNames — назви значень атрибуту для вибіркових типів при його створені.
<activate path="/UI/VCAEngine/ses_AGLKS/pg_so/%2fserv%2fattr%2frunWin" aNm="Вікно виконання" aTp="1" aFlg="1" aVls="0;1;2" aNms="Original size;Maximize;Full screen">0</activate>
Отримання значень візуальних атрибутів гілки віджету сеансу, оптимізовано для мереж
Перевизначає загальний сервісний запит віджетів "<get path='/UI/VCAEngine/{wAddr}/%2fserv%2fattrBr' />" щодо специфіки сеансу.
ЗАП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrBr" tm="{clock}" FullTree="{FullTree}" />
  • wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
  • clock — значення внутрішнього лічильника (цикл життя) від попереднього опрацьованого запиту, для перевірки змінених; за нульового значення примусово додаються сервісні-віртуальні атрибути: "perm", "name".
  • fullTree — отримання повного дерева віджетів незалежно від наявності змін, без атрибутів.
ВІДП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrBr" tm="{clock}" FullTree="{FullTree}" rez="0">{attributes} {widgets}</get>
  • attributes — опрацьовані атрибути у тегах "el": <el id="{ID}" p="{pos}">{value}</el>
    • ID — ідентифікатор атрибуту;
    • pos — позиція-індекс атрибуту для стандартних;
    • value — значення атрибуту.
  • widgets — дочірні віджети у тегах "w": <w id="{ID}">{attributes} {widgets}</w>
    • ID — ідентифікатор віджету.
<get path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/%2fserv%2fattrBr" rez="0" tm="0" user="roman">
  <el id="name" p="-4">CM101</el>
  <el id="perm" p="-3">6</el>
  <el id="root" p="1">Box</el>
  <el id="en" p="5">1</el>
  <el id="active" p="6">0</el>
  <el id="geomX" p="7">0</el>
  <el id="geomY" p="8">0</el>
  <el id="geomW" p="9">900</el>
  <el id="geomH" p="10">580</el>
  <w id="AT101_1">
    <el id="perm" p="-3">6</el>
    <el id="root" p="1">ElFigure</el>
    <el id="en" p="5">1</el>
    <el id="active" p="6">0</el>
    <el id="geomX" p="7">338</el>
    <el id="geomY" p="8">320</el>
    <el id="geomW" p="9">80</el>
    <el id="geomH" p="10">100</el>
  </w>
</get>
Отримання значення специфічного до сеансу атрибуту віджету сеансу
ЗАП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrSess%2f{aID}" />
  • wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
  • aID — ідентифікатор специфічного до сеансу атрибуту.
ВІДП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrSess%2f{aID}" rez="0">{value}</get>
  • value — значення атрибуту.
<get path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/%2fserv%2fattrSess%2ftestA" rez="0" user="roman">тестове значення</get>
Встановлення значення специфічного до сеансу атрибуту віджету сеансу
ЗАП[{owner}-{grp}]: <set path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrSess%2f{aID}">{value}</get>
  • owner, grp — доступ на запис для власника проєкту або користувача у групі та відповідно до прав проєкту;
  • wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
  • aID — ідентифікатор специфічного до сеансу атрибуту;
  • value — значення атрибуту.
<set path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/%2fserv%2fattrSess%2ftestA">тестове значення</set>


14.5 Object of the dynamic tree node (TCntrNode)

Inherited: By all the dynamic and controlled objects directly or through children.

Data:

Masks of the security access (definition):
Named rights of access to control elements (definition):

Dynamic node's flags (enum TCntrNode::Flag):

Flags of the enabling/disabling modes of the node (enum TCntrNode::EnDisFlag):

Enable flags
Disable flags

Modification of the node flags (enum TCntrNode::ModifFlag):

Public methods:

static XMLNode *ctrMkNode( const char *n_nd, XMLNode *nd, int pos, const char *req, const string &dscr int perm = RWRWRW, 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 = RWRWRW, const char *user = "root", const char *grp = "root", ... ); — Adding the control element to the page. It is possible to specify the set of additional attributes in the number of n_attr as follows: "{attribute1},{values1},{attribute2},{values2},..." or by zero pointer at the end of the pair sequence.

Protected methods:

15 Resources locking

Most of the units and subsystems of OpenSCADA are dynamic, ie they allow the creation/deletion/configuration while the system is working. Taking into account the multi-threading of the system, this functionality imposes stringent requirements for synchronization of threads. For synchronization in the system the resources are used, functions of which are localized in the objects "Res" and "ResAlloc". Object "Res" provides storage of the resource, providing the functions of capture/release for the read and write. In object "ResAlloc" the automatic release of the resource functions are implemented. Automatic resource involves the creation of a local resource object with its automatic release at fracture (in the destructor). Using of automatic resource makes the work with resources when using the exceptions much easier.

Any dynamic system object is inherited from "TCntrNode" object, which contains a mechanism to connect via the "AutoHD" template. The main function of the template is to store the link to the object and the capture of the resource, excluding the deleting of the object at the time of use. Template supports copying the resource and its release in case of destruction of the template object. For clarity of the access to the objects generated by "TCntrNode" the "AutoHD" template supports casting, based on the dynamic cast.

15.1 Resource R/W lock object (ResRW)

Public methods:

15.2 Automatic resource RW unlock object (ResAlloc)

Public methods:

15.3 Template (AutoHD)

Public methods:

15.4 Resources allocation object, by mutex (ResMtx)

Public methods:

15.5 Object of the string with the access shared by the resource (ResString)

Public methods:

15.6 Conditional variable object, by mutex (CondVar)

Public methods:

15.7 Object of automatic unlock POSIX mutex (MtxAlloc)

Public methods:

15.8 Object of the string with the access shared by the global the data resource (mutex) (MtxString)

Public methods:

16 Other generic objects

XML in OpenSACDA is represented by the object of the XML-tag — XMLNode.

Errors of the exceptions are handled by the error object "TError".

16.1 XML-tag (XMLNode)

Data:
Options for XML-file loading (enum — XMLNode::LoadFlgs):

Options of the function of XML-file generation (enum - XMLNode::SaveView):

Public methods:

16.2 Error exception (TError)

Data:
Error codes (enum — TError::Codes):

Public methods:

Public attributes:

17 Organization and structure of the database of the system components

Nodes and subsystems of OpenSCADA may have their own tables in the database to store their own data. The structure of tables is individual and determined by the <TConfig> object. Nodes and subsystems must create and configure the <TConfig> object under their demands.

17.1 System tables

OpenSCADA has two system tables: BD and SYS. Table BD contains records of registered databases and the table SYS contains data of system-wide parameters.

Table 7. Structure if the table of system-wide parameters (SYS).

User <user> Parameter's ID <id> Parameter's value <val>
root /DemoStation/MessLev 0
user /DemoStation/Workdir /mnt/home/roman/work/OScadaD/share/OpenScada
user /DemoStation/UI/QTStarter/StartMod QTCfg

Table 8. Structure if the table of registered DB.

ID <ID> DB Type <TYPE> Name <NAME> Description <DESCR> Address <ADDR> Codepage of the database contents <CODEPAGE> To enable <EN>
LibBD MySQL Function's library server.diya.org;roman;123456;oscadaUserLibs KOI8-U 1
AnastModel SQLite AGLKS model ./DATA/AGLKSModel.db UTF8 1
GenDB MySQL Main DB server.diya.org;roman;123456;oscadaDemoSt KOI8-U 1

17.2 Tables of the "Data acquisition" subsystem

Controllers (data sources) of the subsystem "Data acquisition" are stored in the tables of their subsystems named DAQ_<ModName>. The structures of these tables can differ significantly, but all of them have the obligatory fields. The overall structure of the controllers' tables is presented in table 9.

Table 9. The overall structure of the controllers' tables of the subsystem "Data acquisition" (DAQ_<ModName>).

ID <ID> Controller's name <NAME> Description <DESCR> To enable<ENABLE> To start <START> Individual parameters
AutoDA Automatic source Data acquisition from active sources with automatic identification of them. 1 1 ...

Like the controller's table, the parameter's table for different types of data sources can differ significantly, but also have the obligatory fields. In addition to the differences which is typical to the type of data source, parameter's tables can still be different for different types of parameters. The overall structure of the parameters' tables is given in Table 10.

Table 10. The overall structure of the parameters' tables of the subsystem "Data acquisition".

Parameter's shifr <SHIFR> Parameter's name <NAME> Parameter's description <DESCR> To enable <EN> Individual parameters
P3 P3 Pressure on the diaphragm 1 ...

In addition to controllers and parameters the subsystem "Data acquisition" contains parameter's templates. Parameter's templates are grouped by templates' libraries and are stored in tables of three types: templates' library table (ParamTemplLibs) — table 11, parameter's templates table — table 12 and template's parameters table — table 13.

Table 11. Structure of the templates' library table.

ID <ID> Name <NAME> Description <DESCR> DB table of the library <DB>
base Basic templates Basic templates' library tmplib_base
S7 Templates' Library for Siemens S7 series controllers. tmplib_S7

Table 12. Structure of the templates' table.

ID <ID> Name <NAME> Description <DESCR> Text of the template procedure <PROGRAM>
digAlarm Digital signal Alarm over the discrete parameter JavaLikeCalc.JavaScript
simpleBoard Simple boards Formation of the simple boards of the analog signal. JavaLikeCalc.JavaScript

Table 13. Structure of the table of the template's parameters.

Template's ID <TMPL_ID> Parameter's ID <ID> Name <NAME> Type <TYPE> Flags <FLAGS> Value <VALUE> Position <POS>
digAlarm in Вход 3 144 2
digitBlock cmdOpen Open command 3 161 0

17.3 Tables of the "Transports" subsystem

Subsystem "Transports" is divided into input and output transports. For each type of transport there is its own table with its own structure. Table names, respectively: Transport_In and Transport_Out. Tables can be supplemented by fields, typical to the type of transport.

Table 14. Structure of the input transport's table (Transport_in).

ID <ID> Type <MODULE> Name <NAME> Description <DESCRIPT> Address <ADDR> Protocol <PROT> To start <START> Individual fields of the transports' types
web1 Sockets Web 1 Work web transport for proced http requests. TCP::10002:0 HTTP 1 ...
Self SelfSystem TCP 1 Test TCP input socket! Sockets TCP::10001:1 1 ...

Table 15. Structure of the output transport's table (Transport_out).

ID <ID> Type <MODULE> Name <NAME> Description <DESCRIPT> Address <ADDR> Individual fields of the transports' types
tcp_o1 Sockets TCP Out 1 Output TCP transport 1 TCP::10001 ...

For the centralized description of the list of external OpenSCADA stations it is used the table of external hosts (CfgExtHosts). The structure of this table is shown in Table 16.

Table 16. The structure of the table of external OpenSCADA hosts (CfgExtHosts).

User of the system <OP_USER> ID <ID> Name <NAME> Transport <TRANSP> Address of the remote host <ADDR> User of the external host <USER> Password of the user of the external host <PASS>
tcp_o1 Sockets TCP Out 1 Output TCP transport 1 TCP::10001 1 ...

17.4 Tables of the "Archives" subsystem

Subsystem "Archives" contains three tables with fixed names:

Tables of the archivers can be complemented by fields, typical for each type of archiver.

Table 17. Structure of the table of the values' archive (Archive_val).

ID <ID> Name <NAME> Description <DESCR> To start <START> The mode of the values' source <SrcMode> Source of the values <Source> Type of the values <VTYPE> Buffer's periodicity <BPER> Buffer's size <BSIZE> Buffer's hard grid <BHGRD> High resolution of the buffer's time <BHRES> List of the serviced archivers <ArchS>
CPULoad_load 1 1 DAQ.System.AutoDA.CPULoad.load 4 1 100 0 0 FSArch.1s;DBArch.1m;FSArch.1m;
ai1_dP 0 0 4 0.0001 100 1 1 FSArch.POMP_20070301;FSArch.1s;

Table 18. Structure of the table of the values' archivers (Archive_val_proc).

ID <ID> Archiver's type <MODUL> Name <NAME> Description <DESCR> To start <START> Address <ADDR> Values' period <V_PER> Archiving period <A_PER> Individual fields of the archivers' types
1s FSArch One second 1 ARCHIVES/VAL/1s 1 60 ...
POMP_20070301 FSArch 0 ARCHIVES/VAL/POMP_20070301 0.0001 60 ...

Table 19. Structure of the table of the messages' archivers (Archive_mess_proc).

ID <ID> Archiver's type <MODUL> Name <NAME> Description <DESCR> To start <START> Template of the messages' category <CATEG> Messages' level <LEVEL> Address <ADDR> Individual fields of the archivers' types
StatErrors FSArh Station error 1 /DemoStation* 4 ARCHIVES/MESS/stError/ ...
NetRequsts FSArh Network requests 1 /DemoStation/Transport/Sockets* 1 ARCHIVES/MESS/Net/ ...

17.5 Tables of the "Security" subsystem

Subsystem "Security" contains two tables: table of the system's users (Security_user) and groups of the system (Security_grp).

Table 20. Structure of the table of the system's users (Security_user).

Name <NAME> Description <DESCR> Password <PASS> Picture <PICTURE>
root SuperUser openscada
user User user

Table 21. Structure of the table of the system's users groups (Security_grp).

Name <NAME> Description <DESCR> Users in the group <USERS>
root SuperUser's group root;user
users User's group toot;user

17.6 The structure of the databases of the modules

Each module can have its own database tables to store individual data. Structure of database tables of the modules can be formed freely, based on internal needs.

18 API модуля

Модулі в OpenSCADA реалізуються як поділювані бібліотеки та одна така бібліотека може містити багато модулів підсистем OpenSCADA, фактично виступаючи як контейнер. Такі контейнери також можуть бути включені-вбудовані до Бібліотеки Ядра OpenSCADA якщо ви будуєте дуже компактні рішення.

Першим кроком підключення поділюваних бібліотек (SO — Поділювані Об'єкти) є підключення функцій ініціалізації. Такі функції мають бути визначені як звичайні "C" функції для запобігання спотворенню їх назв. Зазвичай це здійснюється наступним чином: 

//================== CUT =========================
extern "C"
{
#ifdef MOD_INCL
    TModule::SAt bd_Tmpl_module( int n_mod )
#else
    TModule::SAt module( int n_mod )
#endif
    {
        if(n_mod == 0) return TModule::SAt(MOD_ID, MOD_TYPE, VER_TYPE);
        return TModule::SAt("");
    }

<!--T:348-->
#ifdef MOD_INCL
    TModule *bd_Tmpl_attach( const TModule::SAt &AtMod, const string &source )
#else
    TModule *attach( const TModule::SAt &AtMod, const string &source )
#endif
    {
        if(AtMod == TModule::SAt(MOD_ID,MOD_TYPE,VER_TYPE)) return new BDTmpl::BDMod(source);
        return NULL;
    }
}
//================== CUT =========================

Точкою входу будь якого модуля є функції:

Загальним для всіх модулів є наслідування кореневого об'єкта-класу модуля від класу модульної підсистеми TModule, що вказує на наявність спільної частини інтерфейсу модуля який розглянемо далі. Для отримання уявлення про архітектуру модулів у контексті загальної архітектури OpenSCADA наполегливо рекомендується мати перед очима загальну діаграму класів OpenSCADA!

Всі інтерфейсні об'єкти модулів успадковують клас вузла TCntrNode, який надає механізм інтерфейсу управління. Одним із завдань цього механізму є надання інтерфейсу конфігурації об'єкту у будь якому конфігураторі OpenSCADA.

Загальне API
TCntrNode — Вузол OpenSCADA:
  • void preEnable( int flag );, void postEnable( int flag ); — підключення модуля до динамічного дерева об'єктів, викликається перед та після фактичного увімкнення модуля відповідно.
  • void preDisable( int flag );, void postDisable( int flag ); — виключення модуля із динамічного дерева об'єктів перед звільненням об'єкту, викликається перед та після фактичного виключення модуля відповідно.
  • void load_( TConfig *cfg );, void load_( ); — завантаження модуля із контексту сховища cfg та загалом, викликається на стадії завантаження конфігурації модуля зі сховку.
  • void save_( ); — збереження модуля, викликається на стадії збереження конфігурації модуля до сховку, зазвичай за ініціативою користувача.
TModule — Модуль OpenSCADA:
  • void modStart( ); — запуск модуля, викликається на стадії запуску завдань виконання фонових функцій модуля, якщо такі модулем надаються.
  • void modStop( ); — зупинка модуля, викликається на стадії зупинки завдань виконання фонових функцій модуля, якщо такі модулем надаються.
  • void modInfo( vector<string> &list ); — запит переліку інформаційних властивостей модуля, яким надається стандартний набір властивостей "Module", "Name", "Type", "Source", "Version", "Author", "Description", "License", та що може бути розширено власними-специфічними властивостями.
  • string modInfo( const string &name ); — запит елементу інформації name за якого здійснюється обробка запитів і до власних-специфічних властивостей модуля.
  • void modFuncReg( ExpFunc *func ); — реєстрація експортованої функції модуля, яка є частиною механізму міжмодульної взаємодії що реєструє внутрішню функцію модуля для зовнішнього виклику за назвою-символом функції та її вказівником відносно об'єкта модуля. Наразі цей механізм мало якими модулями використовується!
  • void perSYSCall( unsigned int cnt ); — виклик із системного-сервісного потоку-завдання з періодичністю 10 секунд та секундним лічильником cnt, може використовуватися для виконання періодичних-рідких сервісних процедур.
API модулів підсистеми "Бази Даних (БД)"
Призначено для інтеграції OpenSCADA із БД чи СУБД, яка реалізується модулем. Надає два загальних підходи до реалізації модулів:
  1. Режим ANSI SQL — є найпростішим шляхом який передбачає безпосереднє використання функцій ядра fieldSQLSeek(), fieldSQLGet(), fieldSQLSet(), fieldSQLDel() у fieldSeek(), fieldGet(), fieldSet(), fieldDel() відповідно; всі SQL-модулі використовують наразі цей підхід.
  2. Повна Реалізація — є найскладнішим шляхом який передбачає повну реалізацію; модулі, що використовують такий підхід є або старими або специфічними: DBF, LDAP.
TTypeBD->TModule — кореневий об'єкт модуля підсистеми "БД":
  • string features( ); — перелік ключових слів підтримуваних властивостей БД.
  • int lsPr( ); — базовий приорітет БД [0...9] у загальному переліку сховків.
  • TBD *openBD( const string &id ); — викликається при відкритті або створені нового об'єкта БД даним модулем з ідентифікатором id.
TBD — об'єкт бази даних:
  • void enable( ); — включення БД.
  • void disable( ); — відключення БД.
  • void allowList( vector<string> &list ) const; — запит переліку list таблиць у БД.
  • void sqlReq( const string &req, vector< vector<string> > *tbl = NULL, char intoTrans = EVAL_BOOL ); — обробка SQL-запиту req до БД та отримання результату у вигляді таблиці tbl, якщо запит вибірки та вказівник ненульовий. При встановлені intoTrans у TRUE для запиту мусить бути відкрита транзакція, у FALSE закрита. Ця функція має реалізовуватися для СУБД, які підтримують SQL-запити.
  • void transCloseCheck( ); — періодично викликається для перевірки транзакцій та закриття старих або які містять багато запитів.
  • TTable *openTable( const string &name, bool create ); — викликається при відкритті або створені нового об'єкта таблиці.
TTable — об'єкт таблиці у базі даних:
  • void fieldStruct( TConfig &cfg ); — отримання поточної структури таблиці у об'єкті cfg.
  • bool fieldSeek( int row, TConfig &cfg, const string &cacheKey = "" ); — послідовне сканування записів таблиці перебором row за об'єктом cfg та повернення FALSE по закінченню, з адресацією за активними keyUse() ключовими полями. Ключ кешу cacheKey вказується для предзавантаженням повної відповіді до кешу, із витягненням наступних записів звідти.
  • void fieldGet( TConfig &cfg ); — запит вказаного у об'єкті cfg запису із адресацією за ключовими полями.
  • void fieldSet( TConfig &cfg ); — передача вказаного у об'єкті cfg запису з адресацією за ключовими полями.
  • void fieldDel( TConfig &cfg ); — видалення вказаного запису за ключовими полями об'єкту cfg.
Специфічне для SQL Баз Даних
  • void fieldFix( TConfig &cfg, const string &langLs = "" ); — виправлення структури таблиці БД до cfg та для мов перекладу langLs, зазвичай після невдалого запису.
  • string getSQLVal( TCfg &cf, uint8_t RqFlg = 0 ); — повернення специфічно до SQL обгорненого значення cf для прапорців ReqFlg звернення RqFlg.
  • void setSQLVal( TCfg &cf, const string &vl, bool tr = false ); — розбір SQL-значення vl для перекладу tr та із записом до cf.
API модулів підсистеми "Транспорти"
Забезпечує OpenSCADA комунікаціями через інтерфейс, часто це мережі які реалізуються цим модулем.
TTypeTransport->TModule — кореневий об'єкт модуля підсистеми "Транспорти":
  • virtual bool isNetwork( ); — ознака реалізації мережі цим модулем.
  • virtual string outAddrHelp( ); — допомога із формату адреси вихідного транспорту.
  • virtual TTransportIn *In( const string &id, const string &stor ); — викликається модулем за відкриття або створення нового об'єкту вхідного транспорту із ідентифікатором id та сховком stor.
  • virtual TTransportOut *Out( const string &name, const string &stor ); — викликається модулем за відкриття або створення нового об'єкту вихідного транспорту із ідентифікатором id та сховком stor.
TTransportIn — об'єкт вхідного транспорту:
  • virtual unsigned keepAliveReqs( ); — максимум запитів "Збереження Життя".
  • virtual unsigned keepAliveTm( ); — час "Збереження Життя".
  • virtual string getStatus( ); — отримання статусу транспорту.
  • virtual void start( ); — запуск транспорту.
  • virtual void stop( ); — зупинка транспорту.
  • virtual int writeTo( const string &sender, const string &data ); — надсилання даних data назад відправнику sender. At.png Переважно застаріле та заміщене режимом опитування вхідного транспортного протоколу, Початково реалізується у транспортах із підтримкою ініціативного відправлення, не лише за запитом.
TTransportOut — об'єкт вихідного транспорту:
  • virtual string timings( ); — таймаути транспорту.
  • virtual unsigned short attempts( ); — спроб підключення.
  • virtual string getStatus( ); — отримання статусу транспорту.
  • virtual void setTimings( const string &vl, bool isDef = false ); — встановлення таймаутів транспорту, як типове за isDef.
  • virtual void setAttempts( unsigned short vl ); — встановлення спроб підключення.
  • virtual void start( int time = 0 ); — запуск транспорту із таймаутом підключення time. Із запуском вихідного транспорту встановлюється підключення до віддаленої станції для інтерфейсів які передбачають підключення. На цей час можуть виникати помилки якщо підключення неможливе та транспорт має повернутися до стану зупинки.
  • virtual void stop( ); — зупинка транспорту.
  • virtual int messIO( const char *oBuf, int oLen, char *iBuf = NULL, int iLen = 0, int time = 0 ); — відправка даних через транспорт. Таймаут очікування time підключення в мілісекундах. Негативне значення time вимикає режим транспорту запит/відповідь для незалежного читання/запису до буферу ВВ, із таймаутом читання time у абсолютному значені.
API модулів підсистеми "Транспортні протоколи"
Забезпечує OpenSCADA комунікаціями рівня протоколу, які реалізуються модулем, щодо доступу до даних із зовнішніх систем та надання даних OpenSCADA для зовнішніх систем.
TProtocol->TModule — кореневий об'єкт модуля підсистеми "Транспортні протоколи":
  • virtual void itemListIn( vector<string> &ls, const string &curIt = "" ); — перелік ls під'елементів вхідного протоколу від поточного елементу curIt, якщо протокол їх надає. Використовується при обранні об'єкта у конфігурації вхідного транспорту.
  • virtual void outMess( XMLNode &io, TTransportOut &tro ); — передавання даних об'єктами ядра OpenSCADA у дереві XML io до віддаленої системи через транспорт tro та поточний вихідний протокол. Представлення даних у дереві XML не стандартизоване та специфічне до логічної структури протоколу. Ці дані серіалізуються — перетворюються у послідовність байтів відповідно до протоколу, та надсилаються через визначений вихідний транспорт tro функцією messIO().
  • virtual TProtocolIn *in_open( const string &id ); — викликається модулем за відкриття або створення нового об'єкту транспортного протоколу із ідентифікатором id.
TProtocolIn — вхідний об'єкт транспортного протоколу з опрацювання вхідних запитів від вхідного транспортного об'єкту TTransportIn. Для кожного сеансу вхідного запиту створюється асоційований об'єкт вхідного протоколу, який залишається живим до завершення повного сеансу "запит->відповідь". Адреса транспорту, який відкриває входження протоколу, визначається у srcTr():
  • virtual unsigned waitReqTm( ) — час очікування запиту на вхідному транспорті у мілісекундах, після якого звертається до протоколу із порожнім повідомленням — режим опитування. Встановлення його у нуль вимикає режим опитування.
  • virtual void setSrcTr( TTransportIn *vl ) — встановлення транспорту-джерела відкритого сеансу вхідного протоколу.
  • virtual void setSrcAddr( const string &vl ); — встановлення адреси відправника.
  • virtual bool mess( const string &request, string &answer ); — передавання послідовності даних запиту request до об'єкту протоколу для її розбору відповідно до реалізації протоколу. Ця функція протоколу має опрацювати запит request, згенерувати відповідь у answer та повернути FALSE у випадку повноти запиту. Якщо запит request не повний, необхідно повернути транспорту TRUE для індикації "очікування завершення", попередні частини запиту повинні зберігатися у контексті об'єкту протоколу.
API of the modules of the "Data AcQuisition" subsystem
Provides the realtime data acquisition from the external systems or it formation in the calculators, implemented by the module. That is the main subsystem since SCADA is about the Data Acquisition primarily. As the main subsystem it provides several approaches in the modules implementation, which mostly about the attributes structure formation and storing:
  1. Static formation through definition a set of the parameter types inherited from TTypeParam, that is the structures applying is performed as an attributes set with the parameter type change. This method is least flexible and it used by such modules: GPIO, SMH2Gi, AMRDevs.
  2. Dynamic formation with the structure container TElem managing in the parameter object TParamContr. This method is most flexible and used in most modules which mean of the structure be configurable.
  3. As an extension of the dynamic formation there is the Logical Level parameter type, what can be added to any module, but that used mostly in the universal data sources: LogicLev, ModBus, Siemens, OPC_UA.
TTypeDAQ->TModule — the root module object of the "Data AcQuisition" subsystem:
  • virtual bool compileFuncLangs( vector<string> *ls = NULL ); — request the list ls of languages for which it is realised the possibility of formation of user procedures in this module, and check for fact of that support.
  • virtual void compileFuncSnthHgl( const string &lang, XMLNode &shgl ); — request the rules of the syntax highlight shgl for the specified language lang.
  • virtual string compileFunc( const string &lang, TFunction &fnc_cfg, const string &prog_text, const string &usings = "", int maxCalcTm = 0 ); — compiling-registering of the user function on the supported programming language lang and on the source code of procedure prog_text, based on the procedure parameters fnc_cfg. Returns address of the compiled function's object, ready for execution.
  • virtual bool redntAllow( ); — state of support the redundancy mechanisms by the module. Should be overridden and return TRUE if supported, otherwise FALSE.
  • virtual TController *ContrAttach( const string &id, const string &daq_db ); — called when a new controller object is opened or created by this module with the identifier id.
TController — the data source controller object. In the context of the object is usually run a task of the periodic or scheduled polling of the realtime data of one physical controller or physically separated block of data. In the case of data getting by the packages, they are placed directly into the archive associated with the parameter attribute TVAl::arch(), and the current value is set by the TVAl::set() function with the attribute "sys"=TRUE:
  • virtual string getStatus( ); — request function of the controller status.
  • virtual void enable_( ); — enabling of the controller object. Usually at this stage the initialisation of the parameters' objects and their interfaces in the form of attributes is made, the attributes can sometimes be requested from the associated remote source.
  • virtual void disable_( ); — disabling the controller object.
  • virtual void start_( ); — starting the controller object. Usually at this stage the task of periodic or scheduled polling is created and started.
  • virtual void stop_( ); — stopping the controller object.
  • virtual void redntDataUpdate( ); — operation of the data receiving from the backup station, called automatically by the service procedure of the redundancy scheme of the subsystem.
  • virtual string catsPat( ); — list of the regular expression rules, separated by '|', for matching by category the messages generated by the object.
  • virtual void messSet( const string &mess, int lev, const string &type2Code = "OP", const string &prm = "", const string &cat = "" ); — formation of the DAQ-sourced messages for the parameter object prm (PrmId) or the controller object in whole if the parameter object is not specified, for the message mess, level lev and for the type code type2Code. This function generates the messages with the unified DAQ-transparency category "{type2Code}{ModId}:{CntrId}[.{prm}][:{cat}]".
  • virtual TParamContr *ParamAttach( const string &id, int type ); — called when a new object of the controller parameter is opened or created by this module with the identifier id.
TParamContr->TValue — the controller parameter object of the data source. Contains attributes with real data in a set defined by physically available data. The values to the attributes come from the polling task of the controller, in the asynchronous mode, or are requested during the access, in the synchronous mode, and through the methods of the inherited type TValue:
  • virtual TElem *dynElCntr( ); — container of the dynamic elements of the DAQ attributes. Defined mostly by the logical level sources what provide such kind containers.
  • virtual void enable( ); — enabling the parameter object, the formation of the attributes set and filling them with the value of unreliability is made.
  • virtual void disable( ); — disabling the parameter object.
  • virtual void setType( const string &tpId ); — called to change the parameter type to tpId and can be processed in the module object to change own data.
  • virtual TVal* vlNew( ); — called at the stage of a new attribute creation. Can be overridden to implement special behavior within its object, inherited from TVal, when accessing the attribute.
  • virtual void vlGet( TVal &vo ); — called for the attribute vo with the direct reading mode TVal::DirRead when reading the value in order to directly-synchronous read from the physical source or the object buffer.
  • virtual void vlSet( TVal &vo, const TVariant &vl, const TVariant &pvl ); — called for the attribute vo with the direct recording mode TVal::DirWrite when setting the value in order to directly-synchronous set to the physical source or the object buffer, with the previous value pvl.
  • virtual void vlArchMake( TVal &val ); — called at the stage of creation the values archive with the val attribute as the source in the order to initialise the qualitative characteristics of the archive buffer according to the characteristics of the data source and polling.
API модулів підсистеми "Архіви-Історія"
Використовується для архівування та ведення історії повідомлень і значень реального часу отриманих у підсистемі "Збір Даних", та у засіб реалізований модулем.
TTypeArchivator->TModule — кореневий об'єкт модуля підсистеми "Архіви-Історія":
  • virtual TMArchivator *AMess( const string &id, const string &stor ); — викликається модулем за відкриття або створення нового об'єкту архіватору повідомлень із ідентифікатором id та у сховку stor.
  • virtual TVArchivator *AVal( const string &id, const string &stor ); — викликається модулем за відкриття або створення нового об'єкту архіватору значень із ідентифікатором id та у сховку stor.
TMArchivator — об'єкт архіватору повідомлень.
  • virtual void redntDataUpdate( ); — операція отримання даних із резервної станції, автоматично викликається сервісною процедурою схеми резервування підсистеми.
  • virtual void start( ); — запуск об'єкту архіватору, архіватор запускається для отримання повідомлень та розміщення їх до сховку.
  • virtual void stop( ); — зупинка об'єкту архіватору.
  • virtual time_t begin( ); — час початку даних архіватору у відповідності до поточного стану сховку.
  • virtual time_t end( ); — час закінчення даних архіватору у відповідності до поточного стану сховку.
  • virtual bool put( vector<TMess::SRec> &mess, bool force = false ); — розташування групи повідомлень mess до архіватору. Повертає TRUE за успішної операції. Встановити force для прямого запису до архіву оминаючи резервування.
  • virtual time_t get( time_t bTm, time_t eTm, vector<TMess::SRec> &mess, const string &category = "", char level = 0, time_t upTo = 0 ); — отримання повідомлень до mess із архіватору для визначених параметрів фільтрації. Повертає час зупинки запиту, корисно для продовження від цієї позиції як часу закінчення, тобто ітераційно заглиблюючись в історію. Фільтр визначається діапазоном часу [bTm...eTm], правилами категорії category, рівнем level та обмежено до часу upTo. За відсутності прямого визначення обмежувального часу upTo, це обмеження встановлюється у prmInterf_TM — 7 секунд.
TVArchivator — об'єкт архіватору значень.
  • virtual void start( ); — запуск об'єкту архіватору, архіватор запускається для отримання значень та розміщення їх у сховок.
  • virtual void stop( bool full_del = false ); — зупинка об'єкту архіватору із можливістю повного видалення його даних зі сховку за full_del.
  • virtual TVArchEl *getArchEl( TVArchive &arch ); — отримання об'єкту елемента архіву значень для визначеного архіву arch.
  • virtual void pushAccumVals( ); — виштовхування накопичених завданням архівації значень, для акумулювальних архіваторів.
TVArchEl — об'єкт елементу архіватору значень.
  • virtual void fullErase( ); — викликається для цілковитого видалення архівної частини архіватору.
  • virtual int64_t end( ); — час завершення у мікросекундах щодо наявних значень у архіві архіватору.
  • virtual int64_t begin( ); — час початку у мікросекундах щодо наявних значень у архіві архіватору.
  • virtual TVariant getValProc( int64_t *tm, bool up_ord ); — запит одного значення із архіву на час tm та із підтягненням до верхнього значення у ґратці вимірювання up_ord.
  • virtual void getValsProc( TValBuf &buf, int64_t beg, int64_t end ); — запит групи значень до buf із архіву та для діапазону часу [beg...end].
  • virtual void setValsProc( TValBuf &buf, int64_t beg, int64_t end, bool toAccum ); — встановлення групи значень buf до архіву, для діапазону часу [beg...end] та через акумуляцію toAccum.
API модулів підсистеми "Користувацькі Інтерфейси"
Користувацький інтерфейс формується згідно до концепції та механізмів зовнішніх розповсюджених стандартів та бібліотек.
TUI->TModule — кореневий об'єкт модуля підсистеми "Користувацькі Інтерфейси":

At.png Не містить специфічних функцій!

API модулів підсистеми "Спеціальне"
Реалізує специфічні функції, які не увійшли до жодної з вищеперелічених підсистем. Специфічні функції формуються згідно їх власних вимог та із використанням всіх можливостей API OpenSCADA.
TSpecial->TModule — кореневий об'єкт модуля підсистеми "Спеціальне":

At.png Не містить специфічних функцій!


19 Debugging and Testing OpenSCADA

To monitor the quality of code and test the performance of various parts of the system the special modules are written that perform testing with the issue of testing protocol. These modules must be executed after the completion of any part of the project.

20 Rules for design and commenting of the sources of OpenSCADA and its modules

When writing and design of the sources of OpenSCADA and its modules you must to follow the rules:

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

Commenting rules of OpenSCADA:

21 Умовні позначення по тексту та у вихідних

????[{ТЕГИ}] — має бути реалізовано найближчим часом або відповідно до плану ТЕГИ:

?!?! — секцію не цілком реалізовано та може бути реалізовано не за розкладом, а за планом;
!!!! — секція потребує переосмислення та пояснює-попереджає такого роду реалізації-коментування.

22 Links

Documents/API/uk - GFDLDecember 2024OpenSCADA 1+r3000