Vehicle control method and device

Abstract

This application provides a vehicle control method and apparatus, belonging to the field of vehicle technology. The vehicle control method, in response to vehicle startup, acquires the vehicle's motor configuration information, which indicates the number of drive motors in the vehicle. If the vehicle's motor configuration information does not match the number of drive motors adapted to the pre-programmed software, the method controls the vehicle to prevent it from driving based on that pre-programmed software. By checking whether the pre-programmed software matches the vehicle's drive motor configuration after vehicle startup, and prohibiting driving based on that software when the software and vehicle hardware are incompatible, this method avoids the vehicle from driving based on incompatible software, thereby preventing abnormalities in the vehicle's powertrain and ensuring driving safety.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle control method and device. Background Technology

[0002] The drive motor of a hybrid electric vehicle is controlled by software, which is flashed into the vehicle by the manufacturer before it leaves the factory and can also be updated through a flashing operation after the vehicle leaves the factory.

[0003] Currently, when flashing software into a vehicle, the vehicle software management platform first determines the software that matches the vehicle's drive motor configuration based on the vehicle's motor configuration information, and then flashes the software into the vehicle through diagnostic equipment. The vehicle's control unit then controls the vehicle to drive based on the flashed software.

[0004] However, in the after-sales maintenance of hybrid vehicles, the software flashed in the vehicle depends on the operation of the maintenance personnel. Therefore, there is a possibility that the vehicle's hardware and software may become incompatible due to the maintenance personnel's mistakes. Controlling the vehicle based on incompatible software will affect the safety of driving the vehicle. Summary of the Invention

[0005] This application provides a vehicle control method and apparatus to improve vehicle driving safety. The technical solution is as follows: Firstly, a vehicle control method is provided, the method comprising: In response to vehicle startup, obtain the vehicle's motor configuration information, which indicates the number of drive motors in the vehicle; If the vehicle's motor configuration information does not match the number of drive motors that have been flashed with compatible software, the vehicle will be prevented from being driven based on the flashed software.

[0006] In some embodiments, obtaining the vehicle's motor configuration information includes: Read the vehicle identification number (VIN) from the vehicle's body control unit; The vehicle's VIN code is parsed to obtain the vehicle's motor configuration information.

[0007] In some embodiments, the above method further includes: Read the software configuration identifier of the software already flashed in the vehicle, and parse the number of drive motors that the software already flashed in the vehicle is compatible with from the software configuration identifier.

[0008] In some embodiments, obtaining the vehicle's motor configuration information includes: Multiple detection frames are sent to detect the presence of drive motors in the vehicle. Based on the received response information for multiple probe frames, the vehicle's motor configuration information is generated.

[0009] In some embodiments, each of the above-mentioned detection frames includes a detection address segment of the drive motor controller corresponding to the detection frame, and the detection address segment is different from the torque control address segment of the corresponding drive motor controller.

[0010] In some embodiments, the above-mentioned control of the vehicle to prevent driving based on flashed software includes: Send a power-off command to the vehicle's battery management system. The power-off command is used to control the vehicle to prevent it from receiving power.

[0011] In some embodiments, the above-mentioned control of the vehicle to prevent driving based on flashed software includes: A torque disable broadcast frame is sent to the vehicle's drive motor controller. The torque disable broadcast frame is used to prevent the vehicle's drive motor controller from sending torque commands to the drive motor.

[0012] In some embodiments, the above method further includes: If the vehicle's motor configuration information does not match the number of drive motors that have been flashed with compatible software, a first fault signal is sent to the vehicle's instrument controller. The first fault signal is used to make the vehicle's instrument panel display a first fault message, which indicates that the flashed software in the vehicle is incompatible with the vehicle.

[0013] In some embodiments, the above method further includes: Obtain the motor configuration information of the software to be flashed. The motor configuration information of the software to be flashed indicates the number of drive motors that are compatible with the software to be flashed. If the motor configuration information of the software to be flashed does not match the motor configuration information of the vehicle, stop flashing the software to the vehicle.

[0014] In some embodiments, obtaining the motor configuration information of the software to be flashed includes: Receive a software flashing request from the diagnostic device. The software flashing request carries the storage address of the motor configuration information of the software to be flashed in the diagnostic device. Based on the software flashing request, a configuration information read request is sent to the diagnostic device. The configuration information read request is used to read the motor configuration information of the software to be flashed. Receive motor configuration information for the software to be flashed, returned by the diagnostic device in response to the configuration information read request.

[0015] In some embodiments, the above method further includes: If the motor configuration information of the software to be flashed does not match the motor configuration information of the vehicle, a second fault signal is sent to the vehicle's instrument controller. The second fault signal is used to make the vehicle's instrument panel display a second fault message, indicating that the software to be flashed is incompatible with the vehicle.

[0016] Secondly, a vehicle control device is provided, the device comprising: A configuration information acquisition module is used to acquire the motor configuration information of the vehicle in response to vehicle startup, wherein the motor configuration information indicates the number of drive motors in the vehicle; The control module is used to control the vehicle to prevent it from being driven based on the flashed software if the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software in the vehicle.

[0017] In some embodiments, the configuration information acquisition module described above is used for: Read the vehicle identification number (VIN) from the vehicle's body control unit; The vehicle's VIN code is parsed to obtain the vehicle's motor configuration information.

[0018] In some embodiments, the above-described apparatus further includes: The configuration identifier reading module is used to read the software configuration identifier of the software that has been flashed in the vehicle, and to parse the number of drive motors that have been flashed and are compatible with the software in the vehicle from the software configuration identifier.

[0019] In some embodiments, the configuration information acquisition module described above is used for: Multiple detection frames are sent to detect the presence of drive motors in the vehicle. Based on the received response information for multiple probe frames, the vehicle's motor configuration information is generated.

[0020] In some embodiments, each of the above-mentioned detection frames includes a detection address segment of the drive motor controller corresponding to the detection frame, and the detection address segment is different from the torque control address segment of the corresponding drive motor controller.

[0021] In some embodiments, the control module described above is configured to: Send a power-off command to the vehicle's battery management system. The power-off command is used to control the vehicle to prevent it from receiving power.

[0022] In some embodiments, the control module described above is configured to: A torque disable broadcast frame is sent to the vehicle's drive motor controller. The torque disable broadcast frame is used to prevent the vehicle's drive motor controller from sending torque commands to the drive motor.

[0023] In some embodiments, the above-described apparatus further includes: The first prompt module is used to send a first fault signal to the vehicle's instrument controller if the vehicle's motor configuration information does not match the number of drive motors that have been flashed and adapted to the vehicle's software. The first fault signal is used to make the vehicle's instrument panel display first fault information, which indicates that the flashed software in the vehicle is incompatible with the vehicle.

[0024] In some embodiments, the above-described apparatus further includes: The software configuration acquisition module is used to acquire the motor configuration information of the software to be flashed. The motor configuration information of the software to be flashed indicates the number of drive motors that are compatible with the software to be flashed. The comparison module is used to stop flashing the software into the vehicle if the motor configuration information of the software to be flashed does not match the motor configuration information of the vehicle.

[0025] In some embodiments, the software configuration acquisition module described above is used for: Receive a software flashing request from the diagnostic device. The software flashing request carries the storage address of the motor configuration information of the software to be flashed in the diagnostic device. Based on the software flashing request, a configuration information read request is sent to the diagnostic device. The configuration information read request is used to read the motor configuration information of the software to be flashed. Receive motor configuration information for the software to be flashed, returned by the diagnostic device in response to the configuration information read request.

[0026] In some embodiments, the above-described apparatus further includes: The second prompt module is used to send a second fault signal to the vehicle's instrument controller if the motor configuration information of the software to be flashed does not match the vehicle's motor configuration information. The second fault signal is used to make the vehicle's instrument panel display a second fault message, indicating that the software to be flashed is incompatible with the vehicle.

[0027] Thirdly, a vehicle is provided for performing operations performed by the vehicle control method provided in the first aspect or various alternative implementations of the first aspect.

[0028] Fourthly, an electronic device is provided, comprising a processor and a memory, the memory for storing at least one computer program, the at least one computer program being loaded and executed by the processor to perform the operations performed by the vehicle control method provided in the first aspect or various alternative implementations of the first aspect.

[0029] Fifthly, a computer-readable storage medium is provided, wherein at least one computer program is stored therein, the at least one computer program being used to perform operations to implement the vehicle control method provided in the first aspect or various alternative implementations of the first aspect.

[0030] In a sixth aspect, a computer program product or computer program is provided that, when executed by a vehicle, performs the operations of the vehicle control method provided in the first aspect or various alternative implementations of the first aspect.

[0031] The vehicle control method provided in this application, in response to vehicle startup, acquires the vehicle's motor configuration information, which indicates the number of drive motors in the vehicle. If the vehicle's motor configuration information does not match the number of drive motors adapted to the pre-programmed software, the method controls the vehicle to prevent it from driving based on that pre-programmed software. This method, by checking whether the pre-programmed software matches the vehicle's drive motor configuration after vehicle startup, and prohibiting driving based on that software when the software and vehicle hardware are incompatible, can prevent the vehicle from driving based on incompatible software, thereby avoiding abnormalities in the vehicle's powertrain and ensuring driving safety.

[0032] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a vehicle control system provided in an embodiment of this application; Figure 3 This is a flowchart of a vehicle control method provided in an embodiment of this application; Figure 4 This is a flowchart of another vehicle control method provided in an embodiment of this application; Figure 5 This is a flowchart of another vehicle control method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a hardware configuration identifier provided in an embodiment of this application; Figure 7 This is a data interaction diagram for comparison and verification based on dynamic topology detection provided in an embodiment of this application; Figure 8 This is a structural block diagram of a vehicle control device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0036] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0037] In this application, the term "at least one" means one or more, and "multiple" means two or more.

[0038] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the topology and driver configuration information involved in this application were obtained with full authorization.

[0039] As the global automotive industry transitions to electrification, hybrid vehicles have garnered widespread attention due to their dual advantages of pure electric and gasoline-powered driving. However, two easily overlooked but serious safety risks exist in the aftermarket maintenance of hybrid vehicles: The first risk arises when technicians use diagnostic equipment to rewrite the software of the vehicle's Hybrid Control Unit (HCU) (also known as the vehicle controller, vehicle control module, hybrid power control unit, etc.), mistakenly flashing HCU software intended for two-wheel drive models onto the HCU hardware of four-wheel drive models. Since the HCU software for two-wheel drive models does not include the control logic for the rear axle drive motor, when a four-wheel drive vehicle is powered on, the rear axle drive motor controller may receive and incorrectly interpret the default signals on the CAN bus. This can cause the rear axle drive motor to output maximum torque incorrectly. If the vehicle is in Park (P) mode, this can cause the drive wheels to rub against the ground and emit smoke; if the vehicle is not in Park mode, it may cause a rollover accident, creating a safety hazard. The second type of risk is that repair personnel mistakenly install HCU hardware (with HCU software already flashed for two-wheel drive models) intended for two-wheel drive vehicles onto vehicles with four-wheel drive systems. This can also incorrectly trigger abnormal output from the vehicle's rear axle drive motor, causing the aforementioned safety hazard. Both of these safety risks stem from hardware and software incompatibility after repair, leading to vehicle control errors and consequently affecting driving safety.

[0040] To address this issue, this application provides a vehicle control method to resolve the problem of abnormal vehicle powertrain systems caused by software flashing errors or incorrect hardware installation. The vehicle control method provided in this application, in response to vehicle startup, acquires the vehicle's motor configuration information, which indicates the number of drive motors in the vehicle. If the vehicle's motor configuration information does not match the number of drive motors compatible with the flashed software, the method controls the vehicle to prevent it from operating based on that flashed software. By verifying whether the flashed software matches the vehicle's drive motor configuration after vehicle startup, and prohibiting operation based on the software when there is a software-hardware mismatch, this method prevents the vehicle from operating based on incompatible software, thereby avoiding abnormalities in the vehicle powertrain system and ensuring vehicle driving safety.

[0041] The implementation environment of the vehicle control method provided in the embodiments of this application will be described below.

[0042] Figure 1 This is a structural schematic diagram of a vehicle according to an embodiment of this application. Figure 1The vehicle 100 shown is a hybrid vehicle, and the type of vehicle 100 includes, but is not limited to, plug-in hybrid electric vehicles (PHEVs), parallel hybrid vehicles, and series hybrid vehicles. Figure 1 As shown, the vehicle 100 includes a vehicle control module 101, a motor control module 102, a body control module 103, and a bus 104. The vehicle control module 101, the motor control module 102, and the body control module 103 are connected to each other via the bus 104.

[0043] The Hybrid Control Unit (HCU) 101, the vehicle's control unit, is the core control unit of the vehicle. The HCU 101 includes a processor and memory. The processor runs the software already programmed into the HCU 101 and, based on the results, issues control commands to other modules in the vehicle via the bus 104, such as issuing drive motor control commands to the motor control module 102. The memory of the HCU 101 includes a Bootloader area and an application layer area. The Bootloader area, physically read-only, stores the hardware configuration identifier of the HCU 101, indicating the number of drive motors adapted to the HCU 101. The application layer area stores the software configuration identifier of the HCU 101, indicating the number of drive motors adapted to the software already programmed into the HCU 101. The application layer area also stores expected motor configuration information, indicating the number of drive motors adapted to the software already programmed into the HCU 101.

[0044] The motor control module 102 is used to control the drive motor to output corresponding torque based on the control commands issued by the vehicle control module 101. When the vehicle 100 includes a front axle drive motor, the motor control module 102 includes a front axle motor controller; when the vehicle 100 includes a rear axle drive motor, the motor control module 102 includes a rear axle motor controller; and when the vehicle 100 includes both a front axle drive motor and a rear axle drive motor, the motor control module 102 includes both a front axle motor controller and a rear axle motor controller.

[0045] The Body Control Module (BCM) 103 stores the vehicle's VIN (Vehicle Identification Number) and configuration information, such as the vehicle type (gasoline or electric) and body configuration information. The information stored in the Body Control Module 103 can serve as a reference for the actual vehicle configuration.

[0046] Bus 104 can be a CAN (Controller Area Network) bus, used to connect various modules in vehicle 100 and transmit instructions and information between the modules.

[0047] In some embodiments, the vehicle 100 further includes an instrument control module, which is connected to the vehicle control module 101 via a bus 104 and is used to receive and display fault information sent by the vehicle control module 101, the fault information indicating that the vehicle's hardware and software are incompatible.

[0048] Based on the above Figure 1 The vehicle shown, Figure 2 This is a schematic diagram of the structure of a vehicle control system provided in an embodiment of this application, such as... Figure 2 As shown, the vehicle control system includes, Figure 1 The diagram shows a vehicle 201 and a diagnostic device 202. The diagnostic device 202 connects to the vehicle via an OBD (On-Board Diagnostics) interface. During software flashing, the diagnostic device 202 sends a software flashing request to the vehicle 201, requesting the flashing of software into the vehicle's control module (VMM) so that the VMM can control the vehicle's drive motors based on this software. The software flashing request conforms to the UDS (Unified Diagnostic Services) protocol. The request carries an identifier for the software to be flashed, indicating the software to be flashed, and also carries the storage address of the software to be flashed in the diagnostic device 202, so that the vehicle can retrieve the software from the diagnostic device and flash it based on this storage address.

[0049] It should be noted that the above description is based on the example of the connection between vehicle 201 and diagnostic equipment 202 via OBD interface. In some embodiments, vehicle 201 and diagnostic equipment 202 are connected via wireless network, and this application embodiment does not limit this.

[0050] Figure 3 This is a flowchart of a vehicle control method provided in an embodiment of this application, such as... Figure 3 As shown, taking the vehicle's control unit executing this method as an example, the method includes the following steps: 301. In response to vehicle startup, the vehicle's control unit acquires the vehicle's motor configuration information, which indicates the number of drive motors in the vehicle.

[0051] The vehicle's motor configuration information can be pre-written into the vehicle or obtained from real-time detection of the presence of drive motors. This information records which drive motors are configured in the vehicle, thus reflecting the number of drive motors in the vehicle. For example, a two-wheel-drive vehicle typically has only one drive motor, installed in either the front or rear drive. Accordingly, the motor configuration information for a two-wheel-drive vehicle records either a front axle drive motor or a rear axle drive motor, indicating a total of one drive motor. A four-wheel-drive vehicle typically has two or more drive motors. Taking a four-wheel-drive vehicle with two drive motors as an example, one motor is installed in the front drive and the other in the rear drive. Accordingly, the motor configuration information for a four-wheel-drive vehicle records both a front axle drive motor and a rear axle drive motor, indicating a total of two drive motors.

[0052] In this embodiment of the application, the vehicle control unit responds to the vehicle starting and completes initialization by obtaining the vehicle's motor configuration information in at least one of the following ways: reading the vehicle's motor configuration information from the local machine; detecting the drive motor in the vehicle and generating the vehicle's motor configuration information based on the detection results. Of course, the control unit can also obtain the motor configuration information in other ways, and this embodiment of the application does not limit this.

[0053] 302. If the vehicle's motor configuration information does not match the number of drive motors that have been flashed with compatible software, control the vehicle to prevent it from being driven based on the flashed software.

[0054] The pre-programmed software in a vehicle is either flashed by the manufacturer before the vehicle leaves the factory, or updated after the vehicle leaves the factory via a flashing process. Different software programs are compatible with a specific number of drive motors. For example, two-wheel drive software focuses on efficient output and basic safety from a single power source, and is compatible with one drive motor in two-wheel drive vehicles. On the other hand, four-wheel drive software, while maintaining efficient power output and basic safety, incorporates multi-dimensional torque distribution and chassis-assisted control algorithms, and is compatible with two or more drive motors in four-wheel drive vehicles.

[0055] In this embodiment, if the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software, it indicates a hardware-software incompatibility issue. Controlling the vehicle based on this software could lead to control errors, causing abnormalities in the vehicle's powertrain and affecting driving safety. Therefore, in this situation, the vehicle's control unit prevents the vehicle from being driven based on the flashed software to avoid safety problems.

[0056] The vehicle control method provided in this application, in response to vehicle startup, acquires the vehicle's motor configuration information, which indicates the number of drive motors in the vehicle. If the vehicle's motor configuration information does not match the number of drive motors adapted to the pre-programmed software, the method controls the vehicle to prevent it from driving based on that pre-programmed software. This method, by checking whether the pre-programmed software matches the vehicle's drive motor configuration after vehicle startup, and prohibiting driving based on that software when the software and vehicle hardware are incompatible, can prevent the vehicle from driving based on incompatible software, thereby avoiding abnormalities in the vehicle's powertrain and ensuring driving safety.

[0057] The above describes the main process of the vehicle control method provided in the embodiments of this application. The vehicle control method will be described in detail below.

[0058] Figure 4 This is a flowchart of a vehicle control method provided in an embodiment of this application, such as... Figure 4 As shown, the complete hardware and software matching detection mechanism of this vehicle control method includes two parts: error prevention verification before software flashing and hardware and software matching verification after vehicle startup, realizing a dual error prevention mechanism. Specifically, the error prevention verification before software flashing involves the diagnostic equipment sending a software flashing request to the vehicle's control unit. The control unit receives the request and, based on it, requests the diagnostic equipment to read the motor configuration information of the software to be flashed. The diagnostic equipment returns this information to the control unit. The control unit compares the motor configuration information of the software to be flashed with the vehicle's motor configuration information. If the motor configuration information matches, the vehicle allows the diagnostic equipment to flash the software to the control unit. If the motor configuration information does not match, the flashing process is interrupted, and a fault code indicating the fault is displayed to the user on the instrument panel.

[0059] Among them, the motor configuration information of the software to be flashed is also known as the software configuration identifier, and the motor configuration information of the vehicle is also known as the hardware configuration identifier. Matching the motor configuration information of the software to be flashed with the motor configuration information of the vehicle means that the number of drive motors indicated by the motor configuration information of the software to be flashed is the same as the number of drive motors indicated by the motor configuration information of the vehicle.

[0060] The aforementioned pre-flash software error prevention verification verifies the compatibility between the software and the control unit before flashing the software, ensuring that the software flashed to the control unit is correct. The post-start software-hardware compatibility verification verifies the compatibility between the software to be run on the control unit and the vehicle each time the vehicle starts. After the vehicle power is switched from OFF to ON, the vehicle's control unit application layer starts. The control unit reads the vehicle's VIN code and parses it to obtain the vehicle's drive type information, including the number of drive motors in the vehicle. The control unit compares this drive type information with the number of drive motors compatible with the software to be run. If they match, the subsequent verification process proceeds; if they do not match, driving based on the software is prohibited. During the subsequent verification process, the vehicle's control unit sends probe frames to identify the actual number of drive motors in the vehicle and compares the identified number with the number of drive motors compatible with the software to be run. If they match, the vehicle is allowed to receive high voltage and drive based on the software; if they do not match, driving based on the software is prohibited, such as prohibiting high voltage power-on or torque output.

[0061] The above content briefly describes the flow of the vehicle control method provided in the embodiments of this application. The following section, in conjunction with... Figure 5 This application provides a detailed description of the vehicle control method provided in its embodiments.

[0062] like Figure 5 As shown, the vehicle control method provided in this application embodiment is applied to a vehicle control system, which includes diagnostic equipment and a vehicle. Taking a four-wheel drive vehicle as an example, the vehicle further includes a control unit, a front axle drive motor controller, a rear axle drive motor controller, and a battery management system (BMS). Taking the vehicle control method as being executed by the control unit in the vehicle as an example, the vehicle control method includes the following steps.

[0063] 501. The control unit receives a software flashing request from the diagnostic device, which carries the storage address of the software configuration identifier of the software to be flashed in the diagnostic device.

[0064] The diagnostic equipment can connect to the vehicle via a wired connection or wireless connection through the vehicle's OBD interface. A software flashing request, for example, is a UDS $34 service (request download) command. This request carries the software identifier of the software to be flashed, indicating the software to be flashed. It also carries the storage address of the software to be flashed in the diagnostic equipment, including the storage address of the software configuration identifier. The software configuration identifier of the software to be flashed is the motor configuration information of the software to be flashed.

[0065] In this embodiment, the vehicle control unit receives a software flashing request from a diagnostic device, but does not immediately perform a software erase or write operation based on the software flashing request. Instead, it performs the verification process shown in steps 502-504 below to verify whether the software to be flashed matches the control unit. If they match, the software to be flashed is then written into the control unit to avoid problems caused by software and hardware incompatibility leading to vehicle control errors.

[0066] 502. Based on the software flashing request, the control unit sends a configuration information read request to the diagnostic device. The configuration information read request is used to read the software configuration identifier of the software to be flashed.

[0067] The configuration information read request is, for example, the UDS $22 service (read data by identifier) ​​instruction. This configuration information read request carries the storage address of the software configuration identifier of the software to be flashed in the diagnostic device. The storage address of the software configuration identifier of the software to be flashed in the diagnostic device is a custom DID (Diagnostic ID) address, such as DID 0xF1A0. This application embodiment does not limit this.

[0068] In this embodiment, the control unit parses the software flashing request, obtains the storage address of the software configuration identifier of the software to be flashed in the diagnostic device from the software flashing request, generates a configuration information read request based on the storage address, and sends the configuration information read request to the diagnostic device. Optionally, the above-mentioned operation of parsing the software flashing request and sending the configuration information read request is performed by the control unit through the bootloader program running on it.

[0069] 503. The control unit receives the software configuration identifier of the software to be flashed from the diagnostic device in response to the configuration information read request. The software configuration identifier of the software to be flashed indicates the number of drive motors that are compatible with the software to be flashed.

[0070] In this embodiment, after receiving a configuration information read request from the control unit, the diagnostic device extracts the software configuration identifier of the software to be flashed from the header information of the software file loaded by the diagnostic device, and returns the software configuration identifier to the control unit. The control unit receives the software configuration identifier of the software to be flashed returned by the diagnostic device in response to the configuration information read request. Optionally, the diagnostic device returns the software configuration identifier via the UDS $62 service (read data response by identifier) ​​instruction.

[0071] The data structure of the software configuration identifier is consistent with the data structure of the vehicle's hardware configuration identifier. For example, the 0th byte of the software configuration identifier: the lower 4 bits (bits 0-3) store the presence flag of the front axle drive motor, where a value of 0 indicates that the vehicle has no front axle drive motor, and a value of 1 indicates that the vehicle has a front axle drive motor. The 0th byte of the software configuration identifier: the higher 4 bits (bits 4-7) store the presence flag of the rear axle drive motor, where a value of 0 indicates that the vehicle has no rear axle drive motor, and a value of 1 indicates that the vehicle has a rear axle drive motor.

[0072] Steps 501-503 above represent one possible implementation method for the control unit to obtain the motor configuration information of the software to be flashed. This possible implementation method, before flashing the software into the vehicle's control unit, uses interaction between the control unit and the diagnostic equipment to allow the control unit to obtain the software configuration identifier of the software to be flashed from the diagnostic equipment. This identifier is then used in subsequent processes to determine whether the software is compatible with the control unit, thus avoiding hardware-software incompatibility issues.

[0073] 504. If the software configuration identifier of the software to be flashed matches the hardware configuration identifier of the vehicle, the control unit allows the software to be flashed to be written to the control unit. If the software configuration identifier of the software to be flashed does not match the hardware configuration identifier of the vehicle, the control unit stops flashing the software to be flashed into the vehicle and stops executing the vehicle control method.

[0074] The vehicle's hardware configuration identifier refers to the hardware configuration identifier of the control unit, which also includes the vehicle's motor configuration information. Before the control unit hardware leaves the factory, the manufacturer writes the control unit's hardware configuration identifier into a fixed address in the control unit's Bootloader area, for example, 0x08000000-0x0800000F. The data structure of the hardware configuration identifier is as follows: Byte 0: The lower 4 bits (bits 0-3) store the presence flag of the front axle drive motor. A value of 0 indicates that the vehicle has no front axle drive motor, and a value of 1 indicates that the vehicle has a front axle drive motor. Byte 0: The higher 4 bits (bits 4-7) store the presence flag of the rear axle drive motor. A value of 0 indicates that the vehicle has no rear axle drive motor, and a value of 1 indicates that the vehicle has a rear axle drive motor. For example, Figure 6 This is a schematic diagram of the structure of a hardware configuration identifier provided in an embodiment of this application, such as... Figure 6 As shown, the hardware configuration identifier consists of 8 bytes. The lower 4 bits of byte 0 are the front axle drive motor presence flag, and the higher 4 bits are the rear axle drive motor presence flag. Bytes 1-3 are reserved bytes, and bytes 4-7 are CRC32 checksums.

[0075] This hardware configuration identifier fully describes the vehicle's drive motor configuration. This hardware configuration identifier is written into the Bootloader area once during the mass production of the control unit hardware using a dedicated programmer. Any subsequent application layer software flashing operation via the CAN bus cannot address or modify the hardware configuration identifier in this area.

[0076] In this embodiment, after receiving the software configuration identifier from the diagnostic device, the control unit executes comparison logic, that is, it compares the software configuration identifier byte-by-byte with the "front axle drive motor presence flag" and "rear axle drive motor presence flag" in the hardware configuration identifier. If the software configuration identifier and the hardware configuration identifier are completely identical, the comparison passes, the software configuration identifier of the software to be flashed matches the vehicle's hardware configuration identifier, and the control unit allows the software to be flashed to be written to the control unit. For example, the control unit replies to the diagnostic device with a UDS $74 service (request download positive response) instruction so that the control unit and the diagnostic device can continue to execute the normal software flashing process. If either of the above two flags is inconsistent, the comparison fails, the software configuration identifier of the software to be flashed does not match the vehicle's hardware configuration identifier, and the control unit stops flashing the software to be flashed into the vehicle. For example, the control unit replies to the diagnostic device with a UDS $7F service (service not supported or condition not met) instruction to terminate the flashing process and stop vehicle control.

[0077] In some embodiments, if the software configuration identifier of the software to be flashed does not match the vehicle's hardware configuration identifier, the control unit sends a second fault signal to the vehicle's instrument cluster controller. This second fault signal is used to cause the vehicle's instrument cluster to display second fault information, indicating that the software to be flashed is incompatible with the vehicle. For example, if the software configuration identifier of the software to be flashed does not match the vehicle's hardware configuration identifier, the control unit records fault code U1990 (software to be flashed is incompatible with control unit hardware) in an EEPROM (Electrically Erasable Programmable Read-Only Memory) and sends the fault code to the vehicle's instrument cluster controller, so that the instrument cluster controller can control the vehicle's instrument cluster to display the corresponding fault information based on the fault code.

[0078] In some embodiments, if the software configuration identifier of the software to be flashed does not match the hardware configuration identifier of the vehicle, the control unit enters a safety cutoff mode. In the safety cutoff mode, the control unit prohibits the vehicle from being driven based on the software. The following step 506 describes the safety cutoff mode in detail, and will not be repeated here.

[0079] Steps 501-504 above are error prevention verification processes before software flashing. This process is optional. The control unit can execute steps 501-504 above to verify whether the software to be flashed is compatible with the current hardware before the software is written to the control unit (such as HCU Flash), so as to avoid flashing incorrect software into the control unit. Alternatively, the control unit can skip steps 501-504 above and instead perform software and hardware matching verification after vehicle startup through steps 505-509 below. This verifies whether the software that has been flashed and is waiting to run in the control unit is compatible with the vehicle, and selects to drive the vehicle based on the software based on the verification result, or prohibits driving the vehicle based on the software.

[0080] Steps 501-504 above are executed before the software is flashed into the control unit, while steps 505-509 below are executed after the vehicle starts (when the vehicle power switch is switched from OFF to ON) and before high-voltage power is applied (when the high-voltage system is connected). The control unit can execute steps 505-509 below once before each high-voltage power-on to verify whether the vehicle's software and hardware are compatible. The software and hardware compatibility verification after vehicle startup shown in steps 505-509 is used to verify whether the vehicle's current software configuration matches the vehicle's actual hardware configuration. It includes two parts of the verification process: one part is based on the comparison of the whole vehicle configuration information, i.e., the verification process shown in steps 505-506 below; the other part is based on the comparison of dynamic topology detection, i.e., the verification process shown in steps 507-509 below. The vehicle's control unit can execute both parts of the verification process to achieve more reliable verification, or it can execute either part of the verification process to save computing resources and improve verification efficiency. This application embodiment does not limit this. In other words, the control unit can execute steps 505-509 below. This ensures that even if the VIN code or other information is tampered with or the detection process is interfered with, the other verification can still function. Of course, the control unit can also execute only steps 505-506 below, or only steps 507-509 below; this application embodiment does not limit this.

[0081] Furthermore, the execution time windows of the two verification processes mentioned above can be staggered or overlapped. That is, the control unit can execute steps 505-506 and 507-509 simultaneously, or it can execute steps 505-506 first and then steps 507-509, or it can execute steps 507-509 first and then steps 505-506. This application embodiment does not limit this. For example, the normal power-on sequence of the vehicle is as follows: at time T0, the user switches the key or start switch from the OFF position to the ON position; at T0+50ms, the control unit HCU completes internal initialization and begins executing application layer code; at T0+100ms, the CAN bus enters normal communication state; at T0+500ms, the control unit HCU sends a high-voltage power-on permission command to the battery management system, causing the high-voltage relay of the power battery to begin closing; at T0+600ms, the high-voltage system is established, and the drive motor controller can output torque to drive the vehicle. The hardware and software matching verification steps provided in this application embodiment must be completed before T0+500ms, that is, steps 505-509 must be completed before the high-voltage contactor closes. Only when all verifications pass will the control unit (HCU) allow the vehicle to be powered on at high voltage. Illustratively, the comparison process based on vehicle configuration information shown in steps 505-506 is executed between T0+100ms and T0+300ms, and the comparison process based on dynamic topology detection shown in steps 507-509 is executed between T0+200ms and T0+450ms. This application embodiment does not limit this.

[0082] The following is a detailed description of steps 505-509.

[0083] 505. In response to vehicle startup, the control unit obtains the vehicle's drive type information based on the vehicle's VIN code.

[0084] The VIN (Vehicle Identification Number) contains core information about the vehicle from production to use. For example, digits 4-8 of the VIN indicate vehicle characteristics such as model series, body type, engine type, and drive system. For instance, the 8th digit of the VIN indicates the vehicle's drive type; a value of "A" indicates a two-wheel drive vehicle, and a value of "B" indicates a four-wheel drive vehicle. This drive type information is essentially the vehicle's motor configuration information.

[0085] In this embodiment, in response to vehicle startup, the control unit reads the vehicle's VIN code from the body controller. For example, the control unit sends a VIN code read request to the body controller via the CAN bus, such as a UDS $22 service request command. This VIN code read request carries the DID address of the VIN code, such as DID 0xF190, so that the body controller can return the VIN code to the control unit based on the VIN code read request. After obtaining the VIN code, the control unit parses the vehicle's VIN code to obtain the vehicle's drive type information, such as extracting the vehicle's drive type information from bits 4-8 of the VIN code.

[0086] Step 505 above is one possible way to obtain the vehicle's motor configuration information. This possible way directly obtains the vehicle's VIN code from the vehicle's body controller, and then parses the vehicle's drive type information from the VIN code, which can directly obtain the vehicle's motor configuration information and has high verification efficiency.

[0087] 506. If the vehicle's drive type information matches the software configuration identifier of the flashed software, the control unit executes step 507. If the vehicle's drive type information does not match the software configuration identifier of the flashed software, the control unit enters the safety cutoff mode.

[0088] The vehicle's drive type information indicates whether the vehicle is a two-wheel drive or four-wheel drive vehicle, and indicates whether the vehicle has one or more drive motors. The software configuration identifier of the flashed software is the motor configuration information of the flashed software, and is similar to the software configuration identifier of the software to be flashed and the vehicle's hardware configuration identifier. The software configuration identifier of the flashed software is stored in the application layer Flash inside the control unit (HCU). This software configuration identifier is automatically embedded by the compiler during the compilation of the HCU software and is stored at a fixed Flash address (e.g., 0x08020000-0x08020007).

[0089] In this embodiment, the control unit reads the software configuration identifier of the flashed software in the vehicle and parses the number of drive motors adapted to the flashed software in the vehicle from the software configuration identifier. The control unit compares this number with the number of drive motors indicated by the drive type information parsed from the VIN code. If the "front axle drive motor presence flag" and "rear axle drive motor presence flag" in the software configuration identifier are consistent with the drive type information in the VIN code (e.g., the software configuration identifier indicates that both the front axle drive motor and the rear axle drive motor are present, and the drive type information in the VIN code indicates that the vehicle is a four-wheel drive vehicle), or if the software configuration identifier indicates that either the front axle drive motor or the rear axle drive motor is absent, and the drive type information in the VIN code indicates that the vehicle is a two-wheel drive vehicle), then the vehicle's drive type information matches the software configuration identifier of the flashed software, the comparison is successful, and the control unit executes step 507. If the "Front axle drive motor presence flag" and "Rear axle drive motor presence flag" in the software configuration identifier are inconsistent with the drive type information in the VIN code, then the vehicle's drive type information does not match the software configuration identifier of the flashed software, the comparison fails, the control unit enters the safety cutoff mode, and prohibits driving based on the above-mentioned flashed software.

[0090] In some embodiments, if the vehicle's motor configuration information does not match the number of drive motors whose software has been flashed and adapted to the vehicle, the control unit sends a first fault signal to the vehicle's instrument cluster controller. This first fault signal causes the vehicle's instrument cluster to display first fault information, indicating that the flashed software is incompatible with the vehicle. For example, if the vehicle's motor configuration information does not match the number of drive motors whose software has been flashed and adapted to the vehicle, the control unit records fault code U1991 (software configuration mismatch with vehicle configuration) and sends this fault code to the vehicle's instrument cluster controller. The instrument cluster controller then controls the vehicle's instrument cluster to display the corresponding fault information based on this fault code.

[0091] In some embodiments, if the body controller does not respond to the control unit's VIN code reading request, or if the VIN code reading fails, the control unit directly enters the safety cutoff mode.

[0092] In some embodiments, when in a safety cutoff mode, the control unit performs at least one of the following measures to prevent the vehicle from driving based on the aforementioned flashed software: (1) Prohibit high voltage power-on: The control unit sends a power-on prohibition command to the vehicle's battery management system via the CAN bus. The power-on prohibition command is used to control the vehicle to prevent power-on.

[0093] (2) Torque output is prohibited: The control unit continuously sends torque prohibition broadcast frames to the vehicle's drive motor controller. The torque prohibition broadcast frames are used to prohibit the vehicle's drive motor controller from sending torque commands to the drive motor. For example, the control unit sends a torque prohibition broadcast frame once every preset period until the fault is cleared. The preset period is, for example, 10ms-20ms.

[0094] (3) Instrument Panel Fault Display: The control unit sends a fault signal to the instrument controller via the CAN bus. This fault signal carries a fault code. After receiving the fault code, the instrument controller displays the corresponding fault information on the instrument panel. For example, fault code U1990 indicates that a hardware / software mismatch was detected during flashing; fault code U1991 indicates that a software configuration mismatch was detected during power-on; and fault code U1992 indicates that a mismatch was detected between the actual vehicle topology and the expected software topology during power-on. After receiving the fault code, the instrument controller controls the instrument panel to display "System Fault - Hardware / Software Mismatch" and illuminates the yellow "System Fault" indicator light. This fault information is different from conventional motor or battery faults, making it easier for maintenance personnel to quickly locate the root cause of the problem.

[0095] Step 506 above is a possible implementation method for controlling the vehicle to prohibit driving based on the flashed software if the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software in the vehicle. This possible implementation method can prevent the vehicle from driving based on the software in a timely manner when the software configuration identifier of the software does not match the drive form information in the vehicle's VIN code, thereby avoiding the problem of vehicle control errors caused by software and hardware incompatibility and improving the safety of vehicle driving.

[0096] 507. The control unit sends multiple detection frames, each used to detect the presence of a drive motor in the vehicle.

[0097] Each probe frame is used to detect the presence of a corresponding drive motor controller in the vehicle. Accordingly, each probe frame includes a probe address segment for the corresponding drive motor controller. This probe address segment is specifically allocated for the corresponding drive motor controller based on the probe frame and differs from the torque control address segment (the address segment carried by the torque command) of the corresponding drive motor controller. By carrying an address segment different from the torque command, such as CANID 0x710 / 0x718, the probe frame can be distinguished from the torque command, ensuring that the drive motor controller can recognize the probe frame as a non-torque request, thereby ensuring that the drive motor controller does not perform any drive operation based on the probe frame.

[0098] In this embodiment, the control unit sends probe frames for each drive motor controller via an address preset for the MCU (Motor Control Unit) on the CAN bus. Schematic, the control unit sends a probe frame targeting the front axle drive motor controller, the probe frame carrying a probe address segment of 0x710, and a probe frame targeting the rear axle drive motor controller, the probe frame carrying a probe address segment of 0x718.

[0099] 508. The control unit generates motor configuration information for the vehicle based on the received response information for multiple probe frames, which indicates the number of drive motors in the vehicle.

[0100] In this embodiment, after receiving a CAN frame, the drive motor controller in the vehicle checks if the address segment carried by the CAN frame is a probe address segment. If the address segment carried by the CAN frame is between 0x710 and 0x71F, the drive motor controller determines that the CAN frame is a probe frame, not a torque command. Based on the received CAN frame being a probe frame, the drive motor controller replies with response information to the control unit, indicating that the corresponding drive motor controller exists. The control unit sets a timeout timer (e.g., a 50ms timeout timer) for each probe frame. In response to the issuance of a probe frame, the timeout timer starts counting. If a response information for the probe frame is received from the drive motor controller before the timeout expires, the control unit determines that the corresponding drive motor exists and records the existence flag of the corresponding drive motor as TRUE, indicating that the drive motor exists. If no response information for the probe frame is received from the drive motor controller before the timeout expires, or if the received response information is in the wrong format, the control unit determines that the corresponding drive motor does not exist and records the existence flag of the corresponding drive motor as FALSE, indicating that the drive motor does not exist. Based on the received response information for multiple probe frames, the control unit generates the vehicle's motor configuration information.

[0101] The response information returned by the drive motor controller carries the probe address segment corresponding to the probe frame, so that the control unit can determine that it has received the corresponding response information from the drive motor controller based on the probe address segment. For example, the response information returned by the front axle drive motor controller carries address segment 0x711, and the response information returned by the rear axle drive motor controller carries address segment 0x719.

[0102] In some embodiments, the control unit constructs the actual motor configuration variable of the vehicle and defines the variable as an 8-bit unsigned integer, where bit 0 is the presence flag of the front axle drive motor and bit 1 is the presence flag of the rear axle drive motor. Similar to the software configuration flag and hardware configuration flag mentioned above, the presence of the vehicle's drive motor is recorded through the value of the variable. This application embodiment does not limit this.

[0103] Steps 507-508 above are one possible way to obtain the vehicle's motor configuration information. Since the number of drive motors in two-wheel drive vehicles and four-wheel drive vehicles is different, by sending a probe frame to the possible drive motor controller and waiting for a response, the vehicle's hardware configuration, i.e. the number of drive motors, can be accurately identified based on the response result, thereby improving the accuracy of obtaining the vehicle's motor configuration information and thus improving the accuracy of software and hardware compatibility verification.

[0104] 509. If the vehicle's motor configuration information matches the number of drive motors in the vehicle that have been flashed with compatible software, the control unit controls the vehicle to be powered on by high voltage and drives the vehicle based on the flashed software. If the vehicle's motor configuration information does not match the number of drive motors in the vehicle that have been flashed with compatible software, the control unit enters a safety cutoff mode.

[0105] In this embodiment, the number of drive motors in the vehicle that have been flashed with software is embedded into the control unit during software compilation. The control unit directly reads the number of drive motors in the vehicle that have been flashed with software from its local storage. The control unit compares the number of drive motors in the vehicle that have been flashed with software with the actual number of drive motors in the vehicle detected by the detection frame. If the number of drive motors that have been flashed with software is the same as the actual number of drive motors in the vehicle, then the vehicle's motor configuration information matches the number of drive motors that have been flashed with software, and the comparison is successful. At T0+500ms, the control unit sends a high-voltage power-on permission command to the battery management system to control the vehicle's high-voltage power-on and drive the vehicle based on the aforementioned flashed software. If the number of drive motors that have been flashed with software is different from the actual number of drive motors in the vehicle, then the vehicle's motor configuration information does not match the number of drive motors that have been flashed with software, and the comparison fails. The control unit enters a safety cutoff mode, which is similar to the above-mentioned related content and will not be described again in this embodiment.

[0106] In some embodiments, if the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software in the vehicle, the control unit sends a first fault signal to the vehicle's instrument cluster controller. This first fault signal causes the vehicle's instrument cluster to display first fault information, indicating that the flashed software is incompatible with the vehicle. For example, if the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software, the control unit records fault code U1992 (actual topology does not match the expected software topology) and sends this fault code to the vehicle's instrument cluster controller. The instrument cluster controller then controls the vehicle's instrument cluster to display the corresponding fault information based on this fault code.

[0107] Step 509 above is a possible implementation method to prevent the vehicle from being driven based on the flashed software if the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software. This possible implementation method is based on verification of the actual number of drive motors in the vehicle obtained through dynamic hardware presence detection, and the verification accuracy is high.

[0108] The aforementioned vehicle control method combines pre-flash software error prevention verification and post-power-on verification into a complete dual error prevention verification scheme. Pre-flash software error prevention verification checks whether the "expected software configuration" and "vehicle identity configuration" are consistent, focusing on vehicle-level compatibility. Post-power-on verification verifies whether the "expected software topology" and "actual physical topology" are consistent, focusing on hardware-software compatibility. Only after both pass will the control unit send a high-voltage power-on permission command at T0+500ms. Furthermore, the verification process shown in steps 505-509 above achieves preventative verification before / at the moment of power-on. This verification process can identify situations where two-wheel drive control unit hardware is incorrectly installed on a four-wheel drive vehicle, overcoming the shortcomings of existing technologies that only focus on software flashing error prevention. Moreover, this process is entirely completed by the vehicle itself, without relying on external devices, and does not require connection to diagnostic equipment, host computers, or the cloud. It is applicable to every power-on throughout the vehicle's entire lifecycle. For example, using dynamic topology detection-based comparison as an example... Figure 7 This application provides a data interaction diagram for comparison and verification based on dynamic topology detection, as shown in the embodiments of this application. Figure 7 As shown, the hardware and software matching verification after vehicle startup involves the interaction between the vehicle's control unit, the front axle drive motor controller, the rear axle drive motor controller, and the battery management system. During the verification process, at time T0+0ms, the vehicle is powered on and switched from the OFF position to the ON position. The control unit completes initialization under low voltage and reads the number of drive motors adapted by the flashed software. With the high voltage not connected, it sends probe frames to the front axle drive motor controller and the rear axle drive motor controller respectively. The front axle drive motor controller and the rear axle drive motor controller reply with response information respectively. The control unit generates the actual motor configuration information of the vehicle based on the received response information and compares this actual motor configuration information with the number of drive motors adapted by the flashed software. After the comparison is successful, a high voltage power-on permission command is sent to the battery management system at T0+500ms to control the high voltage power-on of the vehicle and drive it based on the software, so that the drive motors can output torque normally.

[0109] The vehicle control method provided in this application, in response to vehicle startup, acquires the vehicle's motor configuration information, which indicates the number of drive motors in the vehicle. If the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software, the method controls the vehicle to prevent it from driving based on the flashed software. This method, by checking whether the flashed software matches the vehicle's drive motor configuration after vehicle startup, and prohibiting driving based on the software when it is incompatible with the vehicle hardware, avoids the vehicle from driving based on incompatible software, thereby preventing abnormalities in the vehicle's power system and ensuring driving safety. The aforementioned vehicle control method transforms the hardware / software compatibility verification from a "one-time external verification during flashing" to "HCU active interception before flashing + dual autonomous verification before high-voltage connection after power-on." It combines hardware / software compatibility verification with three key technologies: solidified hardware signature, non-torque detection frame, and VIN code redundancy comparison. This fundamentally eliminates unexpected torque output after vehicle power-on due to incorrect software flashing or incorrect hardware installation, ensuring driving safety. Furthermore, the method provides a dual-layer error prevention and fallback verification mechanism, which sets up verification at two key nodes: "before flashing" and "before applying high voltage," forming a redundant safety defense. Even if the first verification is bypassed for some reason, the second verification can still identify and prevent abnormalities before applying high voltage, fundamentally eliminating the possibility of "unexpected torque output in P / D / R gears." This solves the problem that existing technologies only perform verification once during flashing, which cannot cover the safety hazards caused by abnormal torque output of the vehicle due to incorrect software flashing or incorrect hardware installation by maintenance personnel, thus ensuring the safety of vehicle driving.

[0110] Figure 8 This is a structural block diagram of a vehicle control device provided in an embodiment of this application. This device is used to perform the steps of the above-described vehicle control method, see below. Figure 8 The vehicle control device includes: The configuration information acquisition module 801 is used to acquire the motor configuration information of the vehicle in response to vehicle startup, wherein the motor configuration information indicates the number of drive motors in the vehicle; The control module 802 is used to control the vehicle to prohibit it from being driven based on the flashed software if the motor configuration information of the vehicle does not match the number of drive motors adapted to the flashed software in the vehicle.

[0111] In some embodiments, the configuration information acquisition module 801 described above is used for: Read the vehicle identification number (VIN) from the vehicle's body control unit; The vehicle's VIN code is parsed to obtain the vehicle's motor configuration information.

[0112] In some embodiments, the above-described apparatus further includes: The configuration identifier reading module is used to read the software configuration identifier of the software that has been flashed in the vehicle, and to parse the number of drive motors that have been flashed and are compatible with the software in the vehicle from the software configuration identifier.

[0113] In some embodiments, the configuration information acquisition module 801 described above is used for: Multiple detection frames are sent to detect the presence of drive motors in the vehicle. Based on the received response information for multiple probe frames, the vehicle's motor configuration information is generated.

[0114] In some embodiments, each of the above-mentioned detection frames includes a detection address segment of the drive motor controller corresponding to the detection frame, and the detection address segment is different from the torque control address segment of the corresponding drive motor controller.

[0115] In some embodiments, the control module 802 is configured to: Send a power-off command to the vehicle's battery management system. The power-off command is used to control the vehicle to prevent it from receiving power.

[0116] In some embodiments, the control module 802 is configured to: A torque disable broadcast frame is sent to the vehicle's drive motor controller. The torque disable broadcast frame is used to prevent the vehicle's drive motor controller from sending torque commands to the drive motor.

[0117] In some embodiments, the above-described apparatus further includes: The first prompt module is used to send a first fault signal to the vehicle's instrument controller if the vehicle's motor configuration information does not match the number of drive motors that have been flashed and adapted to the vehicle's software. The first fault signal is used to make the vehicle's instrument panel display first fault information, which indicates that the flashed software in the vehicle is incompatible with the vehicle.

[0118] In some embodiments, the above-described apparatus further includes: The software configuration acquisition module is used to acquire the motor configuration information of the software to be flashed. The motor configuration information of the software to be flashed indicates the number of drive motors that are compatible with the software to be flashed. The comparison module is used to stop flashing the software into the vehicle if the motor configuration information of the software to be flashed does not match the motor configuration information of the vehicle.

[0119] In some embodiments, the software configuration acquisition module described above is used for: Receive a software flashing request from the diagnostic device. The software flashing request carries the storage address of the motor configuration information of the software to be flashed in the diagnostic device. Based on the software flashing request, a configuration information read request is sent to the diagnostic device. The configuration information read request is used to read the motor configuration information of the software to be flashed. Receive motor configuration information for the software to be flashed, returned by the diagnostic device in response to the configuration information read request.

[0120] In some embodiments, the above-described apparatus further includes: The second prompt module is used to send a second fault signal to the vehicle's instrument controller if the motor configuration information of the software to be flashed does not match the vehicle's motor configuration information. The second fault signal is used to make the vehicle's instrument panel display a second fault message, indicating that the software to be flashed is incompatible with the vehicle.

[0121] It should be noted that the device provided in the above embodiments is only illustrated by the division of the above functional modules when controlling a vehicle. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0122] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. This electronic device can be applied to the aforementioned vehicle to execute the vehicle control method provided in this embodiment. The electronic device 900 can vary significantly due to differences in configuration or performance. It may include one or more CPUs (Central Processing Units) 901 and one or more memories 902. The memory 902 stores at least one computer program, which is loaded and executed by the processor 901 to implement the vehicle control method provided in the various method embodiments described above. Of course, the electronic device may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The electronic device may also include other components for implementing device functions, which will not be elaborated upon here.

[0123] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a vehicle to implement the operations performed by the vehicle in the vehicle control method of the above embodiments. For example, the computer-readable storage medium may be ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (CompactDisc Read-Only Memory), magnetic tape, floppy disk, and optical data storage device, etc.

[0124] This application also provides a computer program product or computer program, which includes computer program code stored in a computer-readable storage medium. A vehicle reads the computer program code from the computer-readable storage medium and executes the computer program code, causing the vehicle to perform the vehicle control methods provided in the various optional implementations described above.

[0125] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0126] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A vehicle control method, characterized in that, The method includes: In response to vehicle startup, the motor configuration information of the vehicle is obtained, the motor configuration information indicating the number of drive motors in the vehicle; If the motor configuration information of the vehicle does not match the number of drive motors adapted to the flashed software in the vehicle, the vehicle is controlled to prevent it from being driven based on the flashed software.

2. The method according to claim 1, characterized in that, The process of obtaining the vehicle's motor configuration information includes: Read the vehicle identification number (VIN) of the vehicle from the vehicle's body controller; The VIN code of the vehicle is parsed to obtain the motor configuration information of the vehicle.

3. The method according to claim 1, characterized in that, The method further includes: Read the software configuration identifier of the software already flashed in the vehicle, and parse the software configuration identifier to obtain the number of drive motors adapted to the software already flashed in the vehicle.

4. The method according to claim 1, characterized in that, The process of obtaining the vehicle's motor configuration information includes: Multiple detection frames are sent, the multiple detection frames being used to detect the drive motor present in the vehicle; Based on the received response information for the multiple detection frames, the motor configuration information of the vehicle is generated.

5. The method according to claim 4, characterized in that, Each of the detection frames includes a detection address segment of the drive motor controller corresponding to the detection frame, and the detection address segment is different from the torque control address segment of the corresponding drive motor controller.

6. The method according to claim 1, characterized in that, The control of the vehicle to prevent it from being driven based on the flashed software includes: A power-off command is sent to the vehicle's battery management system, the power-off command being used to control the vehicle to prevent it from being powered on.

7. The method according to claim 1, characterized in that, The control of the vehicle to prevent it from being driven based on the flashed software includes: A torque prohibition broadcast frame is sent to the drive motor controller of the vehicle, the torque prohibition broadcast frame being used to prohibit the drive motor controller of the vehicle from sending torque commands to the drive motor.

8. The method according to claim 1, characterized in that, The method further includes: If the motor configuration information of the vehicle does not match the number of drive motors that have been flashed with compatible software in the vehicle, a first fault signal is sent to the instrument controller of the vehicle. The first fault signal is used to make the instrument panel of the vehicle display first fault information, which indicates that the flashed software in the vehicle is incompatible with the vehicle.

9. The method according to claim 1, characterized in that, The method further includes: Obtain the motor configuration information of the software to be flashed, wherein the motor configuration information of the software to be flashed indicates the number of drive motors adapted to the software to be flashed; If the motor configuration information of the software to be flashed does not match the motor configuration information of the vehicle, the flashing of the software to be flashed into the vehicle will be stopped.

10. The method according to claim 9, characterized in that, The process of obtaining the motor configuration information for the software to be flashed includes: Receive a software flashing request from a diagnostic device, the software flashing request carrying the storage address of the motor configuration information of the software to be flashed in the diagnostic device; Based on the software flashing request, a configuration information read request is sent to the diagnostic device. The configuration information read request is used to read the motor configuration information of the software to be flashed. The diagnostic device receives the motor configuration information of the software to be flashed, returned in response to the configuration information read request.

11. The method according to claim 9, characterized in that, The method further includes: If the motor configuration information of the software to be flashed does not match the motor configuration information of the vehicle, a second fault signal is sent to the vehicle's instrument controller. The second fault signal is used to make the vehicle's instrument panel display second fault information, which indicates that the software to be flashed is incompatible with the vehicle.

12. A vehicle control device, characterized in that, The device includes: A configuration information acquisition module is used to acquire the motor configuration information of the vehicle in response to vehicle startup, wherein the motor configuration information indicates the number of drive motors in the vehicle; The control module is used to prevent the vehicle from being driven based on the flashed software if the vehicle's motor configuration information does not match the number of drive motors adapted to the flashed software in the vehicle.

13. A vehicle, characterized in that, The vehicle is used to perform the method described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one computer program for performing the method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the vehicle, it implements the method as described in any one of claims 1 to 11.

Images