By KS Hsu and Edward Lin
Figuring out which solution fits a network’s architecture best can be a daunting task for system integrators (SIs) when it comes to upgrading communications. Most often, SIs lack sufficient knowledge of protocols, complicating the task at hand even further. Not surprisingly, 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 the 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, because of their unfamiliarity with the variety of protocols currently in use, SIs are often at a loss to know which option is best suited for their network. This article will discuss the various options available to upgrade serial-based DNP3 devices to Ethernet-based networks and expand on some of the key issues that need to be considered beforehand.
DNP3 Background and Benefits
Standardized in 1993, DNP3 is a protocol designed for remote telemetry; it 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 only use 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 interface or through an 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 a number of 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-ultimately leading to lower bandwidth consumption and reduced cost. Second, data would no longer be 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 could 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 because 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 also 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) are still kept in operation 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.
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 is often still being used, making it necessary to enable the device servers’ virtual COM technology. The challenge, however, is that SIs may have to deal with different operating systems, which means the device servers need to 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 in to 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.
When Cross Conversion is Needed
In the era of smart grids and the IIoT, a smart system, particularly in the power automation and process automation industries, needs to integrate a variety of networks. As more smart sensors and devices are added to a network, and more data is collected, it is likely that a large number of different protocols would need to be integrated. Modbus, the most widely used communication protocol in industrial applications, is perhaps the most common protocol that will need to be integrated into a DNP3-supported network.
|TABLE 1: A comparison of the technologies the different solutions rely on to facilitate the different protocol conversions.|
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 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 pre-configured, meaning it lacks flexibility when new functions need to be added.
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 so-called 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 of the devices in the field directly because it only needs to communicate with the data concentrator. Funneling data through the data concentrator greatly reduces the frequency of communications, and ultimately decreases network traffic and the SCADA system’s workload.
Embedded computers can easily play the role of data concentrator. If users have the ability to do the programming, embedded computers can be programmed to collect, analyze and filter data so the SCADA system deals with usable data that has been properly processed.
Embedded computers, however, are not the best option when the requisite programming skill is lacking-or for systems that quickly need to be implemented. In these types of 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.
Moxa offers a variety of products that meet the requirements for upgrading DNP3-supported applications, ensuring easier remote/telemetry communications. Moxa’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 computing platform, providing various communication interfaces, including serial, Ethernet and cellular for different development requirements.