Featured Topic
 

How to Ensure the Stability and Reliability of Your Serial-to-Ethernet Network Architecture

Serial communications based on the RS-232, RS-422, and RS-485 standards have traditionally been used in industrial automation to connect and issue commands to a wide range of serial interface devices, from simple barcode readers to sophisticated Computer Numerical Control (CNC) machines. However, the limitations on transmission distance, accessibility, the amount of data transferred at a time, and transmission speed led to a demand for greater flexibility.

Since the early 1990’s, Ethernet networks have become more prominent in the industrial marketplace due to their ability to provide fast, secure, and flexible networks. With this shift to Ethernet, a requirement for protocol conversion between serial and Ethernet TCP/IP emerged, and serial device servers were developed to bridge this gap. Serial device servers allowed users to retain all of their legacy serial equipment while interfacing directly with an Ethernet network.

One of the most important requirements for serial-to-Ethernet technology is providing stable and reliable data communications between each network node. Given the mission-critical nature of industrial networks, even a minor error in data transmission can cost managers time and money. In this article, we highlight the three types of reliability that are needed to ensure stable connections in a serial-to-Ethernet network architecture: (1) host reliability, (2) network reliability, and (3) device reliability.

Host Reliability

In a serial-to-Ethernet network architecture, a “host” is a computer that monitors and controls the serial devices making up the architecture. The host communicates with a serial device server via Ethernet, and the serial device server communicates with serial devices that are generally connected directly to the serial device server. Since hosts (i.e., computers) can crash due to unforseen hardware or software glitches, it is important to mitigate this possibility by including one or more backup hosts as part of your system.

A simple approach is to use one backup host computer, which we’ll call Host B. Host B’s job is to provide reliability by backing up the data for the primary host computer, which we’ll call Host A. Since this traditional approach to host redundancy requires Host A to manually synchronize with Host B, Host B can only provide limited data redundancy. In addition, Host B can neither read the data on Host A nor take control of the network in place of Host A, leaving the network architecture vulnerable to system-wide crashes. Administrators must manually back up and synchronize host computers, and the backup hosts cannot perform the same tasks as the primary host (e.g., take control of the network).

A smarter solution is provided by the Maximum Connection function supported by most Moxa NPort serial device servers. The Maximum Connection function allows you to designate a primary host, which can automatically send serial data or commands to up to 4 or 8 backup host computers at the same time. Although the primary host can only send the same data or commands to each backup host, each backup host can promptly take over network control when the primary host is not operating properly.

Network Reliability

The Ethernet network itself could also fail, and consequently it is essential to implement some form of network redundancy. Moxa provides two network redundancy solutions.

Network Redundancy Using One LAN

Moxa’s redundant Turbo Ring technology can be used to prevent network disruptions and guarantee reliable data transmissions to the proper devices. With Turbo Ring, one segment of the ring topology is blocked to prevent switching loops and broadcast storms, and then when an abnormality is detected along the original communication route of the ring, the blocked segment is reconnected to allow all of the Ethernet devices making up the ring to continue communicating. Moxa’s Turbo Ring can recover your network in less than 100 ms, which is substantially faster than STP, which could take upwards of 30 seconds to reconnect, or even RSTP, which could take up to 2 seconds to reconnect.

Network Redundancy Using Two LANs

Moxa’s terminal server supports the Redundant COM operation mode, which can be used to set up a redundant LAN between the serial devices connected to the terminal server’s serial ports and the host computer. The redundant structure involves using the terminal server’s two LAN ports to set up two independent LANs that connect the terminal server to the host computer. If either of the two LANs fails, the other LAN will continue transmitting packets between the serial devices and the host, with the packets passing through the terminal server. In fact, one of the biggest advantages of the terminal server’s Redundant COM mode is that since during normal operation both LANs are live, when one of the LANs goes down the other LAN continues operating, and hence the “switching time” is zero.

Device Reliability

There are two things you can do to help ensure the reliability of the serial devices making up your serial-to-Ethernet network architecture. The first involves adding backup serial devices, and the second involves controlling data overflow.

Adding Backup Field Devices

Sometimes, in order to ensure stable operation of the device layer, backup serial devices need to be deployed. The COM Grouping function supported by Moxa’s NPort device servers allows you to skip the development time generally required to revise device settings and deploy new backup devices. With the COM Grouping function, you can keep existing settings and flexibly add backup devices to an existing network. For network devices that already have two built-in serial ports (e.g., intelligent electronic devices), COM Grouping allows you to create a COM Group for these 2 ports and redirect data from the COM Group to physical COM ports on the NPort device server.

Avoiding Data Overflow

When the data buffer on the serial devices receiving data is smaller than the data packet being transmitted, the traditional approach has been to use software flow control to manage the size of the data packets being transmitted to the device side. However, if you use traditional software flow control, you run the risk of losing data if transmission is interrupted before all the data reaches the serial devices. This is because software flow control is affected by whether or not the device kernel is busy.

By enabling the NPort device server’s UART to handle flow control directly, on-chip flow control can overcome the limitations of traditional software flow control. More specifically, on-chip flow control can send an Xoff command to the device server to promptly stop transmitting to allow for a sufficient and efficient lag time.

Additional Information

For additional information about this important topic, please download our Serial-to-Ethernet Q&A.

Back to index