Message middleware system based on data distribution service specifications

Abstract

The invention discloses a message middleware system based on data distribution service specifications, and relates to the technical field of communication management. The system comprises an application layer, middleware and an operating system, wherein the middleware comprises a message distribution component, an Ethernet communication component, a PCIE communication component, a 1394 communication component and a time management component; according to the method, business logic is abstracted into service, and the service is divided into a portable component or a specific platform component; the middleware adds servitization and containerization technologies on the basis of the FACE architecture to form a servitization framework and an execution environment; the application software only needs to concentrate on self function logic development; through middleware software, efficient communication, data sharing and business process management can be realized among services.

Description

Technical Field

[0001] The present invention relates to the technical field of communication management, and in particular to a message middleware system based on data distribution service specifications. Background Art

[0002] As the complexity of avionics system business logic continues to grow, traditional monolithic application architectures are no longer able to meet the business requirements of rapid iteration, flexible expansion, and high availability. This is why service-oriented architectures have emerged. They break complex business systems into multiple independent, reusable services. Each service focuses on a specific business function and works together through lightweight communication mechanisms. This achieves high cohesion and low coupling in the system, greatly improving system maintainability, scalability, and development efficiency. However, service-oriented architectures also bring challenges such as inter-service communication, data consistency, and service governance.

[0003] The existing technology is based on the framework design of the task system software. The functional nodes run on a unified task system software execution environment. The execution environment shields the differences between the underlying hardware and operating system through abstraction and encapsulation technology. The application functional software completes the designed functions of the functional node through the interface services provided by the execution environment; at the same time, the application functional node should also implement several standard interfaces to the task system execution environment so that the execution environment can obtain the application running status and input information to the application.

[0004] However, this design concept faces a series of problems, such as team coordination. As the complexity of business upgrade applications increases, small teams are prone to coordination and code conflicts when maintaining a set of codes. Large-scale applications have high maintenance costs, and any small change requires compiling the entire project, which leads to a significant increase in compilation, testing, and deployment time. Excessively long ICDs lead to coupling problems, and the application's reusability and portability are not strong.

[0005] Therefore, it is necessary to provide a message middleware system based on data distribution service specifications to solve the technical problems of poor versatility of existing technical platforms, high cost of change compilation, and poor reusability and portability. Summary of the Invention

[0006] The purpose of the present invention is to overcome the shortcomings of the background technology and provide a message middleware system based on data distribution service specifications, aiming to provide efficient and reliable service communication and data synchronization functions, ensure the stable operation and efficient collaboration of the entire system, realize the separation of business logic, data conversion and network connection, and provide system flexibility.

[0007] The purpose of the present invention is achieved through the following technical solutions: The present invention provides a message middleware system based on a data distribution service specification, comprising an application layer, middleware, and an operating system, wherein the middleware comprises: Message distribution component: provides a publish-subscribe mechanism to implement message distribution and communication, distributes messages received by the transport layer to the target module, and supports message sending and receiving of the service framework; Ethernet communication component: completes the encapsulation of Ethernet drivers, performs network initialization, creates connections, and sends and receives messages; PCIE communication component: completes the encapsulation of PCIE driver, performs related initialization, creates connections, and sends and receives messages; 1394 communication component: completes the encapsulation of 1394 bus communication, performs 1394 bus initialization, creates connections, and sends and receives messages; Time management component: responsible for encapsulating the time setting and obtaining interface, providing unified services for the following clocks or timers to the application; The application layer is used to run the application program and is respectively connected to the message distribution component, PCIE communication component, RS422 communication component, 1394 communication component and time management component through the middleware API, and the message distribution component is connected to the Ethernet communication component; The operating system is deployed with Ethernet driver, 422 driver, 1394 driver and operating system functions, and is respectively connected to the Ethernet communication component, PCIE communication component, RS422 communication component and 1394 communication component through a hardware abstraction environment.

[0008] As a further solution, the message distribution component includes an interface layer and a logic layer; wherein, the interface layer is configured with a publisher creation interface and a subscriber creation interface; the logic layer is provided with a publishing end, a subscriber end, a data sending module, a data receiving module, a topic and a data management module.

[0009] As a further solution, the publisher creates and configures the required entities through the following steps: Get an instance of the domain participant factory and create a domain participant; Register the corresponding subject data type with the domain participant; Create a topic for the registered data type using the domain participant; Create a publisher using the domain participant; Use the created publisher to build a data writer to publish topic data.

[0010] As a further solution, the publisher sends data samples through the following steps: Assign the data to be sent to the variable corresponding to the topic type; Call the Write operation of the data writer; For instances where no key is defined or not registered, the variable to be assigned is passed with DDS_HANDLE_NIL; For a registered theme instance with a defined key, pass the assigned variable along with the handle returned when registering the instance; The Write operation stores the passed variable into the data writer's buffer, which becomes a data sample. Among them, the data samples in the buffer area will be transmitted according to the QoS policy of the publisher and data writer; if there is a successful matching data reader, the data sample will be transmitted to the physical layer before the Write operation returns.

[0011] As a further solution, the data receiving mode set by the subscriber includes an asynchronous notification mode and a synchronous waiting mode; wherein, Asynchronous notification: When a new data sample arrives, the distribution service component notifies the application through a listener on the subscriber or data reader. During the execution of the listener callback operation, the application can access the data by calling the read or take operation on the data reader. Synchronous waiting mode: The application creates a condition and a wait set, and calls the wait operation of the wait set to wait for new data samples; the distribution service component will block the application thread until the new sample arrives; then, the application calls the read or take operation on the data reader to access the data sample from the receive buffer.

[0012] As a further solution, the subscriber creates and configures the required entities through the following steps: Get an instance of the domain participant factory and create a domain participant; Register the corresponding subject data type with the domain participant; Create a topic for the registered data type using the domain participant; Create a subscriber using the domain participant; Create a generic type data reader for the topic using the publisher.

[0013] As a further solution, use asynchronous notification to receive data samples by following the steps below: Create a data reader listener for a data reader or a subscriber listener for a subscriber; The application creates a data reader listener with the on_data_available callback enabled. When a new data sample arrives, the distribution component executes the on_data_available callback of the listener. The application creates a subscriber listener with the on_data_on_readers callback enabled. When a new data sample arrives, the distribution component executes the listener's on_data_on_readers callback.

[0014] As a further solution, create a publisher interface by following the steps below: Create a domain participant: Get the domain participant factory and create a domain participant in the domain participant factory. For domain participants in the data domain, the default QoS policy is adopted, and the domain ID of the created domain participant must be consistent in the publisher and subscriber; Create publisher: Create a publisher through domain participants to publish topics and attach the publisher to TCP / UDP transmission; Register topic data type: Use domain participants in the data domain to register the topic data type and define the name of the topic data type, which must match it in the subscriber. When creating a topic, specify the name of the topic type, allowing data writers of the topic to create registered data types. Create a topic: Use domain participants to create a topic, define variables to store the topic name, and bind each topic to a data type; Create a data writer: Use the created publisher to build a data writer for publishing topic data. To define a topic, you need to build a data writer; Register a topic instance: Define and register a topic instance for sending topic data.

[0015] As a further solution, create a subscriber interface by following the steps below: Establish a data reader listener: The data reader will attach a data reader listener. Whenever a data sample is received from the publisher, the message distribution uses the corresponding callback operation of the listener to notify the arrival of a new data sample. Define the DataReaderListenerImpl class, implement the DDS::DataReaderListener IDL interface in the listener class, and overload the virtual functions from the interface; The data reader listener class needs to reload all callback operations; when a new data sample arrives, the message dispatcher calls the operation to pass the data; Create a domain participant: obtain a domain participant factory, create a domain participant in the domain participant factory, and use the default QOS; Create subscriber: Create a subscriber to subscribe to a topic and attach the subscriber to the TCP / UDP transmission; Register subject data type: Use domain participants to register data types, and the type name should be consistent with the domain publisher; Create Topic: Create information topic; Create a data reader and a data reader listener to receive data from the corresponding topic.

[0016] The message middleware system based on the data distribution service specification of the present invention has at least the following beneficial effects: The present invention includes an application layer, middleware and an operating system, wherein the middleware includes a message distribution component, an Ethernet communication component, a PCIE communication component, a 1394 communication component and a time management component; wherein the present invention abstracts business logic into services and divides them into portable components or specific platform components; the middleware adds service-oriented and containerized technologies on the basis of the FACE architecture to form a service-oriented framework and an execution environment; application software is developed based on the middleware service-oriented operation framework interface, and the service-oriented framework is responsible for service registration discovery, service link tracking, service governance, RPC communication and other functions, while the execution environment is responsible for message distribution, IO bus adaptation, time management and other functions, and the application software only needs to focus on its own functional logic development; through the middleware software, efficient communication, data sharing and business process management can be achieved between services. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 A schematic diagram of the structure of a message middleware system based on the data distribution service specification provided by the present invention; Figure 2 A schematic diagram of the architecture and composition of the message distribution function provided by the present invention; Figure 3 A schematic diagram of the timing of message distribution provided by the present invention; Figure 4 A schematic diagram of the overall publish / subscribe process provided by the present invention; Figure 5 A schematic diagram illustrating the function of the message distribution component provided by the present invention; Figure 6 A schematic diagram of the class structure of the publisher provided by the present invention; Figure 7 A schematic diagram of the class structure of the subscriber side provided by the present invention; Figure 8 A schematic diagram of the architecture and composition of the Ethernet function provided by the present invention; Figure 9 A schematic diagram of the main process of Socket communication provided by the present invention; Figure 10A schematic diagram of the PCIE architecture provided by the present invention; Figure 11 A schematic diagram of the PCIE communication process provided by the present invention; Figure 12 The architecture and composition diagram of the communication function of the RS422 communication component provided by the present invention; Figure 13 Schematic diagram of the communication flow of the RS422 communication module provided by the present invention; Figure 14 This is a schematic diagram of the 1394 communication module architecture provided by the present invention; Figure 15 A schematic diagram of the encapsulation process of the 1394 bus communication provided by the present invention; The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations.

[0020] Refer to the attached Figure 1 The present invention discloses a message middleware system based on a data distribution service specification, comprising an application layer, a middleware and an operating system, wherein the middleware comprises: Message distribution component: provides a publish-subscribe mechanism to implement message distribution and communication, distributes messages received by the transport layer to the target module, and supports message sending and receiving of the service framework; Ethernet communication component: completes the encapsulation of Ethernet drivers, performs network initialization, creates connections, and sends and receives messages; PCIE communication component: completes the encapsulation of PCIE driver, performs related initialization, creates connections, and sends and receives messages; 1394 communication component: completes the encapsulation of 1394 bus communication, performs 1394 bus initialization, creates connections, and sends and receives messages; Time management component: responsible for encapsulating the time setting and obtaining interface, providing unified services for the following clocks or timers to the application; The application layer is used to run the application program and is respectively connected to the message distribution component, PCIE communication component, RS422 communication component, 1394 communication component and time management component through the middleware API, and the message distribution component is connected to the Ethernet communication component; The operating system is deployed with Ethernet driver, 422 driver, 1394 driver and operating system functions, and is respectively connected to the Ethernet communication component, PCIE communication component, RS422 communication component and 1394 communication component through a hardware abstraction environment.

[0021] It should be noted that this embodiment proposes a middleware software solution; as a core component in the service-oriented architecture, the middleware software aims to provide efficient and reliable service communication, data synchronization and service governance functions, thereby ensuring the stable operation and efficient collaboration of the entire system.

[0022] Applications supporting a service-oriented architecture communicate through messaging, providing asynchronous communication mechanisms that allow applications to exchange data across diverse network hardware platforms, operating systems, and network protocols. By designing and implementing middleware software, we aim to understand the design principles of the execution environment and provide technical support for service-oriented solutions.

[0023] The terms and abbreviations involved in the solution of this embodiment are as follows: DCPS: Data-centric publish / subscribe; DLRL: Data Local Reconstruction Layer; QoS: Quality of Service; Topic: Topic; Publisher: Publisher; Subscriber: Subscriber; IDL: Interface Definition Language; RTPS: Real-time Publish-Subscribe Transport Protocol; GDS: Global Data Space; COBOL: A high-level programming language used to process large amounts of data and complex business logic; DDS: Data Distribution Service; The solution proposed in this embodiment is introduced in detail below.

[0024] This embodiment does not implement service registration, service discovery, service governance, etc., but mainly implements the communication mechanism function between services. It mainly includes the following aspects: 1. Message Transmission and Communication: For service-oriented systems, middleware enables data transmission between different services, ensures reliable message transmission across the network, and handles functions such as message queuing and message routing. Through middleware's functional components, applications can send and receive messages without having to worry about how the messages are transmitted across the underlying network and operating system.

[0025] 2. Shielding underlying hardware differences: Encapsulating the mission system's onboard bus and abstracting the communication method between application software and hardware.

[0026] 3. Provide standard interface: Provide unified and standard interface for different applications or software components to facilitate modular development of software.

[0027] Service-oriented architecture is an architectural pattern that decomposes complex applications into a set of small, independent, and reusable services. Each service implements a specific business function and communicates with other services through well-defined interfaces to jointly support the operation of the business system. This architectural pattern is highly flexible, scalable, and maintainable, and can better adapt to rapidly changing business needs. Service-oriented software architecture consists of services, middleware, operating systems, network drivers, and hardware devices. Software architecture, such as Figure 1 shown.

[0028] Middleware is an integral component of a service-oriented software architecture, providing the infrastructure for communication, collaboration, and management between services. In a service-oriented architecture, middleware software acts as the "software glue," enabling diverse services to work together seamlessly. Through middleware software, services can achieve efficient communication, data sharing, and business process management.

[0029] Business logic is abstracted into services and divided into portable or platform-specific components. Building on the FACE architecture, middleware adds service-oriented and containerized technologies to form a service-oriented framework and execution environment. Application software is developed based on the middleware service-oriented runtime framework interface. The service-oriented framework is responsible for service registration and discovery, service link tracking, service governance, and RPC communication. The execution environment is responsible for message distribution, I / O bus adaptation, and time management. Application software only needs to focus on developing its own functional logic.

[0030] Based on a service-oriented software architecture, we developed targeted middleware software. Because service-oriented middleware involves numerous and complex functions and our team lacks experience, the project implementation plan will initially focus on the middleware's execution environment functionality, designing and developing the corresponding modules to support service communication. The following is a detailed design of the middleware software solution.

[0031] like Figure 1 As shown, the logical architecture of this embodiment: the middleware software adopts a layered architecture, with a structure divided into three levels from top to bottom: the interface layer, the logic layer, and the hardware abstraction layer. The interface layer is responsible for providing functional service interfaces; the logic layer is responsible for implementing specific business logic, decoupling applications from specific transmission mechanisms and data access; the hardware abstraction layer is responsible for shielding network interface differences caused by different hardware, providing the logic layer with a universal interface for accessing different network buses.

[0032] Middleware software exists in the form of a dynamic library. Depending on the operating system, the corresponding compiler is used to compile the target file. When the application uses the middleware software, the middleware library file is linked to the project and the header file is imported. When data communication is required, the interface provided by the middleware is directly used to send and receive the corresponding data. Through system analysis and design, the functional components of the middleware software are divided into: "message distribution component", "Ethernet communication component", "PCIE communication component", "RS422 communication component", "1394 communication component", and "time management component". Among them, the message distribution component is the core of the middleware software, mainly responsible for data communication functions, and is the key hub for the interaction of various system services. The specific functions are described as follows: Message distribution component: provides a publish-subscribe mechanism to implement message distribution and communication, distributes messages received by the transport layer to other modules, and supports message sending and receiving of the service framework.

[0033] Ethernet communication: Complete the encapsulation of the Ethernet driver, initialize the network, create connections, and send and receive messages.

[0034] PCIE communication: completes the encapsulation of the PCIE driver, performs related initialization, creates connections, and sends and receives messages.

[0035] RS422 communication: completes the encapsulation of RS422 bus communication, performs RS422 bus initialization, creates connections, and sends and receives messages.

[0036] 1394 communication: completes the encapsulation of 1394 bus communication, performs 1394 bus initialization, creates connections, and sends and receives messages.

[0037] Time management: Responsible for encapsulating the time setting and acquisition interface, and providing unified services for the following clocks or timers to the application.

[0038] The architecture and composition of the message distribution function are as follows Figure 2 As shown in the figure, message distribution is a service-oriented communication component built based on the data distribution service specification, which implements data-centric publish-subscribe and defines the functions for applications to publish and subscribe to data objects. It allows publishing applications to first identify the data objects to be published and then provide data values ​​for these objects; it allows subscribing applications to identify the data objects of interest and access their data values. At the same time, it supports applications to define topics and attach data type information to topics; it supports the creation of entities such as publishers and subscribers, attaches QoS policies to all these entities, and supports the operation of entities; the timing of message distribution is as follows: Figure 3 As shown below.

[0039] Figure 4This is the overall publish / subscribe flow chart. Message distribution provides the publish / subscribe mechanism required for service communication. Publish and subscribe are linked through topics. The communication process of the publish / subscribe mechanism mainly involves the publisher and the subscriber. The detailed process is described as follows: The steps to create and configure the required entities on the publisher side are as follows: Get an instance of the domain participant factory and create a domain participant; Register the corresponding subject data type with the domain participant; Create a topic for the registered data type using the domain participant; Create a publisher using the domain participant; Use the created publisher to build a data writer to publish topic data.

[0040] The steps for the publisher to send data samples are as follows: Assign the data to be sent to the variable corresponding to the topic type; Call the Write operation of the data writer: for an instance without a defined key or unregistered, pass the assigned variable along with DDS_HANDLE_NIL; for a keyed and registered subject instance, pass the assigned variable along with the handle returned when registering the instance; The Write operation stores the passed variable in the data writer's buffer as a data sample. In this buffer, the data sample is transmitted according to the QoS policies of the publisher and data writer. If there is a matching data reader, the data sample is transmitted to the physical layer before the Write operation returns.

[0041] Subscriber: There are two ways to receive data on the subscriber side, namely asynchronous notification and synchronous waiting. This design uses the asynchronous notification method.

[0042] Asynchronous Notification: When new data samples arrive, the distribution service component notifies the application through a listener on a subscriber or data reader. While the listener callback is executing, the application can access the data by calling the read or take operations on the data reader. This approach allows applications to receive data samples with minimal latency.

[0043] Synchronous wait mode: The application creates a condition and a wait set, then calls the wait operation on the wait set to wait for a new data sample. The distribution service component blocks the application thread until the condition (the arrival of a new sample) is true. The application then calls the read or take operation on the data reader to access the data sample from the receive buffer.

[0044] The steps to create and configure the required entities on the subscriber side are as follows: Get an instance of the domain participant factory and create a domain participant; Register the corresponding subject data type with the domain participant; Create a topic for the registered data type using the domain participant; Create a subscriber using the domain participant; Create a generic type data reader for the topic using the publisher.

[0045] The basic idea of ​​using asynchronous notification to receive data samples is to passively receive the arrival time of new samples through a listener.

[0046] Create a data reader listener for a data reader or a subscriber listener for a subscriber; The application creates a data reader listener with the on_data_available callback enabled. When a new data sample arrives, the distribution component executes the on_data_available callback of the listener. The application creates a subscriber listener with the on_data_on_readers callback enabled. When a new data sample arrives, the distribution component executes the listener's on_data_on_readers callback.

[0047] Among them, the component implementation is to build a message distribution component based on the DDS specification, which mainly provides a publish / subscribe interface for applications to realize message distribution and communication. The message distribution component needs to implement interfaces such as creating publishers and creating subscribers. The implementation process is as follows Figure 5 shown.

[0048] The publisher's class structure is as follows Figure 6 As shown, the process of creating a publisher interface is implemented: Create a domain participant: Get the domain participant factory and create a domain participant in the domain participant factory. For domain participants in the data domain, the default QoS policy is adopted, and the domain ID of the created domain participant must be consistent in the publisher and subscriber; Create publisher: Create a publisher through domain participants to publish topics and attach the publisher to TCP / UDP transmission; Register topic data types: Use domain participants in the data domain to register the topic data type, define the name of the topic data type, which must match it in the subscriber. When creating a topic, specify the name of the topic type, allowing data writers of the topic to create registered data types; Create a topic: Use domain participants to create a topic, define variables to store the topic name, and bind each topic to a data type.

[0049] Create a data writer: Use the created publisher to build a data writer for publishing topic data. To define a topic, you need to build a data writer.

[0050] Register topic instance: define and register topic instance for sending topic data; Send data.

[0051] The class structure of the subscriber side is as follows Figure 7 As shown; among them, the process of creating a subscriber interface is implemented: Establishing a Data Reader Listener: The data reader will attach a Data Reader Listener. Whenever a data sample is received from the publisher, the message dispatcher uses the listener's corresponding callback operation to notify the publisher of the arrival of a new data sample. Define the DataReaderListenerImpl class, implement the DDS::DataReaderListener IDL interface within this listener class, and override several virtual functions from this interface. The Data Reader Listener class must override all callback operations, with the on_data_available callback operation being the most critical. When a new data sample arrives, the message dispatcher calls this operation to deliver the data. Create a domain participant: Get a domain participant factory, create a domain participant in the domain participant factory, and use the default QOS.

[0052] Create subscriber: Create a subscriber to subscribe to a topic and attach the subscriber to the TCP / UDP transmission; Register subject data type: Use domain participants to register data types, and the type name should be consistent with the domain publisher; Create Topic: Create a message topic.

[0053] Create a data reader and a data reader listener to receive data from the corresponding topic. You only need to build one data reader and one data reader listener for each topic.

[0054] The architecture and composition of Ethernet functions are as follows: Figure 8 The Ethernet communication module encapsulates the Ethernet driver interface. It uses a socket communication mechanism based on the UDP / IP protocol and provides a set of application programming interfaces (APIs) to allow different processes to communicate between different network devices. It provides an abstraction layer for network services, allowing applications to ignore the details of the underlying network technology and focus on sending and receiving data. Basic information about socket communication is shown in Table 1.

[0055] Table 1 Basic information of socket communication Furthermore, the main process of Socket communication is as follows Figure 9 As shown in the figure, the Ethernet communication module uses the UDP transmission protocol, which mainly provides network connection, data sending and receiving interfaces for applications to realize data transmission functions. The Ethernet communication component needs to implement interfaces such as creating connections, sending data, and receiving data. The implementation process is as follows: 1) Create a connection a) Create a socket using the socket() driver call; b) Use the bind() driver call to bind the socket to an IP and port.

[0056] 2) Create data to send a) Get the IP and port of the destination; b) Set up sending data; c) Use the Write() driver call to send the data.

[0057] 3) Create data receiver d) Define the source IP and port; e) define the data received; f) Use the Read() driver call to send the data.

[0058] The architecture of PCIE components is as follows Figure 10 As shown; Among them, the PCIE component is responsible for the encapsulation of the PCIE bus driver, provides the message sending and receiving functions of the PCIE bus, and completes the data communication between different processors on the same module. Its basic PCIE communication information is shown in Table 2 below: Table 2 PCIE communication basic information table PCIE communication process is as follows Figure 11 As shown in the figure, the PCIE communication module encapsulates the PCIE card driver and mainly provides the application with the data transmission and reception interface of the PCIE bus to realize the data transmission function of the PCIE bus. The PCIE communication component needs to implement interfaces such as creating connections, sending and receiving data, and the implementation process is as follows: 1) Create a connection Call Initialize() to initialize the device, set the connection parameters, and use the OpenConnection() driver call to open the connection board.

[0059] 2) Data sending and receiving Use the read() and write() driver calls to send and receive data.

[0060] The architecture and composition of the communication function of the RS422 communication component are as follows Figure 12 As shown; Among them, the communication process of the RS422 communication module is as follows Figure 13 As shown, it is responsible for the encapsulation of RS-422 bus driver and provides RS-422 bus message sending and receiving functions. Its RS422 communication basic information is shown in Table 3 below: Table 3 RS422 communication basic information 1394 communication module architecture Figure 14 As shown, and through Figure 15 The steps shown complete the encapsulation of 1394 bus communication, perform 1394 bus initialization, create connection, send and receive messages, and provide 1394 bus message sending and receiving functions; the basic information of 1394 communication is shown in Table 4 below.

[0061] Table 4 1394 communication basic information table The 1394 communication module encapsulates the 1394 card driver and mainly provides the application with the data transmission and reception interface of the 1394 bus, realizing the data transmission function of the 1394 bus. The 1394 communication component needs to implement interfaces such as creating connections, sending and receiving data, and the implementation process is as follows: 1) Create a connection Initialize the board handle and use the OpenConnection() driver call to open the connection board.

[0062] 2) Data sending and receiving Use the read() and write() driver calls to send and receive data.

[0063] Time management component: The middleware software is responsible for encapsulating time setting and acquisition interfaces, providing applications with unified services for the following clocks or timers: The system calendar clock timing service function can only be used by the node where the system time server is located. The task system execution environment provides general applications with the service function of accessing the calendar clock, system clock, and local clock.

[0064] Provides service for setting and removing application timers, and notifies the application through a specified interface when the timer expires.

[0065] Provides query service for the base frequency / clock count of a high-precision timer.

[0066] In summary, the message distribution component is the core module of the middleware software. It is built using a third-party implementation library based on data distribution services to provide efficient and reliable service communication, ensuring the stable operation and efficient collaboration of the entire system.

[0067] Core Features The Data Distribution Service Technical Specification adopts and extends the publish / subscribe model, and is designed to meet the high-performance, data-centric communication requirements of distributed real-time systems. Its features are as follows: High-performance publish-subscribe The primary goal of data distribution is to share the right data at the right time and in the right place. For distributed systems, not all data needs to be available everywhere. Middleware should only provide the data that consumers truly need. Interest-based filtering can be applied to content and data rate control. Proper implementation can save bandwidth and processing power and minimize overall application complexity. A data distribution service can understand the patterns of shared data, enabling it to filter based on content, providing only the data required by the application. In many distributed systems, this effective approach can save 90% of data communication overhead.

[0068] Data-centric publish-subscribe Traditional object-centric distributed systems are integrated using an interface server and client interface. Communication is based on clients calling methods on named interfaces provided by their servers. For distributed real-time systems, this object-based calling mechanism struggles to meet the real-time requirements of the system. In contrast, data distribution services utilize a simpler programming model that eliminates the need to develop specialized event / message infrastructure or manually create encapsulated COBRA (Common Object Request Broker Architecture) objects to retrieve remote data. Applications can specify the data they wish to read or write using a simple name and directly access it using a data-centric API. The data-centric publish / subscribe model establishes the concept of a shared global data space where all data objects reside. Applications can directly access these data objects through simple read or write operations.

[0069] The above are only some embodiments of the present application and are not intended to limit the patent scope of the present application. All equivalent structural transformations made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A message middleware system based on data distribution service specifications, including an application layer, middleware and an operating system, characterized in that: The middleware includes: Message distribution component: provides a publish-subscribe mechanism to implement message distribution and communication, distributes messages received by the transport layer to the target module, and supports message sending and receiving of the service framework; Ethernet communication component: completes the encapsulation of Ethernet drivers, performs network initialization, creates connections, and sends and receives messages; PCIE communication component: completes the encapsulation of PCIE driver, performs related initialization, creates connections, and sends and receives messages; 1394 communication component: completes the encapsulation of 1394 bus communication, performs 1394 bus initialization, creates connections, and sends and receives messages; Time management component: responsible for encapsulating the time setting and obtaining interface, providing unified services for the following clocks or timers to the application; The application layer is used to run the application program and is respectively connected to the message distribution component, PCIE communication component, RS422 communication component, 1394 communication component and time management component through the middleware API, and the message distribution component is connected to the Ethernet communication component; The operating system is deployed with Ethernet driver, 422 driver, 1394 driver and operating system functions, and is respectively connected to the Ethernet communication component, PCIE communication component, RS422 communication component and 1394 communication component through a hardware abstraction environment.

2. A message middleware system based on data distribution service specification according to claim 1, characterized in that: The message distribution component includes an interface layer and a logic layer; wherein the interface layer is configured with a publisher creation interface and a subscriber creation interface; the logic layer is provided with a publishing end, a subscriber end, a data sending module, a data receiving module, a topic and a data management module.

3. A message middleware system based on data distribution service specification according to claim 2, characterized in that: The publisher creates and configures the required entities through the following steps: Get an instance of the domain participant factory and create a domain participant; Register the corresponding subject data type with the domain participant; Create a topic for the registered data type using the domain participant; Create a publisher using the domain participant; Use the created publisher to build a data writer to publish topic data.

4. A message middleware system based on data distribution service specification according to claim 3, characterized in that: The publishing end sends data samples through the following steps: Assign the data to be sent to the variable corresponding to the topic type; Call the Write operation of the data writer; For instances where no key is defined or not registered, the variable to be assigned is passed with DDS_HANDLE_NIL; For a registered theme instance with a defined key, pass the assigned variable along with the handle returned when registering the instance; The Write operation stores the passed variable into the data writer's buffer, which becomes a data sample. Among them, the data samples in the buffer area will be transmitted according to the QoS policy of the publisher and data writer; if there is a successful matching data reader, the data sample will be transmitted to the physical layer before the Write operation returns.

5. A message middleware system based on data distribution service specification according to claim 2, characterized in that: The data receiving mode set by the subscriber includes asynchronous notification mode and synchronous waiting mode; wherein, Asynchronous notification: When a new data sample arrives, the distribution service component notifies the application through a listener on the subscriber or data reader. During the execution of the listener callback operation, the application can access the data by calling the read or take operation on the data reader. Synchronous waiting mode: The application creates a condition and a wait set, and calls the wait operation of the wait set to wait for new data samples; the distribution service component will block the application thread until the new sample arrives; then, the application calls the read or take operation on the data reader to access the data sample from the receive buffer.

6. A message middleware system based on data distribution service specification according to claim 5, characterized in that: The subscriber creates and configures the required entities through the following steps: Get an instance of the domain participant factory and create a domain participant; Register the corresponding subject data type with the domain participant; Create a topic for the registered data type using the domain participant; Create a subscriber using the domain participant; Create a generic type data reader for the topic using the publisher.

7. A message middleware system based on data distribution service specification according to claim 6, characterized in that: When using asynchronous notification, receive data samples through the following steps: Create a data reader listener for a data reader or a subscriber listener for a subscriber; The application creates a data reader listener with the on_data_available callback enabled. When a new data sample arrives, the distribution component executes the on_data_available callback of the listener. The application creates a subscriber listener with the on_data_on_readers callback enabled. When a new data sample arrives, the distribution component executes the listener's on_data_on_readers callback.

8. A message middleware system based on data distribution service specification according to claim 2, characterized in that: Create a publisher interface by following these steps: Create a domain participant: Get the domain participant factory and create a domain participant in the domain participant factory. For domain participants in the data domain, the default QoS policy is adopted, and the domain ID of the created domain participant must be consistent in the publisher and subscriber; Create publisher: Create a publisher through domain participants to publish topics and attach the publisher to TCP / UDP transmission; Register topic data type: Use domain participants in the data domain to register the topic data type and define the name of the topic data type, which must match it in the subscriber. When creating a topic, specify the name of the topic type, allowing data writers of the topic to create registered data types. Create a topic: Use domain participants to create a topic, define variables to store the topic name, and bind each topic to a data type; Create a data writer: Use the created publisher to build a data writer for publishing topic data. To define a topic, you need to build a data writer; Register a topic instance: Define and register a topic instance for sending topic data.

9. A message middleware system based on data distribution service specification according to claim 8, characterized in that: Create a subscriber interface by following the steps below: Establish a data reader listener: The data reader will attach a data reader listener. Whenever a data sample is received from the publisher, the message distribution uses the corresponding callback operation of the listener to notify the arrival of the new data sample; Define the DataReaderListenerImpl class, implement the DDS::DataReaderListener IDL interface in the listener class, and overload the virtual functions from the interface; The data reader listener class needs to reload all callback operations; when a new data sample arrives, the message dispatcher calls the operation to pass the data; Create a domain participant: obtain a domain participant factory, create a domain participant in the domain participant factory, and use the default QOS; Create subscriber: Create a subscriber to subscribe to a topic and attach the subscriber to the TCP / UDP transmission; Register subject data type: Use domain participants to register data types, and the type name should be consistent with the domain publisher; Create Topic: Create information topic; Create a data reader and a data reader listener to receive data from the corresponding topic.

Images