CN115529225A

CN115529225A - Equipment fault diagnosis method and device

Info

Publication number: CN115529225A
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: 2022-12-27

Abstract

The application discloses a method and a device for diagnosing equipment faults, which are used for realizing efficient fault diagnosis of fault equipment in remote areas, so that the fault equipment can be quickly and effectively repaired. The method provided by the application comprises the following steps: determining a fault device which cannot be communicated with a cloud platform and at least one candidate device which is within a preset range of distance from the fault device and can be currently communicated with the cloud platform and the fault device; and determining a proxy node from the at least one candidate device, and performing remote fault diagnosis on the fault device through communication between the proxy node and the cloud platform and the fault device, wherein the proxy node and the fault device communicate 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 method and an apparatus for diagnosing a device fault.

Background

In the scenes such as a fishpond, a construction site and the like where power supply and network deployment are inconvenient, monitoring equipment is generally required to be powered in a solar panel + battery mode, meanwhile, a cellular 4G or 5G network is adopted to achieve 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, and the like, aging of monitoring device components, and iterations of monitoring device software version updates may all cause monitoring device failures. Especially, the network faults of the monitoring equipment are mostly deployed on high poles in remote pasturing areas or construction areas, once network abnormity occurs, the conventional solution is that technicians arrive at the site and are connected with the monitoring equipment through a wired network to analyze the problems on the site, and the process consumes manpower resources and time cost.

Disclosure of Invention

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

On the cloud platform side, the method for diagnosing the equipment fault 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 of distance from the fault device and can currently communicate with the cloud platform and the fault device;

and determining a proxy node from the at least one candidate device, and performing remote fault diagnosis on the fault device through communication between the proxy node and the cloud platform and the fault device, wherein the communication between the proxy node and the fault device is performed through long-distance radio.

In the embodiment of the application, a fault device which cannot communicate with a cloud platform and at least one candidate device which is within a preset range of the distance from the fault device and can currently communicate with the cloud platform and the fault device 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 and the fault device, wherein the proxy node and the fault device communicate 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 the proxy node near the fault device, so that rapid 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 that is capable of long-range radio communication with the failed device with a minimum spreading factor.

In some embodiments, determining a proxy node from the at least one candidate device comprises:

sending a remote fault diagnosis instruction to m candidate devices for instructing the m candidate devices to power on a long-distance radio module; wherein m is an integer greater than or equal to 1;

causing the m candidate devices to perform a device detection procedure, the device detection procedure comprising a plurality of detection rounds, each detection round comprising:

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

receiving the device detection results of the k candidate devices, judging whether any candidate device in the current round can carry out long-distance radio communication with the fault device according to the device detection results, if so, selecting one candidate device from the candidate devices in the current round which can carry out long-distance radio communication with the fault device to inform the fault device of the reduction of the spreading factor by one, and triggering the next round of detection; otherwise, determining that the spreading factor plus one of the current round is the optimal spreading factor, and selecting one device with the best current cellular network quality from the k candidate devices as the proxy node.

In some embodiments, the method further comprises:

sending an end remote fault diagnosis instruction to other candidate devices of the k candidate devices except the proxy node, for instructing the other candidate devices to power down a distant radio module.

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

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 fault equipment on the remote operation instruction sent by the proxy node, and forwarding the execution result to the client.

On the device side, a device fault diagnosis method provided by the embodiment of the application includes:

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

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

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

setting the spreading factor adopted by the long-distance radio module to be the maximum value, and waiting for receiving signals of other equipment;

if the current detection link is in the equipment detection link and the longest detection time allowed by the current round of detection is reached, then:

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

if the current detection is not in the equipment detection link, or the longest detection time allowed by the current round of detection does not arrive, then:

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

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

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

when a remote operation instruction which is forwarded by the agent node and aims at the fault equipment is received, the remote operation instruction is executed, and an execution result is sent to the agent node;

and when a fault repairing instruction aiming at the fault equipment and forwarded by the proxy node 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 an equipment detection instruction sent by the cloud platform is received, a detection packet is sent to the fault equipment by adopting a specified spread spectrum factor through the long-distance radio module within a specified time according to the equipment detection instruction, and if a reply packet of the fault equipment is received, an equipment detection result is generated according to the reply packet and reported to the cloud platform;

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

powering off the remote radio module when receiving a remote fault diagnosis ending instruction sent by the cloud platform;

when a remote operation instruction which is forwarded by the cloud platform and aims at the fault equipment is received, forwarding the remote operation instruction to the fault equipment;

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

when a fault repairing instruction which is forwarded by the cloud platform and aims at the fault equipment is received, the fault repairing instruction is forwarded to the fault equipment, and the long-distance radio module is powered off.

The device for diagnosing the equipment fault 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 above methods.

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

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

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

fig. 2 is a schematic general flow chart of an apparatus fault diagnosis method on the cloud platform side according to an embodiment of the present disclosure;

fig. 3 is a schematic general flowchart 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 apparatus according to an embodiment of the present application;

fig. 5 is a schematic specific flowchart of an apparatus fault diagnosis method on the cloud platform side according to an embodiment of the present disclosure;

fig. 6 is a schematic specific flowchart of an apparatus fault diagnosis method on an apparatus side according to an embodiment of the present application;

fig. 7 is a schematic specific flowchart of the device side executing a remote fault diagnosis task 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 disclosure;

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

The term "and/or" in the embodiments of the present invention describes an association relationship of associated objects, and indicates that three relationships may exist, for example, a and/or B may indicate: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

In the embodiments of the present application, the term "plurality" means two or more, and other terms are similar thereto.

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The method and the device are based on the same application concept, and because the principles of solving the problems of the method and the device are similar, the implementation of the device and the method can be mutually referred, and repeated parts are not described again.

The terms "first," "second," and the like in the description and in the claims of the embodiments of the application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Moreover, 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 understood as merely illustrative examples. While this specification may refer to "an," "one," or "some" example or embodiment in several places, this does not imply that each such reference relates to the same example or embodiment, nor that the feature only applies to a single example or embodiment. Individual features of different embodiments may also be combined to provide further embodiments. Furthermore, terms such as "comprising" and "comprises" should be understood as not limiting the described embodiments to consist of only those features that have been mentioned; such examples and embodiments may also include features, structures, elements, modules, etc. not specifically mentioned.

The technical scheme provided by the embodiment of the application can be suitable for various systems, especially 5G systems. For example, the applicable System may be a Global System for Mobile communications (GSM) System, a Code Division Multiple Access (CDMA) System, a Wideband Code Division Multiple Access (WCDMA) General Packet Radio Service (General Packet Radio Service, GPRS) System, a Long Term Evolution (Long Term Evolution, LTE) System, a LTE Frequency Division Duplex (Frequency Division Duplex, FDD) System, a LTE Time Division Duplex (Time Division Duplex, TDD), a Long Term Evolution (Long Term Evolution Advanced, LTE-a) System, a Universal Mobile telecommunications System (Universal Mobile telecommunications System, UMTS), a Worldwide Interoperability for Mobile Access (WiMAX) System, a New Radio Access (NR 5, wiMAX) System, etc. These various systems include terminal devices and network devices. The System may further include a core network portion, such as an Evolved Packet System (EPS), a 5G System (5 GS), and the like.

The terminal device according to the embodiments of the present application may be any device, such as a monitoring device, a device providing voice and/or data connectivity to a user, a handheld device having a wireless connection function, or another processing device connected to a wireless modem. In different systems, the names of the terminal devices may be different, for example, in a 5G system, the terminal device may be called a User Equipment (UE). Wireless terminal devices, which may be mobile terminal devices such as mobile telephones (or "cellular" telephones) and computers with mobile terminal devices, for example, portable, pocket, hand-held, computer-included, or vehicle-mounted mobile devices, may communicate with one or more Core Networks (CNs) via the RAN, and may exchange speech and/or data with a radio access Network. Examples of such devices include Personal Communication Service (PCS) phones, cordless phones, session Initiation Protocol (SIP) phones, wireless Local Loop (WLL) stations, personal Digital Assistants (PDAs), and the like. The wireless terminal device may also be referred to as a system, a subscriber unit (subscriber unit), a subscriber station (subscriber station), a mobile station (mobile station), a remote station (remote station), an access point (access point), a remote terminal (remote terminal), an access terminal (access terminal), a user terminal (user terminal), a user agent (user agent), and a user device (user device), which is not limited in this embodiment.

The network device according to the embodiment of the present application may include a server and a base station for implementing a cloud platform, and the base station may include a plurality of cells. A base station may also be referred to as an access point, or 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 interconvert received air frames and 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) communications network. The network device may also coordinate attribute management for the air interface. For example, the network device related to the embodiment of the present application may be a global system for mobile communications (GSM) or a network device (BTS) in Code Division Multiple Access (CDMA), or a network device (NodeB) in bandwidth code division multiple access (WCDMA), or an evolved Node B (eNB or e-NodeB) in a Long Term Evolution (LTE) system, or a 5G Base Station in a 5G network architecture (next generation system), or a Home evolved Node B (HeNB), a relay Node, a Home Base Station (femto), or a pico Base Station (pico), which is not limited in the embodiment of the present application. In some network architectures, a network device may include a Centralized Unit (CU) node and a Distributed Unit (DU) node, which may also be geographically separated.

Multiple Input Multiple Output (MIMO) transmission may be performed between the network device and the terminal device by using one or more antennas, where the MIMO transmission may be Single User MIMO (SU-MIMO) or Multi-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 root antenna combinations.

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

Referring to fig. 1, a schematic diagram of a network structure provided in the embodiment of the present application includes a plurality of monitoring devices, a base station, a cloud platform (server), a client used by a worker for maintaining a network, 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 with each other through remote radio (lora link), and 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 are solved.

The technical solutions provided by the embodiments of the present application are described below from different sides, respectively.

On the cloud platform side, referring to fig. 2, an apparatus fault diagnosis method provided in an embodiment of the present application includes:

s101, determining a fault device (such as a monitoring device) incapable of communicating 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) of distance from the fault device and can currently communicate with the cloud platform and the fault device;

and 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 the fault device, wherein the proxy node and the fault device communicate through long-distance radio (namely, the proxy node communicates 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 that is capable of long-range radio communication with the faulty 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 embodiments, determining a proxy node from the at least one candidate device comprises:

step one, sending a device detection instruction for detecting the fault device to k candidate devices, wherein the device detection instruction carries spreading factors and device detection time information required by long-distance radio communication between the candidate devices and the fault device indicated in the current round; wherein k is less than or equal to m;

step two, receiving the device detection results of the k candidate devices, judging whether any candidate device can carry out long-distance radio communication with the fault device in the current round according to the device detection results, if so, selecting one candidate device from the candidate devices which can carry out long-distance radio communication with the fault device in the current round to inform the fault device of reducing the spreading factor by one, and triggering the next round of detection; otherwise, determining the spreading factor of the current 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 end remote fault diagnosis instruction to other candidate devices except the proxy node in the k candidate devices, wherein the end remote fault diagnosis instruction is used for instructing the other candidate devices to power down a long-distance radio module, so that the energy consumption is saved.

acquiring a remote operation instruction aiming at the fault equipment sent by a client (such as a client used by a network maintenance worker), and sending the remote operation instruction to the fault equipment through the proxy node;

Correspondingly, referring to fig. 3, on the device side, a device fault diagnosis method provided in an embodiment of the present application includes:

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

the triggering conditions in which the remote fault diagnosis task is triggered include, for example: 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 fault equipment which cannot communicate with the cloud platform, and executing a remote fault diagnosis task according to a judgment result, wherein the remote fault diagnosis of the fault equipment is realized through communication between remote radio and other equipment.

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

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

if the current detection link is in the equipment detection link and the longest detection time allowed by the current detection is reached, then:

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

when a spreading factor adjustment instruction (for example, an instruction of subtracting one from SF) sent by the other device is received, adjusting a spreading factor adopted by the remote radio module according to the spreading factor adjustment instruction;

when receiving an agent node setting instruction sent by the other equipment, recording the identifier of the agent node, and waiting for receiving a signal of the agent node;

when a fault repairing instruction which is forwarded by the agent node and aims at the fault equipment is received, the fault of the local equipment is repaired according to the fault repairing instruction, for example, the parameters of the local equipment are reset and/or firmware is received for upgrading.

when an equipment detection instruction sent by the cloud platform is received, a detection packet is sent to the fault equipment through the long-distance radio module by adopting a specified spreading factor within a specified time according to the equipment detection instruction, and if a reply packet of the fault equipment is received, an equipment detection result is generated according to the reply packet and reported to the cloud platform;

In summary, the technical scheme provided by the embodiment of the application solves the problems that when network faults occur in the conventional low-power-consumption internet of things equipment, technicians are required to carry out field positioning, time consumption is high, and labor cost is high; the intercommunication of the ultra-long distance (the maximum can reach 15 KM) fault equipment and the proxy node is realized through the lora module, and the whole scheme that technical personnel remotely position the fault equipment is realized by utilizing the linkage of a cellular network of the proxy node and a cloud platform; the method adopts a low-cost lora module chip, realizes the awakening of equipment in a limited area of fault equipment through a platform, realizes the interference-free and high-efficiency selection of an optimal lora module between nodes as a remote proxy node through the platform based on a time division control scheme, and finally, the lora chip of the node which does not participate in the remote fault diagnosis scheme is continuously powered off, and other modules are continuously in a sleep mode to achieve the lowest power consumption of the equipment.

The following takes the above-mentioned faulty devices and candidate devices as monitoring devices as examples, and further exemplifies the technical solutions provided by the embodiments of the present application.

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 (powering off) the lora module.

The long range radio (lora) module described in the embodiments of the present application belongs to a low-cost half-duplex single-transceiver scheme, and the lora module can only perform data modulation and demodulation under a certain spreading factor SF at the same time. The monitoring devices a, B, C and D shown in the system block diagram 1 are all integrated with one lora module, and the lora module must be set to have the same spreading factor to enable normal data communication. The Lora module is designed to solve the problem that when a cellular network connected with a cloud platform fails in a low-power-consumption scene, another data path is provided to facilitate 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 the power of the lora module is powered down and the power consumption of the lora is reduced to 0 by the power management module in the monitoring device provided by the embodiment of the application.

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

after the cloud platform is initialized, when the monitoring equipment and the cloud platform pass login authentication and connection is established, the cloud platform can create an independent thread for processing related services of the monitoring equipment.

The position updating module in the monitoring equipment can report the position information of the monitoring equipment to the cloud platform, and the cloud platform can store the position information of each monitoring equipment to the storage server after preprocessing. The position information mainly includes two aspects, if a Global Navigation Satellite System (GNSS) module is integrated in the monitoring device, and the positioning is successful (the positioning fails due to insufficient number of received satellites in mountainous areas, high buildings or rainy weather), the longitude and latitude information of the successful positioning is directly acquired. If some monitoring devices do not integrate GNSS modules or the GNSS of the current position is not successfully positioned, the related position information of the cellular network is used: mobile Network Code (MNC), mobile Country Code (MCC), location Area Code (LAC) (when the cellular module is registered in 2G or 3G), tracking Area Code (TAC) (when the cellular module is registered in 4G or 5G Network). The cloud platform performs the following preprocessing on the non-GNSS module information: and forwarding the reported MCC, MNC, LAC or TAC information to an LBS (mobile network location positioning server) for position conversion to obtain rough longitude and latitude information. Currently, the position deviation is in the range of 50-1000 m based on LBS location.

After the monitoring equipment is powered on and started and the platform is connected, the monitoring equipment receives a command with the platform, and if the current platform has a pull stream or a remote control instruction, the monitoring equipment is continuously kept in a normal power consumption mode. And if the task is a pull streaming task, 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 the current position changes, the latest position information can be reported to the cloud platform. If the current monitoring equipment does not have a pull flow task, whether a remote fault diagnosis task exists on the current cloud platform or not can be continuously judged at the moment, and the remote fault diagnosis task is divided into two aspects: firstly, when a network fault occurs in the monitoring equipment, the lora modules in other monitoring equipment are required to assist in completing fault diagnosis, and the other monitoring equipment is not in fault in the cellular network, but a certain monitoring equipment around the monitoring equipment has the network fault, and the monitoring equipment is requested to assist in completing fault diagnosis.

If the monitoring device does not have a pull flow task or a remote fault diagnosis task currently, the monitoring device enters a low power consumption mode, and at the moment, the video acquisition module (Camera) and the cellular module (SIM card) enter a low power consumption sleep mode. At this moment, two timers T1 and T2 are set, T1 represents the time interval of heartbeat keep-alive between the monitoring equipment and the platform, namely every other time T1, the cellular module is awakened and then confirmed with the platform through heartbeat packets, if the heartbeat packets are abnormal for a plurality of times continuously, the network between the monitoring equipment and the platform is considered to be abnormal, a network fault occurs, and at this moment, the monitoring equipment exits from a low power consumption mode and is marked as that the monitoring equipment has a remote diagnosis task. T2 represents a location update timer, that is, if the monitoring device finds a location change after a time interval of T2, the changed location information is reported to the server.

When the monitoring equipment is in a low power consumption mode and the cloud platform periodically wakes up the keep-alive process, the monitoring equipment can monitor whether a platform issues a task currently, and if the platform issues the task, the monitoring equipment can exit the low power consumption mode.

When the monitoring equipment is awakened (triggered) because of 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 firstly powers on the lora module through the power management module and carries out related initialization. And then judging whether the current remote fault diagnosis task is triggered by self fault or other nearby monitoring equipment.

If the fault is triggered, the monitoring device sets the spreading factor SF to be the maximum value 12 (the larger the spreading factor is, the longer the communication distance between the lora modules is, the higher the power consumption is, and the lower the speed is), and defaults to open a receiving window to wait for other monitoring devices to detect. If a network fault occurs in the monitoring device B at a certain time point, and the monitoring device B detects the fault of the monitoring device B, the thread to which the monitoring device belongs in the cloud platform also enters a remote fault diagnosis link because the heartbeat packet of the monitoring device is not received for a continuous period of time. The cloud platform would look up all other monitoring devices within 15KM range of the monitoring device in the storage server based on the location of the faulty monitoring device. Due to the positioning errors of GNSS and LBS, in the embodiment of the present application, the search range is adjusted to be expanded to a certain extent according to the respective positioning error ranges (for example, the 15KM range is expanded to 16 KM), so that omission of effective monitoring devices is prevented. The current round of monitoring equipment searching is rough searching, and K1 and K2 \8230 \ 8230;. Km, m monitoring equipment in total are assumed to be arranged around the fault monitoring equipment. The cloud platform will send monitoring device probing instructions (which carry the spreading factor and device probing time information required for long-distance radio communication between the candidate device and the faulty device) to the m monitoring devices in turn.

The monitoring device detection described in the embodiment of the present application aims to find the optimal SF, and find the optimal monitoring device from m monitoring device nodes as a proxy node, and only the proxy node participates in subsequent remote diagnosis tasks with a platform and a technician. The optimal monitoring device is the monitoring device and the fault monitoring device, and the lora module between the monitoring device and the fault monitoring device can perform data communication with the minimum SF factor (namely, the optimal SF) is the lower the SF is, the lower the power consumption is, and the higher the speed is). Specifically, the method comprises the following steps:

the monitoring device detection link may include multiple rounds, but it may be set that at most no more than a preset round is performed, for example, at most no more than 6 rounds (for example, the SF takes a value from a maximum value 12, one is subtracted from each round, and a minimum value is 7, so that, at most, the number of rounds is 6, an optimal SF may be found), each round may have several (for example, k) monitoring devices participating, the first round takes a value from the maximum value of SF, each round of SF is subtracted by 1, if the current round of monitoring devices has a device capable of communicating with a faulty monitoring device, the next round is continued until all the current round of monitoring devices cannot communicate with the faulty monitoring device, and the current SF value plus 1 is used as a minimum spreading factor (i.e., an optimal spreading factor) for performing remote radio communication between the current round of monitoring device and the faulty monitoring device. Specifically, the first round is that all m monitoring devices are searched nearby, the cloud platform sequentially issues detection tasks to the m monitoring devices, and the detection tasks can determine how long the monitoring devices start at which time point to complete detection. Probing is to send a test packet at a specific time, and the failure monitoring device will reply within 100ms after receiving the data packet. And once receiving is the whole process of the detection task. Specific time points are illustrated below: the K1 monitoring device completes probing within 200ms from the time t1, the K2 monitoring device completes within 200ms from the time t2= t1+200ms, and so on. If n monitoring devices can perform long-distance radio communication with the fault monitoring device after the first round is finished (it is stated that SFs adopted between the n monitoring devices and the fault monitoring device are consistent), one monitoring device is randomly selected from the n monitoring devices to inform the fault monitoring device that SF is decreased by 1, a second round is started, a detection task is sent to the n monitoring devices, wherein detection time is carried, and the like until the s round (s belongs to a preset range, for example [1,8 ]), if the s round has k monitoring devices participating, the k monitoring devices cannot perform long-distance radio communication with the fault monitoring device, detection is finished, and the optimal SF is determined as the current SF plus 1, namely the SF in the previous round. And, one monitoring device is selected from the k monitoring devices as a proxy node, for example, the monitoring device with the best cellular network quality is selected as the proxy node, or one monitoring device is randomly selected as the proxy node, and so on.

After the current monitoring device receives a remote diagnosis task (that is, a remote fault diagnosis command) issued by the cloud platform, if the current monitoring device assists other monitoring devices to complete diagnosis, the current monitoring device sets a specified SF according to an instruction of the cloud platform, and then completes detection of the fault monitoring device at a specified time. The monitoring equipment detects that two conditions may exist, one is that the fault monitoring equipment can correctly receive and return under the current configuration of the spread spectrum factor SF, the other is that the two sides cannot realize lora communication due to the fact that the transmission distance of the lora module under the current SF is not enough, the detection results of the monitoring equipment are all returned to the cloud platform, and the cloud platform carries out unified scheduling.

Considering that the positions of the monitoring devices are not uniformly distributed, the number of normal communications with the fault monitoring devices is continuously decreased along with the continuous decrease of the SF, when all the monitoring devices in a certain turn cannot communicate with the fault, the detection of the monitoring devices is stopped, and the cloud platform sends an SF backspacing instruction to the monitoring devices participating in the current detection through the cellular network to indicate that the SF value is increased by 1. The maximum waiting time (i.e. the longest detection time) of the detection of the turn is carried when the SF is adjusted for the fault monitoring equipment in each turn, if the fault monitoring equipment does not have any monitoring equipment to detect the monitoring equipment within the maximum waiting time of a certain turn, the SF value is set to be abnormal, the last SF value needs to be returned, 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 sends a remote diagnosis ending instruction to other monitoring device nodes. The monitoring equipment which is not selected as the proxy node can close the remote fault diagnosis process, and the power management module completes the lower power-on operation of the lora module and continuously switches the lora module into the sleep mode.

And the monitoring equipment selected as the agent node can be continuously in a normal power consumption mode to monitor the remote diagnosis task of the cloud platform. The cloud platform forwards the debugging instructions sent by the technical personnel to the agent node. After receiving, the proxy node first determines whether the proxy node currently holds a token (token), and in order to ensure efficient data transmission between the proxy node and a failed node and prevent unnecessary protocol overhead, the embodiment of the application stipulates that only a node holding the token to be sent can send data, and a node not holding the token to be sent must be in a receiving state. And (3) the default initial proxy node has a sending token, and the proxy node can continuously send all instructions issued by the current platform to the fault node. And releasing the token to the fault node by the proxy node until the data to be sent does not exist. And 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 the token sending function at the moment, the executed result is continuously sent to the proxy node, and if the fault node has no data to send for a period of time, such as 100ms, the token sending function is released to the proxy node again. This loops until the remote diagnosis is finished.

And when the agent node and the fault monitoring equipment receive the diagnosis ending instruction, the agent node and the fault monitoring equipment also exit the diagnosis mode and enter the dormant state again.

To sum up, the embodiments of the present application provide an apparatus, a system, and a method for remote fault diagnosis of a low power consumption monitoring device, which implement intercommunication between an ultra-long-distance (maximum 15 KM) fault monitoring device and an agent monitoring device through system integration of the fault monitoring device, an optimal agent 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 between the agent node and the cloud platform; based on a cloud platform time division control scheme, a method for achieving interference-free rapid finding of the optimal lora module between nodes is achieved, and efficient data transmission between fault monitoring equipment and agent nodes is achieved based on a token scheme.

Based on the same inventive concept, the following describes an apparatus or device provided in the embodiments of the present application, where technical features the same as or corresponding to those described in the above methods are explained or illustrated, and are not repeated herein.

On the network side, see fig. 8, for example, on the cloud platform side, an apparatus for diagnosing a device fault according to an embodiment of the present application includes:

the processor 500, which is used to read the program in the memory 520, executes the following processes:

determining a fault device which cannot be communicated with a cloud platform and at least one candidate device which is within a preset range of distance from the fault device and can be currently communicated with the cloud platform and the fault device;

and determining a proxy node from the at least one candidate device, and performing remote fault diagnosis on the fault device through communication between the proxy node and the cloud platform and the fault device, wherein the proxy node and the fault device communicate through long-distance radio.

In some embodiments, the processor 500, further configured to read the program in the memory 520, performs the following processes:

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

Wherein in fig. 8 the bus architecture may include any number of interconnected buses and bridges, in particular one or more processors, represented by the processor 500, and various circuits, represented by the memory 520, linked together. The bus architecture may also link together various other circuits such as peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further herein. The bus interface provides an interface. The transceiver 510 may be a number of elements including a transmitter and a receiver that provide a means for communicating with various other apparatus over a transmission medium including wireless channels, wired channels, fiber optic 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), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or a Complex Programmable Logic Device (CPLD), and may also have a multi-core architecture.

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

the processor 600, which is used to read the program in the memory 620, executes the following processes:

when receiving a remote fault diagnosis ending instruction sent by the cloud platform, powering off the long-distance radio module;

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

Where in fig. 9, the bus architecture may include any number of interconnected buses and bridges, with various circuits being linked together, particularly one or more processors represented by processor 600 and memory represented by memory 620. The bus architecture may also link together various other circuits such as peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further herein. The bus interface provides an interface. The transceiver 610 may be a number of elements including a transmitter and a receiver that provide a means for communicating with various other apparatus over transmission media including wireless channels, wired channels, fiber optic cables, and the like. For different user devices, the user interface 630 may also be an interface capable of interfacing with a desired device externally, 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 may also adopt a multi-core architecture.

The processor is used for executing any one of the methods provided by the embodiment of the application according to the obtained executable instructions by calling the computer program stored in the memory. The processor and memory may also be physically separated.

It should be noted that the apparatus provided in the embodiment of the present invention can implement all the method steps implemented by the method embodiment, and can achieve the same technical effects, and detailed descriptions of the same parts and beneficial effects as the method embodiment in this embodiment are not repeated herein.

The embodiment of the present application provides a processor-readable storage medium, which stores a computer program, and the computer program is used for causing the processor to execute any one of the methods provided by the embodiment of the present application.

The processor-readable storage medium can be any available medium or data storage device that can be accessed by a processor, including, but not limited to, magnetic memory (e.g., floppy disks, hard disks, magnetic tape, magneto-optical disks (MOs), etc.), optical memory (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor memory (e.g., ROMs, EPROMs, EEPROMs, non-volatile memories (NAND FLASH), solid State Disks (SSDs)), 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 to cause the computer device to perform 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. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc 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 entities in the communication network communicate traffic to and from 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 portions thereof and for execution 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 objective-C, C + +, C #, java, python, javascript, other scripting languages, etc., or a low level programming language, such as a machine language or an assembler.

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

Embodiments may be implemented as separate devices, apparatus, units, components or functions or in a distributed manner, e.g., one or more processors or processing functions may be used or shared in a process or one or more processing segments or processing portions may be used and shared in a process, where a 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, FPGA (field programmable gate array) or CPLD (complex programmable logic device) component, or 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.

As will be appreciated by one skilled in the art, 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, 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 flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such 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 intended to include such modifications and variations as well.

Claims

1. A method of diagnosing equipment failure, the method comprising:

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:

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

sending a device detection instruction for detecting the fault device to k candidate devices, wherein the device detection instruction carries spreading factors and device detection time information required by long-distance radio communication between the candidate devices and the fault device indicated in the current round; wherein k is less than or equal to m;

receiving the device detection results of the k candidate devices, judging whether any candidate device in the current round can carry out long-distance radio communication with the fault device according to the device detection results, if so, selecting one candidate device from the candidate devices in the current round which can carry out long-distance radio communication with the fault device to inform the fault device of the reduction of the spreading factor by one, and triggering the next round of detection; otherwise, determining that the spreading factor plus one in the current round is the optimal spreading factor, and selecting one device with the best current cellular network quality from the k candidate devices as the proxy node.

4. The method of claim 3, further comprising:

5. The method of claim 1, wherein the remote fault diagnosis of the faulty device is achieved through communication between the proxy node and the cloud platform and the faulty device, and comprises:

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

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

and when a fault repairing instruction which is from a client and is forwarded by the proxy node and aims at the fault equipment is received, repairing the fault of the local equipment according to the fault repairing instruction.

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

9. An apparatus for diagnosing equipment failure, comprising a memory, a transceiver, 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 executing the method of any of claims 1 to 8.

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