Cabin atomic component bridging method and vehicle

Abstract

The invention discloses a cabin atomic component bridging method and a vehicle, and the method comprises the steps: analyzing declarative description data generated by an artificial intelligence model, and obtaining a component type identifier, a component class name and a function identifier; according to the component type identifier and the component class name, executing a dynamic loading operation to create a corresponding atomic card component instance; and establishing a communication relationship between the atomic card component instance and the vehicle function service according to the function identifier. The method is applied to an artificial intelligence model in an intelligent cabin system to generate a UI scene, so that UI description generated by the artificial intelligence model can be directly integrated with a vehicle function, and extra code adaptation is not needed.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence application technology, and in particular to a cockpit atomic component bridging method and vehicle. Background Technology

[0002] With the rapid development of smart cockpit technology, in-vehicle infotainment systems are becoming increasingly feature-rich, including various modules such as window control, seat adjustment, air conditioning control, and lighting control. These modules are typically encapsulated in the form of atomic cards, with each atomic card corresponding to a specific in-vehicle infotainment function. In scenarios where user interfaces (UIs) are generated by artificial intelligence models, the UI descriptions generated by the AI ​​models need to be integrated with in-vehicle infotainment functions through bridging components.

[0003] Currently, most general vehicle infotainment system integration solutions adopt hard coding. Developers need to write separate integration code for each functional module, manually create atomic card instances, bind data sources, handle status updates, etc., and need to recode, test, and release every time a function is changed or added. This cannot meet the needs of rapid iteration and personalized recommendations in smart cockpits.

[0004] Based on this, the above solution has the following problems in the scenario of UI generation by artificial intelligence model: First, the integration code is highly repetitive, and each function requires writing similar code logic, resulting in low development efficiency; second, the UI description generated by the artificial intelligence model cannot be directly bound to the vehicle system function, requiring additional code conversion and adaptation; finally, the dynamically generated components require manual handling of the lifecycle of each atomic card, and the atomic cards are highly coupled with the vehicle system function API, requiring modification of multiple code points when the function API changes. Summary of the Invention

[0005] To address the aforementioned issues, this application proposes a cockpit atomic assembly bridging method, which includes: The declarative description data generated by the artificial intelligence model is parsed to obtain the component type identifier, component class name, and function identifier. Based on the component type identifier and the component class name, perform a dynamic loading operation to create the corresponding atomic card component instance; Based on the function identifier, establish the communication relationship between the atomic card component instance and the vehicle system function service.

[0006] In one example, before parsing the declarative descriptive data generated by the artificial intelligence model, the method further includes: Obtain a training dataset, which includes user commands and corresponding declarative description data. The declarative description data is labeled with component type identifiers, component class names, and function identifiers determined based on the vehicle infotainment function service knowledge base. The large language model is trained based on the training dataset so that it can generate corresponding declarative description data in response to user instructions.

[0007] In one example, parsing the declarative description data generated by the artificial intelligence model to obtain the component type identifier, component class name, and function identifier specifically includes: Traverse the structured data structure of the declaratively described data; Locate and extract key-value pairs of component type identifier, component class name, and function identifier.

[0008] In one example, the step of performing a dynamic loading operation based on the component type identifier and the component class name to create a corresponding atomic card component instance specifically includes: Dynamically load atomic card classes based on the component class name; and determine the view creation strategy for atomic cards based on the component type identifier; Based on the atomic card class and the view creation strategy, create the corresponding atomic card component instance.

[0009] In one example, establishing the communication relationship between the atomic card component instance and the vehicle infotainment function service based on the function identifier specifically includes: Create a communication bridge interface instance based on the function identifier and session management instance; Associating the communication bridge interface instance with the atomic card instance establishes a bidirectional data channel between the atomic card component instance and the vehicle infotainment service.

[0010] In one example, the step of creating a communication bridge interface instance based on the function identifier and session management instance specifically includes: Inject the function identifier and the session management instance into the communication bridge interface instance; Configure the function call interface of the communication bridge interface instance to configure the communication bridge interface instance to forward function call requests of the atomic card component instance to the vehicle function service specified by the function identifier through the session management instance.

[0011] In one example, associating the communication bridge interface instance with the atomic card instance specifically includes: Invoke the initialization method of the atomic card; The communication bridge interface instance is passed as a parameter to the initialization method to initialize the atomic card.

[0012] In one example, after establishing the communication relationship between the atomic card component instance and the vehicle infotainment function service based on the function identifier, the method further includes: Register a state change callback interface through a session management instance; When the vehicle infotainment system's functional status data changes, the update method of the status change callback interface is called through the session management instance, and the status change data is passed to the status change callback interface. In the update method of the state change callback interface, the data update method of the atomic card instance is called to pass the state change data to the atomic card instance to drive the user interface to update automatically.

[0013] In one example, after establishing the communication relationship between the atomic card component instance and the vehicle infotainment function service based on the function identifier, the method further includes: Register a view lifecycle listener for the atomic card component; The lifecycle listener detects events where the atomic card component view is detached from the window; In response to the detach event, release the session management instance associated with the atomic card component instance.

[0014] On the other hand, embodiments of this application provide a vehicle including a controller, the controller including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a cockpit atomic component bridging method as described above.

[0015] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By parsing the structured descriptive data output by the AI ​​model and automatically executing the subsequent loading and binding processes, developers are completely freed from tedious low-level coding work. That is, developers only need to declare what components are needed and what functions are bound, and the system can automatically complete all integration work, significantly improving integration efficiency and response speed in AI model-generated UI scenarios. This effectively avoids the problem of traditional solutions requiring developers to write a large amount of code, including manually instantiating components, finding services, and registering listeners, which is tedious and repetitive. It achieves truly automated integration of declarative UI and business functions, greatly improving development efficiency.

[0016] The UI layout and component composition generated by the AI ​​model are unpredictable at compile time, and traditional hard-coding methods cannot handle this dynamism. The core of the dynamic loading operation is designed to address this uncertainty. The system can flexibly create and combine various atomic cards at runtime based on the real-time output of the AI ​​model, giving the cockpit system dynamic responsiveness.

[0017] By establishing communication relationships through a functional identifier abstraction layer, atomic card component instances do not need to directly depend on any specific vehicle infotainment function APIs at the code level. The specific communication links are dynamically established by the underlying system, reducing coupling. Therefore, when the interface of a vehicle infotainment function service changes, only the underlying system's parsing and mapping logic for the functional identifier needs adjustment, while all atomic card components using that identifier remain unchanged, reducing code fragility and enhancing maintainability. Furthermore, when adding new vehicle infotainment functions, only the new functional identifier needs to be registered and its service link implemented; the existing dynamic loading and communication establishment mechanisms can automatically adapt without modifying the core framework. The UI component library can be developed and extended independently of the function services, enhancing scalability.

[0018] Through a unified communication relationship establishment mechanism and lifecycle management, it is ensured that these dynamically created components can be systematically and securely integrated into the overall state management and resource scheduling system of the vehicle infotainment system. This avoids problems such as memory leaks and state asynchrony that may be caused by disordered creation and destruction of components, and guarantees the long-term operational stability and reliability required by the vehicle infotainment system as an embedded system.

[0019] In summary, the AI ​​model-generated UI scenario applied to intelligent cockpit systems allows the UI descriptions generated by the AI ​​model to be directly integrated into vehicle infotainment functions without the need for additional code adaptation. Compared to traditional general integration solutions or hard-coded integration methods, it offers advantages such as dedicated design for AI model-generated UI scenarios, high development efficiency, good system decoupling, secure resource management, and strong scalability. Attached Figure Description

[0020] To more clearly illustrate the technical solution of this application, some embodiments of this application will be described in detail below with reference to the accompanying drawings, in which: Figure 1 A schematic flowchart illustrating a cockpit atomic component bridging method provided in an embodiment of this application; Figure 2 A schematic diagram of a cockpit atomic component bridging system framework in an example scenario provided in this application embodiment; Figure 3 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Some embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0023] Figure 1 A flowchart illustrating a cockpit atomic component bridging method provided in this application embodiment includes the following steps: S101: Parse the declarative description data generated by the artificial intelligence model to obtain the component type identifier, component class name, and function identifier.

[0024] In intelligent cockpit systems, the declarative descriptive data generated by the artificial intelligence model based on user commands is a structured data carrier. Essentially, it is an abstract description of the user interface components and their functional bindings, realizing the instantiation and integration of abstract descriptions into concrete functional components. That is, by parsing the output of the artificial intelligence model, the abstract UI description is transformed into specific parameters that the system can understand and execute.

[0025] In this example, an AI model refers to a technology capable of understanding natural language or design intent and generating structured UI descriptions. An AI model is essentially a UI generation engine; its task is to receive instructions or requirements from users or upper-layer applications and then output a UI blueprint readable by the bridging system. For example, if you are designing a car window control card, the AI ​​model will generate a structured description declaring what components are needed and which vehicle infotainment service the card's functionality needs to be bound to (i.e., the card's functionality needs to be bound to the window control service).

[0026] The structured data format can be JSON, XML, YAML, etc. Artificial intelligence models can include large language models and visual language models. Large language models are used to understand users' natural language descriptions, while visual language models are used to understand UI elements in images.

[0027] For example, by inputting text, a card can be created that allows the user to adjust the seat position. The LLM (Large Language Model) process can be as follows: First, understand the keyword: seat position. Then, associate it with the vehicle's seat adjustment function from the knowledge base. Finally, select the corresponding class name from the component library.

[0028] For example, given an input image—a designer's sketch of a seat adjustment UI—the user is asked to generate a UI description based on this design. The VLM (Visual Language Model) process can be as follows: First, the visual encoder analyzes the image: recognizing it as a card containing a seat-shaped icon, a position slider, and a three-level ventilation button. Then, these visual elements are combined with the language knowledge of the LLM part. Next, the LLM part infers that these visual elements correspond to the seat adjustment function. Then, it associates this with the vehicle's seat adjustment function from the knowledge base. Finally, it selects the corresponding class name from the component library.

[0029] It's important to note that the component type identifier defines the basic form classification of the component in the user interface, such as card-type, button-type, and list-type components. Therefore, the component container type and basic rendering strategy are determined based on the component type identifier. The component class name uniquely identifies the specific class implementing the component within the system components and is also a key basis for dynamic component instantiation. It is used to select the corresponding component from the component library. The function identifier is used to uniquely correspond to a specific vehicle system function. This function identifier can take the form of a Uniform Resource Identifier, a unique function code or hash value, or a service-function combination key. Therefore, this function identifier indicates that the atomic card component needs to communicate with a specific function service, specifically pointing to a particular function within that service. However, the function identifier not only identifies the specific function operation but also the service providing that function.

[0030] Furthermore, atomic cards are the smallest UI units that encapsulate in-vehicle infotainment functions, such as window control cards and seat adjustment cards. Each atomic card corresponds to a specific in-vehicle infotainment function API interface. In other words, atomic card components are the building blocks and functional carriers of the UI, serving as the smallest reusable unit for constructing the UI and possessing complete business functionality.

[0031] The various underlying functions provided within a car typically exist in the form of services. For example: Media services: responsible for music playback, pause, and track skipping. Navigation services: responsible for route planning and real-time navigation. Vehicle status services: providing information such as vehicle speed, fuel consumption, and door open / closed status. Air conditioning services: controlling the air conditioning's on / off state, temperature, and fan speed. These services run continuously in the background, managing hardware resources and core logic.

[0032] Based on this, declarative description data serves as a common language between artificial intelligence models and vehicle systems. By parsing this declarative description data, an operable and functional vehicle interface can be automatically implemented.

[0033] S102: Perform a dynamic loading operation based on the component type identifier and the component class name to create a corresponding atomic card component instance.

[0034] In this example, dynamic loading refers to the technical process of dynamically locating, loading, and instantiating the corresponding class using reflection, based on the class information in string form.

[0035] The above process represents the core steps of dynamic and hard-coding-free implementation, enabling the creation of corresponding user interfaces in real-time based on declarative description statements. Traditional static coding requires developers to specify which class to create before compilation, making it unsuitable for handling constantly changing component requirements. This application's dynamic loading method, however, utilizes reflection to decouple component creation logic (existing in declarative description data) from concrete component classes by finding and creating classes.

[0036] It should be noted that an Atomic Card Component instance is an Atomic Card Component object, which is a complete view object that can be added to the view hierarchy.

[0037] In this example, when dynamic loading fails, the system executes a fallback process, such as replacing the target atomic card component with a default placeholder component. That is, it searches for and replaces the default placeholder component, and reports a missing component alert in the logs.

[0038] S103: Based on the function identifier, establish the communication relationship between the atomic card component instance and the vehicle function service.

[0039] In this example, the communication relationship can be established as follows: During initialization, the atomic card component instance parses the function identifier and proactively initiates a data request to the vehicle system based on that identifier. This request process itself is considered the establishment of the communication relationship. The data returned by the server is populated into the atomic card, completing the first data interaction and signifying that the communication relationship has been successfully established and can be maintained for subsequent interactions.

[0040] Communication relationships can also be established in the following way: During initialization, the atomic card component instance subscribes to a central event bus or service management module, using the function identifier as the event type or message topic. When the corresponding vehicle system function status changes, updated data is published to that topic. Once the subscription is complete, the communication relationship is considered established, and subsequent data pushes are a manifestation and utilization of this communication relationship.

[0041] The communication relationship can also be established in the following way: When the system creates an instance of an atomic card component, it automatically binds a listener or callback interface between the component and the corresponding vehicle infotainment service based on the function identifier. This binding is considered the establishment of the communication relationship; the atomic card receives data updates through the listener, and the service receives user commands through the callback interface.

[0042] Communication relationships can also be established by using a unified interface as a proxy to forward function calls of component instances to a central session manager, which then calls specific vehicle infotainment function APIs.

[0043] It's important to note that the communication relationship is bidirectional, not just a one-way data retrieval. Atomic cards, through established communication relationships, encapsulate user interaction events (such as clicks and swipes) into instructions, invoking the corresponding functions provided by the vehicle's infotainment system. The infotainment system, in turn, proactively pushes or responds to requests, returning status data to drive updates to the atomic card interface.

[0044] It should be noted that, although the embodiments in this application are based on... Figure 1 Steps S101 to S103 will be described sequentially, but this does not mean that steps S101 to S103 must be performed in a strict order. The reason this embodiment follows this order is... Figure 1 The order in which steps S101 to S103 are described is provided to facilitate understanding of the technical solutions of the embodiments of this application by those skilled in the art. In other words, in the embodiments of this application, the order of steps S101 to S103 can be appropriately adjusted according to actual needs.

[0045] In existing AI model generation scenarios, developers still need to manually write integration code to address the integration issues between the AI ​​model and vehicle infotainment functions. This process is tedious and repetitive. Therefore, this application aims to automatically bridge the AI ​​model generation UI with vehicle infotainment functions.

[0046] Therefore, the declarative description data here is automatically inferred from user instructions, rather than manually configured. If the declarative description data were manually generated, the dynamic loading and abstract communication mechanism of this application would not be necessary. The reasons are as follows: When declarative data is manually written (e.g., a developer writes a JSON file by hand), the writer knows exactly what components they want to create and what functionalities they want to bind. In this process, they are perfectly capable of, and usually do, directly write the functional call logic in the corresponding component initialization code, or use static binding annotations or configurations provided by the framework.

[0047] Therefore, in this fully manual or semi-automatic (tool-assisted) development paradigm, dynamically loaded and abstracted communication bridges are not necessary. Everything is under the developer's control; the mapping between components and functions is pre-defined and static. For example, developers can directly rely on specific APIs without needing an intermediate layer that dynamically resolves and establishes communication based on function identifiers at runtime.

[0048] pass Figure 1 This method, by parsing the structured descriptive data output by the artificial intelligence model and automatically executing the subsequent loading and binding process, completely liberates developers from tedious low-level coding work. In other words, developers only need to declare what components are needed and what functions are bound, and the system can automatically complete all integration work, significantly improving integration efficiency and response speed in AI model-generated UI scenarios. It effectively avoids the problem of traditional solutions requiring developers to write a large amount of code, including manually instantiating components, finding services, and registering listeners, which is tedious and repetitive. It achieves truly automated integration of declarative UI and business functions, greatly improving development efficiency.

[0049] The UI layout and component composition generated by the AI ​​model are unpredictable at compile time, and traditional hard-coding methods cannot handle this dynamism. The core of the dynamic loading operation is designed to address this uncertainty. The system can flexibly create and combine various atomic cards at runtime based on the real-time output of the AI ​​model, giving the cockpit system dynamic responsiveness.

[0050] By establishing communication relationships through a functional identifier abstraction layer, atomic card component instances do not need to directly depend on any specific vehicle infotainment function APIs at the code level. The specific communication links are dynamically established by the underlying system, reducing coupling. Therefore, when the interface of a vehicle infotainment function service changes, only the underlying system's parsing and mapping logic for the functional identifier needs adjustment, while all atomic card components using that identifier remain unchanged, reducing code fragility and enhancing maintainability. Furthermore, when adding new vehicle infotainment functions, only the new functional identifier needs to be registered and its service link implemented; the existing dynamic loading and communication establishment mechanisms can automatically adapt without modifying the core framework. The UI component library can be developed and extended independently of the function services, enhancing scalability.

[0051] Through a unified communication relationship establishment mechanism and lifecycle management, it is ensured that these dynamically created components can be systematically and securely integrated into the overall state management and resource scheduling system of the vehicle infotainment system. This avoids problems such as memory leaks and state asynchrony that may be caused by disordered creation and destruction of components, and guarantees the long-term operational stability and reliability required by the vehicle infotainment system as an embedded system.

[0052] In summary, the AI ​​model-generated UI scenario applied to intelligent cockpit systems allows the UI descriptions generated by the AI ​​model to be directly integrated into vehicle infotainment functions without the need for additional code adaptation. Compared to traditional general integration solutions or hard-coded integration methods, it offers advantages such as dedicated design for AI model-generated UI scenarios, high development efficiency, good system decoupling, secure resource management, and strong scalability.

[0053] based on Figure 1 In addition to the method described herein, this application also provides some specific implementation schemes and extension schemes of the method, which will be further explained below.

[0054] In one example, when the artificial intelligence model is a large language model, the training process of the artificial intelligence model may include the following steps: First, obtain the training dataset, which includes user commands and corresponding declarative description data. The declarative description data is labeled with component type identifiers, component class names, and function identifiers determined based on the vehicle infotainment function service knowledge base.

[0055] In this example, the training dataset can be constructed in the following way: Historical data collection: Collect user commands and actual triggered atomic card components and function association records from existing vehicle system application logs.

[0056] Manual annotation: Developers annotate user commands with corresponding declarative descriptive data based on the vehicle's functional service knowledge base.

[0057] Automated generation: Based on the vehicle infotainment function service knowledge base and UI component library, a portion of the training data is automatically generated through scripts.

[0058] Then, the large language model is trained based on the training dataset so that it can generate corresponding declarative description data in response to user instructions.

[0059] The aforementioned training dataset was used to perform supervised fine-tuning of large language models (such as Transformer-based models like GPT and BERT). The goal of training was to enable the large language model to learn the mapping relationship between user commands and declarative descriptive data. During training, the model needed to learn to understand the intent of user commands and select the correct function identifier based on the vehicle's functional service knowledge base, while also selecting the correct component type identifier and component class name based on the UI component library.

[0060] In summary, a compilation model for converting natural language into declarative UI has been established. Users only need to describe their requirements in natural language, and the model can automatically output structured data containing complete component information and functional identifiers, greatly reducing the technical threshold and usage cost of UI generation.

[0061] The model learns not only the visual presentation of atomic card components, but more importantly, it learns how to map user intent to specific in-vehicle infotainment functions and services. The function identifiers in the declarative description data generated by the model directly correspond to the actual service interfaces at the underlying level of the in-vehicle infotainment system, ensuring that the generated atomic card components can actually call in-vehicle infotainment functions.

[0062] By standardizing the declarative data structure (component type identifier, component class name, and function identifier) ​​in the unified training data, a standardized data interface is established for the AI ​​model to generate the UI. This ensures that the model output strictly adheres to the established specifications, forming a clear interface contract with the subsequent component loading and function binding system. Furthermore, when the vehicle infotainment system's functions are updated or expanded, only the training dataset and underlying knowledge base need to be updated accordingly for the model to learn. This allows for new function binding relationships without changing the entire technical architecture, reducing the coupling between different modules of the system.

[0063] In one example, parsing declarative descriptive data generated by an artificial intelligence model may include the following steps: First, iterate through the structured data structures that declaratively describe the data.

[0064] In this approach, the declarative description of the data is organized using a hierarchical structured data format, and each level of the data structure is systematically traversed. The traversal method can be to visit nodes layer by layer in hierarchical order.

[0065] Then, locate and extract key-value pairs of component type identifier, component class name, and function identifier.

[0066] In this example, during the iteration, matching is performed based on a predefined key name rule library. This key name rule library specifies the standard key names for the fields.

[0067] After locating the target key, extract the corresponding value data, and perform format validation and type conversion on the extracted values ​​to ensure that the data format meets expectations.

[0068] In summary, a systematic traversal mechanism ensures the ability to handle declarative data structures of arbitrary complexity, including multi-level nesting and array combinations. The key-value pair location method exhibits good fault tolerance, accurately extracting core parameters even when the data structure undergoes partial changes. The reliability of the parsing process is ensured.

[0069] Furthermore, the parsing process is abstracted into two standardized steps: traversal and extraction. This allows the system to flexibly adapt to different data formats. When the format standard for declarative data descriptions is updated, only the key name configuration and traversal strategy need to be adjusted, without changing the core parsing architecture. This achieves decoupling between the parsing logic and the data format.

[0070] In one example, performing a dynamic loading operation based on the component type identifier and the component class name to create a corresponding atomic card component instance may include the following steps: First, dynamically load atomic card classes based on component class names; and determine the view creation strategy for atomic cards based on component type identifiers.

[0071] The system invokes the view factory's class loader, taking the component class name as input. Using a reflection interface provided by the programming language (such as the `Class.forName(String className)` method in Java), it dynamically searches for, loads, and returns the corresponding object (such as a `Class` object) from the component library in the current classpath (e.g., the classpath) based on the fully qualified class name string. This process maps the string-based class name to virtual machine-manipulated class metadata.

[0072] It's important to note that different view creation methods can be selected based on different component types. A view creation strategy mapping table can be set up to map different component types to corresponding creation strategies. That is, the corresponding view creation strategy is selected from a predefined view strategy mapping table based on the component type identifier.

[0073] Then, based on the atomic card class and view creation strategy, the corresponding atomic card component instance is created.

[0074] After successfully loading the object, obtain the constructor that matches the component type (such as a constructor that accepts a Context parameter) through a method (such as getConstructor). Call the method of the obtained constructor (such as newInstance) and pass in the necessary initialization parameters (such as the Context object) to create a concrete instance of the component class in the memory heap.

[0075] Based on the view creation strategy, the atomic card class instances created through reflection are configured and encapsulated, for example, embedded into the corresponding base view container, and the corresponding view properties are set, thereby forming the final atomic card component instance. In other words, the final atomic card component view is generated by combining the view creation strategy.

[0076] In summary, on-demand loading of component classes has been implemented, enabling the system to support infinitely expandable atomic card types without modifying the core framework code. Furthermore, the separation of UI logic and UI style has been achieved, allowing the same atomic card logic to adapt to different UI styles, enhancing the system's flexibility and visual consistency.

[0077] Based on this, the entire loading and instantiation process is encapsulated into a unified, automated operation. Atomic cards of any type can be created and managed. This achieves unified loading and management of atomic cards, supports dynamic creation of atomic card instances by class name, and improves the system's flexibility and scalability.

[0078] In one example, establishing a communication relationship between an atomic card component instance and a vehicle infotainment function service based on a function identifier may include the following steps: First, create a communication bridge interface instance based on the function identifier and session management instance.

[0079] The communication bridge interface instance is configured to forward function call requests from the atomic card component instance to the vehicle-mounted function service specified by the function identifier through the session management instance.

[0080] It should be noted that the configured communication bridge interface instance becomes an intelligent communication proxy, providing a unified function call method for atomic cards. It combines the received call request with the function identifier and accurately routes it to the target service through the call method of the session management instance.

[0081] The session management instance provides communication channels and capabilities, and is responsible for managing the session state, lifecycle, and actual communication protocols with the vehicle's underlying system.

[0082] Based on this, a specific, technical function call target and a general communication capability are encapsulated into a standardized communication interface that can be used by atomic cards.

[0083] Then, the communication bridge interface instance is associated with the atomic card instance to establish a bidirectional data channel between the atomic card component instance and the vehicle-mounted system function service.

[0084] Before association, the communication bridge interface instance had the ability to communicate with the vehicle-mounted system service, but the service object was not specified. Therefore, after association, the atomic card instance takes on the role of a communication bridge and can communicate with the vehicle-mounted system service.

[0085] In summary, by encapsulating the variable and complex parts (the implementation of the communication protocol) within the bridging system, and providing a stable and simple abstract interface to the atomic cards, the technical problem of dynamic function binding in the UI generation scenario of artificial intelligence models can be solved.

[0086] Through an automated mechanism, based on the functional identifiers declared in structured data by an artificial intelligence model, a complete communication link between atomic card instances and vehicle-mounted function services is dynamically constructed, achieving true declarative function integration.

[0087] In this example, the process of creating a communication relationship may include the following steps: First, inject the function identifier and session management instance into the communication bridge interface instance. Then, configure the function call interface of the communication bridge interface instance.

[0088] It should be noted that injecting the function identifier into the communication bridge interface instance allows the establishment of a mapping relationship with the vehicle's infotainment system functions. Injecting the session management example into the communication bridge interface instance allows the establishment of communication channel capabilities.

[0089] After configuration, the following process can be achieved: Receives a function call request from an atomic card component instance. The function call request includes the function name and parameter package.

[0090] Here, the function name refers to the specific operation to be performed, and the parameter package refers to the parameters required to perform the operation.

[0091] By invoking the function call method of the session management instance, the function call request is forwarded to the vehicle-mounted function service specified by the function identifier.

[0092] The execution result of the vehicle-mounted system function service is returned to the atomic card component instance through the communication bridge interface instance.

[0093] For example, an atomic card instance uses the communication bridge interface instance injected during initialization to call its `funcca11` method, passing in the function name and parameter package. At this point, the request is officially sent from the UI layer and enters the bridging system.

[0094] The communication bridge interface instance internally calls the funccall method of the session management instance it holds, thereby performing precise routing.

[0095] The session management instance is a critical router that combines the following two pieces of information to ensure that requests are delivered accurately: the function identifier indicates the final target address of the call; and the function name and parameter package provide explicit calling instructions.

[0096] Based on this, the session management instance uses its underlying communication capabilities to combine these two pieces of information into a complete instruction that the vehicle's underlying system can recognize, and then sends it out.

[0097] After the vehicle-mounted system function service completes its operation, it returns an execution result. This result is also sent back to the communication bridge interface instance through the session management instance. The communication bridge interface instance then uses this result as the return value of the funccall method and passes it back to the atomic card instance that initially initiated the call.

[0098] In this example, the association process can be as follows: First, the initialization method of the atomic card is called. Then, the communication bridge interface instance is passed as a parameter to the initialization method to initialize the atomic card.

[0099] Based on this, the atomic card example saves the incoming communication bridge interface instance parameter as its own member variable to complete the association.

[0100] In summary, atomic cards only depend on an abstract interface and do not need to know who implements that interface or how. Communication capabilities are provided externally, rather than created by the atomic card itself. This greatly reduces coupling, making the development, testing, and reuse of atomic cards extremely simple.

[0101] The corresponding atomic card instances and communication bridge instances are dynamically created and assembled together during initialization. Throughout the process, there are no hard-coded bindings, and communication capabilities can be dynamically assigned to the atomic card instances corresponding to the declarative description data.

[0102] Communication bridges require unified management of resource lifecycles. If each atomic card creates its own, it can easily lead to resource leaks or session chaos. Therefore, by creating and managing the communication bridge interface and the session management behind it, the lifecycle of resources can be ensured to be consistent with the lifecycle of the atomic card components. When UI components are destroyed, the bridging system can safely release these resources, effectively preventing memory leaks.

[0103] In one example, an automatic response mechanism for vehicle system status changes to atomic card UI updates was established, which may include the following steps: First, register a state change callback interface through the session management instance.

[0104] Specifically, after the atomic card component instance completes initialization, the associated session management instance is obtained, and the registration method of the session management instance is called, passing in an implementation instance of a state change callback interface.

[0105] Based on this, it's equivalent to subscribing to status update notifications from the vehicle infotainment service. The session management instance acts as the event hub, distributing all status change events uniformly. This eliminates the need for atomic cards to be directly coupled to specific vehicle infotainment APIs; they only need to focus on the unified event channel provided by the session management instance.

[0106] Then, when the vehicle system function status data changes, the update method of the status change callback interface is called through the session management instance, and the status change data is passed to the status change callback interface.

[0107] Specifically, when the status data of the vehicle's infotainment system changes (for example, when a window is closed by a physical button), this change is captured by the session management instance. Subsequently, the session management instance automatically calls the update methods of all registered status change callback interfaces and encapsulates the changed status data in a data packet as a parameter.

[0108] Based on this, communication is only triggered when the state actually changes, greatly improving system efficiency and real-time performance. The session management instance acts as a notification center, responsible for broadcasting single state change events multiplexed to all interested subscribers (atomic cards). That is, the communication bridge interface instance can also support an event subscription interface, which allows atomic card component instances to subscribe to event notifications from the vehicle infotainment service. When the vehicle infotainment service triggers an event, the event data is pushed to the atomic card component instance through the communication bridge interface instance.

[0109] Finally, in the update method of the state change callback interface, the data update method of the atomic card instance is called to pass the state change data to the atomic card instance, so as to drive the user interface to update automatically.

[0110] In the specific implementation of the update method of the state change callback interface, the bridging system calls the data update method of the atomic card instance. At this time, the state change data parsed from the data packet is passed as a parameter to this data update method. Inside the method, the atomic card instance re-renders the user interface based on the new data.

[0111] Based on this, changes to the data layer are directly translated into UI layer updates. Since this call occurs within the callback interface, which is associated with the atomic card instance, a closed-loop automation of state changes, callback triggering, and UI updates is achieved. Developers do not need to write any state listening logic in the atomic cards; they only need to implement methods to process new data and update the UI, greatly simplifying development.

[0112] In summary, an efficient, reliable, and decoupled responsive state synchronization channel has been constructed, laying a solid foundation for the declarative and automated development of UI generation from artificial intelligence models in intelligent cockpits.

[0113] In one example, communication between the atomic card component and the vehicle infotainment service may fail due to network anomalies, service not starting, insufficient permissions, or other reasons. Therefore, when communication fails to establish, a simulated data interface is provided for the atomic card instance to use, including the following steps: When communication fails to establish a connection, a simulated communication bridge interface instance is generated; the simulated communication bridge interface instance is configured as follows: Based on the function identifier, obtain the simulated state data from the preset static data mapping and provide the simulated state data to the atomic card component instance; In response to an operation request initiated by an atomic card component instance, update the maintained simulation state and trigger the user interface update callback of the atomic card component instance to simulate the operation execution result.

[0114] Based on this, a simulated communication bridge interface instance is instantiated. This instance implements the exact same interface as the standard communication bridge, but its internal logic does not interact with the real vehicle infotainment service. A static data mapping table associates different function identifiers with a set of preset, reasonable static simulated data. For example, when the function identifier points to the air conditioning service, the corresponding simulated data is a temperature of 22 degrees Celsius and a medium fan speed.

[0115] When an atomic card instance calls a function method (e.g., adjusting temperature) through a simulated communication bridge interface instance, the bridging system performs the following steps: The corresponding simulation state will be updated in the internal local data storage area (for example, updating the simulated temperature value to 24 degrees Celsius). Then, a service state update event is simulated, calling the state update callback registered by the atomic card, and passing the updated simulation data as a parameter.

[0116] Based on this, the atomic card interface can respond to user operations in real time and display visual feedback consistent with actual operations.

[0117] It should be noted that operations can be recorded in an offline operation queue, allowing for selective synchronization once communication is restored.

[0118] In this example, to maintain transparency for the user, the atomic cards in simulation mode can be visually subtly differentiated, such as displaying a semi-transparent simulation or offline icon in the corner of the component. Simultaneously, the system interface may display a system-level notification in a non-intrusive area (such as the status bar) informing the user that some functionality is using demo data.

[0119] In this example, when periodically retrying to establish a communication relationship, if the communication relationship is successfully established, a new real communication bridge interface instance will replace the current simulated communication bridge interface instance, and the atomic card component instance will be driven to synchronize the real service state.

[0120] Based on this, once the connection is restored, the bridging component layer can obtain the real session instance. At this point, the system can perform a silent switch: replacing the simulated interface instance currently held by the atomic card with the newly created real communication bridge interface instance. After the switch, the atomic card will automatically pull the real service status and update the UI, allowing users to seamlessly transition from simulated mode to online mode without any user intervention.

[0121] In summary, even when services are temporarily unavailable, the user interface remains interactive and responsive, preventing interface freezes or blank screens caused by functional unavailability and maintaining the availability and premium feel of the cockpit system.

[0122] The entire degradation and recovery process is transparent to the business logic code of the atomic card component. The component does not need to write special logic for the simulation mode, which reflects the flexibility of the system architecture and realizes transparent degradation and recovery.

[0123] This simulation mechanism can also be used for offline testing or demonstration during the development phase without relying on a complete vehicle infotainment service environment, thus supporting development and testing.

[0124] In one example, establishing a lifecycle management and resource release mechanism may include the following steps: First, register a view lifecycle listener for the atomic card component.

[0125] For example, after instantiating the atomic card component view through mechanisms such as viewFactory, register a view lifecycle listener for the view component.

[0126] Based on this, by registering listeners, it becomes possible to perceive key lifecycle events of UI components, transforming from a passive resource manager to an active lifecycle listener. This provides an event trigger source for subsequent precise release.

[0127] Then, the event of the atomic card component view being detached from the window is detected through a lifecycle listener.

[0128] Specifically, the listener continuously monitors the attachment state of the view. When user interaction causes a change in the UI (such as closing a page or switching tabs), the atomic card component view will detach from its window. At this time, the bridging system will trigger the listener's callback method.

[0129] Finally, in response to the detach event, the session management instance associated with the atomic card component instance is released.

[0130] When the callback method is triggered, a resource cleanup routine is automatically executed. This routine retrieves the session management instance associated with the atomic card instance and calls a unified resource manager method to precisely release the session instance and all network, memory, and other system resources it occupies.

[0131] Therefore, when a view is destroyed, the associated session resources are inevitably released, forming a strict closed-loop management system with no memory leaks. Furthermore, this avoids the gradual depletion of system resources due to resource residue, ensuring the stability and smoothness of the system during long-term operation and achieving efficient resource utilization. In addition, application developers do not need to worry about complex resource release logic; they only need to develop UI components according to the specifications, fundamentally eliminating the possibility of resource leaks due to human error.

[0132] In summary, establishing an automated mechanism for UI lifecycle event-driven background resource release achieves perfect matching between the resource usage cycle of components and session resources and the UI visibility cycle, optimizing management granularity and enabling precise lifecycle synchronization. Furthermore, resource management is automated, requiring no developer intervention and significantly reducing code complexity and the risk of human error. It also effectively prevents system memory overload, slow response times, and even crashes caused by resource leaks, greatly improving the reliability and user experience of the intelligent cockpit system. Moreover, the resource management logic is encapsulated in a unified framework layer, separated from business logic, resulting in a clearer system architecture that is easier to maintain and extend.

[0133] It should be noted that the above-mentioned atomic component bridging method refers to the complete process executed or implemented by the bridging component, including parsing declarative description data, dynamically loading atomic cards according to the parsing results, and establishing communication relationships between atomic cards and vehicle-mounted functional services. The carrier of the bridging component can be the vehicle's own on-board computing platform (such as a smart cockpit domain controller or a dedicated atomic component bridging controller).

[0134] More intuitively, Figure 2 This is a schematic diagram of a cockpit atomic component bridging system framework in an example scenario provided in an embodiment of this application.

[0135] exist Figure 2 In this system, the architecture is divided into three main layers: the JSON description layer, the bridging component layer, and the vehicle infotainment function layer. The JSON description layer defines atomic cards through a declarative protocol, the bridging component layer is responsible for parsing the JSON and loading the atomic cards, and the vehicle infotainment function layer provides the actual atomic card implementation and vehicle infotainment function APIs.

[0136] Based on this, when the declarative description data is in JSON format, the component type is identified as uiType, the component class name is uiClassName, and the function is identified as bind.

[0137] The process of automatically loading atomic cards based on JSON fields is as follows: When creating a view, the AtomicComponent extracts the following key fields from ComponentData: bind field parsing: Extract the value of the bind field.

[0138] For example, in bind: set_vehicle_window_control, this field identifies the vehicle infotainment function corresponding to the atomic card.

[0139] uiClassName field parsing: Extract the value of the uiClassName field.

[0140] For example, uiClassName: widget.vehicle.WindowControlCard, this field specifies the fully qualified name of the atomic card class.

[0141] uiType field parsing: Extract the value of the uiType field.

[0142] For example, uiType:Card, this field specifies the type of atomic card.

[0143] Based on this, the corresponding atomic cards are automatically loaded by parsing the bind, uiClassName, and uiType fields in the JSON.

[0144] Atomic card instance creation: The view factory receives a call request from an upper-level component (such as AtomicComponent), which includes two parameters: the component type identifier (uiType) and the component class name (uiClassName). Based on this, the view factory dynamically loads the atomic card class and creates a view instance using ViewFactory.getView(context, uiType, uiClassName) according to uiType and uiClassName.

[0145] When establishing a communication relationship, a communication bridge is built between the atomic card and the AISession through the IAtomicProvider interface. The process is as follows: IAtomicProvider interface implementation: Create an implementation of IAtomicProvider in AtomicComponent, which calls the vehicle's infotainment system functions through AISession.

[0146] The `funcCall` method mapping: The `funcCall` method of `IAtomicProvider` receives the function name and the parameter `Bundle`, and internally calls `session.funcCall(funcName, parameters)` to forward the function call of the atomic card to `AISession`, which then calls the corresponding vehicle system function API.

[0147] Two-way data transfer: Call parameters are passed through the Bundle parameter, and the call result is obtained through the Bundle return value, realizing two-way data transfer between atomic cards and vehicle functions.

[0148] Atomic card initialization: The atomic card is initialized by calling IAtomicWidget.initData(IAtomicProvider, packageName, id, data), passing in an IAtomicProvider instance, so that the atomic card can call the vehicle's functions through the communication bridge interface.

[0149] In other words, when requesting atomic card data, the atomic card data is requested through AtomicManager.requestAtomicUI(bindURI,callback). This method requests data from the vehicle function API based on the identifier specified in the bind field and returns AtomicData and Bundle data.

[0150] It's important to note that `AtomicComponent` refers to a dedicated component in the cockpit component library, used to integrate atomic cards within a declarative UI protocol. It dynamically loads and manages atomic card instances via JSON descriptions. `IAtomicProvider` serves as a communication bridge between atomic cards and the vehicle's infotainment API; that is, the communication bridge interface instance is an implementation of the `IAtomicProvider` interface. `IAtomicWidget` defines the basic methods of atomic cards, including data initialization and update operations.

[0151] The automatic state synchronization process based on UIDataChangeCallback is as follows: State listener registration: Register the UIDataChangeCallback listener using session.registerUIDataCallback(callback).

[0152] Status change notification: When the vehicle system status changes, AISession automatically calls the update method of the registered UIDataChangeCallback, passing in the changed data Bundle.

[0153] Automatic UI updates: In the update method, call the IAtomicWidget.onUpdate(id, data) method. The atomic card will automatically update the UI based on the new data, without the need to manually write update code.

[0154] By listening to the component's lifecycle using the View's OnAttachStateChangeListener, automatic resource management can be achieved. The process is as follows: Lifecycle listener registration: Register the OnAttachStateChangeListener listener after the atomic card View is created.

[0155] Component destruction detection: The onViewDetachedFromWindow callback is triggered when a component is detached from the window.

[0156] Automatic resource release: Call AIModelManager.releaseSession(id) in onViewDetachedFromWindow to release AISession resources and ensure there is no memory leak.

[0157] In summary, by declaring the vehicle infotainment system functions through the bind, uiClassName, and uiType fields in the JSON, AtomicComponent automatically parses and completes the binding, eliminating the need to write additional integration code and achieving true declarative function integration.

[0158] Furthermore, dynamic loading and management of atomic cards are implemented: AtomicManager and ViewFactory are used to achieve unified loading and management of atomic cards, supporting the dynamic creation of atomic card instances by class name, which improves the flexibility and scalability of the system.

[0159] Furthermore, decoupled communication between atomic cards and vehicle infotainment functions is achieved: a communication bridge is established through the IAtomicProvider interface, so atomic cards do not need to directly depend on vehicle infotainment function APIs, but can make indirect calls through AISession, which reduces coupling and improves system maintainability.

[0160] Furthermore, responsive state synchronization is achieved: through the UIDataChangeCallback mechanism, the atomic card UI is automatically updated when the vehicle system's state changes, eliminating the need to manually write state listening and update code, thus improving development efficiency.

[0161] Furthermore, by listening to the component lifecycle through OnAttachStateChangeListener, the automatic release of AISession resources can be achieved, enabling automatic resource management based on the View's lifecycle.

[0162] In summary, a design specifically addressing the integration of JSON descriptions generated by AI models with in-vehicle infotainment functions can be implemented, solving the following problems: The issue of automatically binding AI-generated JSON UI descriptions to in-vehicle infotainment functions: In AI-generated UI scenarios, the AI-generated JSON UI descriptions need to directly specify in-vehicle infotainment functions. Traditional general integration solutions require manual code writing for binding. This solution declares the `bind` field (in-vehicle infotainment function URI) and the `uiClassName` field (atomic card class name) in the AI-generated JSON. `AtomicComponent` automatically parses these fields and completes the function binding, achieving declarative function integration in AI-generated UI scenarios.

[0163] The issue of dynamic loading and management of atomic cards: Atomic cards need to be dynamically loaded via class name. Traditional solutions require manually calling a factory class to create instances. This solution provides a unified loading interface through AtomicManager. AtomicComponent automatically loads the corresponding atomic card class based on the uiClassName and uiType fields in the JSON description, eliminating the need to manually write loading code.

[0164] Communication issues between atomic cards and vehicle infotainment APIs: Atomic cards need to communicate with vehicle infotainment APIs to obtain data and perform operations. Traditional solutions require manually establishing a communication link. This solution establishes a communication bridge between atomic cards and AISessions through the IAtomicProvider interface. Atomic cards call vehicle infotainment functions via the funcCall method, and bidirectional data communication is achieved through AISessions.

[0165] Atomic card state synchronization and UI update issues: When the vehicle's infotainment system changes state, the atomic cards need to update the UI in real time. Traditional solutions require manually writing state listening and update logic. This solution uses AISession's UIDataChangeCallback mechanism to automatically listen for changes in the vehicle's infotainment system state. When the state changes, it automatically notifies the atomic cards to update the UI, achieving reactive state synchronization.

[0166] Atomic card lifecycle management: Managing resources is required from the creation to the destruction of atomic cards, and traditional solutions are prone to memory leaks. This solution uses the View's OnAttachStateChangeListener to monitor the component's lifecycle and automatically releases the AISession when the component is destroyed, ensuring proper resource release.

[0167] Based on the same idea, some embodiments of this application also provide vehicles and non-volatile computer storage media corresponding to the above methods.

[0168] Figure 3 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0169] For example, such as Figure 3 As shown, the vehicle includes a controller, which includes a memory 301 and a processor 302. The memory 301 stores executable program code 3011, and the processor 302 is used to call and execute the executable program code 3011 to perform the cockpit atomic component bridging method.

[0170] The controller can be a smart cockpit domain controller or an atomic component bridging controller.

[0171] Some embodiments of this application provide a cockpit atomic component bridging non-volatile computer storage medium storing computer-executable instructions capable of executing any of the above-described cockpit atomic component bridging methods.

[0172] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the vehicle and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0173] The vehicle equipment and medium provided in this application are one-to-one with the method. Therefore, the vehicle equipment and medium also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the vehicle equipment and medium will not be repeated here.

[0174] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0175] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0176] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0177] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0178] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0179] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0180] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

[0182] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the technical principles of this application should fall within the protection scope of this application.

Claims

1. A method for bridging atomic components in a cockpit, characterized in that, The method includes: The declarative description data generated by the artificial intelligence model is parsed to obtain the component type identifier, component class name, and function identifier. Based on the component type identifier and the component class name, perform a dynamic loading operation to create the corresponding atomic card component instance; Based on the function identifier, establish the communication relationship between the atomic card component instance and the vehicle system function service.

2. The method according to claim 1, characterized in that, Before parsing the declarative description data generated by the artificial intelligence model, the method further includes: Obtain a training dataset, which includes user commands and corresponding declarative description data. The declarative description data is labeled with component type identifiers, component class names, and function identifiers determined based on the vehicle infotainment function service knowledge base. The large language model is trained based on the training dataset so that it can generate corresponding declarative description data in response to user instructions.

3. The method according to claim 1, characterized in that, The process of parsing the declarative description data generated by the artificial intelligence model yields component type identifiers, component class names, and function identifiers, specifically including: Traverse the structured data structure of the declaratively described data; Locate and extract key-value pairs of component type identifier, component class name, and function identifier.

4. The method according to claim 1, characterized in that, The step of performing a dynamic loading operation based on the component type identifier and the component class name to create a corresponding atomic card component instance specifically includes: Dynamically load atomic card classes based on the component class name; and determine the view creation strategy for atomic cards based on the component type identifier; Based on the atomic card class and the view creation strategy, create the corresponding atomic card component instance.

5. The method according to claim 1, characterized in that, The step of establishing the communication relationship between the atomic card component instance and the vehicle infotainment function service based on the function identifier specifically includes: Create a communication bridge interface instance based on the function identifier and session management instance; Associating the communication bridge interface instance with the atomic card instance establishes a bidirectional data channel between the atomic card component instance and the vehicle-mounted system function service.

6. The method according to claim 5, characterized in that, The step of creating a communication bridge interface instance based on the function identifier and session management instance specifically includes: Inject the function identifier and the session management instance into the communication bridge interface instance; Configure the function call interface of the communication bridge interface instance to configure the communication bridge interface instance to forward function call requests of the atomic card component instance to the vehicle function service specified by the function identifier through the session management instance.

7. The method according to claim 5, characterized in that, Associating the communication bridge interface instance with the atomic card instance specifically includes: Invoke the initialization method of the atomic card; The communication bridge interface instance is passed as a parameter to the initialization method to initialize the atomic card.

8. The method according to claim 1, characterized in that, After establishing the communication relationship between the atomic card component instance and the vehicle infotainment function service based on the function identifier, the method further includes: Register a state change callback interface through a session management instance; When the vehicle infotainment system's functional status data changes, the update method of the status change callback interface is called through the session management instance, and the status change data is passed to the status change callback interface. In the update method of the state change callback interface, the data update method of the atomic card instance is called to pass the state change data to the atomic card instance to drive the user interface to update automatically.

9. The method according to claim 1, characterized in that, After establishing the communication relationship between the atomic card component instance and the vehicle infotainment function service based on the function identifier, the method further includes: Register a view lifecycle listener for the atomic card component; The lifecycle listener detects events where the atomic card component view is detached from the window; In response to the detach event, release the session management instance associated with the atomic card component instance.

10. A vehicle, comprising a controller, characterized in that, The controller includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform a cockpit atomic component bridging method according to any one of claims 1-9.

Images