A vehicle control method, apparatus, device and medium based on atomic services

Abstract

The application provides a vehicle control method and device based on an atomic service, equipment and a medium; comprising: receiving an operation instruction triggered by a user on a desktop interaction component of an electronic device, obtaining vehicle control information corresponding to the operation instruction, and pulling up an atomic service bound to the desktop interaction component; generating a standard vehicle control request based on the vehicle control information through the atomic service, hashing and signing the standard vehicle control request based on a control token corresponding to the vehicle identifier to obtain signature information; sending the signature information and the control token to the cloud through the atomic service, so that the cloud verifies and parses the signature information based on the control token, and then forwards the vehicle control instruction to the vehicle corresponding to the vehicle identifier; receiving feedback information through the atomic service; updating the state of the desktop interaction component according to the feedback information through the atomic service, and displaying the execution result, and automatically releasing the process and resources of the atomic service if the execution result represents successful execution.

Description

Technical Field

[0001] This application relates to the field of remote control technology for intelligent connected vehicles, and in particular to a vehicle control method, apparatus, device, and medium based on atomic services. Background Technology

[0002] With the continuous development of intelligent connected vehicles and vehicle networking technology, remote vehicle control via mobile terminals has become a mainstream basic function of intelligent vehicles.

[0003] The execution process for remote vehicle control via mobile terminals in related technologies includes: user-triggered operation, application launch (APP), initialization of software development kit (SDK), login verification, control request construction, cloud-based command forwarding, and vehicle-mounted execution of the operation. It can be seen that this solution relies on a complete application to complete remote vehicle control. The launch process of a complete application involves numerous module loading, resource initialization, and interface rendering processes, resulting in a lengthy control chain, slow response speed, and unsuitability for scenarios requiring rapid vehicle control. Summary of the Invention

[0004] One objective of this application is to provide a vehicle control method based on atomic services to solve the problems of long control links, slow response speed, and inability to adapt to the use scenarios of fast vehicle control in related technologies; another objective is to provide a vehicle control device based on atomic services; a third objective is to provide an electronic device; a fourth objective is to provide a computer-readable storage medium; and a fifth objective is to provide a computer program product.

[0005] To achieve the above objectives, the technical solution of this application embodiment is implemented as follows: This application provides a vehicle control method based on atomic services, the method including: It receives operation commands triggered by the user on the desktop interactive component of the electronic device, obtains the vehicle control information corresponding to the operation command, and launches the atomic service bound to the desktop interactive component; wherein, the desktop interactive component integrates some basic control functions of the vehicle control application, and the vehicle control information includes the vehicle identifier and the vehicle control command corresponding to the target function; A standard vehicle control request is generated based on vehicle control information through atomic services. The standard vehicle control request is hash-signed based on the control token corresponding to the vehicle identifier to obtain the signature information. The signature information and control token are sent to the cloud through the atomic service, so that the cloud can verify the signature information based on the control token and then forward the vehicle control command to the vehicle corresponding to the vehicle identifier. The atomic service receives feedback information from the cloud after the vehicle executes control commands; the feedback information includes one or more of the following: execution result, vehicle status, and fault code. The atomic service updates the state of the desktop interactive components based on the feedback information and displays the execution result. If the execution result indicates that the execution was successful, the process and resources of the atomic service are automatically released.

[0006] Based on the aforementioned technical means, users can trigger control operations through desktop interactive components without launching the full vehicle control application. The atomic service directly initiates the entire remote vehicle control process, eliminating the time-consuming multi-module loading, resource initialization, and interface rendering phases of the full application's cold start phase. This significantly reduces the response latency of remote vehicle control and simplifies the user's operation path, enabling one-click rapid vehicle control. The entire chain—control request generation, hash signing, cloud transmission, and result reception—is independently handled by the atomic service in a closed loop, running independently of the main application process. This lightweight and singular functional logic ensures stable operation of the vehicle control chain and prevents interference from other business logic in the main application. Hash signing of vehicle control requests based on control tokens, combined with cloud verification, ensures the data integrity and legality of the control request's source, preventing tampering or forgery of instructions during transmission and enhancing the security of the remote vehicle control chain. After the vehicle control command is executed, the atomic service automatically updates the display status of the desktop interactive components and provides feedback on the execution result. Users can intuitively obtain the vehicle control execution status on the system desktop without having to jump into the vehicle control application, making the interaction smooth and convenient. After successful execution, the atomic service process and resources are automatically released to avoid the service running in the background and occupying the electronic device's memory and computing power, thus reducing the device's operating power consumption.

[0007] This application provides a vehicle control device based on atomic services, the device comprising: The receiving module is used to receive operation commands triggered by the user on the desktop interactive components of the electronic device; The acquisition module is used to obtain the vehicle control information corresponding to the operation command and launch the atomic service bound to the desktop interaction component; the desktop interaction component integrates some basic control functions of the vehicle control application, and the vehicle control information includes the vehicle identifier and the vehicle control command corresponding to the target function; The processing module is used to generate a standard vehicle control request based on vehicle control information through atomic services, and to perform a hash signature on the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain the signature information. The sending module is used to send signature information and control token to the cloud through atomic services, so that the cloud can verify the signature information based on the control token, parse it and forward the vehicle control command to the vehicle corresponding to the vehicle identifier. The receiving module is also used to receive feedback information generated after the vehicle executes the vehicle control command, which is returned from the cloud via atomic services; the feedback information includes one or more of the following: execution result, vehicle status, and fault code; The processing module is also used to update the state of desktop interactive components based on feedback information through atomic services and display the execution results. If the execution result indicates successful execution, the process and resources of the atomic service are automatically released.

[0008] This application provides an electronic device, including: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the vehicle control method based on atomic services provided in the embodiments of this application.

[0009] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the vehicle control method based on atomic services provided in this application when executed by a processor.

[0010] This application provides a computer program product, including a computer program or computer-executable instructions. When the computer program or computer-executable instructions are executed by a processor, they implement the vehicle control method based on atomic services provided in this application. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the system architecture of the vehicle control method based on atomic services provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the vehicle control method based on atomic services provided in an embodiment of this application; Figure 3 This is a schematic diagram of the control token authentication process provided in an embodiment of this application; Figure 4 This is a schematic diagram of the atomic service call chain provided in the embodiments of this application; Figure 5 This is a schematic diagram of the state transition of the atomic service provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the vehicle control device based on atomic services provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application.

[0012] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] With the continuous development of intelligent connected vehicles and vehicle networking technologies, remote vehicle control via mobile terminals has become a mainstream basic function of intelligent vehicles. The execution process for remote vehicle control via mobile terminals in related technologies includes: user-triggered operation, application launch (APP), initialization of the Software Development Kit (SDK), login verification, construction of control requests, cloud-based command forwarding, and on-board execution of operations. For example, the vehicle interaction method in publication CN202211484783.6 requires launching a complete APP and involves multiple module loading, resource initialization, and interface rendering processes. Cold start time is typically 1-3 seconds or more, which cannot meet the needs of rapid control. All control operations rely on a complete login system, which is unsupported by lightweight or temporary authorization scenarios. Loading the complete application significantly increases CPU and memory usage, wastes background resources, and is unsuitable for high-frequency, rapid triggering scenarios. The control chain is long, with many dependent links, resulting in high failure rates and slow response times during network fluctuations, making it unsuitable for rapid vehicle control applications.

[0015] To address the aforementioned issues, this application provides a vehicle control method based on atomic services, applied to electronic devices. This method allows for rapid response and completion of remote vehicle control scenarios without requiring the startup of a full application, and can be widely applied to remote control and vehicle networking services for intelligent connected vehicles such as passenger cars, commercial vehicles, and shared mobility vehicles. The electronic device can be a terminal device running HarmonyOS, with a built-in standard atomic service runtime environment and distributed soft bus capabilities. Electronic devices include, but are not limited to, mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, and ultra-mobile personal computers (Ultra). Mobile personal computers (UMPCs), netbooks or personal digital assistants (PDAs), servers, network attached storage (NAS), personal computers (PCs), etc.

[0016] like Figure 1 As shown in the figure, this application embodiment provides a system architecture for a vehicle control method based on atomic services. This system architecture involves the electronic device, the cloud, and the vehicle. The system architecture includes an interaction triggering layer 11, an atomic service execution layer 12, and a remote execution layer 13. The interaction triggering layer 11 receives operation commands triggered by the user on a desktop interactive component and obtains the corresponding vehicle control information. The atomic service execution layer 12 generates a standard vehicle control request based on the vehicle control information using the atomic services of the HarmonyOS system. It then hashes and signs the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain signature information. In other words, the atomic service execution layer implements a lightweight service container, independent lifecycle management, and on-demand loading of execution modules. The remote execution layer 13 executes the actual vehicle control commands corresponding to the standard vehicle control request and provides real-time status feedback.

[0017] like Figure 2 As shown, Figure 2 A schematic diagram of the implementation process of a vehicle control method based on atomic services provided in this application embodiment. Figure 1 The method may include the following steps: Step 201: Receive the operation command triggered by the user on the desktop interaction component of the electronic device, obtain the vehicle control information corresponding to the operation command, and launch the atomic service bound to the desktop interaction component.

[0018] The desktop interaction component integrates some basic control functions from the vehicle control application, and the vehicle control information includes vehicle identification and vehicle control commands corresponding to the target function.

[0019] In this embodiment, the desktop interaction component can be a visual interaction component placed on the desktop of an electronic device. It can be displayed independently and permanently, and integrates some basic control function controls from the vehicle control application. It can receive user touch operations and bind to atomic services to implement function calls. It does not depend on the main interface of the vehicle control application, does not launch the complete vehicle control application, and does not trigger the complete lifecycle of the vehicle control application. In some embodiments, such as Figure 1 As shown, the desktop interaction component may include a desktop service card 111. Of course, the desktop interaction component may also include: a quick access point 112, a negative one screen service access point 113, and a voice call access point and a watch quick control access point. This application does not make any specific limitations on these.

[0020] In this embodiment, an atomic service can be a lightweight business capability provided by the HarmonyOS system. It can be directly called by external components such as functional controls in a vehicle control application displayed on a desktop interactive component. It does not require starting the complete process of the vehicle control application, has an independent lifecycle, and is used to carry a single or a small amount of business processing logic.

[0021] In this embodiment, the vehicle control application can be a client program installed on an electronic device that has complete business capabilities for remote vehicle management and control.

[0022] In this embodiment of the application, the vehicle identifier can be a unique vehicle identification code, used to distinguish different vehicle terminals in the vehicle networking platform and establish a correspondence between control requests and target vehicles.

[0023] In this embodiment of the application, the target function can be the function corresponding to the component triggered by the user, and the vehicle control command is a data command used to instruct the vehicle to perform a specified action, including but not limited to remote control commands such as unlocking the vehicle, locking the vehicle, turning on the air conditioner, and locating the vehicle.

[0024] In this embodiment, the electronic device receives operation commands triggered by the user's basic control functions in the vehicle control application within the desktop interaction component. Based on these commands, it determines the vehicle identifier and the vehicle control command for the target function triggered by the user. Since the desktop interaction component is bound to the entry point of an atomic service, it can also launch the atomic service bound to the desktop interaction component without starting the full vehicle control application. Thus, the electronic device receives user interaction behavior through the persistent desktop interaction component without launching the full vehicle control application; it parses the corresponding business data to obtain vehicle control information and directly invokes the atomic service based on a preset binding relationship, using the atomic service to carry subsequent remote vehicle control logic.

[0025] In some embodiments, electronic devices can launch atomic services bound to desktop interactive components through the standard atomic service scheduling interface of the HarmonyOS system without starting the process of the vehicle control application.

[0026] In this embodiment, the standard atomic service scheduling interface can be a standardized system interface exposed by the HarmonyOS system, used by external components to initiate atomic service wake-up requests, providing a standardized calling channel to enable atomic services to be started independently, without being constrained by the running state of the host application.

[0027] In this embodiment, after receiving an operation command triggered by the user on the desktop interaction component of the electronic device, the atomic service bound to the desktop interaction component is launched through the HarmonyOS standard atomic service scheduling interface. The entire call process does not start the process of the vehicle control application. Thus, the atomic service initiation operation is completed through the scheduling interface natively provided by the HarmonyOS system of the electronic device, and this call chain is independent of the lifecycle of the main process of the vehicle control application. When responding to the user's desktop interaction component operation, only the lightweight atomic service is activated, without loading the complete vehicle control application, thus avoiding a series of initialization processes brought about by the main application startup.

[0028] In some embodiments, before receiving the operation command triggered by the user on the desktop interaction component of the electronic device in step 201, the following steps may also be performed: Step 211: In response to the user logging into the vehicle control application, send an identity authentication request to the cloud so that the cloud can generate a refresh token, a control token, and a signature key corresponding to the control token after completing the identity verification.

[0029] The identity authentication request includes: vehicle identifier, user identifier, device identifier, and vehicle permissions.

[0030] In this embodiment, the authentication request can be a data request transmitted by an electronic device to the cloud, carrying user identity credentials, for the cloud to identify the user. The authentication request includes vehicle identifier, user identifier, device identifier, and vehicle permissions.

[0031] Among them, vehicle identification, user identification, and equipment identification are unique.

[0032] Vehicle permissions are used to indicate whether a user has the basic permissions to access a specified vehicle and are a prerequisite for remote vehicle control. Vehicle permissions may include function control permissions, which are subsets of the remote vehicle operations that a user can perform, provided they possess the necessary vehicle permissions. For example, function control permissions may include vehicle unlocking, vehicle locking, remote air conditioning start, window opening and closing, sunroof control, vehicle horn homing, power tailgate opening and closing, remote start / stop, and charging start / stop. This permission scope does not grant the user permission to modify vehicle status information such as persistent configurations, security parameters, and ownership information.

[0033] In this embodiment, the refresh token is used to silently request a new control token when the control token expires, without requiring the user to log in again, thus automatically renewing the authentication information. The refresh token is used for the entire application session and corresponds to the vehicle identifier, user identifier, and device identifier. The refresh token may include a validity period and can be a long-term valid credential, such as a validity period of 3-6 months.

[0034] In this embodiment, the control token is used for authentication and verification of remote vehicle control requests. It is bound to a user identifier and vehicle permissions to verify the legality of remote vehicle control commands. The control token can have a validity period and vehicle permissions. The validity period of the control token is much shorter than that of the refresh token, meaning the control token can be a short-term valid credential, such as 2-3 days.

[0035] In this embodiment, the signature key is the key corresponding to the control token, used to sign standard vehicle control requests. The signature key is unique. It should be noted that the same vehicle identifier can correspond to one or more signature keys; that is, different control tokens under the same vehicle identifier can have the same or different signature keys. For example, multiple control tokens under the same vehicle identifier can correspond to one signature key, or multiple control tokens under the same vehicle identifier can correspond to different signature keys. That is, when a new control token is generated, a corresponding signature key is generated simultaneously. This application does not impose specific limitations on this.

[0036] It should be noted that while the user remains logged into the vehicle control application and has not logged out, the refresh token and control token can be reused within their respective validity periods. When the vehicle control application logs out and the user initiates a login request again, the electronic device repeats the authentication process, resending the authentication request to the cloud. After the cloud completes the identity verification, it generates a new refresh token, control token, and signature key. Thus, while the user remains logged in, both types of tokens can be reused within their validity periods, eliminating the overhead of frequent authentication and shortening the response time for remote vehicle control. Furthermore, logging out and logging back in generates a completely new token, rendering the old token ineffective and preventing the risk of unauthorized token use during session switching, thus balancing interaction efficiency and access security.

[0037] In this embodiment, each time a user opens the complete vehicle control application on their electronic device and logs in, the device sends an authentication request to the cloud via the application, carrying the vehicle identifier, user identifier, device identifier, and the vehicle permissions granted to that user. Upon receiving the authentication request, the cloud first verifies the user's vehicle permissions based on the vehicle identifier, user identifier, and device identifier to determine if the user is qualified to access the target vehicle. After successful vehicle permission verification, the cloud further verifies the user's corresponding function control permissions to determine the permitted vehicle control commands. Upon successful verification, the cloud generates a refresh token and a control token corresponding to the vehicle identifier, user identifier, and device identifier. Thus, by setting a two-level progressive authentication mechanism—first verifying the user's vehicle permissions to confirm access, and then verifying function control permissions after successful verification—the scope of vehicle control commands that the user can execute is finely defined. This enables differentiated management of permissions for different roles such as vehicle owners and visitors, balancing the flexibility of car sharing with vehicle access security. Simultaneously employing a dual-token separation mechanism of refresh token and control token, the control token can be configured with a shorter validity period. Even if the control token is leaked, its effective window is limited, significantly reducing the security risk of unauthorized use of the token to initiate vehicle control. During the login phase, identity verification, permission validation, and the issuance of a token bound to the vehicle identifier, user identifier, and device identifier are completed in one step, pre-completing permission binding. When the system desktop interaction component initiates a remote vehicle control request, it can directly call the token to complete signature authentication, eliminating the need to repeat the complete identity authentication process, streamlining the remote vehicle control interaction link, and effectively reducing command transmission latency. The token is bound to the vehicle identifier, user identifier, and device identifier, achieving device, account, and vehicle association constraints and preventing unauthorized reuse of the token across devices and vehicles.

[0038] Step 212: Receive the refresh token, control token, and signature key sent from the cloud, store the control token and signature key in the first storage area, and store the refresh token in the second storage area.

[0039] In this embodiment, the first storage area is used to store the control tokens corresponding to the user identifier, device identifier, and vehicle identifier, as well as the signature key corresponding to the control tokens. The first storage area can be a secure storage area in the HarmonyOS system that is only accessible to designated atomic services and not to other applications or services. The secure storage area includes, but is not limited to, a Trusted Execution Environment (TEE), a system key chain, and security components. It should be noted that the control tokens and signature keys are used for authentication and signing of vehicle remote control requests, which poses a higher security risk. Storing them in the first storage area with strictly controlled access permissions, and using the secure storage environment to achieve isolation and protection, reduces the risk of token theft and tampering.

[0040] In this embodiment, the second storage area is used to store refresh tokens corresponding to the user identifier, device identifier, and vehicle identifier. The second storage area can be an area capable of storing information or a secure storage area; this application does not specifically limit its use. It should be noted that the refresh token is used for silent background updates of the control token, which has relatively lower security requirements. Flexible selection of the storage area reduces the consumption of high-security-level storage resources.

[0041] In this embodiment, after receiving the control token, refresh token, and signature key corresponding to the user identifier, device identifier, and vehicle identifier sent from the cloud, the electronic device can store the control token and signature key, which have higher security requirements, in the first storage area, and store the refresh token in the corresponding second storage area. By storing the control token and refresh token separately, differentiated protection strategies can be implemented based on the different security levels of the two types of tokens. This partitioned storage of the two types of tokens makes it difficult for attackers to simultaneously obtain the entire set of authentication credentials even if the storage area corresponding to one type of token is illegally accessed, effectively improving the anti-attack capability of the authentication system and ensuring the security of the vehicle remote control link.

[0042] Step 213: Create desktop interaction components corresponding to some basic control functions in the vehicle control application, register and configure atomic services, and bind the desktop interaction components to the entry points of the atomic services.

[0043] In this embodiment, the electronic device can create desktop interactive components on the desktop corresponding to some basic control functions in the vehicle control application. Some basic control functions include, but are not limited to, commonly used functions such as unlocking, locking, turning on the air conditioner, and finding the vehicle.

[0044] In this embodiment of the application, registering and configuring an atomic service may include: registering the atomic service and configuring its static permissions, startup mode, and loading priority for modules that can be preloaded, so that it can be quickly scheduled by the system and run without installation.

[0045] In this embodiment, by deploying a desktop interaction component on the desktop, high-frequency vehicle control functions such as unlocking, locking, turning on the air conditioner, and locating the vehicle are brought to the native system interface. Users can initiate remote control operations without having to search for and launch the complete vehicle control application, significantly shortening the user operation path. Pre-registering atomic services and configuring their static permissions, startup modes, and module loading priorities optimizes the atomic service scheduling and startup logic, ensuring that atomic services are quickly invoked by the system and supporting independent operation without installation. Binding the desktop interaction component to the atomic service entry point allows for targeted invocation of the corresponding atomic service when the user triggers an operation on the desktop interaction component. This constructs a lightweight business call chain independent of the complete vehicle control application, eliminating the dependence of remote vehicle control functions on the complete application process and effectively shortening the response latency of remote vehicle control. Simultaneously, it displays high-frequency basic control functions externally, reducing the loading of unnecessary business logic and lowering the computing power and memory resource consumption of electronic devices.

[0046] Step 202: Generate a standard vehicle control request based on vehicle control information through atomic services, and perform a hash signature on the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain the signature information.

[0047] In this embodiment, the standard vehicle control request can be a vehicle control request message constructed according to a preset unified data format, with a standardized field structure, which can be uniformly recognized and parsed by the cloud platform and the vehicle terminal, and used to carry vehicle control commands and associated verification information.

[0048] In this embodiment of the application, the hash signature can be a unique feature identifier generated by performing calculations on the request data based on a hash algorithm and combined with a dedicated key credential. It is used to verify the integrity and legality of the request data and to prevent malicious tampering during data transmission.

[0049] In this embodiment, the control token and signature key can be short-term valid authentication credentials issued by the cloud and stored in a secure storage area in the electronic device. The control token is bound to the user identifier, device identifier, and vehicle identifier one by one, and the control token corresponds to the signature key, which is used to sign and verify the operation permission of the vehicle control request.

[0050] In this embodiment, after receiving vehicle control information through an atomic service, the electronic device generates a standardized vehicle control request based on the vehicle identifier and the vehicle control command of the target function in the vehicle control information, according to a preset unified format. It then calls the control token matching the vehicle identifier and obtains the signature key corresponding to the control token. A hash signature operation is performed on the standard vehicle control request to obtain the final signature information, preparing for subsequent sending of vehicle control commands to the cloud. Thus, by using a standardized structure to generate vehicle control requests and unifying the command data format, the cost of command parsing between the cloud and the vehicle terminal is reduced, and the command compatibility between different vehicle models and different terminal devices is improved. Simultaneously, the entire process of constructing the standard vehicle control request and hash signing is completed within the atomic service, building a lightweight closed-loop processing link and reducing cross-module call overhead. Furthermore, relying on the control token to complete the request signature ensures the tamper-proof capability of the control request, balancing vehicle control response efficiency and transmission security.

[0051] In some embodiments, before step 202, where a standard vehicle control request is generated based on vehicle control information through the service module of the atomic service, and the standard vehicle control request is hash-signed using the control token corresponding to the vehicle identifier to obtain the signature information, the running status of the atomic service can also be obtained. If the atomic service is in a cold start state, the atomic service is initialized and its service modules are loaded. That is, the minimum execution environment of the atomic service is initialized, and the service modules required by the atomic service are loaded as needed, without loading redundant user interface (UI) components and business modules. Afterwards, a standard vehicle control request can be generated based on vehicle control information through the service module of the atomic service, and the standard vehicle control request can be hash-signed using the control token corresponding to the vehicle identifier to obtain the signature information. If the atomic service is in a preheating state, indicating that the minimum execution environment of the atomic service has been preloaded, that is, the service modules required by the atomic service have been preloaded, then a standard vehicle control request can be generated based on vehicle control information through the service module of the atomic service, and the standard vehicle control request can be hash-signed using the control token corresponding to the vehicle identifier to obtain the signature information. Thus, through the cold start and preheating dual-state scheduling mechanism, differentiated start strategies are adopted for different running states of atomic services. In the preheating state, the pre-loaded minimum execution environment is directly reused, eliminating the environment initialization and module loading process, and further reducing the response time of atomic services.

[0052] In some embodiments, step 202 generates a standard vehicle control request based on vehicle control information through an atomic service, and performs a hash signature on the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain signature information. This can be achieved through steps 221 and 224, or steps 221 to 223 and steps 225 to 228: Step 221: Generate a standard vehicle control request based on vehicle control information through atomic services. The standard vehicle control request includes: vehicle identifier, instruction type, timestamp, device identifier, and instruction sequence number. Step 222: Read the control token corresponding to the vehicle identifier and the signature key corresponding to the control token from the first storage area of ​​the HarmonyOS system; wherein, the control token has a first validity period and vehicle permissions, and the first storage area is an area that only atomic services can read; Step 223: Based on the vehicle control command, the first valid time, and the vehicle permissions, verify the validity of the control token and obtain the verification result; Step 224: If the verification result indicates that the control token time and permissions are valid, use the signature key to perform a hash signature on the standard vehicle control request to obtain the signature information.

[0053] In the embodiments of this application, reference is made to Figure 1 As shown, the atomic service includes service modules such as instruction generation module 121, network communication module 123, authentication module 122, and status update module 124. The instruction generation module is used to generate standard vehicle control requests for control instructions. The authentication module is used to determine the validity of control tokens and refresh tokens. The network communication module is used to set the corresponding communication protocol on the vehicle and send relevant requests using the communication protocol. The status update module is used to update the status of the desktop interactive components based on the vehicle status fed back by the vehicle.

[0054] In this embodiment, reference is continued. Figure 1 The process of obtaining a signed standard vehicle control request includes: First, initializing the atomic service and loading service modules such as the instruction generation module, network communication module, authentication module, and status update module, or preloading multiple service modules from the atomic service. In this way, a modular division of labor architecture with instruction generation module, authentication module, and network communication module is adopted, with clear boundaries of responsibility for each module. The design adapts to the minimum execution environment and loads on demand, eliminating the need to load redundant business units. This improves functional reusability and maintainability, and also ensures the lightweight startup efficiency of the atomic service.

[0055] Secondly, the instruction generation module 121 in the atomic service generates standard data instructions based on vehicle control information, resulting in a standard vehicle control request carrying vehicle identifier, instruction type, timestamp, device identifier, and instruction sequence number. Thus, the standard vehicle control request carries multiple dimensions of fields such as vehicle identifier, instruction type, timestamp, device identifier, and instruction sequence number, providing complete data support for subsequent cloud-based anti-replay verification, operation tracing, and device matching, thereby improving the traceability and transmission security of the control request.

[0056] Then, through the authentication module 122 in the atomic service, the control token corresponding to the vehicle identifier and the signature key corresponding to the control token are read from the first storage area of ​​the HarmonyOS system. In this way, the authentication module directly reads the control token and signature key from the first secure storage area of ​​the HarmonyOS system. The token and signature key reading link is strictly controlled to prevent the token and signature key from being read or stolen by other unauthorized applications or services, further strengthening the security of the storage and retrieval of the control token and signature key.

[0057] Furthermore, based on the vehicle control command for the target function, the valid time, and vehicle permissions, a hierarchical processing strategy is adopted to perform validity checks on the control token. Specifically, based on the valid time of the control token, the validity of the control token's time is verified. If the current system time is within the valid time of the control token, a verification result of valid control token time is obtained; if the current system time is not within the valid time of the control token, a verification result of invalid control token time is obtained. Simultaneously, based on vehicle permissions and the vehicle control command for the target function, the validity of the control token's permissions is verified. If the vehicle control command for the target function is within the vehicle permissions, a verification result of valid control token permissions is obtained; if the vehicle control command for the target function is not within the vehicle permissions, a verification result of invalid control token permissions is obtained. Finally, if the verification result indicates that both the control token's time and permissions are valid, a hash signature is performed on the standard vehicle control request using the signing key to obtain the signature information. If the verification result indicates that the control token's permissions are invalid, the hash signature of the standard vehicle control request is rejected, and the vehicle control request is not sent to the cloud. If the verification result indicates that the control token's permissions are valid but its time is invalid, a refresh token corresponding to the vehicle identifier is obtained through the instruction generation module 121. Then, a new control token with a valid time is obtained through the network communication module 123 to perform a hash signature on the standard vehicle control request. In this way, dual token verification is performed locally on the atomic service, simultaneously verifying the time validity and permission validity of the control token. This eliminates the need to upload requests to the cloud for legitimacy screening, proactively intercepting expired and unauthorized invalid control requests, reducing invalid network interactions, lowering the cloud verification load, and improving the efficiency of responding to and intercepting illegal requests. Furthermore, when the control token's permissions are invalid, signing and sending requests to the cloud are directly rejected, blocking unauthorized control operations at the source and strengthening the security defenses for vehicle control permissions.

[0058] Step 225: If the verification result indicates that the control token is valid but the time is invalid, obtain the refresh token corresponding to the vehicle identifier, wherein the refresh token corresponds one-to-one with the user identifier, vehicle identifier and device identifier; Step 226: Send a control token generation request to the cloud, wherein the control token generation request carries a refresh token; Step 227: Receive the new control token generated in response to the control token generation request from the cloud; Step 228: After confirming that the new control token is valid in terms of time and permissions, use the signing key corresponding to the new control token to perform a hash signature on the standard vehicle control request to obtain the signature information.

[0059] In this embodiment, based on the vehicle control command, validity period, and vehicle permissions of the target function, a hierarchical processing strategy is adopted to detect the validity of the control token. If the detection result indicates that the control token's permissions are valid but its time is invalid, a refresh token corresponding to the vehicle identifier is obtained. The validity period of the refresh token is detected by the authentication module. If the detection result indicates that the time is valid, a control token generation request carrying the refresh token is sent to the cloud. The cloud determines the corresponding vehicle identifier, user identifier, and device identifier based on the refresh token, generates a new control token corresponding to the vehicle identifier, user identifier, and device identifier, and sends it to the electronic device and stores it in the first storage area. The electronic device uses a hierarchical processing strategy to detect the validity of the new control token. If the detection result indicates that the new control token's time and permissions are both valid, the signature key in the new control token is used to hash and sign the standard vehicle control request to obtain the signature information. In this way, when the control token's permissions are valid but the token expires, a new valid control token is automatically and silently obtained through a refresh token. The entire process does not require the user to log in again, and the token renewal is completed seamlessly. This ensures the timeliness and security of the control token while not interrupting the user's remote vehicle control operation process, balancing security and ease of use.

[0060] In some embodiments, to improve subsequent triggering speed, the service module of the atomic service can be preloaded when the atomic service is in a cold start state. Specifically, the load information of the electronic device is monitored. If the load information meets the low load condition, the service module of the atomic service is preloaded and the atomic service is marked as being in a warm-up state. The low load condition includes: the CPU utilization rate is lower than the utilization rate threshold, the free memory is greater than the free memory threshold, and the network is in an idle state.

[0061] In this embodiment, when the atomic service is in a cold start state, the load information of the electronic device is obtained, namely the utilization rate of the Central Processing Unit (CPU), the free memory, and the network status. If the CPU utilization rate is lower than the utilization rate threshold (e.g., 30%), the free memory is greater than the free memory threshold (e.g., 200MB), and the network is idle, it indicates that the load information meets the low load condition. At this time, the preloading process of the atomic service can be triggered, that is, the service module of the atomic service is preloaded. After the preloading is completed, the atomic service is marked as a preheating state. After receiving the user's trigger operation on the desktop interaction component, it directly enters the subsequent control logic, skipping the initial stage of the atomic service, so the startup time can be compressed to within 200 milliseconds (ms). Thus, by monitoring the load information of the electronic device, the preloading process of the atomic service is started when the load information meets the low load condition. In this way, the atomic service directly reuses the preloaded minimum execution environment in the preheating state, saving the environment initialization and module loading process, and further compressing the response time of the atomic service. By adopting a minimal execution environment architecture, only the service modules required for vehicle control are loaded on demand, without loading redundant UI components and unnecessary business modules. This significantly reduces the resource overhead and initialization time of atomic service startup, ensuring the rapid generation of remote vehicle control commands.

[0062] In some embodiments, if at least one of the CPU utilization, free memory, and network status does not meet the low load condition, it indicates that the electronic device is under high load. In this case, the preloading process of atomic services is automatically paused to avoid affecting the foreground application experience.

[0063] Step 203: Send signature information and control token to the cloud via atomic service, so that the cloud can verify and parse the signature information and then forward the vehicle control command to the vehicle corresponding to the vehicle identifier.

[0064] Step 204: Receive feedback information from the cloud after the vehicle executes the vehicle control command via atomic service.

[0065] The feedback information includes one or more of the following: execution result, vehicle status, and fault code.

[0066] Step 205: Update the status of the desktop interactive components based on the feedback information through the atomic service and display the execution result. If the execution result indicates that the execution was successful, automatically release the process and resources of the atomic service.

[0067] In this embodiment, reference is continued. Figure 1The electronic device sends signature information and a control token to the cloud 131 through the network communication module 123 of the atomic service. The cloud 131 obtains the signature key corresponding to the control token, verifies the signature information using the signature key, and after successful verification, obtains and parses the standard vehicle control request to obtain the vehicle control command corresponding to the instruction sequence number in the standard vehicle control request. The vehicle control command is then sent to the vehicle corresponding to the vehicle identifier. The vehicle sends the vehicle control command to the corresponding actuator 133 through the T-BOX 132. The actuator 133 executes the vehicle control command and generates feedback information, which includes one or more of the following: execution result, current vehicle status, and fault code. The vehicle forwards the feedback information to the atomic service through the cloud. The status update module 124 of the atomic service updates the status of the desktop interactive component according to the feedback information and displays the execution result. If the execution result indicates successful execution, the process and resources of the atomic service are automatically released.

[0068] The following describes a vehicle control method based on atomic services provided in this application through a specific embodiment.

[0069] This application proposes a lightweight vehicle control interaction method based on HarmonyOS atomic services (corresponding to the above-mentioned vehicle control method based on atomic services). It utilizes the system-level capabilities of HarmonyOS atomic services, such as installation-free, lightweight startup, and on-demand loading, to construct a lightweight vehicle control execution link independent of the complete application. Through control token mechanism, cold start optimization mechanism, and weak network compensation mechanism, it achieves low latency, high security, and high availability remote vehicle control capabilities.

[0070] The overall architecture provided in this application embodiment involves, for example, the following: Figure 1 As shown, the traditional vehicle control mode is divided into three layers from a system architecture perspective: the interaction trigger layer, the atomic service execution layer, and the remote execution layer. The interaction trigger layer receives user operations, including desktop service cards, quick access points, the negative one screen service entry point, voice call entry point, and watch quick control entry point. This interaction trigger layer does not depend on the application's main interface and does not trigger the complete app lifecycle. The atomic service execution layer is based on HarmonyOS atomic services to implement a lightweight Ability container, independent lifecycle management, and an on-demand loading execution mechanism. Independent lifecycle management can be implemented as an atomic service execution process: launch → execute → release, without long-term background persistence, reducing system resource consumption and improving overall system responsiveness. The on-demand loading execution mechanism allows atomic services to load only the instruction generation module, authentication module, network communication module, and status update module, without loading complex UI rendering, unnecessary business modules, or redundant third-party SDKs, significantly reducing startup time and memory usage. The remote execution layer includes cloud control services, vehicle TBOX / gateway, in-vehicle central gateway, and actuators to complete the actual control command execution and real-time status feedback.

[0071] Below, in conjunction with Figure 1 ,as well as Figure 3 , Figure 4 and Figure 5 The following examples illustrate this solution.

[0072] Example 1: System Initialization and Runtime Environment Configuration In this embodiment, the electronic device is a smart terminal running HarmonyOS 5.0 or later, including smartphones, smartwatches, and tablets. The device has a built-in standard atomic service runtime environment and distributed soft bus capabilities. For example... Figure 3 As shown, the system initialization phase is performed according to the following steps.

[0073] Step 301: The user logs in to the vehicle control APP.

[0074] Here, when a user opens the full vehicle control application for the first time and completes account login, the application sends an identity authentication request to the cloud control platform after successful login.

[0075] Step 302: Issue refresh tokens and control tokens from the cloud.

[0076] Here, after the cloud completes identity verification based on the identity authentication request, it generates a standard session refresh token (corresponding to the refresh token mentioned above). At the same time, it generates a dedicated control token (corresponding to the control token mentioned above) based on the vehicle ID, user ID, device ID, and authorization scope. This token has an independent signature key, a fixed validity period, and minimum control permissions.

[0077] Step 303: Store the control token in the secure storage area of ​​the HarmonyOS system.

[0078] Here, the terminal refreshes the token for the entire application session and encrypts and stores the control token in the HarmonyOS secure storage area, such as the TEE secure environment, system key chain, or security components. Only designated atomic services are allowed to read it; other applications or services have no access. Subsequently, when using atomic services, they can read the control token from the secure storage area and verify its validity period and permissions for subsequent signing.

[0079] Step 304: Create a universal vehicle control card.

[0080] Here, you can create a universal vehicle control card on the device's desktop, which supports common functions such as unlocking, locking, turning on the air conditioning, and locating the vehicle.

[0081] Step 305: Register and configure the atomic service, and bind the vehicle control universal card to the corresponding atomic service entry.

[0082] Here, the atomic service Ability is registered in the system, and static permissions, startup mode, and preloaded module loading priority are configured so that it can be quickly scheduled by the system and run without installation. The vehicle control universal card is then bound to the corresponding atomic service entry point.

[0083] Step 306: Turn on the preload switch.

[0084] Here, enabling the preload switch will automatically trigger the preload of the atomic service basic environment when the system CPU, memory, and network are under low load, marking the service status as WARM to improve the subsequent triggering speed.

[0085] Example 2: Control Request Triggering and Complete Processing Flow When a user clicks the control buttons in the desktop service card, such as unlocking the vehicle, closing the windows, turning on the air conditioning, or locating the car, etc., Figure 4 As shown, the system executes according to the following process: Step 401, User Operation.

[0086] Here, user click events are identified, event types and corresponding control commands are parsed, and the unique identifier of the target vehicle is determined.

[0087] Step 402: Atomic service is started.

[0088] Here, the corresponding atomic service is quickly launched through the HarmonyOS standard atomic service scheduling interface without starting the full application process or triggering the main application lifecycle.

[0089] Step 403: Load the minimum module.

[0090] Here, after the atomic service starts, only the minimum execution environment of the atomic service is initialized, that is, the instruction generation module, network communication module, authentication module, and status update module are loaded, and redundant UI components and business modules are not loaded.

[0091] Step 404: Control token authentication.

[0092] Here, the control token stored in the encrypted storage area is read from the secure storage area, and the validity of the control token is verified, namely the validity period and the scope of permissions. If the control token has expired, a silent background refresh is triggered by refreshing the token to obtain a new control token without interfering with user operations.

[0093] Step 405: Command Construction and Sending.

[0094] Here, a standard control request data structure is constructed, including vehicle ID, command type, timestamp, random number, device identifier, and command sequence number, ensuring request uniqueness and replay protection. Then, a control token is used to hash-sign the request data, generating tamper-proof and verifiable signature information to ensure secure and reliable transmission. Finally, the signed request data and control token are sent to the cloud via a lightweight network channel using a compression protocol and short connection method, reducing network latency.

[0095] Step 406: Cloud forwarding, vehicle-side execution.

[0096] Here, after receiving the request, the cloud obtains the corresponding signing key based on the control token, and verifies the token's validity, vehicle status, and user permissions using the token signing key. After successful verification, it forwards the request to the corresponding vehicle TBOX or in-vehicle gateway. After receiving the instruction, the vehicle executes the corresponding control operation, such as unlocking the doors, starting the air conditioning, or opening and closing the windows, and returns the execution result, vehicle status, and fault codes (if any) in real time.

[0097] Step 407: Result returned.

[0098] Here, the atomic service receives the results returned from both the cloud and the vehicle.

[0099] Step 408: Card Update.

[0100] Here, the atomic service updates the desktop service card status, displays the execution result, and triggers vibration or prompts based on the returned result.

[0101] Step 409: Atomic services are automatically released.

[0102] Here, the atomic service automatically releases the process and resources after execution, completing a short lifecycle loop.

[0103] It's important to note that the control token mechanism is a lightweight authentication mechanism. Specifically, the control token generation mechanism works as follows: after a user logs in to the app, a standard refresh token is generated in the cloud, along with a dedicated control token. The control token usage mechanism involves: the control token being cached securely in HarmonyOS system storage and directly accessed by atomic services for rapid signing and authentication. The control token's constraint mechanism includes: a validity period of 5-30 minutes, enabling only vehicle control permissions, support for dynamic background refresh, and automatic expiration. Thus, the essence of using a control token is to separate identity authentication from control authorization, achieving lightweight, highly secure, and low-latency authentication.

[0104] Example 3: Control Execution State Machine and Process Management This application defines a standardized control execution state machine: INIT→SENT→ACK→DONE / FAIL, where each state has a clear meaning and processing logic. INIT status: Indicates that the request has been created and is in the process of parameter assembly, token verification, and signature calculation; SENT status: Indicates that the request has been sent to the cloud via the network and is awaiting confirmation from the cloud; ACK status: This indicates that the cloud has successfully received and verified the request and has forwarded it to the vehicle. DONE status: Indicates that the vehicle has successfully executed the command and the control process has ended normally; FAIL status: indicates that an error has occurred in any step, such as token expiration, network timeout, no response from the vehicle, or execution failure.

[0105] By using state machine management, control processes can be traced, anomalies can be recovered, and failures can be compensated, ensuring that user operations are perceptible and traceable, thereby improving overall control reliability and user experience.

[0106] Example 4: Implementation details of atomic services based on ArkTS The atomic service in this application embodiment is developed using the HarmonyOS ArkTS language and implemented based on the lightweight Ability framework. The core code logic is as follows: class AtomicVehicleControlService { / / Atomic vehicle control service onStart(): void { this.initServiceContext(); / / Initialize the service this.loadMinimalModules(); / / Load lightweight modules this.prepareNetwork(); / / Initialize the network channel in advance. } async handleControlCommand(cmdType: string): Promise <void> / / Asynchronous vehicle control command processing let vehicleId = await VehicleManager.getCurrentVehicleId(); / / Get vehicle identifier let token = await SecureStorage.getEncryptedToken("CONTROL_TOKEN") / / Read the control token if (TokenValidator.isExpired(token)) { token = await TokenSilentRefresher.refreshToken() / / Refresh the token after it expires. } let request = ControlRequestBuilder.build(vehicleId, cmdType) / / Build standard request data let signature = CryptoUtil.signRequest(request, token) / / Request data signature let response = await LiteNetworkClient.send(request, signature) CardUpdater.updateStatus(response) Card Update } } The code above implements atomic service startup, minimized module loading, token reading, request construction, signature sending, and status updating, fully complying with the HarmonyOS atomic service development specifications.

[0107] Example 5: Cold Start Optimization and Preloading Strategy To further reduce startup latency, such as Figure 5 As shown, an intelligent preloading mechanism is adopted.

[0108] Step 501: Preload the atomic service basic environment.

[0109] Here, the current load status is monitored in real time. When CPU usage is below 30%, memory free is greater than 200MB, and the network is idle, a preloading process is triggered. Preloading includes loading the control module class, initializing the network connection pool, preparing the authentication module, pre-setting certificates, and warming up the signature tool. Thus, when the device is idle, the basic environment for atomic services is preloaded and network connections are initialized. Of course, if the system is under high load, preloading is automatically paused to avoid impacting the foreground application experience.

[0110] Step 502, Preheating Status Here, after preloading is complete, the atomic service is marked as warm-up.

[0111] Step 503: User-triggered operation, quick execution, instruction execution completed, and resources automatically released.

[0112] Here, when the atomic service is in a warm state, it directly enters the control logic when the user triggers it, skips the initialization phase, and performs subsequent instruction execution and resource release, thus returning to the cold start state. In this way, it does not occupy background resources and realizes the lightweight concept of "use and go". In this way, the startup time can be compressed to less than 200ms.

[0113] Step 504: The user has not triggered the function for an extended period of time.

[0114] Step 505: Return to cold start state.

[0115] Step 506: Automatic recycling.

[0116] Here, if the user does not interact with the desktop for an extended period of time, the atomic service returns to a cold start state, or the electronic device can automatically reclaim the atomic service.

[0117] As can be seen from the above, the beneficial effects of the embodiments of this application are as follows: control latency is reduced by 50% to 80%, and response speed is significantly improved; startup time is reduced to the 200ms level, achieving millisecond-level response; network failure rate is reduced by about 30%, and stability in weak networks is greatly improved; system resource consumption is reduced by more than 70%, and CPU and memory consumption are minimal; no need to start the full APP, simplifying the operation steps; lightweight authentication does not rely on login state, balancing security and convenience.

[0118] This application provides a vehicle control device based on atomic services, referring to... Figure 6 As shown, Figure 6 This application provides a schematic diagram of the structure of a vehicle control device based on atomic services, the vehicle control device 6 based on atomic services includes: The receiving module 601 is used to receive operation commands triggered by the user on the desktop interactive component of the electronic device; The module 602 is used to obtain the vehicle control information corresponding to the operation command and launch the atomic service bound to the desktop interaction component; wherein, the desktop interaction component integrates some basic control functions of the vehicle control application, and the vehicle control information includes the vehicle identifier and the vehicle control command corresponding to the target function; Processing module 603 is used to generate a standard vehicle control request based on vehicle control information through atomic services, and to perform a hash signature on the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain signature information; The sending module 604 is used to send signature information and control token to the cloud through atomic service, so that the cloud can verify the signature information based on the control token and then forward the vehicle control command to the vehicle corresponding to the vehicle identifier. The receiving module 601 is also used to receive feedback information generated after the vehicle executes the vehicle control command, returned from the cloud via an atomic service; wherein the feedback information includes one or more of the following: execution result, vehicle status, and fault code; The processing module 603 is also used to update the state of the desktop interactive components based on the feedback information through the atomic service and display the execution result. If the execution result indicates that the execution was successful, the process and resources of the atomic service are automatically released.

[0119] This application provides a hardware entity diagram of an electronic device, such as... Figure 7 As shown, the hardware entity of the electronic device 7 includes a processor 701 and a memory 702. The memory 702 stores a computer program that can run on the processor 701. When the processor 701 executes the computer program, it implements some or all of the steps in the vehicle control method based on atomic services as described in the above embodiments.

[0120] The memory 702 stores computer programs that can run on the processor. The memory 702 is configured to store instructions and applications that can be executed by the processor 701. It can also cache data to be processed or already processed by the processor 701 and various modules in the electronic device 7 (e.g., image data, audio data, voice communication data and video communication data). It can be implemented by flash memory or random access memory (RAM).

[0121] Specifically, when the processor 701 executes the program, it implements the steps of the vehicle control execution method based on atomic services mentioned above. The processor 701 typically controls the overall operation of the electronic device 7.

[0122] This application provides a computer-readable storage medium storing one or more computer programs, which can be executed by one or more processors to implement some or all of the steps in the above-described method. The storage medium can be transient or non-transient.

[0123] This application provides a computer program including computer-readable code, wherein when the computer-readable code is run in a vehicle, a processor in the vehicle executes some or all of the steps in the above-described method.

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

[0125] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0126] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0127] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0128] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0129] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

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

[0131] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0132] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0133] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0134] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an in-vehicle terminal (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0135] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.< / void>

Claims

1. A vehicle control method based on atomic services, characterized in that, The method, applied to electronic devices equipped with the HarmonyOS operating system, includes: The system receives operation commands triggered by the user on the desktop interactive component of the electronic device, obtains the vehicle control information corresponding to the operation commands, and launches the atomic service bound to the desktop interactive component; wherein, the desktop interactive component integrates some basic control functions of the vehicle control application, and the vehicle control information includes vehicle identification and vehicle control commands corresponding to the target function; The atomic service generates a standard vehicle control request based on vehicle control information, and performs a hash signature on the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain signature information. The signature information and the control token are sent to the cloud through the atomic service, so that the cloud verifies and parses the signature information based on the control token and then forwards the vehicle control command to the vehicle corresponding to the vehicle identifier. The atomic service receives feedback information returned from the cloud after the vehicle executes the vehicle control command; wherein the feedback information includes one or more of the following: execution result, vehicle status, and fault code; The atomic service updates the state of the desktop interaction component based on the feedback information and displays the execution result. If the execution result indicates successful execution, the process and resources of the atomic service are automatically released.

2. The method according to claim 1, characterized in that, The process involves generating a standard vehicle control request based on vehicle control information via the atomic service, and performing a hash signature on the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain signature information, including: The atomic service generates a standard vehicle control request based on vehicle control information, wherein the standard vehicle control request includes: vehicle identifier, instruction type, timestamp, device identifier, and instruction sequence number; The control token corresponding to the vehicle identifier and the signature key corresponding to the control token are read from the first storage area of ​​the HarmonyOS system; wherein, the control token has a validity period and vehicle permissions, and the first storage area is a secure storage area that can only be read by the atomic service; Based on the vehicle control command, the validity period, and the vehicle permissions, the validity of the control token is verified to obtain the verification result; If the verification result indicates that the control token time and permissions are valid, the standard vehicle control request is hashed and signed using the signature key to obtain the signature information.

3. The method according to claim 2, characterized in that, The method further includes: If the verification result indicates that the control token is valid but the time is invalid, a refresh token corresponding to the vehicle identifier is obtained, wherein the refresh token corresponds one-to-one with the user identifier, vehicle identifier and device identifier; Send a control token generation request to the cloud, wherein the control token generation request carries the refresh token; Receive the new control token generated in response to the control token generation request returned by the cloud; If it is determined that the new control token is valid in both time and permission, the standard vehicle control request is hashed and signed using the signing key corresponding to the new control token to obtain the signature information.

4. The method according to claim 1, characterized in that, The method further includes: Monitor the load information of the electronic device. If the load information meets the low load condition, preload the service module of the atomic service and mark the atomic service as being in a preheating state. The low load condition includes: CPU utilization is below a utilization threshold, free memory is above a free memory threshold, and the network is idle; or... If the atomic service is in a cold start state, initialize the atomic service and load the service module of the atomic service.

5. The method according to any one of claims 1 to 4, characterized in that, Before receiving the operation command triggered by the user's desktop interaction component on the electronic device, the method further includes: In response to the user logging into the vehicle control application, an identity authentication request is sent to the cloud, so that the cloud generates a refresh token, a control token, and a signature key corresponding to the control token after completing the identity verification. The identity authentication request includes: the vehicle identifier, the user identifier, the device identifier, and the vehicle permissions; the control token has a validity period and vehicle permissions. Receive the refresh token, the control token, and the signature key sent by the cloud, store the control token and the signature key in a first storage area, and store the refresh token in a second storage area; Create desktop interaction components corresponding to some basic control functions in the vehicle control application, register and configure the atomic services, and bind the desktop interaction components to the entry points of the atomic services.

6. The method according to any one of claims 1 to 4, characterized in that, The service modules of the atomic service include an instruction generation module, a network communication module, an authentication module, and a status update module.

7. The method according to any one of claims 1 to 4, characterized in that, The atomic service that is bound to the desktop interaction component is launched, including: The atomic service bound to the desktop interaction component is launched through the standard atomic service scheduling interface of the HarmonyOS system, without starting the process of the vehicle control application.

8. A vehicle control device based on atomic services, characterized in that, include: The receiving module is used to receive operation commands triggered by the user on the desktop interactive components of the electronic device; The acquisition module is used to acquire the vehicle control information corresponding to the operation command and launch the atomic service bound to the desktop interaction component; wherein, the desktop interaction component integrates some basic control functions of the vehicle control application, and the vehicle control information includes the vehicle identifier and the vehicle control command corresponding to the target function; The processing module is used to generate a standard vehicle control request based on vehicle control information through the atomic service, and to perform a hash signature on the standard vehicle control request based on the control token corresponding to the vehicle identifier to obtain signature information; The sending module is used to send the signature information and the control token to the cloud through the atomic service, so that the cloud verifies and parses the signature information based on the control token and then forwards the vehicle control command to the vehicle corresponding to the vehicle identifier. The receiving module is further configured to receive feedback information returned by the cloud after the vehicle executes the vehicle control command, via the atomic service; wherein the feedback information includes one or more of the following: execution result, vehicle status, and fault code; The processing module is also used to update the state of the desktop interaction component according to the feedback information through the atomic service, and display the execution result. If the execution result indicates successful execution, the process and resources of the atomic service are automatically released.

9. An electronic device, characterized in that, include: Memory is used to store executable instructions or computer programs. A processor is configured to implement the vehicle control method based on atomic services as described in any one of claims 1 to 7 when executing computer-executable instructions or computer programs stored in the memory.

10. A computer-readable storage medium, characterized in that, It stores a computer program or computer-executable instructions for implementing the vehicle control method based on atomic services as described in any one of claims 1 to 7 when executed by a processor.

Images