Vehicle OTA version control and mobile terminal function dynamic adaptation method and system

Abstract

The application provides a vehicle OTA version control and mobile terminal function dynamic adaptation method and system, and belongs to the technical field of vehicle system OTA upgrading.The method comprises the following steps: obtaining an encrypted version feature code containing a hardware fingerprint generated by a vehicle terminal, wherein the encrypted version feature code containing the hardware fingerprint has all ECU version information of the vehicle terminal; performing bidirectional cross verification on the encrypted version feature code containing the hardware fingerprint and a pre-stored reference value by decryption; when the bidirectional cross verification is passed, generating a dynamic function list (DFM) with a digital signature and broadcasting the DFM to a node network for signature; and packing the dynamic function list meeting a preset signature threshold into a block and writing the block into a block chain, wherein the dynamic function list is used for dynamically rendering corresponding UI components by the mobile terminal according to the description of the dynamic function list.The application solves the problem of real-time matching of vehicle terminal versions and mobile terminal functions, can improve the matching degree of mobile terminal functions and vehicle software functions, and improves the experience of users.

Description

Technical Field

[0001] This invention relates to the field of OTA upgrade technology for vehicle systems, and in particular to a method and system for vehicle OTA version control and dynamic adaptation of mobile terminal functions. Background Technology

[0002] With the transformation of intelligent connected vehicles towards "Software Defined Vehicles" (SDV), the frequency of over-the-air (OTA) upgrades for in-vehicle systems is growing exponentially. According to statistics, mainstream models currently require more than two major software updates per quarter on average, involving functional iterations of over 120 ECUs. Meanwhile, the accompanying mobile app, as the core entry point for vehicle control, faces a critical challenge in managing its version and coordinating it with vehicle functions.

[0003] Traditional solutions employ a "vehicle-driven" upgrade strategy, with the app serving only as an information display terminal. When the vehicle adds new API interfaces via OTA (such as a battery preheating timer function), it needs to wait for the app store to review and update, which has an average lag of 48-72 hours, resulting in blind spots in function control during this period.

[0004] When vehicles of the same brand but with different configurations share a common app, functional mismatches often occur. For example, the app on the basic model may display unavailable advanced driver assistance buttons (leading to user complaints); after a hardware downgrade is upgraded, the app may still retain control options that rely on the original hardware (posing a risk of misoperation). Summary of the Invention

[0005] This invention aims to overcome the shortcomings of existing technologies in OTA version control, especially in solving the version consistency of sub-functions and the adaptation limitations of hardware versions, so as to improve the matching degree between mobile terminal functions and vehicle software functions and improve the user experience.

[0006] In a first aspect, embodiments of the present invention provide a method for vehicle OTA version control and dynamic adaptation of mobile terminal functions, including:

[0007] Obtain the encrypted version feature code containing hardware fingerprint generated by the vehicle, wherein the encrypted version feature code containing hardware fingerprint has version information of all ECUs on the vehicle.

[0008] The encrypted version feature code containing the hardware fingerprint is decrypted and then cross-verified with a pre-stored baseline value.

[0009] When the two-way cross-validation passes, a dynamic function list with digital signature is generated and broadcast to the node network for each node to sign. The dynamic function lists that meet the preset signature threshold are packaged into blocks and written into the blockchain. The dynamic function list is used by the mobile terminal to dynamically render and generate corresponding UI components according to the description of the dynamic function list.

[0010] In a preferred embodiment, the method further includes: when bidirectional cross-validation fails, sending a recovery command to both the vehicle and mobile terminals to simultaneously trigger the recovery mechanisms on both the vehicle and mobile terminals.

[0011] In a preferred embodiment, the encrypted version feature code containing hardware fingerprints is obtained by generating a first hardware hash using a hash algorithm from the collected CPU number and the MAC address of the vehicle-side TBOX, and then encrypting the first hardware hash with the collected ECU version information concatenated according to alphabetical order using an encryption algorithm.

[0012] In a preferred embodiment, the step of performing bidirectional cross-verification by decrypting the encrypted version feature code containing the hardware fingerprint and the pre-stored benchmark value includes:

[0013] The first hardware hash is obtained by decrypting the encrypted version feature code containing the hardware fingerprint;

[0014] The second hardware hash is obtained by calculating the pre-stored base value using the same hash algorithm as that used on the vehicle.

[0015] Compare the first hardware hash and the second hardware hash. If they match, the two-way cross-validation passes; otherwise, the two-way cross-validation fails.

[0016] In a preferred embodiment, when the bidirectional cross-validation passes, a dynamic function list with a digital signature is generated and broadcast to the node network for each node to sign. Dynamic function lists that meet a preset signature threshold are packaged into blocks and written into the blockchain. The steps for the mobile device to dynamically render and generate corresponding UI components based on the description of the dynamic function list include:

[0017] When the two-way cross-verification passes, the first set is formed by extracting all ECU version information of the vehicle from the encrypted version feature code containing the hardware fingerprint after decryption.

[0018] Query the database to verify the validity of the first set;

[0019] A dynamic feature list is generated based on the ECU version that has passed the verification of legality.

[0020] The dynamic function list is digitally signed and broadcast to the node network to obtain signatures from each node. When 2 / 3 of the nodes have signed, the dynamic function list is packaged into a block and written into the blockchain.

[0021] In a preferred embodiment, the step of querying the database to verify the legality of the first set includes:

[0022] Query the database to verify whether each ECU version in the first set is an officially released version;

[0023] Verify the compatibility of combinations of different ECU versions;

[0024] Verify that the combination of different ECU versions is compatible with the vehicle configuration.

[0025] In a preferred embodiment, the step of generating a dynamic function list based on the ECU version that has passed the verification of legality includes:

[0026] Obtain multidimensional data, which includes at least one of vehicle status, user attributes, environmental information, and business rules;

[0027] Set preset conditions based on the multidimensional data;

[0028] The available functions are selected based on preset conditions and the ECU version that has passed the legality verification.

[0029] Adjust function parameters based on user profiles;

[0030] Build a structured, dynamic feature list document.

[0031] In a second aspect, embodiments of the present invention provide a vehicle OTA version control and mobile terminal function dynamic adaptation system, configured to implement any of the methods described in the first aspect, the system comprising:

[0032] The acquisition module is used to acquire the encrypted version feature code containing hardware fingerprint generated by the vehicle terminal, wherein the encrypted version feature code containing hardware fingerprint has version information of all ECUs on the vehicle terminal;

[0033] The two-way cross-validation module is used to perform two-way cross-validation by decrypting the encrypted version feature code containing the hardware fingerprint and the pre-stored benchmark value;

[0034] The generation module is used to generate a dynamic function list with digital signatures when the two-way cross-validation passes. This list is then broadcast to the node network for each node to sign. Dynamic function lists that meet the preset signature threshold are packaged into blocks and written into the blockchain. The dynamic function list is used by the mobile terminal to dynamically render and generate corresponding UI components based on the description of the dynamic function list.

[0035] Thirdly, embodiments of the present invention provide an electronic device, including:

[0036] One or more processors;

[0037] Memory, used to store one or more programs;

[0038] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods described in the first aspect.

[0039] Fourthly, embodiments of the present invention provide a computer-readable medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described in the first aspect.

[0040] Beneficial effects of this invention:

[0041] This invention solves the problem of real-time matching between vehicle version and mobile terminal functions through three innovations: hardware-level encryption, dynamic manifest distribution, and conditional rendering. This improves the matching degree between mobile terminal functions and vehicle software functions, thereby enhancing the user experience.

[0042] This invention can reduce compatibility failure rates and support the deployment of new features in a very short time (e.g., 10 seconds). Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the OTA version control architecture corresponding to a vehicle OTA version control and mobile terminal function dynamic adaptation method provided in an embodiment of the present invention.

[0044] Figure 2 This is a schematic diagram of a chained version verification process provided in an embodiment of the present invention.

[0045] Figure 3 This is a schematic diagram of the functional flow of the dynamic function list provided in an embodiment of the present invention.

[0046] Figure 4 This is a schematic diagram of the upgrade failure scenario handling process provided in an embodiment of the present invention.

[0047] Figure 5 This is a schematic diagram of a method for vehicle OTA version control and dynamic adaptation of mobile terminal functions provided in an embodiment of the present invention.

[0048] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0049] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention 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 the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0050] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0051] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0052] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, 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 herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0054] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0055] In related technologies, a method and system for synchronizing APP and vehicle OTA software versions have been proposed. This involves configuring an upgrade strategy and an initial synchronization version relationship table; creating and pushing upgrade tasks to the TSP (Transmission Support Service) terminal according to the upgrade strategy, enabling the TSP terminal to push the upgrade tasks to the vehicle terminal; and receiving upgrade success information from the vehicle terminal, which is the feedback from the vehicle terminal after successfully performing the upgrade according to the upgrade task. The system also receives APP version matching verification requests from the TSP terminal and controls the synchronization of the vehicle OTA version with the APP version based on these requests. Furthermore, the initial synchronization version relationship table is pushed to the TSP terminal based on the upgrade information, enabling the TSP terminal to control the synchronization of the APP version with the vehicle OTA version. While this technical solution can achieve synchronization between the APP version and the vehicle OTA version in the APP and OTA software version management system, it only involves version control of the overall function and cannot achieve version comparison and control of individual sub-functions. Additionally, it lacks an adaptation mechanism for hardware versions, failing to achieve locally differentiated OTA; and it lacks a mature solution for OTA upgrade failures.

[0056] This invention is based on a three-stage control method of vehicle-side function registration, cloud version mapping, and dynamic APP loading, which ensures the consistency between APP-side functions and vehicle-side functions, and also has a compensation mechanism for scenarios where vehicle-side OTA fails.

[0057] Figure 1 This is a schematic diagram of the OTA version control architecture corresponding to a vehicle OTA version control and mobile terminal function dynamic adaptation method provided in an embodiment of the present invention. Figure 1 As shown, the OTA version control architecture includes:

[0058] 1. Vehicle side: Generate a version feature code containing a hardware fingerprint and send [version feature code] + [hardware hash] to the cloud;

[0059] 2. Cloud: Decode the signature code and extract the firmware version set F; query the database to verify the legality of F and compare the hardware hash value; return [signature verification result] + [function list hash] to the vehicle; push [dynamic function list] (including UI descriptor) to the mobile terminal;

[0060] 3. Mobile: Upload [verification result of the manifest] + [environment parameters] to the cloud; render the UI based on the Dynamic Feature Manifest, and render the controls that have passed the signature.

[0061] In this process, when the vehicle is in a trusted state (usually after it comes off the production line or at an authorized service center), the system collects and securely registers the identification data to the cloud as a pre-stored benchmark value for verifying the signature.

[0062] Legitimate Update: After hardware replacement (such as TBOX) or major software rewriting is performed at an authorized 4S store / service center, the cloud baseline values ​​are automatically updated by an authorized technician using a dedicated diagnostic tool.

[0063] Unauthorized alteration: Any hardware modifications made through unauthorized channels will result in the new fingerprint not being included in the cloud baseline, causing subsequent verification to fail.

[0064] Freeze / Invalidate: When a vehicle is scrapped or a major accident causes the digital identity to be reset, the baseline value will be archived or marked as invalid.

[0065] The bidirectional verification relies on the ECU version's signature code and requires the collection of the following information:

[0066]

[0067] The hardware hash value is generated according to the following formula, and the signature is encrypted to obtain the result:

[0068] hw_hash = hmac(combine(cpu_id, mac_addr)) ,

[0069] result = encrypt_aes_gcm(fw_ver + hw_hash, master_key),

[0070] This involves the HMAC hash algorithm and the AES encryption algorithm.

[0071] Figure 2 This is a schematic diagram of a chained version verification process provided in an embodiment of the present invention. Figure 2 As shown, after the vehicle generates the version feature code, it uploads the data to the cloud for verification. If the verification passes, a record R is generated and broadcast to the node network. The supplier node signs the record, and the dealer node signs the record. Once 2 / 3 of the nodes have signed the record, the record is uploaded to the blockchain, and a success value is returned to the vehicle.

[0072] The above node types include:

[0073]

[0074] Chain-based version verification is based on a decentralized trust model, requiring multiple nodes to jointly verify the validity of the data. The on-chain mode is a consensus mechanism: when more than 2 / 3 of the node signatures are collected (or a preset threshold is met), consensus is considered reached, and the data can be packaged into a block and written to the blockchain. This process may be completed by specific consensus nodes or automatically executed through smart contracts.

[0075] Figure 3This is a schematic diagram of the functional flow of the dynamic function list provided in an embodiment of the present invention. The dynamic function list is a function management system that is defined in the cloud, dynamically distributed, and rendered in real time on the vehicle / mobile terminal. It decouples function control from software implementation, enabling fine-grained management at the function level.

[0076] The Dynamic Feature Model (DFM) technology functional flow can be divided into four stages:

[0077] Phase 1, DFM Generation (Cloud): Input Collection: The system collects multi-dimensional data such as vehicle status, user attributes, environmental information, and business rules; Condition Evaluation: The rule engine filters available functions based on preset conditions; Personalized Configuration: Function parameters are adjusted based on user profiles; Inventory Generation: A structured DFM document is built; Secure Signature: Digital signatures are used to ensure integrity.

[0078] Phase Two, DFM Distribution (Network Layer): On-demand delivery: Updates are pushed only when conditions change (incremental updates); Edge caching: Latency is reduced by utilizing CDN edge nodes; Version management: Supports multiple versions coexisting and canary releases;

[0079] Phase 3, DFM Execution (Client): Signature Verification and Parsing: Verify the DFM signature and parse the data structure; Real-time Evaluation: The local condition engine evaluates the functionality availability; Dynamic Rendering: Generate corresponding UI components based on the DFM description; Function Binding: Map UI interactions to specific function APIs;

[0080] Phase Four, Data Feedback (Closed-Loop Optimization): Usage Analysis: Collect data such as function usage frequency and duration; Problem Diagnosis: Monitor function anomalies and user feedback; Strategy Optimization: Adjust function conditions and parameters based on data.

[0081] The Dynamic Feature Inventory (DFM) includes complete version and signature information for each sub-feature, for verification on the mobile device. The feature data is as follows:

[0082]

[0083] On mobile devices, the data display entry point for the above functions only shows the signature approval function.

[0084] Figure 4 This is a schematic diagram illustrating the upgrade failure scenario handling process provided in an embodiment of the present invention. Figure 4 As shown, when the two-way verification fails, the recovery mechanism on both the vehicle and mobile terminals is triggered simultaneously.

[0085] The vehicle performs the following operations: 1. Restore the firmware to the most recently verified version; 2. Send a signed fault report.

[0086] On your mobile device, perform the following steps: 1. A downgrade page will pop up; restore the functionality to the previous version.

[0087] In this embodiment, for ease of description, the cloud is used as the execution subject in the following description. The cloud can be a software module, or other electronic devices capable of performing the following functions.

[0088] Figure 5 This is a flowchart illustrating a method for vehicle OTA version control and dynamic adaptation of mobile terminal functions provided in an embodiment of the present invention; as shown below. Figure 5 As shown, the method includes:

[0089] Step S1: Obtain the encrypted version feature code containing hardware fingerprint generated by the vehicle terminal. The encrypted version feature code containing hardware fingerprint has all ECU version information of the vehicle terminal.

[0090] Step S2: Perform bidirectional cross-verification by decrypting the encrypted version feature code containing the hardware fingerprint and the pre-stored benchmark value;

[0091] Step S3: When the two-way cross-validation passes, a dynamic function list (DFM) with a digital signature is generated and broadcast to the node network for each node to sign. Dynamic function lists that meet the preset signature threshold are packaged into blocks and written into the blockchain. The dynamic function list is used by the mobile terminal to dynamically render and generate corresponding UI components according to the description of the dynamic function list.

[0092] The above steps of this invention ensure that the dynamic function list obtained by the mobile terminal from the blockchain is completely consistent with the vehicle ECU version. Furthermore, the generation process of this dynamic function list undergoes two-way cross-validation and digital signature verification, thus guaranteeing the security and validity of the data. When the mobile terminal uses the above-mentioned function data to display function entry points, it only displays functions that have passed the signature verification.

[0093] Therefore, this invention solves the problem of real-time matching between the vehicle version and the mobile terminal functions, improves the matching degree between mobile terminal functions and vehicle software functions, and enhances the user experience.

[0094] In some embodiments, the method further includes: step S4, when bidirectional cross-validation fails, sending a recovery command to both the vehicle and mobile terminals to simultaneously trigger the recovery mechanisms on both the vehicle and mobile terminals.

[0095] In some embodiments, the encrypted version feature code containing hardware fingerprints is obtained by generating a first hardware hash (hash value H1) from the collected CPU number and the MAC address of the vehicle-side TBOX using a hash algorithm, and then encrypting the first hardware hash with the collected ECU version information concatenated according to alphabetical order using an encryption algorithm.

[0096] In some embodiments, step S2, the step of performing bidirectional cross-verification by decrypting the encrypted version feature code containing the hardware fingerprint and the pre-stored benchmark value, includes:

[0097] Step S21: Decrypt the encrypted version feature code containing the hardware fingerprint to obtain the first hardware hash (hash value H1).

[0098] Step S22: Calculate the pre-stored base value using the same hash algorithm as the vehicle-side hash to obtain the second hardware hash (hash value H2).

[0099] Step S23: Compare the first hardware hash (hash value H1) and the second hardware hash (hash value H2). If they match (H1 == H2), the bidirectional cross-validation passes; otherwise, the bidirectional cross-validation fails.

[0100] In some embodiments, step S3, when the bidirectional cross-validation passes, generates a digitally signed Dynamic Function List (DFM) and broadcasts it to the node network for each node to sign. The DFM lists that meet a preset signature threshold are packaged into blocks and written into the blockchain. The DFM list is used by the mobile terminal to dynamically render and generate corresponding UI components based on the description of the DFM list. The steps include:

[0101] Step S31: When the two-way cross-verification passes, extract all ECU version information of the vehicle end from the decrypted encrypted version feature code containing hardware fingerprint to form a first set F;

[0102] Step S32: Query the database to verify the validity of the first set F;

[0103] Step S33: Generate a dynamic function list based on the ECU version that has passed the verification of legality;

[0104] Step S34: After digitally signing the dynamic function list, broadcast it to the node network to obtain signatures from each node. When 2 / 3 of the nodes have signed, the dynamic function list is packaged into a block and written into the blockchain.

[0105] The above steps of this invention are used to verify the validity of data: the legality of the ECU version can be verified by querying the version compatibility matrix database in the cloud (including confirming that it is an official version, meets compatibility requirements, and meets vehicle configuration requirements, etc.). Then, a dynamic function list is generated based on the legal ECU version. After the dynamic function list is verified by signatures at each node, the validity of the data in the dynamic function list can be confirmed.

[0106] In some embodiments, step S32, the step of querying the database to verify the legality of the first set F, includes:

[0107] Step S321: Query the database to verify whether each ECU version in the first set is an officially released version, in order to confirm the authenticity of the ECU version;

[0108] Step S322: Verify whether the combination of different ECU versions is compatible;

[0109] Step S323: Verify whether the combination of each ECU version is compatible with the vehicle configuration.

[0110] In some embodiments, step S33, which generates a dynamic function list based on the ECU version that has passed the verification of legality, includes:

[0111] Step S331: Obtain multidimensional data, which includes at least one of vehicle status, user attributes, environmental information, and business rules;

[0112] Step S332: Set preset conditions based on the multidimensional data;

[0113] Step S333: Filter the available functions corresponding to the ECU versions that have passed the legality verification according to preset conditions;

[0114] Step S334: Adjust function parameters based on user profile;

[0115] Step S335: Build a structured dynamic feature list document.

[0116] Based on the same inventive concept, embodiments of the present invention also provide a vehicle OTA version control and mobile terminal function dynamic adaptation system, configured to implement any of the methods described in the above embodiments, the system comprising:

[0117] The acquisition module is used to receive data frames from two communication paths through two network interfaces respectively, perform CRC verification, discard erroneous data frames, and acquire data frames that pass the verification.

[0118] The comparison and submission module is used to extract the sequence number of each data frame that passes the verification as the target sequence number, compare the target sequence number with the expected sequence number (Expected_SEQ); if the target sequence number is equal to the expected sequence number, the data frame is submitted to the upper layer application and the expected sequence number is incremented by 1;

[0119] The data frame is generated by the sending end processing unit by attaching a globally unique and monotonically increasing sequence number to each key application data frame. The sequence number is the same as the initial value of the expected sequence number. The sending end processing unit sends two identical data frames into the two communication paths simultaneously.

[0120] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 6As shown, an embodiment of the present invention provides an electronic device including: 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 methods 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.

[0121] 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).

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

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

[0124] Based on the same inventive concept, embodiments of the present invention also provide a computer-readable medium. This computer-readable medium stores a computer program, wherein, when executed by a processor, the program implements the steps of any of the methods described in the above embodiments. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0125] 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).

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

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

[0128] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state 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 circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

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

[0130] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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.

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

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

[0133] 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 the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains 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 shown 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, may 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.

[0134] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, 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 the invention as set forth in the appended claims.

Claims

1. A method for dynamic adaptation of vehicle OTA version control and mobile terminal functions, characterized in that, include: Obtain the encrypted version feature code containing hardware fingerprint generated by the vehicle, wherein the encrypted version feature code containing hardware fingerprint has version information of all ECUs on the vehicle. The encrypted version feature code containing the hardware fingerprint is decrypted and then cross-verified with a pre-stored baseline value. When the two-way cross-validation passes, a dynamic function list with digital signature is generated and broadcast to the node network for each node to sign. The dynamic function lists that meet the preset signature threshold are packaged into blocks and written into the blockchain. The dynamic function list is used by the mobile terminal to dynamically render and generate corresponding UI components according to the description of the dynamic function list.

2. The method according to claim 1, characterized in that, Also includes: When bidirectional cross-validation fails, a recovery command is sent to both the vehicle and mobile terminals to simultaneously trigger the recovery mechanisms on both the vehicle and mobile terminals.

3. The method according to claim 1 or 2, characterized in that, The encrypted version feature code containing hardware fingerprints is obtained by generating a first hardware hash using a hash algorithm from the collected CPU number and the MAC address of the vehicle-side TBOX, and then encrypting the first hardware hash with the collected ECU version information concatenated in alphabetical order using an encryption algorithm.

4. The method according to claim 3, characterized in that, The step of performing bidirectional cross-verification by decrypting the encrypted version feature code containing the hardware fingerprint and comparing it with the pre-stored benchmark value includes: The first hardware hash is obtained by decrypting the encrypted version feature code containing the hardware fingerprint; The second hardware hash is obtained by calculating the pre-stored base value using the same hash algorithm as that used on the vehicle. Compare the first hardware hash and the second hardware hash. If they match, the two-way cross-validation passes; otherwise, the two-way cross-validation fails.

5. The method according to claim 3, characterized in that, When the bidirectional cross-validation passes, a dynamic function list with a digital signature is generated and broadcast to the node network for each node to sign. Dynamic function lists that meet a preset signature threshold are packaged into blocks and written to the blockchain. The steps for the mobile device to dynamically render and generate corresponding UI components based on the description of the dynamic function list include: When the two-way cross-verification passes, the first set is formed by extracting all ECU version information of the vehicle from the encrypted version feature code containing the hardware fingerprint after decryption. Query the database to verify the validity of the first set; A dynamic feature list is generated based on the ECU version that has passed the verification of legality. The dynamic function list is digitally signed and broadcast to the node network to obtain signatures from each node. When 2 / 3 of the nodes have signed, the dynamic function list is packaged into a block and written into the blockchain.

6. The method according to claim 5, characterized in that, The steps for querying the database to verify the legality of the first set include: Query the database to verify whether each ECU version in the first set is an officially released version; Verify the compatibility of combinations of different ECU versions; Verify that the combination of different ECU versions is compatible with the vehicle configuration.

7. The method according to claim 5, characterized in that, The step of generating a dynamic feature list based on the ECU version that has passed the verification of legality includes: Obtain multidimensional data, which includes at least one of vehicle status, user attributes, environmental information, and business rules; Set preset conditions based on the multidimensional data; The available functions are selected based on preset conditions and the ECU version that has passed the legality verification. Adjust function parameters based on user profiles; Build a structured, dynamic feature list document.

8. A vehicle OTA version control and mobile terminal function dynamic adaptation system, characterized in that, The system, configured to implement the method as described in any one of claims 1 to 7, comprises: The acquisition module is used to acquire the encrypted version feature code containing hardware fingerprint generated by the vehicle terminal, wherein the encrypted version feature code containing hardware fingerprint has version information of all ECUs on the vehicle terminal; The two-way cross-validation module is used to perform two-way cross-validation by decrypting the encrypted version feature code containing the hardware fingerprint and the pre-stored benchmark value; The generation module is used to generate a dynamic function list with digital signatures when the two-way cross-validation passes. This list is then broadcast to the node network for each node to sign. Dynamic function lists that meet the preset signature threshold are packaged into blocks and written into the blockchain. The dynamic function list is used by the mobile terminal to dynamically render and generate corresponding UI components based on the description of the dynamic function list.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images