A flexible processing method, device, equipment and medium for vehicle license

Abstract

This application provides a flexible processing method, apparatus, device, and medium for vehicle licenses, effectively solving problems such as rigid exit, inconvenient operation and maintenance, insufficient security, and poor compatibility in license verification and hot updates of the AUTOSAR AP architecture. The method includes: pre-configuring a core layer and an extension layer; performing multi-dimensional verification on the current licenses in the core layer and extension layer using a layered verification module and a backup fallback module to obtain verification results; based on the verification results, controlling the Runtime module of the AUTOSAR AP architecture to enter a target state; receiving a new license pushed by the vehicle's onboard gateway according to the Runtime module in the target state; processing the new license through an encrypted hot update module to obtain a target license; and controlling the encrypted hot update module to replace the current license based on the target license, thereby achieving flexible processing of licenses on the vehicle.

Description

Technical Field

[0001] This application relates to the field of software access control technology, and more specifically, to a flexible processing method, apparatus, device, and medium for vehicle licenses. Background Technology

[0002] With the rapid development of automotive electronics technology, the AUTOSAR AP (Adaptive Platform) architecture, due to its high flexibility and scalability, is widely used in the software system development of automotive ECUs (Electronic Control Units). Its Runtime module, as the core of the architecture, is responsible for managing the operation of core and extended automotive services. To ensure software licensing compliance and system security, the Runtime module needs to verify the access rights and legality of functions through a license verification mechanism. Currently, existing AUTOSAR AP architectures mostly adopt a "rigid verification" mode for license verification, which has many technical defects and seriously affects the availability, operational efficiency, and security protection capabilities of automotive systems.

[0003] First, the verification logic lacks a layered design. The core layer (supporting safety-critical services such as braking and steering) and the extension layer (carrying non-critical services such as logs and monitoring) use a unified verification standard. Once the verification fails, the Runtime process is terminated directly, causing the core functions of the vehicle to be interrupted and the system availability to be extremely poor.

[0004] Secondly, license updates require restarting the ECU or Runtime module to take effect, making online hot updates impossible. This increases the maintenance costs of the vehicle system and interrupts core services during the update process, posing a security risk. Furthermore, the existing verification mechanism lacks robust security protection, failing to employ encrypted transmission and digital signature verification mechanisms. Licenses are easily forged, tampered with, or reused across devices, compromising authorization security.

[0005] Furthermore, existing verification schemes lack compatibility with the AUTOSAR AP architecture, requiring modifications to the core architecture code for integration. This results in poor portability and difficulty in adapting to different versions of the AUTOSAR AP platform. Additionally, the lack of a backup mechanism means that when the primary license expires or verification fails, there is no contingency plan to ensure the continued operation of core functions, further reducing system reliability.

[0006] In summary, the existing license verification mechanism of the AUTOSAR AP architecture has problems such as rigid exit, inconvenient operation and maintenance, insufficient security, and poor compatibility, which cannot meet the requirements of high availability, high security, and easy operation and maintenance of vehicle systems. Therefore, there is an urgent need for a flexible license verification and hot update solution that is adapted to the AUTOSAR AP architecture to solve the above-mentioned technical difficulties. Summary of the Invention

[0007] In view of this, the purpose of this application is to provide a flexible processing method, apparatus, equipment and medium for vehicle licenses, which effectively solves the problems of rigid exit, inconvenient operation and maintenance, insufficient security and poor compatibility of licenses in the AUTOSAR AP architecture in terms of verification and hot update.

[0008] In a first aspect, embodiments of this application provide a flexible processing method for vehicle licenses, applicable to a processing system. The processing system includes a layered verification module, an encrypted hot-update module, and a fallback backup module. The method includes: The AUTOSAR AP architecture deployed on the vehicle ECU is pre-configured to obtain the core layer and the extension layer, and the current license in the configured core layer and extension layer is called respectively. The current licenses in the core layer and extension layer are verified in multiple dimensions through the layered verification module and the backup fallback module to obtain the verification results. Based on the verification result, the Runtime module of the AUTOSAR AP architecture is controlled to enter the target state, and the Runtime module in the target state receives the new license pushed by the vehicle gateway. The new license is processed by the encrypted hot update module to obtain the target license, and the encrypted hot update module is controlled to replace the current license based on the target license, so as to achieve flexible processing of licenses on the vehicle.

[0009] In conjunction with the first aspect, this application provides a first possible implementation of the first aspect, wherein the current license in the core layer and the extension layer is verified in multiple dimensions through a layered verification module and a backup fallback module, including: For the layer where the current license is located, set different collaborative verification strategies for the layer verification module and the backup fallback module; The hierarchical verification module and the backup fallback module are controlled to collaboratively execute the collaborative verification strategy across multiple verification dimensions to verify the current license.

[0010] In conjunction with the first aspect, this application provides a second possible implementation of the first aspect, wherein controlling the layered verification module and the backup fallback module to collaboratively execute the collaborative verification strategy across multiple verification dimensions includes: If the core layer fails the verification of the multiple verification dimensions, the backup fallback module is triggered to load the backup license stored by the vehicle ECU for the core layer. The backup license is sent to the hierarchical verification module to verify the backup license, and the backup license is enabled after the verification is successful.

[0011] In conjunction with the first aspect, this application provides a third possible implementation of the first aspect, wherein the current license in the core layer and the extension layer is verified in multiple dimensions through a layered verification module and a backup fallback module, and further includes: For the core attributes of the license, hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension are set up; Configure the verification methods corresponding to the hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension for verification.

[0012] In conjunction with the first aspect, this application provides a fourth possible implementation of the first aspect, wherein obtaining the target license by processing the new license through an encrypted hot update module includes: The new license is verified, decrypted, and validated through various interfaces of the encrypted hot update module to obtain the corresponding processing results; Based on the processing results, the new license is determined as the target license to replace the current license.

[0013] In conjunction with the first aspect, this application provides a fifth possible implementation of the first aspect, wherein, before performing signature verification, decryption, and legality verification on the new license, the following steps are taken: The Runtime module is controlled to encrypt the new license data and associated data using a target encryption algorithm and a target key to obtain the new license. The target protocol is invoked to cause the Runtime module to transfer the new license to the encrypted hot update module.

[0014] In conjunction with the first aspect, this application provides a sixth possible implementation of the first aspect, wherein the AUTOSAR AP architecture deployed on the vehicle ECU is pre-configured to obtain a core layer and an extension layer, including: Collect all functions in the AUTOSAR AP architecture and divide these functions into a core layer and an extension layer according to security level and business importance; Based on the types of the core layer and the extension layer, the core layer and the extension layer are configured to be associated with different security levels.

[0015] Secondly, embodiments of this application provide a flexible processing device for vehicle licenses, suitable for a processing system. The processing system includes a layered verification module, an encrypted hot update module, and a fallback backup module. The device includes: The configuration module is used to pre-configure the AUTOSAR AP architecture deployed on the vehicle ECU, obtain the core layer and the extension layer, and call the current license in the configured core layer and extension layer respectively. The verification module is used to perform multi-dimensional verification of the current licenses in the core layer and extension layer through the layered verification module and the backup fallback module, and obtain the verification results. The receiving module is used to control the Runtime module of the AUTOSAR AP architecture to enter the target state based on the verification result, and to receive the new license pushed by the vehicle gateway in the vehicle according to the Runtime module in the target state. The replacement module is used to process the new license through the encrypted hot update module to obtain the target license, and to control the encrypted hot update module to replace the current license based on the target license, so as to realize flexible processing of licenses on the vehicle.

[0016] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of any of the flexible processing methods for vehicle licenses described above are performed.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of any of the flexible processing methods for vehicle licenses described in the present invention.

[0018] This application provides a flexible processing method for vehicle licenses, applicable to a processing system. The processing system includes a layered verification module, an encrypted hot update module, and a fallback backup module. The method pre-configures the AUTOSAR AP architecture deployed on the vehicle's ECU to obtain a core layer and an extension layer, and calls the current licenses in the configured core layer and extension layer respectively. Next, the layered verification module and the fallback backup module perform multiple verification dimensions on the current licenses in the core layer and extension layer to obtain verification results. Then, based on the verification results, the Runtime module of the AUTOSAR AP architecture is controlled to enter a target state, and the Runtime module in the target state receives a new license pushed by the vehicle's onboard gateway. Finally, the encrypted hot update module processes the new license to obtain a target license, and controls the encrypted hot update module to replace the current license based on the target license, thereby achieving flexible processing of vehicle licenses. Based on the above methods, this application utilizes a layered verification module and a backup fallback module to perform multi-dimensional verification of the license, significantly improving the availability of the in-vehicle system and enabling flexible processing during the license verification process. By using an encrypted hot-update module to obtain the target license and replace the current license based on the target license, it improves security protection and hardware binding mechanisms, preventing license forgery, tampering, and cross-device reuse, thus enhancing authorization security. It also enables flexible license updates, taking effect without restarting the ECU or runtime, reducing maintenance costs, avoiding service interruption risks, and achieving this without modifying the core architecture code, enhancing the solution's compatibility and portability. Therefore, the technical solution of this application balances the requirements of high system availability, high security, and easy maintenance, and is suitable for the AUTOSAR AP architecture application scenario on in-vehicle ECUs, possessing high practical value and promotional significance. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating a flexible processing method for vehicle licenses provided in an embodiment of this application is shown. Figure 2 This paper illustrates the connection between the processing system provided in this embodiment and the AUTOSAR AP architecture. Figure 3 A schematic diagram of the verification process of the layered verification module provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating the encrypted hot update module provided in an embodiment of this application is shown; Figure 5 This paper shows a structural block diagram of a flexible processing device for vehicle licenses provided in an embodiment of this application; Figure 6 A structural block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0022] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0023] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0024] The existing license verification mechanism of the AUTOSAR AP architecture has problems such as rigid exit, inconvenient operation and maintenance, insufficient security, and poor compatibility, which cannot meet the requirements of high availability, high security, and easy operation and maintenance of vehicle systems. Therefore, there is an urgent need for a flexible license verification and hot update solution that is adapted to the AUTOSAR AP architecture to solve the above-mentioned technical difficulties.

[0025] Based on this, the present application provides a flexible processing method, apparatus, device and medium for vehicle licenses, which will be described below through embodiments.

[0026] Example 1 To facilitate understanding of this embodiment, a flexible processing method for vehicle permits disclosed in this application will first be described in detail. For example... Figure 1 The diagram illustrates a flexible processing method for vehicle licenses. This application provides a flexible processing method for vehicle licenses, applicable to a processing system. The processing system includes a layered verification module, an encrypted hot-update module, and a fallback backup module. The method includes: S101. Configure the AUTOSAR AP architecture deployed on the vehicle ECU in advance to obtain the core layer and the extension layer, and call the current license in the configured core layer and extension layer respectively. S102. The current licenses in the core layer and extension layer are verified in multiple dimensions through the layered verification module and the backup fallback module to obtain the verification results. S103. Based on the verification result, control the Runtime module of the AUTOSAR AP architecture to enter the target state, and receive the new license pushed by the vehicle gateway according to the Runtime module in the target state. S104. The new license is processed by the encrypted hot update module to obtain the target license, and the encrypted hot update module is controlled to replace the current license based on the target license to achieve flexible processing of licenses on the vehicle.

[0027] The processing system described in this application is applied to the AUTOSAR AP architecture, such as Figure 2 As shown, in addition to the layered verification module, the encrypted hot update module, and the backup module, an alarm module is also included. The layered verification module and the backup module are applied in the Runtime module. The layered verification module and the encrypted hot update module also generate alarm information and transmit it to the vehicle T-Box through the alarm module.

[0028] In step S101, this application pre-configures the AUTOSAR AP architecture deployed on the vehicle ECU. Specifically, the configuration involves classifying all service functions in the AUTOSAR AP architecture based on the security level requirements and business importance of the vehicle system, resulting in a core layer and an extension layer. Different security levels are then configured to be associated with the core layer and the extension layer to ensure vehicle safety. Specifically, a new authorizedLayers collection is added to the Runtime class to store the license authorization function layer, which is associated with the AUTOSAR AP function module registry. Business importance refers to the degree of impact of the function on the normal operation and safety of the vehicle ECU and the AUTOSAR AP architecture. If business requirement A is met and the configuration is completed, the Runtime module of the AUTOSAR AP architecture on the vehicle ECU is started. The Runtime module is responsible for basic functions such as service registration, discovery, error domain registration, and performance monitoring. Therefore, after initial integration, the Runtime module calls the current license stored in the configured core layer and extension layer through a preset interface. The current license is the primary license, providing a foundation for subsequent layered verification, hot updates, and backup operations, ensuring that license verification accurately corresponds to each layer of function and achieving the core objective of flexible verification.

[0029] In a specific implementation of step S101, one embodiment is as follows: the AUTOSAR AP architecture deployed on the vehicle ECU is pre-configured to obtain a core layer and an extension layer, including: S1011. Collect all functions in the AUTOSAR AP architecture and divide the various functions into core layer and extension layer according to security level and business importance; S1012. Based on the types of the core layer and the extension layer, configure the core layer and the extension layer to be associated with different security levels respectively.

[0030] In steps S1011-S1012, before configuring the core layer and extension layer, this application collects all functions in the AUTOSAR AP architecture and divides these functions into a core layer and an extension layer according to their safety level and business importance (a secondary core layer can also be divided based on actual needs). Key services supporting the safe operation of the entire vehicle, such as braking and steering, are configured as the core layer. This layer is associated with the ASIL-D safety level and is the foundation for ensuring normal vehicle operation. Key services include service publishing / discovery, error domain registration, and SOME / IP bus communication. Non-safety-critical services, such as log collection, performance monitoring, and entertainment assistance, are configured as the extension layer. This layer is associated with the QM safety level and does not affect the normal operation of the vehicle's core functions. Because of the different services included in the core layer and extension layer, they are determined to be of core and non-core types, respectively. Based on this, the core layer and extension layer are configured to be associated with the ASIL-D safety level and the QM safety level, respectively, both derived from the global international standard ISO for automotive electronic functional safety. 26262 is a general safety grading standard used to assess the level of safety risk of in-vehicle systems or functional components. ASIL-D is the highest safety level, representing an extremely low probability of failure and extremely high reliability. QM is the lowest safety level, applicable to non-safety-critical functions. Specifically, layering identifiers are defined through the enumeration class `LicenseFunctionLayer`. This application binds and adapts different levels of functions to safety levels such as ASIL-D and QM based on the safety requirements of in-vehicle functions. Furthermore, the latest version of the AUTOSAR AP architecture (such as R24-11) has been optimized for functional safety, better supporting the development and operation of ASIL-D level functions. During configuration, the configuration module of the AUTOSAR AP architecture is used to clarify the functional boundaries, permission scope, and verification priorities of the core layer and the extension layer, ensuring that the two layers operate independently and without interference.

[0031] In step S102, the Runtime module in the AUTOSAR AP architecture of this application, after retrieving the current licenses of the core layer and the extension layer, as follows: Figure 3As shown, the two types of licenses are transmitted to the layered verification module. This module simultaneously performs multiple dimensions of legality checks on both the core layer and the extension layer licenses. The backup and fallback module cooperates throughout the process, performing corresponding fallback operations based on the core layer verification results, ultimately obtaining a complete layered verification result. The specific process is as follows: First, the layered verification module initiates the verification process, performing hardware binding verification, validity period verification, and function authorization verification on both the core layer and extension layer licenses to ensure the legality, timeliness, and permission compliance of the licenses. During the layered verification process, the layered verification module independently verifies the core layer and extension layer licenses and provides feedback on the verification results separately. The backup and fallback module only monitors the core layer verification process and does not participate in the extension layer verification operation. If the current core layer license passes all three dimensions of verification, the layered verification module outputs the core layer verification result, and the backup and fallback module remains in standby mode, performing no operation. The Runtime module initializes the core layer service normally based on this result; otherwise, the backup and fallback module performs fallback processing. The layered verification module and the backup fallback module work together to complete multi-dimensional verification of the current licenses of the core layer and the extension layer, and finally output the verification results of the core layer (including backup licenses) and the extension layer, providing core judgment basis for subsequent flexible downgrade, hot update and other operations.

[0032] In the specific implementation of step S102, one embodiment is as follows: the current license in the core layer and the extension layer is verified in multiple dimensions through the layered verification module and the backup fallback module, including: S1021. For the layer where the current license is located, set different collaborative verification strategies for the layer verification module and the backup fallback module; S1022. Control the layered verification module and the backup fallback module to collaboratively execute the collaborative verification strategy in multiple verification dimensions to verify the current license.

[0033] In steps S1021-S1022, the layered verification module of this application sets different collaborative verification strategies for the layer where the current license is located, namely, the collaborative verification strategy when verifying the core layer is different from the collaborative verification strategy when verifying the extended layer. Specifically, the backup module only listens to the core layer verification process and does not participate in the extended layer verification operation. It controls the layered verification module and the backup module to collaboratively execute the collaborative verification strategy in multiple verification dimensions to verify the current license, thereby ensuring flexible processing in the verification of the current license. If CheckLicenseByLayer(LicenseFunctionLayer::kExtensionLayer) is called to check the current license of the extension layer, the layered verification module will perform verification across three dimensions. If all verifications pass, the verification result of the extension layer will be output, and the Runtime module will initialize the extension layer service normally. If any verification dimension fails, the result of the extension layer verification will be output. In this case, the backup fallback module will not perform any fallback operation. The layered verification module will only report the verification result to the Runtime module, providing a basis for subsequent operations to disable the extension layer function and retain the core layer function.

[0034] In a specific implementation of step S1022, one embodiment involves controlling the hierarchical verification module and the backup fallback module to collaboratively execute the collaborative verification strategy across multiple verification dimensions, including: A1. If the core layer fails the verification of the multiple verification dimensions, the backup fallback module is triggered to load the backup license stored by the vehicle ECU for the core layer. A2. Send the backup license to the layered verification module to verify the backup license, and enable the backup license after the verification is successful.

[0035] In steps A1-A2, when this application calls CheckLicenseByLayer(LicenseFunctionLayer::kCoreLayer) to perform multi-dimensional verification on the core layer, if the current license of the core layer passes all three dimensions of verification, the layered verification module outputs the verification result indicating that the core layer has passed the verification. The backup backup module remains in standby mode and does not perform any operation. The Runtime module initializes the core layer service normally based on the verification result. If the current license of the core layer fails in any verification dimension (e.g., hardware identifier mismatch, license expiration, or unauthorized core function), the layered verification module immediately outputs the verification result indicating that the core layer has failed the verification and simultaneously sends a trigger signal to the backup backup module. After receiving the signal, the backup backup module automatically calls TriggerBackupLicense to load the backup license, specifically by loading it from the independent storage partition of the hardware encryption chip of the NV Flash or ECU via AUTOSAR. The OSAL interface uses the `ara::osal::ReadFromNV` command to read the pre-stored core-layer-specific backup license, and transmits the backup license to the layer verification module. The layer verification module then performs the aforementioned three-dimensional verification on the backup license again. If the backup license verification passes, a verification result indicating that the backup license has passed is output. If the backup license verification still fails, a verification result indicating that both the core layer and the backup license have failed is output. The current license is generated by the manufacturer's backend, contains the vehicle ECU hardware ID, has a 720-hour validity period, and has core layer + extension layer authorization. It is stored in the NVFlash "main_license" partition after AES-256 encryption. The backup license is only authorized for core layer functions and has a validity period of 72 hours for emergency use.

[0036] In the specific implementation of step S1022, another embodiment is as follows: The current license in the core layer and extension layer is verified using multiple verification dimensions through a layered verification module and a backup fallback module, and further includes: B1. Set up hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension for the core attributes of the license; B2. Set the verification methods corresponding to the hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension for verification.

[0037] In steps B1-B2, this application, based on the three inherent core attributes of a license—namely, which device it can be used on, the time period it can be used during, and which functions / permissions it can use—establishes hardware binding verification, validity period verification, and function authorization verification dimensions. For the current licenses in both the core and extension layers, verification is performed across these three core dimensions to ensure the license's legality, timeliness, and permission compliance. Verification methods are set for each of the hardware binding verification, validity period verification, and function authorization verification dimensions. The verification method for the hardware binding verification dimension is: via AUTOSAR. The OSAL abstract interface "ara::osal::GetEcuHardwareId()" retrieves the unique hardware identifier of the vehicle ECU and precisely matches it with the "ecuHardwareId" field preset in the license to prevent the current license from being reused across devices. The validity period verification dimension uses "std::chrono::system_clock" to obtain the current system time and compares it with the effective and expiration times marked in the "expireTime" field of the license to determine if the current license is within its valid usage period. The function authorization verification dimension checks whether the functional scope of the current core layer and extension layer is consistent with the authorized functions marked in the "authorizedLayers" set of the license, verifying the function usage permission. These verification methods are encapsulated through the CheckLicenseByLayer interface and replace the original rigid verification in the InitInstance initialization function of the Runtime module, without modifying the AUTOSAR AP core framework code, achieving flexible processing.

[0038] In step S103, after receiving the verification results of the core layer and extension layer from the layered verification module, the Runtime module of this application controls the AUTOSAR AP architecture Runtime module to enter the target state, i.e., the standby target state, when the verification result is that the core layer verification passes and the extension layer verification passes. At this time, the Runtime module runs normally and initializes all services of the core layer and extension layer normally to ensure that all functions of the vehicle system run normally. According to the Runtime module in the standby target state, it is ready to receive new licenses pushed by the vehicle gateway at any time to ensure that the new licenses can be received and processed in a timely manner, so as to realize online updates without interrupting the service. The Runtime module starts a hot update listening thread, establishes stable communication with the vehicle gateway based on the AUTOSAR SOME / IP protocol, and polls the vehicle gateway for update instructions every 1 minute.

[0039] When the verification result shows that the core layer verification fails but passes, the Runtime module enters the core protection running state. In this state, the Runtime module only initializes the core layer services, shields all functions of the extension layer, and prioritizes the continuous operation of safety-critical services such as braking and steering, in line with the ASIL-D safety level requirements associated with the core layer. At the same time, the Runtime module maintains communication with the vehicle's onboard gateway, starts the hot update monitoring mechanism, receives new licenses pushed by the onboard gateway, and prioritizes the verification of the core layer authorization information in the new license in order to quickly replace the invalid master license and restore the system to normal operation as soon as possible. When both the core layer and backup license verifications fail... At this point, the Runtime module enters emergency backup mode. In this mode, the Runtime module only starts the most basic core emergency services to ensure the basic driving safety of the vehicle to the maximum extent. At the same time, it immediately pushes alarm information containing the ECU number and the reason for failure to the vehicle T-Box through the PushAlarmToGateway interface to alert the remote operation and maintenance platform. In this mode, the Runtime module still maintains communication with the vehicle's onboard gateway, giving priority to receiving new licenses pushed by the onboard gateway. Once a new license is received, the layered verification module is immediately triggered to perform rapid verification. If the verification passes, the license is replaced in time, pushing the Runtime module out of the emergency backup mode and restoring normal operation. If the extension layer verification fails but the core layer verification passes, the Runtime module enters the core normal operation and extension layer shielding mode. In this mode, the Runtime module initializes the core layer services normally and shields all extension layer functions, without affecting the core driving safety of the vehicle. At the same time, the Runtime module starts hot update listening normally, maintains communication with the vehicle's onboard gateway, receives new licenses pushed by the onboard gateway, and focuses on verifying the extension layer authorization information in the new license. If the verification passes, the license is replaced, the extension layer function is enabled, and the system is restored to normal operation.

[0040] The Runtime module of this application accurately enters the corresponding state based on the different verification results fed back by the layered verification module. Regardless of the state, it maintains smooth communication with the vehicle's onboard gateway, ensuring that it can receive new licenses pushed by the onboard gateway in a timely manner. This provides the prerequisite for subsequent encrypted signature verification, license replacement, and hot update to take effect, fully demonstrating the core advantages of this application in flexible operation and maintenance and uninterrupted core services.

[0041] In step S104, after the Runtime module of this application receives the new license pushed by the vehicle's onboard gateway, as follows: Figure 4As shown, the new license data is immediately forwarded to the encrypted hot update module. The encrypted hot update module processes the new license to obtain the target license, and then controls the module to replace the current license based on the target license. The replacement process strictly adheres to the principle of flexible processing, requiring no restart of the vehicle ECU or the AUTOSAR AP architecture's runtime module, thus ensuring uninterrupted operation of the core layer services. During replacement, the encrypted hot update module precisely replaces the current licenses at the core and extended layers according to the authorization scope of the target license: if the target license only contains core layer authorization information, only the current core layer license (including the primary and backup licenses) is replaced, while the current extended layer license remains unchanged; if the target license contains all authorization information at both the core and extended layers, both levels of the current license are replaced simultaneously; if the target license only contains extended layer authorization information, only the current extended layer license is replaced, while the current core layer license remains unchanged. This achieves flexible processing of licenses on the vehicle, including flexible hot updates and flexible replacements, ensuring both the security and accuracy of license updates while avoiding service interruptions.

[0042] In a specific implementation of step S104, one embodiment is as follows: the target license is obtained by processing the new license through the encrypted hot update module, including: S1041. The new license is verified, decrypted, and validated through multiple interfaces of the encrypted hot update module to obtain the corresponding processing results; S1042. Based on the processing result, determine the new license as the target license to replace the current license.

[0043] In steps S1041-S1042, this application verifies, decrypts, and validates the new license through various interfaces called by the encryption verification unit of the encryption hot update module, obtaining corresponding processing results. Specifically, the encryption hot update module receives the new license forwarded by the Runtime module. The new license includes its corresponding license data and digital signature. The new license is encrypted data using the AES-256 algorithm and carries an RSA2048 digital signature. The encryption hot update module first initiates a security verification process. Based on the RSA public key pre-installed by the vehicle manufacturer, it performs RSA2048 or SM2 national cryptographic algorithm verification on the digital signature carried by the new license by calling the VerifyLicenseSignature interface to verify the integrity and validity of the new license data, preventing data from being forged or tampered with during transmission. After the verification is successful, the encryption module further verifies the new license. The hot update module calls the AES-256 key pre-installed in the ECU hardware encryption area and calls the DecryptLicense interface to decrypt the encrypted data of the new license, restoring the plaintext data of the license. This completes the secure decryption of the new license. Then, the module calls the CheckLicenseByLayer(LicenseFunctionLayer::kExtensionLayer) and CheckLicenseByLayer(LicenseFunctionLayer::kCoreLayer) interfaces again to perform three core verification dimensions: hardware binding verification, validity period verification, and function authorization verification. This is consistent with the verification standards of the layered verification module, ensuring that the new license is compatible with the current AUTOSAR AP architecture on the vehicle ECU, and that the authorization scope and validity period meet system requirements. Specifically, the hardware binding verification matches the unique hardware identifier of the vehicle ECU to prevent the loading of invalid licenses across devices; the validity period verification confirms that the new license's effective and expiration times are reasonable, ensuring long-term stable use; and the function authorization verification clarifies the authorization scope of the new license for the core and extension layers, accurately matching the layered configuration of the current architecture. If all the above verifications pass, the encrypted hot update module marks the new license as a valid target license, where the target license is the primary license and the backup license is obtained by copying and can replace the current license; if any verification fails, the encrypted hot update module immediately sends a signal to the Runtime module that the new license processing has failed, does not perform subsequent replacement operations, and pushes an alarm message through the vehicle T-Box to notify remote maintenance personnel to handle the issue and ensure system security.

[0044] In a specific implementation of step S1041, one embodiment includes: before performing signature verification, decryption, and legality verification on the new license, the following steps are taken: S10411. Control the Runtime module to encrypt the new license data and associated data using the target encryption algorithm and target key to obtain the new license; S10412. Invoke the target protocol to enable the Runtime module to transfer the new license to the encrypted hot update module.

[0045] In steps S10411-S10412, to ensure the security of the transmission process and prevent the license data and associated data of the new license from being forged, tampered with, or leaked, this application first controls the Runtime module to perform encryption processing on the new license and associated data, and then calls the target protocol to transmit it to the encryption hot update module. The specific process is as follows: First, the Runtime module uses a preset target encryption algorithm and target key. The target encryption algorithm is either the AES-256 symmetric encryption algorithm or the SM4 national cryptographic algorithm. This algorithm has high encryption efficiency and strong security, and is suitable for the hardware resources and real-time requirements of the vehicle ECU. The target key is a dedicated AES-256 key pre-installed in the hardware encryption area of ​​the vehicle ECU. This key can only be called by the Runtime module and the encryption hot update module and cannot be accessed by other modules, ensuring key security. Subsequently, the Runtime module initiates the encryption process, integrating the new license data pushed by the vehicle gateway, along with corresponding associated data (including license authorization scope description, supplementary information on effective / expiration dates, and hardware binding auxiliary data), into a set of data to be encrypted. It then calls the target encryption algorithm (AES-256) and passes in the target key to perform symmetric encryption on the entire set of data, generating a new license that can be securely transmitted. After encryption, the Runtime module performs integrity verification on the new license data, confirming that there was no data loss or encryption anomalies during the encryption process, ensuring that the subsequent encryption hot update module can decrypt it normally. After successful encryption verification, the Runtime module calls the preset target protocol, namely the AUTOSAR SOME / IP or DDS protocol, to establish a SOME / IP communication channel with the encryption hot update module. The Runtime module transmits the new license to the encryption hot update module through the established SOME / IP communication channel, monitoring the transmission status in real time. If transmission interruption or data loss occurs, the transmission request is immediately re-initiated until successful transmission. If multiple transmission failures occur, a transmission alarm message is pushed to the vehicle T-Box to notify remote maintenance personnel to troubleshoot the communication fault. Throughout the process, the Runtime module ensures data security through the target encryption algorithm and target key, and guarantees reliable transmission through the target protocol. This enables the secure and efficient transmission of the new license to the encrypted hot update module, laying the foundation for subsequent decryption, verification, and replacement operations of the encrypted hot update module, and meeting the core requirements of security protection and flexible operation and maintenance.

[0046] Example 2 This application also provides a flexible processing device for vehicle licenses, such as... Figure 5 The diagram shows a block diagram of a flexible vehicle license processing device. This device performs functions corresponding to the steps of executing a flexible vehicle license processing method on a terminal device as described above. The device can be understood as a server component including a processor. The flexible vehicle license processing device described in this application is suitable for a processing system, which includes a layered verification module, an encrypted hot-update module, and a fallback backup module. The device includes: Configuration module 501 is used to pre-configure the AUTOSAR AP architecture deployed on the vehicle ECU, obtain the core layer and the extension layer, and call the current license in the configured core layer and extension layer respectively. The verification module 502 is used to perform multiple verification dimensions on the current licenses in the core layer and the extension layer through the layered verification module and the backup fallback module, and obtain the verification results. The receiving module 503 is used to control the Runtime module of the AUTOSAR AP architecture to enter the target state based on the verification result, and to receive the new license pushed by the vehicle gateway on the vehicle according to the Runtime module in the target state. The replacement module 504 is used to process the new license through the encrypted hot update module to obtain the target license, and to control the encrypted hot update module to replace the current license based on the target license, so as to realize flexible processing of licenses on the vehicle.

[0047] In one feasible implementation, the verification module includes: For the layer where the current license is located, set different collaborative verification strategies for the layer verification module and the backup fallback module; The hierarchical verification module and the backup fallback module are controlled to collaboratively execute the collaborative verification strategy across multiple verification dimensions to verify the current license.

[0048] In one feasible implementation, the verification module further includes: If the core layer fails the verification of the multiple verification dimensions, the backup fallback module is triggered to load the backup license stored by the vehicle ECU for the core layer. The backup license is sent to the hierarchical verification module to verify the backup license, and the backup license is enabled after the verification is successful.

[0049] In one feasible implementation, the verification module also includes: For the core attributes of the license, hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension are set up; Configure the verification methods corresponding to the hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension for verification.

[0050] In one feasible implementation, the replacement module includes: The new license is verified, decrypted, and validated through various interfaces of the encrypted hot update module to obtain the corresponding processing results; Based on the processing results, the new license is determined as the target license to replace the current license.

[0051] In one feasible implementation, the replacement module further includes: The Runtime module is controlled to encrypt the new license data and associated data using a target encryption algorithm and a target key to obtain the new license. The target protocol is invoked to cause the Runtime module to transfer the new license to the encrypted hot update module.

[0052] In one feasible implementation, the configuration module includes: Collect all functions in the AUTOSAR AP architecture and divide these functions into a core layer and an extension layer according to security level and business importance; Based on the types of the core layer and the extension layer, the core layer and the extension layer are configured to be associated with different security levels.

[0053] Example 3 This application also provides an electronic device, such as Figure 6 As shown, it includes: a processor 601, a memory 602, and a bus 603. The memory 602 stores machine-readable instructions that can be executed by the processor 601. When the electronic device is running, the processor 601 and the memory 602 communicate through the bus 603. When the machine-readable instructions are executed by the processor 601, the steps of any of the flexible processing methods for vehicle licenses described above are executed.

[0054] Example 4 This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of any of the flexible processing methods for vehicle licenses described herein.

[0055] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0056] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0057] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0058] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0059] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A flexible processing method of vehicle permits, characterized in that, The method is applicable to a processing system, which includes a layered verification module, an encrypted hot update module, and a fallback backup module. The AUTOSAR AP architecture deployed on the vehicle ECU is pre-configured to obtain the core layer and the extension layer, and the current license in the configured core layer and extension layer is called respectively. The current licenses in the core layer and extension layer are verified in multiple dimensions through the layered verification module and the backup fallback module to obtain the verification results. Based on the verification result, the Runtime module of the AUTOSAR AP architecture is controlled to enter the target state, and the Runtime module in the target state receives the new license pushed by the vehicle gateway. The new license is processed by the encrypted hot update module to obtain the target license, and the encrypted hot update module is controlled to replace the current license based on the target license, so as to achieve flexible processing of licenses on the vehicle.

2. The method of claim 1, wherein, The current licenses in the core and extension layers are verified using a layered verification module and a backup fallback module, across multiple dimensions, including: For the layer where the current license is located, set different collaborative verification strategies for the layer verification module and the backup fallback module; The hierarchical verification module and the backup fallback module are controlled to collaboratively execute the collaborative verification strategy across multiple verification dimensions to verify the current license.

3. The method of claim 2, wherein, Controlling the hierarchical verification module and the backup fallback module to collaboratively execute the collaborative verification strategy across multiple verification dimensions includes: If the core layer fails the verification of the multiple verification dimensions, the backup fallback module is triggered to load the backup license stored by the vehicle ECU for the core layer. The backup license is sent to the hierarchical verification module to verify the backup license, and the backup license is enabled after the verification is successful.

4. The method of claim 2, wherein, The current licenses in the core layer and extension layer are verified through multiple dimensions using a layered verification module and a backup fallback module, including: For the core attributes of the license, hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension are set up; Configure the verification methods corresponding to the hardware binding verification dimension, validity period verification dimension, and function authorization verification dimension for verification.

5. The method of claim 1, wherein, The target license is obtained by processing the new license through the encrypted hot update module, including: The new license is verified, decrypted, and validated through various interfaces of the encrypted hot update module to obtain the corresponding processing results; Based on the processing results, the new license is determined as the target license to replace the current license.

6. The method of claim 5, wherein, Before performing signature verification, decryption, and legality verification on the new license, the following steps are included: The Runtime module is controlled to encrypt the new license data and associated data using a target encryption algorithm and a target key to obtain the new license. The target protocol is invoked to cause the Runtime module to transfer the new license to the encrypted hot update module.

7. The method of claim 1, wherein, The AUTOSAR AP architecture deployed on the vehicle ECU is pre-configured to obtain a core layer and an extension layer, including: Collect all functions in the AUTOSAR AP architecture and divide these functions into a core layer and an extension layer according to security level and business importance; Based on the types of the core layer and the extension layer, the core layer and the extension layer are configured to be associated with different security levels.

8. A flexible processing apparatus for vehicle permits, characterized by, Suitable for processing systems, the processing system including a layered verification module, an encrypted hot update module, and a fallback backup module, the device includes: The configuration module is used to pre-configure the AUTOSAR AP architecture deployed on the vehicle ECU, obtain the core layer and the extension layer, and call the current license in the configured core layer and extension layer respectively. The verification module is used to perform multi-dimensional verification of the current licenses in the core layer and extension layer through the layered verification module and the backup fallback module, and obtain the verification results. The receiving module is used to control the Runtime module of the AUTOSAR AP architecture to enter the target state based on the verification result, and to receive the new license pushed by the vehicle gateway in the vehicle according to the Runtime module in the target state. The replacement module is used to process the new license through the encrypted hot update module to obtain the target license, and to control the encrypted hot update module to replace the current license based on the target license, so as to realize flexible processing of licenses on the vehicle.

9. An electronic device, comprising: include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of a flexible processing method for a vehicle license as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of a flexible processing method for vehicle licenses as described in any one of claims 1 to 7.

Images