In this issue of The Synchrophasor Report, Jeff Otto, an automation engineer, briefly explains the necessary configuration of the SEL RTAC for highly controllable synchrophasor network emulation.
Every day we see more and more ambitious power system asset owners asking, “How I can implement closed-loop control using synchrophasors?” Synchrophasor-based control schemes are migrating from their white-paper homeland into real power systems across the world, driving down commissioning costs while bolstering peace of mind. From oscillation mitigation to island detection, synchrophasor-based control schemes are becoming staples of the day-to-day operations of many utilities. In this issue of The Synchrophasor Report, we will talk about how the RTAC can act as a communications network emulation tool for testing your synchrophasor-based control schemes.
Network emulation is the process of simulating a non-ideal communications network by using specialized software and/or hardware. A network emulator does not typically generate network traffic of its own but rather sits between the source and receiver and alters the flow of packets passing through it. Network emulation is extremely useful not only for training purposes, but also as a tool for validating new technologies under realistic network conditions.
Numerous network emulation tools exist, ranging from free open-source tools to licensed software and dedicated network emulation hardware. Generic network emulators typically give the user control over packet latency, percent packet loss, percent packet jitter, and so on. These settings are often static, meaning they cannot be changed in real time. But what if an application calls for real-time control over the parameters of a network emulator?
I recently had an opportunity to work with a utility on a new and exciting synchrophasor-based control scheme. There was a pivotal point during the testing when we realized that real-world packet loss needed to be accounted for and that our idealized test network would need to be augmented accordingly. This was critical because the core algorithm was potentially sensitive to gaps in the incoming data stream. We discussed the possibility of inserting a robust network emulation tool between the relays and control system, but we ultimately decided that a custom-tailored emulation solution was required. This was because testing the worst-case scenario for our control system meant forcing a dropped packet at a critical time during the simulation (e.g., during a simulated fault). We required real-time control over the packet loss. This type of functionality is not available in generic network emulation tools, so we turned to the SEL RTAC.
The SEL RTAC has been a full-fledged phasor data concentrator (PDC) since the addition of IEEE C37.118 server capability in 2013. Although quite a bit different than SEL’s standalone hardware PDC (the SEL-3373 Station Phasor Data Concentrator), the SEL RTAC offers much greater versatility in how data can be processed.
Using these extended capabilities, we can program an SEL RTAC to effectively force packet loss in the synchrophasor stream passing through it. The number of lost packets per drop can be programmed. The packet drop event itself can be triggered algorithmically, manually from the settings software, or even remotely from another device!
Note that additional network emulation functions, such as network latency or packet reordering, are possible with the SEL RTAC, but are beyond the scope of this article.
In order to force dropped synchrophasor packets from the RTAC IEEE C37.118 server, basic functions need to be configured and manipulated. With the powerful SEL RTAC logic engine you can incorporate as much control and complexity as desired.
To generate synchrophasor packet loss, we must first configure the SEL RTAC to forward synchrophasor data from a C37.118 client to a C37.118 server. When operating in nonstreaming mode, the C37.118 server only sends out a new synchrophasor packet when updated synchrophasor data are available within the logic engine. Therefore, we can trigger packet loss by temporarily inhibiting the insertion of new synchrophasor data into the logic engine.
First, set up a one-to-one mapping of the C37.118 client to the C37.118 server by following these steps:
See an SEL RTAC instruction manual for additional information on C37.118 client/server configuration.
In order to inhibit tag updates at the C37.118 server, the insertion of synchrophasor data into the logic engine must first be blocked. Accomplishing this is a simple matter of manipulating a control bit on the C37.118 client program organization unit (POU) called Disable_Tag_Updates. Locate this control bit on the Controller tab of the C37.118 client while in online mode. Next I will show you how simple it is to manipulate this bit in real time.
Fig. 1 demonstrates how to manually force the state of the Disable_Tag_Updates pin to TRUE while in online mode with acSELerator RTAC. First, left-click the associated cell of the Prepared value column until the desired Boolean state is displayed. Press F6 to force the new state.
Fig.1. Force the Disable_Tag_Updates pin by pressing F6. Press Shift+F6 to release the force.
As a test, force the pin to TRUE while watching the real-time status of the external C37.118 client communications. Note that once this pin has been forced, no packets are received at the C37.118 client. Release the force on the pin by pressing Shift+F6, and notice that packet transmission resumes. We can achieve more precise control over the tag disable period by using an algorithm to control the Disable_Tag_Updates pin.
For the utility application discussed earlier, we created a function block in the RTAC logic engine that triggered upon a digital status bit assertion from the connected PMU. Once triggered, the function block forced the Disable_Tag_Updates pin to be true for a handful of task cycles. This allowed very targeted packet loss and became a key testing tool for the project.
As synchrophasor applications continue to edge further into the realm of control, the SEL RTAC will continue to be a multifaceted synchrophasor processor for both the lab and the field.
|?||Show / hide this help menu|