Token management vehicle control method and device based on cloud desktop signaling service

Abstract

The invention provides a Token management vehicle control method and device based on a cloud desktop signaling service, and relates to the technical field of Token-based vehicle control, and the method comprises the steps: based on the priority of a remote control service of a remote control user corresponding to a current driving user and the priority of a current vehicle networking service of the current driving user, carrying out the remote control service of a remote control user corresponding to the current driving user; the Token validity periods of the remote control service and the current Internet of Vehicles service are dynamically adjusted respectively; managing a Token value of each vehicle-mounted device based on a Token request sent by each vehicle-mounted device in the remote control service and the current Internet of Vehicles service and a device identifier corresponding to each vehicle-mounted device; switching the abnormal Token verification node to the optimal verification node; and issuing the Token value generated by encrypting the hardware features of the current vehicle to the vehicle-mounted terminal, so that the vehicle-mounted terminal controls the remote control service of the current vehicle and the current Internet of Vehicles service, and the technical problem of poor vehicle driving safety is relieved.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle control based on Token, and in particular, to a method and device for managing vehicle control based on Token of cloud desktop signaling service. Background Art

[0002] With the development of vehicle technology, more and more people adopt the transportation mode of traveling by vehicle; however, when most people just learn to drive a vehicle, it is inevitable that there is a great psychological pressure in some occasions that require independent driving of the vehicle, and even the probability of certain vehicle accidents during travel will be increased.

[0003] For such novice drivers, while they are driving a vehicle to travel, family and friends with sufficient driving experience can remotely control the vehicle in necessary situations to ensure the driving safety of novice drivers; currently, the Token management of cloud desktop signaling service mainly relies on static Token or simple time validity control, which cannot meet the application requirements of the above scenarios, and has poor effects in terms of flexibility, security, real-time performance and multi-terminal collaboration, thus affecting the driving safety of remotely controlling the vehicle at necessary moments. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a method and device for managing vehicle control based on Token of cloud desktop signaling service, and through intelligent Token management of cloud desktop signaling service, alleviate the technical problem of poor driving safety of remotely controlling a vehicle.

[0005] In the first aspect, the present invention provides a method for managing vehicle control based on Token of cloud desktop signaling service, including:

[0006] Respond to a control instruction issued by the current driving user for the in-vehicle terminal, and establish a connection with the in-vehicle terminal;

[0007] Based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current vehicle networking service of the current driving user, respectively dynamically adjust the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service; wherein, the first priority is higher than the second priority; the second priority includes multiple types; the first Token validity period is shorter than the second Token validity period;

[0008] Based on the Token requests issued for each in-vehicle device in the remote control service and the current vehicle networking service, and the device identifier corresponding to each in-vehicle device, calculate the Token hash identifier of each in-vehicle device, and manage the Token value of each in-vehicle device;

[0009] Monitor each Token verification node in real time, and switch the Token verification node with anomalies to the optimal verification node;

[0010] Generate a Token value encrypted based on the hardware characteristics of the current vehicle, and then send it to the in-vehicle terminal, so that the in-vehicle terminal controls the remote control service and the current vehicle networking service of the current vehicle.

[0011] In an alternative embodiment, the steps of dynamically adjusting the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current vehicle networking service of the current driving user include:

[0012] Determine the first priority of the remote control service and the second priority of the current vehicle networking service based on the importance of the remote control service of the remote control user corresponding to the current driving user and the importance of the current vehicle networking service of the current driving user;

[0013] Allocate corresponding service weights to the remote control service and the current vehicle networking service based on the first priority and the second priority;

[0014] Determine the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service according to the service weights, historical connection frequencies, and preset load parameters.

[0015] In an alternative embodiment, the steps of calculating the Token hash identifier of each in-vehicle device based on the Token requests sent by each in-vehicle device for the remote control service and the current vehicle networking service, and the device identifier corresponding to each in-vehicle device, and managing the Token value of each in-vehicle device include:

[0016] Calculate the Token hash identifier of each in-vehicle device based on the device identifier and the current Token value corresponding to each in-vehicle device for the remote control service and the current vehicle networking service;

[0017] Verify the Token value sent by each in-vehicle device based on the Token hash identifier and the first Token request sent by each in-vehicle device;

[0018] Refresh the Token value sent by each in-vehicle device based on the Token hash identifier and the second Token request sent by each in-vehicle device.

[0019] In an alternative embodiment, the step of verifying the Token value sent by each vehicle-mounted device based on the Token hash identifier and the first Token request sent by each vehicle-mounted device includes:

[0020] In response to the first Token request sent by each vehicle-mounted device, as well as the Token hash identifier and the current Token value of each vehicle-mounted device, look up the corresponding mapping relationship in the hash table;

[0021] If the lookup is successful, the device identifier and the current Token value of the current vehicle-mounted device are successfully verified;

[0022] If the lookup fails, invalidate or expire the current Token value of the current vehicle-mounted device and return it to the vehicle terminal, so that the current vehicle-mounted device sends a second Token request.

[0023] In an alternative embodiment, the step of refreshing the Token value sent by each vehicle-mounted device based on the Token hash identifier and the second Token request sent by each vehicle-mounted device includes:

[0024] When multiple vehicle-mounted devices in the remote control service simultaneously send a second Token request when the first Token validity period expires, based on the second Token request sent by the first-arriving target vehicle-mounted device, generate a new Token value corresponding to the target vehicle-mounted device;

[0025] According to the device identifier of the target vehicle-mounted device, the new Token value, the latest version number corresponding to the new Token value, and the current timestamp, update the mapping relationship stored in the hash table;

[0026] Send a Token value change notification to each vehicle-mounted device of the vehicle terminal, so that each vehicle-mounted device with a different current version number and the latest version number sends a second Token request.

[0027] In an alternative embodiment, the step of performing real-time monitoring on each Token verification node and switching the abnormal Token verification node to the optimal verification node includes:

[0028] Perform real-time monitoring on the status of each Token verification node;

[0029] If any Token verification node fails or has a network delay, determine the optimal verification node based on the network delay and node load weight of the abnormal Token verification node, as well as the physical distance between the current vehicle and the abnormal Token verification node;

[0030] Switch the abnormal Token verification node to the optimal verification node, and then perform the step of verifying the Token values sent by each vehicle-mounted device.

[0031] In an alternative embodiment, the step of encrypting and generating a Token value based on the hardware characteristics of the current vehicle includes:

[0032] Process the security chip characteristics of the current vehicle through a physically unclonable function to obtain the hardware characteristics of the current vehicle;

[0033] Input the Token value and the hardware characteristics into an encryption function, and output the dynamically encrypted Token value of the current vehicle.

[0034] In a second aspect, the present invention provides a vehicle control device based on cloud desktop signaling service Token management, including:

[0035] A connection module, in response to a control instruction issued by the current driving user for the vehicle-mounted terminal, establishes a connection with the vehicle-mounted terminal;

[0036] A Token lifecycle management module, based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current vehicle networking service of the current driving user, respectively dynamically adjusts the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service; wherein, the first priority is higher than the second priority; the second priority includes multiple types; the first Token validity period is shorter than the second Token validity period;

[0037] A Token management module, based on the Token requests sent by each vehicle-mounted device for the remote control service and the current vehicle networking service, and the device identifier corresponding to each vehicle-mounted device, calculates the Token hash identifier of each vehicle-mounted device and manages the Token value of each vehicle-mounted device;

[0038] A node detection module, monitors each Token verification node in real time, and switches the abnormal Token verification node to the optimal verification node;

[0039] An encryption control module, encrypts and generates a Token value based on the hardware characteristics of the current vehicle, and then issues it to the vehicle-mounted terminal, so that the vehicle-mounted terminal controls the remote control service and the current vehicle networking service of the current vehicle.

[0040] In a third aspect, the present invention provides an electronic device, including a memory and a processor. A computer program that can run on the processor is stored in the memory. When the processor executes the computer program, the steps of the method according to any one of the foregoing embodiments are implemented.

[0041] In a fourth aspect, the present invention provides a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions cause the processor to implement the steps of the method according to any one of the foregoing embodiments.

[0042] A Token management vehicle control method and device based on a cloud desktop signaling service provided by an embodiment of the present invention. First, the life cycle of a Token is dynamically adjusted according to service priorities. The life cycle of the Token is shortened for high-priority services (such as remote control and emergency calls) to improve their response speed, and at the same time, the life cycle of the Token for low-priority services (such as navigation and entertainment) is extended to optimize system resources. Secondly, a Token binding and management mechanism based on device identifiers (device ID) for multiple in-vehicle devices allows multiple in-vehicle devices to share a Token during concurrent requests. The Token value synchronization between multiple in-vehicle devices is achieved through the hash mapping of the device identifier and the Token, avoiding Token verification conflicts during concurrent access by multiple in-vehicle devices. And, multiple Token verification nodes are deployed in the cloud desktop system, and the optimal node is selected for Token verification. Through the optimal node selection algorithm, it is ensured that the vehicle establishes a connection with the nearest node, reducing the network delay during the Token verification process and improving the real-time response of critical tasks. In addition, combined with the hardware characteristics of the in-vehicle terminal, a unique encryption factor is generated for the encryption and authentication of the Token, realizing dynamic encryption. A unique encryption parameter is generated for each Token request to prevent replay attacks and Token forgery, and thus ensuring that the token value issued based on the above steps can achieve relatively reliable vehicle remote control.

[0043] Other features and advantages of the present disclosure will be described in the following description, or some features and advantages can be inferred from the description without doubt, or can be known by implementing the above technologies of the present disclosure.

[0044] To make the above objects, features, and advantages of the present disclosure more obvious and understandable, the following specific preferred embodiments are given, and in conjunction with the accompanying drawings, the detailed description is as follows. Description of the Drawings

[0045] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0046] Figure 1 Flowchart of a Token management vehicle control method based on cloud desktop signaling service provided by an embodiment of the present invention;

[0047] Figure 2 Functional module diagram of a Token management vehicle control device based on cloud desktop signaling service provided by an embodiment of the present invention;

[0048] Figure 3 Schematic diagram of the hardware architecture of an electronic device provided by an embodiment of the present invention. Specific embodiments

[0049] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions of the present invention with reference to the accompanying drawings. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.

[0050] With the development of vehicle networking technology, cloud desktops are increasingly widely used in intelligent vehicles. Through cloud desktop technology, in-vehicle terminals can perform real-time data signaling interactions with cloud desktop systems, thus supporting the realization of functions including remote vehicle control, in-vehicle navigation, entertainment systems, and other intelligent functions. Signaling services play a crucial role in vehicle networking cloud desktop systems, responsible for authentication, communication, and instruction transmission between in-vehicle devices and cloud desktop system platforms.

[0051] Currently, the Token management of signaling services based on cloud desktops mainly relies on static Tokens or simple time-based validity control. Traditional Token management methods have many deficiencies when dealing with complex vehicle networking environments. For example, in the scenario of remote vehicle control in this application, that is, in the case of high concurrency, multiple devices accessing simultaneously, frequent connections and disconnections to the cloud desktop system service, the efficiency of Token generation, distribution, and verification is low, which easily leads to communication delays and even security vulnerabilities. In addition, the lifecycle management of Tokens is not flexible enough and cannot be dynamically adjusted according to the importance of the business, resulting in the inability to guarantee the response speed of some critical services (such as remote control, emergency calls). In some cases of multi-terminal collaboration, the conflict problem of Token management is more prominent. The synchronization problem between multiple devices easily leads to verification failures or duplicate requests, thereby affecting the user experience.

[0052] In addition, with the enhancement of intelligent vehicle functions and the diversification of user needs, the requirements for the security of signaling services used by in-vehicle terminals are also constantly increasing. Traditional Token authentication mechanisms have security vulnerabilities and are easily threatened by man-in-the-middle attacks, Token theft, or forgery, which pose potential risks to the security of vehicle networking systems.

[0053] The inventors have found through research that there are the following defects in Token management in the vehicle remote control scenario, which in turn lead to the reliability of vehicle remote control:

[0054] Lack of flexibility in Token management: In the existing technology, the lifecycle of Tokens is generally fixed and cannot be dynamically adjusted according to different business requirements. Critical services such as remote control and emergency services have high requirements for the rapid verification and update of Tokens, while the Token management method in the existing system cannot effectively distinguish business priorities, thus affecting the real-time response ability of critical services.

[0055] Token management conflicts among multiple devices: When multiple in-vehicle terminal devices access the same cloud desktop system concurrently, the existing Token management mechanism is prone to verification conflicts or delays, resulting in the inability of multiple devices to synchronize Tokens. In this case, the complexity of multi-terminal collaboration and synchronization processing increases, seriously affecting the user experience.

[0056] Token verification delay problem: Since the existing system usually adopts a single Token verification node and cannot make intelligent selections based on the geographical location or network conditions of in-vehicle terminals, the use of long-distance verification nodes increases the Token verification delay, thereby affecting the efficiency of the entire signaling service.

[0057] Lack of Token security: Existing Token management and verification mechanisms usually rely on static encryption methods and cannot fully address security threats in the vehicle networking environment, such as man-in-the-middle attacks and Token theft. The lack of a dual authentication mechanism based on hardware characteristics and dynamic encryption results in Tokens being easily forged or misused.

[0058] Based on this, an embodiment of the present invention provides a Token management vehicle control method and device based on cloud desktop signaling services, aiming to solve problems such as insufficient flexibility in existing Token management, Token verification conflicts during multi-device concurrency, Token verification delays, and lack of security. By designing dynamic Token updates, distributed verification nodes, a multi-terminal collaboration mechanism, and an enhanced security encryption and authentication system, the embodiment of the present invention provides a dynamic, flexible, and highly secure Token management method that can meet the requirements of high concurrency, multi-device collaboration, and critical business response in the vehicle networking cloud desktop system, significantly improving the security, efficiency, and user experience of the cloud desktop system in the vehicle networking environment, and thus ensuring the reliability of the vehicle remote control scenario.

[0059] To facilitate the understanding of this embodiment, first, a Token management vehicle control method based on cloud desktop signaling services disclosed in an embodiment of the present invention will be introduced in detail. This method is applied to a cloud server on which a cloud desktop system can be deployed.

[0060] Figure 1 It is a flowchart of a Token management vehicle control method provided by an embodiment of the present invention.

[0061] As Figure 1 shown, the method includes the following steps:

[0062] Step S102, in response to a control instruction issued by the current driving user for the in-vehicle terminal, establish a connection with the in-vehicle terminal.

[0063] Here, the current driving user of the current vehicle is the current driving user. In some scenarios, this user can be a novice with less driving experience; the cloud server establishes a connection between the cloud desktop and the in-vehicle terminal based on the control instruction issued by the in-vehicle terminal of the current vehicle.

[0064] Step S104, based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current vehicle networking service of the current driving user, dynamically adjust the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service respectively.

[0065] Among them, the remote control user can be understood as the emergency contact person for this trip pre-bound by the current driving user. In some scenarios, this remote control user has relatively rich driving experience; the first priority is higher than the second priority; the current vehicle networking service may include at least one type, and each current vehicle networking service corresponds to a second priority, and different current vehicle networking services may correspond to different second priority values; the validity period of the first Token is shorter than that of the second Token; it should be noted that the validity periods of the first Token and the second Token here are the Token life cycles.

[0066] In some embodiments, the validity period and refresh frequency of the Token can be dynamically adjusted according to the service type, connection status, and priority of the in-vehicle terminal. For high-priority services (such as remote vehicle control, emergency call, etc.), the verification period of the Token for such high-priority services (remote control services) can be shortened to ensure their real-time performance and response speed; for low-priority or non-real-time services (such as navigation, entertainment), the update period of the Token for such low-priority tasks (current vehicle networking services) can be extended to reduce unnecessary request burdens.

[0067] Step S106: Based on the Token requests sent to each in-vehicle device for the remote control service and the current vehicle networking service, and the device identifier corresponding to each in-vehicle device, calculate the Token hash identifier for each in-vehicle device and manage the Token value of each in-vehicle device.

[0068] For the scenario where multiple in-vehicle devices access the cloud desktop system simultaneously, a multi-terminal Token synchronization mechanism is provided. Different in-vehicle devices can share the same Token, but each in-vehicle device has an independent device identifier, and the validity of the Token can be verified for multiple in-vehicle devices simultaneously through the device identifier, avoiding verification conflicts caused by competition for the Token among multiple in-vehicle devices.

[0069] Step S108: Monitor each Token verification node in real time and switch the abnormal Token verification node to the optimal verification node.

[0070] To reduce the network latency in the Token verification process, multiple Token verification nodes are deployed in the cloud desktop system. Based on the geographical location, network condition, and load of the in-vehicle terminal, the optimal verification node is intelligently selected for Token verification, thereby improving the efficiency and speed of Token verification.

[0071] Step S110: Generate a Token value encrypted based on the hardware characteristics of the current vehicle, and then send it to the in-vehicle terminal to enable the in-vehicle terminal to control the remote control service and the current vehicle networking service of the current vehicle.

[0072] Adopt a dual - authentication mechanism based on the hardware characteristics of the in - vehicle system and dynamic encryption algorithms. When generating and distributing the Token, it will be encrypted in combination with the unique hardware characteristics of the in - vehicle terminal. Even if the Token is stolen, the Token that has not been verified by the device cannot be used. In addition, the dynamic encryption technology ensures that each use of the Token has independent encryption parameters, preventing replay attacks and forgery of the Token.

[0073] In the preferred embodiment of the actual application, first, dynamically adjust the life cycle of the Token according to the service priority. Shorten the life cycle of the Token for high - priority services (such as remote control and emergency calls) to improve its response speed, while extend the life cycle of the Token for low - priority services (such as navigation and entertainment) to optimize system resources; second, a Token binding and management mechanism based on the device identifier (device ID) for multiple in - vehicle devices allows multiple in - vehicle devices to share the Token during concurrent requests. Through the hash mapping of the device identifier and the Token, the Token value synchronization between multiple in - vehicle devices is achieved, avoiding Token verification conflicts during concurrent access by multiple in - vehicle devices; and, deploy multiple Token verification nodes in the cloud desktop system and select the optimal node for Token verification; through the optimal node selection algorithm, ensure that the vehicle establishes a connection with the nearest node, reduce the network latency during the Token verification process, and improve the real - time response of critical tasks; in addition, combined with the hardware characteristics of the in - vehicle terminal, generate a unique encryption factor for the encryption and authentication of the Token, realize dynamic encryption, and generate unique encryption parameters for each Token request, preventing replay attacks and Token forgery, thereby ensuring that the token value issued based on the above steps can achieve relatively reliable vehicle remote control.

[0074] In the existing in - vehicle network cloud desktop system, the life cycle of the Token is usually static. The fixed Token validity period cannot adapt to the dynamic changes of different service requirements. High - priority services (such as remote control) require quick response, while low - priority services (such as the entertainment system) have lower requirements for the Token update frequency. Traditional static Token management easily leads to premature invalidation or unnecessary frequent updates, affecting system performance; the embodiment of the present invention introduces a dynamic Token management mechanism, dynamically adjusts the life cycle of the Token according to the service priority, system load, and device connection frequency, ensuring that critical tasks can respond quickly, while non - critical tasks reduce the occupation of system resources; exemplarily, step S104 includes:

[0075] Step 1.1), determine the first priority of the remote control service and the second priority of the current vehicle networking service based on the importance of the remote control service of the remote control user corresponding to the current driving user and the importance of the current vehicle networking service of the current driving user.

[0076] Here, different services are classified, and priorities are set according to the importance of each type of service. For example, remote vehicle control and emergency call are defined as high priorities, while navigation and entertainment are low priorities.

[0077] Step 1.2), based on the first priority and the second priority, assign corresponding service weights to the remote control service and the current vehicle networking service.

[0078] Classify different services by priority (such as remote control, emergency call, etc. are high priorities, and navigation, entertainment are low priorities), and assign weights to each type of service.

[0079] Step 1.3), determine the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service according to the service weight, historical connection frequency, and preset load parameters.

[0080] Adjust the Token validity period through the priority weight algorithm and device connection frequency. For example, high-priority services ensure their timeliness by shortening the Token validity period and refreshing frequently, while low-priority services allow a longer Token validity period to reduce system overhead. This dynamic adjustment mechanism based on priority and connection frequency makes the Token lifecycle more flexible, can adapt to complex service requirements, improve the response speed of critical tasks, and save resources at the same time.

[0081] When the in-vehicle terminal requests to connect to the cloud desktop system, the cloud desktop system calculates the Token validity period through an algorithm according to the current service type and priority. The Token validity period of high-priority services is shorter and may only last for a few minutes, while the Token validity period of low-priority services is longer and can last for several hours or longer.

[0082] The system will decide whether to update the Token in advance according to the connection frequency of the in-vehicle terminal, service usage, and device status. High-priority services with high-frequency connections will trigger frequent Token updates to ensure stable connection and response speed.

[0083] Adopt a dynamic Token update algorithm based on service weight, which dynamically adjusts the Token lifecycle by analyzing the priority of service types, connection frequency, and current system load conditions. The formula of the algorithm is as follows:

[0084]

[0085] Among them, T lifetime is the lifecycle of the Token, that is, the validity period of the Token, and L load is a preset complex parameter, that is, the load condition of the current cloud desktop system, and W priority is the service weight, and f connection is the historical connection frequency.

[0086] In some embodiments, the token can also be dynamically adjusted through the following steps:

[0087] Step 2.1), when each remote control service ends, update the validity period of the first token of the remote control service.

[0088] Or,

[0089] Step 2.2), when each current vehicle networking service ends, update the validity period of the second token of the current vehicle networking service.

[0090] For a vehicle that is using the remote control function, since its priority is high and the connection is frequent, the system will generate a Token with a validity period of 5 minutes and automatically update the Token after each operation. If this vehicle is also using the navigation function at the same time, the validity period of its Token can be set to 30 minutes and the update frequency is lower.

[0091] In a vehicle networking environment, there are usually multiple devices in the vehicle (such as a navigation system, an entertainment system, remote control, etc.) that simultaneously request access to the cloud desktop service. Traditional Token management cannot effectively distinguish these devices, which easily leads to Token verification conflicts. Especially in the scenario where Tokens are shared among devices, such conflicts will result in verification failures or repeated requests, affecting the user experience. The embodiments of the present invention solve the Token verification conflict problem during multi-device concurrent requests through a multi-terminal collaborative Token management mechanism; exemplarily, step S106 can be implemented through the following steps, including:

[0092] Step 3.1), based on the device identifier and the current Token value corresponding to each in-vehicle device in the remote control service and the current vehicle networking service, calculate the Token hash identifier of each in-vehicle device;

[0093] Assign a unique device identifier (device ID) to each in-vehicle device and bind it to the Token, so that multiple in-vehicle devices share the same Token, and the verification requests of each in-vehicle device are distinguished and managed through its independent device identifier;

[0094] Distributed Synchronization Algorithm Based on Device Identifiers. The cloud desktop system ensures that multiple in-vehicle devices can synchronously perform Token verification when accessing the same cloud desktop service by tracking the status of each in-vehicle device and the Token usage. The hash mapping between the device identifier and the Token is implemented through the following formula:

[0095] H device = Hash(D iD + T token )

[0096] Where, H device is the hash identifier, T token is the current Token value, and D iD is the device identifier.

[0097] In practical applications, each in-vehicle device is assigned a unique device identifier (device ID), and it is bound to the generated Token; for multiple in-vehicle devices on the same vehicle, the cloud desktop system shares a Token, but distinguishes them through the device identifier. When a device requests the cloud desktop system, the system will verify the binding relationship between the identifier of the in-vehicle device and the Token.

[0098] Step 3.2), based on the Token hash identifier and the first Token request sent by each in-vehicle device, verify the Token value sent by each in-vehicle device.

[0099] In some embodiments, the cloud desktop system ensures that there will be no conflicts when multiple in-vehicle devices use Tokens simultaneously through a multi-terminal collaboration algorithm. Each in-vehicle device can independently perform Token verification according to its own device identifier, and the system will regularly synchronize the Token status of each in-vehicle device to avoid repeated verification; by introducing a multi-terminal collaboration mechanism, it ensures Token synchronization and effective verification when multiple in-vehicle devices access the cloud desktop service simultaneously, improves the system's concurrent processing ability while significantly enhancing the user experience, and solves the verification conflict problem in the existing system; the embodiment of the present invention ensures that the Token requests of each device are effectively managed and synchronized through the hash mapping algorithm between the device identifier and the Token. This mechanism can dynamically track the status of the device and the Token usage, thus avoiding conflicts and repeated requests; exemplarily, Step 3.2) can also be implemented through the following steps:

[0100] Step 3.2.1), in response to the first Token request sent by each in-vehicle device, as well as the Token hash identifier and the current Token value of each in-vehicle device, look up the corresponding mapping relationship from the hash table.

[0101] Step 3.2.2), if the search is successful, the device identifier of the current in-vehicle device and the current Token value are successfully verified.

[0102] Step 3.2.3), if the search fails, the current Token value of the current in-vehicle device is invalidated or expired and returned to the in-vehicle terminal, so that the current in-vehicle device issues a second Token request.

[0103] Suppose there are three in-vehicle devices in a car for navigation, entertainment, and remote control respectively. When these in-vehicle devices simultaneously request access to the cloud desktop system, the cloud desktop system retrieves the corresponding record from the hash table Hash Map according to the current Token value, and verifies whether the current device identifier device ID matches the binding relationship of the current Token value; if the match is successful, it is considered that the current Token value carried by the device is still available; if the match fails, Token invalidation or expiration is returned, and the current in-vehicle device is required to refresh the Token value.

[0104] Step 3.3), based on the Token hash identifier and the second Token requests sent by each in-vehicle device, refresh the Token values sent by each in-vehicle device.

[0105] Exemplarily, this Step 3.3) includes:

[0106] Step 3.3.1), when multiple in-vehicle devices in the remote control service simultaneously issue a second Token request when the first Token validity period expires, generate a new Token value corresponding to the target in-vehicle device based on the second Token request sent by the first-arriving target in-vehicle device.

[0107] Here, when multiple in-vehicle devices almost simultaneously request to refresh the Token, the cloud desktop system only accepts the first-arriving request to generate a new Token and updates the hash table; subsequent arriving refresh requests will be informed that "a new Token has been generated" and directly return the latest Token based on the hash table without generating it again; by the exclusive processing of Token refresh requests in the cloud desktop system, duplicate generation of Tokens and Token conflicts are avoided.

[0108] Step 3.3.2), according to the device identifier of the target in-vehicle device, the new Token value, the latest version number corresponding to the new Token value, and the current timestamp, update the stored mapping relationship in the hash table.

[0109] Here, the mapping relationship in the hash table can be understood as Token value - version number - update timestamp - at least one device identifier; at this time, the Token value, version number, and update timestamp in the mapping relationship are updated accordingly.

[0110] Step 3.3.3), send a Token value change notice to each in-vehicle device of the in-vehicle terminal, so that each in-vehicle device with a different current version number and the latest version number issues a second Token request.

[0111] Suppose there are three devices in a vehicle for navigation, entertainment, and remote control respectively. When these devices request access to the cloud desktop simultaneously, the system will ensure that the Token requests of each device do not conflict through the device identifier; when a device (such as a remote control terminal) actively requests a refresh because of high-priority services that require a shorter cycle Token: the cloud desktop system generates a new Token, updates the hash table: <old Token -> new Token>, and increases the version number or updates the timestamp; the cloud desktop system can send a "Token change" notice to other devices (such as navigation and entertainment systems) in real time; other devices can automatically perform synchronous pulling after receiving the notice or update when they find that the version numbers are inconsistent during the next request.

[0112] In the existing vehicle networking environment, the Token verification process between in-vehicle devices and the cloud desktop system is affected by geographical location and network conditions. A single verification node results in a relatively high Token verification delay in some regions, affecting the real-time requirements of the vehicle. This delay particularly has a negative impact on the execution of critical tasks (such as remote control and emergency calls); the embodiments of the present invention design a distributed Token verification mechanism, deploy multiple Token verification nodes in the cloud desktop system, and select the optimal node for Token verification through an intelligent selection mechanism to reduce network latency; exemplarily, step S108 can be implemented through the following steps, including:

[0113] Step 4.1), monitor the status of each Token verification node in real time.

[0114] The cloud desktop system deploys Token verification nodes at multiple geographical locations globally, covering different network regions, that is, each Token verification node covers a different geographical area and network area.

[0115] Step 4.2), if any Token verification node fails or has a network delay, determine the optimal verification node based on the network delay and node load weight of the Token verification node with an exception, and the physical distance between the current vehicle and the Token verification node with an exception.

[0116] After selecting the Token verification node, the system will verify the validity of the node in real time and quickly feedback the result to the in-vehicle terminal. If the verification node fails or has a network delay, the system will automatically switch to other nodes for verification.

[0117] In step S106, when the in-vehicle device requests Token verification, the system selects the optimal verification node based on the geographical location and network conditions. The selection algorithm combines network latency, node load, and geographical distance to ensure that the node with the lowest latency and load is selected for Token verification; through a distributed algorithm based on geographical location and load balancing, the nearest and least-loaded verification node is selected. The specific formula is:

[0118]

[0119] where N optimal is the optimal verification node, L network is the network latency, D geo is the geographical distance between the current vehicle and the node, and W load is the load weight of the node.

[0120] Step 4.3), switch the Token verification node with an anomaly to the optimal verification node, and then execute step 3.2) of verifying the Token value sent by each in-vehicle device.

[0121] Through the design of distributed verification nodes, the Token verification process is significantly accelerated. Especially in cases where the geographical locations are scattered or the network conditions are complex, the system can intelligently select the optimal verification node, reduce latency, and improve the response speed of critical tasks.

[0122] In the traditional Token management mechanism, which relies on static encryption methods, it is vulnerable to man-in-the-middle attacks, Token theft, or forgery threats. In the vehicle networking system, ensuring the security of Tokens is crucial, especially when dealing with sensitive operations such as remote control and payment. The leakage or forgery of Tokens will lead to serious security risks; in the embodiments of the present invention, by combining the hardware features of the in-vehicle terminal (such as a security chip or a physical unclonable function) with a dynamic encryption algorithm, the security of Tokens is ensured; exemplarily, the step of encrypting and generating a Token value based on the hardware features of the current vehicle in step S110 includes:

[0123] Step 5.1), process the security chip features of the current vehicle through a physical unclonable function to obtain the hardware features of the current vehicle.

[0124] The system uses the physical unclonable function PUF to generate a unique encryption factor (hardware feature) from the security chip features of the in-vehicle terminal, ensuring that the encryption method of each Token is bound to the specific device hardware. Even if a Token is intercepted, it cannot be used on other devices. When a Token is generated, the system combines the security chip of the in-vehicle terminal and the physical unclonable function for encryption, ensuring that the encryption method of each Token is unique.

[0125] Step 5.2), input the Token value and the hardware feature into the encryption function, and output the dynamically encrypted Token value of the current vehicle.

[0126] When verifying the Token, the system performs double authentication through the hardware feature and the dynamic encryption algorithm to ensure that only authorized devices can use the Token. The system generates unique encryption parameters for each Token request. Even if the Token is intercepted or tampered with, unauthorized devices cannot decrypt and use it. This algorithm combines the Physically Unclonable Function (PUF) to generate a unique hardware feature as the encryption factor, ensuring that the Token encryption for each device is different. The specific formula is:

[0127] T enerypted = Encrypt(T token , P PUF )

[0128] where, T enerypted is the encrypted Token value, T token is the original value before encryption, and P PUF is the hardware feature value generated based on the Physically Unclonable Function.

[0129] Example: The security chip of a vehicle generates a unique hardware feature. The Token is encrypted based on this feature. Even if the Token is intercepted during network transmission, other devices cannot use it because they cannot decrypt the encryption key generated by the hardware feature.

[0130] Here, unique encryption parameters are generated for each Token request. The dynamic encryption algorithm makes the Token have different encryption methods during each transmission, preventing replay attacks and forgery. The double authentication mechanism ensures that the Token must be device-authenticated when used through the hardware feature and dynamic encryption; through the combination of the hardware feature and dynamic encryption, the embodiments of the present invention significantly improve the security of the Token, preventing the theft, forgery, and replay attacks of the Token. This double authentication mechanism innovates on the basis of traditional static encryption, ensuring the high security of the Token in the vehicle networking system.

[0131] In the embodiments of the present invention, not only through the dynamic Token lifecycle management mechanism, can the validity period and update frequency of Tokens be dynamically adjusted according to business priorities to ensure the real-time response speed of high-priority services (such as remote control, emergency calls). For example, the response time of critical services is shortened to the millisecond level, greatly improving the timeliness of the system, avoiding potential safety hazards caused by delays, and enhancing the system response speed and the real-time performance of critical services. Moreover, through the multi-terminal collaborative Token management mechanism, the Token conflict problem when multiple in-vehicle devices access the cloud desktop service simultaneously is solved, ensuring that multiple devices can use Tokens synchronously and avoiding verification conflicts. Even in the case of concurrent requests from multiple devices, the system can still process efficiently, avoiding delays or failures caused by repeated verification requests, and significantly enhancing the concurrent processing ability. In addition, through the distributed Token verification mechanism, multiple verification nodes are distributed globally, and the optimal node selection algorithm is used to reduce the delay of Token verification. The in-vehicle terminal can automatically select the nearest node for verification according to its geographical location and network conditions, significantly reducing network latency, optimizing the user experience, accelerating the Token verification speed, and reducing network latency. And by adopting the dual encryption and dynamic encryption mechanism based on hardware characteristics, combined with the physical unclonable function (PUF) and dynamic encryption algorithm of the in-vehicle terminal, security issues such as man-in-the-middle attacks, Token theft, and forgery are effectively prevented. Even if the Token is intercepted during transmission, it cannot be used on unauthorized devices, significantly enhancing the system security. On this basis, the vehicle remote control solution can be implemented more safely and reliably.

[0132] In some embodiments, as Figure 2 shown, the embodiments of the present invention further provide a vehicle control device 200 based on cloud desktop signaling service Token management, including:

[0133] A connection module 201, in response to a control instruction issued by the current driving user for the in-vehicle terminal, establishes a connection with the in-vehicle terminal;

[0134] A Token lifecycle management module 202, based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current vehicle networking service of the current driving user, respectively dynamically adjusts the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service; wherein, the first priority is higher than the second priority; the second priority includes multiple types; the first Token validity period is shorter than the second Token validity period;

[0135] The Token management module 203 calculates the Token hash identifier for each in-vehicle device based on the Token requests sent by each in-vehicle device for the remote control service and the current vehicle networking service, as well as the device identifier corresponding to each in-vehicle device, and manages the Token value of each in-vehicle device;

[0136] The node detection module 204 monitors each Token verification node in real time and switches the abnormal Token verification node to the optimal verification node;

[0137] The encryption control module 205 encrypts and generates a Token value based on the hardware characteristics of the current vehicle, and then sends it to the in-vehicle terminal, so that the in-vehicle terminal controls the remote control service and the current vehicle networking service of the current vehicle.

[0138] Further, the Token lifecycle management module 202 is specifically configured to determine the first priority of the remote control service and the second priority of the current vehicle networking service based on the importance of the remote control service of the remote control user corresponding to the current driving user and the importance of the current vehicle networking service of the current driving user; based on the first priority and the second priority, allocate corresponding service weights to the remote control service and the current vehicle networking service; and determine the first Token validity period of the remote control service and the second Token validity period of the current vehicle networking service according to the service weights, historical connection frequencies, and preset load parameters.

[0139] Further, the Token management module 203 is specifically configured to calculate the Token hash identifier for each in-vehicle device based on the device identifier and the current Token value corresponding to each in-vehicle device in the remote control service and the current vehicle networking service; verify the Token value sent by each in-vehicle device based on the Token hash identifier and the first Token request sent by each in-vehicle device; and refresh the Token value sent by each in-vehicle device based on the Token hash identifier and the second Token request sent by each in-vehicle device.

[0140] Further, the Token management module 203 is specifically configured to, in response to the first Token request sent by each in-vehicle device, as well as the Token hash identifier and the current Token value of each in-vehicle device, look up the corresponding mapping relationship in the hash table; if the lookup is successful, the device identifier and the current Token value of the current in-vehicle device are successfully verified; if the lookup fails, the current Token value of the current in-vehicle device is invalidated or expired and returned to the in-vehicle terminal, so that the current in-vehicle device sends a second Token request.

[0141] Further, the Token management module 203 is specifically configured to, when multiple vehicle-mounted devices in the remote control service simultaneously send a second Token request when the first Token validity period expires, generate a new Token value corresponding to the target vehicle-mounted device based on the second Token request sent by the first-arriving target vehicle-mounted device; update the mapping relationship stored in the hash table according to the device identifier of the target vehicle-mounted device, the new Token value, the latest version number corresponding to the new Token value, and the current timestamp; send a Token value change notice to each vehicle-mounted device of the vehicle terminal, so that each vehicle-mounted device with a different current version number and the latest version number sends a second Token request.

[0142] Further, the node detection module 204 is specifically configured to monitor the status of each Token verification node in real time; if any Token verification node fails or has a network delay, determine an optimal verification node based on the network delay and node load weight of the abnormal Token verification node, and the physical distance between the current vehicle and the abnormal Token verification node; switch the abnormal Token verification node to the optimal verification node, and then execute the step of verifying the Token value sent by each vehicle-mounted device.

[0143] Further, the encryption control module 205 is specifically configured to process the security chip feature of the current vehicle through a physically unclonable function to obtain the hardware feature of the current vehicle; input the Token value and the hardware feature into an encryption function, and output the dynamically encrypted Token value of the current vehicle.

[0144] Figure 3 It is a schematic hardware architecture diagram of the electronic device 300 provided in the embodiment of the present invention. Refer to Figure 3 As shown, the electronic device 300 includes: a machine-readable storage medium 301 and a processor 302, and may further include a non-volatile storage medium 303, a communication interface 304, and a bus 305; wherein, the machine-readable storage medium 301, the processor 302, the non-volatile storage medium 303, and the communication interface 304 complete mutual communication through the bus 305. The processor 302 can execute the vehicle control method based on cloud desktop signaling service Token management described in the above embodiments by reading and executing the machine-executable instructions for vehicle control based on cloud desktop signaling service Token management stored in the machine-readable storage medium 301.

[0145] The machine-readable storage medium mentioned in this document can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For example, the machine-readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or a combination thereof.

[0146] The non-volatile medium can be non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar non-volatile storage media, or a combination thereof.

[0147] It can be understood that the specific operation methods of the functional modules in this embodiment can refer to the detailed descriptions of the corresponding steps in the above method embodiment, and will not be repeated here.

[0148] The computer-readable storage medium provided by the embodiment of the present invention stores a computer program, and when the computer program code is executed, it can implement the vehicle control method based on cloud desktop signaling service Token management described in any of the above embodiments. For the specific implementation, refer to the method embodiment and will not be elaborated here.

[0149] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described systems and devices can refer to the corresponding processes in the foregoing method embodiments and will not be repeated here.

[0150] In addition, in the description of the embodiments of the present invention, unless otherwise clearly specified and limited, the terms "installed", "connected", and "coupled" shall be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium, and it can be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific situations.

[0151] In the description of the present invention, it should be noted that the orientation or positional relationship indicated by the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation to the present invention. In addition, the terms "first", "second", and "third" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance.

[0152] Finally, it should be noted that the above-described embodiments are only specific embodiments of the present invention, used to illustrate the technical solutions of the present invention, rather than limiting them. The protection scope of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that any person skilled in the art within the technical scope disclosed by the present invention can still modify the technical solutions described in the foregoing embodiments or easily conceive of changes, or perform equivalent replacements for some of the technical features; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the protection scope of the present invention.

Claims

1. A Token management vehicle control method based on cloud desktop signaling service, characterized in that: include: In response to a control instruction issued by a current driving user to the vehicle-mounted terminal, establishing a connection with the vehicle-mounted terminal; Based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current Internet of Vehicles service of the current driving user, dynamically adjust the first Token validity period of the remote control service and the second Token validity period of the current Internet of Vehicles service respectively; wherein the first priority is higher than the second priority; the second priority includes multiple types; the first Token validity period is shorter than the second Token validity period; Based on the Token request issued for each vehicle-mounted device in the remote control service and the current vehicle networking service, and the device identifier corresponding to each vehicle-mounted device, calculate the Token hash identifier of each vehicle-mounted device, and manage the Token value of each vehicle-mounted device; Monitor each Token verification node in real time and switch the abnormal Token verification node to the optimal verification node; The Token value generated based on the encryption of the hardware features of the current vehicle is then sent to the vehicle-mounted terminal so that the vehicle-mounted terminal controls the remote control service and the current Internet of Vehicles service of the current vehicle.

2. The method according to claim 1, characterized in that The steps of dynamically adjusting the first Token validity period of the remote control service and the second Token validity period of the current Internet of Vehicles service respectively based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current Internet of Vehicles service of the current driving user include: Determining a first priority of the remote control service and a second priority of the current Internet of Vehicles service based on the importance of the remote control service of the remote control user corresponding to the current driving user and the importance of the current Internet of Vehicles service of the current driving user; Based on the first priority and the second priority, assigning corresponding service weights to the remote control service and the current Internet of Vehicles service; The validity period of the first Token of the remote control service and the validity period of the second Token of the current Internet of Vehicles service are determined according to the service weight, the historical connection frequency, and the preset load parameters.

3. The method according to claim 1, characterized in that The steps of calculating the Token hash identifier of each onboard device based on the Token request issued for each onboard device in the remote control service and the current Internet of Vehicles service, and the device identifier corresponding to each onboard device, and managing the Token value of each onboard device include: Calculate the Token hash identifier of each on-board device based on the device identifier corresponding to each on-board device in the remote control service and the current Internet of Vehicles service and the current Token value; Verify the Token value issued by each vehicle-mounted device based on the Token hash identifier and the first Token request issued by each vehicle-mounted device; Based on the Token hash identifier and the second Token request issued by each of the vehicle-mounted devices, the Token value issued by each of the vehicle-mounted devices is refreshed.

4. The method according to claim 3, characterized in that The step of verifying the Token value issued by each vehicle-mounted device based on the Token hash identifier and the first Token request issued by each vehicle-mounted device includes: In response to the first Token request issued by each of the vehicle-mounted devices, as well as the Token hash identifier and the current Token value of each of the vehicle-mounted devices, searching for a corresponding mapping relationship in the hash table; If the search is successful, the device identifier of the current vehicle-mounted device and the current Token value are verified successfully; If the search fails, the current Token value of the current vehicle-mounted device is invalid or expired and is returned to the vehicle-mounted terminal, so that the current vehicle-mounted device issues a second Token request.

5. The method according to claim 3, characterized in that: The step of refreshing the Token value issued by each vehicle-mounted device based on the Token hash identifier and the second Token request issued by each vehicle-mounted device includes: When multiple vehicle-mounted devices in the remote control service simultaneously issue a second Token request when the validity period of the first Token expires, a new Token value corresponding to the target vehicle-mounted device is generated based on the second Token request issued by the first arriving target vehicle-mounted device; Update the mapping relationship stored in the hash table according to the device identifier of the target vehicle-mounted device, the new Token value, the latest version number corresponding to the new Token value, and the current timestamp; A Token value change notification is sent to each vehicle-mounted device of the vehicle-mounted terminal, so that each vehicle-mounted device whose current version number is different from the latest version number sends a second Token request.

6. The method according to claim 1, characterized in that The steps of monitoring each Token verification node in real time and switching the abnormal Token verification node to the optimal verification node include: Monitor the status of each Token verification node in real time; If any Token verification node fails or has network delay, the optimal verification node is determined based on the network delay and node load weight of the abnormal Token verification node, as well as the physical distance between the current vehicle and the abnormal Token verification node; The abnormal Token verification node is switched to the optimal verification node, and then the step of verifying the Token value issued by each vehicle-mounted device is performed.

7. The method according to claim 1, characterized in that The step of encrypting and generating a Token value based on the hardware features of the current vehicle includes: Processing the security chip features of the current vehicle through a physical unclonable function to obtain the hardware features of the current vehicle; The Token value and the hardware feature are input into an encryption function together, and the dynamically encrypted Token value of the current vehicle is output.

8. A vehicle control device based on cloud desktop signaling service Token management, characterized in that: include: A connection module, responding to a control instruction issued by a current driving user to the vehicle terminal, establishing a connection with the vehicle terminal; A Token lifecycle management module dynamically adjusts the first Token validity period of the remote control service and the second Token validity period of the current Internet of Vehicles service based on the first priority of the remote control service of the remote control user corresponding to the current driving user and the second priority of the current Internet of Vehicles service of the current driving user; wherein the first priority is higher than the second priority; the second priority includes multiple types; the first Token validity period is shorter than the second Token validity period; A token management module, which calculates a token hash identifier of each vehicle-mounted device based on a token request issued for each vehicle-mounted device in the remote control service and the current vehicle networking service, and a device identifier corresponding to each vehicle-mounted device, and manages a token value of each vehicle-mounted device; The node detection module monitors each Token verification node in real time and switches the abnormal Token verification node to the optimal verification node; The encryption control module generates a Token value based on the encryption of the hardware characteristics of the current vehicle, and then sends it to the vehicle terminal so that the vehicle terminal controls the remote control service and the current Internet of Vehicles service of the current vehicle.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A machine-readable storage medium, characterized in that: The machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the steps of the method described in any one of claims 1 to 7.

Images