Heterogeneous message middleware communication method, intelligent cabin and electronic equipment

Abstract

The invention discloses a heterogeneous message middleware communication method, an intelligent cabin and electronic equipment, and the method is applied to a heterogeneous message middleware communication system developed in an automatic driving intelligent cabin. The method comprises the steps: building a multi-layer communication architecture from an abstract interface layer to a hardware abstraction layer, and providing services for the outside by taking a node as a unit, a service discovery mechanism based on topic is utilized to complete communication interaction between nodes, and data sending and receiving are carried out based on an instantiation protocol in a publishing-subscribing and answering-requesting mode. According to the invention, a highly abstract interface and rich data type support are provided, the maintenance and migration cost is reduced, the code quantity of upper-layer applications is reduced, the logic is clearer, the transportability of the system is also enhanced, the platform migration is more convenient, communication protocols are allowed to be easily added or replaced on the premise of not influencing the existing functions, and the communication efficiency is improved. And new business requirements are continuously met.

Description

Technical Field

[0001] The present invention relates to a communication method, an intelligent cockpit and an electronic device, and in particular to a heterogeneous message middleware communication method, an intelligent cockpit and an electronic device. Background Art

[0002] In the development of autonomous driving smart cockpit applications, there are many types of hardware involved, and each hardware has different transmission protocols and data types, so there are strict requirements on the effectiveness and efficiency of the data link.

[0003] In the development and application of smart cockpits, the message communication protocols involved include: fastdds, iceoryx, rtidds, zmq, and someip. Each protocol is selected based on its usage scenario and its own advantages and disadvantages. The existing solutions cannot integrate different protocols and are called separately in use. Therefore, the problems caused in use are as follows:

[0004] 1. Different protocols have different interface calls, data types, and communication models, which requires separate application adaptation during use;

[0005] 2. Due to the differences between the protocols, if the system is migrated or the business is changed in the later stage, the protocol to be modified needs to be modified separately, which increases the cost of development and maintenance, and the scalability of the system is poor;

[0006] 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;

[0007] 4. Due to the different protocols used, similar codes will be repeated in the protocol interface calls, which will increase the amount of system code and increase the difficulty of maintenance.

[0008] In summary, the existing technology can no longer meet people's requirements and needs to be improved urgently. Summary of the invention

[0009] The purpose of the present invention is to provide a heterogeneous message middleware communication method, a smart cockpit and an electronic device. The first technical problem to be solved is that there is no need to configure a communication protocol separately in the development and application of the smart cockpit. The second technical problem to be solved is to enhance the scalability of the system, reduce the human factors of the system, reduce the difficulty of system maintenance, and solve the shortcomings of the existing technology.

[0010] The present invention provides the following scheme:

[0011] A heterogeneous message middleware communication method is applied to a heterogeneous message middleware communication system for application development in an autonomous driving intelligent cockpit, comprising:

[0012] A multi-layer communication architecture is established from the abstract interface layer to the hardware abstraction layer, and a communication layer for parsing URL format and encapsulating third-party communication protocols is set between the abstract interface layer and the hardware abstraction layer;

[0013] Provide services to the outside world in nodes, and use the topic-based service discovery mechanism to complete the communication interaction between nodes;

[0014] Data is sent and received based on the instantiation protocol through publish-subscribe and reply-request methods.

[0015] Furthermore, the establishment of a multi-layer communication architecture from the abstract interface layer to the hardware abstraction layer, wherein a communication layer for parsing URL format and encapsulating third-party communication protocols is provided between the abstract interface layer and the hardware abstraction layer, further includes:

[0016] Define an abstract interface layer to abstract different communication protocols into publish-subscribe and request-response communication modes;

[0017] Design the communication service adaptation layer to parse the string parameters in the URL format and adapt the protocol name obtained after parsing to the corresponding protocol;

[0018] Establish a service communication management layer to encapsulate third-party communication protocols;

[0019] Build a communication protocol transport layer to encapsulate vehicle-related third-party libraries;

[0020] Add a hardware abstraction layer to abstract cross-device communication / cross-process communication into network transmission and shared memory transmission.

[0021] Furthermore, in configuring the transmission data type of the abstract interface layer, the IDL protobuf type is converted into an interface file through a conversion tool;

[0022] In the establishment of the service communication management layer, the third-party communication protocols include: DDS, FastDDS, Some / IP, ZMQ, and each third-party communication protocol is separately encapsulated in the communication service management layer;

[0023] The string parameters in the URL format are parsed in the communication service adaptation layer. Specifically, the protocol name, service name, and version number are extracted by parsing the string parameters, so that the node can match the node information of the sender through service discovery to create a connection.

[0024] Furthermore, providing services to the outside world in units of nodes and completing communication interactions between nodes using a topic-based service discovery mechanism further includes:

[0025] The node is specified through the QOS configuration file, or the default transmission scheme is adopted, which supports reliable transmission or unreliable transmission and is used to extract different interfaces of the underlying protocol.

[0026] Furthermore, the sending and receiving of data based on the instantiation protocol and through the publish-subscribe and reply-request methods further includes:

[0027] In the process of heterogeneous message middleware publishing data, the application layer calls the abstract interface, inputs the URL format string, and parses the string in the communication service adaptation layer;

[0028] If there are illegal characters or format errors in the parsed string, a failure message is returned;

[0029] If no illegal characters or format errors are found in the parsed string, the parsing format is judged to be correct and the corresponding data information is obtained;

[0030] Create an instantiation object of the corresponding protocol name through the communication protocol management layer and return the corresponding data.

[0031] Furthermore, the sending and receiving of data based on the instantiation protocol and through the publish-subscribe and reply-request methods further includes:

[0032] In the process of heterogeneous message middleware subscription data, the application layer calls the abstract interface, inputs the URL format string and the callback function, and parses the string in the communication service adaptation layer;

[0033] If there are illegal characters or format errors in the parsed string, a failure message is returned;

[0034] If no illegal characters or format errors are found in the parsed string, the parsing format is judged to be correct and the corresponding data information is obtained;

[0035] Create an instantiation object of the corresponding protocol name through the communication protocol management layer, complete service discovery and callback function registration, and return the created instantiation object.

[0036] A heterogeneous message middleware communication system, used to implement the heterogeneous message middleware communication method, characterized by comprising:

[0037] A multi-layer communication architecture establishment module is used to establish a multi-layer communication architecture from the abstract interface layer to the hardware abstraction layer, and a communication layer for parsing URL format and encapsulating third-party communication protocols is provided between the abstract interface layer and the hardware abstraction layer;

[0038] The node unit communication interaction module provides services to the outside world based on the node, and uses the topic-based service discovery mechanism to complete the communication interaction between nodes;

[0039] The instantiated protocol data interaction module sends and receives data based on the instantiated protocol through publish-subscribe and reply-request methods.

[0040] A smart cockpit, characterized in that the heterogeneous message middleware communication system described in 7 is arranged in the smart cockpit.

[0041] 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.

[0042] 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.

[0043] Compared with the prior art, the present invention has the following advantages:

[0044] The present invention will design a service-oriented heterogeneous message communication middleware system based on the communication protocols used in different business scenarios in the vehicle intelligent cockpit. It integrates multiple communication protocols, provides an extremely simple interface for the application layer, abstracts complex protocol interfaces, and supports the stable and reliable request / response communication model (server / client) and the stable and unreliable transmission publish / subscribe communication model (publish / subscribe) commonly used in the vehicle cockpit. At the same time, the data type is abstracted through the template, supporting types such as protobuf / IDL / string / vector / int. It provides abstract and simple interface calls and rich data types for upper-level applications, which is simpler and more convenient to use, thereby helping users reduce the maintenance cost of the code and the cost of platform migration, and increasing the scalability of the system, and expanding other communication protocols without affecting the existing functions.

[0045] The present invention realizes protocol fusion and abstraction, and can integrate multiple communication protocols, such as CAN, LIN, MOST, Ethernet, etc., to achieve seamless docking between different protocols, which not only improves the compatibility of the system, but also simplifies the development of the application layer by abstracting complex protocol interfaces, and supports two commonly used communication models in vehicle cockpits: a stable and reliable request / response model (server / client) and a stable but unreliable transmission publish / subscribe model (publish / subscribe). This flexible model support enables the system to cope with different business scenario requirements, whether it requires high-reliability control instruction transmission or high-efficiency information distribution.

[0046] The present invention improves the richness of data types and supports multiple data types, including but not limited to protobuf, IDL, string, vector, int, etc. The diversity and flexibility of such data types enable upper-layer applications to select appropriate data types according to actual needs, improve the efficiency and accuracy of data processing, simplify the difficulty of interface calling, and provide a set of simple and easy-to-use interface calling mechanisms for upper-layer applications. Developers can quickly implement function development without having to deeply understand the details of the underlying communication protocol, which greatly reduces the time cost of learning and development.

[0047] The present invention provides highly abstract interfaces and rich data type support, reduces the cost of maintenance and migration, reduces the amount of code for upper-level applications, and makes the logic clearer, thereby reducing the cost of code maintenance. At the same time, the portability of the system is also enhanced, and platform migration is more convenient. The future scalability of the system is fully considered at the beginning of the design, allowing communication protocols to be easily added or replaced without affecting existing functions, so that the system can adapt to the rapidly changing technical environment and continue to meet new business needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] 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.

[0049] Figure 1 It is a flow chart of the heterogeneous message middleware communication method.

[0050] Figure 1A It is a flowchart of the technical solution for optimizing step S1 in the heterogeneous message middleware communication method.

[0051] Figure 1BIt is a flow chart of the technical solution for optimizing step S3 in the heterogeneous message middleware communication method.

[0052] Figure 1C It is a flowchart of another optimization technical solution for step S3 in the heterogeneous message middleware communication method.

[0053] Figure 2 It is an architectural diagram of a heterogeneous message middleware communication system.

[0054] Figure 3 This is the overall principle framework diagram of heterogeneous message middleware.

[0055] Figure 4 It is a schematic diagram of the heterogeneous message middleware structure.

[0056] Figure 5 It is a flowchart of the asynchronous communication mode of heterogeneous message middleware.

[0057] Figure 6 It is a flowchart of the synchronous communication mode of heterogeneous message middleware.

[0058] Figure 7 It is a synchronous communication flow chart of heterogeneous message middleware.

[0059] Figure 8 It is a flow chart of asynchronous communication of heterogeneous message middleware.

[0060] Fig. 9 It is a timing diagram of heterogeneous message middleware publishing data.

[0061] Fig.10 This is a timing diagram of heterogeneous message middleware subscription data.

[0062] Fig.11 It is a structural diagram of an electronic device. DETAILED DESCRIPTION

[0063] 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.

[0064] like Figure 1 The heterogeneous message middleware communication method shown is applied to a heterogeneous message middleware communication system for application development in an autonomous driving intelligent cockpit, including:

[0065] Step S1, establishing a multi-layer communication architecture from the abstract interface layer to the hardware abstraction layer, wherein a communication layer for parsing URL format and encapsulating third-party communication protocols is provided between the abstract interface layer and the hardware abstraction layer;

[0066] Step S2, providing services to the outside world in units of nodes, and using a topic-based service discovery mechanism to complete communication interactions between nodes;

[0067] Step S3, based on the instantiation protocol, data is sent and received through the publish-subscribe and server-client methods.

[0068] Glossary:

[0069] The Topic-based service discovery mechanism is a method for service location and communication in a distributed system. Its typical application scenarios are message queues and event-driven architectures. The Topic-based service discovery mechanism allows different services or components to discover and interact with each other through a common communication topic. The Topic-based service discovery mechanism has the following key features:

[0070] 1. Decentralization: Service discovery does not require a centralized registry, and service instances can publish and subscribe to topics independently.

[0071] 2. Dynamic discovery: Service instances can dynamically discover topics of interest at startup or during operation without knowing the specific location of the service in advance.

[0072] 3. Topic subscription: Service instances subscribe to topics of interest, and when messages are published to these topics, subscribers are notified.

[0073] 4. Message publishing: A service instance can publish messages to a specific topic, and these messages will be received by all service instances that subscribe to the topic.

[0074] 5. Decoupling: Communication between services is done through topics, and service instances do not need to directly reference each other, thus reducing the degree of coupling in the system.

[0075] 6. Flexibility: Service instances can subscribe or unsubscribe from topics as needed, enabling flexible communication between services.

[0076] 7. Scalability: As the number of service instances increases, the topic service discovery mechanism can be easily expanded to accommodate more service instances.

[0077] 8. Fault tolerance: Even if some service instances fail, other service instances subscribed to the same topic can still receive messages, which improves the fault tolerance of the system.

[0078] 9. Asynchronous communication: Topic-based service discovery mechanisms usually support asynchronous communication, and service instances can receive and process messages without blocking the main thread.

[0079] 10. Multi-protocol support: Many message middleware (such as Kafka, RabbitMQ, ActiveMQ, etc.) support topic-based service discovery mechanism and provide multiple communication protocols to adapt to different application scenarios.

[0080] In practical applications, the topic-based service discovery mechanism can be used to implement various scenarios such as inter-service communication in microservice architecture, event-driven system integration, real-time data stream processing, etc. Based on this service discovery mechanism, different parts of the vehicle system can develop and expand independently while maintaining efficient communication and collaboration.

[0081] Steps S1 to S3 describe the design and implementation steps of a multi-layer communication architecture, which improves the interoperability and scalability of the system by simplifying the communication process between different hardware and software systems.

[0082] Step S1 implements the establishment of a multi-layer communication architecture, creating a multi-layer architecture from the abstract interface layer to the hardware abstraction layer, so that different layers can interact through a unified communication layer. Step S1 overcomes the communication differences between different hardware and software systems, encapsulates the differences between software and hardware, and makes it unnecessary for upper-layer applications to care about the specific implementation of the underlying hardware. By setting a communication layer between the abstract interface layer and the hardware abstraction layer, parsing the URL format and encapsulating the third-party communication protocol, communication interaction between different systems is achieved.

[0083] Step S2 is based on node service discovery, providing services on a node-by-node basis, and using a subject-based service discovery mechanism to complete communication interactions between nodes. Through the service discovery mechanism, nodes can dynamically find the required services, achieving efficient communication between nodes and dynamic allocation of resources.

[0084] Step S3 instantiates the protocol and uses the publish-subscribe and reply-request methods to send and receive data. At the same time, it provides a developer-friendly interface to simplify the use of the protocol, reduce the complexity of data transmission between different protocols for developers, and hide the complexity of these interfaces, so that developers can operate through a unified interface without having to worry about the details of data transmission between different protocols. Instead, they can send and receive data through a unified interface, thereby improving development efficiency and system flexibility.

[0085] In summary, the multi-layer communication architecture provided by steps S1 to S3 provides a flexible and scalable communication solution. By abstracting and encapsulating communication details at different levels, developers can more easily build and maintain cross-platform communication systems, which not only simplifies the development process but also improves the interoperability and maintainability of the system.

[0086] like Figure 1A As shown, in the optimization technical solution of step S1, the multi-layer communication architecture from the abstract interface layer to the hardware abstraction layer is established, and a communication layer for parsing the URL format and encapsulating the third-party communication protocol is provided between the abstract interface layer and the hardware abstraction layer, further comprising:

[0087] Step S11, defining an abstract interface layer, abstracting different communication protocols into publish-subscribe and request-response communication modes;

[0088] Step S12, designing a communication service adaptation layer, parsing the string parameters in the URL format, and adapting the protocol name obtained after the parsing to the corresponding protocol;

[0089] Step S13, establishing a service communication management layer to encapsulate third-party communication protocols;

[0090] Step S14, constructing a communication protocol transmission layer for encapsulating vehicle-related third-party libraries, and the third-party libraries support flexible addition of transmission protocols;

[0091] Step S15, adding a hardware abstraction layer to abstract cross-device communication / cross-process communication into network transmission and shared memory transmission.

[0092] Exemplarily, in the optimization technical solution of step S11 to step S15, in configuring the transmission data type of the abstract interface layer, the IDL protobuf type is converted into an interface file through a conversion tool; and the QOS policy configuration specification in the transmission is supported.

[0093] In the establishment of the service communication management layer, the third-party communication protocols include: DDS, FastDDS, Some / IP, ZMQ, and each third-party communication protocol is separately encapsulated in the communication service management layer;

[0094] The string parameters in the URL format are parsed in the communication service adaptation layer. Specifically, the protocol name, service name, and version number are extracted by parsing the string parameters, so that the node can match the node information of the sender through service discovery to create a connection.

[0095] Steps S11 to S15 describe the detailed design and implementation process of the communication architecture, providing a flexible and efficient cross-platform communication solution.

[0096] In step S11, an abstract interface layer is defined, and different communication protocols are abstracted into publish-subscribe and request-response modes. In view of the differences between different communication protocols and how to abstract these differences, communication using a unified interface is realized. Developers can ignore the specific implementation of the underlying protocol and use a unified communication mode for data exchange.

[0097] In step S12, a communication service adaptation layer is designed to parse the string parameters in the URL format and adapt to the corresponding communication protocol. Through the communication service adaptation layer in step S12, communication requests in different formats can be automatically identified and processed, thereby improving the flexibility and accuracy of communication.

[0098] In step S13, a service communication management layer is established to encapsulate third-party communication protocols (DDS, FastDDS, Some / IP, ZMQ and other third-party communication protocols), and a unified management interface is provided, so that the system can uniformly manage different communication protocols, simplifying the use and maintenance of the protocols.

[0099] In step S14, a communication protocol transport layer is constructed to encapsulate the vehicle-related third-party library, support flexible addition of transport protocols, achieve efficient and reliable communication in the vehicle environment, and realize the rapid integration of new transport protocols. The communication protocol transport layer in this step provides encapsulation of the vehicle communication library, so that the system can be flexibly expanded to support more types of transport protocols.

[0100] In step S15, a hardware abstraction layer is added to abstract cross-device and cross-process communication into network transmission and shared memory transmission, and efficient cross-platform communication is achieved according to the communication differences between different hardware devices and processes. The hardware abstraction layer in this step provides a unified way to handle communication between different hardware and processes, improving the efficiency and reliability of communication.

[0101] In the abstract interface layer in step S15, the IDL protobuf type is converted into an interface file through a conversion tool, and QOS policy configuration is supported. The data definition language (IDL) and protocol buffer (protobuf) are effectively converted into a usable interface, and the configuration of transmission quality service (QOS) is provided. Through the conversion tool and QOS policy configuration, the vehicle system can provide more flexible and high-quality data transmission services.

[0102] Steps S11 to S15 constitute a highly modular and extensible communication architecture, which provides a unified, efficient and flexible communication solution by abstracting and encapsulating communication details at different levels. It not only simplifies the work of developers, but also improves the interoperability and maintainability of the system. It also supports multiple communication protocols and transmission methods to meet the communication needs in different scenarios.

[0103] Preferably, in the optimization technical solution of step S2, providing services externally in units of nodes, and completing communication interactions between nodes using a topic-based service discovery mechanism, further includes:

[0104] The node is specified through the QOS configuration file, or the default transmission scheme is adopted, which supports reliable transmission or unreliable transmission and is used to extract different interfaces of the underlying protocol.

[0105] like Figure 1B As shown, in the optimization technical solution of step S3, the sending and receiving of data based on the instantiation protocol and through the publish-subscribe (publisher-subscribe) and reply-request (server-client) method further includes the process of heterogeneous message middleware publishing data:

[0106] Step S31, in the process of heterogeneous message middleware publishing data, the application layer inputs a string in URL format by calling an abstract interface, and the communication service adaptation layer parses the string;

[0107] Step S32, if there are illegal characters or format errors in the parsed string, return a failure message;

[0108] Step S33, if no illegal characters or format errors are found in the parsed string, the parsed format is determined to be correct, and corresponding data information is obtained, the data information includes: protocol name, service description, version, etc.;

[0109] Step S34, creating an instantiation object corresponding to the protocol name through the communication protocol management layer, and returning the corresponding data.

[0110] Steps S31 to S34 describe a data publishing process in a heterogeneous message middleware, the core idea of ​​which is to simplify the interaction between the application layer and the communication service through an abstract interface and ensure the accuracy and reliability of the data publishing process.

[0111] In the optimization technical solution from step S31 to step S34, data is published by calling an abstract interface through the application layer, and the interface accepts a string in URL format as input. The adaptation layer is responsible for parsing the string in URL format and extracting necessary communication parameters.

[0112] An error handling mechanism is implemented during the parsing process from step S31 to step S34. If illegal characters or format errors are found, the system can return failure information in time. Based on the parsed information, the communication protocol management layer creates a corresponding protocol instance and returns data.

[0113] Steps S31 to S34 solve the problem of the uniformity of the data publishing interface, and can provide a unified interface for different message middlewares, so that the application layer does not need to care about the underlying communication details. Steps S31 to S34 can be applied to error detection in the data publishing process. In the data publishing process, illegal characters or format errors can be effectively detected and processed to avoid erroneous data publishing, and then the necessary communication parameters such as the protocol name, service description, and version are accurately extracted from the URL format string. Finally, after the correct communication parameters are extracted, the corresponding protocol instance is dynamically created and the data is published.

[0114] The optimization technical solution provided by steps S31 to S34 simplifies application layer development: by using abstract interfaces, application layer developers can focus more on business logic without having to delve into the underlying communication details.

[0115] Steps S31 to S34 improve the accuracy of data publishing by performing error detection at the communication service adaptation layer to ensure that only data with a correct format and legality can be published.

[0116] Steps S31 to S34 enhance the robustness of the system. By returning failure information in a timely manner, the system can respond to error conditions quickly, avoid the propagation of errors, and improve the flexibility and scalability of the system. By dynamically creating protocol instances, it can support multiple communication protocols, making it easier to add new protocols or adjust existing protocols in the future.

[0117] The optimization technical solution of step S31 to step S34 builds a robust, flexible and user-friendly data publishing process, simplifies the interaction between the application layer and the communication service through the abstract interface, ensures the accuracy of data publishing through the parsing and error handling mechanism of the communication service adaptation layer, and provides support for multiple communication protocols through the dynamic instantiation of the protocol management layer, which not only improves the development efficiency, but also enhances the reliability and scalability of the system.

[0118] like Figure 1C As shown, in the optimization technical solution of step S3, the process of subscribing to data in the heterogeneous message middleware is further included:

[0119] Step S35, in the process of heterogeneous message middleware subscribing to data, the application layer calls the abstract interface, inputs the URL format string and the callback function, and parses the string in the communication service adaptation layer;

[0120] Step S36, if there are illegal characters or format errors in the parsed string, return a failure message;

[0121] Step S37, if no illegal characters or format errors are found in the parsed string, the parsed format is determined to be correct and the corresponding data information is obtained; illustratively, the above data information may include: protocol name, service description, version, etc.

[0122] Step S38, creating an instantiated object corresponding to the protocol name through the communication protocol management layer, completing service discovery and callback function registration, and returning the created instantiated object.

[0123] The optimization technical solution provided in steps S35 to S38 describes the process of data subscription in heterogeneous message middleware, and enhances the flexibility and real-time performance of communication by introducing callback functions. In the optimization technical solution provided in steps S35 to S38, the abstraction of the interface is realized. The application layer subscribes to data by calling the abstract interface, and inputs a string including a URL format and a callback function. The communication service adaptation layer is responsible for parsing the URL string and extracting the communication parameters required for subscription. During the parsing process, if an error is found, the system will return a failure message to ensure that only the correct subscription request is processed. Based on the information obtained from the parsing, the communication protocol management layer creates a protocol instance, and performs service discovery and callback function registration.

[0124] The optimization technical solution provided in steps S35 to S38 simplifies the subscription process of the application layer. The application layer subscribes to data through a unified abstract interface without having to worry about the underlying communication details, thereby simplifying the development process; enhancing the error handling capability, improving the robustness of the system through timely error detection and feedback, and avoiding invalid subscription requests; improving the flexibility of data subscription, through the use of callback functions, the application layer can respond immediately when data arrives, thereby enhancing the real-time performance of the system; supporting service discovery and dynamic instantiation, the communication protocol management layer not only creates protocol instances, but also completes service discovery and callback registration, thereby improving the flexibility and scalability of the system.

[0125] For the method steps disclosed in the above embodiments, the method steps are described as a series of action combinations for the purpose of simple description, but those skilled in the art should know that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0126] Any process or method description described in a flowchart or other manner may be understood as representing a module, fragment or portion of a code including one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations, in which the order shown or discussed may not be followed, including executing and implementing the functions in a substantially simultaneous manner or in a reverse order according to the functions involved, or executing computer instructions and implementing the corresponding functions according to program structures such as loops and branches, which can be naturally understood by those skilled in the art when implementing the embodiments of the present invention.

[0127] like Figure 2 The heterogeneous message middleware communication system shown is used to implement the heterogeneous message middleware communication method, including:

[0128] A multi-layer communication architecture establishment module is used to establish a multi-layer communication architecture from the abstract interface layer to the hardware abstraction layer, and a communication layer for parsing URL format and encapsulating third-party communication protocols is provided between the abstract interface layer and the hardware abstraction layer;

[0129] The node unit communication interaction module provides services to the outside world based on the node, and uses the topic-based service discovery mechanism to complete the communication interaction between nodes;

[0130] The instantiated protocol data interaction module sends and receives data based on the instantiated protocol and through the publish-subscribe and reply-request (server-client) methods.

[0131] like Figure 3 and Figure 4 As shown, in order to realize heterogeneous message middleware, this embodiment adopts a service-oriented architecture, which is divided into an interface abstraction layer, a communication service adaptation layer, a communication management layer, a communication transmission layer, and a hardware abstraction layer. Among them:

[0132] The abstract interface layer abstracts different communication protocols into two communication modes, publish-subscribe and request-response, based on the current application scenarios of smart driving and smart cockpits, to facilitate application layer calls. In terms of transmission data types, the defined IDL protobuf type is converted into an interface file in advance through a conversion tool, and QOS policy configuration specification during transmission is supported.

[0133] The communication service adaptation layer can obtain the attribute value in the parameter after parsing the string parameter in URL format (the URL involves the protocol name, service name, and version number). According to the parsed protocol name, it can adapt to the corresponding required protocol.

[0134] The service communication management layer involves a series of encapsulated third-party communication protocols, such as DDS, FastDDS, SHM, Some / IP, ZMQ, etc. Each third-party protocol is encapsulated separately in the communication service management layer, integrating the four methods of client server publisher subscribe in this layer;

[0135] The communication protocol transport layer is a series of encapsulated vehicle-related third-party libraries. The extensible feature is fully reflected in this layer, which can flexibly add transport protocols without affecting the existing protocols, thereby increasing system stability.

[0136] The hardware abstraction layer abstracts cross-device communication / cross-process communication into network transmission and shared memory transmission, which is independent of the hardware.

[0137] like Figure 5 and Figure 6 As shown in the figure, the node is used as a unit to provide services to the outside world. In the node, publisher-subscribe (publish-subscribe) server-client (response-request) is supported. Service discovery is bound to topic, and the same topic can be discovered by the corresponding node to complete the communication. For the publisher-subscribe (publish-subscribe) communication mode, it can be specified through the QOS configuration file or the default transmission scheme can be used, supporting reliable transmission or unreliable transmission. Through publisher-subscribe (publish-subscribe) server-client (response-request), different interfaces of the underlying protocol are extracted to facilitate calling and subsequent maintenance and migration.

[0138] For the publisher-subscribe mode; when creating a publisher sender, enter a URL type string parameter in the node, parse it through the adaptation layer, extract the protocol name, service name, service description, version and other information, register the sender service, and bind the service to the topic. During the sending process, call the write writer to send the data. When creating a subscribe receiver, enter a URL type string parameter in the node input parameter, callback function, parse the URL parameter through the adaptation layer, extract the protocol name, service name, service description, version and other information, the node bottom layer will match the sender node information through service discovery, and thus create a connection. When data is sent, the receiver will obtain the data through the data reader, and then process the data through the callback function of the application layer and return it. Whether the entire transmission process is cross-device or cross-process, whether it is transmitted through the network or shared memory, it is automatically adapted after the protocol bottom layer service is discovered, and the upper layer application is not affected.

[0139] For the server-client (response-request) mode; when creating client-side request data, the input parameter in the node is a string parameter of URL type, which is parsed by the adaptation layer to extract the protocol name, service name, service description, version and other information, and create a client of the corresponding protocol. After the client is created, service discovery and listening thread settings will be performed; when creating server-side response data, the input parameter in the node is a string parameter of URL type and a server-side response callback function, which is parsed by the adaptation layer to extract the protocol name, service name, service description, version and other information, and create a server of the corresponding protocol. After the server is created, service registration, callback function registration and listening thread settings will be performed; when the server service is started, the server-side listening thread waits for the client data request. There are two parameters in the client request interface (request response), where request is the request input data, and response is the data returned by the server response. After calling the request interface, the client generates a unique ID of the system and combines it with the request data into new data, sends the data through the data writer, and blocks and waits until the data responds (when the data times out, it returns timeout); the server listening thread waits for the client data. When data is received, it obtains the data through the data reader and calls the callback registration function for data processing. After processing, it calls the data writer to send the data. At this time, when the client listening thread has data, it calls the data reader to obtain the data and checks whether the unique ID of the request is equal to the unique ID of the response. If they are the same, the thread is notified to obtain the data, unblock and return the response, otherwise it continues to wait until timeout. The client and the server perform binding matching through the topic to complete service discovery.

[0140] During the entire transmission process, whether it is cross-device or cross-process, network transmission or shared memory transmission is automatically adapted after discovery by the underlying service of the protocol, and the upper-layer application is unaware. The default transmission scheme is UDP for network transmission and shared memory for memory transmission.

[0141] like Figure 7 The specific process of synchronous communication of heterogeneous message middleware shown in the figure describes the complete communication process from request initiation to response reception, involving interface call, parameter parsing, service discovery, thread monitoring, unique ID generation, callback registration, data reception and verification, as well as data processing and return, specifically:

[0142] Request function entry: The process starts at the entry point of the request function. The request content of the entry point can be a user request or an internal call of the system.

[0143] Abstract layer interface call: The request is called through the interface of the abstract layer, which provides a unified calling method for the upper-layer application and hides the details of the underlying communication.

[0144] Adaptation layer URL parsing: The request is passed to the adaptation layer, which is responsible for parsing the URL format string and extracting the necessary communication parameters, such as the protocol name, service description, version, etc.

[0145] The communication management layer creates a request service node Node: In the communication management layer, based on the information parsed by the adaptation layer, a request service node (Node) is created, which is responsible for processing specific requests.

[0146] Service Discovery: Service nodes perform service discovery through a topic-based subscription / publishing mechanism to determine which service a request should be sent to.

[0147] Registration service: The service node is registered with the system so that other nodes can discover and communicate with it.

[0148] Thread listening, waiting for request response: The system starts a thread to listen for the response of the request and waits for receiving the corresponding data.

[0149] Generate a unique ID: To uniquely identify requests and responses, the system generates a unique ID.

[0150] Register a callback function callback: The application layer registers a callback function so that it can process data when it is received.

[0151] Subscribe to topic: The service node subscribes to the relevant topic in order to receive data published to the topic.

[0152] Blocked waiting for response: The thread is blocked before receiving data, waiting for a response.

[0153] Reader receives requested data: The reader component receives the requested data.

[0154] Verify that the unique ID in the returned data is equal to the unique ID in the request: The system verifies that the unique ID contained in the received data matches the ID generated during the request to ensure the correctness of the data.

[0155] The callback processes the requested data: If the verification passes, the previously registered callback function is called to process the received data.

[0156] Return response value: After processing is completed, the processing result is returned through the response function.

[0157] The writer returns the processed data: If the process includes a write operation, the writer component writes the processed data back or sends it out.

[0158] like Figure 8 and Fig. 9 As shown, publishing data consists of two parts: first, instantiating the protocol, and then sending data through the instantiated protocol;

[0159] Protocol instantiation process: Figure 7 In the first part, the application layer calls the abstract interface, inputs a string in URL format, and parses the string in the adaptation layer. If there are illegal characters or format errors in the parsed string, failure is returned. After the parsed format is correct, the corresponding protocol name, service description, version and other information are obtained, and an instantiation object of the corresponding protocol name is created and returned through the communication protocol management layer.

[0160] The process of sending data by instantiating an object: Figure 7 In the second part, the application layer interface calls the sending interface, and the parameters are the defined topic and data. The data is serialized inside the interface. When serialization fails, an error code is returned. When serialization succeeds, the memory is loaded through memory management and the sample is obtained. The serialized data is written into the sample, and finally the data writer is called to send the data out.

[0161] like Fig.10 As shown, data subscription consists of two parts: first, instantiate the protocol, and then subscribe to the data through the instantiated protocol;

[0162] Protocol instantiation process: Figure 8In the first part, the application layer calls the abstract interface, inputs a URL-formatted string and a callback function, and parses the string in the adaptation layer. If there are illegal characters or format errors in the parsed string, failure is returned. After the parsed format is correct, the corresponding protocol name, service description, version and other information are obtained. Through the communication protocol management layer, an instantiation object of the corresponding protocol name is created, service discovery and callback function registration are completed, and the created service instance is returned.

[0163] The process of subscribing to data by instantiating an object: the application layer interface calls the subscription interface to start subscribing to data. The parameter is the defined topic. When the specified topic has data to send, the sample memory is loaded through memory management and the data is retrieved from it through the data reader. The data is deserialized, and the registered callback function is called to process the data and return the result.

[0164] like Fig.11 As shown, the present invention provides a heterogeneous message middleware communication method and system, and also provides a corresponding intelligent cockpit, electronic device and storage medium:

[0165] A smart cockpit, wherein the heterogeneous message middleware communication system is arranged in the smart cockpit.

[0166] 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 a heterogeneous message middleware communication method.

[0167] 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 heterogeneous message middleware communication method.

[0168] Fig.11 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Fig.11 As shown, the device 800 includes a processor 801, a memory 802, a communication interface 803 and a bus 804. The processor 801, the memory 802 and the communication interface 803 communicate through the bus 804, and can also communicate through other means such as wireless transmission. The memory 802 is used to store instructions, and the processor 801 is used to execute the instructions stored in the memory 802. The memory 802 stores program code 8021, and the processor 801 can call the program code 8021 stored in the memory 802 to execute the steps of the heterogeneous message middleware communication method.

[0169] It should be understood that in the embodiment of the present application, the processor 801 may be a CPU, and the processor 801 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0170] The memory 802 may include a read-only memory ROM and a random access memory RAM, and provide instructions and data to the processor 801. The memory 802 may also include a non-volatile random access memory. The memory 802 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (doubledate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (synchlink DRAM, SLDRAM), and direct rambus RAM (DR RAM).

[0171] The bus 804 may include, in addition to the data bus, a power bus, a control bus, a status signal bus, etc. However, for the sake of clarity, various buses are labeled as the bus 804 in the figure.

[0172] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented by software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid state drive (SSD).

[0173] 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.

[0174] 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.

[0175] 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.

[0176] In addition, the technical solutions between 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 cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0177] 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.

[0178] 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 heterogeneous message middleware communication method, applied to a heterogeneous message middleware communication system for application development in an autonomous driving intelligent cockpit, characterized in that: include: A multi-layer communication architecture is established from the abstract interface layer to the hardware abstraction layer, and a communication layer for parsing URL format and encapsulating third-party communication protocols is set between the abstract interface layer and the hardware abstraction layer; Provide services to the outside world in nodes, and use the topic-based service discovery mechanism to complete the communication interaction between nodes; Data is sent and received based on the instantiation protocol through publish-subscribe and reply-request methods.

2. The heterogeneous message middleware communication method according to claim 1, characterized in that: The multi-layer communication architecture from the abstract interface layer to the hardware abstract layer is established, and a communication layer for parsing URL format and encapsulating third-party communication protocols is provided between the abstract interface layer and the hardware abstract layer, further comprising: Define an abstract interface layer to abstract different communication protocols into publish-subscribe and request-response communication modes; Design the communication service adaptation layer to parse the string parameters in the URL format and adapt the protocol name obtained after parsing to the corresponding protocol; Establish a service communication management layer to encapsulate third-party communication protocols; Build a communication protocol transport layer to encapsulate vehicle-related third-party libraries; Add a hardware abstraction layer to abstract cross-device communication / cross-process communication into network transmission and shared memory transmission.

3. The heterogeneous message middleware communication method according to claim 2, characterized in that: In configuring the transmission data type of the abstract interface layer, use the conversion tool to convert the IDL protobuf type into an interface file; In the establishment of the service communication management layer, the third-party communication protocols include: DDS, FastDDS, Some / IP, ZMQ, and each third-party communication protocol is separately encapsulated in the communication service management layer; The string parameters in the URL format are parsed in the communication service adaptation layer. Specifically, the protocol name, service name, and version number are extracted by parsing the string parameters, so that the node can match the node information of the sender through service discovery to create a connection.

4. The heterogeneous message middleware communication method according to claim 1, characterized in that: The provision of services to the outside world in units of nodes, and the use of a topic-based service discovery mechanism to complete communication interactions between nodes, further includes: The node is specified through the QOS configuration file, or the default transmission scheme is adopted, which supports reliable transmission or unreliable transmission and is used to extract different interfaces of the underlying protocol.

5. The heterogeneous message middleware communication method according to claim 1, characterized in that: The method of sending and receiving data based on the instantiation protocol and in a publish-subscribe and reply-request manner further includes: In the process of heterogeneous message middleware publishing data, the application layer calls the abstract interface, inputs the URL format string, and parses the string in the communication service adaptation layer; If there are illegal characters or format errors in the parsed string, a failure message is returned; If no illegal characters or format errors are found in the parsed string, the parsing format is judged to be correct and the corresponding data information is obtained; Create an instantiation object of the corresponding protocol name through the communication protocol management layer and return the corresponding data.

6. The heterogeneous message middleware communication method according to claim 1, characterized in that: The method of sending and receiving data based on the instantiation protocol and in a publish-subscribe and reply-request manner further includes: In the process of heterogeneous message middleware subscription data, the application layer calls the abstract interface, inputs the URL format string and the callback function, and parses the string in the communication service adaptation layer; If there are illegal characters or format errors in the parsed string, a failure message is returned; If no illegal characters or format errors are found in the parsed string, the parsing format is judged to be correct and the corresponding data information is obtained; Create an instantiation object of the corresponding protocol name through the communication protocol management layer, complete service discovery and callback function registration, and return the created instantiation object.

7. A heterogeneous message middleware communication system, used to implement the heterogeneous message middleware communication method according to any one of claims 1 to 6, characterized in that: include: A multi-layer communication architecture establishment module is used to establish a multi-layer communication architecture from the abstract interface layer to the hardware abstraction layer, and a communication layer for parsing URL format and encapsulating third-party communication protocols is provided between the abstract interface layer and the hardware abstraction layer; The node unit communication interaction module provides services to the outside world based on the node, and uses the topic-based service discovery mechanism to complete the communication interaction between nodes; The instantiated protocol data interaction module sends and receives data based on the instantiated protocol through publish-subscribe and reply-request methods.

8. A smart cockpit, characterized in that: The smart cockpit is provided with the heterogeneous message middleware communication system 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.

Images