KR101157039B1 - Dds bridge communication system and method - Google Patents

Abstract

PURPOSE: A DDSB(Data Distribution Service Bridge) communication system and method thereof are provided to offer a DDSB structure and protocol by enabling an apparatus including insufficient computing resources to transmit a simple message through a protocol. CONSTITUTION: A DDSB(20) reads a message from a domain. A non-DDS(Data Distribution Service) communication entity(30) is composed of a sender and a receiver communicated with the DDSB. The DDSB includes a DDS(Data Distribution Service)(10) composed of an RTPS(Real-Time Publish-Subscriber) and a DCPS(Data-Centric Publish-Subscriber), an abstract layer composed of a sender and a receiver, a protocol manager which transmits messages, and a DDS entity manager includes the information of DDS entities.

Description

DDS Bridge communication system and method

The present invention relates to a data distribution service bridge (DDSB) structure and protocol, and in particular, a device (non DDS communication object) capable of communicating without a data distribution service (DDS) middleware (non DDS communication object) communicates with the DDSB in the form of a packet and the DDS in the DDSB. When a message is sent to the domain, the DDSB publishes the message through the DDS's DataWriter object and subscribes to the DDSB's DataReader object in the form of a packet (non DDS communication). Object) and a DDSB communication system and method for defining a DDSB (DDS Bridge) structure and protocol for a non-DDS device to use a DDS service using an abstraction layer of a DDSB.

Data Distribution Service (DDS) is an object management group (OMG) standard communication middleware that dynamically forms network domains, and provides efficient data using publish / subscribe communication techniques in the environment where devices can freely participate and leave. Provide distribution.

The feature of DDS is that it is suitable for ubiquitous environment where many devices are dynamically linked to form one network domain and exchange data. DDS includes a variety of features, such as publish / subscribe, QoS control, and discovery to address DDS participating nodes, which requires desktop-scale memory or processor capacity to run. However, devices used in ubiquitous environments have small computing resources such as smartphones and sensors. Therefore, it is not suitable to use efficient DDS middleware in ubiquitous environment.

An object of the present invention for solving the problems of the prior art is to communicate with a DDSB in the form of a packet without a DDS (Data Distribution Service) middleware and to send a message to the DDSB to publish the DDSB DDSB Published to the domain through DDS's data writer, DDSB delivers subscribed messages to DDSB's packet-communicable devices through DDS's data reader object, and devices with insufficient computing resources provide simple messages without installing DDS middleware. It is to provide a DDSB communication system that provides a DDSB (DDSB) structure and a protocol that allows the DDS service to be transmitted by using a protocol of its own.

Another object of the present invention is to provide a data distribution service bridge (DDSB) communication method.

In order to achieve the object of the present invention, a Data Distribution Service Bridge (DDSB) communication system according to the present invention includes a data distribution service bridge (DDSB) for publishing / subscribing a message to a domain; and a sender for communicating with the DDSB. ), And a non-DDS communication object (Non DDS Entity) consisting of a receiver (Receiver);

The DDSB includes a Data Distribution Service (DDS), a Sender, and a Receiver, which include a Real-Time Publish-Subscribe (RTPS) that provides a communication function, and a Data-Centric Publish-Subscribe (DCPS) that transmits data. An abstract layer comprising a protocol manager for generating the DDS object and delivering a message and a DDS entity manager having information on the DDS objects.

A DDSB communication method of a data distribution service bridge (DDSB) communication system including a data distribution service bridge (DDSB) for publishing / subscribing a message to a domain; and a non DDS entity (Non DDS Entity) for communicating with the DDSB.

(a) establishing a connection between the DDSB and the non-DDS communication object; and (b) executing a protocol communication procedure (Publish sequence diagram) in which the non-DDS communication object publishes a message of a domain. ; Or (c) executing a protocol sequence diagram for subscribing a message of a domain from the DDSB to a non-DDS communication object, and dynamically forming a network domain in the DDSB communication system. The non-DDS device may use the DDS service using the Abstract Layer of the DDSB using the Publish / Subscribe protocol of the DDSB in an environment in which a communicable device (non DDS device) may freely participate / deactivate. Sends a subscribed message to the protocol manager through a data reader of a DDS using a sender and a receiver of an abstract layer, and the protocol manager transmits the non-DDS communication object matching the data reader of the DDS. Finds, transmits to the non-DDS communication object through the sender of the abstract layer, and the non-DDS communication object is published Receive a message to the receiver of the Abstract Layer (Receiver) and transmits to the Protocol Manager (Protocol Manager), the protocol manager checks the DDS Entity Manager to create the object of the DDS matching the non-DDS communication object It creates an object and publishes a message in a domain.

DDSB (DDS Bridge) communication system and method according to the present invention DDSB (DDSB) communication device without the DDS (Data Distribution Service) middleware communicates with the DDSB in the form of a packet, if the DDSB sends a message that you want to publish in the DDS domain DDSB DDS Published in the domain through the data writer object of DDSB, and the subscribed message through the DDS data reader object is delivered to the communication device in the form of a packet, so that a device with insufficient computing resources can send a simple message without installing DDS middleware. By using this protocol, it provides DDSB (DDS Bridge) structure and protocol that can use DDS service.

1 is a diagram illustrating a DDS structure.
2 is a diagram illustrating a behavior of a DDS.
3 is a diagram illustrating a behavior of a DDSB (DDSB).
4 is a view showing a DDSB (DDSB Module) proposed in the present invention.
FIG. 5 is a sender component diagram for transmitting a subscribed message to a non-DDS communication object through a data reader of a DDS according to an embodiment of the present invention.
FIG. 6 is a receiver component diagram for delivering a message received from a non DDS communication object to a protocol manager according to an embodiment of the present invention.
7 shows a DDS Entity Table.
8 is a diagram illustrating an example of using DDSB in a TCP / IP layer.
9 is a protocol communication procedure (Publish sequence diagram) in which a non DDS communication object publishes a message in a DDS domain.
10 is a subscription sequence diagram illustrating a protocol communication procedure for subscribing a message of a DDS domain to a non-DDS communication object.
11 illustrates a TCP / IP connection connection procedure when the TCP / IP communication method is selected.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in detail the configuration and operation.

1. DDS ( Data Distribution Service )

Data Distribution Service (DDS) is standardized by OMG as a standard software API (Application Programming Interface) for data-driven publication / subscription communication between distributed applications.

1 is a diagram illustrating a DDS structure.

Data Distribution Service (DDS) consists of two layers: Real-Time Publish-Subscribe (RTPS) and Data-Centric Publish-Subscribe (DCPS). RTPS provides a substantial communication function and DCPS provides a function for providing a communication interface to a DDS application (FIG. 1).

Real-Time Publish-Subscribe (RTPS) is a layer in which real data is published / subscribed in the Linux / Windows operating system of a computer platform, which is divided into RTPS Engine and RTPS Wired Protocol. The RTPS Engine determines the domain formation, the type of data to use, and dynamically discovers remote DDSs participating in the domain. In addition, data is published / subscribed by Publisher and Subscriber. RTPS Wired Protocol is a protocol that transmits actual data and performs reliable or unreliable data communication according to QoS set by RTPS Engine, and RTSP's network is multicast. It supports UDP / IP communication in a unicast and broadcast manner.

Data-Centric Publish-Subscribe (DCPS) is a layer that guarantees reliability through data publishing / subscribing function and quality of service (QoS) provided to an application program, and performs data transmission / reception directly performed by the application program. It is possible to send and receive data by writing simple application program. DCPS provides a read / write API (Application Programming Interface) to provide data exchange function between application programs and to publish / subscribe desired data without having to know a partner to exchange.

2 is a diagram illustrating a behavior of a DDS.

The DDS service can be used by creating a DCPS object. Domain Participant is created to participate in domain, which is a data sharing area, and Publisher and Subscribers are created for each data through domain participant. Publisher creates a data writer to publish data to the domain, and Subscriber creates a data reader to receive data from the domain. Since the sender and receiver of the data establish a logical link by the data, the sender and the receiver can transmit and receive only data with the same topic name, and cannot process data with different topic names (FIG. 2, FIG. 2). 3].

2. DDSB ( DDS Bridge )

DDSB (DDSB) provides two functions. The first function is to communicate with the non-DDS communication object, and the second function is to create a DDS object matching the non-DDS communication object to use the DDS service [FIG. 3].

3 is a diagram illustrating a behavior of a DDSB (DDSB).

The limitations of the proposed DDSB are as follows.

o Only data transmission is supported.

o Only the default QoS is used among various QoS functions provided by DDS.

o Non DDS communication object and data writer or data reader have 1: 1 relationship.

o Use only the data reader's listener.

4 is a view showing a DDSB (DDSB Module) proposed in the present invention.

Figure 4 is a view of the DDSB proposed in the present invention. The proposed DDS Bridge (DDSB) consists of Real-Time Publish-Subscribe (RTPS), Data-Centric Publish-Subscribe (RTPS) and three additional modules (DDS Entity Manager, Protocol Manager, Abstract Layer) of Data Distribution Service (DDS). It consists of.

The Data Distribution Service Bridge (DDSB) communication system of the present invention includes a data distribution service bridge (DDSB) 20 for publishing / subscribing a message to a domain; And a non DDS entity 30 for communicating with the DDSB 20.

The DDSB 20 is a Data Distribution Service (DDS) including a Real-Time Publish-Subscribe (RTPS) 12 that provides a communication function and a Data-Centric Publish-Subscribe (DCPS) 11 that transmits data ( 10), an Abstract Layer (27) consisting of Sender (21) and Receiver (22), Protocol Manager (24) and DDS objects that create the DDS object and deliver the message. The DDS Entity Manager 23 includes information, and the non DDS communication object (non DDS device) 30 is composed of a sender 31 and a receiver 32.

If you want to deliver a message subscribed in the domain to a non-DDS entity 30 (Non DDS Entity, non DDS device) 30, the reader of the Real-Time Publish-Subscribe (RTPS) to deliver the message of the subscribed domain The data reader to the data reader of the DCPS (Data Centric Publish-Subscribe), the data reader to the protocol manager 24, the protocol manager to the non-DSS communication object 30 matching the data reader to the DDS entity manager After searching through the message, the data is transmitted to the sender 21 of the abstract layer 27, and the sender is transmitted to the non-DDS communication object 30.

When a message of a non DDS communication object 30 is to be published in a domain, the message is sent from a sender 31 of the non DDS communication object 30 to the abstract layer 27 of the DDSB 20. When the receiver 22 receives and forwards the data to the protocol manager 24, the protocol manager 24 sends a data writer (DataWriter) matching the non-DDS communication object 30 to the DDS entity manager 23. ), The message is sent to the data writer, and the data writer is published to the domain through the writer of the RTPS.

The DDSB 20 is a layer in which real data is published / subscribed using a publish / subscribe technique in an environment in which a network domain (domain) is dynamically formed and devices can freely participate / disengage. Real-Time Publish-Subscribe (RTPS) (12), which is separated by the RTPS Wired Protocol and provides practical communication functions, uses the data publishing / subscribing function provided to the application, and the default quality of service provided by DDS. Data distribution service (DDS) 10, which is composed of two layers of Data-Centric Publish-Subscribe (DCPS) 11 to guarantee reliability and to transmit data to a DDS application; DDS Entity Manager (23) which contains information of DDS Entities created in the node where DDSB is installed, DDS Entities are matched with non DDS communication object, and managed in DDS Entity Table form (DDS Entity Table) ; This module analyzes the messages received from the receiver of the abstract layer, and checks the DDS Entity Manager, creates the objects, and publish / subscribe services to the domain in order to create the DDS objects matching the non-DDS communication objects. A protocol manager 24 that uses the created object without creating the publisher and the subscriber if the domain Participant has already been created; And a sender for transmitting a subscribed message to a non-DDS communication object through a data reader of a data distribution service (DDS), and a receiver for delivering a response message received from the non-DDS communication object to a protocol manager. Receiver) and an Abstract Layer (27).

The DDSB 20 generates a DDS object that matches the function of communicating with the non-DDS communication object and the non-DDS communication object to use a DDS service, and the DDSB has a DDS middleware, and the non-DSS It has a module (Sender, Receiver) that can communicate with the communication object, the system without the DDS middleware can also use the DDS service by sending a simple message through the DDSB, the DDSB (20) Various communication is supported through Abstract Layer.

2.1. Abstract Layer

The non-DDS communication object 30 may use various communication methods, and supports all of the various communication methods using the abstract layer 27.

Abstract Layer (27) is composed of a Sender (21) and a Receiver (22) for transmitting and receiving data with the non-DDS communication object 30, the operation method is changed according to the communication method, and also, DDSB (DDS Bridge) In order to easily manage the non DDS communication object 30 in the module 20, an ID is assigned to each non DDS communication object 30. For example, an object using the TCP / IP protocol is assigned an ID that matches an IP address and a port number.

2.1.1 Sender

FIG. 5 is a sender component diagram for transmitting a subscribed message to a non-DDS communication object through a data reader of a DDS according to an embodiment of the present invention.

The sender 21 is a module that delivers the subscribed message to the non-DDS communication object 30 through the data reader of the data distribution service (DDS) 20. Reader of RTPS (Real-Time Publish-Subscribe) forwards the subscribed message from domain (domain) to data reader of Data Centric Publish-Subscribe (DCPS) 11, and data reader is Protocol Manager (24). To pass). The protocol manager 24 finds a non-DDS communication object that matches the data reader through the DDS entity manager 23, and then transfers the data to the sender 21 and sends the sender 21 to the sender 21. 21 transmits to the non-DDS communication object 30 matching the data reader (Fig. 5).

2.1.2. Receiver

FIG. 6 is a receiver component diagram for delivering a message received from a non DDS communication object to a protocol manager according to an embodiment of the present invention.

Receiver (22) is a module that delivers the response message received from the non-DDS communication object 30 to the Protocol Manager (24). The message to be published to the domain (domain) is transmitted to the receiver 22, and the message is transmitted from the receiver 22 to the protocol manager 24. The protocol manager 24 finds a DataWriter matching the non-DDS communication object 30 through the DDS Entity Manager 23 and delivers a message to the DataWriter. The DataWriter of the DCPS 11 publishes to a domain (domain) via the Writer of the RTPS 12 (Fig. 6).

2.2. Protocol Manager

The protocol manager 24 is a module for analyzing a message received from a receiver of an abstract layer. The Protocol Manager 24 has two functions. The first function is to check the DDS Entity Manager 23 and create an object to create an object of the DDS that matches the non-DDS communication object. When creating a DDS object, if there is a domain Participant that already participates in the domain to be examined by participating in the DDS objects created in the DDSB 20, the domain Participant that is already participating is used without creating a new one. When publishing / subscribing to the domain, if the publisher and subscriber have already been created in the domain Participant, the created object is used instead. In addition, if a Topic object is already created in the domain, the created object is used without creating it. The second function is to deliver the message. The subscribed message is delivered to the sender of the Abstract Layer, and the message to be published in the domain is delivered to the DataWriter [FIG. 6].

2.3. DDS Entity Manager

7 shows a DDS Entity Table.

The DDS Entity Manager 23 is a module that contains information of DDS Entities created in the node where the DDSB 20 is installed. DDS Entities are matched with non-DDS communication objects, and are managed in a Table form (DDS Entity Table) as shown in FIG. The ID field is a field that stores the ID of a non DDS communication object designated by the Abstract Layer. The remaining five fields store the address values of DDS objects created by non-DDS communication objects. The DP field stores the address of the domain Participant, and the PUB and SUB store the address values of the Publisher and Subscriber. The DW and DR fields store the address values of the DataWriter and the data reader.

When the non-DDS communication object 30 accesses the DDSB 20, the ID specified in the abstract layer is stored. Afterwards, when the Protocol Manager 24 creates the DDS object, the protocol manager 24 stores the address value of the generated DDS object in the same row of the table where the ID is stored.

3. DDSB Protocol for using

Since the DDSB has the limitations defined above, it is possible to use the DDSB by using a simple protocol that defines which domains join which domain and which publication / subscription services to use.

3.1. DDSB Frame structure to use

This section defines the frame of the DDSB protocol between the DDSB and non-DDS communication objects. This frame enters the payload portion of the transport protocol, for example TCP, applied between the DDSB and non-DDS communication objects [Fig. 8].

8 is a diagram illustrating an example of using DDSB in a TCP / IP layer.

The protocol frame structure for using the DDSB proposed in the present invention provides two functions, i) a protocol for creating a DDS object on a domain, and ii) a protocol for data transmission.

First frame structure  Type        Body 0x00 1 byte

Table 1 shows the first frame structure that is distinguished when a message is received in a non DDS communication object.

As shown in Table 1, First frame structure is divided into Type and Body. TYPE has the size of 1 byte. If TYPE is 0x01, it is a message to create domain Participant, Publisher, Subscriber, DataWriter, DataReader of DDS. If TYPE is 0x02, it is a message to create Topic. If TYPE is 0x04, it is a message that contains data published in domain. If the TYPE is 0x08, this message contains the data subscribed to by the domain. The structure of the body is changed as follows according to the type of TYPE.

3.1.1. DDS Entity  Generation protocol

Table 2 shows the frame structure when TYPE is 0x01.

Structure of Type 0x01 Frame  Type                  Body 0x01
   Domain Number  Publish or Subscribe Flag      4 bytes         1 byte

As shown in Table 2, the body of the frame structure with a TYPE of 0x01 is divided into a domain number and a publish or subscribe flag that determines a publication or subscription service. Domain Number is an int type and has a size of 4 bytes. Publish or Subscribe Flag, which determines the publication or subscription service, is a Boolean type and has a size of 1 byte. The domain number stores the number of the domain to which the user wants to participate and determines whether to publish or subscribe to the domain through the flag. If true, the published service is determined. If false, the subscription service is determined.

Table 3 shows the frame structure when TYPE is 0x02.

Structure of Type 0x02 Frame  Type                  Body 0x02
     Kind          Name      1 byte         String

As shown in Table 3, Type 0x02 frame structure is divided into kind and name. kind is a Boolean type and has a size of 1 byte, name has a String type, and has a size except kind 1 byte in the frame structure. To create a topic, you need a type name and a topic name. The kind determines whether the message contains a type name or a topic name. If true, type name; if false, topic name. name contains the type name and topic name.

3.1.2. Publish / Subscribe Protocol

Table 4 shows the frame structure when TYPE is 0x04.

Structure of Type 0x04 Frame  Type           Body  0x04           Data

As shown in Table 4, the Type 0x04 frame structure is not specifically defined. When TYPE is 0x04, Data part of message received from non DDS communication object is published to domain through DataWriter.

Table 5 shows the frame structure when TYPE is 0x08.

Structure of Type 0x08 Frame  Type           Body  0x08           Data

As shown in Table 5, the Type 0x08 frame structure is not specifically defined. When TYPE is 0x08, DDSB saves the message subscribed from domain in Data part and sends it to non DDS communication object.

Table 6 shows the response message frame structure for the messages defined above.

Ack message Frame structure              Type             1 byte

As shown in Table 6, Ack message frame structure is divided into TYPE only. TYPE has the size of 1 byte. When a non DDS communication object receives an Ack message, it determines which message should be sent through the TYPE.

Ack Message   TYPE                        Message   0x10 Received the previous message and asked the other party to send the domain number and publisher / subscriber information as the next message.   0x20 Received the previous message and asked the other party to send the type name of the topic they wish to publish / subscribe as the next message.   0x40 Received the last message and asked the other party to send topic name as the next message.   0x80 Message that informs the other party that the DDS entity creation procedure was successful and the DDS service is available.

Table 7 shows the message meaning according to the type of TYPE in the response message frame.

3.2. Protocol communication procedure

Data Distribution Service Bridge (DDSB) communication method according to the present invention,

Data Distribution Service (DDS), Abstract Layer, which consists of Real-Time Publish-Subscribe (RTPS), which provides communication functions for publishing / subscribing messages to a domain, and Data-Centric Publish-Subscribe (DCPS), which transmits data. A Data Distribution Service Bridge (DDSB) including a Protocol Manager for creating the DDS object and delivering a message, and a DDS Entity Manager having information of the DDS objects; and non communicating with the DDSB. A DDSB communication method of a data distribution service bridge (DDSB) communication system including a non-DSS entity,

     (a) establishing a connection between the DDSB and the non-DDS communication object; after performing (for example, after performing three way handshaking of TCP (FIG. 11)),

(b) the non DDS communication object executing a protocol communication procedure (Publish sequence diagram) for publishing a message of a domain (FIG. 9); or,

(c) executing a protocol communication sequence (subscription sequence diagram) for subscribing a message of a domain from the DDSB to a non-DDS communication object (FIG. 10).

In the DDSB communication system, a data reader of a DDS is formed by using a publish / subscribe protocol of the DDSB 20 in an environment in which a network domain is dynamically formed and free communication is possible for a device (non DDS device). The subscribed message is transmitted to the non-DDS communication object 30 through the sender 21 of the abstract layer 27 of the DDSB 20 and published by the non-DDS communication object 30. A message to be received is received by a receiver 22 of the abstract layer 27 and transmitted to a protocol manager 24, and the protocol manager 24 communicates with the non-DDS communication object 30. In order to create an object of the matching DDS, the DDS Entity Manager 23 checks the object, creates the object, and publishes a message to a domain (domain) through the data writer of the DDS.

9 is a protocol communication procedure (Publish sequence diagram) in which a non DDS communication object publishes a message in a DDS domain.

The protocol procedure for a non-DSS communication object to publish a message in a DDS domain is divided into three parts as shown in FIG. The first DDSB 20 and Non DDS Communication Object (Sender) 31 are connected to each other. Depending on the non DDS communication method, the communication connection method may be changed. For example, in the case of TCP, the three way handshaking method is used (FIG. 11). This part creates a DDS object that matches the second non DDS Entity (Sender) 31. The DDSB 20 sends an Ack message to the non DDS communication object 31 to transmit the first message for creating the DDS object. The non-DDS communication object 31 receiving the Ack message sets the TYPE to 0x01, sets the domain number to participate in which domain, and sets the Flag value to True to publish to the participating domain to the DDSB 20. send. After receiving the message, the DDSB 20 transmits an Ack message to the non DDS communication object 31 to transmit the next message. The non-DDS communication object 31 receiving the Ack message sets the TYPE to 0x02, sets the kind to True, and sets the type name to send the DDSB 20 to generate a topic. After receiving the message, the DDSB 20 transmits an Ack message to the non DDS communication object 31 to transmit the next message. The non-DDS communication object 31 receiving the Ack message sets the TYPE to 0x02, sets the kind to False, and sets the topic name to transmit to the DDSB 20. After receiving the message, the DDSB 20 transmits an Ack message to the non-DDS communication object 31 to indicate that the publication service is available. The third non DDS communication object 31 transmits a message to be published in the domain. The non DDS communication object 31 sets the TYPE to 0x04 and transmits a message to be published in the domain to the DDSB. When a non-DDS communication object 31 publishes a message with the same topic, it is only necessary to transmit a message to be published to the DDSB by defining TYPE as 0x04.

10 is a subscription sequence diagram illustrating a protocol communication procedure for subscribing a message of a DDS domain to a non-DDS communication object.

The protocol procedure for subscribing a message of a DDS domain delivered to a non-DDS communication object is divided into three parts as shown in FIG. The first non DDS Entity (Receiver) 32 connects the connection between the DDSB 20. Depending on the non DDS communication method, the communication connection method may be changed. For example, in the case of TCP, the three way handshaking method is used (FIG. 11). This is a part for creating a DDS object that matches the second non DDS communication object 32. The DDSB 20 sends an Ack message to the non DDS communication object 32 to transmit the first message for creating the DDS object. The object receiving the Ack message sets the TYPE to 0x01, sets the domain number to join which domain, and sets the Flag value to False to subscribe to the participating domain and sends it to the DDSB. After receiving the message, the DDSB 20 sends an Ack message to the non-DDS communication object 32 to transmit the next message. The non-DDS communication object 32 receiving the Ack message sets the TYPE to 0x02, sets the kind to True, and sets the type name to transmit the DDSB 20 to generate a topic. After receiving the message, the DDSB 20 sends an Ack message to the non-DDS communication object 32 to transmit the next message. The non-DDS communication object 32 receiving the Ack message sets the TYPE to 0x02, sets the kind to False, and sets the topic name to transmit to the DDSB 20. After receiving the message, the DDSB 20 transmits an Ack message to the non-DDS communication object 32 to indicate that a subscription service is available. The third part is to deliver the message received from the domain to the non DDS communication object 32. The subscribed message from the created data reader is set to 0x08 and forwarded to the non DDS communication object 32. The non DDS communication object 32 does not transmit an Ack message to the DDSB 20. Thereafter, when the data reader subscribes to the message, the data reader is directly transmitted to the non-DDS communication object 32 in the form of a message whose TYPE is set to 0x08 through the DDSB 20.

11 illustrates a method of connecting a TCP / IP connection when the TCP / IP communication method is selected.

The DDSB 20 and the non-DDS communication object 30 are connected using the three way handshaking method of TCP. The non DDS communication object 30 sends a SYN message to the DDSB 20 to request a communication connection. After receiving the message, the DDSB 20 sends a SYN + ACK message to the non-DDS communication object 30 to respond to the communication connection. After receiving the message, the non DDS communication object 30 transmits an ACK message to the DDSB 20 and responds to the communication.

4. Features of the System of the Invention

The limitations of the system of the present invention are as follows.

The non DDS communication object 30 supports only data publication / subscription of the DDS service.

The DDSB 20 uses only default QoS.

The non DDS communication object 30 has a 1: 1 relationship with the data writer or data reader.

In DDSB 20, only the listener method is used to subscribe to the data of the domain.

The features of the system of the present invention are as follows.

The DDSB 20 has a DDS middleware and a module (Sender, Receiver) capable of communicating with a non DDS communication object 30.

A system without DDS middleware installed may use a DDS service by sending a simple message through the DDSB 20.

ㆍ Support various communication methods through Abstract Layer of DDSB 20.

As described above, although described with reference to a preferred embodiment of the present invention, those skilled in the art without departing from the spirit and scope of the present invention described in the claims In the present invention can be carried out by various modifications or variations.

10,10a, 10b, 10c: DDS 11,11a, 11b, 11c: DSPS
12,12a, 12b, 12c: RTPS 20: DDSB
21: Receiver 22: Sender
30: Non DDS Communication Object 31: Sender
32: Receiver

Claims (11)

In the Data Distribution Service Bridge (DDSB) communication system,
A data distribution service bridge (DDSB) for publishing / subscribing messages to a domain; and a non-DDS communication entity composed of a sender and a receiver communicating with the DDSB.
The DDSB includes a Data Distribution Service (DDS), a Sender, and a Receiver, which include a Real-Time Publish-Subscribe (RTPS) that provides a communication function, and a Data-Centric Publish-Subscribe (DCPS) that transmits data. An Abstract Layer comprising: a Data Distribution Service Bridge (DDSB) comprising a Protocol Manager for creating the DDS object and delivering a message; and a DDS Entity Manager having information on the DDS objects. A) communication system. The method of claim 1,
When a message subscribed in the domain is to be delivered to the non-DDS communication object (Non DDS Entity or non-DDS device), the reader of the Real-Time Publish-Subscribe (RTPS) DCPS delivers the message of the subscribed domain. It delivers to the data reader of (Data Centric Publish-Subscribe), the data reader is delivered to the protocol manager, and the protocol manager finds the non-DDS communication object matching the data reader through the DDS entity manager and then sends it to the sender of the abstract layer. The sender, and the sender to the non-DSS communication object, characterized in that for transmitting. The method of claim 1,
When a message of the non DDS communication object is to be published in the domain, the message to be published is delivered to a receiver of an abstract layer, and the message is transmitted from the receiver to a protocol manager, and the protocol manager communicates with the non DDS communication object. DDSB communication system for finding a matching data writer (DataWriter) through the DDS entity manager, delivers a message to the data writer, the data writer to the domain through the writer of the RTPS. The method of claim 1,
The abstract layer,
In order to easily manage non DDS communication object in DDSB, ID is assigned and managed for each non DDS communication object.In case of object using TCP / IP protocol, ID matching with IP address and port number is assigned. DDSB communication system. The method of claim 1,
The protocol manager,
A module that analyzes the message received by the DDSB, identifies a DDS entity manager and creates an object to generate an object of the DDS matching a non-DDS communication object, and generates a DDS object when the DDS object is generated. If you have a domain Participant that already participates in the domain you want to participate in, you do not create a new one, use a domain party fund that is already participating, and publish / subscribe to that domain. If the publisher and subscriber are already created in the domain party service, the created object is used without creation. If the topic object is already created in the domain, it is created without creation. Message to be used in the domain, and to send subscribed message to Sender of Abstract Layer DDSB communication system characterized in that the data transmitted to the writer. The method of claim 1,
The DDS Entity Manager,
A module having information of DDS entities created in a node in which the DDSB is installed, wherein the DDS entities are matched with the non-DDS communication object, managed in a table form (DDS Entity Table), and in the abstract layer. ID field that stores the ID of the designated non-DDS communication object. The remaining five fields store the address value of the DDS object created by the non-DDS communication object. DP field that stores the address of the domain party support, publisher and sub It consists of PUB and SUB fields for storing address values of scriber, DW and DR fields for storing address values of data writer and data reader, and if the non DDS communication object accesses the DDSB, the ID designated by the abstract layer After storing, when the protocol manager creates the DDS object, the protocol manager stores the address value of the generated DDS object in the same row of the table where the ID is stored. DDSB communication system. Data Distribution Service (DDS), Abstract Layer, which consists of Real-Time Publish-Subscribe (RTPS), which provides communication functions for publishing / subscribing messages to a domain, and Data-Centric Publish-Subscribe (DCPS), which transmits data. A Data Distribution Service Bridge (DDSB) including a Protocol Manager for creating the DDS object and delivering a message, and a DDS Entity Manager having information of the DDS objects; and non communicating with the DDSB. A DDSB communication method of a data distribution service bridge (DDSB) communication system including a non-DSS entity,
(a) establishing a connection between the DDSB and the non DDS communication object;
(b) executing a protocol communication procedure (Publish sequence diagram) in which the non-DDS communication object publishes a message of a domain; or,
(c) executing a protocol communication sequence for subscribing a message of a domain from the DDSB to a non-DDS communication object;
DDSB communication method characterized in that performed. The method of claim 7, wherein
In step (a) of establishing a connection between the DDSB and the non-DDS communication object,
(a1) establishing a connection between the DDSB and the non DDS communication object, and transmitting the SYN message to the DDSB by the non DDS communication object;
(a2) after the DDSB requesting a communication connection receives the message, transmitting a SYN + ACK message to the non-DDS communication object to respond to the communication connection; And
(a3) after the non-DDS communication object receives the message, completing the communication connection by transmitting an ACK message to the DDSB and responding;
DDSB communication method comprising a. The method of claim 7, wherein
(B) the non-DSS communication object executing a protocol communication procedure (Publish sequence diagram) for publishing a message to the DDS domain,
(b1) A part of generating a DDS object that matches the non-DDS communication object, and when the DDSB sends an Ack message to the non-DDS communication object to transmit the first message for creating the DDS object, the non-Ack message is received. After the DDS communication object sets the TYPE to 0x01, sets the domain number to join which domain, and sets the Flag value to True to provide the published service to the participating domain, the DDSB sends the message to the DDSB. To send the next message, the Ack message is sent to the non DDS communication object, and the non-DDS communication object receiving the Ack message sets the TYPE to 0x02, sets the kind to True, and sets the type name to generate the topic. Transmits an Ack message to the non DDS communication object to transmit the next message after receiving the message, and receives the Ack message. The object sets the TYPE to 0x02, sets the kind to False, sets the topic name to send to the DDSB, and sends an Ack message to the non DDS to indicate that the DDSB can publish the service. Generating a DDS entity to transmit to a communication object; And
(b2) The non-DDS communication object transmits a message to be published in a domain. When the non-DDS communication object sets TYPE to 0x04 and transmits a message to be published in the domain to the DDSB, the non-DDS communication is performed. A publication step of transmitting only a message to be published to the DDSB by defining a TYPE as 0x04 when an object publishes a message in the same topic;
DDSB communication method comprising a. The method of claim 7, wherein
(C) executing a protocol communication procedure of subscribing a message of the DDS domain to a non-DDS communication object;
(c1) A part of generating a DDS object that matches the non-DDS communication object. When the DDSB sends an Ack message to the first non-DSC communication object to transmit the first message for creating the DDS object, the Ack message is received. The object sets the TYPE to 0x01, sets the domain number to join which domain, and sets the Flag value to False to subscribe to the participating domains and sends it to the DDSB, and after the DDSB receives the message, Ack message to send a message is transmitted to the non DDS communication object, and the non DDS communication object receiving the Ack message sets the TYPE to 0x02, sets the kind to True, and sets the type name to DDSB to generate the topic. After receiving the message, the DDSB transmits an Ack message to the non-DDS communication object to transmit the next message, and receives the Ack message. The body sets the TYPE to 0x02, sets the kind to False, sets the topic name to send to the DDSB, and sends an Ack message to the non DDS to indicate that the DDSB can receive a subscription service. Generating a DDS entity to transmit to a communication object; And
(c2) As a part of delivering a message received from a domain to the non DDS communication object, if a message subscribed from the generated data reader is set to TYPE as 0x08 and delivered to the non DDS communication object, the non DDS communication object is transmitted to the non DDS communication object. Not transmitting an Ack message to a DDSB, and if the data reader subscribes to the message, a subscription step of directly transmitting the Ack message to the non-DDS communication object in the form of a message whose TYPE is set to 0x08 through the DDSB;
DDSB communication method comprising a. A DDSB communication method of a data distribution service bridge (DDSB) communication system including a data distribution service bridge (DDSB) for publishing / subscribing a message to a domain; and a non DDS entity (Non DDS Entity) for communicating with the DDSB.
(a-1) establishing a connection between the DDSB and the non-DDS communication object;
(b-1) executing a protocol communication procedure (Publish sequence diagram) in which the non-DDS communication object publishes a message in a DDS domain; or,
(c-1) executing a protocol sequence sequence of subscribing a message of a DDS domain from a DDSB to a non-DDS communication object; and executing a publish / subscribe protocol of the DDSB. Sends a subscribed message to the protocol manager through the data reader of the DDS, and the protocol manager finds a non-DDS communication object matching the object of the DDS through the DDS entity manager and sends it to the sender of the abstract layer of the DDSB. Transmits to the non-DDS communication object through the sender of the abstract layer of the DDSB, receives a message to be published by the non-DDS communication object to the receiver of the abstract layer, and transmits the message to the protocol manager; The manager checks the DDS entity manager and creates an object to create an object of the DDS that matches the non-DDS communication object. DDSB communication method wherein a message issued in Maine.

Images