Method of correcting soh and electronic device

Abstract

The application provides a method for correcting SOH and an electronic device, and the method comprises the following steps: identifying whether a vehicle meets a first vehicle condition through a cloud; if the vehicle meets the first vehicle condition, sending an encrypted SOH correction value to the vehicle, so that the vehicle performs SOH correction based on the SOH correction value under the condition of meeting a second vehicle condition. In the scheme, the cloud identifies the vehicle condition of the vehicle before issuing the SOH correction value, and when it is determined that the vehicle is in the first vehicle condition, the SOH correction value is issued to the vehicle in an encrypted manner, and the vehicle performs SOH correction based on the SOH correction value under the condition of being in the second vehicle condition, thereby avoiding the invalid issuance condition of the SOH correction value, ensuring the stability of vehicle-cloud interaction and avoiding vehicle-cloud misinteraction.

Description

Technical Field

[0001] This invention relates to the field of vehicle power battery management technology, specifically to a method and electronic device for correcting State of Health (SOH). Background Technology

[0002] With the increasing popularity of new energy vehicles, the estimation of the vehicle's SOH (Power Battery Health) is crucial for vehicle range management and safety warnings.

[0003] Currently, the SOH calculation results are usually sent from the cloud to the vehicle. However, the interaction link between the cloud and the vehicle to correct the SOH is long and complex. During the interaction, problems such as poor network connection, cloud backend system failure, scene misjudgment, and external data tampering can easily occur, which will lead to vehicle-cloud interaction failure or erroneous interaction. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method and electronic device for correcting SOH (System Occurrence of Hazards) to avoid vehicle-to-cloud interaction failures or erroneous interactions.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0006] The first aspect of this invention discloses a method for correcting SOH (Sort of Holes), the method being applicable to the cloud, the method comprising:

[0007] The system identifies whether the vehicle meets a first vehicle condition, which indicates that the vehicle is in a state where it can receive remote update commands.

[0008] If the vehicle meets the first vehicle condition, the encrypted SOH correction value is sent to the vehicle, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition is met. The second vehicle condition is used to indicate that the vehicle is in a state where the SOH parameter write operation can be performed.

[0009] Preferably, identifying whether a vehicle meets the first vehicle condition condition includes:

[0010] Collect first specified information about the vehicle, which includes at least one of vehicle speed, charging status, current, battery data, and fault codes;

[0011] The vehicle is determined to be in a dormant state based on the first specified information.

[0012] If the vehicle is in a dormant state, determine whether the vehicle simultaneously meets multiple first preset conditions used to determine whether the SOH correction value can be issued.

[0013] If the vehicle simultaneously meets multiple of the first preset conditions, it is determined that the vehicle meets the first vehicle condition conditions.

[0014] Preferably, if the vehicle meets the first vehicle condition condition, the encrypted SOH correction value is sent to the vehicle, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition condition is met, including:

[0015] If the vehicle meets the first vehicle condition, perform two-way identity authentication with the vehicle and establish a secure communication channel;

[0016] The encrypted SOH correction value is sent to the vehicle through the secure communication channel, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition is met.

[0017] Preferably, after sending the encrypted SOH correction value to the vehicle, the method further includes:

[0018] Receive the status code fed back by the vehicle, the status code representing the execution result of the SOH correction;

[0019] Execute the processing strategy corresponding to the status code.

[0020] Preferably, after receiving the status code fed back by the vehicle, the method further includes:

[0021] Based on the statistical distribution of the status codes, the thresholds used to determine whether the power battery has sufficient power and the storage battery has sufficient power in the first preset conditions are optimized and adjusted.

[0022] Preferably, before sending the encrypted SOH correction value to the vehicle, the method further includes:

[0023] Send a wake-up message to the vehicle and start a waiting timer;

[0024] If no ready signal is received from the vehicle within the preset time, the encrypted SOH correction value will be abandoned and the timeout status will be recorded.

[0025] If a ready signal is received from the vehicle within the preset time, the step of sending the encrypted SOH correction value to the vehicle is executed.

[0026] A second aspect of this invention discloses a method for correcting SOH (State of Health), the method being applicable to vehicles, the method comprising:

[0027] The vehicle receives an encrypted SOH correction value sent from the cloud. The encrypted SOH correction value is sent by the cloud when a first vehicle condition is met. The first vehicle condition is used to indicate that the vehicle is in a state where it can receive remote update commands.

[0028] Decrypt the encrypted SOH correction value to obtain the SOH correction value;

[0029] Identify whether the vehicle meets the second vehicle condition, which indicates that the vehicle is in a state where the SOH parameter write operation can be performed.

[0030] If the vehicle meets the second vehicle condition, SOH correction is performed based on the SOH correction value.

[0031] Preferably, identifying whether the vehicle meets the second vehicle condition includes:

[0032] Collect second specified information of the vehicle, the second specified information including at least one of power battery charge, fault code, vehicle speed and charging status;

[0033] The second specified information is used to determine whether the vehicle simultaneously meets multiple second preset conditions used to determine whether SOH parameter writing is allowed.

[0034] If the vehicle simultaneously meets multiple of the second preset conditions, it is determined that the vehicle meets the second vehicle condition conditions.

[0035] Preferably, if the vehicle meets the second vehicle condition condition, SOH correction is performed based on the SOH correction value, including:

[0036] If the vehicle meets the second vehicle condition, the reasonableness of the SOH correction value is verified.

[0037] If the SOH correction value passes the rationality check, the SOH parameter of the vehicle is updated to the SOH correction value.

[0038] A third aspect of this invention discloses an apparatus for correcting SOH (Solar Oxygen Harmonic Discharge), the apparatus being suitable for cloud computing, the apparatus comprising:

[0039] The first identification unit is used to identify whether the vehicle meets the first vehicle condition condition, which indicates that the vehicle is in a state that can receive remote update commands.

[0040] The sending unit is configured to send the encrypted SOH correction value to the vehicle if the vehicle meets the first vehicle condition, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition is met. The second vehicle condition is used to indicate that the vehicle is in a state where the SOH parameter writing operation can be performed.

[0041] A fourth aspect of this invention discloses an apparatus for correcting state of hazardous emissions (SOH), the apparatus being suitable for vehicles, the apparatus comprising:

[0042] The receiving unit is used to receive the encrypted SOH correction value sent by the cloud. The encrypted SOH correction value is sent by the cloud under the condition of satisfying a first vehicle condition. The first vehicle condition is used to indicate that the vehicle is in a state that can receive remote update commands.

[0043] A decryption unit is used to decrypt the encrypted SOH correction value to obtain the SOH correction value;

[0044] The second identification unit is used to identify whether the vehicle meets the second vehicle condition, which indicates that the vehicle is in a state where the SOH parameter writing operation can be performed.

[0045] An execution unit is configured to perform SOH correction based on the SOH correction value if the vehicle meets the second vehicle condition conditions.

[0046] A fifth aspect of the present invention discloses an electronic device, comprising: a processor and a memory, the processor and the memory being connected via a bus; wherein, the processor is configured to call and execute a program stored in the memory; the memory is configured to store the program, the program being configured to implement the method for correcting SOH disclosed in the first aspect of the present invention, or the program being configured to implement the method for correcting SOH disclosed in the second aspect of the present invention.

[0047] Based on the above embodiments of the present invention, a method and electronic device for correcting State of Health (SOH) are provided. The method involves: identifying whether a vehicle meets a first vehicle condition condition via the cloud; if the vehicle meets the first vehicle condition condition, sending an encrypted SOH correction value to the vehicle, so that the vehicle performs SOH correction based on the SOH correction value when it meets a second vehicle condition condition. In this solution, the cloud identifies the vehicle's condition condition before sending the SOH correction value. When it is determined that the vehicle is under the first vehicle condition condition, the SOH correction value is sent to the vehicle in an encrypted manner. The vehicle then performs SOH correction based on the SOH correction value when it is under the second vehicle condition condition, avoiding invalid SOH correction value transmission, ensuring stable vehicle-cloud interaction, and preventing erroneous vehicle-cloud interactions. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0049] Figure 1 A flowchart of a method for correcting SOH provided in an embodiment of the present invention;

[0050] Figure 2 Another flowchart of a method for correcting SOH provided in an embodiment of the present invention;

[0051] Figure 3 An example diagram illustrating the interaction between the cloud and the vehicle, provided for an embodiment of the present invention;

[0052] Figure 4 A structural block diagram of an apparatus for correcting SOH provided in an embodiment of the present invention;

[0053] Figure 5 Another structural block diagram of an apparatus for correcting SOH provided in an embodiment of the present invention. Detailed Implementation

[0054] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0056] As the background technology shows, with the popularization of new energy vehicles, the estimation of the vehicle's State of Health (SOH) is crucial for vehicle range management and safety warnings. Currently, the SOH calculation results are usually sent from the cloud to the vehicle. However, the interaction link between the cloud and the vehicle to correct the SOH is long and complex. During the interaction, issues such as poor network connectivity, cloud backend system failures, scene misjudgments, and external data tampering can easily occur, leading to vehicle-cloud interaction failures or erroneous interactions.

[0057] To address this, this invention proposes a method and electronic device for correcting SOH (State of Health). Before issuing the SOH correction value, the cloud identifies the vehicle's condition. When the vehicle is determined to be under the first condition, the SOH correction value is issued to the vehicle in an encrypted manner. When the vehicle is under the second condition, SOH correction is performed based on the SOH correction value, thus avoiding invalid issuance of the SOH correction value, ensuring stable vehicle-cloud interaction, and preventing erroneous vehicle-cloud interaction.

[0058] To facilitate understanding of the technical solutions of the embodiments of the present invention, some technical terms involved in the embodiments of the present invention will be explained as follows:

[0059] Power battery: refers to the high-voltage rechargeable battery system in a vehicle that provides driving power. It is usually composed of multiple cells connected in series or parallel, and its output voltage is generally several hundred volts. It is the core power source of new energy vehicles. The health of the power battery directly determines the vehicle's driving range and power performance.

[0060] Storage battery: refers to the 12V or 24V low-voltage rechargeable battery in a vehicle used to power low-voltage electrical equipment (such as on-board controllers, sensors, communication modules, lighting systems, etc.), usually a lead-acid battery or a lithium battery. When the vehicle is in sleep mode, the storage battery provides standby power for devices that need to remain in standby mode, such as TBOX. Therefore, whether the storage battery has sufficient power directly determines whether the vehicle can be successfully woken up and complete remote communication.

[0061] State of Health (SOH) is a quantitative indicator that characterizes the degree of performance degradation of a power battery compared to a brand-new battery, usually expressed as a percentage. The SOH value reflects aging characteristics such as capacity decay and increased internal resistance. Accurate estimation of SOH is crucial for vehicle range management, charging and discharging strategy optimization, and safety warnings. A lower SOH value indicates a more severe degree of battery aging.

[0062] SOH Correction Value: This refers to the updated value calculated by the cloud server based on big data analysis and aging models, used to update the SOH parameters stored locally on the vehicle. Because the cloud can aggregate a large amount of vehicle operating data and uses more complex algorithm models, the SOH correction value calculated by it is usually more accurate and reliable than the SOH value estimated by the vehicle based on limited data.

[0063] TBOX (Telematics Box): Refers to a remote communication control unit installed in a vehicle, equipped with cellular network communication (such as 4G / 5G), GPS positioning, CAN bus communication, and other functions. As a data interaction hub between the vehicle and the cloud, the TBOX is responsible for uploading vehicle operation data to the cloud and receiving remote control commands and configuration update data from the cloud.

[0064] BMS (Battery Management System): A dedicated controller used to monitor, control, and manage a power battery system. The BMS is responsible for real-time acquisition of battery parameters such as voltage, current, and temperature; estimating the battery's SOC (State of Charge) and SOH (State of Health); and performing functions such as equalization control, overcharge and over-discharge protection, and thermal management. The BMS is the final execution unit for SOH correction and updates.

[0065] CAN (Controller Area Network) is a serial communication protocol widely used in the automotive industry, characterized by high reliability, real-time performance, and interference resistance. Various electronic control units within a vehicle (such as BMS, TBOX, and vehicle controller) exchange data via the CAN bus.

[0066] AES128 (Advanced Encryption Standard 128-bit) is a symmetric block cipher algorithm that uses a 128-bit key to encrypt and decrypt data. AES128 is characterized by high security and efficiency and is widely used in various secure communication scenarios. In this embodiment of the invention, the cloud and the vehicle each store the same AES128 key for encrypted transmission of the SOH correction value, preventing data from being stolen or tampered with during transmission.

[0067] Ciphertext: refers to encrypted data obtained by encrypting the original plaintext data (such as SOH correction values, command identifiers, etc.) using an encryption algorithm. It cannot be directly read. Only the recipient with the correct decryption key can restore the ciphertext to plaintext.

[0068] CRC (Cyclic Redundancy Check) is an error detection coding technique widely used in data communication. The sender calculates a fixed-length checksum based on the data to be sent and appends it to the data before sending. The receiver recalculates the checksum upon receiving the data and compares it with the received checksum. If they match, it means no error occurred during data transmission; if they do not match, it means the data has been corrupted or tampered with.

[0069] Message counter: This refers to a security mechanism used to prevent replay attacks, typically a monotonically increasing integer value. The sender includes the current message counter value with each sent command, and the receiver records and verifies the continuity of the message counter. If the received message counter value is less than or equal to the previously received value, the message is considered invalid or a replay attack and is discarded.

[0070] See Figure 1The flowchart illustrates a method for correcting SOH according to an embodiment of the present invention. Figure 1 The method shown is applicable to the cloud and includes:

[0071] Step S101: Identify whether the vehicle meets the first vehicle condition condition.

[0072] It should be noted that the first vehicle condition indicates that the vehicle is in a state where it can receive remote update commands. In other words, the first vehicle condition is a pre-judgment condition from the cloud side regarding whether the vehicle is currently suitable for receiving the SOH correction value. Only when the vehicle is in this state will the cloud initiate the subsequent encrypted transmission process; if the vehicle does not meet this condition, the cloud will not transmit the SOH correction value, thereby avoiding invalid transmissions that could interfere with the normal operation of the vehicle.

[0073] In the specific implementation step S101, the cloud collects the first specified information of the vehicle, which includes at least one of the following: vehicle speed, charging status, current, battery data (such as battery voltage or SOC) and fault code (characterizing fault status).

[0074] Specifically, the cloud collects operational data reported by vehicles and identifies the vehicle's first designated information from this operational data.

[0075] It should be noted that the first specified information is the fundamental data source for the cloud to determine whether the vehicle is in a state where it can receive remote update commands. This information is periodically reported by the vehicle to the cloud via the TBOX, with a reporting cycle typically on the order of seconds or minutes. After receiving this reported data, the cloud server stores it in the cloud database for subsequent judgment logic to call. Among them, the vehicle speed signal reflects the vehicle's movement status; the charging status signal reflects whether the vehicle is connected to the charging equipment; the current signal reflects whether current is flowing through the main circuit of the power battery; the fault code reflects whether there are abnormal conditions in various subsystems of the vehicle; and the battery voltage or SOC reflects the energy reserve status of the low-voltage power supply system. By comprehensively analyzing this multi-dimensional information, the cloud can accurately determine the vehicle's true status and avoid misjudgments caused by relying on a single piece of information.

[0076] The cloud determines whether a vehicle is in a hibernation state based on the first specified information. Specifically, multiple hibernation conditions are preset; when the first specified information determines that multiple hibernation conditions are met simultaneously, the vehicle is determined to be in a hibernation state; when the first specified information determines that multiple hibernation conditions are not met simultaneously, the vehicle is determined not to be in a hibernation state.

[0077] For example, sleep conditions may include, but are not limited to: vehicle speed is zero (indicating that the vehicle is stationary); charging status is non-charging (indicating that the vehicle is not connected to an external charging device); current is approximately zero (indicating that there is no current output or input in the main circuit of the power battery); no fault codes (indicating that the vehicle's various electronic control systems are in normal working condition); battery voltage is higher than a preset threshold or battery SOC is higher than a preset percentage (indicating that the low-voltage power supply system has sufficient power to support the wake-up and normal operation of communication devices such as TBOX).

[0078] For example: vehicle speed determines whether the vehicle is stationary; charging status determines whether the vehicle is not charging; current determines whether there is no current in the vehicle's main circuit; fault codes determine whether the vehicle system is fault-free; and battery voltage or SOC determines whether the vehicle's low-voltage power supply is sufficient.

[0079] When the vehicle is stationary, not charging, has no current in the main circuit, has no faults in the vehicle system, and has sufficient low-voltage power supply, it can be determined that the vehicle is in a dormant state; otherwise, it can be determined that the vehicle is not in a dormant state.

[0080] If the vehicle is not in a dormant state, State of Health (SOH) correction cannot be performed. This is because during vehicle operation or charging, the battery is in a transient state of high-current charging and discharging, and the Battery Management System (BMS) is executing complex real-time control strategies. Writing SOH correction values ​​during this time could conflict with the BMS's normal control logic, leading to unpredictable control anomalies. Therefore, a safe SOH update is only possible under the steady-state condition of a completely dormant vehicle.

[0081] If the vehicle is in a dormant state, determine whether the vehicle simultaneously meets multiple first preset conditions used to determine whether the SOH correction value can be issued; if the vehicle simultaneously meets multiple first preset conditions, determine that the vehicle meets the first vehicle condition conditions, and execute step S102. Otherwise, determine that the vehicle does not meet the first vehicle condition conditions.

[0082] For example, the following six first preset conditions are set in advance:

[0083] First preset condition 1: Sufficient power battery charge: This condition is used to ensure that the power battery has sufficient energy reserves to avoid over-discharge of the battery due to SOH correction operation or to avoid affecting the subsequent starting and driving of the vehicle.

[0084] First preset condition 2: Sufficient battery power: This condition is used to ensure that the low-voltage power supply system has enough power to support the communication operation of TBOX in the wake-up state and the execution operation of BMS, and to avoid communication interruption or execution failure due to battery depletion.

[0085] First preset condition 3, system power off: This condition is used to confirm that the vehicle's high-voltage system has been safely de-energized to avoid safety risks caused by accidental power-on of the high-voltage system during SOH correction operations;

[0086] First preset condition 4, BMS (Battery Management System) is fault-free: This condition is used to ensure that the BMS is in normal working condition and can reliably receive and process SOH correction commands, avoiding data corruption caused by performing write operations when the BMS is faulty;

[0087] First preset condition 5, vehicle speed is zero: This condition is used to confirm that the vehicle is completely stationary, forming a double confirmation with the vehicle speed condition in the dormant state judgment.

[0088] First preset condition 6, vehicle not charging: This condition is used to confirm that the vehicle is not connected to an external charging device, so as to avoid conflicts between the interaction logic between the BMS and the charger and the SOH correction operation during the charging process.

[0089] When a vehicle is in a dormant state and simultaneously meets the above six first preset conditions, it is determined that the vehicle meets the first vehicle condition conditions.

[0090] The above methods are used to identify whether a vehicle meets the first vehicle condition condition. If it does, the subsequent SOH correction value issuance process continues. If it does not meet the condition, the SOH correction is not executed, thus avoiding invalid issuance of SOH correction values ​​and erroneous interaction between the vehicle and the cloud.

[0091] Understandably, the specific thresholds or judgment criteria for the above six first preset conditions can be flexibly configured according to actual application scenarios and vehicle models. For example, different vehicle models have different rated battery capacities, so the SOC threshold for judging "sufficient battery power" can be set to different values ​​between 30% and 50%; different battery models have different capacities, so the voltage threshold or SOC threshold for judging "sufficient battery power" will also differ accordingly. The cloud server can flexibly adjust these thresholds through configuration files or remote parameter distribution to adapt to the needs of different vehicle models and application scenarios.

[0092] Step S102: If the vehicle meets the first vehicle condition condition, send the encrypted SOH correction value to the vehicle so that the vehicle can perform SOH correction based on the SOH correction value if the second vehicle condition condition is met.

[0093] It's important to note that the cloud-based system pre-calculates the vehicle's SOH correction value using a SOH algorithm. Specifically, the cloud server aggregates a large amount of operational data from vehicles of the same model, including but not limited to parameters such as battery voltage, current, temperature, charge / discharge cycle count, cumulative mileage, and depth of charge / discharge. Based on this large dataset, the cloud uses aging models, machine learning algorithms, or empirical formulas to estimate and predict the vehicle's current SOH value, thereby calculating the SOH correction value. Because the cloud has stronger computing power and richer data sources, its calculated SOH correction value typically has higher accuracy and reliability than the SOH value estimated by the vehicle's BMS based on limited local data.

[0094] In the specific implementation of step S102, if the vehicle meets the first vehicle condition condition, the cloud encrypts the SOH correction value and then sends the encrypted SOH correction value to the vehicle, so that the vehicle can perform SOH correction based on the SOH correction value when the second vehicle condition condition is met.

[0095] The second vehicle condition is used to indicate that the vehicle is in a state where the SOH parameter writing operation can be performed.

[0096] For example, the cloud uses the AES128 encryption algorithm to encrypt the SOH correction value. The AES128 algorithm uses a 128-bit key, offering high security and computational efficiency, making it suitable for symmetric encrypted communication between the cloud and the vehicle. In practical applications, the cloud and the vehicle are pre-configured with the same AES128 key at the factory or during initial network setup. This key remains unchanged throughout the vehicle's lifespan or is periodically updated through secure channels.

[0097] Understandably, the vehicle has a pre-installed key, while the key is stored in the cloud. Key management between the cloud and the vehicle uses a symmetric key system, meaning the same key is used for encryption and decryption. The cloud encrypts data using the key before sending it, and the vehicle decrypts it using the same key after receiving it. Compared to asymmetric encryption, this method has the advantages of lower computational overhead and faster processing speed, making it suitable for scenarios in vehicle-to-cloud communication where real-time performance is a requirement.

[0098] In some embodiments, the encrypted SOH correction value is sent to the vehicle in the following manner: if the vehicle meets the first vehicle condition, the cloud performs two-way identity authentication with the vehicle and establishes a secure communication channel, and sends the encrypted SOH correction value to the vehicle through the secure communication channel, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition is met.

[0099] For example, the cloud and the vehicle perform two-way authentication through a designated system and establish a secure communication channel such as TLS / HTTPS. The cloud sends the encrypted SOH correction value to the vehicle through this secure communication channel. Two-way authentication can be implemented based on a digital certificate system or a pre-set key system. Through two-way authentication, the cloud can verify that the vehicle currently communicating is a legitimate registered target vehicle and not a counterfeit device, and the vehicle can also verify that the cloud currently communicating is a legitimate authorized server and not a phishing server. The two-way authentication mechanism effectively prevents security threats such as man-in-the-middle attacks and device forgery.

[0100] In practical applications, the cloud at least encrypts the SOH update command (the signal field indicating that SOH correction needs to be performed) and the SOH correction value to obtain ciphertext. The ciphertext includes: the identifier of the SOH update command, the SOH correction value, the command sequence number of the SOH update command, and a valid timestamp.

[0101] It should be noted that the command sequence number is a monotonically increasing integer value, incremented by 1 each time the cloud sends a SOH update command. The vehicle records the sequence number of the last successfully processed command. When a new command is received, it checks if its sequence number is greater than the previously recorded sequence number. If the sequence number is not greater than the previous value, it indicates that the command may be a replay attack or an expired duplicate command, and the vehicle will discard the command without processing it. The valid timestamp is used to limit the validity period of the command. After receiving the command, the vehicle checks if the current time is within the valid time window indicated by the valid timestamp. If it exceeds the valid time window, the command is discarded. This dual verification mechanism of sequence number and timestamp effectively prevents replay attacks and the accidental execution of expired commands.

[0102] The cloud package the VIN, distribution time, and encrypted data into an update data packet, wakes up the vehicle, and distributes the update data packet to the vehicle (e.g., to the vehicle's TBOX). The vehicle decrypts the encrypted data packet to obtain the SOH update command and SOH correction value.

[0103] It should be noted that the Vehicle Identification Number (VIN) is a unique identifier for a vehicle, and the cloud includes the VIN of the target vehicle when packaging the update data packet. After receiving the update data packet, the vehicle first checks whether the VIN in it matches the VIN stored in its own memory. If they do not match, the data packet is discarded and an error is logged, thus ensuring that the update data packet is not received and processed by the wrong vehicle.

[0104] In some embodiments, after the cloud sends a wake-up message to the vehicle's TBOX, the cloud waits for the TBOX to reply with a ready signal within a preset time. If the cloud does not receive a reply with a ready signal from the TBOX within the timeout period, the cloud abandons the message delivery and records the timeout status.

[0105] It should be noted that the wake-up message is a special network message whose purpose is to wake the TBOX from low-power mode to normal operation mode when it is in sleep mode. The TBOX maintains its listening function for the communication module even in sleep mode. When it receives a wake-up message of a specific format (such as a specified port number or a specific data pattern), the TBOX activates the main processor and enters normal operation mode. It then replies with a ready signal to the cloud, indicating that it is ready to receive subsequent update data packets.

[0106] The preset timeout period can be configured based on the network environment and the characteristics of the vehicle communication module; for example, it can be set to 10 seconds, 30 seconds, or 60 seconds. If the network latency is high or the TBOX wake-up time is long, the preset timeout period can be increased appropriately. The cloud records the timeout status for subsequent operation and maintenance analysis and troubleshooting.

[0107] Specifically, before sending the encrypted SOH correction value to the vehicle, the cloud sends a wake-up message to the vehicle's TBOX and starts a waiting timer. If the cloud does not receive a ready signal from the vehicle within a preset time, it abandons the sending of the encrypted SOH correction value and records the timeout status. If the cloud receives a ready signal from the vehicle within a preset time, it executes the step of sending the encrypted SOH correction value to the vehicle.

[0108] By employing the above methods and sending encrypted SOH update commands and SOH correction values ​​to the vehicle, the secure delivery of SOH correction values ​​is ensured, preventing external data tampering. External data tampering refers to attackers intercepting, modifying, or forging communication data to attempt to write incorrect SOH correction values ​​into the vehicle's BMS, leading to abnormal battery management strategies and even security risks. This solution utilizes AES128 encryption and dual authentication; even if communication data is intercepted, attackers cannot decrypt it to obtain plaintext content, nor can they forge valid update data packets.

[0109] It should be noted that during the SOH correction process, vehicles may encounter different execution states, each corresponding to a different SOH correction result. To ensure the cloud is aware of the SOH correction result, the vehicle generates and sends back corresponding status codes during the SOH correction process.

[0110] In some embodiments, after the cloud sends the encrypted SOH correction value to the vehicle, the cloud receives a status code from the vehicle, which indicates the execution result of the SOH correction.

[0111] In practical applications, the following five types of status codes can be set (this is just an example and can be set according to the actual situation): Execution successful (referred to as finish), parameter exceeded (referred to as Over range), update timeout (referred to as Over time), process interrupted (referred to as Interrupt), and status not allowed (referred to as Not allowed).

[0112] The "finish" status code indicates that the vehicle has successfully updated the SOH value to the corrected SOH value. This means the vehicle's BMS has completed the validity check and successfully updated the locally stored SOH parameter value to the corrected SOH value sent from the cloud, and the BMS has successfully written the updated SOH value to non-volatile memory.

[0113] The status code "Parameter Over Range" indicates that the SOH correction value is outside the reasonable range (or the updated parameter does not meet the preset SOH parameter comparison conditions). Specifically, when the BMS performs a reasonableness check on the SOH correction value, it finds that the correction value exceeds the preset correctable range, or the difference between the original SOH value and the correction value exceeds the preset transition threshold. Therefore, the BMS refuses to execute this update.

[0114] The status code "Over time" indicates that the vehicle's BMS timed out during the SOH update operation, failing to complete the SOH update within the specified time. Update timeouts can be caused by various reasons, such as busy CAN bus communication leading to message transmission delays, busy internal BMS task scheduling failing to process update commands in a timely manner, or slow write operations to non-volatile memory.

[0115] The status code "Interrupted" indicates that the update process is interrupted when the vehicle is detected to be powered on or charging during the SOH update. This interruption is a protective mechanism; if the vehicle is woken up during the SOH update (e.g., a user remotely turns on the air conditioning via a mobile app, a user inserts the charging gun, or the vehicle detects a key signal), the system immediately terminates the SOH update operation to ensure driving safety and the integrity of the BMS control logic.

[0116] The status code "Not allowed" indicates that the vehicle was not in a dormant state when the SOH update was performed.

[0117] To enable differentiated processing of status codes, corresponding processing strategies are pre-defined for different types of status codes. After receiving a status code from the vehicle, the cloud executes the processing strategy corresponding to that status code.

[0118] For example, the handling strategy for the "Parameter Over Range" status code is to trigger the SOH output value calibration process of the cloud-based aging model. Specifically, when the cloud receives the "Parameter Over Range" status code, it indicates a significant deviation between the SOH correction value calculated by the cloud-based aging model and the SOH value estimated by the vehicle-side BMS. The cloud will then initiate a model calibration process to re-check the accuracy of the model input data and the rationality of the model's parameter configuration. If necessary, the model will be retrained or its parameters adjusted to improve the accuracy of subsequent SOH correction values.

[0119] The handling strategy for the "Update Timeout (Over time)" status code is as follows: record network latency data and adjust the timeout threshold for subsequent tasks. The cloud records relevant data about this update timeout (such as dispatch time, vehicle response time, timeout duration, etc.) in the database, analyzes the distribution of network latency, and dynamically adjusts the preset timeout threshold based on the statistical results to improve the success rate of subsequent tasks.

[0120] The handling strategies for the status codes "Interrupted" and "Not allowed" are as follows: The update task is retained, and the timing of its re-deployment is adjusted. The cloud will not mark this update as failed; instead, the update task will be kept in the task queue, waiting for a suitable time (e.g., after the vehicle enters sleep mode again) to be re-deployed. The cloud can adjust the re-deployment timing based on historical records, for example, delaying it to off-peak hours at night or when the vehicle has been parked for an extended period.

[0121] In one example, after the cloud sends the encrypted SOH correction value to the vehicle, if the cloud receives a status code from the vehicle that is not allowed (i.e., "Not allowed"), it will retry sending the encrypted SOH correction value after a preset cooldown time.

[0122] It should be noted that the preset cooldown time is set to avoid frequent deployments when the vehicle status does not yet meet the conditions, which would waste communication resources and cause the vehicle to be repeatedly woken up. For example, the preset cooldown time can be set to 5 minutes, 10 minutes, or 30 minutes, and the specific value can be configured according to the actual application scenario. After the preset cooldown time expires, the cloud re-evaluates whether the vehicle meets the first vehicle condition conditions. If it does, it will try to deploy again.

[0123] In practical applications, if the cloud receives multiple failed SOH update records for the same vehicle, remote SOH updates for that vehicle will be suspended and handled by other entities (e.g., the after-sales diagnostic link). Multiple failures (e.g., more than three consecutive failures) may indicate a communication failure, BMS malfunction, or other hardware problem in the vehicle, where remote updates are no longer effective. In such cases, offline diagnostics must be performed by after-sales personnel using physical connections such as the OBD interface to check and update the SOH parameters.

[0124] In some embodiments, after receiving the status code from the vehicle, the cloud reads the corrected SOH parameters from the vehicle. If the corrected SOH parameters are equal to the corrected SOH value, the cloud records a successful execution result. If the corrected SOH parameters are not equal to the corrected SOH value, the cloud records a failed execution result and the reason for the failure.

[0125] In some embodiments, the cloud performs statistics based on the status codes fed back by the vehicle, and optimizes and adjusts the thresholds used to determine "power battery power is sufficient" and "storage battery power is sufficient" in the first preset conditions based on the statistical distribution of the status codes.

[0126] In this embodiment of the invention, the cloud identifies the vehicle's condition before sending the SOH correction value. When the vehicle is determined to be under the first condition, the SOH correction value is sent to the vehicle in an encrypted manner. When the vehicle is under the second condition, the SOH correction is performed based on the SOH correction value to avoid invalid SOH correction value sending, ensure stable vehicle-cloud interaction and avoid erroneous vehicle-cloud interaction.

[0127] See Figure 2 This shows another flowchart of a method for correcting SOH provided by an embodiment of the present invention. Figure 2 The method shown is applicable to vehicles, and the method includes:

[0128] Step S201: Receive the encrypted SOH correction value sent by the cloud. The encrypted SOH correction value is sent by the cloud when the first vehicle condition is met.

[0129] It should be noted that the first vehicle condition is used to indicate that the vehicle is in a state where it can receive remote update commands.

[0130] In the specific implementation step S201, the vehicle's TBOX receives the encrypted SOH correction value sent from the cloud. The process of sending the encrypted SOH correction value from the cloud has been described in the above embodiments of the present invention. Figure 1 For a detailed explanation, please refer to [the relevant documentation], which will not be repeated here.

[0131] Step S202: Decrypt the encrypted SOH correction value to obtain the SOH correction value.

[0132] In the specific implementation step S202, the vehicle's TBOX uses a key to decrypt the encrypted SOH correction value, thereby obtaining the SOH correction value.

[0133] In practical applications, the vehicle's TBOX receives update data packets sent from the cloud (containing ciphertext, VIN, and distribution time; the ciphertext contains the SOH correction value and SOH update instruction). The TBOX decrypts the ciphertext using the AES128 algorithm decryption key to read the SOH correction value and SOH update instruction.

[0134] It should be noted that the encrypted text contains: the identifier of the SOH update command, the SOH correction value, the command sequence number of the SOH update command, and the valid timestamp.

[0135] In some embodiments, after obtaining the update data packet and completing decryption, the vehicle's TBOX needs to compare the integrity and consistency of specified fields item by item to ensure the accuracy of the acquired data.

[0136] The specific comparison method is as follows: determine whether the VIN in the update data packet is consistent with the VIN stored locally; determine whether the issuance time in the update data packet is within the valid time window; and determine whether the command sequence number of the SOH update instruction is monotonically increasing and greater than the command sequence number of the previously received SOH update instruction.

[0137] The logic for determining whether the delivery time is within the valid time window is as follows: TBOX obtains the current time, calculates the time difference between the current time and the delivery time, and if this time difference is less than the preset valid time window (e.g., 24 hours or 48 hours), the delivery time is considered valid; otherwise, it is considered invalid due to timeout. Setting a valid time window prevents vehicles from receiving expired update commands after prolonged offline periods and mistakenly executing them. If the VIN is inconsistent, it indicates that the data packet was not sent to this vehicle and should be discarded; if the command sequence number is not greater than the previous value, it indicates that the command may be a replay attack and should be discarded.

[0138] Step S203: Identify whether the vehicle meets the second vehicle condition conditions.

[0139] It should be noted that the second vehicle condition indicates that the vehicle is in a state where the SOH parameter writing operation can be performed. The second vehicle condition is a comprehensive judgment of whether the vehicle meets the safety prerequisites required to perform the SOH correction value writing operation. Unlike the first vehicle condition, the second vehicle condition is judged locally by the TBOX on the vehicle, rather than by the cloud. This dual verification mechanism of "cloud pre-judgment + vehicle-side final judgment" can minimize the risk of erroneous data transmission due to delayed or inaccurate cloud-based judgment.

[0140] In the specific implementation step S203, the vehicle's TBOX collects the vehicle's second specified information, which includes at least one of the following: power battery charge, fault code, vehicle speed, and charging status.

[0141] The system determines whether the vehicle simultaneously meets multiple second preset conditions for determining whether SOH parameter writing is allowed; if the vehicle simultaneously meets multiple second preset conditions, the system determines that the vehicle meets the second vehicle condition conditions.

[0142] For example, set the following four second preset conditions:

[0143] Second preset condition 1: Sufficient power battery: This condition ensures that the power battery has enough energy to support the BMS in completing the parameter writing operation when performing SOH correction operation, and avoids writing interruption or data corruption due to power depletion during the writing process;

[0144] Second preset condition 2, BMS is fault-free: This condition ensures that the BMS is in normal working condition and can reliably receive CAN messages, perform parameter verification and complete parameter writing operations.

[0145] Second preset condition 3, vehicle speed is zero: This condition ensures that the vehicle is stationary, avoiding the inability to process SOH update commands in time due to high CAN bus load or real-time requirements of BMS control strategy during driving.

[0146] Second preset condition 4, vehicle not charging: This condition ensures that the vehicle is not connected to an external charging device, avoiding conflicts between the BMS and the SOH update operation due to the interaction logic with the charger during the charging process.

[0147] When all four of the aforementioned second preset conditions are met simultaneously, it can be determined that the vehicle meets the second vehicle condition conditions.

[0148] Step S204: If the vehicle meets the second vehicle condition, perform SOH correction based on the SOH correction value.

[0149] In the specific implementation of step S204, if the vehicle meets the second vehicle condition, the vehicle's TBOX encapsulates the SOH correction value into a CAN message and sends the CAN message to the vehicle's BMS via the CAN bus. The CAN message contains the SOH correction value, a message counter, and a checksum. The message counter and checksum can be used to prevent false wake-up and false command execution.

[0150] It should be noted that CAN messages are data frames transmitted on the CAN bus, and their structure conforms to the CAN protocol specification. The CAN bus uses CSMA / CD (Carrier Sense Multiple Access / Collision Detection) mechanism for bus arbitration, which ensures that high-priority messages are sent first when multiple nodes transmit data simultaneously. In this embodiment of the invention, the CAN message of the SOH update command is assigned a higher priority (i.e., a smaller frame ID value) to ensure that the command can be received and processed by the BMS in a timely manner.

[0151] The structure of a CAN message includes: a frame ID (used to identify the SOH update command), a message counter (specifically a monotonically increasing sequence number), a data field (containing the SOH correction value and the command identifier of the SOH update command), and a CRC checksum.

[0152] It should be noted that the frame ID is an identifier for the CAN message, used to distinguish different types of CAN messages. In this embodiment of the invention, a unique frame ID value is assigned to the SOH update command. The BMS identifies the message type based on the frame ID and triggers the corresponding processing logic. The message counter is a monotonically increasing sequence number used to prevent replay attacks and duplicate command execution. The data field stores the SOH correction value and command identifier, where the command identifier is used to distinguish different types of remote commands (e.g., SOH update commands, parameter query commands, firmware upgrade commands, etc.). The CRC checksum is used for data integrity verification. After receiving the CAN message, the BMS recalculates the CRC checksum and compares it with the CRC value in the message. If they do not match, it indicates that the message may have been corrupted or tampered with during transmission.

[0153] In some embodiments, the vehicle's BMS needs to perform a verification process on the CAN messages. Specifically, this involves verifying the continuity and timing validity of the message counter, verifying the correctness of the CRC checksum, and verifying whether the frame ID falls within the scope of the authorized SOH update instruction.

[0154] If the message counter is continuous and timing-valid, the CRC checksum is correct, and the frame ID falls within the scope of the authorized SOH update instruction, the CAN message is determined to have passed the verification process. Otherwise, the CAN message is determined to have failed the verification process (i.e., verification failed), the CAN message is discarded, and an in-vehicle network security alarm is triggered.

[0155] In-vehicle cybersecurity alarms can include: recording alarm logs to the BMS's non-volatile memory for later reading and analysis using diagnostic tools; sending safety alarm messages to the vehicle controller via the CAN bus to trigger the safety warning lights on the dashboard; and reporting safety alarm events to the cloud via the TBOX so that cloud maintenance personnel can understand potential security threats.

[0156] After the CAN message passes the verification process, the vehicle's BMS performs a validity check on the SOH correction value. Specifically, the validity check includes at least the following verification methods:

[0157] The first verification method: determine whether the SOH correction value is within the preset correctable range;

[0158] The second verification method is to determine whether the difference between the corrected SOH value and the original SOH value of the power battery exceeds the preset limit.

[0159] The third verification method: Based on the cumulative charge-discharge cycle count and internal resistance change of the vehicle's battery, the theoretical reasonable range is calculated in reverse; and it is determined whether the SOH correction value is within the reasonable range.

[0160] It should be noted that the "preset limit range" in the second verification method mentioned above can be dynamically adjusted according to the range in which the vehicle's current SOH value is located; when the SOH value is in a lower range, the "preset limit range" will be narrowed accordingly.

[0161] The above-mentioned verification methods can be used to verify the reasonableness of the SOH correction value. After verification by the adopted verification method, it can be determined that the SOH correction value passes the reasonableness verification.

[0162] For example, when using the first and second verification methods, if the SOH correction value is within the preset correctable range and the difference between the SOH correction value and the original SOH value of the power battery does not exceed the preset limit, the SOH correction value can be determined to pass the rationality verification.

[0163] For example, when using the first, second, and third verification methods, if the SOH correction value is within the preset correctable range, and the difference between the SOH correction value and the original SOH value of the power battery does not exceed the preset limit, and the SOH correction value is within a reasonable range, then the SOH correction value can be determined to have passed the reasonableness verification.

[0164] If the SOH correction value passes the rationality check, the vehicle's BMS will perform SOH correction and update the vehicle's SOH parameters to the SOH correction value.

[0165] In some embodiments, after the BMS completes the SOH correction, it stores the SOH value before the update, the SOH value after the update, the update time, and the generated status code in the memory to form an update log.

[0166] In some embodiments, when performing SOH correction, the vehicle's BMS generates a corresponding status code based on the execution status. The status code represents the execution result of the SOH correction, and the generated status code is fed back to the cloud through the TBOX.

[0167] In some embodiments, after the vehicle's TBOX receives a wake-up message from the cloud and replies with a ready signal, if the vehicle does not meet the second vehicle condition, the TBOX sends a "Not allowed" status code to the cloud, and the cloud will retry sending the update data packet after a preset cooldown time.

[0168] In some embodiments, during the execution of step S204, the vehicle's TBOX and BMS continuously monitor changes in the vehicle's status. When any of the following signals are detected: vehicle power-on signal, charging gun insertion signal, or vehicle speed change signal, interrupt protection is immediately triggered. The BMS immediately stops the SOH update operation, does not retain any written data, generates a "Process Interrupt" status code and sends it back to the cloud, keeping the original parameters unchanged before the SOH update.

[0169] The above embodiments of the present invention Figure 2 This is a description of the SOH correction for the vehicle side.

[0170] To better understand the overall implementation process of this solution, the embodiments of the present invention will be used. Figure 3 The diagram illustrating the interaction between the cloud and the vehicle serves as an example. Figure 3 Includes the following steps:

[0171] Step S301: Collect the first specified information of the vehicle in the cloud.

[0172] Step S302: The cloud determines whether the vehicle is in a dormant state. If it is, proceed to step S303; otherwise, do not issue the SOH correction value.

[0173] Step S303: The cloud determines whether the vehicle simultaneously meets multiple first preset conditions. If it does, proceed to step S304; if it does not, the SOH correction value is not issued temporarily.

[0174] Step S304: Package the update data package in the cloud, wake up the TBOX, and send the update data package to the TBOX.

[0175] Step S305: Determine whether the TBOX has fed back a ready signal on time. If not, abandon the transmission of update data packets and record the timeout status; if yes, proceed to step S306.

[0176] Step S306: TBOX decrypts the update data packet.

[0177] Step S307: TBOX compares the integrity and consistency of the specified fields. Determine if the comparison of the specified fields passes. If it passes, proceed to step S308. If it fails, discard the update data packet and return an error status.

[0178] Step S308: The TBOX identifies whether the vehicle meets the second vehicle condition condition. If not, it sends back information indicating that the second vehicle condition condition is not met. If it does meet the condition, it proceeds to step S309.

[0179] Step S309: TBOX encapsulates the SOH correction value into a CAN message and sends the CAN message to the vehicle's BMS via the CAN bus.

[0180] Step S310: The BMS performs a verification process on the CAN message. It determines whether the CAN message passes the verification process. If it fails, the CAN message is discarded, and a security alarm is triggered. If it passes, proceed to step S311.

[0181] Step S311: The BMS performs a reasonableness check on the SOH correction value. It determines whether the SOH correction value passes the reasonableness check. If it fails, it generates and returns the status code "Parameter Over Range". If it passes, proceed to step S312.

[0182] Step S312: Determine whether the vehicle is powered on, charged, or its speed changes during the SOH update process. If so, stop the SOH update, generate and return the "Interrupted" status code. If not, proceed to step S313.

[0183] Step S313: BMS generates a status code for the execution result of SOH correction.

[0184] Step S314: TBOX sends the status code generated in step S313 back to the cloud.

[0185] Step S315: Record the execution results in the cloud and read the latest SOH value.

[0186] Step S316: Determine if the latest SOH value is equal to the SOH correction value. If yes, record a success result. If no, record the reason for failure and execute the processing strategy corresponding to the status code.

[0187] It should be noted that, Figure 3 The execution principle of each step has been explained in the above embodiments of the present invention. Figure 1 and Figure 2 Detailed explanations have been provided and can be found here; they will not be repeated here.

[0188] As can be seen from the above embodiments, this solution achieves full-link secure and reliable closed-loop control for remote SOH updates through cloud vehicle dual condition verification, end-to-end encrypted transmission, CAN message security design, and hierarchical status code feedback mechanism. This effectively prevents false wake-ups, data tampering, and abnormal writing, and improves the accuracy and robustness of remote battery status maintenance.

[0189] Corresponding to the method for correcting SOH provided in the above embodiments of the present invention, see also... Figure 4 The present invention also provides a structural block diagram of an apparatus for correcting SOH. Figure 4 The device shown is suitable for cloud computing and includes a first identification unit 401 and a transmission unit 402.

[0190] The first identification unit 401 is used to identify whether the vehicle meets the first vehicle condition condition, which indicates that the vehicle is in a state where it can receive remote update commands.

[0191] In some embodiments, the first identification unit 401 is specifically used to: collect first specified information of the vehicle, the first specified information including at least one of vehicle speed, charging status, current, battery data and fault code; determine whether the vehicle is in a dormant state based on the first specified information; if the vehicle is in a dormant state, determine whether the vehicle simultaneously meets multiple first preset conditions for determining whether the SOH correction value can be issued; if the vehicle simultaneously meets multiple first preset conditions, determine that the vehicle meets the first vehicle condition conditions.

[0192] The sending unit 402 is used to send the encrypted SOH correction value to the vehicle if the vehicle meets the first vehicle condition condition, so that the vehicle can perform SOH correction based on the SOH correction value if the second vehicle condition condition is met.

[0193] In some embodiments, the sending unit 402 is specifically used to: if the vehicle meets the first vehicle condition, perform two-way identity authentication with the vehicle and establish a secure communication channel; send the encrypted SOH correction value to the vehicle through the secure communication channel, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition is met, the second vehicle condition being used to indicate that the vehicle is in a state where the SOH parameter writing operation can be performed.

[0194] Preferred, combined Figure 4 The device, as shown, also includes:

[0195] The processing unit is used to receive the status code fed back by the vehicle, which represents the execution result of the SOH correction; and to execute the processing strategy corresponding to the status code.

[0196] Preferably, the processing unit is further configured to: optimize and adjust the thresholds used to determine whether the power battery has sufficient power and the storage battery has sufficient power in the first preset conditions based on the statistical distribution of the status codes.

[0197] Preferred, combined Figure 4As shown, the sending unit 402 is also used to: send a wake-up message to the vehicle and start a waiting timer; if no ready signal is received from the vehicle within a preset time, abandon the current transmission of the encrypted SOH correction value and record the timeout status; if a ready signal is received from the vehicle within a preset time, perform the step of sending the encrypted SOH correction value to the vehicle.

[0198] Corresponding to the method for correcting SOH provided in the above embodiments of the present invention, see also... Figure 5 The present invention also provides another structural block diagram of an apparatus for correcting SOH. Figure 5 The device shown is applicable to vehicles and includes: a receiving unit 501, a decryption unit 502, a second identification unit 503, and an execution unit 504;

[0199] The receiving unit 501 is used to receive the encrypted SOH correction value sent by the cloud. The encrypted SOH correction value is sent by the cloud when the first vehicle condition is met. The first vehicle condition is used to indicate that the vehicle is in a state where it can receive remote update commands.

[0200] The decryption unit 502 is used to decrypt the encrypted SOH correction value to obtain the SOH correction value.

[0201] The second identification unit 503 is used to identify whether the vehicle meets the second vehicle condition, which indicates that the vehicle is in a state where the SOH parameter writing operation can be performed.

[0202] In some embodiments, the second identification unit 503 is specifically used to: collect second specified information of the vehicle, the second specified information including at least one of power battery charge, fault code, vehicle speed and charging status; determine whether the vehicle simultaneously meets multiple second preset conditions for determining whether SOH parameter writing is allowed; if the vehicle simultaneously meets multiple second preset conditions, determine that the vehicle meets the second vehicle condition conditions.

[0203] The execution unit 504 is used to perform SOH correction based on the SOH correction value if the vehicle meets the second vehicle condition.

[0204] In some embodiments, the execution unit 504 is specifically used to: if the vehicle meets the second vehicle condition, perform a reasonableness check on the SOH correction value; if the SOH correction value passes the reasonableness check, update the vehicle's SOH parameters to the SOH correction value.

[0205] Preferably, the present invention also provides an electronic device, including: a processor and a memory, the processor and the memory being connected via a bus; wherein, the processor is used to call and execute a program stored in the memory; the memory is used to store the program, the program being used to implement the method for correcting SOH provided in the above method embodiments.

[0206] In summary, the embodiments of the present invention provide a method and electronic device for correcting SOH. Before sending the SOH correction value, the cloud identifies the vehicle's condition. When the vehicle is determined to be under the first condition, the SOH correction value is sent to the vehicle in an encrypted manner. When the vehicle is under the second condition, SOH correction is performed based on the SOH correction value. This avoids invalid sending of the SOH correction value, ensures stable vehicle-cloud interaction, and avoids erroneous vehicle-cloud interaction.

[0207] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0208] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0209] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for correcting SOH, characterized in that, The method is applicable to the cloud and includes: The system identifies whether the vehicle meets a first vehicle condition, which indicates that the vehicle is in a state where it can receive remote update commands. If the vehicle meets the first vehicle condition, the encrypted SOH correction value is sent to the vehicle, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition is met. The second vehicle condition is used to indicate that the vehicle is in a state where the SOH parameter write operation can be performed.

2. The method according to claim 1, characterized in that, Identify whether the vehicle meets the first vehicle condition conditions, including: Collect first specified information about the vehicle, which includes at least one of vehicle speed, charging status, current, battery data, and fault codes; The vehicle is determined to be in a dormant state based on the first specified information. If the vehicle is in a dormant state, determine whether the vehicle simultaneously meets multiple first preset conditions used to determine whether the SOH correction value can be issued. If the vehicle simultaneously meets multiple of the first preset conditions, it is determined that the vehicle meets the first vehicle condition conditions.

3. The method according to claim 1, characterized in that, If the vehicle meets the first vehicle condition condition, the encrypted SOH correction value is sent to the vehicle, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition condition is met, including: If the vehicle meets the first vehicle condition, perform two-way identity authentication with the vehicle and establish a secure communication channel; The encrypted SOH correction value is sent to the vehicle through the secure communication channel, so that the vehicle performs SOH correction based on the SOH correction value when the second vehicle condition is met.

4. The method according to claim 1, characterized in that, After sending the encrypted SOH correction value to the vehicle, the process also includes: Receive the status code fed back by the vehicle, the status code representing the execution result of the SOH correction; Execute the processing strategy corresponding to the status code.

5. The method according to claim 4, characterized in that, After receiving the status code from the vehicle, the system also includes: Based on the statistical distribution of the status codes, the thresholds used to determine whether the power battery has sufficient power and the storage battery has sufficient power in the first preset conditions are optimized and adjusted.

6. The method according to claim 1, characterized in that, Before sending the encrypted SOH correction value to the vehicle, the process also includes: Send a wake-up message to the vehicle and start a waiting timer; If no ready signal is received from the vehicle within the preset time, the encrypted SOH correction value will be abandoned and the timeout status will be recorded. If a ready signal is received from the vehicle within the preset time, the step of sending the encrypted SOH correction value to the vehicle is executed.

7. A method for correcting SOH, characterized in that, The method is applicable to vehicles, and the method includes: The vehicle receives an encrypted SOH correction value sent from the cloud. The encrypted SOH correction value is sent by the cloud when a first vehicle condition is met. The first vehicle condition is used to indicate that the vehicle is in a state where it can receive remote update commands. Decrypt the encrypted SOH correction value to obtain the SOH correction value; The system identifies whether the vehicle meets the second vehicle condition, which indicates that the vehicle is in a state where the SOH parameter write operation can be performed. If the vehicle meets the second vehicle condition, SOH correction is performed based on the SOH correction value.

8. The method according to claim 7, characterized in that, Identifying whether the vehicle meets the second vehicle condition includes: Collect second specified information of the vehicle, the second specified information including at least one of power battery charge, fault code, vehicle speed and charging status; The second specified information is used to determine whether the vehicle simultaneously meets multiple second preset conditions used to determine whether SOH parameter writing is allowed. If the vehicle simultaneously meets multiple of the second preset conditions, it is determined that the vehicle meets the second vehicle condition conditions.

9. The method according to claim 7, characterized in that, If the vehicle meets the second vehicle condition condition, SOH correction is performed based on the SOH correction value, including: If the vehicle meets the second vehicle condition, the reasonableness of the SOH correction value is verified. If the SOH correction value passes the rationality check, the SOH parameter of the vehicle is updated to the SOH correction value.

10. An electronic device, characterized in that, include: A processor and a memory are connected via a bus; wherein the processor is used to call and execute a program stored in the memory; The memory is used to store a program for implementing the method for correcting SOH as described in any one of claims 1-6, or the program is used to implement the method for correcting SOH as described in any one of claims 7-9.

Images