Vehicle software version release management method and system

Abstract

The invention provides a release management method and system for a vehicle software version. The release management method comprises the following steps: executing three-level software version release of a module-level software version, an electronic control unit (ECU)-level software version and a whole vehicle software version based on a workflow engine; in the release process of the three-level software versions, storing all levels of software versions and compatibility rules of the hardware version of the vehicle and all levels of software versions; executing dynamic verification on the whole vehicle software version based on the compatibility rule, and under the condition that the dynamic verification is passed, storing version information of the whole vehicle software version in a block chain; and in response to the fact that a preset triggering condition is met, the whole vehicle software version is encrypted and pushed to a plurality of vehicles through a message queue.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle software management, and in particular to a method and system for managing the release of vehicle software versions. Background Art

[0002] With the rapid development of intelligent connected vehicles, vehicle software systems are becoming increasingly complex. Software version management has become a crucial component in ensuring vehicle functional stability and safety. Traditional vehicle software release methods often rely on manual operations and decentralized management systems, resulting in a lack of unified version control standards and difficulties in achieving efficient collaboration and full-process traceability.

[0003] In related technologies, a centralized database is typically used to record software version information, and version review and release are performed through manual processes. Some systems introduce process engines to streamline the version release process, but there is a lack of linkage mechanisms between multi-level software versions (such as module level, ECU level, and vehicle level), and version compatibility verification is often performed in the later testing phase, lacking real-time dynamic verification methods. In addition, the storage and transmission security of version information is insufficient, posing the risk of data tampering or version confusion.

[0004] Due to the lack of unified version release process management, dynamic compatibility verification, and secure evidence storage mechanisms, related technologies are unable to effectively cope with the complexity and security requirements of vehicle software version releases, affecting the implementation efficiency of the software-defined vehicle (SDV) strategy. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for managing the release of vehicle software versions. To achieve the above purpose, the technical solutions adopted in this application are as follows:

[0006] In a first aspect, a vehicle software version release management method is provided, comprising: executing three-level software version release of module-level software version, electronic control unit ECU-level software version and whole vehicle software version based on a workflow engine; storing software versions at each level and compatibility rules between the vehicle's hardware version and the software versions at each level during the three-level software version release process; performing dynamic verification of the whole vehicle software version based on the compatibility rules, and if the dynamic verification passes, storing the version information of the whole vehicle software version in a blockchain; and encrypting and pushing the whole vehicle software version to multiple vehicles through a message queue in response to meeting a preset trigger condition.

[0007] Based on the above technical approach, a workflow engine is introduced to implement a three-level software release process: module, ECU, and vehicle. During the three-level software release process, compatibility rules are established between the vehicle hardware version and each level of software version. These compatibility rules establish a strong correlation between the vehicle hardware and software versions. Compatibility between the vehicle and software versions is verified based on these compatibility rules, preventing system failures caused by compatibility issues during software releases and vehicle upgrades. For verified vehicle software versions, blockchain technology is used to store version information to ensure data immutability. When trigger conditions are met, encrypted push notifications are implemented via message queues, improving the efficiency and security of vehicle software version management. This approach not only effectively addresses the decentralized management, data silos, and traceability issues inherent in traditional version management, but also provides core support for automakers' software-defined vehicle strategies. For example, in scenarios where a batch of vehicles requires a hardware upgrade, the compatibility of the current software levels with the vehicle hardware levels is determined based on the compatibility rules corresponding to the vehicle hardware version. This allows the most compatible vehicle software version to be matched, and the vehicle can be upgraded based on that vehicle software version, thereby improving the efficiency of vehicle R&D, testing, and production.

[0008] In some embodiments, the vehicle's hardware version includes the vehicle's entire hardware version and the hardware versions of multiple electronic control units in the vehicle. Storing software versions at each level and compatibility rules between the vehicle's hardware version and the software versions at each level includes: storing the software versions at each level in a relational database; defining the compatibility rules using structured data, the compatibility rules including: the range of vehicle software versions corresponding to the vehicle's entire hardware version; the dependency between the vehicle software version and ECU-level software versions corresponding to different electronic control units in the vehicle; the range of ECU-level software versions corresponding to the hardware versions of multiple electronic control units in the vehicle; and the dependency between each ECU-level software version and the module-level software version; and storing the compatibility rules in the relational database.

[0009] The above technical approach, through the use of a relational database to store software versions at all levels and the definition of compatibility rules using structured data, enables efficient management of vehicle software and hardware versions, significantly improving data query efficiency. This ensures accurate compatibility verification during the version release process, thereby avoiding system failures caused by version mismatches and improving the security and efficiency of vehicle software releases.

[0010] In some embodiments, the dynamic verification of the whole vehicle software version based on the compatibility rules includes: determining the hardware version of the target vehicle; obtaining the target compatibility rules corresponding to the hardware version of the target vehicle; according to the target compatibility rules, determining that the whole vehicle software version passes the dynamic verification when the following conditions are met: the whole vehicle software version matches the whole vehicle hardware version of the target vehicle; the versions of multiple ECU-level software in the whole vehicle software are compatible with the whole vehicle software version; the versions of multiple ECU-level software in the whole vehicle software match the hardware versions of the multiple electronic control units; the versions of multiple module-level software in each of the ECU-level software are compatible with the ECU-level software version.

[0011] In the technical solution provided in the application, when upgrading the whole vehicle software version, based on the software and hardware compatibility rules and the multi-level dependency relationship of different levels of software, a layered progressive logic of whole vehicle hardware version-compatibility rules-whole vehicle software-ECU software-ECU hardware-module software is established; the verification method starting from the whole vehicle hardware version can significantly improve efficiency, lock the verification range within the scope of multiple rules that are strongly related to the current hardware, and combined with the efficient query of the relational database, it can significantly improve the query efficiency compared with the traditional solution of traversing all software versions to match hardware or traversing all ECU hardware versions to match software versions. At the same time, based on the above verification process, the software version is released only when the dependency relationship between the software versions at all levels and the compatibility verification of the software versions at all levels with the vehicle hardware version are ensured. This avoids a series of problems caused by incomplete local verification in the verification method of hardware version-whole vehicle software version-ECU software version in the related art. For example, if the "matching of the whole vehicle software with the overall hardware" is skipped and the ECU software is verified directly, the ECU software may be partially adapted, but the whole vehicle software may be incompatible with the hardware.

[0012] Using these technical approaches, by determining the target vehicle's hardware version and obtaining the corresponding compatibility rules, we can then perform a multi-dimensional dynamic verification of the vehicle's software version. This allows for a comprehensive assessment of the compatibility of the software version with the hardware configuration, effectively preventing system failures caused by version incompatibility.

[0013] In some embodiments, obtaining the target compatibility rules corresponding to the hardware version of the target vehicle includes: reading the target compatibility rules from the distributed cache according to the hardware version of the target vehicle; and reading the target compatibility rules from the relational database if the target compatibility rules are not hit in the distributed cache.

[0014] According to the above technical means, by storing the target compatibility rules in the distributed cache and reading the rules from the relational database when the cache misses, the system can complete the version compatibility verification task efficiently and reliably.

[0015] In some embodiments, the blockchain includes multiple nodes, which include multiple peer nodes and at least one sorting node. The storing of version information of the whole vehicle software version in the blockchain includes: calling a smart contract interface to encapsulate the metadata of the whole vehicle software version into a transaction proposal, wherein the metadata includes the whole vehicle software version number, a compatible hardware list, and a test report hash value; synchronizing the transaction proposal to the blockchain for signature confirmation through multiple peer nodes to form multiple endorsement responses; collecting the multiple endorsement responses through the at least one sorting node, packaging the transaction proposal into a block, and broadcasting the block to the multiple peer nodes; verifying the validity of the block through the peer node and updating the local ledger.

[0016] Using these technical approaches, smart contracts encapsulate version metadata into transaction proposals, which are then signed and confirmed by multiple peer nodes, ensuring the legitimacy and credibility of transactions. Ordering nodes are responsible for block generation and broadcast, ensuring the orderliness and consistency of transactions. Ultimately, peer nodes verify and update the ledger, enabling distributed data storage and synchronization, enhancing the security and transparency of the system.

[0017] In some embodiments, the method also includes: storing the source code package of the vehicle software version to the star file system IPFS and obtaining a content identifier; recording the content identifier in the blockchain transaction and binding the hash value of the source code through a smart contract; and establishing a traceable index from the blockchain evidence record to the IPFS file.

[0018] The aforementioned technical approach involves storing the source code package of the vehicle software version on IPFS and obtaining a content identifier. This identifier is then recorded in a blockchain transaction and bound to the source code hash value via a smart contract. Finally, a traceable index is established from the blockchain evidence record to the IPFS file. This ensures the storage security and data consistency of the source code, enabling full traceability of the vehicle software version.

[0019] In some embodiments, the method further includes: in response to a vehicle hardware version update event, updating the compatibility rules between the vehicle's hardware version and various levels of software versions; performing dynamic verification on the vehicle software version based on the updated compatibility rules; if the dynamic verification fails, re-executing the three-level software version release of the module-level software version, the electronic control unit-level software version and the vehicle software version based on the updated compatibility rules; and recording the change history of the vehicle's hardware version and the vehicle software version in the blockchain.

[0020] By responding to hardware version update events and dynamically updating compatibility rules, the above technical measures can effectively ensure the compatibility of vehicle software versions with hardware. This can avoid functional anomalies or system crashes caused by version incompatibility, thereby improving the stability and reliability of vehicle software.

[0021] In some embodiments, the method further includes: obtaining vehicle hardware version information and vehicle software version information of each vehicle among the multiple vehicles; generating a version heat map in a visualization interface, wherein the version heat map includes the number of different vehicle software versions of each vehicle model among the multiple vehicles.

[0022] Using these technical approaches, a version heat map generated within a visual interface can intuitively display the distribution of software versions across different vehicle models, helping managers quickly identify version concentration, update requirements, and potential compatibility issues. This improves the efficiency and accuracy of version management, enabling the optimization of vehicle software release strategies and, ultimately, enhancing the overall management of automotive software-defined capabilities.

[0023] In some embodiments, the preset trigger condition includes at least one of the following: the vehicle mileage reaches a preset mileage threshold; the vehicle is detected to be within a specific geographical location range; a batch update instruction sent by an external system is received.

[0024] According to the above technical means, by setting a variety of preset trigger conditions, the push timing of the vehicle software version can be flexibly controlled; by setting a variety of preset trigger conditions, it can ensure that the encrypted update of the vehicle software version is timely and accurate, thereby avoiding unnecessary waste of resources.

[0025] In a second aspect, a vehicle software version release management system is provided, comprising: a version release unit for executing three levels of software version release: module-level software version, electronic control unit (ECU)-level software version, and vehicle-level software version, based on a workflow engine; a storage unit for storing compatibility rules between each level of software version and the vehicle's hardware version during the three-level software version release process; a verification and evidence storage unit for dynamically verifying the vehicle-level software version based on the compatibility rules, and if the dynamic verification passes, storing the vehicle-level software version information in a blockchain; and a push unit for encrypting and pushing the vehicle-level software version to multiple vehicles via a message queue in response to a preset trigger condition being met. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A flowchart of a method for managing the release of vehicle software versions provided in an embodiment of the present application;

[0027] Figure 2 A schematic flowchart of a method for storing software versions and compatibility rules in the release management method provided in an embodiment of the present application;

[0028] Figure 3 A schematic flowchart of a method for dynamically verifying the vehicle software version based on compatibility rules in the release management method provided in an embodiment of the present application;

[0029] Figure 4 A schematic flowchart of a method for obtaining target compatibility rules corresponding to the hardware version of a target vehicle in the release management method provided in an embodiment of the present application;

[0030] Figure 5 A schematic flow chart of a method for storing vehicle software version information in a blockchain in the release management method provided in an embodiment of the present application;

[0031] Figure 6 Another schematic flow chart of the method for storing vehicle software version information in a blockchain in the release management method provided in an embodiment of the present application;

[0032] Figure 7 A flowchart of another method for managing the release of vehicle software versions provided in an embodiment of the present application;

[0033] Figure 8 A flowchart of a method for managing the release of vehicle software versions provided in another embodiment of the present application;

[0034] Figure 9 An example diagram of a version heat map provided in an embodiment of the present application;

[0035] Figure 10A schematic structural diagram of a vehicle software version release management system provided in an embodiment of the present application;

[0036] Figure 11 A schematic diagram of a vehicle software version release management system provided in one embodiment of the present application;

[0037] Figure 12 A flowchart of a three-level publishing method based on the Camunda process engine provided in one embodiment of the present application;

[0038] Figure 13 This is a flow chart of a method for uploading data to a blockchain in a solution according to an embodiment of the present application;

[0039] Figure 14 A schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The following will describe the embodiments of the present application with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand the other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for the purpose of illustrating the present application and are not intended to limit the scope of protection of the present application.

[0041] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present application. Therefore, the illustrations only show components related to the present application and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0042] In related technologies, the rapid development of intelligent connected vehicles has led to an exponential increase in vehicle software complexity. Traditional vehicle software release methods typically rely on manual operations and decentralized management systems, resulting in a lack of unified version control standards and difficulties in achieving efficient collaboration and full-process traceability. This leads to problems such as decentralized management, data silos, traceability difficulties, and insufficient security.

[0043] To address the above issues, this application provides a method and system for managing the release of vehicle software versions. By introducing a workflow engine to implement a three-level software release process at the module, ECU, and vehicle levels, and combining blockchain technology to store vehicle software versions, ensuring data cannot be tampered with, and implementing encrypted push notifications through a message queue, the efficiency and security of vehicle software version management are improved.

[0044] The technical solutions provided in the embodiments of the present application will be described in detail below with reference to the accompanying drawings. Figure 1 This is an optional flow chart of the release management method of the whole vehicle software version provided in an embodiment of the present application. The method can be executed by a system platform, which can be a management platform deployed on a server or a microservice cluster under a distributed architecture. Figure 1 The method includes steps S110-S140.

[0045] In step S110 , based on the workflow engine, three levels of software version release are executed, namely, module-level software version, electronic control unit ECU-level software version, and vehicle software version.

[0046] The workflow engine can be, for example, the Camunda process engine. The Camunda process engine is an open-source workflow engine based on the BPMN standard, used to define, execute, and monitor business processes. The Camunda process engine enables the construction of three-level software release processes: module-level, ECU-level, and vehicle-level. This allows for visual approval and permission control, thereby standardizing the software release process.

[0047] In the embodiments of the present application, "module-level software version" refers to the software version corresponding to the smallest unit module in the vehicle, the ECU-level software version refers to the software version of the electronic control unit that integrates multiple modules, and the vehicle-level software version refers to the software version corresponding to the entire vehicle composed of multiple ECUs.

[0048] As an example, the three-level software version release based on the aforementioned workflow engine may include:

[0049] Developers create module release orders through the web interface, fill in information such as the module name, version number, and function description, and upload development products and self-test reports to trigger the automated approval process of the Camunda process engine. After approval, the module version information is first stored in the MySQL database and accelerated query through the Redis cache. For ECU-level software version releases, you can select the released module software version, configure the ECU's hardware parameters and functional requirements, form the ECU-level software version, and then pass the Camunda process engine for approval again. Vehicle-level releases are based on the ECU-level version. According to the vehicle configuration and vehicle architecture information, the software versions of all ECUs are combined to form the vehicle-level software version, and the final release is completed through a multi-level approval process.

[0050] It's also worth noting that the Camunda process engine supports approval nodes at different levels. For example, a module-level release might only require approval from a department manager, while a vehicle-level release might require approval from multiple parties, including the product manager, test supervisor, and quality supervisor. Furthermore, the process engine can set different approval permissions based on user roles, ensuring that only those with the appropriate permissions can initiate or approve release requests, thereby improving the security and controllability of the entire release process.

[0051] In step S120 , during the three-level software release process, the software versions at each level and the compatibility rules between the vehicle's hardware version and the software versions at each level are stored.

[0052] In the embodiment of the present application, the compatibility rule refers to the matching relationship between the vehicle's hardware version and the software versions at all levels, including the matching relationship between the vehicle's hardware version and the whole vehicle software version, and the matching relationship between the vehicle's hardware version and the ECU-level software version; according to the previous description, the whole vehicle-level software includes multiple ECU-level software, and each ECU-level software contains multiple module-level software. The above matching relationship also includes the matching relationship between the whole vehicle software version and the vehicle's ECU hardware version, as well as the matching relationship between each ECU-level software version and the module-level software version.

[0053] These rules are usually defined in JSON Schema format, stored in a MySQL database, and access is accelerated through Redis cache. For example, a vehicle's hardware version HWC.2.1 may only be compatible with vehicle software versions between SWC.1.2.0 and SWC.2.0.5, and this version of the vehicle software has specific software version requirements for certain ECUs (such as the power domain controller); in addition, each ECU software version also has some specific requirements for the next-level module-level software version. This compatibility information not only helps with dynamic verification during the release process, but also provides a basis for subsequent version updates to ensure that the new version of the software will not conflict with existing hardware.

[0054] The compatibility rules described above can also be referred to as a compatibility matrix. In practice, when hardware or software versions change, the system triggers an event message, updates the compatibility matrix, and broadcasts it to the vehicle terminal. This ensures the system always uses the latest compatibility rules for version verification, avoiding system failures or performance issues caused by version mismatches.

[0055] Step S130: Perform dynamic verification on the vehicle software version based on the compatibility rules. If the dynamic verification passes, the version information of the vehicle software version is stored in the blockchain.

[0056] The dynamic verification process may include the following aspects: checking whether the vehicle software version matches the vehicle hardware version, checking whether the vehicle software version and each ECU-level software version meet the corresponding dependency relationship, checking whether each ECU-level software version matches the vehicle's ECU hardware version, and checking the dependency relationship between each ECU-level software version and the module-level software.

[0057] For example, if the submitted software version is V2.5 and the vehicle's hardware version supports V3.1, the dynamic verification will reject the release request of the submitted software version and prompt you to select a higher version or adjust the vehicle's hardware version.

[0058] For example, if an ECU requires a software version no lower than SWC.1.3, and the currently released version is SWC.1.2, the system will intercept this version to prevent it from being mistakenly released and installed on the vehicle.

[0059] After the dynamic verification is passed, the system will package the metadata of the vehicle software version (such as version number, compatible hardware list, test report hash, etc.) into a transaction proposal, and call the blockchain smart contract interface to write the data into the blockchain network.

[0060] As an implementation, the aforementioned blockchain utilizes the Hyperledger Fabric consortium chain framework. Peer nodes execute smart contracts and maintain the distributed ledger, while orderer nodes generate blocks and broadcast them to the entire network, ensuring data consistency and immutability. Large files (such as source code packages) are stored on the IPFS network, with their content identifiers (CIDs) recorded in the blocks for quick retrieval.

[0061] Blockchain-based evidence storage not only ensures the integrity and security of version information but also enables full traceability of version history. For example, when a vehicle breaks down, a blockchain browser can quickly locate the version history and associated test reports, helping technicians quickly identify the root cause and improve troubleshooting efficiency.

[0062] In step S140, in response to the preset triggering condition being met, the vehicle software version is encrypted and pushed to multiple vehicles through the message queue.

[0063] In some embodiments, the preset departure condition may be a combination of one or more factors, such as the vehicle mileage reaching a preset mileage value, the user manually requesting an OTA update, or the system detecting that a new software version is available.

[0064] When trigger conditions are met, the vehicle software version can be encrypted and pushed to multiple vehicles via message queues such as Kafka or RabbitMQ. Message queues decouple direct dependencies between system components, improving system reliability and scalability. Through message queues, the system can asynchronously process a large number of version update requests, ensuring that every vehicle receives the update instructions at the appropriate time.

[0065] When pushing data through a message queue, the pushed data can also be encrypted using data encryption technologies such as AES-256 to prevent the data from being illegally intercepted or tampered with during transmission.

[0066] According to the above technical means, a workflow engine is introduced to realize the release process of three-level software versions at module level, ECU level and vehicle level. During the three-level software release process, compatibility rules between vehicle hardware versions and software versions at all levels are established. The compatibility rules establish a strong correlation between vehicle hardware and software versions; based on the above compatibility rules, the compatibility of the vehicle and software versions is verified to avoid system failures caused by compatibility issues during software release and vehicle upgrades; for the vehicle software version that passes the verification, the version information is stored in combination with blockchain technology to ensure that the data cannot be tampered with; when the trigger conditions are met, encrypted push is achieved through the message queue, thereby improving the efficiency and security of vehicle software version management.

[0067] This approach not only effectively addresses the decentralized management, data silos, and traceability challenges inherent in traditional version management, but also provides core support for automakers' software-defined vehicle strategies. For example, in scenarios where a batch of vehicles requires a hardware upgrade, the compatibility of the current software and hardware levels can be determined based on the compatibility rules corresponding to the vehicle's hardware version. This allows the most compatible vehicle software version to be matched, and the vehicle can be upgraded based on that software version, thereby improving the efficiency of vehicle R&D, testing, and production.

[0068] In some embodiments, participation Figure 2 The aforementioned step S120 stores the compatibility rules between the software versions at all levels and the hardware version of the vehicle and the software version of the entire vehicle, and further includes steps S121-S123.

[0069] In step S121, software versions at all levels are stored in a relational database.

[0070] A relational database is a database system that stores data in tabular form. It supports Structured Query Language (SQL) and can efficiently retrieve and update data.

[0071] The software versions at all levels mentioned here include module-level, ECU-level, and vehicle-level versions. Storing this version information in a relational database enables centralized management of software versions, supporting fast query and version rollback.

[0072] In step S122, compatibility rules are defined using structured data. These compatibility rules include: the range of vehicle software versions corresponding to the vehicle hardware version, the dependency between the vehicle software version and the ECU-level software versions corresponding to different electronic control units in the vehicle, the range of ECU-level software versions corresponding to the hardware versions of multiple electronic control units in the vehicle, and the dependency between each ECU-level software version and the module-level software version.

[0073] Structured data refers to data with a fixed format and well-defined fields, such as JSON or XML. Defining these compatible specifications as structured data facilitates parsing and processing. This is particularly true in scenarios such as vehicle factories, where information about the versions of vehicles with different models or hardware configurations is stored. Structured data, with its predefined fixed schema and efficient indexing, significantly improves data query efficiency.

[0074] The vehicle hardware version refers to the version number of the vehicle's hardware configuration, and the vehicle software version range indicates the range of software versions that the hardware version is compatible with. The dependency relationship between the electronic control unit and the vehicle software version refers to the corresponding relationship between the software versions required for the operation or function of various electronic control units (such as the engine control unit and brake control unit).

[0075] The following are some examples of the compatibility rules, which reflect the compatibility relationship between the vehicle hardware version and the vehicle software version, as well as the dependency relationship between the vehicle software version and the ECU-level software version:

[0076]

[0077]

[0078] The above exemplary compatibility rules indicate that when the hardware version is HWC.2.1, the maximum vehicle software version number it can be compatible with is SWC.2.0.5, and the minimum compatible vehicle version number is SWC.1.2.0; at this time, the vehicle software version requires that the software version number of the power domain controller is SWC.1.3 and above, and the software version number of the infotainment system is SWC.2.5 and above.

[0079] In step S123, the compatibility rules are stored in a relational database.

[0080] Because compatibility rules typically include information from multiple dimensions, such as hardware versions, software version ranges, and ECU dependencies, using a relational database can ensure data consistency and integrity. Furthermore, the database's transaction mechanism ensures that data conflicts and data loss do not occur during storage.

[0081] Based on steps S121-S123 above, a complete software and hardware version management framework is constructed. First, a relational database is used to centrally store software versions at all levels, ensuring the uniformity and traceability of version information. Second, structured data is used to define compatibility rules, enabling the system to quickly determine software version compatibility based on hardware versions and ECU configurations. Finally, these compatibility rules are stored again in the relational database to ensure data consistency and integrity.

[0082] The above technical approach, through using a relational database to store software versions at all levels and defining compatibility rules with structured data, enables efficient management of vehicle software and hardware versions. This ensures accurate compatibility verification during the release process, thereby avoiding system failures caused by version mismatches and improving the security and efficiency of vehicle software releases.

[0083] In some embodiments, see Figure 3 The aforementioned step S130, dynamically checking the vehicle software version based on the compatibility rules, further includes steps S131-S134.

[0084] In step S131 , the hardware version of the target vehicle is determined.

[0085] The hardware version of the target vehicle includes the entire vehicle hardware version of the target vehicle and the hardware versions of multiple electronic control units in the target vehicle.

[0086] In step S132 , the target compatibility rule corresponding to the hardware version of the target vehicle is obtained.

[0087] As described above, target compatibility rules refer to a set of rules extracted from a pre-set compatibility matrix based on the target vehicle's hardware version to determine whether the hardware version supports the current vehicle software version. Target compatibility rules include, but are not limited to, the minimum and maximum software version ranges supported by the hardware version and the minimum software version requirements for each ECU.

[0088] In step S133, the compatibility check of the vehicle software version is performed according to the target rules.

[0089] According to the target compatibility rules, the vehicle software version is determined to have passed the dynamic verification if the following conditions are met: the vehicle software version matches the vehicle hardware version of the target vehicle; the versions of multiple ECU-level software in the vehicle software are compatible with the vehicle software version; the versions of multiple ECU-level software in the vehicle software match the hardware versions of multiple electronic control units; the versions of multiple module-level software in each ECU-level software are compatible with the ECU-level software version.

[0090] More specifically, first, the system will verify whether the vehicle software version meets the requirements of the target vehicle's vehicle hardware version. For example, if the vehicle software version is SWC2.0.3 and the target vehicle's vehicle hardware version is HWC2.1, then determine whether the vehicle software version is within the compatibility range of HWC2.1; secondly, check the compatibility of multiple ECU-level software versions in the vehicle software with the vehicle software version. Specifically, each vehicle software version has specific requirements for the versions of multiple ECU software that constitute it. For example, when the vehicle software version is SWC2.0.3, confirm whether the software version of the power domain controller is SWC.1.3 and above; thirdly, check the compatibility of multiple ECU-level software with the hardware versions of multiple electronic control units of the vehicle. For example, different hardware versions of the power domain controller have different requirements for the software version. Based on the above-mentioned compatibility rules, check the compatibility of ECU software and hardware; finally, ECU-level software includes multiple module-level software. Therefore, the compatibility of the software versions of these two levels also needs to be checked.

[0091] The following is an example of a verification algorithm, which shows the verification process of the compatibility of the vehicle software version with the vehicle hardware version and the compatibility of the vehicle software version with the ECU-level software version:

[0092]

[0093] In the above verification algorithm: First, define a function named check_compatibility that accepts two parameters: hw_version (hardware version) and sw_version (software version). Then, attempt to retrieve the compatibility matrix data for the specified hardware version from the Redis cache, and use the key compatibility:{hw_version} to store and retrieve the compatibility information for the corresponding hardware version. Check whether the compatibility matrix data was retrieved from Redis. If the matrix is ​​None or empty, it means that the corresponding data was not found in the cache. If there is no data in the cache, execute an SQL query to retrieve the record with the hw field equal to hw_version from the compatibility table and query the compatibility information for that hardware version. After obtaining the compatibility matrix, compare whether sw_version is less than the minimum compatible version min_sw or greater than the maximum compatible version max_sw, that is, check whether the current software is within the range specified by the compatibility matrix. If the software version is no longer within the compatible range, output: "Software version is out of compatible range." After this, traverse the list of all dependent ECUs defined in the compatibility matrix. Check whether the current ECU software version includes the version required in the dependency. If the version of a certain ECU does not meet the requirements, the output is "Version does not meet the requirements"

[0094] In step 134 , when the vehicle software version matches the vehicle hardware version of the target vehicle and the hardware versions of the plurality of electronic control units, it is determined that the vehicle software version passes the dynamic verification.

[0095] Once the vehicle software version passes all of the above compatibility checks, the system will determine that the software version has passed dynamic verification and allow it to continue the subsequent release process. Otherwise, the system will block the release of the version and prompt the specific incompatibility reasons so that developers can correct them.

[0096] In related technologies, when conducting vehicle OTA management, the hardware version of the entire vehicle is usually matched according to the parts information of each controller in the vehicle, and the software version of the entire vehicle is matched according to the software version of each controller. After the new vehicle software version is released, the vehicle that needs to be upgraded is matched according to the vehicle hardware version, and then the ECU that needs to be upgraded is automatically screened and upgraded.

[0097] In the technical solution provided in the application, when upgrading the whole vehicle software version, based on the aforementioned software and hardware compatibility rules and the multi-level dependency relationship of different levels of software, a layered progressive logic of whole vehicle hardware version-compatibility rules-whole vehicle software-ECU software-ECU hardware-module software is established; the verification method starting from the whole vehicle hardware version can significantly improve efficiency, lock the verification scope within the scope of multiple rules that are strongly related to the current hardware, and combined with the efficient query of the relational database, it can significantly improve the query efficiency compared with the traditional solution of traversing all software versions to match hardware or traversing all ECU hardware versions to match software versions. At the same time, based on the above verification process, the software version is released only when the dependency relationship between the software versions at all levels and the compatibility verification of the software versions at all levels with the vehicle hardware version are ensured. This avoids a series of problems caused by incomplete local verification in the verification method of hardware version-whole vehicle software version-ECU software version in the related art. For example, if the "matching of whole vehicle software and overall hardware" is skipped and the ECU software is verified directly, the ECU software may be partially adapted, but the whole vehicle software may be incompatible with the hardware.

[0098] Using these technical approaches, by determining the target vehicle's hardware version and obtaining the corresponding compatibility rules, we can then perform a multi-dimensional dynamic verification of the vehicle's software version. This allows for a comprehensive assessment of the compatibility of the software version with the hardware configuration, effectively preventing system failures caused by version incompatibility.

[0099] In some embodiments, see Figure 4 The aforementioned step S132 obtains the target compatibility rule corresponding to the hardware version of the target vehicle, and further includes steps S1321-S1322.

[0100] In step S1321, the target compatibility rules are read from the distributed cache according to the hardware version of the target vehicle.

[0101] Distributed caching is a high-performance, memory-based data storage technology used to quickly access frequently queried data. In an embodiment of the present application, a distributed cache (such as Redis) is used to store compatibility rules between common hardware and software versions to improve system responsiveness and reduce frequent access to the relational database. For example, when multiple vehicles have the same hardware version, their corresponding compatibility rules can be cached, avoiding repeated database queries.

[0102] The hardware version refers to the combined state of the hardware components assembled during the vehicle's manufacturing process. It typically consists of information such as the vehicle model, controller model, and sensor configuration. This version information is used to determine whether a vehicle supports a specific software version or functional module. For example, a vehicle may be equipped with different versions of the ECU (electronic control unit) in different years, and these differences will affect software compatibility.

[0103] In step S1322, if the target compatibility rule is not found in the distributed cache, the target compatibility rule is read from the relational database.

[0104] A cache miss occurs when an attempt to read data from the cache fails and the requested data is not present. In this case, the system must fall back to the relational database to query for complete compatibility rule information. For example, if a hardware version is unique or rarely used, its corresponding compatibility rule may not yet be cached. In this case, the system will retrieve the rule from the relational database.

[0105] According to the above technical means, by storing the target compatibility rules in the distributed cache and reading the rules from the relational database when the cache misses, the system can complete the version compatibility verification task efficiently and reliably.

[0106] In some embodiments, see Figure 5 In the aforementioned step S130, the vehicle software version information is stored in the blockchain, including steps S151-S154.

[0107] It should be noted that the blockchain used in the technical solution of the embodiment of the present application can be a Hyperledger Fabric blockchain network, which includes multiple peer nodes and at least one sorting node. The peer nodes are responsible for executing smart contracts, maintaining local ledgers, and participating in the endorsement of transactions; the sorting nodes are responsible for receiving transaction proposals from peer nodes, packaging them into blocks after sorting, and broadcasting them to other peer nodes in the network. By deploying multiple peer nodes and sorting nodes, high availability and fault tolerance can be achieved to ensure that even if some nodes fail, the entire system can still operate normally. In addition, the multi-organization identity authentication (MSP) mechanism supports car companies, suppliers and third-party institutions to jointly participate in the data chain process, thereby enhancing the credibility and collaboration capabilities of the system.

[0108] In step S151, the smart contract interface is called to encapsulate the metadata of the vehicle software version into a transaction proposal.

[0109] The above-mentioned smart contract interface is a set of programmable rules deployed on the blockchain network to execute predefined business logic.

[0110] In an embodiment of the present application, the smart contract interface is responsible for receiving the metadata of the vehicle software version and encapsulating it into a transaction proposal in a standard format.

[0111] The above metadata includes the version number, compatible hardware list and test report hash value. The version number identifies the specific version of the software, the compatible hardware list describes the hardware platforms supported by the version, and the test report hash value is generated by an encryption algorithm to ensure the integrity of the test report content.

[0112] By encapsulating metadata as a transaction proposal, data consistency can be guaranteed during subsequent signature confirmation and block packaging in the blockchain network.

[0113] In step S152, the transaction proposal is synchronized to the blockchain for signature confirmation by peer nodes to form multiple endorsement responses.

[0114] Peer nodes are participating nodes in the blockchain network. Each peer node maintains a complete copy of the ledger and is responsible for executing smart contract code.

[0115] When a transaction proposal is submitted to the blockchain network, multiple peer nodes will sign and confirm the proposal according to the preset endorsement policy, thereby generating multiple endorsement responses; endorsement responses indicate that the transaction proposal meets the consensus conditions reached between organizations and are an important basis for subsequent block generation.

[0116] In this embodiment of the present application, multiple peer nodes can come from automakers, suppliers, and third-party certification organizations. They each verify the legitimacy of the transaction proposal and sign the confirmation if the conditions are met. For example, if the version number included in the proposal conflicts with the historical record, or the test report hash value fails verification, the peer node may refuse to sign. This multi-node signature mechanism enhances the security and credibility of the system.

[0117] In step S153, multiple endorsement responses are collected by at least one sorting node, the transaction proposal is packaged into a block, and the block is broadcast to multiple peer nodes.

[0118] The above-mentioned sequence node is a component in the blockchain network that is specifically responsible for transaction sorting and block generation. It does not participate in the execution and verification of the ledger, but is responsible for collecting multiple endorsement responses and packaging them into blocks in sequence.

[0119] In the aforementioned Hyper LedgerFabric framework, ordering nodes use the Raft consensus protocol to ensure high availability and fault tolerance during the block generation process. The packaged blocks are broadcast to all peer nodes for verification and ledger updates.

[0120] In step S154, the validity of the block is verified by the peer node and the local ledger is updated.

[0121] After receiving the block broadcast by the sorting node, the peer node verifies the legitimacy of the transactions in the block, including checking whether the signature is valid and whether the transaction meets the endorsement policy. If the verification is successful, the peer node will add the block to the local ledger, thus completing the ledger update.

[0122] In this embodiment, each peer node independently verifies the transaction proposals in the block and updates its local ledger upon verification. For example, if a transaction proposal involves the storage of a specific version number, the peer node will add the metadata record for that version to its local ledger and update the index structure for subsequent querying. In this way, vehicle software version release information is immutable and synchronized in real time across the entire blockchain network.

[0123] Using these technical approaches, smart contracts encapsulate version metadata into transaction proposals, which are then signed and confirmed by multiple peer nodes, ensuring the legitimacy and credibility of transactions. Ordering nodes are responsible for block generation and broadcast, ensuring the orderliness and consistency of transactions. Ultimately, peer nodes verify and update the ledger, enabling distributed data storage and synchronization, enhancing the security and transparency of the system.

[0124] In some embodiments, see Figure 6 In the aforementioned step S130, the version information of the vehicle software version is stored in the blockchain, and steps S155-S157 are also included.

[0125] In step S155, the source code package of the entire vehicle software version is stored in the InterPlanetary File System (IPFS) and a content identifier is obtained.

[0126] The InterPlanetary File System (IPFS) is a distributed file storage system that enables efficient data storage and sharing through a decentralized approach. IPFS uses content addressing to ensure the uniqueness and immutability of file content.

[0127] A content identifier (CID) is a string used to uniquely identify file content in the IPFS system. It is typically 48 bits or longer and is generated by an encryption algorithm. This identifier not only ensures the uniqueness of the file content but also supports rapid retrieval and verification. For example, in an embodiment of the present application, after the source code package is uploaded to IPFS, the system will return a CID, which will be recorded in the blockchain transaction, thereby enabling distributed storage and reference to the source code.

[0128] In step S156, the content identifier is recorded in the blockchain transaction and the hash value of the source code is bound through the smart contract.

[0129] In an embodiment of the present application, after the source code package is uploaded to IPFS and the CID is obtained, the system will use the CID as part of the transaction data, package it into a blockchain transaction, and submit it to the blockchain network.

[0130] The hash value of the source code is bound to the source code through a smart contract, forming an unalterable evidence record. When the authenticity of the source code needs to be verified, the corresponding CID and hash value can be quickly queried through the smart contract and compared with the actual file in IPFS.

[0131] When the source code package of the vehicle software version is uploaded to IPFS, the system will generate a unique hash value as a content identifier (CID), which can be used for subsequent reference and verification.

[0132] In step S157, a traceable index is established from the blockchain evidence record to the IPFS file.

[0133] A traceability index is a data structure used to establish a mapping relationship between blockchain evidence records and IPFS files. This index allows users to quickly locate the corresponding IPFS file through the blockchain evidence records, thereby achieving complete traceability of the source code package. For example, when a user needs to view a specific version of the source code, they can find the corresponding CID through the blockchain evidence records and then download the complete source code package through the IPFS system.

[0134] The aforementioned technical approach involves storing the source code package of the vehicle software version on IPFS and obtaining a content identifier. This identifier is then recorded in a blockchain transaction and bound to the source code hash value via a smart contract. Finally, a traceable index is established from the blockchain evidence record to the IPFS file. This ensures the storage security and data consistency of the source code, enabling full traceability of the vehicle software version.

[0135] In some embodiments, see Figure 7 , the method provided in this application also includes steps S710-S740.

[0136] In step S710 , in response to a vehicle hardware version update event, the compatibility rules between the vehicle hardware version and the vehicle software version are updated.

[0137] For example, when a vehicle replaces a new model of ECU (electronic control unit) or upgrades a hardware module, its hardware version is updated. The system will detect this hardware version update event and trigger an update to the compatibility rules between the vehicle software version and the hardware version based on this event.

[0138] As described above, compatibility rules define which software versions a hardware version supports, as well as the minimum and maximum compatibility requirements of a software version with respect to the hardware version. For example, hardware version HWC.2.1 supports software versions SWC.1.2.0 to SWC.2.0.5, and some ECU modules require specific software versions to operate properly.

[0139] In step S720, a dynamic check is performed on the vehicle software version based on the updated compatibility rules.

[0140] After updating the compatibility rules, the system will dynamically check the current vehicle software version based on the latest rules to determine whether it still meets the requirements of the current hardware version.

[0141] In step S730, if the dynamic verification fails, the three-level software version release of the module-level software version, the electronic control unit-level software version and the vehicle software version is re-executed based on the updated compatibility rules.

[0142] If it is determined that the vehicle software version is out of the compatible range or is missing certain key dependencies, it means that the current software version does not match the hardware version, and the version release process needs to be repeated.

[0143] In this case, the system will restart the three-level release process at the module level, ECU level, and vehicle level based on the latest compatibility rules. Through this three-level release process, the system can verify the compatibility of each level step by step to ensure that the final released vehicle software version meets the compatibility requirements of all hardware components.

[0144] In step S740, the change history of the vehicle's hardware version and the vehicle's software version is recorded in the blockchain.

[0145] The system records every hardware and vehicle software version change on-chain, storing it within the blockchain network. This record includes metadata such as the version number, change date, reason for the change, and a hash of the relevant test report. It is digitally signed and endorsed by multiple nodes through smart contracts, ensuring data immutability and traceability. For example, when the hardware version of a batch of vehicles is upgraded from HWC.2.0 to HWC.2.1, accompanied by the release of SWC.2.0.6, this change information is permanently recorded on the blockchain for subsequent query and audit.

[0146] By responding to hardware version update events and dynamically updating compatibility rules, the above technical measures can effectively ensure the compatibility of vehicle software versions with hardware. This can avoid functional anomalies or system crashes caused by version incompatibility, thereby improving the stability and reliability of vehicle software.

[0147] In some embodiments, see Figure 8 , the method also includes steps S810-S820.

[0148] In step S810, the whole vehicle hardware version information and the whole vehicle software version information of each vehicle among the multiple vehicles are obtained.

[0149] Vehicle hardware version information refers to the version identification of the hardware configuration installed in each vehicle, including but not limited to the controller model, chip version, sensor type, etc. This information is usually preset when the vehicle is manufactured and collected through the vehicle system or remote diagnostic interface.

[0150] Vehicle software version information refers to the software version running in the vehicle, including the version numbers of the operating system, control algorithms, functional modules, etc. For example, the vehicle hardware version of a certain model may be HW_V2.3, while the corresponding vehicle software version may be SW_V4.5.

[0151] There's a strong correlation between vehicle hardware and software version information. For example, a specific hardware version may only support software versions within a specific range. Software versions outside this range can cause system incompatibility or malfunction. Therefore, collecting and recording these two types of information during version release management is a key prerequisite for dynamic compatibility verification and version traceability.

[0152] In step S820, a version heat map is generated in the visualization interface, wherein the version heat map includes the number of different vehicle software versions for each vehicle model among the plurality of vehicles.

[0153] In the embodiment of the present application, the visualization interface refers to a graphical operation interface for displaying data, which can be integrated into the front end of the management system for management personnel to view and analyze version distribution in real time.

[0154] Figure 9 This is an example of a version heat map provided in the embodiment of the present application. Figure 9 As shown, this version heat map uses color depth to represent data density, visually displaying the distribution of various software versions across different vehicle models. Darker colors indicate a higher number of vehicles with a particular software version, while lighter colors indicate a lower number.

[0155] The generation of the version heat map is based on the aggregation and statistics of multi-dimensional data in step S810. Specifically, the system first counts the number of different vehicle software versions for each vehicle model, based on vehicle type. Then, this statistical data is mapped to the heat map, presenting it as color changes.

[0156] Still Figure 9 For example, Figure 9Each column represents a single vehicle model, and the five blocks within the same column represent five different software versions (e.g., V1.0-V1.4). Darker blocks within a column represent a greater number of vehicles using that software version. For example, in the fifth column, among the multiple vehicles of this model, the largest percentage uses software version V1.1, while the smallest percentage uses version V1.3.

[0157] This version heat map can be used to assist in decision-making. For example, if a large number of vehicles within a particular model are found to be using older software versions, managers can use this information to determine whether to prioritize software updates or assess whether to adjust version compatibility policies. Furthermore, the heat map can be used to monitor the progress of version updates, ensuring that all vehicles are using the recommended software version.

[0158] Using these technical approaches, a version heat map generated within a visual interface can intuitively display the distribution of software versions across different vehicle models, helping managers quickly identify version concentration, update requirements, and potential compatibility issues. This improves the efficiency and accuracy of version management, enabling the optimization of vehicle software release strategies and, ultimately, enhancing the overall management of automotive software-defined capabilities.

[0159] In some embodiments, the triggering condition in the aforementioned step S140 includes at least one of the following: the vehicle mileage reaches a preset mileage threshold, the vehicle is detected to be in a specific geographical location range, and a batch update instruction sent by an external system is received.

[0160] Vehicle mileage refers to the cumulative distance traveled by a vehicle since leaving the factory or since the last software update, and is typically recorded in kilometers (km). The preset mileage threshold can be a mileage range set based on the stability of the software version, the feature iteration cycle, and user feedback. For example, the preset threshold can be set to 5,000 km or 10,000 km. When the vehicle mileage exceeds the preset threshold, the system determines that the current software version may no longer be applicable or that there is room for optimization, and thus initiates the software update process.

[0161] A specific geographic location range refers to a set of geographic coordinates pre-defined in the system, such as a country, city, factory area, or testing site. The system can identify these geographic coordinates using GPS positioning, base station information, or IP addresses. When a vehicle enters a specific geographic location range, the system automatically determines whether a software update is required.

[0162] A batch update command sent by an external system can be a centralized software update request initiated by the external system. This command is used to simultaneously deploy the same vehicle software version to a large number of vehicles specified by the external system. External systems refer to business systems other than the release management system, such as the automaker's internal production management system, quality management system, and customer service system.

[0163] According to the above technical means, by setting a variety of preset trigger conditions, such as the vehicle mileage reaching a preset threshold, detecting that the vehicle is in a specific geographical location range, and receiving a batch update instruction sent by an external system, the timing of pushing the vehicle software version can be flexibly controlled; by setting a variety of preset trigger conditions, it is possible to ensure that the encrypted update of the vehicle software version is both timely and accurate, thereby avoiding unnecessary waste of resources.

[0164] Combined with the above Figures 1-9 , the method embodiment of the present application is described in detail, and the device embodiment of the present application will be described below with reference to the accompanying drawings. It should be noted that the device embodiment corresponds to the aforementioned method embodiment, so for parts not described in detail, please refer to the aforementioned method embodiment.

[0165] Figure 10 : is a schematic structural diagram of a vehicle software version release management system 1000 provided in an embodiment of the present application. The system 1000 includes:

[0166] The version release unit 1010 is used to execute the three-level software version release of module-level software version, electronic control unit ECU-level software version and vehicle software version based on the workflow engine.

[0167] The storage unit 1020 is used to store the software versions at each level and the compatibility rules between the vehicle's hardware version and the software versions at each level during the three-level software version release process.

[0168] The verification and evidence storage unit 1030 is used to perform dynamic verification on the vehicle software version based on the compatibility rules. If the dynamic verification passes, the version information of the vehicle software version is stored in the blockchain.

[0169] The push unit 1040 is used to push the encrypted vehicle software version to multiple vehicles through a message queue in response to meeting a preset trigger condition.

[0170] In some embodiments, the hardware version of the vehicle includes the whole vehicle hardware version of the vehicle and the hardware versions of multiple electronic control units in the vehicle. The storage unit 1020 is also used to: store the software versions at each level through a relational database; define the compatibility rules through structured data, and the compatibility rules include: the range of the whole vehicle software version corresponding to the whole vehicle hardware version of the vehicle, the dependency relationship between the whole vehicle software version and the ECU-level software versions corresponding to different electronic control units in the vehicle, the range of ECU-level software versions corresponding to the hardware versions of multiple electronic control units in the vehicle, and the dependency relationship between each ECU-level software version and the module-level software version; store the compatibility rules through the relational database.

[0171] In some embodiments, the verification and evidence unit 1030 is also used to: determine the hardware version of the target vehicle; obtain the target compatibility rules corresponding to the hardware version of the target vehicle; and determine, based on the target compatibility rules, that the whole vehicle software version passes the dynamic verification when the following conditions are met: the whole vehicle software version matches the whole vehicle hardware version of the target vehicle; the versions of multiple ECU-level software in the whole vehicle software are compatible with the whole vehicle software version; the versions of multiple ECU-level software in the whole vehicle software match the hardware versions of the multiple electronic control units; the versions of multiple module-level software in each of the ECU-level software are compatible with the ECU-level software version.

[0172] In some embodiments, the verification and evidence unit 1030 is further used to: read the target compatibility rules from the distributed cache according to the hardware version of the target vehicle; and read the target compatibility rules from the relational database if the target compatibility rules are not hit in the distributed cache.

[0173] In some embodiments, the blockchain includes multiple nodes, which include multiple peer nodes and at least one sorting node. The verification and evidence storage unit 1030 is also used to: call the smart contract interface to encapsulate the metadata of the vehicle software version into a transaction proposal, wherein the metadata includes the vehicle software version number, the compatible hardware list, and the test report hash value; synchronize the transaction proposal to the blockchain for signature confirmation through multiple peer nodes to form multiple endorsement responses; collect the multiple endorsement responses through the at least one sorting node, package the transaction proposal into a block, and broadcast the block to the multiple peer nodes; verify the validity of the block through the peer node and update the local ledger.

[0174] In some embodiments, the verification evidence unit 1030 is also used to: store the source code package of the vehicle software version to the star file system IPFS and obtain a content identifier; record the content identifier in the blockchain transaction and bind the hash value of the source code through a smart contract; and establish a traceable index from the blockchain evidence record to the IPFS file.

[0175] In some embodiments, the release management system 1000 further includes an updating unit for updating the compatibility rules between the vehicle's hardware version and various software versions in response to a vehicle hardware version update event; and performing dynamic verification on the vehicle's software version based on the updated compatibility rules.

[0176] The verification and evidence storage unit 1030 is also used to: when the dynamic verification fails, re-execute the three-level software version release of the module-level software version, the electronic control unit-level software version and the whole vehicle software version based on the updated compatibility rules; and record the change history of the vehicle's hardware version and the whole vehicle software version in the blockchain.

[0177] In some embodiments, the release management system 1000 further includes:

[0178] The acquisition unit is used to obtain the whole vehicle hardware version information and the whole vehicle software version information of each vehicle in the multiple vehicles.

[0179] A generating unit is used to generate a version heat map in a visual interface, wherein the version heat map includes the number of different vehicle software versions of each vehicle model among the multiple vehicles.

[0180] In some embodiments, the preset trigger condition includes at least one of the following: the vehicle mileage reaches a preset mileage threshold; the vehicle is detected to be within a specific geographical location range; a batch update instruction sent by an external system is received.

[0181] The following combination Figure 11-13 The technical solutions provided in the embodiments of the present application are further explained.

[0182] The embodiments of the present application also provide a release management method and system for the entire vehicle software version, aiming to solve the problems of decentralized management, data silos, traceability difficulties, and insufficient security existing in traditional version management methods.

[0183] Among them, decentralized management means that each controller in the vehicle releases versions independently, and basic information is repeatedly entered multiple times, which can easily lead to manual operation errors; data tampering means that the version status cannot be synchronized in real time in version management, and there is a risk of missed tests in the testing and production links; the problem of traceability difficulty lies in the lack of an effective association mechanism between software versions, requirement documents, test reports and defect records, resulting in a large amount of manpower and time costs when locating problems. When developers look for the specific cause of the problem, the workload of debugging and repair is increased due to the lack of a clear mapping relationship between the information; the system security is insufficient, specifically manifested in that the system version change process has not undergone a strict approval process, and the version distribution process is not encrypted for transmission, which may cause user data to be maliciously tampered with, thereby causing data security risks.

[0184] To address the above issues, some related technologies standardize version numbers and release processes, but fail to cover the entire chain of management from modules to the entire vehicle, and are deficient in data interaction mechanisms and version compatibility verification. The technical solution of this application introduces blockchain, version control, and dynamic compatibility checking to systematically address the above issues.

[0185] To effectively control, track, and update vehicle software versions, this application embodiment provides a method for managing vehicle software releases and establishes a unified software release management system. This unified software release management system not only implements multi-level version management but also ensures data immutability through blockchain technology and improves release efficiency and security through dynamic compatibility verification.

[0186] Figure 11 This is a schematic diagram of a vehicle software version release management system provided in an embodiment of the present application. The system 1100 includes a version release module 1110 , a version management module 1120 and a version update module 1130 .

[0187] The version release module 1110 can be understood as a functional unit built on the Camunda process engine. It has the ability to support version release processes at three levels: module level, ECU level, and vehicle level, and can perform visual approval functions and authority control mechanisms.

[0188] The version management module 1120 uses a relational database and distributed cache to store the historical records and current status of versions. It also uses blockchain technology to store evidence to ensure that the stored data is tamper-proof.

[0189] Version update module 1130 is a functional unit for automatically updating software or firmware. It operates based on message queues (MQ) and data encryption technology. The system automatically pushes update packages to target devices via the message queue based on pre-set policies, such as when the mileage reaches a set threshold.

[0190] Figure 12 This is a flowchart of the three-level publishing method based on the Camunda process engine. Figure 12 The method includes steps S1201-1216.

[0191] Steps S1201-S1205 are module-level software version releases.

[0192] Step S1201: Create a new release form. The developer creates a module release form through the Web interface and fills in the module name, version number (such as V1.2.3), and function description.

[0193] Step S1202: Module development is performed, and developers perform module-level software development based on the functional requirements of the module.

[0194] Step S1203, module self-test, the developer uploads the development product (such as source code package) and self-test report, triggering the automatic approval of the Camunda process engine; if the self-test passes, execute step S1204, otherwise return to step S1202.

[0195] Step S1204, module testing, performs functional testing on the module-level software in a test environment. If the test passes, execute step S1205, otherwise return to step S1202.

[0196] Step S1205: Module release approval. After the test passes, automatic approval is performed in the Camunda process engine.

[0197] Steps S1206-S1210 are for ECU-level software version release.

[0198] Step S1206: Select a module, select a released module-level software version, and form ECU-level software.

[0199] Step S1207: Create a new release order. Based on the Camunda process engine, create a release order for the ECU-level software.

[0200] Step S1208, software integration test, performs integration test on ECU level software, if the test passes, executes step S1209, otherwise returns to step S1207.

[0201] Step S1209: unit test. If the unit test passes, execute step S1210; otherwise, return to step S1207.

[0202] Step S1210: The system releases the approval. After the unit test passes, the approval is automated in the Camunda process engine.

[0203] Steps S1211-1214 are for the release of vehicle-level software versions.

[0204] Step S1211, select the ECU version, which is the ECU version released in the above steps S1206-S1207.

[0205] Step S1212: Configure the vehicle architecture, which includes the vehicle model and hardware parameters.

[0206] Step S1213, verify the hardware version and the compatibility of the hardware and software versions. If the hardware version and software version are not compatible, return to step S1211 and reselect the ECU version; if they are compatible, execute step S1214.

[0207] Step S1214, trial installation, after completing the compatibility test of the vehicle-level software, it is trial installed and verified in the vehicle.

[0208] In the technical solution of the present application, the blockchain is constructed using a consortium chain framework, including peer nodes (Peer nodes), orderer nodes (Orderer nodes) and smart contract interfaces.

[0209] Peer nodes are deployed in the car company's data center and supplier's node. The peer node can execute smart contracts and maintain distributed ledgers, and supports multi-organization identity authentication.

[0210] The sorting node uses the Raft consensus protocol to ensure fault tolerance of transaction sorting and block generation.

[0211] The smart contract defines the rules for recording version changes, including version hash generation, digital signature verification, and relationship index construction.

[0212] Figure 13 This is a flow chart of the method for uploading data to the chain in the embodiment of the present application. Figure 13 The method includes steps S1301-S1307.

[0213] In step S1301, after the version is approved, the smart contract interface is called to encapsulate the version metadata (including version number, compatible hardware list, test report hash value) as a transaction proposal.

[0214] For example, the data structure of a transaction proposal is:

[0215] {

[0216] "tx_id":"TX_001", / / transaction unique identifier "creator":"OEM_A", / / initiator identity

[0217] "metadata":{

[0218] "version":"SW2.0.1",

[0219] "compatible_hw":["HV2.1","HV2.2"],

[0220] "test_report_hash":"a1b2c3d4...", / / SHA-256 hash value

[0221] "ipfs_cid":"QmXyZ..." / / IPFS file storage identifier

[0222] },

[0223] "signature":"0x9a8b7c..." / / Signature of the initiator's private key (ECDSA algorithm)

[0224] }

[0225] In step S1302, the transaction proposal is broadcast to peer nodes across the entire network via the Goosip protocol.

[0226] In step S1303, each peer node executes the smart contract logic to verify the following: 1. The validity of the proposal digital signature (decrypted and verified using the car company's public key); 2. Whether the version compatibility meets the preset rules (calling the dynamic compatibility verification algorithm); 3. The test report hash value is consistent with the IPFS storage file.

[0227] In step S1304, after verification, each peer node generates an endorsement response and attaches a node signature.

[0228] Exemplarily, the data structure of the node signature is:

[0229] {

[0230] "tx_id":"Tx_001",

[0231] "endorser":"Peer_Supplier",

[0232] "response":"Approved",

[0233] "signature":"0x5e6f7a..." / / Supplier node private key signature

[0234] }

[0235] In step S1305, the Orderer node collects all endorsement responses, sorts the transactions by time, and packages them into blocks.

[0236] In step S1306, the block is broadcast to all peer nodes in the network through the Gossip protocol. Each node verifies the validity of the block and updates its local account.

[0237] For example, the data structure of a block is:

[0238] {

[0239] "block_header":{

[0240] "prev_hash":"0x1234...", / / Previous block hash

[0241] "timestamp":"2023-10-01T12:00:00Z",

[0242] "merkle_root":"0x5678..." / / The Merkle root of this block's transactions

[0243] },

[0244] "transactions":["TX_001","TX_002"], / / Transaction list

[0245] "block_hash":"0x9abc..." / / Current block hash (SHA-256)

[0246] }

[0247] In step S1307, IPFS stores the association: ipfs_cid is recorded in the block, and off-chain files (such as source code packages) can be retrieved through CID.

[0248] The above blockchain-based evidence storage method has the following technical advantages: immutability: the hash chain structure and consensus mechanism ensure data integrity; cross-organizational collaboration: suppliers, car companies and third-party institutions share transparent data; efficient retrieval: the on-chain index library supports complex queries (such as "querying software versions compatible with hardware V3.0"), and the response time is <200ms.

[0249] The above technical solution provided by the embodiment of the present application has the following advantages:

[0250] 1. Rapid reuse of vehicle-side functional requirements, software versions, test cases, and configuration words

[0251] 1. Functional requirements, software versions, test cases, and configuration word standardization and reuse

[0252] The system modularizes the functional requirements, software versions, test cases, and configuration words of common vehicle-side components (such as battery management modules and autonomous driving algorithm libraries) into standardized templates. When a new vehicle model or version reuses the module, the historical solution can be directly called, reducing redesign time.

[0253] For example, a car company reused old battery management software when developing new models. The system automatically matched historical functional requirements, software versions, test cases, and configuration words, shortening the R&D and testing cycle.

[0254] 2. Version change impact analysis

[0255] When the borrowed parts version is updated, the vehicle version can purchase the latest software with one click and automatically compare the version change points to ensure its stability in the new hardware or new software environment.

[0256] 2. Linkage between vehicle version and software version

[0257] 1. Version mapping and tracing

[0258] The system establishes a strong correlation between the vehicle hardware version (such as the hardware configuration corresponding to the vehicle model status number) and the software version, synchronizing the two in real time. For example, when a batch of vehicles undergoes a hardware upgrade, the system automatically matches the latest compatible software version.

[0259] 2. Release consistency check

[0260] Before a version is released, the system will verify the compatibility of the vehicle and software versions. If there is a mismatch (e.g. the hardware supports V2.0, but the software is V1.5), the release will be blocked and a risk warning will be issued.

[0261] 3. Dynamic version status visualization

[0262] The vehicle network displays the corresponding vehicles and software versions for each model / batch in the market in real time, helping management make quick decisions. For example, if a software version defect is discovered, the affected vehicles can be located in a single click.

[0263] 3. Comprehensive Benefits

[0264] 1. Improved efficiency

[0265] Functional requirements, software versions, and test cases all support one-click reuse, reducing a large amount of repetitive work and shortening the testing cycle; avoiding manual verification errors and improving release efficiency.

[0266] 2. Compliance and Security

[0267] All version changes of the system are traceable and meet the safety requirements of the automotive industry.

[0268] The version release management system solves the pain points of difficult component reuse and version confusion in automotive development by enabling one-click reuse of standardized functional requirements, software versions, and test cases, as well as linkage between vehicle and software version status. It provides core support for automakers to implement efficient and secure software-defined vehicle (SDV) strategies.

[0269] Figure 14 is a schematic structural diagram of an electronic device provided in an embodiment of the present application, Figure 14 The electronic device 1400 is used to implement the vehicle software version release management system described in the above method embodiment.

[0270] The electronic device 1400 may include one or more processors 1410. The processor 1410 may support the electronic device 1400 in implementing the method described in the above method embodiment.

[0271] The electronic device 1400 may further include one or more memories 1420. The memories 1420 store programs that can be executed by the processor 1410, causing the processor 1410 to perform the methods described in the above method embodiments. The memories 1420 may be independent of the processor 1410 or integrated into the processor 1410.

[0272] The electronic device 1400 may further include a transceiver 1430. The processor 1410 may communicate with other devices or chips via the transceiver 1430. For example, the processor 1410 may transmit and receive data with other devices or chips via the transceiver 1430.

[0273] An embodiment of the present application provides a computer storage medium, which stores one or more programs. The one or more programs can be executed by one or more processors to implement the steps of the method of any of the above embodiments.

[0274] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0275] The processor may be at least one of an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, and a microprocessor. It is understood that the electronic device that implements the functions of the processor may also be other electronic devices, which are not specifically limited in the embodiments of the present application.

[0276] The computer storage medium / memory may be a read-only memory, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface mount memory, an optical disc, or a compact disc read-only memory (CD ROM).

[0277] An embodiment of the present application provides a computer program, including computer-readable code. When the computer-readable code runs in an electronic device, a processor in the electronic device executes some or all of the steps for implementing the above method.

[0278] An embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, implements some or all of the steps in the above method. The computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium. In other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0279] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned steps / processes does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments.

[0280] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0281] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0282] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0283] In addition, all functional units in the embodiments of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the above-mentioned integrated units can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0284] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, and other media that can store program codes.

[0285] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling an on-board terminal (which can be a personal computer, server, or network device, etc.) to execute all or part of the methods of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks or optical disks.

[0286] The above are only implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the protection scope of the present application.

Claims

1. A method for managing the release of vehicle software versions, characterized in that: include: Based on the workflow engine, execute the three-level software version release of module-level software version, electronic control unit ECU-level software version and vehicle software version; During the three-level software version release process, storing the software versions at each level and the compatibility rules between the vehicle's hardware version and the software versions at each level; Performing a dynamic verification on the vehicle software version based on the compatibility rule, and if the dynamic verification passes, storing the version information of the vehicle software version in the blockchain; In response to meeting a preset trigger condition, the vehicle software version is encrypted and pushed to multiple vehicles through a message queue.

2. The method according to claim 1, characterized in that The vehicle hardware version includes the vehicle hardware version and the hardware versions of multiple electronic control units in the vehicle. The stored software versions at each level and the compatibility rules between the vehicle hardware version and the software versions at each level include: Storing the software versions at all levels in a relational database; The compatibility rules are defined by structured data, and the compatibility rules include: a range of vehicle software versions corresponding to the vehicle hardware version of the vehicle, a dependency relationship between the vehicle software version and ECU-level software versions corresponding to different electronic control units in the vehicle, a range of ECU-level software versions corresponding to hardware versions of multiple electronic control units in the vehicle, and a dependency relationship between each ECU-level software version and the module-level software version; The compatibility rules are stored in the relational database.

3. The method according to claim 2, characterized in that The dynamically checking the vehicle software version based on the compatibility rule includes: Determine the target vehicle's hardware version; Obtaining target compatibility rules corresponding to the hardware version of the target vehicle; According to the target compatibility rule, the vehicle software version is determined to have passed the dynamic verification if the following conditions are met: The vehicle software version matches the vehicle hardware version of the target vehicle; The versions of multiple ECU-level software in the vehicle software are compatible with the vehicle software version; The versions of the multiple ECU-level software in the vehicle software match the hardware versions of the multiple electronic control units; The versions of the plurality of module-level software in each of the ECU-level software are compatible with the ECU-level software version.

4. The method according to claim 3, characterized in that The obtaining of the target compatibility rule corresponding to the hardware version of the target vehicle includes: Reading the target compatibility rule from a distributed cache according to the hardware version of the target vehicle; In the case that the target compatibility rule is not found in the distributed cache, the target compatibility rule is read from the relational database.

5. The method according to claim 1, wherein The blockchain includes a plurality of nodes, the plurality of nodes including a plurality of peer nodes and at least one sorting node, and the storing of the version information of the vehicle software version in the blockchain includes: Calling the smart contract interface to encapsulate the metadata of the vehicle software version into a transaction proposal, wherein the metadata includes the vehicle software version number, compatible hardware list, and test report hash value; Synchronizing the transaction proposal to the blockchain for signature confirmation by multiple peer nodes to form multiple endorsement responses; Collecting the multiple endorsement responses through the at least one ordering node, packaging the transaction proposal into a block, and broadcasting the block to the multiple peer nodes; The peer node verifies the validity of the block and updates the local ledger.

6. The method according to claim 5, characterized in that The method further comprises: Storing the source code package of the vehicle software version in the IPFS file system and obtaining a content identifier; Recording the content identifier in a blockchain transaction and binding the hash value of the source code through a smart contract; Establish a traceable index from the blockchain evidence record to the IPFS file.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: In response to a vehicle hardware version update event, updating the compatibility rules between the vehicle hardware version and the various levels of software versions; Performing dynamic verification on the vehicle software version based on the updated compatibility rules; If the dynamic verification fails, re-execute the three-level software version release of the module-level software version, the electronic control unit-level software version, and the vehicle software version based on the updated compatibility rules; The change history of the vehicle's hardware version and the vehicle's software version is recorded in the blockchain.

8. The method according to any one of claims 1 to 6, characterized in that The method further includes Obtaining vehicle hardware version information and vehicle software version information of each of the multiple vehicles; A version heat map is generated in a visualization interface, where the version heat map includes the number of different vehicle software versions for each vehicle model among the multiple vehicles.

9. The method according to any one of claims 1 to 6, characterized in that The preset trigger condition includes at least one of the following: The vehicle's mileage reaches the preset mileage threshold; The vehicle is detected to be within a specific geographic location range; Receive batch update instructions sent by external systems.

10. A vehicle software version release management system, characterized in that: include: The version release unit is used to execute the three-level software version release of module-level software version, electronic control unit ECU-level software version and vehicle software version based on the workflow engine; A storage unit, configured to store the software versions of each level and the compatibility rules between the vehicle's hardware version and the software versions of each level during the three-level software version release process; A verification and evidence storage unit, configured to perform dynamic verification on the vehicle software version based on the compatibility rule, and if the dynamic verification passes, store the version information of the vehicle software version in the blockchain; The push unit is used to push the encrypted vehicle software version to multiple vehicles through a message queue in response to meeting a preset trigger condition.

Images