CN111913196A

CN111913196A - GNSS equipment fault processing method and system thereof

Info

Publication number: CN111913196A
Application number: CN201910385835.6A
Authority: CN
Inventors: 杨晓芬; 柯根水
Original assignee: Chihiro Location Network Co Ltd
Current assignee: Qianxun Position Network Co Ltd; Chihiro Location Network Co Ltd
Priority date: 2019-05-09
Filing date: 2019-05-09
Publication date: 2020-11-10

Abstract

The application relates to the field of positioning and discloses a GNSS equipment fault processing method and a GNSS equipment fault processing system. Responding to a one-key fault report request of a user side, a server side receives current account information, original observation data, differential data streams and GGA data reported by the user side, the server side determines a solution according to the current account information, the original observation data, the differential data streams and the GGA data, if the solution meets a preset one-key processing requirement, the server side sends a one-key processing request to the user side, and if the user side agrees to the one-key processing request, the server side remotely controls the user side to perform fault processing. According to the method and the device, faults can be automatically identified and troubleshooting can be rapidly completed, a large amount of labor cost is saved, and the efficiency of fault processing of the GNSS equipment is improved.

Description

GNSS equipment fault processing method and system thereof

Technical Field

The application relates to the field of positioning, in particular to a GNSS equipment fault processing technology.

Background

With the wide application of the global satellite navigation positioning technology, the GNSS positioning technology has gradually replaced the traditional measuring modes such as a total station and the like due to the characteristics of easy operation, high efficiency, low cost and the like, is widely applied to various industries such as bridges, buildings, geology and the like, and plays a very important role in the fields of engineering measurement and the like.

The application of the GNSS positioning technology can not be matched with GNSS equipment, China is a large production country of global GNSS equipment, according to incomplete statistics, the sales of surveying and mapping hardware instruments in China all the year around 2017 reaches 1/3 globally, and many traditional GNSS equipment manufacturers begin to enter the field of military high-precision positioning, equipment and high-precision positioning service are packaged and sold together intentionally, so that a whole set of service is provided for users. The measure simplifies the measuring steps of the user completely, saves the cost to a certain extent, and is more and more popular with the user.

With the increasing user group of GNSS devices, the GNSS fault handling requirement is increasing, and especially, the uncertainty of the geographic position of the GNSS device in actual use increases the difficulty of fault handling. How to simplify the fault processing process and improve the fault processing efficiency is closely related to GNSS device manufacturers and users, the existing processing mode relying on 'manual one-to-one' is low in efficiency, the required labor cost is too high, and manual misjudgment or misjudgment sometimes occurs, so that the increasing user groups cannot be met.

Disclosure of Invention

The invention aims to provide a GNSS equipment fault processing method and a GNSS equipment fault processing system, which can automatically identify faults and quickly complete fault troubleshooting, save a large amount of labor cost and improve the GNSS equipment fault processing efficiency.

The application discloses a GNSS equipment fault processing method, which comprises the following steps:

responding to a one-key fault report request of a user side, and receiving current account information, original observation data, differential data streams and GGA data reported by the user side by a server side;

the server side determines a solution according to the current account information, the original observation data, the differential data stream and the GGA data;

if the solution meets the preset one-key processing requirement, the server side sends a one-key processing request to the user side;

and if the user side agrees with the one-key processing request, the server side remotely controls the user side to perform fault processing.

In a preferred embodiment, the method further comprises the following steps:

and if the user side does not agree with the one-key processing request, the server side sends the solution to the user side for the user side to perform fault processing.

In a preferred embodiment, the method further comprises the following steps:

and if the solution does not meet the preset one-key processing requirement, the server side sends the solution to the user side for the user side to perform fault processing.

In a preferred embodiment, before responding to the one-click failure report request of the user side, the method further includes:

a user clicks a preset key of the user side;

the user side and the server side establish network connection;

and the user side sends the one-key fault report request to the server side.

the server side stores a first corresponding relation between a fault point and a fault reason and a second corresponding relation between the fault reason and a solution in advance.

In a preferred embodiment, the server determines a solution according to the current account information, the original observation data, the differential data stream, and the GGA data, and further includes:

the server side determines the fault point according to the current account information, the original observation data, the differential data stream and the GGA data;

and determining the solution according to the fault point, the first corresponding relation and the second corresponding relation.

In a preferred embodiment, the method further comprises the following steps:

the server side judges whether the fault is solved according to the fault processing result;

if not, the server side sends a prompt message to the user side, and transmits a work order generated in the fault analysis process to a fault processing department for subsequent processing.

The application also discloses a GNSS equipment fault handling system includes:

the receiving module is used for receiving the current account information, the original observation data, the differential data stream and the GGA data reported by the user side;

the storage module is used for storing the current account information, the original observation data, the differential data stream and the GGA data reported by the user side;

the communication module is used for carrying out data transmission with the user side;

and the processing module is used for determining a solution according to the current account information, the original observation data, the differential data stream and the GGA data, if the solution meets a preset one-key processing requirement, the server sends a one-key processing request to the client, and if the client agrees to the one-key processing request, the server remotely controls the client to perform fault processing.

In a preferred embodiment, the processing module is further configured to, if the user side does not agree with the request, send the solution to the user side by the server side, so that the user side performs fault processing.

In a preferred example, the processing module is further configured to send the solution to the user side for the user side to perform fault processing if the solution does not meet the one-touch processing requirement.

In a preferred embodiment, the communication module is further configured to establish a network connection with the user side after the user clicks a preset key of the user side, and receive a one-key fault report request sent by the user side.

In a preferred embodiment, the storage module is further configured to store in advance a first corresponding relationship between a failure point and a failure cause, and a second corresponding relationship between the failure cause and a solution.

In a preferred embodiment, the processing module is further configured to determine the fault point according to the current account information, the raw observation data, the differential data stream, and the GGA data, and determine the solution according to the fault point, the first corresponding relationship, and the second corresponding relationship.

In a preferred embodiment, the processing module is further configured to determine whether the fault is resolved according to a result of the fault processing, and if the fault is not resolved, send a prompt message to the user side, and transmit a work order generated in a fault analysis process to a fault processing department for subsequent processing.

The application also discloses a GNSS equipment fault handling system includes:

a memory for storing computer executable instructions; and the number of the first and second groups,

a processor for implementing the steps in the method as described hereinbefore when executing the computer-executable instructions.

The present application also discloses a computer-readable storage medium having stored therein computer-executable instructions which, when executed by a processor, implement the steps in the method as described above.

In the embodiment of the application, a one-key fault processing function is provided on hardware for binding and selling a network RTK service and the GNSS equipment, and a user can receive fault troubleshooting processing service from a service end by clicking a button preset on the GNSS equipment, particularly for some fault points with higher occurrence probability, and solve the fault in extremely short time according to a preset strategy library of 'fault point-fault reason-solution'; furthermore, for fault points or fault reasons and the like which are not related in the strategy library, after the first fault troubleshooting is finished, the fault can be supplemented into the strategy library, so that even no manual interference exists in the past, the fault of the user can be automatically and quickly processed, a large amount of labor cost is saved, and the fault troubleshooting efficiency is improved.

The present specification describes a number of technical features distributed throughout the various technical aspects, and if all possible combinations of technical features (i.e. technical aspects) of the present specification are listed, the description is made excessively long. In order to avoid this problem, the respective technical features disclosed in the above summary of the invention of the present application, the respective technical features disclosed in the following embodiments and examples, and the respective technical features disclosed in the drawings may be freely combined with each other to constitute various new technical solutions (which are considered to have been described in the present specification) unless such a combination of the technical features is technically infeasible. For example, in one example, the feature a + B + C is disclosed, in another example, the feature a + B + D + E is disclosed, and the features C and D are equivalent technical means for the same purpose, and technically only one feature is used, but not simultaneously employed, and the feature E can be technically combined with the feature C, then the solution of a + B + C + D should not be considered as being described because the technology is not feasible, and the solution of a + B + C + E should be considered as being described.

Drawings

FIG. 1 is a flowchart illustrating a GNSS device fault handling method according to a first embodiment of the present application

FIG. 2 is a schematic diagram of a GNSS device fault handling system according to a second embodiment of the present application

FIG. 3 is a specific example of a second embodiment according to the present application

FIG. 4 is a schematic diagram of a GNSS device fault handling system according to a third embodiment of the present application

Detailed Description

In the following description, numerous technical details are set forth in order to provide a better understanding of the present application. However, it will be understood by those skilled in the art that the technical solutions claimed in the present application may be implemented without these technical details and with various changes and modifications based on the following embodiments.

Description of partial concepts:

network RTK: also known as multi-reference station RTK, is a new technology established in recent years on the basis of conventional RTK and differential GPS. A positioning approach in which a plurality of GPS reference stations (typically three or more) established within an area form a mesh coverage area for the area and GPS correction information is calculated and broadcast relative to one or more of the reference stations to correct GPS users within the area in real time is commonly referred to as GPS network RTK.

GNSS: global Navigation Satellite System, Global Navigation Satellite System.

A GNSS receiver: the device is an instrument for receiving global positioning system satellite signals (GPS, GLONASS, Beidou) and determining the ground space position.

GGA data: GGA is a GPS fixed data output statement that includes 17 fields: statement header, universal time, latitude hemisphere, longitude hemisphere, location quality indication, number of satellites in use, HDOP-level accuracy factor, ellipsoid height, altitude unit, geoid altitude anomaly difference, altitude unit, differential GPS data deadline, differential reference base station designation, checksum end marker (with carriage return symbol < CR > and linefeed symbol < LF >), separated by 14 commas, respectively.

The corresponding relation is as follows: refers to a correspondence between two or more data, typically stored in a storage device or storage device, which may be a database, a file, a hard disk, a memory, etc.

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

A first embodiment of the present application relates to a GNSS device fault handling method, a flowchart of which is shown in fig. 1, and the method includes the following steps:

in step 101, in response to a one-key fault report request from a user, a server receives current account information, original observation data, differential data stream, and GGA data reported from the user.

Optionally, before step 101, the following sub-steps are further included: starting, clicking a preset key of the user side by a user; then, the user end and the server end establish network connection; and then, the client sends the one-key fault report request to the server.

The preset key may be provided at the user end (e.g., on the GNSS device or in the phonebook software of the GNSS device), and the existing form thereof is various. Alternatively, it may be a physical button provided on the GNSS device; alternatively, it may be a software tab provided on the phonebook software of the GNSS device.

Optionally, the network connection established between the user terminal and the server terminal is based on a long-range wireless communication network. For example, but not limited to, 4G, 5G networks, and the like.

Optionally, the connection between the service end and the user end is based on OSS protocol. Specifically, the OSS protocol and the infrastructure support QoS and narrow-band networks, support the real-time bidirectional interaction between the terminal and the platform, improve the safety of a service link and data, and simultaneously bear various space-time services. The OSS infrastructure supports access of massive user ends, and each product service can better realize the connection between the user ends and the service ends based on the OSS protocol opening capacity. For this protocol, it needs to be further explained that: OSS is based on MQTT latest version and consists of a user side, an OSS framework and a service provider; topic is managed by the server, and the list is as table 1 below; the CONNECT connection condition may include: username uses a device service number (DSK) and Password uses a device service number Key (DSS).

TABLE 1

Optionally, before step 101, the method further includes: the server stores a first corresponding relation between a fault point and a fault reason and a second corresponding relation between the fault reason and a solution in advance.

Then step 102 is entered, and the server determines a solution according to the current account information, the original observation data, the differential data stream and the GGA data.

In one embodiment, the step 102 may further comprise: the server side determines the fault point according to the current account information, the original observation data, the differential data stream and the GGA data, and determines the solution according to the fault point, the first corresponding relation and the second corresponding relation.

In one embodiment, the failure point is "account abnormal", the failure is "account password incorrect", and the solution is "modified password re-login". In another embodiment, the failure point is "the account password uploaded by the device is not consistent with the correct password in the background", the failure reason is "the access point is incorrect", and the solution is "solution-modified access point re-login". In another embodiment, the failure point is "account abnormal", the failure reason is "account inactivated", and the solution is "account activated".

Then, step 103 is entered to judge: the solution is to meet preset one-touch processing requirements.

If the solution meets the predetermined one-touch requirement, then step 104 is entered, and the server sends a one-touch request to the ue.

Then, step 106 is entered to judge: whether the client agrees with the one-touch processing request.

If the ue agrees with the one-touch request, then step 107 is entered, and the server remotely controls the ue to perform fault handling.

Optionally, if the solution does not meet the preset one-touch requirement, then step 105 is entered, and the server sends the solution to the ue for the ue to perform fault handling.

Alternatively, if the ue does not agree with the one-touch request, then step 105 is entered, and the server sends the solution to the ue for the ue to perform fault handling.

Optionally, as shown in fig. 1, the method further includes: after step 107, step 108 is entered, and it is judged: and the server judges whether the fault is solved or not according to the fault processing result. If not, then entering step 110, the server side sending a prompt message that the fault needs to be further processed to the user side, and transmitting a work order generated in the fault analysis process to a fault processing department for subsequent processing until the fault is solved, and after the fault is solved, performing step 109; otherwise, go to step 109 directly, the server sends a "failure resolved" prompt message to the ue.

Optionally, after "the fault handling section performs subsequent processing until the fault is resolved" in step 110, the following steps may be further included: and further adding a first corresponding relation for storing the fault point and the fault reason and a second corresponding relation for storing the fault reason and the solution to the server, judging whether the solution corresponding to the fault point meets the one-key processing requirement, and if so, identifying the solution for subsequent fault processing.

In order to better understand the technical solution of the present application, the following description is given with reference to several specific examples, in which the listed details are mainly for the sake of understanding and are not intended to limit the scope of the present application.

Example 1, including the steps of (i), (ii), (iii), (iv), (v), and (iv), specifically including: starting a step of one-key fault reporting of a user, entering a fault reporting program by the user side, and establishing network connection in a protocol gateway through a 'CONNECT' request; secondly, executing a step II that the user side reports Account information including equipment service numbers and key information to the service side through Account/upload, continuously reports the original observation data of the current equipment through RTCM/upload, and respectively stores the original observation data in corresponding lists according to the equipment service numbers; then, the server acquires the user terminal contact information, the account password, the uploaded GGA data, the uploaded network congestion data and the broadcasted differential data from the background database according to the account information and stores the acquired GGA data, the uploaded network congestion data and the uploaded differential data; then, executing a step (iv) -the server compares, processes and analyzes the two kinds of data according to a set rule and priority by combining the data uploaded by the current equipment and the data acquired from the background database to find a fault reason, analyzes and finds that a fault point is abnormal, a corresponding fault reason is incorrect, an account password is incorrect, and acquires a corresponding solution-modified password for logging again; then executing the step of matching the remote scheme database to judge whether the remote support is suitable or not through Result/response, if the remote support is suitable, the server side initiates a Request of ' one-key processing ' to the client side through ' Request/response ', the client side agrees to ' one-key processing ', the method enters a step of sending an instruction (with a self-defined format) to the client side through ' Command/response ', such as ' reset + password ', system restart ' and the like, the client side receives the instruction and identifies the instruction and starts to execute the processing process, after the execution processing is finished, the background of the server side continuously monitors the GGA data state (such as 5min) reported by the terminal, if the state is normal, the server side periodically sends a failure release message to the user side through 'Result/response' within a preset time period until receiving an instruction of 'cancel one-key processing' of the user side.

Example 2, including the steps of (i), (ii), (iii), (iv), (v), and (iv), specifically includes: starting a step of one-key fault reporting of a user, entering a fault reporting program by the user side, and establishing connection in a protocol gateway through a 'CONNECT' request; secondly, executing a step II that the user side reports Account information including equipment service numbers and key information to the service side through Account/upload, continuously reports the original observation data of the current equipment through RTCM/upload, and respectively stores the original observation data in corresponding lists according to the equipment service numbers; then, the server acquires the user terminal contact information, the account password, the uploaded GGA data, the uploaded network congestion data and the broadcasted differential data from a background database according to the account information and stores the acquired information; then, executing a step (iv) -the server side combines the data uploaded by the current equipment and the data acquired from the background database, compares, processes and analyzes the two data according to a set rule and a priority level to find a fault reason, analyzes and finds that a fault point is abnormal, the corresponding fault reason is differential data of a certain satellite system which is not broadcast, and acquires a corresponding solution scheme; a fifth step is executed, the server side is matched with the remote scheme database to judge whether the remote support is suitable, if the remote support is not suitable, fault reporting information including an account number and the contact way of a specified processor is transmitted to the client side through 'Message/info', meanwhile, the server side sends a preliminary analysis Result to the client side through 'Result/response', and reminds the specified processor of follow-up examination in a friendly way, please endure for waiting, and contact with the server later, and the fault reporting is finished by one key; and then, executing a step of sending fault troubleshooting progress to the user side by the server side through Result/response in a timing mode, sending information of recovering normal service to the user side after the fault is relieved, and summarizing fault reasons.

Example 3, including the steps of (i), (ii), (iii), (iv), (v), and (iv), specifically including: starting a step of one-key fault reporting of a user, entering a fault reporting program by the user side, and establishing connection in a protocol gateway through a 'CONNECT' request; secondly, executing a step II that the user side reports Account information including equipment service numbers and key information to the service side through Account/upload, continuously reports the original observation data of the current equipment through RTCM/upload, and respectively stores the original observation data in corresponding lists according to the equipment service numbers; then, the server acquires a client contact way, an account password, uploaded GGA data, network congestion data and broadcasted differential data from a background database according to the account information and stores the client contact way, the account password, the uploaded GGA data, the uploaded network congestion data and the broadcasted differential data; then, executing a step (iv) -the server compares, processes and analyzes the two kinds of data according to a set rule and priority by combining the data uploaded by the current equipment and the data acquired from the background database to find a fault reason, analyzes and finds that a fault point, an account password uploaded by the equipment is inconsistent with a correct password in the background, a corresponding fault reason, namely an access point is incorrect, and acquires a corresponding solution, namely a modified access point is logged in again; fifthly, the server side matches the remote scheme database to judge whether the remote support is suitable, if the remote support is suitable, a Request/response Request is used to send a one-key processing Request to the client side; the client agrees to the one-key processing, the method includes the following steps that a server sends an instruction (with a self-defined format) to a client through a Command/response, for example, "set mount point + RTCM32_ GGB", "system restart", and the like, the client receives the instruction, identifies the instruction and starts to execute a processing process, after the execution processing is finished, a server background continuously monitors the GGA data state (for example, 5min) reported by the terminal, and if the state is normal, the server periodically sends a failure release message to the client through "Result/response" within a preset time period until the instruction of "canceling one-key processing" of the client is received.

Example 4, including the steps of (i), (ii), (iii), (iv), (v), and (iv), specifically including: starting a step of one-key fault reporting of a user, entering a fault reporting program by the user side, and establishing connection in a protocol gateway through a 'CONNECT' request; secondly, executing a step II that the user side reports Account information including equipment service numbers and key information to the service side through Account/upload, continuously reports the original observation data of the current equipment through RTCM/upload, and respectively stores the original observation data in corresponding lists according to the equipment service numbers; thirdly, the server acquires a client contact way, an account password, uploaded GGA data, network congestion data and broadcasted differential data from a background database according to the account information and stores the client contact way, the account password, the uploaded GGA data, the uploaded network congestion data and the broadcasted differential data; then, executing a step (iv) -the server compares, processes and analyzes the two kinds of data according to a set rule and priority by combining the data uploaded by the current device and the data acquired from the background database to find a fault reason, analyzes and finds that a fault point-account is abnormal, a corresponding fault reason-account is not activated, and acquires a corresponding solution scheme-activated account; fifthly, the server side matches the remote scheme database to judge whether the remote support is suitable, if the remote support is suitable, the server side initiates a Request of one-key processing to the client side through a Request/response; the client agrees to the one-key processing, the method includes the following steps that a server sends a Command (with a self-defined format) to the client through a Command/response, for example, "active + differential account", "system restart", and the like, the client receives the Command and identifies the Command and starts to execute, the terminal calls an account activating interface to activate the account, after the execution processing is finished, a background of the server continuously monitors the GGA data state (for example, 5min) reported by the terminal, and if the GGA data state is normal, the server periodically sends a failure release message to the client through the Result/response within a preset time period until the Command of canceling the one-key processing of the client is received.

A second embodiment of the present application relates to a GNSS device fault handling system, which is configured as shown in fig. 2 and includes a receiving module, a storage module, and a processing module.

Specifically, the method comprises the following steps:

1. the receiving module is used for receiving the current account information, the original observation data, the differential data stream and the GGA data reported by the user side.

2. The storage module is used for storing the current account information, the original observation data, the differential data stream and the GGA data reported by the user side. Optionally, the account information includes a device service number and key information.

Optionally, the storage module is further configured to store in advance a first corresponding relationship between the failure point and the failure cause, and a second corresponding relationship between the failure cause and the solution.

Optionally, the system further includes an input module, configured to add the first corresponding relationship and the second corresponding relationship to the server.

3. The communication module is used for data transmission with the user side.

Optionally, the communication module is further configured to establish a network connection with the user side after the user clicks a preset key of the user side, and receive a one-key failure report request sent by the user side.

TABLE 1

Serial number	Name (R)	Direction of data flow	Rank of	Data format
					1	Account/upload	User terminal->Service terminal	Session	Self-engagement
2	RTCM/upload	User terminal->Service terminal	Session	RTCM data
					3	Result/response	Service terminal>User terminal	Session	Self-engagement
4	Request/response	Service terminal>User terminal	Session	Self-engagement
					5	Command/response	Service terminal>User terminal	Session	Self-engagement
6	Message/inform	Service terminal>Appointed user terminal	Session	Self-engagement

4. The processing module is used for determining a solution according to the current account information, the original observation data, the differential data stream and the GGA data, if the solution meets a preset one-key processing requirement, the server side sends a one-key processing request to the client side, and if the client side agrees with the one-key processing request, the server side remotely controls the client side to perform fault processing.

Optionally, the processing module is further configured to, if the ue does not agree with the request, send the solution to the ue by the server, so that the ue performs fault handling.

Optionally, the processing module is further configured to, if the solution does not meet the one-touch processing requirement, send the solution to the user side for the user side to perform fault processing.

Optionally, the processing module is further configured to determine the fault point according to the current account information, the original observation data, the differential data stream, and the GGA data, and determine the solution according to the fault point, the first corresponding relationship, and the second corresponding relationship.

In one embodiment, the failure point is "account abnormal", the failure is "account password incorrect", and the solution is "modified password re-login". In another embodiment, the failure point is "the account password uploaded by the device is not consistent with the correct password in the background", the failure reason is "the access point is incorrect", and the solution is "solution-modified access point re-login". In another embodiment, the failure point is "account abnormal", the failure reason is "account inactivated", and the solution is "account activated". Including but not limited to these specific embodiments.

Optionally, the processing module is further configured to determine whether the fault is resolved according to a result of the fault processing. If not, the server side sends a prompt message to the user side, and transmits a work order generated in the fault analysis process to a fault processing department for subsequent processing until the fault is solved, and sends a prompt message of 'the fault is solved' to the user side. Otherwise, directly sending a 'failure resolved' prompt message to the user terminal.

Fig. 3 is a schematic structural diagram of a specific example of a second embodiment according to the present application. In this embodiment, the storage module further comprises a question bank, a tag bank, and a rule bank; the problem library is used for storing the first corresponding relation and the second corresponding relation; the tag library can be a GNSS device service number, each GNSS device only corresponds to one tag in the tag library, and the tag library is mainly used for storing an index of data such as user behavior, network link, differential state, user environment and the like when the GNSS device works normally or calling the index of the stored data when the GNSS device fails; the rule base is mainly used for setting processing priority, for example, when one fault point possibly corresponds to a plurality of fault reasons, the server ranks the priority of the corresponding fault reasons through the rule base and executes the priority step by step; the service scope and service monitoring are mainly based on the monitoring and fault handling scope of each service end.

The first embodiment is a method embodiment corresponding to the present embodiment, and the technical details in the first embodiment may be applied to the present embodiment, and the technical details in the present embodiment may also be applied to the first embodiment.

A third embodiment of the present application relates to a GNSS device fault handling system, which has a structure as shown in fig. 4, and includes a server and a client.

1. On the server side:

the server comprises a receiving module, a storage module, a processing module and a communication module. The receiving module is used for receiving current account information, original observation data, differential data stream and GGA data reported by the user side; the storage module is used for storing current account information, original observation data, differential data stream and GGA data reported by the user side; the communication module is used for carrying out data transmission with the user side; the processing module is used for determining a solution according to the current account information, the original observation data, the differential data stream and the GGA data, if the solution meets a preset one-key processing requirement, the server side sends a one-key processing request to the client side, and if the client side agrees with the one-key processing request, the server side remotely controls the client side to perform fault processing; wherein the account information includes a device service number and key information.

Optionally, the storage module is further configured to store in advance a first corresponding relationship between the failure point and the failure cause, and a second corresponding relationship between the failure cause and the solution. In one embodiment, the system further includes an input module for adding the first corresponding relationship and the second corresponding relationship to the server.

Optionally, the communication module is further configured to establish a network connection with the user side after the user clicks a "one-click processing" key of the user side, and receive a one-click failure report request sent by the user side.

In one embodiment, the failure point is "account abnormal", the failure is "account password incorrect", and the solution is "modified password re-login". In another embodiment, the failure point is "the account password uploaded by the device is not consistent with the correct password in the background", the failure reason is "the access point is incorrect", and the solution is "solution-modified access point re-login". In another embodiment, the failure point is "account abnormal", the failure reason is "account inactivated", and the solution is "account activated". But are not limited to these specific embodiments.

2. On the user side:

the user side comprises GNSS equipment and a one-key processing key, and the GNSS equipment is provided with a communication submodule, a sending submodule and a receiving submodule. The communication submodule is used for carrying out data transmission with the server; the receiving submodule is used for receiving a one-key processing request from a server; the sending submodule is used for reporting the current account information, the original observation data, the differential data stream and the GGA data of the user side after the network connection is established between the user side and the service side, and sending a feedback instruction to the service side according to a one-key processing request from the service side received by the receiving submodule. Specifically, when the GNSS device fails, after the user clicks the "one-click processing" key of the user side, the user establishes network connection with the communication module of the server side through the communication submodule of the user side, and sends a "one-click failure report request" to the receiving module of the server side through the sending submodule of the user side.

Optionally, the "feedback instruction" includes a one-touch processing request of the server and a one-touch processing request of the server.

Optionally, the network connection established between the user terminal and the communication module of the service terminal through the communication submodule of the user terminal is based on a long-range wireless communication network. For example, but not limited to, 4G, 5G networks, and the like.

The "one-touch" button may be provided at the user end (e.g., on the GNSS device or in the phonebook software of the GNSS device), and the existence form thereof is various. Alternatively, it may be a physical button provided on the GNSS device; alternatively, it may be a software tab provided on the phonebook software of the GNSS device.

Optionally, the receiving sub-module is further configured to receive a "failure resolved" prompt message from the server after the failure is resolved; the sending submodule is also used for sending a command of canceling the one-key processing to the server side after receiving the prompt message of 'failure resolved' from the server side.

Optionally, the connection between the service end and the user end is based on OSS protocol. Specifically, the OSS protocol and the infrastructure support QoS and narrow-band networks, support the real-time bidirectional interaction between the terminal and the platform, improve the safety of a service link and data, and simultaneously bear various space-time services. The OSS infrastructure supports access of massive user ends, and each product service can better realize the connection between the user ends and the service ends based on the OSS protocol opening capacity. For this protocol, it needs to be further explained that: OSS is based on MQTT latest version and consists of a user side, an OSS framework and a service provider; topic is managed by the server, and the list is as table 1 below; CONNECT ligation conditions: username uses a device service number (DSK) and Password uses a device service number Key (DSS).

TABLE 1

It should be noted that, as will be understood by those skilled in the art, the implementation functions of the modules shown in the above embodiments of the GNSS device fault handling system may be understood by referring to the related description of the GNSS device fault handling method. The functions of the modules shown in the above embodiments of the GNSS device fault handling system may be implemented by a program (executable instructions) running on a processor, or may be implemented by specific logic circuits. The GNSS device fault handling system according to the embodiment of the present invention may also be stored in a computer-readable storage medium if it is implemented in the form of a software functional module and sold or used as an independent product. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

Accordingly, the present application also provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the computer-executable instructions implement the method embodiments of the present application. Computer-readable storage media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable storage medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

In addition, the embodiment of the application also provides a GNSS device fault handling system, which includes a memory for storing computer executable instructions, and a processor; the processor is configured to implement the steps of the method embodiments described above when executing the computer-executable instructions in the memory. The Processor may be a Central Processing Unit (CPU), other general-purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or the like. The aforementioned memory may be a read-only memory (ROM), a Random Access Memory (RAM), a Flash memory (Flash), a hard disk, or a solid state disk. The steps of the method disclosed in the embodiments of the present invention may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

It is noted that, in the present patent application, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the use of the verb "comprise a" to define an element does not exclude the presence of another, same element in a process, method, article, or apparatus that comprises the element. In the present patent application, if it is mentioned that a certain action is executed according to a certain element, it means that the action is executed according to at least the element, and two cases are included: performing the action based only on the element, and performing the action based on the element and other elements. The expression of a plurality of, a plurality of and the like includes 2, 2 and more than 2, more than 2 and more than 2.

All documents mentioned in this application are to be considered as being incorporated in their entirety into the disclosure of this application so as to be subject to modification as necessary. It should be understood that the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present disclosure should be included in the scope of protection of one or more embodiments of the present disclosure.

Claims

1. A GNSS device fault handling method comprises the following steps:

2. The method of claim 1, further comprising:

3. The method of claim 1, further comprising:

4. The method of claim 1, wherein before responding to the one-touch failure reporting request at the user side, further comprising:

a user clicks a preset key of the user side;

the user side and the server side establish network connection;

and the user side sends the one-key fault report request to the server side.

5. The method of claim 1, wherein before responding to the one-touch failure reporting request at the user side, further comprising:

6. The method of claim 5, wherein the server determines a solution based on the current account information, raw observation data, differential data flow, and GGA data, further comprising:

and the server side determines the solution according to the fault point, the first corresponding relation and the second corresponding relation.

7. The method of any one of claims 1-6, further comprising:

8. A GNSS device fault handling system, comprising:

9. The system according to claim 8, wherein the processing module is further configured to, if the user side does not agree with the request, the server side sends the solution to the user side for the user side to perform fault handling.

10. The system of claim 8, wherein the processing module is further configured to send the solution to the user side for failure handling by the user side if the solution does not meet a one-touch handling requirement.

11. The system according to claim 8, wherein the communication module is further configured to establish a network connection with the user terminal and receive a one-key failure report request sent by the user terminal after the user clicks a preset key of the user terminal.

12. The system of claim 8, wherein the storage module is further configured to pre-store a first correspondence between failure points and failure causes, and a second correspondence between the failure causes and solutions.

13. The system of claim 12, wherein the processing module is further to determine the point of failure based on the current account information, raw observation data, differential data flow, and GGA data, and to determine the solution based on the point of failure, the first correspondence, and the second correspondence.

14. The system according to any one of claims 8 to 13, wherein the processing module is further configured to determine whether the fault is resolved according to the result of the fault processing, and if the fault is not resolved, send a prompt message to the user side, and transmit a work order generated in the fault analysis process to a fault processing department for subsequent processing.

15. A GNSS device fault handling system, comprising:

a processor for implementing the steps in the method of any one of claims 1 to 7 when executing the computer-executable instructions.

16. A computer-readable storage medium having stored thereon computer-executable instructions which, when executed by a processor, implement the steps in the method of any one of claims 1 to 7.