An Adaptive OTA Configuration Method for Vehicle Terminals Based on Persistent Calibration Parameters

Abstract

This application discloses an adaptive OTA configuration method for vehicle terminals based on persistent calibration parameters. This method solves the problem of adapting a single firmware to multiple electronic control unit variants by persistently storing the engine platform calibration code locally on the vehicle terminal. When the terminal starts or the calibration code changes, the system dynamically reads the calibration code and loads the corresponding complete configuration instance from a pre-set differentiated configuration library to the runtime center. Upper-layer business modules access the current configuration through a unified interface, achieving decoupling between business logic and hardware differences. Especially during hot switching of calibration codes, this application cleans up old states in dependency order through a pre-registered callback chain, avoiding state aliasing. This application simplifies the complex mode of traditional solutions requiring multiple firmware sets for parallel maintenance into a single firmware, data-driven adaptive mode, significantly reducing R&D, production, and after-sales costs, and improving system reliability and scalability.

Description

Technical Field

[0001] This application relates to the field of vehicle networking and commercial vehicle remote communication. Specifically, it relates to an adaptive configuration method for an on-board terminal OTA based on persistent calibration parameters. More specifically, it relates to an adaptive configuration method for an on-board remote communication terminal (TBOX) to perform wireless online upgrade (OTA) of an engine electronic control unit (ECU), the corresponding on-board terminal, and a computer-readable storage medium. Background Technology

[0002] Following the implementation of the China VI (GB17691-2018) emission regulations, domestic heavy-duty commercial vehicle engine manufacturers have entered a period of rapid iteration. Taking Cummins engines as an example, at least two generations of electronic control platforms currently exist on the market: the early China VI platform (industry code 15N, including diesel and natural gas sub-models) and the new generation China VI platform (industry code 16N, currently mainly based on natural gas sub-models). For the same vehicle model, the TBOX may need to interface with these two generations of ECUs on different production batches and from different OEMs. Adding to the complexity, each generation of engines is further divided into diesel and natural gas sub-models based on fuel type, with differences in fault code classification, reporting protocols, and snapshot parameter tables. Considering the emission level (China VI a and China VI b), the actual number of engine variants that the TBOX needs to be compatible with reaches more than six.

[0003] For the aforementioned multi-variant scenarios, the common practice among domestic TBOX manufacturers is to develop and maintain a separate TBOX firmware for each engine variant, and then flash the corresponding firmware on the production line according to the vehicle's Bill of Materials (BOM) upon production. However, this approach has the following three prominent problems:

[0004] (1) Firmware version explosion and soaring maintenance costs

[0005] Taking the applicant company's TBOX2.1 project as an example, if the traditional approach is followed, at least six parallel firmware branches need to be maintained, each requiring independent testing, regression testing, and release. The development and testing workload increases linearly with the number of variants, and defect fixing requires multiple parallel rounds across multiple branches, making long-term maintenance costs uncontrollable.

[0006] (2) Production line programming errors and recall risks

[0007] Production line processes require selecting the corresponding firmware version based on the vehicle's Bill of Materials (BOM) for flashing. In multi-model mixed-line production scenarios, workers manually selecting firmware packages can easily lead to incorrect flashing, causing the TBOX to be unable to communicate with the ECU after the vehicle rolls off the line, necessitating rework and flashing. If incorrectly flashed firmware enters the after-sales process, it could cause a large-scale recall.

[0008] (3) Difficulty in after-sales replacement and faulty parts replacement

[0009] Commercial vehicles have a lifespan of 8-15 years, and engine overhauls, replacements, and variant upgrades are common maintenance tasks during operation. If the TBOX firmware is hard-bound to the engine variant, the TBOX firmware needs to be rewritten every time it is replaced, requiring specialized tooling and authorized service stations, resulting in low after-sales efficiency.

[0010] In addition, existing publicly available patents and documents related to TBOX OTA mainly focus on the TBOX's own partition upgrades and OTA link security protection, all of which assume that the target ECU is a single model and a single protocol, and do not involve the configuration switching problem when the same TBOX firmware is connected to multiple generations of engine platforms.

[0011] Therefore, there is an urgent need for an OTA configuration switching method that enables vehicle terminals to adaptively support multiple generations of engine controllers under a single firmware. Summary of the Invention

[0012] This application aims to address the problems existing in the background art described above, and provides a method for adaptive OTA configuration of an in-vehicle terminal to adaptively support multiple generations of engine controllers under a single firmware, as well as the in-vehicle terminal and storage medium. To achieve the above objective, this application adopts the following technical solution.

[0013] In a first aspect, embodiments of this application provide an adaptive OTA configuration method for an in-vehicle terminal based on persistent calibration parameters, including:

[0014] Step S1: Persistently store the calibration code field used to uniquely identify the target electronic control unit platform type in the non-volatile storage of the vehicle terminal;

[0015] Step S2: In response to the startup of the vehicle terminal or the change of the calibration code field, read the calibration code field and load the corresponding configuration instance from the preset differentiated configuration library to the runtime configuration center according to the calibration code field;

[0016] Step S3: The upper-layer business module obtains the currently effective differentiated parameters from the runtime configuration center through the unified configuration access interface in order to perform interactive operations with the target electronic control unit;

[0017] Step S4: When a change in the calibration code field is detected, before executing step S2 to load the new configuration instance, the pre-registered configuration switching callback chain is triggered to clean up the runtime state associated with the old configuration instance according to the predefined dependency order.

[0018] Further, reading the calibration code field in step S2 specifically includes:

[0019] Read the master calibration code file and its first check value from the main storage area, and perform an integrity check on the master calibration code file;

[0020] If the master calibration file is successfully verified, it is used as the valid calibration file; if the master calibration file fails to be verified, the backup calibration file and its second verification value are read from the backup storage area, and the integrity of the backup calibration file is verified.

[0021] If the backup calibration code file is successfully verified, it is used as the valid calibration code; if both the main and backup calibration code files fail to be verified, the default calibration code built in during compilation is used as the valid calibration code.

[0022] Furthermore, the configuration switching callback chain triggered in step S4 performs state cleanup in the following dependency order: "upper-layer business modules first, encryption context second, and lower-layer communication state last."

[0023] The cleaned-up runtime state includes at least: incomplete upper-layer diagnostic sessions, session keys temporarily stored in memory, and the underlying data cache queue.

[0024] Furthermore, the configuration instances in the differentiated configuration library are data structures that encapsulate at least 80 differentiated fields;

[0025] The differentiated fields include: protocol command identifier, file verification algorithm type, secure access seed and key length, and controller LAN channel mapping relationship.

[0026] Furthermore, it also includes a lightweight switching step for secondary sub-variants, specifically including:

[0027] In response to runtime modifications to the fuel type flag, when the business modules related to the fuel type obtain parameters through the unified configuration access interface, they dynamically determine the fuel type flag and selectively load the corresponding command identifier or parameter table based on the determination result, without having to reload the entire configuration instance.

[0028] Furthermore, the calibration code field supports a first write operation from a local calibration tool on the production line and a second write operation from a remote vehicle networking service platform;

[0029] The vehicle terminal configuration adaptive method further includes: in response to a remote command from the remote vehicle network service platform, updating the calibration code field, and triggering steps S4 and S2 to complete the configuration hot switching during runtime.

[0030] Furthermore, the vehicle terminal maintains a state machine that includes states such as uninitialized, loading, ready, switching, service paused, and abnormal rollback.

[0031] During the switching process, the service pause state is synchronized with the service pause state. All upper-layer service modules that depend on the configuration are suspended until the configuration instance is reloaded and enters the ready state.

[0032] Furthermore, after the configuration instance is loaded, the runtime configuration center broadcasts a configuration ready signal to all upper-layer business modules;

[0033] After receiving the configuration ready signal, the upper-layer business module reads the differentiated parameters through the unified configuration access interface and enters the normal operation state.

[0034] Secondly, embodiments of this application provide a vehicle-mounted terminal, including:

[0035] The persistent storage module is configured to persistently store a calibration code field in non-volatile storage to uniquely identify the target electronic control unit platform type;

[0036] The configuration loading module is configured to read the calibration code field and load the corresponding configuration instance from the preset differentiated configuration library according to the calibration code field in response to the startup of the vehicle terminal or the change of the calibration code field.

[0037] A runtime cache module, coupled to the configuration loading module, is configured to store the configuration instance most recently loaded by the configuration loading module;

[0038] The unified access interface module is coupled with the runtime cache module and multiple upper-layer business modules, and is configured to provide the upper-layer business modules with an entry point for obtaining the currently effective differential parameters;

[0039] The switching management module, coupled with the persistent storage module and the configuration loading module, is configured to trigger a pre-registered configuration switching callback chain when a change in the calibration code field in the persistent storage module is detected, before the configuration loading module loads the new configuration instance, and clean up the runtime state associated with the old configuration instance according to a predefined dependency order.

[0040] Thirdly, embodiments of this application provide an electronic device, including: one or more processors;

[0041] A memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are able to implement the steps in the vehicle terminal OTA configuration adaptive method described in any of the preceding claims.

[0042] Fourthly, embodiments of this application provide a computer-readable medium storing a computer program, which, when executed by a processor, can implement the steps of the vehicle terminal OTA configuration adaptive method described in any of the preceding claims.

[0043] This application discloses an adaptive OTA configuration method for vehicle terminals based on persistent calibration parameters. This method solves the problem of adapting a single firmware to multiple electronic control unit variants by persistently storing the engine platform calibration code locally on the vehicle terminal. When the terminal starts or the calibration code changes, the system dynamically reads the calibration code and loads the corresponding complete configuration instance from a pre-set differentiated configuration library to the runtime center. Upper-layer business modules access the current configuration through a unified interface, achieving decoupling between business logic and hardware differences. Especially during hot switching of calibration codes, this application cleans up old states in dependency order through a pre-registered callback chain, avoiding state aliasing. This application simplifies the complex mode of traditional solutions requiring multiple firmware sets for parallel maintenance into a single firmware, data-driven adaptive mode, significantly reducing R&D, production, and after-sales costs, and improving system reliability and scalability. Attached Figure Description

[0044] Figure 1 A core flowchart of an adaptive OTA configuration method for vehicle terminals based on persistent calibration parameters provided in this application embodiment;

[0045] Figure 2 A schematic diagram of the module structure of an in-vehicle terminal provided in an embodiment of this application;

[0046] Figure 3 This is an overall architecture diagram of the solution provided in the embodiments of this application;

[0047] Figure 4 A flowchart of calibration code reading and adaptive configuration loading provided for embodiments of this application;

[0048] Figure 5 This is a timing diagram of callback cleanup during calibration code changes provided in an embodiment of this application;

[0049] Figure 6 This is a schematic diagram of the configuration center running state machine provided in an embodiment of this application;

[0050] Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below with reference to the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. Unless otherwise specified, the various embodiments of this application and the features within those embodiments can be combined with each other.

[0052] As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that when the terms "comprising" and / or "made of" are used herein, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as "connected" or "linked" are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0053] Unless otherwise specified, all terms used in this application (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this application.

[0054] The adaptive OTA configuration method for vehicle terminals based on persistent calibration parameters provided in this application is based on a three-stage architecture of "calibration code driving + runtime configuration switching + state cleanup callback". The following will combine... Figures 1 to 6 The technical solution of this application is described in detail.

[0055] refer to Figure 1 One embodiment of this application proposes an adaptive OTA configuration method for vehicle terminals based on persistent calibration parameters, which may specifically include the following steps.

[0056] Step S1: Persistently store the calibration code field used to uniquely identify the target electronic control unit platform type in the non-volatile storage of the vehicle terminal.

[0057] This application first stores an engine platform calibration code field independently in the local non-volatile storage of the vehicle terminal. The value of this calibration code field can simultaneously reflect engine platform generation information (e.g., 15N or 16N) and fuel type information (e.g., diesel or natural gas). This field can be written by the production line process through a local calibration tool, or it can be updated by a remote TSP platform through remote command.

[0058] Step S2: In response to the startup of the vehicle terminal or a change in the calibration code field, read the calibration code field and load the corresponding configuration instance from the preset differentiated configuration library to the runtime configuration center according to the calibration code field.

[0059] In response to the power-on startup of the vehicle terminal or a change in the calibration code field, the system reads the calibration code field and selects the corresponding configuration instance from the pre-set differential configuration library in the firmware based on the calibration code field and loads it into the runtime configuration center.

[0060] refer to Figure 4 In a preferred embodiment, to ensure the robustness of the calibration data, the above reading process employs a dual backup and integrity verification mechanism. Specifically, when the vehicle terminal starts up, it first reads the main calibration code file and its corresponding CRC32 checksum from the local non-volatile storage, and performs an integrity verification on the main calibration code file. If the verification passes, the main calibration code is used as the valid calibration code to proceed to the next step. If the verification fails (e.g., the calculated CRC32 value does not match the stored value), the backup calibration code file and its CRC32 checksum in the backup storage area are immediately read, and the backup calibration code file is performed on its integrity. If the backup file verification passes, the backup calibration code is used as the valid calibration code. If both the main and backup calibration code files fail verification (e.g., data corruption due to accidental erasure), the default conservative calibration code built in during compilation is used as the valid calibration code. This serves as a fallback strategy to ensure that the TBOX can achieve basic communication functions and prevent the terminal from becoming completely unusable (bricked). By employing a dual backup system and a CRC32 verification mechanism, the robustness and fault tolerance of the calibration data are greatly improved. The default calibration code serves as a fallback strategy, avoiding the risk of the vehicle terminal becoming unusable due to calibration data corruption and ensuring the final availability of the product.

[0061] Step S3: The upper-layer business module obtains the currently effective differentiated parameters from the runtime configuration center through the unified configuration access interface in order to perform interactive operations with the target electronic control unit.

[0062] refer to Figure 3The upper-layer OTA service modules in the vehicle terminal, including but not limited to the OTA process orchestrator, UDS cache writing module, security access module, fault code reporting module, and snapshot data acquisition module, all read the currently effective differentiated parameters from the runtime configuration center through a unified configuration access interface, and no longer hardcode any constants related to a specific engine platform in the code.

[0063] The core of this process is the configuration instance in the differentiated configuration library, as shown in Table 1. This configuration instance is a data structure encapsulating over 80 differentiated fields, covering a much wider range than traditional CAN channel or DID (Data Identifier) ​​differences. Specifically, these differentiated fields include, but are not limited to: protocol command identifiers (e.g., 0xA103 for the 15N platform and 0xA106 for the 16N platform), file verification algorithm type (e.g., MD5 for the 15N platform and SHA256 for the 16N platform), secure access seed and key length (e.g., 16 bytes for the learning seed on the 15N platform and 64 bytes for the 16N platform, with key1 lengths of 64 bytes and 80 bytes respectively), and Controller Area Network (CAN) channel mapping relationships (e.g., CAN3 for the 15N platform and CAN1 for the 16N platform). This configuration instance also incorporates parameters traditionally tightly bound to code logic into the data-driven scope. When new engine variants need to be supported, only a new data instance needs to be added to the configuration library without modifying any upper-layer business logic code. This setup achieves comprehensive coverage of the differences, allowing new variants to be added without modifying the business code; adaptation can be completed simply by expanding the configuration data, greatly improving the system's scalability and maintainability.

[0064] Table 1. Configuration Instances in the Differentiated Configuration Library

[0065]

[0066]

[0067] Furthermore, this application also supports lightweight switching of secondary sub-variants. While the primary platform identifier (e.g., 15N) remains unchanged, when a fuel type switch is required (e.g., from diesel to natural gas), the system responds to runtime modifications to the fuel type flag (e.g., the is_gas_engine boolean flag). Fuel type-related business modules (such as the fault_bridge module and the snapshot module) dynamically determine the fuel type flag when obtaining parameters through the unified configuration access interface, and selectively load the corresponding command identifier or parameter table based on the determination result, without reloading the entire configuration instance. For example, when the flag is "false" (diesel), the fault reporting module uses command ID 0xA201; when the flag is "true" (natural gas), it automatically switches to command ID 0xA207, and the snapshot parameter table dynamically switches between the diesel meter (signal 70) and the gas meter (signal 59). This allows for extremely low-overhead, lightweight, runtime switching of different fuel type sub-variants on the same platform without reloading the entire configuration instance or affecting the operation of other modules, further improving the flexibility and efficiency of configuration switching.

[0068] Step S4: When a change in the calibration code field is detected, before executing step S2 to load the new configuration instance, the pre-registered configuration switching callback chain is triggered to clean up the runtime state associated with the old configuration instance according to the predefined dependency order.

[0069] A key innovation of this application lies in handling configuration hot switching during runtime. When the calibration code field is detected to have changed during the operation of the vehicle terminal, the new configuration is not loaded immediately. Instead, a pre-registered configuration switching callback chain is triggered first to clean up the runtime state associated with the old configuration instance according to a predefined dependency order.

[0070] The cleanup order strictly follows a dependency order: upper-layer business logic first, then encrypted context, and finally lower-layer communication state. Figure 5 In the timing diagram shown, in one specific embodiment, when the remote TSP platform issues a command to change the engine type from 1 (15N diesel) to 13 (15N gas), that is, when a calibration code change occurs during the operation of the on-board terminal, this application cleans up the residual state in a strictly dependent order through a pre-registered callback chain to avoid system crashes or data corruption caused by the mixing of old and new states. The complete timing is as follows:

[0071] 1. Trigger source: The remote TSP platform issues an A500 command or the local calibration tool writes a new calibration code (example: engine_type changes from 1 to 13), and the variant configuration center detects the change in the calibration code field.

[0072] 2. The configuration center sends the stop_hb_cache() command to the heartbeat (HB) cache module to stop the collection and caching of heartbeat data; after the heartbeat cache module completes the execution, it returns an OK (queue stopped) response.

[0073] 3. The configuration center sends the stop_fault_report() command to the fault reporting module to disable the timed reporting task of fault codes A201 / A207; after the fault reporting module completes the execution, it returns an OK (reporting has stopped) response.

[0074] 4. The configuration center sends the abort_uds_session() command to the UDS session module to interrupt all ongoing UDS diagnostic sessions (including flashing, learning, and engineering access sessions). If there is a 0x36 data transmission service in progress, it sends a 0x37 transmission termination command to the ECU. After the UDS session module completes the execution, it returns an OK response.

[0075] 5. The configuration center sends the clear_crypto_ctx() command to the encryption chip driver module to clear sensitive contexts such as the key2 session key temporarily stored in memory (the permanent key file in the security element SE remains unchanged); after the encryption chip driver module completes the execution, it returns an OK response (the SE file remains unchanged).

[0076] 6. The configuration center sends the reset_snapshot() command to the snapshot acquisition module to reset the 3×20 s snapshot acquisition window and PGN task table, and clear the acquired snapshot data.

[0077] 7. After all states are cleared, the configuration center executes the apply_engine_type_full(13) function to load the 15N gas configuration instance from the differentiated configuration library, write the new configuration to the runtime cache, and broadcast the configuration ready signal to all business modules to complete the entire configuration switching process.

[0078] Key constraint: Steps 2 and 3 above must be executed before step 4; otherwise, malformed A201 / A301 messages may be sent to the ECU before the UDS session terminates, causing the ECU to trigger a session error and enter a security lockout state. Only after all states have been cleared will the configuration center load the new configuration instance from the differential configuration library. By establishing a callback chain based on dependency order, the core engineering challenge of configuration hot-switching—state remnants—is solved, completely avoiding system crashes or data logic errors caused by state crossover.

[0079] To achieve remote management throughout the entire vehicle lifecycle, the calibration code field in this application supports a first write operation from a local calibration tool on the production line and a second write operation from a remote vehicle networking service platform (TSP). The method also includes updating the calibration code field in response to a remote command (e.g., an A500 command) from the remote vehicle networking service platform, triggering steps S4 and S2 to complete a runtime configuration hot-swap. In one specific embodiment, a sold 15N diesel vehicle has its engine replaced with a 15N natural gas engine during an engine overhaul. The service station technician operates on the TSP platform, which sends a custom A500 remote command to the vehicle's TBOX, carrying the new calibration code "13". After receiving and verifying the command, the TBOX automatically executes the configuration switching process, updating the local calibration code. The entire process requires no vehicle visit and no connection to any diagnostic equipment. This empowers OEMs to remotely and dynamically change the vehicle's electronic platform attributes throughout its entire lifecycle, completely solving the after-sales replacement problem and enabling applications such as remote recalls and software trial fitting, significantly reducing after-sales costs and response time.

[0080] refer to Figure 6 To ensure system consistency during configuration switching, the vehicle terminal maintains a state machine encompassing uninitialized, loading, ready, switching, service paused, and abnormal rollback states. The switching and service paused states occur synchronously. When remote variant switching begins, the configuration center's state transitions from "ready" to "switching," and the state machine simultaneously enters the "service paused" state. At this time, all upper-layer business modules that depend on the configuration (such as the OTA process orchestrator) are blocked, unable to initiate new upgrade or fault reporting requests. Once the new configuration is loaded, the state machine switches back to "ready," broadcasting a "configuration ready" signal, and all business modules resume operation. Through precise state machine management, the introduction of the service paused state acts as a safety barrier, ensuring that upper-layer services do not read incomplete or mixed old and new configuration data during the atomic operation of configuration updates, thus guaranteeing strong system consistency.

[0081] To ensure all business modules are fully configured before commencing operation, the runtime configuration center broadcasts a "configuration ready" signal to all upper-layer business modules after the configuration instance is loaded. Upon receiving this signal, the upper-layer business modules read the differentiated parameters through the unified configuration access interface and enter normal operation. Prior to this, all business modules are in a blocked waiting state, unable to access any configuration parameters, thus fundamentally preventing issues such as null pointer access or the use of incorrect default values ​​due to unloaded configurations.

[0082] refer to Figure 2 An embodiment of this application also provides an in-vehicle terminal, which includes the following modules:

[0083] The persistent storage module is configured to persistently store a calibration code field in non-volatile storage to uniquely identify the target electronic control unit platform type.

[0084] The configuration loading module is configured to read the calibration code field and load the corresponding configuration instance from a preset differentiated configuration library in response to the startup of the vehicle terminal or a change in the calibration code field.

[0085] The runtime cache module, coupled to the configuration loading module, is configured to store the latest configuration instance loaded by the configuration loading module.

[0086] The unified access interface module is coupled with the runtime cache module and multiple upper-layer business modules, and is configured to provide the upper-layer business modules with an entry point for obtaining currently effective differential parameters.

[0087] The switching management module, coupled with the persistent storage module and the configuration loading module, is configured to trigger a pre-registered configuration switching callback chain when a change in the calibration code field in the persistent storage module is detected, before the configuration loading module loads the new configuration instance, and clean up the runtime state associated with the old configuration instance according to a predefined dependency order.

[0088] In one specific embodiment, the vehicle-mounted terminal is a commercial vehicle TBOX, comprising an MCU, a SOC, and Flash memory. A general firmware is programmed into the TBOX. The EOL (End of Line) partition in the Flash memory stores the calibration code "1". Upon system startup, the configuration loading module reads this calibration code and loads the 15N diesel configuration into the runtime cache of RAM. The OTA service module accesses the cache via the get_config() interface. When the TSP platform remotely updates the calibration code to "13", the switch management module intercepts the change, first calling the callback chain to clear the UDS session and encryption context, and then triggering the configuration loading module to reload the 16N gas configuration into the runtime cache, overwriting the old configuration and completing the hot switch. This vehicle-mounted terminal implements closed-loop logic for zero incorrect fuel burning on the production line, remote after-sales replacement, and zero-code expansion of new variants.

[0089] In summary, this application simplifies the complex mode of traditional solutions that require multiple firmware sets to be maintained in parallel through the technical path of "persistent calibration - data-driven configuration - dependency order cleanup" into a single firmware, data-driven adaptive mode, which significantly reduces R&D, production and after-sales costs and improves the reliability and scalability of the system.

[0090] The embodiments of the aforementioned vehicle terminal OTA configuration adaptive method and the embodiments of the aforementioned vehicle terminal are the same or related in terms of technical concept. They can be referred to and learned from each other in terms of technical details and technical effects, which will not be repeated here.

[0091] Overall, the advantages of this application compared to the prior art include:

[0092] 1. Regarding firmware maintenance and version management

[0093] Existing technologies require the development, testing, and maintenance of a separate TBOX firmware for each engine variant (e.g., 15N diesel, 15N gas, 16N gas, etc.), leading to an explosive growth in firmware versions. Defect fixing requires multiple parallel rounds across various branches, and the R&D and testing workload increases linearly with the number of variants. This application decouples engine platform differences from hard-coded code by introducing a persistent calibration code field, transforming them into runtime data-driven configuration instances. This allows a single firmware to cover all known and future variants. Consequently, the number of firmware versions is reduced from more than six to one. When adding a new variant, no upper-level business code needs to be modified; only configuration data needs to be extended. The R&D cycle can be shortened from 2-3 months to 1-2 weeks, and code maintenance costs are reduced to 1 / N of traditional solutions.

[0094] 2. Regarding production line programming and quality control

[0095] In traditional multi-firmware solutions, production lines must manually select the corresponding firmware version based on the vehicle's BOM for flashing. In multi-model mixed-line production scenarios, incorrect flashing is highly likely, leading to the TBOX failing to communicate with the ECU after the vehicle rolls off the line, necessitating rework or even triggering large-scale recalls. This application adopts a "unique firmware, differentiated calibration" strategy. The production line only needs to flash the same firmware, and then complete the configuration by writing a simple calibration code (e.g., engine_type=1) using a local calibration tool. Since the firmware itself no longer carries the risk of version selection errors, the production line flashing error rate is reduced from "moderate" to near zero, fundamentally eliminating the potential for rework and recalls caused by incorrect firmware flashing.

[0096] 3. Regarding after-sales replacement and remote variant switching

[0097] Commercial vehicles have a lifespan of 8-15 years, and engine overhauls, replacements, or variant upgrades are common occurrences during operation. Traditionally, the TBOX firmware is rigidly bound to the engine variant, requiring dedicated equipment to rewrite the firmware each time, necessitating vehicle return to the factory. This results in extremely low after-sales efficiency and high costs. This application supports remote writing of the calibration code field—the remote TSP platform can directly update the calibration code in the vehicle terminal via A500 commands, triggering a hot configuration switch during runtime. During after-sales replacements, the service station only needs to issue the new calibration code on the platform side. The vehicle can switch from the old engine platform to the new engine platform within seconds without needing to enter the shop or perform any physical operations, reducing the traditional 1-2 day return-to-factory time to a remote, second-level process.

[0098] 4. System stability during configuration switching

[0099] The biggest engineering challenge in dynamically switching engine configurations during operation lies in the fact that the old configuration context held by the business modules (such as incomplete UDS diagnostic sessions, session keys in memory, and cached fault codes to be reported) cannot be immediately discarded; otherwise, the mixing of old and new states will lead to system crashes or data corruption. Existing technologies or solutions lack a systematic handling mechanism for this, usually relying on a restart to clear the state. This application cleans up various runtime states in a strict dependency order of "upper-level business modules first, encrypted context second, and lower-level communication states last" through a pre-registered configuration switching callback chain. During the cleanup, all upper-level business modules are put into a "business pause" state, and operation is resumed only after the new configuration is fully loaded. This mechanism completely avoids communication protocol errors caused by the mixing of old and new configurations (such as sending malformed messages to the ECU, causing it to enter a safety lock state), achieving smooth, seamless configuration hot switching in milliseconds (<500 ms).

[0100] 5. Coverage of cross-platform differences

[0101] Existing publicly available TBOX configuration schemes typically only cover a few differentiating dimensions such as CAN channels and DID. Deeper protocol parameters, such as UDS protocol command IDs (e.g., 0xA103 vs. 0xA106), file verification algorithms (MD5 vs. SHA256), and secure access seeds and key lengths (16 bytes vs. 64 bytes), are often considered strongly bound to code logic and cannot be quantified. This application constructs a differentiated configuration structure containing over 80 fields, bringing all the dimensions that traditionally require code modification for adaptation within the controllable scope of the configuration table. This allows TBOX to achieve complete adaptation even with two completely different generations of electronic control platforms (e.g., the CORE2 architecture of the 15N and the CSAR architecture of the 16N) through pure data switching, opening up a technical path of "data-driven replacement of code branches" and significantly reducing the adaptation cost of embedded software in complex hardware ecosystems.

[0102] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 7 As shown in the embodiments of this application, an electronic device includes: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the OTA configuration adaptive methods for vehicle terminals described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0103] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0104] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0105] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0106] This application also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the OTA configuration adaptation methods for in-vehicle terminals described above. The computer-readable storage medium can be volatile or non-volatile.

[0107] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described vehicle terminal OTA configuration adaptive method.

[0108] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0109] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0110] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0111] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing the status information of the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0112] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0113] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0114] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0115] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0116] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0117] Exemplary embodiments have been disclosed in this application, and while specific terminology has been used, it is used only and should be interpreted in a general illustrative sense and is not intended to be limiting. In some embodiments, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. An adaptive OTA configuration method for vehicle terminals based on persistent calibration parameters, characterized in that, include: Step S1: Persistently store the calibration code field used to uniquely identify the target electronic control unit platform type in the non-volatile storage of the vehicle terminal; Step S2: In response to the startup of the vehicle terminal or the change of the calibration code field, read the calibration code field and load the corresponding configuration instance from the preset differentiated configuration library to the runtime configuration center according to the calibration code field; Step S3: The upper-layer business module obtains the currently effective differentiated parameters from the runtime configuration center through the unified configuration access interface in order to perform interactive operations with the target electronic control unit; Step S4: When a change in the calibration code field is detected, before executing step S2 to load the new configuration instance, the pre-registered configuration switching callback chain is triggered to clean up the runtime state associated with the old configuration instance according to the predefined dependency order.

2. The OTA configuration adaptive method for vehicle terminals according to claim 1, characterized in that, The specific steps in step S2 of reading the calibration code field include: Read the master calibration code file and its first check value from the main storage area, and perform an integrity check on the master calibration code file; If the master calibration file is successfully verified, it is used as the valid calibration file; if the master calibration file fails to be verified, the backup calibration file and its second verification value are read from the backup storage area, and the integrity of the backup calibration file is verified. If the backup calibration code file is successfully verified, it is used as the valid calibration code; if both the main and backup calibration code files fail to be verified, the default calibration code built in during compilation is used as the valid calibration code.

3. The OTA configuration adaptive method for vehicle terminals according to claim 1, characterized in that, The configuration switching callback chain triggered in step S4 performs state cleanup in the following dependency order: "upper-layer business modules first, encryption context second, and lower-layer communication state last". The cleaned-up runtime state includes at least: incomplete upper-layer diagnostic sessions, session keys temporarily stored in memory, and the underlying data cache queue.

4. The OTA configuration adaptive method for vehicle terminals according to claim 1, characterized in that, The configuration instances in the differential configuration library are data structures that encapsulate at least 80 differential fields; The differentiated fields include: protocol command identifier, file verification algorithm type, secure access seed and key length, and controller LAN channel mapping relationship.

5. The OTA configuration adaptive method for vehicle terminals according to claim 1, characterized in that, It also includes a lightweight switching step for secondary sub-variants, specifically including: In response to runtime modifications to the fuel type flag, when the business modules related to the fuel type obtain parameters through the unified configuration access interface, they dynamically determine the fuel type flag and selectively load the corresponding command identifier or parameter table based on the determination result, without having to reload the entire configuration instance.

6. The OTA configuration adaptive method for vehicle terminals according to claim 1, characterized in that, The calibration code field supports a first write operation from the local calibration tool on the production line and a second write operation from the remote vehicle networking service platform; The vehicle terminal configuration adaptive method further includes: in response to a remote command from the remote vehicle network service platform, updating the calibration code field, and triggering steps S4 and S2 to complete the configuration hot switching during runtime.

7. The OTA configuration adaptive method for vehicle terminals according to claim 1, characterized in that, The vehicle terminal maintains a state machine that includes states such as uninitialized, loading, ready, switching, service paused, and abnormal rollback. During the switching process, the service pause state is synchronized with the service pause state. All upper-layer service modules that depend on the configuration are suspended until the configuration instance is reloaded and enters the ready state.

8. The OTA configuration adaptive method for vehicle terminals according to claim 1, characterized in that, After the configuration instance is loaded, the runtime configuration center broadcasts a configuration ready signal to all upper-layer business modules; After receiving the configuration ready signal, the upper-layer business module reads the differentiated parameters through the unified configuration access interface and enters the normal operation state.

9. A vehicle-mounted terminal, characterized in that, include: The persistent storage module is configured to persistently store a calibration code field in non-volatile storage to uniquely identify the target electronic control unit platform type; The configuration loading module is configured to read the calibration code field and load the corresponding configuration instance from the preset differentiated configuration library according to the calibration code field in response to the startup of the vehicle terminal or the change of the calibration code field. A runtime cache module, coupled to the configuration loading module, is configured to store the configuration instance most recently loaded by the configuration loading module; The unified access interface module is coupled with the runtime cache module and multiple upper-layer business modules, and is configured to provide the upper-layer business modules with an entry point for obtaining the currently effective differential parameters; The switching management module, coupled with the persistent storage module and the configuration loading module, is configured to trigger a pre-registered configuration switching callback chain when a change in the calibration code field in the persistent storage module is detected, before the configuration loading module loads the new configuration instance, and clean up the runtime state associated with the old configuration instance according to a predefined dependency order.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it can implement the steps in the vehicle terminal OTA configuration adaptive method as described in any one of claims 1 to 8.

Images