A middleware for service communication

Abstract

An embodiment of the present invention provides a service communication-oriented middleware, comprising: a service deployment application layer for providing a unified component interface and configuration and code generation tools for the development and deployment of service application software; a service communication interface layer for providing the service application software with a unified application call communication interface and a tool generation interface corresponding to the code generation tool; a service operation proxy layer for providing the service application software with a unified communication agent and communication callback processing mechanism required for operation; a service communication management layer for managing the communication process of the service application software through the communication proxy interface provided by the service operation proxy layer, and providing the service application software with a communication protocol interface required for adaptive communication transmission; and a service communication transmission layer for integrating at least one communication transmission protocol that the service communication transmission relies on. The middleware is capable of cross-platform porting and supports multiple systems and multiple protocol stacks.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a service-oriented communication middleware. Background Art

[0002] As smart car E / E architecture evolves from distributed to cross-domain convergence and then to a centralized computing platform, the traditional closed, static, distributed signal-oriented architecture (Signal-Oriented Architecture) no longer meets the requirements of current automotive E / E architectures due to the binding of communication software and components, low runtime flexibility, and inability to expand and reuse other software communication modules to achieve multi-domain convergence. Service-oriented architecture (SOA), on the other hand, will become the technological foundation for future "Software Defined Vehicles (SDVs)" in the automotive field due to its "interface standard accessibility," "high degree of decoupling," "high scalability," and "high reusability."

[0003] While SOA is relatively mature in the internet industry and boasts a comprehensive ecosystem, it's still in its exploratory stages in the field of connected car intelligent driving (ADAS). Existing software technologies only support a single operating system and protocol stack, and there are currently no complete, mature solutions for supporting multiple operating systems and protocol stacks. This is primarily due to the high system complexity and stringent functional safety certification requirements, preventing unified industry standards and communication protocols for automotive software middleware. Cross-domain data sharing and communication interaction in intelligent connected vehicles remain unresolved. Summary of the Invention

[0004] The embodiment of the present invention provides a service communication-oriented middleware, which can support cross-platform transplantation, support multiple systems and multiple protocol stacks, and achieve the effects of decoupling software and hardware and heterogeneous network communication.

[0005] In a first aspect, this embodiment provides a service-oriented communication middleware, including:

[0006] The service deployment application layer is used to provide a unified component interface as well as configuration and code generation tools for the development and deployment of service application software;

[0007] The service communication interface layer is used to provide a unified application call communication interface and a tool generation interface corresponding to the code generation tool to the service application software;

[0008] The service operation agent layer is used to provide the service application software with a unified communication agent and communication callback processing mechanism required for operation;

[0009] The service communication management layer is used to manage the communication process of the service application software through the communication agent interface provided by the service operation agent layer, and to provide the service application software with the communication protocol interface required for adaptive communication transmission;

[0010] The service communication transport layer is used to integrate at least one communication transport protocol that the service communication transport depends on, so that the service application software can call the matching communication transport protocol through the communication protocol interface determined by the service communication management layer.

[0011] An embodiment of the present invention provides a service communication-oriented middleware, comprising: a service deployment application layer, which is used to provide a unified component interface and configuration and code generation tools for the development and deployment of service application software; a service communication interface layer, which is used to provide a unified application call communication interface and a tool generation interface corresponding to the code generation tool to the service application software; a service operation agent layer, which is used to provide the service application software with a unified communication agent required for operation and a communication callback processing mechanism; a service communication management layer, which is used to manage the communication process of the service application software through the communication agent interface provided by the service operation agent layer, and provide the service application software with a communication protocol interface required for adaptive communication transmission; a service communication transport layer, which is used to integrate at least one communication transmission protocol that the service communication transmission depends on, so that the service application software can call the matching communication transmission protocol through the communication protocol interface determined in the service communication management layer. The service communication-oriented middleware provided by the above technical solution can be transplanted across platforms, supports multiple systems and multiple protocol stacks, and realizes the functions of decoupling software and hardware and heterogeneous network communication.

[0012] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0014] Figure 1 A schematic diagram of the structure of a service-oriented communication middleware provided in the first embodiment of the present invention;

[0015] Figure 2 A schematic diagram of the structure of another service-oriented communication middleware provided in the first embodiment of the present invention;

[0016] Figure 3 This is an example diagram of encapsulation of service communication messages in a service communication-oriented middleware provided in the first embodiment of the present invention;

[0017] Figure 4 This is an example diagram of the use of "publish / subscribe" middleware communication for service-oriented communication provided in the first embodiment of the present invention;

[0018] Figure 5 This is an example diagram of the use of "request / response" middleware communication for service-oriented communication provided in the first embodiment of the present invention;

[0019] Figure 6 This is an example diagram of the transmission of a "publish / subscribe" communication data flow of a service-oriented communication middleware provided in the first embodiment of the present invention;

[0020] Figure 7 This is a diagram illustrating an example of a "request / response" communication data flow transmission for a service-oriented communication middleware provided in the first embodiment of the present invention;

[0021] Figure 8 This is an example diagram of a timing sequence of a message sent by a service-oriented communication middleware provided in the first embodiment of the present invention;

[0022] Figure 9 This is an example diagram of the timing of receiving messages in a service-oriented communication middleware provided in the first embodiment of the present invention. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described 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 making creative efforts should fall within the scope of protection of the present invention.

[0024] It should be noted that the terms "original", "target", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or that are inherent to these processes, methods, products or devices.

[0025] Considering that the two main service-oriented communication protocols in the industry currently are SOME / IP (Scalabe Service-Oriented Middleware Over IP) and DDS (Data Distribution Service) protocol architectures, original equipment manufacturers (OEMs) will directly deliver service programs based on SOME / IP or DDS protocols, compiling and packaging them into libraries bound to the protocols when there is a demand for service-oriented communication. In addition, there may be other service-oriented communication protocol stacks such as Hypertext Transfer Protocol (HTTP) and Message Queuing Telemetry Transport (MQTT). Although these protocols are all service-oriented, the interfaces, message data frames, and protocol runtimes of different communication protocols are incompatible with each other. For application integration, if the communication protocol stack is bound, then any changes to the service components will require modification of all related applications, making the application code impossible to reuse and expand.

[0026] Existing software technology currently only supports a single operating system and a single protocol stack. There is currently no complete and mature solution to support multiple operating systems and multiple protocol stacks. Therefore, a solution that can solve the above problems is needed.

[0027] Example 1

[0028] Figure 1 This is a schematic diagram of the structure of a service-oriented communication middleware provided in the first embodiment of the present invention. This method is applicable to the case of supporting service-oriented communication of multiple operating systems and multiple protocol stacks. Figure 1As shown, the service communication-oriented middleware includes: a service deployment application layer 10, a service communication interface layer 20, a service operation agent layer 30, a service communication management layer 40, and a service communication transport layer 50. The service deployment application layer 10 is used to provide a unified component interface and configuration and code generation tools for the development and deployment of service application software; the service communication interface layer 20 is used to provide the service application software with a unified application call communication interface and a tool generation interface corresponding to the code generation tool; the service operation agent layer 30 is used to provide the service application software with a unified communication agent and communication callback processing mechanism required for operation; the service communication management layer 40 is used to manage the communication process of the service application software through the communication agent interface provided by the service operation agent layer, and provide the service application software with the communication protocol interface required for adaptive communication transmission; the service communication transport layer 50 is used to integrate at least one communication transmission protocol that the service communication transmission depends on, so that the service application software can call the matching communication transmission protocol through the communication protocol interface determined by the service communication management layer 40.

[0029] The service deployment application layer 10 is used to provide a unified component interface and configuration and code generation tools for the development and deployment of service application software.

[0030] Specifically, service application software can be understood as an application program (APP) installed on the vehicle that requires service-oriented communication, such as a high-level autonomous driving algorithm application. The service deployment application layer 10 is used to implement interaction between the middleware provided in this embodiment and the service application software. The service deployment application layer 10 can provide interfaces to components related to the service application software.

[0031] In this embodiment, the service deployment application layer 10 may include application infrastructure components, which primarily provide communication, scheduling, configuration parsing, and other core infrastructure. Application infrastructure components use communication nodes as deployment platforms, and application instances within service applications requiring communication are deployed on these nodes. Communication nodes can load and launch application instances required for communication within service applications by creating communication service instances. For example, communication service instances may include message subscribers, message publishers, message requesters, and message responders.

[0032] In addition, the service deployment application layer 10 also provides middleware-related configurations, which can be implemented as configuration files. These configuration files primarily provide middleware system-related configurations and define the message data structures of the service application software. Based on the characteristics and requirements of service-oriented communication, relevant information can be configured to form a configuration file set. For example, for service-oriented communication, it is necessary to configure a list of communication service instances, a list of communication protocols, a list of message definitions, and the corresponding node configurations.

[0033] It is understood that the service deployment application layer 10 also includes a code generation tool, which is used to generate a tool generation interface for the service communication interface layer 20 based on the aforementioned configuration file set. The code generation tool primarily reduces the workload of service application software development by abstracting business-independent template interfaces. Furthermore, by combining the unified interface encapsulated by the application infrastructure components, it achieves complete decoupling of the service application software and middleware.

[0034] It should be noted that when the service application software sends a message through the middleware, the service application software will send the original data and message ID through the communication interface encapsulated by the application infrastructure component of the service deployment application layer 10. When the service application software receives a message through the middleware, the middleware will return the execution processing result to the service application software.

[0035] The service communication interface layer 20 is used to provide a unified application calling communication interface and a tool generation interface corresponding to the code generation tool to the service application software.

[0036] In this embodiment, the "publish / subscribe" and "request / response" communication models are followed. Accordingly, the application calling communication interfaces may specifically include publishing, subscribing, requesting, and responding communication interfaces. At the same time, a service discovery interface may also be included for service registration and access.

[0037] It should be noted that the service communication interface layer 20 also provides a tool generation interface corresponding to the code generation tool. The tool generation interface is used to provide a unified standard interface code generated by the configuration tool, and is also used to compile and package the unified standard interface code into a dynamic library service plug-in for loading and calling by the service communication management layer 40. Exemplarily, the tool generation interface may include a data serialization interface and a deserialization interface. The serialization interface encapsulates the data serialization method, and the deserialization interface encapsulates the data deserialization method. By calling the data serialization interface, the serialization method can be called to serialize the data. By calling the data deserialization interface, the deserialization method can be called to deserialize the data. In addition, the tool generation interface may also include an interface encapsulating a protocol interpretation table, which is used to describe the configuration of communication protocol message data. Exemplary examples include configuration mappings such as event ID, method ID, service ID, etc. of the SOME / IP protocol, or configuration mappings such as message ID, domain ID, and quality of service of the DDS protocol. By utilizing the service communication interface layer 20 in the middleware provided in this embodiment, the service application software will have a unified protocol binding configuration and message configuration, so there is no need to care about different communication protocols mapped by the interpretation table.

[0038] The service operation agent layer 30 is used to provide the service application software with a unified communication agent and a communication callback processing mechanism required for operation.

[0039] In this embodiment, the service operation agent layer 30 provides the service application software with a unified communication agent required for operation, which is used for communication between the service application software and the peer service application. It is understandable that the communication scenarios for communication through middleware may include intra-process communication, inter-process communication, and inter-chip communication. Among them, intra-process communication refers to the communication service instance for communication being deployed on the same node of the same chip, inter-process communication refers to the communication service instance for communication being deployed on different nodes of the same chip, and inter-chip communication refers to the communication service instance for communication being deployed on nodes of different chips. Different agent interfaces can be set in the communication agent for different communication scenarios. For example, for intra-process communication, the agent interface in the communication agent is a local agent, and for inter-process communication or inter-chip communication, the agent interface in the communication agent is a remote agent.

[0040] In this embodiment, a unified communication callback processing mechanism is used to register an execution callback function through a unified application call communication interface and trigger it synchronously or asynchronously through the provided thread context, thereby achieving execution binding during service runtime. Exemplary execution binding can include subscription binding, publication binding, request binding, response binding, or service discovery binding.

[0041] The service communication management layer 40 is used to manage the communication process of the service application software through the communication agent interface provided by the service operation agent layer, and to provide the service application software with a communication protocol interface required for adaptive communication transmission.

[0042] In this embodiment, the service communication management layer 40 is the core layer of the entire middleware, connecting the upper and lower levels. It abstracts and unifies the communication proxy interface provided by the service operation proxy layer 30, and adapts and extends the different transport protocols of the service communication transport layer 50. The service communication management layer 40 primarily consists of a protocol stack management module and a protocol operation management module. The protocol stack management module manages the communication protocol stack proxy interface, service configuration instances, and adapts the communication protocol used for transmission. The protocol operation management module assists service application software in asynchronously sending and receiving messages and performing asynchronous callback processing during message communication.

[0043] It's important to note that, regarding the message sending process, when the protocol operation management module receives a user message, it must further encapsulate the user message into a unified protocol message before forwarding it to the protocol stack management module. In other words, the message received by the protocol stack management module is a unified protocol message. Accordingly, when the protocol stack management module receives a protocol transmission message, it encapsulates the protocol transmission message into a unified protocol message and forwards the unified protocol message to the protocol operation management module. When the protocol operation management module forwards the message to the service operation proxy layer 30, it parses the unified protocol message to obtain the user message, further triggering the unified communication callback process.

[0044] The service communication management layer 40 manages the communication process of the service application software, the communication protocol stack agent interface management, the service configuration instance management, and the adaptation management of the communication protocol used for communication transmission.

[0045] The service communication transport layer 50 is used to integrate at least one communication transport protocol that the service communication transport relies on, so that the service application software can call the matching communication transport protocol through the communication protocol interface determined by the service communication management layer 40 .

[0046] In this embodiment, the communication transmission protocol refers to an open source three-party communication transmission protocol, for example, supporting the service-oriented SOME / IP and DDS protocols. These two service-oriented communication protocols are mainly used for inter-chip communication, which can be understood as cross-machine communication. In addition, inter-process communication (IPC) can also be adapted and integrated.

[0047] Because different protocols have different protocol headers, message definitions, and communication interfaces, to ensure decoupling between the service communication management layer 40 and the service communication transport layer 50, the service communication management layer 40 repackages and adapts different communication protocol messages and interface definitions, providing unified message data and interface definitions to the service application software. Once the service communication management layer 40 determines the communication protocol interface for message communication, the service communication transport layer 50 integrates the communication transport protocols that the service communication relies on. This ensures that the service application software can call the matching communication transport protocol through the communication protocol interface to send messages.

[0048] An embodiment of the present invention provides a service communication-oriented middleware, comprising: a service deployment application layer, which is used to provide a unified component interface and configuration and code generation tools for the development and deployment of service application software; a service communication interface layer, which is used to provide a unified application call communication interface and a tool generation interface corresponding to the code generation tool to the service application software; a service operation agent layer, which is used to provide the service application software with a unified communication agent required for operation and a communication callback processing mechanism; a service communication management layer, which is used to manage the communication process of the service application software through the communication agent interface provided by the service operation agent layer, and provide the service application software with a communication protocol interface required for adaptive communication transmission; a service communication transport layer, which is used to integrate at least one communication transmission protocol that the service communication transmission depends on, so that the service application software can call the matching communication transmission protocol through the communication protocol interface determined in the service communication management layer. The service communication-oriented middleware provided by the above technical solution can be transplanted across platforms, supports multiple systems and multiple protocol stacks, and realizes the functions of decoupling software and hardware and heterogeneous network communication.

[0049] As an optional embodiment of the embodiment of the present invention, based on the above embodiment, the service deployment application layer 10 is further optimized and limited. Figure 2 A schematic diagram of another service-oriented communication middleware provided in the first embodiment of the present invention is shown in FIG. Figure 2 As shown, the service deployment application layer 10 includes: application basic components, which are used to provide the relevant basic components required for communication, scheduling, and configuration analysis for the development and deployment of service application software; a configuration file set, which is used to provide the service application software with the configuration files involved in the service communication and define the message data structure of the service application software in the service communication; a code generation tool, which is used as a tool for generating the code required for communication in the service communication, so as to generate the interface by calling the tool of the service communication interface layer, and generate the code file required for the communication of the service application software in combination with the configuration files in the configuration file set.

[0050] Application infrastructure components are used to provide the relevant infrastructure components required for communication, scheduling, and configuration analysis for the development and deployment of service application software.

[0051] Among them, the application basic components use communication nodes as deployment carriers, and the application instances that need communication in the service application software are all deployed on the communication nodes; the communication nodes load and start the application instances that need communication in the service application software by creating communication service instances; the communication service instances include: message subscribers, message publishers, message requesters and message responders.

[0052] It's important to note that communication nodes are business-independent infrastructure components. All service-oriented application instances requiring communication must be deployed on the nodes, loaded, and started by the node configuration. Message subscribers, message publishers, message requesters, and message responders are all communication service instances created by the nodes. Each app instance can create one or more communication service instances, which, following the "publish / subscribe" and "request / response" communication models, encapsulate the application call interface of the service communication interface layer.

[0053] The configuration file set is used to provide the service application software with the configuration files involved in the service communication and to define the message data structure of the service application software in the service communication.

[0054] Specifically, the configuration file set primarily involves the configuration of the middleware provided in this embodiment and the definition of the message data structure. The configuration files used by the service application software for service communication include: a communication service instance configuration list, a communication protocol configuration list, a message definition list, and a communication node configuration list for communication instance deployment. This embodiment does not impose specific restrictions on the files included in the configuration file set; they can be configured based on the requirements of service-oriented communication. The configuration files can be in the ARXML format, which is not a specific limitation.

[0055] In this embodiment, the messages of the service application software in the service communication include user messages (Topic), unified protocol messages (Parcel) and protocol transmission messages. For example, in order to more clearly describe the definition and packaging of user messages, unified protocol messages and protocol transmission messages, Figure 3 This is an example diagram of encapsulating service communication messages in a service communication-oriented middleware provided in the first embodiment of the present invention, referring to Figure 3 ,User message: consists of message ID (TopicId) and message body (Payload). The message body (Payload) encapsulates the data type ID (TypeId) and original data (Data). For all service application software, the original data sent through the communication interface will be directly encapsulated into a unified user message and forwarded to the service operation agent layer and protocol operation management module.

[0056] Continue to refer Figure 3, unified protocol message: consists of sender instance ID (Sender), receiver instance ID (Receiver), message type (Type), error code (ErrorCode) and user message (Topic), because these fields can basically adapt to all communication transmission protocols; when the protocol operation management module forwards the message to the protocol stack forwarder, the user message will be further encapsulated into a unified protocol message and passed to the corresponding protocol stack forwarder. Correspondingly, when the protocol stack forwarder receives the protocol transmission message, it will encapsulate the protocol transmission message into a unified protocol message and forward the protocol transmission message to the protocol operation management module by triggering a callback. When the protocol operation management module forwards the message to the service operation proxy layer, it will parse the unified protocol message package to get the user message and further trigger the communication unified callback processing.

[0057] Continue to refer Figure 3 Protocol-transmitted messages: Different communication protocols have different message header or body definitions for message transmission. For example, service-oriented communication protocols mainly include two mainstream protocol architectures: SOME / IP and DDS. The SOME / IP protocol message header consists of 4 bytes (32 bits) and a variable-length message body, while the DDS protocol is relatively complex and also consists of a 32-bit Real-Time Publish Subscribe (RTPS) fixed message header and a variable number of sub-messages. Sub-messages are composed of sub-message headers and sub-message bodies. The inter-process communication (IPC) protocol is similar to SOME / IP. It should be noted that although different protocol headers are complex, service-oriented, data-centric middleware does not require users to adapt to different protocol header fields. Instead, the service communication management layer adapts and filters most protocol header fields.

[0058] The code generation tool is used as a tool for generating the communication code required in the service communication, so as to generate the code file required for the service application software communication by calling the tool generation interface of the service communication interface layer 20 and combining the configuration file with the centralized configuration file.

[0059] In this embodiment, the code generation tool mainly generates a tool generation interface for the service communication interface layer 20 based on the configuration files in the configuration file set. The code generation tool mainly reduces the workload of service application software development by abstracting template interfaces that are not related to the business, and at the same time combines the unified interface encapsulated by the application basic components to achieve complete decoupling of the service application software and the middleware.

[0060] In order to more clearly illustrate the process of a node creating a communication service instance and configuring loading and starting, the middleware communication "publish / subscribe" usage example and the middleware communication "request / response" usage example provided in this embodiment are used as examples for description.

[0061] Figure 4 This is an example diagram of the use of "publish / subscribe" middleware communication for service-oriented communication provided by the first embodiment of the present invention. Figure 4 As shown in the figure, assuming that Node1 deploys the publishing application service, which is recorded as Node1-Writer, and Node2 deploys the subscription application service, which is recorded as Node2-Reader, the middleware communication "publish / subscribe" usage example can be expressed as:

[0062] Node1 deploys and publishes application services:

[0063] S11, main function entry creates a node;

[0064] S12, the node parses and loads the configuration file set;

[0065] S13. Construct a globally unique service instance ID based on the configuration file set;

[0066] S14. Create a node publishing service instance through the node and bind it to a globally unique instance ID;

[0067] S15. Publish the service instance and provide services through the registration service;

[0068] S16. Discover the peer service instance through the service discovery interface;

[0069] S17. Start a thread cycle to publish data test with the message ID "Test".

[0070] Node2 deploys subscription application services:

[0071] S21, main function entry creates a node;

[0072] S22, the node parses and loads the configuration file set;

[0073] S23. Construct a globally unique service instance ID based on the configuration file set;

[0074] S24. Create a subscription service instance of the node through the node and bind it to a globally unique instance ID;

[0075] S25. The subscription service instance provides services through the registration service;

[0076] S26. Discover the peer service instance through the service discovery interface;

[0077] S27, asynchronous execution: First construct and register the message processing callback function, then subscribe to the peer message ID, and finally the asynchronous callback will be triggered and executed.

[0078] Figure 5This is an example diagram of a service-oriented communication middleware communication "request / response" usage provided by the first embodiment of the present invention. Figure 5 As shown in the figure, assuming that Node1 deploys the request application service, which is denoted as Node1-Client, and Node2 deploys the response application service, which is denoted as Node2-Service, the middleware communication "request / response" usage example can be expressed as:

[0079] Node1 node deployment request application service:

[0080] S31, main function entry creates a node;

[0081] S32, the node parses and loads the configuration file set;

[0082] S33. Construct a globally unique service instance ID based on the configuration file set;

[0083] S34. Create a request service instance of the node through the node and bind it to a globally unique instance ID;

[0084] S35. Request the service instance to provide services through the registration service;

[0085] S36. Discover the peer service instance through the service discovery interface;

[0086] S37, asynchronous execution: first construct and register the message response processing callback function, then request the peer message ID and send the request data, and finally the asynchronous callback will be triggered to execute.

[0087] Node2 node deployment response application service:

[0088] S41, main function entry creates a node;

[0089] S42, the node parses and loads the configuration file set;

[0090] S43. Construct a globally unique service instance ID based on the configuration file set;

[0091] S44. Create a response service instance of the node through the node and bind it to a globally unique instance ID;

[0092] S45. The response service instance provides services through the registration service;

[0093] S46. Discover the peer service instance through the service discovery interface;

[0094] S47, asynchronous execution: first construct and register a message request processing callback function, and when a client request is received, process the request and then respond to the client with data of the same message ID.

[0095] Preferably, the application call communication interface in the service communication interface layer includes: a publishing communication interface, a subscription communication interface, a request communication interface and a response communication interface that follow the "publish / subscribe" and "request / response" communication modes; it also includes a service discovery interface that follows service-oriented communication; accordingly, the unified service application messages involved in service application software communication include: user messages, unified protocol messages and protocol transmission messages; the communication forms involved in service application software communication include: intra-process communication, inter-process communication and inter-chip communication.

[0096] The service communication interface layer includes application call interfaces, including publishing, subscription, request, and response communication interfaces that follow the "publish / subscribe" and "request / response" communication models. At the same time, a set of service discovery interfaces are designed in accordance with the principles of service-oriented communication. These service discovery interfaces are used for service registration and access. These interface calls follow the "Skeleton / Proxy" model. The Skeleton interface is primarily an interface called by service providers, such as service registration, deregistration, publishing, and response server-side interfaces. The Proxy interface is primarily an interface called by service consumers, such as service access, deregistration, subscription, unsubscription, and request interfaces.

[0097] To more clearly describe the data flow transmission of the middleware "publish / subscribe" communication, the following describes different communication scenarios. In the "publish / subscribe" model, a subscription service instance is created through a network communication node to subscribe to the messages published by the publishing service instance. Figure 6 This is an example diagram of a transmission of a "publish / subscribe" communication data flow of a service-oriented communication middleware provided in the first embodiment of the present invention, as shown in FIG. Figure 6 As shown:

[0098] In-process communication: The publishing service instance (denoted as Writer) and the subscription service instance (denoted as Reader) are created by the communication node 3 (denoted as Node3) on the chip SoC2. Since these two service instances are on the same node, the message (Topic) will be transmitted in-process (Intra). That is, when the Reader subscribes to the message ID of the Writer (denoted as TopicId), the Writer will send the message to the Reader through the process. In this scenario, the user message (Topic) transmission will not go through the protocol layer, but will directly share the original data asynchronously with the thread where the Reader is located.

[0099] Inter-process communication: The publishing service instance (denoted as Writer) created by communication node 1 (Node1) on chip SoC1 and the subscription service instance (denoted as Reader) created by communication node 2 (denoted as Node2) on the same chip. Since these two service instances are on different nodes of the same chip, this message (Topic) will be transmitted through inter-process communication (IPC). IPC transmission mainly uses shared memory, mainly due to its good intra-chip communication transmission performance. Although shared memory transmission is not a service-oriented protocol, data transmission still uses a unified communication interface and still follows the service discovery model and data serialization and deserialization process.

[0100] Inter-chip communication: a publishing service instance (denoted as Writer) created by communication node 2 (denoted as Node2) on chip SoC1 and a subscription service instance (denoted as Reader) created by communication node 3 (denoted as Node3) on SoC2. Since these two service instances are distributed on different chips, the message will be transmitted between chips. The inter-chip communication protocols mainly include SOME / IP protocol and DDS protocol, both of which are service-oriented communication protocols. Different from the prior art, SOME / IP is more commonly used in the middleware of the AUTomotive Open System ARchitecture (AUTOSAR) architecture platform, and DDS is more commonly used in the middleware of the Robot Operating System (ROS) architecture platform. The middleware provided by the present invention organically integrates the communication protocols of different architecture platforms and provides a unified standard for the service deployment application layer.

[0101] For the "request / response" mode, a message request service instance is created through a network communication node and sends a request to a response service instance. The message response service instance processes the request and responds to the request service instance. Figure 7 This is a diagram illustrating a transmission example of a "request / response" communication data flow of a service-oriented communication middleware provided in the first embodiment of the present invention. Figure 7 As shown in the figure, the transmission mode of the "request / response" communication data flow is the same as that of the "publish / subscribe" communication data flow, as follows:

[0102] Process communication: The response service instance (Service) and the request service instance (Client) are created by the communication node 3 (denoted as Node3) on the chip SoC2. Since these two service instances are on the same node, the message (Topic) will be transmitted intra-process (Intra).

[0103] Inter-process communication: The response service instance (denoted as Service) created by communication node 1 (denoted as Node1) on chip SoC1 and the request service instance (denoted as Client) created by communication node 2 (denoted as Node2) on the same chip. Since these two service instances are on different nodes of the same chip, this message (Topic) will be transmitted through inter-process communication (IPC).

[0104] Inter-chip communication: The response service instance (denoted as Writer) created by communication node 2 (denoted as Node2) on chip SoC1 and the request service instance (denoted as Reader) created by communication node 3 (denoted as Node3) on SoC2. Since these two service instances are distributed on different chips, this message will be transmitted inter-chip. However, the communication mode is different. When the client requests, it also needs to send a request message (Topic). After receiving the request message, the service side will respond with a response message (Topic) to the client. Although the message ID (TopicId) of these two topics is the same, the data they carry may not be the same. Therefore, in the "request / response" mode, the message ID describes not a single data type, but rather the binding relationship between the data type requested by the requesting side (Client) and the data type responded by the responding side (Service). This is actually similar to the interface description ID of the SOME / IP protocol, that is, remote procedure call.

[0105] As an optional embodiment of the present invention, on the basis of the above embodiment, the tool generation interface in the service communication interface layer 20 is further optimized and limited to provide a unified standard interface code generated based on the configuration tool, and also to compile and package the unified standard interface code into a dynamic library service plug-in for the service communication management layer to load and call.

[0106] The tool-generated interfaces include data serialization, data deserialization, and a protocol interpretation table interface. The data serialization and deserialization interfaces follow the "Proxy / Skeleton" model. The Skeleton interface encapsulates the data serialization methods for publishing and responding, and the data deserialization methods for proxy-side requests; the Proxy interface encapsulates the data serialization methods for requesting, and the data deserialization methods for publishing and responding on the Skeleton side.

[0107] The Protocol Interpretation Table (ProtocolTable) describes the configuration of communication protocol message data, such as the event ID, method ID, and service ID configuration mappings for the SOME / IP protocol, or the message ID, domain ID, and quality of service configuration mappings for the DDS protocol. Service applications use unified protocol binding and message configurations, eliminating the need to worry about the different communication protocols mapped by the interpretation table. It's important to understand that the data serialization and deserialization interfaces are generated by the service provider's configuration tools. Some service instances may not provide services, but the tool still generates empty instances.

[0108] As an optional embodiment of the present invention, on the basis of the above embodiment, the communication unified agent in the service operation agent layer 30 is further optimized and limited to provide a unified communication service agent to the service application software for communication between the service application software and the peer service application; wherein, the agent interface in the communication service agent includes a local agent for intra-process communication and a remote agent for inter-process communication or inter-chip communication.

[0109] In this embodiment, the unified communication agent in the service operation agent layer is used to provide a unified communication service agent to the service application software for communicating with the opposite service application. Specifically, the communication service agent mainly obtains the agent interface for communicating with the opposite end through the service discovery mechanism. The agent interface includes two types: local agent and remote agent. Among them, the local agent mainly uses local communication, that is, intra-process communication, while the remote agent uses cross-process (inter-process) or cross-machine (inter-chip) communication. Local agent data transmission is mainly through shared pointer data transmission, while remote agent data transmission needs to be serialized and deserialized on different communication transmission protocols for data transmission. Therefore, the unified communication agent also realizes the network communication routing gateway function to a certain extent.

[0110] Furthermore, the unified communication callback processing mechanism in the service operation agent layer 30 is used to register the execution callback function through a unified application call communication interface, and trigger it synchronously or asynchronously through the provided thread context to realize execution binding during service runtime; wherein, execution binding includes: subscription binding, publication binding, request binding, response binding and service discovery binding.

[0111] In this embodiment, the unified communication callback processing process can be described as follows: The unified communication callback processing mechanism in the service runtime proxy layer primarily registers execution callback functions through a unified application call interface and triggers them synchronously or asynchronously using the thread context provided by the runtime, thereby implementing execution binding during the service runtime. The service runtime includes execution bindings such as subscription binding, publish binding, request binding, response binding, and service discovery binding. All of these are scheduled and processed using the unified service runtime thread context.

[0112] As an optional embodiment of the present invention, on the basis of the above embodiment, the service communication management layer 40 is further optimized, including: a protocol stack management module for performing communication protocol stack proxy interface management, service configuration instance management, and adaptation management of the communication protocol used for communication transmission; a protocol operation management module for assisting the service application software in asynchronously sending and receiving messages during message communication and performing asynchronous processing of callbacks.

[0113] The service communication management layer 40 is the core layer of the entire middleware, connecting the upper and lower levels. It abstracts and unifies the communication proxy interface provided by the service operation proxy layer 30 and adapts and expands the transport protocols of the different service communication transport layers 50. The service communication management layer 40 primarily consists of a protocol stack management module and a protocol operation management module.

[0114] Specifically, communication protocol stack proxy interface management can be understood as the management and storage of communication protocol stack proxy interfaces corresponding to different communication service instances. Service configuration instance management can be understood as the management and storage of service configuration instances that follow the "skeleton / proxy" model. Communication protocol adaptation management can be understood as adapting different transmission protocols for service applications through the integration of protocol stack data forwarding proxy interfaces. The protocol operation management module ensures secure synchronous or asynchronous data forwarding.

[0115] Preferably, the protocol stack management module includes: a protocol stack manager, which is used to manage and store the communication protocol stack proxy interfaces corresponding to different communication service instances; a protocol stack interpreter, which is used to manage and store service configuration instances that follow the "skeleton / proxy" model; and a protocol stack forwarder, which is used to adapt different transmission communication protocols for the service communication of the service application software by inheriting the protocol stack data forwarding proxy interface.

[0116] In this embodiment, the protocol stack manager manages and stores the communication protocol stack proxy interfaces corresponding to different service instances. The proxy interfaces are created during initialization and obtain the communication protocol stack data forwarding proxy interfaces during remote service discovery.

[0117] In this embodiment, the protocol stack interpreter mainly manages and stores "skeleton / proxy" service configuration instances. During initialization, it generates an interface through a loading tool to compile an integrated dynamic library plug-in to obtain the skeleton instance interface and the proxy instance interface, that is, to obtain the protocol interpretation table and data serialization and deserialization interfaces corresponding to the service instance. The protocol stack interpreter has one and only one skeleton instance and multiple proxy instances. This is because in service-oriented, service instances are globally unique. The protocol stack interpreter describes the protocol interpretation table and data serialization and deserialization methods provided by this service. The interpretation table and proxy methods can be accessed by all other service instances within the domain.

[0118] In this embodiment, the protocol stack forwarder inherits the protocol stack data forwarding proxy interface to adapt to different transmission communication protocols. An instance is created during initialization and provided to the service runtime management layer by the protocol stack manager during service discovery. Different communication transmission protocols have different protocol forwarder instances and protocol interpreter instances. For example, the SOME / IP protocol stack corresponds to the SOME / IP protocol stack interpreter and the SOME / IP protocol stack forwarder, the DDS protocol stack corresponds to the DDS protocol stack interpreter and the DDS protocol stack forwarder, and the IPC protocol stack corresponds to the IPC protocol stack interpreter and the IPC protocol stack forwarder. It is understandable that the protocol stack forwarder truly adapts to the transmission communication protocol interface, so the data forwarding proxy instance implements both the skeleton interface and the proxy interface, and supports both service-oriented and non-service-oriented communication transmission protocols.

[0119] It's important to note that the protocol stack manager is an object instance shared within a communication node, while the protocol stack interpreter and protocol stack forwarder are shared within services such as subscription and publishing. That is, a node has only one protocol stack manager, and a service instance has only one protocol stack interpreter and protocol stack forwarder. A node can have multiple service instances, so a protocol stack manager stores the mapping between different service instances and different service protocol stacks. It is precisely this protocol stack management capability that enables middleware to seamlessly integrate different communication transport protocols.

[0120] Preferably, the protocol operation management module sends and receives messages asynchronously through the protocol runtime processing unit included when the service application software communicates; wherein, the interface with the communication mode of subscription and request mode sends and receives messages through the protocol proxy channel in the protocol operation management module; the interface with the communication mode of release and response mode sends and receives messages through the protocol skeleton channel in the protocol operation management module; the protocol operation management module also triggers the response execution binding callback by parsing the protocol message packet and forwarding it to the communication unified callback processing mechanism on the service operation proxy layer corresponding to the opposite application.

[0121] In this embodiment, the protocol stack management module is instantiated during service initialization and service discovery, and when the service communicates, the protocol runtime unit included in the protocol operation management module is required to asynchronously send and receive messages. For the protocol runtime unit, the "skeleton / proxy" model is still followed, and the communication mode is distinguished. For the subscription and request mode interfaces, the protocol proxy channel (ProtocolProxyChannel) is used; for the release and response mode interfaces, the protocol skeleton channel (ProtocolSkeletonChannel) is used. No matter which channel the protocol runtime processing unit takes, the data is ultimately sent and received by the protocol stack forwarder, because the protocol runtime processing unit inherits the protocol stack data forwarding proxy callback interface, and the protocol stack forwarder also registers the protocol stack data forwarding proxy callback interface. Therefore, the data is sent and received inside the protocol stack forwarder, and the asynchronous processing of the callback is handed over to the protocol runtime processing unit. The protocol runtime processing unit will eventually parse the protocol message packet and forward it to the corresponding service operation proxy layer 30 for unified communication callback processing, and trigger the corresponding execution binding callback.

[0122] Furthermore, the communication transmission protocols integrated by the service communication transmission layer 50 include: supporting the service-oriented SOME / IP protocol, supporting the service-oriented DDS protocol, and a shared memory transmission protocol for inter-process communication.

[0123] In this embodiment, the service communication transport layer 50 mainly integrates and extends different open source three-party communication transport protocols. Exemplarily, the service communication transport layer 50 mainly supports the integration of service-oriented SOME / IP protocol open source software and DDS protocol open source software. In addition, the self-developed IPC shared memory transport protocol can also be adapted and integrated. Since different protocols have different protocol headers, message definition methods and different communication interfaces, in order to ensure the decoupling of the service communication management layer 40 and the service communication transport layer 50, the service communication management layer 40 repackages and adapts different communication protocol messages and interface definitions, and provides unified data message and interface definitions to the application APP. In this embodiment, there is no specific restriction on the communication transmission protocol integrated by the service communication transport layer 50.

[0124] The above optional embodiment provides a service-oriented communication middleware that supports multiple systems and multiple protocol stacks in the intelligent driving domain. It adopts a unified standard "skeleton / proxy mode" communication interface and code generation tools to make the component code it implements highly reusable and scalable; at the same time, it can adapt to non-service-oriented communication protocol stacks to make customized components, allowing different transmission protocols to transmit data through a unified "skeleton / proxy interface"; it supports dynamic and static binding of protocols, and the communication agent and routing module switch the protocol stack, while supporting inter-chip and intra-chip (inter-process and intra-process) communication; it supports publish / subscribe and request / response full-duplex communication mode, adapted and extended for the real-time publish-subscribe protocol in DDS; multi-protocol stack management supports service-oriented SOME / IP, DDS protocol stack and IPC (shared memory) communication protocol; protocol runtime components enable communication data forwarding to be securely processed synchronously or asynchronously; zero-copy and high-performance data serialization and deserialization components are used to ensure data transmission efficiency and security; service instance ID and message instance ID rules and configurations are defined to implement data security access control and multi-channel data fusion functions; a layered design is used to decouple protocol-related communication components from protocol-independent communication components, allowing it to organically integrate the other three parties' middleware communication architecture.

[0125] In order to more clearly illustrate how the middleware provided by this technical solution communicates, the following description is given using the scenarios of the middleware receiving and sending messages as examples. Figure 8 This is an example diagram of a timing diagram of a service-oriented communication middleware sending message according to the first embodiment of the present invention. Figure 8 As shown in the figure, the timing of sending messages in the service-oriented communication middleware communication can be expressed as:

[0126] S51. The service application software (APP) sends original data (Data) and message ID (TopicId) through the communication interface encapsulated by the application basic component (AppFramework).

[0127] S52. The sending service instance encapsulates the parameters passed by the service application software into a user message (Topic) and the encapsulated execution callback binding and sends it out through the application calling the communication interface. Among them, the sending service instance can be a Writer, Client, or Service service instance, that is, an object that can publish, request, respond, etc. and needs to send data.

[0128] S53. The service operation agent layer encapsulates all the messages of the context through commands (Command), and passes (Post) the commands to the runtime thread task queue in an asynchronous manner through the executor (Executor). At this time, the result of the application data sending, that is, the error code (ErrorCode), is immediately returned, indicating whether the data of the service application software can be normally scheduled and processed by the service operation agent layer.

[0129] S54. The executor will synchronize the task queue of the runtime in an asynchronous blocking manner on its working thread, and process the message in the command to pass the parameters to the protocol runtime processing unit through the unified communication agent interface of the service operation agent layer.

[0130] S55. The protocol runtime processing unit further encapsulates the parameters transmitted by the unified agent interface into a unified protocol message (Parcel) and forwards it to the protocol stack forwarder through the protocol agent or skeleton channel.

[0131] S56. The protocol stack forwarder will, based on the pre-bound transport protocol, eventually convert the data encapsulated by the Parcel message into a transport protocol message by serializing it and following the protocol header of the transport protocol, and send it out through the service communication transport layer. At this time, it will immediately return the error code result sent by the protocol runtime processing unit message.

[0132] It can be understood that the process of sending messages by middleware communication is realized through steps S51-S56.

[0133] Figure 9 This is an example diagram of a timing diagram of a service-oriented communication middleware receiving message provided in the first embodiment of the present invention. Figure 9 As shown in the figure, the timing of receiving messages in the service-oriented communication middleware can be expressed as:

[0134] S61. The service application software (APP) needs to register the callback (Callback) for processing messages in advance through the interface provided by the application basic component (AppFramework), and perform binding and encapsulation on the callback interface by receiving the service instance subscription or request interface.

[0135] S62. The service communication transport layer provides a callback interface for message reception. The protocol stack forwarder receives messages asynchronously in the callback thread of the transport protocol and parses the transport protocol message first according to the transport protocol header.

[0136] S63. The protocol stack forwarder deserializes the protocol message data into a message (Topic) and encapsulates it into a unified protocol message (Parcel). Then, the Parcel message is notified to the protocol runtime processing unit through the unified proxy callback interface. At this time, an error code is immediately returned to indicate that the transmission protocol message processing is completed and the message will be handed over to the protocol runtime processing unit for scheduling and processing. This is also to avoid blocking the message receiving thread and ensure the stability and reliability of message communication.

[0137] S64. The protocol runtime processing unit further parses the Pacel package into a user message (Topic) and notifies the service runtime proxy layer.

[0138] S65. The service execution proxy layer encapsulates all the messages in the context through commands, and asynchronously posts the commands to the runtime thread task queue through the executor, and immediately returns an error code. It should be noted that the service execution proxy layer context has multiple executors. For example, refer to Figure 8 and Figure 9 The message sending and receiving shown are handled in two different thread contexts.

[0139] S66: The receiving service instance processes the execution callback function registered by the service application software in the thread context on the execution binding, and returns the execution processing result to the service application software.

[0140] It can be understood that the process of the middleware communicating and receiving messages is implemented through steps S61-S66.

[0141] It is worth noting that in the above-mentioned embodiment of the service communication-oriented middleware, the various layers included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention.

[0142] Note that the above are only preferred embodiments of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments and may include many other equivalent embodiments without departing from the concept of the present invention. The scope of the present invention is determined by the scope of the appended claims.

Claims

1. A service-oriented communication middleware, characterized in that: include: The service deployment application layer is used to provide a unified component interface as well as configuration and code generation tools for the development and deployment of service application software; The service communication interface layer is used to provide a unified application call communication interface and a tool generation interface corresponding to the code generation tool to the service application software; The service operation proxy layer is used to provide the service application software with a unified communication proxy and communication callback processing mechanism required for operation; wherein the proxy interface in the communication proxy includes a local proxy for intra-process communication and a remote proxy for inter-process communication or inter-chip communication; The service communication management layer is used to manage the communication process of the service application software through the communication agent interface provided by the service operation agent layer, and to provide the service application software with the communication protocol interface required for adaptive communication transmission; The service communication transport layer is used to integrate at least one communication transport protocol that the service communication transport relies on, so that the service application software can call the matching communication transport protocol through the communication protocol interface determined by the service communication management layer; Among them, the communication unified callback processing mechanism in the service operation agent layer is used to register the execution callback function through a unified application call communication interface, and trigger it synchronously or asynchronously through the provided thread context to achieve execution binding during service runtime; The execution binding includes: subscription binding, publication binding, request binding, response binding and service discovery binding.

2. The middleware according to claim 1, characterized in that The service deployment application layer includes: Application infrastructure components are used to provide the relevant infrastructure components required for communication, scheduling, and configuration analysis for the development and deployment of service application software; A configuration file set, used to provide the service application software with configuration files involved in service communication and to define the message data structure of the service application software in service communication; The code generation tool is used as a tool for generating the code required for communication in service communication, by calling the tool generation interface of the service communication interface layer, and combining the configuration file with the centralized configuration file to generate the code file required for service application software communication.

3. The middleware according to claim 2, characterized in that The application basic components use the communication node as a deployment carrier, and the application instances that need to communicate in the service application software are all deployed on the communication node; The communication node creates a communication service instance to load and start the application instance that the service application software needs to communicate; The communication service instance includes: a message subscriber, a message publisher, a message requester, and a message responder.

4. The middleware according to claim 2, characterized in that The configuration files involved in service communication by the service application software include: a communication service instance configuration list, a communication protocol configuration list, a message definition list, and a communication node configuration list for communication instance deployment.

5. The middleware according to claim 1, characterized in that The application call communication interface in the service communication interface layer includes: a publishing communication interface, a subscription communication interface, a request communication interface, and a response communication interface that follow the "publish / subscribe" and "request / response" communication modes; and also includes a service discovery interface that follows service-oriented communication; Accordingly, the unified service application messages involved in service application software communication include: user messages, unified protocol messages, and protocol transmission messages; The communication forms involved in service application software communication include: intra-process communication, inter-process communication and inter-chip communication.

6. The middleware according to claim 1, characterized in that The tool generation interface in the service communication interface layer is used to provide a unified standard interface code generated based on the configuration tool, and is also used to compile and package the unified standard interface code into a dynamic library service plug-in for the service communication management layer to load and call.

7. The middleware according to claim 1, characterized in that The communication unified agent in the service operation agent layer is used to provide a unified communication service agent to the service application software, so as to enable the service application software to communicate with the opposite service application.

8. The middleware according to claim 1, characterized in that The service communication management layer includes: The protocol stack management module is used to manage the communication protocol stack agent interface, service configuration instance management, and the adaptation management of the communication protocol used for communication transmission; The protocol operation management module is used to assist the service application software in asynchronously sending and receiving messages during message communication and performing asynchronous processing of callbacks.

9. The middleware according to claim 8, characterized in that The protocol stack management module includes: The protocol stack manager is used to manage and store the communication protocol stack proxy interfaces corresponding to different communication service instances; The protocol stack interpreter is used to manage and store service configuration instances that follow the "skeleton / proxy" model; The protocol stack forwarder is used to adapt different transmission communication protocols for the service communication of the service application software by inheriting the protocol stack data forwarding agent interface.

10. The middleware according to claim 8, characterized in that The protocol operation management module, through the included protocol operation processing unit, asynchronously sends and receives messages when the service application software communicates; Wherein, the interface in the subscription and request modes of communication sends and receives messages through the protocol proxy channel in the protocol operation management module; The interface in the communication mode of the publish and respond mode sends and receives messages through the protocol skeleton channel in the protocol operation management module; The protocol operation management module also triggers the response execution binding callback by parsing the protocol message packet and forwarding it to the communication unified callback processing mechanism on the service operation proxy layer corresponding to the opposite application.

11. The middleware according to claim 1, characterized in that The communication transport protocols integrated in the communication transport layer include: a service-oriented SOME / IP protocol, a service-oriented DDS protocol, and a shared memory transport protocol for inter-process communication.

Images