CN116893662B - Fault code processing system and method applied to unmanned vehicle - Google Patents
Fault code processing system and method applied to unmanned vehicle Download PDFInfo
- Publication number
- CN116893662B CN116893662B CN202311149256.4A CN202311149256A CN116893662B CN 116893662 B CN116893662 B CN 116893662B CN 202311149256 A CN202311149256 A CN 202311149256A CN 116893662 B CN116893662 B CN 116893662B
- Authority
- CN
- China
- Prior art keywords
- fault code
- fault
- module
- code processing
- key data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012545 processing Methods 0.000 title claims abstract description 91
- 238000000034 method Methods 0.000 title description 18
- 238000004891 communication Methods 0.000 claims abstract description 7
- 238000003672 processing method Methods 0.000 claims abstract description 6
- 239000013598 vector Substances 0.000 claims description 37
- 238000010801 machine learning Methods 0.000 claims description 6
- 230000004044 response Effects 0.000 claims description 6
- 230000006870 function Effects 0.000 description 29
- 230000005856 abnormality Effects 0.000 description 13
- 230000008569 process Effects 0.000 description 9
- 238000012986 modification Methods 0.000 description 8
- 230000004048 modification Effects 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 6
- 238000000605 extraction Methods 0.000 description 6
- 238000012549 training Methods 0.000 description 6
- 230000002159 abnormal effect Effects 0.000 description 5
- 230000001364 causal effect Effects 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 4
- 230000001133 acceleration Effects 0.000 description 3
- 238000013527 convolutional neural network Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 239000000446 fuel Substances 0.000 description 2
- 238000002372 labelling Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 241000157593 Milvus Species 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 239000002826 coolant Substances 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 238000012806 monitoring device Methods 0.000 description 1
- 238000003062 neural network model Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B23/00—Testing or monitoring of control systems or parts thereof
- G05B23/02—Electric testing or monitoring
- G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
- G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
- G05B23/0262—Confirmation of fault detection, e.g. extra checks to confirm that a failure has indeed occurred
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24065—Real time diagnostics
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Automation & Control Theory (AREA)
- Testing And Monitoring For Control Systems (AREA)
Abstract
The embodiment of the application discloses a fault code processing system and a fault code processing method applied to an unmanned vehicle. The system comprises: the cloud server comprises a cloud server, a domain controller, a safety processor and a chassis module, wherein the domain controller comprises a fault code processing module and a functional module, the safety processor comprises a safety module, and the fault code processing module is in communication connection with the safety module and the cloud server; the functional module is in communication connection with the fault code processing module and the safety module.
Description
Technical Field
The specification relates to the field of unmanned vehicles, and in particular relates to a fault code processing system and a fault code processing method applied to an unmanned vehicle.
Background
Unmanned vehicles (also known as autopilots) rely on artificial intelligence, visual computing, radar, monitoring devices, and global positioning systems to cooperate so that computing devices can operate the vehicle automatically and safely without active operation.
The existing unmanned vehicle is difficult to trace faults when faults occur due to no manual intervention during operation, and the automatic processing effect of the faults cannot be ensured. Accordingly, it is desirable to provide a system that is easy to trace and is capable of automatically handling partial faults.
Disclosure of Invention
One of the embodiments of the present specification provides a fault code processing system applied to an unmanned vehicle, including: the cloud server comprises a cloud server, a domain controller, a safety processor and a chassis module, wherein the domain controller comprises a fault code processing module and a functional module, the safety processor comprises a safety module, and the fault code processing module is in communication connection with the safety module and the cloud server; the functional module is in communication connection with the fault code processing module and the safety module; the functional module is configured to: executing a functional program; generating a first fault code and/or key data based on the execution result; uploading the first fault code and/or the key data to the fault code processing module and/or the security module; the security module is configured to: determining whether a fault occurs based on the received first fault code and/or the key data; responding to the occurrence of faults, and sending a preset instruction to the chassis module; uploading a second fault code to the fault code processing module; the chassis module is configured to execute the preset instructions; the fault code processing module is configured to: tracing the received first fault code and/or the second fault code; uploading the first fault code and/or the second fault code and/or the tracing result to the cloud server.
One of the embodiments of the present specification provides a fault code processing method applied to an unmanned vehicle, which is executed based on a security module, and is characterized by comprising: determining whether a fault occurs based on the first fault code and/or the key data received from the functional module; responding to the occurrence of faults, and sending a preset instruction to the chassis module; and uploading the second fault code to the fault code processing module.
One of the embodiments of the present disclosure provides a fault code processing method applied to an unmanned vehicle, which is executed based on a functional module and includes: executing a functional program; generating a first fault code and/or key data based on the execution result; and uploading the first fault code and/or the key data to a fault code processing module and/or a security module.
One of the embodiments of the present disclosure provides a fault code processing method applied to an unmanned vehicle, which is executed based on a fault code processing module and includes: tracing the first fault code received from the functional module and/or the second fault code received from the safety module; and uploading the first fault code and/or the second fault code and/or the tracing result to a cloud server.
Drawings
The present specification will be further elucidated by way of example embodiments, which will be described in detail by means of the accompanying drawings. The embodiments are not limiting, in which like numerals represent like structures, wherein:
FIG. 1 is an exemplary block diagram of a fault code processing system according to some embodiments of the present description;
FIG. 2 is an exemplary flowchart of steps performed by modules of the fault code processing system shown in some embodiments of the present description;
FIG. 3 is an exemplary block diagram of a fault prediction model shown in accordance with some embodiments of the present description.
Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings that are required to be used in the description of the embodiments will be briefly described below. It is apparent that the drawings in the following description are only some examples or embodiments of the present specification, and it is possible for those of ordinary skill in the art to apply the present specification to other similar situations according to the drawings without inventive effort. Unless otherwise apparent from the context of the language or otherwise specified, like reference numerals in the figures refer to like structures or operations.
It will be appreciated that "system," "apparatus," "unit" and/or "module" as used herein is one method for distinguishing between different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.
As used in this specification and the claims, the terms "a," "an," "the," and/or "the" are not specific to a singular, but may include a plurality, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that the steps and elements are explicitly identified, and they do not constitute an exclusive list, as other steps or elements may be included in a method or apparatus.
A flowchart is used in this specification to describe the operations performed by the system according to embodiments of the present specification. It should be appreciated that the preceding or following operations are not necessarily performed in order precisely. Rather, the steps may be processed in reverse order or simultaneously. Also, other operations may be added to or removed from these processes.
In some embodiments, the unmanned vehicle can monitor its running condition in real time during running and record the fault identification when the fault occurs, but when the vehicle is analyzed later, the abnormal components can not be determined quickly only by the fault identification, and each component needs to be checked.
In view of this, some embodiments of the present disclosure provide a fault code processing system applied to an unmanned vehicle, which facilitates locating a fault location and technical analysis by acquiring a fault code and tracing in time.
FIG. 1 is an exemplary block diagram of a fault code processing system according to some embodiments of the present description. FIG. 2 is an exemplary flowchart of steps performed by modules of a fault code processing system according to some embodiments of the present description.
As shown in fig. 1, the fault code processing system 100 applied to an unmanned vehicle shown in the drawing includes: cloud server 110, security processor 120, domain controller 130, and chassis module 140.
The safety processor 120 is a device for processing data related to the operation or safety of the unmanned vehicle, and in some embodiments, the safety processor 120 may be a Micro Control Unit (MCU), such as an inflight Tc397.
The security processor 120 includes a security module 122. The security module 122 may be used to collect and process critical data and/or fault codes on the domain controller 130. For more details on the security module 122, see later description in relation to fig. 2.
The cloud server 110 is a computing service provider of the unmanned vehicle platform (or controller), and the cloud server 110 may process or store received data (e.g., uploaded by the domain controller 130), and so on.
The cloud server 110 is communicatively coupled to the unmanned vehicle, and in some embodiments, the cloud server 110 is coupled to the domain controller 130 via a network. Note that, the communication connection mentioned later may be a connection through a network, and the network may include a public network (e.g., the internet), a private network (e.g., a Local Area Network (LAN), a Wide Area Network (WAN)), and the like, or a combination thereof.
The domain controller 130 is a processor in an unmanned vehicle that may be used to perform data acquisition, processing, transmission, and the like. In some embodiments, domain controller 130 may be a system-on-a-chip (SoC), such as an inflight (NVIDIA) Orin.
In some embodiments, domain controller 130 includes a fault code processing module 132 and a functional module 134, and domain controller 130 may implement one or more preset operations by running one or more of functional modules 134.
The fault code processing module 132 is communicatively connected to the function module 134, the security module 122, and the cloud server 110. The fault code processing module 132 is configured to collect, trace, and upload fault codes (e.g., the first fault code and/or the second fault code) issued by the functional modules 134 and the security module 122 to the cloud server 110 for processing, and for further details regarding the fault code processing module 132, see fig. 2 below.
The functional module 134 is communicatively coupled to the fault code processing module 132 and the secure module 122, and in some embodiments, the functional module 134 is configured to report key data and/or fault codes to the fault code processing module 132 and the secure processor 120, respectively.
In some embodiments, the functional module 134 may execute programs that perform certain functions, such as acquiring sensor data, processing data, encoding and decoding information, and so forth. The functional module 134 may be configured to execute a plurality of programs by one module, or may include a plurality of sub-modules for executing different programs, respectively. For more details on the functional module 134, see later on, the description related to fig. 2.
The chassis module 140 may be part or all of the chassis systems (e.g., drive train, travel system, steering system, and brake system) of the unmanned vehicle. The chassis module 140 is configured to execute control commands issued by the security module 122, wherein the control commands may include, but are not limited to, acceleration, deceleration, steering, engaging gears, braking, and the like.
In some embodiments, the fault code processing system 100 may also include other modules, such as a transmission module, external environment sensors, etc., as desired. It should be noted that, the fault code processing system 100 may be applied to, for example, an unmanned train, an unmanned ship, or the like, in addition to an unmanned vehicle; the fault code processing system 100 may be applied to a vehicle driven by a driver.
It should be noted that the above description of the fault code processing system 100 and its modules is for convenience only and is not intended to limit the present description to the scope of the illustrated embodiments. It will be appreciated by those skilled in the art that, given the principles of the system, various modules may be combined arbitrarily or a subsystem may be constructed in connection with other modules without departing from such principles. In some embodiments, the fault code processing module 132 and the functional module 134 disclosed in fig. 1 may be different modules in a system, or may be one module to implement the functions of two or more modules. For example, each module may share one memory module, or each module may have a respective memory module. Such variations are within the scope of the present description.
Referring also to fig. 2, the functions of the function module 134, the security module 122, and the fault code processing module 132 in the fault code processing system 100 are shown configured, as will be described separately hereinafter.
In some embodiments, the functional module 134 is configured to perform one or more of steps 210-230.
Step 210, executing the functional program.
A functional program is a program designed to implement one or more functions by executing. In some embodiments, the function program may be a program that implements a function related to a running state of the vehicle or running safety. For example, the function program may implement a function of determining a vehicle state based on a plurality of sets of data collected by sensors on the vehicle, a function of determining a driveline control parameter based on current path information, or the like.
In some embodiments, the functional module 134 may obtain the execution result by executing a functional program. In some other embodiments, the executive may obtain information including, in addition to the results of execution, time spent executing, response delays, and the like.
Step 220, generating a first fault code and/or key data based on the execution result.
The execution result is the output of the function program. Taking the foregoing function program as an example, a function of determining a vehicle state based on data collected by a sensor on a vehicle may be implemented, the execution result may include data (e.g., temperature, current, voltage, etc.) in which abnormality may exist among a plurality of sets of data collected by the sensor, and data specific information (e.g., higher than a preset value or lower than a preset value, etc.) in which abnormality may exist.
The first fault code is a code representing an execution result, and the code can be in the form of letters and/or numerical values. For example, in the first fault code, a temperature abnormality may be indicated by "01", a current abnormality may be indicated by "02", or the like.
In some embodiments, when the execution result indicates that the vehicle is not abnormal (e.g., each data is located in a preset interval) or fails to determine an abnormality, the first fault code may not be generated, or a first fault code indicating no abnormality/undetermined abnormality, such as "00", may be generated.
The critical data represents data that is of interest or may have an exception in the execution result. In some embodiments, the partial data is used as important data in the vehicle form process, and even if the partial data is within a preset range, the partial data can also be used as key data, such as engine speed, motor power, vehicle speed per hour and the like.
In some embodiments, the first fault code and the critical data may be included in the execution result, in other words, the functional program may be configured to output the critical data and the first fault code simultaneously when there is an exception in the data. For example, the output of the functional program may be in the form of: the first fault code (01) and the key data (the current water temperature of the engine is 120 ℃ and 20% higher than a preset value).
In some embodiments, the function module 134 may output a plurality of first fault codes. For example, when the engine speed exceeds a preset value of 20% and the engine water temperature exceeds a preset value of 20%, the first failure codes "01" (temperature abnormality) and "03" (speed abnormality) may be included.
Step 230, upload the first fault code and/or key data to the fault code handling module 132 and/or the security module 122.
The function module 134 may upload the first fault code and/or key data to the security module 122 via a network, or upload the first fault code and/or key data to both the fault code processing module 132 and the security module 122, to facilitate further processing and analysis of the data by the fault code processing module 132 and/or the security module 122.
The function module 134 may obtain vehicle operation information, and make a preliminary determination of a fault based on a function program; also, the functional module 134 may send its results of operation to other components for further analysis by the other components.
In some embodiments, the security module 122 is configured to perform one or more of steps 310-330.
In step 310, it is determined whether a fault has occurred based on the first fault code and/or key data received from the functional module 134.
Faults are events where unmanned vehicles have functional problems, for example, faults may include a steering failure, a braking abnormality, or a transmission abnormality, etc.
In some embodiments, the security module 122 may determine whether a fault has occurred based on the first fault code and/or the critical data in a manner that includes determining whether each of the first fault code and/or the critical data meets a preset condition; and judging that the fault occurs when one or more data do not meet the preset conditions. The preset conditions may be set according to actual conditions of the vehicle, for example, the preset conditions may be that each parameter is located in a safe operation interval, the safe operation interval may be that a normal operation parameter interval of each component is enlarged by a preset proportion (for example, 20% (for example, the operation temperature is 40-100 ℃, and the interval is 32-120 ℃ after 20% enlargement) and when the key data exceeds the safe operation interval, it is determined that a fault occurs, and when the key data exceeds the normal operation parameter interval but is in the safe operation interval, it may be determined that a fault does not occur temporarily.
In some embodiments, based on the first fault code and/or the key data may not be sufficient to determine that the current vehicle is faulty, if the aforementioned key data is outside the normal operating parameter interval but within the safe operating interval or simply the vehicle speed is too low, the safety module 122 may determine that the current first fault code and/or key data indicates that the vehicle is not faulty.
In some embodiments, the security module 122 may not perform the subsequent steps 320 and 330 in response to a failure with the vehicle.
In response to the occurrence of the fault, a preset command is issued to the chassis module 140, step 320.
The preset instructions are instructions executable by the chassis module 140, and the preset instructions may enable the chassis module 140 to perform one or more operations, such as acceleration, deceleration, steering, gear engagement, braking, and the like. In some embodiments, the preset instructions may be corresponding instructions that are manually matched according to the fault or type of fault, and the chassis module 140 may increase safety in the event of a vehicle fault or resolve the fault by executing the instructions.
In some embodiments, the preset instructions may be instructions to cause components in the chassis module 140 to operate to a particular state (e.g., a safe mode), and in response to a fault, the preset instructions may be issued to the chassis module 140 for a safe intervention regardless of the type of fault.
In some embodiments, the security module 122 is further configured to: determining a fault type in response to the occurrence of the fault; determining a preset instruction based on the fault type; the preset instructions are issued to the chassis module 140.
The fault type indicates the category to which the fault belongs, and the fault type can be divided according to the position of the fault (such as software fault, transmission system fault and the like) or the emergency degree of the fault (such as high-risk fault, general fault and the like).
In some embodiments, the security module 122 may determine the fault type based on the fault and the first fault code and/or the critical data. In some embodiments, the security module 122 may utilize a preset fault table to infer the fault type from the first fault code and/or key data. The condition in the fault table is a preset numerical range of the first fault code and/or the key data, and the corresponding result is the deduced fault type. And when the first fault code and/or the key data meet the conditions in the table, determining that the inferred fault type corresponding to the conditions is the current fault type. For example, when the first fault code is "03" (abnormal engine speed) and the key data includes fuel consumption exceeding 25% of the preset value per unit time, it is inferred that the fault is likely to be "spark plug fault" according to the preset fault table.
In some embodiments, the manner of determining the preset instructions based on the fault type may be similar to the manner of determining the preset instructions based on the fault, i.e., using the corresponding instructions manually matched according to the fault type as the preset instructions. For example, when the fault type is a high-risk fault, the preset command may be an emergency brake; when the fault type is a general fault, the preset instruction can be to stop by side; when the type of failure is "spark plug failure", the preset command may be to control the vehicle to run normally, but limit the maximum speed to 60% of the original speed, etc.
By determining the fault type, a preset command suitable for the current vehicle condition can be quickly determined and sent to the chassis module 140, so that the driving safety of the vehicle is ensured.
The vehicle may be subject to multiple faults while in operation, and there may be multiple different ways of coping with different faults, different preset instructions may be employed, and thus, in some embodiments, it may also be determined whether a fault and/or type of fault has occurred through a machine learning model.
Thus, in some embodiments, the security module 122 may be further configured to: based at least on the critical data, it is determined whether a fault and/or a fault type has occurred by a fault prediction model 300, the fault prediction model 300 being a machine learning model.
Referring to fig. 3, in some embodiments, the fault prediction model 300 may be a neural network model, such as CNN (convolutional neural network), DNN (deep neural network), or the like. The fault prediction model 300 is used to determine whether a vehicle is faulty and/or of the type of fault.
In some embodiments, the inputs to the fault prediction model 300 may include a first fault code and/or key data; the output of the model is that when the vehicle fails, the failure is indicated; when the vehicle fails, the failure is indicated and the failure type is output at the same time. In some embodiments, the inputs to the fault prediction model 300 may also include a vehicle model number.
In some embodiments, the fault prediction model 300 may be trained from a plurality of labeled training samples. Specifically, a plurality of labeled training samples may be input into the initial fault prediction model 300, a loss function may be constructed from the labels and the results of the initial fault prediction model 300, and parameters of the initial fault prediction model 300 may be iteratively updated by gradient descent or other methods based on the loss function. Model training is completed when preset conditions are met, resulting in a trained fault prediction model 300. The preset condition may be that the loss function converges, the number of iterations reaches a threshold value, etc.
In some embodiments, the training samples trained by the fault prediction model 300 may include at least historical operating data and/or first historical fault codes of other sample unmanned vehicles within the platform (or controller). The historical operation data at least comprises historical key data; for example, when other unmanned vehicles (of the same type or different types) complete a journey under the control of a platform, working parameters of various components such as an engine, a transmission system, a sensor and the like in the journey; the tag may be the result of whether the sample vehicle actually failed and the type of failure in the case of the historical operating data and/or the first historical fault code, and the tag may be obtained based on manual labeling.
By using the failure prediction model 300 trained based on other vehicle history data, it is possible to quickly and accurately determine whether or not the current vehicle is failed and the type of failure, so as to determine a preset instruction suitable for the current vehicle situation based on the type of failure.
In some embodiments, the security module 122 may be further configured to: constructing a data vector based on the key data; and determining whether faults and/or fault types occur or not based on the search results of the data vectors in a database, wherein the database comprises a plurality of historical data vectors constructed based on a plurality of historical key data and/or faults and/or fault types respectively corresponding to the historical data vectors.
In some embodiments, the security module 122 may construct a data vector based on the key data by adopting a feature extraction method, specifically, may determine a vector corresponding to each data in the key data by adopting a feature extraction algorithm (such as one-hot coding or TF-IDF algorithm) or a feature extraction model (such as convolutional neural network or transducer) and the like, and fuse (such as para-addition) a plurality of vectors to obtain the data vector.
In some embodiments, the database includes a historical data vector constructed based on a plurality of historical key data, and the manner of constructing the historical data vector based on the historical key data may be the same as the manner of constructing the data vector based on the key data; the database also comprises fault types corresponding to the historical data vectors.
In some embodiments, the security module 122 may retrieve the results of the retrieval of the data vector in the database by means such as the Milvus engine or other means. Different preset conditions can be determined according to different used vector retrieval modes, for example, in some embodiments, a vector distance (such as euclidean distance, manhattan distance or cosine distance) between a data vector and a historical data vector can be determined, when the vector distance is smaller than a preset value, faults are judged to exist, the fault type corresponding to the historical data vector is the fault type of the current vehicle, and if the vector distance between the data vector and any historical data vector is larger than the preset value, no faults can be judged.
Through the pre-established database, whether the current vehicle has faults and the fault type can be rapidly and accurately determined.
In step 330, the second fault code is uploaded to the fault code processing module 132.
The second fault code is a code that characterizes the vehicle fault determined by the security module 122. In some embodiments, the second fault code may be associated with the fault determined in step 310, e.g., the fault type inferred in the previous example to be "spark plug fault", then the second fault code may be "1S".
In some embodiments, the second fault code may be the same or partially the same as the first fault code, e.g., the security module 122 may determine that the vehicle is currently free of faults based on the first fault code and/or the critical data in step 310, and upload the second fault code to the fault code processing module 132. In some embodiments, the security module 122 may also upload the second fault code and the first fault code at the same time if the second fault code is different from the first fault code. In some embodiments, the security module 122 may also upload the second fault code and critical data to the fault code processing module 132 simultaneously.
The first fault code and the second fault code generated by the functional module 134 and the security module 122 may be uploaded to the fault code processing module 132 in a certain period, so as to learn the running state of the vehicle or trace the source in time. In some embodiments, the function module 134 is configured to upload the first fault code and/or critical data to the fault code processing module 132 and/or the security module 122 based on a preset period; the security module 122 is configured to upload the second fault code to the fault code processing module 132 based on a preset period.
The preset period is an uploading period of the first fault code and/or the second fault code, and the preset period can be obtained by manually setting or automatically adjusting the vehicle before running. For example, the function module 134 may upload the first fault code and/or critical data to the fault code processing module 132 and/or the security module 122 every 30 seconds; the security module 122 may upload the second fault code to the fault code processing module 132 every 30 seconds. In some embodiments, the preset period of the function module 134 and the security module 122 may also be 1 minute, 10 seconds, 5 seconds, or the like.
In some embodiments, the preset period may vary during vehicle operation, such as 10 seconds when the function module 134 is currently generating the first fault code, 20 seconds when the function module 134 is not currently generating the first fault code, and so on.
In some embodiments, the preset period of the function module 134 and the security module 122 may be different, e.g., the function module 134 may upload the first fault code and/or critical data to the fault code processing module 132 and/or the security module 122 every 15 seconds; the security module 122 may upload the second fault code to the fault code processing module 132 every 20 seconds, and for convenience of description, the function module 134 and the security module 122 will be described with the same preset period.
In some embodiments, the preset period may be determined based on operational data and/or vehicle information of the unmanned vehicle.
The operation data are the current operation parameters of the vehicle and can be obtained by sensors on the vehicle. For example, the operating data may include the current travel time, the vehicle speed per hour, the engine speed, the transmission gear, and the like.
The vehicle information is an objective parameter of the vehicle and can be obtained through a specification or a vehicle preset interface. For example, the vehicle information may include age of the vehicle, vehicle performance parameters (horsepower, hundred kilometers acceleration), historical failure, and the like.
In some embodiments, the fault code processing system 100 may determine a current vehicle stability factor from the plurality of operational data and/or vehicle information (the stability factor is smaller the more the operational data and/or vehicle information deviates from the preset value), and determine the preset period based on the stability factor, wherein the larger the stability factor is, the longer the preset period is.
In some embodiments, fault code processing system 100 may determine vehicle usage characteristics based on the operating data and/or the vehicle information; the preset period is determined based on the vehicle usage characteristics.
The vehicle usage feature is a feature vector obtained from the operation data and/or the vehicle information by means of feature extraction. The feature vector may be a multidimensional vector, the operational data and the vehicle information may correspond to two feature vectors, respectively, and in some embodiments, the two feature vectors may be spliced or fused to obtain a vehicle usage feature.
As described above, the fault code processing system 100 may determine the vehicle usage feature by using a feature extraction method, and the feature extraction method may refer to the method of constructing the data vector, which is not described herein.
In some embodiments, the determining of the preset period based on the vehicle usage characteristic may be performed by searching a preset recommended period table for the determined recommended period as the preset period by means of vector matching. The recommended periodic table comprises reference vehicle use characteristics obtained by clustering based on historical operation data of other unmanned vehicles and vehicle information, and manually set recommended periods corresponding to the reference vehicle use characteristics.
The manner of retrieving the vector in the recommended periodic table may refer to the manner of retrieving the data vector in the database as described above, and will not be described herein. For example, in some embodiments, whether the current vehicle usage feature matches the reference vehicle usage feature may be determined based on the vector distance, and when the vector distance is less than the distance threshold, the two are considered to match, and a recommended period corresponding to the reference vehicle usage feature may be used as the preset period of the current vehicle.
The preset period can be selected quickly by determining the use characteristics of the vehicle, and the historical operation data of other vehicles are used as supports in the preset period, so that the selected preset period is more accurate.
In some embodiments, fault code processing module 132 is configured to perform step 410 and/or step 420.
Step 410 performs a tracing process on the first fault code received from the functional module 134 and/or the second fault code received from the security module 122.
The trace-source processing is a processing operation performed to determine the source (e.g., a certain component) of the occurrence of the fault code. When a fault code (e.g., a first fault code or a second fault code) occurs, other faults will occur in the upstream and downstream modules of the corresponding components. The source corresponding to the fault code causing the fault can be found, so that the efficiency of troubleshooting the problem can be effectively improved, and the working difficulty is reduced.
In some embodiments, after performing the tracing process, the fault code processing module 132 may obtain a tracing result, where the tracing result is a root (e.g., a certain component) of the vehicle that causes a fault or abnormality.
The trace-out result may be represented by the code of the abnormal part. In some embodiments, characters representing the tracing result may be added at the end of the fault code to reflect the tracing result of the fault code. For example, if the tracing result indicates that the engine water tank temperature sensor is abnormal, the first fault code "01" may be represented as "01TS", and if the tracing result indicates that the coolant is insufficient to cause the abnormality, the first fault code and the tracing result may be represented as "01CL", etc.
Because the vehicle structure is complex, the fault code processing module 132 may perform the tracing process with the aid of machine learning. In some embodiments, the fault code processing module is further configured to perform tracing processing on the received first fault code and/or the second fault code based on a tracing model, so as to obtain a tracing result, where the tracing model is a machine learning model.
In some embodiments, the input of the traceability model may include a first fault code and/or a second fault code; and outputting the model as a tracing result. The tracing model may be trained in a similar manner to the fault prediction model 300, and may be specifically described with reference to fig. 3.
In some embodiments, the training samples of the traceability model training may include at least a first and/or a second fault history code of other sample unmanned vehicles within the platform (or controller), e.g., the first and second history fault codes that occur during a trip when other unmanned vehicles complete the trip under the control of the platform; the label can be a historical tracing result corresponding to the first historical fault code and the second historical fault code, the historical tracing result can be manually determined based on the first historical fault code and the second historical fault code which occur in the journey and combined with other operation parameters, and the label can be obtained based on manual labeling.
Manual experience can be introduced through the tracing model, and tracing results can be accurately determined based on fault codes.
In some embodiments, the trace-back result may include at least a precedence relationship and/or a logic relationship associated with the first fault code and/or the second fault code.
The sequence may be determined based on a time at which the fault code processing module 132 obtains the fault code, where the sequence includes an order of obtaining the plurality of first fault codes, an order of obtaining the plurality of second fault codes, and an order of obtaining the first fault code and the second fault code. The traceability results can have a chain relation based on the sequence, so that the vehicle faults can be analyzed more conveniently.
The logical relationship may reflect a dependency of the first fault code and/or the second fault code, such as the foregoing engine water temperature anomaly, a temperature sensor anomaly or an engine anomaly that cannot be traced only from temperature, and a subsequent (e.g., related to fuel consumption, operating conditions, etc.) first fault code and/or second fault code may need to be obtained to facilitate determination.
In some embodiments, the logical relationship may include a causal relationship. In some embodiments, the causal relationship may be determined based on a query causal table, for example, trigger reasons of various faults may be pre-stored in the causal table, and subsequent faults triggered by the faults, or early faults triggering the faults, etc., so as to obtain the causal relationship of the first fault code and/or the second fault code.
Based on the sequence relation and the logic relation, the information contained in the traceability result is more abundant, and the vehicle operation data can be conveniently analyzed and processed subsequently.
Step 420, upload the first fault code and/or the second fault code and/or the tracing result to the cloud server 110.
In some embodiments, the fault code processing module 132 uploads the first fault code, the second fault code and the tracing result to the cloud server 110, and if the tracing result cannot be obtained in the tracing process performed by the fault code processing module 132, the first fault code and/or the second fault code may be directly uploaded to the cloud server 110. The server may store, further analyze, or highlight one or more of the first fault code, the second fault code, and the traceability result in a display device of the platform (or the controller).
The fault code processing module 132 timely performs tracing and obtains tracing results based on the fault codes, so that subsequent vehicle operation data can be conveniently analyzed and processed, and the timely obtained results are more objective.
Through being applied to unmanned vehicle's trouble code processing system 100, can make the vehicle trouble obtain reliable processing to in time collect the obstacle sign indicating number and trace to the source, be convenient for quick location system trouble, effectively improve the efficiency of troubleshooting the problem, reduce the work degree of difficulty and can supply follow-up technical analysis.
It should be noted that the descriptions of steps 210-230, steps 310-330, steps 410 and steps 420 are merely for illustration and description, and are not intended to limit the application scope of the present disclosure. Various modifications and changes may be made to steps 210-230, steps 310-330, steps 410 and steps 420 by those skilled in the art under the guidance of the present specification. However, such modifications and variations are still within the scope of the present description.
While the basic concepts have been described above, it will be apparent to those skilled in the art that the foregoing detailed disclosure is by way of example only and is not intended to be limiting. Although not explicitly described herein, various modifications, improvements, and adaptations to the present disclosure may occur to one skilled in the art. Such modifications, improvements, and modifications are intended to be suggested within this specification, and therefore, such modifications, improvements, and modifications are intended to be included within the spirit and scope of the exemplary embodiments of the present application.
Meanwhile, the specification uses specific words to describe the embodiments of the specification. Reference to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic is associated with at least one embodiment of the present description. Thus, it should be emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various positions in this specification are not necessarily referring to the same embodiment. Furthermore, certain features, structures, or characteristics of one or more embodiments of the present description may be combined as suitable.
Furthermore, the order in which the elements and sequences are processed, the use of numerical letters, or other designations in the description are not intended to limit the order in which the processes and methods of the description are performed unless explicitly recited in the claims. While certain presently useful inventive embodiments have been discussed in the foregoing disclosure, by way of various examples, it is to be understood that such details are merely illustrative and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements included within the spirit and scope of the embodiments of the present disclosure. For example, while the system components described above may be implemented by hardware devices, they may also be implemented solely by software solutions, such as installing the described system on an existing server or mobile device.
Likewise, it should be noted that in order to simplify the presentation disclosed in this specification and thereby aid in understanding one or more inventive embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof. This method of disclosure, however, is not intended to imply that more features than are presented in the claims are required for the present description. Indeed, less than all of the features of a single embodiment disclosed above.
In some embodiments, numbers describing the components, number of attributes are used, it being understood that such numbers being used in the description of embodiments are modified in some examples by the modifier "about," approximately, "or" substantially. Unless otherwise indicated, "about," "approximately," or "substantially" indicate that the number allows for a 20% variation. Accordingly, in some embodiments, numerical parameters set forth in the specification and claims are approximations that may vary depending upon the desired properties sought to be obtained by the individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and employ a method for preserving the general number of digits. Although the numerical ranges and parameters set forth herein are approximations that may be employed in some embodiments to confirm the breadth of the range, in particular embodiments, the setting of such numerical values is as precise as possible.
Each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., referred to in this specification is incorporated herein by reference in its entirety. Except for application history documents that are inconsistent or conflicting with the content of this specification, documents that are currently or later attached to this specification in which the broadest scope of the claims to this specification is limited are also. It is noted that, if the description, definition, and/or use of a term in an attached material in this specification does not conform to or conflict with what is described in this specification, the description, definition, and/or use of the term in this specification controls.
Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments of this specification. Other variations are possible within the scope of this description. Thus, by way of example, and not limitation, alternative configurations of embodiments of the present specification may be considered as consistent with the teachings of the present specification. Accordingly, the embodiments of the present specification are not limited to only the embodiments explicitly described and depicted in the present specification.
Claims (8)
1. A fault code processing system for use with an unmanned vehicle, comprising: the cloud server, the domain controller, the safety processor and the chassis module, wherein the domain controller comprises a fault code processing module and a functional module, the safety processor comprises a safety module, and the safety module comprises a plurality of modules,
the fault code processing module is in communication connection with the safety module and the cloud server;
the functional module is in communication connection with the fault code processing module and the safety module;
the functional module is configured to:
executing a functional program;
generating a first fault code and/or key data based on the execution result;
uploading the first fault code and/or the key data to the fault code processing module and/or the security module;
the security module is configured to:
determining whether a fault occurs based on the received first fault code and/or the key data;
responding to the occurrence of faults, and sending a preset instruction to the chassis module;
uploading a second fault code to the fault code processing module;
the chassis module is configured to execute the preset instructions;
the fault code processing module is configured to:
tracing the received first fault code and/or the second fault code;
uploading the first fault code and/or the second fault code and/or the tracing result to the cloud server.
2. The fault code processing system of claim 1, wherein the security module is configured to:
determining a fault type in response to the occurrence of the fault;
determining the preset instruction based on the fault type;
and sending the preset instruction to the chassis module.
3. The fault code processing system of claim 1, wherein the security module is configured to:
determining whether a fault and/or a fault type occurs or not through a fault prediction model based on at least the key data, wherein the fault prediction model is a machine learning model.
4. The fault code processing system of claim 1, wherein the security module is configured to:
constructing a data vector based on the key data;
and determining whether faults and/or fault types occur or not based on the search results of the data vectors in a database, wherein the database comprises a plurality of historical data vectors constructed based on a plurality of historical key data and/or fault types respectively corresponding to the historical data vectors.
5. The fault code processing system of claim 1, wherein:
the functional module is configured to upload the first fault code and/or the key data to the fault code processing module and/or the security module based on a preset period;
the security module is configured to upload the second fault code to the fault code processing module based on the preset period.
6. The fault code processing system of claim 1, wherein:
the fault code processing module is configured to perform tracing processing on the received first fault code and/or the second fault code based on a tracing model to obtain the tracing result, wherein the tracing model is a machine learning model.
7. The fault code processing system of claim 6, wherein:
the tracing result at least comprises a sequence relation and/or a logic relation related to the first fault code and/or the second fault code.
8. A fault code processing method applied to an unmanned vehicle, comprising:
the following operations are performed by the functional modules of the domain controller:
executing a functional program;
generating a first fault code and/or key data based on the execution result; and
uploading the first fault code and/or the key data to a fault code processing module of the domain controller and/or a security module of a security processor;
the following operations are performed by the security module of the security processor:
determining whether a fault occurs based on the first fault code and/or the key data received from the functional module;
responding to the occurrence of faults, and sending a preset instruction to the chassis module; and
uploading a second fault code to the fault code processing module of the domain controller;
the following operations are performed by the fault code processing module of the domain controller:
performing source tracing processing on the first fault code received from the functional module and/or the second fault code received from the safety module; and
uploading the first fault code and/or the second fault code and/or the tracing result to a cloud server.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311149256.4A CN116893662B (en) | 2023-09-07 | 2023-09-07 | Fault code processing system and method applied to unmanned vehicle |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311149256.4A CN116893662B (en) | 2023-09-07 | 2023-09-07 | Fault code processing system and method applied to unmanned vehicle |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116893662A CN116893662A (en) | 2023-10-17 |
| CN116893662B true CN116893662B (en) | 2023-12-05 |
Family
ID=88312418
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311149256.4A Active CN116893662B (en) | 2023-09-07 | 2023-09-07 | Fault code processing system and method applied to unmanned vehicle |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116893662B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018086256A1 (en) * | 2016-11-14 | 2018-05-17 | 深圳市元征科技股份有限公司 | Automobile fault diagnostic method and device |
| CN111984676A (en) * | 2020-07-16 | 2020-11-24 | 深圳市易优成科技有限公司 | Method and device for determining damage of internal parts of vehicle |
| CN114035549A (en) * | 2021-11-15 | 2022-02-11 | 合众新能源汽车有限公司 | Device and method for detecting automobile fault |
| CN114839949A (en) * | 2022-04-02 | 2022-08-02 | 北京长安汽车工程技术研究有限责任公司 | Vehicle fault online diagnosis method and system |
| CN115230723A (en) * | 2022-03-07 | 2022-10-25 | 长城汽车股份有限公司 | Vehicle early warning method and device, electronic equipment and storage medium |
| WO2023103984A1 (en) * | 2021-12-09 | 2023-06-15 | 北京罗克维尔斯科技有限公司 | Vehicle fault diagnosis method and apparatus, electronic device, and storage medium |
| CN116483057A (en) * | 2023-05-04 | 2023-07-25 | 上汽通用五菱汽车股份有限公司 | Fault degradation testing system and testing method |
-
2023
- 2023-09-07 CN CN202311149256.4A patent/CN116893662B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018086256A1 (en) * | 2016-11-14 | 2018-05-17 | 深圳市元征科技股份有限公司 | Automobile fault diagnostic method and device |
| CN111984676A (en) * | 2020-07-16 | 2020-11-24 | 深圳市易优成科技有限公司 | Method and device for determining damage of internal parts of vehicle |
| CN114035549A (en) * | 2021-11-15 | 2022-02-11 | 合众新能源汽车有限公司 | Device and method for detecting automobile fault |
| WO2023103984A1 (en) * | 2021-12-09 | 2023-06-15 | 北京罗克维尔斯科技有限公司 | Vehicle fault diagnosis method and apparatus, electronic device, and storage medium |
| CN115230723A (en) * | 2022-03-07 | 2022-10-25 | 长城汽车股份有限公司 | Vehicle early warning method and device, electronic equipment and storage medium |
| CN114839949A (en) * | 2022-04-02 | 2022-08-02 | 北京长安汽车工程技术研究有限责任公司 | Vehicle fault online diagnosis method and system |
| CN116483057A (en) * | 2023-05-04 | 2023-07-25 | 上汽通用五菱汽车股份有限公司 | Fault degradation testing system and testing method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116893662A (en) | 2023-10-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102263337B1 (en) | Cloud-based vehicle breakdown diagnosis method, device and system | |
| US11181894B2 (en) | Computer system and method of defining a set of anomaly thresholds for an anomaly detection model | |
| CN110889707B (en) | Computer implemented method, system and computer program product for tracking product components | |
| US9836894B2 (en) | Distributed vehicle health management systems | |
| US6950782B2 (en) | Model-based intelligent diagnostic agent | |
| US20190026963A1 (en) | Fusion of aviation-related data for comprehensive aircraft system health monitoring | |
| CN112924205B (en) | Work machine fault diagnosis method and device, work machine and electronic equipment | |
| KR102444442B1 (en) | System and method for diagnosing facility fault | |
| CN104102773A (en) | Equipment fault warning and state monitoring method | |
| Jhou et al. | The implementation of OBD-II vehicle diagnosis system integrated with cloud computation technology | |
| EP3865963A1 (en) | Method and device for analyzing vehicle failure | |
| CN113902233A (en) | Vehicle safety early warning method, big data platform device, vehicle-mounted terminal and vehicle | |
| CN115437339A (en) | Remote diagnosis method and device, electronic equipment and storage medium | |
| CN112668012A (en) | Method and system for verifying safety of automatic driving human-computer interface | |
| CN112256538A (en) | Unmanned ship equipment information acquisition processing and control method | |
| CN116893662B (en) | Fault code processing system and method applied to unmanned vehicle | |
| CN115577151A (en) | Vehicle fault real-time diagnosis method and device, electronic equipment and storage medium | |
| Chen et al. | An intelligent vehicular telematics platform for vehicle driving safety supporting system | |
| CN114637268A (en) | Industrial production control method and system based on artificial intelligence and cloud platform | |
| EP4191489A1 (en) | Maintenance control system and method | |
| CN115338867A (en) | Fault state monitoring method, device and equipment for mobile robot | |
| Jhou et al. | The implementation of obd-ii vehicle diagnosis system integrated with cloud computation technology | |
| CN116048055A (en) | Vehicle fault detection method, device and storage medium | |
| KR20220036791A (en) | System and method for verifying field data collected in ship | |
| CN114072863A (en) | Accident risk diagnosis method, accident risk diagnosis device, and accident risk diagnosis system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |