Vehicle terminal single firmware multi-part number adaptive configuration method, device and medium

Abstract

The application provides a vehicle terminal single-firmware multi-part number adaptive configuration method, equipment and medium, the method comprises the following steps: in the compiling stage of the firmware of the vehicle processor and the application processor in the T-Box inside the vehicle, according to the diagnostic data identifier corresponding to the T-Box, a multi-part number mapping table containing a plurality of part number records is constructed; in the case of terminal off-line or after-sales replacement, write part number and whole vehicle configuration code to the vehicle processor; power-on initialization is performed on the vehicle processor, and the diagnostic data identifier is matched and written back according to the preset priority; the application processor reads the configuration through the diagnostic channel and drives the business; the change of the diagnostic data identifier is listened to, and when the diagnostic data identifier changes, runtime dynamic reconfiguration is carried out, so as to unify the production line and the FOTA firmware package, eliminate version fragmentation, ensure that the configuration and the part number are consistent, and realize the adaptive configuration of single firmware and multiple part numbers.

Description

Technical Field

[0001] This invention relates to the field of vehicle information configuration, and in particular to a method, device and medium for adaptive configuration of multiple part numbers on a single firmware in a vehicle terminal. Background Technology

[0002] Currently, in-vehicle T-Box / 5G terminals (Telematics Box, in-vehicle telematics terminal) generally adopt an AP+VP dual-core architecture: the VP (Vehicle Processor, often responsible for diagnostics, EOL, vehicle network and real-time control, etc.) side manages diagnostic DID (Data Identifier, used for reading and writing data for diagnostic services) and EOL writing (End of Line, off-line / end of production line; EOL writing is writing configuration at the end of the production line), while the AP (Application Processor, carrying TSP, FOTA, remote control and other application services) side carries TSP protocol (Telematics Service Provider, vehicle network service provider / vehicle network service platform; TSP protocol is the protocol for communicating with the TSP platform), remote control, FOTA (Firmware Over-The-Air, remote firmware upgrade), national standard reporting and other services.

[0003] The same hardware platform (such as the AG35 module) needs to be adapted to different sales regions, power types (ICE gasoline / HEV hybrid electric / PHEV plug-in hybrid electric / EV pure electric / REEV range-extended electric), TSP protocols, and ECALL / APN strategies (emergency call system / mobile network data access configuration). Differentiated configurations are usually achieved by using "one part number corresponding to one firmware" or "compile-time macro branch + multiple firmware versions". After EOL / diagnostic data is written to the part number (SparePartNumber, such as 703005415AA), the terminal needs to switch the sales country (sales region), power type, TSP address, APN, ECALL mode, national standard / enterprise standard function switch, etc. according to the part number. That is, the vehicle manufacturer uses the part number to identify the logistics identity of the ECU (Electronic Control Unit) and uses the software configuration code (DID_FUNCTION_CFG, 64 bytes, i.e., function configuration code) to encode parameters such as sales country, power type, and function switch by bit field. Each business module reads this code during runtime to determine function activation and behavior branch.

[0004] However, as the vehicle model matrix expands, the drawbacks of the traditional single-part-number, single-firmware model during compilation (where the compilation configuration file selects a unique project configuration macro, the VP side fixes a single part number and a single product information table, the AP distinguishes project differences using the compilation macro, and the production line and FOTA correspond to independent firmware packages one-to-one by part number) are becoming increasingly prominent, as follows: 1. Firmware version fragmentation: Each part number must be compiled, tested, and have an independent OTA (Over-The-Air) package. Firmware version fragmentation is severe. For each additional part number on the same hardware platform, an independent compilation, testing, and release of an independent OTA package is required. The number of versions grows rapidly with the vehicle model matrix, thus the cost of OTA management and regression testing increases dramatically. 2. Poor consistency between production line and after-sales configuration: Production line programming and after-sales replacement must strictly match the "part number - firmware package", which can easily lead to functional abnormalities due to mismatch between firmware and part number; 3. Unable to self-heal during runtime: After the part number is changed, the software configuration code, logistics part number, TSP address, APN and other DIDs lack automatic verification and write-back, and need to rely on manual alignment, which is prone to configuration inconsistencies. 4. Insufficient support for multiple configuration scenarios with the same part number: When adding a new part number or adjusting the function matrix, it is necessary to recompile and release, which cannot be extended via OTA. It is necessary to go through the complete compilation and release process, resulting in long response cycles and high maintenance costs. When the same part number corresponds to different power types of vehicle configurations such as PHEV / EV / HEV, there is a lack of a two-level adaptive mechanism based on the vehicle configuration code. Summary of the Invention

[0005] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows: According to one aspect of this application, a method for adaptive configuration of multiple part numbers in a single firmware of an in-vehicle terminal is provided, comprising: Step S100: During the firmware compilation stage of the vehicle processor and application processor inside the vehicle's T-Box, a multi-part number mapping table containing several part number records is constructed based on the diagnostic data identifier corresponding to the T-Box. Step S200: In the case of terminal offline or after-sales part replacement, write the part number and vehicle configuration code to the vehicle processor; Step S300: Power on and initialize the vehicle processor and match and write back the diagnostic data identifier according to the preset priority. Step S400: The application processor reads the configuration and drives the service through the diagnostic channel; Step S500: Monitor changes to diagnostic data identifiers and perform runtime dynamic reconfiguration when diagnostic data identifiers change.

[0006] According to another aspect of this application, a non-transitory computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored in the storage medium, the at least one instruction or the at least one program being loaded and executed by a processor to implement the aforementioned vehicle terminal single firmware multi-part number adaptive configuration method.

[0007] According to another aspect of this application, an electronic device is provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0008] The present invention has at least the following beneficial effects: The adaptive configuration method for multiple part numbers in a single firmware of the present invention firstly constructs a multi-part number mapping table containing several part number records based on the diagnostic data identifier corresponding to the T-Box during the firmware compilation stage of the vehicle processor and application processor inside the vehicle's T-Box. When the terminal is offline or replaced after-sales, the part number and vehicle configuration code are written to the vehicle processor, and the vehicle processor is initialized upon power-on and the diagnostic data identifier is matched and written back according to a preset priority. The application processor reads the configuration and drives the business through the diagnostic channel, listens for changes in the diagnostic data identifier, and performs dynamic reconfiguration at runtime when the diagnostic data identifier changes. This allows for the pre-configuration of a mapping table between multiple part numbers and software configuration codes within a single firmware set. The part number written at EOL is automatically matched, verified, and written back to the associated diagnostic data identifier at runtime. This unifies the production line and FOTA firmware package, eliminates version fragmentation, and ensures that the configuration is consistent with the part number, thereby achieving adaptive configuration of multiple part numbers in a single firmware. Attached Figure Description

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

[0010] Figure 1 The flowchart illustrates the adaptive configuration method for multiple part numbers in a single firmware of an in-vehicle terminal provided in this embodiment of the invention. Detailed Implementation

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

[0012] This application proposes a single firmware multi-part number adaptive configuration method for vehicle-mounted terminals, such as... Figure 1 As shown, it includes: Step S100: During the firmware compilation stage of the vehicle processor and application processor inside the vehicle's T-Box, a multi-part number mapping table containing several part number records is constructed based on the diagnostic data identifier corresponding to the T-Box. Specifically, in the version configuration file of the vehicle processor (VP side), a first-level mapping table (represented as g_prodInfoTab[]) is built for the same hardware platform. Each part number record in the first-level mapping table contains an associated diagnostic data identifier (associated DID); the associated diagnostic data identifier includes the part number, a 64-byte software configuration code (DID_FUNCTION_CFG), the logistics software part number, the manufacturer's software version, the TSP address, the port, and the access point name (APN), etc.

[0013] If the same part number corresponds to multiple power types or multiple sales regions, then a secondary mapping table is constructed (the secondary mapping table for multiple power types can be represented as partNum_multiCfg[]; the secondary mapping table for multiple sales regions can be represented as partNum_multiIp[]). The secondary mapping table includes the mapping relationship between the combination of part number and power type and software configuration code (i.e., part number + power type → software configuration code), as well as the mapping relationship between the combination of part number and sales area and TSP address or access point name (i.e., part number + sales area → TSP / APN).

[0014] In addition to power type (fuel type) and sales region in the vehicle configuration code, the secondary mapping table can also be extended to other bit field information such as drive type, ECALL configuration, left / right drive, and communication system to form a hierarchical matching mechanism of "part number + multi-dimensional vehicle configuration" to adapt to more complex common parts and multi-specification vehicle installation scenarios.

[0015] The above mapping data is compiled and packaged together with the VP image. The application processor (AP side) only selects the platform baseline and no longer compiles firmware separately according to part number. Multiple part number mapping records are pre-set in the same AP+VP software baseline. The production line uniformly flashes the same firmware. After EOL is written with different part numbers, the runtime automatically matches and differentiates the configuration to replace the "one part number, one firmware" mode and realize single firmware common version delivery.

[0016] In addition, the first and second mapping tables, besides being permanently stored in the VP image during compilation, can also be stored in the AP-side file system, a separate non-volatile storage area, or a cloud configuration center. When adding part numbers or adjusting the function matrix, only the mapping table data can be updated via OTA or remote distribution, without recompiling the entire firmware package, thereby reducing maintenance costs and improving configuration iteration efficiency.

[0017] Step S200: In the case of terminal offline or after-sales part replacement, write the part number and vehicle configuration code to the vehicle processor; Specifically, when a terminal is taken offline or a part is replaced after sales, the diagnostic tool writes the part number (DID_SUPPLIER_PART_NUM) and the vehicle configuration code (DID_MANU_CFG_INFO) to the vehicle processor. The part number is used as the primary index key, and the vehicle configuration code provides secondary index information such as power type and sales region for adaptive matching during runtime.

[0018] Step S300: Power on and initialize the vehicle processor and match and write back the diagnostic data identifier according to the preset priority. Specifically, after power-on, the vehicle processor's information management module reads the current part number and vehicle configuration code, and performs a software configuration code matching operation: Based on the read part number and power type, traverse the secondary mapping table partNum_multiCfg[] to determine the corresponding software configuration code from the secondary mapping table partNum_multiCfg[], and write back the software configuration code; If the software configuration code corresponding to the combination of part number and power type does not exist in the secondary mapping table partNum_multiCfg[], i.e., it is a miss, then the primary mapping table is traversed according to the part number to determine the corresponding software configuration code from the primary mapping table, and the software configuration code is written back. Verify and write back the associated diagnostic data identifier (including manufacturer software version, logistics software part number, etc.) of the part number corresponding to the part number record in the first-level mapping table. Regarding network parameters, the sales region TSP address and APN are matched and written back according to the second-level mapping table partNum_multiIp[] first; otherwise, the default value of the first-level mapping table is used.

[0019] The first-level mapping table of this application directly matches based on the part number, while the second-level mapping table performs secondary matching by combining dimensions such as power type and sales region in the vehicle configuration code. Through the retrieval mechanism of second-level priority and first-level fallback, it takes into account the scenario of multiple configurations for the same part number. Using the part number as the index key, it searches for the corresponding software configuration code and associated DID (logistics part number, TSP address, APN, etc.) in the corresponding mapping table. After comparing the current value with the table entry, it automatically writes back to ensure that the configuration is consistent with the part number.

[0020] In addition, if the mapping table does not match the target part number or the secondary index is invalid (i.e., there is no software configuration code corresponding to the combination of the part number and power type in the secondary mapping table), different strategies can be adopted, such as using the preset default configuration, recording the alarm and continuing to run, or disabling the relevant functions. In the case of multiple candidate configurations for the same part number, additional conditions such as VIN (Vehicle Identification Number) and tenant identifier can be combined for further filtering to meet the security and management requirements of different projects.

[0021] In addition to power-on initialization and periodic polling, this invention can also trigger matching and write-back immediately by change callback when DID writing is completed, so as to shorten the configuration effective delay; it can also add a verification at key nodes such as AP wake-up and TSP chain establishment as a supplementary guarantee during operation.

[0022] Step S400: The application processor reads the configuration and drives the service through the diagnostic channel; Specifically, after the vehicle processor is rewritten, the application processor reads the latest software configuration code and part number through the diagnostic interface, parses functional parameters such as sales region, power type, ECALL mode, and TSP protocol type through a unified interface, and queries project-level configurations such as APN quantity and number of motors, thereby controlling the activation and behavior of functional modules such as remote control, national standard reporting, and ECALL.

[0023] Business modules such as Book, ECALL, VData, and VCtrl all use software configuration codes as the runtime configuration source, no longer relying on compile-time macros to switch project identities, thus achieving consistent AP / VP dual-core configuration.

[0024] In this application, the vehicle processor is responsible for mapping and writing back, the application processor reads the software configuration code through the diagnostic channel and parses the function parameters by bit field, and all business modules consume them in a unified manner to avoid the disconnect of dual-core configuration.

[0025] Step S500: Monitor changes to diagnostic data identifiers and perform runtime dynamic reconfiguration when diagnostic data identifiers change; Specifically, the vehicle processor registers a diagnostic data identifier change callback, listens for part number and vehicle configuration code write events, and re-executes matching and write-back after the periodic task detects a change, that is, returns to step S300 when a change in the diagnostic data identifier is detected. The application processor registers a callback for software configuration code changes and triggers re-initialization such as TSP reconnection and MDC public network / DNS reconfiguration when the software configuration code is updated.

[0026] Therefore, production line errors, after-sales parts replacements, or changes in vehicle configuration can all trigger runtime self-healing without re-flashing the firmware, thus supporting scenarios such as production line errors and after-sales parts replacements.

[0027] Following the business-driven approach, a single firmware covering multiple part numbers was verified: taking the same hardware platform as an example, multiple part number mapping records are pre-set within a single firmware. After the production line writes different part numbers, the vehicle processor automatically matches the corresponding entries and writes back the differentiated configuration. The application processor then reads this and drives the corresponding regional business logic. Therefore, FOTA only requires maintaining one upgrade package, and the production line uniformly flashes the same firmware, using runtime part numbers to drive configuration differentiation, thus verifying the effectiveness of the single firmware multi-part number co-version mechanism.

[0028] This invention achieves adaptive configuration of multiple part numbers, multiple sales regions, and multiple power types within a single firmware set through a technical approach of "pre-setting multi-level mapping tables during compilation, matching part number indexes at runtime, AP / VP dual-core DID synchronization, and dynamic reconfiguration of DID changes," thereby eliminating firmware fragmentation, ensuring configuration consistency, and shortening the delivery cycle.

[0029] The vehicle terminal single firmware multi-part number adaptive configuration method of the present invention forms a complete closed loop of "construction-writing-matching-synchronization-self-healing" through five stages: compile-time mapping table construction, production line / EOL part number writing, VP-side matching and writing back, AP-side reading and consumption, and DID change dynamic reconfiguration. This enables multi-part number adaptive configuration within a single firmware set, uses software configuration code as a unified functional expression carrier, and connects the complete link between VP matching and writing back and AP service consumption to support two-level adaptive configuration.

[0030] The present invention also provides a 5G vehicle terminal adaptive configuration system for implementing the above method, including a VP-side product information management module and an AP-side product information consumption module, both of which use software configuration codes as a unified configuration source.

[0031] The following will further describe the adaptive configuration method for multiple part numbers of a single firmware in a vehicle terminal according to the present application, with reference to the implemented embodiments: The core modules of this invention have been implemented in multiple ongoing projects: On the VP side, the yds_prod product information management, g_prodInfoTab[] multi-part number mapping table, partNum_multiCfg / partNum_multiIp secondary mapping, and DID automatic write-back logic have been implemented on platforms such as EEA5X (e.g., T13C_4G, T13J_4G_LITE, T18FL4, etc.) of a certain automaker and T1V of another automaker; On the AP side, DID_FUNCTION_CFG is read via Lemon and the Book, ECALL, VData, and other services are driven according to the configuration code, and joint debugging has been successfully completed in the corresponding projects. The above implementations demonstrate that the technical approach of this invention can operate stably under an AP+VP dual-core architecture.

[0032] The following scenarios were verified in bench and real vehicle tests: After EOL is written with different part numbers, VP can correctly match the mapping table and write back the software configuration code, TSP address and APN; The same firmware version is compatible with part numbers in multiple sales regions (such as T13C EU / Israel / Turkey, etc.), and TSP access and remote control functions are normal. After modifying the part number or vehicle configuration code, the DID change callback triggers a rematch, the configuration is automatically updated, and the behavior of the AP business module switches accordingly. Under the same part number, the differentiated software configuration code (partNum_multiCfg) is written back according to the vehicle configuration code and fuel type, and the power type related function switches are as expected.

[0033] Compared to the existing "one firmware per part number" solution, the common firmware in this application has reduced the number of firmware versions on some platforms, unified production line flashing and OTA package management; after the production line miswrites the part number, it can restore the correct configuration through runtime self-healing, and the consistency of after-sales replacement configuration is improved.

[0034] Therefore, compared with the existing single-part-number, single-firmware solution during compilation, the beneficial effects achieved by this invention are as follows: 1. Fewer firmware versions: Single firmware has multiple part number mappings pre-installed, and the production line / FOTA uses a unified package, no longer "one firmware per part number", resulting in lower OTA and testing costs; 2. More reliable configuration: Automatically matches and writes back the software configuration code and associated DID according to the part number, reducing errors such as mixing materials, mis-brushing, and manual alignment; 3. Dual-core consistency: The software configuration code serves as the unified configuration source for AP / VP, avoiding inconsistencies in status caused by separate compilation macros and DIDs; 4. More flexible expansion: Adding new part numbers or modifying configurations can expand the mapping table and it can self-heal at runtime, eliminating the need to recompile and release each time; 5. More configurations and better compatibility: Supports two-level matching of "part number + power type / sales region", so there is no need to add firmware versions for multiple power and multiple regions with the same part number.

[0035] Furthermore, the adaptive configuration method for multiple part numbers in a single firmware of the vehicle terminal of the present invention, in addition to being used for 5G / 4G vehicle T-Box with multiple part numbers, can also be extended to the following scenarios: Multiple OEMs (Original Equipment Manufacturers) and multiple vehicle models share the same communication module: When the same hardware platform is delivered to different vehicle manufacturers or vehicle models, differentiation is achieved through part numbers and configuration codes, reducing the number of software versions on the module side. Engineering prototyping and overseas pilot projects: Prototype vehicles and overseas pilot projects can share the domestic baseline firmware. By writing different part numbers or vehicle configuration codes through EOL, regional functions can be quickly switched, shortening the software import cycle. After-sales parts replacement and refurbishment: After replacing the T-Box, the original vehicle part number is written, and the terminal automatically restores the corresponding configuration, reducing the workload of manual flashing and the risk of configuration errors in after-sales service; Aftermarket and Retrofit Market: Aftermarket terminals are pre-configured with multi-customer and multi-region mapping relationships, and the installation phase is adaptively configured according to vehicle information, achieving one set of hardware covering multiple markets; Large-scale fleet and leasing operations: Switch TSP access policies and function switches by tenant or operating region to facilitate unified operation and maintenance and batch management.

[0036] Furthermore, this invention is not limited to the AP+VP dual-core T-Box architecture, but can also be applied to single-core T-Box, central gateway, domain controller and other ECUs; in addition to the Lemon diagnostic channel, configuration synchronization can also be achieved using SPI, UART and other inter-core private protocols or vehicle Ethernet protocols, as long as the basic process of "writing identifier - table lookup matching - writing back configuration - service consumption" is met.

[0037] The functional differences of this invention can be expressed not only through 64-byte software configuration code, but also by combining other DID parameters; the matching and write-back logic can be deployed on the VP side, or the mapping table can be maintained by the AP side and sent to the VP. The specific choice can be made flexibly according to the ECU resources and architecture constraints.

[0038] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0039] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0040] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0041] In an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided.

[0042] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: entirely in hardware, entirely in software (including firmware, microcode, etc.), or in a combination of hardware and software, collectively referred to herein as “circuit,” “module,” or “system.”

[0043] An electronic device according to this embodiment of the invention. The electronic device is merely an example and should not be construed as limiting the functionality or scope of the embodiments of the invention.

[0044] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and buses connecting different system components (including memory and processor).

[0045] The storage device stores program code that can be executed by the processor to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of the present invention.

[0046] The storage may include readable media in the form of volatile storage, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0047] The storage may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more applications, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0048] A bus can represent one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus architectures.

[0049] Electronic devices can also communicate with one or more external devices (such as keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable users to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (such as routers, modems, etc.). This communication can be performed through input / output (I / O) interfaces. Furthermore, electronic devices can also communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters.

[0050] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0051] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the invention described in the "Exemplary Methods" section of this specification.

[0052] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0053] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0054] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0055] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0056] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0057] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0058] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for adaptive configuration of multiple part numbers in a single firmware of an on-board terminal, characterized in that, include: Step S100: During the firmware compilation stage of the vehicle processor and application processor inside the vehicle's T-Box, a multi-part number mapping table containing several part number records is constructed based on the diagnostic data identifier corresponding to the T-Box. Step S200: In the case of terminal offline or after-sales part replacement, write the part number and vehicle configuration code to the vehicle processor; Step S300: Power on and initialize the vehicle processor and match and write back the diagnostic data identifier according to the preset priority. Step S400: The application processor reads the configuration and drives the service through the diagnostic channel; Step S500: Monitor changes to diagnostic data identifiers and perform runtime dynamic reconfiguration when diagnostic data identifiers change.

2. The method according to claim 1, characterized in that, Step S100 includes: In the vehicle processor's version configuration file, a first-level mapping table is built for the same hardware platform; Each part number record in the primary mapping table contains an associated diagnostic data identifier; the associated diagnostic data identifier includes the part number, a 64-byte software configuration code, a logistics software part number, a manufacturer software version, a TSP address, a port, and an access point name.

3. The method according to claim 2, characterized in that, Step S100 further includes: If the same part number corresponds to multiple power types or multiple sales regions, then a secondary mapping table is constructed; The secondary mapping table includes the mapping relationship between part number and power type combination and software configuration code, as well as the mapping relationship between part number and sales region combination and TSP address or access point name.

4. The method according to claim 3, characterized in that, Step S200 includes: When a terminal is taken offline or a part is replaced after sales, the part number and vehicle configuration code are written to the vehicle processor. The part number is used as the primary index key, and the vehicle configuration code provides secondary index information such as power type and sales region.

5. The method according to claim 4, characterized in that, Step S300 includes: The vehicle processor's information management module reads the current part number and vehicle configuration code after power-on. Based on the read part number and power type, the secondary mapping table is traversed to determine the corresponding software configuration code from the secondary mapping table, and the software configuration code is written back. If the software configuration code corresponding to the combination of part number and power type does not exist in the secondary mapping table, the primary mapping table is traversed according to the part number to determine the corresponding software configuration code from the primary mapping table, and the software configuration code is written back. Write back the associated diagnostic data identifier of the part number record corresponding to the part number in the first-level mapping table.

6. The method according to claim 5, characterized in that, Step S400 includes: After the vehicle processor is rewritten, the application processor reads the latest software configuration code and part number through the diagnostic interface, parses the sales region, power type, ECALL mode, TSP protocol type through the unified interface, and queries the project-level configuration.

7. The method according to claim 6, characterized in that, Step S500 includes: The vehicle processor registers a diagnostic data identifier change callback, listens for part number and vehicle configuration code write events, and returns to step S300 when a change in the diagnostic data identifier is detected. The application processor registers a callback for software configuration code changes and performs reinitialization when the software configuration code is updated.

8. The method according to claim 5, characterized in that, Step S300 further includes: If the software configuration code corresponding to the combination of part number and power type does not exist in the secondary mapping table, the preset default configuration will be used, or an alarm will be recorded and operation will continue, or the relevant function will be disabled.

9. A non-transitory computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the method as described in any one of claims 1-8.

10. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 9.

Images