CN113568871A - Method for real-time automatic synchronization of power management of medical edge equipment - Google Patents

Abstract

The invention discloses a real-time automatic synchronization method for power management of medical edge equipment, and belongs to the technical field of power supply and distribution. The method comprises a file uploading process and a file downloading process, provides a streaming data real-time synchronization mechanism, and can provide efficient data synchronization service for the power management system of each region of the medical equipment, so that the edge equipment of the power supply system of each region can be effectively communicated with the power management center/data center in real time.

Description

Method for real-time automatic synchronization of power management of medical edge equipment

Technical Field

The invention relates to a real-time automatic synchronization method for power management of medical edge equipment, and belongs to the technical field of power supply and distribution.

Background

China is a medical big country, and with the improvement of living standard of global residents and the enhancement of medical care consciousness, the demand of medical appliance products is continuously increased in recent years. Data shows that the market scale of the medical instrument industry in China reaches 5304 million yuan by 2018, and the market scale of the medical instrument industry in China is estimated to exceed 9000 million yuan in 2022, so that the market prospect of the industry is very wide. With the publication of the seventh census data, the proportion of the population of 60 years old and over in China reaches 2.6 hundred million, which accounts for 18.70 percent, wherein the proportion of the population of 65 years old and over in China is 1.9 hundred million, which accounts for 13.50 percent. The aging of population is an important trend of social development, and is a basic national situation of China for a long time in the future, and the increase of old people stimulates the high-speed development of the medical industry.

The rapid increase of medical equipment brings challenges to power management systems in hospital areas, and the development and reliability of the power supply and distribution industry play a significant role in medical safety. The hospitals have higher requirements on the reliability, safety, real-time performance, usability, compatibility and fault influence range reduction of the power supply and distribution system.

The electric power data in the prior art do not form unified and ordered management after being collected and uploaded, and each regional power supply system does not have a good synchronization mechanism with a data center, and the information sharing real-time performance is poor, so that the data storage of each region and a power supply station is disordered, the updating is complex, great troubles are brought to the lookup of workers, and meanwhile, higher manpower management cost is brought.

Disclosure of Invention

In view of the above problems in the background, the present invention provides a method for automatically synchronizing power management of medical edge devices in real time, which can share information in real time and implement power management consistency service.

The technical scheme of the invention is as follows:

the invention discloses a real-time automatic synchronization method for power management of medical edge equipment, which comprises a file uploading process and a file downloading process, wherein the file uploading process comprises the following steps:

(1-1) when a client side learns that a file A is modified through a system file API, the client side firstly judges whether the file is required to be segmented according to the size of the file, namely, integral synchronization or block synchronization is selected, if the size of the file is larger than a set threshold value, the file A is divided into non-overlapping blocks according to a fixed size, a weak hash value and a strong hash value of each block are calculated, otherwise, a blocking step is not executed, and integral synchronization is directly carried out;

(1-2) the client uploads the meta information file of the file A, the path of the file A and the hash value list to a log server, the log server compares the version number, the path and the hash value list to tell the client which blocks need to be uploaded,

(1-3) the server sequences the hash values to construct an ordered list, then finds the blocks with the same weak hash value and strong hash value in the file information of the server, and marks the existing blocks. In order to achieve high speed and high efficiency, the weak hash value is compared firstly in the comparison process, and if the weak hash value is the same, the strong hash value is compared;

(1-4) the server informs the client of the information of the blocks which are not found, and the client uploads the contents of the blocks;

and (1-5) uploading the blocks needing to be updated to a key-value pair type file storage metadata database by the client through the file server, and returning the latest version number to the client after the uploading is successful by the file server.

The file downloading process comprises the following steps:

(2-1) the client communicates with the log server through long links all the time, and if the file A is updated, the client knows immediately;

(2-2) the client informs the log server of the current meta information of the file A, the log server checks the latest record of the file A, and then returns the updated hash block information to the client;

and (2-3) downloading the needed hash block information by the client through the file server.

Further, in step 1-1, the file a is partitioned according to a threshold of 4MB and SHA-256 hash values of each block are calculated respectively.

Further, in step 1-3, the weak hash is a 32-bit rolling checksum, and the strong hash is a 128-bit MD4 checksum.

Further, in step 1-3, the calculation formula of the checksum is as follows:

(2)

where s (k, l) denotes a data block X_k…X_lThe rolling check value of (1), N is 2¹⁶(ii) a Calculating the checksum of the block with the length S at all possible offsets in the file in a rolling mode, wherein S is the size of the block determined in the cutting process, and the calculation formula at each node is as follows:

（3）

（4）

thus, given X₁……X_nAnd X₁And X_n+1By the value of (A), X can be calculated₂……X_nThe checksum of (2).

Further, in steps 1 to 5, the file server includes a block data server and a metadata server, the block data server is responsible for maintaining hash key storage of encrypted content, and the metadata server is responsible for maintaining user, namespace, and server log files.

Further, in steps 1-5, the formula of the file size value M is:

（1）

where M is the desired file size value, V_netIs the network communication speed, T_comThe method is characterized in that the calculation time cost of the rsync algorithm is adopted, a file is split, the difference is compared when the file is updated, the value is possibly different for devices with different calculation capabilities, C is a time constant, namely the size of a file block is divided by the network speed, n is a constant, and T is taken_comand/2C, which represents half of the number of data blocks that can be transmitted in the time generated by the calculation.

Advantageous effects

The invention provides a real-time automatic synchronization method for power management of medical edge equipment, and provides a streaming data real-time synchronization mechanism, which can provide high-efficiency data synchronization service for power management systems of various regions of medical equipment, so that the edge equipment of power supply systems of various regions can be effectively communicated with a power management center/data center in real time, the consistency service of power management is provided, the good uniform and ordered management of the power supply systems is guaranteed, the management efficiency is improved, the high automation is achieved, and the labor cost and the management complexity are reduced.

Description of the drawings

Fig. 1 is a design architecture diagram of a method for real-time automatic synchronization of power management of a medical edge device according to the present invention.

Detailed Description

In the process of using and managing the power equipment, there are two scenarios, one is to distribute information from the power management center to the data center of each regional power supply system, and the other is to report the data generated by each regional power supply system equipment to the power management center. In order to realize that the edge nodes of each area can keep bidirectional automatic data synchronization with the data center of the power management center and achieve real-time consistency, the invention adopts a Streaming Sync Streaming synchronization method based on the rsync algorithm to carry out bidirectional real-time automatic data synchronization between the edge equipment and the management center.

The present invention is described in further detail below with reference to the attached drawing figures.

For the synchronization of data, mainly involving uploading and downloading of files, as shown in fig. 1, it is assumed that there are N edge devices around the power management center, which are edge a, edge B, edge C, and edge D … …, respectively, and these edge devices will generate data by themselves and deliver the data to the data center, and will also obtain the data of these edge devices from the data center. The uploading is that the edge device A uploads the file to a server after generating a new file locally or modifying an existing file, and the server updates the file; edge device B knows that the file was modified and downloads the latest version of the server locally and updates it. The management center contains all data, the data generated by the edge device is automatically synchronized to the management center in real time, and when the management center uploads new file data, the edge device is automatically synchronized from the data center. Not all of the data is needed by the edge device, and different edge devices need only synchronize their required data from the data center, while the data it produces is synchronized to the data center in real time.

In a specific implementation manner, the simplest method is to replace the whole file, as shown in fig. 1, when the client knows that the file is modified (through a file management API of the system), the modified file is uploaded to the server in its entirety and replaced, and the same is true when downloaded. This is the most basic possible method, but the problem is that: if the target file is too large and is frequently modified, each small modification brings replacement of the whole file, and uploading and downloading occupy a large amount of network resources, and both synchronization efficiency and bandwidth utilization rate are not ideal. Another efficient way is to update only the part of the file inconsistent with the old version in the synchronization process, divide the target file into a plurality of small blocks according to the rsync algorithm, then check which blocks are changed after the file is modified, and then request to upload or download the new blocks, and update only the changed parts. Therefore, communication overhead is reduced in the synchronization process through certain calculation cost.

Based on the above analysis, we combine the advantages of the two approaches. And determining a value, namely the size M of the file, directly adopting a full-updating mode for synchronization when the size of the file is smaller than M, and otherwise adopting an rsync algorithm for updating. However, for different system devices and network qualities, the value of M may be different, and the value of M is a balance point, so that the improvement of synchronization efficiency and bandwidth utilization rate caused by the split calculation can make up for the cost of updating the whole file, a calculation formula is defined, and the value of M is solved by formula 1

（1）

M is the desired file size value, V_netIs the network communication speed, T_comThe method is characterized in that the calculation time cost of the rsync algorithm is adopted, a file is split, the difference is compared when the file is updated, the value is possibly different for devices with different calculation capabilities, C is a time constant, namely the size of a file block is divided by the network speed, n is a constant, and T is taken_comand/2C, which represents half of the number of data blocks that can be transmitted in the time generated by the calculation.

The method comprises the steps of dividing a file with the size exceeding M into non-overlapping blocks b1, b2, b3 and b4 … … according to a fixed size, selecting 4MB, wherein the block size is 4MB, the effect of 1MB proposed by an rsync original algorithm is the best, however, excessive comparison is brought, real-time updating of an electric power system is not friendly, selecting 4MB, hashing and storing the blocks by SHA-256, and as shown in table 1, setting the size of a target file to be 14MB, the blocks to be b1, b2, b3 and b4, and calculating a hash value h1, h2, h3 and h4 corresponding to each divided file block by SHA 256.

TABLE 1 File splitting approach

And calculating a weak hash value and a strong hash value of each block, wherein the weak hash value is 32-bit rolling checksum, the strong hash value is 128-bit MD4 checksum, and MD4 is an abbreviation of Message Digest 4, means an information Digest and is a function for compressing information with any length to the information Digest with a certain fixed length. This is to check a 128-bit hash value.

Since the weak hash is computed faster than the strong hash, the weak hash is compared first and if so, the strong hash is compared again. In addition, a special weak hash value algorithm is adopted in the rsync, and the hash value of the block where the current byte is located can be quickly calculated through the hash value of the block where the previous byte is located. The contents of a file can be uniquely identified by this SHA-256 hash list, called a block list. These hash values are ordered and structured as an ordered list so that each subsequent matching lookup of a block starts after the last time the same block was found, without re-searching all blocks of the server, thus speeding up the process.

The checksum is calculated as shown in equation 2, and s (k, l) is the calculated checksum value, given X₁……X_nAnd X₁And X_n+1The value of the byte, the buffer X can be easily calculated₂……X_nThe checksum of (2):

(2)

where s (k, l) denotes a data block X_k…X_lFor simplicity and speed of calculation, the value of N is 2¹⁶. The check calculation formula has a very critical characteristic that the subsequent check value can be obtained by efficient calculation through a ground-push relationship. The block of length S is calculated in a "rolling" manner (S being the size of the block determined at the time of slicing).

An important property of this checksum is that it is very efficient to compute successive values using a recursive relationship, so that the checksum of a block of length S at all possible offsets in the file can be computed in a "rolling" manner, requiring only a few computations at each node, as shown in equations 3 and 4

（3）

（4）

Thus, given X₁……X_nAnd X₁And X_n+1By the value of (A), X can be calculated₂……X_nThe checksum of (2).

Briefly, the file of the client is divided into blocks according to a fixed size, then the server checks which blocks are unseen, and then requests the client to upload the new blocks. The process is as follows:

1) the method comprises the steps that a client firstly judges whether a file needs to be segmented according to the size of the file, namely, integral synchronization or block synchronization is selected, if the size of the file is larger than a set threshold value, a modified file (or a new file) A is divided into non-overlapping blocks according to a fixed size, the weak hash value and the strong hash value of each block are calculated, otherwise, the step of blocking is not executed, and integral synchronization is directly carried out;

2) the client transmits the meta information (such as path and name) and the hash value of the file A to the server and stores the meta information and the hash value in a metadata database;

3) the server sequences the hash values to construct an ordered list, and then finds the blocks with the same weak hash value and strong hash value in the file information of the server. Marking the existing blocks;

4) the server tells the client the information of the blocks that are not found, and the client uploads the content of those blocks.

In the technical scheme, a synchronization method and a calculation principle of an rsync algorithm are introduced, and the following enters a specific implementation mode of the scheme for real-time automatic synchronization in an actual power system application scene:

before stream synchronization, file synchronization is divided into two phases, upload and download. The entire file must be uploaded to the server and submitted to the database before any other client device knows its existence. Stream synchronization allows file content to be "streamed" through clients between servers. Here we define the namespace as an abstraction of the root directory of the more traditional file system directory tree, with one root namespace for each user. In addition, each shared folder is a namespace and can be mounted in one or more root namespaces, and with the abstraction, each file and directory on the server can be uniquely identified by two values: namespaces and relative paths.

The Server File Journal (SFJ) is an important content, which is a large metadata database that represents the File system, but it contains no File content, only a block list, with each row representing a specific version of a File, where important information for synchronous updates is stored, including namespace ID, relative path, block list, Journal ID. Two types of servers are respectively responsible for different responsibilities, a block data server is responsible for maintaining hash key value storage of encrypted contents, and a metadata server is responsible for maintaining users, a name space and server log files. The server communicates via an internal RPC. Each edge device keeps an indication of its location in the server file log for each of its namespaces so that it can communicate its latest status with the server.

The client first attempts to "commit" the block list to the server, including (namespace, path). The meta-server checks if these hash values are known and the user/namespace has access rights. If the commit is successful, the meta-server will update the server log with the new row. The client is then checked and when it finds that an update is available, it will make a "list" call to learn about the new SFJ line. The call to list takes as input the tag of each namespace so that only new entries are returned. There is a new file. We need to reconstruct the file from these blocks. The download client first checks if the chunk exists locally (in an existing file, or in the file cache we deleted). For new files, these checks may fail and the client will download directly from the chunk server, which verifies that the user can access the chunks and provide them. When the client has owned all the blocks, it can reconstruct the file and add it to the local file system.

For large files, the synchronization time is governed by the network time of the store and retrieve calls. Two implementation flows of uploading and downloading are given below.

Uploading scenes:

1) when a client side learns that a file A is modified through a system file API, the file is partitioned into blocks according to 4MB, and SHA-256 hash values of each block are respectively calculated;

2) and the client uploads the meta-information file of the file A, the path of the file A and the hash value list to the log server. The log server compares the version number, the path and the hash value list and tells the client which blocks need to be uploaded;

3) the client uploads the blocks to be updated to a key value pair type file storage database through the file server, and the latest version number is returned to the client by the file server after the blocks are successfully uploaded;

4) the client updates the local version number of file a.

Downloading a scene:

1) as soon as the client communicates with the log server through the long link, the client immediately knows when the file A is updated;

2) the client informs the log server of the current meta information of the file A, the log server checks the latest record of the file A and then returns the updated hash block information to the client;

3) and the client downloads the needed hash block information through the file server.

The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only illustrative of the present invention and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims (6)

1. A real-time automatic synchronization method for power management of medical edge equipment comprises a file uploading process and a file downloading process, wherein the file uploading process comprises the following steps:

(1-1) when a client side learns that a file A is modified through a system file API, the client side firstly judges whether the file is required to be segmented according to the size of the file, namely, integral synchronization or block synchronization is selected, if the size of the file is larger than a set threshold value, the file A is divided into non-overlapping blocks according to a fixed size, a weak hash value and a strong hash value of each block are calculated, otherwise, a blocking step is not executed, and integral synchronization is directly carried out;

(1-2) the client uploads the meta information file of the file A, the path of the file A and the hash value list to a log server, the log server compares the version number, the path and the hash value list to tell the client which blocks need to be uploaded,

(1-3) the server sequences the hash values to construct an ordered list, then finds the blocks with the same weak hash value and strong hash value in the file information of the server, and marks the existing blocks;

in the comparison process, the weak hash value is compared firstly, and if the weak hash value is the same, the strong hash value is compared;

(1-4) the server informs the client of the information of the blocks which are not found, and the client uploads the contents of the blocks;

(1-5) the client uploads the blocks needing to be updated to a key value pair type file storage metadata database through a file server, and after the blocks are successfully uploaded, the file server returns the latest version number to the client;

the file downloading process comprises the following steps:

(2-1) the client communicates with the log server through long links all the time, and if the file A is updated, the client knows immediately;

(2-2) the client informs the log server of the current meta information of the file A, the log server checks the latest record of the file A, and then returns the updated hash block information to the client;

and (2-3) downloading the needed hash block information by the client through the file server.

2. The method of claim 1, wherein, in step 1-1, the file a is partitioned into 4MB blocks according to a threshold value and SHA-256 hash values of each block are calculated respectively.

3. The method of claim 2, wherein the weak hash is a 32-bit rolling checksum and the strong hash is a 128-bit MD4 checksum in steps 1-3.

4. The method of claim 3, wherein the checksum is calculated in steps 1-3 as follows:

(2)

where s (k, l) denotes a data block X_k…X_lThe rolling check value of (1), N is 2¹⁶(ii) a Calculating the checksum of the block with the length S at all possible offsets in the file in a rolling mode, wherein S is the size of the block determined in the cutting process, and the calculation formula at each node is as follows:

（3）

（4）

thus, given X₁……X_nAnd X₁And X_n+1By the value of (A), X can be calculated₂……X_nThe checksum of (2).

5. The method of claim 4, wherein in steps 1-5, the file servers include a block data server responsible for maintaining hash key storage of encrypted content and a metadata server responsible for maintaining user, namespace, and server log files.

6. The method according to claim 5, wherein in steps 1-5, the formula for the file size value M:

（1）

where M is the desired file size value, V_netIs the network communication speed, T_comThe method is characterized in that the calculation time cost of the rsync algorithm is adopted, a file is split, the difference is compared when the file is updated, the value is possibly different for devices with different calculation capabilities, C is a time constant, namely the size of a file block is divided by the network speed, n is a constant, and T is taken_comand/2C, which represents half of the number of data blocks that can be transmitted in the time generated by the calculation.

Images