Vehicle key, method for controlling same, and vehicle equipped with same

Abstract

The invention relates to the technical field of vehicle control, and provides a vehicle key, a control method thereof and a vehicle equipped with the vehicle key. The vehicle key control method comprises the following steps: in response to operation of a user on a vehicle key, determining a target vehicle in a plurality of authorized vehicles configured by the vehicle key; configuration information corresponding to the target vehicle and a vehicle control instruction triggered by a user are obtained, and the configuration information comprises a communication protocol, an instruction coding table and radio frequency configuration information; constructing a data frame corresponding to the vehicle control instruction according to the communication protocol and the instruction coding table, and determining a target radio frequency module matched with the target vehicle according to the radio frequency configuration information; and sending the data frame to the target vehicle through the target radio frequency module so as to control the target vehicle. According to the vehicle key control method, vehicles of different brands and different models can be controlled only through one physical key, and then the vehicle using convenience of a user is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a vehicle key, a control method thereof, and a vehicle equipped with the same. Background Technology

[0002] In current automotive use, it is increasingly common for a single user to own multiple vehicles. As a core control component of a vehicle, the vehicle key is crucial for enabling functions such as unlocking and starting the vehicle.

[0003] In related technologies, vehicle keys are mostly vehicle-specific, meaning that different vehicles cannot share a single physical key.

[0004] However, when a single user owns multiple cars, it is necessary to manage and distinguish multiple vehicle keys, which can easily lead to key confusion, omissions, and other issues, resulting in poor user convenience. Summary of the Invention

[0005] In view of this, this application aims to propose a vehicle key control method to control multiple vehicles of different brands and models with a single physical key, thereby improving the user's vehicle use convenience.

[0006] To achieve the above objectives, the technical solution of this application is implemented as follows:

[0007] A vehicle key control method, the method comprising:

[0008] In response to the user's operation on the vehicle key, the target vehicle is determined from among the multiple authorized vehicles configured on the vehicle key;

[0009] The configuration information corresponding to the target vehicle and the vehicle control command triggered by the user are obtained. The configuration information includes the communication protocol, the command encoding table and the radio frequency configuration information.

[0010] Based on the communication protocol and the instruction encoding table, a data frame corresponding to the vehicle control instruction is constructed, and based on the radio frequency configuration information, a target radio frequency module matching the target vehicle is determined.

[0011] The target radio frequency module sends the data frame to the target vehicle to control the target vehicle.

[0012] Furthermore, the vehicle key includes a hardware security module, which stores a key corresponding to each authorized vehicle.

[0013] The step of constructing the data frame corresponding to the vehicle control command according to the communication protocol and the command encoding table includes:

[0014] According to the communication protocol and the instruction encoding table, assemble the instruction data block corresponding to the vehicle control instruction;

[0015] The hardware security module performs encryption operations based on the key corresponding to the target vehicle and the instruction data block to obtain the electronic signature corresponding to the instruction data block;

[0016] According to the communication protocol, the electronic signature and the instruction data block are encapsulated to obtain the data frame.

[0017] Furthermore, the method also includes:

[0018] The usage priority of each authorized vehicle is determined according to a preset determination method;

[0019] Based on the usage priority of each authorized vehicle, a candidate vehicle is determined, and the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the candidate vehicle are stored in the cache of the vehicle key.

[0020] If the target vehicle is determined to be the candidate vehicle, the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the target vehicle are obtained from the cache.

[0021] Furthermore, determining the usage priority of each authorized vehicle according to a preset determination method includes:

[0022] Based on the stored vehicle information and usage records of each authorized vehicle, determine the feature values ​​and calculation weights of multiple preset priority evaluation features corresponding to each authorized vehicle;

[0023] Based on the calculation weight and feature value corresponding to each of the preset priority evaluation features, the priority score corresponding to each authorized vehicle is calculated respectively.

[0024] The usage priority of each authorized vehicle is determined based on the priority score.

[0025] Among them, several of the preset priority evaluation features include vehicle brand, usage frequency, usage scenario, and historical habits.

[0026] Furthermore, the feature values ​​of the usage scenario characteristics corresponding to the authorized vehicle are determined in the following way:

[0027] Obtain multiple historical driving trajectories of the authorized vehicle;

[0028] Determine the matching confidence level between each historical driving trajectory and multiple preset scene types;

[0029] Based on the matching confidence of each historical driving trajectory with each of the scene types, calculate the scene fit between the authorized vehicle and each of the scene types;

[0030] The scenario type of the authorized vehicle in the current time is predicted according to a preset rule, and the scenario adaptability corresponding to the scenario type is used as the feature value of the usage scenario feature corresponding to the authorized vehicle.

[0031] Furthermore, the step of calculating the priority score corresponding to each authorized vehicle based on the calculated weight and the feature value corresponding to each preset priority evaluation feature includes: calculating the product of the calculated weight and the feature value corresponding to each preset priority evaluation feature;

[0032] The priority score for each authorized vehicle is obtained by summing the products corresponding to each preset priority evaluation feature.

[0033] Furthermore, the vehicle key includes a vehicle selection knob that can be rotated by a rotating mechanism. The vehicle selection knob is used by the user to select the target vehicle from among the authorized vehicles. After determining the usage priority of each authorized vehicle, the method further includes:

[0034] The rotating mechanism drives the vehicle selection knob to rotate, causing the selection button to point to the gear corresponding to the authorized vehicle with the highest priority; or...

[0035] When the priority score of the authorized vehicle with the highest priority is close to that of the authorized vehicle with the second highest priority, the vehicle selection knob is rotated by the rotating mechanism, so that the vehicle selection button points to a position between the gear corresponding to the authorized vehicle with the highest priority and the gear corresponding to the authorized vehicle with the second highest priority.

[0036] Furthermore, the vehicle key includes a display screen for displaying each of the authorized vehicles and allowing the user to select the target vehicle. After determining the usage priority of each of the authorized vehicles, the method further includes:

[0037] The authorized vehicles are displayed on the screen in a preset order;

[0038] The preset order is determined at least according to the usage priority of each authorized vehicle.

[0039] Compared with related technologies, this application has at least the following advantages:

[0040] (1) The vehicle key control method described in this application responds to the user's operation when the user operates the vehicle key, determines the target vehicle triggered by the user's operation and the triggered vehicle control command from multiple authorized vehicles, and encapsulates the vehicle control command into a data frame according to the configuration information of the target vehicle and the relevant requirements corresponding to the target vehicle, and successfully sends the data frame to the target vehicle through the target radio frequency module matched with the target vehicle, so that the target vehicle can perform the corresponding control, thereby enabling the control of multiple different or even different brands of authorized vehicles with one vehicle key.

[0041] In this way, when a user owns multiple vehicles, they can use only one key, which makes key management less chaotic. When a user wants to drive a vehicle, they do not need to select a specific key, thus improving the user's convenience.

[0042] (2) In this application, when constructing the data frame corresponding to the vehicle control command, the corresponding command data block is first assembled, and then the hardware security module encrypts it based on the target vehicle's key and the command data block to obtain the electronic signature of the command data block. Finally, the electronic signature and the command data block are encapsulated through the communication protocol to obtain the data frame, so that the data frame simultaneously contains core control information and an anti-counterfeiting electronic signature. Since the electronic signature is uniquely bound to the command data block, if the command data block is tampered with during transmission, the target vehicle will fail to verify the electronic signature and refuse to execute the command. Therefore, it can prevent the forgery or malicious tampering of vehicle control commands, thereby improving the safety of vehicle operation.

[0043] (3) In this application, the usage priority of each authorized vehicle is first determined by a preset determination method. Based on the usage priority, alternative vehicles are determined, and the communication protocol, instruction encoding table, and radio frequency configuration information corresponding to the alternative vehicles are stored in the cache of the vehicle key in advance. When the determined target vehicle is an alternative vehicle, the configuration information corresponding to the target vehicle can be directly obtained from the cache. That is, the alternative vehicles most likely to be used by the user are initially screened by using priority, and the relevant configuration information of these vehicles is pre-read and stored in the cache. The read and write speed of the cache is much higher than that of the storage module of the vehicle key. Therefore, pre-loading the configuration information of the alternative vehicles into the cache in advance, instead of the process of temporarily retrieving the configuration information from the storage module after the user operation, can shorten the time for obtaining the configuration information, thereby shortening the overall time for data frame construction and transmission, and realizing the rapid response of the vehicle key.

[0044] (4) In this application, the vehicle brand, frequency of use, usage scenario and historical habits feature values ​​and calculation weights are determined by vehicle information and vehicle use records. Then, the priority score is calculated to determine the usage priority. In the process of determining the usage priority, multiple preset priority evaluation features are considered to avoid the one-sidedness of single-dimensional ranking and thus improve the accuracy of determining the usage priority.

[0045] (5) In this application, the scenario fit is calculated by historical driving trajectory and matching confidence, and the usage scenario feature value is determined by combining the current time. In this way, since the historical driving trajectory can truly reflect the actual usage scenario of the authorized vehicle, the matching confidence can quantify the similarity between a single trajectory and the scenario type, and the scenario fit can comprehensively reflect the overall matching situation between the authorized vehicle and each scenario type, and combined with the current time to predict the scenario type of the user's current usage scenario, the feature value of the determined usage scenario feature can be more in line with the user's current car use needs, thereby improving the accuracy of priority score calculation and making the usage priority ranking more in line with the user's actual car use habits.

[0046] (6) In this application, the priority score of each authorized vehicle is calculated by weighted summation based on the calculation weight and feature value corresponding to each preset priority evaluation feature. This avoids the error caused by the direct superposition of multi-dimensional data, thereby improving the accuracy of priority score calculation and ensuring the rationality of using priority ranking.

[0047] (7) In this application, the vehicle selection knob is also adjusted to the highest priority vehicle position so as to select the vehicle that the user actually wants to drive. In this way, the user does not need to rotate the vehicle selection knob to select the vehicle, but can directly trigger the control operation, thereby saving operation time and improving user convenience.

[0048] In addition, when the priority score of the authorized vehicle with the highest priority is similar to that of the authorized vehicle with the second highest priority, the vehicle selection button is positioned between the corresponding gears of the two. This allows users to select the corresponding vehicle by simply rotating the button to either side, thereby reducing the number of manual rotation steps and ultimately improving the convenience of the vehicle selection operation and the user experience.

[0049] (8) In this application, the vehicle key uses a display screen to directly show each authorized vehicle and allows the user to select the target vehicle, providing a visual vehicle selection method that is more intuitive and easier to understand than physical operation. Furthermore, after determining the usage priority of each authorized vehicle, the vehicles are displayed on the screen in a preset order determined at least according to their usage priority. This ensures that the authorized vehicle with the highest usage priority is the one the user is most likely to use, and can be displayed prominently on the screen in a preset order, allowing the user to quickly find and select the target vehicle, thereby reducing the steps and time required for vehicle selection.

[0050] Another objective of this application is to provide a vehicle key that includes a storage module, a radio frequency module, and a control module.

[0051] The storage module stores configuration information for multiple authorized vehicles;

[0052] The radio frequency modules are multiple and are configured one-to-one with each of the authorized vehicles, and each radio frequency module is used to send radio frequency signals to the corresponding authorized vehicle.

[0053] When the user operates the vehicle key, the control module can execute the vehicle key control method described above.

[0054] Another object of this application is to provide a vehicle equipped with the aforementioned vehicle key.

[0055] The vehicle key described in this application enables control of vehicles of different brands and models. This allows users to use a universal vehicle key instead of searching for a specific one, thus improving user convenience. Attached Figure Description

[0056] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0057] Figure 1 This is a flowchart illustrating the vehicle key control method described in an embodiment of this application;

[0058] Figure 2 This is a schematic diagram illustrating the process of preloading relevant configurations in the vehicle key control method described in this application embodiment;

[0059] Figure 3 This is a schematic diagram of the process for determining the usage priority in the vehicle key control method described in the embodiments of this application;

[0060] Figure 4 This is a flowchart illustrating the process of determining the feature values ​​of usage scenario characteristics in the vehicle key control method described in this application embodiment;

[0061] Figure 5 This is a schematic diagram illustrating the structure of a vehicle key as described in an embodiment of this application.

[0062] Explanation of reference numerals in the attached figures:

[0063] 10. Storage module; 20. Radio frequency module; 30. Control module; 40. Hardware security module. Detailed Implementation

[0064] To make the technical solution and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0065] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0066] Furthermore, it should be noted that in the description of this application, if terms such as "upper," "lower," "inner," or "outer" appear, indicating orientation or positional relationship, these are based on the orientation or positional relationship shown in the accompanying drawings and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. In addition, if terms such as "first" or "second" appear, they are also used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0067] Furthermore, in the description of this application, unless otherwise expressly defined, the terms "installation," "connection," "joining," and "connector" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application in light of the specific circumstances.

[0068] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0069] The present application will now be described in detail through exemplary embodiments. However, it should be understood that, without further description, elements, structures, and features in one embodiment may be advantageously incorporated into other embodiments.

[0070] An embodiment of the first aspect of this application provides a vehicle key control method that allows one key to be used by multiple vehicles (which can be from different brands). Specifically, the method can send corresponding data frames to the vehicle according to the target vehicle selected by the user and the vehicle control command, through a communication protocol, command encoding table, radio frequency module 20, etc., to achieve vehicle control, thereby using one key to control multiple different vehicles (which can also be vehicles of different brands), thus improving the user's vehicle use convenience.

[0071] The physical key of a vehicle is the core device for controlling vehicle unlocking, locking, starting, and other control operations. The physical key integrates a radio frequency module 20, a storage module 10, and a control module 30. When a user issues a control command using the key, the control module 30 encapsulates the command into a vehicle-recognizable data frame, which is then transmitted to the vehicle as a radio frequency signal via the radio frequency module 20. The vehicle receives and verifies the validity of the data frame before executing the corresponding unlocking, locking, or other control operations.

[0072] Currently, in related technologies, the communication protocols, encryption keys, and radio frequency modulation methods used by different vehicles and even different brands are all proprietary and incompatible with each other. This results in the internal configuration of each physical key being bound to a single brand and a single vehicle. In other words, a key can only control one vehicle and cannot be compatible with other brands or other vehicles of the same brand.

[0073] Currently, it is very common for users to own multiple vehicles in scenarios such as multi-car households and corporate fleets. These vehicles often cover different brands and models. In such scenarios, the implementation method of a single physical key only being compatible with a single brand and a single vehicle will result in insufficient convenience for users.

[0074] For example, multi-car households need to equip their vehicles of different brands with their own physical keys, which leads to chaotic management and the risk of losing one or more keys or users confusing the vehicle keys. Similarly, corporate fleet managers need to manage multiple vehicles of different brands, each with its own key, which increases the cost of key management and storage and can also affect the progress of operations due to key mismatch during vehicle dispatch.

[0075] In view of this, in order to overcome the shortcomings of related technologies, the vehicle key control method in this embodiment combines... Figure 1In terms of overall design, it includes the following steps S110-S140.

[0076] Step S110: In response to the user's operation on the vehicle key, determine the target vehicle from among the multiple authorized vehicles configured on the vehicle key.

[0077] Step S120: Obtain the configuration information corresponding to the target vehicle, as well as the vehicle control command triggered by the user.

[0078] Specifically, the vehicle key is an intelligent physical key with data storage, processing, and input / output functions, used to control various authorized vehicles in response to user commands. It has a built-in control module 30, which is the execution element for implementing the vehicle control method of this embodiment.

[0079] Authorized vehicles refer to vehicles that have completed pre-configuration processes such as binding and authentication with the vehicle key, and that are authorized to be controlled by that vehicle key. These vehicles can include vehicles of different brands and models. It is important to note that each authorized vehicle must complete two-way security authentication with the vehicle key beforehand; only authorized vehicles that have passed authentication can be controlled by that key.

[0080] The target vehicle is the vehicle selected by the current user after operating the vehicle key.

[0081] User-triggered vehicle control commands are commands initiated by the user based on their own vehicle usage needs, using the vehicle key to request the target vehicle to perform specific actions. These commands form the basis for the final actions the target vehicle needs to execute. Specific examples include unlocking, locking, trunk opening, window raising / lowering, and vehicle starting commands.

[0082] More specifically, the vehicle key is equipped with a vehicle selection component for users to select a target vehicle, and a control selection component for users to select control commands for the vehicle.

[0083] Specifically, the user's operation of the vehicle key can include: vehicle selection operation generated by the vehicle selection component and control selection operation generated by the control selection component.

[0084] Specifically, if the user performs a control selection operation after selecting a vehicle, step S110 is executed to respond to the user's operation and determine the target vehicle. This target vehicle is the vehicle selected by the user during the vehicle selection operation, and the vehicle control command triggered by the user is determined based on the current user's control selection operation.

[0085] After the user performs the vehicle selection operation, if the user does not perform the control selection operation, step S110 can be skipped (possibly due to accidental touch), or step S110 can be performed. When step S110 is performed, the target vehicle is the vehicle selected by the user, but the vehicle control command triggered by the user is the default vehicle control command, such as unlocking.

[0086] If the user performs a control selection operation without performing a vehicle selection operation, then step S110 can be executed, and the vehicle selected by the user in the previous selection operation can be used as the target vehicle. Based on the current user's control selection operation, the vehicle control command triggered by the user can be determined.

[0087] Conversely, if the user does not perform a vehicle selection operation or a control selection operation, it means that the user has not operated the vehicle key, and steps S110-S140 will not be triggered.

[0088] Specifically, the vehicle selection component can be a physical knob (each gear corresponds to one authorized vehicle), a button (each button corresponds to one authorized vehicle), or a touchscreen (the touchscreen displays vehicle icons for each authorized vehicle, which users can click to select the target vehicle). Similarly, the control selection component can also be a physical knob, a button, or a touchscreen, which will not be elaborated further here.

[0089] After the user operates the vehicle key, the vehicle key needs to generate corresponding data frames based on the authorized vehicle (i.e. the target vehicle) selected by the user and the vehicle control command selected by the user, and send them to the vehicle so that the vehicle can receive and execute the corresponding vehicle control command.

[0090] Therefore, in step S120, the configuration information corresponding to the target vehicle is first obtained, and then in step S130 below, the corresponding data frame is generated based on the configuration information.

[0091] Specifically, a storage module 10 is installed inside the vehicle key. This storage module 10 is used to store the configuration information corresponding to each authorized vehicle. The configuration information may include communication protocols, instruction encoding tables, and radio frequency configuration information.

[0092] More specifically, this communication protocol is the communication protocol used for data transmission between the vehicle and the vehicle key, and may include data frame structure, transmission rate, frame header and frame footer identifiers, etc.

[0093] The instruction coding table is a pre-agreed standard between authorized vehicles and vehicle keys, containing a mapping table of vehicle control commands and their corresponding standard codes. The standard code refers to the original command code corresponding to the vehicle. For example, the original command code for locking the car is 0x0A in a vehicle of brand A1, and 0x1F in a vehicle of brand A2. For the vehicle key, it needs to use this instruction coding table to convert the user-triggered vehicle control commands into a standardized code recognizable by the vehicle. This code is the direct basis for the vehicle to execute the corresponding control. The instruction coding tables differ between different brands and models of vehicles.

[0094] It is worth noting that different authorized vehicles typically have their own proprietary communication protocols and instruction encoding tables. If you wish to control a vehicle using a vehicle key, the data frames sent from the vehicle key to the vehicle must conform to that vehicle's proprietary communication protocol and use its proprietary instruction encoding table; otherwise, the vehicle cannot accurately parse and recognize the data frame, and therefore cannot perform the corresponding control operation.

[0095] Furthermore, the data frames used to transmit vehicle control commands between the vehicle and the vehicle key all use radio frequency (RF) signals as carriers. Therefore, when the vehicle key sends corresponding data to the vehicle, the corresponding RF module 20 needs to generate a corresponding RF signal based on the data frame and send it to the vehicle. The vehicle's built-in onboard RF receiver module then receives and parses this RF signal.

[0096] Different vehicle brands use different operating parameters for their onboard radio frequency (RF) receiver modules. If a vehicle key uses only a single-specification RF module 20 and transmits RF signals with fixed parameters, the RF signal may not be recognized by the onboard RF receiver module of each authorized vehicle, or it may cause data packet loss or excessive transmission latency, thus preventing effective vehicle control. In other words, authorized vehicles of different brands and models require corresponding dedicated RF modules 20 and operating parameters to ensure the stability and effectiveness of wireless data transmission.

[0097] Therefore, a corresponding radio frequency module 20 is set in the vehicle key for each authorized vehicle. Each radio frequency module 20 is used to transmit a matching radio frequency signal to the authorized vehicle to ensure stable wireless data interaction between the vehicle key and the corresponding authorized vehicle.

[0098] The aforementioned radio frequency (RF) configuration information can refer to the configuration of the RF module 20 corresponding to the target vehicle. For example, it could be the identifier of the RF module 20 or the relevant RF configuration of the target vehicle. This RF configuration information facilitates the activation of the corresponding RF module 20 based on the user's selected target vehicle, enabling data interaction.

[0099] More specifically, since the aforementioned communication protocol, instruction encoding table, and radio frequency configuration information are all stored in the storage module 10 built into the vehicle key, in step S120, the configuration information corresponding to the target vehicle can be directly obtained from the storage module 10 based on the target vehicle, and then step S130 is executed to construct a corresponding data frame based on the configuration information of the target vehicle.

[0100] Step S130: Construct the data frame corresponding to the vehicle control command according to the communication protocol and command encoding table, and determine the target radio frequency module that matches the target vehicle according to the radio frequency configuration information.

[0101] Specifically, in step S130, the data frame corresponding to the vehicle control command is first constructed according to the communication protocol and command encoding table of the target vehicle.

[0102] This data frame serves as a carrier for information transmission between the vehicle key and the vehicle, allowing the vehicle to determine control commands based on the data frame.

[0103] More specifically, the control module 30 inside the vehicle key first converts the vehicle control command triggered by the user into the corresponding standard code according to the command encoding table of the target vehicle; then, according to the frame structure agreed upon by the communication protocol of the target vehicle, it encapsulates the standard code to obtain the data frame corresponding to the vehicle control command.

[0104] While constructing the data frame corresponding to the vehicle control command, it is also necessary to determine the target radio frequency module matched with the target vehicle from the various radio frequency modules 20 in the vehicle key according to the radio frequency configuration information of the target vehicle. The radio frequency signal generated by the target radio frequency module can be received and identified by the target vehicle.

[0105] Step S140: Send a data frame to the target vehicle through the target radio frequency module to control the target vehicle.

[0106] Specifically, in step S140, the data frame obtained in step S130 is transmitted to the target vehicle via a radio frequency signal through the target radio frequency module matched with the target vehicle. The target vehicle can then read the data frame, and since the data frame is encapsulated according to the target vehicle's communication protocol, it can correctly identify the content of the data frame and obtain the standard code corresponding to the vehicle control command carried within the data frame.

[0107] Then, the target vehicle can determine and execute vehicle control commands based on the standard code and the command code table already configured on the target vehicle, thereby achieving control of the target vehicle.

[0108] Therefore, through the above steps S110-S140, when the user operates the vehicle key, the system responds to the user's operation, determines the target vehicle triggered by the user's operation and the triggered vehicle control command from multiple authorized vehicles, and encapsulates the vehicle control command into a data frame according to the configuration information of the target vehicle and the relevant requirements of the target vehicle. The data frame is then successfully sent to the target vehicle through the target radio frequency module matched with the target vehicle, so that the target vehicle can perform the corresponding control. Thus, a single vehicle key can be used to control different, or even different, authorized vehicles of different brands.

[0109] In this way, when a user owns multiple vehicles, they can use only one key, which reduces key management and storage costs and prevents key management from becoming chaotic. Users do not need to select a specific key when they want to drive the vehicle, thus improving the convenience of using the vehicle.

[0110] In some exemplary embodiments, the vehicle key may include not only the control module 30, the storage module 10, and each radio frequency module 20, but also a hardware security module 40. The hardware security module 40 stores the keys corresponding to each authorized vehicle.

[0111] The key refers to a pre-agreed, proprietary encryption key between the authorized vehicle and its key. Each authorized vehicle has a unique key, and each key is bound to its corresponding authorized vehicle, specifically its VIN (Vehicle Identification Number). This key can be a symmetric or asymmetric encryption key, such as an AES-128 key or an ECDSA private key.

[0112] The hardware security module 40 can specifically be an HSM (Hardware Security Module), which is a dedicated chip for securely storing keys and performing encryption operations. For example, a dedicated HSM chip that conforms to FIPS 140-2 Level 3 or CC EAL4+ certification can be used to completely isolate the entire process of generating, storing and using encryption keys. The keys are never exposed in plaintext form in system memory or bus, and the key lifecycle is managed by the key management engine built into the HSM. It supports key fragment storage, periodic rotation and zero-level erasure.

[0113] Continue by Figure 1In some exemplary implementations, step S130 above, constructing a data frame corresponding to the vehicle control command according to the communication protocol and command encoding table, may specifically include: assembling a command data block corresponding to the vehicle control command according to the communication protocol and command encoding table. After assembling the command data block, the hardware security module 40 performs encryption operations based on the key corresponding to the target vehicle and the command data block to obtain an electronic signature corresponding to the command data block. Then, the electronic signature and the command data block can be encapsulated according to the communication protocol to obtain a data frame.

[0114] More specifically, the vehicle key control module 30 first converts the user-triggered vehicle control command into a corresponding standard code based on the acquired communication protocol and command encoding table of the target vehicle. Then, according to the data format agreed upon in the communication protocol, the control module 30 integrates this standard code with relevant identifiers of the target vehicle (such as the vehicle's VIN code), command generation timestamps, and other information to assemble a command data block of the required length according to the communication protocol. The control module 30 then transmits this command data block to the hardware security module 40.

[0115] After receiving the instruction data block, the hardware security module 40 can, on the one hand, retrieve the target vehicle's exclusive key and perform encryption operations to obtain the corresponding electronic signature, and on the other hand, first verify the legality of the instruction data block, and after the verification is passed, retrieve the target vehicle's exclusive key and perform encryption operations to obtain the corresponding electronic signature.

[0116] More specifically, when the hardware security module 40 performs encryption and signature calculations to obtain the corresponding electronic signature, it can use the AES-256 encryption algorithm, hash calculation, or ECC-384 to obtain the corresponding encryption signature. Alternatively, it can use multiple encryption methods to perform multi-level encryption to obtain the corresponding encryption signature; this is not limited here.

[0117] It is worth noting, however, that all key-based encryption calculations are performed within the hardware security module 40, and the key never leaves the hardware security module 40. The hardware security module 40 only returns the electronic signature to the vehicle key control module 30 after completing the encryption calculation and obtaining the electronic signature; it does not output any key externally, thus preventing key leakage.

[0118] In addition, the hardware security module 40 can also support an anti-cloning mechanism. Specifically, each time the hardware security module 40 communicates with the control module 30, it can combine the challenge-response authentication mechanism in the vehicle protocol and generate a dynamic random identity to complete two-way authentication. This eliminates the risk of the hardware security module 40 being illegally cloned or counterfeited at the communication link level, ensuring the uniqueness and security of the authentication process between the vehicle key and the authorized vehicle.

[0119] For example, when the vehicle key control module 30 needs to communicate with the hardware security module 40 (such as retrieving the target vehicle's key or performing encrypted operations on instruction data blocks), the control module 30, acting as the "challenger," generates a random challenge code based on the target vehicle's proprietary communication protocol. This challenge code can contain dynamic information such as the current communication timestamp, the vehicle key's unique hardware identifier (such as the control module 30's SN code), and the target vehicle's authorization identifier. Furthermore, the challenge code generated for each communication is unique. The control module 30 then sends this random challenge code to the hardware security module 40, triggering the two-way authentication process.

[0120] After receiving the challenge code, the hardware security module 40, as the "respondent", first verifies the integrity of the challenge code (verifies the validity of the timestamp and the matching of the hardware unique identifier) ​​through the built-in anti-tampering verification unit. If the verification fails, the communication is directly interrupted and the hardware security module 40 is locked. If the verification passes, the corresponding response code and identity identifier are generated. This identity identifier can be uniquely bound to this communication session and automatically expires after the session ends and cannot be reused.

[0121] Subsequently, the hardware security module 40 synchronously feeds back the response code and the dynamic random identifier to the control module 30. Upon receiving the feedback, the control module 30 verifies it. If it determines that the hardware security module 40 poses a cloning risk, it immediately terminates all vehicle control-related operations. If the verification is successful, the control module 30 sends an authentication pass command to the hardware security module 40, along with a receipt code generated by itself based on the dynamic random identifier. Only after verifying the receipt code is correct does the hardware security module 40 formally respond to the communication request from the control module 30 (performing encryption operations).

[0122] The challenge code, response code, and dynamic random identity identifier for each communication are dynamically generated and valid only once. Even if an illegal cloned device steals the authentication data of a certain communication, it cannot be reused for the next communication, thus fundamentally eliminating the risk of the hardware security module 40 being cloned or counterfeited and used to illegally control the vehicle.

[0123] After the hardware security module 40 returns the electronic signature, the control module 30 encapsulates the electronic signature and the instruction data block according to the communication protocol to obtain a data frame. Specifically, after receiving the electronic signature returned by the hardware security module 40, the control module 30 integrates and encapsulates the instruction data block and the electronic signature according to the complete data frame structure agreed upon by the target vehicle's communication protocol. It also adds the required content such as the data frame header, frame trailer, and checksum, ultimately forming an encrypted data frame corresponding to the vehicle control command.

[0124] Therefore, when constructing the data frame corresponding to the vehicle control command, the corresponding command data block is first assembled. Then, the hardware security module 40 encrypts the command data block based on the target vehicle's key to obtain an electronic signature for the command data block. Finally, the electronic signature and the command data block are encapsulated through a communication protocol to obtain the data frame, so that the data frame simultaneously contains core control information and an anti-counterfeiting electronic signature. Since the electronic signature is uniquely bound to the command data block, if the command data block is tampered with during transmission, the target vehicle will fail to verify the electronic signature and refuse to execute the command. Therefore, it can prevent the vehicle from performing incorrect operations due to forged or maliciously tampered vehicle control commands, thereby improving the safety of vehicle operation.

[0125] Furthermore, in this embodiment, the encryption operation is completed entirely within the hardware security module 40, rather than being calculated by other modules using the key stored within the hardware security module 40. This ensures that the key stored within the hardware security module 40 is not exposed in plaintext to the vehicle key's memory, external bus, or other modules. In other words, the key is stored entirely within the hardware security module 40 and not exposed to the outside, thus fundamentally preventing the risk of the key being cracked or copied.

[0126] For example, when a user selects vehicle A1, the target vehicle selected by the user is determined, and the instruction encoding table and communication protocol (such as CAN bus ID, baud rate, and data frame format) corresponding to the model of vehicle A1 are retrieved from the storage module 10.

[0127] Subsequently, the control module 30 also dynamically reconfigures the register configuration of the underlying CAN controller according to the loaded communication protocol to ensure that the physical layer communication is compatible with the target vehicle.

[0128] Furthermore, the control module 30 maps the vehicle control commands (such as "lock the car") input by the user to the corresponding proprietary source code (e.g., 0x0A), which is the standard code. After being encrypted by the hardware security module 40 to obtain an electronic signature, it is finally encapsulated into a data frame that conforms to the communication protocol.

[0129] In addition, before sending the data frame, the control module 30 can also perform dual verification of the integrity and authority of the vehicle control command. After confirming that there are no errors, the corresponding radio frequency module 20 is activated, and the transceiver such as the power amplifier sends the encapsulated data frame to the vehicle OBD-II interface (On-Board Diagnostics II, a standard interface for communication between the vehicle and external devices, often used for vehicle programming and parameter reading).

[0130] Throughout the process, the system can monitor the communication status with the vehicle and the vehicle's response in real time. If the expected confirmation response is not received, a retransmission mechanism can be triggered and the anomaly can be reported to the diagnostic log to ensure the reliability of vehicle control command execution and closed-loop control.

[0131] Continue by Figure 1 and combined Figure 2 As shown, in some exemplary embodiments, the vehicle key control method may further include the following steps S210-S230.

[0132] Step S210: Determine the usage priority of each authorized vehicle according to the preset determination method.

[0133] Specifically, the usage priority represents the probability of each authorized vehicle being used; the higher the usage probability, the higher the usage priority.

[0134] Step S220: Based on the usage priority of each authorized vehicle, determine the candidate vehicle and store the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the candidate vehicle in the cache of the vehicle key.

[0135] Specifically, the number of candidate vehicles can be a preset number, such as one, multiple, or determined based on the total number of authorized vehicles; there is no limitation here. For example, three vehicles can be selected as candidate vehicles.

[0136] More specifically, when determining the candidate vehicles, the vehicles can be selected in descending order of usage priority based on the usage priority of each authorized vehicle. For example, if there are three candidate vehicles, the three authorized vehicles with the highest usage priority will be selected as candidate vehicles.

[0137] The communication protocols, command encoding tables, and radio frequency configuration information of each candidate vehicle can then be pre-loaded and stored in the vehicle key's cache. This cache is a high-speed temporary storage module 10 (such as RAM) built into the vehicle key, and its read / write speed is typically much higher than that of a conventional storage module 10 (such as SPI Flash) in the vehicle key.

[0138] For example, for the top three priority candidate vehicles, the vehicle key control module 30 can retrieve the dedicated communication protocol corresponding to each candidate vehicle from the storage module 10, load it, and store it in the vehicle key's built-in cache. This dedicated communication protocol may include, for example, the modulation method corresponding to the 433MHz radio frequency band (such as Amplitude Shift Keying (ASK) or Frequency Shift Keying (FSK)), data frame structure, UUID (Universally Unique Identifier) ​​and encryption key corresponding to the BLE 5.2 communication protocol, pulse sequence parameters and TOF (Time of Flight) measurement parameters corresponding to the UWB 1.3 communication protocol, and ISO / IEC 15693 standard block address and authentication protocol corresponding to the NFC communication protocol.

[0139] In addition, the control module 30 can pre-allocate corresponding communication resources to the multiple radio frequency modules 20 built into the vehicle key according to the radio frequency configuration information. Specifically, it can allocate a primary communication channel (e.g., a UWB communication channel) for the radio frequency communication of the authorized vehicle with the highest priority, allocate a backup communication channel (e.g., a BLE 5.2 communication channel) for the radio frequency communication of the authorized vehicle with the second highest priority, and reserve an NFC communication channel as an emergency communication channel. The relevant information on these channel resource allocations is also loaded into the cache and stored in association with the alternative vehicles.

[0140] Step S230: If the determined target vehicle is a candidate vehicle, then obtain the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the target vehicle from the cache.

[0141] Specifically, if the target vehicle identified by the user is a candidate vehicle, the communication protocol, instruction encoding table, and radio frequency configuration information corresponding to the target vehicle can be directly obtained from the cache.

[0142] If the target vehicle determined by the user is not a candidate vehicle, the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the target vehicle will be retrieved from the storage module 10.

[0143] Therefore, in this embodiment, the usage priority of each authorized vehicle is first determined by a preset method. Based on the usage priority, candidate vehicles are determined, and the communication protocols, instruction encoding tables, and radio frequency configuration information corresponding to the candidate vehicles are pre-stored in the vehicle key's cache. When the determined target vehicle is a candidate vehicle, the configuration information corresponding to the target vehicle can be directly retrieved from the cache. That is, by using priority to initially filter out the candidate vehicles most likely to be used by the user, the relevant configuration information of these vehicles is pre-read and stored in the cache. The read / write speed of the cache is much higher than that of the vehicle key's storage module 10. Therefore, pre-loading the configuration information of the candidate vehicles into the cache in advance, instead of temporarily retrieving the configuration information from the storage module 10 after user operation, can shorten the time for obtaining configuration information, thereby shortening the overall time for data frame construction and transmission, and achieving rapid response from the vehicle key.

[0144] In addition, in some embodiments, when a user’s need for a vehicle is detected, the priority of each authorized vehicle is determined, and the configuration information of the alternative vehicles stored in the storage module 10 is preloaded and stored in the cache. Then, if the user triggers the key to perform the corresponding operation, it is directly determined whether the target vehicle selected by the user is an alternative vehicle. If the target vehicle selected by the user is an alternative vehicle, the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the target vehicle are directly obtained from the cache.

[0145] Specific methods for detecting a user's need for a vehicle may include: detecting whether the vehicle key is near at least one authorized vehicle, or detecting whether the user's dwell time within a preset range around any authorized vehicle exceeds a preset time threshold; or detecting whether the user triggers a vehicle status query operation during a preset travel period; or determining whether the current time and location conform to preset vehicle use behavior rules.

[0146] A user is determined to have a need for a vehicle when the vehicle key is near at least one authorized vehicle, or when the user stays within a preset range around any authorized vehicle for a period of time exceeding a preset time threshold, or when the user triggers a vehicle status query operation during a preset travel period, or when the current time and location meet preset vehicle use behavior rules.

[0147] Conversely, if the vehicle key is not near at least one authorized vehicle, and the user's dwell time within a preset range around any authorized vehicle does not exceed a preset time threshold, and the user does not trigger a vehicle status query operation during the preset travel period, and the current time and current location do not meet the preset vehicle use behavior rules, then it is determined that the user does not have a vehicle use need.

[0148] Specifically, the vehicle key has a built-in near-field detection module (integrating a BLE radio frequency unit and a UWB positioning unit). This module is in a low-power scanning state in real time, continuously detecting the wireless signals (BLE beacon signals and UWB positioning signals) emitted by authorized vehicles in the vicinity.

[0149] When a vehicle key detects that the BLE signal strength (RSSI) of an authorized vehicle is greater than a preset strength threshold (e.g., -75dBm), or when the distance between the vehicle key and the authorized vehicle is less than a preset distance threshold (e.g., 3m) as measured by the UWB positioning unit, it is determined that the vehicle key is close to the authorized vehicle.

[0150] Furthermore, the specific method for calculating the dwell time may include: when the vehicle key detects that it is within a preset range of an authorized vehicle (e.g., UWB distance <3m, BLE RSSI > -75dBm), the vehicle key's control module 30 immediately activates the timing module to start calculating the dwell time of the user (carrying the vehicle key) within this preset range. If the actual dwell time exceeds a preset threshold, it is determined that the user has a need to use the vehicle. This preset dwell time threshold can be customized by the user, such as 30 seconds.

[0151] Furthermore, the process for determining whether a user triggers a vehicle status query operation within a preset travel period includes: combining the synchronized data between the vehicle key and various applications on the user's terminal device, if it is detected that the user opens the vehicle control interface, queries the vehicle status (such as battery level and lock status), or starts navigation to the vehicle location during the travel period (such as morning and evening rush hours), it indicates that the user has triggered a vehicle status query operation within the preset travel period, and it is determined that the user has a need for vehicle use.

[0152] Furthermore, the process of determining whether the current time and location conform to the preset vehicle usage behavior rules can specifically include: based on the vehicle owner's historical habits, statistically analyzing the time periods and locations of vehicle usage. Specifically, if a vehicle owner uses the vehicle multiple times within a preset statistical period, and the number of uses reaches a preset threshold (frequent use), then that time period is determined to be a vehicle usage period. Alternatively, if a vehicle owner uses the vehicle multiple times at a single location within a preset statistical period (such as the most recent week or half a month), and the number of uses reaches the corresponding threshold (frequent use), then that location is determined to be a frequently used vehicle location.

[0153] If the current time is within the designated time period for vehicle use, or the current location is a frequently used location for vehicle use, then it indicates that the behavior conforms to the preset vehicle use rules.

[0154] This determines whether there is a current demand for vehicle use. If there is a demand for vehicle use, or if the current time is the priority update time (for example, with a daily cycle and a corresponding priority update time set in each cycle, such as the priority update time being 8:00 AM every day), the step S210 above, which determines the usage priority of each authorized vehicle according to a preset determination method, is executed.

[0155] Continue by Figure 1-2 and combined Figure 3 As shown, in step S210 above, the usage priority of each authorized vehicle is determined according to a preset determination method, which may specifically include the following steps S211-S213.

[0156] Step S211: Based on the stored vehicle information and usage records of each authorized vehicle, determine the feature values ​​and calculation weights of multiple preset priority evaluation features corresponding to each authorized vehicle.

[0157] Step S212: Calculate the priority score for each authorized vehicle based on the calculated weight and feature value corresponding to each preset priority evaluation feature.

[0158] Specifically, the vehicle key storage module 10 not only stores the configuration information of each authorized vehicle, but also the vehicle information and usage records of each authorized vehicle.

[0159] The vehicle information consists of basic attribute information of each authorized vehicle pre-stored in the vehicle key, such as vehicle brand, model, and factory configuration.

[0160] Vehicle usage records are real-time data recorded by the vehicle key on how users use each authorized vehicle, including usage time, number of uses, driving trajectory, and usage scenario.

[0161] In addition, the multiple preset priority evaluation features in step S211 may specifically include vehicle brand, usage frequency, usage scenario and historical habits.

[0162] The feature value of each preset priority evaluation feature represents the probability of a user selecting the corresponding authorized vehicle based on that feature alone. The higher the probability, the higher the feature value.

[0163] When determining usage priorities, multiple factors are considered, and a corresponding calculated weight is assigned to each preset priority evaluation feature. This calculated weight reflects the degree of influence of the preset priority evaluation feature on the usage priority. It is worth noting that the sum of the calculated weights of all preset priority evaluation features is 1. The calculated weights corresponding to each preset priority evaluation feature can be determined in advance based on expert experience or market research.

[0164] In this way, the feature values ​​of vehicle brand characteristics, usage frequency characteristics, usage scenario characteristics, and historical habit characteristics corresponding to each authorized vehicle are calculated separately. Then, in step S212, for each authorized vehicle, the corresponding priority score (reflecting the probability of being selected by the user) is calculated based on the calculation weight of each preset priority evaluation feature.

[0165] For example, consider a user who owns three vehicles: vehicle A1, vehicle A2, and vehicle A3.

[0166] From the perspective of vehicle brand, analyze the probability of vehicle A1 being selected by users and determine the feature value A11 of the vehicle brand feature of vehicle A1.

[0167] From the perspective of usage frequency, analyze the probability of vehicle A1 being selected by the user, and determine the feature value A12 of the usage frequency feature of vehicle A1.

[0168] From the perspective of usage scenarios, analyze the probability of vehicle A1 being selected by users and determine the feature value A13 of the usage scenario characteristics of vehicle A1.

[0169] From the perspective of historical habits, analyze the probability of vehicle A1 being selected by users and determine the feature value A14 of the historical habit characteristics of vehicle A1.

[0170] Then, based on the weights of each feature and the feature values ​​of each feature corresponding to vehicle A1, the priority score of vehicle A1 is calculated.

[0171] For other vehicles, their respective priority scores are calculated in a similar manner to those for vehicle A1, which will not be elaborated here.

[0172] The process of determining the feature value of a vehicle brand characteristic can specifically include: assigning a value based on market share and protocol complexity. Specifically, the feature value of the vehicle brand can be determined by setting a preset value corresponding to that vehicle brand. For example, the feature value of the vehicle brand characteristic corresponding to brand X is 1.2.

[0173] The process of determining the characteristic value of this usage frequency feature may specifically include: counting the number of times each authorized vehicle has been unlocked (or started) within a recent period. For each authorized vehicle, the characteristic value of its corresponding usage frequency feature is equal to the number of times that authorized vehicle has been unlocked divided by the total number of unlocks. The total number of unlocks is equal to the sum of the number of unlocks for all authorized vehicles.

[0174] The recent period can be, for example, the most recent preset statistical period, which can be, for example, one month.

[0175] The process of determining the feature value of this historical habit characteristic can specifically include: analyzing the driver's behavior sequence based on a machine learning model (such as a Hidden Markov Model, HMM) to identify the "frequently used vehicle-time-location" association pattern. If the analysis shows that the authorized vehicle was driven at a certain time according to historical habits, it indicates that the authorized vehicle has significant historical habit characteristics, and the feature value of this historical habit characteristic can be 1. If the analysis shows that the authorized vehicle has no corresponding driving habits, that is, the authorized vehicle has no significant historical habit characteristics, then the feature value can be 0.5. For example, if the pattern "driving vehicle A2 at 7:30 on a weekday" has occurred ≥15 times consecutively, then the feature value of this historical habit characteristic is equal to 1.0.

[0176] In some embodiments, refer to Figure 4 The feature values ​​of the above-mentioned usage scenario features can be determined through the following steps S2111-S2114.

[0177] Step S2111: Obtain multiple historical driving trajectories of the authorized vehicle.

[0178] Specifically, this example will be used to illustrate the process of determining the feature values ​​of the usage scenarios of other authorized vehicles. The process will not be elaborated here.

[0179] Specifically, in step S2111, multiple historical driving trajectories of the authorized vehicle can be obtained from the storage module 10 built into the vehicle key.

[0180] The storage module 10 built into the vehicle key stores the historical driving trajectories of each authorized vehicle within a preset trajectory statistics period (e.g., the last 30 days).

[0181] The historical driving trajectory is recorded as the vehicle key moves with the vehicle. Each historical driving trajectory is bound to the currently driven authorized vehicle and stored in the storage module 10. In this way, when determining the feature values ​​of the usage scenario characteristics of the authorized vehicle, the various historical driving trajectories corresponding to the authorized vehicle within the preset trajectory statistics period can be directly obtained from the storage module 10.

[0182] Step S2112: Determine the matching confidence between each historical driving trajectory and the preset multiple scene types.

[0183] Among them, the pre-set multiple scenario types are categories built into the vehicle key, targeting common user scenarios, such as commuting, long-distance travel, shopping, and leisure.

[0184] Specifically, in step S2112, for each historical driving trajectory, its core features (such as driving time, driving distance, locations passed through, speed changes, start and end points, duration, etc.) are extracted. Then, these core features are matched one by one with each preset scene type, and the matching confidence between each scene type is calculated.

[0185] The matching confidence score represents the degree of matching between the historical driving trajectory and the scene type. The higher the matching confidence score, the greater the probability that the historical driving trajectory belongs to that scene type.

[0186] More specifically, let's take the calculation of the matching confidence of one historical driving trajectory with each scene type as an example to illustrate this.

[0187] Based on the standard deviation of speed change, duration, type of POI (Point of Interest) passed through (key locations along the road, such as residences, companies, shopping malls, parking lots, gas stations, etc.), and time distribution characteristics corresponding to the historical driving trajectory, the matching confidence (range 0-1) with four scene types is calculated using the weighted Euclidean distance method. This matching confidence indicates the degree of similarity between the trajectory and a certain scene.

[0188] For example, a certain trajectory is characterized as follows: "During weekdays (Monday to Friday) morning and evening peak hours (6:00-9:00, 17:00-20:00), continuous driving distance ≤30km, the starting point and ending point of the route are located in residential areas and commercial / office areas respectively (based on POI database matching), and it repeatedly appears in the same date pattern (≥3 times / week)", which is highly matched with "commuting scenario". Its matching confidence score for commuting scenario is 0.85, the matching confidence score for shopping scenario is 0.1, the matching confidence score for leisure scenario is 0.05, and the matching confidence score for long-distance travel scenario is 0.02.

[0189] For example, if a single continuous driving distance is greater than 80km, takes more than 1.5 hours, occurs during off-peak hours, has no frequent stops along the route, and the origin and destination are not residential or office POIs (such as airports, scenic spots, or intercity hubs), then it is matched with long-distance scenarios.

[0190] The matching confidence can be calculated from the degree of consistency between trajectory features and scene type matching rules. The weighted Euclidean distance method is used to standardize dimensions such as speed, duration, POI matching, and time pattern and then sum them up.

[0191] Specifically, taking one of the historical driving trajectories as an example, based on the standard deviation of the speed change, duration, type of POI passed through, and time distribution characteristics of the historical driving trajectory, the four types of features are first normalized to unify their value range to the [0,1] interval, thus obtaining the trajectory feature vector T=[t1,t2,t3,t4] corresponding to the historical driving trajectory.

[0192] Subsequently, based on the contribution of each feature to scene discrimination, corresponding weight coefficients ω1 (corresponding to the standard deviation of speed change), ω2 (corresponding to duration), ω3 (corresponding to POI type similarity), and ω4 (corresponding to time distribution similarity) are set, satisfying ω1+ω2+ω3+ω4=1.

[0193] Next, for each scene type, a typical feature vector S_j = [s1_j, s2_j, s3_j, s4_j] is constructed, where s i _j is the reference mean of the i-th feature in the j-th scene type.

[0194] Then, using the trajectory feature vector T=[t1,t2,t3,t4] corresponding to this historical driving trajectory as a reference, calculate its weighted Euclidean distance with the scene vector S_j of each class: Finally, the weighted Euclidean distance is converted into a matching confidence score C_j = 1 / (1+D_j), ensuring that C_j ∈ [0,1]. The higher the value of C_j, the higher the similarity between the trajectory and the j-th type of scene.

[0195] Step S2113: Calculate the scene fit between the authorized vehicle and each scene type based on the matching confidence of each historical driving trajectory and each scene type.

[0196] Specifically, after determining the matching confidence level between each historical driving trajectory and each scenario type in step S2112, it is equivalent to determining the driving scenarios that the authorized vehicle has used in the past. Then, the scenario fit between the authorized vehicle and each scenario type can be determined.

[0197] The scene adaptability refers to the degree of matching between the authorized vehicle and each preset scene type. The higher the scene adaptability, the more likely the authorized vehicle is to be selected and used in the corresponding scene.

[0198] More specifically, in step S2113, for each scenario type, the scenario compatibility between the scenario type and the authorized vehicle is calculated based on all historical driving trajectories.

[0199] The following explanation uses the scenario adaptation calculation process for one scenario type (e.g., commuting scenario type) as an example. For instance, each scenario type has a corresponding baseline weight. The baseline weight is multiplied by the matching confidence of the historical driving trajectory with that scenario type to obtain the contribution of that historical driving trajectory to that scenario type.

[0200] The baseline weights are pre-set. More specifically, the baseline weights are determined based on the relative impact of each scenario on resource consumption, traffic pressure, or user demand, through a comprehensive analysis of historical data, behavioral data, and expert evaluation. For example, commuting scenarios, due to their high frequency and concentrated time period, are assigned a baseline weight of 1.0; shopping scenarios, while exhibiting some crowd gathering, have a more dispersed time period, hence the baseline weight is set at 0.8; leisure scenarios are typically non-essential with lower traffic volume, so the baseline weight is set at 0.6; and long-distance travel, due to its longer duration and higher resource consumption, has its baseline weight increased to 1.2. Furthermore, the baseline weights can be dynamically adjusted according to external factors. For instance, during holidays, commuting demand decreases while tourism increases, so the commuting weight is lowered to 0.7, and the long-distance weight is correspondingly increased to 0.9 to reflect changes in actual scenario priority.

[0201] Furthermore, after obtaining the contribution of each historical driving trajectory and scenario type, the driving time percentage of each historical driving trajectory is calculated (the driving time of this historical driving trajectory accounts for the total driving time of all historical driving trajectories of this vehicle).

[0202] Then, based on the proportion of driving time and the contribution obtained by multiplying the confidence of each historical driving trajectory with the scenario type by the baseline weight, a weighted average is performed to obtain the scenario fit of the authorized vehicle with the scenario type.

[0203] For example, assuming authorized vehicle A1 has three historical driving trajectories, when calculating the scenario adaptability of the commuting scenario type, the contribution of the historical driving trajectory to the commuting scenario type is multiplied by the proportion of the driving time of that historical driving trajectory, thus obtaining a product for each historical driving trajectory. Then, the average of the products is calculated, and this average value is equivalent to the scenario adaptability of authorized vehicle A1 to the commuting scenario type.

[0204] Calculate the scenario compatibility of each of the other authorized vehicles with this commuting scenario type in the same way as authorized vehicle A1.

[0205] Furthermore, for other scenario types, the scenario fit degree between each authorized vehicle and each scenario type is calculated in the same way as for the commuting scenario type. After calculating the scenario fit degree between each authorized vehicle and each scenario type, step S2114 can be executed to determine the feature value of the usage scenario feature corresponding to each authorized vehicle.

[0206] Step S2114: Predict the scenario type of the authorized vehicle's matching usage scenario at the current time according to preset rules, and use the scenario adaptability corresponding to the scenario type as the feature value of the usage scenario feature corresponding to the authorized vehicle.

[0207] Specifically, in step S2114, when predicting the scenario type of the current time matching the usage scenario according to the preset rules, the scenario type of the current time matching the usage scenario can be determined according to the preset time scenario type mapping relationship.

[0208] More specifically, this preset time-scene type mapping relationship can be obtained in advance based on statistical analysis of users' vehicle usage data. This preset time-scene type mapping relationship includes the scene type corresponding to each time. For example, weekday mornings usually correspond to commuting scene type, weekend mornings usually correspond to leisure scene type, weekend afternoons usually correspond to shopping scene type, and holidays usually correspond to long-distance travel scene type.

[0209] In addition, after determining the scenario type of the current time-matched usage scenario, the feature value of the usage scenario feature corresponding to each authorized vehicle can be determined based on the scenario type of the current time-matched usage scenario and the scenario adaptability of each authorized vehicle.

[0210] For example, if the current time-matched usage scenario is a commuting scenario, and the matching degree between authorized vehicle A1 and the commuting scenario is 0.7, then the feature value of the usage scenario feature corresponding to authorized vehicle A1 is 0.7.

[0211] Using the same method, the feature values ​​of the usage scenario characteristics corresponding to each authorized vehicle can be determined separately.

[0212] The process of determining the feature values ​​for usage scenario characteristics is described using an example. For instance, if a user owns 3 cars (CarA, CarB, and CarC), and each car has 3 driving trajectories in the past week (a total of 9 trajectories), then 4 scenario types are predefined: commuting scenario type, shopping scenario type, leisure scenario type, and long-distance travel scenario type, with the following baseline weights: commuting scenario type: 1.0; shopping scenario type: 0.8; leisure scenario type: 0.6; long-distance travel scenario type: 1.2.

[0213] Next, the scene matching score for each trajectory is calculated. For each trajectory, the matching confidence score with the four scene types is output. For example, for a trajectory of CarA, the calculated matching confidence scores are as follows: commuting scene matching confidence score = 0.85; shopping scene matching confidence score = 0.10; leisure scene matching confidence score = 0.05; long-distance travel scene matching confidence score = 0.02.

[0214] Then, the confidence score of the scenario type matching of the trajectory is multiplied by the corresponding baseline weight to obtain the contribution of the trajectory to each scenario type: the contribution S commute to the commuting scenario type is 0.85×1.0=0.85; the contribution S_shopping to the shopping scenario type is S=0.10×0.8=0.08.

[0215] Similarly, each trajectory generates a four-dimensional vector: [S_commute, S_shopping, S_leisure (contribution corresponding to the leisure scene type), S_longhaul (contribution corresponding to the long-distance travel scene type)].

[0216] Next, a weighted average of all trajectory contributions for each vehicle is calculated (weighted by the proportion of trajectory duration) to obtain the scene adaptability of that vehicle to each scene type. Assuming the travel time proportions of CarA's three trajectories are 40%, 35%, and 25% respectively, the scene adaptability of CarA to each scene type is:

[0217] Commuting: 0.85×0.4+0.60×0.35+0.20×0.25=0.56.

[0218] Shopping: 0.10×0.4+0.70×0.35+0.30×0.25=0.36.

[0219] Leisure: 0.05×0.4+0.15×0.35+0.50×0.25 =0.20.

[0220] Long distance: 0.02×0.4+0.05×0.35+0.80×0.25 =0.23.

[0221] That is, the scene compatibility of CarA with each scene type is as follows: [0.56, 0.36, 0.20, 0.23].

[0222] If it is determined that the current user intends to perform a commuting scenario, then the feature value of the usage scenario feature corresponding to each authorized vehicle is the scenario fit degree corresponding to that commuting scenario. For example, the feature value of the usage scenario feature of CarA is 0.56.

[0223] Thus, through steps S2111-S2114, the scenario fit is calculated using historical driving trajectories and matching confidence scores. This, combined with the current time, is used to predict the scenario and determine the usage scenario feature values. Because historical driving trajectories accurately reflect the actual usage scenarios of authorized vehicles, matching confidence scores quantify the similarity between a single trajectory and a scenario type, and scenario fit comprehensively reflects the overall matching status of authorized vehicles with various scenario types, combined with the current time to predict the user's current driving scenario, the feature values ​​of the usage scenario characteristics better align with the user's current driving needs. This improves the accuracy of priority score calculation, allowing the usage priority ranking to better reflect the user's actual driving habits.

[0224] Based on step S211 above, the feature values ​​corresponding to each preset priority evaluation feature for each authorized vehicle can be determined. Then, step S212 is executed to calculate the priority score for each authorized vehicle.

[0225] Taking an authorized vehicle as an example, the specific process of calculating the priority score corresponding to the authorized vehicle based on the feature values ​​and calculation weights of each preset priority evaluation feature can include: calculating the product of the feature value of each preset priority evaluation feature corresponding to the authorized vehicle and its corresponding calculation weight. The products corresponding to each preset priority evaluation feature are then summed to obtain the priority score corresponding to the authorized vehicle. The same principle applies to other authorized vehicles, and will not be elaborated further here.

[0226] More specifically, the formula for calculating this priority score is: Priority_i = α × Bi + β × Fi + γ × Si + δ × Hi.

[0227] Where Priority_i is the priority score of the i-th vehicle, α is the calculated weight of the vehicle brand, β is the calculated weight of the usage frequency, γ is the calculated weight of the usage scenario, δ is the calculated weight of historical habits, Bi is the feature value of the vehicle brand feature of the i-th vehicle, Fi is the feature value of the usage frequency feature of the i-th vehicle, Si is the feature value of the usage scenario feature of the i-th vehicle, and Hi is the feature value of the historical habits feature of the i-th vehicle.

[0228] Taking one of the authorized vehicles (e.g., vehicle A1) as an example, the feature value of the vehicle brand characteristic corresponding to vehicle A1 is multiplied by the calculation weight of the vehicle brand; the feature value of the usage frequency characteristic corresponding to vehicle A1 is multiplied by the calculation weight of the usage frequency; the feature value of the usage scenario characteristic corresponding to vehicle A1 is multiplied by the calculation weight of the usage scenario; the feature value of the historical habit characteristic corresponding to vehicle A1 is multiplied by the calculation weight of the historical habit; then, the sum of each product is obtained to obtain the priority score corresponding to the authorized vehicle.

[0229] For other authorized vehicles, the calculation method for priority score of vehicle A1 can be referred to separately, which will not be elaborated here.

[0230] In this way, by calculating the priority score of each authorized vehicle based on the weights and feature values ​​corresponding to each preset priority evaluation feature, the error caused by the direct superposition of multi-dimensional data can be avoided, thereby improving the accuracy of priority score calculation and ensuring the rationality of priority ranking.

[0231] After determining the priority score corresponding to each authorized vehicle according to steps S211 and S212, step S213 can be executed to determine the usage priority of each authorized vehicle based on the priority score.

[0232] Step S213: Determine the usage priority of each authorized vehicle based on the priority score.

[0233] Specifically, the usage priority of each authorized vehicle can be determined by using a method where the higher the priority score, the higher the priority.

[0234] Thus, through the above steps S211-S213, the vehicle brand, usage frequency, usage scenario, and historical habits are determined by vehicle information and usage records, and the characteristic values ​​and calculation weights are calculated. Then, the priority score is calculated to determine the usage priority. In the process of determining the usage priority, multiple preset priority evaluation features are considered, thereby avoiding the one-sidedness of single-dimensional ranking and improving the accuracy of determining the usage priority.

[0235] Continue by Figure 1-4 After determining the usage priority of each authorized vehicle, not only can alternative vehicles be identified and their corresponding configuration information be loaded into the vehicle key's cache, but in other exemplary implementations, the vehicle selection knob in the vehicle key can also be controlled in advance to reduce the number of manual adjustment steps in the vehicle selection operation, thereby improving the convenience and response efficiency of the vehicle selection operation.

[0236] The vehicle selection knob is a physical rotary knob located on the vehicle key. It has multiple fixed positions, each corresponding to an authorized vehicle, allowing the user to select their target vehicle from among these authorized options. The knob is driven by a rotating mechanism, which can consist of a stepper motor, transmission gears, and may also include a limit sensor. The limit sensor detects the position, and the stepper motor and transmission gears then drive the knob to rotate to the designated position.

[0237] That is, the vehicle key control method may also include: driving the vehicle selection knob to rotate through a rotating mechanism, so that the vehicle selection button points to the gear corresponding to the authorized vehicle with the highest priority.

[0238] Alternatively, when the priority score of the highest-priority authorized vehicle is close to that of the second-highest-priority authorized vehicle, a rotating mechanism can be used to rotate the vehicle selection knob, causing the selection button to point to a position between the gear corresponding to the highest-priority authorized vehicle and the gear corresponding to the second-highest-priority authorized vehicle.

[0239] Specifically, after determining the usage priority of each authorized vehicle, the vehicle with the highest usage priority (hereinafter referred to as the highest priority vehicle) and the vehicle with the second highest usage priority (hereinafter referred to as the second highest priority vehicle) are extracted.

[0240] Next, the difference in priority scores between the two vehicles is calculated; this difference in priority scores is then compared with a preset difference threshold.

[0241] When the difference in priority scores is greater than the preset difference threshold, it means that the priority score of the highest priority vehicle is significantly higher than that of the second highest priority vehicle. At this time, the vehicle selection knob can be rotated by the rotating mechanism to make the vehicle selection button point to the gear corresponding to the authorized vehicle with the highest priority, so that the vehicle selection knob automatically returns to the gear corresponding to the highest priority vehicle.

[0242] Correspondingly, when the difference in priority scores is less than or equal to the preset difference threshold, it means that the priority score of the highest priority vehicle is close to that of the second highest priority vehicle. At this time, the vehicle selection knob can be rotated by the rotating mechanism so that the vehicle selection button points to the position between the gear corresponding to the highest priority authorized vehicle and the gear corresponding to the second highest priority authorized vehicle. In other words, the vehicle selection knob is adjusted to the transition position between the highest priority vehicle and the second highest priority vehicle.

[0243] It is worth noting that if the highest priority vehicle and the second highest priority vehicle are in adjacent gears, you can directly set the vehicle selection knob to the gear corresponding to the highest priority vehicle.

[0244] In this way, since the vehicle with the highest priority is the vehicle that the user is most likely to use, adjusting the vehicle selection knob to the highest priority vehicle can more likely directly select the vehicle that the user actually wants to drive. This way, the user does not need to rotate the vehicle selection knob to select a vehicle, but can directly trigger the control operation, thereby saving operation time and improving user convenience.

[0245] In addition, when the priority score of the authorized vehicle with the highest priority is similar to that of the authorized vehicle with the second highest priority, the vehicle selection button is positioned between the corresponding gears of the two. This allows users to select the corresponding vehicle by simply rotating the button to either side, thereby reducing the number of manual rotation steps and ultimately improving the convenience of the vehicle selection operation and the user experience.

[0246] In addition, in some other exemplary embodiments, for vehicle keys that allow selection of target vehicles via a display screen, after determining the usage priority of each authorized vehicle, the authorized vehicles can be displayed on the display screen on the vehicle key in a preset order.

[0247] The preset order is determined at least according to the usage priority of each authorized vehicle.

[0248] Specifically, the display screen is a touch-screen display. Authorized vehicles can be presented on the display screen in various formats, such as list, icon, or card displays, allowing users to select a target vehicle via the vehicle icons displayed on the touchscreen.

[0249] More specifically, after determining the usage priority of each authorized vehicle, the vehicle key control module 30 extracts the usage priority ranking of each authorized vehicle.

[0250] In one possible implementation, authorized vehicles can be displayed on the screen in a preset order, from highest to lowest priority.

[0251] In another possible implementation, the core sorting rule can be to rank authorized vehicles by priority from highest to lowest. If there are authorized vehicles with similar priority scores, the current location of the vehicle key or the frequency of vehicle use can be further considered to determine a preset order for these vehicles with the same or similar priority. For example, for two authorized vehicles with the same priority, the one with higher usage frequency would be ranked higher.

[0252] When displaying authorized vehicles on the screen in a preset order, the specific method can be to sort the preset positions on the screen where vehicle icons are placed for users to select vehicles in descending order of visibility.

[0253] Then, following a preset order from front to back, the system matches each position sequentially to determine the display area for each authorized vehicle (and its corresponding icon) on the screen. This ensures that the vehicle most likely to be used by the user is prominently displayed on the screen.

[0254] In other implementations, the display screen can also show authorized vehicle icons in the following ways: frequently used authorized vehicles are placed at the top, recently used authorized vehicles are placed at the front, and authorized vehicles with high usage priority are highlighted. The display screen supports touch swiping and quick clicks, and can also enhance visual recognition by incorporating color coding of vehicle icons (e.g., green = available, blue = reserved, gray = offline), allowing users to quickly identify and select the target vehicle.

[0255] Thus, by displaying all authorized vehicles directly on the car key screen and allowing users to select their target vehicle, a visual method of vehicle selection is provided, which is more intuitive and easier to understand than physical operation. Furthermore, after determining the usage priority of each authorized vehicle, they are displayed on the screen in a preset order determined by that priority. Vehicles with higher usage priority are the ones the user is most likely to use, and can be prominently displayed in this order, allowing users to quickly find and select their target vehicle, thereby reducing the steps and time required for vehicle selection.

[0256] It is worth noting that, regarding the vehicle key control method of this embodiment, based on the above exemplary implementations, in specific implementation, as a preferred embodiment, it is still based on... Figure 1-4 As shown, it may include, for example:

[0257] The binding and authentication of each authorized vehicle and the vehicle key are completed in advance, and the configuration information of each authorized vehicle is pre-stored in the storage module 10 of the vehicle key.

[0258] When a user uses the vehicle key, the priority score of each authorized vehicle can be calculated and the usage priority of each authorized vehicle can be determined if a usage priority update is triggered. Then, candidate vehicles are selected based on the usage priority of each authorized vehicle, and the configuration information of the candidate vehicles is pre-stored in the vehicle key's cache.

[0259] Then, when the user operates the vehicle key, the target vehicle is identified from multiple authorized vehicles, and the vehicle control command triggered by the user is determined.

[0260] If the target vehicle triggered by the user is one of the aforementioned candidate vehicles, the configuration information for that target vehicle can be directly retrieved from the cache without needing to retrieve it from the storage module 10, thus improving the speed of configuration retrieval. However, if the target vehicle triggered by the user is not one of the aforementioned candidate vehicles, the configuration information corresponding to that target vehicle is retrieved from the vehicle key storage module 10. Furthermore, after completing control operations such as unlocking the vehicle, the current usage record of that target vehicle can be updated to the storage module 10, triggering a recalculation of the usage priority of each authorized vehicle, and synchronously updating the configuration information in both the candidate vehicles and the cache, thereby improving the hit rate of subsequent preloading.

[0261] Then, based on the configuration information, the instruction data block corresponding to the vehicle control command is constructed, and encryption authentication is completed through the hardware security module 40 to obtain an electronic signature. The instruction data block and electronic signature are then encapsulated according to the corresponding communication protocol to obtain a data frame.

[0262] Then, a target radio frequency module that matches the target vehicle is identified, and a data frame is sent to the target vehicle. After receiving the data frame, the target vehicle can identify the corresponding vehicle control command, execute the corresponding control operation, and realize the control of the target vehicle.

[0263] Correspondingly, other authorized vehicles can be controlled in the same way, thus enabling a single physical key to be compatible with different brands and models of vehicles.

[0264] In the preferred embodiment of the above vehicle control method, the specific implementation means of each step can still be referred to the descriptions in the above exemplary embodiments, and the beneficial effects brought about by the design of each step in this preferred embodiment can also be referred to the descriptions in the above exemplary embodiments, and will not be repeated here.

[0265] The vehicle key control method in this embodiment adopts the above design, which enables the control of vehicles of different brands and models through a single physical key. This eliminates the need for users to search for a dedicated vehicle key and manage multiple physical keys, thereby improving the convenience of vehicle use.

[0266] An embodiment of the second aspect of this application provides a vehicle key, combined with Figure 5 As shown, the vehicle key includes a storage module 10, an radio frequency module 20, and a control module 30.

[0267] The storage module 10 stores configuration information for multiple authorized vehicles. Multiple radio frequency (RF) modules 20 are configured to correspond one-to-one with each authorized vehicle, and each RF module 20 is used to send RF signals to its corresponding authorized vehicle. The control module 30 can execute the aforementioned vehicle key control method when the user operates the vehicle key.

[0268] Specifically, in the implementation of the vehicle key of this embodiment, the above-mentioned modules can be existing module products with data transmission, storage or computing functions.

[0269] Similarly, the configuration information may include communication protocols, instruction encoding tables, and radio frequency configuration information. Furthermore, the vehicle key in this embodiment may also include a hardware security module 40, which stores keys corresponding to each authorized vehicle.

[0270] In addition, in specific applications, the specific implementation process of the control function of the above-mentioned control module 30 under the cooperation of the storage module 10, each radio frequency module 20, and the hardware security module 40 can be found in the relevant description in the above method embodiments, and will not be repeated here.

[0271] The vehicle key in this embodiment allows control of different brands and models of vehicles with a single physical key. This eliminates the need for users to search for individual vehicle keys and manage multiple physical keys, thereby improving user convenience.

[0272] An embodiment of the third aspect of this application provides a vehicle equipped with the aforementioned vehicle key.

[0273] The vehicle key configured in this embodiment, by executing the vehicle key control method in the above method embodiment, can enable one vehicle key to control vehicles of different brands and models. Thus, when using the vehicle, the user does not need to search for a dedicated vehicle key and does not need to manage multiple physical keys, thereby improving the user's vehicle use convenience.

[0274] The above descriptions are merely some embodiments of this application and are not intended to limit this application. The technical features or structures in the foregoing different embodiments can be arbitrarily combined to form other specific technical solutions as needed. For those skilled in the art, this application can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of the claims of this application.

Claims

1. A vehicle key control method, characterized in that, The method includes: In response to the user's operation on the vehicle key, the target vehicle is determined from among the multiple authorized vehicles configured on the vehicle key; The configuration information corresponding to the target vehicle and the vehicle control command triggered by the user are obtained. The configuration information includes communication protocol, command encoding table and radio frequency configuration information. Based on the communication protocol and the instruction encoding table, a data frame corresponding to the vehicle control instruction is constructed, and based on the radio frequency configuration information, a target radio frequency module matching the target vehicle is determined. The target radio frequency module sends the data frame to the target vehicle to control the target vehicle.

2. The vehicle key control method according to claim 1, characterized in that, The vehicle key includes a hardware security module (40), which stores the key corresponding to each authorized vehicle. The step of constructing the data frame corresponding to the vehicle control command according to the communication protocol and the command encoding table includes: According to the communication protocol and the instruction encoding table, assemble the instruction data block corresponding to the vehicle control instruction; The hardware security module (40) performs encryption operations based on the key corresponding to the target vehicle and the instruction data block to obtain the electronic signature corresponding to the instruction data block; According to the communication protocol, the electronic signature and the instruction data block are encapsulated to obtain the data frame.

3. The vehicle key control method according to claim 2, characterized in that, The method also includes: The usage priority of each authorized vehicle is determined according to a preset determination method; Based on the usage priority of each authorized vehicle, a candidate vehicle is determined, and the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the candidate vehicle are stored in the cache of the vehicle key. If the target vehicle is determined to be the candidate vehicle, the communication protocol, instruction encoding table and radio frequency configuration information corresponding to the target vehicle are obtained from the cache.

4. The vehicle key control method according to claim 3, characterized in that, The step of determining the usage priority of each authorized vehicle according to a preset determination method includes: Based on the stored vehicle information and usage records of each authorized vehicle, determine the feature values ​​and calculation weights of multiple preset priority evaluation features corresponding to each authorized vehicle; Based on the calculated weights and feature values ​​corresponding to each of the preset priority evaluation features, the priority scores corresponding to each authorized vehicle are calculated respectively. The usage priority of each authorized vehicle is determined based on the priority score. Among them, several of the preset priority evaluation features include vehicle brand, usage frequency, usage scenario, and historical habits.

5. The vehicle key control method according to claim 4, characterized in that, The feature values ​​of the usage scenario characteristics corresponding to the authorized vehicle are determined in the following way: Obtain multiple historical driving trajectories of the authorized vehicle; Determine the matching confidence level between each historical driving trajectory and multiple preset scene types; Based on the matching confidence of each historical driving trajectory with each of the scene types, calculate the scene fit between the authorized vehicle and each of the scene types; The scenario type of the authorized vehicle in the current time is predicted according to a preset rule, and the scenario adaptability corresponding to the scenario type is used as the feature value of the usage scenario feature corresponding to the authorized vehicle.

6. The vehicle key control method according to claim 4, characterized in that, The step of calculating the priority score for each authorized vehicle based on the calculated weights and feature values ​​corresponding to each of the preset priority evaluation features includes: Calculate the product of the calculated weight and the feature value corresponding to each of the preset priority evaluation features; The priority score for each authorized vehicle is obtained by summing the products corresponding to each preset priority evaluation feature.

7. The vehicle key control method according to claim 3, characterized in that, The vehicle key includes a vehicle selection knob that can be rotated by a rotating mechanism. The vehicle selection knob is used by the user to select the target vehicle from among the authorized vehicles. After determining the usage priority of each authorized vehicle, the method further includes: The rotating mechanism drives the vehicle selection knob to rotate, causing the selection button to point to the gear corresponding to the authorized vehicle with the highest priority; or... When the priority score of the authorized vehicle with the highest priority is close to that of the authorized vehicle with the second highest priority, the vehicle selection knob is rotated by the rotating mechanism, so that the vehicle selection button points to a position between the gear corresponding to the authorized vehicle with the highest priority and the gear corresponding to the authorized vehicle with the second highest priority.

8. The vehicle key control method according to claim 3, characterized in that, The vehicle key includes a display screen for displaying the authorized vehicles and allowing the user to select a target vehicle. After determining the usage priority of each authorized vehicle, the method further includes: The authorized vehicles are displayed on the screen in a preset order; The preset order is determined at least according to the usage priority of each authorized vehicle.

9. A vehicle key, characterized in that: It includes a storage module (10), a radio frequency module (20), and a control module (30); The storage module (10) stores configuration information for multiple authorized vehicles; The radio frequency module (20) is a plurality of modules that correspond one-to-one with each of the authorized vehicles, and each radio frequency module (20) is used to send radio frequency signals to the corresponding authorized vehicle; When the user operates the vehicle key, the control module (30) can execute the vehicle key control method according to any one of claims 1-8.

10. A vehicle, characterized in that: The vehicle is equipped with the vehicle key as described in claim 9.

Images