A cross-domain data fusion method and system based on CAN bus

Abstract

The embodiment of the application provides a cross-domain data fusion method based on a CAN bus, comprising: each ECU unit sends CAN equipment data to an MCU through the CAN bus; the MCU sends the received CAN equipment data to an SOC through an SPI interface; the SOC processes the data, and distributes parameters obtained according to a pre-registered registration process of an upper-layer service to a corresponding upper-layer service module, wherein the parameters comprise CAN-ids of CAN equipment of each domain; and the upper-layer service module processes the data of the CAN equipment of each domain. The application realizes transparent transmission and fusion sharing of CAN bus data from each domain without modifying the MCU, reduces the development cost of the MCU, reduces the system load, and improves the data processing efficiency.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicle technology, and more particularly to a cross-domain data fusion method, system, electronic device, and computer storage medium based on CAN bus. Background Technology

[0002] With the rapid development of intelligent cockpit technology, a single SOC can handle more business. Its network bandwidth expansion, low latency, and service differentiation characteristics make business deployment and function allocation more flexible, allowing automotive business functions to be separated, combined, and software-defined. Meanwhile, the automotive electronic and electrical architecture has evolved from a distributed architecture to a domain-centralized architecture, and then to a centrally centralized architecture. The functions of the distributed vehicle electronic control units (ECUs) are being integrated into domain controllers or even the vehicle's central computer, thereby achieving multi-domain convergence.

[0003] Based on the current mainstream smart cockpit hardware solutions, the communication between the vehicle microcontroller unit (MCU) and the vehicle system-on-a-chip (SOC) is mainly through the SPI (Serial Peripheral interface) bus. The MCU receives data from various fields transmitted by each ECU through the CAN interface, and then transmits it to the SOC through the SPI interface. The SOC then sends the received data to the upper-layer business modules, such as the instrument panel and network-side devices. Each upper-layer business module then performs its own filtering and parsing of the received data.

[0004] Since all business logic processing of the data is completed by the upper-layer business module, the disadvantage of this hardware solution is that when the amount of data passed to the SOC is too large, it will increase the load on the entire system and individual upper-layer applications. Furthermore, when multiple upper-layer applications need to obtain CAN device data, the corresponding upper-layer business modules need to parse it separately, resulting in low data processing efficiency.

[0005] Based on the hardware architecture described above, another approach is for the MCU to be responsible for filtering CAN device data. The application service in the QNX operating system uses the communication protocol to control the MCU to perform data parsing, such as parameter filtering and data acquisition. The disadvantage of this approach is that the MCU is not stable enough. When adding upper-layer application functions or adding filtering nodes, the MCU needs to be debugged and modified. In addition, it is not flexible enough. After the MCU performs data parsing, it needs to construct a data structure and modify the protocol before data transmission can be performed.

[0006] Therefore, there is an urgent need for a solution to realize cross-domain converged communication of CAN gateways, which can achieve transparent transmission of CAN events from various domains while reducing MCU development costs, reducing system load, and improving data processing efficiency when using the CAN bus for communication.

[0007] Application content

[0008] To address the shortcomings of existing technologies, this application provides a cross-domain data fusion method and system, electronic device, and computer storage medium based on CAN bus, so as to realize the transparent transmission of data generated by CAN devices in various domains, while reducing MCU development costs, reducing system load, and improving data processing efficiency.

[0009] To address the aforementioned technical problems, embodiments of this application provide a cross-domain data fusion method based on a CAN bus, the method comprising:

[0010] Each ECU unit sends CAN device data to the MCU via the CAN bus;

[0011] The MCU sends the received CAN device data to the SOC via the SPI interface;

[0012] The SOC processes the data and distributes it to the corresponding upper-layer service modules according to the parameters obtained from the registration process of the pre-registered upper-layer services. The parameters include the CAN-id of each domain.

[0013] The upper-layer business module processes the CAN device data from each domain.

[0014] Furthermore, the method also includes:

[0015] The upper-layer business module acts as the client, registers with the service, and simultaneously registers a callback function.

[0016] After receiving data from the CAN device, the service side notifies the client side through the callback function on the service side.

[0017] Preferably, the registration process for the upper-layer service includes:

[0018] After receiving the registration request, the registration module parses and saves the filter parameters, and sets the CAN enable parameters in the driver module to turn on the communication switch with the CAN device.

[0019] After receiving the registration request, the filtering module parses and obtains the filtering parameters, and then sets the operating parameters of the CAN gateway according to the filtering parameters.

[0020] Preferably, the operating parameters include filtering method, acceptance code, masking code, and operating mode.

[0021] Preferably, the SOC processes the data specifically including:

[0022] Virtual machines on the SOC open up a shared cache area through the virito protocol, which is accessed by both QNX and Linux.

[0023] After receiving data from the upper-layer application, the Linux kernel driver converts the data into data conforming to the CAN message structure and stores the converted data in the transmit shared buffer in a first-in-first-out manner, and notifies the QNX operation node backend to retrieve the data.

[0024] After receiving the notification, the QNX operation node backend parses the converted data and sends the parsed data to the CAN bus.

[0025] Furthermore, the SOC's data processing also includes:

[0026] When QNX receives a message from the CAN bus, it places it in QNX's transmit buffer and notifies the Linux network node frontend to receive the data.

[0027] After receiving data from the QNX operation node backend, the Linux network node frontend notifies the upper-layer business module through the registration module.

[0028] Secondly, to address the technical problems of this application, embodiments of this application also provide a cross-domain data fusion system based on a CAN bus. The system includes: a registration module, an upper-layer service module, a filtering module, a driver module, and a communication module.

[0029] The registration module is used to receive registration applications sent by the upper-layer business modules, register the upper-layer applications or services that need to use the data of CAN devices in each domain to the CAN gateway, and use the CAN ID of the CAN device as a unique identifier.

[0030] The filtering module is used to set the filtering parameters of the upper-layer application or service registered by each upper-layer business module after the upper-layer application or service is successfully registered, and to filter the data according to the filtering parameters when the SOC receives data sent by the CAN devices of each domain.

[0031] The driver module is used to apply for a shared buffer based on the virtual virtio bus for communication in each domain, according to the distinction between the applications or services of the upper-layer business modules of each domain.

[0032] The communication module is used to receive data sent by CAN devices in various domains through the shared buffer based on the virtual virtio bus, and distribute the data filtered by the filtering module to the registered upper-layer service modules.

[0033] Thirdly, in order to solve the technical problems of this application, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the cross-domain data fusion method based on the CAN bus as described above.

[0034] Fourthly, in order to solve the technical problems of this application, embodiments of this application also provide a computer storage medium storing computer instructions, which, when executed by at least one processor, implement the steps of the aforementioned cross-domain data fusion method based on CAN bus.

[0035] This application presents a cross-domain data fusion method based on the CAN bus. In an intelligent cockpit platform system, the CAN bus is used for communication. In the virtual operating system of the virtual cockpit system, callback function calls can be used to perform data access operations on the CAN devices. At the same time, by transmitting data of batch CAN devices on the virtual virtio bus device, the transparent transmission and fusion sharing of CAN bus data from various domains are realized without modifying the MCU. This reduces the development cost of the MCU, reduces the system load, and improves the data processing efficiency. Attached Figure Description

[0036] The following is a brief introduction to the accompanying drawings used in the description of the embodiments of this application:

[0037] Figure 1 This is a communication diagram of the hardware solution for an existing smart cockpit.

[0038] Figure 2 This is a schematic diagram illustrating the implementation of the functional modules of the in-vehicle intelligent cockpit based on CAN bus data fusion in an embodiment of this application;

[0039] Figure 3 This is a system logic block diagram of the virtual virtio-CAN bus according to an embodiment of this application;

[0040] Figure 4 This is a schematic diagram illustrating the implementation of the cross-domain data fusion method based on the CAN bus in this application embodiment. Detailed Implementation

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the specific implementation methods of this application will be described below with reference to the accompanying drawings. The accompanying drawings described below are merely some embodiments of this application. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without creative effort. Adjustments and improvements made without departing from the concept of this application are all within the protection scope of this application.

[0042] To keep the drawings concise, the figures in this application only schematically show the parts relevant to this application, and they do not represent the actual structure of the product. Furthermore, to make the drawings concise and easy to understand, some figures only schematically show parts of components with the same structure or function; in reality, there may be more or fewer components with the same structure or function.

[0043] In this application, unless otherwise expressly specified and limited, ordinal numbers, such as "first," "second," etc., are used only to distinguish and describe related objects, and should not be construed as indicating or implying the relative importance or order between related objects; furthermore, they do not represent the number of related objects. "And / or" is used to describe the relationship between related objects, which includes any relationship between the related objects; for example, "a and / or b" includes: "a alone," "b alone," or "a and b." The terms "installation" and "connection" should be interpreted broadly; for example, "installation" can be direct installation or installation via other components; "connection" can be direct connection or connection via other components. The term "relative arrangement" includes parallel relative or relative at a certain angle, the angle of which is not limited and is determined according to the number of objects in the relative arrangement.

[0044] In the embodiments shown in the accompanying drawings, the directional indications (such as up, down, left, right, front, and back) are relative rather than absolute when describing the structure and movement of the various components, and are not intended to limit the direction of the product during actual use.

[0045] like Figure 2 The diagram shows the functional modules of a cross-domain data fusion system for an in-vehicle intelligent cockpit based on the CAN bus.

[0046] A cross-domain data fusion system based on CAN bus, the system comprising: a registration module, an upper-layer service module, a filtering module, a driver module, and a communication module, wherein...

[0047] The registration module is used to receive registration applications sent by the upper-layer business modules, register the upper-layer applications or services that need to use the data of CAN devices in each domain to the CAN gateway, and use the CAN ID of the CAN device as a unique identifier.

[0048] The filtering module is used to set the filtering parameters of the upper-layer application or service registered by each upper-layer business module after the upper-layer application or service is successfully registered, and to filter the data according to the filtering parameters when the SOC receives data sent by the CAN devices of each domain.

[0049] The driver module is used to apply for a shared buffer based on the virtual virtio bus for communication in each domain, according to the distinction between the applications or services of the upper-layer business modules of each domain.

[0050] The communication module is used to receive data sent by CAN devices in various domains through the shared buffer based on the virtual virtio bus, and distribute the data filtered by the filtering module to the registered upper-layer service modules.

[0051] Among them, the upper-layer business modules mainly include various upper-layer applications or services, such as information display and reporting functions for various domains of the vehicle body;

[0052] The registration module is used to receive registration requests sent by upper-layer business modules, register upper-layer applications or services that need to use CAN device data in each domain to the CAN gateway, and use the CAN ID as a unique identifier so that the upper-layer applications or services will not transmit data to other services that do not need the data when transmitting data.

[0053] The filtering module is used to set the filtering parameters for the applications or services registered by each upper-layer business module after the upper-layer application or service has been successfully registered, and to filter the data according to the filtering parameters when the SOC receives data sent by the CAN devices of each domain.

[0054] The communication module is used to receive data sent by CAN devices in each domain and distribute the filtered data to the registered upper-layer service modules.

[0055] The driver module for CAN devices is differentiated by the application or service of the upper-layer business module. Some driver modules are based on the QNX system (such as central control and instrument panel), while others are based on the Linux system (such as entertainment services and information display APP).

[0056] In existing technologies, driver modules based on Linux systems require an additional protocol conversion layer because the data sent by the CAN bus needs to be transmitted to the Linux-based application via SOCKET communication. This increases development complexity and system load.

[0057] To address the aforementioned issues, the implementation scheme of this application modifies the business logic of the driver module, thereby enabling communication between upper-layer services based on QNX and Linux via the CAN bus. The specific communication method is implemented using vrings technology based on the virtual virtio bus.

[0058] The Virtio bus uses a Guest to implement the front-end driver and a Host to implement the back-end driver, with data exchanged between the front-end and back-end via virtqueue.

[0059] The mechanism for performing bulk data transfer on a virtual virtio bus device (virtio device for short) is called virtqueue. virtqueue is implemented through vrings, which is a way for a guest to exchange data with its host.

[0060] In this embodiment, Vring is a circular shared buffer shared between the virtual machine and PVM. Both the PVM and the front-end driver can read and store data from the circular shared buffer (Vring). Here, PVM refers to PhysicalVM, which is implemented based on the QNX device driver, while the front-end driver is implemented based on the Linux or Android device driver.

[0061] Each virtio device can have zero or more virtqueues. When the driver module wants to send data to the virtio device, it populates one or more entries in the Descriptor Table (these entries are linked together) and writes the descriptor index to the Available Ring. Then it notifies the virtio device. When the virtio device has finished receiving the data, it writes the descriptor index to the Used Ring and sends an interrupt.

[0062] The transmission protocol uses virtio queues. Each virtio device has several queues, and each queue handles different data transmissions (e.g., virtio-balloon contains ivq, dvq, and svq).

[0063] refer to Figure 3 The diagram illustrates the framework, where GVM is the guest virtual machine and PVM is the physical virtual machine. The Virtio-CAN driver module, based on the CAN bus, controls the physical CAN device on the PVM side and provides standard CAN device control on the GVM side, but the actual operation is implemented in the PVM.

[0064] The CAN device control process involves opening the CAN device via the CAN driver [GVM]. From the user space perspective, this CAN device is the actual CAN device. At the driver layer, the device control information is transmitted to the CAN client [PVM] via the virtio bus. Then, after processing by the CAN resmgr (QNX's resource manager), the actual CAN driver [PVM] is finally invoked to control the CAN device.

[0065] The status information of the CAN device is reported by the CAN driver [PVM] and then passed to resmgr [pvm] and CANclient [PVM], which in turn pass it to the driver on the GVM side via the virtio bus.

[0066] This enables cross-domain data sharing between QNX and Android based on the virtio Vring mechanism.

[0067] like Figure 4 As shown, the cross-domain data fusion method based on the CAN bus in this application includes:

[0068] S1. Each ECU unit sends CAN device data to the MCU via the CAN bus;

[0069] S2. The MCU sends the received CAN device data to the SOC via the SPI interface;

[0070] S3.SOC processes the data and distributes it to the corresponding upper-layer service modules according to the parameters obtained from the registration process of the pre-registered upper-layer services. The parameters include CAN-id.

[0071] For example, if it is a QNX-driven instrument business, it is sent to the QNX instrument business module; if it is a cockpit-related business, it is sent to Android or Linux.

[0072] S4. The upper-layer business module processes the CAN device data from each domain.

[0073] The upper-layer business module acts as the client, registers with the service, and registers a callback function. After receiving data from the CAN device, the service notifies the client through the callback function on the service side. The client then performs the relevant processing, without needing to poll to obtain CAN information.

[0074] Through this callback function, the client can obtain data in a timely manner. After the service receives the data from the CAN device, it notifies the client through the service's callback function, and the client performs the relevant processing. The client does not need to poll to obtain CAN information.

[0075] Preferably, the registration process for the upper-layer service includes:

[0076] S001. After receiving the registration request, the registration module parses and saves the filter parameters, and sets the CAN enable parameters in the driver module to turn on the communication switch with the CAN device.

[0077] S002. After receiving the registration request, the filtering module parses and obtains the filtering parameters, and then sets the working parameters of the CAN gateway according to the filtering parameters. The working parameters include: filtering method, acceptance code, masking code, and working mode.

[0078] In a preferred embodiment of this application, S3 specifically includes:

[0079] 3.1. The virtual machine on the SOC opens a shared cache area through the virito protocol, which is accessed by both QNX and Linux;

[0080] In Linux, there is a network node frontend for the virtual CAN device, and in QNX, there is an operation node backend for the actual CAN device. The frontend is not responsible for the physical operation of the actual CAN device; the physical operation is performed by the backend.

[0081] In the implementation of this application, virtio, as a general virtual I / O device driver model, defines two standard models and interfaces: 1. Device configuration and initialization on the control plane; 2. Data transmission on the data plane.

[0082] 3.2. After receiving data from the upper-layer application, the Linux kernel driver converts the data into data conforming to the CAN message structure, stores the converted data in the transmit shared buffer in a first-in-first-out manner, and notifies the QNX operation node backend to retrieve the data;

[0083] 3.3. After receiving the notification, the QNX operation node backend parses the converted data and sends the parsed data to the CAN bus.

[0084] In a preferred embodiment of this application, the method further includes:

[0085] 3.4. QNX receives a message from the CAN bus, places it in QNX's transmit buffer, and notifies the Linux network node frontend to receive the data;

[0086] 3.5. After receiving data from the QNX operation node backend, the Linux virtual CAN device notifies the upper-layer business module through the registration module.

[0087] This application presents a cross-domain data fusion method based on the CAN bus. In an intelligent cockpit platform system, the CAN bus is used for communication. In the virtual operating system (Android) of the virtual cockpit system, callback function calls can be used to perform data access operations on the CAN devices. At the same time, by performing batch data transmission of CAN devices on the virtual virtio bus device, the transparent transmission and fusion sharing of CAN bus data from various domains are realized without modifying the MCU. This reduces the development cost of the MCU, reduces the system load, and improves data processing efficiency.

[0088] To address the aforementioned technical problems, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the cross-domain data fusion method based on the CAN bus as described above.

[0089] To address the aforementioned technical problems, this application also provides a computer storage medium storing computer instructions that, when executed by at least one processor, implement the steps of the CAN bus-based cross-domain data fusion method described above.

[0090] It is understood that the computer storage medium in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The computer storage media of the systems and methods described herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0091] The processor may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the processor's hardware or by software instructions. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0092] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0093] For software implementation, the techniques described herein can be achieved through modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or externally.

[0094] Alternatively, as another embodiment, the processor is also configured to perform the steps of the method described in the foregoing embodiments when running the computer program.

[0095] From the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0096] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0097] It should be noted that the above embodiments can be freely combined as needed. The above are only some embodiments of this application. For those skilled in the art, several improvements and modifications can be made without departing from the principles of this application, and these improvements and modifications should also be considered within the protection scope of this application.

Claims

1. A cross-domain data fusion method based on CAN bus, characterized in that, The method includes: Each ECU unit sends CAN device data to the MCU via the CAN bus; The MCU sends the received CAN device data to the SOC via the SPI interface; The SOC processes the CAN device data and distributes the processed data to the corresponding upper-layer service modules according to parameters obtained from the registration process of the pre-registered upper-layer services. These parameters include the CAN-id of the CAN device in each domain. The registration process of the upper-layer services includes: upon receiving a registration request, the registration module parses and saves the filtering parameters, and sets the CAN enable parameters in the driver module to enable communication with the CAN device; upon receiving a registration request, the filtering module parses and obtains the filtering parameters, and sets the operating parameters of the CAN gateway according to these parameters. These operating parameters include the filtering method, acceptance code, masking code, and operating mode. Specifically, the SOC processes the CAN device data including: The virtual machine on the SOC opens a shared buffer via the Virito protocol. This shared buffer is accessed by both QNX and Linux. After receiving data from the upper-layer application, the Linux kernel driver converts the data into data conforming to the CAN message structure and stores the converted data in the transmit shared buffer in a first-in-first-out manner. It then notifies the QNX operation node backend to retrieve the data. Upon receiving the notification, the QNX operation node backend parses the converted data and sends the parsed data to the CAN bus. The SOC's processing of the CAN device data also includes: When QNX receives a message from the CAN bus, it places it in the QNX transmit buffer and notifies the Linux network node frontend to receive the data. After receiving the data from the QNX operation node backend, the Linux network node frontend notifies the upper-layer service module through the registration module. The upper-layer business module processes the data from the CAN devices in each domain.

2. The cross-domain data fusion method based on CAN bus as described in claim 1, characterized in that, The method further includes: The upper-layer business module acts as the client, registers with the service, and simultaneously registers a callback function. After receiving data from the CAN device, the service side notifies the client side through the callback function on the service side.

3. A CAN bus-based cross-domain data fusion system based on the CAN bus-based cross-domain data fusion method of claim 1 or 2, characterized in that, The system includes: a registration module, an upper-layer business module, a filtering module, a driver module, and a communication module, wherein... The registration module is used to receive registration applications sent by the upper-layer business modules, register the upper-layer applications or services that need to use the data of CAN devices in each domain to the CAN gateway, and use the CAN ID of the CAN device as a unique identifier. The filtering module is used to set the filtering parameters of the upper-layer application or service registered by the upper-layer business module of each domain after the upper-layer application or service is successfully registered, and to filter the data according to the filtering parameters when the SOC receives the data sent by the CAN device of each domain. The driver module is used to apply for a shared buffer based on the virtual virtio bus for communication in each domain, according to the distinction between the applications or services of the upper-layer business modules of each domain. The communication module is used to receive data sent by CAN devices in various domains through the shared buffer based on the virtual virtio bus, and distribute the data filtered by the filtering module to the registered upper-layer service modules.

4. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the cross-domain data fusion method based on CAN bus as described in any one of claims 1 to 2.

5. A computer storage medium, characterized in that, The computer storage medium stores computer instructions that, when executed by at least one processor, implement the steps of the cross-domain data fusion method based on the CAN bus as described in any one of claims 1 to 2.

Images