Charging fault diagnosis method, device and computer equipment

Abstract

The application relates to a charging fault diagnosis method, device and computer equipment. The method comprises the following steps: S1, receiving charging CAN information forwarded by a vehicle terminal when target vehicle charging is stopped; S2, when it is determined according to the charging CAN information that the reason for the target vehicle charging being stopped is that the BMS of the target vehicle actively stops, receiving CAN information of the BMS of the target vehicle and vehicle CAN information; S3, analyzing the CAN information of the BMS and the vehicle CAN information to obtain a target fault reason for the target vehicle charging being stopped; the target fault reason is at least one of the battery of the target vehicle causing the charging to be stopped, the vehicle fault causing the charging to be stopped and the vehicle instruction causing the charging to be stopped. The method can improve the efficiency and obtain an accurate fault reason.

Description

Technical Field

[0001] This application relates to the field of charging fault diagnosis technology, and in particular to a charging fault diagnosis method, apparatus and computer equipment. Background Technology

[0002] With the escalating global energy crisis and heightened environmental awareness, developing new energy vehicles has become a crucial strategic direction for countries worldwide. New energy vehicles include pure electric vehicles, plug-in hybrid electric vehicles, and fuel cell vehicles. The new energy vehicle market is experiencing explosive growth, with the number of vehicles on the road continuously increasing. A convenient, efficient, and safe charging experience is a core prerequisite for the large-scale promotion of new energy vehicles and a key aspect of user experience. The charging process involves multiple complex stages and stakeholders, including the vehicle's BMS, charger, charging interface, and communication protocols. When charging fails or an anomaly occurs, existing technologies often only provide simple error codes, making it difficult to accurately pinpoint the specific source and root cause of the fault. This leads to low efficiency for on-site service personnel, frequently requiring specialized technicians to collect multiple communication messages to locate and troubleshoot the specific cause of the fault. Summary of the Invention

[0003] Therefore, it is necessary to provide a charging fault diagnosis method, apparatus, and computer equipment that can improve efficiency and obtain accurate fault causes in order to address the above-mentioned technical problems.

[0004] A charging fault diagnosis method, applied to a fault diagnosis terminal, the method comprising:

[0005] S1. When the target vehicle stops charging, receive the charging CAN information forwarded by the vehicle terminal.

[0006] S2. When it is determined from the charging CAN information that the reason for the charging stop of the target vehicle is the active stop of the BMS of the target vehicle, the CAN information of the BMS of the target vehicle and the CAN information of the whole vehicle are received.

[0007] S3. Parse the CAN information of the BMS and the CAN information of the vehicle to obtain the target fault cause that causes the charging of the target vehicle to stop; the target fault cause is at least one of the following: the battery of the target vehicle causes the charging to stop, the vehicle fault causes the charging to stop, and the vehicle command causes the charging to stop.

[0008] Preferably, the charging interruption of the target vehicle refers to the situation where the charging process is abnormally terminated or interrupted due to some reason during the charging process of the target vehicle. The charging interruption of the target vehicle may occur at any time after the charging starts, until the charging is completed.

[0009] Preferably, the CAN information of the target vehicle's BMS includes the CAN information within the BMS slave controller and the BMS master controller of the vehicle; the CAN information of the target vehicle's BMS refers to the information on the CAN network directly connected to or related to the BMS.

[0010] Preferably, the vehicle CAN information is the vehicle CAN information controlled by the vehicle VCU (Vehicle Control Unit) and the vehicle BMS main controller;

[0011] Preferably, the vehicle command refers to various commands or signals issued by the control system of the target vehicle;

[0012] Preferably, vehicle failure refers to a problem with a system or component of the target vehicle;

[0013] Preferably, the BMS CAN information and the vehicle CAN information are transmitted between the on-board terminal and the fault diagnosis terminal in the form of messages.

[0014] In one embodiment, step S3 is followed by:

[0015] S4. Based on the target fault cause, determine the target solution that matches the target fault cause from the preset solution library, and output the target solution; the preset solution library includes multiple solutions and fault causes associated with each solution.

[0016] Preferably, the preset solution library includes multiple preset solutions based on various faults, as well as the faults that each solution solves, i.e., the fault causes associated with each solution.

[0017] Preferably, the method of outputting the target solution includes, but is not limited to, outputting text information, outputting light, and outputting voice.

[0018] In one embodiment, step S4 includes:

[0019] Obtain the historical fault causes of the target vehicle, and add the historical fault causes to the target fault causes to obtain the updated target fault causes;

[0020] From the preset solution library, determine the target solution that matches the updated target fault cause, and output the target solution.

[0021] In one embodiment, obtaining the historical causes of failures of the target vehicle includes:

[0022] Determine the unique identification code of the target vehicle;

[0023] Determine the target identification code that matches the unique identification code from the fault database of the fault diagnosis terminal;

[0024] The fault causes associated with the target identification code in the fault database are determined as the historical fault causes of the target vehicle.

[0025] Preferably, the unique identification code is the vehicle identification number (VIN) of the target vehicle.

[0026] In one embodiment, the historical fault causes include fault causes determined by the target vehicle during the historical charging fault diagnosis process and empirical fault causes; the empirical fault causes are determined based on the charging theory knowledge of the target vehicle and the experience of the historical charging fault diagnosis.

[0027] In one embodiment, step S3 is followed by:

[0028] The cause of the target fault and the unique identification code of the target vehicle are associated and stored in the fault database of the fault diagnosis terminal.

[0029] In one embodiment, the fault diagnosis terminal includes a cloud terminal and a local terminal.

[0030] In one embodiment, step S3 includes:

[0031] The BMS CAN information and the vehicle CAN information are parsed according to the message parsing method to obtain the parsed information;

[0032] If the parsed information indicates that the battery pack data is lost, then the target fault cause for stopping charging is determined to be a communication failure between the BMS master controller and the BMS slave controller via CAN, and the battery pack where the communication failure occurred is located based on the parsed information.

[0033] If the parsed information does not contain vehicle charging permit information, then the target fault cause of the charging interruption is determined to be that the vehicle has not been issued a permit.

[0034] A charging fault diagnosis device, the device comprising:

[0035] The direction determination module is used to receive charging CAN information forwarded by the on-board terminal when the target vehicle stops charging.

[0036] The information receiving module is used to receive the BMS CAN information and the whole vehicle CAN information of the target vehicle when it is determined from the charging CAN information that the reason for the charging stop of the target vehicle is the active stop of the BMS of the target vehicle.

[0037] The fault diagnosis module is used to parse the CAN information of the BMS and the CAN information of the vehicle to obtain the target fault cause that causes the charging of the target vehicle to stop; the target fault cause is at least one of the following: the battery of the target vehicle causes the charging to stop, the vehicle fault causes the charging to stop, and the vehicle command causes the charging to stop.

[0038] A computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described above.

[0039] The aforementioned charging fault diagnosis method, device, and computer equipment receive charging CAN information forwarded by the on-board terminal when the target vehicle's charging is interrupted. When the charging CAN information determines that the cause of the charging interruption is an active shutdown by the target vehicle's BMS, it receives both the target vehicle's BMS CAN information and the vehicle's CAN information. This reduces the amount of invalid information processed, significantly shortens the time from fault occurrence to cause location, and improves troubleshooting efficiency. Simultaneously, by parsing the BMS CAN information and the vehicle's CAN information, the target fault cause causing the charging interruption is obtained. This achieves precise location from a "general direction" to a "specific fault point," allowing for more accurate identification of the target fault cause leading to the charging interruption. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating a charging fault diagnosis method in one embodiment;

[0041] Figure 2 This is a connection diagram for charging fault diagnosis in one embodiment;

[0042] Figure 3 This is a schematic diagram of the overall process of a charging fault diagnosis method in one embodiment;

[0043] Figure 4 This is a structural block diagram of a charging fault diagnosis device in one embodiment. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0045] In one embodiment, such as Figure 1 As shown, a charging fault diagnosis method is provided, including the following steps:

[0046] S1. When the target vehicle stops charging, receive the charging CAN information forwarded by the vehicle terminal.

[0047] The target vehicles refer to new energy vehicles. New energy vehicles include, but are not limited to, pure electric vehicles and plug-in hybrid vehicles.

[0048] Charging interruption of a target vehicle refers to a situation where the charging process is abnormally terminated or interrupted for some reason. Charging interruption of a target vehicle can occur at any time after charging begins until charging is completed.

[0049] Charging CAN (Controller Area Network) information is used to analyze the charging process and to troubleshoot faults that may cause charging to stop for the target vehicle. Troubleshooting directions include charging stoppages caused by charger issues and charging stoppages caused by the vehicle's BMS (Battery Management System). A BMS-initiated stoppage of charging for the target vehicle is considered a BMS-related charging stoppage. Charging CAN information includes, but is not limited to, A+ signal monitoring, insulation monitor activation commands, charging stop flag, charging voltage, charging current requirements and output values, reasons for charging stoppage by the BMS and charger, and reasons for charging stoppage faults by the BMS and charger.

[0050] When the fault diagnosis terminal receives the charging CAN information sent by the vehicle terminal, it will automatically parse the charging CAN information to determine whether the charging interruption is caused by the charger or by the vehicle's BMS.

[0051] In some embodiments, the charging CAN information sent by the vehicle terminal to the fault diagnosis terminal is obtained by the diagnostic CAN transmission. That is, after the charging CAN information is integrated into the diagnostic CAN, the diagnostic CAN transmits the charging CAN information to the vehicle terminal, and the vehicle terminal sends the received information to the fault diagnosis terminal.

[0052] S2. When the charging interruption of the target vehicle is determined to be due to the BMS of the target vehicle actively stopping, based on the charging CAN information, the CAN information of the BMS of the target vehicle and the CAN information of the whole vehicle are received.

[0053] The CAN information of the target vehicle's BMS includes CAN information within both the slave and master BMS systems. Specifically, the CAN information of the target vehicle's BMS refers to information on the CAN network directly connected to or related to the BMS. The BMS's CAN information is used to determine whether the charging interruption is caused by the target vehicle's battery, while the vehicle's CAN information is used to determine whether the charging interruption is caused by a vehicle malfunction or a vehicle command.

[0054] The vehicle CAN information includes the CAN data from the vehicle's VCU and BMS main controller. This vehicle CAN information includes, but is not limited to, vehicle CAN error messages, charging-related control commands, and mode selection commands.

[0055] In some embodiments, when the communication load of the CAN bus is below a threshold, the diagnostic CAN and the vehicle CAN are combined to use the same physical bus for information transmission.

[0056] Vehicle malfunctions refer to problems with the systems or components of the target vehicle. Vehicle malfunctions include, but are not limited to, BMS (Battery Management System) malfunctions, powertrain malfunctions, electrical system malfunctions, and safety system malfunctions. BMS malfunctions include, but are not limited to, abnormal battery temperature, excessively high or low individual cell voltage, and internal BMS communication failures. Powertrain malfunctions include, but are not limited to, engine or electric motor malfunctions, and transmission problems. Electrical system malfunctions include, but are not limited to, short circuits or open circuits in high-voltage circuits, and insulation test failures. Safety system malfunctions include, but are not limited to, abnormal states of safety systems such as the airbag system and ABS (Anti-lock Braking System).

[0057] Vehicle commands refer to various commands or signals issued by the target vehicle's control system. These commands guide each operational step in the charging process and ensure the entire charging process is executed according to the predetermined plan. Failure to issue or execute a command correctly may result in charging interruption. Vehicle commands include, but are not limited to, charging permission commands, mode selection commands, diagnostic and monitoring commands, and feedback and reporting commands. Charging permission commands ensure that the target vehicle only begins or continues charging when a series of preset conditions are met. Mode selection commands select different charging modes, such as fast charging and slow charging. Diagnostic and monitoring commands are primarily used to monitor the status of the vehicle and charging system in real time and take appropriate measures when abnormalities are detected. Feedback and reporting commands transmit and record information to ensure that all relevant parties are promptly informed of the charging process status and any events that occur.

[0058] When the charging CAN information indicates that the cause of the target vehicle's charging interruption is determined to be the target vehicle's BMS actively stopping the charging, the fault diagnosis terminal will automatically receive the target vehicle's BMS CAN information and the vehicle's CAN information, and automatically parse the BMS CAN information and the vehicle's CAN information to obtain the target fault cause that caused the target vehicle's charging interruption.

[0059] In some embodiments, when it is determined from the charging CAN information that the reason for the charging stoppage of the target vehicle is that the charger has stopped, the cause of the charger failure is determined based on the historical fault information of the charger used by the target vehicle, and the charger is troubleshooted based on the cause of the charger failure until the charger restores normal power supply.

[0060] In some embodiments, the vehicle terminal can simultaneously send charging CAN information, the target vehicle's BMS CAN information, and the whole vehicle CAN information to the fault diagnosis terminal, or it can first send charging CAN information to the fault diagnosis terminal, and then send the target vehicle's BMS CAN information and the whole vehicle CAN information to the fault diagnosis terminal.

[0061] S3. Analyze the CAN information of the BMS and the CAN information of the vehicle to obtain the target fault cause that causes the charging of the target vehicle to stop; the target fault cause is at least one of the following: the battery of the target vehicle causes the charging to stop, the vehicle fault causes the charging to stop, and the vehicle command causes the charging to stop.

[0062] The BMS CAN information and vehicle CAN information are transmitted between the on-board terminal and the fault diagnosis terminal in the form of messages. Therefore, when parsing the BMS CAN information and vehicle CAN information, it is necessary to perform the parsing according to the communication protocol. Specifically, the BMS CAN information and vehicle CAN information are parsed according to the message parsing method to obtain the parsed information. Based on the content included in the parsed information, the reason for charging stoppage can be determined. For example, the communication cycle, message ID (Identifier), and specific data covered in the message are read. Then, the 8 bytes of hexadecimal data on each ID are converted into binary data. According to the meaning and rules of the binary data defined for each byte, the specific meaning can be identified. Then, the data is identified line by line to obtain the target fault cause that caused the target vehicle to stop charging. For example, if the information parsed from the BMS CAN information is a power fault, it can be determined that the target vehicle's battery is causing the charging stoppage. If the information parsed from the vehicle CAN information is a charging disallowment command sent by the vehicle controller, it can be determined that the charging stoppage is caused by a vehicle command.

[0063] In some embodiments, the number of target failure causes may be one or more.

[0064] In some embodiments, the charging fault diagnosis method further includes outputting a target fault cause that causes the target vehicle to stop charging. The methods for outputting the target fault cause that causes the target vehicle to stop charging include, but are not limited to, outputting a light, outputting a text message, and outputting a voice message.

[0065] In some embodiments, during the charging process of the target vehicle, the CAN information of the BMS and the vehicle CAN information can be parsed to output charging process information in real time, such as the charging handshake phase passing, the BMS handshake phase passing, the charging identification phase passing, and the BMS-vehicle identification phase passing. This allows for a clear and intuitive view of the charging status.

[0066] The aforementioned charging fault diagnosis method, device, and computer equipment receive charging CAN information forwarded by the on-board terminal when the target vehicle's charging is interrupted. When the charging CAN information determines that the cause of the charging interruption is an active shutdown by the target vehicle's BMS, it receives both the target vehicle's BMS CAN information and the vehicle's CAN information. This reduces the amount of invalid information processed, significantly shortens the time from fault occurrence to cause location, and improves troubleshooting efficiency. Simultaneously, by parsing the BMS CAN information and the vehicle's CAN information, the target fault cause causing the charging interruption is obtained. This achieves precise location from a "general direction" to a "specific fault point," allowing for more accurate identification of the target fault cause leading to the charging interruption.

[0067] In one embodiment, step S3 includes:

[0068] The BMS CAN information and the vehicle CAN information are parsed according to the message parsing method to obtain the parsed information;

[0069] If the parsed information indicates that the battery pack data is lost, then the target fault causing the charging stop is determined to be a communication failure between the BMS master controller and the BMS slave controller via CAN, and the battery pack where the communication failure occurred is located based on the parsed information.

[0070] If the parsed information does not contain vehicle charging permit information, then the target fault causing the charging interruption is determined to be the failure to issue a permit for the vehicle.

[0071] Specifically, the fault reason parsed from the charging CAN information is that the target vehicle's BMS actively stopped charging. However, at this time, the specific cause of the fault cannot be clearly known through the charging CAN information. Therefore, it is necessary to further parse the BMS CAN information and the vehicle CAN information. If the BMS CAN information indicates that a certain battery pack has lost data, it can be determined that the target fault reason for the charging stop is a CAN communication failure between the BMS master controller and the BMS slave controller. The parsed information contains the information of the battery pack that has failed. Based on the parsed information, it can be determined which specific battery pack has experienced a communication failure. If the vehicle CAN information shows no vehicle charging permission information, it can be determined that the target fault reason for the BMS actively stopping charging is that the vehicle has not issued permission information.

[0072] In this embodiment, the CAN information of the BMS and the CAN information of the vehicle are parsed according to the message parsing method to obtain the parsed information. If the parsed information indicates that the battery pack data is lost, the target fault cause of the charging stop is determined to be a communication failure between the CAN of the BMS master controller and the BMS slave controller. The battery pack with the communication failure is located according to the parsed information. If there is no vehicle charging permission information in the parsed information, the target fault cause of the charging stop is determined to be that the vehicle has not issued permission information. This achieves precise positioning from the "general direction" to the "specific fault point", and can more accurately find the target fault cause of the charging stop.

[0073] In one embodiment, step S3 is followed by:

[0074] S4. Based on the cause of the target fault, determine the target solution that matches the cause of the target fault from the preset solution library and output the target solution; the preset solution library includes multiple solutions and the fault cause associated with each solution.

[0075] The preset solution library includes multiple pre-set solutions for various faults, as well as the faults that each solution addresses, i.e., the fault causes associated with each solution. The preset solution library can be pre-configured based on historical fault causes and solutions for those historical fault causes.

[0076] When determining the target solution that matches the target fault cause from the preset solution library, the fault cause associated with each solution in the preset solution library is matched with the target fault cause. If there is a fault cause that is the same as or similar to the target fault cause, then the solution associated with that fault cause is the target solution.

[0077] Furthermore, the methods for outputting the target solution include, but are not limited to, outputting text information, outputting light, and outputting voice.

[0078] In some embodiments, if there are multiple target fault causes, the target solution associated with each target fault cause is output.

[0079] Once the cause of the target fault is determined, the fault diagnosis terminal will automatically select the target solution that matches the cause of the target fault from the preset solution library and automatically output the target solution.

[0080] In some embodiments, the preset solution library can be derived from expert experience and historical failure cases. Specifically, common failure phenomena, failure causes, and corresponding solutions are summarized, and the solutions and corresponding failure causes are associated and stored in the preset solution library; historical work orders, failure reports, maintenance records, and other documents are extracted in a structured manner to form "failure causes-solutions" and stored in the preset solution library.

[0081] In this embodiment, by determining a target solution matching the target fault cause from a preset solution library based on the target fault cause and outputting the target solution, it is possible to ensure that the recommended solution is highly relevant to the fault cause, reducing misjudgments and ineffective operations. Furthermore, it avoids manual troubleshooting and reliance on experience, achieving automation and intelligence in fault response, and significantly shortening fault diagnosis and repair time.

[0082] In one embodiment, step S4 includes:

[0083] Obtain the historical fault causes of the target vehicle and add the historical fault causes to the target fault causes to obtain the updated target fault causes;

[0084] From the preset solution library, determine the target solution that matches the updated target fault cause and output the target solution.

[0085] Historical fault causes refer to the reasons why charging was interrupted when the target vehicle was charging in the past. These historical fault causes are stored in the fault database of the fault diagnosis terminal for easy retrieval at any time.

[0086] The updated target fault causes include both historical fault causes and target fault causes obtained from the CAN information of the BMS and the vehicle CAN information.

[0087] In some embodiments, if the target fault cause obtained by parsing the CAN information from the BMS and the vehicle CAN information has the same content as the historical fault cause, only one is retained to avoid duplication.

[0088] Furthermore, when there are multiple target fault causes to be updated, a target solution matching each updated target fault cause is determined from the preset solution library, and each target solution is output.

[0089] In this embodiment, by obtaining the historical fault causes of the target vehicle and adding the historical fault causes to the target fault causes, an updated target fault cause is obtained. This can improve the comprehensiveness and accuracy of fault diagnosis. When determining the target solution that matches the updated target fault cause from the preset solution library, a more accurate and comprehensive target solution is obtained. This enables comprehensive repair of faults that cause charging interruption, reduces the return rate, and improves repair efficiency.

[0090] In one embodiment, obtaining the historical causes of failures of the target vehicle includes:

[0091] Determine the unique identification code of the target vehicle;

[0092] Determine the target identification code that matches the unique identification code from the fault database at the fault diagnosis end;

[0093] The fault causes associated with the target identification code in the fault database are identified as the historical fault causes of the target vehicle.

[0094] The unique identification code, also known as the vehicle identification number (VIN), is a unique 17-character alphanumeric code, equivalent to a vehicle's "ID number." The unique identification code is used to accurately identify and distinguish each unique vehicle.

[0095] The fault database includes the historical fault causes of multiple vehicles and a unique identification code associated with each historical fault cause.

[0096] The matched target identification code is consistent with the unique identification code of the target vehicle.

[0097] In this embodiment, by determining the unique identification code of the target vehicle, the target identification code that matches the unique identification code is determined from the fault database of the fault diagnosis terminal. The fault causes associated with the target identification code in the fault database are determined as the historical fault causes of the target vehicle. This ensures that the historical fault causes of the target vehicle are obtained in the end, rather than the historical fault causes of other vehicles.

[0098] In one embodiment, the historical fault causes include fault causes determined during the historical charging fault diagnosis process of the target vehicle and empirical fault causes; the empirical fault causes are determined based on the charging theory knowledge of the target vehicle and the experience of historical charging fault diagnosis.

[0099] Among them, the fault causes identified during the historical charging fault diagnosis process of the target vehicle refer to faults that have been clearly diagnosed and confirmed and have actually occurred. Experienced fault causes refer to faults that have not yet occurred, determined based on theoretical knowledge of the target vehicle's charging and experience in diagnosing historical charging faults.

[0100] The theoretical knowledge of charging for a target vehicle refers to the in-depth scientific and engineering knowledge about the vehicle's working principles, design architecture, material properties, and physical limits. For example, if the material of the charging port seal is prone to aging under prolonged sun exposure, then "poor sealing of the charging port leading to water ingress" is an "empirical fault cause" based on materials science theory. According to the BMS's thermal management algorithm, if the coolant flow sensor fails, the BMS will default to "conservative mode" and reduce charging power. Therefore, "coolant flow sensor failure leading to slow charging" is an "empirical fault cause" based on control logic theory.

[0101] Historical charging fault diagnosis experience refers to the statistical patterns and common problems extracted from the historical fault causes of a large number of similar vehicles. For example, analyzing the historical fault causes of 1,000 vehicles of the same model in the fault database and finding that "the electronic lock failure rate of the XX model charging gun is as high as 5%", then for any target vehicle of this model, "electronic lock failure" can be listed as an "experienced fault cause". As another example, if a supplier's BMS main control board has a soldering problem that has caused multiple communication interruptions, then for all target vehicles using this BMS main control board, "poor soldering of the BMS main control board" would be considered an experienced fault cause.

[0102] In this embodiment, historical fault causes include fault causes determined during the historical charging fault diagnosis process of the target vehicle and empirical fault causes. Empirical fault causes are determined based on theoretical knowledge of the target vehicle's charging and experience in historical charging fault diagnosis, thus improving the comprehensiveness and predictability of fault diagnosis. Furthermore, by introducing empirical fault causes, in scenarios where newly manufactured vehicles or vehicles that have operated without faults for a long time have few fault causes identified during historical charging fault diagnosis, the situation of "no basis for diagnosis" due to insufficient data can be avoided.

[0103] In some embodiments, step S3 is followed by:

[0104] The cause of the target fault and the unique identification code of the target vehicle are associated and stored in the fault database of the fault diagnosis terminal.

[0105] In this embodiment, by associating the target fault cause with the unique identification code of the target vehicle and storing it in the fault database of the fault diagnosis terminal, a dynamic fault database can be established for the target vehicle. This ensures that the target fault cause of each charging interruption becomes a historical fault cause of the target vehicle, so that the historical fault causes obtained during the subsequent charging fault diagnosis of the target vehicle are more complete fault causes.

[0106] In one embodiment, the fault diagnosis end includes both cloud and local ends.

[0107] In this context, "cloud" refers to the server system deployed in a remote data center by the automaker or a third-party company, which communicates with the target vehicle via the Internet of Vehicles (IoV). "Local" refers to the hardware systems inside the target vehicle, such as electronic control units, onboard computing platforms, sensors, and actuators.

[0108] Furthermore, when the fault diagnosis end is in the cloud, the cloud receives the charging CAN information forwarded by the vehicle terminal and determines the direction of troubleshooting the fault that caused the target vehicle to stop charging based on the charging CAN information. When the troubleshooting direction indicates that the cause of the target vehicle's charging stop is the target vehicle's BMS actively stopping, the cloud receives the target vehicle's BMS CAN information and the whole vehicle CAN information, parses the BMS CAN information and the whole vehicle CAN information, and obtains the target fault cause that caused the target vehicle to stop charging.

[0109] Furthermore, when the fault diagnosis end is a local end, the local end receives the charging CAN information forwarded by the vehicle terminal, and determines the direction of troubleshooting the fault cause that caused the target vehicle to stop charging based on the charging CAN information. When the troubleshooting direction indicates that the cause of the target vehicle's charging stop is the target vehicle's BMS actively stopping, the local end receives the target vehicle's BMS CAN information and the whole vehicle CAN information, parses the BMS CAN information and the whole vehicle CAN information, and obtains the target fault cause that caused the target vehicle to stop charging.

[0110] In this embodiment, charging fault diagnosis is performed locally, which improves the real-time performance and reliability of fault diagnosis. It also allows for identification of the cause of charging interruption even when the target vehicle has no network connection, ensuring smooth charging. Using cloud-based charging fault diagnosis saves local computing resources.

[0111] This application also provides an application scenario in which the above-described charging fault diagnosis method is applied. Specifically, the charging fault diagnosis method is applied in this scenario as follows:

[0112] The connection diagram for charging fault diagnosis is as follows: Figure 2 As shown, specifically, the charging CAN information between the charger and the vehicle BMS master controller, the CAN information between the vehicle BMS slave controller and the vehicle BMS master controller, and the vehicle CAN information between the vehicle VCU and the vehicle BMS master controller are integrated into the diagnostic CAN and then transmitted to the vehicle terminal. The vehicle terminal then transmits the information to the fault diagnosis terminal for storage and fault cause identification.

[0113] The overall flowchart of the charging fault diagnosis method is as follows: Figure 3As shown. Specifically, the fault diagnosis terminal receives charging CAN information, vehicle CAN information, and BMS CAN information. The fault diagnosis terminal parses the charging CAN information and, based on the parsing results, determines the direction of troubleshooting for the fault that caused the target vehicle's charging to stop. When the troubleshooting direction indicates that the cause of the target vehicle's charging stoppage is the target vehicle's BMS actively stopping the charging, the fault diagnosis terminal parses the BMS CAN information and vehicle CAN information to obtain the target fault cause that caused the target vehicle's charging to stop, and retrieves the target vehicle's historical fault causes, adding the historical fault causes to the target fault cause to obtain the updated target fault cause. Based on the updated target fault cause, the fault diagnosis terminal determines a target solution that matches the updated target fault cause from a preset solution library and outputs the target solution and the updated target fault cause.

[0114] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0115] Based on the same inventive concept, this application also provides a charging fault diagnosis device for implementing the charging fault diagnosis method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more embodiments of the charging fault diagnosis device provided below can be found in the limitations of the charging fault diagnosis method described above, and will not be repeated here.

[0116] In one embodiment, such as Figure 4 As shown, a charging fault diagnosis device is provided, comprising:

[0117] The direction determination module 402 is used to receive charging CAN information forwarded by the vehicle terminal when the target vehicle stops charging.

[0118] The information receiving module 404 is used to receive the CAN information of the BMS of the target vehicle and the CAN information of the whole vehicle when it is determined from the charging CAN information that the reason for the charging stop of the target vehicle is the active stop of the BMS of the target vehicle.

[0119] The fault diagnosis module 406 is used to parse the CAN information of the BMS and the CAN information of the vehicle to obtain the target fault cause that causes the charging of the target vehicle to stop; the target fault cause is at least one of the following: the battery of the target vehicle causes the charging to stop, the vehicle fault causes the charging to stop, and the vehicle command causes the charging to stop.

[0120] Each module in the aforementioned charging fault diagnosis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0121] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0122] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0123] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0124] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0125] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0126] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A charging fault diagnosis method, applied to a fault diagnosis terminal, characterized in that, The method includes: S1. When the target vehicle stops charging, receive the charging CAN information forwarded by the vehicle terminal. S2. When it is determined from the charging CAN information that the reason for the charging stop of the target vehicle is the active stop of the BMS of the target vehicle, the CAN information of the BMS of the target vehicle and the CAN information of the whole vehicle are received. S3. Parse the CAN information of the BMS and the CAN information of the vehicle to obtain the target fault cause that causes the charging of the target vehicle to stop; the target fault cause is at least one of the following: the battery of the target vehicle causes the charging to stop, the vehicle fault causes the charging to stop, and the vehicle command causes the charging to stop. Step S3 is followed by: S4. Based on the target fault cause, determine the target solution that matches the target fault cause from the preset solution library, and output the target solution; the preset solution library includes multiple solutions and fault causes associated with each solution; Step S4 includes: Obtain the historical fault causes of the target vehicle, and add the historical fault causes to the target fault causes to obtain the updated target fault causes; From the preset solution library, determine the target solution that matches the updated target fault cause, and output the target solution; The process of obtaining the historical causes of faults of the target vehicle includes: Determine the unique identification code of the target vehicle; Determine the target identification code that matches the unique identification code from the fault database of the fault diagnosis terminal; The fault causes associated with the target identification code in the fault database are determined as the historical fault causes of the target vehicle.

2. The method according to claim 1, characterized in that, The historical fault causes include the fault causes determined during the historical charging fault diagnosis process of the target vehicle and the empirical fault causes; the empirical fault causes are determined based on the charging theory knowledge of the target vehicle and the experience of the historical charging fault diagnosis.

3. The method according to claim 1, characterized in that, Step S3 is followed by: The cause of the target fault and the unique identification code of the target vehicle are associated and stored in the fault database of the fault diagnosis terminal.

4. The method according to claim 1, characterized in that, The fault diagnosis terminal includes both cloud-based and local terminals.

5. The method according to claim 1, characterized in that, Step S3 includes: The BMS CAN information and the vehicle CAN information are parsed according to the message parsing method to obtain the parsed information; If the parsed information indicates that the battery pack data is lost, then the target fault cause of the charging stop is determined to be a communication failure between the BMS master controller and the BMS slave controller via CAN, and the battery pack that experienced the communication failure is located based on the parsed information. If the parsed information does not contain vehicle charging permit information, then the target fault cause of the charging interruption is determined to be that the vehicle has not been issued a permit.

6. A charging fault diagnosis device, used to perform the method according to any one of claims 1-5, characterized in that, The device includes: The direction determination module is used to receive charging CAN information forwarded by the on-board terminal when the target vehicle stops charging. The information receiving module is used to receive the BMS CAN information and the whole vehicle CAN information of the target vehicle when it is determined from the charging CAN information that the reason for the charging stop of the target vehicle is the active stop of the BMS of the target vehicle. The fault diagnosis module is used to parse the CAN information of the BMS and the CAN information of the vehicle to obtain the target fault cause that causes the charging of the target vehicle to stop; the target fault cause is at least one of the following: the battery of the target vehicle causes the charging to stop, the vehicle fault causes the charging to stop, and the vehicle command causes the charging to stop.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

Images