Adaptive programming method, device, medium and diagnostic terminal for vehicle ecu

Abstract

The application discloses a kind of adaptive programming method, device, medium and diagnostic terminal of vehicle ECU, it is related to vehicle diagnostic technical field.By diagnostic interface, the identity information of target vehicle is obtained, and the identity information contains vehicle type information and platform identifier;When vehicle type information is second vehicle type information, whether target vehicle belongs to the jointly developed vehicle of platform shared with the first vehicle type information vehicle type is judged according to platform identifier;If yes, then according to second vehicle type information, corresponding configuration strategy is extracted, and by hot replacement diagnostic protocol parameter, instantiation independent security access algorithm container and loading brand custom interface element resource, virtual configuration layer is dynamically formed;Based on the virtual configuration layer, diagnostic session is established, security unlocking is executed and ECU programming operation is completed.This method enables single brand diagnostic software to be compatible with the programming operation of other brand vehicles on the same platform, reduces the development and maintenance cost of multi-brand diagnostic tools, and improves the operation convenience.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to an adaptive programming method, device, medium and diagnostic terminal for a vehicle ECU. Background Technology

[0002] In the platform-based development model of automobiles, it has become common practice for different automakers to jointly develop a shared platform based on the same E / E architecture (Electrical / Electronic Architecture). Under this model, vehicles from different brands on the same platform may differ in diagnostic protocol parameters, secure access mechanisms, and electronic / electrical architecture definitions.

[0003] Diagnostic terminals and their running diagnostic software are typically developed by a specific automaker for its own brand of vehicles, with internally fixed communication parameters and safety logic tailored to that brand. When this diagnostic software is used on vehicles from other brands on the same platform, inconsistencies in protocol parameters or different safety algorithms often lead to diagnostic session establishment failures, preventing the completion of ECU (Electronic Control Unit) programming operations.

[0004] To address this issue, the industry typically develops separate versions of maintenance and diagnostic tools for different brands, resulting in redundant investment of R&D resources and complicated version management. Furthermore, operators must manually consult manuals to obtain the location and wiring methods of the target vehicle's electronic control unit, leading to low efficiency and a high risk of errors.

[0005] Therefore, a diagnostic programming solution that can be compatible with the differences between vehicles of different brands on the same platform is needed to reduce the development burden of multi-brand compatibility and improve ease of operation. Summary of the Invention

[0006] This application provides an adaptive programming method, device, medium, and diagnostic terminal for vehicle ECUs, which solves the technical problem in the prior art where single-brand diagnostic software cannot be compatible with programming operations of other brands of vehicles on the same platform. The technical solution is as follows: In a first aspect, embodiments of this application provide an adaptive programming method for a vehicle ECU, applied to a diagnostic terminal, wherein the diagnostic terminal supports vehicle models with first vehicle model information by default; The method includes: The identity information of the target vehicle is obtained through the diagnostic interface, and the identity information includes vehicle model information and platform identifier. When the vehicle model information is the second vehicle model information, determine whether the target vehicle belongs to a jointly developed vehicle model that shares a platform with the vehicle model of the first vehicle model information based on the platform identifier; If so, the corresponding configuration strategy is extracted based on the second vehicle model information; Based on the configuration strategy, configuration operations are performed to form a virtual configuration layer; the configuration operations include: hot-swapping diagnostic protocol parameters in the communication protocol stack, instantiating an independent security access algorithm container, and loading corresponding brand-customized interface element resources according to the second vehicle model information; A diagnostic session is established with the target vehicle based on the diagnostic protocol parameters in the virtual configuration layer. The secure access algorithm container in the virtual configuration layer is invoked to securely unlock the target vehicle. After secure unlocking, the brand-customized interface elements are invoked to update the human-machine interface of the diagnostic terminal, and ECU programming operations are performed.

[0007] Secondly, embodiments of this application provide an adaptive programming device for a vehicle ECU, the device comprising: The acquisition module is used to acquire the identity information of the target vehicle through the diagnostic interface. The identity information includes vehicle model information and platform identifier. The judgment module is used to determine whether the target vehicle belongs to a jointly developed vehicle that shares a platform with the vehicle in the first vehicle information when the vehicle information is the second vehicle information; The acquisition module is further configured to extract the corresponding configuration strategy based on the second vehicle model information if the condition is met. The generation module is used to perform configuration operations based on the configuration strategy to form a virtual configuration layer; the configuration operations include: hot-swapping diagnostic protocol parameters in the communication protocol stack, instantiating an independent security access algorithm container, and loading corresponding brand-customized interface element resources according to the second vehicle model information; A module is established to establish a diagnostic session with the target vehicle based on the diagnostic protocol parameters in the virtual configuration layer. The unlocking module is used to invoke the secure access algorithm container in the virtual configuration layer to securely unlock the target vehicle. The programming module is used to update the human-machine interface of the diagnostic terminal by calling the brand-customized interface element resources after secure unlocking, and to perform ECU programming operations.

[0008] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0009] Fourthly, embodiments of this application provide a diagnostic terminal, which may include: a processor and a memory; wherein the memory stores a computer program, the computer program being adapted to be loaded by the processor and to execute the above-described method steps.

[0010] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: The diagnostic terminal, while defaulting to supporting the first vehicle model information, can automatically identify whether the connected vehicle is a second vehicle model information jointly developed with the same platform. Upon confirmation of a jointly developed vehicle model, the diagnostic terminal extracts the corresponding configuration strategy based on the second vehicle model information and dynamically constructs a virtual configuration layer without restarting the diagnostic software kernel. This is achieved through hot-swapping diagnostic protocol parameters, instantiating an independent secure access algorithm container, and loading brand-customized interface element resources. This virtual configuration layer shields the configuration differences between different vehicle brands in terms of diagnostic protocol, security algorithm, and human-machine interface, enabling diagnostic software that was originally only compatible with the first vehicle model information to be directly compatible with vehicles using the second vehicle model information.

[0011] Thanks to the hot-swap mechanism for diagnostic protocol parameters, the same core engine of diagnostic software can adapt to different communication protocols without requiring separate versions for different brands, significantly reducing software development and version management costs in multi-brand collaborative development models. Independently instantiated secure access algorithm containers encapsulate the key generation logic of different brands in isolated runtime environments, avoiding algorithm cross-interference and ensuring reliable execution of the secure unlocking process across brands. The use of brand-customized interface elements allows the human-machine interface to automatically switch according to the vehicle model, providing operators with an operating environment that conforms to the characteristics of the target brand and reducing the risk of misoperation.

[0012] In summary, this application solves the problem that single-brand diagnostic software cannot be directly compatible with the programming and operation differences of other brands' vehicles on the same platform through a dynamic adaptation mechanism driven by configuration strategy. It achieves a comprehensive technical effect of reusing R&D resources, improving ease of operation, and enhancing cross-brand compatibility. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram of the system architecture provided in the embodiments of this application; Figure 2 This is a flowchart illustrating an adaptive programming method for a vehicle ECU provided in an embodiment of this application; Figure 3 This is a schematic flowchart of the method for determining jointly developed vehicle models provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of an adaptive programming device for a vehicle ECU provided in this application; Figure 5 This is a schematic diagram of a computer storage medium provided in this application; Figure 6 This is a schematic diagram of the structure of a diagnostic terminal provided in this application. Detailed Implementation

[0015] 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.

[0016] It should be noted that the adaptive programming method for vehicle ECUs provided in this application is generally executed by a diagnostic terminal, and correspondingly, the adaptive programming device for vehicle ECUs is generally located in the diagnostic terminal.

[0017] Figure 1 An exemplary system architecture is shown that can be applied to the adaptive programming method of the vehicle ECU or the processing device for vehicle diagnostic data in this application.

[0018] Specifically, the system architecture includes: diagnostic terminal 100, cloud server 101, and target vehicle 102.

[0019] The diagnostic terminal 100 is the main execution body of the method of this invention, and has a processor, memory, communication interface, and human-machine interface. This diagnostic terminal runs diagnostic software from vehicle manufacturer A, and its internal components include a joint development platform mapping library, configuration strategy library, vehicle interior layout data, and safety algorithm modules. The diagnostic terminal 100 establishes a wired connection with the target vehicle 102 via the OBD (On-Board Diagnostics) interface, and can also establish a wireless or wired connection with the cloud server 101 via the network. Its core function is to automatically identify the target vehicle's model information and platform identifier, dynamically load the adapted virtual configuration layer, and perform scenario-based ECU programming operations.

[0020] Cloud server 101 is a remote data processing center deployed on the network side, maintained by Automaker A or its joint development partners. This server stores ECU firmware data packages awaiting updates, the latest version of the joint development platform mapping library, configuration strategy update files for each vehicle model, and a database of archived test reports. Cloud server 101 and diagnostic terminal 100 interact bidirectionally via a network connection. Cloud server 101 responds to requests from diagnostic terminal 100 by sending firmware and configuration files, and receives programming results and test reports uploaded by diagnostic terminal 100. The existence of cloud server 101 enables diagnostic terminal 100 to obtain the latest compatibility data and firmware resources without frequently changing local storage media.

[0021] The target vehicle 102 is the vehicle entity to be programmed by the ECU. In a typical scenario of this solution, it is a D model launched by automaker B based on platform C. The target vehicle 102 contains an OBD interface, an in-vehicle communication network, and multiple ECUs, at least one of which is the target ECU for this programming operation. The target vehicle 102 receives diagnostic requests and programming instructions sent by the diagnostic terminal 100 through the OBD interface and executes corresponding response actions, such as returning the VIN (Vehicle Identification Number) code, platform identifier, seed value, and receiving and writing firmware data in programming mode. After programming is completed, the ECU of the target vehicle 102 can also respond to a functional smoke test command, drive specific actuator actions, and return the execution results to the diagnostic terminal 100.

[0022] It should be understood that Figure 1 The number of diagnostic terminals, networks, and servers shown is for illustrative purposes only. The number of diagnostic terminals, networks, and servers can be any number, depending on the implementation requirements.

[0023] The following will be combined with the appendix Figure 2 This application provides a detailed description of the adaptive programming method for a vehicle ECU according to embodiments of the present application. The adaptive programming device for the vehicle ECU in these embodiments can be... Figure 1 The diagnostic terminal shown.

[0024] Please see Figure 2 This is a flowchart illustrating an adaptive programming method for a vehicle ECU, as provided in this application embodiment. Figure 2 As shown, the method described in this application embodiment may include the following steps: S1. Obtain the target vehicle's identity information through the diagnostic interface. The identity information includes vehicle model information and platform identifier.

[0025] The diagnostic terminal reads the target vehicle's identity information, including vehicle model information and platform identifier, through a diagnostic interface. Following diagnostic communication standards, it sends a request to the vehicle network to read the VIN code and parses the returned data to extract vehicle model information, such as manufacturer and model series. Simultaneously, it obtains the development platform identifier upon which the target vehicle is based by reading platform identification data stored in a specific ECU of the vehicle or executing a platform query routine. The vehicle model information distinguishes the brand and model of the target vehicle, while the platform identifier reflects the common attributes of its underlying electronic and electrical architecture.

[0026] For example, by sending a standard diagnostic service to the gateway or engine control unit via the OBD interface and obtaining the 17-digit VIN code, the first three digits are parsed to identify the manufacturer (B) and the model (D) as the vehicle type code, thus confirming the vehicle information as manufacturer B, model D. A request to read a specified data identifier or execute input / output control is then sent, and the platform code (C platform) is extracted from the response. Based on this, the vehicle type information (BD model) and the platform identifier (C platform) are obtained.

[0027] S2. When the vehicle model information is the second vehicle model information, determine whether the target vehicle belongs to a jointly developed vehicle model that shares a platform with the vehicle model information of the first vehicle model information based on the platform identifier.

[0028] When the obtained vehicle model information is a second vehicle model information that differs from the natively adapted vehicle model of the diagnostic terminal, the platform identifier is used to determine whether the target vehicle belongs to a jointly developed vehicle model. The diagnostic terminal's memory pre-stores first vehicle model information, which corresponds to the first brand vehicle model supported by default by the diagnostic software. The obtained vehicle model information is compared with the first vehicle model information; if they do not match, the vehicle model information belongs to the second vehicle model information. Next, the built-in joint development mapping table is accessed. This mapping table defines which platform identifiers correspond to joint development projects and records the vehicle models of each brand participating in the joint development. The platform identifier is used to search the mapping table. If the search result shows that the platform identifier is the same as the platform corresponding to the first vehicle model information, and the brand corresponding to the second vehicle model information is within the cooperation list, then the target vehicle is determined to be a jointly developed vehicle model that shares a platform with the vehicle model information in the first vehicle model information.

[0029] In one example, the first vehicle model information is set as model A of automaker A. The identified target vehicle model information is model D of automaker B. The two are different, and model D belongs to the second vehicle model information. The joint development mapping table is queried using the platform identifier C. The table records that platform C is jointly developed by automakers A and B, and model D of automaker B is included in the table. Therefore, model D is determined to be a jointly developed model that shares a platform with model A, triggering cross-brand collaborative processing.

[0030] S3. If yes, then extract the corresponding configuration strategy based on the second vehicle model information.

[0031] After determining that the target vehicle is a jointly developed model, the corresponding configuration strategy is extracted from the configuration strategy library based on the second vehicle model information. The configuration strategy library is stored locally in the diagnostic terminal's non-volatile memory. This library uses vehicle model information as an index, and each strategy record contains entries such as the diagnostic protocol parameter set, the security access algorithm module identifier, and the call path to the brand interface resource package. The complete configuration strategy data structure is retrieved using the second vehicle model information as the key, providing all the necessary parameters and resource references for the subsequent construction of the virtual configuration layer.

[0032] In one example, using car manufacturer B and model D as the index, a specific entry is found in the configuration policy library. The extracted configuration policy content is: extending the diagnostic session timeout parameter P2 to 100 milliseconds, marking the security access algorithm container as Algo-B-02, and pointing the interface element resource to the path " / skins / brand_b / d_dark". This information is temporarily stored in memory for use in subsequent steps.

[0033] Understandably, when the vehicle model information obtained from the target vehicle is identified as consistent with the first vehicle model information supported by the diagnostic terminal by default, it indicates that the currently connected vehicle is the model natively adapted by the diagnostic software, and there is no need to trigger the cross-brand collaboration mode. At this time, the default configuration parameters corresponding to the first vehicle model information preset within the diagnostic terminal are directly called. These default configuration parameters are already embedded in the basic communication and security modules of the diagnostic software. The processor executes the standard diagnostic session establishment process based on the default configuration parameters, including sending a diagnostic session control request to the target vehicle using the diagnostic protocol parameters corresponding to the first vehicle model information to establish a diagnostic session. Subsequently, the native secure access module built into the diagnostic software is called to send a secure access request to the target vehicle, receive the seed value returned by the target vehicle, and generate a key according to the security algorithm corresponding to the first vehicle model information to complete the secure unlock. After secure unlock, the default interface element resources corresponding to the first vehicle model information are loaded to update the human-machine interface, and the ECU programming operation is executed according to the standard programming process.

[0034] For example, the diagnostic terminal defaults to supporting vehicle model A from manufacturer A as the primary vehicle model information when it leaves the factory. When the target vehicle's model information is read as model A, the terminal directly calls the fixed diagnostic protocol parameters for model A, establishes a diagnostic session at the standard baud rate, uses manufacturer A's native security algorithm to unlock the vehicle, maintains the default style of brand A in the interface, and then completes ECU programming according to the standard procedure.

[0035] S4. Execute configuration operations based on the configuration strategy to form a virtual configuration layer; the configuration operations include: hot-swapping diagnostic protocol parameters in the communication protocol stack, instantiating an independent security access algorithm container, and loading corresponding brand-customized interface element resources according to the second vehicle model information.

[0036] The process involves executing a series of configuration operations based on the extracted configuration strategy to construct a virtual configuration layer matching the target vehicle brand within the diagnostic software environment. All these operations are performed without restarting the diagnostic software kernel. The specific configuration operations include the following three items: First, hot-swapping the diagnostic protocol parameters in the communication protocol stack. This redirects the parameter table pointer currently used by the protocol stack to the parameter set read from the configuration strategy, or directly modifies parameter variables in memory. For example, it updates the service response wait time, error retries, and the format of specific service identifiers for diagnostic session control, enabling the protocol stack to immediately adapt to the target vehicle's communication protocol without interrupting the main program. Second, instantiating an independent secure access algorithm container. This creates a completely new algorithm execution instance in memory, loading the secure access algorithm library specified by the configuration strategy. This library encapsulates the brand-specific seed key generation logic corresponding to the second vehicle model information. This instance is isolated from the algorithm container used by the first vehicle model information to avoid logical cross-interference. Third, based on the second vehicle model information, the corresponding brand-customized interface element resources are loaded. The interface resource package specified by the configuration strategy is read from the file system, and the element data such as icons, color schemes, font styles, and layout templates contained therein are loaded into the graphics resource buffer in memory, ready to replace the current interface display. Through the above operations, a virtual configuration layer that transparently shields brand differences is dynamically generated during software runtime.

[0037] In one example, for vehicle model D, the diagnostic session timeout parameter was modified to 100 milliseconds in the communication protocol stack, and the format identifier for requesting the download service was set to the B-brand specific value 0x35. Simultaneously, a secure access algorithm container object was created in memory, loading a dynamic library containing a B-brand specific cryptographic hash function. This function's seed processing method involves inverting the received seed and then performing an XOR operation. Regarding UI elements, a dark theme resource, including the B-brand logo and rounded button styles, was loaded from the path " / skins / brand_b / d_dark". Throughout the process, the diagnostic software's main interface remained responsive, without any crashes or restarts.

[0038] S5. Establish a diagnostic session with the target vehicle based on the diagnostic protocol parameters in the virtual configuration layer.

[0039] Once the virtual configuration layer is formed, it uses the diagnostic protocol parameters to establish a diagnostic session with the target vehicle. The session establishment interface of the protocol stack is called, and the protocol stack sends a diagnostic session control request to the target ECU based on the updated parameters. The session type and timing carried in the request message follow the specific timing requirements of the D model. The system waits for a positive response from the ECU. If a positive response is received within the specified time, the diagnostic session is successfully established, and subsequent communication will take place within this session channel. If failure occurs due to parameter deviation, a limited number of retries can be performed according to the parameter settings, and the retries also follow the timing requirements of the D model.

[0040] In one example, based on the diagnostic protocol parameters for vehicle model D, an extended diagnostic session request is first sent at a low baud rate. After waiting 100 milliseconds, a positive response byte 0x50 is received from the ECU. Subsequently, a timer period is started to send online tester requests to prevent the session from being automatically closed by the ECU. At this point, a stable diagnostic session conforming to the timing specifications of vehicle manufacturer B is established between the diagnostic terminal and vehicle model D.

[0041] S6. Call the secure access algorithm container in the virtual configuration layer to securely unlock the target vehicle.

[0042] The process involves invoking a secure access algorithm container within the virtual configuration layer to securely unlock the target vehicle. While the diagnostic session remains active, a security access level request is sent to the target ECU. Upon receiving the request, the ECU generates a random seed and returns it via a response message. This seed is extracted and used as input to the instantiated secure access algorithm container. The algorithm container executes the key calculation logic corresponding to the second vehicle model information to generate the corresponding unlock key. This key is then packaged into a secure access response message and sent to the target ECU. The ECU verifies the received key; if it matches the internal calculation result, it returns a positive response, granting programming access. If the initial unlock fails, a retry can be performed according to a preset strategy, or an error can be reported.

[0043] In one example, for vehicle model D, a request of 0x27 0x01 is sent. The ECU returns a seed of 0x4E 6F 76 61. These four bytes are passed to a secure access algorithm container. Following the rules of vehicle manufacturer B, the container first inverts each byte to obtain 0xB1 0x90 0x89 0x9E, then XORs it with a fixed mask of 0x55 to calculate the key 0xE4 0xC5 0xDC 0xCB. After sending the key, the ECU verifies the key and returns 0x67 0x01, indicating successful unlocking.

[0044] S7. After secure unlocking, call the brand-customized interface element resources to update the human-machine interface of the diagnostic terminal and perform ECU programming operations.

[0045] After secure unlocking, the system invokes brand-customized interface elements from the virtual configuration layer to update the diagnostic terminal's human-machine interface, and then performs ECU programming. Previously loaded brand icons, color schemes, and layout templates are applied to the current interface, refreshing the screen display to present the visual style of the B-brand vehicle manufacturer in elements such as operation prompts and progress indicators. Simultaneously, the programming process is initiated. First, a programming mode request is sent to switch the target ECU to online programming mode. Then, firmware data packets are sent in chunks, awaiting positive confirmation from the ECU after each chunk is sent. After data transmission is complete, integrity verification is performed, and an ECU reset command is sent to activate the new firmware. If the ECU supports this, a functional test service can be used to activate specific actuators for rapid verification of the programming results.

[0046] In one example, after the interface update, the diagnostic terminal screen displayed the logo of car manufacturer B and a dark theme prompt: "Upgrading the domain controller for your B brand D vehicle." It then requested entry into a programming session with the ECU. After erasing the old program, the ECU sent the new firmware at a rate of 256 bytes per data block, waiting for confirmation after each block transmission. The final 1MB firmware flashing process took approximately 5 minutes. After flashing, routine control commands were sent to reset the ECU and illuminate specific indicator lights on the dashboard, confirming normal functionality.

[0047] This solution enables diagnostic terminals to automatically identify cross-brand vehicles on the same platform and dynamically reconstruct diagnostic protocols, security algorithms, and human-machine interfaces without restarting the software, forming a virtual configuration environment tailored to specific vehicle models. This allows for fully adaptive processing throughout the entire process, from vehicle identification and secure unlocking to customized programming. This mechanism eliminates the need to develop and maintain separate diagnostic tools for different brands, helping to improve operational efficiency on production lines and in after-sales service, and ensuring consistency and reliability in cross-brand programming.

[0048] In one possible implementation, see Figure 3 As shown, Figure 3 This is a schematic flowchart of the method for determining jointly developed vehicle models provided in this application embodiment, which specifically includes the following steps: S21. Query the pre-set joint development platform mapping library based on the platform identifier; the joint development platform mapping library stores multiple shared platform identifiers and vehicle model information mapping tables associated with each shared platform identifier.

[0049] The diagnostic terminal, after obtaining the platform identifier of the target vehicle, uses this identifier as a query condition to search a joint development platform mapping library pre-stored in the terminal's non-volatile memory. This mapping library is a structured dataset that pre-stores multiple shared platform identifiers developed jointly by different automakers. Each shared platform identifier in the mapping library is associated with an independent vehicle model information mapping table, which records the correspondence and cooperation relationships between various brand vehicle models developed based on this shared platform. The query process involves comparing each obtained platform identifier with the shared platform identifiers stored in the mapping library to determine if they match.

[0050] In one example, the platform identifier read from the target vehicle is the string "C-Platform". Using this string as the key, the joint development platform mapping library is traversed, and it is compared with the first shared platform identifier "Q-Platform" stored in the library. The result is inconsistent; then it is compared with the second shared platform identifier "C-Platform", and the result is consistent, so the query is successful.

[0051] S22. If the platform identifier is the same as any shared platform identifier, obtain the vehicle model information mapping table associated with that shared platform identifier.

[0052] When a shared platform identifier identical to the target vehicle's platform identifier is found in the joint development platform mapping library, the specific vehicle information mapping table is retrieved from the storage medium based on the association between this shared platform identifier and the vehicle information mapping table. This mapping table contains one or more pairs of vehicle information, each pair indicating that, under the premise of sharing the same platform, there is an established fact of collaborative operation between two vehicles from different brands. This vehicle information mapping table is loaded into memory to provide a data foundation for the next step of the judgment process.

[0053] In one example, after the query hits C-Platform, the corresponding vehicle model information mapping table Table-C is read based on the associated pointer in the library. This Table-C contains a pairing record, specifically, the first vehicle model information "Vehicle Model A of Automaker A" and the second vehicle model information "Vehicle Model D of Automaker B" are set as a joint development pairing.

[0054] S23. Determine whether the first vehicle information and the second vehicle information are matched based on the vehicle information mapping table.

[0055] The process involves comparing the previously known first vehicle model information and the currently read second vehicle model information with each pairing recorded in the acquired vehicle model information mapping table. The first vehicle model information is the vehicle model natively adapted to the diagnostic terminal and is pre-stored in the system; the second vehicle model information is the actual vehicle model identifier read from the target vehicle in step S1. The judgment logic is to check whether there exists a pairing in the mapping table such that one vehicle model identifier in the pair matches the first vehicle model information, and the other vehicle model identifier in the pair matches the second vehicle model information. If both conditions are met, the first vehicle model information and the second vehicle model information are determined to be paired in the mapping table; otherwise, they are determined not to be paired.

[0056] In one example, examining the pairing records in the mapping table Table-C reveals a joint pairing of model A from automaker A and model D from automaker B. The known first model information is model A from automaker A, and the known second model information is model D from automaker B. Matching the first model information with the A end of the pairing is successful, and then matching the second model information with the B end of the pairing is also successful. Both conditions are met, therefore the pairing is determined.

[0057] S24. If yes, the target vehicle is determined to be a jointly developed model.

[0058] In step S23, if the result shows that the first vehicle model information and the second vehicle model information form a pair in the vehicle model information mapping table, a final conclusion is drawn, determining that the currently connected target vehicle belongs to a jointly developed vehicle model. This confirmation result will serve as a key process control signal, triggering the cross-brand collaborative processing flow set for the jointly developed vehicle model in subsequent steps, including a series of operations such as extracting specific configuration strategies and loading the virtual configuration layer.

[0059] For example, since model A from automaker A and model D from automaker B are successfully matched in the mapping table, the attributes of the target vehicle model D are marked as a jointly developed model, and then step S3 is entered based on this judgment result to prepare to extract the configuration strategy exclusive to model D.

[0060] S25. If no, the target vehicle is determined not to be a jointly developed model.

[0061] In step S23, if the result is that neither the first nor the second vehicle model information can be matched in the vehicle model information mapping table, or the platform identifier of the target vehicle cannot be found in the mapping library, a final conclusion will be reached: the target vehicle does not belong to the jointly developed vehicle model. At this point, the adaptive recognition process will terminate, and the target vehicle can be treated as an unknown or incompatible vehicle model. For example, a prompt message will be output on the diagnostic terminal interface to inform the operator that the current vehicle is not supported.

[0062] For example, suppose the second model information of the target vehicle is model F of car company E, but the mapping table only has the pairing of model A of car company A and model D of car company B. It is impossible to find any pairing that includes both model A and model F. Therefore, the pairing is determined to be unsuccessful, the target vehicle is determined not to be a jointly developed model, and the screen will display "The current model is not within the scope of collaborative support".

[0063] Through the hierarchical query and pairing judgment mechanism of the aforementioned joint development platform mapping library, the diagnostic terminal can accurately identify vehicles based on the same underlying platform but belonging to different brands, and effectively exclude models outside the scope of cooperation. This not only provides an accurate prerequisite for loading customized configuration strategies in the future, but also avoids protocol failures or flashing faults caused by incorrect matching. Thus, while ensuring the reliability of identification, it achieves intelligent compatibility with multi-brand joint development models.

[0064] In one possible implementation, instantiating a separate secure access algorithm container includes: A1. Obtain the safety algorithm parameters corresponding to the second vehicle model information from the configuration strategy.

[0065] After obtaining the configuration policy corresponding to the second vehicle model information, the diagnostic terminal locates and extracts security algorithm parameters from the multiple entries contained in the configuration policy. The configuration policy, as a pre-defined data structure, includes a dedicated area for storing various parameters required for secure access, in addition to diagnostic protocol parameters and interface resource paths. When parsing the configuration policy, it traverses its entries until it finds the field marked as a security algorithm type, and then reads all parameter values ​​under that field. These security algorithm parameters specifically indicate the encryption algorithm identifier used by the brand to which the second vehicle model information belongs, the mask constant in the seed value processing rules, the number of iterations, and the length of the final key. These parameters are temporarily stored in memory as the direct basis for subsequently generating algorithm instances.

[0066] In one example, the security algorithm parameter block was located in the configuration strategy of model D from car manufacturer B. The algorithm identifier was read as ALGO-07-B, the mask constant was 0x5A, the key length was 4 bytes, and the seed processing order was first inverted and then XORed. These parameters were completely stored in memory variables, awaiting use in the next operation.

[0067] A2. Based on the safety algorithm parameters, create an algorithm instance independent of the first vehicle model information.

[0068] Using the security algorithm parameters obtained in step A1, a completely new algorithm instance, entirely isolated from the algorithm logic used by the first vehicle model information, is constructed in memory. This algorithm instance for the first vehicle model information is loaded and resides in a specific memory area upon startup of the diagnostic terminal, handling the security unlocking calculations for the natively adapted vehicle model. When an algorithm instance needs to be created for the second vehicle model information, an independent memory space is allocated, and within this space, the security algorithm parameters are assigned, the encryption logic functions are bound, and the computation buffer is allocated according to the algorithm framework's interface specifications. This instance has no overlap with the algorithm instance for the first vehicle model information in terms of address space and runtime context. This isolation ensures that the key calculation logic of the two different brands will not interfere with each other due to interleaved function call paths or shared global variables.

[0069] In one example, an algorithm instance serving car model A already exists at memory address 0x1F00, using a mask of 0x37. A new memory space is allocated at memory address 0x3A00, and the pointer to the negation XOR function from the ALGO-07-B algorithm library is written into the function table of this instance. The mask parameter 0x5A is filled into the parameter slot of the instance, thus generating an independent algorithm instance specifically for car model D. This instance does not interact with the instance for car model A in memory.

[0070] A3. Use algorithm instances as containers for secure access to algorithms; The secure access algorithm container is used to: send a secure access request to the target vehicle, receive the seed value returned by the target vehicle, generate a key based on the seed value and the security algorithm parameters, and send the key to the target vehicle to complete the secure unlocking.

[0071] The independent algorithm instance created in step A2 is encapsulated into a fully functional secure access algorithm container, allowing other modules of the diagnostic terminal to use it in standardized calls in subsequent steps. Specifically, the encapsulation involves registering the entry address of the algorithm instance in the diagnostic software's security module scheduling table and assigning a container identifier bound to the second vehicle model information. This container exposes a unified calling interface covering the following three standard actions: sending a secure access request to the target vehicle, receiving the seed value returned by the target vehicle, generating a key based on the seed value and built-in security algorithm parameters, and sending the key to the target vehicle to complete the secure unlock. When other process modules need to perform secure unlocking, they only need to call this interface through the container identifier. The container will automatically drive the encapsulated algorithm instance to execute the brand-specific algorithm logic corresponding to the second vehicle model information, without the caller needing to know the internal algorithm details.

[0072] In one example, the D-model algorithm instance at memory address 0x3A00 is encapsulated into a container and assigned the identifier SEC-D-01. Once the diagnostic session is established, the main control flow sends an unlock command to the SEC-D-01 container. Inside the container, the send interface is first called to send a secure access request 0x27 0x01 to the D-model's ECU. Upon receiving the seed 0x3C 7F 2A 11 returned by the ECU, the container-driven algorithm instance first inverts each byte of the seed to obtain 0xC3 0x80 0xD5 0xEE, then XORs it with the mask 0x5A to finally generate the key 0x99 0xDA 0x8F 0xB4. The container then calls the send interface to send the key. After the ECU verifies the key, it returns 0x67 0x01. The entire secure unlock is completed in a closed loop within the container.

[0073] Through the three steps of parameter acquisition, independent instantiation, and container encapsulation, the diagnostic terminal can dynamically construct mutually isolated security algorithm runtime environments for jointly developed vehicle models from different brands, and expose these environments to the outside world in the form of standardized interfaces. This design allows the core framework of the diagnostic software to be unaware of the differences in security algorithms between brands, and only needs to switch container identifiers to achieve compatibility of a single software with multiple security unlocking logics. While ensuring the security of algorithm isolation, it can reduce the complexity of multi-brand compatible development.

[0074] In one possible implementation, performing ECU programming operations includes: B1. Identify the current operating environment, which is determined based on the user role or system preset.

[0075] Before performing ECU programming, the diagnostic terminal first identifies the current operating environment, which characterizes the usage scenario and operator type. The identification of the operating environment is based on two factors: user role and system presets. User role identification can be achieved in various ways, such as reading the role tag in the account information used to log in to the diagnostic software, detecting the physical position of a specific mode selection switch on the diagnostic terminal, or analyzing the type of currently connected peripheral devices to infer the user's identity; for example, connecting to a production line automation main control device indicates a production environment. System presets are a default environment identifier obtained by the diagnostic terminal at startup by reading configuration files or factory settings. When the user role cannot be clearly obtained, the system preset is used as the operating environment determination. The identified operating environment is mapped to a standardized environment type identifier, such as production line mode, after-sales mode, or user self-service mode, for use in subsequent steps.

[0076] B2. Based on the operating environment, dynamically generate scenario-based programming strategies, including adjusting the verification level of the programming process, the number of concurrent threads, and the information density of the human-computer interaction interface.

[0077] Based on the operating environment identified in step B1, a matching scenario-based programming strategy is dynamically generated. The diagnostic terminal's memory stores a set of strategy templates, one for each operating environment, defining adjustment rules for various parameters of the programming process. Using the operating environment identifier as an index, the corresponding strategy template is read, and the following three aspects are configured in real-time according to the rules in the template: First, the verification level of the programming process is adjusted according to the strategy template, determining whether to perform full data verification, skip the status check of non-critical ECUs, and enable fast handshake mode during the flashing process, thus achieving a balance between efficiency and safety. Second, the number of concurrent threads is adjusted according to the strategy template, adjusting the number of ECUs or data channels processed in parallel. Production line mode tends to maximize concurrency to compress production cycle time, while after-sales mode uses a conservative number of concurrency to ensure the reliability of individual vehicles. Third, the information density of the human-machine interface is set according to the strategy template, including whether to display detailed technical parameters, whether to enable graphical hardware location guidance, and whether to replace technical terms with natural language descriptions. These parameters, adjusted by the strategy template, are assembled into a complete scenario-based programming strategy and temporarily stored in memory as the basis for subsequent programming operations.

[0078] B3. Perform ECU programming operations according to the scenario-based programming strategy.

[0079] Use the scenario-based programming strategy generated in step B2 as an execution blueprint to drive the underlying functional modules of the diagnostic terminal to complete the actual ECU programming operation. First, write the configuration parameters related to the check level in the strategy into the communication and check management module, so that the module performs check or no check according to the set level in the subsequent data transmission. Then, transfer the configuration parameter of the number of concurrent threads to the task scheduler, which creates a corresponding number of working threads or data channels accordingly, and allocates the list of ECUs to be programmed to each thread for parallel or serial processing. Meanwhile, transfer the information density parameter of the human-machine interaction interface to the interface rendering module, which refreshes the screen display according to the set level of detail and presents a corresponding number of text prompts, progress elements or graphic guides. Throughout the entire programming process, continuously monitor whether these configurations take effect, and determine whether to generate a simplified report or a detailed report according to the strategy after programming is completed.

[0080] In a possible embodiment, B2. Dynamically generating a scenario-based programming strategy according to the operating environment, comprising: B21. Acquiring the storage battery voltage of a target vehicle, and generating a power guarantee instruction according to the comparison result between the storage battery voltage and a preset threshold; acquiring ECU position data corresponding to the interior layout of the target vehicle, and generating graphic position guides according to the ECU position data; the scenario-based programming strategy is constituted by the power guarantee instruction and the graphic position guides for display on a human-machine interaction interface.

[0081] When the diagnostic terminal identifies that the operating environment is the after-sales mode, it executes two parallel actions of data acquisition and instruction generation.

[0082] The first one is generating the power guarantee instruction. A request for reading the storage battery voltage is sent to the target vehicle through the diagnostic interface to acquire the real-time voltage value. A minimum voltage threshold for safe flashing is preset in the memory, which is generally determined by the vehicle electrical system specification, for example, 12.5 volts. Compare the acquired voltage value with this threshold. If the voltage value is lower than the threshold, a power guarantee instruction is generated, which includes a start request for an external regulated power supply and a control signal for maintaining voltage stability. If the voltage value is higher than or equal to the threshold, a power guarantee instruction is still generated, but its content is an indication confirming that the voltage is normal and no external intervention is required. This instruction is used on the one hand to drive the linkage control of the diagnostic terminal to external power equipment, and on the other hand it also serves as the content of prompt information on the human-machine interaction interface.

[0083] The second step is to generate graphical location guidance. The diagnostic terminal's memory pre-stores ECU location data for each vehicle's interior layout. This data includes the target ECU's three-dimensional coordinates, external outline, and recommended wiring port locations within the vehicle. Using the second vehicle model information as an index, the ECU location data for the corresponding interior layout of vehicle model D is retrieved from storage. The graphics rendering engine is then invoked to generate one or more graphical guidance images based on this location data. The target ECU is highlighted in the vehicle perspective or interior view, and recommended wiring ports are highlighted with visual elements such as arrows or circles.

[0084] By combining the aforementioned power protection instructions and graphical location guidance, a scenario-based programming strategy suitable for after-sales scenarios is formed, and the interface module is instructed to simultaneously display voltage status prompts and ECU location graphics on the human-machine interface.

[0085] In one example, in a 4S dealership after-sales scenario, the battery voltage was read as 11.8 volts, below the 12.5-volt threshold. A power assurance command, "Low voltage, recommend connecting a voltage regulator," was generated, and a start signal was sent to the networked voltage regulator. Simultaneously, based on data from vehicle model D, a perspective view of the engine compartment was rendered in the center of the screen, highlighting the autonomous driving domain controller in orange and marking the recommended wiring port location near the left side of the firewall with a red arrow. The technician saw both the voltage warning and controller location guidance on the screen, allowing them to quickly locate the ECU and complete the wiring after connecting the voltage regulator.

[0086] B22. Obtain the technical terminology mapping table corresponding to the ECU programming operation, and replace each technical term with natural language prompt text; generate progress indication data containing the estimated remaining time based on the current programming progress; the natural language prompt text and progress indication data constitute a scenario-based programming strategy for display on the human-machine interface.

[0087] When the diagnostic terminal recognizes that the operating environment is in user self-service mode, it will perform two interface optimization actions for non-professional users.

[0088] The first step is to replace technical terms with natural language prompts. The diagnostic terminal's memory contains a pre-installed technical terminology mapping table, stored in a two-column structure. The left column contains various technical terms that may appear during diagnosis and programming, and the right column contains easy-to-understand natural language descriptions corresponding to each term. When generating interface prompts, each word or phrase in the original prompt message is iterated and matched against the left column of the mapping table. Once a match is found, the original terminology is replaced with the natural language description from the right column. If no matching terminology exists in the original prompt message, the original text remains unchanged.

[0089] The second step is to generate progress indication data that includes the estimated remaining time. During programming operations, the amount of firmware data already transferred and the total amount of firmware data to be transferred can be obtained in real time. Based on the current percentage completed and the time elapsed, the average transfer rate is calculated, and then the estimated remaining time is estimated based on this rate and the remaining data volume. The current progress percentage and the estimated remaining time are then packaged into progress indication data.

[0090] By combining the aforementioned natural language prompts and progress indicators, a scenario-based programming strategy suitable for user self-service scenarios is formed, and the indicator interface module presents this information in a concise and user-friendly manner.

[0091] In one example, a car owner remotely upgraded their vehicle (model D) from their own garage. The diagnostic terminal identified it as being in user self-service mode. The original message, "Performing UDS (Unified Diagnostic Services) service 0x34, transmitting data," was replaced with "Updating your driver assistance features" after matching the mapping table. Simultaneously, it calculated that 40 megabytes out of the current 80 megabytes transmitted were 50% complete, taking 4 minutes at an average rate of 10 megabytes per minute. The remaining 40 megabytes were estimated to take another 4 minutes, so a progress bar and the text "Halfway complete, estimated 4 minutes remaining, please do not turn off the engine" were displayed on the screen. The car owner saw a very basic and technical message.

[0092] B23. Set the verification level of the programming process to skip unnecessary verification items; enable the high-speed batch flashing channel and configure the number of concurrent threads to support parallel processing of multiple ECUs; the setting of the verification level and the configuration of the number of concurrent threads constitute a scenario-based programming strategy.

[0093] When the diagnostic terminal identifies the operating environment as production line mode, it will perform two configuration actions with efficiency as the core.

[0094] The first step is to adjust the verification level of the programming process. The diagnostic terminal's memory defines a verification level system, ranging from the highest level of full data byte-by-byte verification to the lowest level of verifying only critical blocks or completely skipping verification. Based on the specific characteristics of the production line scenario, the verification level is set to skip unnecessary verification items. Specifically, this can include disabling intermediate block CRC (Cyclic Redundancy Check) verification during data transmission, performing an overall integrity check only after all data transmission is complete, or completely skipping verification steps for some non-safety-critical ECUs. This setting eliminates the need for the communication module to wait for confirmation and comparison results after each data block transmission during the flashing process, thus significantly reducing the flashing cycle for a single vehicle.

[0095] The second step is to enable the high-speed batch flashing channel and configure the number of concurrent threads. Switch the diagnostic terminal's communication controller to high-throughput mode, such as using the maximum effective bandwidth of CAN-FD (Controller Area Network with Flexible Data-Rate) or Ethernet protocols, and disable diagnostic monitoring functions that may cause communication delays. Simultaneously, issue a concurrent configuration to the task scheduler, setting the number of concurrent threads to support the simultaneous programming of multiple ECUs, such as 4 or 8, enabling the scheduler to manage the erase, download, and reset processes of multiple ECUs simultaneously.

[0096] By combining the above-mentioned verification level settings and concurrent thread configurations, a scenario-based programming strategy suitable for production line scenarios is formed. This strategy is directly distributed to each underlying module without the need to display detailed information on the human-machine interface.

[0097] In one example, on the vehicle production line, the diagnostic terminal identifies the system as being in production line mode and adjusts the verification level to "final verification only." This means that data blocks are sent continuously during the flashing process without waiting for intermediate confirmation; a CRC32 check is performed only once after all firmware downloads are complete. Simultaneously, the number of concurrent threads is set to four, and the task scheduler starts four working threads concurrently to flash the engine ECU, transmission ECU, vehicle stability system ECU, and infotainment ECU in parallel. Throughout the process, the HMI only displays the status indicator lights of the four ECUs; once all lights turn green, the work at that station is complete. The programming cycle time for a single vehicle is reduced from 8 minutes to less than 2 minutes.

[0098] The three strategy generation methods described above target three typical scenarios: after-sales service, user self-service, and production line. By differentiating elements such as power supply assurance, graphical guidance, natural language replacement, progress prediction, verification level adjustment, and concurrent channel configuration, the diagnostic terminal can adaptively output the programming strategy that best suits the current operating environment within the same software framework. This scenario-based adaptation mechanism ensures that the production line meets the requirements of extreme cycle time and batch parallelism, while also taking into account the needs of after-sales maintenance for safety, reliability, and precise positioning, and providing ordinary car owners with a zero-technical-barrier operating experience.

[0099] In one possible implementation, when the diagnostic terminal establishes a diagnostic session with the target vehicle based on diagnostic protocol parameters in the virtual configuration layer, it first performs adaptive detection of communication parameters. The physical layer transceiver controlling the diagnostic interface sequentially attempts different baud rate combinations and protocol types within the target vehicle's supported range. Specifically, it sends a diagnostic activation request to the target vehicle's network at a preset baud rate and listens for a compliant positive response within a specified time. If no response is received within the timeout period, it switches to the next baud rate and continues trying. Upon receiving a correct response, it locks the currently used baud rate as the actual communication rate. Based on the determined baud rate, it further identifies the protocol type used by the target vehicle by sending specific protocol probe frames, such as distinguishing between CAN bus, CAN-FD bus, or automotive Ethernet. Protocol type identification is based on the frame structure, data length, and specific flag bits returned by the target vehicle. After completing the baud rate and protocol type detection, the communication controller's parameter register is configured to match the target vehicle, thus completing the communication parameter adaptation.

[0100] In one example, a diagnostic activation request is initially sent at a baud rate of 500 kilobits per second. If no response is received, the rate is switched to 250 kilobits per second. Still no response is received, so the rate is switched to 1000 kilobits per second, at which point a positive response is received from the target vehicle. The baud rate is then locked at 1000 kilobits per second. Next, a diagnostic request frame supporting the FD format is sent. The target vehicle returns a data field length exceeding 8 bytes, and the FD format flag is valid. Based on this, the protocol type is determined to be CAN-FD, and the communication controller is switched to CAN-FD mode, completing the adaptation.

[0101] The secure access algorithm container in the virtual configuration layer is invoked to securely unlock the target vehicle. This secure access algorithm container, instantiated in steps A1 to A3, encapsulates the security algorithm parameters and key generation logic bound to the second vehicle model information. The first step of the unlocking process is to send a secure access request to the target vehicle's ECU via the secure access algorithm container's sending interface. This request carries the requested security level parameters. Upon receiving the request, the target vehicle's ECU generates a set of random seed values ​​using its internal random number generator and returns these seed values ​​via a diagnostic response message. The seed value is extracted from the response message and passed to the secure access algorithm container. The container executes a specific algorithm corresponding to the second vehicle model information. This algorithm uses the seed value and preset mask constants, transformation rules, and other security algorithm parameters to calculate and generate a set of unlocking keys. These keys are then packaged into a secure access response message and sent to the target vehicle's ECU via the container's sending interface. Upon receiving the key, the ECU performs a verification comparison using the same internal algorithm and parameters. If the calculated key is completely identical to the received key, the secure unlock is considered successful, and a positive response is returned, fully unlocking the ECU's programming permissions.

[0102] In one example, a secure access algorithm container specific to vehicle model D is invoked, sending a request message 0x270x03 to the ECU. The ECU's internal random number generator produces a seed value 0xA1 B2 C3 D4 and returns it. After receiving the seed, the container first performs an XOR operation on each of the four bytes with the mask 0x6C to obtain an intermediate value, then performs a cyclic left shift operation of the intermediate value by 3 bits, finally generating the key 0xD8 5F 2A 97. This key is sent to the ECU, and after the ECU verifies it, it returns 0x67 0x03, indicating that secure unlocking is complete.

[0103] During ECU programming, the network communication status between the diagnostic terminal and the target vehicle is continuously monitored. Monitoring methods include hardware-level bus error interruption detection and software-level periodic heartbeat timeout judgment. When a communication interruption event is detected, such as a bus shutdown due to electromagnetic interference or a momentary loosening of the connector, the current firmware data transmission operation is immediately paused. The address offset, data block sequence number, and session status information of the last data block that has been transmitted are recorded as breakpoint information in the non-volatile memory of the diagnostic terminal. During the communication interruption, continuous attempts are made to re-establish the diagnostic session with the target vehicle ECU. Once the communication link is restored, the previously saved breakpoint information is read first, and then a continuation transmission request with breakpoint location parameters is sent to the target vehicle ECU. The ECU resets its internal write pointer to the memory area corresponding to the breakpoint based on these parameters, and then continues sending firmware data from the next data block at the breakpoint, without needing to retransmit the entire firmware file from the starting address.

[0104] In one example, a 1.5-megabyte firmware file was being sent to the domain controller of vehicle model D. The transmission had successfully reached data block 1536, corresponding to address offset 0x00180000. Suddenly, a momentary loosening of the vehicle battery terminal caused a communication interruption. The bus shutdown flag was captured, and the breakpoint address 0x00180000 and data block number 1536 were immediately written to the diagnostic terminal's flash memory. Communication resumed 2 seconds later, the diagnostic session was re-established, the breakpoint information was read from the flash memory, and a continue download command with address offset 0x00180000 was sent to the ECU. After ECU confirmation, the download resumed from data block 1537, ultimately successfully completing the firmware flashing.

[0105] In one possible implementation, after performing the ECU programming operation, the following is also included: C1. Send a functional smoke test command to the target ECU to drive a specific actuator. After completing the ECU firmware programming and verifying its integrity, the diagnostic terminal sends a functional smoke test command to the target ECU that has just been flashed. Internally, a test command mapping table associated with the second vehicle model information is pre-stored. This table records the quick functional verification items supported by each ECU, such as driving specific indicator lights, controlling window motors, and triggering relays. Based on the type of target ECU involved in this programming, the corresponding test command is selected from the mapping table. Each test command follows the diagnostic service format supported by the target vehicle, essentially requesting the target ECU to perform an input / output control or routine control operation. Through the established diagnostic session channel, the selected test commands are sent one by one to the target ECU, requiring the ECU to drive specific actuators within its jurisdiction to produce a brief, observable action.

[0106] In one example, after flashing the firmware for the autonomous driving domain controller of vehicle model D, two test items are selected from the test command mapping table: the first is to request the domain controller to illuminate the yellow ADAS (Advanced Driver Assistance System) status indicator on the dashboard via the vehicle network; the second is to request the domain controller to energize the windshield camera heating wire for one second. These two procedural control commands are issued sequentially through the diagnostic session, requiring the ECU to immediately execute the corresponding actions.

[0107] C2. Receive the execution results fed back by the executor.

[0108] After sending the functional smoke test command, the system listens on the diagnostic bus and receives the execution results returned by the target ECU. After executing the test command, the target ECU returns a response message according to the diagnostic protocol specifications. A positive response message indicates that the actuator has acted as instructed and is functioning normally, while a negative response message carries a fault code indicating the specific reason for the execution failure, such as an open circuit in the actuator, a response timeout, or temporary unavailability of the function. Furthermore, for some actuator actions that can be indirectly verified by other sensors, objective execution results can be obtained by reading relevant data identifiers. For example, reading the window position status through the body controller can verify whether the window raising / lowering test is effective. All received response codes and read status data are summarized into the execution result set of this functional smoke test.

[0109] In one example, a positive response was received to the ADAS status indicator light illumination command, confirming that the indicator light had been successfully illuminated. However, the camera heating wire test command returned a negative response code 0x31, indicating that the heating wire circuit was currently open-circuited. Simultaneously, the value from the windshield temperature sensor was read as an auxiliary reference, and the positive response, negative response code 0x31, and temperature data were combined to form the complete execution result of this test. C3. Based on the execution results, generate a test report. The test report includes general descriptions of the shared platform and customized confirmation information for the second vehicle model.

[0110] Based on the execution results obtained in step C2, a structured test report is generated. This report consists of two levels of confirmation information. The first part is a general description of the common platform. This part is retrieved from a pre-set report template and uses fixed text paragraphs to describe the consistency of the underlying technology of the C platform on which this programming is based. For example, it explains the compatibility between the firmware version being flashed and the platform's basic software, and the compliance of the standard diagnostic services used with the platform specifications. The aim is to convey to the user the reliability of the underlying technology across brands. The second part is customized confirmation information for the second vehicle model. This part is dynamically populated based on the execution results, organizing data such as the test item name, execution result status, and fault codes when execution fails into a personalized confirmation description for the D vehicle model. The general description and customized confirmation information are combined into a complete test report. This report can be displayed simultaneously on the diagnostic terminal screen and stored in local memory or uploaded to the after-sales service system via a network module.

[0111] In one example, a test report is generated. The general description section states, "This programming is based on the C platform's unified diagnostic protocol stack, and the firmware is fully compatible with the platform's basic software version V3.2." The customized confirmation information section states, "Function verification results after programming the autonomous driving domain controller for B brand D model: The instrument panel ADAS indicator lights illuminate normally, the camera heating circuit response is abnormal, fault code 0x31, it is recommended to check the heating wire connector." The technician, seeing this report on the screen, understands both the general assurance of cross-platform technology and receives specific diagnostic recommendations for their vehicle.

[0112] By automatically performing functional smoke tests and generating tiered test reports after programming is completed, the diagnostic terminal upgrades traditional static data verification to dynamic, functional-level closed-loop verification. This not only confirms the compatibility and consistency of cross-brand shared platforms from a technical perspective, but also provides personalized functional confirmations and fault prompts for specific vehicle models, improving the credibility of the final results for operators and vehicle owners.

[0113] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0114] Please see Figure 4 This illustration shows a schematic diagram of an adaptive programming device for a vehicle ECU provided in an exemplary embodiment of this application, hereinafter referred to as device 4. Device 4 can be implemented as all or part of a diagnostic terminal through software, hardware, or a combination of both. Device 4 includes: The acquisition module 401 is used to acquire the identity information of the target vehicle through the diagnostic interface, the identity information including vehicle model information and platform identifier; The judgment module 402 is used to determine whether the target vehicle belongs to a jointly developed vehicle that shares a platform with the vehicle in the first vehicle information when the vehicle information is the second vehicle information; The acquisition module 401 is further configured to extract the corresponding configuration strategy based on the second vehicle model information if the condition is met. The generation module 403 is used to perform configuration operations based on the configuration strategy to form a virtual configuration layer; the configuration operations include: hot-swapping diagnostic protocol parameters in the communication protocol stack, instantiating an independent security access algorithm container, and loading corresponding brand-customized interface element resources according to the second vehicle model information; Module 404 is established to establish a diagnostic session with the target vehicle based on the diagnostic protocol parameters in the virtual configuration layer. The unlocking module 405 is used to call the secure access algorithm container in the virtual configuration layer to securely unlock the target vehicle. The programming module 406 is used to call the brand-customized interface element resources to update the human-machine interface of the diagnostic terminal and perform ECU programming operations after the security is unlocked.

[0115] For further details regarding the implementation of the above technical solution by each module in the adaptive programming device for the vehicle ECU, please refer to the description in the adaptive programming method for the vehicle ECU provided in the above embodiments of the invention, which will not be repeated here.

[0116] It should be noted that the device 4 provided in the above embodiments, when executing the adaptive programming method for a vehicle ECU, is only illustrated by the division of the above functional modules. In practical 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 above functions. In addition, the adaptive programming device for a vehicle ECU and the adaptive programming method embodiment for a vehicle ECU provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiment, which will not be repeated here.

[0117] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0118] See Figure 5 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 5 The computer program shown above), the instructions are adapted to be loaded and executed as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0119] This application also provides a computer program product that stores at least one instruction, which is loaded and executed to implement the adaptive programming method for the vehicle ECU as described in the above embodiments.

[0120] Please see Figure 6 This is a schematic diagram of the structure of a diagnostic terminal provided in an embodiment of this application. Figure 6 As shown, the diagnostic terminal 600 may include: at least one 601, at least one network interface 604, a user interface 603, a memory 605, and at least one communication bus 602.

[0121] The communication bus 602 is used to enable communication between these components.

[0122] The user interface 603 may include input units such as a mouse and keyboard.

[0123] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0124] 601 may include one or more processing cores. 601 connects various parts within the diagnostic terminal 600 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 605, and by calling data stored in memory 605. Optionally, 601 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). 601 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into 601 and may be implemented as a separate chip.

[0125] The memory 605 may include random access memory (RAM) or read-only memory. Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0126] exist Figure 6In the diagnostic terminal 600 shown, the user interface 603 is mainly used to provide an input interface for the user and to obtain the user's input data; while 601 can be used to call the application program stored in the memory 605 and specifically execute, such as Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0127] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0128] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. An adaptive programming method for a vehicle ECU, characterized in that, Applied to a diagnostic terminal, which by default supports vehicle models based on the first vehicle model information; The method includes: The identity information of the target vehicle is obtained through the diagnostic interface, and the identity information includes vehicle model information and platform identifier. When the vehicle model information is the second vehicle model information, determine whether the target vehicle belongs to a jointly developed vehicle model that shares a platform with the vehicle model of the first vehicle model information based on the platform identifier; If so, the corresponding configuration strategy is extracted based on the second vehicle model information; Based on the configuration strategy, configuration operations are performed to form a virtual configuration layer; the configuration operations include: hot-swapping diagnostic protocol parameters in the communication protocol stack, instantiating an independent security access algorithm container, and loading corresponding brand-customized interface element resources according to the second vehicle model information; A diagnostic session is established with the target vehicle based on the diagnostic protocol parameters in the virtual configuration layer. The secure access algorithm container in the virtual configuration layer is invoked to securely unlock the target vehicle. After secure unlocking, the brand-customized interface elements are invoked to update the human-machine interface of the diagnostic terminal, and ECU programming operations are performed.

2. The method according to claim 1, characterized in that, The step of determining whether the target vehicle belongs to a jointly developed vehicle model that shares a platform with the vehicle model information in the first model category based on the platform identifier includes: The query is performed in a pre-set joint development platform mapping library based on the platform identifier; the joint development platform mapping library stores multiple shared platform identifiers and vehicle model information mapping tables associated with each shared platform identifier; If the platform identifier is the same as any shared platform identifier, obtain the vehicle model information mapping table associated with that shared platform identifier; Based on the vehicle information mapping table, determine whether the first vehicle information and the second vehicle information are paired; If so, the target vehicle is determined to be a jointly developed model. If not, it is determined that the target vehicle is not a jointly developed model.

3. The method according to claim 1, characterized in that, The instantiated independent security access algorithm container includes: Obtain the safety algorithm parameters corresponding to the second vehicle model information from the configuration strategy; Based on the safety algorithm parameters, create an algorithm instance independent of the first vehicle model information; Use the algorithm instance as a container for the secure access algorithm; The secure access algorithm container is used to: send a secure access request to the target vehicle, receive a seed value returned by the target vehicle, generate a key based on the seed value and the security algorithm parameters, and send the key to the target vehicle to complete the secure unlocking.

4. The method according to claim 1, characterized in that, The ECU programming operation includes: Identify the current operating environment, which is determined based on the user role or system presets; Based on the operating environment, a scenario-based programming strategy is dynamically generated. The scenario-based programming strategy includes adjusting the verification level of the programming process, the number of concurrent threads, and the information density of the human-computer interaction interface. ECU programming operations are performed according to the described scenario-based programming strategy.

5. The method according to claim 4, characterized in that, The step of dynamically generating scenario-based programming strategies based on the operating environment includes: The system acquires the battery voltage of the target vehicle and generates a power supply guarantee command based on a comparison between the battery voltage and a preset threshold; it acquires the ECU location data corresponding to the interior layout of the target vehicle and generates a graphical location guide based on the ECU location data; the power supply guarantee command and the graphical location guide constitute the scenario-based programming strategy, which is then displayed on the human-machine interface; or Obtain a technical terminology mapping table corresponding to ECU programming operations, and replace each technical term with natural language prompt text; generate progress indication data including the estimated remaining time based on the current programming progress; the natural language prompt text and the progress indication data constitute the scenario-based programming strategy, which is displayed on the human-machine interface; or The programming process is configured to skip unnecessary verification items by setting the verification level; a high-speed batch flashing channel is enabled, and the number of concurrent threads is configured to support parallel processing of multiple ECUs; the setting of the verification level and the configuration of the number of concurrent threads constitute the scenario-based programming strategy.

6. The method according to claim 1, characterized in that, The step of establishing a diagnostic session with the target vehicle based on the diagnostic protocol parameters in the virtual configuration layer includes: The communication baud rate and protocol type of the target vehicle are detected to complete the communication parameter adaptation; The step of invoking the secure access algorithm container in the virtual configuration layer to securely unlock the target vehicle includes: The secure access algorithm container sends a secure access request to the target vehicle, receives a seed value returned by the target vehicle, generates a key based on the seed value and the security algorithm parameters corresponding to the second vehicle model information, and sends the key to the target vehicle to complete the secure unlocking. The ECU programming operation includes: During ECU programming, the network communication status is monitored. When a communication interruption is detected, the breakpoint information is recorded, and data transmission is automatically resumed from the breakpoint after communication is restored.

7. The method according to claim 1, characterized in that, After performing the ECU programming operation, the following is also included: Send a functional smoke test command to the target ECU to drive a specific actuator. Receive the execution result fed back by the actuator; Based on the execution results, a test report is generated, which includes a general description of the common platform and customized confirmation information of the second vehicle model.

8. An adaptive programming device for a vehicle ECU, characterized in that, include: The acquisition module is used to acquire the identity information of the target vehicle through the diagnostic interface. The identity information includes vehicle model information and platform identifier. The judgment module is used to determine whether the target vehicle belongs to a jointly developed vehicle that shares a platform with the vehicle in the first vehicle information when the vehicle information is the second vehicle information; The acquisition module is further configured to extract the corresponding configuration strategy based on the second vehicle model information if the condition is met. The generation module is used to perform configuration operations based on the configuration strategy to form a virtual configuration layer; the configuration operations include: hot-swapping diagnostic protocol parameters in the communication protocol stack, instantiating an independent security access algorithm container, and loading corresponding brand-customized interface element resources according to the second vehicle model information; A module is established to establish a diagnostic session with the target vehicle based on the diagnostic protocol parameters in the virtual configuration layer. The unlocking module is used to invoke the secure access algorithm container in the virtual configuration layer to securely unlock the target vehicle. The programming module is used to update the human-machine interface of the diagnostic terminal by calling the brand-customized interface element resources after secure unlocking, and to perform ECU programming operations.

9. A computer storage medium, characterized in that, The computer storage medium stores multiple instructions adapted for loading by a processor and executing the steps of the adaptive programming method for the vehicle ECU as described in any one of claims 1 to 7.

10. A diagnostic terminal, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the adaptive programming method for the vehicle ECU as claimed in any one of claims 1 to 8.

Images