Vehicle multi-domain fusion method and system and readable storage medium

Abstract

The invention provides a multi-domain fusion method and system of a vehicle, a single SOC and a computer readable storage medium, a multi-domain fusion framework is created on the single SOC, the multi-domain fusion framework comprises a hardware layer, a Hypervisor located on the hardware layer and a plurality of Guest OSs created according to user configuration, and all functional domains used for fusion in an intelligent driving vehicle run on the Guest OSs. On the basis of the multi-domain fusion architecture, the Hypervisor is adopted for communication between the source domain and the target domain, multi-domain fusion is completed, unnecessary similar data redundancy sources are reduced through data sharing, data between the domains are transmitted through the Hypervisor, and the real-time performance and reliability of communication can be remarkably improved.

Description

Technical Field

[0001] The present application relates to the field of automobile intelligent driving technology, and in particular to a multi-domain fusion method, system, single SOC and computer-readable storage medium for a vehicle. Background Art

[0002] With the advancement of technology, automobiles are developing in the direction of intelligence, and the manifestation of intelligence is multifaceted, such as intelligent driving, intelligent networking, and intelligent cockpit. However, the current technical solutions for these intelligent directions are relatively independent and have a low degree of integration. For example, there may be positioning modules in the TBOX module, the vehicle navigation module, and the intelligent driving module, resulting in many positioning modules and waste. Another example is that the current electronic rearview mirror camera and the intelligent driving rearview camera are also separate, resulting in a large number of cameras, high costs, and difficult layout. Therefore, intelligent driving vehicles with intelligent driving as the core must inevitably require the cooperation of intelligent networking and intelligent cockpits while realizing the core functions. The problem of multi-domain integration needs to be considered during the design to jointly form the framework of automobile intelligence and improve automobile safety and user experience.

[0003] The main architecture of smart cars at present is the domain controller architecture. Each domain (such as intelligent driving domain, cockpit domain, power domain, chassis domain, etc.) has a corresponding domain controller connected to the central gateway through the backbone network, and the communication and functional integration between domains are mostly realized through the backbone network. However, for the transmission of large amounts of data (such as images, point clouds, etc.), physical transmission channels such as in-vehicle Ethernet and GMSL are usually used between domains, resulting in large transmission delays in multi-domain integration. Summary of the invention

[0004] To overcome the problems existing in the related art, this specification provides a multi-domain fusion method, system, single SOC and computer-readable storage medium for a vehicle.

[0005] According to a first aspect of an embodiment of this specification, a multi-domain fusion method for a vehicle is provided, which is applied to a single SOC, and the method includes:

[0006] Based on the abstracted service interface of the Hypervisor layer, the data interaction request sent by the application program in the source domain of each functional domain of the vehicle to the target domain is received;

[0007] According to a preset inter-domain communication mechanism, the data in the data interaction request is forwarded to the target domain through the Hypervisor, so that after the target domain receives the data, it parses and processes the data according to a set format to complete multi-domain fusion;

[0008] A multi-domain fusion architecture is created on the single SOC, and the multi-domain fusion architecture includes a hardware layer, a Hypervisor layer located above the hardware layer, and multiple Guest OSes created according to user configuration. Each functional domain used for fusion in the vehicle runs in the Guest OS, and the Hypervisor layer abstracts and allocates hardware resources to each Guest OS through virtualization technology.

[0009] According to a multi-domain fusion method for a vehicle provided by the present application, before forwarding the data in the data interaction request to the target domain through the Hypervisor according to the preset inter-domain communication mechanism, the method further includes:

[0010] Verifying the legitimacy of the data interaction request;

[0011] Under legal circumstances, the Hypervisor allocates required resources for data interaction between the source domain and the target domain.

[0012] According to a multi-domain fusion method for a vehicle provided by the present application, the method further includes:

[0013] When the Hypervisor receives a hardware access request from an application in the source domain, the Hypervisor reads data of the target hardware corresponding to the hardware access request;

[0014] The data is encapsulated and the encapsulated data packet is forwarded to the source domain, so that the source domain can analyze and process the data after receiving it.

[0015] According to a multi-domain fusion method for a vehicle provided by the present application, when the Hypervisor receives a hardware access request from an application in a source domain, the Hypervisor reads data of a target hardware corresponding to the hardware access request, including:

[0016] When the Hypervisor receives a hardware access request from an application in the source domain, the Hypervisor parses the hardware access request and determines the request type;

[0017] Check the resource configuration of the Guest OS where the source domain is located;

[0018] When resource configuration is satisfied, based on the request type, data is exchanged with the target hardware through the Hypervisor to read data of the target hardware corresponding to the hardware access request.

[0019] According to a multi-domain fusion method for a vehicle provided by the present application, the hardware layer of the single SOC includes multiple heterogeneous cores. According to the resource requirements of the Guest OS and the characteristics of the heterogeneous cores, the Guest OS is matched with the heterogeneous cores to construct the multi-domain fusion architecture; wherein the heterogeneous cores interact with each other for data based on the service interface abstracted by the Hypervisor layer.

[0020] According to a multi-domain fusion method for a vehicle provided by the present application, the method further includes:

[0021] Monitoring resource usage of each functional domain in real time through the service interface between the Hypervisor and the Guest OS, and determining resource utilization of the data interaction process between the source domain and the target domain;

[0022] When the resource utilization rate reaches an upper limit, analyzing data interaction characteristics between the source domain and the target domain;

[0023] Based on the analysis results and the importance and priority of the services carried by the source and target domains, the resource allocation strategy is dynamically adjusted to meet the needs of data interaction.

[0024] According to a multi-domain fusion method for a vehicle provided by the present application, the dynamic adjustment of resource allocation strategy includes:

[0025] According to a preset resource adjustment frequency, a progressive adjustment strategy is adopted to allocate resources to the source domain and / or the target domain that needs to be adjusted.

[0026] The present application also provides a multi-domain fusion system for a vehicle, the system comprising:

[0027] The hardware layer is used to provide computing and storage capabilities for the entire system;

[0028] The Hypervisor layer is located above the hardware layer and is used to create multiple Guest OSes according to user configurations and abstract and allocate hardware resources to each Guest OS through virtualization technology; and

[0029] The virtual machine layer includes multiple virtual machines created by the Hypervisor, the Guest OS is configured in the virtual machine, and each functional domain used for fusion in the vehicle runs in the Guest OS.

[0030] The present application also provides a single SOC, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a multi-domain fusion method for a vehicle as described in any one of the above-mentioned methods is implemented.

[0031] The present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-domain fusion method for a vehicle as described in any one of the above.

[0032] In the embodiments of this specification, the multi-domain fusion method, system, single SOC and computer-readable storage medium of the vehicle are provided. By creating a multi-domain fusion architecture on a single SOC, the multi-domain fusion architecture includes a hardware layer, a Hypervisor layer located above the hardware layer and multiple Guest OS created according to user configuration, and each functional domain used for fusion in the intelligent driving vehicle runs on the Guest OS. Based on the multi-domain fusion architecture, Hypervisor is used for communication between the source domain and the target domain, and based on the abstracted service interface of the Hypervisor layer, a data interaction request sent by the application of the source domain in each functional domain of the vehicle to the target domain is received; according to the preset inter-domain communication mechanism, the data in the data interaction request is forwarded to the target domain through the Hypervisor, so that after the target domain receives the data, it parses and processes the data according to the set format to complete the multi-domain fusion, and reduces unnecessary similar data redundancy sources through data sharing, and the data between domains is transmitted through the Hypervisor, which can significantly improve the real-time and reliability of communication.

[0033] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

[0035] Figure 1 is a schematic diagram of a conventional architecture of a vehicle according to an exemplary embodiment of the present specification;

[0036] Figure 2 is a schematic diagram of a sensor multi-domain multiplexing architecture according to an exemplary embodiment of this specification;

[0037] Figure 3 is a schematic diagram of conventional inter-domain communication according to an exemplary embodiment of this specification;

[0038] Figure 4 is a schematic diagram of a multi-domain fusion architecture according to an exemplary embodiment of this specification;

[0039] Figure 5 is a schematic diagram of a multi-domain fusion architecture of another heterogeneous SOC shown in this specification according to an exemplary embodiment;

[0040] Figure 6 is a flow chart of a multi-domain fusion method for a vehicle according to an exemplary embodiment of the present specification;

[0041] Figure 7 is an example diagram of a deep fusion data flow of an intelligent driving domain and a cockpit domain shown in this specification according to an exemplary embodiment;

[0042] Figure 8 is a schematic diagram of a multi-domain fusion device for a vehicle according to an exemplary embodiment of the present specification;

[0043] Fig. 9 It is a schematic block diagram of a multi-domain fusion device of a vehicle according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0044] Here, the technical solutions in the embodiments (or "implementations") of the present application will be described clearly and completely in conjunction with the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements.

[0045] If there are terms involving directional indications or positional relationships in the embodiments of the present application (such as up, down, left, right, front, back, inside, outside, top, bottom, center, vertical, horizontal, longitudinal, transverse, length, width, counterclockwise, clockwise, axial, radial, circumferential, etc.), such terms are only used to explain the relative positional relationship, movement, etc. between the components under a certain specific posture (as shown in the accompanying drawings); if the specific posture changes, the directional indication or positional relationship will also change accordingly. In addition, the terms "first", "second", etc. involved in the embodiments of the present application are only used for the purpose of convenience of description and cannot be understood as indicating or implying relative importance.

[0046] The present application provides a multi-domain fusion method, system, single SOC and computer-readable storage medium for a vehicle. The present application is described in detail below in conjunction with the accompanying drawings. The features of the following embodiments and implementations may be combined with each other without conflict.

[0047] The vehicles described in this article generally refer to smart driving cars that can achieve autonomous driving functions without human intervention or assistance through integrated sensors, computer vision, machine learning and artificial intelligence technologies, as well as accurate map data and real-time data processing capabilities. The vehicles have intelligent technologies such as smart driving, smart networking, and smart cockpits, as well as conventional functions on the market, which will not be specifically introduced in this article.

[0048] like Figure 1As shown in the figure, current smart cars are usually composed of smart driving domain, smart cockpit domain, power domain, chassis domain, etc., but the systems in each domain are relatively independent and the degree of integration is not high. For example, there are positioning modules in the smart driving domain control unit and the smart cockpit domain control unit, and the smart domain components and cockpit domain components used to achieve positioning are also the same, which results in many positioning modules in the vehicle and waste. For example, the current electronic rearview mirror camera and smart driving rearview camera are also separate, resulting in a large number of cameras, high cost, and difficult layout. Therefore, to solve these problems, deep integration between domains and deep reuse of modules are required.

[0049] Smart driving cars are centered around smart driving. To realize the core functions, they must also cooperate with smart networking and smart cockpits. Therefore, multi-domain integration must be considered during the design to achieve the purpose of parts sharing and cost savings. At the same time, the smart driving controller is responsible for collecting sensor information, and after perception, regulation, control, decision-making and other operations, it sends the control information to systems such as power and chassis to realize the vehicle's intelligent driving.

[0050] like Figure 2 As shown in the figure, one current way to deeply reuse sensors in multiple domains is to set up a domain controller architecture in smart cars, and achieve deep reuse of shared components or modules through data transmission between domains. For example, the smart driving domain and the smart cockpit domain can share sensors such as positioning modules and cameras. Taking the shared rearview camera of the smart driving domain and the smart cockpit as an example, usually each domain has a domain controller, and the communication and functional integration between domains are mostly achieved through the backbone network and the central gateway connection. For the transmission of large amounts of data (such as images, point clouds, etc.), physical transmission channels such as in-vehicle Ethernet and GMSL are usually used between domains. As shown in the figure, Figure 3 As shown in the figure, the camera data is first input to the controller of the intelligent driving domain through the GMSL interface, and then input from the controller of the intelligent driving domain to the controller of the intelligent cockpit domain through Ethernet, so as to realize the multiplexing of the camera data by the intelligent cockpit domain. In this scheme, due to the huge amount of camera data, even a high-bandwidth physical channel such as automotive Ethernet still takes a certain amount of time to transmit a large amount of data. In addition, the serial transmission mode of data from one controller to another will accumulate transmission delay, so there is still a problem of large transmission delay.

[0051] In order to solve the above technical problems, this specification provides a multi-domain fusion method for a vehicle.

[0052] Based on the generation and sharing of data, a multi-domain fusion method for vehicles is proposed. Through data sharing, unnecessary similar data redundancy sources are reduced to achieve the goal of streamlining system design. In addition, the data between domains in the system is transmitted through the intermediate architecture, which can significantly improve the real-time and reliability of communication.

[0053] Specifically, install and configure the Hypervisor on a single SOC, set the rules and mechanisms for inter-domain communication in the Hypervisor, and ensure fast and reliable data interaction within the chip through the Hypervisor. Furthermore, the Hypervisor architecture can effectively solve the problems of relative independence of systems in various domains in smart cars, duplicate functions, and low sensor reuse, and realize multi-domain integration.

[0054] In this method, the vehicle's multi-domain fusion method can integrate information and technologies from multiple fields, improve the performance and reliability of the autonomous driving system, and provide strong support for achieving safer and more efficient autonomous driving.

[0055] Figure 4 A multi-domain fusion system for a vehicle on a single SOC is provided in an embodiment of this specification, which relies on a multi-domain fusion architecture created on a single SOC to implement a multi-domain fusion method for the vehicle.

[0056] The multi-domain fusion architecture includes: a hardware layer, a Hypervisor layer located above the hardware layer, and a virtual machine layer created by the Hypervisor.

[0057] The hardware layer is used to provide computing and storage capabilities for the entire system, including CPU, memory, storage, etc. During the design, Hypervisor is used to virtualize hardware devices such as cameras and displays, and virtual devices are allocated to each domain of the vehicle to ensure that these domains can access and use these devices normally. At the same time, Hypervisor uniformly manages and schedules shared hardware resources between multiple domains such as cameras to avoid resource conflicts and improve resource utilization.

[0058] The Hypervisor layer is used to create multiple Guest OS based on user configuration, such as Figure 4Guest OS1 and Guest OS2 in the Guest OS include corresponding applications. The functional domains used for integration in the intelligent driving vehicle run in the Guest OS to realize the functions of each functional domain. Hypervisor also has the following important functions: responsible for managing and allocating system resources (dynamically adjusting resource allocation according to the workload and priority of different domains to ensure that each domain can run stably), data isolation and security (ensuring that the data obtained by the intelligent driving domain is not accessed by other unauthorized domains, enhancing the security and stability of the system.), data backup and cache (while the intelligent driving domain obtains data, the Hypervisor can back up and cache the data so that it can be provided to other related domains (such as parking assistance domain) when needed (such as failure or abnormality in the intelligent driving domain).), coordination and scheduling (if in special circumstances, such as when the processing capacity of the intelligent driving domain reaches its limit, the Hypervisor can coordinate and control the data acquisition frequency of the camera or temporarily allocate part of the data to other domains with processing capacity for auxiliary processing.).

[0059] It should be noted that when designing a multi-domain fusion architecture, select a SoC chip that supports virtualization functions, ensure that it has sufficient processing power, memory controller, and high-speed bus interface, select a Hypervisor that suits the SoC architecture and application requirements, such as KVM, Xen, etc., integrate the Hypervisor into the SoC's software stack, and ensure compatibility with the underlying hardware and drivers.

[0060] Then, the hardware resources are abstracted and allocated to each Guest OS through the virtualization technology of the Hypervisor to ensure the normal operation of each Guest OS. The resource allocation mechanism for the Guest OS can also be determined according to the requirements of the functional domain running on the Guest OS.

[0061] The virtual machine layer includes multiple virtual machines created by the Hypervisor. A Guest OS is configured in the virtual machine to provide an environment for the Guest OS to run.

[0062] Compared with the large data transmission delay in the existing multi-domain fusion, in the multi-domain fusion system based on this multi-domain fusion architecture, the operating system Guest OS and applications in the virtual machine submit access requests to the Hypervisor, which is responsible for interacting with the hardware and returning the results to the virtual machine, completing the data interaction between the domains, and significantly improving the real-time and reliability of communication.

[0063] As an example, when an application in a virtual machine needs to access hard disk data, it sends a request to read the data to the Hypervisor through a unified interface. After receiving the request, the Hypervisor communicates with the hard disk, reads the data, and returns the data to the application.

[0064] In this way, unified interfaces and specifications simplify the interaction between virtual machines and hardware, improving the manageability and stability of the system.

[0065] Furthermore, the Hypervisor will set access permissions for each functional domain based on the virtual machine configuration, user role, and security policy to ensure that each virtual machine can operate normally without interfering with each other, while protecting the system from potential security threats and ensuring system stability and security.

[0066] In some embodiments, as chip technology continues to develop and high-performance heterogeneous chips continue to improve, in order to meet the real-time, safety, and functional requirements of vehicles, smart driving car SoCs are usually heterogeneous chips, generally including high-performance CPU cores (such as ARM Cotex-A), AI computing cores (such as GPUs), and security MCU cores (such as ARM Cortex-R). Therefore, another multi-domain fusion system for vehicles on a single SOC provided in an embodiment of this specification relies on a multi-domain fusion architecture created by heterogeneous cores on a single SOC to implement a multi-domain fusion method for vehicles.

[0067] like Figure 5 As shown, the multi-domain fusion architecture includes a hardware layer with heterogeneous cores, a Hypervisor layer located above the hardware layer, and a virtual machine layer created by the Hypervisor.

[0068] Based on the application requirements of each functional domain and the performance of heterogeneous cores, cores are allocated and managed in the Hypervisor, and different cores are allocated to different domains. Furthermore, different operating systems (such as the Guest OS running the intelligent driving domain) are installed and configured on high-performance CPU cores to meet the application requirements of different domains, provide a running environment for the total application of each domain, and improve the degree of application reuse.

[0069] Furthermore, the Hypervisor shields the SoC heterogeneity from the lower layer, provides hardware abstraction for the operating system and applications, and provides communication channels between different cores, abstracting the services between heterogeneous cores so that the heterogeneous cores can call the required services through the abstracted service interface. Specifically, the Hypervisor abstracts and manages the hardware resources of the SoC and provides a unified hardware interface for the operating system and applications. It establishes communication channels between different cores to ensure data transmission and service calls between heterogeneous cores. At the same time, it defines abstract service interfaces to encapsulate the services between heterogeneous cores so that the heterogeneous cores can call the required services through these interfaces.

[0070] In this embodiment, the hardware virtualization extension functions generally provide better support for multi-core processors, and the Hypervisor can use these functions to better allocate and manage multi-core resources and improve the efficiency of parallel processing.

[0071] As an example, in actual deployment, taking the fusion of the shared hardware camera of the intelligent driving domain and the cockpit domain as an example, the following steps can be followed:

[0072] Step a1: during the startup process of the SoC chip, the Hypervisor firmware is loaded.

[0073] Step a2: Create the intelligent driving domain and cockpit domain through the management interface of the Hypervisor, and allocate corresponding CPU cores and memory to them.

[0074] Step a3: Connect the camera to the SoC chip and virtualize it into a virtual camera accessible to both the intelligent driving domain and the cockpit domain through the Hypervisor.

[0075] Step a4: configure the communication channel in the Hypervisor so that the intelligent driving domain and the cockpit domain can exchange data through the service interface.

[0076] High-precision positioning service sharing can be achieved through multi-domain fusion. This solution can reduce the number of sensors, maximize resource sharing, and reduce the amount of system sensors while achieving the same functions and performance. For example, multi-domain fusion can be used to achieve the sharing of intelligent driving perception rearview cameras and electronic rearview mirrors.

[0077] The multi-domain fusion system of the vehicle constructed through the above embodiment realizes the deep fusion of various functional domains in the vehicle by using Hypervisor technology on a SoC. The rate and reliability of data transmission between domains can be significantly improved through Hypervisor. This system can reasonably use the computing resources of the hardware to realize multi-functional integration, and uniformly abstracts heterogeneous cores to provide communication channels between heterogeneous cores.

[0078] Figure 6 1 is a flow chart of a multi-domain fusion method for a vehicle provided in the first embodiment of this specification, comprising the following steps:

[0079] S100: Based on the abstracted service interface of the Hypervisor, a data interaction request sent by an application in a source domain in each functional domain of the vehicle to a target domain is received.

[0080] A multi-domain fusion architecture is created on the single SOC, wherein the multi-domain fusion architecture includes a hardware layer, a Hypervisor located above the hardware layer, and multiple Guest OSes created according to user configuration, wherein each functional domain used for fusion in the vehicle runs in the Guest OS, and the Hypervisor abstracts and allocates hardware resources to each Guest OS through virtualization technology.

[0081] The source domain described in this article refers to the functional domain that initiates requests and transmits data in data interaction, and the target domain refers to the functional domain that receives data in data interaction. For example, the intelligent driving controller is responsible for collecting sensor information, and after perception, regulation, control, decision-making and other operations, the control information is sent to the power and chassis systems to realize the intelligent driving of the vehicle. In this process, the intelligent driving system is deeply integrated with the network system and the cockpit system. For example, the intelligent driving system needs to transmit the vehicle's location, perception, regulation, warning, surround view image and other information to the cockpit system for display. The upgrade and data upload of the intelligent driving system also require support from the network system. In this example, the intelligent driving domain where the intelligent driving system is located is the source domain, and the chassis domain where the cockpit system is located is the target domain.

[0082] In step S100, the Hypervisor provides unified and standardized service interfaces for different functional domains. These interfaces abstract the underlying hardware and complex communication mechanisms, so that the application programs in the source domain do not need to understand the underlying technical details, but only need to call the interfaces in a prescribed manner to send data interaction requests.

[0083] Furthermore, when the source domain application in each functional domain of the vehicle needs to exchange data with other target domains, it will initiate a request by calling the service interface provided by the Hypervisor. This request contains the data to be sent by the source domain and relevant information of the target domain.

[0084] The specific process of providing a unified and standardized service interface for different functional domains by Hypervisor is as follows: First, conduct a demand analysis to clarify the communication requirements and service types of each functional domain. Then define the interface and data format, select the communication protocol, and make good resource management allocation. Then implement the interface code in Hypervisor, establish the registration and discovery, and permission management mechanisms. After that, conduct testing and verification, and optimize and update the interface according to the actual situation.

[0085] S200. According to a preset inter-domain communication mechanism, the data in the data interaction request is forwarded to the target domain through the Hypervisor, so that after receiving the data, the target domain parses and processes the data according to a set format to complete multi-domain fusion.

[0086] During the system design phase, a set of rules and processes are predefined to regulate the data communication mode, frequency, priority, etc. between different functional domains. These rules are stored in the Hypervisor and followed during the data forwarding process. Then, after the Hypervisor receives the request from the source domain, it determines the data transmission path and method according to the preset communication mechanism and forwards the data to the target domain accurately.

[0087] After receiving the data, the target domain will parse the data according to the pre-agreed format (such as a specific data structure, encoding method, etc.), extract useful information, and perform corresponding processing based on its own functions and logic.

[0088] Through such an orderly data interaction and processing process, collaborative work and information sharing between different functional domains are realized, and multi-domain integration of the vehicle system is achieved, thereby improving the performance, reliability and intelligence level of the entire vehicle system.

[0089] As an example, combining Figure 4 As shown in the figure, when the application (APP1 and / or APP2) in the vehicle's power system domain (configured in Guest OS1) needs to send the real-time operation data of the engine to the chassis control domain (configured in Guest OS2), it will send a data interaction request through the service interface of the Hypervisor. The Hypervisor forwards the data to the chassis control domain according to the preset communication mechanism, and the chassis control domain parses the data according to the agreed format and uses it to adjust the control strategy of the chassis.

[0090] In some embodiments, before forwarding the data in the data interaction request to the target domain through the Hypervisor according to the preset inter-domain communication mechanism, the method further includes:

[0091] S101, verifying the legitimacy of the data exchange request.

[0092] The legitimacy verification of the data interaction request described in this article includes at least one of authority verification, data format verification, and content integrity verification.

[0093] Among them, permission verification is to check whether the source domain has the permission to send data to the target domain. Based on the pre-set access control list or policy, it ensures that only authorized domains can initiate specific types of data interaction requests.

[0094] Data format verification is to confirm whether the data carried in the request conforms to the predetermined format specification. If the data format is incorrect, the target domain may not be able to parse and process it correctly, thus affecting the normal operation of the entire system.

[0095] Content integrity verification is to check whether the data in the request is complete and no key information is missing.

[0096] S102: Under legal circumstances, allocating required resources for data interaction between the source domain and the target domain through the Hypervisor.

[0097] After determining that the data interaction request is legitimate, the Hypervisor is then used to allocate the required resources for the data interaction between the source domain and the target domain. For example, memory resources, I / O network bandwidth resources, Cores computing resources, etc. are allocated. Allocate memory resources: Allocate enough memory space for the data to be transmitted to store the data in the transmission process. Allocate network bandwidth resources: Ensure that there is enough network bandwidth to support fast and stable data transmission to avoid data congestion or delays. Allocate computing resources: It may be necessary to allocate certain CPU computing resources for operations such as data processing, encryption / decryption (if necessary), etc.

[0098] In this embodiment, by first verifying the legitimacy of the data interaction request and then allocating the required resources to the legitimate request, the security and stability of the system can be improved and the efficient data interaction can be ensured.

[0099] Through the above embodiments, a multi-domain fusion solution is provided using a Hypervisor on a SoC. Since data interaction between two domains is achieved through a Hypervisor within the chip, this method is faster and more reliable than using in-vehicle Ethernet communication between chips.

[0100] Based on the above first embodiment, a second embodiment of a multi-domain fusion method for a vehicle is proposed.

[0101] S300, when the Hypervisor receives a hardware access request from an application in the source domain, reading data of the target hardware corresponding to the hardware access request through the Hypervisor;

[0102] S400, encapsulate the data, and forward the encapsulated data packet to the source domain, so that the source domain can analyze and process the data after receiving it.

[0103] When the Hypervisor receives a hardware access request from an application in the source domain, the Hypervisor communicates with the relevant hardware device based on the hardware identification and access parameters in the request to obtain the required data, which involves reading data through a hardware interface, driver, or specific communication protocol.

[0104] To ensure the integrity and security of data during transmission, the Hypervisor will encapsulate the read data. The encapsulation process may include adding header information, such as the source and target domain identifiers, the length of the data, a checksum, etc. In some embodiments, the data may also be encrypted to prevent the data from being stolen or tampered with during transmission.

[0105] The Hypervisor forwards the encapsulated data packet to the source domain through the established communication channel. After the source domain receives the data, the application in the source domain will first decapsulate the data packet, remove the header information and possible encryption layer, and obtain the original data.

[0106] As an example, an application in the source domain needs to obtain data from a vehicle sensor (such as a temperature sensor). After receiving the request, the Hypervisor reads the temperature value from the sensor, encapsulates it into a data packet containing the source domain identifier, the temperature value length, and a checksum, and then forwards it to the source domain. After receiving it, the source domain decapsulates it to obtain the temperature value and performs subsequent analysis, such as determining whether the temperature exceeds a threshold to decide whether to trigger a corresponding action (such as starting a cooling fan).

[0107] In some embodiments, when the Hypervisor receives a hardware access request from an application in the source domain, reading data of the target hardware corresponding to the hardware access request through the Hypervisor includes:

[0108] S310: When the Hypervisor receives a hardware access request from an application in a source domain, the Hypervisor parses the hardware access request and determines a request type.

[0109] The Hypervisor will perform a detailed analysis of the received request, including analyzing the instructions, parameters, and identifiers contained in the request, and then determine the specific type of the request, such as reading data, writing data, and performing specific hardware operations.

[0110] S320, checking the resource configuration of the Guest OS where the source domain is located.

[0111] The Hypervisor will check the resource configuration information pre-set for the Guest OS where the source domain is located. This includes checking the restrictions and configurations of the hardware resource permissions, available bandwidth, processing power, etc. allocated to the Guest OS.

[0112] S330: When resource configuration is satisfied, based on the request type, data is exchanged with the target hardware through the Hypervisor to read data of the target hardware corresponding to the hardware access request.

[0113] If the guest OS resource configuration is determined to support the current request type, the Hypervisor will establish a communication connection with the target hardware and perform the corresponding data interaction operation based on the specific type of request. For example, if it is a read request, the Hypervisor will obtain the required data from the target hardware.

[0114] As an example, an application in the source domain wants to read a large amount of data from a storage device. The Hypervisor first parses the request to determine that it is a read request, and then checks the resource configuration of the Guest OS where the source domain is located to confirm that it has sufficient bandwidth and permissions to perform such a large-scale read operation. If the resource configuration is satisfied, the Hypervisor will communicate with the storage device to read the data required by the application.

[0115] In this embodiment, by parsing the hardware access request and checking the resource configuration of the Guest OS where the source domain is located, it is ensured that the hardware resources are not over-occupied or abused, and the optimal allocation of resources is achieved. In addition, the request type is accurately parsed and targeted data interaction is performed, which reduces unnecessary operations and errors, thereby improving the operating efficiency of the entire system.

[0116] Based on the above first and second embodiments, a third embodiment of a multi-domain fusion method for a vehicle is proposed.

[0117] The hardware layer of the single SOC includes multiple heterogeneous cores. According to the resource requirements of the Guest OS and the characteristics of the heterogeneous cores, the Guest OS is matched with the heterogeneous cores to construct the multi-domain fusion architecture; wherein the heterogeneous cores interact with each other based on the service interface abstracted by the Hypervisor.

[0118] Smart driving car SoCs are usually heterogeneous chips, generally including high-performance CPU cores (such as ARM Cotex-A), AI computing cores (such as GPU), and security MCU cores (such as ARM Cortex-R). Figure 5As shown, the hypervisor of this solution spans different cores, and different operating systems can be run on high-performance CPU cores, providing an operating environment for applications to improve the reuse of applications. Among them, the workload of each Guest OS is analyzed in detail to determine its main computing types (such as integer operations, floating-point operations, vector operations, etc.), memory access modes (random access, sequential access, etc.) and real-time requirements, and to determine the characteristics of each heterogeneous core in terms of computing performance, power efficiency, cache structure, etc., as well as their adaptability to different types of computing and memory access. Based on the results of demand analysis and core feature evaluation, algorithms or strategies are used to determine which heterogeneous core is most suitable for a specific Guest OS. For example, for a Guest OS that is computationally intensive and has high real-time requirements, a heterogeneous core with a high main frequency and strong computing power will be matched; for a Guest OS that is sensitive to power consumption, a low-power heterogeneous core will be selected, thereby constructing the multi-domain fusion architecture. Among them, the Hypervisor designs a unified service interface, which shields the differences between the underlying heterogeneous cores and provides a consistent data format and calling method.

[0119] Based on the multi-domain fusion architecture, the data interaction process between heterogeneous cores based on the abstracted service interface of the Hypervisor is basically the same as the implementation method of data interaction based on the Hypervisor in the same processor core, which will not be repeated here.

[0120] In this embodiment, the Hypervisor spans different cores and can run different operating systems on high-performance CPU cores, providing an operating environment for applications and improving the reuse of applications. The lower-layer Hypervisor shields the SoC heterogeneity and provides hardware abstraction for the operating system and applications. Furthermore, the Hypervisor provides a communication channel between different cores, abstracts the services between heterogeneous cores, and enables heterogeneous cores to call the required services through the abstracted service interface.

[0121] In some embodiments, the method further comprises:

[0122] S500, monitoring the resource usage of each functional domain in real time through the service interface between the Hypervisor and the Guest OS, and determining the resource utilization rate of the data interaction process between the source domain and the target domain.

[0123] During the data interaction process between the source domain and the target domain, resource usage is monitored and the resource allocation strategy is dynamically adjusted to ensure smooth operation of data interaction.

[0124] Specifically, the Hypervisor continuously obtains data about resource usage such as CPU usage, memory usage, and network bandwidth usage from the service interface. Based on the collected data, the resource utilization of each functional domain during the data interaction process is calculated, such as the average CPU usage and the peak memory usage.

[0125] S600: When the resource utilization rate reaches an upper limit, analyzing data interaction characteristics between the source domain and the target domain.

[0126] When the resource utilization reaches the upper limit, it indicates that the data interaction task between the source domain and the target domain has used the specific resources to the maximum extent that it can obtain or be allocated, which may lead to system performance degradation, slow response, task queueing for resources, and even system crash or error. Therefore, the data interaction characteristics between the source domain and the target domain are analyzed, and the resource allocation strategy is adjusted to improve the operation of the system.

[0127] Among them, data interaction characteristics include data interaction traffic analysis, data interaction frequency and periodicity, data type and size, etc. For example, when analyzing data interaction traffic, check the traffic size and traffic change trend of data interaction to determine whether there is a sudden large amount of data transmission. If so, additional temporary resources can be allocated to the source domain and target domain that are performing large amounts of data transmission, such as increasing network bandwidth, memory buffer or CPU time slice, to cope with emergencies and ensure smooth data transmission.

[0128] S700, dynamically adjust the resource allocation strategy according to the analysis result and the importance and priority of the services carried by the source domain and the target domain to meet the needs of data interaction.

[0129] Including the following situations: If the business importance of the source domain and the target domain is high, and the resource utilization reaches the upper limit and affects the business performance, the Hypervisor allocates more CPU cores, memory or network bandwidth to them. If the business priorities of the two domains are similar, but one domain has tight resources and the other domain has idle resources, the idle resources will be allocated to the tight domain. In the case of limited resources, the priorities of the two domains are readjusted according to the importance of the business, giving priority to meeting the resource needs of important businesses.

[0130] In some embodiments, the dynamically adjusting resource allocation strategy includes:

[0131] S710: According to a preset resource adjustment frequency, a progressive adjustment strategy is adopted to allocate resources to the source domain and / or the target domain that needs to be adjusted.

[0132] The preset resource adjustment frequency described in this article refers to a preset time interval or trigger condition for re-evaluating and adjusting resources. For example, it can be set to check resource utilization every 5 minutes, or trigger adjustment when resource utilization exceeds 80%.

[0133] An incremental adjustment strategy means that resource allocation is not changed drastically at once, but rather is done gradually and in small increments.

[0134] As an example, assume that the source domain is a video processing module and the target domain is a data analysis module. The preset resource adjustment frequency is once every 10 minutes. During one adjustment, it is found that the resource utilization of the video processing module is too high and CPU resources need to be increased. First, increase the CPU time slice by 10%, wait 10 minutes and evaluate again. If it is still insufficient, increase it by another 10% until the resource utilization is within a reasonable range.

[0135] In this embodiment, the use of a progressive adjustment strategy can prevent excessive fluctuations in resource allocation from affecting system stability, and can more finely optimize resource allocation to adapt to dynamic requirements of the system.

[0136] like Figure 7 As shown, it is an example of cross-domain fusion data flow of electronic rearview mirror and 360-degree surround view function in the deep fusion method of intelligent driving domain and cockpit domain, which realizes the sharing of intelligent driving rearview camera and electronic rearview mirror camera, deep fusion of 360-degree surround view function and intelligent cockpit domain, and deep fusion of display function required for intelligent driving and cockpit domain.

[0137] Specifically, the camera is virtualized through the Hypervisor, so that the smart driving rearview camera and the electronic rearview mirror camera can be shared by multiple domains. The data of the 360-degree surround view function is transmitted to the smart cockpit domain through the Hypervisor to achieve deep integration.

[0138] The content required for intelligent driving, such as perception results, functional status, etc., is integrated and displayed with the cockpit domain through the Hypervisor.

[0139] In this embodiment, a deep integration of the intelligent driving domain and the cockpit domain is achieved, and the integrated data is transmitted on-chip through the hypervisor, which significantly improves the communication speed and reliability compared with off-chip transmission, and is conducive to the development of more integrated functions and performance improvement.

[0140] The present application provides a vehicle multi-domain fusion method, system, single SOC and computer-readable storage medium, by creating a multi-domain fusion architecture on a single SOC, the multi-domain fusion architecture includes a hardware layer, a Hypervisor layer located above the hardware layer and multiple Guest OS created according to user configuration, and each functional domain used for fusion in an intelligent driving vehicle runs on the Guest OS. Based on the multi-domain fusion architecture, Hypervisor is used for communication between the source domain and the target domain, and based on the abstracted service interface of the Hypervisor layer, a data interaction request sent by the application of the source domain in each functional domain of the vehicle to the target domain is received; according to the preset inter-domain communication mechanism, the data in the data interaction request is forwarded to the target domain through the Hypervisor, so that after the target domain receives the data, it parses and processes the data according to the set format to complete the multi-domain fusion, and reduces unnecessary similar data redundancy sources through data sharing, and the data between domains is transmitted through the Hypervisor, which can significantly improve the real-time and reliability of communication.

[0141] Based on the same application concept as the above method, the embodiment of the present application also proposes a multi-domain fusion device for a vehicle, such as Figure 8 shown.

[0142] The device comprises:

[0143] The data request module 802 is used to receive a data interaction request sent by an application in a source domain of each functional domain of the vehicle to a target domain based on the service interface processed by the hypervisor after abstraction;

[0144] The data transmission module 804 is used to forward the data in the data interaction request to the target domain through the Hypervisor according to a preset inter-domain communication mechanism, so that after the target domain receives the data, it parses and processes the data according to a set format to complete multi-domain fusion;

[0145] A multi-domain fusion architecture is created on the single SOC, and the multi-domain fusion architecture includes a hardware layer, a Hypervisor located above the hardware layer, and multiple Guest OSes created according to user configuration. Each functional domain used for fusion in the vehicle runs in the Guest OS, and the Hypervisor abstracts and allocates hardware resources to each Guest OS through virtualization technology.

[0146] The implementation process of the functions and effects of each module / submodule / unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and the same technical effect can be achieved, so it will not be repeated here.

[0147] Fig. 9The following is a schematic diagram of the physical structure of a multi-domain fusion device for a vehicle, such as Fig. 9 As shown, the multi-domain fusion device of the vehicle 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 through the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the multi-domain fusion method of the vehicle.

[0148] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0149] On the other hand, the present application also provides a computer program product, which includes a computer program. The computer program 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 multi-domain fusion method of the vehicle provided by the above-mentioned methods.

[0150] On the other hand, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which is implemented when the computer program is executed by a processor to execute the multi-domain fusion method of the vehicle provided by the above methods.

[0151] It should be noted that the technical solutions or technical features described in the above embodiments can be combined or supplemented with each other without causing conflicts. The scope of protection of this application is not limited to the precise structures described in the above embodiments and shown in the drawings; all modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims

1. A multi-domain fusion method for a vehicle, characterized in that: Applied to a single SOC, the method includes: Based on the abstracted service interface of the Hypervisor, the data interaction request sent by the application in the source domain of each functional domain of the vehicle to the target domain is received; According to a preset inter-domain communication mechanism, the data in the data interaction request is forwarded to the target domain through the Hypervisor, so that after receiving the data, the target domain parses and processes the data according to a set format to complete multi-domain fusion; Among them, the multi-domain fusion method of the vehicle is implemented based on the multi-domain fusion architecture on the single SOC, and the multi-domain fusion architecture includes a hardware layer, the Hypervisor located above the hardware layer, and multiple Guest OSes created according to user configuration. The Guest OS is configured with virtual hardware resources allocated after the functional domains used for fusion in the vehicle and the Hypervisor are processed by virtualization technology.

2. The multi-domain fusion method for a vehicle as claimed in claim 1, characterized in that: Before forwarding the data in the data interaction request to the target domain through the Hypervisor according to the preset inter-domain communication mechanism, the method further includes: Verifying the legitimacy of the data interaction request; Under legal circumstances, the Hypervisor allocates required resources for data interaction between the source domain and the target domain.

3. The multi-domain fusion method for a vehicle as claimed in claim 1, characterized in that: The method further comprises: When the Hypervisor receives a hardware access request from the application in the source domain, the Hypervisor reads data of the target hardware corresponding to the hardware access request; The data is encapsulated, and the encapsulated data packet is forwarded to the source domain, so that the source domain can analyze and process the data after receiving it.

4. The multi-domain fusion method for a vehicle as claimed in claim 3, characterized in that: When the Hypervisor receives a hardware access request from an application in the source domain, reading data of the target hardware corresponding to the hardware access request through the Hypervisor includes: When the Hypervisor receives a hardware access request from the application in the source domain, the Hypervisor parses the hardware access request and determines the request type; Checking the resource configuration of the Guest OS where the source domain is located; When resource configuration is satisfied, based on the request type, data is exchanged with the target hardware through the Hypervisor to read data of the target hardware corresponding to the hardware access request.

5. The multi-domain fusion method for a vehicle as claimed in claim 1, characterized in that: The hardware layer of the single SOC includes multiple heterogeneous cores. According to the resource requirements of the Guest OS and the characteristics of the heterogeneous cores, the Guest OS is matched with the heterogeneous cores to construct the multi-domain fusion architecture; wherein the heterogeneous cores interact with each other based on the service interface abstracted by the Hypervisor.

6. The multi-domain fusion method for a vehicle as claimed in claim 1, characterized in that: The method further comprises: Monitoring resource usage of each functional domain in real time through the service interface between the Hypervisor and the Guest OS, and determining resource utilization of the data interaction process between the source domain and the target domain; When the resource utilization rate reaches an upper limit, analyzing data interaction characteristics between the source domain and the target domain; Based on the analysis results and the importance and priority of the services carried by the source and target domains, the resource allocation strategy is dynamically adjusted to meet the needs of data interaction.

7. The multi-domain fusion method for a vehicle as claimed in claim 6, characterized in that: The dynamically adjusting resource allocation strategy includes: According to a preset resource adjustment frequency, a progressive adjustment strategy is adopted to allocate resources to the source domain and / or the target domain that needs to be adjusted.

8. A multi-domain fusion system for a vehicle, characterized in that: The system comprises: The virtual hardware layer is formed by abstracting the physical hardware resources on a single SOC through hypervisor virtualization technology, and is used to provide computing and storage capabilities for the entire system; A Hypervisor layer, located above the virtual hardware layer, is used to create multiple Guest OSes according to user configuration, and abstract and allocate the physical hardware resources to each Guest OS through virtualization technology; and The virtual machine layer includes a plurality of virtual machines created by a hypervisor, the Guest OS is configured in the virtual machine, and the Guest OS is configured with virtual hardware resources allocated after the functional domains used for fusion in the vehicle and the hypervisor layer are processed by virtualization technology.

9. A single SOC, characterized in that: The invention comprises a memory, a processor and a multi-domain fusion program of a vehicle stored in the memory and executable on the processor, wherein when the processor executes the multi-domain fusion program of the vehicle, the steps of the multi-domain fusion method of the vehicle as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a multi-domain fusion program for the vehicle, and when the multi-domain fusion program for the vehicle is executed, the steps of the multi-domain fusion method for the vehicle as described in any one of claims 1-7 are implemented.

Images