KR20210073005A - A middleware apparatus operating method of data distribution services for providing a efficient message processing - Google Patents

Abstract

A method for operating a data distribution service (DDS) middleware device for providing efficient message processing comprises the steps of: transmitting a message request, received from a user device, to an event processing unit; and serializing a message received from the event processing unit and transmitting the same to a network through a communication interface unit. The transmitting step includes a serialization step of serializing the message, requested to be published, in a format according to a real time publish subscribe (RTPS) standard, but batching a plurality of messages, accumulated in a message buffer, to a sub-message of one RTPS message. Therefore, the method can implement low latency time.

Description

A MIDDLEWARE APPARATUS OPERATING METHOD OF DATA DISTRIBUTION SERVICES FOR PROVIDING A EFFICIENT MESSAGE PROCESSING }

The present invention relates to a method of operating a middleware device for a data distribution service. More specifically, the present invention relates to a method of operating a data distribution service middleware (DDS) device that provides efficient message processing.

DDS (Data Distribution Service) defines OMG (Object Management Group) standard communication middleware, and discloses communication middleware that provides data-oriented publish-subscribe communication method to applications.

In particular, the DDS middleware provides efficient data distribution using the Publish/Subscribe communication technique in an environment where devices can freely participate/withdraw.

A characteristic of such DDS is that it is suitable for a ubiquitous environment in which a plurality of devices are dynamically linked to form a single network domain and exchange data frequently. DDS includes various functions such as publish/subscribe function, QoS control function, discovery function to find out the address of DDS participating node, and each middleware is equipped with computing resources such as processor and memory for such processing.

However, since computing resources are limited, it is necessary to improve the inefficient aspects of DDS middleware defined by RTPS and OMG standards to efficiently operate them.

For example, DDS middleware transmits messages to the network by re-expressing data in the form of RTPS Submessage according to the RTPS standard. However, when the size of the transmitted message is smaller than the maximum transmission unit (MTU), which is the maximum size of a message that one packet can contain, the efficiency of using the packet decreases, which leads to a decrease in throughput.

In addition, DDS middleware internally performs highly complex communication processing logic to support 22 types of QoS. To simplify communication processing logic, DDS middleware creates a plurality of threads during execution and then distributes tasks in units of threads. However, inter-thread communication that occurs in the process of processing a communication task causes an increase in delay time, thereby reducing real-time communication.

In addition, RTPS, which is a standard wire protocol of DDS, does not participate in flow control, unlike Transmission Control Protocol (TCP). Therefore, if the network output speed of the chip is faster than the input speed of the adjacent network, loss occurs for the excess bandwidth.

Meanwhile, RTPS, the standard wire protocol for DDS, deals only with basic mechanisms to ensure interoperability between various DDS implementations. As a result, it is difficult to satisfy high throughput and low latency, and the method to control traffic according to the actual network is not specified. In particular, the performance of the reliable communication method is greatly reduced in low-quality networks. .

The present invention has been devised to solve the above problems, overcomes the decrease in throughput and real-time communication due to the size limitation of the message, and prevents traffic loss and loss due to traffic flow control, thereby reducing the low latency. An object of the present invention is to provide an operating method of a DDS middleware device that implements and effectively enables real-time processing.

A data distribution service (DDS) middleware device according to an embodiment of the present invention for solving the above-described problems includes: a message processing unit that transmits a message request received from a user device to an event processing unit; and a packet processing unit that serializes the message received from the event processing unit and transmits it to a network through a communication interface unit, wherein the packet processing unit serializes the message requested to be published in a format according to the RTPS (Real Time Publish Subscribe) standard, but , and a serialization unit that batches a plurality of messages accumulated in the message buffer into sub-messages of one RTPS message.

A method of operating a data distribution service (DDS) middleware device for solving the above-described problems includes: transmitting a message request received from a user device to an event processing unit; and serializing the message received from the event processing unit and transmitting it to the network through the communication interface unit, wherein the transmitting includes serializing the message requested to be published in a format according to the RTPS (Real Time Publish Subscribe) standard. , a serialization step of batching a plurality of messages accumulated in the message buffer to a sub-message of one RTPS message.

According to an embodiment of the present invention, a maximum message throughput within a delay limit may be achieved through real-time message batching processing according to a DDS middleware device and an operating method thereof.

In addition, the DDS middleware apparatus and the operating method thereof according to an embodiment of the present invention can process conditional input/output processing pass-through activation to minimize event overhead, and thus minimize delay time.

In addition, according to the DDS middleware apparatus and the operating method thereof according to an embodiment of the present invention, it is possible to control the transmission bandwidth to prevent loss of excess bandwidth due to traffic flow control, and to implement a reliable data transmission/reception process.

Accordingly, the DDS middleware device and the method of operation thereof according to an embodiment of the present invention overcome a decrease in throughput and a decrease in real-time communication due to a size limitation of a message, and prevent traffic loss and loss due to traffic flow control, Through this, it is possible to provide a DDS middleware device and an operating method thereof that implement low latency and effectively enable real-time processing.

1 is a conceptual diagram schematically illustrating an entire system according to an embodiment of the present invention.
2 is a block diagram illustrating a detailed configuration of a packet processing unit and a system operation according thereto according to an embodiment of the present invention.
3 is a diagram illustrating serialization of an RTPS message according to an embodiment of the present invention, and FIG. 4 is a diagram comparing serialization between an embodiment of the present invention and the prior art.
5 is a flowchart for explaining the operation of the packet processing unit according to the serialization unit processing according to an embodiment of the present invention.
6 is a flowchart illustrating an operation of an input/output pass-through activation unit according to an embodiment of the present invention.
7 is a flowchart illustrating an operation of a traffic controller according to an embodiment of the present invention.
8 is a flowchart illustrating in more detail a calculation process for calculating the delay time of the traffic control unit.

The following is merely illustrative of the principles of the invention. Therefore, those skilled in the art will be able to devise various devices which, although not explicitly described or shown herein, embody the principles of the present invention and are included within the spirit and scope of the present invention. Moreover, it is to be understood that all conditional terms and examples listed herein are, in principle, expressly intended solely for the purpose of enabling the concept of the present invention to be understood, and not limited to the specifically enumerated embodiments and states as such. should be

Moreover, it is to be understood that all detailed description reciting the principles, aspects, and embodiments of the invention, as well as specific embodiments, are intended to cover structural and functional equivalents of such matters. It is also to be understood that such equivalents include not only currently known equivalents, but also equivalents developed in the future, i.e., all devices invented to perform the same function, regardless of structure.

Thus, for example, the block diagrams herein are to be understood as representing conceptual views of illustrative circuitry embodying the principles of the present invention. Similarly, all flowcharts, state transition diagrams, pseudo code, etc. may be tangibly embodied on computer-readable media and be understood to represent various processes performed by a computer or processor, whether or not a computer or processor is explicitly shown. should be

The functions of the various elements shown in the figures including a processor or functional blocks represented by similar concepts may be provided by the use of dedicated hardware as well as hardware having the ability to execute software in association with appropriate software. When provided by a processor, the functionality may be provided by a single dedicated processor, a single shared processor, or a plurality of separate processors, some of which may be shared.

In addition, clear use of terms presented as processor, control, or similar concepts should not be construed as exclusively referring to hardware having the ability to execute software, and without limitation, digital signal processor (DSP) hardware, ROM for storing software. It should be understood to implicitly include (ROM), RAM (RAM) and non-volatile memory. Other common hardware may also be included.

In the claims of the present specification, a component expressed as a means for performing the function described in the detailed description includes, for example, a combination of circuit elements that perform the function or software in any form including firmware/microcode, etc. It is intended to include all methods of performing the functions of the device, coupled with suitable circuitry for executing the software to perform the functions. Since the present invention defined by these claims is combined with the functions provided by the various enumerated means and combined in a manner required by the claims, any means capable of providing the functions are equivalent to those contemplated from the present specification. should be understood as

The above-described objects, features and advantages will become more apparent through the following detailed description in relation to the accompanying drawings, and accordingly, those of ordinary skill in the art to which the present invention pertains can easily implement the technical idea of the present invention. There will be. In addition, in describing the present invention, if it is determined that a detailed description of a known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted.

Hereinafter, a preferred embodiment according to the present invention will be described in detail with reference to the accompanying drawings.

1 is a conceptual diagram schematically illustrating an entire system according to an embodiment of the present invention.

Referring to FIG. 1 , the DDS middleware device 100 according to an embodiment of the present invention includes a packet processing unit 110 , an event processing unit 120 , and a message processing unit 130 , and the packet processing unit 110 is a communication interface. It may be connected to an external network through the unit 140 , and the message processing unit 130 may publish a message input from the user device 200 , or subscribe to a message received from the network and deliver it to the user device 200 . have.

More specifically, the middleware device 100 according to an embodiment of the present invention provides a communication function using a Data Centric Publish Subscribe (DCPS) protocol and a RealTime Publish Subscribe (RTPS) protocol according to the standardized Dara Distribution Service (DDS) standard. can provide DCPS standardizes standardized user API and modeling, and RTPS standardizes communication protocol that enables interoperability between DDS vendors.

The message processing unit 130 is responsible for interfacing with the user device 200 using the DCPS API of DDS, and receives a message publication/subscription request according to the request of the user device 200, Transmission processing and reception processing of subscription messages are performed.

In addition, the event processing unit 120 may process a transmission event process and a retransmission event process required for the message publication or subscription processing of the message processing unit 130 .

Meanwhile, the packet processing unit 110 may be connected to the communication interface unit 140 , and packetizes a message into an RTPS packet and transmits it to the communication interface unit 140 , or restores a message from the RTPS packet to the event processing unit 120 . Forwarding processing can be performed.

As described above, in an embodiment of the present invention, message information written in the user device 200 may be transmitted to the message processing unit 130 , and the transmitted message is published and processed through the event processing unit 120 to be processed by the packet processing unit 110 . may be packetized and transmitted to an external network through the communication interface unit 140 .

Here, the external network is a local area network (LAN), a wide area network (WAN), a value added network (VAN), a personal local area network (PAN), a mobile communication network ( It can be implemented in all types of wired/wireless networks such as mobile radiocommunication network) or satellite communication networks. However, in order to support the DDS standard, it may be preferable that the external network be implemented as a wired/wireless network in the form of a local area network.

In addition, when a DDS subscription message reception is requested from the user device 200 , the message processing unit 130 receives a packet received from the communication interface unit 140 in the packet processing unit 110 through the subscription message processing through the event processing unit 120 . Inverse transformation is processed with this subscription message. In addition, the inversely transformed subscription message may be transmitted to the message processing unit 130 through the event processing unit 120 and output to the user device 200 .

In particular, the packet processing unit 110 according to an embodiment of the present invention converts an RTPS standard message transmitted and received through the communication interface unit 140 into a communication protocol packet such as UDP to ensure interoperability between DDS products. can be performed, and this conversion process may include a serialization process of serializing a message requested to be published in a form according to the RTPS standard.

And, in the serialization process, the packet processing unit 110 according to an embodiment of the present invention can eliminate bandwidth wastage through a real-time BATCHING process and ensure real-time performance.

More specifically, for example, in RTPS, one user message is basically configured to be serialized into one RTPS message. Accordingly, when the user device 200 requests to publish 100 messages, 100 RTPS messages may be generated and transmitted to the network.

However, due to the characteristics of the network device, frequent I/O caused by a large number of packets generated within a short period of time causes performance degradation. In addition, when converting user data into network packets, space for expressing metadata and headers of each protocol such as Ethernet, IP, UDP, and RTPS is added to the message. Bandwidth is wasted.

Accordingly, in order to solve the performance degradation due to frequent I/O and the wastage of bandwidth required for expressing protocol metadata and headers, and at the same time to ensure real-time performance, the packet processing unit 110 according to an embodiment of the present invention includes: A serialization process capable of batching multiple messages up to the maximum allowable byte limit of the packet in the RTPS sub-message may be processed, and one or more message buffers may be included for this.

In addition, the packet processing unit 110 according to an embodiment of the present invention performs the start and end processing of each event processed by the event processing unit 120, delay caused by communication between threads and delay time caused by state transition In order to minimize this, an input/output pass-through path that processes a message publication or subscription process with a single thread can be activated, and whether or not such an input/output pass-through is activated is dynamically variable depending on the delay time of the message, thereby adapting to the environment It is possible to achieve the minimization of the delay time.

In addition, the packet processing unit 110 according to an embodiment of the present invention may set a maximum bandwidth that prevents loss during traffic control, which is performed by performing transmission standby processing through a delay time calculation according to a packet transmission parameter. can be adjusted.

This embodiment of the present invention will be described in more detail below with reference to the following drawings.

2 is a block diagram illustrating a detailed configuration of a packet processing unit and a system operation according thereto according to an embodiment of the present invention.

Referring to FIG. 2 , the packet processing unit 110 according to an embodiment of the present invention includes an input/output pass-through activation unit 111 , a serialization unit 113 , a traffic control unit 115 , and a transmission/reception unit 117 .

First, the packet processing unit 110 may use UDP as a transport layer protocol of the RTPS, and may encapsulate the middleware internal data and user data generated through the middleware into an RTPS message. Since RTPS uses UDP as the transport layer, RTPS messages can be encapsulated back into UDP datagrams.

The serializer 113 may serialize the RTPS message for encapsulating the RTPS message into a UDP datagram.

3 is a diagram illustrating serialization of an RTPS message according to an embodiment of the present invention, and FIG. 4 is a diagram comparing serialization between an embodiment of the present invention and the prior art.

Referring to FIG. 3 , the RTPS message may specifically include an RTPS header and one or more RTPS sub-message data, and the RTPS header includes an arbitrary value (Magic Value), a protocol version (Protocol Version), and a vendor ID (Vendor ID). and publisher identification information (GUID-Globally Unique Identifier) that publishes the message. The DDS physically performs communication using an IP address and a UDP port through the communication interface unit 140, but is logically defined so that the counterpart can be identified with a GUID prefix.

And, the RTPS sub-message data may include sub-message header information and sub-message body information. The sub-message header information may include sub-message type information and size information. The sub-message body information may include actual data to be expressed by the message.

The sub-message type information may be classified as DATA, DATA_FRAG, GAP, ACKNACK, HEARTBEAT, HEARTBEAT_FRAG, PAD, INFO_SRC, INFO_DST, INFO_TS, or INFO_REPLY, and may indicate the properties of actual data included in each sub-message body. .

And, referring to FIG. 4A, basically, in the prior art, one user message is serialized into one RTPS message. Therefore, when the user publishes 100 messages, 100 RTPS messages are generated and transmitted to the network. Due to the characteristics of network devices, frequent I/O caused by a large number of packets generated within a short period of time causes performance degradation. In addition, when converting user data into network packets, space for expressing metadata and headers of each protocol such as Ethernet, IP, UDP, and RTPS is added to the message. Bandwidth is wasted.

Accordingly, as shown in FIG. 4(B), the serializer 113 according to an embodiment of the present invention batches the RTPS sub-message constituting the RTPS message up to the maximum byte limit allowed for the packet. ) can be processed. Therefore, if the user message is small enough, a plurality of user messages can be serialized into one RTPS message.

To this end, the serializer 113 may include a separate message buffer (not shown) for message batching. In order to batch messages, there must be enough messages in the message buffer.

Accordingly, the serializer 113 according to an embodiment of the present invention, in order to accumulate enough messages in the message buffer, when the user device 200 requests a message publication request faster than the network transmission rate, the message cannot be transmitted immediately. It can be determined to be accumulated in the message buffer. In addition, the serializer 113 may secure time for the message to accumulate in the message buffer by forcibly delaying the message publication request received from the user device 200 .

In particular, the DDS standard defines a delay allocation (LATENCY_BUDGET) parameter as a QoS parameter. The delay allocation parameter can be applied to the publishing-side user device 200 and is defined as a numerical value expressing the urgency of data communication only, but the actual meaning can be arbitrarily assigned by the implementer. Accordingly, the serializer 113 according to an embodiment of the present invention may redefine the delay allocation (LATENCY_BUDGET) parameter as the maximum delay time of message transmission for arranging the RTPS message.

Accordingly, the serializer 113 according to an embodiment of the present invention forcibly delays the message publication request received from the user device 200 during the maximum delay time of message transmission based on the delay allocation parameter, and sends the requested publication message to the message. It accumulates in the buffer, and when the delay time elapses, the accumulated messages are batched to form one serialized RTPS merge message, and the configured RTPS merge message is converted into a communication packet through the transceiver 117 and the communication interface unit 140 ) can be printed.

Since such an RTPS merge message follows the RTPS standard defined in DDS as it is, interoperability is not affected, and the receiver can acquire serialized data from the start point to the end point of the messages included in the RTPS merge message, respectively. Real-time batch transmission and reception processing becomes possible.

Accordingly, the serialization unit 113 according to an embodiment of the present invention can solve the aforementioned performance degradation due to frequent I/O and waste of bandwidth required for expressing protocol metadata and headers, and at the same time ensure real-time performance. can

5 is a flowchart for explaining the operation of the packet processing unit 110 according to the processing of the serialization unit 113 according to an embodiment of the present invention.

Referring to FIG. 5 , when an event of the event processing unit 120 is generated and delivered ( S101 ), the serialization unit 113 according to an embodiment of the present invention determines whether it is a message publication event ( S103 ).

In the case of a message publication event, the serialization unit 113 assigns a sequence having the same GUID to the publication message and inserts the sequence into the message buffer (S109).

For example, the sequence assigned to the publication message may be a serial number such as 1, 2, 3, and all messages inserted into the message buffer may be matched to the same publisher identifier (GUID).

Then, the serializer 113 determines whether the message buffer is full (S111), and if it is full, performs batch processing of the buffered messages (S113). If it is not full, the publication event may be processed by waiting until a certain delay allocation cycle time.

Here, the serializer 113 may perform a process of including a plurality of submessages to which a serial number sequence is assigned to one RTPS message matched with the same publisher identifier (GUID) for buffered message batching processing. .

Then, the serialization unit 113 transmits the batched message to the transceiver 117 , and the transceiver 117 performs packetized processing and transmits it to an external network through the communication interface unit 140 ( S115 ).

Meanwhile, according to an embodiment of the present invention, as described above, a delay allocation (LATENCY_BUDGET) QoS parameter may be set.

Accordingly, when it is confirmed that the event generated in step S103 is not a message publication event, the serializer 113 determines that it is a delay allocation cycle event, and checks whether there is a message queued for more than the delay allocation time in the message buffer. (S105).

If there is a message waiting for the delay allocation time, the serialization unit 113 performs batch processing (S113) and transmission processing (S115) of the messages buffered so far.

However, if there is no message waiting for more than the delay allocation yet, the serializer 113 may reschedule the periodic event according to the delay allocation ( S107 ), so that there is no data delayed more than the delay allocation time.

Accordingly, the batching process of the serialization unit 113 according to an embodiment of the present invention can ensure real-time, and in particular, through the delay allocation (LATENCY_BUDGET) QoS parameter setting, the maximum within the delay limit guaranteed by a specific parameter. Message throughput can be secured.

Meanwhile, referring to FIG. 2 again, the packet processing unit 110 according to an embodiment of the present invention includes an input/output pass-through activation unit 111 .

The middleware device 100 according to an embodiment of the present invention may be divided into a plurality of processing units in order to reduce the complexity of implementing complex DDS functions, and each processing unit except for some logic for flow connection with other processing units, Most of the logic can be driven independently of other processing units. Accordingly, the middleware device 100 according to an embodiment of the present invention may include its own processor in each processing unit, and each processor processes each process thread to simultaneously perform several tasks to publish/subscribe a large amount of messages. Able to respond to requests.

However, a delay occurs when the flow of processing is changed from one processing unit to the next. This may be caused by a delay caused by inter-thread communication with the next processing unit that occurs at the start and end of event delivery, and a delay until the corresponding thread is restarted when the next processing unit's thread is in the waiting state.

In order to minimize the delay, the input/output pass-through activation unit 111 according to an embodiment of the present invention directly processes the task without creating a thread to start or end event transfer between each processing unit through thread driving of a single processing unit. The occurrence of unnecessary delay time can be minimized, and it can be processed ON or OFF by determining whether the input/output pass-through function is activated.

For example, if I/O pass-through is enabled, parallel processing becomes impossible because the final processing of a message is performed using a thread of one processing unit, and as a result, processing performance of a large amount of messages may be reduced. Accordingly, the input/output pass-through activation unit 111 according to an embodiment of the present invention may dynamically change whether to activate the input/output pass-through in order to optimize both throughput and delay time.

6 is a flowchart for exemplarily explaining the operation of the input/output pass-through activation unit 111 according to an embodiment of the present invention.

Referring to FIG. 6 , the input/output pass-through activation unit 111 according to an embodiment of the present invention optimizes both the throughput and the delay time, and the average time difference of the RTPS packet transmission/reception time records and the transmission/reception processing time of one RTPS packet By comparing , it is possible to dynamically change whether input/output pass-through is activated.

More specifically, first, the input/output pass-through activation unit 111 accumulates and records the transmission/reception time information of the RTPS packet (S201).

Then, the input/output pass-through activation unit 111 determines whether the time recording is measured 32 times or more ( S203 ).

Here, the number of times recorded may be different depending on the network environment.

Then, the input/output pass-through activation unit 111 determines whether the measured average value of the time difference between packets of the RTPS packets is within a preset transmission/reception processing time of one RTPS packet ( S205 ).

If the time difference average is within the pre-set transmission/reception processing time of one RTPS packet, it may be determined that the number of current packets processed through input/output pass-through is large. The pass-through activation unit 111 may deactivate the input/output pass-through function (S207).

On the other hand, when the time difference average value exceeds the preset transmission/reception processing time of one RTPS packet, the serial message processing can minimize the delay time, so the input/output pass-through activation unit 111 activates the input/output pass-through function (S209). ).

In this way, the input/output pass-through activation unit 111 according to the embodiment of the present invention can minimize the delay time according to the real-time transmission situation of the message, and in particular, when processing a large amount of messages, each processing unit processes the message in parallel. Since it is possible to minimize the delay time, it is expected that the overhead of event delivery start/end will be large when disabling I/O pass-through and processing a small amount of messages. Therefore, it is possible to minimize the delay time by enabling I/O pass-through. there will be

Meanwhile, referring to FIG. 2 again, the packet processing unit 110 according to an embodiment of the present invention may include an input/output traffic control unit 115 .

The transceiver 117 may packetize the data processed by the serializer 113 and transmit the packet to an external network. However, when the bandwidth of the network interface of the communication interface unit 140 is greater than the bandwidth of the actual network, all packets corresponding to the excess bandwidth of the actual network may be lost.

In order to recover the lost packet, the transceiver 117 may start a retransmission process. However, since the retransmission process is also an act of sending packets to the network, some retransmission packets may also be lost as much as bandwidth excess occurs in the retransmission process, and a vicious cycle of retransmitting some lost retransmission packets causes deterioration of communication performance. .

Accordingly, the traffic control unit 115 according to an embodiment of the present invention can connect between the serialization unit 113 and the transceiver unit 117, so that the transmission bandwidth can be constantly controlled through a transmission time delay, the bandwidth Packet loss due to excess can be prevented. This maximum bandwidth allowance may vary depending on the actual network environment and may be predetermined according to user settings.

7 is a flowchart for explaining the operation of the traffic control unit 115 according to an embodiment of the present invention.

Referring to FIG. 7 , when serialized message data is transmitted from the serialization unit 113 ( S310 ), the traffic control unit 115 according to an embodiment of the present invention determines whether a current time is within a delay time according to a preset bandwidth. (S303).

In addition, the traffic control unit 115 transmits the message to the transceiver 117 if it is within the allowable amount (S305), and if it exceeds the allowable amount, processes the transmission delay for a predetermined time (S307), and the delayed message is the transmission delay time Thereafter, it may be transmitted to the transceiver 117 .

More specifically, in step S303, the traffic control unit 115 according to an embodiment of the present invention may determine whether the current time point is within a delay time according to a preset bandwidth using Equation 1 below.

Equation 1 as described above shows a process of calculating the time T_open during which packet transmission is possible when n packets are transmitted, and the traffic control unit 115 determines whether or not the message transmission is delayed depending on whether the packet transmission is within the available time. and a delay time.

More specifically, T_open indicates a time during which packet transmission is possible, and when T_current is earlier than T_open, packet transmission may be delayed.

T_current may represent the current time, and a value representing the UNIX Epoch Timestamp with nanosecond resolution may be exemplified. For example, T_current corresponding to 16:30 on October 1, 2019 may have a value of 1,569,915,000,000,000,000.

And, B may be a value representing the maximum bandwidth value of the network interface used by the middleware device 100 in bits per second (bps). The maximum bandwidth value may be detected by the traffic control unit 115 by identifying it from the communication interface unit 140 or may be separately designated by a user.

And, 10^9 / B represents a bit slice, and may mean nanoseconds required for the bandwidth of a network device to transmit 1 bit.

In addition, L_i may indicate the size of the i-th packet, and since the packet size Li is in bytes, a value obtained by multiplying the packet size by 8 to integrate the unit of the packet size into bits may be defined to be cumulatively summed.

Referring to Equation 1 proposed in this way, the traffic control unit 115 determines how many bit slices divided in nanoseconds are used when packet transmission occurs within a preset maximum bandwidth and Tx traffic occurs. By calculating, it is possible to calculate the time T_open during which packet transmission is possible.

For example, if the currently measured T_current is smaller than the last calculated T_open, the traffic controller 115 may delay transmission for a delay time equal to the value of T_open - T_current.

8 is a flowchart illustrating in more detail a calculation process for calculating the delay time of the traffic control unit 115 .

Referring to FIG. 8 , the traffic control unit 115 according to an embodiment of the present invention inputs an initial T_open of 0 and updates T_current to a current value ( S401 ).

Then, the traffic control unit 115 determines whether T_current is greater than T_open (S403).

If T_current is smaller than T_open, the traffic control unit 115 determines whether a difference between T_open - T_current values is 1 ms or less (S405).

If the difference between T_open - T_current is greater than 1 ms, the traffic control unit 115 determines whether T_open is smaller than T_current (S407).

If T_open is not smaller than T_current, the traffic control unit 115 processes transmission standby and updates the T_open value to T_current (S409).

Meanwhile, when T_current is greater than T_open in step S403 , the traffic controller 115 determines whether a difference between T_current - T_open is 1 ms or less ( S411 ).

If T_open is smaller than T_current or the difference between T_current and T_open is not less than 1 ms in step S407, T_current is updated again (S413) and T_open is updated again (S415).

According to such processing, the T_open value and the T_current value may be adjusted so that the transmission standby does not occur too often. In particular, when the current time has elapsed more than 1 millisecond from the last packet transmission time, the T_open value may be updated to the T_current value so that a transmission standby processing flow does not occur.

On the other hand, referring back to FIG. 2 , the packet processing unit 110 according to the embodiment of the present invention includes a transceiver 117 , and the transceiver 117 is configured through the serialization unit 113 and the traffic control unit 115 . The received publication message is packetized and transmitted to an external network through the communication interface unit 140 , or an external packet is received and delivered to the serializer 113 so that the deserialized subscription message is transmitted to the user through the message processing unit 130 . It can be processed to be delivered to the device 200 .

Through such a configuration, the middleware device 100 according to an embodiment of the present invention may provide message batching processing, input/output processing pass-through processing, and traffic control processing capable of maintaining real-time performance.

The above-described method according to various embodiments of the present invention may be implemented as a program and provided to each server or device while being stored in various non-transitory computer readable media. Accordingly, the user terminal 100 may access the server or device and download the program.

The non-transitory readable medium refers to a medium that stores data semi-permanently, not a medium that stores data for a short moment, such as a register, cache, memory, etc., and can be read by a device. Specifically, the various applications or programs described above may be provided by being stored in a non-transitory readable medium such as a CD, DVD, hard disk, Blu-ray disk, USB, memory card, ROM, and the like.

In addition, although preferred embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above, and the technical field to which the present invention belongs without departing from the gist of the present invention as claimed in the claims In addition, various modifications may be made by those of ordinary skill in the art, and these modifications should not be individually understood from the technical spirit or perspective of the present invention.

Claims (10)

In the method of operating a DDS (Data Distribution Service) middleware device,
transmitting the message request received from the user device to the event processing unit; and
Serializing the message received from the event processing unit and transmitting it to a network through a communication interface unit,
The transmitting step is
Serializing the message requested to be published in a format according to the RTPS (Real Time Publish Subscribe) standard, but including a serialization step of batching a plurality of messages accumulated in the message buffer to a sub-message of one RTPS message
How DDS middleware devices work. According to claim 1,
The serialization step is
and assigning a sequence number sequence having the same GUID to a plurality of published messages accumulated in a message buffer.
How DDS middleware devices work. 3. The method of claim 2,
The serialization step is
performing a process of including a plurality of submessages assigned with a serial number sequence in one RTPS message matched with the same publisher identifier (GUID) for buffered message batching processing
How DDS middleware devices work. 4. The method of claim 3,
The serialization step is
Checking whether there is a message queued for more than a preset delay allocation time in the message buffer, and if there is a message waiting for the delay allocation time, performing batch processing of messages buffered so far
How DDS middleware devices work. According to claim 1,
The transmitting step is
Through the thread driving of a single processing unit, the input/output pass-through activation step of determining whether to activate the input/output pass-through function capable of performing message processing independently without creating individual event delivery start or end threads of other processing units
How DDS middleware devices work. 6. The method of claim 5,
The input/output pass-through activation step includes:
Comparing the time difference average time of the RTPS packet transmission/reception time record and the transmission/reception processing time of the RTPS packet, dynamically varying whether input/output pass-through is activated
How DDS middleware devices work. 7. The method of claim 6,
The input/output pass-through activation step includes:
Deactivating an input/output pass-through function when the average time difference of the RTPS packet transmission/reception time record is within a preset transmission/reception processing time of the RTPS packet;
How DDS middleware devices work. 7. The method of claim 6,
The input/output pass-through activation step includes:
activating an input/output pass-through function when the average time difference of the RTPS packet transmission/reception time record exceeds a preset transmission/reception processing time of the RTPS packet
How DDS middleware devices work. According to claim 1,
The transmitting step is
If the current time T_current is earlier than the time T_open at which packet transmission is possible, further comprising a traffic control step of constantly controlling the transmission bandwidth to a preset maximum bandwidth through a transmission time delay of packet transmission
How DDS middleware devices work. 10. The method of claim 9,
The traffic control unit calculates the amount of bit slices for a predetermined unit period used when packet transmission occurs within a preset maximum bandwidth and traffic is generated to calculate a time T_open during which the packet transmission is possible.
How DDS middleware devices work.

Images