Using PMUSimulator for PDC Testing.
Currently, there are not readily available ways to test the operation of PDCs. The problem is that it is nearly impossible to have enough PMUs to max out the PDC and you can't cause a real PMU to operate incorrectly to test the response of a PDC. Even most
manufacturers don't have programmable PMUSimulators, so iPDC's PMUSimulator allows anyone to test PDCs. I wrote my thesis on using PMUSimulator to test PDCs, with fairly good results. Here is a link to it, it's all open. http://scholar.lib.vt.edu/theses/available/etd-05012012-085423/
There are three tests that were developed for PDC testing using PMUSimulator.
First, PDC processing latency. You can use Wireshark to capture the departure and arrival times of PMU and PDC packets and determine the time the PDC needs to process the data. When doing this testing, I noticed that some commercial PMUs sent their data
frames at the same time but PMUSimulator didn't. So I made PMUSimulator send at specific points in time so that all instances of PMUSimulator would send data with corresponding timestamps at the same time. This way, the PDC would receive all PMU data at the
same time. PMUSimulator allows you to use however many PMUs you need to max out the inputs to a given PDC.
Second, Wait Time testing.
PDCs have a programmable wait time so that a PDC will wait a given amount of time on late PMU data. With commercial PMUs it is impossible to test this wait time. With PMUSimulator, in the ServerFunction.c file under the "udp_send_data" section you
can add a "usleep" command after the data frame is generated and before it is sent to simulate a late data frame. This way you can send the late data to a PDC and determine how the PDC responds.
Third, Bad Data Frame Checksum.
The last test was to send bad data to a PDC and verify that the PDC zeroes the data. Also, in the "ServerFunction.c" file when the data frame is computed, you can change the number of shift bits from 8 to anything else and a bad data frame will be
generated. You can also add an if statement to only generate bad data once or twice per second as that's probably how it would occur in operation. I found that one of the PDCs we had in the lab did not zero the output PDC data but sent no PDC output at all
which is not correct.
I am not a good programmer so I was never able to change any of the GUI functions to make PDC testing simpler. To conclude, this software has enormous potential in the area of PDC testing and should be developed further by anyone interested in PDC testing.
Thanks to the makers of this software.
May 30, 2012 at 4:45 PM
Thanks for letting us know about PMU Simulator usage and real world working scenarios. And we are also glade that Simulator helped in terms of completing your tasks.
We also want to thanking to you in terms of your continuous help regarding improving the PMUSimulator & iPDC software.
I am thinking of adding some of new features like as you have mentioned in your three test cases. You went through the programming stuff and modified in the coding manually, instead of that we can provide such features by clicking the buttons. That would
be more appropriate!
Currently the PMU Simulator acting as a server but can only be connect to one PDC at a time. The problem is I have used some of global and local variables to do that. Instead of variables I am thinking of taking data structure (link list) for every newly
connected PDC and run the separate thread to handle the peer communication with PDC. I have already started working on this and may be shortly we will released it.
I am also thinking of changing the GUI for iPDC & PMU Simulator from GTK+ to JAVA (using JNI). First Java have rich library compare to GTK+ and I also have some Java-swing coding experience, that will help. Secondly with java it would be easy to make
the iPDC software suite portable for Windows OS.
I hope you will be continuing with iPDC project and its development in the future.
Once again thank you. Keep in touch.