Vehicle remote control method, system, electronic device and storage medium

Abstract

The application provides a vehicle remote control method, system, electronic equipment and storage medium. A mobile terminal pre-processes original voice data input by a user, verifies the pre-processed voice data based on preset voiceprint information, and sends the pre-processed voice data to the cloud when the pre-processed voice data passes the verification. The cloud determines the risk level of the pre-processed voice data based on a preset risk engine, and sends a voice instruction to the vehicle end based on the risk level and a TSP platform, so that the vehicle end checks the received voice instruction and executes the voice instruction that passes the check. The application can reduce the risk of voiceprint information being stolen and misused, reduce the cost of hardware modification of the vehicle end, and also help to ensure the effectiveness of vehicle remote control in a weak network scenario.

Description

Technical Field

[0001] This invention relates to the field of vehicle control technology, and in particular to a vehicle remote control method, system, electronic device, and storage medium. Background Technology

[0002] Currently, mainstream remote vehicle control technologies primarily rely on cloud-based voice recognition to parse control commands and indirectly verify identity by combining account binding relationships. However, existing remote vehicle control technologies mainly depend on stable networks and cloud computing power, requiring the uploading of complete original voice data to the cloud for recognition and comparison. This poses a risk of user voice biometric information being stolen or misused, and it is impossible to distinguish control permissions based on user identity, creating a security risk of others impersonating users to control the vehicle using voice commands. Furthermore, remote vehicle control often fails completely in scenarios with weak network coverage, such as underground parking garages and remote areas. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a vehicle remote control method, system, electronic device and storage medium to alleviate the above-mentioned problems existing in the related art.

[0004] In a first aspect, embodiments of the present invention provide a method for remote vehicle control, comprising: a mobile terminal preprocessing raw voice data input by a user, and verifying the preprocessed voice data based on preset voiceprint information; and sending the preprocessed voice data to the cloud when the verification of the preprocessed voice data is successful; the cloud determining the risk level of the preprocessed voice data based on a preset risk engine, and sending voice commands to the vehicle based on the risk level and the vehicle information service provider platform; and the vehicle verifying the received voice commands and executing the verified voice commands.

[0005] Secondly, embodiments of the present invention also provide a vehicle remote control method applied in the cloud, comprising: receiving preprocessed voice data sent by a mobile terminal; the mobile terminal being used to preprocess the original voice data input by a user to obtain the preprocessed voice data, and to verify the preprocessed voice data based on preset voiceprint information, and to send the preprocessed voice data to the cloud when the verification of the preprocessed voice data is passed; determining the risk level of the preprocessed voice data based on a preset risk engine, and sending voice commands to the vehicle based on the risk level and the vehicle information service provider platform; the vehicle being used to verify the received voice commands and execute the verified voice commands.

[0006] Thirdly, embodiments of the present invention also provide a vehicle remote control system, comprising: a mobile terminal, configured to preprocess raw voice data input by a user, and verify the preprocessed voice data based on preset voiceprint information, and send the preprocessed voice data to the cloud when the verification of the preprocessed voice data is successful; the cloud, configured to determine the risk level of the preprocessed voice data based on a preset risk engine, and send voice commands to the vehicle based on the risk level and the vehicle information service provider platform; and the vehicle, configured to verify the received voice commands and execute the verified voice commands.

[0007] Fourthly, embodiments of the present invention also provide an electronic device, including a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the vehicle remote control method described in the first or second aspect above.

[0008] Fifthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the vehicle remote control method described in the first or second aspect above.

[0009] This invention provides a vehicle remote control method, system, electronic device, and storage medium. The mobile terminal preprocesses the raw voice data input by the user and verifies the preprocessed voice data based on preset voiceprint information. When the preprocessed voice data passes verification, it sends the preprocessed voice data to the cloud. The cloud determines the risk level of the preprocessed voice data based on a preset risk engine and sends voice commands to the vehicle based on the risk level and the TSP platform, so that the vehicle can verify the received voice commands and execute the verified voice commands. Using the above technology, voice data can be verified on the mobile terminal side and sent to the cloud when verification is successful. Then, on the cloud side, a preset risk engine determines the risk level of the voice data and sends voice commands to the vehicle via the TSP platform. Finally, the voice commands are verified on the vehicle side and executed when verification is successful. There is no need to upload the relevant voiceprint information used to verify the voice data to the cloud, which can greatly reduce the risk of voiceprint information being stolen or misused. Moreover, the calculation is mainly performed on the mobile terminal side and the cloud side, eliminating the need to deploy high-computing models on the vehicle side, which can reduce the cost of vehicle hardware modification. At the same time, it avoids the impact of cloud computing being too concentrated or network latency affecting the control response speed, which helps to ensure the effectiveness of remote vehicle control in weak network scenarios.

[0010] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0011] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0012] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating a vehicle remote control method according to an embodiment of the present invention; Figure 2 This is a logical block diagram of the overall architecture of the vehicle remote control system in this embodiment of the invention; Figure 3 This is a schematic diagram of the deployment structure of the mobile terminal (device side) in an embodiment of the present invention; Figure 4 This is a schematic diagram of the cloud deployment structure in an embodiment of the present invention; Figure 5 This is a flowchart illustrating Example 1 in an embodiment of the present invention; Figure 6 This is a flowchart illustrating another vehicle remote control method in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0015] Currently, existing remote vehicle control technologies mainly rely on stable networks and cloud computing power. They require uploading complete, original voice data to the cloud for recognition and comparison, posing a risk of theft and misuse of user voice biometric information. Furthermore, the inability to distinguish control permissions based on user identity creates a security vulnerability, allowing unauthorized individuals to control the vehicle using voice commands. In addition, remote vehicle control often fails completely in scenarios with weak network coverage, such as underground parking garages and remote areas. Therefore, this invention provides a vehicle remote control method, system, electronic device, and storage medium that can alleviate the aforementioned problems in related technologies.

[0016] To facilitate understanding of this embodiment, a vehicle remote control method disclosed in this invention will first be described in detail, see [link to relevant documentation]. Figure 1 As shown, the method may include the following steps: In step S102, the mobile terminal preprocesses the raw voice data input by the user, verifies the preprocessed voice data based on preset voiceprint information, and sends the preprocessed voice data to the cloud when the verification of the preprocessed voice data is successful.

[0017] In step S104, the cloud determines the risk level of the preprocessed voice data based on a preset risk engine, and sends voice commands to the vehicle based on the risk level and the TSP platform.

[0018] Step S106: The vehicle verifies the received voice command and executes the voice command if the voice command verification is successful.

[0019] This invention provides a vehicle remote control method in which a mobile terminal preprocesses the raw voice data input by the user and verifies the preprocessed voice data based on preset voiceprint information. When the preprocessed voice data passes verification, it is sent to the cloud. The cloud determines the risk level of the preprocessed voice data based on a preset risk engine and sends voice commands to the vehicle based on the risk level and the TSP platform, so that the vehicle can verify the received voice commands and execute the verified voice commands. Using the above technology, voice data can be verified on the mobile terminal side and sent to the cloud when verification is successful. Then, on the cloud side, a preset risk engine determines the risk level of the voice data and sends voice commands to the vehicle via the TSP platform. Finally, the voice commands are verified on the vehicle side and executed when verification is successful. There is no need to upload the relevant voiceprint information used to verify the voice data to the cloud, which can greatly reduce the risk of voiceprint information being stolen or misused. Moreover, the calculation is mainly performed on the mobile terminal side and the cloud side, eliminating the need to deploy high-computing models on the vehicle side, which can reduce the cost of vehicle hardware modification. At the same time, it avoids the impact of cloud computing being too concentrated or network latency affecting the control response speed, which helps to ensure the effectiveness of remote vehicle control in weak network scenarios.

[0020] As one possible implementation, the raw voice data can be acquired by at least two voice acquisition devices; the preprocessing of the raw voice data input by the user in step S102 above may include: beamforming (BF) and acoustic echo cancellation (AEC) on the raw voice data.

[0021] Taking a mobile phone as an example, the phone can be equipped with two microphones (one is the main microphone and the other is a noise-canceling microphone). The phone can collect the voice data input by the user into the phone as the target voice through dual microphone pickup. Then, BF is performed on the target voice to enhance it, and AEC is performed on the enhanced voice to eliminate environmental noise. The signal-to-noise ratio (SNR) of the processed voice is improved (for example, by 8dB).

[0022] As one possible implementation, the preset voiceprint information may include at least one first voiceprint information corresponding to a known identity; based on this, the verification of the preprocessed speech data based on the preset voiceprint information in step S102 above may include: using a preset voiceprint model to extract voiceprint features from the preprocessed speech data and the first voiceprint information respectively, and performing a first comparison on the different voiceprint features obtained, so as to determine whether the preprocessed speech data has passed the verification based on the first comparison result; wherein, the preset voiceprint model is obtained by quantizing the original voiceprint model.

[0023] Continuing the previous example, a pre-trained voiceprint model, obtained by INT8 quantization of the original voiceprint model (such as the x-vector model), can be pre-deployed on the mobile phone. At least one pre-recorded voiceprint template corresponding to a known identity of the user can be stored on the phone (encrypted or unencrypted). The training dataset for this voiceprint model contains in-vehicle environment speech (e.g., 65dB(A) noise) from multiple people (e.g., 1200 people) of different ages (e.g., 18-60 years old), various accents (e.g., 6 accents). The processed speech obtained by passing the target speech through BF and AEC, along with the pre-stored voiceprint templates, are input into the voiceprint model for feature extraction. The voiceprint model converts the processed speech and each voiceprint template into corresponding feature vectors and outputs them. The log-likelihood ratio (LLR) between different feature vectors is calculated using Probabilistic Linear Discriminant Analysis (PLDA) as the spatial similarity (i.e., similarity score). The specific calculation process for the similarity score can be expressed as: score = PLDA(embedding_test, embedding_enroll) is a similarity comparison function. `score` represents the similarity score, `embedding_test` is the feature vector corresponding to the speech to be verified (i.e., the processed speech), and `embedding_enroll` is the feature vector corresponding to the registered speech (i.e., the user's pre-recorded voiceprint template). The PLDA comparison threshold θ_mobile = 0.68 can be set (optimized using the ROC curve to ensure that the false acceptance rate (FAR) ≤ 0.05% and the false rejection rate (FRR) ≤ 0.46%). If a voiceprint template corresponding to a feature vector with a similarity score not less than θ_mobile is found, the preprocessed speech data is considered verified successfully. If no voiceprint template corresponding to a feature vector with a similarity score not less than θ_mobile is found, the preprocessed speech data is considered to have failed verification.

[0024] As one possible implementation, the step S102 above, which involves sending the preprocessed voice data to the cloud when the preprocessed voice data verification is successful, may include: if the preprocessed voice data verification is successful, generating a one-time dynamic password token and sending the one-time dynamic password token and the preprocessed voice data to the cloud.

[0025] Accordingly, the above-mentioned vehicle remote control method may also include: cloud-based verification of a one-time dynamic password token, so as to determine the risk level of the preprocessed voice data based on a preset risk engine when the one-time dynamic password token passes verification.

[0026] Continuing from the previous example, the voice verification process on the mobile phone backend (including feature extraction and similarity score calculation) automatically issues a P-Token (i.e., a one-time dynamic password token) and sends it to the cloud after the processed voice verification is successful. After the cloud verifies the P-Token, it generates a CmdPkg (i.e., a voice command) using the processed voice. The data format of the P-Token is shown in Table 1, and the data format of the CmdPkg is shown in Table 2.

[0027] Table 1. Example of P-Token data format

[0028] Table 2. Example of data format for CmdPkg

[0029] As one possible implementation, the steps of sending a one-time dynamic password token and preprocessed voice data to the cloud may include: compressing and encoding the preprocessed voice data, and encrypting and transmitting the one-time dynamic password token and compressed and encoded voice data to the cloud.

[0030] Accordingly, the above-mentioned vehicle remote control method may further include: decrypting the encrypted voice data in the cloud to obtain compressed and encoded voice data, and decoding the compressed and encoded voice data to obtain preprocessed voice data.

[0031] Following the previous example, the phone temporarily stores the processed voice in its memory and performs Opus compression encoding on the processed voice. Then, it encrypts and uploads the P-Token and the Opus voice (i.e., the voice obtained by Opus compression encoding the processed voice) together to the cloud. The cloud decrypts and decompresses the encrypted voice to obtain the processed voice.

[0032] As one possible implementation, the step S104 above, which determines the risk level of the preprocessed speech data based on a preset risk engine, may include: performing first speech recognition on the preprocessed speech data to obtain first text; if the confidence level of the first text is not lower than a preset confidence level, then performing intent recognition and parameter extraction on the first text, and determining the risk level based on the intent recognition result and the parameter extraction result using a preset risk engine.

[0033] Following the previous example, Automatic Speech Recognition (ASR) models, Natural Language Processing (NLP) models, and risk engines can be pre-deployed in the cloud; The parameters and performance of an ASR model (e.g., Conformer-L) can be mainly described as follows: 12 encoder layers, 8 attention heads, 16kHz / 16bit mono input, beam search (beam size=4), and low word error rate (e.g., the error rate was only 2.8% after testing the ASR model with 5000 in-vehicle voice messages).

[0034] The parameters and performance of an NLP model (e.g., using BERT-Base) can mainly include: 12-layer transformer, 768-dimensional hidden layers, fine-tuning datasets including a large number of vehicle control commands (e.g., 100,000 vehicle control commands), high intent recognition accuracy (e.g., 97.2%), and high parameter extraction accuracy (e.g., 98.5%).

[0035] The parameters and performance of a risk engine (e.g., an architecture combining a rule engine and a LightGBM model) can mainly include: multiple (e.g., 10) basic rules, a multi-dimensional (e.g., 15-dimensional) feature model, a high misclassification rate (e.g., 0.12%), and a short response time (e.g., ≤50ms); the speech risk level determination strategy is shown in Table 3). Table 3. Example of Voice Risk Level Determination Strategy

[0036] The cloud verifies the P-Token uploaded by the mobile phone (specifically, it verifies fields such as Sig_P, ts, and nonce in the P-Token) to confirm the legitimacy of the user's identity. After the P-Token verification is successful, the cloud uses an ASR model to convert the processed speech into text. If the confidence score of the obtained text is not less than a preset threshold (e.g., 0.8), the NLP model is used to perform intent parsing and parameter parsing on the obtained text. After the cloud maps the CmdID, the risk engine finally determines the risk level based on the parsed intent and parameters and the rules corresponding to the CmdID.

[0037] As one possible implementation, the operation of sending voice commands to the vehicle based on the risk level and the TSP platform in step S104 above can be divided into the following three cases: (1) If the risk level is medium risk, a security code is sent to the mobile terminal so that the mobile terminal can verify the user's voice input data based on the security code and send the voice input data to the cloud when the voice input data is verified; the voice input data is verified and the TSP platform is used to send voice commands to the vehicle when the voice input data is verified.

[0038] (2) If the risk level indicates low risk, then send voice commands directly to the vehicle.

[0039] (3) If the risk level indicates high risk, no voice command will be generated.

[0040] As one possible implementation, the steps for verifying user-inputted voice input data based on the security code may include: performing a second speech recognition on the voice input data to obtain a second text; performing a second comparison between the second text and the security code to determine whether the voice input data has been verified based on the second comparison result.

[0041] Following the previous example, see Figure 2 As shown, a lightweight ASR model (such as the Tiny-ASR model) can also be pre-deployed on the mobile phone. The parameters and performance of the lightweight ASR model can mainly include: support for multiple (e.g., 100) whitelisted speech recognition, low word error rate (e.g., ≤4%), and support for recognizing speech with SNR within a certain range (e.g., SNR range of -10dB to 20dB). If the cloud-based risk engine determines the security code to be of medium risk, it generates a security code and pushes it to the mobile phone. The mobile phone displays the security code and provides prompts (such as displaying and / or playing a prompt message reminding the user to enter the security code). The user repeats the security code to the mobile phone to input the corresponding voice (i.e., security code voice). The mobile phone uses a lightweight ASR model to recognize the security code voice and outputs the corresponding text (i.e., security code text). The mobile phone then uploads the security code text to the cloud. The mobile phone calculates the first text similarity between the security code text and the security code. If the first text similarity is greater than a first threshold (e.g., 0.65), the security code voice verification on the mobile phone side passes. If the first text similarity is not greater than the first threshold, the security code voice verification on the mobile phone side fails. The cloud calculates the second text similarity between the security code text and the security code. If the second text similarity is greater than the second threshold, the security code voice verification on the cloud side passes. If the second text similarity is not greater than the second threshold, the security code voice verification on the cloud side fails. If the security code voice verification passes on both the mobile phone and cloud sides, the cloud fills in the values ​​of fields such as VehicleID, CmdID, ts, and nonce according to the data format shown in Table 2 to complete the assembly of the instruction data packet CmdPkg. Then, the cloud performs digital signature calculation using its private key to generate a security signature Sig_AI. Finally, Sig_AI and CmdPkg are combined to form an instruction message, completing the full issuance of CmdPkg. The cloud adds the fully issued CmdPkg to a gray list (indicating medium risk) dedicated scheduling queue through the TSP platform. Following the medium-risk control logic, the instruction message is sent to the vehicle after a certain delay (e.g., 2 seconds), reserving a window for manual intervention to cancel the voice command in an emergency stop (just before the full signature is issued). The CmdPkg message is delayed in being sent to the vehicle. The vehicle uses a T-Box to call the locally trusted comparison criteria pre-set at the factory to perform the following multi-dimensional verifications on the received command message: the command message header is compared with the locally pre-set standard protocol version; the VehicleID of the command message is compared with the locally fixed unique vehicle identifier; the legality of the Sig_AI of the command message is verified with the locally pre-stored public key (provided by the cloud and corresponding to the above private key); the validity of the ts of the command message is verified in combination with the local clock threshold; and the uniqueness of the nonce of the command message is verified by the local short-term cache random number list. The vehicle executes the command message only after all the verification items involved in the multi-dimensional verification of the command message have been determined to be passed.

[0042] If the cloud determines the risk to be low through the risk engine, the cloud will directly assemble the instruction data packet CmdPkg and generate a security signature Sig_AI. After that, the CmdPkg will be fully issued and the instruction message will be sent to the vehicle immediately. The vehicle will use the T-Box to call the local trusted comparison criteria that are pre-set at the factory to perform multi-dimensional verification on the received instruction message and execute the instruction message after the multi-dimensional verification is passed. If the cloud determines that the risk is high through the risk engine, the cloud will not assemble the instruction data packet CmdPkg, and the vehicle will not receive the instruction message.

[0043] As one possible implementation, the above-mentioned vehicle remote control method may further include: when the cloud fails to verify the one-time dynamic password token or the confidence level of the first text is lower than a preset confidence level, it sends an abnormal message to the mobile terminal; the mobile terminal receives the abnormal message and displays it.

[0044] Continuing from the previous example, after the mobile phone automatically issues a P-Token (i.e., a one-time dynamic password token) and sends it to the cloud, if the cloud fails to verify the P-Token issued by the mobile phone, the cloud returns a first abnormal message indicating user authentication failure (such as the text message "Authentication failed") to the mobile phone, and the mobile phone displays this first abnormal message. If the cloud verifies the P-Token issued by the mobile phone, and the confidence score of the text obtained by the cloud through the ASR model to convert the processed speech to text is less than a preset threshold (e.g., 0.8), the cloud returns a second abnormal message indicating unclear processed speech (such as the text message "Speech unclear") to the mobile phone, and the mobile phone displays this second abnormal message.

[0045] As one possible implementation, the above-mentioned vehicle remote control method may further include: when the voice input data verification is successful, the cloud sends a prompt message to the mobile terminal based on the real-time status of the vehicle; the mobile terminal receives the prompt message and displays it.

[0046] Continuing from the previous example, if the security code voice verification passes on the cloud side, the cloud obtains the vehicle's real-time speed through the TSP platform and generates a window for user operation (this window includes prompts indicating that the user confirms the security code is correct and / or performs manual control operations on the vehicle). Then, the display duration of this window is set according to the real-time vehicle speed (for example, the display duration is set to 5 seconds when the vehicle speed is >60km / h, and the display duration is set to 2 seconds when the vehicle speed is ≤60km / h) and sent to the mobile phone for display. The window is continuously displayed on the mobile phone until the set display duration is reached and then disappears. The user can perform manual control operations on the vehicle through this window displayed on the mobile phone to achieve manual intervention.

[0047] For ease of understanding, the implementation process of the above-mentioned vehicle remote control method will be described exemplarily using a specific application as an example.

[0048] A vehicle remote control system can be designed to implement the above-mentioned vehicle remote control method. See [link / reference]. Figure 2 As shown, the vehicle remote control system mainly includes a mobile terminal, a cloud terminal, and a vehicle terminal. See Figure 2 and Figure 3 As shown, the deployment structure on the mobile device mainly includes: (1) Security area dependency: The iOS side relies on the Secure Enclave hardware encryption module, and the Android side requires Android 9 or above and supports Hardware-backed Keystore to ensure that the voiceprint model and private key cannot be extracted or tampered with. (2) Model deployment details: The x-vector model is quantized with INT8. The training dataset contains in-vehicle environment speech (65dB (A) noise) of 1200 people (18-60 years old, 6 accents); PLDA comparison threshold θ_mobile=0.68; Tiny-ASR model, supports 100 whitelisted speech recognition, word error rate ≤4%, supports recognition of speech with SNR in the range of -10dB to 20dB; (3) Interaction design: Dual microphones (main microphone and noise-canceling microphone) are used for sound pickup, BF enhances the target speech, AEC eliminates environmental noise, and the processed speech SNR is improved by 8dB; voiceprint comparison is performed in the background, and P-Token is automatically issued after the voiceprint comparison is successful. When the voiceprint comparison fails, the text "Voiceprint verification failed, please move closer to the microphone to try again" pops up to prompt the user. After the voiceprint comparison fails 3 times, the user is triggered to enter a password to verify the user's identity.

[0049] See Figure 4 As shown, the deployment structure in the cloud mainly includes: (1) Hardware environment: Alibaba Cloud ECS instance (8 cores, 16GB memory, NVIDIA T4 GPU) is used for containerized deployment (Docker + K8s); RDS MySQL (master-slave architecture) is used to store user data, vehicle data, etc., and OSS is used to store voice clips, logs, etc. (2) AI central module configuration: ASR model (using Conformer-L), NLP model (using BERT-Base), risk engine (using rule engine combined with LightGBM model). For specific configuration parameters and performance, please refer to the relevant content above, and will not be repeated here.

[0050] (3) Blockchain deployment: Consortium blockchain (using Hyperledger Fabric, including 3 endorsement nodes and 1 sorting node), calculates block hashes for CmdPkg every 10 minutes and packages blocks (≤1MB), the block hashes are linked by SHA-256, and authorized nodes (such as car companies, regulatory agencies, etc.) can query relevant data for auditing.

[0051] The deployment structure on the vehicle side mainly includes: (1) Core hardware selection: The T-Box uses the Qualcomm MDM9207 communication module (supports 4G / 5G switching and is compatible with BLE5.0 Long Range), and the main controller is STM32H743 (480MHz main frequency, supports hardware encryption acceleration); the storage unit uses 256KB SRAM + 4MB Flash to meet the storage requirements of certificate (≤1KB), whitelist hash table (8kB) and log (remaining space); (2) Security configuration: A_Cert (ED25519 public key) and V_Cert (P256 certificate) are issued by the car manufacturer's CA center and written to the T-Box before leaving the factory; the whitelist static hash table is initially written through the car manufacturer's OTA, with an update cycle of 3 months. ECDSA signature verification is used during the update to prevent tampering; the graylist emergency stop window is 2 seconds by default, and supports remote adjustment (0-10 seconds) through the TSP platform. When the vehicle speed is >60km / h, it is automatically extended to 5 seconds (triggered by reading the vehicle speed signal through the CAN bus); (3) Communication interface: Connect to the vehicle actuator via CAN FD bus (rate 8Mbps), communicate with the TSP platform via Ethernet (100Mbps), and connect directly to the mobile phone via BLE 5.0 Long Range in weak network scenarios (communication distance ≤100m, transmission rate 2Mbps).

[0052] Example 1: Remotely open the vehicle's trunk.

[0053] See Figure 5 As shown, the specific process of Example 1 is as follows: Step S001: The user makes a voice input.

[0054] Scenario: The user is 30m away from the car (4G signal -85dBm, ambient noise 65dB(A)), holding a mobile phone and saying "XX, please open the trunk for me"; Mobile phone processing: Dual microphones for sound pickup (sampling rate 16kHz), BF and AEC processing to obtain a 16-bit PCM voice signal, SNR improved to 25dB, the PCM voice signal is only temporarily stored in memory (not written to disk).

[0055] Step S002: Voiceprint comparison and P-Token issuance on the mobile device.

[0056] Feature extraction: The PCM speech signal is pre-emphasized, framed (frame length 25ms, frame shift 10ms), and extracted by Mel spectrum. It is then input into the x-vector model (in the Secure Enclave on the mobile phone) after INT8 quantization. The x-vector model outputs a 1024-dimensional user speech feature vector embedding_test. Voiceprint comparison: The user's voice feature vector is compared with the feature vector corresponding to the locally encrypted user registration voiceprint template, embedding_enroll. Within trusted hardware, a similarity score is calculated using the PLDA model: score = PLDA(embedding_test, embedding_enroll). When a score is greater than or equal to 0.68, the voiceprint comparison is considered successful (i.e., user voice verification is successful); otherwise (if each calculated score is less than 0.68), the voiceprint comparison is considered unsuccessful (i.e., user voice verification fails). P-Token Issuance: If the voiceprint comparison passes, a P-Token (UID=12345678, ts=1718000000, nonce=987654321) is generated according to the data format shown in Table 1, and temporarily stored after being signed by Sig_P. Error handling: If the voiceprint comparison fails, a pop-up window will be displayed. After three failed voiceprint comparisons, password verification will be triggered (i.e., the user needs to enter a password to verify the user's identity).

[0057] Step S003: The issued P-Token is sent up to the cloud AI central module along with the voice message.

[0058] Data Upload: The mobile phone encodes and compresses the PCM voice signal temporarily stored in memory in step S001 using Opus (3s / 6KB) to obtain Opus voice, and uploads it to the cloud via TLS1.3 encryption. The encrypted data uploaded to the cloud includes the issued P-Token and the Opus voice. Cloud signature verification: After obtaining the P-Token through cloud decryption, the Sig_P signature, ts, nonce and other fields in the P-Token are verified. After the P-Token is verified, the cloud generates a unique random value (32 bytes) for this session and stores it in the session context. ASR Decoding: After obtaining the Opus speech through cloud decryption, the Opus speech is decoded into PCM format and input into the Conformer-L model for speech recognition. The Conformer-L model outputs the text "Open the trunk" (confidence level of 0.96, greater than 0.8). NLP parsing: Input the text output by the Conformer-L model into the BERT-Base model for intent parsing and parameter parsing, and map it to obtain CmdID=0x05; Voice Classification: The risk engine determines voices to be graylisted based on the risk rules corresponding to CmdID (such as the basic rules mentioned above); Exception handling: If P-Token verification fails, return the text "Authentication failed" to the mobile phone and display it on the mobile phone; if the confidence score of the Conformer-L model output text is less than 0.8, return the text "Instruction unclear" to the mobile phone and display it on the mobile phone.

[0059] After the cloud completes ASR decoding, NLP parsing, and voice classification, it caches core command parameters such as vehicle identifier (i.e., VehicleID), command ID (i.e., CmdID), user authorization, and risk level in the session context.

[0060] Step S004, second confirmation.

[0061] Verification code generation and push: The risk engine generates the security code "5J3M" (TTL=180s) and pushes it to the mobile APP; User response: The mobile APP prompts "Please say security code 5J3M". After the user repeats "security code 5J3M", the user's voice repeating "security code 5J3M" is recognized by the Tiny-ASR model and then uploaded to the cloud. Dual verification: The mobile device verifies the security code text recognized by Tiny-ASR (i.e., calculates the text similarity between the security code text and the security code), and the cloud verifies the security code text (i.e., calculates the text similarity between the security code text and the security code); if the security code text verification on the mobile device passes (e.g., the text similarity is greater than 0.65) and the security code text verification on the cloud passes, then proceed to step S005; Error Handling: If the mobile security code text verification fails (e.g., text similarity less than or equal to 0.65), the mobile phone displays the text "Secondary Confirmation Error"; if the cloud security code text verification fails, the cloud returns the text "Secondary Confirmation Error" to the mobile phone, which is then displayed on the mobile phone; if the mobile phone does not receive the user's voice or cloud security code text verification result within a certain time range, or if the mobile phone does not receive the security code text verification result within a certain time range, the mobile phone displays the text "Secondary Confirmation Timeout"; after 3 failed secondary confirmation attempts, the mobile phone will be locked for 10 minutes, and unlocking requires entering the APP password or SMS verification code for verification.

[0062] Step S005: Issue CmdPkg and send it to the vehicle terminal.

[0063] CmdPkg generation: After all the double verifications in step S004 pass, the cloud uses the core instruction parameters (such as vehicle identifier, instruction ID, user authorization, risk level, etc.) cached in the session context in step S003 as a basis, and strictly follows the data format shown in Table 2 to fill in the values ​​of static fields such as VehicleID=87654321 and CmdID=0x05 as well as the values ​​of dynamic fields such as real-time timestamp and random number to complete the assembly of the instruction data packet; CmdPkg issuance: The cloud performs ED25519 calculations using a private key to generate a secure signature Sig_AI, and combines Sig_AI with CmdPkg to form an instruction message, ultimately issuing a fully compliant CmdPkg. TSP Dispatch: The cloud adds the complete CmdPkg that has been issued to the gray list exclusive dispatch queue through the TSP platform. After a 2-second delay according to the medium risk control logic, it is sent to the vehicle. At the same time, the mobile APP pops up a text message "Open the trunk in 2 seconds, can be canceled" to prompt the user, leaving a window period for the user to cancel the voice command in case of emergency stop.

[0064] Step S006, executed on the vehicle side.

[0065] Command message verification: The T-Box calls the local trusted comparison criteria pre-set at the factory (such as standard protocol version, unique vehicle identifier, public key provided by the cloud, local clock threshold, local short-term cache random number list, etc.) to complete the above multi-dimensional verification. After all the verification items in the above multi-dimensional verification process are determined to be passed, the vehicle executes the command message. Emergency stop monitoring: For the command messages generated corresponding to the graylist voice commands, the vehicle-side system listens for the commands sent from the mobile APP to the T-Box (i.e., the commands generated by the mobile APP triggered by the user's operation on the pop-up window displayed by the mobile APP, such as emergency stop commands, cancellation commands, etc.). If no command sent from the mobile APP to the T-Box is detected within the listening period (i.e. the display duration of the pop-up window displayed by the mobile APP), the subsequent command message is executed. Control command execution: The T-Box sends the corresponding control command (CAN ID=0x100, valid data bit=0x01, corresponding to the trunk opening action) to the corresponding execution unit (such as the trunk, door, etc.) via the CAN FD bus. After the trunk (the execution unit at this time) drive motor runs stably for 1.5 seconds, the trunk opening action is completed. Feedback: After the vehicle action (which is the trunk opening action) is completed, the T-Box actively assembles and generates an execution response ACK message and encrypts and uploads it to the TSP platform in the cloud; after receiving the execution response ACK message, the cloud simultaneously pushes a notification of the vehicle action execution status to the mobile APP, and the mobile APP displays the text "Trunk Open" on the interface; Exception handling: If any of the above multi-dimensional verification items fails, the vehicle will directly discard the command message as an illegal command and retain the attack log locally. If a command (such as an emergency stop command, cancellation command, etc.) is detected from the mobile app to the T-Box within the monitoring period (i.e. the display duration of the pop-up window displayed by the mobile app), the currently required vehicle control command (corresponding to the command message) will be immediately terminated, and a reverse reset action will be performed (opposite to the vehicle action corresponding to the vehicle control command, such as closing or locking the trunk, doors, and other corresponding vehicle components) to avoid the risk of misoperation.

[0066] Example 2: Attacker Injection Defense (No P-Token).

[0067] See Figure 2 As shown, the relevant description of Example 2 is as follows: Attack Scenario: Attackers use Bluetooth communication link sniffing tools to capture plaintext control commands related to "opening the trunk" during Bluetooth interaction between the vehicle and mobile phone. After parsing the format of the plaintext control command, they forge the plaintext command and, without going through voiceprint comparison on the mobile phone side, generating a P-Token, or obtaining a legitimate signature from the cloud, directly initiate an illegal data writing request to the vehicle's T-Box via the Bluetooth GATT protocol. This attempt is to bypass the full-link mechanism provided by the aforementioned vehicle remote control methods, including identity authentication, voice classification, and secondary confirmation, in order to illegally control the vehicle.

[0068] Defense Process: When the vehicle-mounted T-Box receives all control messages written via the Bluetooth GATT protocol, it first triggers a local security verification mechanism. On one hand, it captures the source MAC address of the access device in real time through the Bluetooth underlying protocol stack (natively carried by the Bluetooth communication link layer, which the T-Box can directly read and identify). On the other hand, it forcibly verifies whether the control message conforms to the CmdPkg standard data format shown in Table 2, focusing on whether the control message contains a valid security signature Sig_AI. Since the attacker has not been authorized by the cloud, it cannot generate a valid security signature Sig_AI and has not encapsulated the standard CmdPkg data packet. The T-Box determines that the plaintext command forged by the attacker is an illegal injection command and immediately discards it without performing any vehicle-mounted actions. At the same time, the T-Box records a complete attack log in the local secure storage area. The complete attack log can include the attack time, attack type (e.g., illegal injection of unsigned commands), the attacker's device source MAC address, illegal message characteristics, and communication signal strength. The complete attack log is only stored locally on the vehicle and is not uploaded to the cloud or leaked.

[0069] Audit Alerts: The T-Box locally tracks the frequency of abnormal attacks on a single MAC address in real time. When the same illegal device MAC address launches three or more attacks such as unsigned instruction injection or illegal GATT writing within one hour, the T-Box automatically uploads the illegal device MAC address and complete attack logs to the cloud TSP platform via an encrypted channel. Upon receiving the illegal device MAC address and complete attack logs, the cloud immediately adds the MAC address to the temporary blacklist linked between the vehicle and the cloud, and simultaneously pushes a text message "Bluetooth Illegal Injection Alert" to the car owner's mobile app, clearly informing the car owner of the alert type, attack time, and suspicious device identifier. The temporary blacklist is valid for 24 hours, during which time Bluetooth connections, GATT data writing, and vehicle control requests initiated by the device corresponding to the MAC address are rejected. After 24 hours, the ban on vehicle control actions of the device corresponding to the MAC address is automatically lifted. The ban duration can be manually extended according to the car owner's needs.

[0070] Defense effectiveness: Based on the above defense process, 100 simulated attack tests were conducted (simulating different device MAC addresses and different attack frequencies of P-Token-free instruction injection). All illegal instructions were successfully intercepted and discarded by the T-Box. No attack was able to trigger the action of the vehicle components. The attack interception success rate was 100%, which verifies the effectiveness of the above vehicle remote control method in defending against Bluetooth sniffing, illegal instruction injection attacks, etc., indicating that the above vehicle remote control method can significantly improve the security protection level of remote vehicle control.

[0071] Example 3: Downgraded remote vehicle control for whitelisted voice commands in a weak network environment.

[0072] The scenario definition for Example 3 is as follows: Network: There is no 4G in the underground parking garage. The mobile phone and the vehicle T-Box communicate via BLE (-70dBm, 2Mbps). The user's voice message was "unlock the car door" (the user's voice message was classified as a whitelisted voice message, and the user's voice message could be recognized locally on the mobile phone).

[0073] See Figure 2 and Figure 6 As shown, the specific process of Example 3 is as follows: When the user says "XX, unlock the car door", the phone's dual microphones pick up and process the user's voice. The Tiny-ASR model recognizes the user's voice locally on the phone and outputs the text "unlock car door" (confidence 0.93 > 0.9), matching the whitelist of voices pre-stored locally on the phone. The mobile phone issues a Short-Token (86B, TTL=30s, indicating that the user only has the permissions corresponding to the whitelisted voice) within the Secure Enclave and sends it to the T-Box via BLE; The T-Box verifies the Short-Token. Once verified, it sends an "unlock" command (CAN ID=0x101, data=0x01) to the corresponding execution unit (the door) via CAN FD. After the car door is successfully unlocked, the vehicle sends a notification to the mobile app via BLE and displays the text "Car door unlocked".

[0074] The vehicle remote control method provided by this invention offers a remote vehicle control architecture that coordinates the terminal side, cloud, and vehicle. Its core innovation lies in moving voiceprint comparison and other functions to the terminal side, while moving voice classification and security verification to the cloud, and retaining only lightweight computing power on the vehicle side. This forms a technical path that prioritizes privacy, adapts computing power, and ensures a secure closed loop. The main implementation methods are as follows: (a) On the device side (mobile phone), a trusted execution environment is built based on secure hardware modules (iOS Secure Enclave / Android Hardware-backed Keystore). An x-vector model quantized with INT8 is deployed, and voiceprint registration and comparison are performed only within this trusted environment: the user's voiceprint template is encrypted and stored only in the trusted area on the device side and is never transmitted to the cloud; voice data is processed entirely in memory and released immediately after processing, without being stored on the phone's disk; the voiceprint comparison process is directly executed by the trusted hardware, and the model parameters and voiceprint template cannot be read or tampered with by external processes; after successful voiceprint comparison, the device side uses a private key to perform ECDSA-P256 signature on the user identifier, timestamp, and random number, generating a one-time P-Token (valid for only 5 seconds) to ensure that each... The uniqueness and timeliness of each request prevent replay attacks. In scenarios with weak or no network, the device automatically switches to the local Tiny-ASR model to recognize pre-agreed whitelisted voices, without relying on cloud computing power, thus solving the shortcomings of existing technologies in remote vehicle control failure in scenarios with weak networks such as underground parking garages and remote areas. The device uniformly performs PLDA spatial similarity calculation on the high-dimensional feature vector obtained by inferring the user's voice through the quantized voiceprint model and the feature vector corresponding to the user's registered voiceprint template stored in a secure area. The similarity score is then compared with the device's preset decision threshold (i.e., the PLDA comparison threshold) to achieve local identity legitimacy determination without privacy leakage.

[0075] The aforementioned end-side implementation method achieves "biological data not leaving the mobile phone and zero computing power increase on the vehicle side" through trusted hardware combined with a quantitative model, which not only meets the requirements for the protection of sensitive personal information, but also avoids increasing the cost of modifying the vehicle side hardware.

[0076] (b) The cloud-based system integrates multiple modules for collaborative operation, enabling P-Token verification, speech-to-text conversion, intent parsing, parameter parsing, speech classification, and command generation. Whitelisted speech corresponds to low-risk reversible operations (such as unlocking or locking doors), directly sending corresponding control commands to the vehicle for execution. Graylisted speech corresponds to medium-risk semi-reversible operations (such as opening the trunk or starting the engine), requiring a secondary confirmation mechanism. Blacklisted speech corresponds to high-risk irreversible operations (such as turning off the engine while driving), directly rejecting the generation of control commands. The TSP platform schedules and issues commands according to priority, supporting emergency command priority processing to ensure safe response in emergency scenarios.

[0077] The cloud-based implementation method described above achieves refined management through identity verification, intent parsing, parameter parsing, and risk level determination, and supports emergency stop and queue jumping, resulting in a more timely security response.

[0078] (c) The vehicle-side implementation only pre-installs lightweight configurations without deploying a voiceprint model. Specifically, it pre-installs an ED25519 / P-256 public key certificate issued by the vehicle manufacturer's CA and white, gray, and black list voice hash tables. After receiving the CmdPkg instruction package from the cloud, it sequentially verifies the protocol version, vehicle identification, user authorization, signature validity, timestamp, random number, etc., and filters out replay, tampered, and forged instructions. After the CmdPkg instruction package passes verification, it performs corresponding subsequent operations according to the risk level. The emergency stop window duration can be dynamically adjusted according to the vehicle speed, taking into account both convenience and driving safety.

[0079] The above-described vehicle-side implementation requires only a very small amount of storage resources on the vehicle side to complete instruction packet verification and hierarchical execution without additional computing power. Compared with existing technologies, the hardware cost per vehicle is reduced. At the same time, the local instruction packet verification mechanism effectively avoids the risk of illegal control of the vehicle after the cloud is compromised.

[0080] (d) Implement TLS 1.3 encrypted communication between the device, cloud, and vehicle to prevent data leakage and tampering during transmission; the cloud uploads the hash value of the CmdPkg instruction packet to the consortium blockchain (Hyperledger Fabric) every 10 minutes to form an immutable audit log, which authorized nodes (such as car manufacturers, regulatory agencies, etc.) can query and trace at any time; the original voice data is only processed on the device and is not uploaded to the cloud at all, and the vehicle does not store any user biometric information, which complies with the relevant personal information protection requirements.

[0081] The beneficial effects of the above-mentioned vehicle remote control method are mainly reflected in the following aspects: 1) Significantly improved security: The detection rate of attacks is extremely high even under the noise interference of the vehicle environment, which significantly improves the level of security protection compared with traditional vehicle remote control technology; 2) Optimized response speed: Short end-to-end response time to meet users' real-time control needs; 3) Cost and compliance advantages: No voiceprint model needs to be deployed on the vehicle side, which significantly reduces the hardware cost per vehicle. In addition, the vehicle side does not need to store user biometric data, which meets the relevant protection requirements for sensitive personal information. 3) Enhanced scenario adaptability: Supports all network scenarios (4G, 5G, Wi-Fi, no network). When the network is weak or there is no network, it automatically degrades to BLE near-field control. The vehicle control commands corresponding to the whitelisted voice commands are executed normally, solving the problem of the failure of traditional vehicle remote control technology in the case of weak network.

[0082] In practical applications, the x-vector backbone model used for voiceprint feature extraction on the mobile device can be replaced with QuartzNet (1D convolutional architecture) or ECAPA-TDNN (temporal modeling optimization). After the voiceprint feature extraction network is replaced, the core calculation logic of PLDA similarity comparison remains unchanged. Only the voiceprint model and the optimal decision boundary need to be retrained iteratively, and the PLDA comparison threshold on the device side is adaptively adjusted to the range of 0.65 to 0.70. After the voiceprint model and PLDA comparison threshold are adapted, the overall voiceprint comparison performance remains stable and still meets the constraints of FAR≤0.05% and FRR≤0.46%.

[0083] In practical applications, the cloud-based AI hub module can also be migrated from the public cloud to the car manufacturer's private cloud. This requires configuring a localized GPU cluster (such as 8 NVIDIA T4 servers that support load balancing) and deploying a private CA center to manage certificates, making it suitable for car manufacturers with high data localization requirements.

[0084] In practical applications, the secondary confirmation method can be replaced by generating a short question from the cloud or the client side to ensure readability, and a validity period for the user's answer to the short question can be set (e.g., TTL=180s).

[0085] In practical applications, the user's voice recitation of the verification code can be replaced by mobile phone vibration feedback combined with numeric keypad input (adapting to noisy environments such as roadsides and factory perimeters), and multi-factor authentication (such as facial recognition verification, fingerprint verification, etc.).

[0086] In practical applications, the fixed-duration emergency stop window can be replaced with a user-defined window (the duration can be adjusted to the range of 0-10 seconds via a mobile app), and the user-defined window can be synchronized to the cloud blockchain for auditing.

[0087] Based on the above-described vehicle remote control method, this invention also provides another vehicle remote control method, which can be executed by the cloud. See [link to relevant documentation]. Figure 6 As shown, the method may include the following steps: Step S602: Receive preprocessed voice data sent by the mobile terminal; the mobile terminal can be used to preprocess the user's input raw voice data to obtain preprocessed voice data, and verify the preprocessed voice data based on preset voiceprint information, and send the preprocessed voice data to the cloud when the verification of the preprocessed voice data is successful.

[0088] Step S604: Determine the risk level of the preprocessed voice data based on the preset risk engine, and send voice commands to the vehicle based on the risk level and the vehicle information service provider platform; the vehicle can verify the received voice commands and execute the verified voice commands.

[0089] Based on the above-described vehicle remote control method, this invention also provides a vehicle remote control system, which may include: The mobile terminal is used to preprocess the raw voice data input by the user, verify the preprocessed voice data based on preset voiceprint information, and send the preprocessed voice data to the cloud when the verification of the preprocessed voice data is successful. In the cloud, it is used to determine the risk level of preprocessed voice data based on a preset risk engine, and send voice commands to the vehicle based on the risk level and the vehicle information service provider platform. The vehicle-side system verifies received voice commands and executes commands that pass the verification.

[0090] The vehicle remote control system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0091] This invention also provides an electronic device, such as... Figure 7 The diagram shows the structure of the electronic device, which includes a processor 71 and a memory 70. The memory 70 stores computer-executable instructions that can be executed by the processor 71. The processor 71 executes the computer-executable instructions to implement the above-mentioned vehicle remote control method.

[0092] exist Figure 7 In the illustrated embodiment, the electronic device further includes a bus 72 and a communication interface 73, wherein the processor 71, the communication interface 73, and the memory 70 are connected via the bus 72.

[0093] The memory 70 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 73 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 72 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 72 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0094] The processor 71 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the aforementioned vehicle remote control method can be completed through the integrated logic circuitry in the processor 71 or through software instructions. The processor 71 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the vehicle remote control method disclosed in the embodiments of this invention can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory. The processor 71 reads the information in the memory and, in conjunction with its hardware, completes the steps of the vehicle remote control method of the aforementioned embodiment.

[0095] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the aforementioned vehicle remote control method. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0096] The computer program products of the vehicle remote control method, device and electronic device provided in the embodiments of the present invention include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the vehicle remote control method described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0097] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

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

[0099] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0100] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for remote vehicle control, characterized in that, include: The mobile terminal preprocesses the raw voice data input by the user and verifies the preprocessed voice data based on preset voiceprint information. When the preprocessed voice data passes the verification, it sends the preprocessed voice data to the cloud. The cloud platform determines the risk level of the preprocessed voice data based on a preset risk engine, and sends voice commands to the vehicle based on the risk level and the vehicle information service provider platform. The vehicle terminal verifies the received voice commands and executes the voice commands that pass the verification.

2. The vehicle remote control method according to claim 1, characterized in that, When the preprocessed voice data passes verification, the preprocessed voice data is sent to the cloud, including: If the preprocessed voice data passes verification, a one-time dynamic password token is generated, and the one-time dynamic password token and the preprocessed voice data are sent to the cloud. Also includes: The cloud verifies the one-time dynamic password token, and determines the risk level of the preprocessed voice data based on a preset risk engine when the one-time dynamic password token passes the verification.

3. The vehicle remote control method according to claim 1, characterized in that, The preset voiceprint information includes at least one first voiceprint information corresponding to a known identity; Verification of the preprocessed speech data based on preset voiceprint information includes: A preset voiceprint model is used to extract voiceprint features from the preprocessed speech data and the first voiceprint information respectively, and the different voiceprint features obtained are compared for the first time to determine whether the preprocessed speech data has passed the verification based on the first comparison result; wherein, the preset voiceprint model is obtained by quantizing the original voiceprint model.

4. The vehicle remote control method according to claim 1, characterized in that, The risk level of the preprocessed voice data is determined based on a preset risk engine, including: The preprocessed speech data is subjected to first speech recognition to obtain first text; If the confidence level of the first text is not lower than the preset confidence level, then the first text is subjected to intent recognition and parameter extraction, and the risk level is determined by a preset risk engine based on the intent recognition results and parameter extraction results.

5. The vehicle remote control method according to claim 4, characterized in that, Based on the aforementioned risk level and the vehicle information service provider platform sending voice commands to the vehicle, including: If the risk level is classified as risky, a security code is sent to the mobile terminal so that the mobile terminal can verify the user's voice input data based on the security code and send the voice input data to the cloud when the voice input data is verified. The voice input data is verified, and when the voice input data passes the verification, the vehicle information service provider platform sends a voice command to the vehicle.

6. The vehicle remote control method according to claim 5, characterized in that, Verification of user-inputted voice data based on the security code includes: The voice input data is subjected to second speech recognition to obtain second text; The second text is compared with the security code in a second comparison to determine whether the voice input data has been verified based on the second comparison result.

7. A method for remotely controlling a vehicle, characterized in that, Applied to the cloud, including: The system receives preprocessed voice data sent by a mobile terminal; the mobile terminal is used to preprocess the raw voice data input by the user to obtain the preprocessed voice data, and to verify the preprocessed voice data based on preset voiceprint information, and to send the preprocessed voice data to the cloud when the verification of the preprocessed voice data is successful. The risk level of the preprocessed voice data is determined based on a preset risk engine, and voice commands are sent to the vehicle based on the risk level and the vehicle information service provider platform; the vehicle is used to verify the received voice commands and execute the verified voice commands.

8. A vehicle remote control system, characterized in that, include: A mobile terminal is used to preprocess the raw voice data input by the user, verify the preprocessed voice data based on preset voiceprint information, and send the preprocessed voice data to the cloud when the verification of the preprocessed voice data is successful. The cloud is used to determine the risk level of the preprocessed voice data based on a preset risk engine, and to send voice commands to the vehicle based on the risk level and the vehicle information service provider platform. The vehicle terminal is used to verify the received voice commands and execute the voice commands that pass the verification.

9. An electronic device, characterized in that, The system includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the vehicle remote control method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the vehicle remote control method according to any one of claims 1 to 7.

Images