Vehicle configuration word stock flashing method and device, equipment and medium
By introducing a drive controller verification and self-test process during the vehicle configuration font flashing process, errors caused by manually building configuration tables were resolved, ensuring the accuracy and reliability of vehicle software flashing, and improving production quality and production line continuity.
Patent Information
- Application Number
- CN202511392186.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-26
- Publication Date
- 2025-12-26
AI Technical Summary
The existing vehicle configuration font flashing process relies heavily on manually building configuration tables, which poses a risk of batch quality incidents due to configuration definition errors caused by project personnel's lack of technical familiarity.
A verification step for the driver controller is introduced during the flashing process. By comparing the driver type indicated by the feature value in the configuration table with the driver type actually reported by the driver controller, the flashing operation is only performed when the two match. Temporary errors are eliminated through retest verification and self-testing processes to ensure accuracy and reliability.
This effectively avoids batch flashing problems caused by human error, improves the accuracy and production quality of vehicle software flashing, reduces interruptions caused by temporary anomalies, and improves the continuity and efficiency of the production line.
Smart Images
Figure CN121209902A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle configuration flashing technology, and in particular to a method, apparatus, device and medium for flashing vehicle configuration fonts. Background Technology
[0002] With the increasing diversification of vehicle configurations, automakers commonly employ "configuration word matching" technology to efficiently manage the co-production of models with different configurations (especially drive types such as two-wheel drive / four-wheel drive) on the same platform. Its core is the establishment of a configuration word library system. This system acts like a digital dictionary, defining unique characteristic values for different configuration states (such as independent four-wheel drive, integrated four-wheel drive, and two-wheel drive) of each controller (e.g., four-wheel drive system, independent four-wheel drive, integrated four-wheel drive, two-wheel drive). (For example, EAV configuration indicates an integrated four-wheel drive controller: EAV00 indicates that integrated four-wheel drive configuration word writing is not initiated, and EAV10 indicates that integrated four-wheel drive configuration word writing is initiated.)
[0003] The vehicle configuration table is the source and guiding document of the system, and is manually built by project personnel according to the vehicle model plan. During production, the flashing equipment identifies the configuration by reading the vehicle's VIN (Vehicle Identification Number) code, queries the configuration font library, and determines which specific controller software needs to be flashed for the vehicle based on the corresponding feature values.
[0004] However, this process carries a critical risk: the configuration table is entirely manual. If project personnel are unfamiliar with the complex technical specifications, they may define the configuration incorrectly at the outset (e.g., mistakenly setting the characteristic value of a four-wheel drive vehicle to EAV00). This would cause all subsequent vehicles of that model to be flashed with the wrong logic (i.e., the four-wheel drive software is not flashed onto four-wheel drive vehicles), leading to a batch of quality incidents.
[0005] In summary, while the existing process is efficient, it is highly dependent on the accuracy of manual input at the front end, and there is a risk that batch writing may fail due to errors in the configuration table. Summary of the Invention
[0006] In view of the above problems, this disclosure provides a method, apparatus, device, and medium for flashing vehicle configuration fonts to solve the problem of configuration font errors during whole-vehicle flashing. The technical solution is as follows: A method for flashing a vehicle configuration font library includes: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.
[0007] It should be noted that this application introduces a verification step of the drive controller during the actual flashing process. The drive type indicated by the feature value of the configuration table is compared with the drive type actually reported by the drive controller. The flashing operation is only performed when the two match. This effectively avoids batch flashing problems caused by errors that may occur when the project team manually builds the configuration table (such as reversed drive type configuration). This ensures the accuracy and reliability of vehicle software flashing and improves production quality.
[0008] Optionally, before specifying the specified feature value corresponding to the specified vehicle, the method further includes: The corresponding configuration font library is set according to the vehicle's drive type, and the corresponding feature value is set for each configuration font library.
[0009] It should be noted that this application systematically establishes and divides the configuration font library and its feature values based on the actual drive type of the vehicle at the initial stage of the flashing process. This lays an accurate and structured data foundation for the entire subsequent flashing process. This preliminary standardization work ensures that the feature values can be truly and uniquely mapped to the specific hardware configuration, thereby avoiding subsequent identification and flashing errors that may be caused by confusion or misalignment between the configuration font library and the drive type definition. This greatly improves the standardization and reliability of the entire configuration management system.
[0010] Optionally, the feature values corresponding to each of the configuration character libraries are configured with different configuration character encoding logic based on the driver type, and the configuration character encoding logic includes the configuration character encoding position.
[0011] It should be noted that this application sets configuration word encoding logic with specific encoding positions for different driver types, so that each driver configuration has its own unique and structured digital identity in the configuration word library. This strict distinction from content to form fundamentally eliminates the possibility of confusion between configuration words of different driver types at the encoding level, and provides a clear and unambiguous data source for all subsequent feature-based identification, comparison and writing operations, thereby greatly enhancing the accuracy and robustness of the entire writing system when dealing with complex configuration variations.
[0012] Optionally, if the first driver type and the second driver type are inconsistent, the method further includes: Perform a retest verification process; The retesting process includes: Redetermine the new specified feature value corresponding to the specified vehicle; The flashing verification command is resent to the drive controller of the specified vehicle, and a new verification response command is received from the drive controller. Determine the third drive type corresponding to the newly specified feature value, and determine the fourth drive type corresponding to the new verification response instruction; Compare whether the third drive type and the fourth drive type are consistent; If there is a discrepancy, determine whether the number of times the retest verification process has been executed has reached a first preset number. The first preset number is configured based on the vehicle model, communication protocol, or flashing environment parameters. If so, it will display a message indicating that the specified vehicle configuration font flashing failed.
[0013] It should be noted that this application introduces a retest verification process. When the initial drive type comparison is inconsistent, it does not immediately determine that the flashing has failed. Instead, the system automatically reacquires vehicle characteristic values and drive controller verification information, performing multiple comparisons and verifications. This mechanism effectively distinguishes between transient errors (such as communication interference, signal jitter, or temporary hardware response delays) and permanent configuration errors. By dynamically configuring the first preset number of retries based on vehicle model, communication protocol, or flashing environment parameters, the system can adaptively adjust the retry strategy, avoiding false failures due to occasional problems and preventing infinite loops when genuine configuration conflicts exist. An error is only finally reported after the preset number of retries has been reached and inconsistencies still exist. This process ensures fault tolerance for intermittent faults, significantly reducing flashing interruptions caused by temporary anomalies, improving production line continuity and efficiency, and maintaining the system's reliability and robustness in complex industrial environments.
[0014] Optionally, displaying the message that the specified vehicle configuration font flashing failed includes: The drive type comparison for the specified vehicle failed. Please confirm whether the new specified feature value corresponding to the specified vehicle is correct, or check whether the drive controller of the specified vehicle has been modified.
[0015] It should be noted that when the system ultimately determines that the vehicle flashing has failed, this application can provide operators with clear and instructive fault location information. It not only points out the failure of the drive type comparison, but more importantly, it directly indicates the two most likely causes: configuration feature value setting problems or abnormal vehicle hardware modifications. This precise prompt greatly reduces the time and effort required for on-site personnel to troubleshoot and solve problems, effectively avoids production line stoppages or repeated trial and error due to unclear causes of problems, and significantly improves the efficiency of handling production anomalies and the success rate of first-time repairs.
[0016] Optionally, after flashing the specified vehicle based on the specified configuration font library, the method further includes: Send a flash self-test command to the drive controller and receive a self-test response command from the drive controller; Determine the fifth drive type that the specified vehicle has been flashed, and determine the sixth drive type corresponding to the self-test response command; Compare whether the fifth drive type and the sixth drive type are consistent; If they match, complete the configuration font flashing self-test for the specified vehicle.
[0017] It should be noted that this application adds a self-check verification step with the drive controller immediately after the software flashing is completed. This step verifies the final consistency between the drive type defined in the newly flashed configuration font and the actual drive type fed back by the controller. This creates a final reliable quality defense before the vehicle rolls off the production line, ensuring that the actual effect of each flashing operation is verified in a closed loop. This effectively prevents the potential risk of "flashing successfully but actually failing" due to unknown errors in the flashing process or incomplete data transmission, greatly improving the final reliability of the vehicle software flashing and the factory quality assurance.
[0018] Optionally, if the fifth drive type is inconsistent with the sixth drive type, the method further includes: Execute the retry self-test process; The retry self-test process includes: The flash self-test command is resent to the drive controller, and a new self-test response command is received from the drive controller; Re-determine the seventh drive type that has been flashed for the specified vehicle, and determine the eighth drive type corresponding to the new self-test response command; Compare whether the seventh drive type and the eighth drive type are consistent; If there is a discrepancy, determine whether the number of times the retry self-test process has been executed has reached the second preset number. The second preset number is configured based on the vehicle model, communication protocol, or flashing environment parameters. If so, it will display a message indicating a problem with the specified vehicle configuration font flashing.
[0019] It should be noted that this application introduces a retry self-test process to perform a secondary verification of the drive type of the flashed vehicle after the final flashing operation. When it is detected that the actual flashed drive type of the vehicle is inconsistent with the drive type reported by the drive controller, multiple verifications are performed through a retry mechanism intelligently set based on the specific vehicle model, communication protocol, and real-time flashing environment. This design enables the system to effectively filter out the risk of misjudgment caused by occasional interference such as the momentary instability of the controller during the restart process after flashing and the brief congestion of bus communication. It ensures that only when the inconsistency is confirmed as a persistent hardware configuration error or a substantial defect in the flashing itself is it finally judged as a flashing error. This greatly reduces the probability of falsely reporting a vehicle in a normal self-test transition state as a faulty vehicle, improves the accuracy of the quality inspection process, effectively prevents the misinterpretation of qualified products and unnecessary rework, and ensures the smoothness of the production line and the reliability of the final product delivery.
[0020] A vehicle-configured font writing device includes: The feature value determination unit determines the specified feature value corresponding to the specified vehicle when the specified vehicle is being configured with a font library. The instruction sending unit sends a flashing verification instruction to the drive controller of the designated vehicle and receives a verification response instruction from the drive controller. The type determination unit determines the first driving type corresponding to the specified feature value and the second driving type corresponding to the verification response instruction. The comparison unit compares whether the first drive type and the second drive type are consistent; If the flashing unit matches, it determines the specified configuration font library for the specified vehicle based on the first drive type or the second drive type, and flashes the specified vehicle based on the specified configuration font library.
[0021] A vehicle-configured font writing device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.
[0022] A non-volatile computer storage medium storing computer-executable instructions, which, when executed by a computer, can achieve the following: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.
[0023] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, specific embodiments of this disclosure are described below. Attached Figure Description
[0024] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating a method for flashing a vehicle configuration font library according to an embodiment of this disclosure is shown. Figure 2 This diagram illustrates the structure of a vehicle configuration font writing device according to an embodiment of the present disclosure; Figure 3 A schematic diagram of a vehicle configuration font writing device provided in an embodiment of this disclosure is shown. Detailed Implementation
[0025] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
[0026] With the development of automotive technology, vehicles now come in a wide variety of configurations, including both two-wheel drive and four-wheel drive. While the same model may be produced at a single OEM, different models may be produced on the same production line. In this context, automakers use configuration character matching to differentiate configurations. Configuration character matching involves establishing a configuration character library system containing information about various controllers. Different configurations of the same model can be distinguished through this system. The OEM's software flashing equipment then uses the vehicle's VIN (Vehicle Identification Number) to identify different configurations within the same model, thus determining which software needs to be flashed and which does not.
[0027] Taking four-wheel drive vehicles as an example, generally, four-wheel drive vehicles also have two-wheel drive configurations. Four-wheel drive vehicles require reprogramming the four-wheel drive system software, while two-wheel drive vehicles do not (because they do not have a four-wheel drive system). Furthermore, the four-wheel drive system of the same vehicle model can have different states, such as independent four-wheel drive and integrated four-wheel drive. These configurations are categorized through the vehicle configuration table, so the four-wheel drive system configuration library contains corresponding special values, such as independent four-wheel drive, integrated four-wheel drive, part-time four-wheel drive, intelligent four-wheel drive, and two-wheel drive. In the actual vehicle production process, the configuration characters are copied specifically according to the different characteristic value states, thus achieving differentiated reprogramming.
[0028] The configuration table serves as the input for the configuration font logic and is also a guiding document for vehicle production. The configuration fonts for each controller are derived from the configuration table. The configuration font contains many characteristic values, such as EAV (Entity-Attribute-Value) configurations, which represent integrated four-wheel drive controllers: EAV00 indicates no four-wheel drive controller, while EAV10 indicates a four-wheel drive controller. The OEM's flashing equipment identifies these values using specific EAV values. If EAV00 is selected, flashing the integrated four-wheel drive configuration font will not be initiated; if EAV10 is selected, flashing the integrated four-wheel drive configuration font will be initiated. However, the configuration table is manually built by the project team, who are not entirely familiar with the technical status of each controller in the vehicle, leading to potential errors. If the integration of the four-wheel drive solution is incorrectly configured during the project's configuration table setup, the corresponding EAV configuration values of 00 and 10 for the entire vehicle will be reversed, resulting in incorrect configuration fonts flashed later on, causing batch issues.
[0029] Therefore, this application provides a flowchart illustrating a method for flashing a vehicle configuration font library, as shown below. Figure 1 As shown, this process can be executed by the vehicle configuration font flashing system. Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.
[0030] The method flow steps of this application embodiment are as follows: S101, when the specified vehicle is being configured with a font library, the specified feature value corresponding to the specified vehicle is determined.
[0031] In the embodiments described in this specification, when a designated vehicle enters the flashing station, the flashing system first obtains the vehicle identification number (VIN) of the vehicle through a scanning device. The system then uses this VIN as an index to automatically query the vehicle configuration table database in the background, retrieves and locks all the pre-configured feature values of the vehicle from the database, and these successfully retrieved feature values are defined by the system as the "specified feature values" required for this flashing process.
[0032] S102, a flashing verification command is sent to the drive controller of the designated vehicle, and a verification response command is received from the drive controller.
[0033] In the embodiments described in this specification, the flashing system sends a "flash verification command" requesting the identity status of the drive controller on the designated vehicle through the physical diagnostic interface. After receiving the command, the drive controller packages its own hardware type identifier or fixed configuration information into a "verification reply command" and sends it back to the flashing system through the original path, completing a handshake communication.
[0034] S103, determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction.
[0035] In the embodiments described in this specification, this step includes two parallel parsing processes. On the one hand, the flashing system translates a theoretical "first drive type" based on the "specified feature value" obtained from S101 and according to preset mapping rules (such as feature value EAV10 corresponding to "integrated four-wheel drive"). On the other hand, the system parses the "verification reply instruction" received from S102, extracts the hardware information actually reported by the drive controller, and thus obtains a "second drive type" in physical state.
[0036] S104, compare whether the first drive type and the second drive type are consistent.
[0037] In the embodiments of this specification, the flashing system accurately compares the "first drive type" (theoretical configuration) obtained in step S103 with the "second drive type" (physical state), executes consistency verification logic, and determines whether the two are completely consistent.
[0038] S105, if consistent, determine the specified configuration font library for the specified vehicle based on the first drive type or the second drive type, and flash the specified vehicle based on the specified configuration font library.
[0039] In the embodiments described in this specification, this step is triggered only when the comparison result in S104 is "consistent". Based on the verified driver type (first or second driver type), the system precisely retrieves the "specified configuration font" and related software data packages that perfectly correspond to it from the configuration font library. Subsequently, the flashing system initiates the regular flashing process, safely and orderly flashing all these software data packages into the corresponding controller of the specified vehicle.
[0040] It should be noted that this application introduces a verification step of the drive controller during the actual flashing process. The drive type indicated by the feature value of the configuration table is compared with the drive type actually reported by the drive controller. The flashing operation is only performed when the two match. This effectively avoids batch flashing problems caused by errors that may occur when the project team manually builds the configuration table (such as reversed drive type configuration). This ensures the accuracy and reliability of vehicle software flashing and improves production quality.
[0041] It should be noted that, in general, a controller builds a configuration font library, and the four-wheel drive system must build a four-wheel drive system configuration font library. Since a vehicle can only have one four-wheel drive mode, the integrated four-wheel drive solution and the independent four-wheel drive solution in the four-wheel drive system are mutually exclusive. That is to say, if a vehicle has an independent four-wheel drive solution, then it is definitely not an integrated four-wheel drive solution, and if it has an integrated four-wheel drive solution, then it is definitely not an independent four-wheel drive solution.
[0042] To prevent the entire vehicle from being flashed with both independent and integrated four-wheel drive, a "no ECU" option would be added to the conventional logic. For example, the independent four-wheel drive system would recognize the EAV10 characteristic value of the integrated four-wheel drive. If the vehicle has the EAV10 characteristic value, then the independent four-wheel drive ECU would be set to "no," and the independent four-wheel drive configuration word would not be flashed. To solve the above problem, this solution adopts the following approach: 1. Split the configuration font library 1) The four-wheel drive system is configured with two sets of configuration fonts, which are bound to the corresponding special values in the configuration table. One set is for independent four-wheel drive and the other is for integrated four-wheel drive. 2) Based on the actual configuration of the vehicle, the designers built the configuration font library for each project. For independent four-wheel drive solution models, they built an independent four-wheel drive configuration font library, and for integrated four-wheel drive solution models, they built an integrated solution configuration font library. 3) Remove ECU mutual exclusion lock, and do not bind the independent four-wheel drive configuration font library and the integrated four-wheel drive configuration font library with the "ECU None" option.
[0043] Using the above development strategy, even if the project team builds the configuration table incorrectly, it will not cause batch problems. This is because the configuration character sets for the independent four-wheel drive solution and the integrated four-wheel drive solution are already distinguished, and there is no mutual exclusion between them, so errors will not occur. 2. Set different eigenvalues The feature values in the configuration character library of independent four-wheel drive and integrated four-wheel drive are designed differently. They use different configuration character encoding logic. For example, independent four-wheel drive recognizes positions 1-3 of the vehicle configuration character, while integrated four-wheel drive recognizes positions 4-6 of the vehicle configuration character. The two do not overlap. In this example, the independent four-wheel drive solution recognizes byte 0 and byte 1 and byte 3 of the vehicle configuration character, which represent the project code, engine number and transmission number, respectively. The integrated four-wheel drive solution recognizes byte 2 of the vehicle configuration character library, which represents the transfer case type and differential lock type of the vehicle.
[0044] 3. Add error-proofing identification technology First, the OEM flashing equipment adds a four-wheel drive configuration word detection logic; the equipment sends 22F1C5 before flashing the configuration word; if a 00 response is received from the four-wheel drive controller, it indicates that this model is actually equipped with an independent four-wheel drive solution; if a 01 response is received from the four-wheel drive controller, it indicates that this model is actually equipped with an integrated four-wheel drive solution; if no response is received from the four-wheel drive controller within 5 seconds, it indicates a fault in the surface circuit.
[0045] (1) The device will receive the four-wheel drive controller's reply command and compare it with the actual information in the configuration table, performing the logical comparison as shown in Table 1 before flashing: Table 1 Comparison before flashing
[0046] (2) Add prompts for OEM equipment When the information is inconsistent, the OEM equipment will display a four-wheel drive flashing failure message. The flashing slip will indicate a four-wheel drive flashing error. The negative response code NRC35 can be found in the equipment backend, indicating that the configuration word flashing failed. (3) Post-flash test The four-wheel drive software adds configuration character recognition technology. After the configuration character is recognized and the flashing is completed, the four-wheel drive software starts a self-test program and sends 22F1C6 to request the device to reply with the project configuration table information. The logic of testing after flashing is compared according to Table 2. If the device replies with 00, it means that the project configuration table of this model is an independent four-wheel drive solution; if the device replies with 01, it means that the project configuration table of this model is an integrated four-wheel drive solution.
[0047] Table 2 Logic Comparison After Flashing
[0048] (4) Error prevention reminder for four-wheel drive software The vehicle is now configured with a new signal A - a four-wheel drive configuration error warning signal; Signal A=0x0, four-wheel drive configuration is correct, no special indication on the instrument panel; Signal A=0x1, four-wheel drive configuration word error, instrument execution prompt "four-wheel drive system configuration word error", forced prompt.
[0049] If signal A = 0x1 is encountered, signal A will continue to maintain this state until the following conditions are met: 1) New configuration word flashing detected; 2) After executing 22F1C6 again, the comparison was successful.
[0050] If both 1 and 2 above are satisfied, the state of signal A can be restored to A=0x0; otherwise, signal A=0x1.
[0051] Optionally, before specifying the specified feature value corresponding to the specified vehicle, a corresponding configuration font library can be set based on the vehicle's drive type, and a corresponding feature value can be set for each of the configuration font libraries.
[0052] It's important to note that, firstly, all possible vehicle drive types on the production line must be defined and enumerated (e.g., two-wheel drive, independent four-wheel drive, integrated four-wheel drive, etc.). For each defined drive type, technicians need to compile or generate a complete set of corresponding software data packages, i.e., a configuration font library. Subsequently, the system assigns a unique and fixed identifier, i.e., a feature value, to each configuration font library (e.g., assigning the feature value "EAV10" to the configuration font library for the "integrated four-wheel drive" drive type). Finally, this set of rules, defining the strict mapping relationship between drive types, configuration font libraries, and feature values, will be completely and accurately entered into the vehicle's configuration table database, serving as the authoritative basis for all subsequent production flashing activities.
[0053] It should be noted that this application systematically establishes and divides the configuration font library and its feature values based on the actual drive type of the vehicle at the initial stage of the flashing process. This lays an accurate and structured data foundation for the entire subsequent flashing process. This preliminary standardization work ensures that the feature values can be truly and uniquely mapped to the specific hardware configuration, thereby avoiding subsequent identification and flashing errors that may be caused by confusion or misalignment between the configuration font library and the drive type definition. This greatly improves the standardization and reliability of the entire configuration management system.
[0054] Optionally, the feature values corresponding to each of the configuration character libraries are configured with different configuration character encoding logic based on the driver type, and the configuration character encoding logic includes the configuration character encoding position.
[0055] It should be noted that while creating configuration word libraries and assigning feature values for different driver types, system designers need to predefine a dedicated configuration word encoding logic for each driver type. One of the core rules of this logic is to clearly define the storage location of all relevant data under that driver type in the configuration word library, i.e., the configuration word encoding location.
[0056] For example, for the "integrated four-wheel drive" drive type, the configuration word encoding logic strictly stipulates that the "four-wheel drive controller model" information must be stored in the Nth byte of the configuration word library, and the "torque distribution strategy" information must be stored in the Mth byte. This differentiated design rule for different drive types and their data storage locations will be synchronously integrated into the configuration table construction rules, ensuring clear isolation and accurate identification of the configuration word libraries for each drive type from the source of the data structure, providing an unambiguous data foundation for subsequent queries, comparisons, and flashing.
[0057] It should be noted that this application sets configuration word encoding logic with specific encoding positions for different driver types, so that each driver configuration has its own unique and structured digital identity in the configuration word library. This strict distinction from content to form fundamentally eliminates the possibility of confusion between configuration words of different driver types at the encoding level, and provides a clear and unambiguous data source for all subsequent feature-based identification, comparison and writing operations, thereby greatly enhancing the accuracy and robustness of the entire writing system when dealing with complex configuration variations.
[0058] Optionally, if the first drive type is inconsistent with the second drive type, a retest verification process is executed. During the retest verification process, a new specified feature value corresponding to the specified vehicle can be re-determined; a flashing verification command can be re-sent to the drive controller of the specified vehicle, and a new verification response command can be received from the drive controller; a third drive type corresponding to the new specified feature value can be determined, and a fourth drive type corresponding to the new verification response command can be determined; the third drive type and the fourth drive type can be compared to see if they are consistent; if they are inconsistent, it is determined whether the number of times the retest verification process has been executed has reached a first preset number, which is configured based on the vehicle model, communication protocol, or flashing environment parameters; if so, it is displayed that the flashing of the specified vehicle configuration font library has failed.
[0059] It should be noted that when step S104 finds an inconsistency between the first and second drive types, the system automatically initiates a retest verification process. The system does not immediately declare failure; instead, it first attempts to redetermine the new specified characteristic value corresponding to the vehicle (e.g., by re-querying the vehicle configuration database or requesting manual input confirmation). Subsequently, the system resends the flash verification command to the vehicle's drive controller and receives the new verification response command. The system then processes these two pieces of new information in parallel: on one hand, it parses the new specified characteristic value to obtain the third drive type (the new theoretical value); on the other hand, it parses the new verification response command to obtain the fourth drive type (the new physical feedback value). Finally, the system performs a consistency comparison between the third and fourth drive types. If the comparison result is still inconsistent, the system uses a retry counter to determine the outcome. The retry counter records the cumulative number of times the "retest verification process" has been executed for the specified vehicle. When the comparison result is again inconsistent, the system reads the value of this counter. Simultaneously, the system will look up or calculate the corresponding "first preset number of attempts" from a preset configuration rule table based on the vehicle model, the current communication protocol version, and real-time flashing environment parameters (such as network load estimates). Then, the system compares the current number of retries with this "first preset number of attempts" in the dynamic or static configuration. If the condition is met (i.e., the number of retries has reached or exceeded the first preset number of attempts), the system's main control program will ultimately determine that the vehicle's configuration font flashing has failed and will report or display this result. This verification mechanism aims to eliminate temporary communication or data reading errors that may occur during the initial comparison, ensuring the accuracy of fault diagnosis.
[0060] It should be noted that this application introduces a retest verification process. When the initial drive type comparison is inconsistent, it does not immediately determine that the flashing has failed. Instead, the system automatically reacquires vehicle characteristic values and drive controller verification information, performing multiple comparisons and verifications. This mechanism effectively distinguishes between transient errors (such as communication interference, signal jitter, or temporary hardware response delays) and permanent configuration errors. By dynamically configuring the first preset number of retries based on vehicle model, communication protocol, or flashing environment parameters, the system can adaptively adjust the retry strategy, avoiding false failures due to occasional problems and preventing infinite loops when genuine configuration conflicts exist. An error is only finally reported after the preset number of retries has been reached and inconsistencies still exist. This process ensures fault tolerance for intermittent faults, significantly reducing flashing interruptions caused by temporary anomalies, improving production line continuity and efficiency, and maintaining the system's reliability and robustness in complex industrial environments.
[0061] Optionally, when the display shows that the flashing of the specified vehicle configuration font failed, it can display that the drive type comparison of the specified vehicle failed. Please confirm whether the new specified feature value corresponding to the specified vehicle is correct, or check whether the drive controller of the specified vehicle has been modified.
[0062] It should be noted that after the system executes the aforementioned process and ultimately determines that the flashing of the specified vehicle's configuration font library has failed, the system displays this final result on the human-machine interface. The displayed prompt information must include two core parts: first, a clear statement of the nature of the fault, namely "drive type comparison failed"; second, two clearly directional troubleshooting suggestions. The first suggestion guides the operator to "confirm whether the new specified characteristic value corresponding to the specified vehicle is correct," which requires them to trace back to the source such as the configuration table database to verify the accuracy of the data definition; the second suggestion guides the operator to "check whether the specified vehicle has undergone the drive controller modification," which requires them to verify on-site whether the vehicle's hardware status is consistent with the factory default status and whether there have been any subsequent changes. This implementation plan ensures that the fault information is not only a result status but also a clear action instruction, directly guiding the subsequent troubleshooting direction.
[0063] It should be noted that when the system ultimately determines that the vehicle flashing has failed, this application can provide operators with clear and instructive fault location information. It not only points out the failure of the drive type comparison, but more importantly, it directly indicates the two most likely causes: configuration feature value setting problems or abnormal vehicle hardware modifications. This precise prompt greatly reduces the time and effort required for on-site personnel to troubleshoot and solve problems, effectively avoids production line stoppages or repeated trial and error due to unclear causes of problems, and significantly improves the efficiency of handling production anomalies and the success rate of first-time repairs.
[0064] Optionally, after flashing the specified vehicle based on the specified configuration font library, a flashing self-test command can be sent to the drive controller, and a self-test reply command can be received from the drive controller; the fifth drive type that has been flashed on the specified vehicle can be determined, and the sixth drive type corresponding to the self-test reply command can be determined; the fifth drive type and the sixth drive type can be compared to see if they are consistent; if they are consistent, the configuration font library flashing self-test of the specified vehicle can be completed.
[0065] It should be noted that after flashing the software of all controllers on a specified vehicle based on the specified configuration font, the system does not immediately end the process. Instead, it automatically initiates a flashing self-test. The system will again send a specific flashing self-test command to the vehicle's drive controller through the diagnostic interface, requesting it to report its current operating status. Upon receiving this command, the drive controller will assemble its currently active software configuration or hardware identifier into a self-test response command and send it back to the system, using this information as feedback.
[0066] The system then processes two pieces of information in parallel: on the one hand, it parses out the expected fifth drive type based on the content defined by the specified configuration font that was just flashed into the vehicle; on the other hand, it parses the received self-test response command and extracts the sixth drive type actually reported by the controller.
[0067] The system then performs a final consistency comparison between the fifth drive type (expected state) and the sixth drive type (actual state). If the comparison results match, the system determines that the flashing operation was completely successful and completes its self-check, marking the end of the entire flashing process. This step constitutes the final quality checkpoint to ensure the accuracy of software flashing.
[0068] It should be noted that this application adds a self-check verification step with the drive controller immediately after the software flashing is completed. This step verifies the final consistency between the drive type defined in the newly flashed configuration font and the actual drive type fed back by the controller. This creates a final reliable quality defense before the vehicle rolls off the production line, ensuring that the actual effect of each flashing operation is verified in a closed loop. This effectively prevents the potential risk of "flashing successfully but actually failing" due to unknown errors in the flashing process or incomplete data transmission, greatly improving the final reliability of the vehicle software flashing and the factory quality assurance.
[0069] Optionally, if the fifth drive type is inconsistent with the sixth drive type, a retry self-test process is executed. During the retry self-test process, a flashing self-test command can be resent to the drive controller, and a new self-test response command can be received from the drive controller. The seventh drive type that has been flashed for the specified vehicle is re-determined, and the eighth drive type corresponding to the new self-test response command is determined. The seventh drive type and the eighth drive type are compared to see if they are consistent. If they are inconsistent, it is determined whether the number of times the retry self-test process has been executed has reached a second preset number, which is configured based on the vehicle model, communication protocol, or flashing environment parameters. If so, an error is displayed indicating that the specified vehicle configuration font flashing is incorrect.
[0070] It should be noted that when the self-test after flashing detects a discrepancy between the fifth and sixth drive types, the system automatically initiates a retry self-test process. During the retry self-test process, the system first resends the flashing self-test command to the vehicle's drive controller and receives the new self-test response command returned by it.
[0071] The system then processes two pieces of information in parallel: on the one hand, it reconfirms the content defined by the specified configuration font that was just flashed and parses out the expected seventh drive type (whose value should be the same as the fifth drive type); on the other hand, it parses the new self-test response command received and extracts the eighth drive type actually reported by the controller in this query.
[0072] Finally, the system performs a final consistency comparison between the seventh drive type (the expected state confirmed again) and the eighth drive type (the actual state acquired again). If the comparison result is still inconsistent, the system makes a judgment based on the retry counter used for self-testing. The retry counter records the cumulative number of times the "retry self-test process" is executed for the specified vehicle. When the comparison result is "inconsistent" again, the system reads the value of this counter. At the same time, the system retrieves the corresponding "second preset number of attempts" from a preset configuration rule table based on the vehicle model, the communication protocol version used, and the real-time flashing environment parameters. The system compares the current number of self-test retry attempts with this "second preset number of attempts." If the judgment condition is met (i.e., the number of self-test retry attempts has reached or exceeded the second preset number of attempts), the system main control program ultimately determines that there is a substantial error in this flashing operation and displays a flashing error message for the specified vehicle's configuration font library. This verification mechanism aims to eliminate transient communication or controller response errors that may occur during the initial self-test, ensuring the ultimate accuracy of the flashing failure judgment.
[0073] It should be noted that this application introduces a retry self-test process to perform a secondary verification of the drive type of the flashed vehicle after the final flashing operation. When it is detected that the actual flashed drive type of the vehicle is inconsistent with the drive type reported by the drive controller, multiple verifications are performed through a retry mechanism intelligently set based on the specific vehicle model, communication protocol, and real-time flashing environment. This design enables the system to effectively filter out the risk of misjudgment caused by occasional interference such as the momentary instability of the controller during the restart process after flashing and the brief congestion of bus communication. It ensures that only when the inconsistency is confirmed as a persistent hardware configuration error or a substantial defect in the flashing itself is it finally judged as a flashing error. This greatly reduces the probability of falsely reporting a vehicle in a normal self-test transition state as a faulty vehicle, improves the accuracy of the quality inspection process, effectively prevents the misinterpretation of qualified products and unnecessary rework, and ensures the smoothness of the production line and the reliability of the final product delivery.
[0074] Figure 2 The present application provides a schematic diagram of a vehicle configuration font writing device, which includes: a feature value determination unit 201, a receiving unit 202, a type determination unit 203, a comparison unit 204, and a writing unit 205.
[0075] The feature value determination unit 201 determines the specified feature value corresponding to the specified vehicle when the specified vehicle is being configured with a font library. The instruction sending unit 202 sends a flashing verification instruction to the drive controller of the designated vehicle and receives a verification reply instruction from the drive controller. The type determination unit 203 determines the first driving type corresponding to the specified feature value and the second driving type corresponding to the verification response instruction; Comparison unit 204 compares whether the first drive type and the second drive type are consistent; If the two drive types are consistent, the flashing unit 205 determines the specified configuration font library for the specified vehicle based on the first drive type or the second drive type, and flashes the specified vehicle based on the specified configuration font library.
[0076] Figure 3 A structural schematic diagram of a vehicle-configured font writing device provided in this application includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.
[0077] A non-volatile computer storage medium storing computer-executable instructions, which, when executed by a computer, can achieve the following: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.
[0078] 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, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0079] 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, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0080] Those skilled in the art will 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, or a combination of computer software and electronic hardware. 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 implementation should not be considered beyond the scope of this application.
[0081] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0082] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.
[0083] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The aforementioned units can be implemented in hardware or software.
[0084] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.
[0085] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A method for flashing a vehicle's configuration font library, characterized in that, The method includes: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.
2. The method according to claim 1, characterized in that, Before specifying the characteristic value corresponding to the specified vehicle, the method further includes: The corresponding configuration font library is set according to the vehicle's drive type, and the corresponding feature value is set for each configuration font library.
3. The method according to claim 2, characterized in that, The feature values corresponding to each of the configuration character libraries are set with different configuration character encoding logic based on the driver type. The configuration character encoding logic includes the configuration character encoding position.
4. The method according to claim 1, characterized in that, If the first driver type and the second driver type are inconsistent, the method further includes: Perform a retest verification process; The retesting process includes: Redetermine the new specified feature value corresponding to the specified vehicle; The flashing verification command is resent to the drive controller of the specified vehicle, and a new verification response command is received from the drive controller. Determine the third drive type corresponding to the newly specified feature value, and determine the fourth drive type corresponding to the new verification response instruction; Compare whether the third drive type and the fourth drive type are consistent; If there is a discrepancy, determine whether the number of times the retest verification process has been executed has reached a first preset number. The first preset number is configured based on the vehicle model, communication protocol, or flashing environment parameters. If so, it will display a message indicating that the specified vehicle configuration font flashing failed.
5. The method according to claim 4, characterized in that, The message indicating that the specified vehicle configuration font flashing failed includes: The drive type comparison for the specified vehicle failed. Please confirm whether the new specified feature value corresponding to the specified vehicle is correct, or check whether the drive controller of the specified vehicle has been modified.
6. The method according to claim 1, characterized in that, After flashing the specified vehicle based on the specified configuration font library, the method further includes: Send a flash self-test command to the drive controller and receive a self-test response command from the drive controller; Determine the fifth drive type that the specified vehicle has been flashed, and determine the sixth drive type corresponding to the self-test response command; Compare whether the fifth drive type and the sixth drive type are consistent; If they match, complete the configuration font flashing self-test for the specified vehicle.
7. The method according to claim 6, characterized in that, If the fifth drive type is inconsistent with the sixth drive type, the method further includes: Execute the retry self-test process; The retry self-test process includes: The flash self-test command is resent to the drive controller, and a new self-test response command is received from the drive controller; Re-determine the seventh drive type that has been flashed for the specified vehicle, and determine the eighth drive type corresponding to the new self-test response command; Compare whether the seventh drive type and the eighth drive type are consistent; If there is a discrepancy, determine whether the number of times the retry self-test process has been executed has reached the second preset number. The second preset number is configured based on the vehicle model, communication protocol, or flashing environment parameters. If so, it will display a message indicating a problem with the specified vehicle configuration font flashing.
8. A vehicle-configured font writing device, characterized in that, include: The feature value determination unit determines the specified feature value corresponding to the specified vehicle when the specified vehicle is being configured with a font library. The instruction sending unit sends a flashing verification instruction to the drive controller of the designated vehicle and receives a verification response instruction from the drive controller. The type determination unit determines the first driving type corresponding to the specified feature value and the second driving type corresponding to the verification response instruction. The comparison unit compares whether the first drive type and the second drive type are consistent; If the flashing unit matches, it determines the specified configuration font library for the specified vehicle based on the first drive type or the second drive type, and flashes the specified vehicle based on the specified configuration font library.
9. A vehicle-configured font writing device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.
10. A non-volatile computer storage medium, characterized in that, It stores computer-executable instructions, which, when executed by a computer, can achieve the following: When flashing the configuration font library for a designated vehicle, a specified feature value corresponding to the designated vehicle is determined; Send a flashing verification command to the drive controller of the specified vehicle, and receive a verification response command from the drive controller; Determine the first drive type corresponding to the specified feature value, and determine the second drive type corresponding to the verification response instruction; Compare whether the first driver type and the second driver type are consistent; If they match, the specified configuration font library for the specified vehicle is determined based on the first drive type or the second drive type, and the specified vehicle is flashed based on the specified configuration font library.