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

Home | Index | Changes | Comments | Users | Registration | Login:   Password:  
 

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.


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.


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 three 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.


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

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

Tasks tab of the main page of the configuration of the station. (192 Êá)
Fig 4c. "Tasks" tab of the main page of the configuration of the station.

Help of the main page of the configuration of the station. (92 Êá)
Fig. 4d. "Help" 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 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 tabs "Modules" and "Help" is provided. Tab "Modules" (Fig. 4.1b) contains the list of modules in subsystem "DB", available at the station. Tab "Help" tab contains a brief help for this page.


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.

(74 Êá)
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 "Help". "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 "Help" tab contains information about the module of the "DB" subsystem (Fig.4.1d):


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

(85 Êá)
Fig. 4.1d. "Help" 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". (99 Êá)
Fig. 4.1e. Tab "Data base" of the DB of module of subsystem "DB".

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

Tab "SQL" of the DB of module of subsystem "DB". (104 Êá)
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. (75 Êá)
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" and "Help". 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 "Help" contains the brief help for this page.


Tab [Users and Groups] of the root page of the subsystem Security.\n (56 Êá)
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. (61 Êá)
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. (51 Êá)
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", "Modules" and "Help".


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's and the user's ones that is selected by the appropriate option. 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 "Modules" tab (fig. 4.1b) contains the list of modules in subsystem "Transports" and is identical for all modular subsystems. Tab "Help" contains a brief help for this page.


(63 Êá)
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 "Help". 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 "Help" tab it is provided the information about the module of subsystem "Transports" (Fig. 4.1d), whose structure is identical for all modules.


(80 Êá)
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:


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

Outgoing transport (Fig. 4.3e) contains:


(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:


(112 Êá)
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 the following tabs: "Modules" and "Help". The tab "Modules" (Fig. 4.1b) contains the list of modules in subsystem "Transport Protocols" and is identical for all modular subsystems. The tab "Help" contains a brief help for this page.


Each module of subsystem "Transport Protocols" provides configuration page with the only one tab — "Help". On the tab "Help" 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 "Template libraries", "Modules" and "Help".


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".

Tab "Redundancy" (Fig. 4.5b) contains the configuration of redundancy of data sources of subsystem "Data acquisition" of the station with the following settings:


Tab [Redundancy] tab of subsystem Data acquisition. (78 Êá)
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 "Help" contains the brief help for this page.


(66 Êá)
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.


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

(70 Êá)
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:


(71 Êá)
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


(116 Êá)
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 "Help". 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 "Help" provides information about the module of the subsystem "Data acquisition" (Fig. 4.1d), which structure is identical for all modules.


(59 Êá)
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". (106 Êá)
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". (71 Êá)
Fig. 4.5j. "Parameters" tab of the 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.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 main configuration tab of the parameter of the controller of subsystem "Data acquisition". (59 Êá)
Fig. 4.5k. 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". (62 Êá)
Fig. 4.5l. The "Attributes" tab of the parameter of the controller of subsystem "Data acquisition".

(68 Êá)
Fig. 4.5m. 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". (70 Êá)
Fig. 4.5n. 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 "Messages archive", "Value archives", "Modules" and "Help".


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"

The "Messages archive" 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:


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

Tab "Value archives" (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 is identical for all modular subsystems. The "Help" tab contains the brief help for this page.


(76 Êá)
Fig. 4.6c. 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.6d) contains the basic settings of the archive:


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

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:


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

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:


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

Each module of the "Archives" subsystem provides configuration page with the tabs "Archivators" and "Help". 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 "Help" tab contains information about the module of subsystem "Archives" (Fig. 4.1d), whose structure is identical for all modules.


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

Messages archivers 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:


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

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:


(112 Êá)
Fig. 4.6i. 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.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:


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

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.


(77 Êá)
Fig. 4.6k. 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 tabs "Modules" and "Help". The "Modules" tab (Fig. 4.1b) contains a list of modules of subsystem and it is identical for all modular subsystems. The "Help" tab contains a brief help for this page.


Each module of the subsystem "User Interfaces" provides configuration page with the tabs "User Interface" and "Help". 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 "Help" tab there is an information about the module of the subsystem "User Interfaces" (Fig. 4.1d), which structure is identical for all modules.


(69 Êá)
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 tabs "Modules" and "Help". The "Modules" tab (Fig. 4.1b) contains a list of modules of subsystem and it is identical for all modular subsystems. The "Help" tab contains a brief help for this page.


Each module of the subsystem "Specials" provides configuration page with the tabs "Special" and "Help". 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 "Help" tab there is an information about the module of the subsystem "Specials" (Fig. 4.1d), which structure is identical for all modules.


(73 Êá)
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 tabs "Subsystem" and "Help". The "Subsystem" tab (Fig.4.9a) contains the basic settings of the subsystem. The "Help" tab contains a brief help for this page. The structure of the tab "Subsystem":


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

/Home Page En / Doc / Programm Manual / part 4 / part 10  :: (edit)

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, for example script (openscada_demo) of 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="DemoStation">
        <!--
        Discribe internal parameter for station.
        Station this only OpenSCADA programm.
        -->
        <prm id="StName">Demo station</prm>
        <prm id="StName_ru">Äåìî ñòàíöèÿ</prm>
        <prm id="StName_uk">Äåìî ñòàíö³ÿ</prm>
        <prm id="WorkDB">SQLite.GenDB</prm>
        <prm id="Workdir">~/.openscada</prm>
        <prm id="IcoDir">./icons</prm>
        <prm id="ModDir">/usr/lib/openscada</prm>
        <prm id="LogTarget">10</prm>
        <prm id="MessLev">0</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="./DEMO/DemoSt.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="" DB="test2"
                    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" BLK="Klap" IO="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" PERIOD="1000" PRIOR="0" PER_DB="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_Transporter">
                <!--
                <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>

        <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/"
                    FSArchMSize="300"
                    FSArchNFiles="10"
                    FSArchTmSize="30"
                    FSArchXML="1"
                    FSArchPackTm="10"
                    FSArchTm="60"/>
                <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/"
                    FSArchMSize="300"
                    FSArchNFiles="10"
                    FSArchTmSize="30"
                    FSArchXML="1"
                    FSArchPackTm="10"
                    FSArchTm="60"/>
            </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"
                    FSArchTmSize="8640"
                    FSArchNFiles="10"
                    FSArchRound="0.1"
                    FSArchPackTm="10"
                    FSArchTm="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"/>
                <prm id="SOAttDet" on="0" per="20" name="../../lib/openscada/daq_LogicLev.so" 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="BD" on="0" per="10" type="MySQL" bd="server.diya.org;roman;123456;oscadaTest" table="test" size="1000"/>
                <prm id="BD" on="0" per="10" type="DBF" bd="./DATA/DBF" table="test.dbf" size="1000"/>
                <prm id="BD" on="0" per="10" type="SQLite" bd="./DATA/test.db" table="test" size="1000"/>
                <prm id="BD" on="0" per="10" type="FireBird" bd="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="Func" on="0" per="10"/>
                <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="DemoStation"/>. 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=DemoStation. 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">Demo station</prm>. Where in the attribute <id> the ID of the attribute is specified, and in the tag's body the value of parameter "Demo station" 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 or in the "Help" tabs of the pages of the components of the configuration files of OpenSCADA (Fig.4.10a).


(108 Êá)
Fig. 4.10a. The "Help" tab of the OpenSCADA component.

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

***************************************************************************
********** OpenSCADA v0.6.4.1 (Linux-2.6.30-std-def-alt15). *********      
***************************************************************************

===========================================================================
========================= The general system options ======================
===========================================================================
-h, --help             Info message about system options.                  
    --Config=<path>    Config file path.                                   
    --Station=<id>     Station identifier.                                 
    --demon            Start into demon mode.                              
    --MessLev=<level>  Process messages <level> (0-7).                     
    --log=<direct>     Direct messages to:                                 
                         <direct> & 1 - syslogd;                           
                         <direct> & 2 - stdout;                            
                         <direct> & 4 - stderr;                            
                         <direct> & 8 - archive.                           
----------- The config file station </EmptySt/> parameters -----------     
StName     <nm> Station name.                                              
WorkDB     <Type.Name> Work DB (type and name).                            
Workdir    <path>       Work directory.                                    
IcoDir     <path>       Icons directory.                                   
ModDir     <path>       Modules directory.                                 
MessLev    <level>     Messages <level> (0-7).                             
LogTarget  <direction> Direct messages to:                                 
                           <direct> & 1 - syslogd;                         
                           <direct> & 2 - stdout;                          
                           <direct> & 4 - stderr;                          
                           <direct> & 8 - archive.                         
Lang2CodeBase <lang>    Base language for variable texts translation, two symbols code.
SaveAtExit <true>      Save system at exit.                                            
SavePeriod <sec>        Save system period.                                            

=================== Subsystem "Module sheduler" options =================
    --ModPath=<path>   Modules <path> (/var/os/modules/).                
------------ Parameters of section </DemoStation/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 </DemoStation/sub_BD/> parameters -----------
SYSStPref    <1>   Use station id prefix into generic (SYS) table.

======================= Subsystem "Security" options ====================

======================= Subsystem "Transports" options ==================

=============== Subsystem "Transport protocols" options =================

======================= The module <Protocol:HTTP> options =======================
---------- Parameters of the module section </DemoStation/sub_Protocol/mod_HTTP/> in config file ----------
AuthTime <min>      Life time of the authentication, minutes (default 10).

=================== Subsystem "Data acquisition" options ================
------------ Parameters of section </DemoStation/sub_DAQ/> in config file -----------
RdStLevel    <lev>  The curent station redundant level.                              
RdTaskPer    <s>    The redundant task call period.                                  
RdRestConnTm <s>    Restore connection timeout to dead reserve stations.             
RdRestDtTm   <hour> Restore data archive depth from a reserve station after deadline.
RdStList     <list> Redundant stations list, separated symbol ';' (st1;st2).

======================== Subsystem "Archives" options ===================
------------ Parameters of section </DemoStation/sub_Archive/> in config file -----------
MessBufSize   <items>       Messages buffer size.                                        
MessPeriod    <sec>         Message arhiving period.                                     
ValPeriod     <msec>        Values arhiving period.                                      
ValPriority   <level>        Values task priority level.                                 
MaxReqMess    <items>       Maximum request messages.                                    
MaxReqVals    <items>       Maximum request values.

======================= Subsystem "Special" options =====================

======================= The module <Special:SystemTests> options =======================
---------- Parameters of the module section </DemoStation/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 config 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)
11) Base64Code  Mime Base64 encoding algorithm tests.

===================== Subsystem "User interfaces" options ===============

======================= The module <UI:Vision> options =======================
---------- Parameters of the module section </DemoStation/sub_UI/mod_Vision/> in config file ----------
StartUser   <user>    No password requested start user.
RunPrjs     <list>    Run projects list on the module start.
RunTimeUpdt <mode>    RunTime update mode (0 - all widgets periodic adaptive update,
                       1 - update only changed widgets).
VCAstation  <id>      VCA station id ('.' - local).

======================= The module <UI:VCAEngine> options =======================
    --VCADBClearForce            Force clear VCA DB from data of API 1.

======================= The module <UI:QTCfg> options =======================
---------- Parameters of the module section </DemoStation/sub_UI/mod_QTCfg/> in config file ----------
StartPath  <path>    Configurator start path.
StartUser  <user>    No password requested start user.

======================= The module <UI:QTStarter> options =======================
---------- Parameters of the module section </DemoStation/sub_UI/mod_QTStarter/> in config file ----------
StartMod  <moduls>    Start modules list (sep - ';').

======================= The module <UI:WebVision> options =======================
---------- Parameters of the module section </DemoStation/sub_UI/mod_WebVision/> in config file ----------
SessTimeLife <time>      Time of the session life, minutes (default 10).


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.

/Home Page En / Doc / Programm Manual / part 4 / part 10  :: (edit)


 
There are 49 files on this page.[Display files/form]
There is no comment on this page. [Display comments/form]
2012-02-23 09:02:15 | Owner: Maxim Lysenko | Print version | Search: