Vehicle-mounted message middleware processing method and system and intelligent cabin thereof
By adopting decentralized on-vehicle message middleware processing methods in the autonomous driving smart cockpit, the delay and redundancy problems in multi-platform system communication are solved, and an efficient, flexible and reliable communication mechanism is achieved, improving system performance and development are improved. efficiency.
Patent Information
- Application Number
- CN202411380444.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-30
- Publication Date
- 2025-02-14
AI Technical Summary
In the development of autonomous driving smart cockpit applications, communications of multiple different platform systems lead to data delays, system redundancy, maintenance difficulties and low development efficiency, and inconsistent use of message middleware, resulting in poor system scalability and poor reusability.
Adopt a decentralized on-board message middleware processing method, and implements data type abstraction and decoupling by defining the abstract interface layer and hardware abstraction layer. Based on Fast DDS as message middleware, it supports "publish-subscribe" and "client- Server" communication mode.
Simplifies the user interface, improves communication speed, reduces CPU usage, enhances system performance, supports calls from multiple programming languages, improves development efficiency and system compatibility, and sets different service quality strategies according to communication scenarios to ensure Reliability and real-timeness of data transmission.
Smart Images

Figure CN119440871A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a processing method, a system and an intelligent cockpit thereof, and in particular to a vehicle-mounted message middleware processing method, a system and an intelligent cockpit thereof. Background Art
[0002] In the development of autonomous driving smart cockpit applications, the platforms involved include Android, Qnx, Linux, etc., and many business scenarios involve communication between different platform systems with different transmission protocols and data types. Therefore, many types of communication middleware are required, and the data link becomes longer, resulting in data delay or system redundancy. In addition, different message middlewares are used in different ways, which leads to a series of problems such as troublesome system maintenance in the later stage, low development efficiency, coupling of communication middleware with data, and difficulty in expansion. Among them, the following problems need to be solved:
[0003] 1. Different protocols have different interface calls, data types, and communication models, which requires separate application adaptation during use;
[0004] 2. Due to the differences in protocols, if the system is migrated or the business is changed in the later stage, the development and maintenance costs will increase, and the system has poor scalability and reusability;
[0005] 3. Because different businesses involve different protocols, the system code needs to be adjusted according to the business. When problems occur, it is difficult to troubleshoot due to the long links;
[0006] 4. Due to the existence of different types of message middleware, the amount of system code increases and the difficulty of maintenance increases.
[0007] The above problems have not been effectively solved, can no longer meet people's requirements, and are in urgent need of improvement. Summary of the invention
[0008] The purpose of the present invention is to provide a vehicle message middleware processing method, system and intelligent cockpit thereof, so as to solve the problems such as the difficulty in adapting communication services caused by various different protocols in the middle layer of the software, and to solve the shortcomings of the prior art.
[0009] The present invention provides the following scheme:
[0010] A decentralized vehicle-mounted message middleware processing method, applied to a decentralized vehicle-mounted message middleware processing system, comprising:
[0011] Define an abstract interface layer for abstracting and decoupling data types, and create a data structure framework through template classes and interface classes;
[0012] Creating a communication interface based on a hardware abstraction layer, and performing cross-device communication and cross-process communication through the abstract interface layer;
[0013] Based on the communication interface, Fast DDS is used as the message middleware in the communication protocol transmission layer, and communication interaction is carried out through the "publish-subscribe" or "client-server" communication mode;
[0014] The abstract interface layer is encapsulated at the application layer, and communication nodes are created at the communication interface layer according to the communication protocol and QoS strategy. The communication nodes are used to manage objects of the communication mode across processes, across devices, and within processes.
[0015] Furthermore, the definition is used to implement an abstract interface layer for data type abstraction and decoupling, and a data structure framework is created through template classes and interface classes, further including:
[0016] An interface component is defined in the abstract interface layer, wherein each interface in the interface component corresponds to a data type;
[0017] Create a corresponding template class for each data type, define an interface mapping mechanism based on the template class, and dynamically associate the data type with the corresponding template class when the vehicle-mounted messaging middleware is running;
[0018] The data type registration and serialization mechanism are performed through the interface mapping mechanism. The data type registration is used to register user-defined data types, and the serialization mechanism is used for data serialization and deserialization operations.
[0019] Furthermore, the creating of a communication interface based on a hardware abstraction layer and performing cross-device communication and cross-process communication through the abstract interface layer further includes:
[0020] Defining a communication interface: defining a communication interface component in the hardware abstraction layer, encapsulating a corresponding hardware communication protocol for each interface through the communication interface component, and performing cross-device communication and cross-process communication based on the communication interface component;
[0021] Packaging and parameter configuration: configure the parameters of the communication interface in the communication interface component and set up corresponding different hardware communication protocols, including TCP / IP protocol and serial communication protocol;
[0022] Dynamic binding and multi-threaded processing: A dynamic binding mechanism is implemented for the communication interface component, so that the communication interface can select and bind different communication interfaces according to communication requirements at runtime to achieve multi-threaded communication processing.
[0023] Furthermore, the communication interface adopts Fast DDS as the message middleware in the communication protocol transport layer, and performs communication interaction through the "publish-subscribe" or "client-server" communication mode, further including:
[0024] Configure Fast DDS message middleware in the communication protocol transport layer to support the corresponding communication mode;
[0025] Encapsulate the interface of Fast DDS message middleware and configure QoS policy to form the corresponding communication interface;
[0026] Dynamically create communication nodes for managing communication modes based on communication protocols and QoS policies for cross-process, cross-device, and intra-process communication;
[0027] Establish data caching mechanisms and define data serialization and deserialization patterns for data exchange formats.
[0028] Further, the abstract interface layer is encapsulated at the application layer, and a communication node is created at the communication interface layer according to the communication protocol and the QoS policy, wherein the communication node is used to manage objects of the communication mode across processes, across devices, and within processes, further comprising:
[0029] Case No.: FAW042481-C-XCN1240698 3
[0030] The abstract interface layer is encapsulated through JNI encapsulation at the application layer, and communication nodes are dynamically created at the communication interface layer according to the communication protocol and QoS strategy. The communication nodes are used to manage cross-process, cross-device and intra-process communications;
[0031] In each communication node, based on the logic processing of different communication modes, data consistency processing in a cross-language environment is achieved through JNI encapsulation;
[0032] Communication protocols are adapted based on the interface calling mechanism, and data interactions between different protocols are processed.
[0033] Furthermore, the abstract interface layer is encapsulated by JNI encapsulation at the application layer, specifically:
[0034] Define JNI interface: define native methods in Java application and declare local interfaces, which will be mapped to functions implemented in C++;
[0035] Implement native functions: Implement native functions corresponding to declared native Java methods in C++ code and ensure that these functions can be called through the JNI environment;
[0036] Configure the JNI environment: configure the JNI environment at the interaction point between Java and C++ codes, implement the local function corresponding to the declared native Java method in the C++ code, and the local function is used for JNI environment calling;
[0037] Thread management: manage threads called by JNI interfaces, map and synchronize threads between the Java virtual machine and native code.
[0038] A decentralized vehicle-mounted message middleware processing system, used to implement the decentralized vehicle-mounted message middleware processing method, comprising:
[0039] Abstract interface layer definition module, which defines the abstract interface layer used to implement data type abstraction and decoupling, and creates a data structure framework through template classes and interface classes;
[0040] A communication interface creation module, which creates a communication interface based on a hardware abstraction layer, and performs cross-device communication and cross-process communication through the abstract interface layer;
[0041] Case No.: FAW042481-C-XCN1240698 4
[0042] A message middleware communication interaction module uses Fast DDS as a message middleware in the communication protocol transmission layer based on the communication interface, and performs communication interaction through a "publish-subscribe" or "client-server" communication mode;
[0043] The communication node creation module encapsulates the abstract interface layer at the application layer, and creates communication nodes at the communication interface layer according to the communication protocol and QoS strategy. The communication nodes are used to manage objects in the communication mode across processes, across devices, and within processes.
[0044] A smart cockpit is provided with the decentralized in-vehicle message middleware processing system.
[0045] An electronic device comprises: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the method.
[0046] A computer-readable storage medium stores a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the method.
[0047] Compared with the prior art, the present invention has the following advantages:
[0048] The in-vehicle message middleware provided by the present invention simplifies the user interface and supports two main communication modes: publish-subscribe mode and request-response mode. The publish-subscribe mode allows asynchronous communication between publishers and subscribers of messages, while the request-response mode supports synchronous communication, so that the system can flexibly select the communication mode according to the application scenario.
[0049] The present invention adopts a shared memory communication mode during internal communication of the vehicle-mounted system, which significantly improves the communication speed and reduces the CPU usage, reduces the data duplication overhead, and thus improves the overall performance of the system.
[0050] The present invention supports calling of two programming languages, Java and C++, and realizes cross-language communication between Java and C++, so that developers can take advantage of the advantages of their respective languages, thereby improving development efficiency and system compatibility.
[0051] The present invention allows users to set different quality of service (QoS) configuration strategies according to different communication scenarios, improves the reliability, real-time nature and security of data transmission, ensures that the system can meet diverse communication needs, and provides stable and efficient intra-process communication, inter-process communication and inter-domain communication mechanisms. Whether within a single device or in a distributed system across devices, the present invention can ensure the stability and efficiency of data transmission.
[0052] The present invention supports multiple abstract data types, including interface definition language (IDL), Google's protocol buffer (protobuf), string, array, etc., which can cover the data structure requirements within the vehicle body domain, so that the vehicle system can flexibly process various data formats. BRIEF DESCRIPTION OF THE DRAWINGS
[0053] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0054] Figure 1 It is a flow chart of a decentralized in-vehicle message middleware processing method.
[0055] Figure 1A It is a flow chart of the optimization technical solution of step S1.
[0056] Figure 1B It is a flow chart of the optimization technical solution of step S2.
[0057] Figure 1C It is a flow chart of the optimization technical solution of step S3.
[0058] Figure 1D It is a flow chart of the optimization technical solution of step S4.
[0059] Figure 2 This is the architecture diagram of the decentralized in-vehicle message middleware processing system.
[0060] Figure 3 This is the overall framework diagram of the message middleware.
[0061] Figure 4 This is a detailed diagram of the message middleware structure.
[0062] Case No.: FAW042481-C-XCN1240698 6
[0063] Figure 5 It is an asynchronous communication mode of message middleware.
[0064] Figure 6 It is a system architecture diagram of an embodiment of the present application.
[0065] Figure 7 It is a structural diagram of an electronic device. DETAILED DESCRIPTION
[0066] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0067] like Figure 1 The decentralized vehicle-mounted message middleware processing method shown is applied to a decentralized vehicle-mounted message middleware processing system, including:
[0068] Step S1, define an abstract interface layer for implementing data type abstraction and decoupling, and create a data structure framework through template classes and interface classes; in step S1, implementing data type abstraction and decoupling means creating a standardized interface layer that is independent of specific implementation details, which is used to define data types and operations without relying on the specific implementation of data types. By abstracting and decoupling data types, the flexibility, maintainability and scalability of the software can be improved. For example, data type abstraction and decoupling can be implemented in the following ways:
[0069] Define interface: Create an interface definition to specify the operations that a data type must implement, but does not involve the specific implementation of these operations.
[0070] Use template classes: Use the template class function provided by the programming language to define data structures. Template classes can generate implementations of specific data types at compile time without hard coding in the code.
[0071] Implementation decoupling: Separate the definition of data types (abstract) from the implementation of data operations (concrete) so that changing one does not affect the other, thereby reducing the dependencies between different parts of the system.
[0072] Dynamic association: When the system is running, the data type is dynamically associated with the corresponding implementation as needed.
[0073] Supports extensions: Allows developers to add new data types and implementations as needed without modifying the existing code infrastructure.
[0074] Data type registration: Users can register custom data types, and the system can recognize and use these new types.
[0075] Serialization mechanism: Serialize and deserialize data, that is, convert data types into formats that can be stored or transmitted, and convert these formats back to the original data types.
[0076] Step S2, creates a communication interface based on the hardware abstraction layer, and performs cross-device communication and cross-process communication through the abstract interface layer; the role of step S2 is to realize network transmission and shared memory transmission through the abstract interface layer. During the communication process, based on network transmission and shared memory transmission, no matter how the underlying hardware changes, the upper-level application can communicate through a unified interface, thereby realizing transparent processing of the hardware.
[0077] Step S3, based on the communication interface, Fast DDS is used as the message middleware in the communication protocol transmission layer to perform communication interaction through the communication mode;
[0078] In step S3, the communication mode is specifically "publish-subscribe" or "client-server", where "publish-subscribe" is publisher-subscriber and "client-server" is server-client. Step S3 ensures the reliability and real-time performance of data transmission by configuring the QoS policy of Fast DDS. At the same time, this step also includes encapsulating the user interface of Fast DDS, providing publish-subscribe and request-reply communication interfaces to support communication between different platforms. In step S3, the "communication protocol transport layer" can also be referred to as the communication protocol transport layer, the transport layer communication protocol, etc. For example, it can be the TCP / IP protocol-transport layer.
[0079] Step S4, encapsulate the abstract interface layer at the application layer, create a communication node at the communication interface layer according to the communication protocol and QoS strategy, and the communication node is used to manage the objects of the communication mode across processes, across devices and within processes. In step S4, the application layer can support Android, Linux, QNX platforms, realize cross-language communication between Java and C++, and provide a good foundation for subsequent development work.
[0080] The technical solution provided in steps S1 to S4 realizes an efficient, flexible and reliable communication mechanism. By defining an abstract interface layer and using template classes and interface classes to create a data structure framework, the abstraction and decoupling of data types are realized, thereby improving the maintainability and scalability of the code; by creating a communication interface in the hardware abstraction layer and realizing cross-device and cross-process communication through the abstract interface layer. No matter how the underlying hardware changes, upper-layer applications can communicate through a unified interface, realizing transparent communication of the hardware. Fast DDS is used as the message middleware to implement the "publish-subscribe" and "client-server" communication models in the communication protocol transport layer, and the reliability and real-time performance of data transmission are ensured by configuring QoS policies. By encapsulating the user interface of Fast DDS, a publish-subscribe and request-reply communication interface is provided to support communication between different platforms and simplify the user interface. The abstract interface layer is encapsulated in the application layer to support Android, Linux, and QNX platforms, and cross-language communication between Java and C++ is realized, providing a good foundation for communication under different platforms and language environments. Communication nodes are created in the communication interface layer according to the communication protocol and QoS policy, and objects of the communication mode (such as publisher / subscriber / server / client) are managed to support cross-process, cross-device, and intra-process communication.
[0081] The technical solutions provided in steps S1 to S4 improve the flexibility and scalability of communication. Through the design of the abstract interface layer and the hardware abstraction layer, the vehicle system can flexibly adapt to different communication requirements and hardware changes. Through the QoS policy configuration of Fast DDS, the reliability and real-time performance of data transmission are ensured. Through a unified communication interface and cross-language support, the communication implementation in different platforms and language environments is simplified. Through hardware transparent processing and management of communication nodes, the compatibility and maintainability of the system are improved.
[0082] QoS (Quality of Service) policy refers to a set of rules, protocols, and mechanisms used in network communications to ensure that data transmission meets specific service quality requirements. These policies are mainly used to manage network resources, optimize data transmission, and ensure the performance of key applications. QoS policies are widely used in various network technologies, including wired networks, wireless networks, and more specific applications. Case number: FAW042481-C-XCN1240698 9
[0083] scenarios, such as streaming media, VoIP (Voice over Internet Protocol) and in-vehicle network communications.
[0084] The main goals of QoS policies include:
[0085] 1. Bandwidth management: Ensure that applications receive enough bandwidth to maintain their performance.
[0086] 2. Latency reduction: Reducing the delay in data packet transmission is especially important for real-time applications.
[0087] 3. Packet loss rate control: reduce the loss of data packets during transmission and improve the reliability of data transmission.
[0088] 4. Error rate control: reduce errors in data transmission and ensure data accuracy.
[0089] 5. Traffic Shaping: Control the rate of data traffic to optimize the use of network resources.
[0090] 6. Priority sorting: Assign different priorities to different types of data streams to ensure that critical data is transmitted first.
[0091] In vehicle networks, QoS strategies are particularly important because vehicle control, safety communications, and infotainment systems have strict requirements on the reliability, real-time, and efficiency of data transmission. For example:
[0092] Vehicle control: Low-latency and high-reliability QoS strategies are required to ensure timely and accurate execution of control instructions.
[0093] Safety communication: such as collision warning systems, requires high-priority QoS strategies to ensure the rapid transmission of safety information.
[0094] Infotainment systems: May not have as high latency and reliability requirements as control and safety communications, but also require certain QoS guarantees to ensure a good user experience.
[0095] By implementing QoS policies, the in-vehicle network can effectively manage multiple concurrent data flows and ensure that mission-critical data transmission is given priority, thereby improving the performance and safety of the entire system.
[0096] like Figure 1A As shown, in step S1, the abstract interface layer for realizing data type abstraction and decoupling is defined, and a data structure framework is created through a template class and an interface class, further comprising: Case No.: FAW042481-C-XCN1240698 10
[0097] Step S11, defining an interface component in the abstract interface layer, wherein each interface in the interface component corresponds to a data type;
[0098] Step S12, creating a corresponding template class for each data type, defining an interface mapping mechanism based on the template class, and dynamically associating the data type with the corresponding template class when the in-vehicle messaging middleware is running;
[0099] Step S13, performing data type registration and serialization mechanism through the interface mapping mechanism, the data type registration is used to register user-defined data types, and the serialization mechanism is used for data serialization and deserialization operations.
[0100] In the optimization technical solution provided in steps S11 to S13, the interface mapping mechanism refers to a technical means for dynamically associating data types with corresponding processing classes or functions at runtime when an abstract interface layer is involved in software design. The interface mapping mechanism is used to achieve polymorphism and dynamic binding, so that the system can process different types of data more flexibly. The main features of the interface mapping mechanism in the embodiment of the present application include:
[0101] Abstract definition: Define a set of interfaces that specify methods and properties that all concrete classes must comply with;
[0102] Specific implementation: Provide one or more specific class implementations for each data type;
[0103] Mapping registration: Register the mapping relationship between each data type and its corresponding specific implementation in the system.
[0104] Dynamic binding: At runtime, based on the current context or configuration, the system dynamically maps an interface to its concrete implementation.
[0105] Decoupling: The interface mapping mechanism helps decouple the definition of the interface from its implementation, increasing the flexibility and maintainability of the code.
[0106] Extensibility: When you need to support new data types, you only need to add new implementation classes and update the mapping without modifying existing interfaces or other implementations.
[0107] Case No.: FAW042481-C-XCN1240698 11
[0108] By defining an interface mapping mechanism, decoupling and extensibility of software design are achieved, which helps to decouple the definition of the interface from its implementation, increase the flexibility and maintainability of the code. When new data types need to be supported, only new implementation classes need to be added and the mapping updated without modifying the existing interface or other implementations.
[0109] The optimization technical solution provided in steps S11 to S13 realizes the efficient construction and flexible management of the data structure framework, improves the flexibility and scalability of the system, and enables the system to adapt to the ever-changing data type requirements through dynamic data type association and flexible data type expansion; improves the efficiency and compatibility of data transmission, and ensures the efficient transmission and consistency of data between different networks and platforms through efficient data serialization and deserialization mechanisms; improves the maintainability and reusability of the code: through decoupled data structure design, the system is more modular and easy to maintain and reuse.
[0110] To summarize, the optimization technical solution provided in steps S11 to S13 realizes an efficient, flexible and scalable in-vehicle message middleware processing method by defining standardized interface components at the abstract interface layer, realizing dynamic data type association, flexible data type extension, and efficient data serialization and deserialization mechanism.
[0111] like Figure 1B As shown, in step S2, creating a communication interface based on the hardware abstraction layer, and performing cross-device communication and cross-process communication through the abstract interface layer further includes:
[0112] Step S21, defining a communication interface: defining a communication interface component in a hardware abstraction layer, encapsulating a corresponding hardware communication protocol for each interface through the communication interface component, and performing cross-device communication and cross-process communication based on the communication interface component;
[0113] Step S22, packaging and parameter configuration: parameter configuration of the communication interface in the communication interface component, and establishment of corresponding different hardware communication protocols, wherein the communication protocols include TCP / IP protocol and serial communication protocol, to meet different communication requirements;
[0114] Case No.: FAW042481-C-XCN1240698 12
[0115] Step S23, dynamic binding and multi-threaded processing: a dynamic binding mechanism is performed on the communication interface component to enable the communication interface to select and bind different communication interfaces according to communication requirements during runtime, thereby realizing multi-threaded communication processing.
[0116] The optimization technical solution provided by steps S21 to S23 achieves efficient and flexible management of cross-device communication and cross-process communication by defining communication interface components in the hardware abstraction layer, configuring parameters and dynamically binding them. By defining a communication interface group, unified encapsulation of different hardware communication protocols is achieved, and a standardized interface is provided for cross-device and cross-process communication. The communication interface is parameterized to adapt to different hardware communication protocols (such as TCP / IP protocol, serial communication protocol), so that the system can be flexibly adjusted according to different communication requirements.
[0117] The optimization technical solution provided in steps S21 to S23 adopts a dynamic binding mechanism: it implements a dynamic binding mechanism for the communication interface, allowing the system to select and bind the most appropriate communication interface according to communication requirements at runtime, thereby improving the adaptability and flexibility of the system, and supporting multi-threaded communication processing, so that the system can handle multiple communication tasks at the same time, thereby improving communication efficiency and the concurrent processing capability of the system.
[0118] To sum up, the optimization technical solution provided by steps S21 to S23 realizes an efficient, flexible and scalable cross-device and cross-process communication mechanism by defining communication interface components in the hardware abstraction layer, performing parameter configuration and dynamic binding, and supporting multi-threaded communication processing.
[0119] like Figure 1C As shown, in step S3, the communication interface adopts FastDDS as the message middleware in the communication protocol transport layer, and performs communication interaction through the "publish-subscribe" or "client-server" communication mode, further comprising:
[0120] Step S31, configure Fast DDS message middleware in the communication protocol transport layer to support the corresponding communication mode; in some embodiments, the two communication modes of step S31 are "publish-subscribe" and "client-server", and each communication mode is defined with a corresponding communication interface and operation process; Case No.: FAW042481-C-XCN1240698 13
[0121] Step S32, encapsulate the interface of the Fast DDS message middleware and configure the QoS policy to form a corresponding communication interface; the communication interface includes different communication modes such as "publish-subscribe", "client-server", and "request-reply";
[0122] Step S33, dynamically creating a communication node for managing the communication mode according to the communication protocol and QoS policy, for cross-process, cross-device and intra-process communication;
[0123] Step S34, establish a data cache mechanism, and define data serialization and deserialization modes for data exchange formats.
[0124] The optimization technical solution provided in steps S31 to S34 realizes efficient and reliable "publish-subscribe" and "client-server" communication models by adopting Fast DDS as the message middleware and performing interface encapsulation and QoS policy configuration on it, and provides corresponding communication interfaces and operation processes for different communication needs. By encapsulating the interface of Fast DDS and configuring QoS policy, communication interfaces including different communication modes such as "publish-subscribe", "client-server", and "request-reply" are formed, ensuring the reliability and real-time performance of data transmission.
[0125] The optimization technical solution provided in steps S31 to S34 dynamically creates communication nodes according to the communication protocol and QoS strategy, realizes the management of cross-process, cross-device and intra-process communication, improves the flexibility and scalability of communication, defines data serialization and deserialization modes by establishing a data caching mechanism, optimizes the efficiency and performance of data exchange, ensures the service quality of key data transmission, and finally, by dynamically creating communication nodes, enables the system to adapt to changing communication environments and needs.
[0126] In the optimization technical solution provided in steps S31 to S34, the data caching mechanism is specifically a technology for temporarily storing data in memory. By caching frequently accessed data in memory, repeated access to the original data source (such as a vehicle-side database or cloud remote service) is reduced, thereby reducing latency and increasing data processing speed.
[0127] The data cache mechanism can reduce the read and write operations on the disk or network, thereby reducing the I / O burden and improving the overall performance of the system. When the system is idle, it preloads the data that may be used into the cache. Case No.: FAW042481-C-XCN1240698 14
[0128] Then, this data can be provided quickly when actually needed. In particular, the data caching mechanism in the vehicle-mounted distributed system can maintain the vehicle-side (local) consistency of the data and ensure the synchronization of data between nodes.
[0129] In the optimization technical solution provided in steps S31 to S34, creating a communication node is specifically to establish an entity in the vehicle-mounted distributed system that can independently send and receive data. Each communication node can encapsulate specific communication protocols and mechanisms, provide a unified communication interface for upper-level applications, and support different communication modes such as publish-subscribe, client-server, and request-reply to adapt to different application scenarios.
[0130] Creating communication nodes in the optimization technical solution provided in steps S31 to S34 can improve communication efficiency. By processing communication details (such as message queue management, protocol conversion, etc.) at the communication node layer, the burden on the application layer can be reduced and communication efficiency can be improved. They can be dynamically created and destroyed according to system requirements, so that the vehicle-mounted system can flexibly expand communication capabilities.
[0131] like Figure 1D As shown, in step S4, the abstract interface layer is encapsulated at the application layer, and a communication node is created at the communication interface layer according to the communication protocol and the QoS policy, and the communication node is used to manage the objects of the communication mode across processes, across devices and within processes, further comprising:
[0132] Step S41, encapsulating the abstract interface layer through JNI encapsulation at the application layer, and dynamically creating a communication node at the communication interface layer according to the communication protocol and QoS policy, wherein the communication node is used to manage cross-process, cross-device and intra-process communications;
[0133] Step S42, in each communication node, based on the logic processing of different communication modes, data consistency processing in a cross-language environment is implemented through JNI encapsulation;
[0134] Step S43, performing communication protocol adaptation based on the interface calling mechanism, and processing data interaction between different protocols.
[0135] The optimization technical solution provided in step S41 to step S43 realizes efficient communication management in a cross-platform and cross-language environment by performing JNI encapsulation on the abstract interface layer at the application layer and dynamically creating communication nodes according to the communication protocol and QoS strategy, and realizes seamless communication between different programming languages such as Java and C++, so that the application layer can use a unified interface to call the underlying communication function, thereby improving cross-platform and cross-language communication. Case No.: FAW042481-C-XCN1240698 15
[0136] The data consistency processing capability in the language environment and the communication nodes dynamically created according to the communication protocol and QoS strategy enable the system to flexibly adapt to different communication needs and effectively manage cross-process, cross-device and intra-process communications. The logical processing of different communication modes (such as publish-subscribe, client-server) is implemented in each communication node, so that each node can perform corresponding data processing and forwarding tasks according to the specific communication scenario, and the communication protocol is adapted through the interface call mechanism, so that the system can handle data interaction between different protocols, improving the compatibility and scalability of the system.
[0137] Exemplarily, the step S41 of encapsulating the abstract interface layer through JNI encapsulation at the application layer is specifically as follows:
[0138] Define JNI interface: define native methods in Java application and declare local interfaces, which will be mapped to functions implemented in C++;
[0139] Implement native functions: Implement native functions corresponding to declared native Java methods in C++ code and ensure that these functions can be called through the JNI environment;
[0140] Configure the JNI environment: configure the JNI environment at the interaction point between Java and C++ codes, implement the local function corresponding to the declared native Java method in the C++ code, and the local function is used for JNI environment calling;
[0141] Thread management: manage threads called by JNI interfaces, map and synchronize threads between the Java virtual machine and native code.
[0142] The JNI encapsulation process in step S41 is intended to achieve seamless integration and communication between Java applications and C++ native libraries. By declaring native methods in Java applications, a set of native interfaces is defined, which serves as a bridge between Java code and C++ code, allowing Java to call functions implemented in C++. The JNI encapsulation process provides implementations corresponding to native methods declared in Java in C++ code, allowing Java code to call these native functions through the JNI interface to perform underlying calculations or access operating system-level resources.
[0143] The JNI encapsulation process in step S41 ensures the correct configuration of the JNI environment by configuring the JNI environment, establishes the basis for interaction between Java and C++ codes, and realizes the management of threads. Case No.: FAW042481-C-XCN1240698 16
[0144] It ensures thread safety and synchronization between the Java virtual machine and the native code, prevents data competition and inconsistency issues, and provides a communication technology means for the in-vehicle messaging middleware to achieve high performance and high reliability.
[0145] like Figure 2 The decentralized vehicle-mounted message middleware processing system shown is used to implement the decentralized vehicle-mounted message middleware processing method, including:
[0146] Abstract interface layer definition module, which defines the abstract interface layer used to implement data type abstraction and decoupling, and creates a data structure framework through template classes and interface classes;
[0147] A communication interface creation module, which creates a communication interface based on a hardware abstraction layer, and performs cross-device communication and cross-process communication through the abstract interface layer;
[0148] A message middleware communication interaction module uses Fast DDS as a message middleware in the communication protocol transmission layer based on the communication interface, and performs communication interaction through a "publish-subscribe" or "client-server" communication mode;
[0149] The communication node creation module encapsulates the abstract interface layer at the application layer, and creates communication nodes at the communication interface layer according to the communication protocol and QoS strategy. The communication nodes are used to manage objects in the communication mode across processes, across devices, and within processes.
[0150] The implementation methods of the system described above are merely illustrative, for example, the various functional modules, units or subsystems in the system may or may not be physically separated, or may or may not be physical units, that is, they may be located in the same place, or they may be distributed to multiple different systems and their subsystems or modules. Those skilled in the art may select some or all of the functional modules, units or subsystems according to actual needs to achieve the purpose of the embodiments of the present invention, and those of ordinary skill in the art may understand and implement the above-mentioned situations without creative work.
[0151] like Figure 3 and Figure 4 As shown, in order to realize cross-system and cross-platform message middleware, the bottom layer of the present application adopts Fastdds as the carrier of the message middleware, which is divided into JNI interface layer, abstract interface layer, communication mode, communication transmission layer, and hardware abstraction layer. Among them:
[0152] Case No.: FAW042481-C-XCN1240698 17
[0153] The abstract interface layer abstracts data types based on the current application scenarios of smart driving and smart cockpits, decouples data in the form of templates, and also supports STL string and array, making it portable, generic, and specializable. It also supports QOS policy configuration specification during transmission. The hardware abstraction layer abstracts cross-device communication / cross-process communication into network transmission and shared memory transmission, which is independent of hardware;
[0154] The communication protocol transport layer uses fastdds as a carrier to implement publisher-subscriber and server-client communication modes. The application layer supports android, linux, and qnx platforms. Due to the differences between java and c++, the abstract interface layer needs to be encapsulated by JNI before it can be called by java. However, since the underlying protocol and the abstract layer interface are the same, communication between android-linux, android-qnx, and linux-qnx can be achieved.
[0155] like Figure 5 and Figure 6 As shown, the Fast DDS middleware is encapsulated with the concept of communication nodes to provide a publish-subscribe, request-reply (RPC) communication interface to the application layer, supporting inter-service communication on the QNX side, inter-service communication on the Android side, service communication between Android and QNX, and inter-service communication between the smart cockpit domain and the intelligent driving domain.
[0156] During the creation of the communication node, the communication protocol is specified according to the input parameters, and the specified QOS and default QOS are supported. According to the node concept of ros, the node manages the publisher / subscriber / server / client objects, and according to the template, a node can create objects of different data types, because its underlying layer supports tcp / udp / shm communication and the protocol is the same, supporting cross-process / cross-device / intra-process communication.
[0157] It can be seen from the description of the embodiments of the present application that:
[0158] 1. The present invention adopts the development concept of communication model, adopts the concept of paradigm programming, and abstracts the unified interface;
[0159] 2. This invention adopts class extraction technology to abstract the serialization and deserialization of data, which can determine the data type in the compilation stage, dynamically judge the data type, and support IDL / protobuf / string / array; Case No.: FAW042481-C-XCN1240698 18
[0160] 3. The present invention adopts the concept of interface isolation to isolate the abstract interface, adaptation layer, and protocol layer, thereby increasing the scalability and reliability of the system;
[0161] 4. The present invention realizes Java and C++ cross-language and cross-system communication through cross-platform and cross-system transplantation of codes.
[0162] like Figure 7 As shown, the present invention not only provides a decentralized vehicle-mounted message middleware processing method, but also provides a corresponding smart cockpit, electronic device and storage medium:
[0163] A smart cockpit, wherein the decentralized in-vehicle message middleware processing system is provided in the smart cockpit.
[0164] An electronic device includes: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of a decentralized in-vehicle message middleware processing method.
[0165] A computer-readable storage medium stores a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of a decentralized in-vehicle message middleware processing method.
[0166] like Figure 7 As shown, the device 600 includes a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory 602 (ROM) or a computer program loaded from a storage unit 608 into a random access memory 603 (RAM). In the RAM, various programs and data required for the operation of the device 600 can also be stored. The computing unit 601, the ROM, and the RAM are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.
[0167] A number of components in the device 600 are connected to the I / O interface 605, including: an input unit 606, such as a keyboard, a mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a disk, an optical disk, etc.; and a communication unit 609, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.
[0168] Case No.: FAW042481-C-XCN1240698 19
[0169] The computing unit 601 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 601 performs the various methods and processes described above, such as executing a decentralized vehicle message middleware processing method. For example, in some embodiments, the decentralized vehicle message middleware processing method may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the computing unit 601, one or more steps of the decentralized vehicle message middleware processing method described above may be executed. Alternatively, in other embodiments, the computing unit 601 may be configured to execute a decentralized in-vehicle message middleware processing method in any other appropriate manner (eg, by means of firmware).
[0170] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0171] The program code for implementing the method of the present invention can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other decentralized vehicle-mounted message middleware processing system, so that the program code is processed by Case No.: FAW042481-C-XCN1240698 20
[0172] When executed by a processor or controller, the functions / operations specified in the flowchart and / or block diagram are implemented. The program code may be executed entirely on the machine, partially on the machine, partially on the machine as a stand-alone software package and partially on a remote machine, or entirely on a remote machine or server.
[0173] In the context of the present invention, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0174] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).
[0175] The systems and techniques described herein may be implemented in a computing system that includes a backend component (e.g., as a data server), or a computing system that includes a middleware component (e.g., an application server), or a computing system that includes a frontend component (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components.
[0176] Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.
[0177] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship with each other. The server may be a cloud server, a server of a distributed system, or a server combined with a blockchain.
[0178] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution disclosed in the present invention can be achieved, and this document does not limit this.
[0179] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0180] In addition, those skilled in the art will appreciate that, although some embodiments described herein include certain features included in other embodiments but not other features, the combination of features of different embodiments is meant to be within the scope of the present invention and form different embodiments. For example, any one of the embodiments claimed in the claims can be used in any combination in the embodiments of the present invention.
[0181] In the description of this specification, the description with reference to the terms "one embodiment", "example", "specific example", etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.
[0182] In addition, the technical solutions of the various embodiments of the present invention can be combined with each other, but it must be based on the fact that ordinary technicians in the field can implement it. When the combination of technical solutions is contradictory or inconsistent, Case No.: FAW042481-C-XCN1240698 22
[0183] When the method is implemented, it should be considered that this combination of technical solutions does not exist and is not within the scope of protection required by the present invention.
[0184] All features disclosed in this specification, or steps in all methods or processes disclosed, except mutually exclusive features and / or steps, can be combined in any way. Any feature disclosed in this specification, unless otherwise stated, can be replaced by other equivalent or alternative features with similar purposes. That is, unless otherwise stated, each feature is only an example of a series of equivalent or similar features. Throughout the specification, the same reference numerals indicate the same elements.
[0185] Those skilled in the art will appreciate that the modules in the devices in the embodiments can be adaptively changed and set in one or more devices different from the embodiments. The modules or units or components in the embodiments can be combined into one module or unit or component, and in addition they can be divided into multiple submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive, all features disclosed in this specification (including corresponding claims, abstracts and drawings) and all processes or units of any method or device disclosed in this manner can be combined in any combination. Unless otherwise explicitly stated, each feature disclosed in this specification (including corresponding claims, abstracts and drawings) can be replaced by an alternative feature that provides the same, equivalent or similar purpose.
[0186] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. A decentralized vehicle-mounted message middleware processing method, characterized in that: The in-vehicle message middleware processing system used for decentralization includes: Define an abstract interface layer for realizing data type abstraction and decoupling, and create a data structure framework through template classes and interface classes; Creating a communication interface based on a hardware abstraction layer, and performing cross-device communication and cross-process communication through the abstract interface layer; Based on the communication interface, Fast DDS is used as the message middleware in the communication protocol transmission layer to perform communication interaction through the communication mode; The abstract interface layer is encapsulated at the application layer, and communication nodes are created at the communication interface layer according to the communication protocol and QoS strategy. The communication nodes are used to manage objects of the communication mode across processes, across devices, and within processes.
2. The decentralized vehicle-mounted message middleware processing method according to claim 1 is characterized in that: The definition is used to implement an abstract interface layer for data type abstraction and decoupling, and a data structure framework is created through template classes and interface classes, further including: An interface component is defined in the abstract interface layer, wherein each interface in the interface component corresponds to a data type; Create a corresponding template class for each data type, define an interface mapping mechanism based on the template class, and dynamically associate the data type with the corresponding template class when the vehicle-mounted messaging middleware is running; The data type registration and serialization mechanism are performed through the interface mapping mechanism. The data type registration is used to register user-defined data types, and the serialization mechanism is used for data serialization and deserialization operations.
3. The decentralized vehicle-mounted message middleware processing method according to claim 1 is characterized in that: The creating of a communication interface based on the hardware abstraction layer and performing cross-device communication and cross-process communication through the abstract interface layer further includes: Case No.: FAW042481-C-XCN1240698 1 Defining a communication interface: defining a communication interface component in the hardware abstraction layer, encapsulating a corresponding hardware communication protocol for each interface through the communication interface component, and performing cross-device communication and cross-process communication based on the communication interface component; Packaging and parameter configuration: configure the parameters of the communication interface in the communication interface component and set up corresponding different hardware communication protocols, including TCP / IP protocol and serial communication protocol; Dynamic binding and multi-threaded processing: A dynamic binding mechanism is implemented for the communication interface component, so that the communication interface can select and bind different communication interfaces according to communication requirements at runtime to achieve multi-threaded communication processing.
4. The decentralized vehicle-mounted message middleware processing method according to claim 1, characterized in that: The method of using Fast DDS as a message middleware in the communication protocol transmission layer based on the communication interface and performing communication interaction through the communication mode further includes: Configure Fast DDS message middleware in the communication protocol transport layer to support the corresponding communication mode, which is specifically "publish-subscribe" or "client-server"; Encapsulate the interface of Fast DDS message middleware and configure QoS policy to form the corresponding communication interface; Dynamically create communication nodes for managing communication modes based on communication protocols and QoS policies for cross-process, cross-device, and intra-process communication; Establish data caching mechanisms and define data serialization and deserialization patterns for data exchange formats.
5. The decentralized vehicle-mounted message middleware processing method according to claim 1 is characterized in that: The abstract interface layer is encapsulated at the application layer, and a communication node is created at the communication interface layer according to the communication protocol and the QoS strategy, wherein the communication node is used to manage objects of the communication mode through cross-process, cross-device and intra-process communication, further comprising: Case No.: FAW042481-C-XCN1240698 2 The abstract interface layer is encapsulated through JNI encapsulation at the application layer, and communication nodes are dynamically created at the communication interface layer according to the communication protocol and QoS strategy. The communication nodes are used to manage cross-process, cross-device and intra-process communications; In each communication node, based on the logic processing of different communication modes, data consistency processing in a cross-language environment is achieved through JNI encapsulation; Communication protocols are adapted based on the interface calling mechanism, and data interactions between different protocols are processed.
6. The decentralized vehicle-mounted message middleware processing method according to claim 5 is characterized in that: The abstract interface layer is encapsulated by JNI encapsulation at the application layer, specifically: Define JNI interface: define native methods in Java application and declare local interfaces, which will be mapped to functions implemented in C++; Implement native functions: Implement native functions corresponding to declared native Java methods in C++ code and ensure that these functions can be called through the JNI environment; Configure the JNI environment: configure the JNI environment at the interaction point between Java and C++ codes, implement the local function corresponding to the declared native Java method in the C++ code, and the local function is used for JNI environment calling; Thread management: manage threads called by JNI interfaces, map and synchronize threads between the Java virtual machine and native code.
7. A decentralized vehicle-mounted message middleware processing system, characterized in that: A decentralized vehicle-mounted message middleware processing method for implementing any one of claims 1 to 6, comprising: Abstract interface layer definition module, which defines the abstract interface layer used to implement data type abstraction and decoupling, and creates a data structure framework through template classes and interface classes; A communication interface creation module, which creates a communication interface based on a hardware abstraction layer, and performs cross-device communication and cross-process communication through the abstract interface layer; Case No.: FAW042481-C-XCN1240698 3 A message middleware communication interaction module uses Fast DDS as a message middleware in the communication protocol transmission layer based on the communication interface, and performs communication interaction through a communication mode; The communication node creation module encapsulates the abstract interface layer at the application layer, and creates communication nodes at the communication interface layer according to the communication protocol and QoS strategy. The communication nodes are used to manage objects in the communication mode across processes, across devices, and within processes.
8. A smart cockpit, characterized in that: The smart cockpit is provided with the decentralized in-vehicle message middleware processing system as described in claim 7.
9. An electronic device, characterized in that: include: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the method described in any one of claims 1 to 6.
10. A computer-readable storage medium, characterized in that: It stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the method described in any one of claims 1 to 6.
Citation Information
Cited By
SOA application implementation method, device and equipment
CN119961198A
Inter-process communication system and method based on fusion of visual model and DDS
CN120045356A
Man-machine interaction method of single SOC system based on cabin-driving fusion chip
CN120540519A
A man-machine interaction method based on a single SOC system of cabin driving fusion chip
CN120540519B
Data communication system, method and equipment based on communication middleware and storage medium
CN121309654A