Communication interruption duration determination method and apparatus, and electronic device

Abstract

The invention discloses a communication interruption duration determination method and device and electronic equipment, and belongs to the technical field of communication, and the method comprises the steps: sending a Modbus protocol-based request message to a server when a data collection period arrives; judging whether a response message sent by the server is received within a preset receiving duration, and determining whether a line fault occurs or not according to a receiving result of the response message; when the line fault is determined, determining the current time as fault starting time; determining whether a restart condition is met or not based on a receiving result of response messages corresponding to a preset first number of request messages after the line fault; when it is determined that the restarting condition is met, the client is restarted to reestablish the connection with the server; and determining the communication interruption duration based on the fault starting time, the fault ending time during connection recovery and the data acquisition period. Through the automatic recovery of the line fault, the communication interruption duration can be accurately calculated, and the data integrity and reliability are improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method, device and electronic device for determining the duration of a communication interruption. Background Art

[0002] Modbus Communication Protocol (Modbus protocol) is a general protocol used in electronic controllers. The communication process of Modbus protocol adopts a "question-answer" interaction method, where the client (data acquisition terminal or control terminal) sends a request to the server (such as a sensor, etc.). After receiving the request, the server will perform the corresponding operation according to the request content and return a response message to the client. The response message contains the execution result or the requested data. When the client does not receive the response message within the preset time, or the received response message cannot be correctly matched with the previous request, it usually abandons the current request and continues to execute the next set of data requests. The server will not actively send data when it does not receive the client's request.

[0003] In the prior art, the power monitoring system usually uses Linux as the operating system. The Linux system cannot detect communication interruptions caused by external factors (such as poor contact of the device port, manual unplugging, etc.) in a short period of time, and thus restart to re-establish the communication link. The Modbus protocol itself does not have a mechanism for detecting and determining automatic disconnection. Therefore, when a communication interruption caused by external factors occurs (such as poor contact of the device port, manual unplugging, etc.), the client and the server will still operate in a "fake communication" but data-free manner, and the communication failure cannot be automatically restored. The problem can only be solved by manually restarting the client or server. In the power monitoring system, the data collected by the client will be written into the real-time library at the same time, and the data storage module will periodically obtain values ​​from the real-time library as historical data; since the currently commonly used real-time libraries are all data retention mechanisms, that is, if there is no action to insert a new value into the real-time library for a certain period of time, it will maintain the value after the last action, resulting in an inability to accurately determine the fault interval, which in turn leads to low data integrity and reliability. Summary of the invention

[0004] The embodiments of the present application provide a method, device and electronic device for determining the duration of a communication interruption, which are used to accurately calculate the duration of a communication interruption, thereby improving the integrity and reliability of data.

[0005] In a first aspect, an embodiment of the present application provides a method for determining a communication interruption duration, which is applied to a client, and the method includes:

[0006] When the data collection cycle arrives, a request message based on the Modbus protocol is sent to the server;

[0007] Determine whether a response message sent by the server is received within a preset receiving time, and determine whether it is a line fault according to the reception result of the response message;

[0008] When it is determined to be a line fault, the current time is determined as the fault start time;

[0009] Determining whether a restart condition is met based on a reception result of a response message corresponding to a preset first number of request messages after a line failure;

[0010] When it is determined that the restart condition is met, restart the client to re-establish a connection with the server;

[0011] The duration of the communication interruption is determined based on the fault start time, the fault end time when the connection is restored, and the data collection cycle.

[0012] In some embodiments, determining whether the restart condition is met based on the reception result of the response message corresponding to the preset first number of request messages after the line failure includes:

[0013] If the preset first number of request messages do not receive corresponding response messages within the preset receiving time period, it is determined that the restart condition is met; or

[0014] Among the preset first number of request messages, if any request message receives a corresponding response message within the preset receiving time length, and it is determined that the connection has not been restored based on the reception result of the response message corresponding to the preset second number of request messages after the received response message, then it is determined that the restart condition is met.

[0015] In some embodiments, whether the connection is restored is determined by:

[0016] Parsing the response messages corresponding to the preset second number of request messages to determine the parsing result of each response message;

[0017] Based on the parsing results of each response message, determine whether each response message is an error response message;

[0018] If all the response messages corresponding to the preset second number of request messages are error response messages, it is determined that the connection has not been restored;

[0019] If the response message corresponding to any request message among the preset second number of request messages is not an error response message, it is determined that the connection is restored.

[0020] In some embodiments, the determining whether each response message is an error response message based on the parsing result of each response message includes:

[0021] For any target response message, compare the first transaction identifier of the target response message with the second transaction identifier of the request message corresponding to the target response message;

[0022] If the first transaction identifier is consistent with the second transaction identifier, determining that the target response message is not an error response message;

[0023] If the first transaction identifier is inconsistent with the second transaction identifier, it is determined that the target response message is an error response message.

[0024] In some embodiments, determining the duration of the communication interruption based on the fault start time, the fault end time when the connection is restored, and the data collection cycle includes:

[0025] Determine the fault duration based on the difference between the fault end time and the fault start time;

[0026] Determining the number of data collection cycles based on the sum of the ratio between the fault duration and the data collection cycle and a preset value;

[0027] The product of the number of data collection cycles and the data collection cycle is determined as the communication interruption duration.

[0028] In some embodiments, after determining the duration of the communication interruption, the method further includes:

[0029] Determining the communication interruption start time based on the difference between the fault end time and the communication interruption duration;

[0030] Determine the fault end time as the communication interruption end time;

[0031] A communication interruption interval is determined based on the communication interruption start time and the communication interruption end time.

[0032] In a second aspect, an embodiment of the present application provides a device for determining a communication interruption duration, which is applied to a client, and the device includes:

[0033] The sending module is used to send a request message based on the Modbus protocol to the server when the data collection cycle arrives;

[0034] A first determination module, used to determine whether a response message sent by the server is received within a preset receiving time, and determine whether it is a line fault according to the reception result of the response message;

[0035] A second determination module, for determining the current time as the fault start time when a line fault is determined;

[0036] A third determination module, configured to determine whether a restart condition is met based on a reception result of a response message corresponding to a preset first number of request messages after a line failure;

[0037] A restart module, configured to restart the client to re-establish a connection with the server when it is determined that the restart condition is met;

[0038] The fourth determination module is used to determine the duration of the communication interruption based on the fault start time, the fault end time when the connection is restored, and the data collection cycle.

[0039] In some embodiments, the third determination module is specifically configured to:

[0040] If the preset first number of request messages do not receive corresponding response messages within the preset receiving time period, it is determined that the restart condition is met; or

[0041] Among the preset first number of request messages, if any request message receives a corresponding response message within the preset receiving time length, and it is determined that the connection has not been restored based on the reception result of the response message corresponding to the preset second number of request messages after the received response message, then it is determined that the restart condition is met.

[0042] In some embodiments, the third determination module determines whether the connection is restored in the following manner:

[0043] Parsing the response messages corresponding to the preset second number of request messages to determine the parsing result of each response message;

[0044] Based on the parsing results of each response message, determine whether each response message is an error response message;

[0045] If all the response messages corresponding to the preset second number of request messages are error response messages, it is determined that the connection has not been restored;

[0046] If the response message corresponding to any request message among the preset second number of request messages is not an error response message, it is determined that the connection is restored.

[0047] In some embodiments, the third determination module is specifically configured to:

[0048] For any target response message, compare the first transaction identifier of the target response message with the second transaction identifier of the request message corresponding to the target response message;

[0049] If the first transaction identifier is consistent with the second transaction identifier, determining that the target response message is not an error response message;

[0050] If the first transaction identifier is inconsistent with the second transaction identifier, it is determined that the target response message is an error response message.

[0051] In some embodiments, the fourth determining module is specifically configured to:

[0052] Determine the fault duration based on the difference between the fault end time and the fault start time;

[0053] Determining the number of data collection cycles based on the sum of the ratio between the fault duration and the data collection cycle and a preset value;

[0054] The product of the number of data collection cycles and the data collection cycle is determined as the communication interruption duration.

[0055] In some embodiments, after determining the communication interruption duration, the fourth determination module is further configured to:

[0056] Determining the communication interruption start time based on the difference between the fault end time and the communication interruption duration;

[0057] Determine the fault end time as the communication interruption end time;

[0058] A communication interruption interval is determined based on the communication interruption start time and the communication interruption end time.

[0059] In a third aspect, an embodiment of the present application provides an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein:

[0060] The memory stores a computer program executable by at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the above-mentioned method for determining the duration of communication interruption.

[0061] In a fourth aspect, an embodiment of the present application provides a storage medium. When a computer program in the storage medium is executed by a processor of an electronic device, the electronic device can execute the above-mentioned method for determining the duration of communication interruption.

[0062] In a fifth aspect, an embodiment of the present application provides a computer program product, which, when called and executed by an electronic device, enables the electronic device to execute the above-mentioned method for determining the duration of communication interruption.

[0063] In the embodiment of the present application, when the data acquisition cycle arrives, a request message based on the Modbus protocol is sent to the server; it is determined whether a response message sent by the server is received within the preset receiving time, and whether it is a line fault according to the reception result of the response message; when it is determined to be a line fault, the current time is determined as the fault start time; based on the reception result of the response message corresponding to the preset first number of request messages after the line fault, it is determined whether the restart condition is met; when it is determined that the restart condition is met, the client is restarted to re-establish the connection with the server; based on the fault start time, the fault end time when the connection is restored, and the data acquisition cycle, the communication interruption duration is determined. In this way, by adding a mechanism for detecting communication interruption in the communication system, the fault start time is determined when a line fault is detected, and it can be automatically restarted when it is determined that the restart condition is met, and the automatic recovery of the line fault is realized, which ensures the real-time and accuracy of the data. Furthermore, based on the fault start time, the fault end time when the connection is restored, and the data acquisition cycle, the communication interruption duration can be accurately calculated, which improves the integrity and reliability of the data.

[0064] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0066] Figure 1 A flow chart of a method for determining a communication interruption duration provided in an embodiment of the present application;

[0067] Figure 2 A flowchart of a restart judgment mechanism is provided for this application;

[0068] Figure 3 A flowchart of another restart determination mechanism is provided for this application;

[0069] Figure 4 A flowchart of another method for determining the duration of a communication interruption provided in an embodiment of the present application;

[0070] Figure 5 A schematic diagram of the structure of a device for determining the duration of a communication interruption provided in an embodiment of the present application;

[0071] Figure 6A schematic diagram of the hardware structure of an electronic device for implementing a method for determining a communication interruption duration provided in an embodiment of the present application. DETAILED DESCRIPTION

[0072] In order to accurately calculate the duration of communication interruption and improve the integrity and reliability of data, the embodiments of the present application provide a method, device and electronic device for determining the duration of communication interruption.

[0073] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application may be combined with each other if there is no conflict.

[0074] It should be noted that the terms "first", "second", etc. in the description of the embodiment of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiment of the present application described here can be implemented in an order other than those illustrated or described here. In the description of the embodiment of the present application, unless otherwise specified, "multiple" refers to two or more. "And / or", describes the association relationship of the associated objects, indicating that three relationships can exist, for example, A and / or B, can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are a kind of "or" relationship. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, the process, method, system, product or equipment comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0075] In the technical solution of this application, the acquisition, transmission, storage, and use of data are in compliance with the requirements of relevant national laws and regulations.

[0076] Before introducing the method for determining the duration of a communication interruption provided in an embodiment of the present application, for ease of understanding, the technical background of the embodiment of the present application is first introduced in detail below.

[0077] Modbus communication protocol is the most commonly used data acquisition method for power monitoring systems. The communication process of Modbus protocol adopts a "question-and-answer" interactive method, where the client (data acquisition terminal or control terminal) sends a request to the server (such as a sensor, etc.). After receiving the request, the server will perform the corresponding operation according to the request content and return a response message to the client. The response message contains the execution result or the requested data. When the client does not receive the response message within the preset time, or the received response message cannot be correctly matched with the previous request, it usually abandons the current request and continues to execute the next set of data requests. The server will not actively send data when it does not receive the client's request.

[0078] At present, the power monitoring system usually uses Linux as the operating system. The Linux system cannot detect communication interruptions caused by external factors (such as poor contact of the device port, manual unplugging, etc.) in a short time, and thus restart to re-establish the communication link. The Modbus protocol itself does not have a mechanism to detect and determine automatic disconnection. Therefore, when communication interruptions caused by external factors occur (such as poor contact of the device port, manual unplugging, etc.), the client and the server will still operate in a "fake communication" but data-free manner, and the communication failure cannot be automatically restored. The problem can only be solved by manually restarting the client or server. Since the data collected by the client in the power monitoring system will be written into the real-time library at the same time, and the data storage module will periodically obtain values ​​from the real-time library as historical data; since the currently commonly used real-time libraries are data retention mechanisms, that is, if there is no action to insert a new value into the real-time library for a certain period of time, it will maintain the value after the last action, resulting in an inability to accurately determine the fault interval, which in turn leads to low data integrity and reliability.

[0079] In view of this, in order to solve the problem that the fault interval cannot be accurately determined in the prior art, which leads to low integrity and reliability of data, the embodiment of the present application provides a method, device and electronic device for determining the duration of communication interruption. Some preferred embodiments of the present application are described below in conjunction with the drawings of the specification.

[0080] The following takes the application in power monitoring system as an example. Figure 1 A flowchart of a method for determining a communication interruption duration provided in an embodiment of the present application, the method is applied in a client, and the method includes the following steps.

[0081] In step 101, when the data collection cycle arrives, a request message based on the Modbus protocol is sent to the server.

[0082] In specific implementation, the data collection period can be set to 1 minute, 10 minutes, or 1 hour. It can be set by technical personnel according to actual needs, and this application does not limit it here.

[0083] In specific implementation, in the application scenario of the power monitoring system, the client can be a monitoring host, the server can be a sensor or an electric meter and other equipment, and the client and the server can be connected through the Internet to achieve mutual communication. The Internet is usually the Internet, but it can also be any network, including but not limited to a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile, wired or wireless network, a private network or any combination of a virtual private network. In some embodiments, technologies and / or formats including Hyper Text Mark-up Language (HTML), Extensible Markup Language (XML), etc. are used to represent data exchanged through the network. In addition, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet Protocol Security (IPsec), etc. can also be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies may be used to replace or supplement the above-mentioned data communication technologies.

[0084] In step 102, it is determined whether a response message sent by the server is received within a preset receiving time, and whether it is a line fault according to the reception result of the response message.

[0085] During specific implementation, the receiving time can be set, for example, 20 seconds. If no response message sent by the server is received within the receiving time of 20 seconds, it can be determined that the line is faulty.

[0086] In step 103, when it is determined that there is a line fault, the current time is determined as the fault start time.

[0087] In step 104, based on the reception result of the response messages corresponding to the preset first number of request messages after the line failure, it is determined whether the restart condition is met.

[0088] In specific implementation, the communication interruption caused by external factors refers to the failure of hardware such as the communication medium when the software of both sides of the communication system is running normally, such as aging and breaking of the line, poor contact of the device interface, and artificial disconnection. Assuming that the line failure is aging and breaking of the line, at this time, the line cannot be restored by itself in a short time, then determining whether the restart condition is met can be that if a preset first number of request messages do not receive corresponding response messages within a preset reception time, then it is determined that the restart condition is met.

[0089] For example, Figure 2 As shown, Figure 2 A flowchart of a restart judgment mechanism is provided for the present application, and the method includes the following steps.

[0090] In step 201, a line fault is determined and a first counter is started.

[0091] The first counter is used to count the number of request messages sent by the client that have not received response messages sent by the server.

[0092] In step 202, when the data collection cycle arrives, a request message based on the Modbus protocol is sent to the server.

[0093] In step 203 , it is determined whether a response message sent by the server is received within a preset receiving time. If so, the process proceeds to step 204 , otherwise, the process proceeds to step 205 .

[0094] In step 204 , the first counter is cleared and the process returns to step 202 .

[0095] In step 205, the value of the first counter is increased by 1.

[0096] In step 206 , it is determined whether the value of the first counter meets the preset first quantity. If so, the process proceeds to step 207 , otherwise, the process proceeds to step 202 .

[0097] Among them, the preset first number can be set to 1, that is, as long as any response message is not received, it can be determined that the restart condition is met. Of course, for application scenarios with high fault tolerance, the preset first number can also be set to other values, which is not limited in this application.

[0098] In step 207, it is determined that a condition for restarting the client is met.

[0099] In this way, when it is determined that no response messages are received for request messages exceeding the preset first number, it can be determined that the restart condition is met.

[0100] In specific implementation, if the line fault is caused by poor contact of the device interface, the line fault can be restored automatically in a short time. At this time, whether the restart condition is met can also be determined by, among the preset first number of request messages, if any request message receives a corresponding response message within a preset reception time, and based on the reception result of the response message corresponding to the preset second number of request messages after the received response message, it is determined that the connection is not restored, then it is determined that the restart condition is met.

[0101] In specific implementation, you can determine whether the connection is restored by the following methods:

[0102] Parsing the response messages corresponding to the preset second number of request messages to determine the parsing result of each response message;

[0103] Based on the parsing result of each response message, determine whether each response message is an error response message;

[0104] If the response messages corresponding to the preset second number of request messages are all error response messages, it is determined that the connection is not restored;

[0105] If the response message corresponding to any request message in the preset second number of request messages is not an error response message, it is determined that the connection is restored.

[0106] For example, Figure 3 As shown, Figure 3 A flowchart of another restart determination mechanism is provided for the present application, and the method includes the following steps.

[0107] In step 301, a first counter and a second counter are started.

[0108] The second counter is used to count whether the response messages corresponding to the request messages sent by the client are error response messages.

[0109] In step 302, when the data collection cycle arrives, a request message based on the Modbus protocol is sent to the server.

[0110] In step 303 , it is determined whether a response message sent by the server is received within a preset receiving time. If so, the process proceeds to step 304 , otherwise, the process proceeds to step 306 .

[0111] In step 304 , it is determined whether the value of the first counter is greater than or equal to 1 and less than a preset first number. If so, the process proceeds to step 309 , otherwise, the process proceeds to step 305 .

[0112] In step 305 , the first counter is cleared and the process proceeds to step 302 .

[0113] In step 306, the value of the first counter is increased by 1.

[0114] In step 307 , it is determined whether the value of the first counter meets the preset first quantity. If so, the process proceeds to step 308 , otherwise, the process proceeds to step 302 .

[0115] In step 308, it is determined that a condition for restarting the client is met.

[0116] In step 309, the first counter is cleared, the received response message is parsed, and the parsing result of the response message is determined.

[0117] In step 310 , based on the parsing result of the response message, it is determined whether the response message is an error response message. If so, the process proceeds to step 311 , otherwise, the process proceeds to step 313 .

[0118] In a specific implementation, for any target response message, the first transaction identifier of the target response message is compared with the second transaction identifier of the request message corresponding to the target response message;

[0119] If the first transaction identifier is consistent with the second transaction identifier, determining that the target response message is not an error response message;

[0120] If the first transaction identifier is inconsistent with the second transaction identifier, it is determined that the target response message is an error response message.

[0121] For example, the request message is TX, and the response message is RX. The transaction identifiers of the request message TX and the response message RX are both preset to be 0x0001, indicating that the two messages are used to represent the request and response of the same set of data.

[0122] Request message (TX): 000100000006010300000002

[0123] Response message (RX): 0001000000FB 01030442A00000435E 0000

[0124] In step 311, the value of the second counter is increased by 1.

[0125] In step 312 , it is determined whether the value of the second counter meets the preset second quantity. If so, the process proceeds to step 308 , otherwise, the process proceeds to step 302 .

[0126] In step 313 , the second counter is cleared and the process proceeds to step 302 .

[0127] Among them, the preset second number can be set to 1, that is, as long as any response message is an error response message, it can be determined that the restart condition is met. Of course, for application scenarios with high fault tolerance, the preset second number can also be set to other values, which is not limited in this application.

[0128] In this way, if any request message among the preset first number of request messages receives a corresponding response message within the preset receiving time, it means that the line has been restored. At this time, the order of the request message and the response message may be disordered, and the correct mapping cannot be achieved, which will also lead to poor data accuracy. Therefore, the number of error response messages can also be recorded. When the number of error response messages meets the preset second number, it is determined whether the restart condition is met.

[0129] In step 105, when it is determined that the restart condition is met, the client is restarted to re-establish the connection with the server.

[0130] In step 106, the duration of the communication interruption is determined based on the fault start time, the fault end time when the connection is restored, and the data collection cycle.

[0131] In specific implementation, the fault duration can be determined based on the difference between the fault end time and the fault start time, and the number of data collection cycles can be determined based on the sum of the ratio between the fault duration and the data collection cycle and a preset value, where the preset value can be 1, and the product of the number of data collection cycles and the data collection cycle is determined as the communication interruption duration.

[0132] For example, the fault start time is 10:00:00, the connection is restored at 10:08:00, the data collection cycle is 1 minute, and the preset value is set to 1. At this time, the fault duration is 10:08:00-10:00:00=8 minutes. In addition, the fault duration can be rounded off, and the number of data collection cycles is 8 / 1+1=9, which means that during the communication interruption, starting from 10:00:00, data is collected every 1 minute until 10:08:00. Theoretically, the number of data points that should be collected but are not collected is 9. Finally, the communication interruption duration is 9x1=9 minutes.

[0133] Furthermore, after determining the duration of the communication interruption, the communication interruption start time can be determined based on the difference between the fault end time and the communication interruption duration; the fault end time is determined as the communication interruption end time; and the communication interruption interval is determined based on the communication interruption start time and the communication interruption end time.

[0134] For example, the start time of the communication interruption is 10:08:00-9 minutes=09:59:00, the end time of the communication interruption is 10:08:00, and the communication interruption interval is [09:59:00, 10:08:00]. Subsequently, the client can also send the communication interruption interval to the alarm processing unit of the power monitoring system, so that the alarm processing unit can notify relevant technical personnel to process the response message recorded by the data storage module within the communication interruption interval, so as to facilitate subsequent data analysis and fault diagnosis.

[0135] In this way, by adding a mechanism for detecting communication interruptions in the communication system, the fault start time is determined when a line fault is detected, and the system can automatically restart when the restart conditions are met, thereby achieving automatic recovery of the line fault and ensuring the real-time and accuracy of the data. Furthermore, based on the fault start time, the fault end time when the connection is restored, and the data collection cycle, the communication interruption duration can be accurately calculated to ensure that the system does not incorrectly process data lost during the communication interruption, thereby improving data integrity and reliability.

[0136] Figure 4 A flowchart of another method for determining the duration of a communication interruption provided in an embodiment of the present application, the method is applied in a client, and the method includes the following steps.

[0137] In step 401, a first counter is started, and a second counter is started.

[0138] In step 402, when the data collection cycle arrives, a request message based on the Modbus protocol is sent to the server.

[0139] In step 403, it is determined whether a response message sent by the server is received within a preset receiving time. If so, the process proceeds to step 404, otherwise, the process proceeds to step 406.

[0140] In step 404 , it is determined whether the value of the first counter is greater than or equal to 1 and less than a preset first number. If not, the process proceeds to step 405 ; if yes, the process proceeds to step 410 .

[0141] In step 405 , the first counter is cleared and the process proceeds to step 402 .

[0142] In step 406 , the value of the first counter is increased by 1, and when the value of the first counter is 1, the current time is determined as the fault start time.

[0143] In step 407 , it is determined whether the value of the first counter meets the preset first quantity. If so, the process proceeds to step 408 ; otherwise, the process proceeds to step 402 .

[0144] In step 408, it is determined that the conditions for restarting the client are met, the client is restarted to re-establish the connection with the server, and the current time is determined as the failure end time.

[0145] In step 409, the duration of the communication interruption is determined based on the fault start time, the fault end time when the connection is restored, and the data collection cycle.

[0146] In step 410, the first counter is cleared, the received response message is parsed, and the parsing result of the response message is determined.

[0147] In step 411 , based on the parsing result of the response message, it is determined whether the response message is an error response message. If so, the process proceeds to step 412 , otherwise, the process proceeds to step 414 .

[0148] In step 412, the value of the second counter is increased by 1.

[0149] In step 413 , it is determined whether the value of the second counter meets the preset second quantity. If so, the process proceeds to step 408 , otherwise, the process proceeds to step 402 .

[0150] In step 414 , the second counter is cleared, and the current time is determined as the fault end time before entering step 409 .

[0151] Based on the same technical concept, an embodiment of the present application also provides a device for determining the duration of a communication interruption. The principle of solving the problem by the device for determining the duration of a communication interruption is similar to that of the method for determining the duration of a communication interruption. Therefore, the implementation of the device for determining the duration of a communication interruption can refer to the implementation of the method for determining the duration of a communication interruption, and the repeated parts will not be repeated.

[0152] Figure 5 A structural diagram of a device for determining a communication interruption duration provided in an embodiment of the present application includes a sending module 501, a first determining module 502, a second determining module 503, a third determining module 504, a restarting module 505, and a fourth determining module 506.

[0153] The sending module 501 is used to send a request message based on the Modbus protocol to the server when the data collection cycle arrives;

[0154] A first determination module 502 is used to determine whether a response message sent by the server is received within a preset receiving time, and determine whether it is a line fault according to the reception result of the response message;

[0155] The second determination module 503 is used to determine the current time as the fault start time when it is determined that there is a line fault;

[0156] A third determination module 504, configured to determine whether a restart condition is met based on a reception result of a response message corresponding to a preset first number of request messages after a line failure;

[0157] A restart module 505, configured to restart the client to re-establish a connection with the server when it is determined that the restart condition is met;

[0158] The fourth determination module 506 is used to determine the duration of the communication interruption based on the fault start time, the fault end time when the connection is restored, and the data collection cycle.

[0159] In some embodiments, the third determining module 504 is specifically configured to:

[0160] If the preset first number of request messages do not receive corresponding response messages within the preset receiving time period, it is determined that the restart condition is met; or

[0161] Among the preset first number of request messages, if any request message receives a corresponding response message within the preset receiving time length, and it is determined that the connection has not been restored based on the reception result of the response message corresponding to the preset second number of request messages after the received response message, then it is determined that the restart condition is met.

[0162] In some embodiments, the third determination module 504 determines whether the connection is restored by:

[0163] Parsing the response messages corresponding to the preset second number of request messages to determine the parsing result of each response message;

[0164] Based on the parsing results of each response message, determine whether each response message is an error response message;

[0165] If all the response messages corresponding to the preset second number of request messages are error response messages, it is determined that the connection has not been restored;

[0166] If the response message corresponding to any request message among the preset second number of request messages is not an error response message, it is determined that the connection is restored.

[0167] In some embodiments, the third determining module 504 is specifically configured to:

[0168] For any target response message, compare the first transaction identifier of the target response message with the second transaction identifier of the request message corresponding to the target response message;

[0169] If the first transaction identifier is consistent with the second transaction identifier, determining that the target response message is not an error response message;

[0170] If the first transaction identifier is inconsistent with the second transaction identifier, it is determined that the target response message is an error response message.

[0171] In some embodiments, the fourth determining module 506 is specifically configured to:

[0172] Determine the fault duration based on the difference between the fault end time and the fault start time;

[0173] Determining the number of data collection cycles based on the sum of the ratio between the fault duration and the data collection cycle and a preset value;

[0174] The product of the number of data collection cycles and the data collection cycle is determined as the communication interruption duration.

[0175] In some embodiments, after determining the communication interruption duration, the fourth determination module 506 is further configured to:

[0176] Determining the communication interruption start time based on the difference between the fault end time and the communication interruption duration;

[0177] Determine the fault end time as the communication interruption end time;

[0178] A communication interruption interval is determined based on the communication interruption start time and the communication interruption end time.

[0179] The division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, the functional modules in the embodiments of the present application may be integrated in a processor, or may exist physically separately, or two or more modules may be integrated in one module. The coupling between the modules may be achieved through some interfaces, which are usually electrical communication interfaces, but it is not excluded that they may be mechanical interfaces or other forms of interfaces. Therefore, the modules described as separate components may or may not be physically separated, and may be located in one place or distributed to different locations of the same or different devices. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0180] After introducing the method and device for determining the communication interruption duration according to an exemplary embodiment of the present application, next, an electronic device according to another exemplary embodiment of the present application is introduced.

[0181] Refer to the following Figure 6 The electronic device 130 implemented according to this embodiment of the present application is described. Figure 6 The electronic device 130 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0182] like Figure 6 As shown, the electronic device 130 is in the form of a general electronic device. The components of the electronic device 130 may include but are not limited to: the at least one processor 131, the at least one memory 132, and a bus 133 connecting different system components (including the memory 132 and the processor 131).

[0183] Bus 133 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.

[0184] The memory 132 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 1321 and / or a cache memory 1322 , and may further include a read-only memory (ROM) 1323 .

[0185] The memory 132 may also include a program / utility 1325 having a set (at least one) of program modules 1324, such program modules 1324 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0186] The electronic device 130 may also communicate with one or more external devices 134 (e.g., keyboards, pointing devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 130, and / or communicate with any device that enables the electronic device 130 to communicate with one or more other electronic devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 135. Furthermore, the electronic device 130 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 136. As shown, the network adapter 136 communicates with other modules for the electronic device 130 via a bus 133. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0187] In an exemplary embodiment, a storage medium is also provided, and when a computer program in the storage medium is executed by a processor of an electronic device, the electronic device can perform the above-mentioned method for determining the duration of communication interruption. Optionally, the storage medium can be a non-temporary computer-readable storage medium, for example, the non-temporary computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0188] In an exemplary embodiment, the electronic device of the present application may include at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program executable by the at least one processor, and when the computer program is executed by the at least one processor, the at least one processor may execute the steps of any method for determining the duration of a communication interruption provided in an embodiment of the present application.

[0189] In an exemplary embodiment, a computer program product is also provided. When the computer program product is executed by an electronic device, the electronic device can implement any exemplary method provided in the present application.

[0190] Furthermore, the computer program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a RAM, a ROM, an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0191] The program product for determining the duration of communication interruption in the embodiment of the present application may adopt a CD-ROM and include program code, and may be run on a computing device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, apparatus, or device.

[0192] The readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, wherein the readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable signal medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0193] The program code contained on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.

[0194] The program code for performing the operation of the present application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and also conventional procedural programming languages ​​such as "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device, partially on the remote computing device, or completely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network such as a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect through the Internet).

[0195] It should be noted that, although several units or subunits of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided into multiple units to be embodied.

[0196] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0197] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0198] The present application is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0199] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0200] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0201] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0202] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for determining the duration of a communication interruption, characterized in that: Applied to a client, the method comprises: When the data collection cycle arrives, a request message based on the Modbus protocol is sent to the server; Determine whether a response message sent by the server is received within a preset receiving time, and determine whether it is a line fault according to the reception result of the response message; When it is determined to be a line fault, the current time is determined as the fault start time; Determining whether a restart condition is met based on a reception result of a response message corresponding to a preset first number of request messages after a line failure; When it is determined that the restart condition is met, restart the client to re-establish a connection with the server; The duration of the communication interruption is determined based on the fault start time, the fault end time when the connection is restored, and the data collection cycle.

2. The method according to claim 1, characterized in that The determining whether the restart condition is met based on the reception result of the response message corresponding to the preset first number of request messages after the line failure includes: If the preset first number of request messages do not receive corresponding response messages within the preset receiving time period, it is determined that the restart condition is met; or Among the preset first number of request messages, if any request message receives a corresponding response message within the preset receiving time length, and it is determined that the connection has not been restored based on the reception result of the response message corresponding to the preset second number of request messages after the received response message, then it is determined that the restart condition is met.

3. The method according to claim 2, characterized in that Determine whether the connection is restored by: Parsing the response messages corresponding to the preset second number of request messages to determine the parsing result of each response message; Based on the parsing results of each response message, determine whether each response message is an error response message; If all the response messages corresponding to the preset second number of request messages are error response messages, it is determined that the connection has not been restored; If the response message corresponding to any request message among the preset second number of request messages is not an error response message, it is determined that the connection is restored.

4. The method according to claim 3, characterized in that The determining, based on the parsing result of each response message, whether each response message is an error response message includes: For any target response message, compare the first transaction identifier of the target response message with the second transaction identifier of the request message corresponding to the target response message; If the first transaction identifier is consistent with the second transaction identifier, determining that the target response message is not an error response message; If the first transaction identifier is inconsistent with the second transaction identifier, it is determined that the target response message is an error response message.

5. The method according to claim 1, characterized in that Determining the duration of the communication interruption based on the fault start time, the fault end time when the connection is restored, and the data collection cycle includes: Determine the fault duration based on the difference between the fault end time and the fault start time; Determining the number of data collection cycles based on the sum of the ratio between the fault duration and the data collection cycle and a preset value; The product of the number of data collection cycles and the data collection cycle is determined as the communication interruption duration.

6. The method according to claim 5, characterized in that After determining the duration of the communication interruption, the method further includes: Determining the communication interruption start time based on the difference between the fault end time and the communication interruption duration; Determine the fault end time as the communication interruption end time; A communication interruption interval is determined based on the communication interruption start time and the communication interruption end time.

7. A device for determining the duration of communication interruption, characterized in that: Applied to a client, the device comprises: The sending module is used to send a request message based on the Modbus protocol to the server when the data collection cycle arrives; A first determination module, used to determine whether a response message sent by the server is received within a preset receiving time, and determine whether it is a line fault according to the reception result of the response message; A second determination module, for determining the current time as the fault start time when a line fault is determined; A third determination module, configured to determine whether a restart condition is met based on a reception result of a response message corresponding to a preset first number of request messages after a line failure; A restart module, configured to restart the client to re-establish a connection with the server when it is determined that the restart condition is met; The fourth determination module is used to determine the duration of the communication interruption based on the fault start time, the fault end time when the connection is restored, and the data collection cycle.

8. An electronic device, characterized in that: include: at least one processor, and a memory communicatively connected to the at least one processor, wherein: The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can perform the method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: When the computer program in the storage medium is executed by a processor of an electronic device, the electronic device can execute the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that When the computer program product is called and executed by an electronic device, the electronic device is enabled to execute the method according to any one of claims 1 to 6.

Images