Display method, device and equipment of vehicle-mounted human-computer interaction interface and storage medium

Abstract

This invention provides a display method, apparatus, device, and storage medium for an in-vehicle human-machine interface, belonging to the field of interactive control technology. By acquiring intent recognition results containing the number and attribute information of user intents, the system can deeply understand the entire composition and details of a user's complete request at the data level. Then, by analyzing these data characteristics, the target layout pattern of the interface is dynamically determined, allowing the interface layout to flexibly adjust according to real-time changes in user intents. Finally, the determined functional components are displayed in this dynamically generated layout, thereby presenting multiple related task information to the user simultaneously on a unified and logically clear interface. This solution can more efficiently and intuitively display the processing of complex intents, significantly improving the information presentation efficiency and user experience of in-vehicle human-machine interaction.

Description

Technical Field

[0001] This invention relates to the field of interactive control technology, and in particular to a display method, apparatus, device, and storage medium for an in-vehicle human-machine interface. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity technologies, intelligent cockpits have become a core component of modern automobiles. As the main window for users to interact with the vehicle information system, the design and implementation of the in-vehicle human-machine interface directly affects the user's driving experience and driving safety.

[0003] Most existing in-vehicle human-machine interfaces use preset templates or fixed card layouts. Such static layouts require more user interaction to display the content the user wants to see, resulting in relatively low interaction efficiency. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for displaying a vehicle-mounted human-machine interface, which addresses the shortcomings of existing static layout vehicle-mounted human-machine interfaces that require more user interaction to display the content the user wants to see, resulting in low interaction efficiency. This invention enables the dynamic generation of vehicle-mounted human-machine interfaces, thereby improving interaction efficiency.

[0005] This invention provides a method for displaying a vehicle-mounted human-machine interface, comprising the following steps.

[0006] Obtain the intent recognition result determined based on the input operation request, wherein the intent recognition result includes at least one user intent and intent type and attribute information corresponding to each user intent; The target functional components to be used are determined based on the user intent and the intent type corresponding to the user intent. The target layout pattern is determined based on the number of user intents and the attribute information of the user intents; Based on the target layout pattern, function cards corresponding to the target functional components are displayed on the in-vehicle human-machine interface.

[0007] According to a display method for an in-vehicle human-machine interface provided by the present invention, the step of determining the target functional component to be used based on the user intent and the intent type corresponding to the user intent includes: Based on the intent type corresponding to the user intent, select the main functional components with the same intent type from the atomic component library; Based on the user intent, determine the variants corresponding to the main functional component and the required auxiliary components; The target functional component is constructed based on the variants corresponding to the main functional component and the required auxiliary components.

[0008] According to a display method for an in-vehicle human-machine interface provided by the present invention, the intent recognition result further includes scene state information, and the step of filtering out main functional components with the same intent type from the atomic component library based on the intent type corresponding to the user intent includes: Based on the intent type corresponding to the user intent, select candidate functional components with the same intent type from the atomic component library; The scene state information is used to filter out functional components that do not match the current scene from the candidate functional components, and the main functional components are obtained. The scene status information includes one or more of the following: time information, vehicle location information, vehicle speed information, and weather information.

[0009] According to the present invention, the display method of an in-vehicle human-machine interface further includes user historical preference information in the intent recognition result. After constructing the target functional component based on the variant corresponding to the main functional component and the required auxiliary components, the display method of the in-vehicle human-machine interface further includes: Based on the user's historical preference information, update the default configuration parameters of the target functional component.

[0010] According to a display method for an in-vehicle human-machine interface provided by the present invention, the attribute information includes the dependency relationship of user intent and the priority level of user intent; Determining the target layout pattern based on the number of user intents and the attribute information of the user intents includes: The preset application scenario corresponding to the current application scenario is determined based on at least one of the user intent dependency relationship and the user intent priority level, along with the number of user intents. Based on the preset application scenario corresponding to the current application scenario, select the target layout mode from the preset layout modes.

[0011] According to a display method for an in-vehicle human-machine interface provided by the present invention, the step of determining a preset application scenario corresponding to the current application scenario based on at least one of the dependency relationship of the user intent and the priority level of the user intent, along with the number of user intents, includes: If the number of user intents is one and the dependency relationship is non-dependent, the current application scenario is determined to be a single-task execution scenario. If there are multiple user intents, the dependency relationship is independent, and the priority levels differ by a preset level, the current application scenario is determined to be a multi-task parallel processing scenario. If there are multiple user intents, the dependency relationship is non-dependent, and the priority levels differ by less than a preset level, the current application scenario is determined to be a multi-task primary and secondary processing scenario. If there are multiple user intents, the dependency relationship is dependent, and the triggering type of the dependency relationship is user-triggered, then the current application scenario is determined to be the first multi-task serial processing scenario. If there are multiple user intents, the dependency relationship is dependent, and the triggering type of the dependency relationship is automatic triggering, then the current application scenario is determined to be the second multi-task serial processing scenario.

[0012] According to a display method for an in-vehicle human-machine interface provided by the present invention, the step of selecting a target layout mode from a preset layout mode based on the current application scenario further includes: Obtain constraints, which include scene state constraints and / or user preference constraints. The scene state constraints are used to constrain at least one of the following: the number of split screens of the vehicle human-machine interface, the display parameters of the vehicle human-machine interface, the priority level of the functional components, and the display parameters of the functional components. Adjust the page layout parameters in the target layout mode based on the constraints; or adjust and switch the target layout mode based on the constraints.

[0013] According to a display method for an in-vehicle human-machine interface provided by the present invention, after displaying the function card corresponding to the target functional component on the in-vehicle human-machine interface based on the target layout pattern, the display method further includes: The execution status of the target task is displayed based on the function card corresponding to the target functional component; The target task is the task performed by the target functional component.

[0014] According to a display method for an in-vehicle human-machine interface provided by the present invention, after displaying the function card corresponding to the target functional component on the in-vehicle human-machine interface based on the target layout pattern, the display method further includes: In response to the user's voice input, at least one voice interaction label determined based on the voice input is displayed on the in-vehicle human-machine interface; In response to the user's input on the target voice interaction tag, the control command corresponding to the target voice interaction tag is executed.

[0015] The present invention also provides a display device for an in-vehicle human-machine interface, comprising the following modules: The acquisition module is used to acquire the intent recognition result determined based on the input operation request. The intent recognition result includes at least one user intent and intent type and attribute information corresponding to each user intent. The first determining module is used to determine the target functional component to be used based on the user intent and the intent type corresponding to the user intent; The second determining module is used to determine the target layout pattern based on the number of user intentions and the attribute information of the user intentions; The display module is used to display function cards corresponding to the target functional components on the in-vehicle human-machine interface based on the target layout pattern.

[0016] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the display method of any of the above-described vehicle-mounted human-machine interface.

[0017] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the display method of the vehicle-mounted human-machine interface as described above.

[0018] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements the display method of any of the above-described vehicle-mounted human-machine interface.

[0019] The present invention provides a display method, apparatus, device, and storage medium for an in-vehicle human-machine interface. By acquiring intent recognition results containing the number and attribute information of user intents, the system can deeply understand the entire composition and details of a user's complete request at the data level. Then, by analyzing these data characteristics (especially the number and attribute information of intents), the target layout mode of the interface is dynamically determined. This breaks through the limitations of existing technologies that rely on static, preset templates, allowing the interface layout to be flexibly adjusted according to real-time changes in user intents. Finally, the determined functional components are displayed in this dynamically generated layout, thereby presenting multiple related task information to the user simultaneously on a unified and logically clear interface. The entire process achieves end-to-end dynamic generation from intent to interface. Compared to the existing technology that can only switch single cards within a fixed template, this solution can more efficiently and intuitively display the processing of complex intents, significantly improving the information presentation efficiency and user experience of in-vehicle human-machine interaction. Attached Figure Description

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

[0021] Figure 1 This is one of the flowcharts illustrating the display method of the vehicle-mounted human-machine interface provided by the present invention.

[0022] Figure 2 This is a flowchart illustrating the process of determining the target functional component to be used based on the user intent and the intent type corresponding to the user intent, as provided by the present invention.

[0023] Figure 3 This is a flowchart illustrating how the present invention filters out main functional components with the same intent type from the atomic component library based on the intent type corresponding to the user's intent.

[0024] Figure 4 This is a flowchart illustrating the process of determining the target layout pattern based on the number of user intentions and the attribute information of user intentions, as provided by the present invention.

[0025] Figure 5 This is the second flowchart illustrating the display method of the vehicle-mounted human-machine interface provided by the present invention.

[0026] Figure 6 This is the third flowchart illustrating the display method of the vehicle-mounted human-machine interface provided by the present invention.

[0027] Figure 7 This is a schematic block diagram of the display device for the vehicle-mounted human-machine interface provided by the present invention.

[0028] Figure 8 This is a schematic diagram of the structure of the electronic device provided by the present invention.

[0029] Figure label: 701: Acquisition module; 702: First determination module; 703: Second determination module; 704: Display module; 810: Processor; 820: Communication interface; 830: Memory; 840: Communication bus. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0031] The following explains the terminology used in this invention: 1. Directed acyclic graph (DAG) is used to represent dependencies between multiple tasks.

[0032] 2. context_info: Context information, including time, weather, vehicle speed, location, user habits, etc.

[0033] 3. delta_priority: Intent priority difference, used to distinguish between primary and secondary scenarios and parallel scenarios.

[0034] 4. space_ratio: The ratio of space required by the intent, used to determine the split-screen ratio or whether to use picture-in-picture.

[0035] 5. USER_TRIGGER: User-triggered dependency; subsequent tasks require user confirmation to activate.

[0036] 6. AUTO_TRIGGER: System-triggered dependency; automatically activates subsequent tasks after the preceding tasks are completed.

[0037] This application provides a method for displaying an in-vehicle human-machine interface, which can be executed by the display device of the in-vehicle human-machine interface. This device can be integrated into an in-vehicle smart cockpit device, such as an in-vehicle central control unit or an in-vehicle operating system. The generating device may include a processor and a memory, and the method is implemented by the processor executing computer program instructions stored in the memory. The embodiments of the present invention will be described in detail below.

[0038] The following is combined Figures 1 to 8 The present invention describes a display method, apparatus, device, and storage medium for an in-vehicle human-machine interface.

[0039] Figure 1 This is one of the flowcharts illustrating the display method of the in-vehicle human-machine interface provided by the present invention, such as... Figure 1 As shown, the method includes the following: Step 101: Obtain the intent recognition result determined based on the input operation request. The intent recognition result includes at least one user intent and the intent type and attribute information corresponding to each user intent.

[0040] Input operation requests are the way users express their needs to the in-vehicle system. These requests can take many forms. For example, it could be a sentence spoken by the user (such as "Navigate to Central Park and order me a coffee while you're at it"), which the in-vehicle voice recognition engine will convert into text. It could also be text entered by the user in the in-vehicle system's text input box, or a general request initiated by the user by clicking a function entry button.

[0041] The intent recognition model within the in-vehicle system, such as a natural language understanding model or a master agent based on a large language model, performs deep parsing of the aforementioned input operation requests and generates structured intent recognition results. These results are machine-readable data structures, such as JSON or XML messages, to facilitate subsequent processing.

[0042] The core of intent recognition results is at least one user intent. A user intent can be understood as an independent, executable task unit. For example, in requesting navigation to a destination and playing music, the intent recognition model will resolve two user intents: one for navigation and the other for playing music.

[0043] In order for subsequent steps to process these user intents, each user intent needs to be associated with intent type and attribute information.

[0044] The intent type is a classification identifier for the functional domain to which the user's intent belongs. For example, it could be navigation, food, media, climate, etc. This classification helps the system assign user intents to the corresponding functional modules for processing.

[0045] Attribute information is a specific description of the user's intent and the parameters required for its execution. This is a broad concept that includes all kinds of information necessary to execute the user's intent.

[0046] In some embodiments, step 101 mainly includes two steps: receiving user input and determining user intent, specifically: The input received from the user is: the user's input operation request via voice or text input, such as: Navigate to Central Park, and please order me a coffee.

[0047] The process of receiving user input is as follows: 1. The in-vehicle speech recognition engine is called to convert speech into text, which is then fed into a natural language understanding model for preliminary semantic analysis; 2. Synchronously collect current scene context: timestamp (system clock), Global Positioning System (GPS) positioning (location and region type), vehicle speed, and weather; 3. Read the user's historical preference database and generate user habit feature vectors (user_habits); The output of receiving user input consists of: the original text input (i.e., the text obtained from the initial semantic parsing) and the scene context data packet.

[0048] The scene context data packet includes time period, weather conditions, vehicle speed status, geographical region, and user_habits.

[0049] The input for determining the user's intent is: the output that receives the user's input; The process of determining user intent is as follows: MasterAgent (the main intelligent agent) performs multi-intent recognition and task decomposition using a large language model. The specific steps are as follows: (1) Semantic parsing: Identify the number of user intents (single intent / multiple intents), the service type of each intent (navigation / food / media / climate, etc.), and intent parameters (destination, product name, etc.); (2) Dependency analysis: Determine whether there is an execution order dependency between each intent. If the execution of intent B is contingent on the completion of intent A, then set B.depends_on=A.id; at the same time, determine the trigger type (USER_TRIGGER user-initiated trigger / AUTO_TRIGGER system-initiated trigger). (3) Priority sorting: Assign a priority value (0 is the highest) to each intent based on the order in which the user expresses their intent (previous intents have higher priority), the urgency of the task (security-related intents have higher priority), and historical preferences (user_habits.priority_weights). (4) Scene fusion: Encapsulate the scene context (context_info) into the intent delivery protocol for use in subsequent steps; The output for determining user intent is: the intent recognition result output by the structured intent delivery protocol.

[0050] For example, the intent recognition result is represented as: {"request_id":"req_20260413_001","scene_state":"parked", "multi_intent_mode":"parallel", "context_info":{"time":"08:30","time_period":"morning_rush", "weather":"sunny","temperature":22,"vehicle_speed":0, "location":"First City, First District","area_type":"urban", "user_habits":{"preferred_coffee":"brand","nav_preference":"fastest", "layout_history":{"HORIZONTAL_SPLIT":0.72,"FULLSCREEN":0.21}}}, "intents":[ {"id":"intent_001","service":"navigation","intent":"navigate_to", "priority":0,"status":"pending","depends_on":null, "context":{"destination":"Central Park","address":"First City, First District"}}, {"id":"intent_002","service":"food","intent":"order", "priority":1,"status":"pending","depends_on":null, "context":{"brand":"Branded Coffee"}} ]}.

[0051] Step 102: Determine the target functional components to be used based on the user intent and the intent type corresponding to the user intent.

[0052] A functional component can be understood as a logical functional unit that encapsulates the backend service call logic and frontend interface display logic for a specific business. For example, there may be navigation components, music components, order components, etc.

[0053] The process of identifying the target functional component can be a lookup process based on a pre-defined mapping. The system can internally maintain a mapping table between intent types and functional components. When a user intent with a specific intent type (such as navigation) is received, the system queries this mapping table to find the corresponding navigation functional component and identifies it as the target functional component to be used. This mapping table can be stored in a local database or configuration file. In this way, the system can establish a clear association between abstract user intents and specific functional implementation modules.

[0054] Step 103: Determine the target layout pattern based on the number of user intents and the attribute information of the user intents.

[0055] Among them, layout mode refers to the way the display area is divided and organized on the vehicle human-machine interface. For example, it can be a full-screen mode that occupies the entire screen, or a split-screen mode that divides the screen into two areas, left and right or top and bottom.

[0056] Specifically, the system first analyzes the number of user intents contained in the intent recognition results. For example, if the number is one, the system may prefer to select full-screen mode to provide an immersive single-task experience. If the number is multiple, the system will determine that a layout mode that can accommodate multiple function cards displayed side by side is needed, such as split-screen mode.

[0057] Simultaneously, the system also analyzes the attribute information of user intentions. As mentioned earlier, the attribute information contains the parameters required to execute the intention, and these parameters, to some extent, reflect the complexity, information content, or importance of the intention. The system can use this attribute information to assist in deciding on the layout pattern. For example, given two user intentions, if one intention's attribute information is very simple (such as adjusting volume), while the other intention's attribute information is very complex (such as planning a long-distance route), the system may choose a layout pattern with a clear hierarchy rather than an equally divided layout pattern.

[0058] By comprehensively analyzing the quantity and attribute information of intentions, the system can dynamically select the most suitable target layout pattern from a preset layout pattern library.

[0059] Step 104: Based on the target layout pattern, display the function cards corresponding to the target functional components on the vehicle human-machine interface.

[0060] Function cards are the visual representations of target functional components on the interface. The display process can specifically include: The UI rendering engine first creates a corresponding layout container on the screen based on the determined target layout pattern. For example, if the target layout pattern is a split-screen layout, the rendering engine will divide the screen into two areas, left and right.

[0061] Then, the rendering engine will instantiate the corresponding functional cards within the corresponding layout container based on the determined target functional components. For example, a navigation card will be instantiated in the left area, and a music card will be instantiated in the right area.

[0062] When instantiating a feature card, the rendering engine uses the obtained user intent attribute information to populate the card's content. For example, it might populate the title bar of a navigation card with the destination "Central Park".

[0063] In this embodiment, by acquiring intent recognition results containing the number and attribute information of user intents, the system can deeply understand the entire composition and details of a user's complete request from a data perspective. Then, by analyzing these data characteristics (especially the number and attribute information of intents), the system dynamically determines the target layout pattern of the interface. This breaks through the limitations of existing technologies that rely on static, preset templates, allowing the interface layout to be flexibly adjusted according to real-time changes in user intents. Finally, the determined functional components are displayed in this dynamically generated layout, enabling the simultaneous presentation of multiple related task information to the user on a unified and logically clear interface. The entire process achieves end-to-end dynamic generation from intent to interface. Compared to existing technologies that can only switch between single cards within a fixed template, this solution can more efficiently and intuitively display the processing of complex intents, significantly improving the information presentation efficiency and user experience of in-vehicle human-machine interaction.

[0064] In some embodiments, such as Figure 2 As shown, the target functional components to be used are determined based on the user intent and the corresponding intent type, including: Step 201: Based on the intent type corresponding to the user intent, filter out the main functional components with the same intent type from the atomic component library.

[0065] The atomic component library is a collection of components pre-built and stored in the vehicle system or cloud. It contains multiple minimal, reusable basic interface units (i.e., atomic components). These atomic components are designed to perform only a single functional responsibility, with independent rendering logic and data binding interfaces, thereby breaking down the barriers of strong coupling and difficulty in decomposing interface components in traditional vehicle systems.

[0066] The main functional component refers to the atomic component that undertakes the core information display and main business operations in a specific service area.

[0067] Specifically, the system parsing module extracts the intent type corresponding to the user's intent (for example, the intent type is represented by a "service" field indicating a service category in the data structure). Then, using this intent type as an index, it performs a matching query in the atomic component library to select the main functional component pre-defined to handle that intent type. For instance, if the parsed intent type is "navigation," the system will select the corresponding "NavCard" as the main functional component; if the intent type is "food," it will select "OrderCard" as the main functional component.

[0068] Step 202: Based on user intent, determine the variants of the main functional components and the required auxiliary components.

[0069] After defining the general direction of the main functional components, the system needs to refine its structure based on specific sub-intentions. The same main functional component will have different presentation formats and required interactive elements when facing different specific operation requests.

[0070] Variants refer to specific form branches of the main functional component in terms of layout structure or visual style.

[0071] Auxiliary components refer to atomic components that are attached to the main functional components and are used to provide fine-grained information display or specific interaction triggers, such as Button (for interaction triggers), Slider (for numerical adjustment), InfoLabel (for read-only information display), etc.

[0072] In this step, the system further extracts the specific operation instruction data of the user's intent (e.g., the intent field representing the specific action in the data structure). By querying the preset intent refinement mapping rules, the system can determine what variant the main functional component needs to present for the current specific operation, and what types and how many auxiliary components need to be attached. For example, when the specific operation of the user's intent is navigate_to (navigate to a certain place), the system determines the basic variant of the navigation card needed according to the rules, and calculates that two InfoLabel auxiliary components need to be extracted (to display the destination and estimated arrival time respectively) and three Button auxiliary components (to start, cancel, and route preference settings respectively).

[0073] Step 203: Construct the target functional component based on the variants corresponding to the main functional component and the required auxiliary components.

[0074] In this process, the identified main functional component variants are logically combined with the corresponding number and types of auxiliary components at the data level. This combination does not directly generate an image, but rather generates a structured data package (such as a JSON Schema description file) that describes the component's hierarchical structure and includes the identifiers and relationships of each atomic component. This data package, obtained through atomic assembly, constitutes the final output target functional component, which will be passed to subsequent layout orchestration and rendering for the actual interface drawing.

[0075] In this embodiment, the main functional components are selected from the atomic component library by extracting intent types. Then, based on specific intents, the required variants and auxiliary components are further deconstructed. Finally, at runtime, these fine-grained data units are dynamically assembled into the target functional components. This data processing mechanism, based on intent data for atomic decomposition and dynamic assembly, completely decouples the in-vehicle user interface from the underlying business logic. It greatly improves the reusability of component code, eliminating the need for a massive update of the entire vehicle's interface package when adding new vehicle interaction scenarios. Instead, a new component assembly configuration file can be distributed from the cloud, enabling rapid iteration within hours and significantly reducing development and maintenance costs.

[0076] For example, the input to the step of determining the target functional component to be used based on the user intent and the intent type corresponding to the user intent is: A structured list of intents (service and intent fields) plus scene_state and user_habits from context_info; The process of determining the target functional component to be used based on the user intent and the corresponding intent type is as follows: Based on the intent-component mapping rule table, component selection is completed through the following steps: (1) Service type matching: Based on the service field of the intent, find the main component of the corresponding service in the atomic component library (e.g., navigation→NavCard). (2) Intent type refinement: Based on the intent field, determine the specific variant of the main component and the required auxiliary components (such as navigate_to→NavCard+InfoLabel×2+Button×3). (3) Scene adaptation filtering: Combine scene_state to filter out components that are not applicable to the current scene (filter high interaction complexity components such as inline editing of ItemList while driving). (4) Personalized habits: Combine user_habits to adjust the default parameters of the component (e.g., user_habits.preferred_coffee="brand" pre-populate the brand field of OrderCard). The output of the step of determining the target functional components to be used based on the user intent and the intent type corresponding to the user intent is: a list of components corresponding to each intent (including the main component type, the type and quantity of auxiliary components, the space requirement score, and the component initialization parameters).

[0077] For example, the atomic component library definition is represented as follows: NavCard: Main component, displays destination / route / estimated time | Subsidiary components: InfoLabel×2 + Button×3 | Spatial weight: 10; OrderCard: Main component, order list | Subcomponents: ItemList + Button×2 | Weight: 8; ServiceCard: Main component, providing life services such as parking / charging stations | Subsidiary: InfoLabel×2 + Button×2 | Spatial weight: 6; ConfirmCard: Main component, secondary confirmation for high-risk operations | Subsidiary: InfoLabel×2 + Button×2 | Spatial weight: 4; MediaCard: Main component, music / video control | Subcomponents: Slider×2 + Button×4 | Spatial weight: 6; ClimateCard (Air Conditioning Card): Main component, temperature / mode control | Auxiliary: Slider×2 + Toggle×4 | Spatial weight: 5; Button: An atomic component, an interaction trigger, which automatically binds the button text to a voice command; Slider: An atomic component for numerical adjustment, supporting voice commands for absolute and relative values; Toggle (switch): An atomic component used to toggle the function on / off. InfoLabel: An atomic component that displays read-only information.

[0078] In some embodiments, the intent recognition result may also include scene state information, such as... Figure 3 As shown, based on the intent type corresponding to the user intent, the main functional components with the same intent type are selected from the atomic component library, including: Step 301: Based on the intent type corresponding to the user intent, filter out the candidate functional components with the same intent type from the atomic component library.

[0079] Specifically, all functional components that match the current user's intent type are identified, forming a set of candidate functional components. One intent type may correspond to multiple functional components. These components are similar in function, but may differ in their presentation and interaction complexity to adapt to different use cases.

[0080] For example, for a user intent involving navigation, the system might filter out several candidate functional components from the atomic component library. These could be: a full-featured navigation component with complex functions such as route planning, map interaction, and nearby search; and a simplified navigation component that only displays turn arrows, distances, and road names in large font. Both components belong to the navigation type and are therefore added to the set of candidate functional components.

[0081] Step 302: Use scene state information to filter out functional components that do not match the current scene from the candidate functional components, and obtain the main functional components.

[0082] After obtaining the set of candidate functional components, the system performs a filtering operation. Each functional component in the atomic component library, in addition to defining its function, can also have its applicable scenario label pre-configured. For example, a full-featured navigation component might be labeled as applicable only to stationary scenarios, while a simplified navigation component might be labeled as applicable to driving scenarios.

[0083] The filtering operation involves comparing the applicable scenario label of each component in the set of candidate functional components with the currently acquired scenario state information. If the applicable scenario of a candidate functional component does not match the actual scenario state of the current vehicle, that component will be removed from the set.

[0084] Continuing the example above: If the obtained vehicle speed information shows that the vehicle is traveling at 60 km / h, meaning the scenario is "moving," the system will find that the applicable scenario of the full-function navigation component ("stationary") does not match the current actual scenario during the filtering process, and therefore will filter it out. The simplified navigation component, however, is applicable in the "moving" scenario and will therefore be retained. After this round of filtering, the components remaining in the set are the main functional components most suitable for the current scenario.

[0085] In this embodiment, the determination of the main functional components is based not only on the intent type at the functional level but also on real-time scene status information from the vehicle's internal and external environment. By adding this filtering step, the system can proactively and intelligently eliminate functional components that are inapplicable in the current scenario or may pose safety hazards (such as providing a complex list selection component when driving at high speeds). This ensures that the final main functional components selected are the optimal choices after dual verification of function and scenario. This data processing flow ensures that the interface elements presented to the user are always highly relevant to the current driving context, thereby greatly improving the safety of the interaction and the fit of the experience while ensuring functional implementation.

[0086] The scene status information includes one or more of the following: time information, vehicle location information, vehicle speed information, and weather information.

[0087] In some embodiments, time information can be obtained by reading the system clock of the vehicle system to determine whether it is daytime, nighttime, or a specific period such as morning or evening rush hour.

[0088] In some embodiments, vehicle location information can be obtained through an onboard GPS module, which can not only provide latitude and longitude, but also, in combination with map data, determine the type of area where the vehicle is currently located, such as highways, urban roads, parking lots, etc.

[0089] In some embodiments, vehicle speed information can be obtained by reading the vehicle speed signal on the vehicle controller local area network bus, thereby accurately determining whether the vehicle is in a driving state (e.g., vehicle speed greater than 0 km / h) or a parked state.

[0090] In some embodiments, weather information can be obtained by calling the vehicle-to-everything (V2X) weather service application interface to determine whether the current weather is sunny, rainy, snowy, or foggy.

[0091] In some embodiments, the intent recognition result also includes user historical preference information. After constructing the target functional component based on the variants corresponding to the main functional component and the required auxiliary components, the display method of the in-vehicle human-machine interface further includes: Update the default configuration parameters of the target functional components based on the user's historical preference information.

[0092] Specifically, user historical preference information refers to personalized user data formed by the system through long-term recording and learning of user behavior patterns during interactions with the in-vehicle system. This information can be stored in the user profile database locally within the in-vehicle system or synchronized via the cloud. When the intent recognition model parses a user's input request, it simultaneously reads preference information related to the current user's intent from this database and encapsulates it in the intent recognition result. For example, user historical preference information can record a user's frequently used navigation destinations, preferred coffee brands, and habitually set air conditioning temperatures. Its data structure can be a series of key-value pairs.

[0093] It should be noted that all actions involving the acquisition of signal information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0094] Default configuration parameters refer to the initial values ​​of each configurable field within a target functional component after it has been built. For example, in an order functional component, the default configuration parameter for the brand field might be empty or a system-recommended value.

[0095] The specific update process is as follows: The system iterates through each item in the user's historical preference information. For each preference data item, the system checks whether a corresponding default configuration parameter exists in the currently built target functional component. If it exists, the system uses the value of the preference data to overwrite or populate the parameter.

[0096] In this embodiment, by adding a step after constructing the target functional component to update its default configuration parameters based on user historical preference information, the personalization and intelligence of the interface are achieved. A new data dimension, user historical preference, is introduced and applied to the data model level of the functional component. After the structure of the target functional component is determined, the initial parameters of the component are proactively and personally pre-populated using this historical preference data. This results in a user interface that is no longer generic and requires starting from scratch, but rather pre-configured based on past habits and is more user-friendly. This effectively predicts the user's next action, reduces the number of user interaction steps (such as eliminating the step of selecting a brand), and thus significantly simplifies the user's operation process without changing the core layout logic, improving the efficiency and user-friendliness of human-computer interaction.

[0097] In some embodiments, the attribute information includes the user intent dependency and the user intent priority level.

[0098] In this context, user intent dependencies characterize whether there is a sequential relationship between multiple user intents. For example, in a user request to "Plan my weekend trip to Hangzhou and book a highly-rated Sichuan restaurant after I arrive," the execution of the user intent "book a Sichuan restaurant" depends on the completion of the user intent "complete trip planning," thus creating a dependency relationship. Structurally, this relationship can be linked through intent identity codes. For instance, the "book a Sichuan restaurant" intent might have a `depends_on` field whose value points to the identity code of the "trip planning" intent. If no such prerequisite relationship exists, the dependency can be marked as no dependency.

[0099] User intent priority levels are used to characterize the importance or urgency of each intent when multiple user intents coexist. This level can be a numerical value, such as an integer from 0 to 10, with smaller values ​​indicating higher priority. Priority determination can consider various factors, such as the order in which the user expresses the intent in speech or text (usually, the intent spoken first is more important), the nature of the task itself (e.g., navigation intents related to driving safety have higher priority), or the user's historical preferences.

[0100] like Figure 4 As shown, the target layout pattern is determined based on the number of user intents and the attribute information of those intents, including: Step 401: Determine the preset application scenario corresponding to the current application scenario based on at least one of the user intent dependency relationship and the user intent priority level, along with the number of user intents.

[0101] Specifically, after obtaining the intent recognition results, three key dimensions of data are extracted: the number of user intents (one or multiple), the dependencies between user intents (dependent or non-dependent), and the priority level of user intents (priority values ​​of each intent). Then, the system matches the combination of these three dimensions with a preset application scenario according to a set of internally defined classification rules.

[0102] In some embodiments, the preset application scenario can be defined as a single-task execution scenario, a multi-task parallel processing scenario, a multi-task primary and secondary processing scenario, a multi-task serial processing scenario, etc.

[0103] Among them, the multi-task serial processing scenario can be divided into the first multi-task serial processing scenario and the second multi-task serial processing scenario according to the triggering type.

[0104] Step 402: Select the target layout mode from the preset layout modes based on the preset application scenario corresponding to the current application scenario.

[0105] Specifically, a mapping table is maintained between preset application scenarios and preset layout modes, and then the target layout mode is selected based on the mapping table.

[0106] For example, this mapping relationship can be pre-configured as follows: Single-task execution scenario -> Map to -> Full-screen mode; Multi-task parallel processing scenario -> Map to -> Horizontal split-screen mode; Multi-task primary and secondary processing scenario -> Map to -> Vertical split-screen mode or picture-in-picture mode; Multi-task serial processing scenario -> Mapping to -> Task flow mode.

[0107] In this embodiment, by explicitly requiring attribute information to include dependencies and priority levels, richer and more structured data input is provided for subsequent layout decisions. Introducing a pre-defined application scenario as an intermediate abstraction layer allows the system to first summarize and understand the inherent logical structure of user requests, and then match the most suitable interface organization based on this understanding. This avoids the logical confusion that may result from directly handling complex feature combinations, making the layout decision-making process more robust, modular, and easily extensible. Ultimately, it ensures that the selected target layout pattern accurately and logically reflects the inherent structure of the user's multi-task requests, thereby significantly improving the information organization efficiency of the interface and the user's cognitive efficiency.

[0108] In some embodiments, a preset application scenario corresponding to the current application scenario is determined based on at least one of the dependency relationship of user intents and the priority level of user intents, along with the number of user intents, including: If there is only one user intent and no dependency, the current application scenario is determined to be a single-task execution scenario. If there are multiple user intents, no dependencies, and priority levels differ by a factor greater than or equal to a preset level, the current application scenario is determined to be a multi-task parallel processing scenario. If there are multiple user intents, no dependencies, and the priority levels differ by less than a preset level, the current application scenario is determined to be a multi-task primary and secondary processing scenario. If there are multiple user intents, the dependencies are defined as dependent, and the trigger type of the dependencies is user-triggered, then the current application scenario is determined to be the first multi-task serial processing scenario. Given that there are multiple user intents, dependencies exist, and the triggering type of the dependencies is automatic, the current application scenario is determined to be the second multi-task serial processing scenario.

[0109] In this embodiment, a mapping mechanism from complex intents to standardized scenarios is established by performing precise, multi-dimensional logical judgments on structured data such as the number of user intents, dependencies, and priority levels in the intent recognition results. This mechanism categorizes infinitely diverse user input requests into five finite, enumerable, preset application scenarios through a set of clear rules. This classification process is equivalent to a crucial preprocessing and feature extraction of the raw data, transforming complex data structures that were originally difficult to use directly for layout decisions into simple and clear scenario classification labels. This standardized intermediate result provides a stable and reliable input for subsequent layout pattern selection steps, greatly simplifying the decision-making logic and ensuring that the final generated interface layout accurately reflects the internal structure and logic of the user's multi-task requests, thus laying a solid data processing foundation for achieving highly contextualized and intelligent interface generation.

[0110] For example, the input for determining the preset application scenario corresponding to the current application scenario based on at least one of the user intent dependency relationship and the user intent priority level, along with the number of user intents, is: intent list (quantity / depends_on / priority fields) + component list (space requirement score) + context_info (weather / time / vehicle speed / user_habits).

[0111] The process of determining the preset application scenario corresponding to the current application scenario based on at least one of the following factors—user intent dependency and user intent priority level, and the number of user intents—determines the layout pattern through the following decision-making process (rule engine + habit learning hybrid algorithm): Level 1 Decision: Determining the Quantity of Intent If the number of intents is 1 and depends_on is null, proceed to [Scenario 1: Single Task Execution Scenario]. If the number of intents is ≥2, proceed to the multi-intent branch and continue to determine dependencies; Second-level decision: Dependency judgment (for multiple intentions): If all intents have null depend_on, proceed to the no-dependency branch and continue to assess priority differences. If at least one intent's depend_on is not null, proceed to the dependent branch and determine the trigger type. Level 3 Decision Making: Priority Differences (for Undependent Multiple Intents): Calculate delta_priority = highest priority value - second highest priority value; If delta_priority≥2 → proceed to 【Scenario 2: Multi-task primary and secondary processing scenario; If delta_priority < 2, proceed to [Scenario 3: Multi-task parallel processing scenario]; Level 3 Decision: Trigger Type (for multi-intention dependencies): If the trigger type is USER_TRIGGER, proceed to [Scenario 4: First Multi-task Serial Processing Scenario - User Trigger]; If the trigger type is AUTO_TRIGGER, proceed to [Scenario 5: Second Multi-task Serial Processing Scenario (Automatic Trigger)].

[0112] The input for determining the preset application scenario corresponding to the current application scenario is: the preset application scenario corresponding to the current application scenario, based on at least one of the user intent dependency relationship and the user intent priority level, and the number of user intents.

[0113] Specifically, for single-task execution scenarios, full-screen mode is adopted as the target layout mode.

[0114] The partitioning condition is: len(intents)=1, and intents[0].depends_on=null.

[0115] Typical examples include setting the air conditioner temperature to 24 degrees Celsius or playing a song by a certain singer.

[0116] The selected target layout mode is LayoutMode=FULLSCREEN (100% screen space), which is full-screen mode.

[0117] Specifically, the judgment steps are as follows: 1: Detect that the length of the intent list len(intents) = 1, and confirm that depends_on = null; 2. Read scene_state and vehicle_speed. If driving (vehicle_speed>0), enable driving safety mode (enlarge critical information, collapse non-critical operations); 3: Read time_period. If it is nighttime (22:00-06:00), enable nighttime style (dark background, larger font size); 4: Read user_habits.layout_history to confirm the full-screen mode acceptance rate. If it is less than 50%, a "Expand display?" prompt will appear. 5: Output LayoutMode=FULLSCREEN, main component occupancy=100%.

[0118] Specifically, for multi-task primary and secondary processing scenarios, vertical split-screen mode or picture-in-picture mode is adopted as the target layout mode.

[0119] The partitioning criteria are: len(intents)≥2, all depends_on=null, delta_priority≥2.

[0120] A typical example is navigating to a destination while simultaneously opening the car window (navigation priority = 0, window opening priority = 3).

[0121] The selected target layout mode is LayoutMode=VERTICAL_SPLIT (60% main idea at the top / 40% secondary idea at the bottom).

[0122] Specifically, the judgment steps are as follows: 1: Confirm that all intents have depend_on=null, extract the priority value of each intent, sort them and calculate delta_priority; 2: Confirm delta_priority≥2, then proceed to the main branch and secondary branch; main intention = highest priority, secondary intention = other intentions; 3: Read vehicle_speed. If the vehicle is in motion, further compress the auxiliary intention area (auxiliary area height ≤ 20%). 4. Read user_habits.layout_history. If the user's historical preference for split-screen layout has an acceptance rate of >70%, switch to HORIZONTAL_SPLIT (60% left / 40% right). 5: Calculate the space requirements of each intent component list. If the space requirement of the auxiliary intent is less than 10% of the main intent graph, switch to PICTURE_IN_PICTURE (picture-in-picture). 6: Output LayoutMode, where the primary and secondary intent spaces are displayed according to the allocation ratio.

[0123] Specifically, for multi-task parallel processing scenarios, a horizontal split-screen mode is adopted as the target layout mode.

[0124] The partitioning criteria are: len(intents)≥2, all depends_on=null, delta_priority<2.

[0125] A typical example is navigating to a destination and asking me to order a coffee (navigation priority=0, ordering priority=1).

[0126] The selected target layout mode is LayoutMode=HORIZONTAL_SPLIT (70% left / 30% right) or PICTURE_IN_PICTURE (when the secondary intent requirement is extremely small).

[0127] Specifically, the judgment steps are as follows: 1: Confirm that all depends_on=null, calculate delta_priority<2, and enter the parallel branch; 2: Evaluate the space requirement score (sum(component space weight)) of the component list corresponding to each intent, and calculate space_ratio=max_need / min_need; 3: If space_ratio > 3 (the requirement for a certain intention is much lower than others), select PICTURE_IN_PICTURE (90% for the main image and 10% for the floating window); 4: If space_ratio≤3 (relatively equal demand), dynamically allocate HORIZONTAL_SPLIT according to the space weight ratio of each intent (e.g., if the weight is 10:4, then allocate 70%:30%). 5: If the number of intents > 2 (multiple parallel operations), screen space is allocated in descending order of priority. Intents exceeding the capacity are placed in a waiting queue and displayed with minimized indices. 6: Combine time_period and user_habits to dynamically adjust the default parameters of the component (e.g., ordering "brand coffee" for frequently ordered brands at 8:30 am or more). 7: Output LayoutMode. Each intent area is displayed proportionally.

[0128] Specifically, for multi-task serial processing scenarios, namely the first multi-task serial processing scenario, the task flow mode is adopted as the target layout mode.

[0129] The criteria for determining the partition are: there exists an intent whose depend_on is not null, and the trigger_type of the dependency is USER_TRIGGER.

[0130] A typical example is navigating me to the high-speed rail station and reminding me to buy a ticket after I arrive (the ticket purchase is only triggered after the user manually confirms upon arrival).

[0131] The selected target layout mode is LayoutMode=VERTICAL_TASK_FLOW, and the subsequent task is in a pending confirmation state, waiting for user operation to activate it.

[0132] Specifically, the judgment steps are as follows: 1: If a non-null value for depend_on is detected, confirm that trigger_type=USER_TRIGGER; 2: Construct a task dependency graph: use intent identity encoding as nodes and depend_on relationships as directed edges; 3: Perform topological sorting on the task dependency graph to obtain the execution sequence of the intent (nodes with in-degree = 0 are the first batch of activated nodes). 4: The first batch of activated nodes displays a complete function card (highlighted); subsequent dependent nodes display a pending confirmation status card (gray dashed border + lock icon). 5: When the first batch of nodes completes execution, the system displays a ConfirmCard asking the user whether to execute [subsequent task name], and prompts the current scenario (e.g., you have arrived near the high-speed rail station). 6: After user confirmation, subsequent intentions will be activated, and the function card will be updated to the fully interactive state; if the user refuses, subsequent tasks will be marked as skipped. 7: Combine context_info (GPS location, estimated arrival time) to prompt the user in advance (e.g., 500m in advance) whether they are ready to trigger subsequent tasks; 8: Output LayoutMode=VERTICAL_TASK_FLOW, the task dependency graph structure, and the initial state of each node.

[0133] Specifically, for multi-task serial processing scenarios, namely the second multi-task serial processing scenario, the task flow pattern is adopted as the target layout pattern.

[0134] The criteria for determining the partition are: there exists an intent whose depend_on is not null, and the trigger_type of the dependency is AUTO_TRIGGER.

[0135] A typical example is helping me plan my weekend trip to Hangzhou, and then booking a highly-rated Sichuan restaurant after I arrive (the restaurant booking is automatically triggered after the trip planning is completed).

[0136] The selected target layout mode is LayoutMode=VERTICAL_TASK_FLOW. After the preceding tasks are completed, the system will automatically activate the subsequent tasks.

[0137] Specifically, the judgment steps are as follows: 1: If a non-null `depends_on` value for an intent is detected, confirm that `trigger_type=AUTO_TRIGGER`. 2: Construct a task dependency graph, perform topological sorting, and determine the first batch of activated nodes (all nodes with in-degree = 0). 3: The first batch of activated nodes immediately displays the complete function card, and the status is set to "Executing" (blue dynamic icon). 4: Register a status listener in the task execution engine: When the status of a node changes to SUCCESS, automatically activate all subsequent nodes that depend on that node; 5: When a subsequent node is activated, its function card transitions from waiting (gray) to executing (blue dynamic icon), while relevant parameters are pre-populated using user_habits; 6: If the preceding node fails to execute (FAILED), all subsequent nodes that depend on it will be automatically updated to "cancelled" (orange), and an InfoCard will pop up to show the error reason and processing options (retry / skip / cancel all). 7: After all nodes have completed execution (all node statuses are SUCCESS / CANCELLED), a task completion summary card will be displayed and automatically collapsed after 3 seconds; 8: Output LayoutMode=VERTICAL_TASK_FLOW, task dependency graph, initial state of each node (first batch activated, subsequent nodes awaiting activation).

[0138] In some embodiments, such as Figure 5 As shown, selecting the target layout mode from the preset layout modes based on the current application scenario also includes: Step 501: Obtain constraints, including scene state constraints and / or user preference constraints. Scene state constraints are used to constrain at least one of the following: the number of split screens in the vehicle human-machine interface, the display parameters of the vehicle human-machine interface, the priority level of functional components, and the display parameters of functional components.

[0139] Among them, constraints can be understood as a set of rules or parameters that affect the final appearance of the interface, which comes from the perception of the vehicle's real-time status and the user's historical behavior.

[0140] Specifically, the scene state constraints are generated based on the vehicle's current state and the environmental information of its current location.

[0141] In some embodiments, vehicle speed information, gear information, and remaining driving range are read via the vehicle bus; vehicle location information is obtained via a positioning device; time information is obtained via an onboard clock or network time service (e.g., to determine whether it is day or night); and weather information is obtained via a network or onboard sensors.

[0142] After obtaining the vehicle's current state and the environmental information of its current location, the information is analyzed to generate scene state constraints.

[0143] In some embodiments, scene state constraints include one or more of the following: When the vehicle speed exceeds a preset threshold (e.g., 80 km / h), a constraint is generated to limit the number of screens in the in-vehicle human-machine interface. This constraint may require that the interface can only be displayed on a single screen at most, in order to reduce driver distraction.

[0144] When the time information is nighttime, a constraint will be generated to constrain the display parameters of the in-vehicle human-machine interface, requiring the interface to adopt a dark theme.

[0145] When the remaining driving range is lower than a preset threshold, a constraint will be generated to control the priority level of functional components, raising the display priority of any functional components related to charging or refueling to the highest level.

[0146] When the weather information is heavy rain or heavy fog, a constraint is generated to restrict the display parameters of the functional components, requiring the map and text of the navigation components to be displayed in a larger font size.

[0147] For example, the number of split screens for the vehicle human-machine interface is constrained as follows: driving state (vehicle_speed>0): limit the maximum number of split screens to ≤2; force large font components; and / or display in full-screen mode or picture-in-picture mode.

[0148] For example, the number of split screens for the vehicle human-machine interface is constrained as follows: in parked state (vehicle_speed=0): the maximum number of split screens is allowed to be ≤4; and full multitasking flow is supported.

[0149] For example, the constraints used to constrain the display parameters of the vehicle-mounted human-machine interface are as follows: during nighttime hours (22:00-06:00): automatically reduce screen brightness; increase font size by 20%; simplify the interface (hide secondary information).

[0150] For example, the constraints used to limit the display parameters of functional components are as follows: severe weather (rain / snow / fog): increase the priority of navigation components; limit the display ratio of entertainment components.

[0151] User preference constraints are formed based on learning from users' historical settings or long-term usage habits. For example, by analyzing users' historical interaction data, the system can discover that when using the split-screen function, users place the navigation card on the left side 80% of the time, with the split-screen ratio set to 7:3. Based on this, the system can generate a user preference constraint that includes parameters such as the left-side component type being navigation and the split-screen ratio being 7:3.

[0152] For example, user_habits.layout_history (the last 30 user layout operation records) is read to determine user preference constraints.

[0153] Specifically, when multiple layout schemes have similar rule scores (difference < 0.1), the layout with higher historical acceptance rate is given priority.

[0154] In some embodiments, a user behavior record database is periodically maintained, and user habits are learned and applied to the personalized adjustments of the in-vehicle human-machine interface through the following mechanisms.

[0155] 1. Behavior Recording: Records user behavior in different scenarios (time_period + area_type + intent_combination) regarding layout modes (accepting the original layout / actively adjusting / closing), and updates user preference scores for each layout mode.

[0156] 2. Personalized parameters: Record frequently used component parameters (frequently used navigation destinations, frequently ordered coffee brands, frequently used temperatures) as user historical preference information.

[0157] 3. Scene association model: Establish a mapping of time period + region type + intent combination → layout mode preference, and use a sequence model (the last 30 records of the sliding window) to dynamically update the preference weights to determine user preference constraints.

[0158] In some embodiments, for new users, the user preference constraint adopts the default preference constraint, and the user preference constraint is generated when the cumulative number of times the in-vehicle human-machine interaction interface is generated based on user intent is greater than 10.

[0159] Step 502: Adjust the page layout parameters in the target layout mode based on constraints; or adjust and switch the target layout mode based on constraints.

[0160] For example, suppose a user's intention is to navigate to their office and play music. When the system determines that the application falls under a third preset scenario, it selects the default 5:5 split-screen layout as the target layout. At this point, the system obtains a user preference constraint, which records the user's habit of placing the navigation on the left side in a 7:3 aspect ratio. Based on this constraint, the system adjusts the page layout parameters of the target layout, ultimately changing the application's layout to a 7:3 split-screen mode, placing the navigation component in the left 70% of the screen area.

[0161] For example, if a user intends to navigate to their workplace and play music, the system initially selects a split-screen mode. However, at this point, the system receives a scene state constraint triggered by a vehicle speed exceeding 100 km / h, requiring the interface to be in single-screen focus mode. In this situation, the system will directly switch the target layout mode based on this constraint, discarding the original split-screen mode and adopting a full-screen mode, displaying only the most important navigation function cards on the screen according to priority.

[0162] In this embodiment, a constraint processing step is introduced. By acquiring scene state constraints from the vehicle's real-time status and user preference constraints from the user's historical habits, the system can perform secondary verification and optimization after initially selecting the layout pattern. Using this constraint data, the page parameters of the layout pattern are adjusted, or the layout pattern itself is switched when necessary. This ensures that the final interface generation decision no longer relies solely on the user's instantaneous input intent, but comprehensively considers the dynamically changing driving environment and the user's personalized preferences. This method integrates intent data, scene data, and user data for interface layout decisions, greatly improving the interface's contextual adaptability and security, providing users with a more intelligent, considerate, and safe interactive experience.

[0163] In some embodiments, after displaying the function card corresponding to the target functional component on the in-vehicle human-machine interface based on the target layout pattern, the display method of the in-vehicle human-machine interface further includes: The execution status of the target task is displayed based on the function cards corresponding to the target functional components; The target task is the task performed by the target functional component.

[0164] In this step, the execution progress of the backend tasks is fed back to the user in real time and visually, establishing a closed-loop information flow from task execution to interface presentation.

[0165] The target task refers to the specific task performed by the target functional component identified in the preceding steps. For example, the navigation component performs the route planning and navigation task, or the media component performs the music search and playback task.

[0166] Specifically, when the target functional component executes its corresponding target task in the backend, it interacts with related business services (such as navigation engines and music services). When the state of a business service changes, the target functional component captures these state change events and encapsulates them into state data in a unified format. Subsequently, this state data is pushed to the front-end human-computer interaction interface. After receiving the state data, the human-computer interaction interface parses out the state content and the identifier of the target functional component to which the state belongs. Then, it finds the functional card corresponding to the identifier on the interface and updates and displays the latest execution status text or visual effect in a preset area of ​​the card (e.g., the card's subtitle position, the bottom status bar, or through a dynamic icon). This update is real-time or near real-time, ensuring that what the user sees is what the system does.

[0167] For example, in a scenario involving both navigation and music playback, the interface will display navigation cards and music cards simultaneously. When the backend navigation engine is calculating the route, the navigation component will send a "Route planning..." status to the frontend, displayed on the navigation card; at the same time, if the music has started playing, the music component will send a "Now playing:..." status to the frontend, displayed on the music card.

[0168] In this embodiment, task execution status data is introduced. While executing tasks, the backend target functional components continuously generate and output status data reflecting task progress. The frontend functional cards are designed to receive and respond to this status data, dynamically updating their displayed content. This real-time status data flow from the backend task to the frontend card transforms the previously static functional card into a dynamic information window that provides real-time feedback on task progress. This resolves the anxiety and uncertainty users experience when issuing complex commands due to the lack of awareness of the backend processing. By providing transparent and real-time process feedback, it significantly improves the user-friendliness of the interaction and the credibility of the system, thereby optimizing the overall user experience.

[0169] In some embodiments, the execution status is represented by an execution status icon, specifically: Pending: Gray clock icon, the task has not yet started; Running: A blue, dynamically rotating icon indicates that the task is in progress. Successful execution: A green checkmark icon indicates the task is complete; Execution failed: A red cross icon indicates a task error, and a retry option is provided; Cancelled: An orange exclamation mark icon indicates that the previous task failed, causing this task to be cancelled; WaitingUser: Gray lock icon + text "Please confirm", waiting for user to actively trigger (USER_TRIGGER scenario).

[0170] In some embodiments, in task flow mode, dependencies between task cards are displayed via connecting lines. Completed node connections are solid green lines; waiting node connections are dashed gray lines; failed node connections are red lines.

[0171] In some embodiments, the representation of negative operation processing includes: Task failure: Display a red failure icon + InfoCard (error message + retry / cancel button); Pre-processing failure propagation: The pre-processor displays a red failure icon, and the subsequent automatic update is changed to orange (indicated as canceled), with an InfoCard popping up to explain the reason; User cancellation midway: High-risk tasks (payment, automatic parking) will prompt a ConfirmCard for secondary confirmation; low-risk tasks will be cancelled directly. Timeout: Warning icon + InfoCard (Continue waiting / Cancel task options) will be displayed.

[0172] In some embodiments, such as Figure 6 As shown, based on the target layout pattern, after displaying the function cards corresponding to the target functional components on the in-vehicle human-machine interface, the display method of the in-vehicle human-machine interface also includes: Step 601: In response to the user's voice input, display at least one voice interaction label determined based on the voice input on the in-vehicle human-machine interface.

[0173] In this embodiment, after the in-vehicle human-machine interface has generated and displayed multiple function cards (e.g., a navigation card and a music card) based on the user's initial intent, the user may wish to fine-tune or control one of the ongoing tasks. At this point, the user can issue a subsequent voice input.

[0174] The voice input can be a specific command, such as zooming in on a map; or it can be a command that may be ambiguous in the current multitasking context, such as switching modes.

[0175] After receiving the voice input, the system performs semantic understanding. Unlike directly executing instructions, the core of this step is that the system converts one or more executable operations into visual voice interaction labels and displays them on the interface.

[0176] Voice interaction labels are temporary, interactive interface elements, such as a button with text descriptions or a highlighted checkbox. They visualize the results of abstract voice command parsing, providing users with a clear visual confirmation and selection process.

[0177] For example, suppose the current interface has navigation cards on the left and music cards on the right. The user issues a voice command to switch modes. This command is ambiguous because it can be interpreted as switching the display mode of the navigation map (e.g., 2D / 3D / satellite mode) or switching the playback mode of the music (e.g., sequential / shuffle playback).

[0178] At this point, this method will not rashly execute any operation, but will instead: On or near the navigation card, display one or more voice interaction labels, such as labels for switching to satellite view or switching to 3D mode.

[0179] Display a voice-interactive label on or near the music card, such as a label that says "Switch to shuffle".

[0180] In this way, the system presents its understanding to the user in a visual way, returning the choice to the user.

[0181] Step 602: In response to the user's input on the target voice interaction tag, execute the control command corresponding to the target voice interaction tag.

[0182] Once the aforementioned voice interaction labels are displayed on the interface, the system will wait for the user's input to determine the final intent.

[0183] User input can take many forms. For example, on a touchscreen-enabled device, a user can directly tap the desired voice interaction label, which then becomes the target voice interaction label. Alternatively, if the label is numbered (e.g., "1. Switch to satellite view", "2. Switch to shuffle"), the user can specify the target using subsequent voice commands (e.g., "Select first" or "Execute one").

[0184] Once the system receives user input for a specific voice interaction tag, it executes the control command associated with that tag. For example, when a user clicks the "Switch to Satellite View" tag on a navigation card, the system sends a command to the navigation function component to switch map modes, thus completing the user's precise operation.

[0185] In this embodiment, instead of directly executing potentially ambiguous instructions when responding to subsequent user voice input, the system first generates visual voice interaction labels related to the current context (i.e., each function card), thus transparently presenting the system's intent understanding results to the user. This step transforms the ambiguity of voice interaction into a clear visual selection problem. Then, the final instruction is executed in response to the user's explicit actions on these labels (such as touch clicks), ensuring the accuracy of the operation. This approach essentially constructs a multimodal interaction closed loop combining voice and touch, effectively resolving the ambiguity of subsequent control instructions in complex multi-tasking scenarios. It avoids erroneous operations caused by voice misrecognition or misunderstanding, greatly improving the interaction efficiency and safety for users fine-tuning tasks in driving scenarios.

[0186] In some embodiments, voice interaction tags may be represented in the following form: Button component: Voice command = button text, example: Start navigation, confirm booking; Slider component (absolute value): Voice format = adjust [tag name] to [value], example: adjust the temperature to 24 degrees; Slider component (relative value): Voice format = increase / decrease [tag name], example: increase the volume slightly; Toggle component: Voice format = On / Off [Function Name], Example: Turn on the air conditioner, Close the car window; Card Title: Voice Command = Title Text, Example: Coffee, Trip Planning; List items: Supports voice prompts based on serial number (select the first one) and voice prompts based on name (select Sichuan style).

[0187] In some embodiments, if there is a command conflict in the voice input, it is handled according to the following strategy: Level 1: Prioritize matching the currently focused component (the component area last touched by the user); Level 2: Prioritize matching components closest to the center of the screen; Level 3: A selection prompt pops up, highlighting candidate components and displaying number labels, allowing the user to speak a number for confirmation.

[0188] The following examples illustrate multi-task parallel processing scenarios: User input: Navigate to Central Park, and while you're at it, please order me a coffee; Scene context: Time = 09:00 (morning rush hour), Weather = sunny, Vehicle speed = 0 (parked), Location = First City, First District; Output: Text input + context_info(time_period=morning_rush,weather=sunny,vehicle_speed=0); Output: intent_001(navigation, priority=0, no_dep) + intent_002(food, priority=1, no_dep), user_habits.preferred_coffee="brand"; Output: NavCard component package (space weight = 13) + OrderCard component package (space weight = 10, pre-filled with branded coffee). Decision: len=2, no dependency, delta_priority=1<2→parallel scenario; space_ratio=1.3≤3→HORIZONTAL_SPLIT; weight ratio 13:10→left 57%:right 43% (rounded to left 60%:right 40%); vehicle_speed=0 allows full interaction; Rendering: The NavCard on the left shows the destination, Central Park; the OrderCard on the right shows the coffee menu.

[0189] The following example illustrates the second multi-task serial processing scenario: User input: Help me plan my weekend trip to Hangzhou, and then book a highly-rated Sichuan restaurant when I arrive; Scene context: Time = 20:00 (night), Weather = sunny, Vehicle speed = 0; Output: intent_001 (planning, priority=0, no_dep) + intent_002 (restaurant, priority=1, depends_on=intent_001, trigger=AUTO); Decision: There is a dependency, trigger_type=AUTO_TRIGGER → Second multi-task serial processing scenario; Construct task dependency graph (intent_001→intent_002); Enable night mode (increase font size); Rendering: Vertical task flow - Node 1 (trip planning card, blue icon in progress) → Node 2 (restaurant reservation card, gray icon in progress); Execution process: After the trip planning is completed, the status changes to SUCCESS, the restaurant reservation is automatically activated, and the user_habits preference parameters for Sichuan cuisine / rating ≥4.5 are pre-populated.

[0190] The display device for the vehicle-mounted human-machine interface provided by the present invention will be described below. The display device for the vehicle-mounted human-machine interface described below and the display method for the vehicle-mounted human-machine interface described above can be referred to in correspondence with each other.

[0191] In some embodiments, such as Figure 7 As shown, a display device for an in-vehicle human-machine interface is provided, comprising the following modules: The acquisition module 701 is used to acquire the intent recognition result determined according to the input operation request. The intent recognition result includes at least one user intent and intent type and attribute information corresponding to each user intent. The first determining module 702 is used to determine the target functional component to be used based on the user intent and the intent type corresponding to the user intent. The second determining module 703 is used to determine the target layout pattern based on the number of user intents and the attribute information of the user intents; Display module 704 is used to display function cards corresponding to target functional components on the vehicle human-machine interface based on the target layout pattern.

[0192] Figure 8 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 8 As shown, the electronic device may include a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute a display method for the vehicle-mounted human-machine interface. This method includes: acquiring an intent recognition result determined based on an input operation request, the intent recognition result including at least one user intent and intent type and attribute information corresponding to each user intent; determining the target functional component to be used based on the user intent and the intent type corresponding to the user intent; determining a target layout pattern based on the number of user intents and the attribute information of the user intents; and displaying function cards corresponding to the target functional components on the vehicle-mounted human-machine interface based on the target layout pattern.

[0193] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0194] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the display method of the in-vehicle human-machine interface provided by the above methods. The method includes: acquiring an intent recognition result determined according to an input operation request, the intent recognition result including at least one user intent and intent type and attribute information corresponding to each user intent; determining the target functional component to be used according to the user intent and the intent type corresponding to the user intent; determining a target layout pattern according to the number of user intents and the attribute information of the user intents; and displaying a function card corresponding to the target functional component on the in-vehicle human-machine interface based on the target layout pattern.

[0195] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a method for displaying an in-vehicle human-machine interface provided by the methods described above. This method includes: acquiring an intent recognition result determined based on an input operation request, the intent recognition result including at least one user intent and intent type and attribute information corresponding to each user intent; determining a target functional component to be used based on the user intent and the intent type corresponding to the user intent; determining a target layout pattern based on the number of user intents and the attribute information of the user intents; and displaying a function card corresponding to the target functional component on the in-vehicle human-machine interface based on the target layout pattern.

[0196] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0197] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0198] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for displaying a vehicle-mounted human-machine interface, characterized in that, include: Obtain the intent recognition result determined based on the input operation request, wherein the intent recognition result includes at least one user intent and intent type and attribute information corresponding to each user intent; The target functional components to be used are determined based on the user intent and the intent type corresponding to the user intent. The target layout pattern is determined based on the number of user intents and the attribute information of the user intents; Based on the target layout pattern, function cards corresponding to the target functional components are displayed on the in-vehicle human-machine interface.

2. The display method of the vehicle-mounted human-machine interface according to claim 1, characterized in that, The step of determining the target functional component to be used based on the user intent and the intent type corresponding to the user intent includes: Based on the intent type corresponding to the user intent, select the main functional components with the same intent type from the atomic component library; Based on the user intent, determine the variants corresponding to the main functional component and the required auxiliary components; The target functional component is constructed based on the variants corresponding to the main functional component and the required auxiliary components.

3. The display method for the vehicle-mounted human-machine interface according to claim 2, characterized in that, The intent recognition result also includes scene state information. The step of filtering main functional components with the same intent type from the atomic component library based on the intent type corresponding to the user intent includes: Based on the intent type corresponding to the user intent, select candidate functional components with the same intent type from the atomic component library; The scene state information is used to filter out functional components that do not match the current scene from the candidate functional components, and the main functional components are obtained. The scene status information includes one or more of the following: time information, vehicle location information, vehicle speed information, and weather information.

4. The display method of the vehicle-mounted human-machine interface according to claim 2, characterized in that, The intent recognition result also includes user historical preference information. After constructing the target functional component based on the variants corresponding to the main functional component and the required auxiliary components, the display method of the in-vehicle human-machine interface further includes: Based on the user's historical preference information, update the default configuration parameters of the target functional component.

5. The display method of the vehicle-mounted human-machine interface according to claim 1, characterized in that, The attribute information includes the user intent's dependency relationships and the user intent's priority level; Determining the target layout pattern based on the number of user intents and the attribute information of the user intents includes: The preset application scenario corresponding to the current application scenario is determined based on at least one of the user intent dependency relationship and the user intent priority level, along with the number of user intents. Based on the preset application scenario corresponding to the current application scenario, select the target layout mode from the preset layout modes.

6. The display method of the vehicle-mounted human-machine interface according to claim 5, characterized in that, The step of determining the preset application scenario corresponding to the current application scenario based on at least one of the user intent dependency relationship and the user intent priority level, along with the number of user intents, includes: If the number of user intents is one and the dependency relationship is non-dependent, the current application scenario is determined to be a single-task execution scenario. If there are multiple user intents, the dependency relationship is independent, and the priority levels differ by a preset level, the current application scenario is determined to be a multi-task parallel processing scenario. If there are multiple user intents, the dependency relationship is non-dependent, and the priority levels differ by less than a preset level, the current application scenario is determined to be a multi-task primary and secondary processing scenario. If there are multiple user intents, the dependency relationship is dependent, and the triggering type of the dependency relationship is user-triggered, then the current application scenario is determined to be the first multi-task serial processing scenario. If there are multiple user intents, the dependency relationship is dependent, and the triggering type of the dependency relationship is automatic triggering, then the current application scenario is determined to be the second multi-task serial processing scenario.

7. The display method of the vehicle-mounted human-machine interface according to claim 5, characterized in that, The step of selecting a target layout mode from the preset layout modes based on the current application scenario also includes: Obtain constraints, including scene state constraints and / or user preference constraints. The scene state constraints are used to constrain at least one of the following: the number of split screens of the vehicle human-machine interface, the display parameters of the vehicle human-machine interface, the priority level of functional components, and the display parameters of functional components. Adjust the page layout parameters in the target layout mode based on the constraints; or adjust and switch the target layout mode based on the constraints.

8. The method for displaying a vehicle-mounted human-machine interface according to any one of claims 1 to 7, characterized in that, After displaying the function card corresponding to the target functional component on the in-vehicle human-machine interface based on the target layout pattern, the display method of the in-vehicle human-machine interface further includes: The execution status of the target task is displayed based on the function card corresponding to the target functional component; The target task is the task performed by the target functional component.

9. The display method of the vehicle-mounted human-machine interface according to claim 8, characterized in that, After displaying the function card corresponding to the target functional component on the in-vehicle human-machine interface based on the target layout pattern, the display method of the in-vehicle human-machine interface further includes: In response to the user's voice input, at least one voice interaction label determined based on the voice input is displayed on the in-vehicle human-machine interface; In response to the user's input on the target voice interaction tag, the control command corresponding to the target voice interaction tag is executed.

10. A display device for an in-vehicle human-machine interface, characterized in that, include: The acquisition module is used to acquire the intent recognition result determined based on the input operation request. The intent recognition result includes at least one user intent and intent type and attribute information corresponding to each user intent. The first determining module is used to determine the target functional component to be used based on the user intent and the intent type corresponding to the user intent; The second determining module is used to determine the target layout pattern based on the number of user intentions and the attribute information of the user intentions; The display module is used to display function cards corresponding to the target functional components on the in-vehicle human-machine interface based on the target layout pattern.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the display method of the vehicle-mounted human-machine interface as described in any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the display method of the vehicle-mounted human-machine interface as described in any one of claims 1 to 9.

Images