Voice interaction processing method and electronic device

Abstract

The application provides a voice interaction processing method and an electronic device, applied to a cloud end, the method comprising: in response to a user voice request, determining a target application corresponding to the user voice request based on a semantic recognition result of the user voice request; if it is determined that the installation state of the target application in the corresponding vehicle end is not installed, replacing the semantic recognition result with a candidate recognition result, the candidate recognition result being a result associated with the semantic recognition result and corresponding to a candidate application that has been installed in the vehicle end; and issuing the candidate recognition result to the vehicle end to forward the candidate recognition result to the candidate application corresponding to the candidate recognition result through the vehicle end. Thus, the application sets a degradation replacement mechanism for the recognition result, when the target application is not installed, disabled or version incompatible, the cloud voice platform completes request distribution through an existing routing path, realizes processing of the user voice request, and improves user experience.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, and more specifically, to a voice interaction processing method and an electronic device. Background Technology

[0002] With the rapid development of in-vehicle smart cockpits, mobile terminals, and AI voice interaction, more and more applications support triggering specific business functions through voice commands, such as wallpaper generation, pixel headlight pattern generation, and AI-generated images. Voice interaction has become an important interaction method between users and devices.

[0003] Currently, in relevant voice domaining solutions, voice platforms typically route voice requests directly to the corresponding target application based on semantic recognition results, and complete the call through the package name or predefined capabilities of the target application, thereby realizing the mapping of voice commands to specific business functions.

[0004] However, the existing voice domain landing link relies heavily on the installation status of the target application. When the target application is not installed, is disabled, or is incompatible with the version, the cloud voice platform cannot complete the request distribution through the existing routing path, resulting in voice request processing failure. Users cannot use the voice function normally, which reduces the user experience. Summary of the Invention

[0005] This application provides a voice interaction processing method and an electronic device. The method sets up a degradation replacement mechanism for the recognition results. When the target application is not installed, is disabled, or is incompatible with the version, the cloud voice platform completes the request distribution through the existing routing path, realizes the processing of user voice requests, and improves user experience.

[0006] Firstly, a voice interaction processing method is provided, applied in the cloud. The method includes: responding to a user's voice request, determining the target application corresponding to the user's voice request based on the semantic recognition result of the user's voice request; if it is determined that the target application is not installed in the corresponding vehicle terminal, then replacing the semantic recognition result with a candidate recognition result, wherein the candidate recognition result is a result that is related to the semantic recognition result and the corresponding candidate application has been installed in the vehicle terminal; and sending the candidate recognition result to the vehicle terminal so that the vehicle terminal can forward the candidate recognition result to the candidate application corresponding to the candidate recognition result.

[0007] In the above technical solution, in response to a user's voice request, the semantic recognition result based on the user's voice request completes the business domain placement and determines the corresponding target application. At the same time, the installation status of the target application in the corresponding vehicle is verified through cloud cache retrieval or vehicle-side reverse query. If it is determined that the target application is not installed, the original semantic recognition result is replaced with a candidate recognition result that is topic-related and whose corresponding candidate application is already installed on the vehicle. This sets up an elastic degradation and replacement mechanism in the cloud voice domain placement link, solving the problem of strong dependence of the original routing logic on the installation status of the target application. Finally, the candidate recognition result is sent to the vehicle-side voice entry point, and the vehicle forwards it to the candidate application that matches the candidate recognition result to complete the business execution. This effectively avoids the problem of voice request distribution failure caused by the target application not being installed, being disabled, or version incompatibility, ensuring that voice commands can be responded to normally in a closed loop. Moreover, the core user needs and intentions are preserved through associative degradation and replacement, preventing the business from deviating from user expectations and improving the usability and user experience of voice interaction.

[0008] Secondly, a voice interaction processing device is provided, comprising: a determining module, configured to, in response to a user's voice request, determine a target application corresponding to the user's voice request based on the semantic recognition result of the user's voice request; a replacing module, configured to, if the target application is determined to be not installed in the corresponding vehicle terminal, replace the semantic recognition result with a candidate recognition result, wherein the candidate recognition result is a result that is associated with the semantic recognition result and the corresponding candidate application has been installed in the vehicle terminal; and a sending module, configured to send the candidate recognition result to the vehicle terminal so that the vehicle terminal can forward the candidate recognition result to the candidate application corresponding to the candidate recognition result.

[0009] Thirdly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the methods of the first aspect or any possible implementation thereof. Attached Figure Description

[0010] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A schematic diagram of a voice interaction processing system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 1 ; Figure 4 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 2 ; Figure 5 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 3 ; Figure 6 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 4 ; Figure 7 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 5 ; Figure 8 A schematic diagram of the structure of a voice interaction processing device provided in an embodiment of this application. Figure 1 ; Figure 9 A schematic diagram of the structure of a voice interaction processing device provided in an embodiment of this application. Figure 2 . Detailed Implementation

[0011] The technical solutions of this application will now be described clearly and in detail with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " signifies "or," for example, A / B can mean A or B. "And / or" in the text merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more.

[0012] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0013] With the development of in-vehicle intelligent cockpits and AI (Artificial Intelligence) voice interaction technology, voice commands have become the mainstream interaction method for triggering cockpit business functions, supporting various AIGC (AI Generated Content) services such as wallpaper generation and pixel headlight pattern projection. Current mainstream voice domain matching solutions mostly rely on semantic recognition results to directly match target applications, completing routing and distribution through application package names or predefined capabilities to map voice commands to business functions. However, the domain matching link of these solutions heavily depends on the installation status and availability of the target application, lacking business degradation and replacement mechanisms. When the target application is not installed, disabled, or has an incompatible version, the cloud-based voice platform cannot complete request routing, directly causing voice command execution failure, preventing users from using voice functions normally, and resulting in a poor interactive experience. Based on this, this application proposes a voice domain matching solution with business degradation capabilities, namely a voice interaction processing solution, to solve the above-mentioned technical problems.

[0014] Before elaborating on the technical solution, the technical terms used in this application will be explained to facilitate subsequent understanding.

[0015] Voice domain routing refers to the process by which a voice platform routes recognized voice service requests to the corresponding target application or functional module based on semantic parsing results. It is the core link in transforming voice commands from general semantics into specific business execution.

[0016] The voice assistant is the intermediate entry application on the vehicle side that carries the unified AI voice domain application capability. It receives the domain application results issued from the cloud, is responsible for command forwarding, business scheduling and result feedback, and is the core hub for voice capability to connect with downstream businesses.

[0017] Dynamic distribution is the scheduling mechanism of the voice assistant. Based on the business identifier, application installation status and availability, it dynamically selects the target application for the actual business to be processed, and supports flexible routing logic such as business degradation and scenario adaptation.

[0018] AIDL (Android Interface Definition Language) is a native cross-process communication solution of the Android system. By defining standardized interaction interfaces, it enables data transfer and method calls between different application processes, and is a communication method for command interaction between multiple applications on the vehicle.

[0019] Service is one of the four major components of Android. It has no user interface and can run in the background for a long time to perform tasks. It is suitable for scenarios such as persistent voice background, message sending and receiving, and status monitoring. It is the core carrier of persistent processes such as voice daemon.

[0020] The voice interaction processing method and electronic device of this application will be described in detail below with reference to the accompanying drawings and through multiple embodiments.

[0021] Figure 1 This is a schematic diagram of a voice interaction processing system provided in an embodiment of this application. Figure 1 As shown, the voice interaction processing system 100 includes at least: vehicle terminal 110 and cloud terminal 120.

[0022] Among them, the voice interaction processing system 100 adopts a distributed architecture with separate vehicle and cloud deployment. The vehicle-side module 110 runs in the vehicle-side operating system of the vehicle computing platform; the cloud-side module 120 is deployed on a cloud server cluster, and each module is decoupled through a microservice architecture.

[0023] The vehicle-side module 110 includes at least the following modules: Daemon module 111, Adapter module 112, voice assistant module 113, AI subsystem module 114, and downstream business application module 115. The cloud-side module 120 includes at least the following modules: speech recognition module 121, speech semantic module 122, arbitration service module 123, spatial cloud engine module 124, agent cloud module 125, and cloud caching module 126.

[0024] Among them, the Daemon module 111 is a resident background voice entry daemon process with the highest process priority. As the scheduling hub and vehicle-to-cloud communication relay node for the entire local voice link on the vehicle side, it collects the raw audio stream in real time through the vehicle microphone hardware driver layer and completes three steps of local audio processing in sequence: removing background noise such as wind noise, road noise, and air conditioning noise during vehicle operation through a vehicle-specific noise reduction algorithm, and extracting the pure human voice frequency band; identifying the start and end points of the user's speech based on speech energy characteristics and acoustic models, cutting out effective speech segments, and removing silent segments and invalid ambient sounds; encoding the original PCM (Pulse Code Modulation) format audio into a high compression ratio format such as OPUS (Opus Audio Codec), reducing the transmission bandwidth usage while ensuring recognition accuracy; after processing, it transmits the encoded voice data along with the vehicle's unique identifier VIN (Vehicle Identification Number) and the unique ID of this session through the vehicle network TCP (Transmission Control Protocol) long connection channel. Identity (identifier) ​​is uploaded to the cloud-based speech recognition module 121.

[0025] The Adapter module 112 is a business-specific adaptation layer, deployed independently according to business domains, to realize the protocol conversion between general voice commands and business-specific parameters; the voice assistant module 113 is the local scheduling core of the raw image business, responsible for raw image request assembly, material reception and cross-application distribution; the AI ​​subsystem module 114 is the edge-side multimodal perception and semantic assistance unit, carrying local context management and multi-source scene fusion capabilities; the downstream business application module 115 is the final landing carrier of the business, that is, the carrier corresponding to the target application and candidate application in this application, including at least: pixel headlight application, wallpaper mall application and other independently run in-vehicle applications.

[0026] The speech recognition module 121 carries the computing power for Automatic Speech Recognition (ASR) and is equipped with an end-to-end ASR model optimized for in-vehicle scenarios. After receiving the encoded audio uploaded from the vehicle, the speech recognition module 121 first decodes and restores the audio waveform, then converts the audio feature sequence into a phoneme sequence through an acoustic model. Combining a pre-trained language model with a dedicated corpus covering high-frequency in-vehicle domains such as vehicle control, raw images, audio-visual, and navigation, it decodes the audio into natural language text and outputs the recognition confidence score simultaneously. Finally, the speech text, along with the session ID, vehicle VIN, and confidence score data, is sent to the speech semantic module 122 through the internal RPC (Remote Procedure Call) service call interface to provide standardized input for subsequent semantic parsing.

[0027] The speech and semantic module 122 carries natural language processing and business domain mapping capabilities. It is responsible for semantic parsing, legality verification, and business mapping of the text output by speech recognition. The overall processing is divided into four stages: First, business domain determination. By matching and comparing the speech text with a preset business domain keyword library, the business domain is determined by the set of keywords with the highest matching degree. For example, matching keywords such as "headlight" and "light projection" determines the domain of pixel headlight raw images, while matching keywords such as "wallpaper" and "desktop background" determines the domain of wallpaper raw images. Second, intent and parameter extraction. Based on the natural language semantic analysis model, the user's operation intent is identified, and structured intent parameters are extracted from the text. In the raw image scenario, the structured intent parameters are at least This includes: pattern theme, painting style, color tendency, size constraints, etc. These structured intent parameters are structured constraint data for executing user intents and are input conditions for downstream modules to complete business actions, rather than the implementation method of the intent itself; third, legality verification, which performs correlation verification on the business domain, user intent, and structured intent parameters to check whether the domain and intent match and whether the parameter values ​​are within the preset legal range, eliminating logical conflicts and illegal values; fourth, target application mapping, which maps the verified business domain to the corresponding target application identifier based on the preset business domain-application mapping relationship table, for example, the pixel headlight domain is mapped to the pixel headlight hardware ID, and the wallpaper domain is mapped to the wallpaper mall application package name.

[0028] Arbitration service module 123 is a node for business availability adjudication. It is used to retrieve the installation status of the target application through cloud caching module 126. If a valid cache is found, the installation status is obtained directly. If the cache is invalid or there is no cache, a status query command is sent to Daemon module 111, and the installation status returned by Daemon module 111 is received. Based on the installation status, it is determined whether to perform degradation processing, and a final domain result with degradation flag is generated and sent to Daemon module 111.

[0029] It should be noted that the arbitration service module 123 adopts a two-level status acquisition mechanism of cache priority and reverse query as a fallback. The specific implementation principle is as follows: First, using the vehicle VIN as the primary key, the corresponding vehicle's business status record is queried in the cloud cache module 126, and the installation status field matching the target application identifier is extracted. If the cache record exists and is within the preset validity period (e.g., the preset validity period is set to 5 minutes), the cache status is read directly without interaction with the vehicle, thereby reducing query latency and the frequency of vehicle-cloud communication. If no corresponding cache record is found, or the cache has expired, the reverse status query process is triggered. This reverse status query process involves the arbitration service module 123 assembling a status query instruction, which carries the target application identifier, request sequence number, and vehicle VIN, and is sent to the vehicle-side Daemon module 111 through the vehicle-cloud downlink long connection channel. After receiving the status response data packet returned by the Daemon module 111, the actual installation status is parsed, and the cloud cache module 126 is updated with the vehicle VIN as the key and the target application status as the value, resetting the 5-minute validity period to avoid repeatedly sending query instructions in a short period of time. After obtaining the accurate installation status, the arbitration service module 123 executes a downgrade ruling. If the target application or hardware is already installed, the original business domain, intent, and bound business parameters are retained, generating a final domain result without a downgrade flag. If the target application or hardware is not installed, business downgrade is performed, for example, replacing the pixel headlight image domain with the wallpaper image domain, rebinding wallpaper-specific business parameters, and adding a downgrade flag to the domain result. This downgrade flag can be implemented using a Boolean type (e.g., is_degrade = true / false) or an enumeration type (e.g., degrade_type = pixel_light_to_wallpaper), and can also include a downgrade description field. Finally, the arbitration service module 123 sends the final domain result, including the complete domain, intent, parameters, and optional downgrade flag, to the corresponding vehicle's Daemon module 111.

[0030] The Daemon module 111 is also used to receive status query instructions issued by the arbitration service module 123, parse the status query instructions to determine the query type, call the corresponding underlying interface to obtain the installation status, and return the installation status to the arbitration service module 123; as well as receive the final domain landing result and distribute it to the Adapter module 112 and the AI ​​subsystem module 114.

[0031] The Daemon module 111 has two independent processing logics for reverse status queries and domain result distribution: First, reverse status query processing: The Daemon module 111 residently monitors the vehicle cloud downlink command channel. Upon receiving a status query command, it first parses the command message, extracts the target application identifier and request sequence number, and divides the query branch according to the identifier type. If it is a hardware identifier (such as the pixel headlight hardware ID), it enters the hardware reading branch; if it is an application identifier (such as the wallpaper store package name), it enters the application reading branch. If it enters the hardware reading branch, the Daemon module 111 calls the vehicle CAN bus hardware driver interface to read the vehicle peripheral mounting register information and obtain the actual installation status of the pixel headlight hardware. If it enters the application reading branch, the Daemon module 111 calls the vehicle-side system application management service interface, traverses the list of locally installed applications and matches the target package name to obtain the application installation status. After obtaining the actual status, the Daemon module 111 assembles the installation status, request sequence number, and vehicle VIN into a response data packet, and sends it back to the arbitration service module 123 via the vehicle-cloud uplink channel. Simultaneously, it briefly caches this status locally for reuse in repeated requests within a short period. Secondly, the final domain-specific result distribution: After receiving the final domain-specific result from the cloud, the Daemon module 111 uses a parallel distribution mechanism to simultaneously distribute the same domain-specific data to two downstream modules: one path matches the corresponding Adapter module 112 according to the business domain and distributes the domain-specific data packet via AIDL (Android Interface Definition Language) cross-process communication, serving as the main business execution line; the other path synchronously sends the domain-specific result along with ASR voice and text to the AI ​​subsystem module 114, serving as a multi-mode auxiliary line. This parallel distribution mechanism avoids the auxiliary line logic blocking the main line business, effectively reducing the end-side latency of business execution.

[0032] AI subsystem module 114 receives the domain-specific results distributed by Daemon module 111, integrates the vehicle-side front-end page, local hardware status, and historical dialogues, updates the local multi-turn dialogue context cache, and provides an interface for reading scene-assisted verification information. Specifically, AI subsystem module 114 is an edge-side multimodal semantic auxiliary unit. After receiving the domain-specific results and ASR text distributed by Daemon module 111, it performs multi-source data fusion processing: first, it obtains the current front-end application page information of the vehicle-side through the system framework interface to determine whether the user is within the corresponding business application interface; second, it reads the local hardware status snapshot to supplement the real-time operation and mounting information of the vehicle hardware; and third, it reads the locally persistently stored historical dialogue records, associating historical commands and generated results with the same session ID. After fusing the above multi-dimensional data with the current domain-specific results, the module updates the local multi-turn dialogue context cache. The cache is stored in units of session ID, including the current command, parameters, business domain, and scene information. AI subsystem module 114 adopts a passive reading interface design, providing only a standardized scene data query interface to the outside world, without actively pushing data to the voice assistant module; the voice assistant module 113 can actively call the interface to pull auxiliary verification information according to business needs. This not only ensures the contextual continuity of multi-turn dialogues, but also avoids performance interference of invalid data pushes on the main business through the passive calling mode, while supporting fallback semantic parsing in offline scenarios.

[0033] Adapter module 112 is used to parse the final domain landing result, assemble a standard request, and send it to the voice assistant module. Adapter module 112 is a business-specific adaptation layer, deployed independently according to business domains (e.g., wallpaper adapter, pixel headlight adapter). After receiving the domain landing data packet from Daemon module 111, it performs three steps: First, parameter integrity verification, checking whether the business domain, intent, and raw image parameters are complete, and removing illegal fields and missing items; second, protocol conversion, stripping redundant encapsulation fields such as cloud-based general message headers and session management, extracting pure business parameters, and binding them to the corresponding business-specific parameter specifications, such as binding projection size and line constraints for the pixel headlight business, and binding screen resolution and image quality constraints for the wallpaper business; third, standard request assembly, encapsulating the extracted parameters according to the raw image-specific standard request format defined by the voice assistant module, and supplementing fields such as business affiliation identifier and degradation flag. After assembly, Adapter module 112 sends the standard request to voice assistant module 113 through an inter-process communication interface.

[0034] The voice assistant module 113 receives standard requests and optionally reads scene-assisted verification information from the AI ​​subsystem module 114 to generate a raw image request and send it to the spatial cloud engine module. The voice assistant module 113 is the scheduling core for the local raw image service. After receiving a standard raw image request from the Adapter module 112, it first parses the basic information such as drawing requirements, business domain, and degradation markers, and then decides whether to read the auxiliary data from the AI ​​subsystem module 114 as needed. If it is a single, short command without multi-turn context dependencies or special scene constraints, the reading step is skipped, and the request is directly assembled to maximize response speed. If it is a multi-turn modification command that needs to be combined with the current page scene or needs to verify the local hardware status, the query interface of the AI ​​subsystem is actively called to retrieve multi-modal scene auxiliary information for secondary verification. Subsequently, the voice assistant module 113 supplements the vehicle's local additional information, including the vehicle's unique VIN, the hardware dimensions of the corresponding service (such as headlight projection resolution and wallpaper screen size), and the current vehicle scene information. It then combines the above information with the core image generation parameters to form a complete image generation request message, which is sent to the spatial cloud engine module 124 via the HTTPS interface.

[0035] The spatial cloud engine module 124 performs security verification on raw image requests, forwards verified requests to the agent cloud module 125, and receives the material response package returned by the agent cloud module 125, which is then sent to the voice assistant module 113. The spatial cloud engine module 124 serves as the cloud gateway node for the raw image service, undertaking verification, pass-through, and fallback calibration functions. The specific processing flow is as follows: First, legality verification: authentication is performed based on the vehicle's VIN, verifying vehicle service permissions, and then verifying whether the request parameter format conforms to the specifications, excluding illegal format requests. Second, content security verification: a sensitive content detection model is invoked to screen for illegal content in the user's drawing description text. If illegal content is detected, the request is directly intercepted, and a failure result is returned to the vehicle. Third, hardware specification fallback calibration: considering that local cache deviations, degradation logic switching, and vehicle model changes may cause distortion of the size parameters in the message, the spatial cloud engine module 124 simultaneously initiates real-time status retrieval from the vehicle to obtain the current vehicle's actual wallpaper resolution and headlight projection specifications, and calibrates and corrects the size parameters in the message. After verification and calibration are completed, the spatial cloud engine module 124 forwards the standardized raw image request to the agent cloud module 125; after receiving the material response package returned by the agent cloud module 125, it is then sent to the vehicle-side voice assistant module 113 through the vehicle-cloud channel.

[0036] Agent cloud module 125 is used to generate image materials based on raw image requests, encapsulate them into material response packages, and return them to spatial cloud engine module 124. Agent cloud module 125 carries AIGC raw image capabilities. This processing flow is divided into four stages: The first stage is LLM (Large Language Model) semantic preprocessing. The LLM processes the raw image request text, confirming the business domain (e.g., pixelated headlights or wallpaper domain) and operation type (new generation or multi-round iterative modification). It rewrites colloquial requirements into standardized structured drawing prompts, supplementing constraints such as style, lines, and image quality, and extracting quantifiable structured key-value pair parameters (e.g., theme, style, color, canvas size) from the text. The second stage is context memory correction. Based on the unique context ID of the dialogue, it retrieves the current dialogue history. If it is a multi-round modification instruction, it compares the old and new parameters, updating only the user's changes and automatically overwriting conflicting parameters. If it is a completely new generation... The first stage involves clearing historical constraints and using only current parameters. The second stage is differentiated image generation, where the final drawing parameters and hardware specifications are input into the AIGC image generation model to generate images differentiated according to business domains. For example, for the pixel headlight business, low-line, simple line drawing materials without complex fills are generated to adapt to the size of the light projection canvas; for the wallpaper business, high-resolution, detailed images are generated to adapt to the screen ratio of the vehicle. The third stage is material encapsulation, where the generated binary images are uploaded to the cloud resource server to generate downloadable resource links. At the same time, metadata (such as generation size, style, business affiliation, dialogue ID, and degradation mark) is assembled and uniformly encapsulated into a standard material response package, which is then returned to the spatial cloud engine module 124.

[0037] The voice assistant module 113 is also used to distribute the material response package to the downstream business application module 115. Specifically, after receiving the material response package from the space cloud, the voice assistant module 113 first parses the image resource link, business affiliation, and degradation flag information, downloads the image file to the local cache, and then performs distribution according to the business domain: if the business domain is pixel headlights, the simple line drawing material is pushed to the pixel headlight application, which loads the pattern and drives the headlight hardware to complete the light projection display; if the business domain is wallpaper images, the high-definition wallpaper is pushed to the wallpaper store application, which provides preview, save, and one-click setting of the vehicle wallpaper. If the response package carries a degradation flag, a prompt message is simultaneously triggered, such as "Pixel headlights not installed, a matching wallpaper has been generated for you."

[0038] Downstream business application module 115 executes material application and sequentially transmits the execution results back to voice semantic module 121 via voice assistant module 113, Adapter module 112, and Daemon module 111. After completing material loading and display, downstream business application module 115 generates the execution result for this business, including execution success or failure status, material usage records, error codes, and error messages (if failure occurs). The execution result is transmitted upwards layer by layer along the main business link: first to voice assistant module 113, which supplements the raw image metadata and forwards it to the corresponding Adapter module 112. Adapter module 112 encapsulates the result into a standardized voice execution result and transmits it back to Daemon module 111 via the AIDL cross-process interface. Finally, Daemon module 111 synchronizes the complete execution result, along with the session ID and vehicle VIN, to cloud-based voice semantic module 122 via the vehicle-cloud uplink channel, storing it in the cloud context memory to support semantic parsing and context association for the next round of multi-turn voice dialogue.

[0039] As an example, this application also provides a complete implementation example of a voice interaction processing system, as shown below: Step 1: User voice recording and cloud upload.

[0040] After the user wakes up the in-vehicle voice assistant module 113 and speaks a command, the audio stream is directly sent to the vehicle-side resident voice daemon module 111, which serves as the first local voice receiving entry point. The voice daemon module 111 performs local audio processing such as noise reduction, voice segmentation, and format encoding, and then actively uploads the processed audio data to the cloud voice recognition module 121 through the vehicle network channel.

[0041] Step 2: Cloud-based speech recognition and semantic parsing.

[0042] After receiving audio data, the cloud-based speech recognition module 121 converts the user's voice commands into speech text and uploads the speech text to the speech semantic module 122. Subsequently, the speech semantic module 122 first extracts keywords from the text, compares them with a preset business keyword library to determine the business domain, then performs semantic analysis on the text to identify the user's intent and the corresponding intent parameters. Finally, it performs a legality and consistency check on the business domain, user intent, and intent parameters, and outputs the check result after confirming that there are no conflicts.

[0043] Step 3: Target application matching and parameter adaptation.

[0044] Based on the verified business domain, the corresponding target application is determined by combining the preset business domain-application mapping relationship. At the same time, the verified user intent and intent business parameters are associated with the target application, and the general intent business parameters are converted into exclusive target intent business parameters that can be recognized by the target application.

[0045] Step 4: Target application availability cache verification.

[0046] When determining whether a target application is available, a caching mechanism is used first. The cloud-based 120 system retrieves the corresponding vehicle's cloud business status cache record based on the vehicle identifier, matches the target application identifier of the current business domain from the record, and directly reads the installation status of the application to complete the availability determination without sending a query command to the vehicle.

[0047] Step 5: Reverse state lookup under cache invalidation.

[0048] If the cloud-based 120 system finds no corresponding vehicle cache or the cached data has expired, a reverse query process is triggered. Specifically, the cloud-based 120 system sends a status query command carrying the target application identifier and request sequence number to the vehicle-side voice Daemon module 111. The voice Daemon module 111 parses the command and distinguishes the query type. For example, to query the pixel headlight hardware status, it calls the CAN hardware driver interface; to query the wallpaper store application status, it calls the system application management service. After obtaining the actual installation status, it encapsulates the status information, request sequence number, and vehicle VIN into a response data packet and sends it back to the cloud arbitration service module 123 via the vehicle-cloud uplink channel. Simultaneously, it briefly caches the status result locally for reuse within a short period.

[0049] Step 6: Cloud-based arbitration ruling and business downgrade.

[0050] The cloud arbitration service module 123 receives and parses the response data packet. After obtaining the actual installation status of the target application, it updates the cloud temporary status cache with the vehicle VIN as the key and sets a 5-minute validity period. Then, it performs arbitration based on the preliminary business domain and the latest installation status. If the target application or hardware is already installed, the original business domain and bound business parameters are retained; if not installed, business downgrading is performed, replacing the pixel headlight image domain with the wallpaper image domain, rebinding the wallpaper-specific business parameters, and generating a downgrading flag. Finally, the final domain result, carrying the downgrading flag, complete business domain, user intent, and intent parameters, is sent to the Enter terminal voice Daemon module 111, officially entering the business execution chain.

[0051] Step 7: Distribute the domain results in parallel on both the vehicle and other sides.

[0052] After receiving the final domain placement result from the cloud 120, the vehicle-side voice Daemon module 111 distributes it in parallel through two channels: On the main business channel, the voice Daemon module 111 matches the corresponding wallpaper or pixel headlight voice Adapter module 112 according to the target business domain, and distributes the domain placement data across processes. The voice Adapter module 112 completes parameter integrity verification, removes cloud-based general encapsulation fields, binds business-specific parameter specifications, and then assembles a raw image-specific standard request that the voice assistant can recognize and pushes it to the voice assistant module 113. On the auxiliary multi-mode auxiliary channel, the voice Daemon module 111 simultaneously sends the domain placement result and ASR text to the AI ​​subsystem module 114. The AI ​​subsystem module 114 integrates the vehicle-side front-end page, local hardware status, and historical dialogue information to update the local multi-turn dialogue context cache. It only provides a scene data reading interface to the outside world and does not actively push data to the voice assistant module 113.

[0053] Step 8: The voice assistant integrates information and initiates a cloud-based image request.

[0054] The voice assistant module 113 receives and parses the standard raw image request sent by the voice adapter module 112. Based on the actual scenario, it actively reads the multi-mode scenario information of the AI ​​subsystem module 114 to complete the secondary auxiliary verification. Then, it supplements local additional data such as the vehicle VIN, the screen or headlight hardware size of the corresponding business, and vehicle-side scenario information. All the information is then stitched together into a raw image request message and sent to the spatial cloud engine module 124.

[0055] Step 9: Space cloud engine verification and pass-through.

[0056] After receiving the raw image request, the spatial cloud engine module 124 first completes vehicle identity authentication and parameter format verification, then performs sensitive content detection on the image description, directly intercepting any illegal content and returning a failure result; after the verification is passed, it synchronously pulls the latest wallpaper resolution and headlight projection specifications from the vehicle to perform parameter fallback correction, avoiding parameter distortion caused by local caching, degradation logic, etc., and finally forwards the standardized raw image request to the Agent cloud module 125.

[0057] Step 10: The Agent executes the AIGC image pipeline in the cloud.

[0058] The Agent cloud module 125 first uses an LLM model to classify intents, confirm the business type and operation type, and extract the pure main requirement text. Then, combined with hardware specifications, it rewrites the colloquial requirements into standardized structured drawing prompts that include style, line, and image quality constraints, and extracts quantifiable key-value pair structured pattern parameters. Subsequently, it retrieves historical dialogue records based on the unique context ID of the dialogue. In multi-round modification scenarios, it only updates the user's changes and automatically corrects conflicting parameters. In newly generated scenarios, it uses the current parameters. After obtaining a complete set of drawing parameters, it inputs them into the AIGC raw image model of the corresponding business. The pixel headlight business generates low-line simple line drawing materials, and the wallpaper business generates high-definition vehicle wallpapers. After generation, the images are uploaded to the cloud resource server to generate download links. Together with the drawing parameters, business type, hardware specifications, degradation markers, and other meta-information, they are packaged into a complete material response package and sent back to the spatial cloud engine module 124.

[0059] Step 11: Business material distribution and local caching.

[0060] The spatial cloud engine module 124 sends the encapsulated material response package to the vehicle-side voice assistant module 113. After receiving the package, the voice assistant module 113 completes local caching of the image material and metadata.

[0061] Step 12: Downstream business implementation and application.

[0062] The voice assistant module 113 distributes materials to the corresponding downstream business application modules 115 based on the business domain. For example, in the Pixel Headlight business, simple line drawing materials are pushed to the Pixel Headlight application, which loads the pattern and supports headlight light projection display; in the Wallpaper Raw Image business, high-definition wallpapers are pushed to the wallpaper store, providing preview, save, and one-click wallpaper setting functions. If the material is a downgraded material, the corresponding prompt text is displayed simultaneously.

[0063] Step 13: Close the loop of end-to-end result return.

[0064] Downstream business application module 115 generates business execution results including execution status and material usage records and uploads them to voice assistant module 113. Voice assistant module 113 sends the results back to the corresponding voice adapter module 112, which encapsulates them into standardized domain results and sends them back to voice daemon module 111 via AIDL. Finally, voice daemon module 111 synchronizes the complete execution results to cloud voice semantic module 122, updates cloud context memory to support subsequent multi-turn dialogues, and simultaneously pushes the latest execution records to AI subsystem module 114 to refresh local multi-turn dialogue cache.

[0065] The voice interaction processing system provided in this application adopts a vehicle-cloud collaborative distributed architecture, consisting of a vehicle-side Daemon module, Adapter module, voice assistant module, AI subsystem module, and downstream business application module, which collaborate with a cloud-side speech recognition module, speech semantic module, arbitration service module, spatial cloud engine module, Agent cloud module, and cloud cache module. After the user wakes up the voice assistant, the Daemon module receives the user's voice command, performs audio preprocessing such as local noise reduction, endpoint segmentation, and format encoding, and uploads it to the cloud via a long-distance connection in the vehicle network. The speech recognition module then converts the speech to text and outputs it to the speech input device. The semantic module and the voice semantic module extract business domain, user intent, and structured intent parameters through keyword matching and deep semantic analysis. After legality verification, they match the target application based on the preset business domain-application mapping relationship. Then, the arbitration service module 123, in conjunction with the cloud caching module, prioritizes querying the installation status of the target application. Effective caches are directly reused to reduce vehicle-cloud interaction overhead. When the cache is invalid or there is no cache, a status query command carrying the target identifier and request sequence number is sent to the Daemon module. The Daemon module calls the corresponding underlying interface to obtain the actual installation status according to two query branches: hardware and application, and returns it. The arbitration service module 123 then uses this information to... The system determines whether to implement business degradation, generates a final domain name result with degradation flags, and sends it to the vehicle. This ensures smooth service availability in hardware-deficient scenarios and significantly reduces arbitration latency through a caching mechanism. After receiving the final domain name result, the Daemon module uses a parallel distribution mechanism: one path sends it to the Adapter module for parameter adaptation and standard request assembly before passing it to the voice assistant module; the other path synchronizes it to the AI ​​subsystem module to integrate the front-end page, hardware status, and historical dialogues to update the local context cache. This ensures the execution efficiency of the main business chain and provides auxiliary verification support for subsequent interactions through multi-modal perception data. The voice assistant module responds on demand. After reading the scene assistance information from the AI ​​subsystem, a standard intent request is assembled and sent to the spatial cloud engine module. After identity authentication, parameter verification, sensitive content filtering, and end-side hardware specification verification, it is forwarded to the Agent cloud module. The Agent cloud module optimizes prompts, corrects context, and generates differentiated images. After being packaged into a material response package, it is returned along the original path. Finally, the voice assistant module distributes it to the downstream business application module to complete the material landing. The execution result is transmitted back to the cloud layer by layer along the original link to update the global dialogue context, forming a business closed loop. While ensuring that the business degradation is imperceptible, it also takes into account the response speed, material adaptability, and multi-turn interaction experience.

[0066] Optionally, Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 2 As shown, the electronic device 200 may include a processor 210 and a memory 220.

[0067] The memory 220 stores machine-executable instructions that can be executed by the processor 210. When the electronic device 200 is running, these machine-executable instructions are executed. The processor 210 and the memory 220 communicate via a bus. The processor 210 can execute these machine-executable instructions to implement a voice interaction processing method.

[0068] The memory 220, processor 210, and bus components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected via one or more communication buses or signal lines. The memory 220 includes at least one software functional module, which is stored or embedded in the operating system (OS) of the electronic device in the form of software or firmware. This software functional module has at least one executable module. The processor 210 executes the executable modules stored in the memory 220, such as the software functional modules and computer programs included in the voice interaction processing method.

[0069] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0070] The electronic device 200 can be selected according to actual needs; for example, it can be selected to be cloud-based. Furthermore, the electronic device 200 has software or a voice interaction processing system capable of executing voice interaction processing methods, etc.

[0071] The voice interaction processing method provided in this application embodiment can be executed by a processor in the electronic device 200. The voice interaction processing method provided in this application embodiment will be explained further below. Figure 3 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 1 .like Figure 3 As shown, the method may include: S310. In response to a user's voice request, determine the target application corresponding to the user's voice request based on the semantic recognition result of the user's voice request.

[0072] Among them, user voice requests are the original requests that users input into the system through voice interaction. They include both the original audio stream spoken by the user and the colloquial natural language text transcribed by automatic speech recognition, such as "generate a pixelated headlight sketch with a starry sky theme". The expression is colloquial and loosely structured, and only carries the user's subjective needs, which cannot be directly parsed and executed by the business system.

[0073] Semantic recognition results are standardized data output by cloud-based voice semantic services after keyword matching, semantic parsing, and structured decomposition of user voice text. This data includes three categories: business domain, user intent, and structured intent parameters. It is a crucial intermediate product that transforms user natural language needs into standardized, machine-recognizable, and transferable instructions. Specifically, the business domain is the top-level business classification boundary, used to define the business scenario to which the instruction belongs (e.g., pixelated headlight image, wallpaper image), determining the subsequent instruction distribution route and adaptation rules. User intent represents the user's core operational needs within the corresponding business domain, clarifying the specific actions the user expects to achieve. Intent parameters are structured and refined constraints on user intent, using quantifiable fields to carry execution conditions such as theme, style, size, and color; they are the core input basis for downstream business modules to implement user intent.

[0074] In one possible implementation, semantic recognition of user voice requests categorizes completed user needs into business domains. The system pre-configures a one-to-one mapping rule between business domains and downstream applications: when the semantic recognition result outputs the "pixel headlight image" business domain, it can be directly matched to the "pixel headlight" application through a preset mapping relationship; when it outputs the "wallpaper image" business domain, it matches the "wallpaper store" application. Simultaneously, the user intent type and intent parameters in the semantic recognition result can further verify the application's functional adaptability, ensuring that the matched application has the capability to handle such user needs, achieving targeted matching from natural language requirements to specific business applications. Based on this, this step is implemented collaboratively by the cloud-based speech recognition module and the speech semantic module. The vehicle-mounted voice daemon module serves as the primary local voice entry point, receiving the user's voice audio stream. It first performs local noise reduction, effective voice segmentation, and audio format encoding preprocessing to obtain processed audio data. This processed audio data is then uploaded to the cloud-based voice recognition module via the vehicle-to-everything (V2X) uplink channel. The cloud-based voice recognition module uses Automatic Speech Recognition (ASR) technology to convert the voice audio into structured user voice text, which is then transmitted to the voice semantic module. The voice semantic module first extracts core keywords from the user voice text and matches them against a pre-defined business domain keyword library to initially identify the business domain corresponding to the user's voice request. Then, it uses Natural Language Processing (NLP) technology to perform deep semantic analysis on the user voice text, identifying the user's core operational intent, i.e., the user intent, and the structured intent parameters corresponding to this core operational intent. The intent parameters are quantified execution data that carries the constraints of the user intent, such as constraints like theme, style, and color in image generation requirements. Next, the voice and semantic module performs legality and consistency checks on the business domain, user intent, and intent parameters. First, it verifies the accuracy of the business domain match; then, it verifies the unambiguity of the user intent; and finally, it verifies the logical conflicts of the intent parameters. Once the checks pass, based on the system's preset business domain-application mapping table, the business domain is mapped and bound to a unique target application identifier. Simultaneously, the verified intent parameters are converted into target intent business parameters adapted to the target application's format, ultimately determining the target application.

[0075] S320. If it is determined that the target application is not installed in the corresponding vehicle terminal, the semantic recognition result is replaced with the candidate recognition result.

[0076] Among them, the candidate recognition result is the result that is related to the semantic recognition result and the corresponding candidate application has been installed on the vehicle. It is a fallback alternative pre-configured by the system for each main business area. It belongs to the same business requirement as the original semantic recognition result, but is adapted to different landing business carriers. It is only enabled when the main business is unavailable. For example, the candidate recognition result corresponding to the pixel headlight raw image is the same theme wallpaper raw image instruction.

[0077] In one possible implementation, when the user's original voice request cannot be executed, a pre-matched alternative service of the same type is used to take over the user's needs. This avoids the user's voice request command failing directly and ensures a basic interactive experience. Simultaneously, the candidate recognition result and the original semantic recognition result belong to the same theme and need, but on different carriers, maximizing alignment with the user's original creative requirements. Based on this, this step is executed by the cloud arbitration service module. The installation status of the target application on the vehicle can be determined through a two-tiered mechanism of cloud caching priority and reverse lookup fallback. After obtaining the target application identifier, the arbitration service module prioritizes using the Vehicle Identifier (VIN) as the search key to retrieve vehicle service status records stored in the cloud cache module. It then extracts the installation status field corresponding to the target application identifier from these records. If the cached data exists and is within a preset 5-minute validity period, the cached service status is read directly to complete the determination, without needing to send a query command to the vehicle. If no corresponding cached record is found, or the cached data has expired, a reverse status query process is triggered. This process involves the cloud arbitration service module sending a status query command to the vehicle's voice daemon module. This command carries the target application identifier and a unique user voice request sequence number, used to identify the query object and match the response message. The vehicle's voice daemon module receives the command. After parsing the status query command, the system first determines the query type: if the target application is a hardware-related service (such as pixel headlights), it enters the hardware reading branch, calling the vehicle-side CAN bus hardware driver interface to read the actual hardware mounting status; if the target application is a software-related service (such as a wallpaper store), it enters the application list reading branch, calling the vehicle-side system application management service to read the application installation status. After reading, the voice daemon module encapsulates the actual installation status, the unique user voice request serial number, and the vehicle VIN into a response data packet, and sends it back to the cloud arbitration service module through the vehicle-cloud uplink channel. At the same time, the arbitration service module updates the cloud temporary status cache with the vehicle VIN as the key and resets the 5-minute validity period. When the arbitration service module determines that the installation status of the target application / hardware is not installed, it executes the business downgrade replacement logic. That is, the business domain in the original semantic recognition result is replaced with a candidate business domain with a topic association relationship, and the exclusive business parameters of the corresponding candidate application are re-bound. A downgrade marker field is added to the final domain result to indicate to the vehicle that this business is a replacement business for automatic system downgrade switching, so as to finally generate candidate recognition results. The degradation flag supports two designs: boolean (is_degrade = true / false) and enumeration (degrade_type = pixel_light_to_wallpaper).

[0078] It should be noted that the candidate recognition results retain the core requirement relevance to the original semantic recognition results. For example, if the original semantic recognition result is "generate pixel headlight starry sky line drawing", the candidate recognition result is the requirement for a wallpaper with the same starry sky theme. The corresponding candidate application is the wallpaper store that is already installed by default on the vehicle, ensuring that the candidate application can be implemented normally.

[0079] S330: Send the candidate recognition results to the vehicle terminal so that the vehicle terminal can forward the candidate recognition results to the candidate application corresponding to the candidate recognition results.

[0080] In one possible implementation, since the cloud can only perform preliminary domain matching and candidate filtering based on semantic models and cached data, while the vehicle-side possesses the actual installation status, running permissions, hardware compatibility capabilities, and current foreground scenario of local applications, the vehicle-side uniformly receives candidate results and completes the final application matching verification, parameter adaptation, and command delivery. This approach avoids the problem of user voice request command delivery failures caused by cloud cached data deviations, and enables unified permission control, end-to-end tracking, and anomaly fallback based on the vehicle-side's standardized cross-process communication framework. Simultaneously, it reduces the direct coupling between the cloud and various business applications, adapts to the complex operating environment of multiple applications and hardware in vehicles, and ensures the accuracy, security, and maintainability of user voice request command delivery. Based on this, this step is implemented through a layered forwarding link between the cloud and the vehicle. The cloud-based arbitration service module encapsulates candidate recognition results containing candidate business domains, candidate user intents, candidate intent parameters adapted to candidate applications, and downgrade markers. These results are then sent as the final domain-specific resolution result to the vehicle's voice daemon module via the vehicle-to-everything (V2X) downlink channel. The voice daemon module receives and parses the data packet containing the final domain-specific resolution result. Based on the candidate business domain, it matches the corresponding dedicated voice adapter (e.g., a wallpaper store voice adapter for wallpaper services) and sends the candidate recognition result to the corresponding voice adapter module via the AIDL cross-process communication mechanism. The voice adapter module first performs parameter integrity verification on the data packet and eliminates any incorrect entries. The cloud uses a universal encapsulation field and redundant message headers to bind the exclusive parameter specifications of candidate services. The data is then assembled into a standard business request that can be recognized by downstream business application modules and pushed to the vehicle-side voice assistant module. After receiving the standard business request, the vehicle-side voice assistant module initiates a complete business processing flow based on the candidate recognition results, including calling cloud-based image generation capabilities to generate corresponding materials and caching materials locally. Finally, the business execution instructions and generated materials corresponding to the candidate recognition results are forwarded to the candidate application to complete the implementation. If the candidate recognition results carry a downgrade flag, the candidate application will simultaneously display a preset downgrade prompt message to inform the user that the original target application is unavailable and the system has automatically switched to an alternative service with the same theme.

[0081] The voice interaction processing method provided in this application responds to user voice requests, completes business domaining based on the semantic recognition results of the user's voice request, and determines the corresponding target application. Simultaneously, it verifies the installation status of the target application in the corresponding vehicle through cloud cache retrieval or vehicle-side reverse lookup. If it is determined that the target application is not installed, the original semantic recognition result is replaced with a candidate recognition result that is topic-related and whose corresponding candidate application is already installed on the vehicle. This establishes an elastic degradation and replacement mechanism in the cloud-based voice domaining link, resolving the strong dependency of the original routing logic on the target application's installation status. Finally, the candidate recognition result is sent to the vehicle-side voice entry point, and the vehicle forwards it to the candidate application matching the candidate recognition result to complete business execution. This effectively avoids voice request distribution failures caused by the target application not being installed, disabled, or having version incompatibility, ensuring normal closed-loop response of voice commands. Furthermore, the associative degradation and replacement preserves the user's core needs and intentions, preventing business from deviating from user expectations and improving the usability and user experience of voice interaction.

[0082] Figure 4 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 2 .like Figure 4 As shown, the above method determines the target application corresponding to the user's voice request based on the semantic recognition result of the user's voice request, including: S410. Read the business domain corresponding to the user's voice request from the semantic recognition result of the user's voice request.

[0083] Among them, the business domain is a top-level classification label for various independent business capabilities within the system. It is the core dimension for determining the business affiliation of user voice request commands during the voice semantic parsing stage, and is used to define the business boundaries and capability scope corresponding to user voice request commands from the root. In this application, it is used as a field to distinguish different businesses. On the one hand, different business domains correspond to independent business systems. For example, the pixel headlight domain is associated with hardware driver interfaces, simple drawing generation specifications, and light projection execution logic, while the wallpaper domain is associated with wallpaper mall applications, high-definition image generation rules, and desktop setting capabilities. The parameter standards, dependent resources, and implementation paths of the two do not overlap. Using the business domain as a classification identifier can naturally achieve business diversion. On the other hand, the business domain is determined at the semantic domain stage at the very beginning of the link and will run through the entire process of cloud arbitration, parameter adaptation, image generation, and downstream distribution. It will not change with the differences in users' colloquial expressions, and as a classification field, it has extremely high stability and universality.

[0084] In one possible implementation, this step is executed by a cloud-based voice semantic module. After receiving the semantic recognition result of the user's voice request (which is now the user's voice text), the module first performs word segmentation and part-of-speech tagging on the user's voice text using a Chinese word segmentation algorithm to extract keywords containing business characteristics. The extracted keywords are then matched against a pre-built keyword library categorized by business dimensions. The matching overlap between the keyword set and each business domain is calculated, and the business category with the highest matching degree and reaching a preset matching threshold is selected as the business domain corresponding to the user's voice request. The keyword library is pre-built in the cloud and categorized by business dimensions; the preset matching threshold can be selected based on actual conditions.

[0085] S420. Based on the preset mapping relationship between business domains and applications, determine the target application corresponding to the business domain.

[0086] The pre-defined mapping relationship between business domains and applications is stored in the configuration module of the cloud semantic module in the form of a structured key-value pair mapping table. The mapping table uses the unique identifier of the business domain as the index key and the unique application identifier of the corresponding in-vehicle application as the mapping value. It supports back-end operation and maintenance personnel to flexibly add and modify mapping entries to adapt to business iteration needs.

[0087] In one possible implementation, the execution entity for this step is also a cloud-based voice and semantic service. After completing the business domain determination and verifying the legality of the business domain, user intent, and intent parameters to ensure there are no conflicts or illegal values, the voice and semantic module uses the currently verified business domain identifier as the retrieval condition to perform a table lookup and matching in the preset business domain-application mapping table. The retrieval yields the unique application identifier corresponding to the business domain, which is the target application corresponding to this user's voice request.

[0088] It should be noted that after the target application is determined, the initially identified general user intent (i.e., the verified user intent) and general intent parameters (i.e., the verified intent parameters) will be further associated and adapted with the target application. The general intent business parameters will be converted into exclusive target intent business parameters that can be recognized and executed by the target application, so as to complete the business adaptation of semantic commands and ensure that downstream in-vehicle business applications can directly parse and execute the user's voice request commands without the need for secondary parameter conversion.

[0089] The voice interaction processing method provided in this application extracts core keywords from the semantic recognition results of user voice requests and matches them with a preset keyword library for different business domains. This parsing process obtains the corresponding business domain of the user request. The business domain is a classification field that distinguishes different in-vehicle services, enabling rapid categorization of business requests. Subsequently, based on the preset mapping relationship between business domains and applications, the method automatically matches and determines the target application corresponding to the business domain. This completes the determination of the business entry point during the semantic parsing stage, providing a preliminary basis for the subsequent business-oriented adaptation of intent parameters and command issuance. This reduces the probability of mismatch between cross-business commands and improves the execution accuracy and response efficiency of voice commands.

[0090] Optionally, the semantic recognition results may also include: user intent and intent parameters.

[0091] Among them, user intent refers to the specific operation of the user's voice request in the business domain; intent parameters are the specific execution conditions corresponding to the user intent.

[0092] In one possible implementation, this step is executed by the cloud-based speech and semantic module, serving as the conversion step from natural language to structured executable instructions. The cloud-based speech recognition module first converts the user's speech into user speech-text using ASR (Automatic Speech Recognition). The speech and semantic module then determines the business domain by comparing keywords against a pre-defined business keyword library. Next, it performs deep semantic analysis on the user's speech-text, decomposing and outputting two types of structured data: user intent and intent parameters. The user intent corresponds to the user's core operational request within the current business domain. For example, in the domain of pixel headlight image generation, the user intent could be visualized as "generate custom image materials," clearly defining the core action direction. The intent parameters are quantified constraints on the user intent, including key-value pairs such as image theme, style, color, and canvas size, which can be recognized by downstream models and serve as the direct input basis for the business module to execute specific operations.

[0093] In the above method, the semantic recognition result is replaced with the candidate recognition result, including: Based on the business domain, candidate business domains are identified.

[0094] Among them, the candidate business domains are those that are related to the business domains and for which the corresponding candidate applications have been installed.

[0095] In one possible implementation, this step is executed by the cloud arbitration service module. It is used to filter legally available alternative business domains when the hardware / application corresponding to the original business domain is unavailable, serving as the determination step in the business degradation mechanism. Specifically, the system has a pre-defined business domain association mapping table. Based on business attributes and requirement reusability, it defines the alternative association relationships for each domain. For example, the candidate associated domain for pixel headlight image generation is the wallpaper image generation domain. Both belong to the AIGC image generation business scope, and users' core image generation needs such as themes and styles can be directly reused, ensuring consistency of requirements after degradation. Then, the arbitration service module verifies the installation status of candidate applications through a cache-first, reverse query fallback mechanism. Specifically, it prioritizes retrieving business status records cached in the cloud using the vehicle VIN as an index, directly reading the installation status of candidate applications. The cache is set to have a 5-minute validity period to avoid duplicate queries. If the cache is missing or expired, a reverse query process is triggered. The cloud sends a status query command carrying the candidate application identifier and the user's voice request sequence number to the vehicle-side voice Daemon module. The voice Daemon module then calls the corresponding underlying interface based on the query type. In essence, the hardware status is invoked via the CAN bus driver interface, and the application installation status is invoked via the system application management service. After reading the actual installation status, it is encapsulated and sent back to the cloud. Finally, the arbitration service module selects domains that simultaneously meet the requirements of having a preset association with the original business domain and having the corresponding candidate application / hardware already installed as candidate business domains. This ensures both the relevance of the downgraded business to the user's original voice needs and the normal execution of the downgraded business, avoiding the failure of user voice request commands.

[0096] Candidate intent parameters are determined based on user intent and intent parameters.

[0097] Among them, the candidate intent parameter is the specific execution condition corresponding to the user intent in the candidate business domain.

[0098] In one possible implementation, when no matching target application is found in the cloud and business downgrade adaptation is required, the downgrade only changes the business carrier and application entry point for the user's voice request command, while the user's core operational needs and personalized constraints remain unchanged. The user's intent clearly defines the behavioral attributes and overall boundaries of the parameter constraints for this operation, ensuring that the downgraded business direction aligns with the user's initial intention. The original intent parameters carry the details of the user's clearly expressed personalized needs and are the core source of candidate parameters. Based on this, by matching the preset parameter specifications of the alternative business, adapting the format of the original intent parameters, completing missing fields, and mapping business attributes, a complete set of candidate intent parameters that conforms to the validation rules of the alternative business can be output. This set can both accommodate the user's actual needs and provide standardized input for subsequent parameter validation and execution of the downgraded business. Based on this, the user's original intent and corresponding intent parameters are first retained. These intent parameters include at least the user-specified theme, core style, and color scheme to ensure that the downgraded content meets the user's expectations. Then, according to the specific business specifications of the candidate business domain, the specification constraints in the original intent parameters are adapted and modified. For example, when the original business domain is a pixel-level headlight image, the original intent parameters include low-line sketch constraints and 400... The 120 headlights project a dedicated canvas size. When the candidate business area switches to wallpaper images, the system replaces the canvas size with the standard resolution of the vehicle screen, adjusts line and image quality constraints to adapt to the high-definition display requirements of wallpapers, and simultaneously updates the business affiliation marker of the intent parameters to obtain candidate intent parameters. These candidate intent parameters ensure the consistency of core user needs, achieve a degradation effect for the same content on different platforms, and avoid problems such as image generation failure and abnormal material display caused by incompatible intent parameter specifications, thus guaranteeing the execution quality of the downgraded business.

[0099] Based on user intent, candidate business domains, and candidate intent parameters, candidate recognition results are generated to replace semantic recognition results.

[0100] In one possible implementation, this step is completed by the cloud arbitration service module, serving as the final output of the cloud arbitration phase. First, the user's original intent, the selected and confirmed candidate business domains, and the adapted candidate intent parameters are integrated and encapsulated, with a degradation marker field added. The resulting encapsulated candidate recognition result is the final domain landing result. The cloud uses this candidate recognition result to replace the initial original semantic recognition result and sends it to the vehicle-side voice daemon module to enter the business execution chain. Downstream business application modules can identify the degradation status through the degradation marker field and display corresponding prompts to the user upon business execution, ensuring the user's right to know.

[0101] The voice interaction processing method provided in this application further includes the following semantic recognition results: user intent and intent parameters. The user intent is the specific operation requested by the user in the business domain; the intent parameters are the specific execution conditions corresponding to the user intent. Based on the original business domain, candidate business domains that are related to the original business domain and whose corresponding candidate applications have been installed on the vehicle side are matched and filtered. At the same time, the original intent parameters are combined with the user's original intent to convert them into executable candidate intent parameters under the candidate business domains. Finally, based on the user's original intent, candidate business domains, and candidate intent parameters, candidate recognition results are generated and replace the original semantic recognition results. Thus, this application automatically completes the seamless degradation adaptation of related businesses in scenarios where the target business is unavailable, effectively improving the success rate of voice command execution, avoiding command execution failures due to hardware deficiencies or application non-installation, and optimizing the user's voice interaction experience.

[0102] Optionally, the above method determines candidate intent parameters based on user intent and intent parameters, including: If the user's intent is a multi-round modification instruction, then compare the intent parameters with the historical intent parameters, update the user's modified items and retain the unmodified items to obtain candidate intent parameters.

[0103] Multi-round modification instructions are adjustments made by the user to previous voice requests within the current conversation round. These instructions are characterized by incremental adjustments within the same session, rather than independent, entirely new requests. Specifically, they are voice expressions by the user making partial modifications or attribute adjustments to materials or submitted requirements from the previous round, such as "change the pattern to blue" or "change to a simple line drawing style," etc. The system recognizes these instructions by combining the semantic features of the LLM model with the ASR-transcribed text, while also considering the current conversation context. It determines whether the multi-round modification instruction refers to a historical request and makes the necessary adjustments, ultimately outputting a label indicating the operation type of the multi-round iterative modification.

[0104] Historical intent parameters are retrieved from the current dialogue history. They are stored in a cloud-based context memory. After each dialogue round, the voice daemon module synchronizes the execution result to the cloud-based voice semantic module and stores it in the cloud context memory, which contains the structured intent parameters confirmed for each round. The index for retrieval is based on the unique context ID assigned to the current dialogue. The agent cloud module can retrieve the current dialogue history based on this unique context ID and perform index matching, ensuring that only historical parameters from the same session are retrieved, preventing parameter confusion across sessions or users. The subsequent retrieval includes all structured intent parameters that took effect in the previous dialogue round, as well as the corresponding generated material's metadata, covering all constraint fields such as theme, style, color, canvas size, and business affiliation. The retrieval action is triggered only after determining that the current instruction is a multi-round modification instruction; retrieval is not triggered in non-multi-round scenarios to reduce unnecessary cloud data interaction and lower system overhead.

[0105] In one possible implementation, this step corresponds to the context memory correction stage of the AIGC image pipeline in the Agent cloud module. Specifically, the determination of multi-round modification instructions is based on the operation type label output by the intent classification of the LLM large model. The operation type includes at least: new generation operation type and multi-round iterative modification operation type. When it is marked as multi-round iterative modification, this branch logic is triggered, that is, comparing the intent parameters with the historical intent parameters, updating the user's modified items and retaining the unmodified items, to obtain candidate intent parameters. Among them, the LLM large model will decompose the user requirements into a set of quantifiable key-value pair structured parameters such as theme, style, color, canvas size, etc., and use each structured parameter field as an independent unit to match and verify the current round intent parameters with the historical intent parameters one by one. Then, the parameter items with different field values ​​are determined as user modified items, and the parameter values ​​of the current round overwrite the historical parameter values; the parameter items with no difference in field values ​​are determined as unmodified items, and the historical parameter values ​​are directly used. If there is a logical conflict between the old and new parameters (e.g., historical parameters are in color while current parameters are in black and white), the conflicting items are automatically overwritten with the parameter values ​​from the latest round, thus eliminating the parameter contradiction. Finally, after integrating all parameter items, a complete and logically consistent candidate intent parameter is obtained, which serves as the input basis for the downstream AIGC image generation model.

[0106] If the user intent is not a multi-round modification instruction, then the intent parameter will be used as a candidate intent parameter.

[0107] In one possible implementation, when the operation type output by the LLM large model is marked as "new generation," it indicates that the current user intent is not a multi-round modification command, meaning the user is initiating an independent, entirely new image request, unrelated to any adjustments made to historical requests within the same session. Therefore, there's no need to call the cloud context memory or perform parameter comparisons or incremental merging; the structured intent parameters obtained after semantic parsing and standardization in this round are directly used as the candidate intent parameter set. This simplifies the processing chain for single-round independent requests, skipping the historical parameter reading and comparison stage, shortening the response latency of image requests, and improving the execution efficiency of single voice commands. It also avoids interference from historical parameters on new user voice requests, ensuring the accuracy and purity of independent image generation requirements.

[0108] The voice interaction processing method provided in this application, if the user's intent is a multi-round modification instruction, i.e., an adjustment instruction made by the user in the current dialogue round to a historical voice request within the same conversation, reads the historical intent parameters corresponding to the current dialogue round from the cloud context memory, compares the intent parameters parsed in the current round with the historical intent parameters field by field, updates only the parameter items that the user has explicitly modified, retains the historical constraint parameters that have not been modified, and automatically overwrites parameter items with logical conflicts, ultimately generating candidate intent parameters that meet the user's complete needs; if it is determined not to be a multi-round modification instruction, the intent parameters parsed in the current round are directly used as candidate intent parameters. Therefore, this application can completely continue the user's historical needs in multi-round interaction scenarios, avoids the user repeatedly inputting all parameters, and reduces parameter processing redundancy through field-level incremental updates, balancing the response efficiency of single-round requests with the consistency of needs in multi-round dialogues.

[0109] Figure 5 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 3 .like Figure 5 As shown, the method described above determines the installation status of the target application in the corresponding vehicle, including: S510: Read the installation status of the target application in the corresponding vehicle from the cloud cache.

[0110] In one possible implementation, a vehicle service status cache is pre-configured in the cloud. This cache uses the vehicle's unique identification number (VIN) as the primary key index. Each cached record corresponds to multiple hardware and application installation statuses for a single vehicle, and each status record has a preset validity period (e.g., 5 minutes) to control data freshness. After the cloud semantic module completes the initial domain location and determines the target application, the arbitration service module first uses the VIN of the vehicle corresponding to the current request as the search key to match the corresponding vehicle's status record in the cache, and then extracts the installation status field bound to the unique identifier of the target application from that status record. By utilizing the cloud cache to reuse historical query results, repeated vehicle-side queries for the same vehicle within a short period of time are avoided, thereby reducing the occupation of the vehicle network channel and reducing the overall latency of service availability determination.

[0111] S520: If the target application's installation status is not found in the cloud cache, or the installation status has expired, a status query command is sent to the vehicle.

[0112] The status query command carries the identifier of the target application.

[0113] In one possible implementation, this step includes two triggering conditions, with a downlink query triggered if either condition is met: First, a cache miss, meaning the cloud cache does not contain a status record corresponding to the vehicle's VIN, or the status record does not contain the status field of the current target application; second, a cache expiration, meaning the corresponding status record's generation time has exceeded the preset 5-minute validity period, and the data reliability cannot meet the arbitration requirements. After triggering the query, the arbitration service module generates a standardized status query command message, which carries at least the target application's unique identifier and the user's voice request sequence number. The user's voice request sequence number is a globally unique identifier for this query, used to match the response results returned by the vehicle, avoiding response packet corruption in multi-vehicle concurrent query scenarios. Subsequently, the arbitration service module sends the query command message to the corresponding vehicle's voice daemon module via the vehicle network downlink data channel.

[0114] S530: Receives the installation status of the target application returned by the vehicle terminal based on the status query command.

[0115] In one possible implementation, after receiving a status query command, the vehicle-side voice daemon module first parses the target application identifier and user voice request sequence number in the command. Based on the attributes of the target application identifier, it determines the query type: if it's a hardware query such as a pixel headlight, it calls the vehicle-side CAN bus hardware driver interface to read the actual hardware mounting status; if it's an application query such as a wallpaper store, it calls the vehicle-side system application management service interface to read the actual application installation status. After reading the actual installation status, the voice daemon module encapsulates the installation status result, user voice request sequence number, and vehicle VIN into a standardized response data packet and transmits it back to the cloud arbitration service module via the vehicle network uplink channel. Upon receiving this response data packet, the cloud arbitration service module first matches the corresponding query request using the user voice request sequence number, then extracts the valid installation status field. Simultaneously, using the vehicle VIN as the primary key, it updates the latest status obtained from this query to the cloud status cache and resets the 5-minute validity period of this record, providing reusable data for subsequent query requests from the same vehicle.

[0116] The voice interaction processing method provided in this application reads the installation status of the target application in the corresponding vehicle terminal from the cloud cache. Based on the cache reuse mechanism, it avoids repeatedly initiating vehicle terminal queries, effectively reducing the overhead of vehicle-cloud interaction and the latency of business status determination. If there is no corresponding installation status record in the cloud cache, or the record has expired after a preset validity period, a status query command carrying the target application identifier is sent to the vehicle terminal through the vehicle network downlink channel, triggering the vehicle terminal to collect the real installation status in real time. Subsequently, the real-time installation status result returned by the vehicle terminal based on the status query command is received. In this way, while taking into account query efficiency, it ensures that the status determination result is consistent with the actual configuration of the vehicle terminal, providing an accurate basis for subsequent business degradation arbitration.

[0117] Figure 6 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 4 .like Figure 6 As shown, after sending the candidate recognition results to the vehicle, the above method also includes: S610 receives standard intent requests sent by the vehicle-side voice assistant.

[0118] The standard intent request is generated based on the candidate identification results.

[0119] In one possible implementation, the vehicle-side voice assistant serves as the scheduling entry point for the vehicle-side image generation service. After receiving the domain parameters from the voice adapter module, it supplements the vehicle's VIN, hardware dimensions, and scene information as needed. It then standardizes and encapsulates the candidate recognition results obtained from the previous cloud-based semantic parsing, generating a standardized intent request with a uniform format. This request is then sent to the spatial cloud engine via the vehicle-to-everything (V2X) uplink channel. The candidate recognition results originate from the semantic parsing and arbitration process of the front-end cloud-based voice semantic service, including information such as candidate business domains, candidate intent parameters, downgrade markers, and dialogue context IDs. Upon receiving the standardized intent request, the spatial cloud engine module first completes vehicle identity authentication, parameter format verification, and sensitive content filtering. Only after successful verification is the request forwarded to the Agent cloud module. This ensures both the legality and security of the request, and also avoids additional format conversions in the cloud through standardized messages, improving request processing efficiency.

[0120] S620: Based on the candidate business domain and candidate intent parameters in the candidate recognition results, call the business materials generated by the vehicle-side voice assistant.

[0121] Among them, business materials are rendering data adapted to the corresponding hardware devices in the candidate business domain.

[0122] In one preferred implementation, if the candidate business domain is the first business domain (e.g., headlight interaction domain), then based on the candidate intent parameters (e.g., animal type, shape outline), a simple line drawing material adapted to the headlight projection canvas is generated. This simple line drawing material is the business material. The first business domain belongs to the pixel headlight image generation business under the headlight interaction domain. When the Agent cloud module determines that the candidate business domain belongs to the pixel headlight image generation business domain, it will forcefully constrain the image generation model to output a simple line drawing style with low lines and no complex fills based on the candidate intent parameters, while simultaneously matching the projection canvas size of the pixel headlight hardware (e.g., 400). Using 120-pixel resolution and monochrome illumination, we generate simple line drawing materials adapted for headlight projection canvases.

[0123] It should be noted that, due to the limited number of light-emitting units and low resolution of headlight projection, complex fillings and dense lines can cause the projected image to be blurry and lose its recognizability. Therefore, by forcing a simplified drawing style and size constraints, we ensure that the generated pattern can be clearly and completely projected and displayed through the headlight hardware. The final output business material is a simplified drawing image file that conforms to the headlight projection specifications.

[0124] As another preferred implementation, if the candidate business domain is the second business domain (e.g., the in-vehicle display domain), then wallpaper materials adapted to the vehicle's screen resolution are generated based on candidate intent parameters (e.g., landscape type, color preference). These business materials are wallpaper materials. The second business domain falls under the wallpaper business within the in-vehicle screen display domain, covering in-vehicle screen display scenarios such as the desktop and lock screen. When the Agent cloud module determines that the candidate business domain belongs to the wallpaper business domain, it constrains the raw image model based on the candidate intent parameters to output a high-resolution, detailed image, while simultaneously matching the physical resolution and aspect ratio of the in-vehicle central control screen to generate wallpaper materials adapted to the in-vehicle screen resolution.

[0125] It should be noted that this branch supports two types of triggering scenarios: one is the native wallpaper generation command initiated directly by the user, and the other is the wallpaper generation command after cloud arbitration and downgrading when the pixel headlight hardware is not installed; the final output business material is a high-definition wallpaper image file that conforms to the vehicle display specifications and can be directly used for vehicle wallpaper settings to avoid display abnormalities such as image stretching, blurring, and aspect ratio distortion.

[0126] The second business area differs from the first business area.

[0127] In addition, it should be noted that those skilled in the art will understand that the above-mentioned headlight sketches and in-vehicle wallpapers are merely examples. Depending on the actual application scenario, the business materials may also be navigation animations adapted to HUDs, lighting timing data adapted to ambient lights, etc., and this application does not limit them in this regard.

[0128] In one possible implementation, since the user's true intent is determined from the moment the command is issued and does not change as the system's recognition phase progresses, the candidate business domain and candidate intent parameters are essentially preliminary analysis results of the user's constant true intent, already covering the business direction and personalized constraints required for material generation. Therefore, based on this candidate recognition result, the vehicle-side voice assistant's image generation capabilities can be invoked in advance to pre-generate business materials. Once the final domain result is confirmed, the materials can be directly deployed, thereby shortening user waiting time and improving interaction response efficiency. Based on this, the candidate intent parameters are first ambiguously clarified, structurally extracted, and the prompt words optimized using a large language model, decomposing quantifiable key-value pair parameters such as theme, style, color, and size to generate standardized drawing prompt words that conform to the input specifications of the image generation model. Then, the historical dialogue records in the cloud are retrieved in conjunction with the dialogue context ID. If it is a multi-round modification scenario, only the user's modified parameters are incrementally updated, and conflicting parameters are automatically overridden. If it is a completely new generation, the current full set of parameters is used. Finally, the standardized prompt words and corresponding hardware specification parameters are input into the AIGC image generation model to complete the automated generation of business materials.

[0129] S630: Distribute business materials to the vehicle's voice assistant.

[0130] In one possible implementation, the Agent cloud module first uploads the generated image file to the cloud resource server, generates a download resource link that can be resumed after interruption, and encapsulates metadata such as material size, business ownership, degradation flag, and dialogue ID, assembling it into a standard response message and returning it to the spatial cloud engine module. The spatial cloud engine module then sends this standard response message to the vehicle-side voice assistant module via the vehicle network downlink channel. After receiving the message, the vehicle-side voice assistant module performs local image caching and metadata parsing, which is then used for subsequent distribution to downstream business applications such as the pixel headlight application and wallpaper store for deployment.

[0131] The voice interaction processing method provided in this application involves receiving a standard intent request uploaded by the vehicle-side voice assistant in the cloud. This standard intent request is generated by standardizing and encapsulating the candidate recognition results output by semantic parsing. Based on the candidate business domain and candidate intent parameters in the candidate recognition results, the cloud generates business materials in the form of rendering data adapted to the corresponding hardware devices of the candidate business domain. Finally, the generated business materials and supporting metadata are sent to the vehicle-side voice assistant to complete the end-to-cloud collaborative image-based business response, taking into account both material adaptability and generation efficiency for different hardware scenarios.

[0132] Figure 7 A flowchart illustrating a voice interaction processing method provided in this application embodiment. Figure 5 .like Figure 7 As shown, this voice interaction processing method is applied to the vehicle side, and the method includes: S710 receives candidate recognition results sent from the cloud.

[0133] Among them, the candidate recognition result is the result obtained by replacing the semantic recognition result in the cloud when the target application is detected not to be installed on the vehicle.

[0134] Among them, the candidate recognition results are related to the semantic recognition results, and the corresponding candidate applications have been installed on the vehicle. For example, if the user command is "generate a starry sky themed headlight sketch", the downgraded candidate recognition results still retain the starry sky theme and sketch style, only replacing the business carrier from pixel headlight projection to in-vehicle wallpaper display, ensuring that the replacement result matches the user's initial requirements and achieving a seamless downgrade.

[0135] In one possible implementation, when it is determined that the target application / hardware is not installed, the cloud arbitration service module replaces the business domain in the original semantic recognition result with a preset alternative business domain (e.g., replacing the pixel headlight image domain with the wallpaper image domain), rebinds the exclusive parameter specifications corresponding to the alternative business domain, and appends a downgrade marker field to the result message, ultimately generating a complete candidate recognition result and sending it to the vehicle. The vehicle then receives this candidate recognition result.

[0136] S720. Parse the candidate recognition results and forward the parsed candidate recognition results to the candidate application corresponding to the candidate recognition results.

[0137] In one possible implementation, the voice daemon module decodes the data packets of candidate recognition results, strips off the cloud-based general message encapsulation header, and extracts fields such as candidate business domain, user intent, structured intent parameters, and degradation flags. After verifying the field format and legality, it forms standardized internal command data. Then, based on the extracted candidate business domain, the voice daemon module matches the corresponding business-specific voice adapter in a locally preset business domain-adapter mapping table (e.g., if the candidate business is wallpaper images, then match the wallpaper voice adapter). Subsequently, through the AIDL cross-process communication interface, it forwards the parsed standardized internal command data to the corresponding voice adapter module. The voice adapter module further completes business parameter adaptation and redundant field removal, and finally connects to the business interface of the candidate application (e.g., a wallpaper store), realizing the landing and flow of user voice request commands.

[0138] The voice interaction processing method provided in this application receives candidate recognition results from the cloud. These candidate recognition results are obtained by replacing the semantic recognition results when the cloud detects that the target application is not installed on the vehicle. The candidate recognition results are related to the semantic recognition results, and the corresponding candidate applications are already installed on the vehicle. The method parses the candidate recognition results and forwards them to the corresponding candidate applications. Therefore, this application can automatically complete service degradation and transition in scenarios where the target hardware or application is unavailable, without requiring the user to re-initiate voice commands, effectively improving the hardware compatibility and smoothness of in-vehicle voice services.

[0139] Optionally, parsing the candidate recognition results in the above method includes: The candidate identification results are analyzed to determine the corresponding candidate business domains and candidate intent parameters.

[0140] Among them, the candidate recognition result is the original semantic response message issued by the cloud-based voice and semantic module after completing the preliminary semantic processing of the user's voice command. The original semantic response message is encapsulated in a structured JSON format and includes at least the following fields: business domain encoding, intent identifier, original parameter key-value pairs, and ASR transcribed text. Its generation is based on the preliminary semantic conclusions obtained by the cloud through comparison with a preset keyword library and classification by a semantic model.

[0141] In one possible implementation, the general encapsulation header of the transport layer is stripped through a preset message protocol decoding to extract semantic layer data. Next, a preset business domain encoding mapping table is queried to map the abstract domain encoding in the message to concrete candidate business domains. For example, the encoding "PIXEL_LIGHT" is mapped to the pixel headlight image domain, or "WALLPAPER" is mapped to the wallpaper image domain. Finally, the original constraints corresponding to the user's colloquial expressions are extracted from the parameter fields in the message to form candidate intent parameters. These candidate intent parameters include at least: personalized content explicitly mentioned by the user, such as pattern theme, style, and color. At this stage, the parameters have not yet undergone business specification verification and format standardization, retaining their original semantic parsing form. Based on the candidate business domains, a corresponding business adapter is matched to convert the candidate intent parameters into a standard intent request executed by the vehicle.

[0142] The parsed candidate recognition results include a standard intent request. This standard intent request includes at least: a business affiliation identifier, structured graph parameters, a degradation flag, and a dialogue context ID. This standard intent request is the output node of the voice adapter module, connecting the upstream semantic parsing results with the downstream business execution link. It is the key carrier for the user's voice request command to be implemented from the semantic layer to the business layer. The vehicle-side voice assistant module can directly read this standard intent request to trigger the subsequent graph generation process without being aware of the differences in upstream semantic parsing. This ensures the consistency of the entry point for different business commands and reduces the complexity of the integration with downstream business application modules.

[0143] In one possible implementation, the system pre-defines a static mapping table of business domains and adapters, storing the one-to-one binding relationship between each business domain and its corresponding voice adapter. For example, the pixel headlight image domain corresponds to the pixel headlight voice adapter, and the wallpaper image domain corresponds to the wallpaper store voice adapter. This static mapping table can be extended through configuration files to adapt to new business scenarios. After the voice daemon module parses the candidate business domains, it queries the static mapping table to complete the adapter routing match. Subsequently, through the AIDL cross-process communication mechanism, the candidate intent parameters and business domain identifiers are sent to the successfully matched business adapters. The business adapter performs the following processing: First, it validates the parameters to check if any required fields are missing from the candidate intent parameters, while removing redundant encapsulated fields common to the cloud and retaining only valid parameters related to the image generation business. Then, it loads the corresponding parameter specifications according to the business domain. For example, the pixel headlight business is bound to the projection canvas size and line quantity constraints, while the wallpaper business is bound to the vehicle screen resolution and image quality level constraints. Finally, it converts the original spoken parameters into structured parameters with unified key names and unified data formats, and finally encapsulates them into a standard intent request that can be directly recognized by the vehicle image generation business. Through the conversion processing of the dedicated adapter, the decoupling of general voice capabilities and vertical business is achieved. When adding a new business, only the corresponding adapter needs to be added, without modifying the voice link.

[0144] The voice interaction processing method provided in this application parses the candidate recognition results to determine the corresponding candidate business domains and candidate intent parameters; it matches the corresponding business adapters based on the candidate business domains, and converts the candidate intent parameters into standard intent requests for vehicle-side execution through the business adapters; wherein, the parsed candidate recognition results include: standard intent requests. Therefore, this application can unify the instruction entry format of different services based on the standard intent request, reduce the adaptation cost of downstream business application modules, and improve the execution efficiency and parameter compatibility of voice commands.

[0145] Optionally, the above method, which matches the corresponding business adapter based on the candidate business domain, includes: Obtain the business domain identifier corresponding to the candidate business domain.

[0146] In one possible approach, the textualized candidate domain results output by semantic parsing are converted into a standardized and unique code that can be uniformly recognized across the entire edge-cloud chain. This eliminates ambiguity and expression differences in natural language descriptions, providing a unified judgment benchmark for subsequent business routing and distribution, parameter specification matching, material generation scheduling, and business degradation adjudication. Standardized domain identifiers can decouple modules from the semantic layer and the business execution layer, ensuring that each link, such as the voice adapter, image assistant, and cloud arbitration, completes business matching, permission verification, and link scheduling based on the same set of encoding rules. Simultaneously, it supports rapid domain switching and full-link business log traceability in degradation scenarios, ensuring the consistency and reliability of business flow in the edge-cloud collaborative process.

[0147] Based on this, after the cloud-based speech and semantic service completes keyword matching and semantic analysis of the user's speech text and outputs a set of candidate business domain texts with confidence scores, it traverses the pre-configured business domain mapping rule library. It reads the one-to-one correspondence between pre-set domain keywords, semantic tags, and unique business domain identifiers in the rule library. Through a combination of text keyword matching and semantic similarity weighted calculation, it matches a standardized business domain code for each candidate business domain. If multiple sets of candidate business domain matching results exist, they are sorted from highest to lowest confidence score, and the result with the highest confidence score and meeting the preset matching threshold is selected as the final business domain identifier. After matching, the business validity of the business domain identifier is simultaneously verified. Once confirmed, the business domain identifier is bound and encapsulated with the candidate intent parameters, and the corresponding business parameter specifications, degradation strategies, and other configuration information are associated with the identifier. Finally, standardized recognition results are output to downstream modules.

[0148] Based on the business domain identifier, the local business adapter that matches the candidate business domain is invoked.

[0149] Among them, the business adapter is a local component used to handle requests for the corresponding business domain. Different business domain identifiers have corresponding business adapters pre-set.

[0150] In one possible implementation, after receiving the candidate recognition result carrying the business domain identifier, the vehicle's voice daemon first loads a locally pre-configured business domain identifier-adapter mapping table. This mapping table pre-stores a one-to-one correspondence between all business domain identifiers and the component names, communication interfaces, and calling permissions of the corresponding local voice service adapters. Subsequently, the voice daemon extracts the business domain identifier from the candidate recognition result and performs a match in the mapping table using the business domain identifier as the search keyword to locate the unique component information of the local service adapter that corresponds one-to-one with the candidate business domain. Next, the voice daemon verifies the process running status and service calling permissions of the target service adapter. After confirming that the adapter has been properly registered, is in an available state, and has the calling permissions for the current service, it establishes a data transmission link with the target service adapter through a cross-process communication interface and sends the standardized candidate recognition result data packet to the matched local service adapter, completing the triggering of the adaptation call and data delivery.

[0151] For example, if the candidate business domain is the first business domain, then the first business adapter corresponding to the first business domain is invoked.

[0152] The first business area is pixel headlight business in the scenario of projecting headlights onto vehicles.

[0153] In one possible implementation, when the business domain is determined to be the pixel headlight business corresponding to the vehicle headlight projection scenario (i.e., the first business domain), the voice daemon module, based on the AIDL cross-process communication mechanism, initiates an inter-process call to the first business adapter (such as the pixel headlight voice adapter) that is pre-mapped one-to-one with the pixel headlight business. This transmits the complete domain-specific data packet, including intent parameters and degradation flags, to the first business adapter. The first business adapter incorporates the pixel headlight business's proprietary parameter specifications, including at least the headlight projection canvas size, line drawing constraints, and color format requirements. It can perform business-dimensional parameter verification and format conversion on general domain-specific commands, ensuring that the subsequently generated materials are fully compatible with the pixel headlight's hardware projection capabilities. This solves the technical problem that general voice commands cannot directly match the hardware specifications of vertical businesses.

[0154] If the candidate business domain is the second business domain, then the second business adapter corresponding to the second business domain is invoked.

[0155] The second business area is wallpaper services for in-vehicle screen display scenarios.

[0156] Both the first business adapter and the second business adapter are local components used to process requests in their respective business domains.

[0157] In one possible implementation, when the business domain is determined to be the wallpaper business (i.e., the second business domain) in the corresponding vehicle-side screen display scenario, the vehicle-side voice daemon module uses the AIDL cross-process communication mechanism to call the second business adapter (such as the wallpaper store voice adapter) that is bound one-to-one with the wallpaper business, and transmits complete domain parameters, including degradation flags. This second business adapter has built-in dedicated parameter specifications for the wallpaper business, including at least: vehicle-side screen resolution, wallpaper quality level, display ratio constraints, and other business rules. It can adapt to the interface protocol of the wallpaper store application, completing the conversion from general domain parameters to standard raw image requests for the wallpaper business.

[0158] The voice interaction processing method provided in this application obtains the business domain identifier corresponding to the candidate business domain, so as to convert the textual candidate domain result into a standardized code for unified recognition across the entire end-to-end cloud link, effectively dispelling the ambiguity of natural language expression and providing a consistent judgment basis for subsequent business scheduling; then, based on the business domain identifier, it calls the local business adapter that matches the candidate business domain; wherein, the business adapter is a local component used to process requests for the corresponding business domain, and different business domain identifiers have corresponding business adapters preset, so as to achieve accurate routing through the pre-configured identifier-adapter mapping relationship, which can not only achieve module decoupling between semantic processing and business adaptation, but also ensure that business requests are quickly distributed to the corresponding adaptation components, improving the link execution efficiency and business matching accuracy.

[0159] Optionally, after forwarding the parsed candidate recognition result to the candidate application corresponding to the candidate recognition result in the above method, it further includes: Receive the execution results returned by the candidate application.

[0160] In one possible implementation, since the candidate applications are downstream business applications bound one-to-one with the current candidate business domain, after completing operations such as loading materials, projecting lights, or setting wallpapers, the downstream candidate applications report execution result data packets to the voice assistant module through the system's cross-process communication mechanism (such as AIDL callback interfaces). These execution result data packets adopt a preset structured format and include at least: execution status enumeration values ​​(such as success / failure), unique identifiers of material resources, material usage records, and optional error codes and exception information fields. The voice assistant module receives the execution result data packet through a pre-registered result listening interface, performs format verification and field parsing, and then stores it in a local temporary cache.

[0161] If the candidate business area is the second business area, a downgrade prompt message will be generated.

[0162] The downgrade notification message is used to inform users that the current service being performed is now in a downgraded state.

[0163] In one possible implementation, the first business domain is the original target business pointed to by the user's original voice command (such as a pixel headlight image), and the second business domain is the alternative business switched through a business degradation mechanism when the target hardware or application is determined not to be installed during the cloud arbitration stage (such as a wallpaper image). Therefore, the voice assistant module reads the final domain result cached locally, extracts the degradation marker field, and triggers the generation of degradation prompt information when the degradation marker field indicates a degradation state and the current candidate business domain matches the preset second business domain enumeration value. This generation method involves calling a locally preset degradation text template, substituting the original business name, the downgraded business name, and the reason for degradation, and outputting structured bimodal prompt data: one side is plain text speech generated via text-to-speech (TTS), and the other side is styled prompt text displayed on the vehicle interface, for example, "Pixel headlight hardware not installed, same theme wallpaper automatically generated."

[0164] Output the downgrade prompt message and the execution results returned by the candidate application.

[0165] In one possible implementation, the voice assistant module encapsulates the downgrade prompt information and the execution results returned by the candidate application into a unified standardized feedback data packet. This standardized feedback data packet is sent back to the corresponding business's voice adapter module. After completing the protocol conversion and field encapsulation, the adapter module reports to the voice daemon module through AIDL cross-process communication. The voice daemon module, as the overall entry point for vehicle-side voice communication, coordinates the output. On the one hand, it calls the vehicle-side voice synthesis engine to play the prompt voice, and on the other hand, it sends the interface display command to the corresponding business application, popping up the downgrade prompt text and execution status indicator in the application interface, realizing dual-modal feedback of voice and vision.

[0166] It should be noted that the voice daemon module can also synchronize the complete interaction record, including dialogue ID, business domain, degradation flag, and execution result, to the cloud voice semantic module through the vehicle-cloud uplink channel to update the cloud dialogue context memory; at the same time, it can push the latest execution record to the vehicle-side AI subsystem module to refresh the local multi-turn dialogue cache, providing accurate contextual basis for subsequent multi-turn voice iteration and modification interactions.

[0167] The voice interaction processing method provided in this application receives the execution results returned by candidate applications; if the candidate business domain is the second business domain, a downgrade prompt message is generated to proactively inform the user of the reason for the business downgrade and the actual type of business executed, eliminating the user's expectation deviation; finally, the downgrade prompt message and the execution results returned by the candidate applications are output to complete the user-side feedback in a dual-modal form of voice broadcast and interface display. At the same time, it is transmitted back layer by layer along the Adapter module and Daemon module and synchronized to the cloud voice semantic module and the vehicle AI subsystem module to achieve data closure and context consistency, providing an accurate semantic basis for subsequent multi-round voice interaction.

[0168] Based on the same inventive concept, this application also provides a voice interaction processing device. Since the principle of the device in this application to solve the problem is similar to the voice interaction processing method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0169] Figure 8 A schematic diagram of the structure of a voice interaction processing device provided in an embodiment of this application. Figure 1 .like Figure 8 As shown, the voice interaction processing device 800, applied in the cloud, includes: The determination module 801 is used to respond to a user's voice request and determine the target application corresponding to the user's voice request based on the semantic recognition result of the user's voice request. The replacement module 802 is used to replace the semantic recognition result with the candidate recognition result if it is determined that the target application is not installed in the corresponding vehicle terminal. The candidate recognition result is the result that is related to the semantic recognition result and the corresponding candidate application has been installed in the vehicle terminal. The distribution module 803 is used to distribute the candidate recognition results to the vehicle terminal, so that the vehicle terminal can forward the candidate recognition results to the candidate application corresponding to the candidate recognition results.

[0170] In one optional implementation, the determining module 801 is specifically used to: read the business domain corresponding to the user's voice request from the semantic recognition result of the user's voice request, wherein the business domain is a field used to distinguish different businesses; and determine the target application corresponding to the business domain based on the preset mapping relationship between the business domain and the application.

[0171] In an optional implementation, the semantic recognition result further includes: user intent and intent parameters, wherein the user intent is the specific operation of the user's voice request in the business domain; the intent parameters are the specific execution conditions corresponding to the user intent; and the replacement module 802 is specifically used to: determine candidate business domains based on the business domain, wherein the candidate business domains are business domains that are related to the business domain and whose corresponding candidate applications have been installed; determine candidate intent parameters based on the user intent and intent parameters, wherein the candidate intent parameters are the specific execution conditions corresponding to the user intent in the candidate business domain; and generate candidate recognition results based on the user intent, candidate business domains, and candidate intent parameters to replace the semantic recognition result.

[0172] In one optional implementation, the replacement module 802 is specifically used to: if the user intent is a multi-round modification instruction, compare the intent parameters with the historical intent parameters, update the user's modified items and retain the unmodified items to obtain candidate intent parameters. The multi-round modification instruction is the user's adjustment instruction for the previous voice request in the current dialogue round; the historical intent parameters are read from the history of the current dialogue round; if the user intent is not a multi-round modification instruction, use the intent parameters as candidate intent parameters.

[0173] In one optional implementation, the replacement module 802 is specifically used for: reading the installation status of the target application in the corresponding vehicle terminal from the cloud cache; if the installation status of the target application in the corresponding vehicle terminal is not found in the cloud cache, or the installation status has expired, then sending a status query instruction to the vehicle terminal, the status query instruction carrying the identifier of the target application; and receiving the installation status of the target application returned by the vehicle terminal based on the status query instruction.

[0174] In an optional implementation, the delivery module 803 is further configured to: receive a standard intent request sent by the vehicle-side voice assistant, the standard intent request being generated based on the candidate recognition results; based on the candidate business domain and candidate intent parameters in the candidate recognition results, call the business material generated by the vehicle-side voice assistant, the business material being rendering data adapted to the hardware device corresponding to the candidate business domain; the second business domain being the wallpaper business in the vehicle-side screen display scenario; and deliver the business material to the vehicle-side voice assistant.

[0175] Figure 9 A schematic diagram of the structure of a voice interaction processing device provided in an embodiment of this application. Figure 2 .like Figure 9 As shown, the voice interaction processing device 900, applied to the vehicle end, includes: The receiving module 901 is used to receive the candidate recognition results sent from the cloud. The candidate recognition results are obtained by replacing the semantic recognition results when the cloud detects that the target application is not installed on the vehicle. The candidate recognition results are related to the semantic recognition results and the corresponding candidate applications have been installed on the vehicle. The parsing module 902 is used to parse the candidate recognition results so as to forward the parsed candidate recognition results to the candidate applications corresponding to the candidate recognition results.

[0176] In one optional implementation, the parsing module 902 is specifically used to: parse the candidate recognition results to determine the corresponding candidate business domain and candidate intent parameters; match the corresponding business adapter based on the candidate business domain, so as to convert the candidate intent parameters into a standard intent request executed by the vehicle through the business adapter; wherein, the parsed candidate recognition results include: standard intent requests.

[0177] In one optional implementation, the parsing module 902 is specifically used to: obtain the business domain identifier corresponding to the candidate business domain; and, based on the business domain identifier, call the local business adapter that matches the candidate business domain; wherein, the business adapter is a local component used to process requests for the corresponding business domain, and different business domain identifiers have pre-set corresponding business adapters.

[0178] In an optional implementation, the parsing module 902 is further configured to: receive the execution result returned by the candidate application; if the candidate business domain is the second business domain, generate a downgrade prompt message, which is used to inform the user that the current execution is a downgraded business; and output the downgrade prompt message and the execution result returned by the candidate application.

[0179] It should be noted that for details not disclosed in the voice interaction processing device of this application embodiment, please refer to the details disclosed in the voice interaction processing method of this application embodiment, which will not be repeated here.

[0180] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0181] Optionally, embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is run by a processor, the processor executes the steps of the voice interaction processing method for the computer-readable storage medium described in the above embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0182] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The integrated unit described above can be implemented in hardware or in the form of hardware plus software functional units.

[0183] Optionally, this embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a voice interaction processing method provided in the above embodiment.

[0184] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0185] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0186] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and other division methods may exist in actual implementation. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

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

Claims

1. A voice interaction processing method, characterized in that, Applied to the cloud, the method includes: In response to a user's voice request, the target application corresponding to the user's voice request is determined based on the semantic recognition result of the user's voice request; If it is determined that the target application is not installed in the corresponding vehicle, the semantic recognition result is replaced with a candidate recognition result, which is a result that is related to the semantic recognition result and whose corresponding candidate application has been installed in the vehicle. The candidate recognition results are sent to the vehicle terminal, so that the vehicle terminal can forward the candidate recognition results to the candidate application corresponding to the candidate recognition results.

2. The method according to claim 1, characterized in that, The step of determining the target application corresponding to the user's voice request based on the semantic recognition result includes: The business domain corresponding to the user's voice request is read from the semantic recognition result of the user's voice request. The business domain is a field used to distinguish different businesses. Based on the pre-defined mapping relationship between business domains and applications, the target application corresponding to the business domain is determined.

3. The method according to claim 2, characterized in that, The semantic recognition result also includes: user intent and intent parameters, wherein the user intent is the specific operation of the user's voice request in the business domain; and the intent parameters are the specific execution conditions corresponding to the user intent. The step of replacing the semantic recognition result with the candidate recognition result includes: Based on the business domain, candidate business domains are determined. The candidate business domains are those that are associated with the business domain and for which the corresponding candidate applications have been installed. Based on the user intent and the intent parameters, candidate intent parameters are determined, wherein the candidate intent parameters are the specific execution conditions corresponding to the user intent in the candidate business domain; Based on the user intent, the candidate business domain, and the candidate intent parameters, the candidate recognition result is generated to replace the semantic recognition result.

4. The method according to claim 3, characterized in that, The step of determining candidate intent parameters based on the user intent and the intent parameters includes: If the user intent is a multi-round modification instruction, then the intent parameters are compared with the historical intent parameters, the user's modified items are updated and the unmodified items are retained to obtain candidate intent parameters. The multi-round modification instruction is the user's adjustment instruction to the previous voice request in the current dialogue round; the historical intent parameters are read from the history of the current dialogue round. If the user intent is not a multi-round modification instruction, then the intent parameter is used as the candidate intent parameter.

5. The method according to claim 1, characterized in that, Determining the installation status of the target application in the corresponding vehicle includes: Read the installation status of the target application in the corresponding vehicle from the cloud cache; If the target application does not exist in the cloud cache in the corresponding vehicle terminal, or the installation status has expired, a status query instruction is sent to the vehicle terminal, and the status query instruction carries the identifier of the target application. Receive the installation status of the target application returned by the vehicle terminal based on the status query command.

6. The method according to claim 1, characterized in that, After sending the candidate recognition results to the vehicle, the process also includes: Receive a standard intent request sent by the vehicle-side voice assistant, the standard intent request being generated based on the candidate recognition results; Based on the candidate business domain and candidate intent parameters in the candidate recognition results, the business material generated by the vehicle-side voice assistant is invoked. The business material is rendering data adapted to the hardware device corresponding to the candidate business domain. The business materials are sent to the vehicle-side voice assistant.

7. A voice interaction processing method, characterized in that, Applied to the vehicle end, the method includes: The system receives candidate recognition results from the cloud, which are obtained by replacing the semantic recognition results when the cloud detects that the target application is not installed on the vehicle. The candidate recognition results are related to the semantic recognition results and the corresponding candidate applications are already installed on the vehicle. The candidate identification results are parsed so that the parsed candidate identification results are forwarded to the candidate application corresponding to the candidate identification results.

8. The method according to claim 7, characterized in that, The parsing of the candidate identification results includes: The candidate identification results are parsed to determine the corresponding candidate business domains and candidate intent parameters; Based on the candidate business domain, a corresponding business adapter is matched, and the candidate intent parameters are converted into a standard intent request to be executed by the vehicle through the business adapter; The parsed candidate identification results include: the standard intent request.

9. The method according to claim 8, characterized in that, The service adapter matched based on the candidate service domain includes: Obtain the business domain identifier corresponding to the candidate business domain; Based on the business domain identifier, invoke the local business adapter that matches the candidate business domain; The service adapter is a local component used to process requests for the corresponding business domain. Different business domain identifiers have corresponding service adapters.

10. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform the method as described in any one of claims 1 to 9.

Images