Communication protocols are a formalized way for data to be transmitted between devices. A protocol is a communication structure that allows two or more devices to send and receive information. In order for a device to communicate with another device, they must speak the same language, or "protocol," to be understood. Without protocols, data would be transmitted in a raw format, which is neither secure nor organized.
Common protocols used in SCADA:
Modbus and DNP3 are the two most common protocols used in solar PV SCADA systems.
Modbus has been around for over 40 years and is open source. This protocol is very widely used for automation components. About 80-90% of plant devices (inverters, trackers, etc) "speak" Modbus protocol, so it is important that your SCADA software and power plant controllers do too.
DNP3 (Distributed Network Protocol) is a newer protocol that has gained usage over the past 10-15 years. It has some additional features over Modbus, including a timestamp that lets you know exactly when and where data was received. It is primarily used to communicate between different substation devices. At Nor-Cal, we typically recommend DNP3 for critical devices like substation devices, and Modbus for the rest of the plant.
There are two additional common SCADA protocols, OPC-UA/DA and SEL. They are used for specific functions that we'll cover in a bit.
SCADA software, such as GE CIMPLICITY, Ignition and Kepware, runs from the SCADA server itself and initiates the communication protocols. SCADA software packages are loaded with communication drivers, including Modbus, DNP3, SNP, DH+, Modicon, Profi-Net(Bus), IEC 61850, and more. These drivers allow the SCADA software platform to communicate with and control (if applicable) all field devices.
If the SCADA software is unable to support communications to a particular field device, a protocol converter can be used. A protocol converter is an embedded device that acts as a translator between the device and the SCADA system. We often use the Red Lion protocol converter in our systems, which supports more than 300 protocols.
A (Remote Terminal Unit) RTU or Intelligent Electronic Device (IED) can also serve as a media converter. "Media" refers to the physical means of data transfer between two devices, such as serial or Ethernet (we'll cover those in a minute). A media converter allows two devices that aren't entirely compatible (due to different media types, speeds, operation types or modes) to communicate.
Standard protocols like Modbus and DNP3 can be linked to a SCADA system either over a network (TCP/IP) or via a serial link (a direct connection, not on the network).
A serial link is a physical electrical connection between two devices that allows them to communicate. RS-232 and RS-485 are two common examples.
The alternative is Ethernet or TCP/IP, in which two devices communicate over a network. They don't have to be directly physically connected to each other, but they do have to be connected to the same network. TCP/IP is a combination of two separate protocols: Transmission Control Protocol (TCP) and Internet Protocol (IP). The U.S. Department of Defense developed TCP/IP as a clear, universal standard that allows computers from different vendors to communicate.
Interoperability protocols like OPC-UA are typically used for secure Local Area Network (LAN) to Wide Area Network (WAN) connections, and have the ability to utilize security certificates. This allows you to connect systems of different types and manufacturers under one common umbrella. OPC-UA is typically used to connect the solar PV site's SCADA system to another cloud-based system over the Internet.
With Modbus, you have a device that asks for the data (the "master") and the device that provides it (the "slave"), which has a Modbus ID. There are different addresses that the asking device uses to request different data. For example, if you were looking for real power from an inverter, it could be at address 40001 with a data type of 16-bit signed integer.
The main advantage of Modbus is that it's easy to set up and get running quickly. You typically just need to know the Modbus ID and the Modbus address map for each device. The downside to Modbus is that it can be communication intensive. It requires that requests for data be sent out every second, or however often is desired for data resolution. That means a lot more traffic or serial traffic for the Modbus protocol compared to DNP3, which we will cover soon.
You need to make sure that your devices are configured properly and that there are no duplicate Modbus IDs. If you're requesting something on a network and two devices have the same ID, they might both try to respond at the same time. If that occurs, you won’t get any communication response.
For Modbus addressing, you need to be aware that there could be an offset between the devices. Using our example from above, real power from the inverter is at 40001. In an offset situation, the asking device has to ask for 40002 to actually receive the data for 40001. This is one of the most common troubleshooting issues we see with Modbus.
DNP3 is similar to Modbus in that it also has one device requesting data from another, but it's very different in terms of how it transmits data. With DNP3, the device has a DNP3 address instead of an ID. Instead of an address, you have what's called a DNP index or point. The DNP3 indices are split by data type and variation type.
Advantages of DNP3
DNP3, with its different data types and variations, has a lot more functionality than Modbus. It can support timestamps, for example, as well as event-based recording or event-based data transmissions. That means that instead of communicating once per second like Modbus, DNP3 can transmit data only when that value changes or when an event happens. It can put a timestamp on that data for when that value actually occurred.
This extra information makes it much easier to troubleshoot, and you can find out a lot more about the quality of the data. This is the main advantage of DNP3.
The main disadvantage is that DNP3 is more difficult to set up than Modbus. You have to know the DNP3 address, the DNP3 indices, and the variation type and whether it’s event based or not.
Like Modbus, you need to watch out for duplicate devices. There may be an offset in the DNP indices as well.
OPC is very different from Modbus and DNP3. At a high level, it is used more for communicating between SCADA systems. It doesn't use addresses like Modbus and DNP3, but instead uses tag-based or tag name-based, object-oriented communication.
When you are trying to connect two SCADA platforms, you can set up the OPC connection and scan, from one system to the other, all of the tag names from the system you're pulling from. These data tags can be mapped over easily; you just have to know the IP addresses between them.
The main advantage of OPC is that it's easy to set up a lot of tags in a very short amount of time versus Modbus and DNP3, where you have to address them all individually.
Another advantage of OPC is added security. You can set up the connection with a username and password. The data can also be encrypted. This is also possible with Modbus and DNP3, but with OPC it is built in.
There are two primary types of OPC: OPC-UA and OPC-DA. OPC-DA is the older version and not as widely used anymore. The set up of OPC DA is the main disadvantage of OPC (in general) and can be very difficult to set up because it uses certain types of Windows DCOM.
If you ever make changes on the machine that is sending the data, you have to manually go and make changes on the machine that's asking for that data. Data types and tag names do not dynamically update.
|
Modbus |
DNP3 |
|
Open Standard |
Open Standard |
|
Register oriented |
Object oriented |
|
Very efficient on per message basis |
Greater efficiency—static and event scanning |
|
16-bit registers—must use multiple registers for longer data types |
Object group and variation determine its use and capabilities |
|
Type of register determines how its used and whether it’s read only or writable |
Objects eliminate endianness |
|
No indication of point status means possibility of “stale” data looking valid |
Data points carry additional information about the point including on-line status and communication lost status |
|
Data translation must account for endianness in long data types |
Event data buffered in source device |
|
Inexpensive, simple and easy to implement, but lack of consistency in implementation is problematic |
Event scanning can reduce data payload and provide more efficient transfer |
|
Devices polled on registers are not data priority |
Data organized by "class" can be prioritized—critical data polled more often and noncritical less often |
|
Data time-stamped at host machine |
Data time-stamped at device under an event |
|
Programmer needs to add time sync, quality bits, time stamping at device |
Built in time sync, quality bits, time stamping |
|
Data stored in registers |
Data is stored based on data types |
|
Live data lost during communication outage—no way to know what’s happening. Can be programmed to store data using memory space. |
No loss of data if communication is temporarily lost. Events are buffered and reported once comms is restored. |
|
Out stations can forward data to master (unsolicited) |
|
|
Expensive, more complex to learn |
The Nor-Cal team is well-versed in all of these SCADA communication protocols, as well as all other major protocols that exist. Whether you need a new SCADA system for your solar PV site or assistance troubleshooting the one you have, we can help.
Schedule a call with us today.