1. An off-line data synchronization method for a digital factory, comprising the steps of:

s101, sending a complete table structure and an SQL statement for importing a terminal local database to a first terminal;

s102, returning first response information to a first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting instruction, refusing to respond to the record deleting request sent by other terminals before receiving a record unlocking request sent by a subsequent first terminal, putting the locking record request into a memory queue and forwarding the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the record unlocking request;

s103, if the second terminal fails to forward, storing the SQL incremental file with the timestamp for the corresponding terminal;

s104, operating the relevant records according to the deletion and modification updating request sent by the first terminal, if the operation is successful, immediately returning second response information, simultaneously putting the deletion and modification updating request into a queue, after the next heartbeat arrives, forwarding the deletion and modification updating request to other terminals through websocket for updating respective local databases, and if the second terminal fails to forward, saving the SQL incremental file with the timestamp for recording the deletion and modification updating operation into a second incremental file of the SQL incremental file;

and S105, after the second terminal is switched to the online state, receiving a first incremental file sent by the second terminal, and sending a second incremental file corresponding to the first incremental file to the second terminal, wherein the first incremental file is deletion, modification and update operation information of a part of records of the second terminal in the offline state.

2. The offline data synchronization method for digital factory according to claim 1, wherein said step S105 further comprises:

and continuously waiting for a plurality of heartbeat cycles after receiving a first incremental file uploaded by a second terminal, if receiving no incremental file uploading request of other terminals, sending a lock table request broadcast to all terminals, stopping responding to a newly-added or deleted updating request sent by each terminal, recombining all incremental files according to an SQL time stamp sequence and then importing the incremental files into a database, wherein the lock table request broadcast is configured to prohibit the terminals from sending the newly-added or deleted updating request to a server until receiving an unlocking request broadcast.

3. The offline data synchronization method for digital factories of claim 2, characterized in that: the step S105 further includes:

after receiving a first incremental file sent by a second terminal, if the same record is deleted and modified in both the first incremental file and a second incremental file sent to the second terminal, screening the record deletion and modification information in the first incremental file and the second incremental file according to a preset rule, and judging whether the relevant record in the server database needs to be updated by adopting the first incremental file.

4. The offline data synchronization method for digital factories of claim 3, characterized in that: the preset rule specifically comprises:

acquiring a first user ID for deleting the record from the first incremental file, acquiring a second user ID for deleting the record from the second incremental file, and acquiring the authority level corresponding to the user ID from the database according to the user ID;

if the first user authority level is higher than the second user authority level, deleting, modifying and updating the record stored in the database by adopting the content in the first incremental file;

and if the first user permission level is lower than or equal to the second user permission level, acquiring the first time of the record deletion from the first incremental file timestamp, acquiring the second time of the record deletion from the second incremental file timestamp, and if the first time is later than the second time, deleting, updating and otherwise not deleting and updating the record by adopting the content in the first incremental file.

5. An off-line data synchronization apparatus for a digital factory, comprising:

the table structure sending module is used for sending a complete table structure and SQL sentences used for importing a terminal local database to the first terminal;

the response module is used for returning first response information to the first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting instruction, refusing to respond to the record deleting request sent by other terminals before receiving an unlocking record request sent by a subsequent first terminal, putting the locking record request into a memory queue and forwarding the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the unlocking record request;

the incremental file generation module is used for saving the SQL incremental file with the timestamp for the corresponding terminal when the second terminal fails to forward; returning first response information to the first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting and modifying instruction, refusing to respond to the record deleting and modifying request sent by other terminals before receiving a record unlocking request sent by a subsequent first terminal, putting the locking record request into a memory queue and transmitting the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the record unlocking request;

and the incremental file sending module is used for receiving the first incremental file sent by the second terminal and sending a corresponding second incremental file to the second terminal after the second terminal is switched to the online state.

6. The offline data synchronization apparatus for a digital factory according to claim 5, wherein: the incremental file sending module is further configured to continue to wait for multiple heartbeat cycles after receiving a first incremental file uploaded by a second terminal, if an incremental file uploading request of other terminals is not received, send a table locking request broadcast to all terminals and stop responding to a new or deletion update request sent by each terminal, recombine all the incremental files according to an SQL timestamp sequence and then import the incremental files into a database, wherein the table locking request broadcast is configured to prohibit the terminals from sending new or deletion update requests to a server until receiving an unlocking request broadcast.

7. The offline data synchronization apparatus for a digital factory according to claim 6, wherein: the incremental file sending module is further configured to, after receiving a first incremental file sent by a second terminal, if both the first incremental file and a second incremental file sent to the second terminal have deletion and modification of the same record, screen the record deletion and modification information in the first incremental file and the second incremental file according to a preset rule, and determine whether to update a related record in the server database by using the first incremental file.

8. The offline data synchronization apparatus for a digital factory according to claim 7, wherein: the preset rule specifically comprises:

acquiring a first user ID for deleting the record from the first incremental file, acquiring a second user ID for deleting the record from the second incremental file, and acquiring the authority level corresponding to the user ID from the database according to the user ID;

if the first user authority level is higher than the second user authority level, deleting, modifying and updating the record stored in the database by adopting the content in the first incremental file;

and if the first user permission level is lower than or equal to the second user permission level, acquiring the first time of the record deletion from the first incremental file timestamp, acquiring the second time of the record deletion from the second incremental file timestamp, and if the first time is later than the second time, deleting, updating and otherwise not deleting and updating the record by adopting the content in the first incremental file.

9. An offline data synchronization server for a digital plant, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: the processor, when executing the computer program, realizes the steps of the method according to any of claims 1-4.

10. A computer-readable storage medium storing a computer program, characterized in that: the computer program realizing the steps of the method according to any of claims 1-4 when executed by a processor.

Background

In the existing equipment production workshops of a factory, a plurality of workshops do not have wireless networks, so that when the related services of equipment are processed, records can only be recorded on a paper carrier, and recording deviation or omission is easily caused, thereby causing management confusion. For example, when a worker performs a business operation of equipment in a workshop, such as maintenance, inspection, and the like, the worker may need to refer to the history. In addition, when the staff operates in the workshop, the execution equipment needs to be checked, the equipment number is generally long and complicated, and if the mobile terminal of the staff cannot be connected with the network, the mobile terminal can only retrieve and query the relevant equipment information on the paper record, so that the query efficiency is low. And a factory establishes a network for a workshop, and particularly, huge cost is needed to ensure that each area of the factory covers the wireless network. However, even if a wireless network is established for each workshop in a park, due to the obstruction of various large-scale production devices, the problem that network signals become poor or even the connection of mobile terminals of workers is impossible often exists when the mobile terminals enter the production devices or other special areas, so that effective recording operation cannot be finally performed on the mobile terminals, and the recorded data of operation, inspection and the like of each worker cannot be effectively kept synchronous, thereby greatly influencing the operation and guarantee efficiency in the production and manufacturing process.

Disclosure of Invention

Aiming at the defects in the prior art, the invention provides an off-line data synchronization method for a digital factory, which comprises the following steps:

s101, sending a complete table structure and an SQL statement for importing a terminal local database to a first terminal;

s102, returning first response information to a first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting instruction, refusing to respond to the record deleting request sent by other terminals before receiving a record unlocking request sent by a subsequent first terminal, putting the locking record request into a memory queue and forwarding the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the record unlocking request;

s103, if the second terminal fails to forward, storing the SQL incremental file with the timestamp for the corresponding terminal;

s104, operating the relevant records according to the deletion and modification updating request sent by the first terminal, if the operation is successful, immediately returning second response information, simultaneously putting the deletion and modification updating request into a queue, after the next heartbeat arrives, forwarding the deletion and modification updating request to other terminals through websocket for updating respective local databases, and if the second terminal fails to forward, saving the SQL incremental file with the timestamp for recording the deletion and modification updating operation into a second incremental file of the SQL incremental file;

and S105, after the second terminal is switched to the online state, receiving a first incremental file sent by the second terminal, and sending a second incremental file corresponding to the first incremental file to the second terminal, wherein the first incremental file is deletion, modification and update operation information of a part of records of the second terminal in the offline state.

Preferably, the step S105 further includes:

and continuously waiting for a plurality of heartbeat cycles after receiving a first incremental file uploaded by a second terminal, if receiving no incremental file uploading request of other terminals, sending a lock table request broadcast to all terminals, stopping responding to a newly-added or deleted updating request sent by each terminal, recombining all incremental files according to an SQL time stamp sequence and then importing the incremental files into a database, wherein the lock table request broadcast is configured to prohibit the terminals from sending the newly-added or deleted updating request to a server until receiving an unlocking request broadcast.

Preferably, the step S105 further includes:

after receiving a first incremental file sent by a second terminal, if the same record is deleted and modified in both the first incremental file and a second incremental file sent to the second terminal, screening the record deletion and modification information in the first incremental file and the second incremental file according to a preset rule, and judging whether the relevant record in the server database needs to be updated by adopting the first incremental file.

Preferably, the preset rule specifically includes:

acquiring a first user ID for deleting the record from the first incremental file, acquiring a second user ID for deleting the record from the second incremental file, and acquiring the authority level corresponding to the user ID from the database according to the user ID;

if the first user authority level is higher than the second user authority level, deleting, modifying and updating the record stored in the database by adopting the content in the first incremental file;

and if the first user permission level is lower than or equal to the second user permission level, acquiring the first time of the record deletion from the first incremental file timestamp, acquiring the second time of the record deletion from the second incremental file timestamp, and if the first time is later than the second time, deleting, updating and otherwise not deleting and updating the record by adopting the content in the first incremental file.

The invention also discloses an offline data synchronization device for the digital factory, which comprises a table structure sending module, a table structure synchronization module and a database query language (SQL) statement synchronization module, wherein the table structure sending module is used for sending the complete table structure and SQL statement for importing the local database of the terminal to the first terminal; the response module is used for returning first response information to the first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting instruction, refusing to respond to the record deleting request sent by other terminals before receiving an unlocking record request sent by a subsequent first terminal, putting the locking record request into a memory queue and forwarding the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the unlocking record request; the incremental file generation module is used for saving the SQL incremental file with the timestamp for the corresponding terminal when the second terminal fails to forward; returning first response information to the first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting and modifying instruction, refusing to respond to the record deleting and modifying request sent by other terminals before receiving a record unlocking request sent by a subsequent first terminal, putting the locking record request into a memory queue and transmitting the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the record unlocking request; and the incremental file sending module is used for receiving the first incremental file sent by the second terminal and sending a corresponding second incremental file to the second terminal after the second terminal is switched to the online state.

Preferably, the incremental file sending module is further configured to continue to wait for multiple heartbeat cycles after receiving the first incremental file uploaded by the second terminal, and if an incremental file uploading request of another terminal is not received, send a lock table request broadcast to all terminals and stop responding to a new addition or deletion update request sent by each terminal, recombine all the incremental files according to an SQL timestamp sequence and then import the incremental files into the database, where the lock table request broadcast is configured to prohibit the terminal from sending a new addition or deletion update request to the server until receiving an unlocking request broadcast.

Preferably, after receiving the first incremental file sent by the second terminal, if both the first incremental file and the second incremental file sent to the second terminal have deletion and modification of the same record, the incremental file sending module is further configured to filter the record deletion and modification information in the first incremental file and the second incremental file according to a preset rule, and determine whether to update the relevant record in the server database by using the first incremental file.

Preferably, the preset rule specifically includes:

acquiring a first user ID for deleting the record from the first incremental file, acquiring a second user ID for deleting the record from the second incremental file, and acquiring the authority level corresponding to the user ID from the database according to the user ID;

if the first user authority level is higher than the second user authority level, deleting, modifying and updating the record stored in the database by adopting the content in the first incremental file;

and if the first user permission level is lower than or equal to the second user permission level, acquiring the first time of the record deletion from the first incremental file timestamp, acquiring the second time of the record deletion from the second incremental file timestamp, and if the first time is later than the second time, deleting, updating and otherwise not deleting and updating the record by adopting the content in the first incremental file.

The invention also discloses an offline data synchronization server for a digital plant, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of the preceding claims when executing the computer program.

The invention also discloses a computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of the preceding claims.

The off-line data synchronization method for the digital factory, disclosed by the invention, can be used for a server, and returns first response information to a first terminal according to a received record locking request sent by the first terminal after acquiring a record deleting and modifying instruction by sending a complete table structure and SQL (structured query language) statement for importing a terminal local database to the first terminal, and refuses to respond to the record deleting and modifying request sent by other terminals before receiving a record unlocking request sent by a subsequent first terminal. Operating the relevant records according to the deletion and modification updating request sent by the first terminal, and if the second terminal fails to forward, saving the SQL incremental file with the timestamp for the record deletion and modification updating operation into the second incremental file; and after the second terminal is switched to the online state, receiving the first incremental file sent by the second terminal, and sending a second incremental file corresponding to the first incremental file to the second terminal. Therefore, the business operation process of the electronic information system in the network-free environment of a factory workshop at the lowest cost is realized, the operation records and the operation results of each mobile terminal and each fixed terminal can be uploaded and synchronized to the system database, and the data synchronization of the server system database and each terminal local database is maintained.

Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

fig. 1 is a flowchart illustrating an off-line data synchronization method for a digital factory according to the present embodiment.

FIG. 2 is another flow chart of the offline data synchronization method for digital plant disclosed in this embodiment

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the drawings of the embodiments of the present invention. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the described embodiments of the invention without any inventive step, are within the scope of protection of the invention.

In the description of the present invention, it is to be understood that the terms "first", "second" and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implying any number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the present invention, "a plurality" means two or more unless specifically defined otherwise.

In the present invention, unless otherwise expressly specified or limited, the terms "mounted," "connected," "secured," and the like are to be construed broadly and can, for example, be fixedly connected, detachably connected, or integrally connected; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meanings of the above terms in the present invention can be understood by those skilled in the art according to specific situations.

In the present invention, unless otherwise expressly stated or limited, "above" or "below" a first feature means that the first and second features are in direct contact, or that the first and second features are not in direct contact but are in contact with each other via another feature therebetween. Also, the first feature being "on," "above" and "over" the second feature includes the first feature being directly on and obliquely above the second feature, or merely indicating that the first feature is at a higher level than the second feature. A first feature being "under," "below," and "beneath" a second feature includes the first feature being directly under and obliquely below the second feature, or simply meaning that the first feature is at a lesser elevation than the second feature.

Fig. 1 is a detailed flowchart of an embodiment of the present invention, which discloses an offline data synchronization method for a digital factory, and the method can implement a business operation process of an electronic information system in a workshop non-network environment at the lowest cost of the factory, and can synchronize operation records and results into a system database and handheld terminals of each device, and specifically includes the following steps:

step S101, sending a complete table structure and SQL statements for importing the terminal local database to the first terminal. When the first terminal operates for the first time, the server sends a complete table structure and an SQL statement to the first terminal for the first terminal to download and import into a local database, wherein the local database can be an SQLite database in the terminal, or the step is executed after a reset button of the first terminal is operated.

Step S102, first response information is returned to the first terminal according to a received locking record request sent by the first terminal after a record deleting instruction is obtained, response of the record deleting request sent by other terminals before a record unlocking request sent by a subsequent first terminal is received is refused, meanwhile, the locking record request is put into a memory queue and is forwarded to other terminals through websocket after next heartbeat arrives, and the locking record request is configured to prohibit the terminal receiving the request from deleting the record before the terminal receiving the record unlocking request is received.

Specifically, the first terminal judges the network state after acquiring the deletion record instruction, if the first terminal is in the no-network state, the first terminal saves the deleted SQL statement and the timestamp in the local database, and if the first terminal is in the network connection state, the first terminal sends a record locking request to the server through an http protocol. The method comprises the steps that if a server receives a locking record request, first response information is returned, response is refused to a record deleting request sent by other terminals before an unlocking record request sent by a subsequent first terminal is received, meanwhile, the locking record request is placed in a memory queue and is forwarded to other terminals through websocket after next heartbeat arrives, if partial terminals fail to forward, SQL incremental files with time stamps are stored for the corresponding terminals, and the locking record request is configured to prohibit the terminal receiving the request from deleting the record before the terminal receiving the unlocking record request.

And step S103, if the second terminal fails to forward, saving the SQL incremental file with the timestamp for the corresponding terminal.

And step S104, operating the relevant records according to the deletion and modification request sent by the first terminal, if the operation is successful, immediately returning second response information, simultaneously putting the deletion and modification request into a queue, after the next heartbeat arrives, forwarding the deletion and modification request to other terminals through websocket for updating respective local databases, and if the second terminal fails to forward, storing the SQL incremental file with the timestamp for recording the deletion and modification operation into a second incremental file of the SQL incremental file.

Specifically, if the first terminal receives the response message replied by the server, the first terminal sends a deletion and update request to the server through an http protocol. And the server operates according to the deletion update request, immediately returns second response information if the operation is successful, simultaneously puts the deletion update forwarding request into a queue, forwards the deletion update forwarding request to other terminals through websocket after the next heartbeat arrives for updating respective local databases, and stores the SQL incremental file with the timestamp for the corresponding terminal if partial terminal forwarding fails. And if the first terminal does not receive the first response information or the second response information replied by the server, the local database of the first terminal is not updated, otherwise, an unlocking request is sent to the server after the local database is updated.

Specifically, before deletion and modification, the first terminal sends a record locking request to the server through http, the server forwards the request to other terminals through websocket, the other terminals can be mobile terminals or immovable fixed terminals, and any other terminal cannot delete and modify the record after the locking is successful. And then the first terminal sends a deletion update request to the server through http, the first terminal updates the local SQLite database after the server is updated successfully, meanwhile, the server side forwards the deletion update request to other mobile terminals through websocket and updates the SQLite database of each terminal, and finally the first terminal sends an unlocking request to the server.

In some specific embodiments, if the first terminal does not receive the first response signal sent by the server, the recording request is continuously locked to the server for multiple times at preset intervals, and when the first response signal sent by the server is not received, the network state of the first terminal is determined to be a no-network state, the deleted SQL statement and the timestamp are stored in the local database as an SQL incremental file of the server, and when the first terminal is in a network connection state, the corresponding SQL incremental file is sent to the server through an http protocol. Specifically, after a first terminal sends a locking record request to a server, a server side forwards the locking record request to other terminals through a websocket, because the heartbeat of the websocket is sent once every 20 seconds, the forwarding request is firstly put into a memory queue and is forwarded after the next heartbeat request arrives, the server responds to the locking request successfully without worrying whether other terminals successfully receive the request or not, even if some terminals do not receive the locking forwarding request and send a deletion request in the period, the server side can respond refused by corresponding operation error codes, and only one terminal is allowed to request in the same time for deletion operation of one record, so that the consistency of data is ensured; if the server times out and does not respond to the lock request in time, the first terminal will send the request again.

In some embodiments, if the first terminal sends a deletion, modification and update request to the server after receiving the first response signal sent by the server but does not receive the second response signal within the set time, the first terminal suspends subsequent deletion, modification and locking of the record in the local database, and unlocks the record in the local database after receiving the second response signal or the forwarded unlocking request of the server. Specifically, after the first terminal sends the deletion request to the server, if the operation of the server fails, the first terminal will not update the local SQLite database. And if the server is successfully operated, immediately returning successful response information, namely a second response signal, simultaneously putting the forwarding request into a queue, forwarding to other mobile terminals when the next heartbeat arrives, and if the forwarding fails, saving a SQL incremental file with a timestamp for the corresponding terminal to the file server.

In this embodiment, in a network-free environment, any add, delete, modify, and check operation of the mobile terminal is only related to the local sql lite database, and is not related to the server, and the increment file in the form of sql statement is stored in the local flash storage, and is uploaded to the server after network recovery. After the network is recovered, the mobile terminal uploads the incremental file to a server to update the database, and conversely, if the server has the incremental file, the server issues the incremental file to the mobile terminal, and the mobile terminal updates the sqlite database; any adding, deleting and modifying operations of the mobile terminal are completed in the server database and the local sqlite database synchronously. The business operation process of the electronic information system in the non-network environment of the factory workshop at the lowest cost is realized, the operation records and the operation results of all the mobile terminals and the fixed terminals can be uploaded and synchronized to the system database, and the data synchronization of the server system database and the local databases of all the terminals is kept.

Step S105, after the second terminal is switched to the online state, receiving a first incremental file sent by the second terminal, and sending a second incremental file corresponding to the first incremental file to the second terminal, where the first incremental file is deletion, modification and update operation information of a part of records of the second terminal in the offline state.

In this embodiment, the second terminal queries whether a downloadable SQL incremental file corresponding to the second terminal exists in the server after restoring the network connection, if so, downloads the SQL incremental file according to an incremental file download path replied by the server, reassembles the incremental file according to the SQL timestamp sequence, and then imports the incremental file into the local database, and during the import, rejects a notification about lock table/lock record or deletion and modification from the server.

The step S105 further includes: and continuously waiting for a plurality of heartbeat cycles after receiving a first incremental file uploaded by a second terminal, if receiving no incremental file uploading request of other terminals, sending a lock table request broadcast to all terminals, stopping responding to a newly-added or deleted updating request sent by each terminal, recombining all incremental files according to an SQL time stamp sequence and then importing the incremental files into a database, wherein the lock table request broadcast is configured to prohibit the terminals from sending the newly-added or deleted updating request to a server until receiving an unlocking request broadcast.

The step S105 further includes:

after receiving a first incremental file sent by a second terminal, if the same record is deleted and modified in both the first incremental file and a second incremental file sent to the second terminal, screening the record deletion and modification information in the first incremental file and the second incremental file according to a preset rule, and judging whether the relevant record in the server database needs to be updated by adopting the first incremental file.

As shown in fig. 2, in some embodiments, the offline data synchronization method for a digital factory further includes the following steps:

and step S1051, after acquiring the new record instruction, the second terminal saves the added or modified SQL statement and the timestamp as an incremental file to a local database, and if the second terminal is in a network-free state, the second terminal suspends sending a new update request to the server. Specifically, the second terminal determines whether the second terminal is in a no-network state or not according to whether Android broadcastrcerechiver receives a system broadcast of a no-network state or not, and also determines whether the second terminal is in the no-network state or not according to whether websocket connection is successful or whether the server has no response after more than 10 heartbeat requests or the like, and the second terminal can be considered to be in the no-network state as long as the terminal is determined to be in the no-network state through any of the above manners.

When the second terminal is in a network-free state, deleting, adding, inquiring and other operations of the second terminal directly access the local SQLite database, no relation is generated between the second terminal and the server, SQL sentences of the deleting, adding, inquiring and other operations are added with time stamps and then serve as incremental files to be stored in a local flash storage, and the incremental files are uploaded to the server after network recovery and forwarded to other terminals by the server.

Step S1052, after the second terminal is switched to the network connection state again, the second terminal requests the server to upload the first incremental file through the http protocol, and queries whether a downloadable second incremental file corresponding to the second terminal exists in the server. Specifically, when the second terminal is switched from the network-free state to the network connection state, the second terminal uploads the incremental file, namely the first incremental file, which is originally stored in the local flash memory in the network-free state, to the server and forwards the incremental file to other terminals. Meanwhile, when the second terminal is in a non-network state, any deletion, addition, query and other operations performed by other terminals in the time period store the incremental text with the time stamp, namely the second incremental file, corresponding to the second terminal on the server, and the second incremental file is issued to the second terminal when the second terminal is in a network connection state. And the network recovery judgment of the second terminal can receive the broadcast of the system network connection according to the Android broadcastrechiveriver, and then resend the websocket connection, and can judge the network recovery after monitoring the heartbeat request response.

And step S1053, the second terminal uploads the first incremental file to the server according to the uploading and downloading path of the incremental file replied by the server, simultaneously downloads the second incremental file, reorganizes the incremental file according to the SQL timestamp sequence, then imports the incremental file into the local database, and stops responding to a locking record request, a locking table request, a deletion update request or a new addition update request sent by the server to the terminal before the incremental file is imported.

Specifically, the server sends a message for downloading the incremental file to the second terminal through the websocket heartbeat, and then the second terminal downloads the corresponding incremental file, that is, the second incremental file, from the file server after sending a request for downloading the incremental file through http. After the second terminal successfully downloads the incremental file, the incremental file is recombined according to the SQL timestamp sequence and is imported into a local SQLite database, and the response to a locking record request, a locking table request, a deletion update request or an addition update request sent to the terminal by a server is stopped before the incremental file is imported, namely, a notification about locking table/locking record or addition deletion update from the server is rejected during the import.

Step S1054, the server continues to wait for a plurality of heartbeat cycles after receiving the first increment file uploaded by the second terminal, if the increment file uploading requests of other terminals are not received, the server sends a lock table request broadcast to all terminals and stops responding to the newly increased or deleted update requests sent by all terminals, all increment files are recombined according to the SQL timestamp sequence and then are imported into the database, and the lock table request broadcast is configured to prohibit the terminals from sending the newly increased or deleted update requests to the server until receiving the unlocking request broadcast.

Specifically, the server waits for a plurality of heartbeats, for example, within 10 heartbeats, if there is no incremental file request uploaded by other terminals, the server sends a lock table request broadcast to all mobile terminals and non-mobile terminals, and after the broadcast is finished, the server reassembles the incremental files corresponding to all terminals according to the SQL timestamp sequence and then imports the incremental files into the database, and stops responding to the lock record request, the deletion update request or the new addition update request sent to each terminal before the incremental file import is finished, that is, rejects the addition and deletion update request of any terminal during the import period, and sends an unlock message after the import is finished.

When the first incremental file and the second incremental file both have deletion and modification of the same record, the record deletion and modification information in the first incremental file and the second incremental file can be screened according to a preset rule to judge whether the second incremental file is finally adopted to update the related record of the second terminal.

In this embodiment, the preset rules may include a first preset rule, a second preset rule, and a third preset rule, and the server may select and use each rule according to preset rules, may select one of the preset rules to process, may also set each preset rule in a sequence, and if the previous rule cannot be processed, then uses the subsequent rule to process.

In this embodiment, the first preset rule specifically includes:

the server acquires a first user ID for deleting the record from the first incremental file, acquires a second user ID for deleting the record from the second incremental file, and acquires the authority level corresponding to the user ID from the database according to the user ID.

And if the first user authority level is higher than the second user authority level, deleting and updating the record stored in the database by adopting the content in the first incremental file.

And if the first user permission level is lower than or equal to the second user permission level, acquiring the first time of the record deletion from the first incremental file timestamp, acquiring the second time of the record deletion from the second incremental file timestamp, and if the first time is later than the second time, deleting, updating and otherwise not deleting and updating the record by adopting the content in the first incremental file.

In another embodiment, the second preset rule may be determined according to the operation level of the generation time period of the relevant record in the delta file. In this embodiment, the second preset rule specifically includes:

after the server receives a first incremental file sent by a second terminal, if the first incremental file and a second incremental file sent to the second terminal have the same record object to be updated, acquiring a first time corresponding to record deletion from a timestamp of the first incremental file, acquiring a second time corresponding to record deletion from a timestamp of the second incremental file, and comparing the running grades of the time periods of the first time and the second time, wherein the running grades are the polling intensity and/or the working intensity of each time period in which the mobile terminal is located. Specifically, for example, each cooperative department is in an efficient working state during the working period of the day, the inspection of each device is more systematic and standard, and due to the participation of each department, various modification records generated by each department can be more accurate. And the night is often in the duty time period, only local information can be checked and adjusted, and because the number of the participating departments and equipment is small, various modification records generated by the department are often more comprehensive and cannot be compared with the records of the formal working time period in the day, so if two completely independent modification records for one equipment exist, the records of the day time period are often better than the records of the night duty time period, and the importance is stronger.

And if the first time is earlier than the second time and the running grade of the first time is higher than that of the second time, the server adopts the content in the first incremental file to delete, modify and update the record stored in the database.

And if the first time is earlier than the second time but the running grade of the first time is not higher than that of the second time, the content in the first incremental file is not adopted to update the record stored in the database in a deleting way.

And if the first time is later than the second time and the running grade of the first time is higher than or equal to that of the second time, the server adopts the content in the first incremental file to delete, modify and update the record stored in the database.

And if the first time is later than the second time and the operation level of the first time is lower than that of the second time, deleting, modifying and updating the record stored in the database without adopting the content in the first incremental file.

If the first time is equal to the second time, comparing the running grades of the first time and the second time, if the running grade of the first time is higher than the running grade of the second time, deleting and updating the record stored in the database by adopting the content in the first incremental file by the server, otherwise, not deleting and updating the record.

In another embodiment, a plurality of preset rules may be used in combination to determine whether the first terminal related record needs to be updated by using the second incremental file. For example, the first preset rule and the second preset rule are combined, and the judgment is performed by using the above mutual cooperation according to the recorded operator permission level and the recorded generation time period operation level, wherein the generation time period operation level judgment may be mainly used, and the operator permission level is used as an auxiliary, specifically as follows.

After the server receives a first incremental file sent by a second terminal, if the first incremental file and a second incremental file sent to the second terminal have the same record object to be updated, acquiring a first time corresponding to record deletion from a timestamp of the first incremental file, acquiring a second time corresponding to record deletion from a timestamp of the second incremental file, and comparing the running grades of the time periods of the first time and the second time, wherein the running grades are the polling intensity and/or the working intensity of each time period in which the mobile terminal is located.

And if the first time is earlier than the second time and the running grade of the first time is higher than that of the second time, the server adopts the content in the first incremental file to delete, modify and update the record stored in the database.

And if the first time is earlier than the second time but the running grade of the first time is not higher than that of the second time, the content in the first incremental file is not adopted to update the record stored in the database in a deleting way.

And if the first time is later than the second time and the running grade of the first time is higher than or equal to that of the second time, the server adopts the content in the first incremental file to delete, modify and update the record stored in the database.

If the first time is later than the second time and the operation level of the first time is lower than that of the second time, acquiring a first user ID for deleting the record from the first incremental file, acquiring a second user ID for deleting the record from the second incremental file, and acquiring the authority level corresponding to the user ID from the authority database according to the user IDs; the authority database stores user ID and corresponding authority level for logging in each terminal to perform operations such as adding, deleting and the like on data. And if the first user authority level is higher than the second user authority level, deleting, modifying and updating the record by adopting the content in the first incremental file, otherwise, deleting, modifying and updating the record again without adopting the content in the first incremental file. That is, although the first time is later than the second time, if the operation level of the first time is lower than the operation level of the second time and the first user permission level is also lower than the second user permission level, the record is not updated by adopting the content in the first incremental file to delete the record again.

In another embodiment, the third preset rule may be determined according to the offline duration of the second terminal that sends the second incremental file and the number of records to be updated in a time period. In this embodiment, the third preset rule specifically includes:

and acquiring a timestamp of the earliest record deleted and modified in the second incremental file, calculating the minimum value of the offline duration of the second terminal according to the earliest timestamp, judging whether the minimum value of the offline duration is greater than a set time threshold, and if the minimum value of the offline duration is greater than the set time threshold, not adopting the first incremental file to delete and modify the record stored in the database by the server.

And if the minimum value of the offline duration time is not greater than the set time threshold, acquiring the first time of the same record deletion from the time stamp of the first incremental file, and acquiring the second time of the same record deletion from the time stamp of the second incremental file.

If the first time is earlier than the second time, the server does not adopt the first incremental file to update the record stored in the database in a deleting mode.

If the first time is equal to the second time, the number of records to be updated and the time stamp which are contained in the first incremental file are obtained, if the number of records to be updated in the time period of the same record exceeds a preset value, the same record in the database is updated by adopting the first incremental file, otherwise, the same record deleting and modifying information in the first incremental file is not adopted to update the database.

And if the first time is later than the second time, adopting the first incremental file to delete and update the record stored in the database.

In the screening rule of the same record information in the incremental file adopted in this embodiment, the value of the minimum time for the second terminal to continue the offline state at this time is obtained by determining the earliest record timestamp in the first incremental file, and when the offline time of the second terminal is greater than a certain time, that is, a set time threshold value, it may be determined that the offline time of the second terminal is too long, the recorded data may be inaccurate, and at this time, the second incremental file of the server is preferably updated. When the offline state of the second terminal is within the acceptable range, two same record deletion information with the same timestamp in the first incremental file and the second incremental file is generally subject to the deletion information of the server, but when the number of records to be updated in the time period of the record in the first incremental file exceeds a preset value, it indicates that the time period may be that each terminal and the server perform systematic record verification, at this time, the corresponding record of the first terminal is updated with the same record deletion information in the first incremental file as the reference, wherein the time period span may be several preset hours, and the like, and is only a preset time span interval.

In other embodiments, after receiving the first incremental file uploaded by the second terminal and forwarded by the server, the other terminals always in the online state may also filter the record deletion and modification information in the incremental file by using a preset rule similar to that described in the above embodiments.

In the embodiment, under the network-free environment, any adding, deleting, modifying and checking operation of the mobile terminal only has a relationship with the local sqlite database and does not have any relationship with the server, and the increment file in the form of the sql statement is stored in the local flash storage and uploaded to the server after the network is restored. After the network is recovered, the mobile terminal uploads the incremental file to a server to update the database, and conversely, if the server has the incremental file, the server issues the incremental file to the mobile terminal, and the mobile terminal updates the sqlite database; any adding, deleting and modifying operations of the mobile terminal are completed in the server database and the local sqlite database synchronously. The business operation process of the electronic information system in the non-network environment of the factory workshop at the lowest cost is realized, the operation records and the operation results of all the mobile terminals and the fixed terminals can be uploaded and synchronized to the system database, and the data synchronization of the server system database and the local databases of all the terminals is kept.

In another embodiment, the device for synchronizing the offline data of the digital factory further comprises a table structure sending module, a table structure receiving module, a table structure analyzing module and a database management module, wherein the table structure sending module is used for sending a complete table structure and an SQL statement for importing a terminal local database to a first terminal; the response module is used for returning first response information to the first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting instruction, refusing to respond to the record deleting request sent by other terminals before receiving an unlocking record request sent by a subsequent first terminal, putting the locking record request into a memory queue and forwarding the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the unlocking record request; the incremental file generation module is used for saving the SQL incremental file with the timestamp for the corresponding terminal when the second terminal fails to forward; returning first response information to the first terminal according to a received locking record request sent by the first terminal after acquiring a record deleting and modifying instruction, refusing to respond to the record deleting and modifying request sent by other terminals before receiving a record unlocking request sent by a subsequent first terminal, putting the locking record request into a memory queue and transmitting the locking record request to other terminals through websocket after next heartbeat arrives, wherein the locking record request is configured to prohibit the terminal receiving the request from deleting the record before receiving the record unlocking request; and the incremental file sending module is used for receiving the first incremental file sent by the second terminal and sending a corresponding second incremental file to the second terminal after the second terminal is switched to the online state.

In this embodiment, the incremental file sending module is further configured to continue to wait for multiple heartbeat cycles after receiving the first incremental file uploaded by the second terminal, and if an incremental file uploading request from another terminal is not received, send a lock table request broadcast to all terminals and stop responding to a new addition or deletion update request sent by each terminal, reassemble all the incremental files according to an SQL timestamp sequence and then import the incremental files into the database, where the lock table request broadcast is configured to prohibit the terminal from sending a new addition or deletion update request to the server until receiving an unlock request broadcast.

In this embodiment, the incremental file sending module is further configured to, after receiving a first incremental file sent by a second terminal, if both the first incremental file and a second incremental file sent to the second terminal have deletion and modification of the same record, filter the record deletion and modification information in the first incremental file and the second incremental file according to a preset rule, and determine whether to update a relevant record in the server database by using the first incremental file.

In this embodiment, the preset rule specifically includes: acquiring a first user ID for deleting the record from the first incremental file, acquiring a second user ID for deleting the record from the second incremental file, and acquiring the authority level corresponding to the user ID from the database according to the user ID; if the first user authority level is higher than the second user authority level, deleting, modifying and updating the record stored in the database by adopting the content in the first incremental file; and if the first user permission level is lower than or equal to the second user permission level, acquiring the first time of the record deletion from the first incremental file timestamp, acquiring the second time of the record deletion from the second incremental file timestamp, and if the first time is later than the second time, deleting, updating and otherwise not deleting and updating the record by adopting the content in the first incremental file.

The specific functions and components of the above-mentioned offline data synchronization device for a digital plant correspond to those of the offline data synchronization method for a digital plant disclosed in the foregoing embodiments one to one, so that the detailed description is not repeated again, and specific reference may be made to each of the embodiments of the offline data synchronization method for a digital plant disclosed in the foregoing embodiments.

It should be noted that, in the present specification, the embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. The off-line data synchronization device for the digital plant disclosed in the embodiment corresponds to the off-line data synchronization method for the digital plant disclosed in the embodiment, so that the description is relatively simple, and the relevant points can be referred to the description of the method part.

In still other embodiments, there is provided an offline data synchronization server for a digital plant, including a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the offline data synchronization method for the digital plant as described in the above embodiments when executing the computer program.

The offline data synchronization server for the digital factory may include, but is not limited to, a processor and a memory. It will be understood by those skilled in the art that the schematic is merely an example of an offline data synchronization server for a digital plant and does not constitute a limitation of an offline data synchronization server for a digital plant, and may include more or fewer components than those shown, or some components in combination, or different components.

The Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. The general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, the processor being the control center of the apparatus for off-line data synchronization of a digital plant, the various parts of the entire apparatus for off-line data synchronization of a digital plant being connected by various interfaces and lines.

The memory may be used to store the computer programs and/or modules, and the processor may implement the various functions of the apparatus for offline data synchronization of a digital plant by running or executing the computer programs and/or modules stored in the memory and calling up the data stored in the memory. The memory may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required for at least one function, and the like, and the memory may include a high speed random access memory, and may further include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), at least one magnetic disk storage device, a Flash memory device, or other volatile solid state storage device.

The offline data synchronization apparatus for a digital factory, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, all or part of the flow of the method according to the above embodiments may be implemented by a computer program, which may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of the above embodiments of the offline data synchronization method for a digital factory. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.

Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

In summary, the above-mentioned embodiments are only preferred embodiments of the present invention, and all equivalent changes and modifications made in the claims of the present invention should be covered by the claims of the present invention.