OpenSCADAWiki: Home Page En/Doc/ Programm Manual ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
Russian (1 Êá) Ðîññèéñêèé

 (2 Êá) This page is frozen, actual one here and here.


46160

OpenSCADA program description

Author: Roman Savochenko, Maxim Lysenko (2012)


Contents


Introduction

This document is a description of the "open source" project called "OpenSCADA". OpenSCADA is a SCADA system built on the principles of modularity, scalability and multiple OS/Hardware integration.


As a policy the development of the system utilized "open source" principles. This choice allowed for the creation of a reliable and publicly available SCADA system. At the same time bringing together a significant number of product developers, enthusiasts and other stake holders to develop, test, and disseminate the project, thus minimizing the financial and distribution costs.


OpenSCADA is designed for the collection and archiving of system data plus the visualization and controlling of process operations typical of SCADA systems. Due to the level of scalability and modularization the system can be used in a variety of applications.


OpenSCADA can be used:


The host operating system selected for development was Linux has it optimized the solutions of the following issues:


While the system currently operates only on the Linux OS the project is being developed so that it can be installed on different operating systems. This ability to port to other OS will be added in future revisions.


At the heart of the system is a modular kernel, and depending on what modules are installed the system can configured to operate on a variety of networked servers and clients and in this way allow for the implementation of a client-server architecture saving machine memory, disk space, and programming time. However it is possible to configure the OpenSCADA on a single stand alone PC with the user choosing which modules to install, data acquisition, simple client, or both the client and server.


Differing server configuration can be designed for collecting data, processing data, issuing commands, archiving and logging information, and providing this information to clients (UI, GUI, TUI ...). The modular architecture allows for modification of a module’s functionality without the requirement of restarting the whole system.


Flexible system configuration allows the user to build solutions to meet specific requirements of reliability, functionality and complexity. Custom configurations can be based on different graphics libraries (GUI/TUI ToolKits), using the core program and selecting various modules (by adding it to the UI-user interface module), or the system can be used in a standalone application connecting the core of OpenSCADA to its libraries.


1. Functions of the system.

The block scheme of OpenSCADA system (74 Êá)
Fig. 1. The block scheme of OpenSCADA system

1.1. Modularity.

In order to achieve flexibility and a high degree of scalability OpenSCADA is constructed in a modular fashion. The process of developing our own modules imposed a great risk; possible errors could introduce an element of instability into the system, however tight integration of the modules with kernel lessened this issue and the ability to create a distributed configuration was seen as a greater benefit. In the end a more flexible and stable system was created.


OpenSCADA modules are stored within dynamic libraries and each shared library can contain modules of various types. The specific functional modules that are contained in a library is determined by the specifics of the modules connections. These dynamic libraries are hot swappable, which allows for the updating of a specific module without affecting the system as a whole. This method of storing code modules in dynamic libraries is essential for OpenSCADA, because it is supported by virtually all modern operating systems (OS). However, this does not exclude the possibility of developing other methods of storing code modules.


OpenSCADA has the following functional parts or modules:


Management of the modules is carried out by the "Modules Management" subsystem, whose functions include connection, switching off, updating, and other operations concerned with the management of the modules and their libraries.

1.2. Subsystems.

Architecturally OpenSCADA is divided into subsystems or two types, regular and modular. Modular subsystem have the ability to expand through the addition of modules, with each modular subsystem containing sets of modular objects. For example the modular Database subsystem contains modular objects of the database type, thus the modular object is the root of the module.


The basic configuration of OpenSCADA consists of nine subsystems with seven being modular. These nine subsystems are present at every configuration. Additional subsystems can be created by adding additional modules. The following lists the basic subsystems of OpenSCADA:

1.3. PLC and other sources of dynamic data. A subsystem "Data acquisition".

The Data Acquisition subsystem supports dynamic data sources whether PLC controllers, USO boards, virtual, or other sources. The functions of this subsystem are to provide data in a structured manner and the management of the data, i.e. data modification.


Since the Data Acquisition subsystem is modular it contains objects of the dynamic data source type. For example in October 2007 OpenSCADA supported the following data sources:


Each data source requires a separate module that can be connected or disconnected, with a module communicating to one or more devices(controllers).


Each controller contains parameters with the types, defined by the module. The parameter provides the list of attributes which contain the data. Parameter's attributes can be one of four basic types, string(text), integer, float and boolean. For example an analog parameter can contain data in either integer or float format.


The structures of a controllers, parameters and their types are contained in the Data Acquisition subsystem so that the module objects can specifically fill in these structures.


A source of dynamic data can be on a remote OpenSCADA system. In this case the data source would be the OpenSCADA data transport. The function of this type of data source is to mirror of the data sources on the local system.

1.4. Databases. A subsystem of "Database"

For a data storage of system databases (DB) are everywhere used. With a view of systematization of access and management of databases in OpenSCADA system the subsystem "Database" is provided. For support of various DB/DBMS the subsystem is modular.


In a role of the modular objects, containing in a subsystem, type DB/DBMS acts, i.e. the module of a subsystem "Database", which practically contains realization of access to the certain type of a DB. For example modules: DBF, MySQL, SQLite.


The object of type DB/DBMS, in its turn, contains the list of objects of separated DB of the given type. And the object of a DB contains the list of objects of tables which are contained by data in the tabulated form.


Practically all the data of OpenSCADA system are stored in this or that DB. The toolkit of system allows to transfer easily the data from one type of a DB on another and as consequence provide an optimum selection of DB type under the concrete area of OpenSCADA system. Transfer of the information from one DB to another can be made by two ways. The first is a change of the address of a working DB and save of all system on it, the second is a direct copying the information between DB. Except for copying the function of direct editing of contents of tables of a DB is supported also.


For the organization of the centralized access of the allocated system to a uniform DB two ways are provided. The first is using of network DBMS, for example MySQL. The second way is using of transport type of a DB on local systems for access to one central DB (It is planned.). Function of a transport DB is transfer of queries to a DB on remote OpenSCADA system.


Data can be stored also in a configuration file of system. The mechanism of full reflection of structure of a DB on structure of a configuration file is realized. I.e. the standard configuration can be placed in a configuration file. An essence of such mechanism that by default for example at start without a DB, it is possible to describe the data of system in a configuration file. In the further, these data can be redefined in a DB. Besides for cases of impossibility of start of any DB generally, it is possible to store all data in a configuration file.


For access to databases the mechanism of registration of a DB is used. Registered DB in system are accessible to all subsystems of OpenSCADA system and can be used in their work. Owing to this mechanism it is possible to provide an allocation of data storage. For example, various libraries can be stored and extend independently, and connection of library will consist in simple registration of the necessary DB.


In the further, realization of duplication of a DB by linkage of the registered DB is planned. This mechanism will allow to increase considerably reliability of OpenSCADA system as a whole by reservation of the mechanism of a data storage. (It is planned.)

1.5. Archives. A subsystem "Archives".

Any SCADA system gives an opportunity of archiving the acquisition data, i.e. formation of history of change (dynamics) of processes. Archives, conditionally, it is possible to divide into two types: archives of messages and archives of values.


Feature of archives of messages is that the subject of archiving are, so-called, events. A characteristic attribute of event is time of occurrence of this event. Archives of messages, usually, are used for archiving messages in system, i.e. conducting logs and reports. Depending on a source, messages can be classified by various criteria. For example, it can be reports of emergencies, reports of actions of operators, reports of failures of connection, etc.


Feature of archives of values is their periodicity defined by the time interval between two adjacent values. Archives of values are applied for archiving of history of continuous processes. As far as process is continuous and it's archiving is possible only by introduction of conception of quantization of interrogation of values as differently we receive archives of the infinite sizes, in view of a continuity of the nature of process. Besides, practically, we can receive values with the period limited by sources of data. For example, qualitative enough sources of data, in the industry, data with frequency more 1kHz seldom allow to obtain. And it without taking into account sensors having even less qualitative characteristics.


For the decision of tasks of archiving data flows in OpenSCADA system the subsystem "Archives" is provided. The subsystem "Archives" allows to conduct both: archives of messages and archives of values. The subsystem "Archives" is modular. The modular object containing in a subsystem "Archives" the type of the archiver acts. The type of the archiver defines the way of a data storage, i.e. storehouse (file system, DBMS, a network, etc.). Each module of a subsystem "Archives" can realize both: archiving of messages, and archiving of values. The subsystem "Archives" can contain set of the archives served by various modules of a subsystem.


The message in OpenSCADA system is characterized: by date, by level of importance, by category and the text of the message. Date of the message specifies for the period of creation of the message. The level of importance specifies a degree of importance of the message. The category determines the address or the conditional identifier of a source of the message. Usually, the category contains a full way to a source of the message in system. The text of the message, actually, also carries meaning content of the message.


During archiving messages are passed through the filter. The filter works on a level of importance and a category of the message. The level of the message in the filter specifies that it is necessary to pass messages with specified or higher level of importance. To filtering on a category templates or regular expressions are used, which define what messages are applied to pass. Each archiver contains own options of the filter. Consequently it is possible to create easily various specialized archivers for archive of messages. For example archivers of messages it is possible to dedicate on:


In view of the similar nature of the messages and the alarms, the subsystem "Archives" contains a buffer of current alarms, which contains active at the time the alarms with using the message category as a key identifier of the alarm. Access to the list-buffer of current alarms specifying by a negative value level messages. Thus, the formation of negative message with level -2 cause place in this message to buffer active alarms with level 2, as well as duplication of directly to messages archive. At the subsequent formation of the message in the same category, but a positive level, say 1, will be carried deletion of the specified alarm from the buffer of alarms and also the message fall into messages archive. This mechanism allows you to simultaneously keep track of active alarms and log their passage into the messages archive. When requesting to archive messages, an set of a positive level makes a request to archive messages, and a negative to buffer-list of current alarms.


The archive of values in system OpenSCADA acts as an independent component which includes the buffer processable by archivers. Key parameter of archive of value is the source of data. In a role of a source of data attributes of parameters of OpenSCADA system and also other external sources of data (a passive mode) can act. Other sources of data can be: network archivers from remote OpenSCADA systems, the environment of programming of OpenSCADA system, etc.


Key component of archiving of values of continuous processes is the buffer of values. The buffer of values is intended for intermediate storage of a file of the values received with certain periodicity (quantum of time). The buffer of values is used as for direct storage of big arrays of values in archives of values, before direct "retire" on physical carriers, and for manipulations with the staff of values, i.e. in functions of frame-accurate query of values and their placement in buffers of archives.


For the organization of the dedicated archivers, in the allocated systems it is possible to use transport type of the archiver (It is planned.). Function of transport type of the archiver is reflection of the remote central archiver on local system. As consequence, archivers of transport type carry out data transmission between local system and the archiver of the remote system, hiding from subsystems of local system the real nature of the archiver.

1.6. Communications. Subsystems "Transports" and "Transport protocols".

As far as the OpenSCADA system is pawned as is high-scaled system that support of communications should be flexible enough. For satisfaction of a high degree of flexibility, communications in OpenSCADA system are realized in subsystems "Transports" and "Transport protocols" which are modular.


The subsystem "Transports" is intended for an exchange of the not structured data between OpenSCADA system and external systems. In a role of external systems can act even remote OpenSCADA systems. Not structured data are understood as a file of symbols of the certain length. The modular object containing in a subsystem "Transports", the type of transport acts. The type of transport defines the mechanism of transfer of not structured data. For example it can be:


The subsystem "Transports" includes support of input and output transports. Input transport is intended for service of external queries and sending of answers. Output transport, on the contrary, is intended for sending messages and expectation of the answer. Consequently, input transport contains a configuration of the given station as server, and output transport contains a configuration of the remote server. The module of a subsystem "Transports" realizes support both: input and output transports.


The subsystem "Transport protocols" is intended for structuring of data received from a subsystem "Transports". As a matter of fact, the subsystem "Transport protocols" is continuation of a subsystem "Transports" and carries out functions of check of structure and integrity of the received data. So, for the indication of the protocol together with which transport should work, the special configuration field is provided. The modular object containing in a subsystem "Protocols" is the protocol. For example, transport protocols can be:


The full chain of connection can be written down as follows:


Protocols for output transports are supported also. The output protocol incurs function of dialogue with transport and realization of features of the protocol. The internal side of access to the protocol is realized by data-flow way with own structure for each protocol module. Such mechanism allows to carry out transparent access to external system, by means of transport, simply specifying a name of the protocol by means of which to serve transfer.


Owing to standard API-access to transports of OpenSCADA system it is possible to change easily a way of data exchange not touching exchanging systems. For example, in the case of a local exchange it is possible to use faster transport on the basis of shared memory, and in the case of an exchange through the Internet and a local network to use TCP or UDP sockets.

1.7. Interfaces of the user. A subsystem "Interfaces of the user".

SCADA-systems as a class, assume presence of user interfaces. In OpenSCADA, for granting the user interfaces, the subsystem "The user interfaces" is provided. The user interface of OpenSCADA system is understood not only as the environment of visualization from which the end user should work, but also as everything, that concerns the user, for example:


The subsystem "The user interfaces" is modular. As modular object of a subsystem the concrete interface of the user actually acts. Modularity of subsystem allows to create various interfaces of users on various GUI/TUI libraries and to use optimal of decisions in particularly taken case, for example, for environments of performance of programmed logic controllers it is possible to use configurators and visualizers on the basis of Web-technologies (WebCfg, WebUI), and in case of stationary workstations to use the same configurators and visualizers, but on the basis of libraries Qt, GTK.

1.8. Security of system. A subsystem "Security".

The OpenSCADA system is the branched out system which consists of ten subsystems and can include set of modules. Consequently, granting of unlimited access by all to these resources is at least unsafe. Therefore, for differentiation of access in OpenSCADA system, the subsystem of "Security" is provided. The basic functions of a subsystem "Security" are:

1.9. Management of libraries of modules and modules. A subsystem "Management of modules".

The OpenSCADA system is constructed by a modular principle that means presence of set of modules with which it is necessary to operate. For performance of function of management by modules of OpenSCADA system the subsystem "Management of modules" is provided. All modules, for the present moment are delivered in system by means of shared libraries (containers). Each container can contain set of modules of various type.


The subsystem "Management of modules" realizes the control over the status of containers and allows to carry out hot addition, removal and updating of containers and modules containing in them.

1.10. Unforeseen opportunities. A subsystem "Special".

Certainly, to provide all probable functions it is impossible, therefore in OpenSCADA system the subsystem "Special" is provided. The subsystem "Special" is modular and is intended for addition in OpenSCADA system unforeseen functions by modular expansion. For example, by means of a subsystem "Special" can be realized:

1.11. The user functions. Objective model and the environment of programming of system.

Any modern SCADA system should contain the mechanisms giving an opportunity to program at the user level, i.e. to contain the environment of programming. The OpenSCADA system contains such environment. By means of the environment of programming of OpenSCADA system it is possible to realize:


The environment of programming of OpenSCADA system represents a complex of assets organizing the computing environment of the user. Into structure of a complex of assets are included:


Modules of libraries of functions give set of functions of the certain orientation expanding objective model of system. Libraries can be realized both: by the set of functions of the fixed type, and functions supposing free updating and addition.


Libraries of functions of the fixed type can be given by standard modules of system, organically supplementing objective model. Functions of such libraries will represent the interface of access to assets of the module at a level of the user. For example, "The environment of visual data presentation" can give functions for delivery of various messages. Using these functions the user can realize interactive algorithms of communication with system.


Libraries of functions of free type give the environment of a writing of the user functions on one of programming languages. Within the limits of the module of libraries of functions mechanisms of creation of libraries of functions can be given. So, it is possible to create libraries of devices of technological processes, and in a consequence to use them by linkage. Various modules of libraries of functions can give realizations of various programming languages.


On the basis of the functions given by objective model, computing controllers are under construction. Computing controllers carry out linkage of functions with parameters of system and the mechanism of calculation.


2. SCADA systems and their structure.

Scada-system. (145 Êá)
Fig. 2. SCADA-system.

SCADA (Supervisory Control And Data Acquisition), in a general view, have the allocated architecture like represented on fig. 2. Elements of SCADA systems, in sense of the software, carry out following functions:
The acquisition server: represents a task or group of tasks engaged in data acquisition from sources of data, or act in a role as a source of data. Into tasks of a server enters:

The server of archiving: represents a task or group of tasks engaged in archiving of data. Into tasks of the server enters:

The journaling server: represents a task or group of tasks engaged in archiving of messages. Into tasks of the server enters:

The alarm server: represents a task or group of tasks carrying out functions of the server of recording concerning a narrow category of messages of the signal system.
The operator working place: represents constantly functioning GUI (Grafical User Interface) application executed in an one-monitor, multimonitor or panel mode and carrying out functions:

The engineer working place: represents GUI application used for configuration of SCADA system. Into tasks of the application enters:

The chief working place: represents GUI application, as a rule, executed in an one-monitor mode and carrying out functions:

The technologist working place: completely includes functions of a workplace of the operator plus model of technological process (without direct communication with technological process).
The work planner working place: completely includes functions of a workplace of the technologist plus toolkit for creation of models of technological processes.


3. Ways of configuration and using of OpenSCADA system.

3.1. Simple server connection.

In the elementary case the OpenSCADA system can be configured in a server mode (fig. 3.1) for acquisition and archiving of data. The given configuration allows to carry out following functions:


Simple server connection. (25 Êá)
Fig. 3.1. Simple server connection.

3.2. The duplicated server connection.

For increasing of reliability and productivity the OpenSÑADA system supposes plural reservation (fig. 3.2) at which controllers of one copy are reflected in other. At use of a similar configuration distribution of loading of interrogation/calculation at various stations is possible. The given configuration allows to carry out functions:


The duplicated server connection. (32 Êá)
Ðèñ. 3.2. The duplicated server connection.

3.3. The duplicated server connection on one server.

Special case of the duplicated connection is the duplicated connection within the limits of one server (fig. 3.3), that is start of several stations by one machine with a crossing of parameters. The purpose of the given configuration is increase of reliability and fault tolerance of system by reservation of software.


The duplicated server connection on one server. (32 Êá)
Fig. 3.3. The duplicated server connection on one server.

3.4. Client access by means of the Web-interface. A place of the manager.

For visualization of data containing on a server, the good decision is to use the user WEB-interface (fig. 3.4). The given decision allows to use a standard WEB-browser at the client side and therefore is the most flexible as it is not adhered to one platform, i.e. is multiplatform. However this decision has essential imperfections: low productivity and reliability. In this connection it is recommended to use the given method for visualization of noncritical data or data having a reserve highly reliable way of visualization. For example, the good decision will be using of this method at the heads of plants where always exists place(attendant position) with reliable way of visualization. The given configuration allows to carry out following functions:


Client access by means of the Web-interface. A place of the manager. (32 Êá)
Fig. 3.4. Client access by means of the Web-interface. A place of the manager.

3.5. The automated workplace (place of the manager/operator).

For visualization of critical data, and also in case of if high quality and productivity is required, it is possible to use visualization on the basis of OpenSCADA system configured with the GUI module (fig. 3.5). The given configuration allows to carry out following functions:


The automated workplace (place of the manager/operator). (44 Êá)
Fig. 3.5. The automated workplace (place of the manager/operator).

3.6. Automated workplace with a server of acquisition and archiving on the single machine (a place of the operator, model...).

The full-function client-server configuration on the single machine (fig. 3.6) can be used for increasing of reliability of system as a whole by start of the client and a server in different processes. The given configuration allows, without consequences for a server, to stop the client and to do with it various preventive works. It is recommended for use at stations of the operator by installation of two machines combining in itself the station of the operator and redundant server. The given configuration allows to carry out following functions:


Automated workplace with a server of acquisition and archiving on the single machine (a place of the operator, model...). (42 Êá)
Fig. 3.6. Automated workplace with a server of acquisition and archiving on the single machine (a place of the operator, model...).

3.7. The elementary mixed connection (model, demonstration, configurator...).

The mixed connection combines functions of a server and the client (fig. 3.7). It can be used for test, demonstration functions, and also for granting models of technological processes as a unit. In this mode following functions can be carried out:


The elementary mixed connection (model, demonstration, configurator...). (25 Êá)
Fig. 3.7. The elementary mixed connection (model, demonstration, configurator...).

3.8. The steady, allocated configuration.

The given configuration is one of variants of steady/reliable connection (fig. 3.8). Stability is reached by distribution of functions on:


The steady, allocated configuration. (64 Êá)
Fig. 3.8. The steady, allocated configuration.

The server of interrogation is configured on the basis of OpenSCADA system and represents the task (group of tasks) engaged with interrogation of the controller (group of controllers of the same type). The received values are accessible to the central server through any transport which support is added by connection of the corresponding module of transport. For decrease in frequency of interrogation and size of the network traffic the server of interrogation can be equipped with small archive of values. The configuration of a server of interrogation is stored in one of accessible DB.


The central server of archiving and service of client queries carries out function of the centralized acquisition and processing of parameters of servers of interrogation and their values. Access to servers of interrogation is carried out by means of one of accessible in OpenSCADA transports+protocols (for example it is SGA). For granting the uniform interface of access to parameters and controllers the module Transporter which reflects data of servers of interrogation on structure of local parameters is used.


For performance of internal calculations and the additional analysis of parameters computing controllers are used.


For versatile and deep archiving various modules of archives are used.


For access of clients to a server are used accessible for OpenSCADA network transports, for example it is Sockets, and transport protocols, for an example it is the protocol OpenSCADA "SelfSystem".


The configuration of the central server is stored in one of accessible DB (for example it is network DBMS MySQL).


For granting the user WEB-interface the module WebCfg by means of the transport protocol "HTTP" is used.


Various clients, among them automated workplaces and WEB-clients, are carried out on the separated machines in necessary quantity. The automated workplace is realized on the basis of OpenSCADA system. Its functions include interrogation of values of parameters from the central server and their visualization on the GUI interface(s). For reception of parameters in an automated workplace the module of reflection of the remote parameters Transporter, also, is used. For granting access to archives the module of archive of network type can be used. The configuration of an automated workplace can be stored in one of accessible DB (for example it is network DBMS MySQL, located on the machine of the central archiving server).


4. Configuration and adjustment of the system

As it can be seen in the section above, OpenSCADA allows configuration for execution in various roles. Support of this possibility is provided by the developed mechanisms for configuration and storage of configuration data. This section contains a description of these mechanisms, designed to demonstrate the flexibility and diversity, thereby allowing to use OpenSCADA to 100%.


In describing the configuration mechanisms and methods of its storage in this section it will be focused the description of system-wide mechanisms. Features of the configuration of modules of subsystems of OpenSCADA are provided in their own module's documentation.


In OpenSCADA it is used the formalized approach to describing the configuration interfaces based on XML. In fact, features of the component's configuration are provided by the component itself, thereby running through the whole system, as the nervous system of the organism. In terms of OpenSCADA it is called the interface of control of OpenSCADA (Control interface). On the basis of the control interface the graphical interfaces of the user configuration are generated by means of modules of OpenSCADA. This approach has the following important advantages:


In OpenSCADA the three configuration modules on the different basis of visualization are provided. Lets observe them and their configuration options:


Configuration values, changed in the configurators, as well as most of the data are stored in databases (DB). Given the modularity of subsystems "DB", there can be different database. Moreover, there is the possibility of storing different OpenSCADA parts in different databases of the same type and in the database of different types as well.


In addition to the database configuration information may be contained in the OpenSCADA configuration file, and passed through the command line parameter's when you call OpenSCADA. Saving the configuration in the configuration file is carried out on an equal footing with the database. Standard name of the OpenSCADA configuration file is /etc/oscada.xml. The format of the configuration file and command line parameters we'll examine in the separate section.


Some node's configuration changing will set the modification flag for the node, and also will set active for buttons "Load from DB", for loading the first configuration, and "Save to DB" for the changes saving. The modification flag also rise to parrent node, which allow for restore-save from root node, but real into operations with DB will participate only modified nodes.  (2 Kb) A node removing causes to removing it from storage-DB and modification mechanism do not work for this operation.


Many of the settings and configuration objects OpenSCADA, which are executed or are already enabled, are not applied immediately, as for changes, because the configuration is read/apply usually only when turn on or start. Therefore to apply the changes, in such cases, it is enough to enable/disable enabled object or to restart the running — start/stop. Presently many configurations, which its are not provided applying for now, just are not allowed for editing.


Further examining of the OpenSCADA configuration will be based on the interface of the configurator UI.QTCfg, but the principles of work will be fully consistent with the rest of the configurators owing to the generality in the control interface of OpenSCADA.


We will start examining with the configuration of system parameters of OpenSCADA, which is located in the six tabs at the root page of the station:


To modify the fields of this page it may be required the super user's rights. Get these rights you can by means of including your user into the superuser's group "root", or by entering the station from the superuser "root".


We must mention another one important point: the fields of the identifiers of all OpenSCADA objects are unacceptable for direct editing, because they are keys for storage of objects' data in the database. However, to change the object's identifier you can by the command of cutting and the further pasting of the object (Cut-> Paste) in the configurator.


The "Station" tab of the main page of the configuration of the station. (156 Êá)
Fig. 4a. The "Station" tab of the main page of the configuration of the station.

The "Subsystems" tab of the main page of the configuration of the station. (76 Êá)
Fig 4b. The "Subsystems" tab of the main page of the configuration of the station.

The service task of the redundancy mechanism is always running and executed at intervals which are prescribed in the appropriate configuration field. The real work on implementing the redundancy is carried out in the presence of at least one redundant station in the list of stations, and implies:


There is recommended the redundancy configure in way for DBs of the redundant stations save equal and that will allow you to copy its painlessly to each the station and then to backup only one the DBs set. And the configurations specified to the different stations will save into the configuration file and you can simply configure and change the needed station by the proper configuration file select.


The redundancy configuration start from the redundant stations appending to list of system stations OpenSCADA in tab "Subsystem" of the subsystem "Transports" (Fig.4.3b). And to add here needs not only the redundant stations to the current one but the same current one with its external IP, that is some loop. Further this configurations will have been stored into the generic DB of the redundant system, and from this time the DBs will be used for that all redundant station creation. Then there is important to make on that stage all needed changes into the generic DB and about this project in general!


Next for the concrete station, with copy of the generic DB, we configure its specific parameters into the tab "Redundancy" of the main page (Fig.4c), which will be stored into the configuration file.


After that all next configurations of redundancy perform into the tab "Redundancy" of proper subsystem, "Data acquisition" (Fig.4.5b) or "Archives" (Fig.4.6b). If you will set the parameter "Local primary commands transfer" (Fig.4c) then the configurations, like to any other generic configurations, can be performed at any one from the stations and all the performed changes will be transferred to all other ones, sure if its are available.


The "Redundancy" tab of the main page of the configuration of the station. (93 Êá)
Fig 4c. The "Redundancy" tab of the main page of the configuration of the station.

The "Tasks" tab of the main page of the configuration of the station. (196 Êá)
Fig 4d. "Tasks" tab of the main page of the configuration of the station.

For OpenSCADA different working specific debug you may be necessary to enable addition-debugging messages generation, which you can set by select minimal messages level, into tab "Station", to "Debug (0)". As a result of this will emerge tab "Debug" (fig.4e) where available the objects counters for control to leaks, and also the table with incoming debug messages' categories list. Into the table you can select only needed debug messages sources and omit to overload the archiving messages subsystem and overall the system performance decrease. You can also select higher categories, up to root system category, that will disable detailed selection and enable all messages generation by the level or by overall system. For the debug messages observing you need to go subsystem "Archives" (fig. 4.6c), and for this provided button "See to messages". Selected debug mode and debug categories list can be standard stored to configuration file and on next boot the debug mode will be activated, this important primarily for the objects counters.


The "Debug" tab of the main page of the configuration of the station. (98 Êá)
Fig. 4e. The "Debug" tab of the main page of the configuration of the station.

The "Translations" tab of the main page of the configuration of the station. (158 Êá)
Ðèñ. 4f. The "Translations" tab of the main page of the configuration of the station.

While examining the configuration pages of modular subsystems there will be described the general for all modules properties. However, it should be noted that each module can provide both: the additional tabs, and separate fields for the configuration of their own functioning for the pages, objects of which are inherited by modules. Information on the features and additions of the modules can be found in separate documentation for each of them.

4.1. "DB" subsystem

The subsystem is the modular one and contains a hierarchy of objects depicted in Figure 4.1a. To configure the subsystem the root page of the subsystem "DB" containing the tab "Modules". Tab "Modules" (Fig. 4.1b) contains the list of modules in subsystem "DB", available at the station.


To modify the page's fields of this subsystem it may be required the super user's rights or the inclusion of your user to the "DB" group.


The hierarchical structure of DB subsystem. (37 Êá)
Fig. 4.1a. The hierarchical structure of "DB" subsystem.

Tab "Modules" tab of the root page of "DB" subsystem. (58 Êá)
Fig. 4.1b. Tab "Modules" tab of the root page of "DB" subsystem.

Each module of the "DB" subsystem provides the configuration page with the following tabs: "DB" and "Module". "DB" tab (Fig. 4.1c) contains the list of databases registered in the module and the flag of the sign of full deleting of the database when making the delete command. In the context menu of the databases' list the user is provided with an opportunity to add, delete and move to the desired database. The "Module" tab contains information about the module of the "DB" subsystem (Fig.4.1d):


"DB" tab of the module of "DB" subsystem. (61 Êá)
Fig. 4.1c. "DB" tab of the module of "DB" subsystem.

"Module" tab of the module of the "DB" subsystem. (72 Êá)
Fig. 4.1d. "Module" tab of the module of the "DB" subsystem.

Each database contains its own configuration page with the tabs "Data base", "Tables" and "SQL", in case SQL-requests support. Besides the basic operations you can copy the contents of the DB by means of the standard function for the copying the objects in the configurator. The copying operation the DB contents involves the copying of the original database to the destination database, and the contents of the destination database is not cleared before the copy operation. Copying the contents of database is made only when the both databases are enabled, otherwise it will run a simple copy of the object of the database.


Tab "Data base" (Fig.4.1e) contains the main configuration options of the DB as follows:


Tab "Tables" (Fig.4.1f) contains the list of the opened pages. In normal mode of the program operation this tab is empty, because after the completion of working with tables the program closes them. The presence of opened tables tells that the program is now working with tables or tables are opened by the user to examine their contents. In the context menu of list of opened tables you can open the table for study (the command "Add"), close the opened page (the command "Delete") and proceed to examination of the contents of the table.


Tab "SQL" (Fig.4.1g) allow only for data bases which support SQL-requests, and contains field to request enter, button to request send and table to result. To control the request transaction context provided by separate configuration field.


Tab "Data base" of the DB of module of subsystem "DB". (80 Êá)
Fig. 4.1e. Tab "Data base" of the DB of module of subsystem "DB".

Tab "Tables" of the DB of module of subsystem "DB". (50 Êá)
Fig. 4.1f. Tab "Tables" of the DB of module of subsystem "DB".

Tab "SQL" of the DB of module of subsystem "DB". (106 Êá)
Fig. 4.1g. Tab "SQL" of the DB of module of subsystem "DB".

Page of the examination of the contents of the table contains only one tab, "Table". Tab "Table" (Figure 4.1h) contains the field of the name of the table and the table with the contents. Table of contents provides the following functions:


Tab "Table" of the DB table of the module of the subsystem "DB". (99 Êá)
Fig. 4.1h. Tab "Table" of the DB table of the module of the subsystem "DB".

4.2. Subsystem "Security"

The subsystem is not modular one. To configure the subsystem the root page of the subsystem "Security" is provided, which contains the tab "Users and Groups". Tab "Users and Groups" (Figure 4.2a) contains the list of users and users' groups. Users in the group "Security" and with the rights of the privileged user can add, delete the user or group of users. All other users can go to the page the user or the users' group.


Tab "Users and Groups" of the root page of the subsystem "Security". (57 Êá)
Fig. 4.2a. Tab "Users and Groups" of the root page of the subsystem "Security".

To configure the user it is provided the page containing only the tab "User" (Fig.4.2b). Tab contains the configuration data of the user's profile, which can be changed by the user itself, the user of the "Security" group or the privileged user:


The tab "User" of the user's page of "Security" subsystem. (77 Êá)
Fig. 4.2b. The tab "User" of the user's page of "Security" subsystem.

To configure the user's group it is provided the page containing only the tab "Group" (Fig.4.2c). Tab contains the configuration data of the group's profile, which can be changed only by the privileged use:


The tab "Group" of the user's group page of "Security" subsystem. (60 Êá)
Fig. 4.2c. The tab "Group" of the user's group page of "Security" subsystem.

4.3. Subsystem "Transports"

The subsystem is the modular one and contains the hierarchy of objects shown in Figure 4.3a. To configure the subsystem it is provided the root page of the subsystem "Transports", containing the tabs "Subsystem" and "Modules".


The hierarchical structure of subsystems Transports. (20 Êá)
Fig. 4.3a. The hierarchical structure of subsystems "Transports".

The tab "Subsystem" (Figure 4.3b) contains the configuration table of the external stations for a given OpenSCADA. External stations can be the system, user and both ones that is selected by the appropriate column. System's external stations are available only to the super user and are used by the components of the system purpose, for example, the mechanism of the horizontal redundancy and module DAQ.DAQGate. User's external stations are tied to the user who created them, and thus the list of user's external stations is individual for each user. User's external stations are used by the components of graphical interface, for example, UI.QTCfg, UI.WebCfgD and UI.Vision. In the table of the external stations it is possible to add and delete records about the station, as well as their modification.
Each station contains the following fields:


Tab "Moules" tab (fig. 4.1b) contains the list of modules in subsystem "Transports" and it is identical for all modular subsystems.


Tab "Subsystem" of the root page of subsystem "Transports". (77 Êá)
Fig. 4.3b. Tab "Subsystem" of the root page of subsystem "Transports".

Each module of the subsystem "Transports" provides the configuration page with the tabs "Transports" and "Module". The tab "Transports" (Fig.4.3c) contains the list of incoming and outgoing transports registered in the module. The context menu of lists of transports provides the user with the possibility to add, delete and move to the desired transport. On the "Module" tab it is provided the information about the module of subsystem "Transports" (Fig. 4.1d), whose structure is identical for all modules.


The tab "Transports" of the module of subsystem "Transports". (64 Êá)
Fig. 4.3c. The tab "Transports" of the module of subsystem "Transports".

Each transport contains its own configuration page with one tab "Transport". This tab contains the basic settings of transport. Incoming transport (fig.4.3d) includes:


Tab "Transport" of the page of incoming transport of module of subsystem "Transports". (85 Êá)
Fig. 4.3d. Tab "Transport" of the page of incoming transport of module of subsystem "Transports".

Outgoing transport (Fig. 4.3e) contains:


Tab "Transport" of the page of outgoing transport of module of subsystem "Transports". (89 Êá)
Fig. 4.3e. Tab "Transport" of the page of outgoing transport of module of subsystem "Transports".

Outgoing transport, in addition, provides the tab for forming the user request via this transport (Fig.4.3f). The tab is provided for setting communication, as well as for debugging the protocols and includes:


The tab "Request" of the page of outgoing transport of module of subsystem "Transports". (99 Êá)
Fig. 4.3f. The tab "Request" of the page of outgoing transport of module of subsystem "Transports".

4.4. Subsystem "Transport protocols"

The subsystem is modular. To configure the subsystem the root page of the subsystem "Transport Protocols" is provided, it contains tab "Modules". The tab "Modules" (Fig. 4.1b) contains the list of modules in subsystem "Transport Protocols" and is identical for all modular subsystems.


Each module of subsystem "Transport Protocols" provides configuration page with the only one tab — "Module". On the tab "Module" there is the information on the module of subsystem "Transport Protocols" (Fig. 4.1d), which structure is identical for all modules.

4.5. Subsystem "Data acquisition"

The subsystem is modular and contains the hierarchy of objects depicted in Fig.4.5a. To configure the subsystem the root page of subsystem "Data acquisition" is provided, which contains the tabs "Redundancy", "Template libraries" and "Modules".


To obtain access to modify the objects of this subsystem the user of the group "DAQ" or the rights of the privileged user are required.


The hierarchical structure of subsystem Data acquisition. (41 Êá)
Fig. 4.5a. The hierarchical structure of subsystem "Data acquisition".

As a redundancy object of the subsystem "Data Acquisition" there used the object of controller for which the redundancy process performs that functions:


Tab "Redundancy" (Fig. 4.5b) presented only if at last one station pointed into the redundancy and contains the configuration of redundancy of data sources of subsystem "Data acquisition" with the following settings:


Tab "Redundancy" tab of subsystem "Data acquisition". (104 Êá)
Fig. 4.5b. Tab "Redundancy" tab of subsystem "Data acquisition".

The tab "Template libraries" (Fig.4.5c) contains the list of libraries of templates for the parameters of this subsystem. In the context menu of the list of template libraries the user can add, delete and move to the desired library. The tab "Modules" (Fig. 4.1b) contains the list of modules in the subsystem "Transports" and is identical for all modular subsystems.


The tab "Template libraries" of the subsystem "Data acquisition". (56 Êá)
Fig. 4.5c. The tab "Template libraries" of the subsystem "Data acquisition".

Each template library of subsystem "Data acquisition" provides the configuration page with the tabs "Library" and "Parameter templates". Tab "Library" (fig. 4.5d) contains the basic settings of the library:


Tab "Parameter templates" (Fig.4.5e) contains the list of templates in the library. In the context menu of the list the user can add, delete and move to the desired template.


The main tab of configuration of template library of subsystem "Data acquisition". (67 Êá)
Fig. 4.5d. The main tab of configuration of template library of subsystem "Data acquisition".

The tab of the list of templates in the template library of subsystem "Data acquisition". (61 Êá)
Fig. 4.5e. The tab of the list of templates in the template library of subsystem "Data acquisition".

Each template of the template library provides the configuration page with the tabs "Template" and "IO". The tab "Template" (Figure 4.5f) contains the basic settings of the template:


The main configuration tab of the parameters template of subsystem "Data acquisition". (77 Êá)
Fig. 4.5f. The main configuration tab of the parameters template of subsystem "Data acquisition".

The tab "IO" (Fig.4.5g) contains the configuration of attributes (IO) of templates and the program of template on the one of languages of the user programming of OpenSCADA, for example, DAQ.JavaLikeCalc.JavaScript. To the table of attributes of template user can, through the context menu, add, insert, delete, move up or down the record of attribute, as well as edit the attribute's fields:


The syntax of the language of the template's program you can see in the documentation of the module, providing an interpreter of the chosen language. For example, a typical user programming language of OpenSCADA — DAQ.JavaLikeCalc.


The configuration tab of the attributes and template's program of subsystem "Data acquisition". (139 Êá)
Fig. 4.5g. The configuration tab of the attributes and template's program of subsystem "Data acquisition".

Each module of the subsystem "Data acquisition" provides the configuration page with the tabs "Controllers" and "Module". The tab "Controllers" (Fig.4.5h) contains the list of controllers, registered in the module. In the context menu user can add, delete and move to the desired controller. The tab "Module" provides information about the module of the subsystem "Data acquisition" (Fig. 4.1d), which structure is identical for all modules.


The tab "Controllers" of the module of the subsystem "Data acquisition". (66 Êá)
Fig. 4.5h. The tab "Controllers" of the module of the subsystem "Data acquisition".

Each controller contains its own configuration page with the tabs "Controller" and "Parameters".


The tab "Controller" (Fig.4.5i) contains the basic settings. The structure of these settings may differ slightly from one module of this subsystem to another, as you can find in the own documentation of modules. As an example, lets examine the settings of the controller in the module of the controller of logic DAQ.LogicLev:


The main configuration tab of the controller of subsystem "Data acquisition". (78 Êá)
Fig. 4.5i. The main configuration tab of the controller of subsystem "Data acquisition".

"Parameters" tab (Fig.4.5j) contains a list of parameters in the controller, select the type of parameters that are created by default, as well as information on the total number and the number of enabled parameters. In the context menu user can add, delete and move to the desired parameter.


"Parameters" tab of the configuration page of the controller of subsystem "Data acquisition". (62 Êá)
Fig. 4.5j. "Parameters" tab of the configuration page of the controller of subsystem "Data acquisition".

"Diagnostic" tab (Fig.4.5k) contains diagnostic messages form by the data source. More data sources is external devices with accessing to the data by a network connection or a system bus then there possible different emergency situation on access to the data. Print all its to field "State" of controller object impossible due it display only current access data state. Due the diagnostic you can trace all emergency situation at messages view, which forming by the controller object for specified period of time and by selected messages level. Besides to certain diagnostic information some modules of data sources can provide here debug exchange dumps, on messages level "Debug (0)".


"Diagnostic" tab of configuration page of the controller of subsystem "Data acquisition". (135 Êá)
Fig. 4.5k. "Diagnostic" tab of configuration page of the controller of subsystem "Data acquisition".

Parameters of the controllers of subsystem "Data acquisition" provides the configuration page with the tabs "Parameters", "Attributes", "Archiving" and "Template config". The tab "Template config" is not standard, but it is present only in the parameters of modules of subsystem "Data acquisition", which implement the mechanisms of working under the template in the context of the data source, which they are served, for logical type. In this review this tab is included for logical completeness of the review of the configuration of templates of parameters of subsystem "Data acquisition" and as the final stage — using.


The tab "Parameter" (Fig.4.5l) contains the main settings:


The tab "Attributes" (Fig.4.5m) contains the parametr's attributes and their values in accordance with the configuration of the used template and calculation of its program.


The "Archiving" tab (Fig.4.5n) contains the table with the attributes of a parameter in the columns and the archivers in rows. The user can set the archiving for the desired attribute with the required archiver simply by changing the cell at the intersection.


The "Template config" tab (Figure 4.5o) contains the configuration fields in accordance with the template. In this example it is the group link on the external parameter. This link can be set simply by pointing the way to the parameter if the flag "Only attributes are to be shown" is not set, or to set the addresses of the attributes separately in the case if the flag is set. Sign "(+)", at the end of the address signals about successful linking and presence of the target.


The main configuration tab of the parameter of the controller of subsystem "Data acquisition". (55 Êá)
Fig. 4.5l. The main configuration tab of the parameter of the controller of subsystem "Data acquisition".

The "Attributes" tab of the parameter of the controller of subsystem "Data acquisition". (55 Êá)
Fig. 4.5m. The "Attributes" tab of the parameter of the controller of subsystem "Data acquisition".

The "Archiving" tab of the parameter of the controller of subsystem "Data acquisition". (58 Êá)
Fig. 4.5n. The "Archiving" tab of the parameter of the controller of subsystem "Data acquisition".

The "Template config" tab of the parameter of the controller of subsystem "Data acquisition". (65 Êá)
Fig. 4.5o. The "Template config" tab of the parameter of the controller of subsystem "Data acquisition".

4.6. Subsystem "Archives"

The subsystem is modular and contains the hierarchy of objects depicted in Fig.4.6a. To configure the subsystem the root page of the subsystem "Archives" is provided, it contains tabs: "Redundancy", "Messages archive", "Value archives" and "Modules".


To gain the access to modify the objects of this subsystem the user of the group "Archive" or the privileged user rights are required.


The hierarchical structure of subsystem Archives (24 Êá)
Fig. 4.6a. The hierarchical structure of subsystem "Archives"

As a redundancy object of the subsystem "Archives" there used the object of messages archivator for which the redundancy process performs that functions:


Redundancy of the value archivators doesn't provided directly but that process does through data sources and the subsystem of "Data acquisition".


Tab "Redundancy" (Fig. 4.6b) presented only if at last one station pointed into the redundancy and contains the configuration of redundancy of messages archvators with the following settings:


The "Redundancy" tab of subsystem "Archives". (80 Êá)
Fig. 4.6b. The "Redundancy" tab of subsystem "Archives".

The "Messages archive" tab (Fig.4.6c) contains the configuration of messages archive and the request form of messages from the archive.


Configuration of the messages archive is represented by the fields:


The messages request form contains the configuration fields of the request and the table of results. Configuration fields of the request are:


The result table contains rows of messages with the following columns:


The "Messages archive" tab of the subsystem "Archives". (131 Êá)
Fig. 4.6c. The "Messages archive" tab of the subsystem "Archives".

Tab "Value archives" (Fig.4.6d) contains the general configuration of value's archiving and the list of archives of values. In the context menu of the list of values the user has the opportunity to add, delete and move to the desired archive. The general configuration of archiving is represented by the fields:


The "Modules" tab (Fig. 4.1b) contains a list of modules in subsystem "Archives" and it is identical for all modular subsystems.


The "Value archives" tab of the subsystem "Archives". (76 Êá)
Fig. 4.6d. The "Value archives" tab of the subsystem "Archives".

Archive of values of subsystem "Archives" provides the configuration page with the tabs "Archive", "Archivators" and "Values".


Tab "Archive" (Fig.4.6e) contains the basic settings of the archive:


The main configuration tab of the values' archive of subsystem "Archives". (138 Êá)
Fig. 4.6e. The main configuration tab of the values' archive of subsystem "Archives".

Tab Archivators' (Fig.4.6f) contains the table with the configuration of the processing of the archive by the available archivers. Lines are available archivers, and the columns are the following parameters:


The "Archivators" tab of the values archive of subsystem "Archives". (72 Êá)
Fig. 4.6f. The "Archivators" tab of the values archive of subsystem "Archives".

Tab "Values" (Fig.4.6g) contains the values request in the archive and the result as a table of values or image of the trend. Values request contains the fields:


The "Values" tab of the values archive of subsystem "Archives". (109 Êá)
Fig. 4.6g. The "Values" tab of the values archive of subsystem "Archives".

Each module of the "Archives" subsystem provides configuration page with the tabs "Archivators" and "Module". The "Archivators" tab (Fig.4.6h) contains a list of messages and values archivers registered in the module. The context menu of the list provides user with possibility to add, delete and move to the desired controller. The "Module" tab contains information about the module of subsystem "Archives" (Fig. 4.1d), whose structure is identical for all modules.


The "Archivators" tab of the module of subsystem "Archives". (62 Êá)
Fig. 4.6h. The "Archivators" tab of the module of subsystem "Archives".

Messages archivators contains their own configuration page with tabs "Archivator" and "Messages".


The "Archivator" tab (Fig.4.6i) contains the basic settings. The structure of these settings may differ slightly from one module of this subsystem to another as you can find in the own documentation of modules. As an example we shall examine the settings of the messages archiver from the module of the archive on the file system Arch.FSArch Settings:


The main tab of the messages archiver configuration of subsystem "Archives". (93 Êá)
Fig. 4.6i. The main tab of the messages archiver configuration of subsystem "Archives".

The "Messages" tab (Fig.4.6j) contains the form of the messages request from the archive of the archiver:


The result table contains messages rows with the following columns:


Tab of the messages request "Messages" of the messages archiver of subsystem "Archives". (155 Êá)
Fig. 4.6j. Tab of the messages request "Messages" of the messages archiver of subsystem "Archives".

Values archivers contains their own configuration page with tabs "Archivator" and "Archives".


The "Archivator" tab (Fig.4.6k) contains the basic settings. The structure of these settings may differ slightly from one module of this subsystem to another as you can find in the own documentation of modules. As an example we shall examine the settings of the messages archiver from the module of the archive on the file system Arch.FSArch Settings:


The main tab of the values archiver configuration of subsystem "Archives". (107 Êá)
Fig. 4.6k. The main tab of the values archiver configuration of subsystem "Archives".

The "Archives" tab (Fig.4.6l) contains a table with information about the archives being processed by the archiver. In the rows the table contains archives, and in the columns — the following information:


In the case of the module Arch.FSArch in this tab you can find the form of export the archiver's data.


The "Archives" tab of the values archiver of subsystem "Archives". (86 Êá)
Fig. 4.6l. The "Archives" tab of the values archiver of subsystem "Archives".

4.7. Subsystem "User interfaces"

The subsystem is modular. To configure the subsystem the root page of the subsystem "User Interfaces" is provided, it contains the tab "Modules". The "Modules" tab (Fig. 4.1b) contains a list of modules of subsystem and it is identical for all modular subsystems.


Each module of the subsystem "User Interfaces" provides configuration page with the tabs "User Interface" and "Module". The "User Interface" tab (Fig.4.7a) provides the parameter for monitoring the "Running" status of the module, as well as the configuration sections specialized for the modules of this subsystem. On the "Module" tab there is an information about the module of the subsystem "User Interfaces" (Fig. 4.1d), which structure is identical for all modules.


The "User Interface" tab of the module of subsystem "User Interfaces". (70 Êá)
Fig. 4.7a. The "User Interface" tab of the module of subsystem "User Interfaces".

4.8. Subsystem "Specials"

The subsystem is modular. To configure the subsystem the root page of the subsystem "User Interfaces" is provided, it contains the tab "Modules". The "Modules" tab (Fig. 4.1b) contains a list of modules of subsystem and it is identical for all modular subsystems.


Each module of the subsystem "Specials" provides configuration page with the tabs "Special" and "Module". The "Special" tab (Fig.4.8a) provides the parameter for monitoring the "Running" status of the module, as well as the configuration sections specialized for the modules of this subsystem. On the "Module" tab there is an information about the module of the subsystem "Specials" (Fig. 4.1d), which structure is identical for all modules.


The "Special" tab of the module of subsystems "Specials". (66 Êá)
Fig. 4.8a. The "Special" tab of the module of subsystems "Specials".

4.9. Subsystem "Modules scheduler"

The subsystem is not modular. To configure the subsystem the subsystem's page "Modules scheduler" is provided, it contains tab "Subsystem". The "Subsystem" tab (Fig.4.9a) contains the basic settings of the subsystem. The structure of the tab "Subsystem":


The main configuration tab of subsystem "Modules scheduler". (142 Êá)
Fig. 4.9a. The main configuration tab of subsystem "Modules scheduler".

4.10. Configuration file of the OpenSCADA and parameters of command-line OpenSCADA execution.

Configuration file of the OpenSCADA system is provided to store the system and general configuration of OpenSCADA-station. Only in the configuration file and through the command-line options you can specify the part of the key system parameters of the station, so familiarity with the structure of the configuration file is necessary for professionals who make solutions based on OpenSCADA.


The configuration file of the OpenSCADA system can be called somehow, but the oscada.xml name and derived from it are accepted. The configuration file is usually indicated when you start the station by the command-line option "--config=/home/roman/roman/work/OScadaD/etc/oscada_demo.xml". For the convenience of the calling the startup scripts of the station are created with the correct configuration file or used the project manager at start script openscada_start. For example script (openscada_demo) uses for the demo station execution:


#!/bin/sh
openscada --config=/etc/oscada_demo.xml $@


If the configuration file is not specified then the standard configuration file: /etc/oscada.xml is used.


Structure of the configuration file based on the extensible markup language XML. Therefore the strict adherence to the rules of XML syntax is required. An example of the configuration file of the OpenSCADA, with configuration nodes of most of the OpenASCADA components, is given below:


<?xml version="1.0" encoding="UTF-8" ?>
<OpenSCADA>
    <!--
    This is the OpenSCADA configuration file.
    -->
    <station id="AGLKS">
        <!--
        Describe internal parameters for station.
        The station is OpenSCADA program.
        -->
        <prm id="StName">AGLKS</prm>
        <prm id="StName_ru">ÀÃËÊÑ</prm>
        <prm id="StName_uk">ÀÃËÊÑ</prm>
        <prm id="WorkDB">SQLite.GenDB</prm>
        <prm id="LogTarget">10</prm>
        <prm id="Lang2CodeBase">en</prm>
        <prm id="SaveAtExit">0</prm>
        <prm id="SavePeriod">0</prm>

        <node id="sub_BD">
            <prm id="SYSStPref">0</prm>
            <tbl id="DB">
                <fld ID="GenDB" TYPE="SQLite" NAME="Generic DB" NAME_ru="Îñíîâíàÿ ÁÄ" NAME_uk="Îñíîâíà ÁÄ" ADDR="St.db" CODEPAGE="UTF-8"/>
            </tbl>
        </node>

        <node id="sub_Security">
            <!--
            <tbl id="Security_user">
                <fld
                    NAME="root"
                    DESCR="Super user"
                    DESCR_ru="Ñóïåð ïîëüçîâàòåëü"
                    DESCR_uk="Ñóïåð êîðèñòóâà÷"
                    PASS="openscada"/>
                <fld
                    NAME="user"
                    DESCR="System user"
                    DESCR_ru="Ñèñòåìíûé ïîëüçîâàòåëü"
                    DESCR_uk="Ñèñòåìíèé êîðèñòóâà÷"
                    PASS=""/>
            </tbl>
            <tbl id="Security_grp">
                <fld
                    NAME="root"
                    DESCR="Super users groups"
                    DESCR_ru="Ãðóïïà ñóïåðïîëüçîâàòåëåé"
                    DESCR_uk="Ãðóïà ñóïåðêîðèñòóâà÷³â"
                    USERS="root;user"/>
            </tbl>-->
        </node>

        <node id="sub_ModSched">
            <prm id="ModAllow">*</prm>
            <prm id="ModDeny"></prm>
            <prm id="ChkPer">0</prm>
        </node>

        <node id="sub_Transport">
            <!--
            <tbl id="Transport_in">
                <fld
                    ID="WEB_1"
                    MODULE="Sockets"
                    NAME="Generic WEB interface"
                    NAME_ru="Îñíîâíîé WEB èíòåðôåéñ"
                    NAME_uk="Îñíîâíèé WEB ³íòåðôåéñ"
                    DESCRIPT="Generic transport for WEB interface."
                    DESCRIPT_ru="Îñíîâíîé òðàíñïîðò äëÿ WEB èíòåðôåéñà."
                    DESCRIPT_uk="Îñíîâíèé òðàíñïîðò äëÿ WEB ³íòåðôåéñó."
                    ADDR="TCP::10002:0"
                    PROT="HTTP"
                    START="1"/>
                <fld
                    ID="WEB_2"
                    MODULE="Sockets"
                    NAME="Reserve WEB interface"
                    NAME_ru="Ðåçåðâíûé WEB èíòåðôåéñ"
                    NAME_uk="Ðåçåðâíèé WEB ³íòåðôåéñ"
                    DESCRIPT="Reserve transport for WEB interface."
                    DESCRIPT_ru="Ðåçåðâíûé òðàíñïîðò äëÿ WEB èíòåðôåéñà."
                    DESCRIPT_uk="Ðåçåðâíèé òðàíñïîðò äëÿ WEB ³íòåðôåéñó."
                    ADDR="TCP::10004:0"
                    PROT="HTTP"
                    START="1"/>
            </tbl>
            <tbl id="Transport_out">
                <fld
                    ID="testModBus"
                    MODULE="Sockets"
                    NAME="Test ModBus"
                    NAME_ru="Òåñò ModBus"
                    NAME_uk="Òåñò ModBus"
                    DESCRIPT="Data exchange by protocol ModBus test."
                    DESCRIPT_ru="Òåñò îáìåíà ïî ïðîòîêîëó ModBus."
                    DESCRIPT_uk="Òåñò îáì³íó çà ïðîòîêîëîì ModBus."
                    ADDR="TCP:localhost:10502"
                    START="1"/>
            </tbl>-->
        </node>

        <node id="sub_DAQ">
            <!--
            <tbl id="tmplib">
                <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" DB="tmplib_test2"/>
            </tbl>
            <tbl id="tmplib_test2">
                <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk=""
                    PROGRAM="JavaLikeCalc.JavaScript&#010;cnt=5*i;"/>
            </tbl>
            <tbl id="tmplib_test2_io">
                <fld TMPL_ID="test2" ID="i" NAME="I" NAME_ru="I" NAME_uk="I" TYPE="4" FLAGS="160" VALUE="" POS="0"/>
                <fld TMPL_ID="test2" ID="cnt" NAME="Cnt" NAME_ru="Cnt" NAME_uk="Cnt" TYPE="4" FLAGS="32" VALUE="" POS="0"/>
            </tbl>-->

            <node id="mod_LogicLev">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="test2"
                        NAME="Test 2"
                        NAME_ru="Òåñò 2"
                        NAME_uk="Òåñò 2"
                        DESCR=""
                        DESCR_ru=""
                        DESCR_uk=""
                        ENABLE="1"
                        START="1"
                        PRM_BD="test2prm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" MODE="2" PRM="test2.test2"/>
                </tbl>-->
            </node>

            <node id="mod_System">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="DataOS"
                        NAME="Data OS"
                        NAME_ru="Äàíûå ÎÑ"
                        NAME_uk="Äàí³ ÎÑ"
                        DESCR="Data of services and subsystems OS."
                        DESCR_ru="Äàííûå ñåðâèñîâ è ïîäñèñòåì ÎÑ."
                        DESCR_uk="Äàí³ ñåðâ³ñ³â òà ï³äñèñòåì ÎÑ."
                        ENABLE="1"
                        START="1"
                        AUTO_FILL="0"
                        PRM_BD="DataOSprm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="DataOSprm">
                    <fld SHIFR="CPU" NAME="CPU load" NAME_ru="Íàãðóçêà CPU" NAME_uk="Íàâàíòàæåííÿ CPU" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" TYPE="CPU" SUBT="gen"/>
                    <fld SHIFR="MEM" NAME="Memory" NAME_ru="Ïàìÿòü" NAME_uk="Ïàì\'ÿòü" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" TYPE="MEM"/>
                </tbl>
                -->
            </node>

            <node id="mod_DiamondBoards">
                <!--
                <tbl id="DAQ">
                    <fld ID="Athena" NAME="Athena board" NAME_ru="Ïëàòà Athena" NAME_uk="Ïëàòà Athena" DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="0" BOARD="25" PRM_BD_A="AthenaAnPrm" PRM_BD_D="AthenaDigPrm" ADDR="640" INT="5"
                        DIO_CFG="0" ADMODE="0" ADRANGE="0" ADPOLAR="0" ADGAIN="0" ADCONVRATE="1000"/>
                </tbl>
                <tbl id="AthenaAnPrm">
                    <fld SHIFR="ai0" NAME="AI 0" NAME_ru="AI 0" NAME_uk="AI 0" DESCR="" DESCR_ru="" DESCR_uk="" EN="0" TYPE="0" CNL="0" GAIN="0"/>
                </tbl>
                <tbl id="AthenaDigPrm">
                    <fld SHIFR="di0" NAME="DI 0" NAME_ru="DI 0" NAME_uk="DI 0" DESCR="" DESCR_ru="" DESCR_uk="" EN="0" TYPE="0" PORT="0" CNL="0"/>
                </tbl>
                -->
            </node>

            <node id="mod_BlockCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="Model" NAME="Model" NAME_ru="Ìîäåëü" NAME_uk="Ìîäåëü" DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="Model_prm" BLOCK_SH="Model_blcks" PERIOD="1000" PRIOR="0" PER_DB="0" ITER="1"/>
                </tbl>
                <tbl id="Model_blcks">
                    <fld ID="Klap" NAME="Klapan" NAME_ru="Êëàïàí" NAME_uk="Êëàïàí" DESCR="" DESCR_ru="" DESCR_uk=""
                        FUNC="DAQ.JavaLikeCalc.lib_techApp.klap" EN="1" PROC="1"/>
                </tbl>
                <tbl id="Model_blcks_io">
                    <fld BLK_ID="Klap" ID="l_kl1" TLNK="0" LNK="" VAL="50"/>
                    <fld BLK_ID="Klap" ID="l_kl2" TLNK="0" LNK="" VAL="20"/>
                </tbl>
                <tbl id="Model_prm">
                    <fld SHIFR="l_kl" NAME="Klap lev" NAME_ru="Ïîëîæ. êëàïàíà" NAME_uk="Ïîëîæ. êëàïàíà" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" IO="Klap.l_kl1"/>
                </tbl>
                -->
            </node>

            <node id="mod_JavaLikeCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="CalcTest" NAME="Calc Test" NAME_ru="Òåñò âû÷èñë." NAME_uk="Òåñò îá÷èñë." DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="CalcTest_prm" FUNC="TemplFunc.d_alarm" SCHEDULE="1" PRIOR="0" ITER="1"/>
                </tbl>
                <tbl id="CalcTest_val">
                    <fld ID="in" VAL="0"/>
                    <fld ID="alrm" VAL=""/>
                    <fld ID="alrm_md" VAL="1"/>
                    <fld ID="alrm_mess" VAL="Error present."/>
                </tbl>
                <tbl id="CalcTest_prm">
                    <fld SHIFR="alrm" NAME="Alarm" NAME_ru="Àâàðèÿ" NAME_uk="Àâàð³ÿ" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" FLD="alrm"/>
                </tbl>
                <tbl id="lib">
                    <fld ID="TemplFunc" NAME="" NAME_ru="" NAME_uk="" DESCR="" ESCR_ru="" DESCR_uk="" DB="lib_TemplFunc"/>
                </tbl>
                <tbl id="lib_TemplFunc">
                    <fld ID="d_alarm" NAME="Digit alarm" NAME_ru="Àâàðèÿ ïî äèñêð." NAME_uk="Àâàð³ÿ çà äèñêð" DESCR=""
                        FORMULA="alrm=(in==alrm_md)?&quot;1:&quot;+alrm_mess:&quot;0&quot;;"/>
                </tbl>
                <tbl id="lib_TemplFunc_io">
                    <fld F_ID="d_alarm" ID="in" NAME="Input" NAME_ru="Âõîä" NAME_uk="Âõ³ä" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
                    <fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_ru="Àâàðèÿ" NAME_uk="Àâàð³ÿ" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
                    <fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_ru="Ðåæèì àâàðèè" NAME_uk="Ðåæèì àâàð³¿"
                        TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
                    <fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_ru="Ñîîáù. àâàðèè" NAME_uk="Ïîâ³ä. àâàð³¿"
                        TYPE="0" MODE="0" DEF="" HIDE="0" POS="3"/>
                </tbl>-->
            </node>

            <node id="mod_Siemens">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" CIF_DEV="0" ADDR="5" ASINC_WR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" TMPL="S7.ai_man"/>
                </tbl>-->
            </node>

            <node id="mod_SNMP">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="test2prm" PERIOD="1000" PRIOR="0" ADDR="localhost" COMM="public" PATTR_LIM="20"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" OID_LS="system"/>
                </tbl>-->
            </node>

            <node id="mod_ModBus">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" TRANSP="Sockets" ADDR="exlar.diya.org" NODE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1"
                        ATTR_LS="321:0:tst:Test"/>
                </tbl>-->
            </node>

            <node id="mod_DAQGate">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" SYNCPER="60" STATIONS="loop" CNTRPRM="System.AutoDA"/>
                </tbl>-->
            </node>

            <node id="mod_DCON">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" ADDR="" REQ_TRY="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" MOD_TP="0"
                        MOD_ADDR="1" CRC_CTRL="1"/>
                </tbl>-->
            </node>

            <node id="mod_ICP_DAS">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" BUS="1" BAUD="115200" LP_PRMS="" REQ_TRY="3"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1"
                        MOD_TP="552985" MOD_ADDR="0" MOD_SLOT="1" MOD_PRMS="0"/>
                </tbl>-->
            </node>

            <node id="mod_OPC_UA">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" SCHEDULE="1" PRIOR="0" SYNCPER="60" ADDR="" EndPoint="opc.tcp://localhost:4841" SecPolicy="None"
                        SecMessMode="1" Cert="" PvKey="" AttrsLimit="100"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" ND_LS=""/>
                </tbl>-->
            </node>

            <node id="mod_SoundCard">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" CARD="" SMPL_RATE="8000" SMPL_TYPE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" CHANNEL="0"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Archive">
            <prm id="MessBufSize">1000</prm>
            <prm id="MessPeriod">5</prm>
            <prm id="ValPeriod">1000</prm>
            <prm id="ValPriority">10</prm>
            <!--
            <tbl id="Archive_mess_proc">
                <fld
                    ID="StatErrors"
                    MODUL="FSArch"
                    NAME="Errors"
                    NAME_ru="Îøèáêè"
                    NAME_uk="Ïîìèëêè"
                    DESCR="Local errors\' archive"
                    DESCR_ru="Àðõèâ ëîêàëüíûõ îùèáîê"
                    DESCR_uk="Àðõ³â ëîêàëüíèõ ïîìèëîê"
                    START="1"
                    CATEG="/DemoStation*"
                    LEVEL="4"
                    ADDR="ARCHIVES/MESS/stError/"/>
                <fld
                    ID="NetRequsts"
                    MODUL="FSArch"
                    NAME="Net requests"
                    NAME_ru="Ñåòåâûå çàïðîñû"
                    NAME_uk="Ìåðåæåâ³ çàïèòè"
                    DESCR="Requests to server through transport Sockets."
                    DESCR_ru="Çàïðîñû ê ñåðâåðó ÷åðåç òðàíñïîðò Sockets."
                    DESCR_uk="Çàïèòè äî ñåðâåðà ÷åðåç òðàíñïîðò Sockets."
                    START="1"
                    CATEG="/DemoStation/Transport/Sockets*"
                    LEVEL="1"
                    ADDR="ARCHIVES/MESS/Net/"/>
            </tbl>
            <tbl id="Archive_val_proc">
                <fld
                    ID="1h"
                    MODUL="FSArch"
                    NAME="1hour"
                    NAME_ru="1÷àñ"
                    NAME_uk="1ãîä"
                    DESCR="Averaging for hour"
                    DESCR_ru="Óñðåäíåíèå çà ÷àñ"
                    DESCR_uk="Óñåðåäíåííÿ çà ãîäèíó"
                    START="1"
                    ADDR="ARCHIVES/VAL/1h/"
                    V_PER="360"
                    A_PER="60"/>
            </tbl>
            <tbl id="Archive_val">
                <fld
                    ID="test1"
                    NAME="Test 1"
                    NAME_ru="Òåñò 1"
                    NAME_uk="Òåñò 1"
                    DESCR="Test 1"
                    DESCR_ru="Òåñò 1"
                    DESCR_uk="Òåñò 1"
                    START="1"
                    VTYPE="1"
                    BPER="1"
                    BSIZE="200"
                    BHGRD="1"
                    BHRES="0"
                    SrcMode="0"
                    Source=""
                    ArchS=""/>
            </tbl>-->
        </node>

        <node id="sub_Protocol">
        </node>

        <node id="sub_UI">
            <node id="mod_QTStarter">
                <prm id="StartMod">QTCfg</prm>
            </node>
            <node id="mod_WebCfg">
                <prm id="SessTimeLife">20</prm>
            </node>
            <node id="mod_VCAEngine">
                <!--
                <tbl id="LIB">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk=""
                        DB_TBL="wlib_test2" ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2">
                    <fld ID="test2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2_io">
                    <fld IDW="test2" ID="name" IO_VAL="Test 2" IO_VAL_ru="Òåñò 2" IO_VAL_uk="Òåñò 2" SELF_FLG=""
                        CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
                    <fld IDW="test2" ID="dscr" IO_VAL="Test module 2" IO_VAL_ru="Òåñò ìîäóëÿ 2" IO_VAL_uk="Òåñò ìîäóëÿ 2" SELF_FLG=""
                        CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
                </tbl>
                <tbl id="PRJ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Òåñò 2" NAME_uk="Òåñò 2" DESCR="" DESCR_ru="" DESCR_uk="" DB_TBL="prj_test2"
                        ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="prj_test2">
                    <fld OWNER="/test2" ID="pg1" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436" FLGS="1"/>
                    <fld OWNER="/test2/pg1" ID="pg2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436" FLGS="0"/>
                </tbl>
                <tbl id="prj_test2_incl">
                    <fld IDW="/prj_test2/pg_pg1" ID="wdg1" PARENT="/wlb_originals/wdg_Box"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Special">
            <node id="mod_SystemTests">
                <prm id="Param" on="0" per="5" name="LogicLev.experiment.F3"/>
                <prm id="XML" on="0" per="10" file="/etc/oscada.xml"/>
                <prm id="Mess" on="0" per="10" categ="" arhtor="DBArch.test3" depth="10"/>
                <prm id="SOAttach" on="0" per="20" name="../../lib/openscada/daq_LogicLev.so" mode="0" full="1"/>
                <prm id="Val" on="0" per="1" name="LogicLev.experiment.F3.var" arch_len="5" arch_per="1000000"/>
                <prm id="Val" on="0" per="1" name="System.AutoDA.CPULoad.load" arch_len="10" arch_per="1000000"/>
                <prm id="DB" on="0" per="10" type="MySQL" addr="server.diya.org;roman;123456;oscadaTest" table="test" size="1000"/>
                <prm id="DB" on="0" per="10" type="DBF" addr="./DATA/DBF" table="test.dbf" size="1000"/>
                <prm id="DB" on="0" per="10" type="SQLite" addr="./DATA/test.db" table="test" size="1000"/>
                <prm id="DB" on="0" per="10" type="FireBird" addr="server.diya.org:/var/tmp/test.fdb;roman;123456" table="test" size="1000"/>
                <prm id="TrOut" on="0" per="1" addr="TCP:127.0.0.1:10001" type="Sockets" req="time"/>
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:10001" type="Sockets" req="time"/>
                <prm id="TrOut" on="0" per="1" addr="UNIX:./oscada" type="Sockets" req="time"/>
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:daytime" type="Sockets" req="time"/>
                <prm id="SysContrLang" on="0" per="10" path="/Archive/FSArch/mess_StatErrors/%2fprm%2fst"/>
                <prm id="ValBuf" on="0" per="5"/>
                <prm id="Archive" on="0" per="30" arch="test1" period="1000000"/>
                <prm id="Base64Code" on="0" per="10"/>
            </node>
        </node>
  </station>

</OpenSCADA>


Lets examine in details the structure of the configuration file. A configuration file can contain a configuration of several stations in the sections <station id="AGLKS"/>. To attribute set the identifier of the station. Using one or another section of the station at startup is specified by the command-line option --station=AGLKS. Section of the station directly contains parameters of the station and subsystems' sections. Configuration options of the section are written in the form <prm id="StName">AGLKS</prm>. Where in the attribute <id> the ID of the attribute is specified, and in the tag's body the value of parameter "AGLKS" is specified. The list of available options and their description for the station and all other sections can be obtained from the console by calling OpenSCADA with parameter --help.


Sections of subsystem (<node id="sub_DAQ" />) contains parameters of subsystem, sections of modules and sections of tables of reflections of the data of databases in the configuration file. Sections of modules (<node id="mod_DiamondBoards" />) contain the individual parameters of modules and sections of tables of reflection of the data of databases in the configuration file.


Sections of the tables of reflection of the data of databases are provided for placement in the configuration file records of DB tables for the OpenSCADA components. Lets examine the table of incoming transports "Transport_in" of subsystem transports (<node id="sub_Transport">) from the example of configuration file above. The table contains two records with fields: ID, MODULE, NAME, DESCRIPT, ADDR, PROT, START. After booting with this section and in general without the DB in the subsystem "Transports" of the "Sockets" module you'll see two input transports. Formats of the table's structures of the main components are included in the demo configuration files. For the details of the database's structure you should read the relevant documentation of modules or simple save the object into the configuration file.


The result of the command: # ./openscada_AGLKS --help


5. System-wide API of user programming

User programming API is the tree of OpenSCADA objects, every object of which can provide own list of properties and functions. Properties and functions of objects can be used by the user in procedures on the languages of user programming of OpenSCADA. The entry point for access to the objects of system OpenSCADA from user programming language JavaLikeCalc is the reserved word "SYS" of the root OpenSCADA object. For example, to access the function of outgoing transport you should write: SYS.Transport.Serial.out_ModBus.messIO(mess);.


API of the objects provided by the modules is described in the own documentation of the module.

5.1. System-wide user objects

Abstract object is an associative container of properties and functions. Properties can contain the data of four basic types and other objects. Access to the properties of an object is usually made by recording the names of properties through a point to the object "obj.prop", as well as by entering the property name in brackets "obj["prop"]". It is obvious that the first mechanism is static, while the second lets you to specify the name of the property through a variable. The basic definition of the object does not contain functions. Copying of an object actually makes reference to the original object. When you delete an object the reduce of the reference counter is made, and when the reference counter is equal to the zero object is removed physically.


Different components can redefine the basic object with special properties and functions. The standard extension of the object is an array "Array".

Array object

Peculiarity of the array is that it works with the properties like with the indexes, and complete their naming if senseless, and hence the mechanism of addressing is available only by the conclusion of the index in square brackets "arr[1]". Array stores the properties in its own container of one-dimensional array. Digital properties of the array are used to access directly to the array, and the characters work as object properties.


Array provides the special property "length" to get the array size "var = arr.length;". Also array provides the following functions:

RegExp object

Object for work with regular expressions, based on the library PCRE. In the global search set object attribute "lastIndex", which allows you to continue searching for the next function call. In the case of an unsuccessful search for the attribute "lastIndex" reset to zero.


As arguments passed to create the object put string with the text of regular expression and flags as a string of characters:


Object's properties:


Object's functions:


XMLNodeObj object

Functions:

5.2. System (SYS)

Object functions:

5.3. Any object (TCntrNode) of OpenSCADA objects tree (SYS.*)

Object functions:

5.4. "Security" subsystem (SYS.Security)

The subsystem object's functions (SYS.Security):


The user (SYS.Security["usr_User"]) object's functions:


The group (SYS.Security["grp_Group"]) object's functions:

5.5. "DB" subsystem (SYS.BD)

DB object functions (SYS.BD["TypeDB"]["DB"]):


Table object functions (SYS.BD["TypeDB"]["DB"]["Table"]):


5.6. Subsystem "DAQ" (SYS.DAQ)

Functions of subsystem's object (SYS.DAQ):


Functions of object of controller (SYS.DAQ["Modul"]["Controller"]):


Functions of object of controller's parameter (SYS.DAQ["Modul"]["Controller"]["Parameter"]):


Functions of object of atribute of controller's parameter (SYS.DAQ["Modul"]["Controller"]["Parameter"]["Attribute"]):


Functions of object of templates library (SYS.DAQ[tmplb_Lib"]) and template (SYS.DAQ[tmplb_Lib"]["Tmpl"]) of controller's parameter:

5.6.1. The module DAQ.JavaLikeCalc


The object "Functions library" (SYS.DAQ.JavaLikeCalc["lib_Lfunc"])

  • ElTp {funcID}(ElTp prm1, ...) — call the library function "funcID" of library "Lfunc". Return result of the called function. The prefix "lib_" before the library identifier is required!

The object "User function" ( SYS.DAQ.JavaLikeCalc["lib_Lfunc"]["func"] )

  • ElTp call(ElTp prm1, ...) — call the function "func" of library "Lfunc" with parameters "prm{N}". Return result of the called function. The prefix "lib_" before the library identifier is required!

5.6.2. The module DAQ.LogicLev


The object "Parameter" [this]

  • bool attrAdd( string id, string name, string tp = "real", string selValsNms = "" ) [for enabled parameter of the standard type] — attribute id and name for type tp add. If the attribute already present then will apply properties allowed to hot changing: name, selection mode and the selection mode parameters.
    • id, name — new attribute id and name;
    • tp — attribute type [boolean | integer | real | string | text | object] + selection mode [sel | seled] + read-only [ro];
    • selValsNms — two lines with values in first and it's names in first (separated by ";").
  • bool attrDel( string id ) [for enabled parameter of the standard type] — attribute id remove.

5.6.3. The module DAQ.BlockCalc


Object "Block" (SYS.DAQ.BlockCalc["cntr"]["blk_block"])

  • ElTp cfg( string nm ) — get value of configuration field nm of the object.
  • bool cfgSet( string nm, ElTp val ) — set configuration field nm of the object to value val.
  • TCntrNodeObj cntr( ) — return the object of controller for the parameter nesting independent.

5.6.4. The module DAQ.ModBus


The object "Controller" [this.cntr()]

  • string messIO(string pdu) — sending pdu through the transport of controller object by means of ModBus protocol. PDU query result is placed instead of the query pdu, and the error returned by the function.

The object "Parameter" [this]

  • bool attrAdd( string id, string name, string tp = "real", string selValsNms = "" ) [for enabled parameter of the logical type] — attribute id and name for type tp add. If the attribute already present then will apply properties allowed to hot changing: name, selection mode and the selection mode parameters.
    • id, name — new attribute id and name;
    • tp — attribute type [boolean | integer | real | string | text | object] + selection mode [sel | seled] + read-only [ro];
    • selValsNms — two lines with values in first and it's names in first (separated by ";").
  • bool attrDel( string id ) [for enabled parameter of the logical type] — attribute id remove.

5.7. "Archives" subsystem (SYS.Archive)

Functions of the subsystem's object:


Functions of object's archiver of messages (SYS.Archive["mod_Modul"]["mess_Archivator"]):


Functions of object's archiver of values (SYS.Archive["val_Modul"]["val_Archivator"]):


Functions of object's archive (SYS.Archive["va_Archive"]):

5.8. "Transports" subsystem (SYS.Transport)

Functions of the ingoing transport object (SYS.Transport["Modul"]["in_Transp"]):


Functions of the outgoing transport object (SYS.Transport["Modul"]["out_Transp"]):


5.9. "User interfaces" subsystem (SYS.UI)

5.9.1. The module UI.VCAEngine


Object "Session" ( this.ownerSess() )

  • string user( ) — current session user.
  • int alrmQuittance( int quit_tmpl, string wpath = "", bool ret = false ) — violations quittance wpath with the template quit_tmpl. If wpath is empty string then make global quittance. Into the string wpath, by symbol ';', can be enumerated addresses of several widgets. The ret sets will cause the quittance return.
  • int reqTm( ) — last request time.
  • string reqUser( ) — last request user.
  • string reqLang( ) — last request language.
  • int userActTm( ) — last user action time.

Object "Widget" (this)

  • TCntrNodeObj ownerSess( ) — the session's object is getting for current widget.
  • TCntrNodeObj ownerPage( ) — the parent object's page is getting for current widget.
  • TCntrNodeObj ownerWdg( bool base = false ) — the parent widget is getting for current widget. If set base then will return the parent pages' objects also.
  • TCntrNodeObj wdgAdd( string wid, string wname, string parent ) — add new widget wid with the name wname and based on the library widget parent.

  • bool wdgDel( string wid ) — delete the widget wid.
  • TCntrNodeObj wdgAt( string wid, bool byPath = false ) — attach to child or global, by byPath, widget. In the case of global connection, you can use absolute or relative path to the widget. For starting point of the absolute address acts the root object of the module "VCAEngine", which means the first element of the absolute address is session identifier, which is omitted. The relative address takes the countdown from the current widget. Special element of the relative address is an element of parent node "..".
  • bool attrPresent( string attr ) — the attribute attr of the widget checking to presence fact.
  • ElTp attr( string attr, bool fromSess = false ) — value of the attribute attr of the widget getting or from the session fromSess. For missing attributes will return empty string.
  • TCntrNodeObj attrSet( string attr, ElTp vl, bool toSess = false ) — value of the attribute attr of the widget setting to vl, or to the session toSess. The object is returned for the function concatenation.
  • string link( string attr, bool prm = false ) — the link return for the widget's attribute attr. At set prm requests the link for the attributes block (parameter), represented by the attribute.
  • string linkSet( string attr, string vl, bool prm = false ) — the link set for the widget's attribute attr. At set prm makes the link set for the attributes block (parameter), represented by the attribute.

  • string mime( string addr, string type = "" ) — the "mime" object by the address addr (the direct link to the resource or the widget's attribute contained the link) getting with the type to type, from the session table or the source. It is designed for the "mime" objects edition and that substitution to this session's context, for example, images SVG.
  • int mimeSet( string addr, string data, string type = "" ) — the "mime" object data with type type by address addr setting.
  • int messDebug( string mess ); int messInfo( string mess ); int messNote( string mess ); int messWarning( string mess ); int messErr( string mess ); int messCrit( string mess ); int messAlert( string mess ); int messEmerg( string mess ); — formation of the system message mess with the category as the widget path.

Object "Widget" of the primitive "Document" (this)

  • string getArhDoc( int nDoc) — getting the archive document's text to "nDoc" (0-{aSize-1}) depth.

5.10. "Special" subsystem (SYS.Special)

5.10.1. Module Special.FLibSYS


The object "Functions library" (SYS.Special.FLibMath)

  • ElTp {funcID}(ElTp prm1, ...) — call the library function {funcID}. Return result of the called function.

The object "User function" (SYS.Special.FLibMath["funcID"])

  • ElTp call(ElTp prm1, ...) — call the function with parameters prm{N}. Return result of the called function.

5.10.2. Module Special.FLibMath


The object "Functions library" (SYS.Special.FLibMath)

  • ElTp {funcID}(ElTp prm1, ...) — call the library function {funcID}. Return result of the called function.

The object "User function" (SYS.Special.FLibMath["funcID"])

  • ElTp call(ElTp prm1, ...) — call the function with parameters <prm{N}>. Return result of the called function.

5.10.3. Module Special.FLibComplex1


The object "Functions library" (SYS.Special.FLibComplex1)

  • ElTp {funcID}(ElTp prm1, ...) — call the library function {funcID}. Return result of the called function.

The object "User function" (SYS.Special.FLibComplex1["funcID"])

  • ElTp call(ElTp prm1, ...) — call the function with parameters <prm{N}>. Return result of the called function.

Links

Referring pages: HomePageEn/Developers
HomePageEn/Doc
HomePageEn/Doc/API/part2
HomePageEn/Doc/DCON
HomePageEn/Doc/HTTP
HomePageEn/Doc/JavaLikeCalc
HomePageEn/Doc/ModBus
HomePageEn/Doc/ModuleBuild
HomePageEn/Doc/QuickStart
HomePageEn/Doc/VCAEngine
HomePageEn/Doc/VCAconcept/part4/part5
HomePageEn/Doc/Vision
HomePageEn/Doc/WebVision
HomePageEn/Using/APIFunctionLibs/LibUserPrtDevs
HomePageEn/Using/GraphicElementsLibraries/MainElements
HomePageUk/Doc/HTTP
HomePageUk/Doc/ModBus


 
There are 3 files on this page.[Display files/form]
Comments [Hide comments/form]