Method and device for diagnosing a vehicle fault

Abstract

The present disclosure relates to a vehicle electronics technology, in particular to a method, an apparatus, and a non-transitory computer-readable storage medium storing computer programs / instructions for implementing the method for diagnosing a vehicle fault, and a computer program product. The method comprises the following steps: in response to a trigger event monitored by a buried point, determining a first fault matched with the trigger event by using a first fault diagnosis model; when the matched first fault does not exist, a second fault diagnosis model is used for determining a second fault associated with a trigger event, the trigger event is a first abnormal event or a second abnormal event, the first fault diagnosis model defines the corresponding relation between the first fault and the first abnormal event, and the second fault diagnosis model defines the corresponding relation between the first fault and the second abnormal event. The second fault diagnosis model defines a correspondence between i) a second fault and ii) a fault feature or a logical combination of a plurality of fault features associated with a second anomalous event, the fault features being determined based on the vehicle operating state information.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to vehicle electronics, and in particular to a method for diagnosing vehicle faults, an apparatus, a non-transitory computer-readable storage medium storing computer programs / instructions for implementing the method, and a computer program product. BACKGROUND

[0002] With the rapid popularization of electric vehicles, consumers' demand for energy replenishment efficiency is increasing. Although the cruising range of electric vehicles has been greatly improved, problems such as uneven distribution of charging facilities and long charging time still exist, so the range anxiety problem has not been fundamentally solved. In this context, the battery swap mode has attracted widespread attention in the market for its efficient and convenient energy replenishment method.

[0003] Battery swap fault detection technology plays a core role in the battery swap system of electric vehicles, which helps to ensure the safety and reliability of the battery swap process, improve the efficiency of battery swap, user experience and reduce operation and maintenance costs. SUMMARY

[0004] One embodiment of the present disclosure relates to a method for diagnosing battery swap faults, comprising:

[0005] In response to a trigger event monitored by a buried point deployed in a car machine software system, determining a first fault matched with the trigger event by using a first fault diagnosis model;

[0006] When there is no first fault matched with the trigger event, determining a second fault associated with the trigger event by using a second fault diagnosis model,

[0007] Wherein, the trigger event is a first abnormal event or a second abnormal event occurring in the vehicle battery swap process,

[0008] Wherein, the first fault diagnosis model defines a corresponding relationship between the first fault and the first abnormal event,

[0009] Wherein, the second fault diagnosis model defines a corresponding relationship between: i) the second fault; ii) a logical combination of one fault feature or multiple fault features associated with the second abnormal event, the fault feature being determined based on vehicle operating state information.

[0010] Optionally, in the above method, the corresponding relationship is represented as a relationship list, and the step of determining the first fault comprises:

[0011] Searching for a first fault corresponding to the trigger event in the relationship list.

[0012] Optionally, in the above method, the step of determining the second fault comprises:

[0013] determining one or more meta-events having relevance to the trigger event from the vehicle operating state information;

[0014] determining the feature failure from a single meta-event, or determining the feature failure from a logical combination of multiple meta-events or a time sequence relationship between multiple meta-events;

[0015] determining the second failure from the feature failure using the second failure diagnosis model.

[0016] Optionally, in the above method, the vehicle operating state information comprises at least one of the following: real-time operating parameters of the vehicle, diagnostic event records, and log files of electronic control units.

[0017] Optionally, in the above method, the meta-event comprises at least one of the following: a real-time operating parameter taking a set value, a fault code of a set type appearing in the diagnostic event records, and a set type of event records in the log files.

[0018] Optionally, in the above method, the real-time operating parameter is a sensor detection value or a state value of an executing component transmitted in real time by a vehicle-mounted network bus.

[0019] Optionally, in the above method, the set type of the fault code comprises a first diagnostic fault code generated in a software interaction process of multiple electronic control units and a second diagnostic fault code determined based on a combination of multiple real-time operating parameters.

[0020] Optionally, in the above method, the relevance comprises at least one of the following: a temporal relevance and a relevance in vehicle operation.

[0021] Optionally, in the above method, the time sequence relationship comprises an occurrence sequence of multiple meta-events or a time interval between multiple meta-events.

[0022] Optionally, in the above method, further comprising:

[0023] outputting a diagnosis result, the diagnosis result comprising a component identifier of the first failure or the second failure, a failure category, and a failure occurrence time.

[0024] Embodiments of the present disclosure also relate to an apparatus for diagnosing a battery swap failure, comprising:

[0025] a computing unit;

[0026] a memory having a computer program / instruction stored thereon, the computer program / instruction being executed on the processor to perform the following operations:

[0027] determining, in response to a trigger event monitored by a buried point deployed in an infotainment software system, a first fault matching the trigger event by using a first fault diagnosis model;

[0028] when there is no first fault matching the trigger event, determining a second fault associated with the trigger event by using a second fault diagnosis model,

[0029] wherein the trigger event is a first abnormal event or a second abnormal event occurring in a battery swapping process of a vehicle,

[0030] wherein the first fault diagnosis model defines a correspondence between the first fault and the first abnormal event,

[0031] wherein the second fault diagnosis model defines a correspondence between i) the second fault and ii) a logical combination of one fault feature or a plurality of fault features associated with the second abnormal event, the fault feature being determined based on vehicle running state information.

[0032] Optionally, in the above apparatus, the correspondence is represented as a relationship list, and the computer program / instructions are run on the processor to perform the operation of determining the first fault in the following manner:

[0033] searching the relationship list for a first fault corresponding to the trigger event

[0034] Optionally, in the above apparatus, the computer program / instructions are run on the processor to perform the operation of determining the second fault in the following manner:

[0035] determining one or more meta events having relevance to the trigger event from the vehicle running state information;

[0036] determining the fault feature from a single meta event or a logical combination of a plurality of meta events or a timing relationship between a plurality of meta events;

[0037] determining the second fault from the fault feature by using the second fault diagnosis model.

[0038] Optionally, in the above apparatus, the vehicle running state information comprises at least one of the following: real-time running parameters of the vehicle, diagnostic event records, and log files of electronic control units.

[0039] Optionally, in the above apparatus, the meta event comprises at least one of the following: a real-time running parameter taking a set value, a fault code of a set type appearing in the diagnostic event records, and a set type of event records in the log files.

[0040] Optionally, in the above-mentioned device, the real-time operating parameters are sensor detection values ​​or status values ​​of actuators transmitted in real time by the vehicle network bus.

[0041] Optionally, in the above-described device, the fault code setting type includes a first diagnostic fault code determined based on a combination of multiple real-time operating parameters and a second diagnostic fault code defined during the software interaction process of multiple electronic control units.

[0042] Optionally, in the above-described apparatus, the correlation includes at least one of the following: correlation in time and correlation in vehicle operation.

[0043] Optionally, in the above-described apparatus, the timing relationship includes the order in which multiple meta-events occur or the time interval between multiple meta-events.

[0044] Optionally, in the above-described apparatus, the computer program / instructions run on the processor to further perform the following operations:

[0045] Output diagnostic results, which include the component identification, fault category, and fault occurrence time of the first or second fault.

[0046] Embodiments of this disclosure also relate to a non-transitory computer-readable storage medium storing a computer program / instructions suitable for execution on a processor of a terminal device, the execution of which causes the steps of the method described above to be performed.

[0047] Embodiments of this disclosure also relate to a computer program product comprising a computer program / instructions suitable for execution on a processor of a terminal device, the execution of which causes the steps of the method described above to be performed.

[0048] In some specific implementations, meta-events are used to define fault characteristics, and these fault characteristics are further used to define the type of a second fault. This hierarchical and progressive fault description approach achieves high flexibility, scalability, and maintainability in fault diagnosis by atomizing meta-events, patterning fault characteristics, and abstracting fault types, while reducing complexity and improving the efficiency and accuracy of fault diagnosis. In other specific implementations, fault characteristics are determined based on the order of occurrence of multiple meta-events or the time interval between multiple meta-events. Since the order of occurrence reflects the causal relationship between meta-events and the time interval can serve as a measure of the correlation between meta-events, the accuracy of fault diagnosis can be improved. Attached Figure Description

[0049] The above and / or other aspects and advantages of this disclosure will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, in which like or similar elements are denoted by the same reference numerals. The drawings include:

[0050] Figure 1 This is a schematic diagram of an exemplary battery swapping management architecture.

[0051] Figure 2 This is a schematic block diagram of a computing device.

[0052] Figure 3 This is a flowchart of a method for diagnosing battery swapping faults according to an embodiment of the present disclosure.

[0053] Figure 4 This is a flowchart of a method for diagnosing battery swapping faults according to another embodiment of the present disclosure. Detailed Implementation

[0054] The present disclosure will now be described more fully with reference to the accompanying drawings, which illustrate exemplary embodiments thereof. However, the present disclosure may be implemented in various forms and should not be construed as being limited to the embodiments set forth herein. The foregoing embodiments are intended to make the disclosure herein complete and thorough, so as to more fully convey the scope of protection of the present disclosure to those skilled in the art.

[0055] In this specification, terms such as “comprising” and “including” indicate that, in addition to the units and steps that are directly and explicitly stated in the specification and claims, the technical solutions of this disclosure do not exclude the presence of other units and steps that are not directly or explicitly stated.

[0056] In this specification, "vehicle infotainment software system" refers to various software systems running on the vehicle, which may employ a layered architecture consisting of an operating system, middleware, and an application layer. The vehicle infotainment software system can connect to the vehicle's electronic control unit (ECU), sensors, and actuators via a bus (e.g., CAN / LIN / Ethernet) to achieve functions such as human-machine interaction, vehicle control, diagnostics and logging, and battery management.

[0057] Data points or event trackers can be set at key code locations or business process nodes in the vehicle infotainment system to track events occurring during software operation or collect various information during software operation (such as the time, type, and characteristics of events). For example, when the software reaches a data point and meets specific triggering conditions (such as an abnormal execution status of a step in the battery swapping process or a parameter value exceeding the normal range), the data point is triggered to perform corresponding data acquisition and event information reporting operations.

[0058] In some cases, the type of battery swap failure can be directly located or determined based on the information of the trigger event reported based on the buried point. The trigger event and the battery swap failure are referred to as the first abnormal event and the first failure, respectively, in the following. The first battery swap failure matched with the trigger event can be determined by establishing a failure diagnosis model (hereinafter also referred to as the first failure diagnosis model) defining the corresponding relationship between the first failure and the first abnormal event.

[0059] Some examples of the first abnormal event and the first failure are given below. For example, when an event of detecting a battery voltage of 0 occurs continuously for 500 ms, it can be basically determined that a hardware failure of the internal voltage sensor of the battery ECU occurs, and therefore the above event can be classified as the first abnormal event, and the above failure can be classified as the first failure. Accordingly, the buried point can be set at a suitable position of the car machine software system, and "BMS_Voltage_Sensor@BMS_ECU == 0V" can be used as the trigger condition. In addition, in the first failure diagnosis model, a corresponding relationship can be established between the failure "internal voltage sensor short circuit of the battery ECU" and the trigger condition "BMS_Voltage_Sensor@BMS_ECU == 0V".

[0060] However, due to the complexity of the battery swapping process (which involves the coordinated operation of multiple ECUs within the vehicle and the coordinated operation of the vehicle and the battery swapping station equipment), in some cases, the information provided by the trigger events reported by the embedded points is insufficient to determine the type of battery swapping fault. These trigger events and battery swapping faults are referred to as second abnormal events and second faults, respectively. Vehicle operating status information, such as real-time vehicle operating parameters (e.g., the voltage and temperature of the power battery, and the current and torque of the motor), diagnostic event records (which record, for example, the occurrence of faults identified by DTC codes), and ECU log files, provides a rich source of data for determining the second fault. In some embodiments of this application, the type of second fault associated with the trigger event is determined using the following second fault diagnosis model. Specifically, this second fault diagnosis model defines the correspondence between various types of second faults and single fault features or logical combinations of multiple fault features (e.g., defined by logical relationships such as "AND," "OR," and "NOR"). The fault features described herein can be determined based on vehicle operating status information and associated with the second abnormal event. Taking "poor battery performance leading to battery drain during battery swapping" as an example, this battery drain fault cannot be directly located through the trigger event information reported by the data acquisition point, and therefore can be classified as a second fault. Furthermore, when the performance of the small battery deteriorates, causing the battery swapping preparation stage to fail or the battery swapping self-test stage to fail, the aforementioned battery drain fault can be confirmed. Therefore, "poor battery performance leading to battery swapping preparation stage failure" and "poor battery performance leading to battery swapping self-test stage failure" can be used as corresponding fault features, and the combination of the logical relationship between the above two fault features ("OR") can be used as the judgment condition for the fault "poor battery performance leading to battery drain during battery swapping". The correspondence between the second fault and the fault features can be obtained by using various machine learning algorithms to perform statistical analysis on a large number of fault samples.

[0061] In some embodiments, a fault feature can be determined or defined by a single meta-event. In other embodiments, a fault feature can be determined or defined by a logical combination of multiple meta-events (e.g., defined by logical relationships such as “and”, “or”, “nor”, etc.) or a timing relationship therebetween, that is, a fault feature can be determined by one of a logical combination of multiple meta-events and a timing relationship therebetween, or by both. The meta-event described herein can be considered as a “bottom layer” factor that causes the occurrence of a fault feature, which has a correlation with the second abnormal event and can be determined from the vehicle operating state information. It should be noted that this correlation can be embodied as a temporal correlation (e.g., the interval between the occurrence of the meta-event and the triggering event is within a set time range), a vehicle operation correlation (e.g., the meta-event and the triggering event both involve battery pre-locking operation), or both. In addition, this correlation of the meta-event also causes the fault feature to be associated with the second abnormal event. In some embodiments, the determination condition of the fault feature or the corresponding relationship between the fault feature and the meta-event can be obtained by statistical analysis of a large number of fault samples using various machine learning algorithms.

[0062] It should be noted that the hierarchical and progressive description method of the above meta-event → fault feature → fault type has many technical advantages. For example, the meta-event, as the most basic atomic-level event (such as the jump of a certain CAN signal, the triggering of a sensor, etc.), has a stable definition. When a new fault type needs to be added or modified, only the upper layer fault feature combination needs to be adjusted without changing the definition of the bottom layer meta-event, reducing the complexity of system maintenance. For another example, the same meta-event can be referenced by multiple fault features, avoiding repeated definition and improving code or configuration reuse rate. For another example, different fault features can be combined to generate a new fault type, so that the diagnostic needs of complex scenarios can be met. For another example, when a new sensor, signal or fault scenario is added, only the corresponding meta-event, fault feature or fault type needs to be added at the corresponding level, so that the overall architecture stability can be maintained while quickly responding to new requirements. In summary, the hierarchical and progressive fault description method described above realizes high flexibility, scalability and maintainability of fault diagnosis by atomizing meta-events, patterning fault features and abstracting fault types, while reducing complexity and improving efficiency and accuracy of fault diagnosis. The above technical advantages are particularly prominent for complex scenarios such as battery swap fault diagnosis.

[0063] The following gives specific examples of meta-events. For example, the CAN bus signal state "770@PwrSwapProc==5" indicates that the parameter PwrSwapProc contained in the message with ID 770 takes the value 5, which usually prompts an abnormality of the pre-lock link (such as unsuccessful positioning of a mechanical arm, battery connection failure, etc.), and the CAN bus signal state "1033@VCU_Err57_LVSplyLowFlt==1" indicates that the parameter VCU_Err57_LVSplyLowFlt contained in the message with ID 1033 takes the value 1, which prompts that the voltage of the low-voltage power supply system of the vehicle is too low. Exemplarily, the events in which the above two signal states occur are referred to as meta-event a and meta-event b, respectively. The fault analysis result shows that if meta-event b occurs within a set period (for example, 10 minutes) after the occurrence of meta-event a, the aforementioned fault feature "poor performance of small battery leading to failure of the battery replacement preparation phase" will occur. Thus, the above timing relationship between meta-events a and b can be taken as a discrimination condition of the fault feature "poor performance of small battery leading to failure of the battery replacement preparation phase".

[0064] For another example, taking the fault "self-check failure during battery replacement process" as an example, it cannot be directly located through the event information reported by the burying point, and thus can be classified as a second fault. In addition, when this fault occurs, it usually manifests as self-check failure caused by VCU reply 0x4 negative response or self-check failure caused by VCU reply 0xF0 negative response. Thus, "self-check failure caused by VCU reply 0x4 negative response" and "self-check failure caused by VCU reply 0xF0 negative response" can be taken as corresponding fault features, and the combination of the above two fault features defined by the "or" logical relationship can be taken as a discrimination condition of the fault "self-check failure during battery replacement process". Further, the fault features "self-check failure caused by VCU reply 0x4 negative response" and "self-check failure caused by VCU reply 0xF0 negative response" can be determined according to the ECU log file. Exemplarily, assuming that the trigger event is reported by the burying point of a software system running on a vehicle control ECU, when the software execution error information "Error_data: [0x4], error_source: [0x3], returnh: [0x300000004]" occurring near the trigger event is read from the log file of the vehicle control ECU, the existence of meta-event c can be determined, and further the existence of the fault feature "self-check failure caused by VCU reply 0x4 negative response" can be determined; for another example, when the software execution error information "VCU Prepare routine FAIL with code = 0xF0" occurring near the trigger event is read from the log file of the vehicle control ECU, the existence of meta-event d can be determined, and further the existence of the fault feature "self-check failure caused by VCU reply 0xF0 negative response" can be determined.

[0065] For example, the "radar fault occurs in the battery swap parking process" classified as the second fault corresponds to the combination of the following fault features defined by the "or" relationship: "radar system fault occurs in the battery swap parking process (the failed radar subsystem cannot locate)", "front radar system fault occurs in the battery swap parking process", and "rear radar system fault occurs in the battery swap parking process". For example, the presence of the above fault features can be determined according to the diagnostic fault codes, which can be included in the diagnostic event records generated by the vehicle end or remote fault diagnosis device. For example, the diagnostic fault codes "WTI-PI-16", "WTI-PI-17", and "WTI-PI-18" respectively indicate that the radar system fails (the failed radar subsystem cannot locate), the front radar system fails, and the rear radar system fails. Therefore, when the diagnostic fault code "WTI-PI-16" is determined to occur near the trigger event by the diagnostic event record, the existence of the meta-event e is determined, and the existence of the fault feature "radar system fault occurs in the battery swap parking process (the failed radar subsystem cannot locate)" is further determined; similarly, when the diagnostic fault code "WTI-PI-17" or "WTI-PI-18" occurs near the trigger event, the existence of the corresponding meta-event f or g is determined, and the existence of "front radar system fault occurs in the battery swap parking process" and "rear radar system fault occurs in the battery swap parking process" is further determined.

[0066] In some embodiments, the above diagnostic fault codes can be diagnostic fault codes generated in the software interaction process of multiple ECU electronic control units (hereinafter referred to as first diagnostic fault codes), such as DTC codes that can be retrieved from the on-board diagnostic system. In other embodiments, the diagnostic fault codes are determined based on the combination of multiple real-time operating parameters of the vehicle (such as sensor detection values or execution component state values transmitted in real time by the vehicle network bus) (hereinafter referred to as second diagnostic fault codes).

[0067] It should be noted that the above description of the time interval between the meta-events as an example of the timing relationship is not limiting. In other embodiments, the timing relationship can also include the occurrence order of the meta-events, for example, the meta-event a occurs before the meta-event. The occurrence order can reflect the causal relationship between the meta-events, and the time interval can be a certain measure of the correlation between the meta-events, so introducing these timing relationships when determining fault features can help improve the accuracy of fault diagnosis.

[0068] Figure 1 An exemplary schematic diagram of the battery swap management architecture. In Figure 1In the illustrated battery swap management architecture, the vehicle 110 can transmit information of the trigger event detected by the buried point (e.g. a description of the trigger condition, an identification code of the type of the trigger event, etc.) and vehicle running status information to the database 130 (which can be a remote server, for example) via the network 120 (e.g. the Internet or a wireless local area network, etc.). As mentioned above, the vehicle running status information includes, for example but not limited to, real-time running parameters of the vehicle (e.g. voltage, temperature of the battery, current, torque of the motor, etc.), diagnostic event records (which contain the aforementioned first diagnostic fault code and second diagnostic fault code, for example) and log files of the ECU. In some embodiments, the vehicle running status information is transmitted by the vehicle 110 to the database 130 in real time during the battery swap operation. In other embodiments, the vehicle 110 sends the vehicle running status information to the database 130 in response to the detection of the trigger event by the buried point.

[0069] As shown in FIG. 1, the vehicle 110 is equipped with a battery swap management system 112. The battery swap management system 112 includes a buried point 114 and an ECU 116. The buried point 114 is configured to monitor the trigger event of the battery swap operation and to transmit information of the trigger event to the database 130 via the network 120. The ECU 116 is configured to collect vehicle running status information and to transmit the vehicle running status information to the database 130 via the network 120. Figure 1 As shown in FIG. 1, the vehicle 110 is equipped with a battery swap management system 112. The battery swap management system 112 includes a buried point 114 and an ECU 116. The buried point 114 is configured to monitor the trigger event of the battery swap operation and to transmit information of the trigger event to the database 130 via the network 120. The ECU 116 is configured to collect vehicle running status information and to transmit the vehicle running status information to the database 130 via the network 120.

[0070] Further, the device for diagnosing battery swap faults 140 will determine the type of battery swap fault based on the information of the trigger event and the vehicle running status information, and will report the diagnosis result to the battery swap management platform 150. The battery swap management platform 150 will then execute a corresponding fault handling process according to the diagnosis result, such as a remote handling process or an on-site intervention handling process, etc.

[0071] The manner of determining the type of battery swap fault has been described in detail above, and will be further described below with the aid of Figure 3 and 4 In this example, the device for diagnosing battery swap faults 140 can utilize some or all of the features described above to determine the type of battery swap fault.

[0072] It should be noted that, Figure 1 The battery swap management architecture illustrated in FIG. 1 is merely exemplary and various modifications can be made thereon. For example, although in the example of FIG. 1 the vehicle 110 is equipped with the battery swap management system 112, in other embodiments the vehicle 110 can not be equipped with the battery swap management system 112. In such embodiments, the vehicle 110 can transmit the information of the trigger event and the vehicle running status information to the database 130 via the network 120 in response to the detection of the trigger event by the buried point 114. Figure 1In the illustrated architecture, the battery swap failure diagnosis function and the battery swap management function are implemented by two independent general-purpose or special-purpose computing devices or computer systems, but the two functions can also be integrated in a single computing device. For example, in another battery swap management architecture, the data storage function, the battery swap failure diagnosis function, and the battery swap management function can be integrated in the same computing device.

[0073] Figure 2 is a schematic block diagram of a computing device. Figure 2 The illustrated computing device can be used to implement the device 140 for diagnosing battery swap failure in Figure 1 The computing device described herein encompasses various forms of computing devices with computing functionality, including but not limited to, a laptop computer, a desktop computer, a workstation, a personal digital assistant, a server, a blade server, a mainframe computer, a mobile phone, a tablet computer, a wearable device, and the like.

[0074] As illustrated in Figure 2 , the computing device 200 includes a computing unit 201 that can perform various appropriate actions and processes according to computer programs / instructions stored in a read-only memory (ROM) 202 or loaded from a storage unit 208 into a random access memory (RAM) 203. In the RAM 203, data associated with the software running of the computing device 200 (e.g., fault diagnosis results, information of triggering events, and vehicle operating state information, etc.) can also be stored. The computing unit 201, the ROM 202, and the RAM 203 are connected to each other through a bus 204. An input / output (I / O) interface 205 is also connected to the bus 204.

[0075] A plurality of components in the computing device 200 are connected to the I / O interface 205, including an input unit 206 (e.g., a keyboard, a mouse, etc.), an output unit 207 (e.g., various types of displays, a speaker, etc.), a storage unit 208 (e.g., a magnetic disk, an optical disk, etc.), and a communication unit 209 (e.g., a network card, a modem, a wireless communication transceiver, etc.). The communication unit 209 is configured as a communication interface to establish a communication connection between the computing device 20 and external devices (e.g., the database 130 and the battery swap management platform 150 in Figure 1 to exchange information / data via a computer network (e.g., the network 120 in Figure 1 ).

[0076] The computing unit 201 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 201 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. In some embodiments, the computer software program / instructions are tangibly contained within a machine-readable medium, such as storage unit 208. In other embodiments, part or all of the computer program / instructions may be loaded and / or installed on the computing device 200 via ROM 202 and / or communication unit 209. When the computer program / instructions are loaded into RAM 203 and executed by the computing unit 201, the functions described above and to be described below can be implemented. Figure 3 and 4 The battery swapping fault diagnosis method is described in further detail. Alternatively, in other embodiments, the computing unit 201 may be configured to perform the battery swapping fault diagnosis method by any other suitable means (e.g., by means of firmware).

[0077] Figure 3 This is a flowchart of a method for diagnosing battery swapping faults according to an embodiment of this disclosure. For illustrative purposes, the following description uses… Figure 1 The battery swapping management architecture shown is used as the context.

[0078] Figure 3 The method shown begins at step 301. In this step, the device 140 for diagnosing battery swapping faults determines whether a trigger event has been detected by a data point deployed within the vehicle's infotainment software system. If a trigger event is detected, the process proceeds to step 302; otherwise, it continues to wait. Optionally, in step 301, the device 140 for diagnosing battery swapping faults can perform the above determination operation by periodically accessing the database 130. Alternatively, when the database 130 receives a report about a trigger event from the vehicle 110, it sends information about the trigger event (e.g., a textual description of the trigger conditions and an identification code for the trigger event type) to the device 140 for diagnosing battery swapping faults.

[0079] See also Figure 3 In step 302, the device 140 for diagnosing battery swapping faults uses a first fault diagnosis model to determine a first fault that matches the triggering event. The first fault diagnosis model can define the correspondence between various types of first faults and corresponding first abnormal events. In some specific implementations, this correspondence is represented as a relation list, whereby a first fault matching the triggering event can be searched.

[0080] Then, the process enters step 303, in which the device 140 for diagnosing battery swap failure determines whether a first failure matching the trigger event is searched, and if yes, the process goes to step 304, otherwise, the process goes to step 305.

[0081] In step 304, the device 140 for diagnosing battery swap failure outputs the diagnosis result to the battery swap management platform 150. Optionally, the diagnosis result includes the component identification where the first failure occurs, the failure category (e.g. hardware failure / software error) and the time when the failure occurs, etc. Further optionally, the diagnosis result can also include one or more of the following: the label name, the label description, the label level, the information of the trigger event, the battery swap operation link when the failure occurs and the failure recovery mode, etc.

[0082] In another branch step 305 of step 303, the device 140 for diagnosing battery swap failure determines a second failure associated with the trigger event by using a second failure diagnosis model. As described above, the second failure diagnosis model defines the correspondence between various types of second failures and the logical combination of single failure feature or multiple failure features. Optionally, each failure feature can be determined by a single elementary event, or can be determined by the logical combination of multiple elementary events or the time sequence relationship therebetween. The determination of the second failure will be further described below in connection with Figure 4 .

[0083] After completing step 305, Figure 3 the process enters step 306. In step 306, the device 140 for diagnosing battery swap failure determines whether there is a second failure associated with the trigger event, and if yes, the process goes to step 307, otherwise, the process goes to step 308.

[0084] In step 307, the device 140 for diagnosing battery swap failure outputs the diagnosis result to the battery swap management platform 150. Optionally, the diagnosis result includes the component identification where the second failure occurs, the failure category (e.g. hardware failure / software error) and the time when the failure occurs, etc. Further optionally, the diagnosis result can also include one or more of the following: the label name, the label description, the label level, the information of the trigger event, the battery swap operation link when the failure occurs and the failure recovery mode, etc.

[0085] In step 308, the device 140 for diagnosing battery swap failure outputs a report to the battery swap management platform 150 about the failure associated with the trigger event cannot be determined.

[0086] Figure 4 For the flowchart of the method for diagnosing battery swap failure according to another embodiment of the present disclosure, the shown process can be used to implement Figure 3 step 305 in.

[0087] Figure 4 The flowchart shown begins at step 401, which can be followed, for example, by step 303 in Figure 3 . In step 401, the device 140 for diagnosing battery swap failure determines one or more meta-events having relevance to the triggering event from the vehicle operating state information. For example, the presence of meta-event b can be determined when the CAN bus signal state representing the real-time operating parameter of the vehicle (e.g., the voltage of the low-voltage power supply system) is “1033@VCU_Err57_LVSplyLowFlt==1”. For another example, the presence of meta-event c can be determined when the ECU log file records the software execution error information “Error_data: [0x4], error_source: [0x3], returnh: [0x300000004]”. For yet another example, the presence of meta-event e can be determined when the diagnostic fault code “WTI-PI-16” appears in the diagnostic event record. The various features of the meta-events have been described in detail above and will not be repeated here.

[0088] After step 401 is completed, Figure 4 the flowchart shown proceeds to step 402. In step 402, the device 140 for diagnosing battery swap failure determines the failure feature from a single meta-event, or determines the characteristic failure from a logical combination of multiple meta-events or the timing relationship between multiple meta-events. The judgment conditions for the failure feature and the correspondence between the meta-events and the failure feature have been described in detail above and will not be repeated here.

[0089] Subsequently, step 403 is entered, in which the device 140 for diagnosing battery swap failure determines a second failure that matches the failure feature obtained in step 402 using a second failure diagnosis model. After step 403 is completed, Figure 4 the flowchart shown proceeds, for example, to step 306 in Figure 3 .

[0090] Those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described herein can be implemented as electronic hardware, computer software, or combinations of the two.

[0091] To show the interrelation of the elements illustrated in the various figures, the blocks are arranged in a sequence representative of their interrelation. However, it should be understood that this arrangement is merely intended to assist in understanding the disclosure and that the interrelation of the blocks can be in other arrangements without departing from the scope of the disclosure.

[0092] While only certain embodiments of this disclosure have been described, any person skilled in the art will appreciate that many other forms and modifications can be made without departing from the spirit and scope of this disclosure. Accordingly, the examples and embodiments set forth are considered illustrative and not restrictive, and the disclosure can encompass various modifications and alternative forms without departing from the spirit or scope of the disclosure as defined by the appended claims.

[0093] The embodiments and examples set forth herein are presented to best explain and provide overall structure of the application in such full, complete and exemplary post as to enable those in the art to provide and use the disclosure in association with the particular application. However, those skilled in the art will appreciate that the foregoing description and examples are provided for illustrative purposes only. The description is not intended to cover all aspects of the disclosure or limit the disclosure to the precise forms disclosed.

Claims

1. A method for diagnosing battery swapping faults, comprising: In response to a triggering event detected by embedded points deployed in the vehicle infotainment software system, a first fault matching the triggering event is determined using a first fault diagnosis model; If no first fault matches the triggering event, a second fault associated with the triggering event is determined using a second fault diagnosis model. The triggering event is either a first abnormal event or a second abnormal event that occurs during the vehicle battery swapping process. The first fault diagnosis model defines the correspondence between the first fault and the first abnormal event. The second fault diagnosis model defines the following correspondence between the two: i) the second fault; ii) a fault feature or a logical combination of multiple fault features associated with the second abnormal event, wherein the fault feature is determined based on vehicle operating status information.

2. The method of claim 1, wherein, The correspondence is represented as a relation list, and the steps for determining the first fault include: Search the relationship list for the first fault corresponding to the triggering event.

3. The method of claim 1, wherein, The steps to determine the second fault include: One or more meta-events associated with the triggering event are determined from the vehicle operating status information; The fault characteristic can be determined by a single meta-event, or by a logical combination of multiple meta-events or a temporal relationship between multiple meta-events. The second fault is determined by the fault characteristics using the second fault diagnosis model.

4. The method of claim 3, wherein, The vehicle operating status information includes at least one of the following: real-time operating parameters of the vehicle, diagnostic event records, and log files of the electronic control unit.

5. The method of claim 4, wherein, The meta-events include at least one of the following: the real-time operating parameter is set to a value, a fault code of a set type appears in the diagnostic event record, and an event of a set type is recorded in the log file.

6. The method of claim 4, wherein, The real-time operating parameters are the sensor detection values ​​or the status values ​​of the actuators transmitted in real time by the vehicle network bus.

7. The method of claim 5, wherein, The fault code setting type includes a first diagnostic fault code generated during the software interaction of multiple electronic control units and a second diagnostic fault code determined based on a combination of multiple real-time operating parameters.

8. A device for diagnosing battery swapping faults, comprising: Computational unit; A memory that stores computer programs / instructions that run on the processor to perform the following operations: In response to a triggering event detected by embedded points deployed in the vehicle infotainment software system, a first fault matching the triggering event is determined using a first fault diagnosis model; If no first fault matches the triggering event, a second fault associated with the triggering event is determined using a second fault diagnosis model. The triggering event is either a first abnormal event or a second abnormal event that occurs during the vehicle battery swapping process. The first fault diagnosis model defines the correspondence between the first fault and the first abnormal event. wherein the second fault diagnosis model defines a correspondence between i) the second fault and ii) a fault feature or a logical combination of a plurality of fault features associated with the second abnormal event, the fault feature being determined based on vehicle operating state information. 9.A non-transitory computer-readable storage medium storing computer programs / instructions therein, characterized in that, Steps of the method as claimed in any one of claims 1-7, when the computer program / instructions are executed by a processor.

10. A computer program product, the computer program product comprising computer programs / instructions, characterized in that, Steps of the method as claimed in any one of claims 1-7, when the computer program / instructions are executed by a processor.

Images