Hierarchical calling method for cabin service and electronic device

Abstract

The application provides a cockpit service hierarchical calling method and an electronic device, and relates to the technical field of intelligent cockpits. The method is executed by a target intermediate service unit, which is determined by an intelligent agent based on a service calling request from a plurality of candidate intermediate service units. The method comprises the following steps: in response to the service calling request sent by the intelligent agent, based on the service calling request, screening out a target function execution unit from at least one managed function execution unit; sending the service calling request to the target function execution unit, so that the target function execution unit executes the business logic corresponding to the service calling request; obtaining the execution result returned by the target function execution unit, and returning the execution result to the intelligent agent. Thus, the application is used to solve the problems of the existing flat calling architecture, such as the error-prone semantic recognition of the AI intelligent agent, the need to traverse all function execution units, the low calling accuracy, the long interaction link, the large calculation overhead, and the slow response speed.

Description

Technical Field

[0001] This application relates to the field of smart cockpit technology, and more specifically, to a method for hierarchical invocation of cockpit services and an electronic device. Background Technology

[0002] In the development of intelligent cockpits, the number of integrated functional services within the cockpit has grown exponentially.

[0003] Currently, the mainstream architecture of existing smart cockpits adopts a flat service call mode. The AI ​​Agent directly connects to all MCP Server (Media Control Protocol Server / Micro Control Platform Server) function execution units. It completes semantic recognition by reading the custom title and description information of each function execution unit, and directly calls the target function execution unit based on the recognition results, thereby realizing the matching and execution of user commands and cockpit services.

[0004] However, under the existing flat calling architecture, AI Agent is prone to semantic recognition errors when faced with a large number of similar functional services, and it needs to traverse all functional execution units to complete the filtering, resulting in low service call accuracy, long interaction links, large computational overhead, slow response speed, and inability to achieve efficient service scheduling. Summary of the Invention

[0005] The application provides a layered invocation method and electronic device for cockpit services. This method is used to solve the problems of easy error in semantic recognition of AI intelligent agents, the need to traverse all functional execution units, low invocation accuracy, long interaction links, large computational overhead, and slow response speed under the existing flat invocation architecture.

[0006] Firstly, a layered invocation method for cockpit services is provided, executed by a target intermediate service unit. The target intermediate service unit is determined by the agent from multiple candidate intermediate service units based on a service invocation request. The method includes: responding to a service invocation request sent by the agent; selecting a target functional execution unit from at least one managed functional execution unit based on the service invocation request; sending the service invocation request to the target functional execution unit so that the target functional execution unit executes the business logic corresponding to the service invocation request; obtaining the execution result returned by the target functional execution unit and returning the execution result to the agent.

[0007] In the above technical solution, the target intermediate service unit performs aggregated management of functional execution units in the same domain. Responding to service call requests sent by the agent, it filters the target functional execution unit from at least one functional execution unit under its management based on the service call request. This eliminates the need to traverse all functional execution units, effectively shortening the interaction chain and accelerating the response speed. Simultaneously, it avoids semantic recognition errors of similar functional services through domain-specific matching, improving service call accuracy. The service call request is then directed to the target functional execution unit, enabling it to execute the business logic corresponding to the request, ensuring service execution. Finally, the execution result returned by the target functional execution unit is obtained and sent back to the agent. This solves the technical shortcomings of existing flat call architectures, such as easy semantic recognition errors in AI agents, the need to traverse all functional execution units, low call accuracy, long interaction chains, high computational overhead, and slow response speed, achieving efficient scheduling of cabin services.

[0008] Secondly, a layered invocation method for cockpit services is provided, executed by an intelligent agent. The method includes: responding to a service invocation request, determining a target intermediate service unit from multiple candidate intermediate service units based on the service invocation request, wherein each candidate intermediate service unit manages at least one functional execution unit; sending the service invocation request to the target intermediate service unit, so that the target intermediate service unit, based on the service invocation request, selects a target functional execution unit from the functional execution units managed by the target intermediate service unit and sends the service invocation request to the target functional execution unit; receiving the execution result returned by the target intermediate service unit, wherein the execution result is generated by the target functional execution unit after executing the business logic corresponding to the service invocation request, and returned by the target intermediate service unit.

[0009] In the above technical solution, in response to a service call request, the agent performs semantic matching based on the service call request and the functional description information of each candidate intermediate service unit, and determines the target intermediate service unit from multiple candidate intermediate service units. Each candidate intermediate service unit aggregates and manages at least one functional execution unit according to its functional domain, which can effectively reduce the semantic recognition error of the agent when facing a large number of similar services, and reduce the number of interaction objects and computational overhead. The agent sends the service call request to the target intermediate service unit, so that the target intermediate service unit performs a secondary screening in its managed functional execution units based on the service call request to determine the target functional execution unit, and sends the service call request to the target functional execution unit, further improving the accuracy and response efficiency of the service call. Subsequently, the agent receives the execution result returned by the target intermediate service unit. This execution result is generated by the target functional execution unit after executing the business logic corresponding to the service call request, and is fed back to the agent through the target intermediate service unit along the original communication link, thus forming a complete service call closed loop, ensuring the efficiency, stability and accuracy of the cockpit service call.

[0010] Thirdly, a layered invocation device for cockpit services is provided, executed by a target intermediate service unit. The target intermediate service unit is determined by the agent from multiple candidate intermediate service units based on a service invocation request. The device includes: a filtering module, used to filter out a target functional execution unit from at least one managed functional execution unit based on the service invocation request in response to a service invocation request sent by the agent; a first sending module, used to send the service invocation request to the target functional execution unit so that the target functional execution unit executes the business logic corresponding to the service invocation request; and an acquisition module, used to acquire the execution result returned by the target functional execution unit and return the execution result to the agent.

[0011] Fourthly, a layered invocation device for cockpit services is provided, executed by an intelligent agent. This device includes: a determination module, used to determine a target intermediate service unit from multiple candidate intermediate service units based on a service invocation request, wherein each candidate intermediate service unit manages at least one functional execution unit; a second sending module, used to send the service invocation request to the target intermediate service unit, so that the target intermediate service unit, based on the service invocation request, selects a target functional execution unit from the functional execution units managed by the target intermediate service unit and sends the service invocation request to the target functional execution unit; and a receiving module, used to receive the execution result returned by the target intermediate service unit, the execution result being generated by the target functional execution unit after executing the business logic corresponding to the service invocation request, and returned by the target intermediate service unit.

[0012] Fifthly, 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 method corresponding to the first aspect or any possible implementation thereof.

[0013] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of this application more easily understood, specific embodiments of this application are given below. Attached Figure Description

[0014] 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 1This is a schematic diagram of a layered calling system for cabin services 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 layered invocation method for cabin services provided in this application embodiment. Figure 1 ; Figure 4 A flowchart illustrating a layered invocation method for cabin services provided in this application embodiment. Figure 2 ; Figure 5 A flowchart illustrating a layered invocation method for cabin services provided in this application embodiment. Figure 3 ; Figure 6 A flowchart illustrating a layered invocation method for cabin services provided in this application embodiment. Figure 4 ; Figure 7 A schematic diagram of the structure of a layered dispatching device for cabin services provided in this application embodiment. Figure 1 ; Figure 8 A schematic diagram of the structure of a layered dispatching device for cabin services provided in this application embodiment. Figure 2 . Detailed Implementation

[0015] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of 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, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

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

[0017] With the development of intelligent cockpit technology, the number of in-cockpit functional services is rapidly increasing, with diverse service types and significant functional similarities. Existing cockpits employ a flat service invocation architecture, where the AI ​​agent directly connects to all MCP service function execution units, relying solely on the custom titles and descriptions provided by each MCP service function execution unit to complete semantic recognition and service invocation. In this model, the AI ​​agent is highly susceptible to semantic recognition errors when faced with a massive number of similar functional services. Furthermore, each service invocation requires traversing all MCP service function execution units for filtering, resulting in low service invocation accuracy, long interaction chains, high computational overhead, and slow system response, hindering efficient service scheduling. Therefore, this application proposes a layered cockpit service invocation scheme based on AI agents to address the aforementioned shortcomings of existing technologies.

[0018] The following detailed description, in conjunction with the accompanying drawings, of the layered invocation method and electronic device for cockpit services according to embodiments of this application through multiple examples.

[0019] Figure 1 This is a schematic diagram of a hierarchical calling system for cabin services provided in an embodiment of this application. Figure 1 As shown, the layered invocation system 100 for the cockpit service includes at least: an intelligent agent 110, multiple intermediate service units 120, and multiple function execution units 130.

[0020] After the system powers on and completes initialization, the agent 110 establishes long-lived or request-response communication connections with multiple intermediate service units 120 via HTTP, JSON, or RPC 2.0 communication protocols. Each intermediate service unit 120, as a first-level logical classification unit, establishes a one-to-one binding communication connection with multiple functional execution units 130 via AIDL (Android Interface Definition Language), forming a two-layer communication architecture from the agent to the intermediate service unit and then to the functional execution unit. The intermediate service unit 120 is the first-level layer; the functional execution unit is the MCP Server.

[0021] Upon receiving a service call request from a user, the intelligent agent 110 reads the structured information of each intermediate service unit 120, such as its hierarchical name and functional description, from its local cache. Leveraging the semantic understanding capabilities of a pre-set AI model, it semantically matches the service call request with the functional descriptions of each intermediate service unit 120, thereby identifying the target intermediate service unit 120 from among the multiple intermediate service units 120. The agent then sends the service call request to the target intermediate service unit 120 via a pre-set communication protocol. Upon receiving the service call request, the target intermediate service unit 120, based on four rules—functional matching, call parameter matching, semantic similarity matching, and state availability matching—and a four-level filtering strategy—service priority, functional execution unit load priority, functional execution unit response speed priority, and functional execution unit registration order priority—selects a unique target functional execution unit 130 from among the multiple functional execution units 130 it manages, and forwards the service call request to that target functional execution unit 130.

[0022] After receiving the request, the target function execution unit 130 calls the corresponding underlying cockpit service capability process via the AIDL protocol to execute the business logic matching the request. After execution, it returns the business execution result to the target intermediate service unit 120 along the original path. Upon receiving the execution result, the target intermediate service unit 120 transmits the result back to the intelligent agent 110 via the established communication link, completing the full call and feedback process. During system initialization, the intermediate service unit 120 automatically categorizes and aggregates function execution units 130 within the same functional domain based on the domain tags configured during registration. It also aggregates and generates its own functional description information, which is synchronized to the local cache of the intelligent agent 110, providing data support for semantic matching and target intermediate service unit determination by the intelligent agent 110.

[0023] It should be noted that each functional execution unit is uniquely bound to only one cockpit service capability process, and each cockpit service capability process is also encapsulated and proxied by only one functional execution unit, achieving a one-to-one correspondence between service processes and functional execution units. During its own startup initialization and system registration phases, each functional execution unit must pre-configure fixed basic information, specifically including: a node name, using concise text as an identifier, such as music playback service or air conditioning temperature control service; a function description, using natural language to describe the business capabilities that the node can achieve, providing a basis for the agent's semantic understanding and matching; a call parameter description, clearly defining the input and output parameters supported by the service interface, such as the temperature value and operating mode required for air conditioning adjustment; and a domain label, pre-defining the functional business domain to which the node belongs, facilitating the system's automatic aggregation to the corresponding intermediate service unit according to domain category. All the above information configured by each functional execution unit will be uniformly summarized and integrated by its respective intermediate service unit, thus forming the overall service capability description information of that intermediate service unit.

[0024] In addition, it should be noted that each intermediate service unit is pre-configured with fixed structured information during the initialization and definition phase, specifically including four items: First, a hierarchical name, which serves as a classification identifier for quick identification and differentiation of corresponding functional domains, such as standardized names like multimedia entertainment services; second, a hierarchical functional description, using natural language to summarize the overall service capabilities of all media control server nodes under this intermediate service unit; third, a list of subordinate media control servers, used to record information on all specific media control server nodes under the jurisdiction of the current intermediate service unit; and fourth, a summary of subordinate media control server functions, which uniformly summarizes and integrates the business functional capabilities of all sub-service nodes within its jurisdiction, providing standardized semantic data support for the intelligent agent to conduct subsequent semantic matching and domain intent recognition.

[0025] The cockpit service hierarchical invocation system provided in this application adopts a three-tiered hierarchical architecture, consisting of at least an intelligent agent, multiple intermediate service units, and multiple functional execution units. The intelligent agent establishes communication connections with multiple intermediate service units, and each intermediate service unit communicates with its managed multiple functional execution units. This hierarchical and decoupled architecture overcomes the technical drawbacks of traditional cockpit service centralized invocation, high module coupling, and chaotic invocation logic. The specific invocation process and hierarchical control logic are as follows: The intelligent agent, as the top-level request scheduling core, is responsible for receiving service invocation requests initiated externally. The intelligent agent pre-stores the functional description information corresponding to all intermediate service units, enabling semantic matching of service invocation requests with the functional description information of each intermediate service unit. Based on this, it selects the target intermediate service unit suitable for the current request from among many intermediate service units and sends the service invocation request to the corresponding target intermediate service unit. This semantic intelligent matching mechanism effectively improves the accuracy of service classification and top-level scheduling, avoiding service mismatch and ineffective scheduling. The intermediate service units, as mid-level relay and fine-tuning functional execution units, pre-classify and manage each functional execution unit in a modular manner based on its domain tags, achieving aggregation of similar functions. The refined management of heterogeneous functions allows for rapid selection of target functional execution units (DMUs) from among multiple managed functional execution units based on the business attributes of the request after receiving a service call request from the agent. This narrows the scope of function retrieval and improves the efficiency of mid-level request distribution. The target DMU, ​​acting as the underlying business execution carrier, executes the cockpit business logic corresponding to the service call request upon receiving the forwarded service call request from the target intermediate service unit and returns the final business execution result to the target intermediate service unit. The target intermediate service unit, upon receiving the execution result from the underlying layer, summarizes and organizes the data and returns it layer by layer to the agent, forming a fully closed-loop layered call mechanism from top-level scheduling to mid-level selection to bottom-level execution and then to layer-by-layer return. Therefore, this layered call system, through agent semantic matching scheduling, domain-based classification management of intermediate service units, and a layered collaborative model of dedicated business execution for functional execution units, reduces the coupling between various service modules in the cockpit, standardizes the service call process, and improves the cockpit service response speed, call accuracy, and system scalability.

[0026] 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.

[0027] The memory 220 stores machine-executable instructions that can be executed by the processor 210. When the electronic device 200 is running, these machine-readable 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 hierarchical invocation method for cockpit services.

[0028] 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 processor 210 includes at least one software functional module, which is stored or embedded in the operating system (OS) of the electronic device as software or firmware. This software functional module includes 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 layered invocation method for cockpit services.

[0029] 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.

[0030] The electronic device 200 can be selected according to the actual situation. For example, the electronic device 200 can be selected as an in-vehicle controller or computer equipment. Furthermore, the electronic device 200 has software capable of executing a hierarchical invocation method for cockpit services or a hierarchical invocation system for cockpit services, which can execute the hierarchical invocation method for cockpit services.

[0031] The layered invocation method for cockpit services provided in this application embodiment can be scheduled and controlled by the processor of an electronic device. The business processing steps at the corresponding layer in the method are specifically executed by the target intermediate service unit, such as... Figure 3 As shown, the hierarchical invocation method for cockpit services provided in the embodiments of this application will be further explained. Figure 3 A flowchart illustrating a layered invocation method for cabin services provided in this application embodiment. Figure 1The method may include: S310. In response to a service call request sent by the agent, select the target functional execution unit from at least one managed functional execution unit based on the service call request.

[0032] Among them, the service call request is a command message generated by the intelligent agent after receiving user interaction instructions and understanding their semantics. It carries information such as functional requirements, call parameters, and semantic instructions and is used to request the intermediate service unit to call the corresponding cockpit service.

[0033] In one possible implementation, the service call request sent by the agent only completes the initial matching of the business domain and does not directly specify which underlying functional execution unit will provide the service. As the unified manager of all functional execution units in the same domain, the intermediate service unit needs to perform secondary matching and selection among all available functional execution units under its jurisdiction based on the key information such as functional requirements, call parameters, semantic instructions, and status requirements carried in the service call request. This will locate the unique target functional execution unit that can correctly, stably, and efficiently respond to the user's needs, avoid service call errors caused by functional similarity, and ensure the reliability and timeliness of service execution. Based on this, the intermediate service unit first receives service call requests from the agent via the HTTP and JSON or RPC 2.0 communication links established with the agent during system initialization, using long connections or request-response methods. It then breaks down and parses the service call request messages to extract key information such as functional requirements, call parameters, and semantic instructions. Next, the intermediate service unit filters out candidate functional execution units that can meet the request from all functional execution units under its jurisdiction, categorized by domain tags, based on four criteria: functional matching, call parameter matching, semantic similarity matching, and state availability matching. If there is more than one candidate functional execution unit, it selects the single most suitable target functional execution unit according to a four-level rule: service priority, functional execution unit load priority, response speed priority, and registration order priority. The filtering process automatically skips temporarily unavailable, abnormally isolated, or expired functional execution units. All filtering rules are executed according to the preset parameters in the local configuration file, ultimately locking in the target functional execution unit capable of executing the service.

[0034] S320. Send the service call request to the target function execution unit so that the target function execution unit executes the business logic corresponding to the service call request.

[0035] In one possible implementation, the intermediate service unit acts only as a routing and management unit for domain services, possessing only the capabilities of service classification, request forwarding, and function execution unit filtering. It does not carry specific business logic itself, nor does it directly connect to the underlying cockpit service process. In contrast, the target function execution unit is the only function execution unit that is one-to-one bound to the underlying cockpit service capability process. Only this function execution unit can establish communication with the underlying service process and drive business execution through AIDL. Therefore, service call requests must be directed to the target function execution unit in order for it to trigger the underlying service process to run the business logic corresponding to the user's needs, ultimately completing the actual call and function implementation of the cockpit service. Based on this, after the intermediate service unit completes the selection of the target function execution unit, it sends the service call request, which has completed parameter encapsulation and instruction verification, to the target function execution unit through the internal communication link established during the system initialization phase. This target function execution unit is a function execution unit bound one-to-one with the underlying cockpit service process. Upon receiving the service call request, it establishes a communication connection with its uniquely bound cockpit service capability process via the AIDL protocol. Based on the functional requirements and call parameters in the service call request, it drives the underlying cockpit service process to start and run the business logic corresponding to the request, thereby completing the cockpit service execution operation required by the user instruction. The underlying cockpit service process includes all service capability processes within the cockpit (such as music, air conditioning, navigation, etc.) and provides the specific business logic implementation.

[0036] S330. Obtain the execution result returned by the target function execution unit and return the execution result to the intelligent agent.

[0037] In one possible implementation, the target function execution unit is only responsible for communicating with the underlying cockpit service process and executing business logic. It can only send the execution results back to the intermediate service unit that manages it and cannot directly establish a communication link with the agent. As the user-facing cockpit service interaction entry point, the agent needs to provide feedback on the service execution status and results to the user. Therefore, the intermediate service unit must first obtain the execution results returned by the target function execution unit and then send the results back to the agent. This forms a closed loop of call from request to filtering to execution to result feedback, ensuring that the agent can promptly synchronize the execution status of the cockpit service to the user and guaranteeing the integrity and interactive closed loop of the entire service call process. Based on this, the intermediate service unit receives the service execution results returned by the target function execution unit via the AIDL protocol after completing the execution of the underlying cockpit service business logic through a stable communication link established with the target function execution unit, thus obtaining the execution results. After obtaining the execution results, the intermediate service unit performs standardized encapsulation processing on the execution results, and then returns the encapsulated execution results to the intelligent agent along the original communication path through the HTTP and JSON or RPC 2.0 communication links established with the intelligent agent during the system initialization phase, according to the long connection or request-response communication mode, thus completing the execution result return process.

[0038] The layered invocation method for cockpit services provided in this application is executed by a target intermediate service unit. This intermediate service unit aggregates and manages functional execution units within the same domain. In response to service invocation requests sent by the agent, it filters for target functional execution units from at least one functional execution unit under its management based on the service invocation request. This eliminates the need to traverse all functional execution units, effectively shortening the interaction chain and accelerating response speed. Simultaneously, it avoids semantic recognition errors in similar functional services through domain-specific matching, improving service invocation accuracy. The service invocation request is then directed to the target functional execution unit, enabling it to execute the business logic corresponding to the request, ensuring service execution. Finally, the execution result returned by the target functional execution unit is obtained and sent back to the agent. This addresses the technical shortcomings of existing flat invocation architectures, such as error-prone semantic recognition by AI agents, the need to traverse all functional execution units, low invocation accuracy, long interaction chains, high computational overhead, and slow response speed, thus achieving efficient scheduling of cockpit services.

[0039] Figure 4 A flowchart illustrating a layered invocation method for cabin services provided in this application embodiment. Figure 2 .like Figure 4 As shown, the above method, based on the service call request, filters out the target functional execution unit from at least one managed functional execution unit, including: S410. Determine the functional matching degree based on the semantic relevance between the service call request and the preset functional information of each functional execution unit.

[0040] The preset functional information for each functional execution unit refers to the fixed structured information configured during the system registration phase, such as the preset functional execution unit name (Title), preset functional description (Description), and domain tag. This fixed structured information is used to uniquely identify the service capabilities that the functional execution unit can provide.

[0041] In one possible implementation, after receiving a service call request from the intelligent agent, the intermediate service unit first parses the request message to extract the semantic instruction information corresponding to the user's needs. This semantic instruction information includes at least the functional intent of the service call, such as natural language functional requests like "play a song," "adjust the air conditioner temperature," or "start navigation." Subsequently, the intermediate service unit retrieves the preset functional information of all functional execution units under its jurisdiction from local configuration files and local caches, based on the information acquired during the system registration phase. The intermediate service unit then synchronously inputs the extracted semantic instruction information and the preset functional information of each functional execution unit into a preset AI model. Relying on the preset AI model's own natural language understanding, semantic feature extraction, and semantic similarity calculation capabilities, the model performs semantic feature alignment and relevance calculation between the semantic instruction information and the preset functional information of each functional execution unit. The semantic relevance calculation process does not use a fixed algorithm or rules pre-set by humans. Instead, a pre-set AI model autonomously learns, understands, and matches the input natural language description information, ultimately outputting a semantic relevance value. The intermediate service unit uses this semantic relevance value to determine the functional matching degree between each functional execution unit and the current service call request. The higher the semantic relevance value, the higher the functional matching degree. The pre-set AI model can be selected according to the actual situation.

[0042] S420. Determine the matching degree of the calling parameters based on the matching degree between the request parameters in the service call request and the calling parameters corresponding to each functional execution unit.

[0043] In one possible implementation, after parsing the service call request message, the intermediate service unit extracts the specific request parameters carried by the user instruction from the parsed service call request data. These request parameters are the actual execution data required to implement the service call, such as the temperature value and operating mode for air conditioning adjustment, the playback content and artist name for multimedia playback, and the destination and route preferences for navigation. Subsequently, the intermediate service unit retrieves the call parameter description information pre-configured during the system startup registration phase for each functional execution unit under its jurisdiction from the system's local configuration file and the functional execution unit registration cache. This call parameter description information is the parameter definition, which is fixedly configured during the functional execution unit registration, including the input parameter type, output parameter type, parameter value range, required parameter items, and parameter format specifications. It is the sole basis for determining whether the request parameters are suitable. Next, the intermediate service unit checks the extracted request parameters against the preset call parameters of each functional execution unit. It verifies whether the request parameter type matches the preset input parameter type of the functional execution unit, whether the request parameter value is within the preset value range of the functional execution unit, whether all required parameters for the service call are included, and whether the parameter data format meets the requirements of the functional execution unit. Finally, based on the overall consistency of the above checks, the intermediate service unit determines the corresponding call parameter matching degree for each functional execution unit. Functional execution units with consistent parameter types, compliant values, and complete required fields have a higher call parameter matching degree and can proceed to the subsequent screening process first.

[0044] S430. Based on the functional execution unit status, functional matching degree, and call parameter matching degree, at least one managed functional execution unit is screened in sequence to determine the target functional execution unit.

[0045] The function execution unit status indicates whether the corresponding function execution unit is in an available state. Specifically, this status is a status identifier generated by the intermediate service unit based on the real-time operation of the function execution unit. This status identifier clearly marks whether the corresponding function execution unit is in a normally available, temporarily unavailable, abnormally isolated, or failed state, and serves as the basis for determining whether a function execution unit can participate in service calls during the screening process.

[0046] In one possible implementation, the intermediate service unit first reads the function execution unit status table maintained in real time by the system. This table records the real-time operating status of each function execution unit (e.g., normally available, temporarily unavailable, abnormally isolated, and failed). The intermediate service unit prioritizes removing function execution units marked as temporarily unavailable, abnormally isolated, or failed directly from the candidate list, retaining only those in a normally available state, forming the first round of available candidate pools. Then, based on the available candidate pool obtained in the first round of filtering, the intermediate service unit retrieves the function matching degree value of each function execution unit, which is calculated from semantic relevance. The intermediate service unit removes function execution units whose function matching degree does not reach a preset threshold, retaining only those that highly match the functional intent of the service call request, forming the second round of function matching candidate pools. Subsequently, based on the second round of function matching candidate pools, the intermediate service unit checks the call parameters of each function execution unit against the request parameters in the service call request, removing function execution units with mismatched request parameter types, missing request parameters, or request parameter values ​​outside the range, retaining only those with compatible call parameters, forming the final set of candidate function execution units. If there is only one functional execution unit in the final candidate functional execution unit set, it will be directly determined as the target functional execution unit; if there are multiple functional execution units that meet the conditions, the intermediate service unit will select the best one according to the four-level priority strategy of service functional execution unit priority > functional execution unit load priority > functional execution unit response speed priority > functional execution unit registration order priority, and finally determine the unique target functional execution unit that can execute the service call.

[0047] The layered invocation method for cockpit services provided in this application determines the function matching degree based on the semantic relevance between the service invocation request and the preset function information of each function execution unit. This can match function intent, reduce semantic recognition errors of similar functions, and improve the accuracy of function matching. At the same time, it determines the call parameter matching degree based on the degree of matching between the request parameters in the service invocation request and the call parameters corresponding to each function execution unit. This can ensure the adaptability of request parameters and avoid invocation failures due to mismatched request parameters. On this basis, the intermediate service unit sequentially filters at least one function execution unit under its management based on the function execution unit status, function matching degree, and call parameter matching degree to determine the target function execution unit. This can reduce the scope of invalid filtering, improve the positioning efficiency of function execution units, and realize service scheduling.

[0048] Optionally, the above method filters at least one managed functional execution unit based on the functional execution unit status, functional matching degree, and call parameter matching degree, including: Based on the functional execution unit status, a set of candidate functional execution units that are in an available state is selected from at least one managed functional execution unit.

[0049] In one possible implementation, the intermediate service unit first reads the real-time running status of all functional execution units under its jurisdiction. This real-time running status is the status information dynamically marked by the system during the functional execution unit registration, operation monitoring, and exception handling process, and is divided into four categories: normal availability, temporary unavailability, abnormal isolation, and failure. The intermediate service unit uses the status of the functional execution units as the filtering basis to perform the first round of filtering on all functional execution units under its jurisdiction, automatically removing functional execution units marked as temporary unavailability, abnormal isolation, or failure, and only retaining functional execution units with a normal availability status. These available functional execution units are then aggregated to form a candidate functional execution unit set. This filtering rule is stored in a local configuration file to ensure that all functional execution units in the candidate set have service execution capabilities.

[0050] In the candidate functional execution unit set, the functional matching degree of each functional execution unit is sorted to obtain the first matching unit set.

[0051] The first matching unit set consists of functional execution units whose functional matching degree meets the preset functional requirements. The preset functional requirements for each functional execution unit can be the same or different, and can be selected according to the actual situation.

[0052] In one possible implementation, the intermediate service unit retrieves the functional matching degree corresponding to each functional execution unit in the candidate functional execution unit set. The functional matching degree is calculated by the semantic relevance between the semantic instructions of the service call request and the preset functional information of the functional execution unit. The intermediate service unit sorts the candidate functional execution units in descending order according to the functional matching degree value, and then filters out the functional execution units whose functional matching degree reaches or exceeds the preset functional matching degree threshold (i.e., preset functional requirements) in the local configuration file. These functional execution units that meet the functional requirements are summarized to form a first matching unit set. Only the functional execution units in the first matching unit set can enter the subsequent parameter matching stage.

[0053] In the first set of matching units, the target functional execution unit is determined based on the matching degree of the calling parameters of each functional execution unit.

[0054] In one possible implementation, the intermediate service unit extracts the matching degree of the call parameters corresponding to each functional execution unit within the first matching unit set. This matching degree is determined by the degree of fit between the request parameters in the service call request and the preset call parameters of the functional execution unit. The intermediate service unit prioritizes selecting the functional execution unit with the highest matching degree. If there are multiple functional execution units with the same matching degree, the unit selects the best one according to a four-level priority strategy: service functional execution unit priority, functional execution unit load priority, functional execution unit response speed priority, and functional execution unit registration order priority. Finally, the unit that uniquely meets the service call requirements is determined. This selection logic is executed based on the system's preset configuration file to ensure the accuracy and stability of the target functional execution unit selection.

[0055] The layered invocation method for cockpit services provided in this application involves an intermediate service unit first selecting a set of candidate functional execution units that are in an available state from at least one functional execution unit under its management, based on the status of the functional execution units. Unavailable functional execution units are pre-emptively eliminated to reduce invalid matches and improve screening efficiency. Subsequently, within this set of candidate functional execution units, they are sorted according to the functional matching degree of each functional execution unit to obtain a first set of matching units whose functional matching degree meets the preset functional requirements. This initial screening by functional dimension narrows the target range and reduces the computational overhead of subsequent matching. Finally, within the first set of matching units, the target functional execution unit is determined based on the matching degree of the invocation parameters of each functional execution unit. By relying on the layered screening logic of status verification, functional matching, and parameter matching, the accuracy of locating the target functional execution unit is improved, ensuring the effectiveness and reliability of service invocation.

[0056] Optionally, determining the target function execution unit in the above method includes: If a single functional execution unit is obtained after filtering, then the single functional execution unit is determined as the target functional execution unit.

[0057] In one possible implementation, after the intermediate service unit completes the entire screening process of functional execution unit status verification, functional matching degree evaluation, and call parameter matching degree verification, if only one functional execution unit that meets all the screening conditions is selected, then there is no need to start the priority sorting logic. The only remaining functional execution unit that meets all service call requirements is directly and formally determined as the target functional execution unit corresponding to this service call, and serves as the only designated functional execution unit for receiving service call requests and triggering the execution of underlying business logic.

[0058] If multiple functional execution units are obtained after filtering, the target functional execution unit is determined from the multiple functional execution units based on the preset priority strategy.

[0059] In one possible implementation, after completing the entire filtering process, if the intermediate service unit selects two or more functional execution units that meet the conditions of available status, functional matching, and parameter compatibility, it will then sort and select the best candidate functional execution units according to a four-level preset priority strategy written into the local configuration file during system initialization and supporting dynamic adjustment. The preset priority strategy, from highest to lowest, is: service functional execution unit priority, functional execution unit load priority, functional execution unit response speed priority, and functional execution unit registration order priority. The intermediate service unit will retrieve status data such as service flags, real-time load rates, historical response times, and system registration times of each candidate functional execution unit in real time, compare and filter them one by one according to the priority level, and finally determine the functional execution unit ranked first as the target functional execution unit for this service call.

[0060] The layered invocation method for cockpit services provided in this application, if only one qualified functional execution unit is obtained after multi-dimensional screening including function matching, invocation parameter matching, semantic similarity matching, and functional execution unit status availability verification, directly determines this single functional execution unit as the target functional execution unit, thereby quickly locking the target functional execution unit, simplifying the screening process, and improving service invocation response efficiency; if multiple qualified functional execution units are obtained after screening, a unique target functional execution unit is selected from multiple candidate functional execution units based on a preset priority strategy that prioritizes service functional execution units, functional execution unit load, functional execution unit response speed, and functional execution unit registration order, in order to achieve optimal scheduling of service functional execution units, ensure the stability, reliability, and execution continuity of service invocation, and avoid invocation conflicts and resource waste caused by competition among multiple functional execution units.

[0061] Optionally, the above method further includes: If the execution result is not received from the target function execution unit within the preset time, the target function execution unit will be marked as temporarily unavailable, and a new target function execution unit will be selected from other managed function execution units based on the service call request.

[0062] The preset time is a call timeout threshold preset by the system through a local configuration file. It can be selected according to the actual situation. For example, the preset time can be set to: 500ms for core services, 1000ms for ordinary services, and 2000ms for non-core services.

[0063] In one possible implementation, the intermediate service unit starts a timeout countdown simultaneously when sending the service call request to the target function execution unit. If the timeout reaches the preset time and the business execution result is not received from the target function execution unit via the AIDL communication link, the call is deemed to have timed out. At this point, the local function execution unit status cache is immediately updated, marking the running status of the target function execution unit that triggered the timeout as temporarily unavailable. This running status mark is synchronized to the intermediate service unit's function execution unit filtering list, so that the function execution unit is automatically excluded from the subsequent filtering process of this service call and does not participate in secondary matching and function execution unit selection. Subsequently, the intermediate service unit retains the core information such as functional requirements, request parameters, and semantic instructions from the original service call request, and restarts the functional execution unit screening process. During the screening, functional execution units marked as temporarily unavailable, abnormally isolated, or invalid are first removed. Then, candidate functional execution units are screened sequentially through four rules: functional matching, call parameter matching, semantic similarity matching, and state availability matching. If there are multiple candidate functional execution units, they are further screened from the remaining available functional execution units under their jurisdiction according to a four-level priority strategy: core service functional execution unit priority, functional execution unit load priority, functional execution unit response speed priority, and functional execution unit registration order priority. The new target functional execution unit that meets the service call requirements is selected from the remaining available functional execution units under its jurisdiction.

[0064] The layered invocation method for cockpit services provided in this application, if an intermediate service unit does not receive the execution result returned by the target function execution unit within the system's preset timeout threshold, immediately marks the target function execution unit as temporarily unavailable. This prevents subsequent invocation requests from being reassigned to the abnormal function execution unit, causing repeated timeouts. Simultaneously, based on the current service invocation request, it re-executes the matching and filtering process among the other available function execution units under its management to determine a new target function execution unit. Therefore, this application, through its rapid marking and dynamic reselection mechanism for abnormal function execution units, effectively ensures the continuity and stability of the service invocation process, avoids service invocation interruptions due to timeout anomalies of a single function execution unit, and improves the reliability and response success rate of cockpit service invocation.

[0065] Optionally, the above method further includes: If the obtained execution result indicates a service exception, the corresponding target function execution unit will be isolated, and a new target function execution unit will be selected from the other managed function execution units based on the service call request.

[0066] In one possible implementation, the intermediate service unit parses and verifies the execution results returned by the target function execution unit. When the execution result reports one of three service exception states: no response from the underlying service process, abnormal service execution result, or abnormal AIDL communication between the function execution unit and the underlying cockpit service process, or carries the corresponding exception identifier, error code, and exception details, the intermediate service unit determines that the obtained execution result indicates a service exception. At this point, the intermediate service unit immediately records the function execution unit identifier, its level, exception type, and error information of the exception function execution unit, marks it as an exception function execution unit, removes it from the list of available function execution units, and places it in an exception isolation state. The isolation duration can be preset according to the local configuration file parameters; the default isolation time is 30 seconds for ordinary function execution units and 10 seconds for core service function execution units. During the isolation period, the function execution unit does not participate in any service call matching process.

[0067] Subsequently, the intermediate service unit retains the core information of the original service call request, such as functional requirements, request parameters, and semantic instructions. It then traverses all available functional execution units within its jurisdiction, except for the exception isolation functional execution unit. It sequentially completes the screening of candidate functional execution units through four rules: functional matching, call parameter matching, semantic similarity matching, and state availability matching. Finally, it selects the new target functional execution unit based on a four-level strategy: priority of core service functional execution units, priority of functional execution unit load, priority of functional execution unit response speed, and priority of functional execution unit registration order, ensuring the continuous execution of service calls.

[0068] The layered invocation method for cockpit services provided in this application can mark and isolate abnormal target function execution units to prevent them from interfering with subsequent service invocations and to prevent the spread of invocation failures. At the same time, based on the original service invocation request, and according to the rules of function matching, parameter matching, semantic matching, and state matching, it can re-select suitable new target function execution units from other available function execution units under its management, ensuring that the cockpit service invocation process continues uninterrupted and effectively improving the stability and reliability of service invocations.

[0069] Optionally, the above method further includes: In response to changes in the managed functional execution units, the list of functional execution units managed by the target intermediate service unit and the corresponding functional description information are updated and synchronized to the agent.

[0070] In one possible implementation, when the underlying services of the cockpit undergo updates such as additions, deletions, or function modifications, the functional execution units bound to those services will synchronously update their own configurations and report the change status to the system. The target intermediate service unit, by monitoring the registration status and configuration file changes of the functional execution units in real time, detects the changes in the functional execution units under its jurisdiction and immediately responds to the change event, initiating subsequent information update and synchronization processes. Subsequently, based on the type of change of the functional execution units, the target intermediate service unit automatically adjusts its managed list of functional execution units in the background, deleting invalid / removed functional execution unit information, adding new functional execution unit information, and updating the parameter changes of functional execution units. At the same time, it re-aggregates the functional execution unit names, function descriptions, and call parameters of all valid functional execution units within its jurisdiction, generates and updates its own hierarchical function description information, and synchronously writes the updated data to local configuration files (such as level_config.json and mcp_node_config.json), completing the dynamic calibration of local information. Once the target intermediate service unit completes the local list and function description information update, it pushes the latest function execution unit list and hierarchical function description information to the agent through the HTTP and JSON or RPC 2.0 communication links established during the initialization phase. After receiving the information, the agent automatically replaces the old configuration data cached locally, completes real-time information synchronization, and ensures that the information used for subsequent semantic matching and service calls is consistent with the actual management information of the intermediate service unit.

[0071] The layered invocation method for cockpit services provided in this application allows the intermediate service unit to respond immediately to changes such as additions, deletions, or functional modifications to the functional execution units managed by the intermediate service unit. It automatically updates the list of functional execution units it manages and simultaneously updates the hierarchical functional description information based on the subordinate functional execution units. The updated list and functional description information are also synchronized to the agent's local cache, ensuring that the agent's information is consistent with the actual state of the underlying services in real time. This effectively avoids semantic matching errors and invocation errors caused by changes in functional execution units, continuously guaranteeing service identification accuracy and routing stability.

[0072] Figure 5 A flowchart illustrating a layered invocation method for cabin services provided in this application embodiment. Figure 3 .like Figure 5 As shown, the method, executed by the agent, includes: S510. In response to a service call request, determine the target intermediate service unit from multiple candidate intermediate service units based on the service call request.

[0073] Each candidate intermediate service unit manages at least one functional execution unit.

[0074] In one possible implementation, after receiving the cockpit service interaction command from the user, the agent first performs semantic parsing and message encapsulation of the command, generates a standardized service call request, and triggers the subsequent matching process. Then, the agent reads the structured information such as the hierarchical name, hierarchical function description, and subordinate function summary of each candidate intermediate service unit synchronized during the system initialization phase from the local cache. It compares the core functional intent of the service call request with the above information. That is, the agent relies on the natural language understanding capability of the built-in preset AI model to perform semantic matching between the service call request and the functional description of each candidate intermediate service unit, and selects the unique target intermediate service unit that matches the requested functional domain. Each candidate intermediate service unit manages at least one functional execution unit. This means that each candidate intermediate service unit is a logically classified unit divided according to the business functional domain. During system initialization, based on the domain label registered by the functional execution unit, one or more functional execution units in the same domain are included in its management scope, forming a one-to-one or one-to-many management relationship.

[0075] S520. Send the service call request to the target intermediate service unit, so that the target intermediate service unit can select the target function execution unit from the function execution units managed by the target intermediate service unit based on the service call request and send the service call request to the target function execution unit.

[0076] In one possible implementation, the agent, through HTTP and JSON or RPC 2.0 communication links established during system initialization, transmits the encapsulated service call request to the identified target intermediate service unit in a long-lived connection or request-response mode. Upon receiving the service call request, the target intermediate service unit parses the message and extracts core information such as functional requirements, call parameters, and semantic instructions as selection criteria. The target intermediate service unit then filters candidate functional execution units sequentially through four dimensions: functional matching, call parameter matching, semantic similarity matching, and state availability matching. If multiple candidate functional execution units exist, a unique target functional execution unit is determined according to a four-level strategy: priority of core service functional execution units, priority of functional execution unit load, priority of functional execution unit response speed, and priority of functional execution unit registration order. Finally, the target intermediate service unit forwards the service call request to the target functional execution unit through an internal communication link, providing instruction support for subsequent business logic execution.

[0077] S530: Receive the execution result returned by the target intermediate service unit.

[0078] The execution result is generated by the target function execution unit after executing the business logic corresponding to the service call request, and then returned by the target intermediate service unit.

[0079] In one possible implementation, the agent receives service execution result messages from the target intermediate service unit via a communication link, completing the reception and parsing of the result data. Specifically, the target functional execution unit, as a functional execution unit bound one-to-one with the underlying cockpit service process, drives the underlying service process to run via the AIDL protocol to complete the execution of the business logic corresponding to the service call request and generate an execution result containing execution status and data information. Subsequently, the target functional execution unit first sends the execution result back to the target intermediate service unit that manages it. The target intermediate service unit then encapsulates and verifies the result before forwarding it to the agent along the original communication path, ultimately forming a complete service call and result feedback closed loop.

[0080] The layered invocation method for cockpit services provided in this application, in response to a service invocation request, involves an agent performing semantic matching based on the service invocation request and the functional description information of each candidate intermediate service unit, determining the target intermediate service unit from multiple candidate intermediate service units. Each candidate intermediate service unit aggregates and manages at least one functional execution unit according to its functional domain, which can effectively reduce the semantic recognition error of the agent when facing a large number of similar services, and reduce the number of interactive objects and computational overhead. The agent sends the service invocation request to the target intermediate service unit, so that the target intermediate service unit performs a secondary screening among the functional execution units it manages based on the service invocation request to determine the target functional execution unit, and then sends the service invocation request to the target functional execution unit, further improving the accuracy and response efficiency of the service invocation. Subsequently, the agent receives the execution result returned by the target intermediate service unit. This execution result is generated by the target functional execution unit after executing the business logic corresponding to the service invocation request, and is fed back to the agent through the target intermediate service unit along the original communication link, thus forming a complete service invocation closed loop, ensuring the efficiency, stability and accuracy of cockpit service invocation.

[0081] Figure 6 A flowchart illustrating a layered invocation method for cabin services provided in this application embodiment. Figure 4 .like Figure 6 As shown, in response to the service call request, the above method also includes: S610: Obtain configuration information for at least one functional execution unit within the cockpit.

[0082] The configuration information includes at least the following: the name, function description, call parameter description, and domain tag for each functional execution unit. The name of each functional execution unit is a standardized character name pre-configured during system deployment to uniquely identify its service identity. This name is used for identification during system registration, node list display, and link communication addressing; it is unique throughout the system. The function description is pre-configured text information that records the specific business capabilities, executable operation types, and applicable service scenarios of the corresponding functional execution unit. This content is standardized semantic text and serves as the semantic basis for semantic understanding, semantic similarity calculation, and function matching determination between the agent and the intermediate service unit. The call parameter description is a standardized parameter definition for the external service interface of the functional execution unit, including the parameter types, number, value range, required fields, optional fields, and parameter data structure of the interface input and output parameters. During service calls, the intermediate service unit can use this call parameter description to verify the validity of the request parameters carried by the user request and whether they conform to the node interface specifications. This allows for the calculation of the call parameter matching degree, preventing service call anomalies or execution failures due to non-standard parameters. The domain label is a pre-configured, standardized business category identifier used to represent the business function domain to which the corresponding functional execution unit belongs, such as air conditioning control, seat control, audio entertainment, and lighting control. This label is the sole classification criterion for system aggregation and categorization. Based on the same domain label, the system aggregates and groups multiple functional execution units of the same type and business domain under the same intermediate service unit for unified management, thereby achieving the automatic construction of a domain-based hierarchical architecture for cabin services.

[0083] In one possible implementation, after the system powers on and completes the startup of the underlying cockpit service process, it enters the functional execution unit initialization and registration phase. Each functional execution unit, upon startup, automatically performs a registration operation according to system preset rules, proactively reporting all its pre-configured structured configuration information to the system. The system reads configuration files stored on the local hard drive, uniformly receiving, parsing, and collecting the configuration information reported by all registered functional execution units. It then extracts two core configuration elements: functional description and domain tag, which are then collected, organized, and temporarily stored as the foundational data for subsequent classification, management, and generation of intermediate service units. This completes the unified collection and aggregation of basic configuration information for all functional execution units within the cockpit.

[0084] S620. At least one functional execution unit with the same domain label is grouped into the same candidate intermediate service unit for management, and functional description information is generated for each candidate intermediate service unit.

[0085] In one possible implementation, the system, based on locally pre-stored first-level hierarchical configuration rules, uses the domain label of the functional execution unit as the sole classification criterion. It automatically assigns one or more functional execution units with the same domain label to the same candidate intermediate service unit, which then performs unified routing, scheduling, and status management. After classifying the functional execution units, the candidate intermediate service unit automatically summarizes the functional descriptions, call parameters, and other configuration information of all the functional execution units under its jurisdiction. Based on this summary, it generates its own unique hierarchical functional description information, which is used to externally represent the overall service capabilities of this candidate intermediate service unit.

[0086] Optionally, the method described above, based on the service invocation request, determines the target intermediate service unit from multiple candidate intermediate service units, including: S630. Based on the service call request and the functional description information of each candidate intermediate service unit, determine the target intermediate service unit.

[0087] In one possible implementation, the agent acquires and caches the functional description information of all candidate intermediate service units during the system initialization phase. When a service call request is received, the agent synchronously inputs the semantic instructions in the service call request and the functional description information of each candidate intermediate service unit cached locally into a preset AI big model. The preset AI big model calculates the matching degree between the two through natural language understanding and semantic matching capabilities. Based on the matching result, it selects the candidate intermediate service unit that best matches the function of the service call request and determines it as the target intermediate service unit for this service call.

[0088] The layered invocation method for cockpit services provided in this application first obtains the configuration information of at least one functional execution unit within the cockpit. This configuration information includes a pre-defined functional description and domain label for each functional execution unit, thereby clarifying the service capabilities and business affiliation of each functional execution unit and providing data basis for subsequent service classification. Subsequently, at least one functional execution unit with the same domain label is grouped into the same candidate intermediate service unit for unified aggregation and management. A unique functional description is generated for each candidate intermediate service unit, achieving centralized management of similar services, effectively simplifying the service architecture and reducing the semantic understanding and recognition difficulty of the intelligent agent. Finally, semantic matching is performed based on the service invocation request and the functional description information of each candidate intermediate service unit to determine the target intermediate service unit, avoiding semantic recognition errors caused by a large number of similar services from the source, and improving the accuracy of service matching and invocation efficiency.

[0089] Optionally, the method described above determines the target intermediate service unit based on the service call request and the functional description information of each candidate intermediate service unit, including: Semantic matching is performed based on the service call request and the functional description information of each candidate intermediate service unit.

[0090] In one possible implementation, after receiving a service call request from a user, the agent first performs message parsing and semantic analysis on the service call request, extracting core semantic information such as the user's functional intent, business requirements, and scenario demands contained in the service call request. Simultaneously, the agent retrieves the functional description information of all candidate intermediate service units stored locally in a pre-cached manner. This functional description information is generated by the corresponding candidate intermediate service unit based on the overall service capabilities of all functional execution units under its jurisdiction. The agent then feeds the parsed core semantic information of the service call request and the functional description information of each candidate intermediate service unit into a pre-defined semantic matching model. Through natural language feature extraction, semantic vector encoding, and content relevance comparison, a global semantic matching operation is performed between the service call request and the functional description information of each candidate intermediate service unit, obtaining a semantic matching score between the two, providing a quantitative basis for subsequent matching result determination.

[0091] If the semantic match is successful, the target intermediate service unit is determined.

[0092] In one possible implementation, the agent pre-sets a semantic matching threshold. After calculating the semantic matching score between the service call request and each candidate intermediate service unit, it compares the semantic matching score of each candidate intermediate service unit with the preset semantic matching threshold. If at least one candidate intermediate service unit has a semantic matching score greater than or equal to the preset semantic matching threshold, the semantic matching result is considered a successful match. Among all candidate intermediate service units that meet the threshold requirements, the agent selects the candidate intermediate service unit with the highest semantic matching score and the best business domain fit, and locks it as the target intermediate service unit corresponding to the current user service call request, thus entering the subsequent request forwarding and service scheduling process.

[0093] If semantic matching fails and the target intermediate service unit is not identified, the control agent returns a matching failure message to the user.

[0094] In one possible implementation, after the agent completes the semantic matching score comparison of all candidate intermediate service units, if the semantic matching score of all candidate intermediate service units is lower than the preset semantic matching threshold, it indicates that the overall service capability of all candidate intermediate service units in the current cabin cannot match the functional intent of the service call request initiated by the user. At this time, the semantic matching is determined to be unsuccessful, and it is impossible to filter and determine the target intermediate service unit that meets the requirements from the many candidate intermediate service units. In this case, the agent terminates the process of forwarding the service call request to the lower-level intermediate service unit, and at the same time triggers the human-machine interaction prompt mechanism. Through human-machine interaction methods such as text pop-ups on the in-vehicle screen, voice broadcasts, and interface icon reminders, it actively pushes prompt information to the user indicating that the semantic matching has failed and the function command is not currently supported, thus completing the interaction loop in abnormal scenarios and avoiding ineffective link scheduling and resource waste.

[0095] The layered invocation method for cockpit services provided in this application involves an intelligent agent receiving parsed service invocation requests and performing semantic matching with the pre-generated functional description information of each candidate intermediate service unit. A semantic similarity comparison mechanism is used to select service units that are highly compatible with the business domain. If the semantic matching is successful, the target intermediate service unit that matches the current user command is determined, ensuring that subsequent service requests can be forwarded in a targeted and orderly manner. If the semantic matching fails and the corresponding target intermediate service unit cannot be determined, the intelligent agent promptly generates a matching failure message and sends it back to the user. This avoids invalid node traversal and idle scheduling, reduces system computational resource overhead, and promptly informs the user that there is no corresponding available service for the current command, improving the integrity of human-computer interaction and user experience.

[0096] Based on the same inventive concept, this application also provides a hierarchical invocation device for cabin services. Since the principle of the device in this application is similar to the hierarchical invocation method for cabin services 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.

[0097] Figure 7 A schematic diagram of the structure of a layered dispatching device for cabin services provided in this application embodiment. Figure 1 .like Figure 7 As shown, the first hierarchical invocation device 700 for the cockpit service, executed by the target intermediate service unit (which is determined by the agent from multiple candidate intermediate service units based on a service invocation request), includes: The filtering module 701 is used to respond to a service call request sent by the intelligent agent and, based on the service call request, filter out the target functional execution unit from at least one functional execution unit under management. The first sending module 702 is used to send a service call request to the target function execution unit so that the target function execution unit executes the business logic corresponding to the service call request. The acquisition module 703 is used to acquire the execution result returned by the target function execution unit and return the execution result to the intelligent agent.

[0098] In one optional implementation, the filtering module 701 is specifically used to: determine the function matching degree based on the semantic relevance between the service call request and the preset function information of each function execution unit; determine the call parameter matching degree based on the matching degree between the request parameters in the service call request and the call parameters corresponding to each function execution unit; and sequentially filter at least one managed function execution unit based on the function execution unit status, function matching degree, and call parameter matching degree to determine the target function execution unit; the function execution unit status is used to indicate whether the corresponding function execution unit is in an available state.

[0099] In one optional implementation, the filtering module 701 is specifically used for: filtering a set of candidate functional execution units whose functional execution units are in an available state from at least one managed functional execution unit based on the functional execution unit status; sorting the functional matching degree of each functional execution unit in the candidate functional execution unit set to obtain a first matching unit set, wherein the first matching unit set consists of functional execution units whose functional matching degree meets preset functional requirements; and determining the target functional execution unit in the first matching unit set based on the matching degree of the calling parameters of each functional execution unit.

[0100] In one optional implementation, the filtering module 701 is specifically used to: if a single functional execution unit is obtained after filtering, then the single functional execution unit is determined as the target functional execution unit; if multiple functional execution units are obtained after filtering, then the target functional execution unit is determined from the multiple functional execution units based on a preset priority strategy.

[0101] In an optional implementation, the first hierarchical invocation device 700 is further configured to: if no execution result is received from the target function execution unit within a preset time, mark the target function execution unit as temporarily unavailable, and, based on the service invocation request, reselect a new target function execution unit from the other managed function execution units.

[0102] In an optional implementation, the first hierarchical invocation device 700 is further configured to: if the obtained execution result indicates a service exception, isolate the corresponding target function execution unit, and based on the service invocation request, reselect a new target function execution unit from the other managed function execution units.

[0103] In an optional implementation, the first hierarchical invocation device 700 is further configured to: update the list of functional execution units managed by the target intermediate service unit and the corresponding functional description information in response to changes in the managed functional execution units, and synchronize them to the intelligent agent.

[0104] Figure 8 A schematic diagram of the structure of a layered dispatching device for cabin services provided in this application embodiment. Figure 2 .like Figure 8 As shown, the second-level invocation device 800 for the cockpit service, executed by an intelligent agent, includes: The determination module 801 is used to determine the target intermediate service unit from multiple candidate intermediate service units in response to a service call request, based on the service call request, wherein each candidate intermediate service unit manages at least one functional execution unit; The second sending module 802 is used to send the service call request to the target intermediate service unit, so that the target intermediate service unit can select the target function execution unit from the function execution units managed by the target intermediate service unit based on the service call request and send the service call request to the target function execution unit. The receiving module 803 is used to receive the execution result returned by the target intermediate service unit. The execution result is generated by the target function execution unit after executing the business logic corresponding to the service call request, and is returned by the target intermediate service unit.

[0105] In an optional implementation, the second hierarchical invocation device 800 is further configured to: obtain configuration information of at least one functional execution unit in the cockpit, wherein the configuration information is a functional description and domain label of each functional execution unit; classify at least one functional execution unit with the same domain label into the same candidate intermediate service unit for management, and generate functional description information for each candidate intermediate service unit; the determination module 801 is specifically configured to: determine the target intermediate service unit based on the service invocation request and the functional description information of each candidate intermediate service unit.

[0106] In one optional implementation, the determining module 801 is specifically used to: perform semantic matching based on the service call request and the functional description information of each candidate intermediate service unit; if the semantic matching is successful, the target intermediate service unit is determined; if the semantic matching fails and no target intermediate service unit is determined, the control agent returns a matching failure prompt to the user.

[0107] It should be noted that for details not disclosed in the layered invocation device for cockpit services in this application embodiment, please refer to the details disclosed in the layered invocation method for cockpit services in this application embodiment, which will not be repeated here.

[0108] 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).

[0109] 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 layered invocation method for cockpit services described in the above embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0110] 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 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 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.

[0111] Optionally, this embodiment also provides a computer program product. When the computer program product is run on a computer, the computer performs the above-mentioned related steps to implement a layered invocation method for cabin services provided in the above embodiment.

[0112] 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.

[0113] 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.

[0114] 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 there may be other division methods 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.

[0115] 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 method for hierarchical invocation of cabin services, characterized in that, The method, executed by a target intermediate service unit (which is determined by the agent from multiple candidate intermediate service units based on a service invocation request), includes: In response to the service call request sent by the intelligent agent, a target functional execution unit is selected from at least one functional execution unit under management based on the service call request; The service call request is sent to the target function execution unit so that the target function execution unit executes the business logic corresponding to the service call request; Obtain the execution result returned by the target function execution unit and return the execution result to the intelligent agent.

2. The method according to claim 1, characterized in that, The step of selecting the target function execution unit from the managed at least one function execution unit based on the service call request includes: The functional matching degree is determined based on the semantic relevance between the service call request and the preset functional information of each functional execution unit; The matching degree of the calling parameters is determined based on the degree of matching between the request parameters in the service call request and the call parameters corresponding to each functional execution unit. The at least one managed function execution unit is filtered sequentially based on the function execution unit status, the function matching degree, and the call parameter matching degree to determine the target function execution unit; the function execution unit status is used to indicate whether the corresponding function execution unit is in an available state.

3. The method according to claim 2, characterized in that, The step of filtering the managed at least one functional execution unit based on the functional execution unit status, the functional matching degree, and the call parameter matching degree includes: Based on the state of the functional execution unit, a set of candidate functional execution units in an available state is selected from the at least one functional execution unit under management; In the candidate functional execution unit set, the functional matching degree of each functional execution unit is sorted to obtain a first matching unit set. The first matching unit set consists of functional execution units whose functional matching degree meets the preset functional requirements. In the first set of matching units, the target function execution unit is determined based on the matching degree of the calling parameters of each function execution unit.

4. The method according to claim 2 or 3, characterized in that, The determination of the target function execution unit includes: If a single functional execution unit is obtained after filtering, then the single functional execution unit is determined as the target functional execution unit; If multiple functional execution units are obtained after filtering, the target functional execution unit is determined from the multiple functional execution units based on a preset priority strategy.

5. The method according to claim 1, characterized in that, The method further includes: If the execution result is not received from the target function execution unit within a preset time, the target function execution unit will be marked as temporarily unavailable, and a new target function execution unit will be selected from the other managed function execution units based on the service call request.

6. The method according to claim 1, characterized in that, The method further includes: If the obtained execution result indicates a service error, the corresponding target function execution unit will be isolated, and a new target function execution unit will be selected from the other managed function execution units based on the service call request.

7. The method according to claim 1, characterized in that, The method further includes: In response to changes in the managed functional execution units, the list of functional execution units managed by the target intermediate service unit and the corresponding functional description information are updated and synchronized to the intelligent agent.

8. A method for hierarchical invocation of cabin services, characterized in that, Performed by an intelligent agent, the method includes: In response to a service call request, a target intermediate service unit is determined from multiple candidate intermediate service units based on the service call request, and each candidate intermediate service unit manages at least one functional execution unit; The service call request is sent to the target intermediate service unit, so that the target intermediate service unit, based on the service call request, selects the target functional execution unit from the functional execution units managed by the target intermediate service unit and sends the service call request to the target functional execution unit. The system receives the execution result returned by the target intermediate service unit. The execution result is generated by the target function execution unit after executing the business logic corresponding to the service call request, and is returned by the target intermediate service unit.

9. The method according to claim 8, characterized in that, Prior to responding to a service invocation request, the method further includes: Obtain configuration information for at least one functional execution unit within the cockpit, wherein the configuration information comprises a functional description and domain label for each functional execution unit; At least one functional execution unit with the same domain label is grouped into the same candidate intermediate service unit for management, and functional description information is generated for each candidate intermediate service unit. The step of determining the target intermediate service unit from multiple candidate intermediate service units based on the service call request includes: Based on the service call request and the functional description information of each candidate intermediate service unit, the target intermediate service unit is determined.

10. The method according to claim 9, characterized in that, The step of determining the target intermediate service unit based on the service call request and the functional description information of each candidate intermediate service unit includes: Semantic matching is performed based on the service call request and the functional description information of each candidate intermediate service unit; If the semantic matching is successful, the target intermediate service unit is determined; If semantic matching fails and the target intermediate service unit is not identified, the agent is controlled to return a matching failure message to the user.

11. 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 10.

Images