Design of a new-generation seismic-acoustic monitoring information and analytical system

. The analysis of the existing approach to the development of an information and analytical system for seismic-acoustic monitoring is carried out. An approach to the development of a new generation system based on modern information technologies is proposed. The advantages of developing a system based on a universal technological platform are considered.


Introduction
For the assessment and continuous monitoring of the state of the developed rock mass and rock structures in the world mining practice in recent years, measuring systems with various technical characteristics and design features have been used.
In Russia, a number of measuring systems for monitoring rock pressure and assessing the state of a rock mass have been developed, a number of which have been successfully used at rock burst hazardous mines. One of the most advanced domestic developments for monitoring of the state of a rock mass is the digital automated system "Prognoz ADS" developed at the Mining Institute of the Far East Branch of the Russian Academy of Sciences (Khabarovsk), which has been in operated since 2005 at a number of underground mines in the Far East and Transbaikalia [1][2][3].
The software of this system consists of the following elements: «Master» -a program for configuring the system control parameters and continuous monitoring modes; «GeoControl» is a program for receiving data from digital receivers on the state of registration of seismic acoustic impulses and storing their characteristics in the form of macroparameters in the database management system (DBMS); «GeoAcoustics ADS» is a program for analyzing the results of continuous monitoring with the ability to generate graphical and tabular reports. Microsoft SQL Server is used as a DBMS, and Microsoft Windows is used as an operating system. This hardware and software complex has a significant number of advanced technical and algorithmic tools designed to ensure the reliability of the system, the relevance of the recorded data, the reliability of monitoring results and the efficiency of predictive estimates. However, this complex of programs is not devoid of a number of shortcomings inherent in similar software developments based on the applied two-tier architecture.
Such limitations include: -complexity of organizing remote work, due to the lack of offered in the set of thin clients and Web clients; -applied approach of object-oriented programming makes it possible to significantly simplify the possibility of team development with a simultaneous increase in the average rate of modernization of the functional of applications, however, the high level of developer involvement and the need for manual description of all characteristics of the developed objects of the final application does not allow us to assert the possibility of a significant increase in the speed of development; -lack of flexibility in terms of the platforms used, due to the lack of cross-platform and the need for a rigid binding to the used DBMS; -lack of built-in mechanisms for organizing work on mobile platforms and using Web technologies; -lack of built-in capabilities to create a failover cluster of applications with dynamic load balancing; -the need for independent development or use of third-party modules of analytical tools, combined with the means of flexible formation of interactive reporting documents.
Below is a description of the approach to the creation of a new generation information and analytical system for seismoacoustic monitoring, devoid of the above limitations.

Analytical platform
The solution to the problem of designing a new generation of seismoacoustic monitoring system should begin with the choice of the most suitable architecture. The most perfect solution at present is the use of a three-tier architecture, which assumes the presence of the following application components: a client application ("thin client" or terminal) connected to the application server, which in turn is connected to the database server [4].
In this case the client is a front-end (usually graphical) component that represents the first level, the actual application for the end user. The first level should not have direct connections with the database (for security requirements), be loaded with the main business logic (for scalability requirements) and store the application state (for reliability requirements). The simplest business logic can be and usually is taken to the first level: the authorization interface, encryption algorithms, checking the entered values for validity and compliance with the format, simple operations (sorting, grouping, counting values) with data already loaded on the terminal.
The application server is located at the second level. The second level contains most of the business logic. Outside of it are fragments exported to terminals, as well as stored procedures and triggers assigned to the third level.
The database server provides data storage and is taken to the third level. This is usually a standard relational or object-oriented database management system. While the third level is a database along with stored procedures, triggers, and a schema that describes the application in terms of the relational model, the second level is built as a programming interface that connects client components with the application logic of the database.
In the simplest configuration, the physical application server can be combined with the database server on one computer, to which one or more terminals are connected via the network.
In the "correct" (in terms of security, reliability, scalability) configuration, the database server is located on a dedicated computer (or cluster) to which one or more application servers are connected via the network, to which, in turn, terminals are connected via the network [5].
Compared to client-server or file-server architecture, the following advantages of threetier architecture can be distinguished: -scalability; -configurability -the isolation of the levels from each other allows (with the correct deployment of the architecture) to quickly and easily reconfigure the system in the event of failures or during scheduled maintenance at one of the levels; -high security; -high reliability; -low requirements for the speed of the channel (network) between terminals and the application server; -low requirements for productivity and technical characteristics of terminals, as a result of a decrease in their cost. The terminal can be not only a computer, but also, for example, a mobile phone or a Web client.
All the above requirements are met by modern platforms for the development and operation of ERP systems. The term EPR is usually understood as a software package that implements the strategy of enterprise resource planning (Enterprise Resource Planning through a specialized integrated package of application software. However, first of all, this term refers to an information system that allows you to store and process most critical data for work [6].
All ERP systems, regardless of the developer, are united by a common architecture, which can be described as follows: Platform. Basic capabilities and environment for modules and components. Only the developer can make changes to the platform code. Users and implementers do not have access to this code. The platform includes: -core -a software environment in which work will be done, for which you can write some add-ons and components; -basic functionality -a list of objects and functions, without which no information system can work. This functionality is usually built into the platform, unlike modules, it cannot be disabled.
Data management system. Database, including storage and methods of processing (interpretation) data. This category includes data storage on a server, database software (SQL or any alternative), tools for interpreting and processing data and sending it to software modules.
Modules. Components that connect to the platform as needed. All of them work with a single database and apply basic functionality. The rest of the modules work independently of each other, they can "seamlessly" connect and disconnect without problems if the need for them has disappeared. This modular structure is an important distinguishing feature of ERP systems [7].
It should be noted that the main functionality offered by manufacturers of such systems is practically useless, with rare exceptions, for performing work on organizing seismic acoustic monitoring at an enterprise. However, the development environment itself and the capabilities inherent in the proposed platform can significantly improve the quality of the development of the corresponding information and analytical system, leading to the optimization of production and practical application of the final product.
Analysis of the existing market for such software products allows us to conclude that at present the most optimal tool for development is the 1C: Enterprise platform.
Note that initially the 1C platform was created for automated work in enterprises, but over time, the 1C program was transformed into a system capable of automating almost any business process. In fact, it is a universal constructor that can be assembled and optimized for any type of activity [8].

Approach to developing an applied solution
Unlike existing programming approaches, the developer operates not only with classical programming terms, but primarily with configuration objects, which are constituent elements of any applied solution.
They are problem-oriented objects supported at the technology platform level. Thus, the developer's task is to collect from these objects, as from a constructor, the necessary structure of an applied solution and then describe specific algorithms for the functioning and interaction of these objects, which differ from their typical behavior.
The composition of objects supported by the technological platform is the result of analyzing the subject areas of 1C: Enterprise use, and identifying and classifying the business entities used in these areas. As a result of this analysis, the developer can operate with such objects as directories, documents, information registers, charts of accounts, etc.
Based on this description, the technological platform will create the corresponding information structures in the database, and in a certain way will work with the data stored in these structures. The developer does not need to worry about which tables, for example, the data should be placed in how they will be modified or presented to the user. The platform will perform all these actions automatically, based on the typical behavior of the objects used.
Thus, the developer operates with metadata -"data about data", or configuration objects. By adding another configuration object to the structure of the applied solution, the developer, in fact, adds a description of how the corresponding data will be placed and how it will interact with other data stored in the info-base [9].
Thus, the currently existing tables with primary data on registered impulses, information on placed primary converters, etc., in the 1C: Enterprise paradigm are described by such objects as the "Directory". And the complex of functions and data, assuming analytical calculations for the formation of events and acoustically active zones, are described by the objects "Document", which in this case takes the initial data in the form of the corresponding fields of the "Directory" and contains the program code for data processing. It is advisable to save the calculation results in the "Information register" object. This object can store information in the form of records, each of which contains dimension values and their corresponding resource values, as well as in the context of time.
At the same time, 1C: Enterprise analytics tools allow you to generate interactive documents that are closely integrated into the application solution. The user can change the parameters of the report, rebuild it, use "transcripts" -the ability to generate additional reports based on individual elements of an already generated report.

Conclusions
The proposed approach to the design of a new generation seismic-acoustic monitoring information and analytical system compares favorably with the current approach due to the use of a modern technological development platform that combines the functions of a modern development environment and a highly reliable, scalable, cross-platform execution environment.
Testing the proposed approach allows us to conclude about the prospects of this solution and its practical importance of application at a working enterprise.
The proposed approach can be proposed as a further evolutionary development of seismoacoustic monitoring tools in the corresponding laboratories of the MI FEB RAS, which has a complete analogue of the existing functionality and its expanded capabilities [10].