Substation maintenance data management method and management platform

Abstract

The invention provides a transformer substation maintenance data management method and management platform. The method comprises the following steps that a background server receives a data uploading request sent by a PC client; the background server verifies the data uploading request based on the PC terminal user login information and the PC terminal user permission information; if the verification of the data uploading request is passed, the background server receives an uploading data packet corresponding to the data packet linked list information, and stores the uploading data packet to a distributed storage database; the background server receives a data downloading request sent by the mobile client; the background server verifies the data downloading request in combination with the mobile terminal user login information, the local data type information and the local key data hash value; and if the verification of the data downloading request is passed, the background server pushes the corresponding target data packet to the mobile client based on the local data type information. The method has the effects of efficiently and safely storing and accessing the data.

Description

Technical Field

[0001] The invention belongs to the technical field of data storage management, and in particular relates to a substation maintenance data management method and a management platform. Background Art

[0002] With the rapid development of information technology, all walks of life have generated massive amounts of data that need to be managed and utilized. Especially in the complex industrial environment of the power system, there are many types of data that need to be processed and managed, especially equipment maintenance data. These maintenance data are not only huge in quantity, but also updated frequently, which places very high demands on the data management system. At the same time, the power system usually requires people from multiple departments and multiple roles to work together, so data sharing and secure access have become particularly important. In addition, with the popularity of mobile devices, field staff need to be able to access the required data anytime and anywhere, which requires the data management system to support the access of multiple terminal devices.

[0003] With the rapid increase in data volume and the increasing complexity of data types, traditional centralized storage methods have been unable to meet the needs of efficient processing and management. Secondly, in a multi-user, multi-device environment, how to ensure data consistency and security has become a challenge. In this context, traditional methods often have problems such as low efficiency and insufficient security in the process of data storage and access. Summary of the invention

[0004] The present invention provides a substation maintenance data management method and a management platform to solve the problems of low efficiency and insufficient security in the process of data storage and access.

[0005] In a first aspect, the present invention provides a substation maintenance data management method, which is applied to a maintenance data management platform, wherein the maintenance data management platform includes a background server, a distributed storage database and a client, wherein the client includes a PC client and a mobile client, wherein the background server is connected to the mobile client and the PC client through an intranet respectively, wherein the PC client is used to upload maintenance data through the background server, wherein the mobile client is used to download the maintenance data through the background server, wherein the background server is connected to the distributed storage database, wherein the distributed storage database is used to divide the maintenance data uploaded by the PC client into baseline data and incremental data and perform distributed storage, wherein the distributed storage database is further used to classify and store the baseline data according to the data type of the maintenance data; The method comprises the following steps: The backend server receives a data upload request sent by the PC client, wherein the data upload request includes PC user login information, PC user authority information and data packet linked list information; The backend server verifies the data upload request based on the PC user login information and the PC user authority information; If the data upload request is verified, the backend server receives the uploaded data packet corresponding to the data packet linked list information, and stores the uploaded data packet in the distributed storage database; The backend server receives a data download request sent by the mobile client, wherein the data download request includes mobile user login information, local data type information, and a local key data hash value; The backend server verifies the data download request in combination with the mobile user login information, the local data type information and the local key data hash value; If the data download request is verified to be successful, the backend server pushes the corresponding target data packet to the mobile client based on the local data type information.

[0006] Optionally, the backend server is deployed with a data fusion module, the data fusion module is connected to the distributed storage database, the data fusion module is deployed with a data cache area, the data cache area is used to store the data upload request, and before the backend server verifies the data upload request based on the PC user login information and the PC user authority information, the following steps are also included: The backend server obtains the server real-time indicator data and server time of the backend server at the current moment at each preset interval; If the backend server determines that the server state of the backend server is in an idle state according to the server real-time indicator, and the server time is in a preset idle time period, the backend server extracts a plurality of historical data upload requests from the data buffer area; The backend server determines a plurality of target time periods based on the historical timestamps of the historical data upload request, wherein the number of target historical timestamps included in each of the target time periods exceeds a preset number threshold; The backend server marks all the historical data upload requests corresponding to the target historical timestamps as target historical data upload requests; For each of the target time periods, the background server analyzes the historical data packet linked list information of all the target historical data upload requests in the target time period, and counts the upload frequencies of all different types of data packets in the target time period based on the historical data packet linked list information; The backend server screens the data packet types using the upload frequency, and generates target data packet linked list information corresponding to the target time period; The background server creates a baseline data pre-calling strategy for the data fusion module in combination with the target time period and the target data packet linked list information. The baseline data pre-calling strategy is: when the server time is in any of the target time period, the data fusion module retrieves the corresponding target baseline data from the distributed storage database to the data cache area based on the target data packet linked list information.

[0007] Optionally, the backend server filters the data packet types by using the upload frequency and generates the target data packet linked list information corresponding to the target time period, including the following steps: The backend server filters out the data packet types whose upload frequency is less than a preset frequency threshold, and obtains type information of all retained target data packet types; The backend server queries the distributed storage database to obtain the data memory of the baseline data corresponding to all the type information; The backend server sorts the baseline data corresponding to all the type information in the order of the data memory from small to large, and marks the sorted baseline data as target baseline data in sequence, until the sum of the data memory of all the target baseline data is greater than the difference between the storage upper limit of the data cache area and the preset reserved storage space; The background server generates target data packet linked list information corresponding to the target time period based on the header information of all the target baseline data.

[0008] Optionally, the background server is also deployed with a data distribution module, and the data distribution module is respectively connected to the data fusion module and the distributed storage database, the data distribution module stores the target data packet linked list information, and the data distribution module is used to receive the uploaded data packet corresponding to the data packet linked list information. The data distribution module is also used to distribute the uploaded data packet to the data fusion module or the distributed storage database in combination with the target data packet linked list information and the data packet linked list information.

[0009] Optionally, the backend server receives the uploaded data packet corresponding to the data packet linked list information, and stores the uploaded data packet in the distributed storage database, including the following steps: The backend server receives the uploaded data packet corresponding to the data packet linked list information through the data distribution module; The background server performs data matching analysis on the data packet linked list information and the target data packet linked list information through the data distribution module, and distributes the target maintenance data of the same type as the target baseline data in the uploaded data packet to the data fusion module according to the data matching analysis results, and distributes all other maintenance data in the uploaded data packet as the incremental data to the distributed storage database.

[0010] Optionally, the method further comprises the following steps: After the backend server distributes the target maintenance data of the same type as the target baseline data in the uploaded data packet to the data fusion module through the data distribution module and according to the data matching analysis result, the backend server fuses the target maintenance data of the matching type with the target baseline data through the data fusion module to obtain fused baseline data, and stores the fused baseline data in the distributed storage database.

[0011] Optionally, the server real-time indicator data includes real-time memory usage, real-time CPU usage, real-time disk I / O read and write data, real-time load average, real-time number of processes, real-time number of threads and real-time queue length.

[0012] Optionally, the backend server verifies the data download request in combination with the mobile user login information, the local data type information and the local key data hash value, including the following steps: The backend server verifies the mobile user login information; If the mobile user login information is verified, the backend server searches the data cache area for the target baseline data of the same type according to the local data type information; If the target baseline data of the same type is found in the data cache area according to the local data type information, the backend server extracts key baseline data from the target baseline data of the same type, and calculates a key baseline data hash value based on the key baseline data; If the target baseline data of the same type is not found in the data cache area according to the local data type information, the backend server searches the distributed storage database for the target baseline data of the same type according to the local data type information; The backend server extracts key baseline data from the target baseline data of the same type, and calculates a key baseline data hash value based on the key baseline data; If the key baseline data hash value is consistent with the local key data hash value, the backend server determines that the data download request verification fails; If the key baseline data hash value is inconsistent with the local key data hash value, the background server determines that the data download request verification is successful.

[0013] Optionally, the backend server pushes the corresponding target data packet to the mobile client based on the local data type information, including the following steps: If the backend server finds the target baseline data of the same type in the data cache area according to the local data type information, the backend server packages the target baseline data of the same type into a target data packet and pushes the target data packet to the mobile client; If the backend server finds the target baseline data of the same type in the distributed storage database according to the local data type information, the backend server packages the target baseline data of the same type into a target data packet and pushes the target data packet to the mobile client.

[0014] In the second aspect, the present invention also provides a substation maintenance data management platform, which is applied to the substation maintenance data management method described in the first aspect, the maintenance data management platform includes a background server, a distributed storage database and a client, the client includes a PC client and a mobile client, the background server is connected to the mobile client and the PC client through an intranet respectively, the PC client is used to upload maintenance data through the background server, the mobile client is used to download the maintenance data through the background server, the background server is connected to the distributed storage database, the distributed storage database is used to divide the maintenance data uploaded by the PC client into baseline data and incremental data and perform distributed storage, and the distributed storage database is also used to classify and store the baseline data according to the data type of the maintenance data.

[0015] The beneficial effects of the present invention are: The present invention adopts a distributed storage architecture, which greatly improves the efficiency of data processing and storage. By dividing the maintenance data into baseline data and incremental data, and storing them by data type, the data can be managed and accessed more flexibly, thereby improving the overall performance. Secondly, the present invention realizes the seamless connection between the PC and the mobile terminal, making the upload and download of data more convenient and greatly improving the work efficiency. Especially for on-site maintenance personnel, the required information can be obtained at any time, which greatly improves the flexibility and accuracy of the work. Furthermore, the present invention designs a strict authority verification mechanism, which not only verifies when uploading on the PC side, but also performs multiple verifications when downloading on the mobile terminal, greatly enhancing data security. At the same time, by using hash value comparison, data changes can be quickly identified, incremental updates can be achieved, unnecessary data transmission can be reduced, and network resources can be saved. In summary, the present invention not only improves data processing efficiency and enhances system security, but also greatly improves user experience, provides strong technical support for substation maintenance work, and is expected to significantly improve the operational efficiency and safety of substations. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a schematic diagram of the platform structure of the maintenance data management platform in one of the implementation modes of the present application.

[0017] Figure 2 This is a flow chart of a substation maintenance data management method in one of the implementation modes of the present application. DETAILED DESCRIPTION

[0018] The following will be combined with the drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of this application.

[0019] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0020] The substation maintenance data management method disclosed in the present invention is applied to the maintenance data management platform, and the architecture design of the platform fully considers the particularity and complexity of substation maintenance work. Figure 1 The maintenance data management platform consists of three parts: the background server, the distributed storage database and the client, forming a complete data management ecosystem. The client is divided into PC client and mobile client. This dual-end design meets the data operation requirements in different scenarios. The PC client is mainly used for data upload, which is suitable for use in an office environment and can handle a large amount of complex maintenance data. The mobile client is mainly used for data download, which is convenient for on-site maintenance personnel to obtain the required information at any time. Both clients are connected to the background server through the intranet, ensuring the security and stability of data transmission.

[0021] As the core of the entire system, the backend server undertakes the important functions of data processing, verification and distribution. It is closely connected with the distributed storage database to form an efficient data processing center. The backend server deploys two key modules: data fusion module and data distribution module. These two modules work together to greatly improve the efficiency and flexibility of data processing. The data fusion module is directly connected to the distributed storage database and is responsible for processing data upload requests from PC clients. It has a data cache area inside for temporary storage of data upload requests. This design can effectively alleviate the pressure during the peak period of data upload and ensure the stable operation of the system. The data fusion module not only processes the newly uploaded data, but also is responsible for fusing these data with the stored data to ensure the consistency and integrity of the data.

[0022] The data distribution module is a bridge connecting the data fusion module and the distributed storage database. It stores the target data packet linked list information, which is the data classification standard predefined by the system. When receiving the uploaded data packet, the data distribution module will compare and analyze the data packet linked list information and the target data packet linked list information, and decide whether to distribute the data to the data fusion module for further processing or directly store it in the distributed storage database. This intelligent distribution mechanism greatly improves the efficiency of data processing and reduces unnecessary data flow.

[0023] The distributed storage database is the data storage center of the entire system. It uses advanced distributed storage technology and can effectively process a large amount of maintenance data. An important feature of the database is that the maintenance data uploaded by the PC client is divided into baseline data and incremental data. Baseline data is usually relatively stable and long-term unchanged data, while incremental data is data that changes over time. This division method allows the system to manage and update data more efficiently. In addition, the distributed storage database will also classify and store baseline data according to the type of maintenance data. This classified storage method is conducive to the rapid retrieval and access to specific types of data, improving the efficiency of data management.

[0024] During the data upload process, the backend server first receives the data upload request sent by the PC client. This request contains the PC user login information, PC user permission information, and data packet list information. The backend server will perform strict verification based on the user login information and permission information to ensure that only authorized users can upload data, which greatly enhances the security of the system. After the verification is passed, the backend server will receive the uploaded data packet corresponding to the data packet list information. These data packets will then be stored in the distributed storage database.

[0025] In terms of data download, the background server will receive data download requests from mobile clients. This request contains mobile user login information, local data type information, and local key data hash values. The background server will verify this information to ensure the security of data download. In particular, the use of local key data hash values ​​can quickly determine whether the client's data needs to be updated, achieve incremental updates, and reduce data transmission. After verification, the background server will extract the corresponding target data packet from the distributed storage database based on the local data type information and push it to the mobile client. This on-demand push method not only ensures that the mobile client can obtain the latest maintenance data, but also avoids unnecessary data transmission, thereby improving the efficiency of the system.

[0026] Figure 2 FIG. 1 is a flow chart of a method for managing substation maintenance data in one embodiment. It should be understood that although Figure 2 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2At least part of the steps in the above method may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps. Figure 2 As shown, a substation maintenance data management method disclosed in the present invention specifically includes the following steps: S101. The backend server receives a data upload request sent by a PC client.

[0027] When the backend server receives the data upload request sent by the PC client, it first establishes a secure communication channel, usually using the HTTPS protocol to ensure the encryption of data transmission. During this process, the backend server will perform a TLS handshake, exchange encryption keys, and establish an encrypted session. This process includes the server sending its digital certificate to the client, the client verifying the validity of the certificate, and then the two parties negotiate a session key. Once the secure channel is established, the backend server begins to receive the specific content of the data upload request.

[0028] The received request contains three key parts: PC user login information, PC user permission information and data packet linked list information. User login information usually includes user name and encrypted password. The backend server will temporarily store this information in memory for use in the subsequent verification process. User permission information defines the scope of operations that the user can perform, such as what types of data can be uploaded, which databases can be accessed, etc. This information usually exists in the form of a permission code or permission list. Data packet linked list information is a structured data that contains detailed information about the data packets to be uploaded, such as the number of data packets, the size of each data packet, the data type, the checksum, etc. The backend server will parse this linked list information to prepare for subsequent data reception. For example, if the linked list information shows that 10 data packets will be uploaded, each packet size is 1MB, and the total data is 10MB, the backend server will pre-allocate 10MB of cache space. This preprocessing mechanism can significantly improve the efficiency of data reception and reduce data transmission interruptions caused by insufficient cache.

[0029] At the same time, the background server will prepare the corresponding data processing module in advance according to the data type in the linked list information, so that it can quickly process and store the data after receiving it. During the receiving process, the background server will also monitor the network status in real time. If the network connection is detected to be unstable, the background server will automatically adjust the data reception strategy, such as reducing the receiving rate or increasing the number of retransmissions of the data packet to ensure the integrity of the data. In addition, the background server will also record the relevant information of the data upload request, such as the request time, the request source IP, etc. Through this detailed and comprehensive request reception process, the background server can ensure the security and integrity of the data upload request, laying the foundation for subsequent data processing and storage. This method not only improves the security of the system, but also greatly improves the efficiency of data processing.

[0030] S102. The backend server verifies the data upload request based on the PC user login information and PC user authority information.

[0031] Among them, the backend server adopts a multi-level verification mechanism when verifying the data upload request to ensure the security and legitimacy of the data upload. First, the backend server checks the validity of the PC user's login information. This usually involves comparing the received username and encrypted password with the information stored in the database. To improve security, passwords are usually encrypted and stored using powerful hash algorithms such as bcrypt or Argon2. For example, if the bcrypt algorithm is used, the verification process may be as follows: the backend server first obtains the stored password hash value corresponding to the username from the database, and then uses bcrypt's compare function to compare the received password and the stored hash value. If the comparison result is true, the login information verification is passed.

[0032] If the login information is verified, the backend server will further check the user's permission information. A role-based access control (RBAC) model is adopted. In the RBAC model, each user is assigned one or more roles, and each role is given specific permissions. For example, a "senior maintenance engineer" role may have the right to upload all types of maintenance data, while a "junior maintenance engineer" role may only be able to upload some types of data. The backend server will match the user's role with the permissions required for the current operation. The process is as follows: the backend server first obtains the user's role information from the database, then obtains the permission list corresponding to the role, and then checks whether the permission list contains the permissions required for the current operation. If it does, the permission verification is passed.

[0033] In addition, the backend server will also check the user's login status, account status (whether it is locked or disabled), and other information. For example, the backend server may maintain a list of active sessions, check whether the user's session is in this list, and whether the session has expired. The entire verification process usually adopts multi-factor authentication, and also includes additional security measures such as verification codes and dynamic passwords. For example, for sensitive operations, the backend server may require the user to enter a one-time verification code sent via SMS. During the verification process, the backend server will record all verification steps and results, including verification time, verification results, and failure reasons (if any). These log information is very important for subsequent security audits and system optimization. If any step of the verification fails, the backend server will immediately terminate the verification process and return the corresponding error information to the PC client. At the same time, in order to prevent brute force cracking, the backend server may implement a limit on the number of login attempts. For example, if the same user fails to log in multiple times in a short period of time, the account will be temporarily locked. Through this strict and comprehensive verification mechanism, the backend server can effectively ensure that only legitimate users can upload data, greatly improving the security of the system. At the same time, this layered verification method also improves the flexibility of the system, making it easier for administrators to adjust permission settings according to actual needs.

[0034] S103. If the data upload request is verified to be successful, the background server receives the uploaded data packet corresponding to the data packet linked list information, and stores the uploaded data packet in the distributed storage database.

[0035] Among them, after the data upload request is verified, the background server starts to receive the upload data packet corresponding to the data packet linked list information. This process usually adopts the block transmission method to improve the transmission efficiency and reduce the transmission failure caused by network fluctuations. The background server will know the number of data packets to be received and the size of each packet based on the previously received data packet linked list information. During the receiving process, the background server will verify each data packet, usually using hash algorithms such as MD5 or SHA-256 to ensure the integrity of the data. The verification process is as follows: the background server first calculates the hash value of the received data packet, and then compares the calculated hash value with the hash value provided in the data packet linked list information. If the two are consistent, the data packet is complete; otherwise, the data packet is required to be retransmitted. If a data packet is found to be damaged or lost, the background server will ask the PC client to resend the data packet. This process may be repeated many times until all data packets are received correctly.

[0036] After receiving all the data packets, the backend server will assemble them into a complete data set. During the assembly process, the backend server will sort the data packets according to their sequence numbers to ensure the integrity and correctness of the data. Then, the backend server will store the data in the distributed storage database. During the storage process, the backend server will decide whether to store the data as baseline data or incremental data based on the type and characteristics of the data. Baseline data is a complete snapshot of the entire data set at a specific point in time, which represents the overall state of the system at a specific moment. Incremental data only contains data that has changed since the last data synchronization or backup, and it only contains newly added, modified, or deleted data records.

[0037] When storing, the background server will also add metadata to the data, such as upload time, upload user, data version, etc., for subsequent management and retrieval. These metadata are usually stored in a separate metadata table and associated with the actual data. In the distributed storage process, the background server will use certain strategies to determine the storage location of the data. Common strategies include: hash sharding (calculating the hash based on a key value of the data to determine the storage location), range sharding (determining the storage location based on the range of a certain attribute value of the data), and consistent hashing (using a consistent hashing algorithm to minimize data migration when nodes change). After storage is completed, the background server will back up the data, usually using a multi-copy strategy to copy the data to multiple nodes to improve data availability and fault tolerance.

[0038] Finally, the backend server updates the relevant indexes and caches to quickly retrieve the newly uploaded data. This process may involve multiple steps such as updating the database index, updating the search engine index, and updating the memory cache. Through this detailed and comprehensive data reception and storage process, the backend server can ensure the integrity, consistency, and availability of the data, providing a reliable foundation for subsequent data analysis and use. This approach not only improves the efficiency of data storage, but also enhances the reliability and scalability of the system, enabling the entire substation maintenance data management system to handle a large number of real-time data upload requests.

[0039] S104. The backend server receives the data download request sent by the mobile client.

[0040] When the backend server receives a data download request from a mobile client, it first establishes a secure communication channel, usually using the TLS / SSL encryption protocol to ensure the security of data transmission. This process includes the following steps: the backend server first receives the request message sent by the client, which contains a list of supported encryption algorithms and a random number; then the backend server responds to the request message, selects an encryption algorithm, and sends its own random number and digital certificate; then the client verifies the digital certificate of the backend server; after the verification is passed, the client generates a pre-master key, encrypts it with the public key of the backend server, and sends it to the backend server; then both parties use the random number and the pre-master key to generate a session key; finally, both parties exchange all information to confirm the establishment of the secure channel. After the secure channel is established, the backend server begins to receive data download requests.

[0041] The received data download request contains three key parts: mobile user login information, local data type information, and local key data hash value. Mobile user login information usually includes username and encrypted password. The backend server will temporarily store this information in memory for use in the subsequent verification process. To improve security, passwords are usually encrypted using powerful hash algorithms such as bcrypt or Argon2. Local data type information indicates the type of data that the mobile client needs to download, such as equipment maintenance records, equipment performance parameters, or fault diagnosis data. The backend server will determine which data needs to be retrieved from the distributed storage database based on this information. This information is usually parsed into one or more database query statements. The local key data hash value is a summary of the local data on the mobile client, usually generated using a hash algorithm such as SHA-256. The backend server will use this hash value to determine whether the data of the mobile client needs to be updated. This mechanism can greatly reduce unnecessary data transmission and improve system efficiency.

[0042] During the receiving process, the backend server will monitor the network status in real time. If the network connection is detected to be unstable, the backend server will take corresponding measures, such as adjusting the packet size, increasing the number of retransmissions, etc., to ensure the complete reception of the request. In addition, the backend server will also record the relevant information of the data download request, such as the request time, the request source IP, the requested data type, etc. This information will be used for subsequent audits, security analysis and system optimization. For example, by analyzing these logs, you can find the frequently requested data types, thereby optimizing data storage and caching strategies.

[0043] S105. The backend server verifies the data download request based on the mobile user login information, local data type information and local key data hash value.

[0044] Among them, the backend server adopts a multi-level verification mechanism when verifying the data download request to ensure the security and legitimacy of the data download. First, the backend server checks the validity of the mobile user's login information. This usually involves comparing the received username and encrypted password with the information stored in the authentication database. To improve security, passwords are usually encrypted and stored using a powerful hash algorithm such as bcrypt or Argon2. The verification process may be as follows: the backend server first obtains the stored password hash value corresponding to the username from the database, then hashes the received password using the same hash algorithm, and then compares the calculated hash value with the stored hash value. If the two are consistent, the login information verification is passed.

[0045] If the login information is verified, the backend server will analyze the local data type information to ensure that the requested data type is valid and exists in the system. This process includes: the backend server first parses the local data type information, extracts the specific data type, and then queries the system's data type directory to confirm whether the data type exists. If it exists, it further checks whether the data type can be downloaded. Then, the backend server uses the local key data hash value to determine whether data update is required. The backend server calculates the hash value of the latest data on the server side and compares it with the local key data hash value provided by the mobile client. This process may be as follows: the backend server first retrieves the latest data from the distributed storage database based on the data type information, and then uses the same hash algorithm as the client (usually SHA-256) to calculate the hash value of these data, and then compares the calculated hash value with the hash value provided by the client. If the two are different, it means that the data needs to be updated; if they are the same, the data transmission step can be skipped. This hash value-based incremental update mechanism can greatly reduce unnecessary data transmission and improve system efficiency.

[0046] S106. If the data download request is verified to be successful, the backend server pushes the corresponding target data packet to the mobile client based on the local data type information.

[0047] Among them, the background server will construct the corresponding database query statement according to the local data type information. For example, if the request is for the equipment maintenance records in the last month, the background server may construct the following SQL query: SELECT *FROM maintenance_records WHERE device_id = 'XXX' AND record_date >= DATE_SUB(CURDATE(), INTERVAL 1 MONTH) ORDER BY record_date DESC. When executing the query, the background server will use the characteristics of the distributed storage database, such as parallel query, shard query, etc., to improve the query efficiency. For example, if the database adopts a time-based sharding strategy, the query may only need to be executed on the most recent few shards instead of traversing the entire database. Then, the background server will filter out the incremental data that the mobile client really needs from the retrieved data. This is usually achieved by comparing the timestamp or version number of the data.

[0048] Next, the backend server will compress and encrypt these target data packets. Compression can use algorithms such as gzip, while encryption may use high-strength encryption algorithms such as AES-256. The process is as follows: the backend server first uses the gzip algorithm to compress the data to reduce the size of the data packet, then generates a random AES key, then uses the AES-256 algorithm and the generated key to encrypt the compressed data, and finally encrypts the AES key using the client's public key. The compressed and encrypted data packets will be divided into multiple small blocks, each of which is usually no larger than 1MB in size, to facilitate transmission in an unstable mobile network environment. The block division process is as follows: the backend server first divides the encrypted data into blocks of a fixed size (such as 1MB), then generates a unique identifier and sequence number for each block, and finally creates a block information list containing the identifier, sequence number, and size of each block.

[0049] Finally, the background server will push these data blocks to the mobile client in sequence and monitor the network status in real time during the transmission process. If the network is found to be unstable, the background server will automatically adjust the transmission strategy, for example: reduce the transmission rate to reduce the probability of data packet loss; increase the number of data packet retransmissions to ensure data integrity; if a network interruption is detected, suspend the transmission and save the current status, and continue the transmission after the network is restored. During the push process, the background server will also maintain a transmission status table to record the transmission status of each data block. If a data block fails to be transmitted, the server can retransmit only the block without retransmitting the entire data packet. After the transmission is completed, the background server will ask the mobile client to return a confirmation message containing the hash value of the received data. The server will verify this hash value to ensure that the data is received intact.

[0050] In one embodiment, the backend server is deployed with a data fusion module, the data fusion module is connected to the distributed storage database, the data fusion module is deployed with a data cache area, the data cache area is used to store data upload requests, and before the backend server verifies the data upload request based on the PC user login information and the PC user authority information, the following steps are also included: The backend server obtains the server real-time indicator data and server time of the backend server at the current moment at each preset interval; If the backend server determines that the server state of the backend server is in an idle state according to the server real-time indicator, and the server time is in a preset idle time period, the backend server extracts multiple historical data upload requests from the data cache area; The backend server determines multiple target time periods based on the historical timestamps of the historical data upload request, and the number of target historical timestamps included in each target time period exceeds a preset number threshold; The backend server marks all historical data upload requests corresponding to the target historical timestamps as target historical data upload requests; For each target time period, the backend server analyzes the historical data packet linked list information of all target historical data upload requests in the target time period, and counts the upload frequencies of all different types of data packets in the target time period based on the historical data packet linked list information; The backend server uses the upload frequency to filter the data packet type and generates a target data packet linked list information corresponding to the target time period; The background server creates a baseline data pre-retrieval strategy for the data fusion module based on the target time period and the target data packet linked list information. The baseline data pre-retrieval strategy is: when the server time is in any target time period, the data fusion module retrieves the corresponding target baseline data from the distributed storage database to the data cache area based on the target data packet linked list information.

[0051] In this embodiment, the server real-time indicator data includes real-time memory usage, real-time CPU usage, real-time disk I / O read and write data, real-time load average, real-time number of processes, real-time number of threads and real-time queue length.

[0052] In one implementation manner, the backend server uses the upload frequency to filter the data packet type and generates the target data packet linked list information corresponding to the target time period, including the following steps: The backend server filters out the data packet types whose upload frequency is less than the preset frequency threshold, and obtains the type information of all retained target data packet types; The backend server queries the distributed storage database to obtain the data memory corresponding to the baseline data of all types of information; The backend server sorts the baseline data corresponding to all types of information in order from small to large data memory, and marks the sorted baseline data as target baseline data in sequence, until the sum of the data memory of all target baseline data is greater than the difference between the storage upper limit of the data cache area and the preset reserved storage space; The background server generates target data packet linked list information corresponding to the target time period based on the header information of all target baseline data.

[0053] In this embodiment, the background server obtains the server real-time indicator data and server time of the background server at the current moment at each preset interval. In this step, the background server will periodically execute a system monitoring task, usually every 1 minute or 5 minutes. This task will call various system monitoring interfaces provided by the operating system to collect real-time operation status data of the server. Specifically, the background server will obtain the real-time memory usage rate, which is usually expressed as a percentage and reflects the current memory usage; the real-time CPU usage rate, which is also expressed as a percentage and reflects the busyness of the CPU; the real-time disk I / O read and write data, which is usually measured in bytes read and written per second or IOPS (input / output operations per second); the real-time load average, which is a comprehensive indicator that reflects the average load of the system in the past 1 minute, 5 minutes and 15 minutes; the real-time number of processes and the real-time number of threads, these two indicators reflect the number of processes and threads currently running in the system; and the real-time queue length, which indicates the number of processes currently waiting for CPU processing. At the same time, the background server will also obtain the current server time, accurate to the second or millisecond level.

[0054] The backend server determines whether the server status of the backend server is in an idle state and whether the server time is in a preset idle time period based on the server real-time indicators. In this step, the backend server will first analyze the server real-time indicator data collected in the previous step. It will compare these indicators with the preset thresholds to determine whether the server is in an idle state. For example, the backend server may check whether the real-time CPU usage is less than 30%, whether the real-time memory usage is less than 50%, whether the real-time disk I / O is less than 1000IOPS, whether the real-time load average is less than 50% of the number of system CPU cores, etc. If all these indicators are lower than their respective thresholds, the backend server will consider itself to be in an idle state. At the same time, the backend server will also check whether the current server time falls within the preset idle time period. This idle time period is usually set by the system administrator based on business characteristics and historical data analysis, such as 2 am to 5 am every day. Only when the server status is determined to be idle and the current time is within the preset idle time period will the backend server perform subsequent operations.

[0055] The backend server determines multiple target time periods based on the historical timestamps of the historical data upload requests, and the number of target historical timestamps contained in each target time period exceeds the preset quantity threshold. In this step, the backend server first performs time analysis on the historical data upload requests extracted from the data cache. Each historical data upload request contains a historical timestamp, which indicates the specific time when the request was submitted. The backend server sorts and groups these timestamps to determine the time distribution pattern of the data upload requests. Specifically, the backend server may group the timestamps by hour or day to form multiple time periods. Then, the backend server counts the number of requests in each time period and compares this number with the preset quantity threshold. This preset quantity threshold may be based on the system's processing capacity and historical data analysis, for example, it may be set to 100 or 1000. Only those time periods in which the number of requests exceeds the threshold will be marked as target time periods. In this way, the backend server can identify the peak period of historical data upload requests, providing an important reference for subsequent data processing.

[0056] The backend server marks all historical data upload requests corresponding to the target historical timestamp as target historical data upload requests. In this step, the backend server will traverse all previously determined target time periods and find all historical data upload requests that fall within these time periods. For each such request, the backend server will add a special tag to its metadata to identify it as a target historical data upload request. This tag may be a simple Boolean value, or a more complex identifier that includes additional data such as time period information. The purpose of the tag is to be able to quickly identify and prioritize these requests in subsequent processing.

[0057] For each target time period, the background server analyzes the historical data packet linked list information of all target historical data upload requests in the target time period, and counts the upload frequency of all different types of data packets in the target time period based on the historical data packet linked list information. In this step, the background server will conduct an in-depth analysis of the target historical data upload requests in each target time period. First, the background server will extract the historical data packet linked list information in each request. This linked list information usually contains detailed information such as the type, size, and sequence number of each data packet. Then, the background server will classify and count this information, and calculate the number of uploads of each type of data packet in the time period. Specifically, a hash table can be used to quickly count the number of occurrences of each type. After the statistics are completed, the background server will obtain a list of all data packet types and their corresponding upload frequencies.

[0058] The backend server will filter out the data packet types whose upload frequency is less than the preset frequency threshold, and obtain the type information of all retained target data packet types. In this step, the backend server will further filter the data packet types and their upload frequencies obtained in the previous step. The backend server will set a preset frequency threshold, such as 100 times / hour. Then, the backend server will traverse all data packet types and remove those types with upload frequencies lower than this threshold from the list. The purpose of this is to focus on the most frequently uploaded data types. For those retained data packet types, the backend server will extract their type information, which includes detailed descriptions of the format, structure, and purpose of the data packet.

[0059] The backend server queries the distributed storage database to obtain the data memory of the baseline data corresponding to all types of information. In this step, the backend server will initiate a query request to the distributed storage database based on the target data packet type information retained in the previous step. The purpose of this query is to obtain the memory size occupied by the baseline data corresponding to each target data packet type. The backend server uses SQL or NoSQL query language to construct appropriate query statements according to the specific type and structure of the database. This query returns the total size of the baseline data of each data type. Next, the backend server will first sort the memory size of the baseline data obtained in the previous step, and use efficient algorithms such as quick sort or merge sort to arrange the data from small to large. Then, the backend server will mark these baseline data as target baseline data in sequence, starting from the smallest. In this process, the backend server will maintain a cumulative sum, which represents the total memory size of the marked target baseline data. The backend server will continuously compare this cumulative sum with a specific value: the storage upper limit of the data cache minus the preset reserved storage space. When the cumulative sum exceeds this specific value for the first time, the marking process will stop. The purpose of this is to reserve enough space in the data cache to store this important baseline data, while also retaining some space for other uses.

[0060] The background server generates the target data packet linked list information corresponding to the target time period based on the header information of all target baseline data. In this step, the background server processes all the target baseline data marked in the previous step. For each target baseline data, the background server extracts its header information, including key metadata such as data type, size, version number, etc. Then, the background server organizes these header information into a structured linked list. Each node in this linked list represents a target baseline data and contains key descriptive information of the data. The order of the linked list may be arranged according to the importance or access frequency of the data. The purpose of generating this linked list is to be able to quickly locate and obtain the required baseline data in the subsequent data prefetching process.

[0061] Next, the background server will combine the target time period determined in the previous step with the generated target data packet linked list information to create an intelligent baseline data pre-retrieval strategy. The core idea of ​​this strategy is to load the most needed baseline data into a fast-access cache in advance before the system enters the predicted peak period. Specifically, the background server will set a scheduled task to continuously check whether the current server time falls into any target time period. Once the time matches, the data fusion module will be triggered. It will batch read the corresponding target baseline data from the distributed storage database according to the target data packet linked list information corresponding to the time period, and store this data in the data cache. Through this pre-retrieval strategy, the system can prepare the most commonly used data before the peak period arrives, greatly reducing the delay in real-time data access.

[0062] This approach not only improves the system's response speed, but also reduces the access pressure on the distributed storage database during peak hours. The backend server will regularly evaluate the effectiveness of this pre-retrieval strategy and may dynamically adjust the strategy based on the actual data access pattern to ensure the effectiveness of the strategy and the optimal use of system resources. For example, if it is found that some pre-retrieved data is actually rarely accessed, the backend server may remove this data from the pre-retrieval list when the policy is updated next time. On the contrary, if it is found that some frequently accessed data is not pre-retrieved, the backend server will add this data to the pre-retrieval list. Through this continuous optimization process, the backend server can continuously improve the accuracy and efficiency of data pre-retrieval, thereby significantly improving the performance of the entire system and user experience.

[0063] In one of the embodiments, the background server is also deployed with a data distribution module, which is connected to the data fusion module and the distributed storage database respectively. The data distribution module stores the target data packet linked list information. The data distribution module is used to receive the uploaded data packet corresponding to the data packet linked list information. The data distribution module is also used to distribute the uploaded data packet to the data fusion module or the distributed storage database in combination with the target data packet linked list information and the data packet linked list information.

[0064] The backend server receives the uploaded data packet corresponding to the data packet linked list information, and stores the uploaded data packet in the distributed storage database, including the following steps: the backend server receives the uploaded data packet corresponding to the data packet linked list information through the data distribution module; The background server performs data matching analysis on the data packet linked list information and the target data packet linked list information through the data distribution module. According to the data matching analysis results, the target maintenance data of the same type as the target baseline data in the uploaded data packet is distributed to the data fusion module, and all other maintenance data in the uploaded data packet is distributed as incremental data to the distributed storage database.

[0065] After the background server distributes the target maintenance data of the same type as the target baseline data in the uploaded data packet to the data fusion module through the data distribution module and according to the data matching analysis results, the background server fuses the type-matched target maintenance data with the target baseline data through the data fusion module to obtain fused baseline data, and stores the fused baseline data in the distributed storage database.

[0066] In this embodiment, the background server receives the upload data packet corresponding to the data packet linked list information through the data distribution module. In this step, the background server first activates its data distribution module and prepares to receive the upload data packet from the PC client. The data distribution module will establish a secure network connection, usually using the HTTPS protocol, to ensure the security of data transmission. When the upload data packet begins to be transmitted, the data distribution module of the background server will pre-allocate appropriate memory space to store these data packets based on the previously received data packet linked list information. The data packet linked list information usually includes metadata such as the size, type, and sequence number of each data packet, which enables the background server to efficiently manage the receiving process.

[0067] The backend server performs data matching analysis on the data packet linked list information and the target data packet linked list information through the data distribution module. According to the data matching analysis results, the target maintenance data of the same type as the target baseline data in the uploaded data packet is distributed to the data fusion module, and all other maintenance data in the uploaded data packet are distributed as incremental data to the distributed storage database. In this step, the data distribution module of the backend server first loads the pre-stored target data packet linked list information. Then the data packet linked list information just received is compared with the target data packet linked list information. This comparison process can use the KMP algorithm or regular expressions to quickly identify the same or similar data types. For each uploaded data packet, the backend server checks whether its type matches the type of the target baseline data. If the match is successful, the backend server marks the data packet as the target maintenance data and routes it to the data fusion module. For those data packets that do not match the target baseline data type, the backend server marks them as incremental data and routes them directly to the distributed storage database.

[0068] The backend server fuses the target maintenance data with the target baseline data of matching types through the data fusion module to obtain the fused baseline data, and stores the fused baseline data in the distributed storage database. In this step, the data fusion module of the backend server first retrieves the target baseline data that matches the target maintenance data type from the data cache. Then the data fusion algorithm is started, which varies according to the data type. For example, for numerical data, the fusion process may involve algorithms such as weighted average or Kalman filtering; for text data, natural language processing technology may be used to merge information; for image data, computer vision algorithms may be applied to integrate features. During the fusion process, the backend server will consider factors such as the timestamp and credibility of the data to ensure the accuracy and timeliness of the fusion results. After the fusion is completed, the backend server will generate new fused baseline data. The fusion operation can clear useless historical data in the baseline data, reduce the number of data files, and also optimize the user's reading performance. Next, the backend server will store these fused baseline data in the distributed storage database.

[0069] In one embodiment, the substation maintenance data management method further includes the following steps: When the backend server detects that the number of times the data fusion module executes the data fusion step reaches a preset number threshold, the backend server creates a data consistency check task based on all baseline data in the distributed storage database, and the data consistency check task is used to verify the fused baseline data; When the data download request is verified, the backend server obtains the real-time device performance data and real-time device status data corresponding to all mobile clients; The backend server combines the real-time device performance data and the real-time device status data to split the data consistency check task, and distributes the split data consistency check task to the mobile client; The backend server obtains the inspection result fed back by the mobile client after executing the data consistency check task; The backend server combines all the inspection results to complete the data verification process of all baseline data in the distributed storage database.

[0070] In this embodiment, the background server monitors the number of times the data fusion module executes the data fusion step. When the preset number threshold is reached, a data consistency check task is created based on all baseline data in the distributed storage database. This process involves the maintenance of counters and threshold comparisons. After reaching the threshold, the background server will traverse all baseline data tables in the distributed storage database and generate a check task for each table. These tasks may include data integrity checks, consistency checks, and version checks. The background server organizes these tasks into a task queue for subsequent distribution and execution. Through this mechanism, the background server can regularly verify the quality of the data to ensure that no errors or inconsistencies are introduced during the fusion process.

[0071] After the data download request is verified, the backend server obtains the real-time device performance data and real-time device status data of all relevant mobile clients. Specifically, it first determines which mobile clients are related to this data download, which may be based on factors such as user group, device type, or geographic location. Then, the backend server sends data requests to these clients, asking them to report the latest device performance and status data. This data may include CPU usage, memory usage, network connection status, battery power, etc. The backend server uses asynchronous communication to collect this data in parallel to improve efficiency. The received data will be temporarily stored and standardized in preparation for subsequent task allocation.

[0072] The backend server combines real-time device performance data and real-time device status data to split the data consistency check task and distribute the split tasks to mobile clients. Specifically, the performance and status data of each client are first analyzed to evaluate its processing capabilities. For example, devices with sufficient power and low CPU usage may be assigned more tasks. Then, the backend server splits the overall inspection task into multiple subtasks, each of which is responsible for checking a part of the data. The splitting strategy may be based on a comprehensive consideration of data volume, complexity, and client capabilities. The backend server generates a unique identifier for each subtask and packages information such as the task description and the data range to be checked. Finally, it distributes these subtasks to the corresponding mobile clients through a secure channel.

[0073] The backend server obtains the inspection results fed back by the mobile client after executing the data consistency check task. Specifically, a listener is set for each distributed subtask to wait for the client's response. When receiving the response, the backend server first verifies the integrity and authenticity of the response, possibly using mechanisms such as digital signatures. Then, it parses and stores each inspection result into a temporary result set. This result set is a distributed data structure, such as a distributed hash table, to efficiently handle a large number of concurrent results. The backend server tracks the completion status of each subtask. If a task times out and does not respond, it may reallocate the task to other clients. This step ensures that all distributed tasks can be processed, improving the reliability of the overall inspection.

[0074] The background server combines all the inspection results to complete the data verification process for all baseline data in the distributed storage database. Specifically, the inspection results of all subtasks are first summarized, and parallel processing technologies such as MapReduce may be used to accelerate this process. Then, the background server compares the summary results with the original baseline data to check for inconsistencies or errors. For data that has passed the verification, the background server will update its metadata, such as the last verification time. Finally, it may generate an overall verification report, including statistical information such as verification coverage and the number of problems found. This step ensures the accuracy and consistency of the baseline data in the distributed storage, providing a reliable guarantee for subsequent data use.

[0075] In one embodiment, the backend server verifies the data download request in combination with the mobile user login information, the local data type information and the local key data hash value, including the following steps: The backend server verifies the mobile user's login information; If the mobile user login information is verified, the backend server queries the data cache for target baseline data of the same type based on the local data type information; If the same type of target baseline data is found in the data cache according to the local data type information, the backend server extracts the key baseline data from the same type of target baseline data and calculates the key baseline data hash value based on the key baseline data; If the target baseline data of the same type is not found in the data cache according to the local data type information, the backend server searches for the target baseline data of the same type in the distributed storage database according to the local data type information; The backend server extracts key baseline data from target baseline data of the same type, and calculates a key baseline data hash value based on the key baseline data; If the key baseline data hash value is consistent with the local key data hash value, the backend server determines that the data download request verification has failed; If the key baseline data hash value is inconsistent with the local key data hash value, the backend server determines that the data download request verification is successful.

[0076] In this embodiment, the backend server verifies the mobile user login information. In this step, the backend server first receives the user login information from the mobile terminal, which usually includes a username and an encrypted password. The backend server uses a secure communication protocol, such as HTTPS, to ensure that these sensitive information will not be eavesdropped or tampered with during transmission. After receiving the login information, the backend server will perform a series of verification steps. First, it will check whether the username exists in the user database. If the username exists, the backend server will take out the stored password hash value associated with the username. Then, the backend server will hash the received password using the same encryption algorithm (such as bcrypt or Argon2) and compare the result with the stored hash value. If the two match, the password verification is considered to be passed. In addition, the backend server may also check other security factors, such as whether the account is locked, whether secondary verification is required, etc. If all verification steps are passed, the backend server will generate a session token and return it to the mobile terminal for subsequent communication.

[0077] The backend server queries the data cache for target baseline data of the same type based on the local data type information. In this step, the backend server first parses the local data type information received from the mobile terminal. This information is usually an identifier or descriptor used to indicate the data type required by the mobile terminal. The backend server converts this information into a data type identifier for internal use. Then, the backend server accesses the data cache and uses optimized search algorithms, such as hash table search or B-tree search, to quickly locate possible target baseline data. During the query process, the backend server may use a multi-level cache strategy, first checking the fastest first-level cache, and if not found, then searching the next level cache level by level. If matching target baseline data is found in any first-level cache, the backend server records the result and prepares for the next step. This cache query mechanism greatly improves the speed of data access and reduces access to slower storage databases, thereby improving the response performance of the entire system.

[0078] The backend server extracts key baseline data from the target baseline data of the same type and calculates the key baseline data hash value based on the key baseline data. In this step, the backend server traverses the target baseline data and extracts the key parts according to these rules. For example, for equipment maintenance records, key baseline data may include equipment ID, last maintenance date, and key performance parameters. After the extraction is completed, the backend server organizes these key data into a structured format. Next, the backend server uses a cryptographic hash algorithm, such as SHA-256, to hash this structured key baseline data. This process generates a fixed-length hash value that uniquely represents the current state of the key baseline data. In this way, the backend server can generate a compact but highly recognizable data fingerprint that can be used to quickly determine whether the data has changed.

[0079] The backend server queries the distributed storage database for target baseline data of the same type based on the local data type information. In this step, if the previous query in the data cache does not find matching data, the backend server will turn to the distributed storage database for query. The backend server will first construct a query request, which contains the local data type information and possible other query parameters. Then, the backend server will send this request to the distributed storage database system. In a distributed environment, this query will be distributed to multiple data nodes for parallel execution to improve query efficiency. Each data node will search for target baseline data that meets the conditions in its own data shard. The query process involves query optimization techniques, such as bitmap indexes or columnar storage. When all nodes complete the search, the results will be aggregated to a coordination node. The backend server will receive the query results from this coordination node and perform necessary post-processing on the results, such as sorting or filtering. Through this distributed query method, the backend server can efficiently locate the required information in massive data.

[0080] The backend server extracts key baseline data from target baseline data of the same type and calculates the key baseline data hash value based on the key baseline data. This step is similar to the previous operation when querying data in the cache, but it processes data obtained from the distributed storage database. The backend server traverses the target baseline data obtained from the database and extracts this key information.

[0081] The backend server will compare the key baseline data hash value just calculated with the local key data hash value sent by the mobile terminal. If the two hash values ​​are exactly the same, it means that the local data on the mobile terminal is no different from the latest baseline data on the server, that is, the data on the mobile terminal is already the latest. In this case, the backend server will make a "verification failure" judgment. "Failure" here does not mean an error, but means that data download is not required. The backend server will generate a special response message to inform the mobile terminal that the current data is already the latest and does not need to be updated. This response message may contain a status code (such as "304 Not Modified") and some metadata, such as the verification timestamp. At the same time, the backend server will record the results of this verification in the log, including user ID, data type, verification time and other information, which can be used for subsequent system optimization and problem diagnosis. Through this mechanism, the backend server can avoid unnecessary data transmission, save network bandwidth and storage space of mobile devices, and also reduce the load on the server. This intelligent verification mechanism greatly improves the efficiency and user experience of the entire system.

[0082] If the key baseline data hash value is inconsistent with the local key data hash value, it means that there is a difference between the local data of the mobile terminal and the latest baseline data of the server, that is, the data of the mobile terminal needs to be updated. In this case, the backend server will make a "verification passed" judgment. This "pass" means that the backend server recognizes the rationality of the data update request of the mobile terminal. Next, the backend server will prepare the relevant processes for data download. First, a session token is generated for the identity authentication of the subsequent data transmission process. At the same time, the backend server will start to prepare the data packet to be downloaded. This may involve data screening, compression and encryption. The backend server will also generate a response message to inform the mobile terminal that the verification has passed, and contains some meta information, such as the estimated data packet size, recommended download method, etc. This information can help the mobile terminal prepare to receive data. At the same time, the backend server will record this verification and the upcoming data download operation in the system log, including user ID, data type, verification time, data size and other information.

[0083] In one implementation manner, the backend server pushes the corresponding target data packet to the mobile client based on the local data type information, including the following steps: If the backend server finds the same type of target baseline data in the data cache according to the local data type information, the backend server packages the same type of target baseline data into a target data packet and pushes the target data packet to the mobile client; If the background server finds the same type of target baseline data in the distributed storage database according to the local data type information, the background server packages the same type of target baseline data into a target data packet and pushes the target data packet to the mobile client.

[0084] In this embodiment, the backend server queries the target baseline data of the same type in the data cache according to the local data type information, and then packages the target baseline data of the same type into a target data packet, and pushes the target data packet to the mobile client. In this step, the backend server first confirms that the target baseline data matching the local data type requested by the mobile terminal has been successfully found in the data cache. Next, the backend server will start the data packaging process. The packaging process first serializes the target baseline data into a common data exchange format, such as JSON or Protocol Buffers. This serialization process ensures the compatibility of data between different systems. Then, the backend server may compress the data, using algorithms such as gzip or zlib to reduce the amount of data transmission. If the data contains sensitive information, the backend server will also encrypt the data using an encryption algorithm (such as AES). The encryption process usually uses a session key, which has been negotiated with the mobile client in the previous authentication phase. After packaging is completed, the backend server will generate a data packet header containing metadata such as data packet size, data type, version number, etc. Finally, the backend server will combine the data packet header and the encrypted and compressed data body into a complete target data packet.

[0085] The backend server queries the target baseline data of the same type in the distributed storage database based on the local data type information, then packages the target baseline data of the same type into a target data packet, and pushes the target data packet to the mobile client. In this step, the backend server first confirms that no matching data is found in the data cache, so it needs to retrieve data from the distributed storage database. This process involves distributed query operations, and the backend server may use distributed computing frameworks such as MapReduce or Spark to execute queries. The query request will be distributed to multiple data nodes, and each node is responsible for searching the data shards stored in it. After the query results are aggregated from each node, the backend server will perform necessary post-processing on the data, such as deduplication, sorting, or filtering.

[0086] Once the target baseline data is obtained, the background server begins the data packaging process. First, the server converts the data into a standardized format, such as using a data serialization system such as Apache Avro or Thrift. This ensures the interoperability of data between different systems. Then, the background server compresses the data, possibly using a high-performance compression algorithm such as Snappy or LZ4 to reduce the data volume while maintaining a fast decompression speed. After packaging, the background server generates a detailed data packet header containing meta information such as data packet size, checksum, data format version, etc. This information is critical for the client to correctly parse the data packet. In the push phase, the background server may use communication protocols such as WebSocket or gRPC, which can provide two-way real-time communication capabilities. The server will split the data packet into multiple frames or messages for transmission, and the size of each frame is usually between 1KB and 16KB to balance transmission efficiency and network friendliness.

[0087] The present invention also discloses a substation maintenance data management platform, which includes a background server, a distributed storage database and a client, the client includes a PC client and a mobile client, the background server is connected to the mobile client and the PC client through an intranet respectively, the PC client is used to upload maintenance data through the background server, the mobile client is used to download maintenance data through the background server, the background server is connected to the distributed storage database, the distributed storage database is used to divide the maintenance data uploaded by the PC client into baseline data and incremental data and perform distributed storage, and the distributed storage database is also used to classify and store the baseline data according to the data type of the maintenance data.

[0088] The backend server is deployed with a data fusion module, which is connected to the distributed storage database. The data fusion module is deployed with a data cache area, which is used to store data upload requests. The backend server is also deployed with a data distribution module, which is connected to the data fusion module and the distributed storage database respectively. The data distribution module stores target data packet linked list information. The data distribution module is used to receive the uploaded data packet corresponding to the data packet linked list information. The data distribution module is also used to distribute the uploaded data packet to the data fusion module or the distributed storage database in combination with the target data packet linked list information and the data packet linked list information.

[0089] A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of protection of the present application is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of different aspects of one or more embodiments of the present application as above, which are not provided in detail for the sake of simplicity.

[0090] One or more embodiments of the present application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the present application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present application should be included in the protection scope of the present application.

Claims

1. A substation maintenance data management method, characterized in that: Applied to a maintenance data management platform, the maintenance data management platform includes a background server, a distributed storage database and a client, the client includes a PC client and a mobile client, the background server is connected to the mobile client and the PC client through an intranet respectively, the PC client is used to upload maintenance data through the background server, the mobile client is used to download the maintenance data through the background server, the background server is connected to the distributed storage database, the distributed storage database is used to divide the maintenance data uploaded by the PC client into baseline data and incremental data and perform distributed storage, and the distributed storage database is also used to classify and store the baseline data according to the data type of the maintenance data; The method comprises the following steps: The backend server receives a data upload request sent by the PC client, wherein the data upload request includes PC user login information, PC user authority information and data packet linked list information; The backend server verifies the data upload request based on the PC user login information and the PC user authority information; If the data upload request is verified to be successful, the backend server receives the uploaded data packet corresponding to the data packet linked list information, and stores the uploaded data packet in the distributed storage database; The backend server receives a data download request sent by the mobile client, wherein the data download request includes mobile user login information, local data type information and local key data hash value; The backend server verifies the data download request in combination with the mobile user login information, the local data type information and the local key data hash value; If the data download request is verified to be successful, the backend server pushes the corresponding target data packet to the mobile client based on the local data type information.

2. The substation maintenance data management method according to claim 1, characterized in that: The backend server is deployed with a data fusion module, the data fusion module is connected to the distributed storage database, the data fusion module is deployed with a data cache area, the data cache area is used to store the data upload request, and before the backend server verifies the data upload request based on the PC user login information and the PC user authority information, the following steps are also included: The backend server obtains the server real-time indicator data and server time of the backend server at the current moment at each preset interval; If the backend server determines that the server state of the backend server is in an idle state according to the server real-time indicator, and the server time is in a preset idle time period, the backend server extracts a plurality of historical data upload requests from the data buffer area; The backend server determines a plurality of target time periods based on the historical timestamps of the historical data upload request, wherein the number of target historical timestamps included in each of the target time periods exceeds a preset number threshold; The backend server marks all the historical data upload requests corresponding to the target historical timestamps as target historical data upload requests; For each of the target time periods, the background server analyzes the historical data packet linked list information of all the target historical data upload requests in the target time period, and counts the upload frequencies of all different types of data packets in the target time period based on the historical data packet linked list information; The backend server screens the data packet types using the upload frequency, and generates target data packet linked list information corresponding to the target time period; The background server creates a baseline data pre-calling strategy for the data fusion module in combination with the target time period and the target data packet linked list information. The baseline data pre-calling strategy is: when the server time is in any of the target time period, the data fusion module retrieves the corresponding target baseline data from the distributed storage database to the data cache area based on the target data packet linked list information.

3. The substation maintenance data management method according to claim 2, characterized in that: The backend server uses the upload frequency to filter the data packet type and generates the target data packet linked list information corresponding to the target time period, including the following steps: The backend server filters out the data packet types whose upload frequency is less than a preset frequency threshold, and obtains type information of all retained target data packet types; The backend server queries the distributed storage database to obtain the data memory of the baseline data corresponding to all the type information; The backend server sorts the baseline data corresponding to all the type information in ascending order of the data memory, and marks the sorted baseline data as target baseline data in sequence, until the sum of the data memory of all the target baseline data is greater than the difference between the storage upper limit of the data cache area and the preset reserved storage space; The background server generates target data packet linked list information corresponding to the target time period based on the header information of all the target baseline data.

4. The substation maintenance data management method according to claim 2, characterized in that: The background server is also deployed with a data distribution module, and the data distribution module is connected to the data fusion module and the distributed storage database respectively. The data distribution module stores the target data packet linked list information. The data distribution module is used to receive the uploaded data packet corresponding to the data packet linked list information. The data distribution module is also used to distribute the uploaded data packet to the data fusion module or the distributed storage database in combination with the target data packet linked list information and the data packet linked list information.

5. The substation maintenance data management method according to claim 4, characterized in that: The backend server receives the uploaded data packet corresponding to the data packet linked list information, and stores the uploaded data packet in the distributed storage database, including the following steps: The backend server receives the uploaded data packet corresponding to the data packet linked list information through the data distribution module; The background server performs data matching analysis on the data packet linked list information and the target data packet linked list information through the data distribution module, and distributes the target maintenance data of the same type as the target baseline data in the uploaded data packet to the data fusion module according to the data matching analysis results, and distributes all other maintenance data in the uploaded data packet as the incremental data to the distributed storage database.

6. The substation maintenance data management method according to claim 5, characterized in that: The method further comprises the steps of: After the backend server distributes the target maintenance data of the same type as the target baseline data in the uploaded data packet to the data fusion module through the data distribution module and according to the data matching analysis result, the backend server fuses the target maintenance data of the matching type with the target baseline data through the data fusion module to obtain fused baseline data, and stores the fused baseline data in the distributed storage database.

7. The substation maintenance data management method according to claim 2, characterized in that: The server real-time indicator data includes real-time memory usage, real-time CPU usage, real-time disk I / O read and write data, real-time load average, real-time number of processes, real-time number of threads and real-time queue length.

8. The substation maintenance data management method according to claim 2, characterized in that: The backend server verifies the data download request by combining the mobile user login information, the local data type information and the local key data hash value, including the following steps: The backend server verifies the mobile user login information; If the mobile user login information is verified, the backend server searches the data cache area for the target baseline data of the same type according to the local data type information; If the target baseline data of the same type is found in the data cache area according to the local data type information, the backend server extracts key baseline data from the target baseline data of the same type, and calculates a key baseline data hash value based on the key baseline data; If the target baseline data of the same type is not found in the data cache area according to the local data type information, the backend server searches the distributed storage database for the target baseline data of the same type according to the local data type information; The backend server extracts key baseline data from the target baseline data of the same type, and calculates a key baseline data hash value based on the key baseline data; If the key baseline data hash value is consistent with the local key data hash value, the backend server determines that the data download request verification fails; If the key baseline data hash value is inconsistent with the local key data hash value, the background server determines that the data download request verification is successful.

9. The substation maintenance data management method according to claim 8, characterized in that: The backend server pushes the corresponding target data packet to the mobile client based on the local data type information, including the following steps: If the backend server finds the target baseline data of the same type in the data cache area according to the local data type information, the backend server packages the target baseline data of the same type into a target data packet and pushes the target data packet to the mobile client; If the backend server finds the target baseline data of the same type in the distributed storage database according to the local data type information, the backend server packages the target baseline data of the same type into a target data packet and pushes the target data packet to the mobile client.

10. A substation maintenance data management platform, characterized in that: Applied to the substation maintenance data management method according to any one of claims 1 to 9, the maintenance data management platform includes a background server, a distributed storage database and a client, the client includes a PC client and a mobile client, the background server is connected to the mobile client and the PC client through an intranet respectively, the PC client is used to upload maintenance data through the background server, the mobile client is used to download the maintenance data through the background server, the background server is connected to the distributed storage database, the distributed storage database is used to divide the maintenance data uploaded by the PC client into baseline data and incremental data and perform distributed storage, and the distributed storage database is also used to classify and store the baseline data according to the data type of the maintenance data.

Images