For utilities, SCADA is the undisputed champion and the data it collects is of paramount importance. (After all, the last two letters stand for “Data Acquisition”.) In the SCADA world, standards for controls and data acquisition is not just requested, it’s an expectation.
Luckily in the Distribution Automation (DA) world, we have standards that ensure immense interoperability between vendors and utilities—it’s IEEE1815. This standard, more commonly known as Distributed Network Protocol or DNP3, has been around since the 1970s. According to DNP.org, the protocol technical committee, and Triangle Microworks, a DNP3 protocol vendor, 88% of DA electric in the United States is DNP3 compliant.
Methods for Acquiring Data
Under the DNP3 protocol framework, there are two methods for acquiring data: unsolicited and solicited. For the purpose of this discussion, let’s consider a specific type of data—Events. Arguably, this is the most important data because it illustrates what happened on a utility’s system and when it occurred. Under DNP3 protocol, events can be timestamped. Additionally, in most modern Intelligent Electronic Devices (IEDs), there is often a history available for download known as a “Sequence of Events” log.
Since this data is part of a utility’s critical infrastructure, most utilities are acquiring it by using intelligent licensed communication networks. (If you aren’t, you should. Each site visit costs you money. Not to mention using an unlicensed network is a security threat.)
Solicited Data Acquisition
In SCADA and DNP3, there is the concept of a “Master” and an “Outstation”. As the parent of two crazy little boys, I’ll use a familial analogy to describe this approach. In this case, the parent is the “Master” and a child is the “Outstation”. In some more regimented parent-child relationships, the child isn’t allowed to speak unless spoken to. The previous relationship dynamic illustrates solicited data acquisition very well.
An example of this might be:
Continuing with this train of thought:
This is known as solicited. That is, the “Master” specifically polls the “Outstation” for data and it returns timestamped data of critical events that occurred since the last time query.
Unsolicited Data Acquisition
Now, and much more applicable in my life, we’ll look at unsolicited data acquisition. My children speak without prompting (whether I like it or not). I do not specifically ask for their feedback, but often receive unsolicited responses.
Let me set the scene. When I walk in the front door and before I can even say “hello”, my son jumps up with a running monologue…
Although the parent “Master” is still in charge, the child “Outstation” has the freedom to speak without specific prompting. I accept this as unsolicited data. This approach has many advantages, but it also can result in a lot of information that can be seen as noise.
So, which camp are you?
There is no wrong answer, both are completely acceptable, configurable, and in mass use in the industry. From my experience, most utilities reside in the solicited camp. The key is to look at your processes and align and configure to your needs.
For example, if low latency is important to your utility, then unsolicited might be the answer. It usually is faster as the DNP3 Master does not need to poll for this data. However, if you go unsolicited, be careful. Field personnel programming IEDs for event reporting need to be extremely competent. There’s a large amount of data that will go over your network and that can cause problems if the programming/deadbands are tight on Analog Values. In some cases, it may even create buffer overflows in the protocol.
Regardless of what camp you are in, make sure your IEDs and SCADA system is configured in such a way to utilize the “Event Timestamp”. If done properly, you can essentially get your “Sequence of Events” data from your field devices to your SCADA system and save yourself site visits!
So, which camp are you?