A method for automatically generating and displaying inspection reports

Abstract

This invention discloses an automatic inspection report generation and display method, including the following steps: Step 1: drawing a configuration screen according to requirements and selecting a database connection based on actual conditions; Step 2: configuring database request parameters and data processing parameters or functions for the cell model targeting data point objects; Step 3: querying real-time cross-section data or historical database data according to the parameters configured in the configuration screen; Step 4: updating the data results after calculation operations for the cell model in the configuration screen; Step 5: converting the configuration screen to generate a report file or database file. This invention provides a unified, universal, and feasible automated process for requesting and displaying data based on the drawing, configuration, data request, and report export functions of the configuration screen. It also utilizes server scripts to ensure the program can run effectively for a long time and is readily available with the server, and provides a downloadable inspection report function on the system interface front end.

Description

Technical Field

[0001] This invention relates to the fields of screen drawing, object configuration, parameter setting, data request, statistics and display in automated monitoring systems and information systems, and particularly to a method for generating and displaying automated inspection reports. Background Technology

[0002] Automated monitoring systems encompass the monitoring and operation management of integrated monitoring, power monitoring, environmental and equipment monitoring, rail transit, and other automated industrial control industries and their supporting facilities. Through uninterrupted monitoring and protection of functional facilities, they improve equipment reliability and automation levels, achieving reliable, safe, and advanced automated industrial control systems. Utilizing distributed devices and integrating various metering devices and monitoring terminals through a control network, they achieve real-time acquisition, statistics, and storage of monitoring data from auxiliary buildings and their surrounding environment, and automate the monitoring and control of various equipment. Data acquisition typically involves a wide variety of equipment, requiring the collection of substantial amounts of real-time operating parameters and status data. Some of this data is stored in historical databases based on changes or different data aggregation methods for statistical analysis.

[0003] With the continuous development of automated monitoring systems, their architecture is shifting from a client / server (C / S) model to a browser / server (B / S) model, and their design philosophy is becoming more intelligent, simple, and comprehensive. Data statistical analysis functions are becoming increasingly important. However, most current automated monitoring systems are limited to storing data from key data nodes and displaying statistical data for fixed important data. The rough statistical displays in graphical interfaces lack attention to and display of actual equipment operating parameters and data details. The steps for users to obtain detailed data are cumbersome, and it's difficult to create a standardized template for real-time parameters and data, resulting in a lack of usability. Previously, modules used for statistical data only operated on historical databases. When users needed data from multiple databases simultaneously, data acquisition became a tedious, inefficient, and error-prone task. Furthermore, there was no corresponding engineering software capable of integrating data from various sources to generate clear and concise inspection reports. Therefore, the existing automated monitoring systems are relatively lacking or incomplete in terms of data statistical analysis and data display methods.

[0004] In today's real-world projects, users prefer systems with configurable and permanent automated processes that can quickly, efficiently, and timely acquire real-time data from the same measurement points on the same equipment objects to generate inspection reports. Furthermore, the acquired data can be combined with historical data for statistical analysis to output more intuitive results. For example, users may not only need to collect statistics on multiple real-time data points for a specific equipment object A at certain times each day, but also expect to compare the parameter data of a specific equipment object B at a certain time with previously acquired historical data to obtain statistical data for equipment object B over a given time interval. This data from different databases or the calculated statistical data can be integrated to generate readable and easy-to-understand data reports. Summary of the Invention

[0005] To address the problems existing in the prior art, automated monitoring systems often require data queries by requesting a historical database containing real-time data detection and storage statistics from several measuring devices. This invention provides an automatic inspection report generation and display method that simplifies the tedious process of setting query conditions when querying data of the same type of equipment by setting parameters and requirements for the requested data.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is: an automatic inspection report generation and display method, comprising the following steps:

[0007] Step 1: Create a configuration screen for connecting to the database to obtain data points. The configuration screen will be drawn using models such as lines, text, tables, and cells. The static part of the table screen can be drawn with lines and text. The dynamic data part of the table is defined first with the table model. Then, cell models are bound in the table, and the style of each model is defined. After connecting to the database, the configuration screen can directly display the data points in the database in a tree list in the configuration interface and directly select the data points as objects to bind to cell models.

[0008] Step 2: Configure database request parameters and data processing parameters for the data point object. Different databases require different parameters. Bind the data point object to the cell model of the configuration screen. It is supported to bind the same data point object to multiple cell models of multiple configuration screens. After binding, configure the parameters required for the data point in the configuration interface of the cell model.

[0009] Step 3: Convert the configuration parameters of the data point objects and cell models into a specific data structure and query the real-time cross-section data or historical database data periodically according to the parameters.

[0010] Step 4: Update the data obtained in Step 3 to the corresponding cell model in the configuration screen according to the relevant parameters or functions set in the cell model, and generate an online data report that can be displayed in real time on the system screen.

[0011] Step 5: Convert the data structure of the configuration screen to generate specific report files or database files. This step is usually performed automatically every day, but it can also be done manually.

[0012] The second method of generating inspection reports in this invention is to add a report template model to the configuration screen. This model has a file path and a configuration item for whether to start it. The file in the file path is the report template. The static content and style of the report template are drawn directly in the report template. The cell requesting data is a dictionary string that converts the cell object data structure of the configuration screen into a JSON string, i.e., the template cell dictionary. After configuring the file path of the report template, clicking the button on the model starts the connection to the database. Then the configuration screen will read the cell dictionary, concatenate the string, send the request, and retrieve the data.

[0013] The configuration screen described in step one is for creating a set of easily editable and usable cell models. Connecting to the database is for efficiently selecting data point objects, which are then bound to the cell models in the configuration screen according to their positions to generate a report template. The static model in the configuration screen determines the static content and style of the generated report file, while the returned data determines the dynamic content of the report file. The cell models and data together determine the generated database file or configuration file. Data point objects and the configuration screen can also be generated by importing a database file.

[0014] Step one begins by classifying the measurement points of the automated monitoring system. Measurement points are defined as points with the same measurement requirements, time, equipment, or physical significance, grouped together as a single type. In the configuration screen, the locations of these measurement points are configured according to engineering requirements. The resulting configuration screen model should include important variable parameters for the equipment during field operation, such as three-phase current, gate status, and local / remote conditions. The report screen model should be logical, with appropriate classification of different points for ease of understanding; this is a requirement for the technical personnel designing the screen.

[0015] Once the specific format of the display model and the positions of the data point cell models are designed, you can begin drawing the configuration screen. Based on the design, use line and text models to draw the static parts of the table screen, such as the header. Use table models to define the dynamic data parts of the table screen, then bind cell models to the table, setting corresponding content and styles for each model. Finally, connect to the corresponding database address to retrieve the required data points. In the method using report template models, there is no need to draw the configuration table screen; the static content and styles of the report template are directly drawn from the report file.

[0016] Step two requires filling in the parameters for the required data, with each data point as the object. Data items can be broadly categorized into two types based on the database source and data nature: real-time data and historical data. Real-time cross-sectional data is a precise measurement of data from a specific device at a specific moment, while historical data is a statistical summary of data from a specific device over a certain period. For a cell model in the configuration screen that binds a single data point object, many different configuration items are required. The cell model in the configuration screen provides a configuration interface for data points. All configuration parameters can be directly selected and edited in the model's configuration interface. The selections come from the basic settings of the configuration screen itself and the database connected to the configuration screen.

[0017] If a database file is imported into the configuration screen, the file itself is generated by the configuration screen, and the data in it will be converted into a data structure that is easy for the program to recognize. If the data structure meets the requirements of the data point object, the data will be added to the data point object list of the current configuration screen, and the configuration parameters will change according to the settings in the program. If the data structure does not meet the requirements of the data point object, an error message will be displayed, which may be because the file was corrupted during the transmission process.

[0018] Step two: If the report template model is used, the cells requesting data are filled with a dictionary string that is a JSON string representation of the cell object data structure of the configuration screen, i.e., the template cell dictionary, which includes information about the data point objects and the necessary configuration items of the cell objects in the configuration screen.

[0019] For example, "Data Source" is a required parameter, representing the requested database. In real-time data, data points are unique in their data source because they possess the "Object ID" and "Object Attribute" parameters; therefore, these two parameters are also necessary, otherwise the requested object cannot be found. In the configuration screen, since the data point is directly selected, these two items are automatically filled in, but they are required when not connected to a database or when using a report template model; otherwise, the program will report an error.

[0020] Historical data has more complex configuration options compared to real-time data. Besides required fields such as "Data Source," "Object ID," and "Object Attributes," and optional fields like "Query Time," "Prefix," "Suffix," "Data Point," and "Operation," different configuration options exist depending on the historical database. For example, for the historical database used in the configuration example included with the program, the historical data cell model also requires configuration of required parameters such as "Data Type," "Statistical Type," "Statistical Operation," and "Statistical Status." Multiple configuration options are needed to retrieve accurate data. The "Data Point" and "Operation" configuration options specify the type of operation to be performed between the retrieved data and the original data stored in the program. If the "Data Point" contains JSON-formatted data point objects, multi-object operations will also be performed on the historical data.

[0021] The parameter configurations described above are all based on the database data request parameters and the parameter settings of the request program.

[0022] Step three relies on a module in the program. This module reads each cell model and its bound data point object from the configuration screen. Each cell model generates a dictionary object to store the configuration and data point information. All dictionary objects requesting the same data source are grouped according to the report order. When using the report template model, the program iterates through the cells in the table to read the cell dictionary and perform corresponding operations. Each newly generated dictionary object, in addition to the configuration items filled in the cell model or cell dictionary, also includes parameters such as "form," "row," and "column," indicating the cell model's position on the screen. These parameters do not need to be configured; the program reads them directly.

[0023] The fixed format of dictionary objects is determined by the classes defined in the program. The program defines several base classes, and the most important class that generates dictionary objects, "data point", depends on several lower-level classes. The functions of several subclasses are to load all configuration items of real-time data points, load all configuration items of historical data points, store data rules, and store important data of historical data points, respectively. Defining these subclasses can make the data structure clearer and easier to modify.

[0024] For real-time data points from the same data source, the data is further divided into multiple arrays based on the requested time. These arrays are stored in a large dictionary, where the keys are the requested time and the values ​​are arrays of data points. Historical data points, on the other hand, have only one measurement time and require only one array to store them.

[0025] At each set time point, the program retrieves the corresponding array and concatenates the parameters from each data point into the format required by the interface to make a data request. Different databases have certain differences in their request methods and interfaces.

[0026] In step four, after the data is requested, the program will first check whether the cell model of the data point has any pre-set calculation operations or function operations. If so, it will operate on the returned data, which will be divided into several cases: most of the returned historical data will be calculated with the data previously stored in the configuration file; if other data point objects are linked, multi-object calculation operations will also be performed; if an independent function is bound, the data will be processed by the function first.

[0027] For historical data, the latest requested data will also be updated in the configuration file to await the next retrieval. It is important to note the case of the first request for historical data. The automated monitoring system will create a new historical data configuration file, which will not contain the previous data. There are two ways to handle this: one is to give an initial value when writing the configuration item in the cell model, or default to 0 if no value is given; the other is not to output the result of the first historical data and to give a label prompt in the configuration screen. Of course, the generated report file will also give a prompt.

[0028] The program will then use a mapping table dictionary to index the results and data points to improve the speed of subsequent queries. If no data is found, the program will output an error and replace the original data with a default value.

[0029] Finally, the program locates the cell model to be written based on the index, then writes the data result and the string concatenated with the prefix and suffix into the corresponding cell model. After traversing all data points, it saves and generates a report file, and the data is displayed in real time on the configuration screen. At this point, the automatic generation and display of the report for that point in time is complete. When using a report template model, the data result is directly returned to the corresponding cell in the template, thus directly generating the corresponding report file for download.

[0030] In step five, the automated monitoring system iterates through all cell models in the configuration screen and generates either a report file for display and download or a database file for reusable data storage, depending on the requirements. The report file retains the content and style of the configuration screen but removes much configuration information. The database file stores all the data in the configuration screen for easy data recovery after a program crash or for running the same configuration screen on other devices. This step is usually performed automatically at a set time each day, but it can also be generated manually. Directly requesting data from the report template will generate a new report file without affecting the original report template and its configuration information, and the generation of daily report templates can be stopped at any time.

[0031] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0032] 1. This invention provides a feasible process for the automated request and retrieval of data. It can drive the driver to automatically query data and update the report screen model at regular intervals by drawing and configuring the configuration screen. It can also output data to report files or database files normally and efficiently. After being set up, it is relatively easy to maintain. The database file can be reused on other devices, and the configuration screen can be modified in real time. It greatly reduces the consumption of labor costs, greatly improves the efficiency of statistical data, and ensures the availability and ease of use in the later stage.

[0033] 2. This invention fulfills the requirement of simultaneously requesting data from different databases. By modifying the program settings according to the interface requirements of different databases, it is possible to query data from more diverse databases. For special data in historical databases, previous data can be stored for further processing. For data requiring special and precise processing, independent functions can be bound to retrieve the results. Therefore, this invention also possesses scalability.

[0034] 3. This invention uses different modules to make requests to different databases. When one module has a problem, the other modules can still operate normally without any problems. The good low coupling of this invention ensures that requests to different databases will not affect each other, thus guaranteeing the reliability of the invention.

[0035] 4. Once started, this invention requires no further operation. The program will automatically convert the configuration screen to generate daily report files and store the corresponding configuration files. Only when it is necessary to modify or add report content will the operation be performed again. Moreover, it can be operated directly within the configuration screen, which is convenient and efficient.

[0036] 5. This invention can be deployed in a server service via a script, automatically starting when the server boots up, and can promptly restart the service after it crashes for unknown reasons, ensuring the availability and longevity of the program.

[0037] 6. The method of this invention allows for convenient and quick requests to device object data points in an automated monitoring system without having to manipulate specific points in the database each time. Data point selection and parameter configuration can also be directly based on the configuration screen, greatly simplifying the tedious process of querying device object data. The configuration screen is more flexible and diverse, allowing technicians to customize the screen according to their needs. For historical data, this invention can also cache object data and link multiple data points, further improving data query and processing capabilities.

[0038] 7. The present invention also includes a front-end component. The front-end module located on the web can directly obtain the previously generated inspection reports from the server and provide a download link to the user. Attached Figure Description

[0039] Figure 1 This is a flowchart illustrating the automatic inspection report generation and display method of the present invention.

[0040] Figure 2 A flowchart of the report template drawing process is provided for an embodiment of the present invention.

[0041] Figure 3 Example of a transformer used in the process of creating a report template for this invention.

[0042] Figure 4 Example of a line cabinet for drawing report templates for this invention.

[0043] Figure 5 This is a flowchart of the parameter configuration process in an embodiment of the present invention.

[0044] Figure 6 This is a flowchart illustrating the JSON file generation process in an embodiment of the present invention.

[0045] Figure 7 This is a flowchart of the real-time data index generation process in an embodiment of the present invention.

[0046] Figure 8 This is a flowchart illustrating the historical data index generation process in an embodiment of the present invention.

[0047] Figure 9 A flowchart illustrating the process of writing real-time data in an embodiment of the present invention.

[0048] Figure 10 A flowchart illustrating the process of writing historical data in an embodiment of the present invention. Detailed Implementation

[0049] To enable those skilled in the art to further understand the features and technical content of the present invention, please refer to the following detailed description and accompanying drawings. The drawings are provided for reference and explanation and are not intended to limit the present invention.

[0050] In this embodiment, a subway power monitoring system is used as a system example for investigation. A new configuration screen template is created, and the WebSocket interface of the device connecting real-time data and the historical database is connected. The real-time data points, historical data points, and configuration parameters required for requests are configured in the data cell model in the screen.

[0051] The subway power monitoring system includes numerous types of measurement points, such as power consumption statistics for different incoming line cabinets, three-phase current and voltage of the line, SF6 pressure in different transformer compartments, oil temperature and winding temperature of different transformers, etc. Each measurement point also has one or more measurement time requirements. For example Figure 1 As shown, this paper will take the requirements of several devices of transformer type and incoming line cabinet type monitored by the subway power monitoring system and the numerous measurement points of these devices as an example to illustrate the specific process of configuring the measurement points of this type of device, filling in the query request parameters, and querying and displaying the data.

[0052] Step 1: Classify all transformer-type measurement points in the subway power monitoring system to their corresponding specific transformer equipment. Arrange the hierarchical relationships and structure of transformer types and measurement points on the screen. Finally, create a logical and easy-to-read report screen using different models. The report format and style are drawn using different models in the configuration screen according to the needs of technical personnel. For example, the headers and sidebars for "Equipment Object," "Measurement Point," "Time / Category," and "Measurement Time" are drawn using line and text models, while the body is drawn using a table model. Each cell in the table model is then bound to a cell model. Cell models can have more configuration options set, and each cell model exists independently to prevent high coupling.

[0053] Reference Figure 2 In this embodiment, "Equipment Object 1" to "Equipment Object n" represent n transformer-type equipment objects. First, each of these n transformer equipment objects ("Equipment Object 1" to "Equipment Object n") includes n measurement points ("Measurement Point 1" to "Measurement Point n"). Taking "Equipment Object 1" as an example, "Measurement Point 1" represents the room temperature of the environment in which the transformer equipment object is located, and "Measurement Point n" represents the winding temperature of the equipment object. Similarly, the measurement points of the remaining n-1 transformer equipment objects serve the same purpose. Therefore, it is possible to... Figure 2In the first step of the process, the aforementioned n transformer equipment objects are categorized into the same equipment type, allowing them to be grouped into the same report screen. For this transformer equipment type, "Measurement Point 1" only needs to be measured at 8:00 AM, while the other measurement points require measurement at the same three times: 8:00 AM, 2:00 PM, and 11:00 PM. Measurement times can also be categorized within the report template. After all the points are roughly categorized, they can then be... Figure 2 In process ②, a table is drawn according to the above classification. Measurement time is used as the vertical axis, and measurement points are used as the horizontal axis. The measurement points on the horizontal axis are also classified and merged together based on the equipment object. Since "Measurement Point 1" only needs to be measured once, it does not need to be used as the vertical axis with measurement time, and will follow the cell model of the equipment object in the form of parentheses.

[0054] The same operation applies to transformer-type equipment, but the data cell models for both types of equipment can be displayed in the same report screen. Figure 3 This is a flowchart illustrating the process of creating a report screen using a transformer device object as an example.

[0055] Similarly, the same applies to incoming line cabinet type equipment. Figures 2-4 In the design, "Equipment Object 1" to "Equipment Object n" represent n incoming line cabinet equipment objects, each with n measurement points. However, since the measurement points of the incoming line cabinet type equipment are historical data, it is only necessary to request the historical data of the previous day at a single time point on the second day. Therefore, the measurement time of the historical data does not need to be shown in the chart. Figure 4 This is a flowchart illustrating the process of creating a report template using the incoming line cabinet equipment as an example. Compared to transformer equipment, the drawing of measurement time has been simplified.

[0056] Based on the design, draw the static elements such as the table header using lines and text models. Place the table model in the area where you will fill in the measurement points, and bind multiple cell models to the table model. The table is now complete. Next, connect to the database to retrieve the list of data point objects.

[0057] Step 2: Bind the data point objects in the report screen drawn from the device type model described in Step 1 to the cell model and configure the necessary parameters. The placement of the data point objects is planned during the design phase; simply find the corresponding data point and bind it to the cell model at that coordinate.

[0058] For data configuration items, different items have different priorities. Some required parameters may affect the normal operation of the database. The specific implementation steps and configuration item priorities include:

[0059] Step 1: The first thing to focus on is the "Data Source" configuration item. This is mainly related to the database requested by the data cell model. For example, the measurement points of transformer equipment are real-time data, and the data source is a real-time database. Therefore, this item should be configured to use a real-time database. The "Data Source" configuration item is the most important. It is not only needed for later data classification, but it is also essential for the initial configuration file generation step. If the program does not find this configuration item, it will not only report an error, but also fail to generate the configuration file. Therefore, the "Data Source" configuration item has the highest priority.

[0060] Step 2: Next, you need to fill in the "Object ID" and "Object Attributes" configuration items. These two, combined, uniquely locate the measurement point's data in the database. Missing either one will prevent data retrieval, even though a configuration file can be generated. Therefore, the "Data Source" configuration item has the second highest priority. The device's "Object ID" and "Object Attributes" need to be obtained by requesting from the database. However, the advantage of this invention is that the configuration screen is already connected to the data points, allowing direct querying and binding of the corresponding data points to the report screen without manually configuring the "Object ID" and "Object Attributes." However, for cases where the database was not connected during the configuration phase or for externally imported report templates, manual configuration is required. Each transformer device has a different "Object ID," but they all share the same attribute category. For different measurement points, points belonging to the same device have the same "Object ID," while the "Object Attributes" depend on the type of data measured at the point.

[0061] Step 3: The types and priorities of configuration items differ for different databases. For example, for historical data, the priorities of "Data Type," "Statistical Type," "Statistical Operation," "Statistical Status," and "Query Time" are just as important as the two in Step 2. However, real-time data does not require these items at all. This is because historical databases have more complex data storage and more powerful functions, involving more statistical parameters. These parameters are used to obtain statistical data after the raw data has been processed. Without these configuration items, the database cannot retrieve accurate values. It is worth noting that "Query Time" is not a required field. This does not mean it is unimportant; it simply has a default value, which is the previous day's time.

[0062] Step 4: The measurement time determines when the measurement point is measured, so the corresponding configuration item "Request Time" is also very important, although it is not required. When this configuration item is not set, the measurement time defaults to the first time point in the time point list, so for real-time data, its priority is third. Historical data requests are generally made at a single time point on the next day, and the "Request Time" setting is not very meaningful for them. The historical data request time is set by technical personnel in the program's basic settings.

[0063] Step 5: Historical data cannot be used immediately. Some historical data needs to be processed before it can be used. The "operation" configuration item is the configuration for processing the requested data, which will affect the output data. However, it has a default value and is not a required field, so its priority is not high.

[0064] Step 6: The "prefix" and "suffix" configuration items only determine the final appearance of the data cell model in the report and do not change the output data. They are optional configuration items based on requirements, so they have the lowest priority.

[0065] Figure 5 The configuration items and their priorities have been visualized.

[0066] Once the configuration parameters for the cell model are determined, they can be set to... Figure 5 Enter the process step ① into the report. Figure 5 The display shows the parameter configurations of two measurement points for the transformer device "Transformer 1" and the "Positive Active Daily Power Consumption Statistics" measurement point for the "Incoming Line Cabinet 1" device.

[0067] Assuming the index value of the real-time database in the database list is 1, the "Data Source" configuration item for both points of the transformer equipment is 1; assuming the object ID of "Transformer 1" in the real-time database is 34865155, and both points belong to "Transformer 1", the "Object ID" configuration item is also the same; assuming the object attribute of the first measurement point is "Temperature", then its "Object Attribute" item is "Temperature", and the same applies to the other point; assuming the first measurement point is measured at 8:00, and the number of 8:00 in the time point list is 0, then the "Request Time" configuration item for the first point is 0, while the number of 14:00 in the time point list is 1, so the configuration item for the second point is 1; both points are for temperature, in degrees Celsius, and the "Suffix" configuration item is set to "℃".

[0068] Assuming the index value of the historical database in the database list is 0, the "Data Source" configuration item for the incoming line cabinet device should be set to 0. Assuming the object ID of "Incoming Line Cabinet 1" in the historical database is 529530917 and the object attribute is "Counter", both configuration items for the location can be set. Assuming that obtaining the electricity consumption statistics for the location requires the data type to be analog, the statistical type to be cumulative, and the statistical operation to be the maximum value, then according to the historical database interface specification, the location's "Data Type" can be set to 0, "Statistical Type" to 1, and "Statistical Operation" to 1. The "Query Time" defaults to the day before the database request time, so it doesn't need to be set here. The location's electricity consumption is in kilowatt-hours, so the "Suffix" configuration item should be set to "kwh". The obtained data is actually the total electricity consumption of the incoming line cabinet device since its startup, which needs to be differentially calculated with the previously stored data. According to the program's basic settings, the "Calculation Operation" configuration item should be 1, representing differential calculation.

[0069] Step 3: The program first creates multiple dictionaries based on the data source in the basic settings. Then, based on the request time, it creates several time point queues under these arrays. Each queue will store the data point object requested at that time point. The program then begins reading the cell models in the report. When it detects a bound data point object, it retrieves the configuration items and data point information, converts them into a data object, and adds this object to one of the corresponding time point queues according to the data source and request time parameters.

[0070] After traversing the cell model, it means that all objects in the screen have been arranged into the time point queue. The parameters of the transformer equipment are in the real-time data queue. If a certain device has both real-time data and historical data, its data points will also be arranged in the two queues respectively.

[0071] The cell model of the "temperature" measurement point bound to "Transformer 1" in the configuration screen is read by the program and then... Figure 6 In process ①, the data points are added to the dictionary. Unconfigured items are stored with default values. Through process ①, the parameters entered by technicians are stored in the added data point object. Simultaneously, the program obtains the location of this cell model and updates the dictionary parameters identifying the cell model's location, such as "report," "form," "row number," and "column number." Finally, after all data cell models have been traversed, a data point queue, divided according to the data source and request time, is created and awaits invocation. The incoming line cabinet equipment objects follow the same process, but they request historical data from the historical database and are therefore added to a different queue than the transformer equipment objects.

[0072] Subsequent data requests are convenient; the work can be completed by directly calling the database interface. For example, for real-time cross-sectional data, a request is made via HTTP using a RESTful interface, and the requested device returns the current real-time data to the program in the form of a WebSocket. For historical databases, however, data needs to be requested indirectly by calling a PHP file via HTTPS.

[0073] All n measurement points of the n transformer equipment objects, from "Equipment Object 1" to "Equipment Object n", will be measured once at 8:00. The program will concatenate the parameters of all requested data points into a string required by the interface and send it to the RESTful interface to request data. There will be n*n data request operations at 8:00. However, "Measurement Point 1" will not be measured at 14:00 and 23:00, so there will only be n*(n-1) data request operations.

[0074] Step four focuses on processing and displaying the returned data. Based on the previously configured operations and functions, the program first performs calculations and function processing on the data. This process may involve calling other data point objects or historical data stored in the configuration file. The processed data is finally displayed on the configuration screen. Of course, some data points that require historical data during calculations will also have their data updated in the configuration file.

[0075] The key point of step four is the way the returned data and data points are indexed. It is foreseeable that each measurement point will be requested once or multiple times a day, which means that the index should be reusable. Also, it is unlikely that all measurement point data will be requested at a single point in time. Therefore, it is inefficient and resource-intensive to create an index after the data is requested. Thus, it is necessary to create an external mapping table for the index and to create the index before requesting the data.

[0076] This invention will use a dictionary to create a mapping table.

[0077] For real-time data points, the dictionary keys consist of the report number, the data object ID, the attribute name, and the string of the requested time. The dictionary values ​​are an array containing all data points that request the same data, thus enabling a data point to be bound to one or more cell models.

[0078] Because the data returned by the real-time database contains corresponding object IDs and attribute names, it is not necessary to index the returned data with the data points. For transformer equipment objects, this step is completed before the data request. Each data point in the cell model corresponds to a parameter dictionary. The parameters are extracted according to rules, concatenated into strings as keys, and the parameter dictionary is passed into an array. The array is used as the values ​​to form a key-value pair mapping table. The mapping table for the n measurement points of n transformer equipment objects is established before the data request, resulting in a total of n*n mappings.

[0079] Figure 7 The process of indexing the measurement point "temperature" of "Transformer 1" is demonstrated. First, the data parameters in memory are assembled into a fixed format through process ① as the key of the mapping table dictionary. The data points are first put into an array through process ③, and then the array is used as the value of the dictionary through process ④.

[0080] The historical database is more complex. The dictionary keys consist of the report number, the data object ID, the attribute name, the data type queried, and a string representing the query time. Although the dictionary value is an array, because the historical database doesn't return data with corresponding object IDs and attribute names like the real-time database, the array stores two smaller dictionaries containing key-value pairs. These smaller dictionaries include the data point and the returned data. The default value for the returned data in a newly created dictionary is None. If two historical data points with the same key exist in the report, the smaller dictionary for the new historical data point is added to the corresponding array. After the database returns data, the data values ​​in the smaller dictionaries are updated.

[0081] Figure 8 This demonstrates the process of creating an index for the "Positive Active Daily Electricity Consumption Statistics" measurement point of "Incoming Cabinet 1", outlining the general steps and... Figure 7 It's the same, except that the array value in the historical data mapping table dictionary is another small dictionary.

[0082] The mapping tables for real-time and historical databases are set to arrays instead of single data points to account for potential duplicate data in the reports, meaning that multiple cell models may contain identical data. However, in this embodiment, this situation does not occur with either real-time or historical data. In practical applications, however, this situation will occur more frequently as the number and content of reports increase; therefore, this invention takes it into consideration. Thus, in this embodiment, n*n mappings may not necessarily correspond to n*n cell models; there could be more.

[0083] Based on the returned data and the established index, the obtained data results can be filled into the cell models of the report screen. For real-time data, the returned data also includes the corresponding object ID and attribute name. Knowing the current report number and request time, the key of the mapping table can be directly constructed to retrieve the dictionary of the corresponding data point, which contains all the parameters of the measurement point. Based on the parameters, the location of the corresponding cell model can be determined, and the returned data can be directly written into the cell model.

[0084] Taking 8:00 as an example, the n measurement points of the n transformer equipment objects from "Equipment Object 1" to "Equipment Object n" return n*n data. By concatenating the parameters in the data into a fixed format, the corresponding data points can be retrieved from the mapping table. Finally, the data is written into the retrieved cell model. This operation needs to be performed n*n times or more.

[0085] Figure 9 This demonstrates the process of writing the temperature measurement point "Transformer 1" into the report screen. First, the parameters are assembled into a fixed format through process ①, then the corresponding data points are obtained through process ②, the cell model is located according to the position parameters through process ③, and finally the data results are filled into the cell model through process ④.

[0086] For historical databases, a one-to-one or one-to-many mapping has been established between data and data points, allowing data to be written directly through the mapping table. The mapping table is traversed, retrieving dictionaries containing the results of calculations and the corresponding arrays of data points. The parameters for each data point are obtained, the position of the corresponding cell model is determined, and the data result is written.

[0087] Figure 10 This demonstrates the process of traversing the mapping table for each key-value pair, obtaining the data point, locating the cell model, and then writing the data result into the report.

[0088] Step five primarily involves transforming the data structure of the configuration screen to generate specific report files or database files. The configuration screen itself is a database with a unique data structure. Using the Python library `openpyxl` can generate report files with the `.xlsx` extension. Stringifying the data structure directly generates configuration files with the `.json` extension. Using the Python library, the keys in the configuration screen's dictionary are mapped to fields in the SQL table to generate a database file with the `.sql` extension. It's important to note that generating report files from the configuration screen will lose information about data point objects and their parameter configurations in the cell model; it's only suitable for displaying data results. Configuration files and database files can better preserve configuration information and data results, making them easier to use on other devices. Using a report template model, directly requesting data will generate a new report file without affecting the original report template at the corresponding file path or its configuration information. Furthermore, the generation of daily report templates can be stopped at any time via a button.

[0089] The present invention has been disclosed above with reference to preferred embodiments, but it is not intended to limit the present invention. All technical solutions obtained by equivalent substitution or equivalent transformation fall within the protection scope of the present invention.

Claims

1. A method for automatically generating and displaying inspection reports, characterized in that: Includes the following steps: Step 1: Create a configuration screen for connecting to the database to obtain data points. The configuration screen uses lines and text to draw the static part of the table screen. The table model is used to first define the dynamic data part of the table, then the cell model is bound in the table, and the content and style of each model are defined. At the same time, after connecting to the database, the configuration screen can directly display the data points in the database in a tree list in the configuration interface and directly select the data points as objects to bind to the cell model. Step 2: Configure database request parameters and data processing parameters for data point objects. Different databases require different parameters. Bind the data point object to the cell model of the configuration screen. It is supported to bind the same data point object to multiple cell models of multiple configuration screens. After binding, configure the parameters required for the data point in the configuration interface of the cell model. Step 3: Convert the data point objects and their configuration parameters into a specific data structure and query the real-time cross-section data or historical database data periodically according to the parameters; Step 4: Update the data obtained in Step 3 to the cell model of the corresponding configuration screen by performing relevant operations on the relevant parameters or functions corresponding to the data points, and generate an online data report that can be displayed on the screen in real time. Step 5: Convert the data structure of the configuration screen to generate specific report files or database files.

2. The method for generating and displaying automatic inspection reports according to claim 1, characterized in that: The configuration screen and data point objects are generated by importing from the database file. The configuration screen is used to create a set of cell models that are easy to edit and use. Connecting to the database is used to efficiently select data point objects. Then, the data point objects are bound to the cell models in the configuration screen according to their positions to generate a report template. The static model in the configuration screen determines the static content and style of the generated report file, and the returned data determines the dynamic content of the report file. The cell model and data together determine the generated database file or configuration file.

3. The method for generating and displaying automatic inspection reports according to claim 1 or 2, characterized in that: Add a report template model to the configuration screen. This model has a file path and a configuration item for whether to start it. The file in the file path is the report template. The static content and style of the report template are drawn directly in the report template. The cell requesting data is a dictionary string that is a JSON string of the cell object data structure of the configuration screen, i.e., the template cell dictionary. Configure the file path of the report template, click the button on the model to start the database connection, and then the configuration screen will read the cell dictionary, concatenate the string, send the request to get the data and return it.

4. The method for generating and displaying automatic inspection reports according to claim 1, characterized in that: In step two, when complex data operations are required, the cell is linked to other data point objects and the operation is set; if there are more refined operation requirements, an independent function is configured in the cell model or the database file is imported into the program to generate a configuration screen.

5. The method for generating and displaying automatic inspection reports according to claim 3, characterized in that: In step two, parameters need to be filled in for the required data based on the data points. Data items can be divided into two categories based on the source of the database and the nature of the data: real-time data and historical data. Real-time data is a precise measurement of the data of a certain device at a certain moment, while historical data is a statistical analysis of the data of a certain device over a certain period of time. The configuration screen provides a configuration interface for data points. Configuration parameters can be selected and edited directly in the data point object. The selection items come from the basic settings of the configuration screen itself and the database connected to the configuration screen.

6. The method for generating and displaying automatic inspection reports according to claim 5, characterized in that: The configuration parameters in the real-time data include data source, object ID, object attributes, query time, prefix, and suffix; the configuration parameters in the historical data include data source, object ID, object attributes, query time, prefix, suffix, data type, statistical type, statistical operation, statistical status, data point, and operation; at the same time, the data points of both types of data can be bound to independent functions, and the obtained raw data will be updated into the configuration screen after the function's operation.

7. The method for generating and displaying automatic inspection reports according to claim 5, characterized in that: In step two, if a database file is imported into the configuration screen, the file itself is generated by the configuration screen, and the data in it will be converted into a data structure that is easy for the program to recognize. If the data structure meets the requirements of the data point object, the data will be added to the data point object list of the current configuration screen, and the configuration parameters will change according to the settings in the program. If the data structure does not meet the requirements of the data point object, it is because the file was corrupted during transmission, and an error message will be displayed.

8. The method for generating and displaying automatic inspection reports according to claim 5, characterized in that: In step two, if the report template model method is used, the cell requesting data is filled with a dictionary string that is a JSON string representation of the cell object data structure of the configuration screen, i.e., the template cell dictionary, which includes information about the data point object and the necessary configuration item information of the cell object of the configuration screen.

9. The method for generating and displaying automatic inspection reports according to claim 1, characterized in that: Step three specifically involves: reading each cell model and its bound data point object in the configuration screen; generating a dictionary object for each cell model to store the configuration and data point information on the cell model; and grouping all dictionary objects requesting the same data source together according to the report order.

10. The method for generating and displaying automatic inspection reports according to claim 9, characterized in that: The data structure and format of the data point object are determined by the classes defined in the program. The program defines multiple base classes, and the class "data point" that generates the dictionary object depends on multiple lower-level subclasses. The functions of these subclasses include loading all configuration items of real-time data points, loading all configuration items of historical data points, storing data rules, and storing important data of historical data points.

11. The method for generating and displaying automatic inspection reports according to claim 9, characterized in that: Before the automated monitoring system runs, it first reads the cell model in the configuration screen, then refines the data points and classifies them. Real-time data points are divided into multiple arrays according to the time of the requested data. These arrays are stored in a large dictionary, where the key of the dictionary is the requested time and the value is the data point array. Historical data points have only one measurement time and only need one array to store the data points. At each set time point, the program retrieves the corresponding array, assembles the parameters in the data points into the format required by the interface, and makes a data request.

12. The method for generating and displaying automatic inspection reports according to claim 1, characterized in that: Step four specifically involves the following steps: After data is requested, the program will first check if the cell model of the data point has any pre-defined operations or functions. If so, the returned data will be processed. For historical data, the latest requested data will also be updated in the configuration file to await the next retrieval. Then, the program will use a mapping table dictionary to index the obtained results and data points to improve the speed of subsequent queries. If no data is requested, the program will output an error and replace the original data with a default value. Finally, the program will locate the cell model to be written based on the index, and then write the data result and the string concatenated with the prefix and suffix into the corresponding cell model. After traversing all data points, the program will save and generate a report file, and the data will be displayed in real time on the configuration screen.

13. The method for generating and displaying automatic inspection reports according to claim 1, characterized in that: Step five specifically involves the automated monitoring system traversing all cell models in the configuration screen and generating report files that can be displayed and downloaded or database files that can be reused and stored, based on requirements. The report files retain the content and style of the configuration screen but delete the configuration information. The database files store all the data in the configuration screen to facilitate data recovery after a program crash or to run the same configuration screen on other devices.

Images