| Contents | Index |
| On this page… |
|---|
The xPC Target software supports communication from the target computer to other systems or devices using User Datagram Protocol (UDP) packets. UDP is a transport protocol similar to TCP. However, unlike TCP, UDP provides a direct method to send and receive packets over an IP network. UDP uses this direct method at the expense of reliability by limiting error checking and recovery.
To use UDP for your xPC Target system, be sure to create a TCP/IP boot disk and boot the target computer with that boot disk.
The User Datagram Protocol (UDP) is a transport protocol layered on top of the Internet Protocol (IP) and is commonly known as UDP/IP. It is analogous to TCP/IP. A convenient way to present the details of UDP/IP is by comparison to TCP/IP as presented below:
Connection Versus Connectionless — TCP is a connection based protocol, while UDP is a connectionless protocol. In TCP, the two ends of the communication link must be connected at all times during the communication. An application using UDP prepares a packet and sends it to the receiver's address without first checking to see if the receiver is ready to receive a packet. If the receiving end is not ready to receive a packet, the packet is lost
Stream Versus Packet — TCP is a stream-oriented protocol, while UDP is a packet-oriented protocol. This means that TCP is considered to be a long stream of data that is transmitted from one end to the other with another long stream of data flowing in the other direction. The TCP/IP stack is responsible for breaking the stream of data into packets and sending those packets while the stack at the other end is responsible for reassembling the packets into a data stream using information in the packet headers. UDP, on the other hand, is a packet-oriented protocol where the application itself divides the data into packets and sends them to the other end. The other end does not have to reassemble the data into a stream. Note, some applications might indeed present the data as a stream when the underlying protocol is UDP. However, this is the layering of an additional protocol on top of UDP, and it is not something inherent in the UDP protocol itself.
TCP Is a Reliable Protocol, While UDP Is Unreliable — The packets that are sent by TCP contain a unique sequence number. The starting sequence number is communicated to the other side at the beginning of communication. Also, the receiver acknowledges each packet, and the acknowledgment contains the sequence number so that the sender knows which packet was acknowledged. This implies that any packets lost on the way can be retransmitted (the sender would know that they did not reach their destination because it had not received an acknowledgments). Also, packets that arrive out of sequence can be reassembled in the proper order by the receiver.
Further, time-outs can be established, because the sender will know (from the first few packets) how long it takes on average for a packet to be sent and its acknowledgment received. UDP, on the other hand, simply sends the packets and does not keep track of them. Thus, if packets arrive out of sequence, or are lost in transmission, the receiving end (or the sending end) has no way of knowing.
TCP communication can be compared to a telephone conversation where a connection is required at all times and two-way streaming data (the words spoken by each party to the conversation) are exchanged. UDP, on the other hand, can be compared to sending letters by mail (without a return address). If the other party is not found, or the letter is lost in transit, it is simply discarded. The analogy fails, however, when considering the speed of communication. Both TCP and UDP communication roughly happen at the same speed, because both use the underlying Internet Protocol (IP) layer.
Note Unreliable is used in the sense of "does not always succeed" as opposed to "fails a lot of the time." In practice, UDP is reliable as long as the receiving socket is active and is processing data as quickly as it arrives. |
UDP was chosen as the xPC Target transport layer because of its lightweight nature. Since the primary objective of an application running in the xPC Target framework is real-time, the lightweight nature of UDP gives the real-time application a good chance of succeeding in real-time execution. Also, the datagram nature of UDP is good for sending samples of data from the application generated by the Simulink Coder software. Because TCP is stream oriented, separators between sets of data must be used for the data to be processed in samples. It is easier to build an application to deal with unreliable data than it is to decode all of this information in real-time. If the application is unable to process the data as quickly as it arrives, the following packets can just be ignored and only the most recent packet can be used.
Communication can involve a packet made up of any Simulink data type (double, int8, int32, uint8, etc.), or a combination of these. The xPC Target block library provides blocks for combining various signals into one packet (packing), and then transmitting it. It also provides blocks for splitting a packet (unpacking) into its component signals that can then be used in a Simulink model. The maximum size of a packet is limited to about 1450 bytes.
The UDP blocks work in the background when the real-time application is not running. The UDP communication has been set up to have a maximum of two UDP packets waiting to be read. This applies to one UDP port, which corresponds to one UDP Receive block. All subsequent packets are rejected. This prevents excessive memory usage and minimizes the load on the TCP/IP stack. Consequently, when any large background task is performed, such as uploading a screen shot or communicating large pages through the WWW interface, packet loss might occur. Design applications so that the receipt of further packets after the ones that were lost bridges any gap. .
Note also that because UDP block transfers operate as background tasks, the xPC Target software disables them in polling mode. See Restrictions Introduced by Polling Mode.
![]() | UDP I/O Support | xPC Target UDP Example | ![]() |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |