Method and system for collecting and processing failure data for analysis of unmanned mine car
By continuously analyzing the fault data of unmanned mining trucks and recording the start and end times of the faults, the problems of low analysis accuracy and availability in existing technologies are solved, and more efficient fault handling is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- DONGFENG COMML VEHICLE CO LTD
- Filing Date
- 2024-05-31
- Publication Date
- 2026-06-30
AI Technical Summary
Existing technologies for handling faults in unmanned mining vehicles have low analytical accuracy and usability, and cannot effectively prevent the recurrence of faults.
By collecting fault data from unmanned mining vehicles and dividing it into continuous fault data and single-point fault data, recording the start and end times of the faults, and analyzing the causes of the faults based on the time range.
It improves the accuracy and availability of fault data analysis, enabling more accurate identification of fault causes and the development of comprehensive handling solutions, thereby reducing the probability of fault recurrence.
Smart Images
Figure CN118609236B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data acquisition, specifically to a method and system for acquiring and processing fault data for analysis of unmanned mining vehicles. Background Technology
[0002] Mining cars are an indispensable key piece of equipment in mining operations, used to transport ore, materials, and personnel.
[0003] Mining cars can be mainly classified into the following categories based on their purpose and structural characteristics:
[0004] Self-propelled mining trucks: These trucks have independent drive systems and can travel independently on mine roads. Depending on their carrying capacity, self-propelled mining trucks can be further divided into small, medium, and large types.
[0005] Trailer-mounted mine cars: Trailer-mounted mine cars consist of a tractor and a trailer, and the trailer can be replaced as needed.
[0006] Mining cars have the following characteristics in mining operations:
[0007] Highly adaptable: Mining trucks can be modified and adjusted according to different mining environments and operational needs, thereby meeting various transportation requirements.
[0008] Large carrying capacity: Mining cars typically have a large carrying capacity, which can meet the large transportation needs of mining operations.
[0009] High reliability: Mining trucks are typically designed and manufactured using advanced technologies and materials to ensure high reliability and service life.
[0010] Easy to maintain: The maintenance and upkeep of mining cars are relatively simple. They only need to be inspected and maintained regularly according to the instruction manual.
[0011] Mining cars are widely used in the following scenarios:
[0012] Ore transportation: In mining operations, ore is typically transported using mining cars. Different types and carrying capacities of mining cars can be selected depending on the type of ore and the transportation distance.
[0013] Material transportation: In mine construction, mining cars can be used to transport various construction materials, such as cement, steel bars, and timber.
[0014] Personnel transportation: When the mine is large, mining cars can also be used to transport mine workers to improve work efficiency and safety.
[0015] Currently, the general troubleshooting methods for unmanned mining trucks are as follows: monitor the truck's parameters (such as travel speed, tire pressure, and power consumption). When abnormal parameters are detected, the truck's position is determined on the path map using its positioning signal. If the truck is not moving or moving slowly, operators are dispatched to check its condition and perform repairs. If the truck can move within acceptable limits, it continues to operate. After completing its work, appropriate actions are taken based on the truck's current status, such as maintenance and / or performance adjustments.
[0016] However, even after processing in the above manner, the unmanned mining trucks are highly likely to experience the same malfunction. Analysis revealed that this is because the processing method relies on information from the current malfunction (i.e., "single-point" malfunction data), which is often caused by multiple different factors. Therefore, for more refined malfunction handling to prevent recurrence, single-point malfunction data with low accuracy and usability should not be used. Summary of the Invention
[0017] In view of the deficiencies in the existing technology, the technical problem solved by the present invention is: how to improve the accuracy and usability of fault data analysis of unmanned mining vehicles.
[0018] To achieve the above objectives, in a first aspect, embodiments of this application provide a method for collecting and processing fault data for analysis of unmanned mining vehicles, comprising the following steps: collecting fault data of the unmanned mining vehicle according to a pre-set fault identifier; dividing the fault data into continuous fault data and single-point fault data other than continuous fault data, wherein continuous fault data includes several fault data of the same type repeatedly received within a specified period; determining the start and end times of the fault corresponding to the continuous fault data based on the times of the first and last fault data received in the continuous fault data; determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data; and determining the time range of the corresponding fault occurrence based on the start and end times of each fault data.
[0019] In conjunction with the first aspect, in one implementation, the fault identifier includes a unique fault identifier corresponding to each type of fault. The process of determining the start and end times of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data, and determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data, includes:
[0020] When fault data is collected and the unique fault identifier in the fault data does not exist, the current fault data is stored, the start time of the corresponding fault is determined according to the collection time of the current fault data, and the storage duration of the current fault data is determined according to the start time.
[0021] When the storage time reaches the specified period and fault data with the same unique fault identifier as the current fault data is collected, the current fault data is regarded as continuous fault data; the end time of the fault corresponding to the continuous fault data is determined according to the collection time of the last collected continuous fault data.
[0022] When the storage time reaches the specified period and no fault data with the same unique fault identifier as the current fault data is collected, the current fault data is taken as single-point fault data, and the end time of the corresponding fault is determined according to the collection time of the single-point fault data.
[0023] In conjunction with the first aspect, in one implementation, the process of determining the start and end times of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data, and determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data, specifically includes: after collecting fault data, if there is no unique fault identifier for the current fault data in the cache database, the current fault data is stored in both the cache database and the local database, and the collection time of the current fault data is taken as the fault start time. The storage duration of the current fault is recorded in the cache database. When the storage duration reaches the specified period, it is determined whether fault data with the same unique fault identifier as the current fault data has been collected.
[0024] If so, the current fault data is treated as continuous fault data. When no fault data with the same unique fault identifier as the current fault data is collected after a specified period, the collection time of the last collected current fault data is used as the fault end time of the current continuous fault data and updated to the local database.
[0025] Otherwise, the current fault data will be used as the single point of failure data, and the fault start time of the current fault data will be used as the fault end time of the single point of failure data and updated to the local database.
[0026] In conjunction with the first aspect, in one implementation, the method further includes the step of deleting fault data for which the same unique fault identifier has not been received within a specified time period.
[0027] In conjunction with the first aspect, in one implementation, the cache database is a Redis database, and the local database is a MySQL database.
[0028] In conjunction with the first aspect, in one implementation, the process of collecting fault data of the unmanned mining truck according to the pre-set fault identifier includes: setting the field value corresponding to each unique fault identifier in the Java object, converting the running data of the unmanned mining truck into a JSON object, and determining that the Java object is fault data when the JSON object can be converted into the Java object.
[0029] In conjunction with the first aspect, in one implementation, the fields of the unique fault identifier include: faultAddr, spn, and fmi.
[0030] In conjunction with the first aspect, in one implementation, the method further includes the step of: assigning a fault level to a fault tag corresponding to each type of fault data.
[0031] Secondly, embodiments of this application provide a fault data acquisition and processing system for unmanned mining vehicles, including a client and a server;
[0032] The client is used to: upload fault data to the server;
[0033] The server is used to process fault data according to the method provided by the first invention.
[0034] In conjunction with the second aspect, in one implementation, the system further includes an unmanned mining vehicle, on which the client is mounted.
[0035] The specific workflow of the server includes: collecting fault data of the unmanned mining truck according to the pre-set fault identifiers; dividing the fault data into continuous fault data and single-point fault data other than continuous fault data, where continuous fault data includes several fault data of the same type repeatedly received within a specified period; determining the start and end time of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data; determining the start and end time of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data; and determining the time range of the corresponding fault based on the start and end time of each fault data.
[0036] The fault identifier includes a unique fault identifier corresponding to each type of fault. The process of determining the start and end times of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data, and determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data, includes:
[0037] When fault data is collected and the unique fault identifier in the fault data does not exist, the current fault data is stored, the start time of the corresponding fault is determined according to the collection time of the current fault data, and the storage duration of the current fault data is determined according to the start time.
[0038] When the storage time reaches the specified period and fault data with the same unique fault identifier as the current fault data is collected, the current fault data is regarded as continuous fault data; the end time of the fault corresponding to the continuous fault data is determined according to the collection time of the last collected continuous fault data.
[0039] When the storage time reaches the specified period and no fault data with the same unique fault identifier as the current fault data is collected, the current fault data is taken as single-point fault data, and the end time of the corresponding fault is determined according to the collection time of the single-point fault data.
[0040] The process of determining the start and end times of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data, and determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data, specifically includes: after collecting fault data, if there is no unique fault identifier for the current fault data in the cache database, the current fault data is stored in both the cache database and the local database, and the collection time of the current fault data is taken as the fault start time. The storage duration of the current fault is recorded in the cache database. When the storage duration reaches the specified period, it is determined whether fault data with the same unique fault identifier as the current fault data has been collected.
[0041] If so, the current fault data is treated as continuous fault data. When no fault data with the same unique fault identifier as the current fault data is collected after a specified period, the collection time of the last collected current fault data is used as the fault end time of the current continuous fault data and updated to the local database.
[0042] Otherwise, the current fault data will be used as the single point of failure data, and the fault start time of the current fault data will be used as the fault end time of the single point of failure data and updated to the local database.
[0043] The method also includes the following step: deleting fault data for which the same unique fault identifier has not been received within a specified time period.
[0044] The cache database is a Redis database, and the local database is a MySQL database.
[0045] The process of collecting fault data of unmanned mining trucks according to pre-set fault identifiers includes: setting field values in a Java object corresponding to each unique fault identifier, converting the running data of the unmanned mining truck into a JSON object, and determining that the Java object is fault data when the JSON object can be converted into the Java object.
[0046] The fields for the unique fault identifier include: faultAddr, spn, and fmi.
[0047] The method also includes the following step: assigning a fault level to the fault tag corresponding to each type of fault data.
[0048] Compared with the prior art, the advantages of the present invention are as follows:
[0049] Compared to existing technologies that process unmanned mining trucks based on single-point fault data, this invention divides fault data into segments based on their continuity during data collection and records the start and end times of each fault occurrence. This allows for the determination of the corresponding fault's time range based on the start and end times of each fault data point. Users can better understand the autonomous driving status of the unmanned mining truck by analyzing the fault's time range and specific fault data information, leading to a more comprehensive fault handling solution. For example, if the fault data shows that the vehicle repeatedly and unexplainedly reduced its speed within a specific time range each day, by identifying the relevant time periods and considering the local weather, it was found that high humidity at night caused the engine to slow down and sensors to malfunction occasionally. This led to a decision to optimize the moisture resistance of the sensor materials to reduce the probability of the fault occurring. Therefore, the data collected and processed by this invention has high analytical accuracy and usability. Attached Figure Description
[0050] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0051] Figure 1 This is a flowchart of the method for collecting and processing fault data for analysis of unmanned mining vehicles in an embodiment of the present invention. Detailed Implementation
[0052] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0053] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.
[0054] The method for collecting and processing fault data for unmanned mining trucks in this embodiment of the invention includes the following steps: collecting fault data of the unmanned mining truck according to a pre-set fault identifier; dividing the fault data into continuous fault data and single-point fault data other than continuous fault data, where continuous fault data includes several fault data of the same type repeatedly received within a specified period; determining the start and end times (start and end times) of the faults corresponding to the continuous fault data based on the times of the first and last fault data received in the continuous fault data; determining the start and end times of the faults corresponding to the single-point fault data based on the times of receiving the single-point fault data; and determining the time range of the corresponding fault occurrence based on the start and end times of each fault data (i.e., including continuous fault data and single-point fault data).
[0055] Therefore, compared with existing technologies that process unmanned mining trucks based on single-point fault data, this invention divides fault data according to the continuity of occurrence during collection and records the start and end times of fault occurrences. This allows for the determination of the corresponding fault's time range based on the start and end times of each fault data point. Users can better understand the autonomous driving status of the unmanned mining truck based on the fault occurrence time range and specific fault data information, thus analyzing the causes of the fault from multiple perspectives and obtaining a more comprehensive fault handling solution. For example, if the fault data shows that the vehicle repeatedly and unexplainedly reduced its speed within a specific time range each day, by querying the relevant time periods and considering the local weather, it was found that high humidity at night caused the engine to slow down and sensors to malfunction occasionally. This led to a decision to optimize the moisture resistance of the sensor materials to reduce the probability of the fault occurring. Therefore, the data collected and processed by this invention has high analytical accuracy and usability.
[0056] Preferably, the fault identifier includes a unique fault identifier corresponding to each type of fault. In the above method, the start and end times of the fault corresponding to the continuous fault data are determined based on the time of the first and last fault data received in the continuous fault data; the process of determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data specifically includes:
[0057] (1) When fault data is collected and the unique fault identifier in the fault data does not exist, store the current fault data, determine the start time of the corresponding fault based on the collection time of the current fault data (i.e., the data reception time), and determine the storage duration of the current fault data based on the start time.
[0058] (2) When the storage duration reaches the specified period and the same fault identifier as the current fault data is collected, the current fault data is taken as continuous fault data, and the start time of the fault corresponding to the continuous fault data is the start time in item (1); the end time of the fault corresponding to the continuous fault data is determined according to the collection time of the last collected continuous fault data.
[0059] (3) When the storage time reaches the specified period and no fault data with the same unique fault identifier as the current fault data is collected, the current fault data is taken as single-point fault data. The end time of the corresponding fault is determined according to the collection time of the single-point fault data. That is, the start time and end time of the current single-point fault data are both the start time in item (1).
[0060] Preferably, in the above method, the start and end times of the fault corresponding to the continuous fault data are determined based on the time of the first and last fault data received in the continuous fault data; the process of determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data specifically includes:
[0061] Step A: After collecting the fault data, determine whether the unique fault identifier of the current fault data exists in the cache database. If it does, it means that the fault is still occurring and will not be processed for the time being; otherwise, it means that a new fault has occurred and proceed to Step B.
[0062] Step B: Store the current fault data in the cache database and the local database respectively, and use the collection time of the current fault data as the fault start time. Record the storage duration of the current fault in the cache database, and then proceed to step C.
[0063] Step C: When the storage duration reaches the specified period, determine whether fault data with the same unique fault identifier as the current fault data has been collected. If so, treat the current fault data as continuous fault data and proceed to step D. Otherwise, treat the current fault data as single-point fault data, and use the collection time in step B as the fault end time corresponding to the single-point fault data and update it to the local database.
[0064] Step D: When no fault data with the same unique fault identifier as the current fault data is collected after the specified period, the collection time of the last collected current fault data is used as the fault end time of the current continuous fault data and updated to the local database.
[0065] Therefore, it can be seen that the present invention stores the "full" data in a local database and processes the data in real time through a cache database (such as marking the start and end time and storage duration of specified data, adding data identifiers, etc.). The existence of the cache database can greatly improve the data processing efficiency.
[0066] Preferably, the above method further includes the following process: deleting fault data that has not received the same unique fault identifier within a specified time period to release cache resources.
[0067] Furthermore, the aforementioned cache database is a Redis (Remote Dictionary Server) database, which retrieves data using hash values, resulting in high efficiency. The local database uses a MySQL (Relational Database Management System) database.
[0068] Preferably, the fault identifier in the above method includes a unique fault identifier corresponding to each type of fault. The process of collecting fault data of the unmanned mining truck according to the pre-set unique fault identifier corresponding to each type of fault in the above method includes: setting the field value in the Java object corresponding to each unique fault identifier, converting the running data (binary stream) of the unmanned mining truck into a JSON object, and determining that the Java object is fault data when the JSON object can be converted into the Java object.
[0069] Based on this, the fields for the unique fault identifier mentioned above include: faultAddr, spn, and fmi.
[0070] Preferably, the above method further includes the following steps: assigning a fault level to the fault label corresponding to each type of fault data, so as to facilitate subsequent analysis of fault data based on the fault level and to determine the order of fault handling solutions based on the fault level.
[0071] See below. Figure 1 As shown, the method of the present invention is illustrated through a specific embodiment.
[0072] S1: Set unique fault identifiers (faultAddr, spn, fmi) and associate them with Java objects. The spn field in the Java object has a value of 518101, and the fmi field has a value of 6. Set the corresponding fault level for each fault. Fault levels include:
[0073] Minor: Fault codes such as SPN3487, FMI11, system category is engine, description is urea pump air solenoid valve open circuit;
[0074] General: Fault codes such as SPN518101, FMI6, system category BCM / Body Controller, description: high beam relay short circuit. The binary data of fault codes within a fixed time interval are summarized, packaged, and sent.
[0075] S2: At fixed time intervals, upload the binary data of the above fault codes as the fault data packet (binary stream data packet) of the unmanned mining vehicle. After parsing the fault data packet according to the predefined parsing protocol, obtain the binary data stream and convert it into a JSON object. Convert the JSON object into a corresponding Java object with various attributes. One Java object represents one fault data.
[0076] S3: Obtain an untraversed fault data, determine if the unique fault identifier of the current fault data exists in the Redis database. If it does, it means that the fault is still occurring and will not be processed for the time being. Mark the current fault data as untraversed fault data and go to S3; otherwise, it means that it is a newly occurring fault data and go to S4.
[0077] S4: Store the current fault data in both the Redis and MySQL databases, and use the collection time of the current fault data as the fault start time. Record the storage duration of the current fault in the Redis database, and then proceed to S5.
[0078] S5: When the storage time reaches the specified period (the specified period in this embodiment is the same as the fixed time interval in S2), determine whether fault data with the same unique fault identifier as the current fault data has been collected. If so, treat the current fault data as continuous fault data and go to S6; otherwise, treat the current data as single-point fault data, use the collection time in S4 as the fault end time of the single-point fault data and update it to the MySQL database, and go to S7.
[0079] S6: When no fault data with the same unique fault identifier as the current fault data is collected after the specified period, the collection time of the last collected current fault data is used as the fault end time of the current continuous fault data and updated to the MySQL database, then proceed to S7.
[0080] S7: After traversing all fault data in the current fault data packet, delete the fault data that exists in the Redis database and does not have a unique fault identifier in the current fault data packet.
[0081] After processing the received faulty data packets according to the above process, a faulty data set will be formed in the MySQL database. Based on this, users can periodically analyze the faulty data set. For example, processing can be done once a week, summarizing the occurrence time periods of each fault within the week on a chart. The y-axis represents the day, and the x-axis represents 24 hours in a day, showing which time periods each fault occurs each day. Users can use this chart to analyze whether the fault occurrences have a periodicity.
[0082] If the fault is periodic, the distributed system can further compare vehicle data such as latitude and longitude, humidity, etc., between the fault occurrence period and the normal period, and calculate the comparison results of each numerical indicator. For example, if the normal vehicle speed is 50 and the fault occurs at a speed of 60, then the normal vehicle speed is 1 and the abnormal vehicle speed is 1.2. By obtaining the differences in all indicators, the cause of the fault can be investigated.
[0083] If the fault is not periodic, broaden the time frame to examine, for example, the time periods within a month during which the fault occurred. Compare vehicle data during these periods with data from normal times to optimize the vehicle's autonomous driving strategy. For instance, if the fault data shows a vehicle repeatedly and unexplainedly reducing speed within a specific time frame each day, identifying these time periods and considering the local weather conditions reveals that high humidity at night causes the engine to slow down and sensors to malfunction occasionally. This leads to optimizing the moisture resistance of sensor materials to reduce the probability of this fault occurring. Similarly, if a vehicle repeatedly and unexplainedly hits a wall in a specific area, analyzing the current data and combining it with the latitude and longitude information of the uploaded data reveals that poor network signal at the vehicle's location caused data upload failures, leading to a brief loss of control and the collision. This requires timely resolution of the network issue.
[0084] At the same time, users can also query fault code data based on time range, such as vehicle number, fault source address, system category, system name and model, Chinese description, FMI, fault level, fault type, fault unit and other information.
[0085] This invention also provides a storage medium storing a computer program, which, when executed by a processor, implements the above-described method. It should be noted that the storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, ROM (Read-Only Memory), RAM (Random Access Memory), a magnetic disk, or an optical disk.
[0086] This invention also provides a fault data acquisition and processing system for unmanned mining vehicles, including a client and a server.
[0087] The client is used to upload fault data to the server.
[0088] The server is used to process fault data according to the above methods.
[0089] Furthermore, the fault data acquisition and processing system for unmanned mining trucks in this embodiment of the invention also includes the unmanned mining truck, and the aforementioned client is set on the unmanned mining truck.
[0090] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer-readable storage media (or non-transitory media) and communication media (or transient media).
[0091] As is known to those skilled in the art, the term computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0092] For example, the computer-readable storage medium may be an internal storage unit of the electronic device described in the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., provided on the electronic device.
[0093] The above are merely specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the scope of the claims.
Claims
1. A method for collecting and processing fault data for analysis of unmanned mining vehicles, characterized in that, The method includes the following steps: collecting fault data of the unmanned mining vehicle according to a pre-set fault identifier; dividing the fault data into continuous fault data and single-point fault data other than continuous fault data, wherein continuous fault data includes several fault data of the same type repeatedly received within a specified period; determining the start and end time of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data; determining the start and end time of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data; and determining the time range of the corresponding fault based on the start and end time of each fault data. The fault identifier includes a unique fault identifier corresponding to each type of fault. The process of determining the start and end times of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data, and determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data, includes: When fault data is collected and the unique fault identifier in the fault data does not exist, the current fault data is stored, the start time of the corresponding fault is determined according to the collection time of the current fault data, and the storage duration of the current fault data is determined according to the start time. When the storage time reaches the specified period and fault data with the same unique fault identifier as the current fault data is collected, the current fault data is regarded as continuous fault data; the end time of the fault corresponding to the continuous fault data is determined according to the collection time of the last collected continuous fault data. When the storage time reaches the specified period and no fault data with the same unique fault identifier as the current fault data is collected, the current fault data is taken as single-point fault data, and the end time of the corresponding fault is determined according to the collection time of the single-point fault data. The process of determining the start and end times of the fault corresponding to the continuous fault data based on the time of the first and last fault data received in the continuous fault data, and determining the start and end times of the fault corresponding to the single-point fault data based on the time of receiving the single-point fault data, specifically includes: after collecting fault data, if there is no unique fault identifier for the current fault data in the cache database, the current fault data is stored in both the cache database and the local database, and the collection time of the current fault data is taken as the fault start time. The storage duration of the current fault is recorded in the cache database. When the storage duration reaches the specified period, it is determined whether fault data with the same unique fault identifier as the current fault data has been collected. If so, the current fault data is treated as continuous fault data. When no fault data with the same unique fault identifier as the current fault data is collected after a specified period, the collection time of the last collected current fault data is used as the fault end time of the current continuous fault data and updated to the local database. Otherwise, the current fault data will be used as the single point of failure data, and the fault start time of the current fault data will be used as the fault end time of the single point of failure data and updated to the local database.
2. The method for collecting and processing fault data for analysis of unmanned mining vehicles as described in claim 1, characterized in that, The method also includes the following step: deleting fault data for which the same unique fault identifier has not been received within a specified time period.
3. The method for collecting and processing fault data for analysis of unmanned mining vehicles as described in claim 1, characterized in that: The cache database is a Redis database, and the local database is a MySQL database.
4. The method for collecting and processing fault data for analysis of unmanned mining vehicles as described in any one of claims 1 to 3, characterized in that: The process of collecting fault data of unmanned mining trucks according to pre-set fault identifiers includes: setting field values in a Java object corresponding to each unique fault identifier, converting the running data of the unmanned mining truck into a JSON object, and determining that the Java object is fault data when the JSON object can be converted into the Java object.
5. The method for collecting and processing fault data for analysis of unmanned mining vehicles as described in claim 4, characterized in that: The fields for the unique fault identifier include: faultAddr, spn, and fmi.
6. The method for collecting and processing fault data for analysis of unmanned mining vehicles as described in any one of claims 1 to 3, characterized in that: The method also includes the following step: assigning a fault level to the fault tag corresponding to each type of fault data.
7. A fault data acquisition and processing system for unmanned mining vehicles, comprising a client and a server; The client is used to: upload fault data to the server; The server is used to process fault data according to any one of claims 1 to 6.
8. The fault data acquisition and processing system for unmanned mining trucks as described in claim 7, characterized in that: The system also includes unmanned mining trucks, on which the client is mounted.