Author: Roman Savochenko
This document is a manual of the "open source" program called "OpenSCADA". OpenSCADA represents a SCADA system built on the principles of modularity, multiplatformity and scalability.
As a policy of the development of the program there uses "open source" principle. This choice was done at needs of creation of a free, reliable and publicly available SCADA system. This policy allows to bring together a significant number of developers, enthusiasts and other interested persons to develop, test, improve, distribute and use the program, thus minimizing and distribution of efforts and financial costs.
OpenSCADA is designed for acquisition, archiving, visualization of information, performing of control actions and for other related operations charactered for full-featured SCADA systems. Due to the high level of abstraction and modularization the program can be used in a variety of related industries.
OpenSCADA can be and used now at:
In the role of the common operating system (program platform) for development and using there was selected Linux OS, which is an optimal solution of the following issues:
While the project currently develops under the principles of multiplatformity then there is no most problem for porting the project to other operational systems (program platforms) and hardware platforms. That is planned to future and mostly already done for some platforms.
At the heart of the program is a modular core. And depending on what modules are installed the program can be configured to operate in role of variety servers, clients and both clients and servers in the same time and into the same program. It allows for implementation of the client-server architecture on the same components/modules, saving machine memory, disk space and expensive programming time.
Server configurations of the program were designed for issuing control actions and acquisition, processing, archiving, logging information from different sources and this information providing also to clients (UI, GUI, TUI ...). The modular architecture allows for expanding of server's functionality without it restarting.
Client configurations can be built on different graphics libraries (GUI/TUI ToolKits), as using the program core and its modules (by adding to it an user interface module), or as an independent application connected the OpenSCADA core as a library.
The flexible configuration of the program allows for user to build solutions to meet specific requirements of reliability, functionality and capacity-complexity.
In order to achieve flexibility and a high degree of scalability OpenSCADA is constructed in a modular fashion. Tight integration the modules with the core improves the program stability in whole due to repeat of using the well-tuned code. But same process of developing of self code of the modules OpenSCADA imposes greater responsibility — possible errors introduce an element of instability into the program. The ability to create distributed configurations smooths this danger.
OpenSCADA modules are stored within dynamic libraries and each shared library can contain modules of various types. The filling of dynamic libraries by modules is determined by the functional connectivity of the modules itself. Dynamic libraries are hot swappable which allows to update certain parts of the program during the operation. This method of storing of modules' code in dynamic libraries is essential for OpenSCADA, because it is supported by practically all modern operating systems (OS). However, this does not exclude the possibility of developing other methods of storing of the modules' code.
OpenSCADA has the following functional parts implemented in modules:
Management of the modules is carried out by the "Module scheduler" subsystem. The subsystem functions are: connection, switching off, updating and other operations concerned with the modules and their libraries.
Architecturally OpenSCADA is divided into subsystems. Subsystems can be two types: regular and modular. Modular subsystem have the ability of expanding by modules. Each the modular subsystem can contain many of modular objects. For example, the modular subsystem "Databases" contains modular objects of types of databases. Modular object is the root of the module.
Summary OpenSCADA contains nine subsystems with seven being modular. These nine subsystems of OpenSCADA are base ones and their present at every configuration. To the list of these nine subsystems can be added new ones, through the modules themselves. OpenSCADA subsystems:
The subsystem "DAQ" (Data Acquisition) (Fig. 1.3) provides to support dynamic data sources whether: PLC, MOD, virtual sources and other. The function of this subsystem is to provide the received data in structured form and to provide management of these data, for example, these are data modification.
The subsystem "DAQ" is a modular one and it contains modular objects of types of sources of dynamic data. For example OpenSCADA provides now more than twenty modules and libraries items by sources of the logical level. Most significant and developed from them are:
Each non-logical source type is implemented into a separate module, which can contain many sources (controller objects), and each source is usually executed in a separate thread-task.
Separately taken object controller may contain parameters specified by module types. For example, the parameters of the analog type, the basic information of which is the value of the integer or the real type. Structurally, the parameter is a list of attributes that contain data. Attributes can have five basic types: logical, integer, real, character string (text) and object. Structures of controller objects, parameters and their types are contained in the subsystem "DAQ" so that the module objects carry out their filling in accordance with their own specifics.
Certain types of data sources themselves can generate data as they generate them entirely, as well as processing physical data, and even fully implement the gathering of these data into OpenSCADA environment and its internal language. Such data sources are called logical. Fully logical data sources are represented by modules: LogicLev and BlockCalc. There are several modules that combine logical data as a result of direct physical ones processing: ModBus and Siemens.
Dynamic data sources can be remote, that is, they can be generated or received at the remote OpenSCADA station. To communicate with such data sources, the DAQGate gateway module is used. The function of this type of data sources is to display the data sources of the remote OpenSCADA station to the local one.
You can read in detail the key subsystem "DAQ" and its functions in a separate document "Data acquisition in OpenSCADA".
To store data of the program are constantly used databases (DB). In order to unify access and manage databases, OpenSCADA has a subsystem called "Databases" (Fig. 1.4). To support different DB/DBMS the subsystem implemented as a modular one.
In the role of modular object contained in the subsystem, the type of DB/DBMS acts, that is, any module of the subsystem "Databases" practically contain the implementation of access to a specific type of database. OpenSCADA provides that most significant and developed modules: SQLite, MySQL, PostgreSQL, FireBird.
Type of the DB/DBMS in its turn contains a list of objects of separate DB of this type, and the database object contains a list of table objects, which contain data in tabular form.
Practically all OpenSCADA data is stored in one or another database. The program's toolkit allows you to easily transfer data from one type of database to another, and, as a result, optimally select a database type for a specific scope of application OpenSCADA. Transferring information from one database to another can be done in two ways. The first one is to change the address of the working DB and to save the whole configuration of the program to it, the second one — it is direct copying information between the database. Except of copying the function of direct editing of content of tables of DB is supported also.
There are two ways to organize the centralized access of a distributed program to a single database. The first is the use of network databases, for example — MySQL. The second way is to use a transport type database on local stations to access one central database of another OpenSCADA station, by sending requests to the database at that remote station — not yet implemented in OpenSCADA.
Data can also be stored in the configuration file of the program. The mechanism of full mapping of the DB structure to the structure of the configuration file is implemented. That is, the standard configuration can be placed in the configuration file. The essence of the mechanism is that the typical (by default) data of programs can be described in the configuration file, for example — when starting without a DB. In the future, these data can be redefined in the DB. In addition, for cases of impossibility to run any DB in general, all data can be stored in the configuration file.
To access databases, a DB registration mechanism is used. Registered DBs in the program are accessible to all OpenSCADA subsystems and can be used in their work. Thanks to this mechanism, you can ensure the distribution of data storage. For example, different libraries can be stored and distributed independently, and connecting a library will be simple registration of the desired DB.
Any SCADA system should provide the ability to archive the gathered data, that is, to form the history of the change (dynamics) of the process. Archives can be divided into two types: messages and values archives.
The peculiarity of message archives is the very archiving of so-called program messages, that is logging. A characteristic sign of a message is the time of its occurrence. Depending on the source the messages can be classified according to different criteria. For example, it can be emergency reports, operator logs, communication failure protocols, and more.
The peculiarity of the value archives is their periodicity, which is determined by the time interval between two adjacent values. Value archives are used to archive the history of continuous processes. Since the process is continuous, it can be archived only by introducing the concept of quantization of the acquired values, otherwise we will receive archives of infinite sizes, in accordance with the continuity of the nature of the process itself. Besides, we can practically get values with a period limited by the data sources themselves. For example, rather high-quality data sources in industry rarely allow data to be received at frequencies above 1 kHz, without taking into account the sensors themselves, which have less qualitative frequency characteristics.
To solve the problems of archiving data streams in OpenSCADA provides a subsystem "Archives-History" (Fig. 1.5), which is modular and allows you to maintain archives of messages and values. Modular object, which is contained in the subsystem "Archives-History", is the type of archiver. The type of archiver determines a way of data storing ie the storage — file system, DBMS. Each module of the "Archives-History" subsystem, respectively, can implement the archiving of messages and values, and the subsystem itself can contain many archives that are processed by different modules.
Messages in OpenSCADA are characterized by the date, level of importance, category, and directly the message text. Date of a message indicates the date and time of his creation. Level of importance points to importance of the message. Category defines address or identifier-key of the message source. Often, category contains full path to a source of the message in the program. Text of a message, respectively, has the main meaning of the message.
When archiving messages, they are passed through a filter that works according to importance level and category of messages. Messages level in a filter indicates that you must skip messages with specified or higher levels of importance. For filtering by category, templates or regular expressions are used to determine which messages to pass. Each archiver has its own filter settings, therefore, it is easy to create various specialized archivers for the archive of messages. For example, archivers of messages can be directed to:
In accordance with the nature of messages and violations the subsystem "Archives-History" contains a buffer of current violations, which contains these most actual ones with category of the messages as the key-ID. Access to the buffer-list of current violations is done by indicating the negative value of the message level. Thus, formation of a message with a negative level -2 causes the location of this message in the buffer of active violations with level 2, as well as duplicate it directly in the message archive (the general messages buffer). At forming a message in the same category, but at a positive level — say 1, this violation will be removed from the buffer of violations, and the message will also fall into the message archive (the general messages buffer). Such a mechanism allows simultaneous accounting of active violations and logging of their passage in the message archive. When requesting an archive of messages, the definition of the positive level requests the archive of messages (through the general messages buffer), and the negative to the buffer-list of current violations.
OpenSCADA values archives act as independent components that include buffers processed by archivers. The main parameter of the values archives is data source, in the role of which may be attributes of the parameters of the subsystem "DAQ", as well as other external data sources (passive mode). Other data sources may be network archivers of remote OpenSCADA stations, OpenSCADA programming environment, and more.
A key component of archiving the values of continuous processes is the value buffer, which is intended for intermediate storing of an array of values obtained with a defined periodicity (time quantum). The values buffer is used to directly store large values of arrays in the value archives both before the direct "flushing" on the physical storage, and for manipulating the value frames, that is, in the functions of the frame-by-frame query of the values and their location in the archive buffer.
To organize remote archivers in distributed configurations, the transport type of archivers is used, which is currently not implemented in OpenSCADA. The function of the transport type of archivers is to display the remote central archiver of OpenSCADA in the local configuration. As a result, the transport-type archiver performs data transfer between the local configuration and the archiver of the remote configuration of the program, by hiding from the subsystems of the local configuration the real nature of the archiver.
Since OpenSCADA is highly scalable, communication support should be sufficiently flexible, for which it is implemented in the "Transports" and "Transport protocols" subsystems (fig. 1.6), which are modular ones.
The "Transport" subsystem is intended to provide for the exchange of unstructured data between OpenSCADA and external systems, in the role of which remote stations OpenSCADA may also serve. Under unstructured data means the stream of characters of a certain length. Modular object contained in the "Transport" subsystem is a type of transport that determines the mechanism for the transmission of unstructured data. For example, their may be and are:
The subsystem "Transport" includes support for ingoing and outgoing transports. Ingoing transports are designed to serve external requests and send replies. Outgoing transports, by contrast, are designed to send messages and wait for a responses. Therefore, ingoing transports contain configuration of local station as a server, and outgoing transports contain configuration of a remote server. That sort of specialization is typical for the "request-response" mechanism, however, currently ingoing and outgoing transports support the independent transmission and reception of data. Modules of the subsystem "Transports" implement support for both ingoing and outgoing transports.
The "Transport protocols" subsystem is designed to structure data received from the "Transports" subsystem, is a continuation of the subsystem "Transports" and performs functions of checking structure and integrity of received data. A special configuration field is provided to determine protocol with which transport must operate. Modular object contained in the "Protocols" subsystem is protocol itself. For example, transport protocols can be and are:
The full sequence of incoming communication session for typical "request-response" protocols can be written as follows:
Protocols are also supported for outgoing transports and assume the function of communication with transport and implementation of features of these protocols, when preparing data for the transmission and analysis of responses. The external interface for accessing protocols, from code of other modules and the OpenSCADA programming environment, implements in an XML tree with its own structure for each protocol module. Such a mechanism allows for transparent access to external systems through transports, simply by specifying the name of the protocol by which to serve transmission.
Thanks to the standard access (API) to transports in OpenSCADA, it's easy to change the way data is exchanged without affecting the exchanging programs themselves. For example, in the case of a local exchange, you can use faster transport based on UNIX sockets or shared memory, and in the case of exchanging over the Internet and local network using TCP or UDP sockets.
SCADA systems, as a class, provide for user interfaces presence. In OpenSCADA for user interfaces, the subsystem "User Interfaces" is provided, which means not only the visualization environment that the end user must work with, but all that is relevant to the user, for example:
The subsystem "User interfaces" is a modular one and its modular object is concrete that user interface itself. Modularity of the subsystem allows you to create different user interfaces in different GUI/TUI libraries and use the most optimal solution in a particular case, for example, you can use Web-based configurators and visualizers (WebCfg, WebCfgD, WebVision, WebUser), and in the case of stationary workstations, use the same configurators and visualizers, but on the basics libraries like Qt (QTCfg, Vision).
OpenSCADA is a ramified program that consists of a dozen subsystems and can include many modules. Therefore, providing all unrestricted access to these resources is least rash. In order to differentiate access, OpenSCADA provides the subsystem "Security" whose main functions are:
OpenSCADA is built on the modular principle, which involves the presence of many modules that need to be controled and scheduled for availability, which is provided for the subsystem "Modules Scheduler". All modules are currently provided to the program through shared libraries (containers) or embedded directly into the OpenSCADA core library according to their logical connection. Each container can contain many different types of modules.
The subsystem "Modules scheduler" controls the state of the containers and allows "hot" plugging, deletion, and updating of the containers and modules it contains.
Obviously, it is impossible to predict all need functions and functions that may be needed in the future so OpenSCADA has the subsystem "Specials" that is modular and designed to provide unpredictable functions through modular extensions. For example, using this subsystem may be implemented:
Modern SCADA system should include mechanisms that enable programming at the user level, that is, the user programming environment. OpenSCADA contains this environment and can be used to:
The programming environment is a set of tools that organize the user's computing area and includes
Modules of function libraries provide static functions of a defined orientation, which extend the object model of the program and represent an user interface for accessing module resources. For example, "Visualization Control Area" can provide functions for issuing various messages, using which the user can implement interactive algorithms for interaction with the program. Function libraries can generally be implemented as a set of fixed-type functions — static ones, and functions that allow free modification and additions — dynamic ones.
Free-style function libraries (dynamic) provide the user-defined writing environment in one of the programming languages; at present, this language is similar to Java implemented by the module DAQ.JavaLikeCalc. In this way you can create libraries of devices of technological processes and many others, and then use them by binding.
On the basis of the functions given by the object model constructs objects of calculating controllers that carry out the binding of functions with the program parameters and the calculation mechanism. Also there construct procedures and protocols of data acquisition of the user level, Widget procedures of "the Visual Control Area" and much more.
SCADA (Supervisory Control And Data Acquisition), in a general view, have the allocated architecture like represented on Figure 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 the server enters:
The server of archiving: represents a task or group of tasks engaged in archiving of data or their history maintenance. Into tasks of the server enters:
The logging server: represents a task or group of tasks engaged in archiving of messages or their history maintenance. Into tasks of the server enters:
The alarm server: represents a task or group of tasks carrying out functions of the server of logging concerning a narrow category of signaling-alarm messages.
The working place of operator: represents constantly functioning GUI (Grafical User Interface) application executed in an one-monitor, multimonitor or panel mode and carrying out functions:
The working place of engineer: represents GUI application used for configuration of SCADA systems. Into tasks of the application enters:
The working place of chief: represents GUI application, executed in an one-monitor mode as a rule, and carrying out functions:
The working place of technologist: completely includes functions of workplace of operator plus models of technological processes (without direct communication with the technological processes).
The working place of technologist-programmer: completely includes functions of workplace of technologist plus a toolkit for creation of models of technological processes.
In the elementary case OpenSCADA 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:
For increasing of reliability and productivity OpenSСADA supposes plural reservation (fig. 3.2) at which data sources (controllers) and archives-history of one copy are reflected in other. At use of a similar configuration there is possible distribution of loading of interrogation/calculation at various stations. The given configuration allows to carry out functions:
Special case of the duplicated connection is the duplicated connection within one server (fig. 3.3), that is starting of several stations at one machine with their parameters crossing. The purpose of the given configuration is increase of reliability and fault tolerance of the configuration by reservation of software.
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 related to one platform, i.e. is multiplatform. However this decision has essential imperfections — that is 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 in the management of industrial plants where always exists an operator station with a reliable way of visualization. The given configuration allows to carry out following functions:
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 configured with a GUI module (fig. 3.5). The given configuration allows to carry out following functions:
The full-function client-server configuration on single machine (fig. 3.6) can be used for increasing of reliability of the configuration as a whole by start of a client and a server in different processes. The given configuration allows, without consequences for the 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 a station of the operator and a redundant server. The given configuration allows to carry out following functions:
The mixed connection combines functions of a server and a client (fig. 3.7). It can be used for test, demonstration functions, and also for granting simulators of technological processes as a unit. In this mode following functions can be carried out:
The given configuration is one of variants of robust/reliable connection (fig. 3.8). Stability is reached by distribution of functions on:
The acquisition server is configured on the basis of OpenSCADA and represents a task or a group of data collection tasks — acquisition of a controller or a group of controllers of the same type. Obtained values are available to the central server through any transport which support is added by connecting the corresponding transport module. To reduce the polling frequency and the value of network traffic, the polling server can be equipped with a small archive of values. Configuration of the acquisition server is stored in one of the available databases.
The central server of archiving and maintaining customer requests performs the centralized acquisition and processing of parameters of the polling servers and their values. Access to the polling servers is performed through one of transport + protocols available into OpenSCADA (for example, these Sockets). The module DAQGate is used to provide a single interface for accessing parameters and controllers, which reflects polling server data into the structure of local parameters of data acquisition.
To perform internal computations and additional analysis of parameters, objects of computing controllers are used.
Various archive-history modules are used for versatile and deep archiving.
For access of clients to the server are used accessible for OpenSCADA network transports, for example — Sockets, and transport protocols, for an example — 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 WebCfgD by means of the transport protocol "HTTP" is used.
Various clients, including AWPs and WEB clients, are executed on separate machines in the right amount. AWP implements on OpenSCADA basis. Its function is to acquire the values of parameters from the central server and their visualization on the GUI interface(s). To obtain data acquisition parameters the DAQGate remote display parameters module is also used in the AWP. A network-type archive module can be used to provide access to archive-history. The AWP configuration can be stored in one of the available databases (for example, this is a network MySQL database located on the central archiving server machine).
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 program-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 program, 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. Let's 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.
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 program 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 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 OpenSCADA stations 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 station, 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.
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.
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.
The subsystem is the modular one and contains a hierarchy of objects shown in Figure 1.4. To configure the subsystem the root page of the subsystem "DB" containing the tab "Modules". Tab "Modules" (Fig. 4.1a) 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.
Each module of the "DB" subsystem provides the configuration page with the following tabs: "DB" and "Module". "DB" tab (Fig. 4.1b) 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.1c):
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.1d) contains the main configuration options of the DB as follows:
Tab "Tables" (Fig.4.1e) 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.1f) 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.
Page of the examination of the contents of the table contains only one tab, "Table". Tab "Table" (Figure 4.1g) contains the field of the name of the table and the table with the contents. Table of contents provides the following functions:
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.
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:
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 subsystem is the modular one and contains the hierarchy of objects shown in Figure 1.6. To configure the subsystem it is provided the root page of the subsystem "Transports", containing the tabs "Subsystem" and "Modules".
The tab "Subsystem" (Figure 4.3a) 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.
Each module of the subsystem "Transports" provides the configuration page with the tabs "Transports" and "Module". The tab "Transports" (Fig.4.3b) 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.
Incoming transport (fig.4.3c) includes:
Outgoing transport (Fig. 4.3d) contains:
Outgoing transport, in addition, provides the tab for forming the user request via this transport (Fig.4.3e). The tab is provided for setting communication, as well as for debugging the protocols and includes:
Both incoming and outgoing transports also contain tab "IO log" (Fig.4.3f). The tab is provided for generic control, observing and learning the traffic through the transports and includes the log length field and the same text area of the log. For the log disable you can the log length field set to zero.
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.
The subsystem is modular one and contains the hierarchy of objects shown in Fig.1.3. 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.
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.5a) 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:
The tab "Template libraries" (Fig.4.5b) 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.
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.5d) 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.
Each template of the template library provides the configuration page with the tabs "Template" and "IO". The tab "Template" (Figure 4.5e) contains the basic settings of the template:
The tab "IO" (Fig.4.5f) 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.JavaScript.
Each module of the subsystem "Data acquisition" provides the configuration page with the tabs "Controllers" and "Module". The tab "Controllers" (Fig.4.5g) 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.
Each controller contains its own configuration page with the tabs "Controller" and "Parameters".
The tab "Controller" (Fig.4.5h) 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, let's examine the settings of the controller in the module of the controller of logic DAQ.LogicLev:
"Parameters" tab (Fig.4.5i) 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.
"Diagnostic" tab (Fig.4.5j) 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)".
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.5k) contains the main settings:
The tab "Attributes" (Fig.4.5l) 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.5m) 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.5n) 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 subsystem is modular and contains the hierarchy of objects shown in Fig.1.5. 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.
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.6a) 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 "Messages" tab (Fig.4.6b) 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:
Tab "Value" (Fig.4.6c) 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.
Archive of values of subsystem "Archives" provides the configuration page with the tabs "Archive", "Archivators" and "Values".
Tab "Archive" (Fig.4.6d) contains the basic settings of the archive:
Tab Archivators' (Fig.4.6e) 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:
Tab "Values" (Fig.4.6f) 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:
Each module of the "Archives" subsystem provides configuration page with the tabs "Archivators" and "Module". The "Archivators" tab (Fig.4.6g) 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.
Messages archivators contains their own configuration page with tabs "Archivator" and "Messages".
The "Archivator" tab (Fig.4.6h) 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 "Messages" tab (Fig.4.6i) contains the form of the messages request from the archive of the archiver:
The result table contains messages rows with the following columns:
Values archivers contains their own configuration page with tabs "Archivator" and "Archives".
The "Archivator" tab (Fig.4.6j) 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 "Archives" tab (Fig.4.6k) 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 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 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 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":
Configuration file of OpenSCADA is provided to store the program 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 OpenSCADA 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 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
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)?"1:"+alrm_mess:"0";"/>
</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>
Let's 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. Let's 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
***************************************************************************
********** OpenSCADA v0.9 (Linux-3.2.0-4-amd64). *********
***************************************************************************
===========================================================================
==================== Generic options ======================================
===========================================================================
-h, --help Info message about the program options.
--config=<file> The station configuration file.
--station=<id> The station identifier.
--statName=<name> The station name.
--demon, --daemon Start into the daemon mode.
--pidFile=<file> The file for the programm process ID place here.
--coreDumpAllow Set the limits for a core dump creation allow on the crash.
--messLev=<level> Process messages <level> (0-7).
--log=<direct> Direct messages to, by bitfield:
0x1 - syslogd;
0x2 - stdout;
0x4 - stderr;
0x8 - the messages archive.
----------- The config-file station '/' parameters -----------
StName <nm> Station name.
WorkDB <Type.Name> Work DB (type and name).
WorkDir <path> Work directory.
ModDir <path> Modules directory.
IcoDir <path> Icons directory.
DocDir <path> Documents directory.
MessLev <level> Messages <level> (0-7).
SelDebCats <list> Debug categories list (separated by ';').
LogTarget <direction> Direct messages to, by bitfield:
0x1 - syslogd;
0x2 - stdout;
0x4 - stderr;
0x8 - the messages archive.
Lang <lang> Work-internal language, like "en_US.UTF-8".
Lang2CodeBase <lang> Base language for variable texts translation, two symbols code.
MainCPUs <list> Main used CPUs list (separated by ':').
ClockRT <false> Set for use REALTIME (else MONOTONIC) clock, some problematic with the system clock modification.
SaveAtExit <true> Save the system at exit.
SavePeriod <sec> Save the system period.
RdStLevel <lev> Level of redundancy current station.
RdTaskPer <s> Call period of the redundant task.
RdRestConnTm <s> Restore connection timeout of try to the "dead" reserve stations.
RdStList <list> Redundant stations list, separated symbol ';' (st1;st2).
RdPrimCmdTr <0|1> Enable the primary commands transfering to the redundant stations.
=================== Subsystem "Module scheduler" options =================
--modPath=<path> Modules <path> (/var/os/modules/).
------------ Parameters of section '/sub_ModSched/' in config-file -----------
ModPath <path> Path to shared libraries(modules).
ModAllow <list> List of shared libraries allowed for automatic loading, attaching and starting (bd_DBF.so;daq_JavaLikeCalc.so).
Use '*' value for allow all modules.
ModDeny <list> List of shared libraries deny for automatic loading, attaching and starting (bd_DBF.so;daq_JavaLikeCalc.so).
ChkPer <sec> Period of checking at new shared libraries(modules).
========================= Subsystem "DB" options ========================
----------- The config-file station '/sub_BD/' parameters -----------
SYSStPref <1> Use station id prefix into generic (SYS) table.
======================= Subsystem "Security" options ====================
======================= Subsystem "Transports" options ==================
=============== Subsystem "Transport protocols" options =================
======================= Module <Protocol:HTTP> options =======================
---------- Parameters of the module section '/sub_Protocol/mod_HTTP/' in config-file ----------
AuthTime <min> Life time of the authentication, minutes (default 10).
=================== Subsystem "Data acquisition" options ================
------------ Parameters of section '/sub_DAQ/' in config-file -----------
RdRestDtTm <hour> Restore data archive depth from a reserve station after deadline.
======================== Subsystem "Archives" options ===================
------------ Parameters of section '/sub_Archive/' in config-file -----------
MessBufSize <items> Messages buffer size.
MessPeriod <sec> Message archiving period.
ValPeriod <msec> Values active archiving period.
ValPriority <level> Values task priority level of active archiving.
RdRestDtOverTm <hours> Overtime of the reserve history reload at start in hours.
======================= Module <Archive:FSArch> options =======================
--noArchLimit Disable archives limit to the file number. Use for see archives mode, not work.
======================= Subsystem "Special" options =====================
======================= Module <Special:SystemTests> options =======================
---------- Parameters of the module section '/sub_Special/mod_SystemTests/' in config-file ----------
All tests main options:
id test's id;
on on test's flag;
per repeat period (sek).
*** Test's options ***
1) Param DAQ parameters test. Make read a parameter's attributes and configuration fields.
1:name DAQ parameter address
2) XML XML file parsing test. Parse and show selected file structure.
1:file XML file
3) Mess Messages archive test. Periodic read new messages from archive, for selected archivator.
1:arhtor Archivator
2:categ Messages category pattern
3:depth Messages depth (s)
4) SOAttach Attach/detach module test.
1:name Path to module
2:mode Mode (1-attach;-1-detach;0-change)
3:full Full attach(to start)
5) Val Parameter attribute's value test.
Periodic make gathering for last value of selected attribute, and also gathering from archive for selected depth.
1:name Parameter attribute path
2:arch_len Archive value getting depth (s)
3:arch_per Archive value getting period (us)
6) DB Full database test. Make:
- make/open DB;
- make/open table;
- make multiply records for determined structure;
- modify multiply records;
- get and check values for multiply records;
- modify record and table structure;
- remove multiply records;
- close/remove table;
- close/remove DB.
1:type DB type
2:addr DB address
3:table DB table
4:size Records number
7) TrOut Output and/or input transports test.
Make test for output transport by send the request to selected input transport.
1:addr Address
2:type Transport module
3:req Request text
8) SysContrLang System control language test.
Make request to language elements by full path set.
Full path to language element have view </Archive/%2fbd%2fm_per>.
Full path contained two included path.
First </d_Archive/> is path to the node of the control tree.
Second </bd/m_per> is path to concrete node's element.
1:path Path to language element
9) ValBuf Value buffer tests.
Contain 13 tests for all aspects of value buffer (subsystem "Archives").
10) Archive Value archive allocation tests.
Contain 7(8) tests for value archivator for check to correct working the consecutive pack mechanism.
1:arch Value archive
2:period Values period (us)
3:archtor Archivator
11) Base64Code Mime Base64 encoding algorithm tests.
===================== Subsystem "User interfaces" options ===============
======================= Module <UI:QTStarter> options =======================
----------- Qt debug commandline options ----------
--noX11 Prevent Qt start, mostly for pure console.
--sync Switches to synchronous mode X11 for debugging.
--widgetcount Prints debug message at the end about number of widgets
left undestroyed and maximum number of widgets existed at
the same time.
----------- Qt commandline options ----------------
--qws With Qt for Embedded Linux makes this application the server.
--style=<nm> Sets GUI style to <nm> (windows, platinum, plastique, ...).
--stylesheet=<path> Sets styleSheet by <path> to file that contains.
--session=<nm> Restores from an earlier session <nm>.
--reverse Sets layout direction to Qt::RightToLeft.
--graphicssystem=<nm> Sets the backend to be used for on-screen widgets and QPixmaps (raster, opengl).
--display=<nm> Sets the X display name (default it is $DISPLAY).
--geometry=<geom> Sets the client geometry of the first window that is shown.
---------- Parameters of the module section '/sub_UI/mod_QTStarter/' in config-file ----------
StartMod <moduls> Start modules list (sep - ';').
======================= Module <UI:QTCfg> options =======================
---------- Parameters of the module section '/sub_UI/mod_QTCfg/' in config-file ----------
StartPath <path> Configurator start path.
StartUser <user> No password requested start user.
======================= Module <UI:Vision> options =======================
---------- Parameters of the module section '/sub_UI/mod_Vision/' in config-file ----------
StartUser <user> No password requested start user.
UserPass <pass> User password for no local start.
RunPrjs <list> Run projects list on the module start.
ExitLstRunPrjCls {0;1}Exit on last run project close (default = 1).
CachePgLife <hours> Cached pages lifetime.
VCAstation <id> VCA station id ('.' - local).
RestoreTime <seconds> Restore connection time.
======================= Module <UI:WebVision> options =======================
---------- Parameters of the module section '/sub_UI/mod_WebVision/' in config-file ----------
SessTimeLife <time> Time of the session life, minutes (default 10).