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?
Grid Modernization: The Grid Edge
A balancing act: communication architecture and the grid edge
Download the Viewpoint
Great writeup. I believe ‘There’s a large amount of data that will go over your network and that can cause problems if the programming/deadbands are NOT tight on Analog Values.’
I believe there are situations where both are correct. Unsolicited data is great for creating tables to use for graphing etc. Solicited data is great for “report by exception” occurrences where a change in state results in a critical notification. 1 example is with the old TVM’s that Telemetric had. If a voltage hit a threshold, then an unsolicited message (alarm) with critical information gets transmitted, but an unsolicited message at midnight with hourly data was fine for all other conditions, allowing a user to review history without having to “ping” the device.
You bring up a sound point that I did not mention – interval or time based reporting. That is, there is a slight difference between a report by exception, unsolicited response, and some static interval to report regardless of change. The first two are exceptionally subtle when used with data concentration in the architecture. In the example you mentioned, a change in voltage above a particular level triggered a data concentration asset to trigger/report and notify the upstream players (like SCADA). However, in the case of a true unsolicited model, any event, that is a class 1, 2, or 3 event (DNP object 60 variation 2,3 or 4) is passed up and sent to the upstream players (like SCADA) whether anyone asked or not. That is, consider every .01 volt change a class 2 analog event… the systems would get pretty “chatty”. If not configured properly, unsolicited data may cause undue load onto upstream networks and systems. In all cases, configuration is key to get the right data to the right person at the right time in the most optimal way.
Es necesario programar un mix, donde se pregunte por los eventos pero donde también surjan alarmas de eventos críticos desde el Punto de trabajo al scada
Google translation: It is necessary to program a mix, where you ask about the events but where there are also alarms of critical events from the work point to scada
Fabián,
That’s a great point! While there are fundamental differences between unsolicited and solicited, in a lot of cases, a mixture is optimal for SCADA. Getting the appropriate data to make an operational or engineering decision is paramount. Moreover, there are cases where some application types, such as reclosers, may have more unsolicited data than other application types (such as capacitor controls). Especially when you couple advanced grid operational behavior like FLISR- Fault Location Isolation Service Restoration. Those micro changes and sequence of events traffic is often times critical for SCADA to make centralized decisions. Thanks for the response!