By Wenyuan Niu, Moxa Americas
Figuring out which solution best fits a network’s architecture can be a daunting task for system integrators (SIs) who are upgrading communications. Most often, SIs lack sufficient knowledge of protocols, complicating the task even further.
A frequently asked question by SIs is: “How can we simplify protocol conversion to ensure seamless operations in automation?” This question is particularly relevant for SIs who want to upgrade communications supported by Distributed Network Protocol (DNP3). Many SIs are further frustrated by the absence of sufficient built-in mechanisms to pinpoint where, as well as why, network communications break down, adding to the urgency of finding a reliable solution.
In the age of the Industrial Internet of Things (IIoT), protocol conversion is key to connecting legacy and multivendor devices to networks. SIs often consider device servers, protocol gateways or embedded computers for connecting their serial devices to Ethernet-based networks. But, due to their unfamiliarity with the variety of protocols currently in use, SIs often are at a loss to know which option is best suited for their network. In this article, we look at the various options available to upgrade serial-based DNP3 devices to Ethernet-based networks and expand on some of the key issues that must be considered beforehand.
DNP3 Background and Benefits
Standardized in 1993, DNP3 is a protocol designed for remote telemetry and is mainly used in power industry applications. In pre-DNP3 days, devices used by the power industry, such as remote terminal units (RTUs) and intelligent electronic devices (IEDs), could use only a serial interface to communicate. These devices connected with a local human machine interface (HMI) for local monitoring and control, either through an RS-232 or RS-485 interface, and connected with the control center to give engineers the ability to remotely monitor and control the substation and power distribution status.
To transmit data over longer distances, engineers usually used a modem connected to the public switched telephone network (PTSN) for wired communication, or a radio for wireless communication. The serial devices connected through the serial port on the dial-up modem or radio in the power station, which transmitted data to a modem or radio in the control center. The data was then transferred to the SCADA system in the control center. The transmission speed for this kind of setup was relatively slow, and the cost to transmit data through a modem was high.
The introduction of DNP3 as a communication protocol brought several welcome changes. First, the cost of data transmissions dropped significantly. DNP3 is designed to transmit unsolicited responses from slave devices to a SCADA system, and consequently does not necessarily require a SCADA system to send frequent requests to field devices. This ultimately leads to lower bandwidth consumption and reduced cost.
Second, data is no longer lost when modems unexpectedly disconnected. With DNP3, a buffer zone can serve as a temporary data storage location in case of an interruption. When communication resumes, the data stored in the buffer zone can easily be retrieved by the remote control center.
Third, DNP3 supports time-stamped data records. Along with the time-synchronization function, events can be easily identified through a time sequence, as all control centers use the same time reference when data is sent back from edge devices.
In addition to substation and distributed automation applications, DNP3 is widely used in the water processing, waste water and oil and gas industries in North America, Australia, New Zealand and some Asian countries.
The Easiest Way to Bring DNP3 Serial Devices to Ethernet-based Networks
During the rapid development of network communication technology, many communication media have transitioned to Ethernet. On the master side of SCADA systems, an Ethernet interface, with integrated native Ethernet-based DNP3 drivers, is now commonplace. On the slave side, nothing much has changed. The existing DNP3 outstations (slaves) continue to operate because transforming such systems can be expensive. For this reason, engineers are under constant pressure to find more budget-friendly solutions to enable serial-based DNP3 devices to connect with an Ethernet-based DNP3 master (see Table 1).
The first solution that comes to mind is device servers. With device servers, raw socket mode allows the physical conversion from a serial interface to an Ethernet interface for serial protocols. The Ethernet-based DNP3 protocol includes the standard TCP/IP header and DNP3 serial frame, which is also referred to as DNP3 over TCP/IP. Coincidentally, by using serial tunneling technology, device servers can add serial-based protocol frames into standard TCP/IP packets to handle protocol conversion between DNP3-serial packets and DNP3-over-TCP/IP packets.
When a system is upgraded-even though the system’s serial and legacy hardware are migrated to Ethernet-based networks-the old utility software often is still being used, making it necessary to enable the device servers’ virtual component object model (COM) technology. The challenge, however, is that SIs may have to deal with different operating systems, which means the device servers must support a different driver for each operating system. Even though this technology can support the basic requirements needed to execute serial-to-Ethernet tunneling, data that passes through device servers cannot be monitored, making it difficult to identify the root cause of an abnormality during data transmissions.
Monitoring Protocol Conversion
Users who are looking for a more accurate means of monitoring protocol data transmissions to identify disruptions and abnormalities can use a protocol gateway. Protocol gateways not only convert serial-based DNP3 data packets into Ethernet-based packets, they also monitor and record these data packets through a tool built into the web console. The tool also supports debugging and maintenance functions. In addition, users can view the raw data and its routing direction, considerably reducing the commissioning time and debugging process when the system is in operation.
The Need for Cross Conversion
In the era of smart grids and the IIoT, a smart system, particularly in power automation and process automation industries, must integrate a variety of networks. As more smart sensors and devices are added to a network, and more data is collected, it is highly likely that many different protocols must be integrated. Modbus, the most widely used communication protocol in industrial applications, is perhaps the most common protocol required to be integrated into a DNP3-supported network.
Two methods can be used to integrate these different communication protocols. The first method employs embedded computers, enabling engineers to write and compile software for specific purposes to fulfill customization demands. Such solutions, though, require that the engineers have a comprehensive knowledge of protocols. The second method relies on protocol gateways, featuring plug-and-play integration of configured interfaces for Modbus and DNP3 protocols. With a protocol gateway, users only need to set up the corresponding Modbus commands, DNP3 commands and the memory exchange configuration; data exchange between the different protocols can be easily implemented once the system is configured. The only drawback is that the protocol gateway solution is preconfigured, meaning it lacks flexibility when adding new functions.
Data Concentration
As automation systems become more integrated, SCADA systems need to monitor more devices and handle significantly larger amounts of data traffic. Normally, in a multi-layered architecture, a data concentrator collects data from low-layer devices and sends it to the SCADA system at regular intervals. The advantage of using a data concentrator is that the SCADA system does not need to manage all the devices in the field directly, because it needs to communicate with only the data concentrator. Funneling data through the data concentrator dramatically reduces communication frequency, and ultimately decreases network traffic and the SCADA system’s workload.
Embedded computers can play the role of data concentrator. If users have proper programming ability, embedded computers can be used to not only collect, but also analyze and filter data, allowing only processed data to be sent to the SCADA system.
Embedded computers, however, are not the best option when programming skill is lacking or for systems that need to be implemented in a hurry. In these scenarios, a better option is to use protocol gateways that support agent mode, which actively and continuously retrieves data from connected devices. The updated data is stored in the gateway’s internal memory, and the SCADA system can retrieve this data directly from the gateway’s memory.
A variety of products that meet the requirements for upgrading DNP3-supported applications and ensure easier remote/telemetry communications are available. Mona’s NPort products easily convert serial-based DNP3 packets into Ethernet-based DNP3 packets, meeting various serial tunneling requirements. In addition, MGate 5109 gateways facilitate heterogeneous network conversion with a pre-configured user interface for DNP3 and Modbus. Furthermore, built-in diagnostic tools can be used to monitor the network status and raw data received by the protocols, easily fulfilling the requirements for debugging and system maintenance. UC-8100 embedded computers use the Cortex-A8 RISC processor for a useful computing platform, providing various communication interfaces, including serial, Ethernet and cellular, for different development requirements.
Wenyuan Niu is the industrial Ethernet gateway product marketing manager for Moxa Americas. He has 10 years of experience in industrial networking and computing, working directly with customers in Asia, Europe and the Americas. He has been involved with major deployments, including energy monitoring.
