CN115529225B

CN115529225B - Equipment fault diagnosis method and device

Info

Publication number: CN115529225B
Application number: CN202211173907.9A
Authority: CN
Inventors: 孟伟; 王明慧; 姜哲华; 李辉; 邓志吉; 刘明; 周俊杰; 袁文君; 姚仲亮; 孔维生
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2022-09-26
Filing date: 2022-09-26
Publication date: 2024-07-12
Anticipated expiration: 2042-09-26
Also published as: CN115529225A

Abstract

The application discloses a device fault diagnosis method and device, which are used for realizing efficient fault diagnosis of fault devices in remote areas, so as to quickly and effectively repair faults of the fault devices. The method provided by the application comprises the following steps: determining a fault device which cannot communicate with a cloud platform and at least one candidate device which is within a preset range from the fault device and can communicate with the cloud platform and the fault device at present; and determining a proxy node from the at least one candidate device, and realizing remote fault diagnosis of the fault device through communication between the proxy node and the cloud platform and between the proxy node and the fault device, wherein the proxy node and the fault device are communicated through long-distance radio.

Description

Equipment fault diagnosis method and device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a device fault diagnosis method and apparatus.

Background

In the situations of inconvenient power supply and network deployment, such as fishponds, construction sites and the like, the monitoring equipment is generally required to be powered in a solar panel and battery mode, meanwhile, a cellular 4G or 5G network is adopted to realize the access of a monitoring platform, and then video pushing is carried out through the cellular network. However, over time, version updates of network monitoring devices such as base stations, core networks, etc., aging of monitoring device components, and iterations of version updates of monitoring device software may all cause monitoring device failures. Particularly, because the monitoring equipment with low power consumption is deployed on a high pole of a remote pasture area or a construction area in a network fault mode, once the network abnormality occurs, the conventional solution is that a technician arrives at the site to analyze the field problem through connection of a wired network and the monitoring equipment, and the process consumes manpower resources and time cost very much.

Disclosure of Invention

The embodiment of the application provides a device fault diagnosis method and device, which are used for realizing efficient fault diagnosis of fault devices in remote areas, so that the fault devices can be quickly and effectively repaired.

On the cloud platform side, the device fault diagnosis method provided by the embodiment of the application comprises the following steps:

determining a fault device which cannot communicate with a cloud platform and at least one candidate device which is within a preset range from the fault device and can communicate with the cloud platform and the fault device at present;

And determining a proxy node from the at least one candidate device, and realizing remote fault diagnosis of the fault device through communication between the proxy node and the cloud platform and between the proxy node and the fault device, wherein the proxy node and the fault device are communicated through long-distance radio.

In the embodiment of the application, the fault equipment which cannot communicate with the cloud platform and at least one candidate equipment which can communicate with the cloud platform and the fault equipment at present and has the distance within the preset range with the fault equipment are determined; and determining a proxy node from the at least one candidate device, and implementing remote fault diagnosis on the fault device through communication between the proxy node and the cloud platform as well as between the proxy node and the fault device, wherein the proxy node and the fault device are in communication through long-distance radio, so that a long-distance radio communication mode is utilized, and efficient diagnosis on the fault device in a remote area is implemented through proxy nodes near the fault device, so that quick and effective fault repair on the fault device can be implemented.

In some embodiments, the proxy node is a device, of the at least one candidate device, capable of long-range radio communication with the failed device with a minimum spreading factor.

In some implementations, determining a proxy node from the at least one candidate device includes:

transmitting a remote fault diagnosis instruction to m candidate devices, wherein the remote fault diagnosis instruction is used for indicating the m candidate devices to power up a remote radio module; wherein m is an integer greater than or equal to 1;

and enabling the m candidate devices to execute a device detection link, wherein the device detection link comprises multiple rounds of detection, and each round of detection comprises:

Transmitting a device detection instruction for detecting the fault device to k candidate devices, wherein the device detection instruction carries the spreading factor and the device detection time information required by the remote radio communication between the candidate devices indicated by the round and the fault device; wherein k is less than or equal to m;

Receiving device detection results of the k candidate devices, judging whether the candidate devices in the round can carry out remote radio communication with the fault device according to the device detection results, if so, selecting one candidate device from the candidate devices in the round, which can carry out remote radio communication with the fault device, notifying the fault device of reducing the spread spectrum factor by one, and triggering the next round of detection; otherwise, determining the spreading factor of the round plus one as the optimal spreading factor, and selecting one device with the best current cellular network quality from the k candidate devices as a proxy node.

In some embodiments, the method further comprises:

and sending an ending remote fault diagnosis instruction to other candidate devices except the proxy node in the k candidate devices, wherein the ending remote fault diagnosis instruction is used for indicating the other candidate devices to power down a remote radio module.

In some embodiments, through communication between the proxy node and the cloud platform, the fault device, remote fault diagnosis of the fault device is achieved, including:

Acquiring a remote operation instruction aiming at the fault equipment and sent by a client, and sending the remote operation instruction to the fault equipment through the proxy node;

And acquiring an execution result of the remote operation instruction by the fault equipment sent by the proxy node, and forwarding the execution result to the client.

On the device side, the device fault diagnosis method provided by the embodiment of the application comprises the following steps:

When the remote fault diagnosis task is triggered, controlling a remote radio module in the local equipment to be powered on;

Judging whether the local equipment is a fault equipment which cannot communicate with the cloud platform, and executing a remote fault diagnosis task according to a judging result, wherein the remote fault diagnosis of the fault equipment is realized through communication between a remote radio and other equipment.

In some embodiments, if the local device is the fault device, the performing a remote fault diagnosis task according to the determination result includes:

setting a spreading factor adopted by the long-range radio module to a maximum value, and waiting for receiving signals of other devices;

if the current equipment detection link is in, and the longest detection time allowed by the current wheel detection arrives, the method comprises the following steps:

Judging whether a detection packet of other equipment is received within the longest detection time allowed by the current detection, if so, continuing to perform the next detection, otherwise, adding one to the spread spectrum factor adopted by the remote radio module, and ending the equipment detection link;

If the current detection link is not in the equipment detection link or the longest detection time allowed by the current detection is not reached, the method comprises the following steps:

when receiving the detection packet sent by the other equipment, sending a reply packet to the other equipment;

When receiving a spreading factor adjustment instruction sent by the other equipment, adjusting the spreading factor adopted by the remote radio module according to the spreading factor adjustment instruction;

when receiving a proxy node setting instruction sent by the other equipment, recording the identification of the proxy node and waiting for receiving a signal of the proxy node;

When a remote operation instruction from a client side aiming at the fault equipment, which is forwarded by the proxy node, is received, the remote operation instruction is executed, and an execution result is sent to the proxy node;

When a fault repairing instruction which is forwarded by the proxy node and is aimed at the fault equipment is received, repairing the fault of the local equipment according to the fault repairing instruction.

In some embodiments, if the local device is not the faulty device, the performing a remote fault diagnosis task according to the determination result includes:

When a device detection instruction sent by the cloud platform is received, sending a detection packet to the fault device by adopting a specified spread spectrum factor through the remote radio module within a specified time according to the device detection instruction, and if a reply packet of the fault device is received, generating a device detection result according to the reply packet and reporting the device detection result to the cloud platform;

when a command of resetting the spreading factor of the fault equipment sent by the cloud platform is received, the command of resetting the spreading factor of the fault equipment is sent to the fault equipment, wherein the fault equipment is instructed to reduce the spreading factor by one;

powering down the remote radio module when a remote fault diagnosis instruction sent by the cloud platform is received;

When a remote operation instruction which is forwarded by the cloud platform and is directed at the fault equipment from a client side is received, forwarding the remote operation instruction to the fault equipment;

when receiving an execution result of the remote operation instruction sent by the fault equipment, forwarding the execution result to the cloud platform;

and when a fault repair instruction, which is forwarded by the cloud platform and is directed at the fault equipment, is received, forwarding the fault repair instruction to the fault equipment, and powering down the remote radio module.

The device fault diagnosis device provided by the embodiment of the application comprises a memory, a transceiver and a processor:

a memory for storing a computer program; a transceiver for transceiving data under control of the processor; a processor for reading the computer program in the memory and performing any of the methods described above.

Another embodiment of the present application provides a processor-readable storage medium storing a computer program for causing the processor to perform any one of the methods described above.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic diagram of a network architecture according to an embodiment of the present application;

Fig. 2 is a general flow diagram of an equipment fault diagnosis method on the cloud platform side according to an embodiment of the present application;

fig. 3 is a general flow diagram of an apparatus fault diagnosis method on an apparatus side according to an embodiment of the present application;

Fig. 4 is a schematic structural diagram of a monitoring device according to an embodiment of the present application;

fig. 5 is a specific flow diagram of an equipment fault diagnosis method on the cloud platform side according to an embodiment of the present application;

Fig. 6 is a specific flow diagram of an apparatus fault diagnosis method on an apparatus side according to an embodiment of the present application;

Fig. 7 is a schematic flowchart of a specific process for performing a remote fault diagnosis task on the device side according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an apparatus fault diagnosis device on a cloud platform side according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an apparatus fault diagnosis device on an apparatus side according to an embodiment of the present application.

Detailed Description

In the embodiment of the invention, the term "and/or" describes the association relation of the association objects, which means that three relations can exist, for example, a and/or B can be expressed as follows: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.

The term "plurality" in embodiments of the present application means two or more, and other adjectives are similar.

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The method and the device are based on the same application, and because the principles of solving the problems by the method and the device are similar, the implementation of the device and the method can be referred to each other, and the repetition is not repeated.

The terms first, second and the like in the description and in the claims of embodiments of the application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The following examples and embodiments are to be construed as illustrative only. Although the specification may refer to "an", "one", or "some" example or embodiment(s) at several points, this does not mean that each such reference is related to the same example or embodiment, nor that the feature is applicable to only a single example or embodiment. Individual features of different embodiments may also be combined to provide further embodiments. Furthermore, terms such as "comprising" and "including" should be understood not to limit the described embodiments to consist of only those features already mentioned; such examples and embodiments may also include features, structures, units, modules, etc. that are not specifically mentioned.

The technical scheme provided by the embodiment of the application can be suitable for various systems, in particular to a 5G system. For example, applicable systems may be global system for mobile communications (Global System of Mobile communication, GSM) system, code division multiple access (Code Division Multiple Access, CDMA) system, wideband code division multiple access (Wideband Code Division Multiple Access, WCDMA) General Packet Radio Service (GPRS) system, long term evolution (Long Term Evolution, LTE) system, LTE frequency division duplex (Frequency Division Duplex, FDD) system, LTE time division duplex (Time Division Duplex, TDD), long term evolution-advanced (Long Term Evolution Advanced, LTE-a) system, universal mobile system (Universal Mobile Telecommunication System, UMTS), worldwide interoperability for microwave access (Worldwide interoperability for Microwave Access, wiMAX) system, 5G New air interface (New Radio, NR) system, etc. Terminal devices and network devices are included in these various systems. Core network parts may also be included in the system, such as Evolved packet system (Evolved PACKET SYSTEM, EPS), 5G system (5 GS), etc.

The terminal device according to the embodiment of the present application may be any device, for example, a monitoring device, or may be a device that provides voice and/or data connectivity to a user, a handheld device with a wireless connection function, or other processing device connected to a wireless modem. The names of the terminal devices may also be different in different systems, for example in a 5G system, the terminal devices may be referred to as User Equipment (UE). The wireless terminal device may communicate with one or more Core Networks (CNs) via the RAN, which may be mobile terminal devices such as mobile phones (or "cellular" phones) and computers with mobile terminal devices, e.g., portable, pocket, hand-held, computer-built-in or vehicle-mounted mobile devices that exchange voice and/or data with the radio access Network. Such as Personal communication services (Personal Communication Service, PCS) phones, cordless phones, session initiation protocol (Session Initiated Protocol, SIP) phones, wireless local loop (Wireless Local Loop, WLL) stations, personal digital assistants (Personal DIGITAL ASSISTANT, PDA) and the like. The wireless terminal device may also be referred to as a system, subscriber unit (subscriber unit), subscriber station (subscriber station), mobile station (mobile station), remote station (remote station), access point (access point), remote terminal device (remote terminal), access terminal device (ACCESS TERMINAL), user terminal device (user terminal), user agent (user agent), user equipment (user device), and embodiments of the present application are not limited.

The network device according to the embodiment of the application may include a server, a base station, etc. for implementing a cloud platform, where the base station may include a plurality of cells. A base station may also be referred to as an access point, or may refer to a device in an access network that communicates over the air-interface, through one or more sectors, with wireless terminal devices, or by other names, depending on the particular application. The network device may be configured to convert the received air frames to and from internet protocol (Internet Protocol, IP) packets as a router between the wireless terminal device and the rest of the access network, which may include an Internet Protocol (IP) communication network. The network device may also coordinate attribute management for the air interface. For example, the network device according to the embodiment of the present application may be a network device (Base Transceiver Station, BTS) in a global system for mobile communications (GSM) or Code Division Multiple Access (CDMA), a network device (NodeB) in a Wideband Code Division Multiple Access (WCDMA), an evolved network device (evolutional Node B, eNB or e-NodeB) in a Long Term Evolution (LTE) system, a 5G base station in a 5G network architecture (next generation system), a home evolved base station (Home evolved Node B, heNB), a relay node (relay node), a home base station (femto), a pico base station (pico), etc., which are not limited in the embodiment of the present application. In some network structures, the network devices may include centralized unit (centralized unit, CU) nodes and Distributed Unit (DU) nodes, which may also be geographically separated.

Multiple-input Multiple-output (Multi Input Multi Output, MIMO) transmissions may be made between the network device and the terminal device, each using one or more antennas, and the MIMO transmissions may be Single User MIMO (SU-MIMO) or Multiple User MIMO (MU-MIMO). The MIMO transmission may be 2D-MIMO, 3D-MIMO, FD-MIMO, or massive-MIMO, or may be diversity transmission, precoding transmission, beamforming transmission, or the like, depending on the form and number of the root antenna combinations.

Various embodiments of the application are described in detail below with reference to the drawings attached to the specification. It should be noted that, the display sequence of the embodiments of the present application only represents the sequence of the embodiments, and does not represent the advantages or disadvantages of the technical solutions provided by the embodiments.

Referring to fig. 1, a network structure schematic diagram provided in an embodiment of the present application includes a plurality of monitoring devices, a base station, a cloud platform (server), a client for maintaining a network by a worker, and the like. In the embodiment of the application, a remote radio module is arranged in the monitoring equipment, so that the monitoring equipment can communicate through a remote radio (lora link), thereby solving the problems of time and labor consumption, high cost, high power consumption and the like of the monitoring equipment in a low-power-consumption scene network fault diagnosis scheme.

The technical scheme provided by the embodiment of the application is described below from different sides respectively.

On the cloud platform side, referring to fig. 2, the device fault diagnosis method provided by the embodiment of the application includes:

S101, determining a fault device (such as a monitoring device) which cannot communicate with a cloud platform, and at least one candidate device (such as a plurality of candidate monitoring devices) which is within a preset range (such as 15 KM) from the fault device and can communicate with the cloud platform and the fault device at present;

S102, determining a proxy node from the at least one candidate device, and realizing remote fault diagnosis of the fault device through communication between the proxy node and the cloud platform and between the proxy node and the fault device, wherein communication is carried out between the proxy node and the fault device through long-distance radio (namely, communication is carried out through a lora link established by a lora module).

In some embodiments, the proxy node is a device, of the at least one candidate device, capable of long-range radio communication with the failed device with a minimum Spreading Factor (SF). The smaller the SF, the lower the power consumption and the faster the rate.

The at least one candidate device, e.g., m candidate devices; in some implementations, determining a proxy node from the at least one candidate device includes:

step one, transmitting equipment detection instructions for detecting the fault equipment to k candidate equipment, wherein the equipment detection instructions carry spread spectrum factors and equipment detection time information required by remote radio communication between the candidate equipment indicated by the round and the fault equipment; wherein k is less than or equal to m;

Step two, receiving device detection results of the k candidate devices, judging whether the candidate devices in the round can carry out remote radio communication with the fault device according to the device detection results, if so, selecting one candidate device from the candidate devices in the round, which can carry out remote radio communication with the fault device, notifying the fault device that the spread spectrum factor is reduced by one, and triggering the next round of detection; otherwise, determining the spreading factor of the round plus one as the optimal spreading factor, and selecting a proxy node from the k candidate devices, for example, selecting the device with the best quality of the current cellular network as the proxy node.

In some embodiments, the method further comprises:

And sending an ending remote fault diagnosis instruction to other candidate devices except the proxy node in the k candidate devices, wherein the ending remote fault diagnosis instruction is used for instructing the other candidate devices to power down a remote radio module, so that energy consumption is saved.

Acquiring a remote operation instruction for the fault equipment, which is sent by a client (such as a client used by a staff for network maintenance), and sending the remote operation instruction to the fault equipment through the proxy node;

Accordingly, referring to fig. 3, on the device side, the method for diagnosing a device fault provided by the embodiment of the application includes:

s201, when a remote fault diagnosis task is triggered, controlling a remote radio module in the local equipment to be powered on;

Triggering conditions in which a remote fault diagnosis task is triggered, such as: the local equipment cannot communicate with the cloud platform or receives a remote fault diagnosis instruction sent by the cloud platform.

S202, judging whether the local equipment is a fault equipment which cannot communicate with the cloud platform, and executing a remote fault diagnosis task according to a judging result, wherein the remote fault diagnosis of the fault equipment is realized through communication between a remote radio and other equipment.

setting the spreading factor employed by the long range radio module to a maximum value (e.g., sf=12) and waiting to receive signals of other devices;

Judging whether a detection packet of other equipment is received within the longest detection time allowed by the current detection, if so, continuing to perform the next detection, otherwise, adding one spreading factor adopted by the remote radio module (namely backing to the last value), and ending the equipment detection link;

When receiving a spreading factor adjustment instruction (for example, an instruction for subtracting one SF) sent by the other equipment, adjusting the spreading factor adopted by the remote radio module according to the spreading factor adjustment instruction;

When a fault repair instruction from the client side, which is forwarded by the proxy node, is received, the fault of the local equipment is repaired according to the fault repair instruction, for example, local equipment parameters are reset and/or receiving firmware is updated.

In summary, the technical scheme provided by the embodiment of the application solves the problems of time consumption, labor consumption and high cost of needing technicians to go to the site to locate when the network failure occurs in the traditional low-power-consumption internet of things equipment; through the lora module, the intercommunication between the fault equipment with the ultra-long distance (up to 15 KM) and the proxy node is realized, and the whole scheme of remotely positioning the fault equipment by technicians is realized by utilizing the linkage of the cellular network of the proxy node and the cloud platform; and the low-cost lora module chip is adopted, equipment in a limited area of the fault equipment is waken up through the platform, the platform is based on a time division control scheme, no interference among nodes is realized, the optimal lora module is efficiently selected as a remote proxy node, and finally the other modules of the node lora chip which does not participate in the remote fault diagnosis scheme continue to be powered off and continue to be in a sleep mode, so that the power consumption of the equipment is minimized.

The technical solution provided by the embodiment of the present application is further illustrated below by taking the above fault device and the candidate device as monitoring devices.

Referring to fig. 4, the monitoring device in the embodiment of the present application specifically includes: DSP (main control module), 5G module, SIM card, power management module, lora module, image acquisition module (camera), battery, solar panel etc.. The power management module is responsible for powering on and powering off (power off) the lora module.

The long range radio (lora) module in the embodiment of the application belongs to a low-cost half-duplex single-transceiver scheme, and can only modulate and demodulate data under a certain spreading factor SF at the same time. As in the monitoring device A, B, C, D shown in system block 1, the sara module is integrated therein, and must be set to the same spreading factor to enable normal data communication. The Lora module is designed to solve the problem that in a low-power consumption scene, when a cellular network connected with a cloud platform fails, another data path is provided for providing convenience for remote diagnosis of technicians.

When the cellular network can normally register the cloud platform, the lora module does not need to participate in the service, and at the moment, the lora module is powered down through the power management module in the monitoring equipment provided by the embodiment of the application, so that the lora power consumption is reduced to 0.

Fig. 5 shows a specific process flow of a cloud platform, and fig. 6 shows a specific process flow of a monitoring device, where the specific process flow of a remote diagnosis link related to the monitoring device is shown in fig. 7, and in combination with fig. 5 to fig. 7, the device fault diagnosis method provided by the embodiment of the application specifically includes:

After the cloud platform is initialized, when the monitoring equipment and the cloud platform are authenticated by login, and after connection is established, the cloud platform can create an independent thread for processing related business of the monitoring equipment.

The position updating module in the monitoring equipment reports the position information of the monitoring equipment to the cloud platform, and the cloud platform pre-processes the position information of each monitoring equipment and stores the position information to the storage server. The location information mainly comprises two aspects, if the global navigation satellite system (Global Navigation SATELLITE SYSTEM, GNSS) module is integrated inside the monitoring equipment, and the positioning is successful (positioning failure may be caused by insufficient number of received satellites in mountain areas, high buildings or overcast and rainy weather), the longitude and latitude information of the successful positioning is directly obtained. If some monitoring devices do not integrate a GNSS module or the currently located position GNSS is not positioned successfully, the relevant position information of the cellular network is used: mobile network Code (Mobile Network Code, MNC), mobile country Code (Mobile Country Code, MCC), location area Code (location Area Code, LAC) (when the cellular module is registered with 2G or 3G), tracking area Code (TRACKING AREA Code, TAC) (when the cellular module is registered with 4G or 5G network). The cloud platform performs the following preprocessing for the non-GNSS module information: and forwarding the reported MCC, MNC, LAC or TAC information to an LBS (mobile network position location server) for position conversion to obtain rough longitude and latitude information. Currently, based on LBS location, the positional deviation is in the range of 50-1000 m.

After the monitoring equipment is powered on and the platform establishes connection, the platform receives a command, and if the current platform has a pull stream or a remote control instruction, the monitoring equipment continues to be kept in a normal power consumption mode. If the current drawing task is adopted, the monitoring equipment transmits the data acquired and encoded from the camera to the cloud platform in real time through the cellular network.

In the video transmission process, the monitoring equipment can regularly judge whether the current position changes, and if so, the latest position information is reported to the cloud platform. If the current monitoring equipment has no current drawing task, the current cloud platform can continuously judge whether the current cloud platform has a remote fault diagnosis task or not, and the remote fault diagnosis task is divided into two aspects: the method is characterized in that when the monitoring equipment fails in a network, a lora module in other monitoring equipment is needed to assist in completing fault diagnosis, and when the monitoring equipment does not fail in a cellular network, a certain monitoring equipment around the monitoring equipment fails in the network, and the monitoring equipment is requested to assist in completing fault diagnosis.

If the monitoring equipment does not have a current streaming task or a remote fault diagnosis task, the monitoring equipment enters a low-power consumption mode, and a video acquisition module (Camera) and a cellular module (SIM card) enter a low-power consumption sleep mode. At this time, two timers T1 and T2 are set, where T1 represents a time interval of keep-alive of heartbeat between the monitoring device and the platform, i.e. every time T1, the cellular module is woken up and then confirms heartbeat packets with the platform, if the heartbeat packets are abnormal several times in succession, it is considered that a network between the monitoring device and the platform is abnormal, and a network failure occurs, at this time, the monitoring device exits from the low power consumption mode and is marked as having a remote diagnosis task for the monitoring device. T2 represents a location update timer, i.e. if the monitoring device finds that the location is changed after the interval T2, the changed location information is reported to the server.

And in the process that the monitoring equipment is in the low-power consumption mode and the cloud platform wakes up the keep-alive at regular intervals, the monitoring equipment monitors whether a platform issues a task at present, and if the platform issues the task, the monitoring equipment also exits from the low-power consumption mode.

When the monitoring equipment is awakened (triggered) due to the remote fault diagnosis task, the monitoring equipment starts to enter a diagnosis link, namely the remote fault diagnosis task needs to be executed, and the link is powered on the lora module through the power management module and is initialized in a related mode. It is then determined whether the current remote fault diagnosis task is self-fault triggered or triggered by other nearby monitoring devices.

If the monitoring device is triggered by the self fault, the spreading factor SF is set to be the maximum value 12 (the larger the spreading factor is, the farther the communication distance between the lora modules is, the higher the power consumption is and the lower the speed is, and the receiving window is opened by default to wait for detection of monitoring devices by other monitoring devices. Assuming that the monitoring equipment B has network faults at a certain time point, when the monitoring equipment B detects the self faults, a thread to which the monitoring equipment belongs in the cloud platform enters a remote fault diagnosis link because a heartbeat packet of the monitoring equipment is not received for a continuous period of time. The cloud platform may search the storage server for all other monitoring devices within 15KM of the monitoring device based on the location of the fault monitoring device. For reasons of positioning errors of GNSS and LBS, in the embodiment of the application, the searching range is enlarged and adjusted to a certain extent (for example, the 15KM range is enlarged to 16 KM) according to the respective positioning error range, so that the omission of effective monitoring equipment is prevented. The search of the monitoring equipment is rough search, and K1 and K2 … … Km are arranged around the fault monitoring equipment, so that m monitoring equipment can be obtained. The cloud platform sequentially sends monitoring device detection instructions (which carry the spreading factor and device detection time information required for long-distance radio communication between the candidate device and the fault device) to the m monitoring devices.

The monitoring equipment detection described in the embodiment of the application aims at finding the optimal SF, and finding the optimal monitoring equipment from m monitoring equipment nodes as the proxy node, wherein only the proxy node participates in the subsequent remote diagnosis tasks of a platform and technicians. The optimal monitoring device is that the lora module between the monitoring device and the fault monitoring device can perform data communication with the minimum SF factor (i.e. optimal SF) (the smaller the SF, the lower the power consumption and the faster the rate). Specifically:

The monitoring device detection link may include multiple rounds, but may set up to not more than a preset round, for example, up to not more than 6 rounds (for example, SF starts to be valued from the maximum value 12, each round is decremented by one, the minimum value is 7, thus, the maximum round is 6 rounds, and the optimal SF can be found), each round has several (for example, k) monitoring devices involved, the first round starts to valued from the maximum value of SF, SF decreases by 1, if the current round monitors devices capable of communicating with the fault monitoring device, the next round is continued until all monitoring devices of the current round fail to communicate with the fault, and the current SF value is increased by 1 as the minimum spreading factor (i.e., the optimal spreading factor) that the monitoring device of the current round can perform remote radio communication with the fault device. Specifically, the first round is all m monitoring devices that search nearby, and the cloud platform can send detection tasks to m monitoring devices in proper order, and the detection tasks can determine how long the monitoring device begins at which time point to finish detection. The detection is to send a test packet at a designated time, and the fault monitoring device replies and confirms within 100ms after receiving the data packet. The whole process of the detection task is one time and one time. The specific time points are described as follows: the K1 monitoring device completes the detection within 200ms from the t1 time, the K2 monitoring device completes at 200ms from the t2=t1+200 ms time, and so on. If after the first round is finished, n monitoring devices can perform remote radio communication with the fault monitoring device (the fact that the SF adopted between the n monitoring devices and the fault monitoring device is consistent is indicated), randomly selecting one monitoring device from the n monitoring devices to inform the fault monitoring device that SF is reduced by 1, starting a second round, sending a detection task to the n monitoring devices, wherein the detection time is carried, and the like until the s-th round (s belongs to a preset range, such as [1,8 ]), assuming that the s-th round has k monitoring devices to participate, and the k monitoring devices cannot perform remote radio communication with the fault monitoring device, ending detection, and determining that the optimal SF is the SF in the previous round is the SF of the current SF plus 1. And, select one monitoring device from the k monitoring devices as a proxy node, for example, select the monitoring device with the best cellular network quality as a proxy node, or randomly select one monitoring device as a proxy node, etc.

After the current monitoring equipment receives a remote diagnosis task (namely a remote fault diagnosis command) issued by the cloud platform, if the remote diagnosis task is to assist other monitoring equipment to complete diagnosis, the current monitoring equipment firstly sets a designated SF according to an instruction of the cloud platform, and then completes detection of the fault monitoring equipment at a designated time. Monitoring equipment detection may have two conditions, one is that under the current spread spectrum factor SF setting, fault monitoring equipment can correctly receive and return, and the other is that under the current SF, the emitting distance of a lora module is insufficient, so that both sides cannot realize lora communication, the detection result of the monitoring equipment can be all returned to a cloud platform, and the fault monitoring equipment is uniformly scheduled by the cloud platform.

Considering that the position distribution of the monitoring equipment is uneven, the number of normal communication with the fault monitoring equipment continuously decreases along with the continuous decrease of SF, when all monitoring equipment cannot communicate with the fault in a certain turn, the monitoring equipment detection is stopped, and the cloud platform sends an SF back instruction to the monitoring equipment participating in the detection in the present turn through a cellular network to indicate the SF value to be increased by 1. And the maximum waiting time (namely the longest detection time) of the round detection is carried when SF is adjusted for the fault monitoring equipment in each round, if the fault monitoring equipment does not have any monitoring equipment for monitoring equipment detection within the maximum waiting time of a certain round, the SF value is set abnormally, the SF value needs to be returned to the last SF value, and the last SF value is the optimal node communication SF value.

After the optimal SF is found, if a plurality of monitoring devices can normally communicate with the fault monitoring device under the optimal SF, the cloud platform randomly selects one monitoring device with the best quality of the current cellular network as a proxy node, and the cloud platform can issue a remote diagnosis ending instruction to other monitoring device nodes. The monitoring device not selected as the proxy node can close the remote fault diagnosis flow, and the power-down operation of the lora module is completed through the power management module to be continuously switched into the sleep mode.

The monitoring device selected as the proxy node may continue to monitor the remote diagnostic tasks of the cloud platform in the normal power consumption mode. The cloud platform forwards the debug instruction sent by the technician to the proxy node. After receiving the data, the proxy node firstly judges whether a transmit token (token) is currently held, and in order to ensure efficient data transmission between the proxy node and the fault node and prevent unnecessary protocol overhead, the embodiment of the application agrees that only the node holding the transmit token can transmit the data and does not have to be in a receiving state. The default initial proxy node has a transmit token, and the proxy node continuously transmits all instructions issued by the current platform to the fault node. And the proxy node releases the token to the fault node until no data to be transmitted exists. The fault node receives the diagnosis instruction forwarded by the proxy node and then sequentially executes the diagnosis instruction in the background, if the fault node has a transmit token at the moment, the execution result is continuously transmitted to the proxy node, and if the fault node has no data to be transmitted for a period of time, such as 100ms, the transmit token is released to the proxy node again. This cycle proceeds until the remote diagnosis is completed.

And when the proxy node and the fault monitoring equipment receive the diagnosis ending instruction, the diagnosis mode is also exited, and the sleep state is re-entered.

In summary, the embodiments of the present application provide a device, a system, and a method adapted to remote fault diagnosis of a low-power consumption monitoring device, which implement intercommunication between a fault monitoring device and a proxy monitoring device with an ultra-long distance (15 KM max) through system integration of the fault monitoring device, an optimal proxy node, and a platform, and then implement real-time remote diagnosis and problem repair of the fault monitoring device by a technician through a cellular link of the proxy node and a cloud platform; based on a cloud platform time division control scheme, a method for quickly finding an optimal lora module without interference between nodes is realized, and efficient data transmission between fault monitoring equipment and proxy nodes is realized based on a token scheme.

Based on the same inventive concept, the explanation or illustration of the same or corresponding technical features as those described in the above method will be described below, and the description will not be repeated.

On the network side, referring to fig. 8, for example, the cloud platform side, an apparatus fault diagnosis device provided in an embodiment of the present application includes:

the processor 500, configured to read the program in the memory 520, performs the following procedures:

In some embodiments, the processor 500 is further configured to read the program in the memory 520, and perform the following procedure:

A transceiver 510 for receiving and transmitting data under the control of the processor 500.

Wherein in fig. 8, a bus architecture may comprise any number of interconnected buses and bridges, and in particular, one or more processors represented by processor 500 and various circuits of memory represented by memory 520, linked together. The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., which are well known in the art and, therefore, will not be described further herein. The bus interface provides an interface. The transceiver 510 may be a number of elements, including a transmitter and a receiver, providing a means for communicating with various other apparatus over transmission media, including wireless channels, wired channels, optical cables, and the like. The processor 500 is responsible for managing the bus architecture and general processing, and the memory 520 may store data used by the processor 500 in performing operations.

The processor 500 may be a Central Processing Unit (CPU), application SPECIFIC INTEGRATED Circuit (ASIC), field-Programmable gate array (Field-Programmable GATE ARRAY, FPGA), or complex Programmable logic device (Complex Programmable Logic Device, CPLD), or may employ a multi-core architecture.

On the terminal side, referring to fig. 9, for example, on the monitoring device side, an apparatus fault diagnosis apparatus provided in an embodiment of the present application includes:

The processor 600, configured to read the program in the memory 620, performs the following procedures:

A transceiver 610 for receiving and transmitting data under the control of the processor 600.

Wherein in fig. 9, a bus architecture may comprise any number of interconnected buses and bridges, and in particular one or more processors represented by processor 600 and various circuits of memory represented by memory 620, linked together. The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., which are well known in the art and, therefore, will not be described further herein. The bus interface provides an interface. The transceiver 610 may be a number of elements, i.e., including a transmitter and a receiver, providing a means for communicating with various other apparatus over transmission media, including wireless channels, wired channels, optical cables, etc. The user interface 630 may also be an interface capable of interfacing with an inscribed desired device for different user devices, including but not limited to a keypad, display, speaker, microphone, joystick, etc.

The processor 600 is responsible for managing the bus architecture and general processing, and the memory 620 may store data used by the processor 600 in performing operations.

In some embodiments, the processor 600 may be a CPU (central processing unit), an ASIC (Application SPECIFIC INTEGRATED Circuit), an FPGA (Field-Programmable gate array) or a CPLD (Complex Programmable Logic Device ), and the processor may also employ a multi-core architecture.

The processor is operable to perform any of the methods provided by embodiments of the present application in accordance with the obtained executable instructions by invoking a computer program stored in a memory. The processor and the memory may also be physically separate.

It should be noted that, the above device provided in the embodiment of the present invention can implement all the method steps implemented in the method embodiment and achieve the same technical effects, and detailed descriptions of the same parts and beneficial effects as those in the method embodiment in this embodiment are omitted.

An embodiment of the present application provides a processor-readable storage medium storing a computer program for causing the processor to execute any of the methods provided in the embodiments of the present application described above.

The processor-readable storage medium may be any available medium or data storage device that can be accessed by a processor, including, but not limited to, magnetic storage (e.g., floppy disks, hard disks, magnetic tape, magneto-optical disks (MOs), etc.), optical storage (e.g., CD, DVD, BD, HVD, etc.), and semiconductor storage (e.g., ROM, EPROM, EEPROM, non-volatile storage (NAND FLASH), solid State Disk (SSD)), etc.

Embodiments of the present application also provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the method of any of the above embodiments. The program product may employ 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 can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

It should be understood that:

The access technology via which an entity in the communication network communicates traffic may be any suitable current or future technology, such as WLAN (wireless local access network), wiMAX (worldwide interoperability for microwave access), LTE-a, 5G, bluetooth, infrared, etc. may be used; in addition, embodiments may also apply wired technologies, e.g., IP-based access technologies, such as wired networks or fixed lines.

Embodiments suitable for implementation as software code or a portion thereof and operation using a processor or processing function are software code independent and may be specified using any known or future developed programming language, such as a high-level programming language, such as an object-C, C, C ++, c#, java, python, javascript, other scripting language, etc., or a low-level programming language, such as a machine language or assembler.

The implementation of the embodiments is hardware-independent and may be implemented using any known or future developed hardware technology or any hybrid thereof, such as microprocessors or CPUs (central processing units), MOS (metal oxide semiconductors), CMOS (complementary MOS), biMOS (bipolar MOS), biCMOS (bipolar CMOS), ECL (emitter coupled logic), and/or TTL (transistor-transistor logic).

Embodiments may be implemented as a single device, apparatus, unit, component, or function, or in a distributed fashion, e.g., one or more processors or processing functions may be used or shared in a process, or one or more processing segments or portions may be used and shared in a process where one physical processor or more than one physical processor may be used to implement one or more processing portions dedicated to a particular process as described.

The apparatus may be implemented by a semiconductor chip, a chipset, or a (hardware) module comprising such a chip or chipset.

Embodiments may also be implemented as any combination of hardware and software, such as an ASIC (application specific IC (integrated circuit)) component, an FPGA (field programmable gate array) or CPLD (complex programmable logic device) component, or a DSP (digital signal processor) component.

Embodiments may also be implemented as a computer program product comprising a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to perform a process as described in the embodiments, wherein the computer usable medium may be a non-transitory medium.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

1. A method of diagnosing a device fault, the method comprising:

Determining a fault device which cannot communicate with a cloud platform, determining position information of the fault device, and determining at least one candidate device which can communicate with the cloud platform and the fault device at present and has a distance within a preset range from the fault device based on the position information of the fault device; wherein long-range radio communication is enabled between the candidate device and the malfunctioning device;

Determining a proxy node from the at least one candidate device, and realizing remote fault diagnosis of the fault device through communication between the proxy node and the cloud platform and between the proxy node and the fault device, wherein the proxy node and the fault device are communicated through remote radio;

The remote fault diagnosis of the fault equipment is realized through the communication between the proxy node and the cloud platform as well as between the proxy node and the fault equipment, and the remote fault diagnosis method comprises the following steps:

2. The method of claim 1, wherein the proxy node is a device of the at least one candidate device that is capable of long-range radio communication with the failed device with a minimum spreading factor.

3. The method of claim 1, wherein determining a proxy node from the at least one candidate device comprises:

4. A method according to claim 3, characterized in that the method further comprises:

5. A method of diagnosing a device fault, the method comprising:

Judging whether the local equipment is fault equipment which cannot be communicated with the cloud platform or not, and executing a remote fault diagnosis task according to a judging result, wherein the remote fault diagnosis task comprises the step of realizing remote fault diagnosis of the fault equipment through communication between the remote radio module and other equipment; when the local equipment is the fault equipment, the other equipment is a proxy node; when the other equipment is the fault equipment, the local equipment is a proxy node; the agent node is determined by a cloud platform in the following manner:

determining a fault device which cannot communicate with the cloud platform, determining position information of the fault device, and determining at least one candidate device which can communicate with the cloud platform and the fault device currently, wherein the distance between the candidate device and the fault device is within a preset range based on the position information of the fault device; wherein long-range radio communication is enabled between the candidate device and the malfunctioning device;

Determining a proxy node from the at least one candidate device;

Wherein, through the communication between long-range radio module and other equipment, realize the long-range fault diagnosis to the trouble equipment, include:

when the local equipment is the proxy node, acquiring a remote operation instruction from a client side forwarded by the cloud platform and aiming at the fault equipment, sending the remote operation instruction to the fault equipment through the remote radio module, acquiring an execution result of the remote operation instruction by the fault equipment through the remote radio module, and forwarding the execution result to the cloud platform;

when the local equipment is the fault equipment, a remote operation instruction, forwarded by the proxy node, aiming at the fault equipment is obtained through the remote radio module, an execution result of the remote operation instruction by the fault equipment is sent to the proxy node through the remote radio module, and the execution result of the remote operation instruction is respectively forwarded to the client through the proxy node and the cloud platform.

6. The method of claim 5, wherein if the local device is the faulty device, the performing a remote fault diagnosis task according to the determination result includes:

7. The method of claim 5, wherein if the local device is not the faulty device, the performing a remote fault diagnosis task according to the determination result includes:

8. A device fault diagnosis apparatus, comprising a memory, a transceiver, and a processor:

A memory for storing a computer program; a transceiver for transceiving data under control of the processor; a processor for reading the computer program in the memory and performing the method of any of claims 1 to 7.

9. A processor-readable storage medium, characterized in that the processor-readable storage medium stores a computer program for causing the processor to perform the method of any one of claims 1 to 7.