4. Configuration and adjustment of the system

• Scalability. You can connect only the required configuration modules or use only the remote mechanisms.
• Excluding the need to update the configurators with the addition of new modules/functions, as well as the exclusion of "swelling" of the configurator, providing the support for all of history of now unnecessary and obsolete modules/functions.
• Simplicity of the creation of the graphical interfaces of configuration on the different basis owing to the clear formality.
• The possibility of dynamic configuration is available, ie configuration can be performed directly while the running of the system both locally and remotely, directly controlling the result.
• The simple and special extensibility of the configuration interface by adding the configuration fields on the control interface's description language only in the required components.

• Configuration module on the GUI library Qt (http://en.wikipedia.org/wiki/Qt_(framework)) — UI.QTCfg. Provides an advanced configuration interface, allowing to operate as a local station and the remote ones in the local and global networks, including secure connection.
• Configuration module based on the dynamic WEB-technologies (DHTML) — UI.WebCfgD. Provides an advanced configuration interface, allowing to operate as a local server's station, and the remote stations in the local and global networks, including work on the secure connection. Client connection is provided through the usual Web-browser.
• Configuration module based on the static WEB-technologies (XHTML) — UI.WebCfg. Provides an adequate configuration interface that allows to manage the local server's station via the usual Web-browser.

• Tab "Station" contains basic information and configuration field of the station, Fig.4a. Here are the provided fields and comments on them:
  • ID — contains information about the station's identifier. It is specified by the command line parameter "--station". When loading it is sought the section in the configuration file appropriate to the station identifier, and if not detected, it uses the first available one.
  • Station name — indicates the localized station's name. It is specified by the command line parameter "--statName".
  • Program — contains information on the program name. Usually it is OpenSCADA or name of solution based on OpenSCADA.
  • Version — contains the information on the current version of the programme.
  • Host name — contains the information on the name of the machine that runs the station.
  • System user — contains the information about the user on whose behalf the program is executed in the system (OS).
  • Operation system — contains the information about the name and version of operation system, operation system kernel on which the program is executed.
  • CPU — contains the CPU operative information specifically that is accessible CPU/core number and frequency of the CPU, which runs the program. The value of frequency is checked every 10 seconds, for X86, and allows you to monitor its change, for example, by the power management mechanisms.
  • Main CPUs set — indicates main list CPUs for use by OpenSCADA tasks. Into round brackets contains list of used CPUs currently.
  • Tasks planning clock — contains information about the used tasks planning clock and it's resolution on the operation system. It allows you to orient with the minimum interval of time of periodic tasks, for example, for task of data acquisition.
  • Internal charset — contains information about the charset in which text messages are stored within the program.
  • Config file — contains information about the configuration file used by the program. Set by the command-line parameter "--config".
  • Work directory — indicates the working directory of the station. It is used in relative addressing of the objects in the file system, for example, database files. It allows the user to save the modified system data to another database. The value of this field is not stored in the database, but can be changed only in the "WorkDB" section of the configuration file.
  • Modules directory — indicates the directories of modules for OpenSCADA, separated by ';', they can include a files' template into the end (/my/modules/path/lib*.so). If the value of this field is incorrect, then at start you will not see any graphical interface, but the only information in the console on the correct running of the OpenSCADA kernel.
  • Icons directory — indicates the directory containing the program icons. If the configuration navigation tree have no icons, then you have incorrectly entered the value of this field.
  • Documents directory — indicates the directory containing the program documents. If you can not to call local documents then you have incorrectly entered the value of this field or no the documents installed.
  • Work DB — indicates the working database (DB), namely, the database used to store basic data of the program. Changing of this field notes all objects as modified that allows you to save or to load station's data from the specified main database.
  • Save the system at exit — points to the need to save the changed data at finishing of the program.
  • Save the system period — indicates the frequency in seconds with which to save the changed station's data.
  • Language — indicates the language of messages of the program. Changing of this field is acceptable, but leads to a change of messages' language only for the interface and dynamic messages!
  • Messages — section of the parameters' group that are processing by the work and messages of the stations:
    • Least level — indicates the level of messages beginning from which they are to be processed. Messages below this level will be ignored. The level "Debug (0)" have special sense, it set will enable debug messages generation by different parts of the system. For the parts debug messages generation control you can use tab "Debug" (fig.4d).
    • To syslog — indicates the need of sending the message to the system logger, the mechanism of operation system for work with system messages and software. When this option is enabled the possibility appears to manage and control the OpenSCADA messages by the mechanisms of OS.
    • To stdout — indicates the using as a standard mechanism to display the message the output to the console. Disabling of this feature will eliminate the entire output in the console, unless you specify the following parameter.
    • To stderr — indicated the using as a standard mechanism to display the message the error output, it is also usually sent to the console.
    • To archive — indicated the need for output of the messages in the messages' archive of OpenSCADA. This option is usually enabled and its disabling leads to the actual disabling of the archiving at the station.
• Tab "Subsystems" tab contains the list of subsystems (Fig. 4b) and allows you to jump directly to them using the context menu.
• Tab "Redundancy" (Fig. 4c) contains the configuration of redundancy of the station with the following settings:
  • Status — contains information on redundancy scheme, at the moment this time spent on the execution of one cycle of the task of reserve processing.
  • Station level — indicates the level of the station in an arrangement (0-255).
  • Redundant task period (s) — indicates the period of execution of the redundancy task in seconds (1-255).
  • Restore connection timeout (s) — indicates over the which period of time to attempt to reconnect with a lost redundant station in seconds (0-255).
  • Local primary commands transfer — enables of local primary commands transfer to the redundant stations for the local changes automatic sync.
  • Stations — contains the table with information about the redundant stations. Stations can be added and removed via contextual menu. Id of the added stations is to be chosen from the list of available OpenSCADA system stations. Presence into the table at last one enables the redundancy in whole and opens access to pages of the redundancy configuration at level of subsystems, in condition of the subsystem supports the redundancy. The table provides the following information about the station:
    • ID — ID of the system OpenSCADA station, should be changed after the addition by choosing from the list of available ones;
    • Name — name of the system OpenSCADA station;
    • Live — sign of the connection with the redundant station;
    • Level — level of the remote station in the redundancy scheme;
    • Counter — requests' counter to the redundant station or waiting time, in the case of the absence of connection.
  • Go to remote stations list configuration — command to go to the configuration page of the remote OpenSCADA stations in the subsystem "Transports".
• Tab "Tasks" contains the table with opened tasks by OpenSCADA components (Fig.4d). From table you can get several information about the tasks, and also set CPUs for tasks of multi-processors systems.
• Tab "Debug" contains elements for control to debug (Fig.4e) and activates at select the messages level "Debug (0)" or at the objects counters using.
• Tab "Translations" contains elements of the manager of central translations text messages of the system (Fig.4f) and activates at the multi-language mode enabling by base language of text variables set. Elements of the translations manager:
  • Text variable's base language — is used to activate the support of multilingual text variables by specifying a non-empty basic language. The value of the basic language is selected from the list of bi-character language code, usually only the current and the base language is in the list. Further for the text variables in the non basic language in the tables of the database it will be created the separate columns. Under the text variables the all text fields of configurator, which can be translated into another language are meant. Numbers and other symbolic values are not in their number and are not translated.
  • Dynamic translation — current state and plan the dynamic text messages translation. The dynamic text messages translation causes the text messages translation cache enabling and requests to the translations to the DB depends to the OpenSCADA system part's language, mostly for multi-language dynamic user interfaces when user has self-preferred language.
  • Enable manager — enabling the translation manager. Cause the system reloading to forming an index of built translations, however this do not doing to forming full the messages index by deny to reloading some objects into an execution. For full the messages index loading you ought the manager save into enable mode and OpenSCADA restart. Ongoing the system next start will forming full the messages index.
  • Languages — the translations languages list from base, controls the manager. The language column will contain a data if set language present into source or will not else.
  • Source filter — the messages filter by substring into the source.
  • Check for mismatch — toggle checking and indicating to mismatch messages' translation into different places, needs more time for that.
  • Messages — same the messages table with columns: the base language, selected translation languages, the messages sources. To modify there are allowed the languages columns and at result the changes will set to the messages sources.

Fig. 4a. The "Station" tab of the main page of the configuration of the station.

Fig 4b. The "Subsystems" tab of the main page of the configuration of the station.

• Monitoring of the connection with external stations. In the monitoring process the requests to remote stations are made to get the information about them updated and to check connection. In the case of loss of connection with the station the repeat of connection to it is made through interval specified in the configuration field "Restore connection timeout". In the "Live" field of the station the current state of communication is displayed. In the "Counter" field the number of requests carried to the remote station, or the time remaining for the next connection attempt to the lost station is displayed. In the "Run" field there is a list of active controllers at the remote station with a sign of the local execution.
• Local planning of the objects' execution in reserve. Planning is carried out in accordance with the station's level and preferences of execution of objects: controllers, messages archivators.
• Calling the data synchronization function for the local objects of the redundant subsystems working in the mode of synchronization of data from the external stations.

Fig 4c. The "Redundancy" tab of the main page of the configuration of the station.

Fig 4d. "Tasks" tab of the main page of the configuration of the station.

Fig. 4e. The "Debug" tab of the main page of the configuration of the station.

Рис. 4f. The "Translations" tab of the main page of the configuration of the station.

4.1. "DB" subsystem

Fig. 4.1a. The hierarchical structure of "DB" subsystem.

Fig. 4.1b. Tab "Modules" tab of the root page of "DB" subsystem.

• Module — module's identifier.
• Name — module's name.
• Type — module's type, subsystem's identifier, which contains the module.
• Source — shared library — the source of the module.
• Version — module's version.
• Author — module's author.
• Description — module's short description.
• License — license agreement of module's distribution.

Fig. 4.1c. "DB" tab of the module of "DB" subsystem.

Fig. 4.1d. "Module" tab of the module of the "DB" subsystem.

• Section "State" — contains the properties which characterize the DB status:
  • Enable — DB status "Enable".
  • Accessible tables — list of tables that are in the database. Context menu of the property gives the opportunity to physically remove the tables from the database.
  • Load system from this DB — command to make load from this database. Can be used when transferring data in the database between stations. For example, you can save the section of one station in the export database, physically to move the DB to another station and connect it in this subsystem, and call this command.
• Section "Config" — contains the following configuration fields:
  • ID — contains the information on the DB identifier.
  • Name — specifies the DB name.
  • Description — short description of the DB and it's appointment.
  • Address — DB address in the specific for the database type (module) in the format. Format Description of the DB address recording format is usually available in the tooltip for this field.
  • Code page — indicates the code page, in which the text values of database are stored and provided. The value of the code page of database in conjunction with the internal code page of the station is used for clear transcoding of the text message while exchange between the station and the database.
  • To enable — indicates the state "Enable", in which to set the DB when start.

Fig. 4.1e. Tab "Data base" of the DB of module of subsystem "DB".

Fig. 4.1f. Tab "Tables" of the DB of module of subsystem "DB".

Fig. 4.1g. Tab "SQL" of the DB of module of subsystem "DB".

• table's cells content redaction;
• addition of the line;
• deleting of the line.

Fig. 4.1h. Tab "Table" of the DB table of the module of the subsystem "DB".

4.2. Subsystem "Security"

Fig. 4.2a. Tab "Users and Groups" of the root page of the subsystem "Security".

• Name — information about the name (identifier) of the user.
• Full name — specifies the full name of the user.
• Description — description and random information about the user.
• Password — the field to change the user's password. It always displays "******".
• Language — user's language for the dynamic messages context and for text to speech of the user interface. Empty to the system language.
• User picture — specifies the user's picture. Picture can be loaded and saved.
• Groups — the table with a list of user groups of the station and with the sign of identity of the user to the groups.
• User DB — DB address for the user's data storage.

Fig. 4.2b. The tab "User" of the user's page of "Security" subsystem.

• Name — information about the name (identifier) of the user's group.
• Full name — specifies the full name of the user's group.
• Description — description and random information about the users group.
• Users — list of users included in this group. With the context menu of the list you can add or remove the user in the group.
• User group DB — DB address for the user group's data storage.

Fig. 4.2c. The tab "Group" of the user's group page of "Security" subsystem.

4.3. Subsystem "Transports"

Fig. 4.3a. The hierarchical structure of subsystems "Transports".

• Id — identifier of the external station.
• Name — the name of the external host.
• Transport — the combobox of the subsystem's module "Transports" for the using of it when access to the external station.
• Address — address of the external station if the format, specific to the chosen in the previous field of the module of the subsystem "Transports".
• User — the name/identifier of the user of the external station on behalf of whom to perform the connection.
• Password — password of the user of the external station.
• Mode — The host mode: "User", "System", "User and System".
• Uprising level — Uprising hosts level of the pointed host for possibility of the requests re-transmission.

Fig. 4.3b. Tab "Subsystem" of the root page of subsystem "Transports".

Fig. 4.3c. The tab "Transports" of the module of subsystem "Transports".

• Section "State" — contains the settings that characterize the state of the transport:
  • Status — information on the current transport's status and statistics of its work.
  • Running — state of the transport "Running".
  • Transport DB — DB address to store the transport's data.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the transport's identifier.
  • Name — specifies the transport's name.
  • Description — brief description of the transport and its appointment.
  • Address — transport's address in the specific for the type of transport (module) format. Description of the record format addresses transport, as a rule, is available in the tooltip for this field.
  • Transport protocol — indicates the transport protocol module (subsystem "Transport protocols") that should work in conjunction with the input transport. Ie the received unstructured data this module will sent to the structuring and processing to the specified module of the transport protocol.
  • To start — indicates the status of "Running", in which to transfer the transport at startup.

Fig. 4.3d. Tab "Transport" of the page of incoming transport of module of subsystem "Transports".

• Section "State" — contains the settings that characterize the state of the transport:
  • Status — information on the current transport's status and statistics of its work.
  • Running — state of the transport "Running".
  • Transport DB — DB address to store the transport's data.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the transport's identifier.
  • Name — specifies the transport's name.
  • Description — brief description of the transport and its appointment.
  • Address — transport's address in the specific for the type of transport (module) format. Description of the record format addresses transport, as a rule, is available in the tooltip for this field.
  • To start — indicates the status of "Running", in which to transfer the transport at startup.

Fig. 4.3e. Tab "Transport" of the page of outgoing transport of module of subsystem "Transports".

• Time (ms) — information about the time taken for request and receiving the answer.
• Mode — indicates the regime of data from the following list: "Binary", "Text(LF)", "Text(CR)", "Text(CR/LF)", in which the request will be formed and the answer will be provided. In binary mode data is recorded in pairs of numbers in hex, ie bytes, separated by spaces.
• Timeout wait — sign for expect by timeout when a response is received. Many systems in response to various protocols (HTTP) are send the response data in several pieces. Without this flag will be received and displayed only the first piece. When this flag will be set all the pieces awaiting an answer, until the lack of data during the timeout the transport elapsed .
• Input buffer size, bytes — control of the input buffer size and the reading disabling (0) at all, only writing.
• Send — command to send a request.
• Request — contains the request in the selected mode of data representing.
• Answer — provides the answer in the selected mode of data representing.

Fig. 4.3f. The tab "Request" of the page of outgoing transport of module of subsystem "Transports".

4.4. Subsystem "Transport protocols"

4.5. Subsystem "Data acquisition"

Fig. 4.5a. The hierarchical structure of subsystem "Data acquisition".

• Redundancy of the data acquisition mechanism. Typically, this function is realized without special arrangements by simply running of the parallel redundancy stations with the same configuration and working independently. However, in the case at the station, which works as PLC, such approach is unacceptable because of the simultaneous making of control actions and the absence of synchronization of calculators' data.
• Compensation of the data loss on the time of the node stop with the redundant node archive. There are two mechanisms of compensation. The first and the main mechanism implements the loading of the sections of the archive from the redundant station at the time of the station startup in general or of individual controller's objects. The section of the archive is requested from the moment of the last record in the local archive and till the current time. The depth of the request is limited by the indicating of the limit time in the configuration of the redundancy. The second, complementary mechanism, performs the filling of the "holes" in the archive at the time of the actual user's request to the data. Such an approach on the one hand allows to make the predictable in time synchronization at startup and on the other hand it's actually eliminates the data loss in the case of working at least one station during the entire time.
• Load distribution of data acquisition between the nodes. When creating complex allocated systems there can be an important question of predicting and optimizing of the overall system performance. Taking into account these problems the redundancy mechanism provides the execution of tasks of data acquisition of individual sources (OpenSCADA controllers) only at one station. The other stations' tasks would go to data synchronization mode with the executive station. In the case of loss of the connection with the executive station the task of the local data acquisition is started. It's also provided the possibility of optimal the load distribution of the execution of data acquisition task's of the controllers' group between the stations.
• Optimization of the load on the external data sources through the data request from an external source by the only one node. In practice, we often meet highly loaded data sources or interfaces of access to the data sources, for which even the data acquisition by one station can be a problem and would require reducing the acquisition periodicity, i.e. data quality. The mechanism of redundancy, besides the load distribution between the stations as described above allows you to remove an additional load form the data source and its interfaces, thereby improving the quality of data. Writing to attributes of the controller's object under redundancy causes to the modification request sending to the master one, that is through it.
• Prevention of some differences of data on different nodes associated with the mismatch of moments of time at the independent acquisition of data by individual nodes by means of receiving the data from the station with an active controller. In systems of high accountability under the redundancy there should be excluded or minimized the differences in the data at different stations, that means the real acquisition of data by one station and synchronization with these data of other ones.

• Restore data depth time (hours) — indicates the maximum depth of archival data to restore from the archive of the remote station when start up in hours (0-12).
• Controllers — contains the table with the list of controllers, available for redundancy, and their current status:
  • Controller — full controller's ID;
  • Name — controller's name;
  • Started — the sign of the controller's execution on the local station;
  • Redundant — redundancy mode of the controller, you can select it from the list:
    • "Off" — absolutely independent working of the controller's object.
    • "Asymmetric" — full redundancy with the allowed controller's object configuration of the remote station and without tries to generalize its.
    • "Only alarms" — in fact it is working without a redundancy, but with alarms oppressing from the reserve controller's object to exclude a duple messages into the alarms.
  • Preferable run — configuration of the preferred execution at the specified station can be changed; reserved values:
    • <High Level> — execution at the station with the highest level.
    • <Low Level> — execution at the station with the lowest level.
    • <Optimal> — the choice for the execution of the least loaded station.
  • Remoted — sign indicating the execution of the controller on the remote station and work the local station in mode with a remote data synchronization.

Fig. 4.5b. Tab "Redundancy" tab of subsystem "Data acquisition".

Fig. 4.5c. The tab "Template libraries" of the subsystem "Data acquisition".

• Section "State" — contains properties that characterize the state of the library:
  • Accessing — state of library "Accessing".
  • Library DB — address of the database for data storage of the library and templates.
  • Date of modification — date and time for the object last modification.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the ID of the library.
  • Name — specifies the name of the library.
  • Description — short description of the library and its purpose.

Fig. 4.5d. The main tab of configuration of template library of subsystem "Data acquisition".

Fig. 4.5e. The tab of the list of templates in the template library of subsystem "Data acquisition".

• Section "State" — contains properties that characterize the state of the template:
  • Accessing — state of template "Accessing".
  • Used — counter of the template's using. Allows you to determine whether the template is used and, consequently, the ability to edit the template.
  • Date of modification — date and time for the object last modification.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the ID of the template.
  • Name — specifies the name of the template.
  • Description — short description of the template and its purpose.

Fig. 4.5f. The main configuration tab of the parameters template of subsystem "Data acquisition".

• Id — ID of the attribute.
• Name — the name of the attribute.
• Type — select the value's type of the attribute from the following: "Real", "Integer", "Boolean", "String", "Text", "Object".
• Mode — select the mode from list: "Input", "Output". Typically used to indicate the direction of data transmission through link. Ie, values for "Input" data link will only be obtained, and for the "Output" will also be transferred, in the case of modification.
• Attribute — mode of the parameter's attribute, implemented based on a template from the list: "No attribute" ,"Read Only","Full access". For the attributes of a template, in which this field is set, it will be created an appropriate attribute in the controller's parameter of this subsystem.
• Configure — configuration mode of the attribute in the configuration tab of a template of the controller's parameter of this subsystem from the list: "Variable", "Constant", "Link". In "Constant" and "Link" modes tab in the configuration tab of the template will be added these attributes to set the constant or specify an external link of the parameter.
• Value — attribute's default value or template of the links to access by the link. The format of the link's template depends on the component that uses it. Usually for the module DAQ.LogicLev the link's template is written the following way: {Parameter}|{attribute}. Field {Parameter} — specifies the parameter's name as the attribute's container. Attributes with the equal value {Parameter} will be grouped and will be appointed only by the indication of attributes' container, and individual attributes will be associated with the attributes of the container in accordance with the field {attribute}.

Fig. 4.5g. The configuration tab of the attributes and template's program of subsystem "Data acquisition".

Fig. 4.5h. The tab "Controllers" of the module of the subsystem "Data acquisition".

• Section "State" — contains the properties, which characterize the state of the controller:
  • Status — specifies the controller's status. In our case, the controller is running and the computation time is 425 microseconds.
  • Enable — the state of the controller "Enable". When enabled, the controller provides the possibility of creating the parameters and their configuration.
  • Run — the state of the controller "Run". The running controller performs the physical data acquisition and/or includes mechanisms for access to these data.
  • Controller DB — the address of the database for data storage of the controller and its parameters.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the controller's identifier.
  • Name — specifies the controller's name.
  • Description — brief description of the controller and its purpose.
  • To enable — indicates the status of "Enable" in which to transfer the controller at startup.
  • To start — indicates the status of "Run" in which to transfer the controller at startup.
  • Parameters tables — names of tables that store the parameters of different types (refers to parameter objects of data acquisition).
  • Calc schedule — defines a periodic or scheduled character of calculations. In our example this one second of calculation template.
  • Request task priority — sets the priority of data acquisition of this controller. It is used when scheduling the operating system tasks. In the case of proper access availability this field includes the planning of the controller's task in real time and with the specified priority otherwise it modifies parameter "nice" of the task.

Fig. 4.5i. The main configuration tab of the controller of subsystem "Data acquisition".

Fig. 4.5j. "Parameters" tab of the configuration page of the controller of subsystem "Data acquisition".

Fig. 4.5k. "Diagnostic" tab of configuration page of the controller of subsystem "Data acquisition".

• Section "State" — contains the properties, which characterize the state of the parameter:
  • Type — specifies the type parameter. Type of disabled parameter can be changed if there are multiple types.
  • Enable — the state of the parameter "Enable". Enabled parameter is used by the controller fro data acquisition.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the parameter's identifier.
  • Name — specifies the parameter's name.
  • Description — brief description of the parameter and its purpose.
  • To enable — indicates the status of "Run" in which to transfer the parameter at startup.
  • Parameter template — the address of the previously discussed template.

Fig. 4.5l. The main configuration tab of the parameter of the controller of subsystem "Data acquisition".

Fig. 4.5m. The "Attributes" tab of the parameter of the controller of subsystem "Data acquisition".

Fig. 4.5n. The "Archiving" tab of the parameter of the controller of subsystem "Data acquisition".

Fig. 4.5o. The "Template config" tab of the parameter of the controller of subsystem "Data acquisition".

4.6. Subsystem "Archives"

Fig. 4.6a. The hierarchical structure of subsystem "Archives"

• Redundancy of the data acquisition mechanism. It's means of messages combination from the redundant stations by the three mechanisms:
  • in the main cycle of redundancy there performs a request for new messages of the archivator on the master station from a last message time of the redundant object;
  • writing messages to the redundant archivator causes to redirection of the writing request to to the master station both for new and rewriting messages (also the messages write locally);
  • rewriting messages to the master archivator causes to the messages sending for all redundant stations.
• Compensation of the data loss on the time of the node stop with the redundant node archive. There provides only an initial synchronization by loading/reloading of parts of the archive from the redundant station, at the station starting in general. The archive's part requested from the moment of the last record into the local archive minus value of the parameter of the depth of the forced reloading and till the current time. Changed messages to more depth from the pointed should be lost on the started station!
• Load distribution of data acquisition between the nodes. When creating complex allocated systems there can be an important question of predicting and optimizing of the overall system performance. Taking into account these problems the redundancy mechanism provides the execution of tasks of archivation of individual archivators only at one station. The other stations' tasks would go to data synchronization mode with the executive station. In the case of loss of the connection with the executive station the task of the local archivation is started. It's also provided the possibility of optimal the load distribution of the execution of archivation task's of the archivators' group between the stations.
• Restoring of the alarms primacy. For alarming messages, negative level, at its writing performs an additional processing for the active alarms, that is only old — original ones allow for rewriting.

• Overtime of the reserve history reload at start, hours — points to the messages requesting depth from time of the last message into the local archive. Sometime that can be usable for reloading last messages if its can be potential changed-updated at the station down.
• Message archivators — contains the table with the list of message archivators, available for redundancy, and their current status:
  • Archivator — full archivator's ID;
  • Name — archivator's name;
  • Started — the sign of the archivator's execution on the local station;
  • Redundant — redundancy mode of the archivator, enabling;
  • Preferable run — configuration of the preferred execution at the specified station can be changed; reserved values:
    • <High Level> — execution at the station with the highest level.
    • <Low Level> — execution at the station with the lowest level.
    • <Optimal> — the choice for the execution of the least loaded station.
  • Remoted — sign indicating the execution of the archivator on the remote station and work the local station in mode with a remote data synchronization.

Fig. 4.6b. The "Redundancy" tab of subsystem "Archives".

• Messages buffer size — indicates the dimension of the area of memory reserved for the interim buffer of messages. Messages from the buffer are requested for viewing and archived with the messages archivers.
• Archiving period (s) — the periodicity with which the archivers select messages from the buffer for their archiving.

• Time, size (s) and level — specifies the request time, the size or the depth (in seconds) and the minimum level of messages (more than or equal).
• Category pattern — specifies the category of the requested messages. In the category you can specify the elements of a sample of the template, namely, the characters '*' — for any string and '?' — for any character, as well as a regular expression enclosed between '/' (/mod_(System|LogicLev)/).
• Archivators — indicates the messages archivators (separated by symbol ';'), for which the request is to be processed. If the value is missing, the request will be processed for the buffer and all archivers. If "<buffer>" is specified, then the request will be processed for the messages buffer.

• Time — message's time.
• Category — message's category.
• Level — message's level.
• Message — message's text.

Fig. 4.6c. The "Messages archive" tab of the subsystem "Archives".

• Get data period (ms) — indicates the periodicity of the active archiving task. In fact, the highest level of detail or the minimum period of active archives is determined by this value.
• Get data task priority level — sets the priority of task of active archiving. It is used when scheduling the operating system tasks. In the case of proper access availability this field includes the planning of the archiving task in real time and with the specified priority otherwise it modifies parameter "nice" of the task.
• Variable timestamp force to current time — time-stamp of values, received on the active archivation, forces to current time, replaces the data source time.

Fig. 4.6d. The "Value archives" tab of the subsystem "Archives".

• Section "State" — Contains the properties, which characterize the state of the archive:
  • Running — The state of the parameter "Running". Running archive collects data in the buffer and is served by the archivators.
  • Buffer start and end — Time of values begin and end into the buffer.
  • Archive DB — Database address for storing the archive's data.
• Section "Config" — Directly contains the configuration fields:
  • ID — Information on the archive's identifier.
  • Name — Specifies the archive's name.
  • Description — Brief description of the archive and its purpose.
  • To start — Indicates the state "Running" in which to transfer the archive at startup.
  • Source — Indicates the type and address of the source. Type of source is indicated from the list: "Passive", "Passive param. attribute" or "Active param. attribute". Passive archive does not have an associated source of values, the data to the such archive the source transfers by itself, for example from users' calculate procedures on internal programming language. Types with the attribute of the parameter in the address field indicate the parameter of the subsystem "Data acquisition" as the source. Passive attribute of the parameter sends data to the archive by itself with its own period of data acquisition. Active attribute of the parameter is queried by the archiving task of this subsystem. Virtually all sources of real data process into passive mode of archiving as the data at once placed in the attribute parameter, sometimes by time stamp. But calculators (DAQ.JavaLikeCalc, DAQ.LogicLev, DAQ.BlockCalc) can only operate in active mode, archiving, because the data in the attribute parameter is updated only with their direct request, and are taken from the execution context. In the case of real data sources, the difference between active and passive mode of archiving by the fact that in the passive mode the source can put data into the archive by timestamp, and in active mode, the timestamp is always set to the current system time.
  • Data combining mode — Sets combining mode for data writing from highresolution buffer (for example, 1s) to lowresolution archivator (for example, 1min.), when into single point of the archivator placed several values from buffer (for example, 60). The modes implemented: "Moving average", "Single", "Minimum" and "Maximum".
  • Value type — Indicates the type of values which are stored in the archive from the list: "Boolean", "Integer", "Real", "String", "Int16", "Int32", "Int64", "Real(Float)" and "Real(Double)".
  • Buffer period (s) — Indicates the periodicity of values in the archive's buffer.
  • Buffer size (items) — Indicates the dimension and depth of the archive's buffer. The dimension is usually set in terms of 60 sec of the periodicity of the archiving task with the reserve.
  • Buffer hard time grid — Indicates the mode of the buffer. The hard grid mode involves the memory reservation for each value, but without the timestamp. This mode eliminates the possibility of packaging the adjacently-identical values, but also saves on storage of the timestamp. Otherwise, the buffer operates in the mode of storage the value and timestamp and supports the packaging of adjacently-identical values.
  • Buffer high time resolution — indicates the possibility of storing values at intervals up to 1 microsecond, differently the values can be stored at intervals up to 1 second.
  • Fill pass points to a last value — mostly the pass values fill by EVAL but sometime the source's data periodicity greater to the archive's one and it is normal.

Fig. 4.6e. The main configuration tab of the values' archive of subsystem "Archives".

• Archivator — information on the archiver's address.
• Start — information on the archiver's state "Started".
• Process — sign of the processing this archive be the archiver. The field is available for modification by the user.
• Period (s) — information on the periodicity of the archiver.
• Begin — date and time of the archive beginning in the archiver.
• End — date and time of the archive ending in the archiver.

Fig. 4.6f. The "Archivators" tab of the values archive of subsystem "Archives".

• Time — indicates the time of request. It contains two fields: the field of date + time and microseconds.
• Size (s) — specifies the size or depth of the request in seconds.
• Archivator — indicates values archiver for which the request is to be processed. If the value is missing, the request will be processed for the buffer and for all archivers. If the <buffer> is specified, then the request will be processed only for the archive's buffer.
• Show trend — indicates the necessity for presentation of the archive's data in the form of a graph (trend), otherwise the result is presented in a table that contains only time and value. In the case of installation of this field the schedule is formed and displayed, in addition additional configuration fields of the image settings are appeared:
  • Picture size — indicates the width and height of the generated image in pixels.
  • Value scale — indicates the lower and upper limit of the scale of value. If both values are set to 0 or equal, then the scale will be determined automatically depending on the values.

Fig. 4.6g. The "Values" tab of the values archive of subsystem "Archives".

Fig. 4.6h. The "Archivators" tab of the module of subsystem "Archives".

• Section "State" — contains the properties, hich characterize the archivers' state:
  • Running — archivers' state "Running". The running archiver processes the messages archive buffer and puts his data in its repository, but also it processes requests for access to data in the repository.
  • Archivator DB — database address for storing the archiver's data.
  • End — date + time of the last data in the archiver's repository.
  • Begin — date + time of the first data in the archiver's repository.
  • Archivator files size (kB) — information about the total size of the archiver's files with the data.
  • Archiving time (ms) — time spent on the archiving of messages archive data.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the archiver's identifier.
  • Name — indicates the archiver's name.
  • Description — brief description of the archiver and its purpose.
  • To start — indicates the status "Running", in which to transfer archiver at startup.
  • Message categories — list of categories of messages, separated by ';'. Messages matched with the templates or regular expressions of categories will be processed by the archiver. In the category you can specify the elements of a sample of the template, namely, the characters '*' — for any string and '?' — for any character, as well as a regular expression enclosed between '/' (/mod_ (System|LogicLev)/).
  • Message level — indicates the level of archiver's messages. Messages with a level greater than or equal to the specified one are processed by the archiver.
  • Address — address of the storage in the specific for the type of archiver (module) format. Format description usually available in the tooltip for this field. In the example it is the relative path to the storage directory.
• Section "Additional options" — specialized section for module about the contents of which you can read in the documentation on the module.

Fig. 4.6i. The main tab of the messages archiver configuration of subsystem "Archives".

• Time, size (s) and level — specifies the request time, the size or the depth (in seconds) and the minimum level of messages (more than or equal).
• Category pattern — indicates the category of the requested messages. In the category you can specify the elements of a sample of the template, namely, the characters '*' — for any string and '?' — for any character, as well as a regular expression enclosed between '/' (/mod_ (System|LogicLev)/).

• Time — message time.
• Category — message category.
• Level — message level.
• Message — message text.

Fig. 4.6j. Tab of the messages request "Messages" of the messages archiver of subsystem "Archives".

• Section "State" — contains the properties, hich characterize the archivers' state:
  • Running — archivers' state "Running". The running archiver processes the messages archive buffer and puts his data in its repository, but also it processes requests for access to data in the repository.запросы на доступ к данным в хранилище.
  • Archiving time (ms) — information about the time spent on archiving data of the archives buffers. Periodicity of archiving is set in the field "Period archiving" in the section "Config" of the tab.
  • Archivator DB — database address for storing the archiver's data.
• Section "Config" — directly contains the configuration fields:
  • ID — information on the archiver's identifier.
  • Name — indicates the archiver's name.
  • Description — brief description of the archiver and its purpose.
  • To start — indicates the status "Running", in which to transfer archiver at startup.
  • Address — address of the storage in the specific for the type of archiver (module) format. Format description usually available in the tooltip for this field. In the example it is the relative path to the storage directory.
  • Value period (s) — indicates the periodicity of values that are contained in the archiver's repository.
  • Period archiving (s) — indicates the periodicity of the archives buffers data archiving task. The dimension of the archives buffers in the time expression must not be less, and preferably somewhat greater then the periodicity of the of archiving task. Set zero period for disable using the archiver for buffer processing, only for direct write.
  • Selection priority — selection the archiver priority for "All" sources using mode. Set to zero for full the selection disable.
• Section "Additional options" — specialized section for module about the contents of which you can read in the documentation on the module.

Fig. 4.6k. The main tab of the values archiver configuration of subsystem "Archives".

• Archive — archive's name.
• Period (s) — archive's periodicity in seconds.
• Buffer size — buffer's dimension in units.
• Files size (Mb) — specific to the module Arch.FSArch field with information about the total size of the files of the archiver's storage for the archive.

Fig. 4.6l. The "Archives" tab of the values archiver of subsystem "Archives".

4.7. Subsystem "User interfaces"

Fig. 4.7a. The "User Interface" tab of the module of subsystem "User Interfaces".

4.8. Subsystem "Specials"

Fig. 4.8a. The "Special" tab of the module of subsystems "Specials".

4.9. Subsystem "Modules scheduler"

• Path to shared libs (modules) — information about the location of the directory with the modules of the OpenSCADA system. It is set by the parameter <ModDir> of the station, of the configuration file.
• Denied modules — the list, separated by ';' of modules that are denied for automatically connection and updating. It is set by the parameter <ModDeny> of the section of subsystem "sub_ModSched" of station of configuration file. List of denied modules has higher priority than allowed.
• Allowed modules — the list, separated by ',', of modules that are authorized for automatic connection and renewal. The value of '*' is used to resolve all the modules. It is set by the parameter <ModAllow> of the section of subsystem, sub_ModSched, of the station of the configuration file.
• Check modules period (sec) — indicates the periodicity of testing modules on the fact of their updating. Modules that are allowed for automatically connection and updating will be automatically updated.
• Check modules now — command to check the modules on the fact of their updating. Modules that are allowed for automatically connection and updating will be automatically updated.
• Shared libs (modules) — table with the list of shared libraries with the modules detected by OpenSCADA. Rows are modules, and in the columns there is an information about them:
  • Path — information on the full path to the shared library.
  • Time — information about the time the of last modification of a shared library.
  • Modules — information about the list of modules in a shared library.
  • Enable — state "Enable" of the shared library. Privileged users are provided with an opportunity to manually enable/disable the shared libraries by changing this field.

Fig. 4.9a. The main configuration tab of subsystem "Modules scheduler".

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

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

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

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

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

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

        <node id="sub_BD">
            <prm id="SYSStPref">0</prm>
            <tbl id="DB">
                <fld ID="GenDB" TYPE="SQLite" NAME="Generic DB" NAME_ru="Основная БД" NAME_uk="Основна БД" ADDR="St.db" CODEPAGE="UTF-8"/>
            </tbl>
        </node>

        <node id="sub_Security">
            <!--
            <tbl id="Security_user">
                <fld
                    NAME="root"
                    DESCR="Super user"
                    DESCR_ru="Супер пользователь"
                    DESCR_uk="Супер користувач"
                    PASS="openscada"/>
                <fld
                    NAME="user"
                    DESCR="System user"
                    DESCR_ru="Системный пользователь"
                    DESCR_uk="Системний користувач"
                    PASS=""/>
            </tbl>
            <tbl id="Security_grp">
                <fld
                    NAME="root"
                    DESCR="Super users groups"
                    DESCR_ru="Группа суперпользователей"
                    DESCR_uk="Група суперкористувачів"
                    USERS="root;user"/>
            </tbl>-->
        </node>

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

        <node id="sub_Transport">
            <!--
            <tbl id="Transport_in">
                <fld
                    ID="WEB_1"
                    MODULE="Sockets"
                    NAME="Generic WEB interface"
                    NAME_ru="Основной WEB интерфейс"
                    NAME_uk="Основний WEB інтерфейс"
                    DESCRIPT="Generic transport for WEB interface."
                    DESCRIPT_ru="Основной транспорт для WEB интерфейса."
                    DESCRIPT_uk="Основний транспорт для WEB інтерфейсу."
                    ADDR="TCP::10002:0"
                    PROT="HTTP"
                    START="1"/>
                <fld
                    ID="WEB_2"
                    MODULE="Sockets"
                    NAME="Reserve WEB interface"
                    NAME_ru="Резервный WEB интерфейс"
                    NAME_uk="Резервний WEB інтерфейс"
                    DESCRIPT="Reserve transport for WEB interface."
                    DESCRIPT_ru="Резервный транспорт для WEB интерфейса."
                    DESCRIPT_uk="Резервний транспорт для WEB інтерфейсу."
                    ADDR="TCP::10004:0"
                    PROT="HTTP"
                    START="1"/>
            </tbl>
            <tbl id="Transport_out">
                <fld
                    ID="testModBus"
                    MODULE="Sockets"
                    NAME="Test ModBus"
                    NAME_ru="Тест ModBus"
                    NAME_uk="Тест ModBus"
                    DESCRIPT="Data exchange by protocol ModBus test."
                    DESCRIPT_ru="Тест обмена по протоколу ModBus."
                    DESCRIPT_uk="Тест обміну за протоколом ModBus."
                    ADDR="TCP:localhost:10502"
                    START="1"/>
            </tbl>-->
        </node>

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

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

            <node id="mod_System">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="DataOS"
                        NAME="Data OS"
                        NAME_ru="Даные ОС"
                        NAME_uk="Дані ОС"
                        DESCR="Data of services and subsystems OS."
                        DESCR_ru="Данные сервисов и подсистем ОС."
                        DESCR_uk="Дані сервісів та підсистем ОС."
                        ENABLE="1"
                        START="1"
                        AUTO_FILL="0"
                        PRM_BD="DataOSprm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="DataOSprm">
                    <fld SHIFR="CPU" NAME="CPU load" NAME_ru="Нагрузка CPU" NAME_uk="Навантаження CPU" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" TYPE="CPU" SUBT="gen"/>
                    <fld SHIFR="MEM" NAME="Memory" NAME_ru="Память" NAME_uk="Пам\'ять" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" TYPE="MEM"/>
                </tbl>
                -->
            </node>

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

            <node id="mod_BlockCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="Model" NAME="Model" NAME_ru="Модель" NAME_uk="Модель" DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="Model_prm" BLOCK_SH="Model_blcks" PERIOD="1000" PRIOR="0" PER_DB="0" ITER="1"/>
                </tbl>
                <tbl id="Model_blcks">
                    <fld ID="Klap" NAME="Klapan" NAME_ru="Клапан" NAME_uk="Клапан" DESCR="" DESCR_ru="" DESCR_uk=""
                        FUNC="DAQ.JavaLikeCalc.lib_techApp.klap" EN="1" PROC="1"/>
                </tbl>
                <tbl id="Model_blcks_io">
                    <fld BLK_ID="Klap" ID="l_kl1" TLNK="0" LNK="" VAL="50"/>
                    <fld BLK_ID="Klap" ID="l_kl2" TLNK="0" LNK="" VAL="20"/>
                </tbl>
                <tbl id="Model_prm">
                    <fld SHIFR="l_kl" NAME="Klap lev" NAME_ru="Полож. клапана" NAME_uk="Полож. клапана" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" IO="Klap.l_kl1"/>
                </tbl>
                -->
            </node>

            <node id="mod_JavaLikeCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="CalcTest" NAME="Calc Test" NAME_ru="Тест вычисл." NAME_uk="Тест обчисл." DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="CalcTest_prm" FUNC="TemplFunc.d_alarm" SCHEDULE="1" PRIOR="0" ITER="1"/>
                </tbl>
                <tbl id="CalcTest_val">
                    <fld ID="in" VAL="0"/>
                    <fld ID="alrm" VAL=""/>
                    <fld ID="alrm_md" VAL="1"/>
                    <fld ID="alrm_mess" VAL="Error present."/>
                </tbl>
                <tbl id="CalcTest_prm">
                    <fld SHIFR="alrm" NAME="Alarm" NAME_ru="Авария" NAME_uk="Аварія" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" FLD="alrm"/>
                </tbl>
                <tbl id="lib">
                    <fld ID="TemplFunc" NAME="" NAME_ru="" NAME_uk="" DESCR="" ESCR_ru="" DESCR_uk="" DB="lib_TemplFunc"/>
                </tbl>
                <tbl id="lib_TemplFunc">
                    <fld ID="d_alarm" NAME="Digit alarm" NAME_ru="Авария по дискр." NAME_uk="Аварія за дискр" DESCR=""
                        FORMULA="alrm=(in==alrm_md)?&quot;1:&quot;+alrm_mess:&quot;0&quot;;"/>
                </tbl>
                <tbl id="lib_TemplFunc_io">
                    <fld F_ID="d_alarm" ID="in" NAME="Input" NAME_ru="Вход" NAME_uk="Вхід" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
                    <fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_ru="Авария" NAME_uk="Аварія" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
                    <fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_ru="Режим аварии" NAME_uk="Режим аварії"
                        TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
                    <fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_ru="Сообщ. аварии" NAME_uk="Повід. аварії"
                        TYPE="0" MODE="0" DEF="" HIDE="0" POS="3"/>
                </tbl>-->
            </node>

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

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

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

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

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

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

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

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

        <node id="sub_Archive">
            <prm id="MessBufSize">1000</prm>
            <prm id="MessPeriod">5</prm>
            <prm id="ValPeriod">1000</prm>
            <prm id="ValPriority">10</prm>
            <!--
            <tbl id="Archive_mess_proc">
                <fld
                    ID="StatErrors"
                    MODUL="FSArch"
                    NAME="Errors"
                    NAME_ru="Ошибки"
                    NAME_uk="Помилки"
                    DESCR="Local errors\' archive"
                    DESCR_ru="Архив локальных ощибок"
                    DESCR_uk="Архів локальних помилок"
                    START="1"
                    CATEG="/DemoStation*"
                    LEVEL="4"
                    ADDR="ARCHIVES/MESS/stError/"/>
                <fld
                    ID="NetRequsts"
                    MODUL="FSArch"
                    NAME="Net requests"
                    NAME_ru="Сетевые запросы"
                    NAME_uk="Мережеві запити"
                    DESCR="Requests to server through transport Sockets."
                    DESCR_ru="Запросы к серверу через транспорт Sockets."
                    DESCR_uk="Запити до сервера через транспорт Sockets."
                    START="1"
                    CATEG="/DemoStation/Transport/Sockets*"
                    LEVEL="1"
                    ADDR="ARCHIVES/MESS/Net/"/>
            </tbl>
            <tbl id="Archive_val_proc">
                <fld
                    ID="1h"
                    MODUL="FSArch"
                    NAME="1hour"
                    NAME_ru="1час"
                    NAME_uk="1год"
                    DESCR="Averaging for hour"
                    DESCR_ru="Усреднение за час"
                    DESCR_uk="Усереднення за годину"
                    START="1"
                    ADDR="ARCHIVES/VAL/1h/"
                    V_PER="360"
                    A_PER="60"/>
            </tbl>
            <tbl id="Archive_val">
                <fld
                    ID="test1"
                    NAME="Test 1"
                    NAME_ru="Тест 1"
                    NAME_uk="Тест 1"
                    DESCR="Test 1"
                    DESCR_ru="Тест 1"
                    DESCR_uk="Тест 1"
                    START="1"
                    VTYPE="1"
                    BPER="1"
                    BSIZE="200"
                    BHGRD="1"
                    BHRES="0"
                    SrcMode="0"
                    Source=""
                    ArchS=""/>
            </tbl>-->
        </node>

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

        <node id="sub_UI">
            <node id="mod_QTStarter">
                <prm id="StartMod">QTCfg</prm>
            </node>
            <node id="mod_WebCfg">
                <prm id="SessTimeLife">20</prm>
            </node>
            <node id="mod_VCAEngine">
                <!--
                <tbl id="LIB">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
                        DB_TBL="wlib_test2" ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2">
                    <fld ID="test2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2_io">
                    <fld IDW="test2" ID="name" IO_VAL="Test 2" IO_VAL_ru="Тест 2" IO_VAL_uk="Тест 2" SELF_FLG=""
                        CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
                    <fld IDW="test2" ID="dscr" IO_VAL="Test module 2" IO_VAL_ru="Тест модуля 2" IO_VAL_uk="Тест модуля 2" SELF_FLG=""
                        CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
                </tbl>
                <tbl id="PRJ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" DB_TBL="prj_test2"
                        ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="prj_test2">
                    <fld OWNER="/test2" ID="pg1" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436" FLGS="1"/>
                    <fld OWNER="/test2/pg1" ID="pg2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436" FLGS="0"/>
                </tbl>
                <tbl id="prj_test2_incl">
                    <fld IDW="/prj_test2/pg_pg1" ID="wdg1" PARENT="/wlb_originals/wdg_Box"/>
                </tbl>-->
            </node>
        </node>

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

</OpenSCADA>

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

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

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

The result of the command: # ./openscada_AGLKS --help
*************************************************************************** ********** OpenSCADA v0.9 (Linux-3.2.0-4-amd64). ********* *************************************************************************** =========================================================================== ==================== Generic options ====================================== =========================================================================== -h, --help Info message about the system 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 ================= ======================= The 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. ======================= The module <Archive:FSArch> options ======================= --noArchLimit Disable archives limit to the file number. Use for see archives mode, not work. ======================= Subsystem "Special" options ===================== ======================= The 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 =============== ======================= The 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 - ';'). ======================= The 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. ======================= The 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. ======================= The 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).