Sensor-simulator published data with aggregation

[garydblack]

Screen capture of voltage magnitude plot of sensor-simulator output on 13-node model with the default 30-second aggregation and the "Simulate-all" checkbox selected for the sensor-simulator configuration. This plot was created by the State-Plotter application.

The sensor-simulator values appear to be error-free between the aggregation intervals and are being published for every simulation timestamp. Tom termed this behavior as "adjusting back to true underlying values". See the mrid represented by the brown live just above 1.08 p.u. in the plot. The expected behavior is no data being published between the aggregation intervals. Additionally, we are not observing any dropouts of measurements when the configuration specifies a 5% dropout rate. Behavior with a zero value for aggregation interval is as expected except for lack of dropouts.

The reproduce the error configure sensor-simulator with "Simulate-all" selected, but all other configuration parameters at default values. This will publish sensor data as described above for any model, although the plot above is for 13-node ieee13nodecktassets. The plot above was created by running both the state-estimator and state-plotter from the command line. The platform viz hopefully also has the means of plotting sensor-simulator output to more easily display the published data.

[garydblack]

Here is an update to this issue after updating the state-plotter application to deal with sporadic data like the sensor-simulator now produces:

Take a look at the screen capture below. What this data represents is every bus,phase pair (35 of them, just like the simulator outputs) for the ieee13nodecktassets model with the series of timestamps (the offset of time from when the plotter was first started) when the data arrives at the node for 180 seconds. I started my plotting app right near the beginning of the simulation, but given the overhead time of the plotter that means there were a small number of sensor service messages that were missed. This really should have no impact though in this exercise. I left aggregation at the default 30 seconds, but set the drop-out rate from the default 0.05 down to 0 so we could ignore the effects of missing values.

A good number of the nodes have what would seem to be the correct 30 second interval between when data is sent, but many don’t as well. Here’s all the ones that are right on 30 second intervals, 22 of them:

Here’s all the ones that aren’t on single 30 second intervals, 13 of them:

Now there are definitely fixed patterns in these ones not on the “30-second plan”. For instance:

• 645,B 675,B 675,C alternate between 12 and 18 seconds so they do always output data at 30 second intervals, but with the 12-second intermediate output thrown in • 670,B does the opposite with an 18 second interval followed by a 12 second interval to arrive at 30 seconds total as well • 692,C and 670,A are a 6-second interval followed by a 24 also making 30 total • 652,A is 21 seconds followed by 9 seconds • 611,C is 2 15-second intervals to make 30

All 13 of these nodes not on the "30-second plan" are some variation that does always add up to 30 seconds and here’s the full breakdown:

• Nodes with a 12 sec then 18 sec interval: 645,B 675,B 675,C 646,B 670,C
• Nodes with a 18 sec then 12 sec interval: 670,B
• Nodes with a 6 sec then a 24 sec interval: 692,C 670,A 671,B • Nodes with a 21 sec then a 9 sec interval: 652,A
• Nodes with a 15 sec then a 15 sec interval: 611,C
• Nodes with a 3 sec then a 27 sec interval: 671,C • Nodes with a 9 sec then a 21 sec interval: 675,A

So, is this the intended and justified behavior for how aggregation works? I expect not. If you want me to do anything further to produce more data like with an aggregation period other than 30 or running other models, I could do that. But, I suspect this is enough to make an initial determination. One other good sign is that sensor-simulator is no longer just passing through the simulation measurement values like it was before except for those timestamps, depending on the aggregation period, when it introduced some random noise.

[garydblack]

Here is another update after some further testing as requested by Craig related to sensor-simulator dropping data rather than the aggregation period. Note that both this update and the last one were sent in emails on Oct 22:

Here are the results from testing the drop-rate configuration parameter as you suggested. I tweaked my debugging/logging code for the state-plotter application to give a total number of dropped values over a 180-second run. Again, this is the ieee13nodecktassets model with a sensor aggregation value of 0. So that would be 60 sensor messages with 35 nodes each for a total of 2,100 data points so you’d expect 10% drop-rate to produce 210 missing values. Note also the UI won’t let me exceed a 10% drop-rate so I tested 5% and 10% instead of the 20% you suggested (maybe the UI should allow in the 20 or 25% range of dropped data just for testing applications for robustness even if real-world would never be that high?). Note also I’m only considering missing magnitude data, not angle data for these tests.

For drop-rate of 0.10, I got 212 missing total values over all nodes and measurement or 10.1%

For drop-rate of 0.05, I got 113 missing or 5.4%

Because the 5% value was a bit high, I ran it a couple more times and got: • 117 missing or 5.6% • 117 missing • 117 missing

Finally, because all the 5% values were consistent and a bit high, I wanted to try 10% again and got: • 212 missing or 10.1% • 212 missing

So lots of consistency. Not sure why I got some outliers. All the results are a bit over the configured drop-rate values, but I suspect it’s not worth investigating if the concern isn’t absolute correctness.

There are a couple other issues though related to nature of how data is or should be dropped that Andy and I have found that may be worth further consideration:

1. When sensor-simulator drops data, the method for doing so is that the value (magnitude or angle) is missing from the JSON message, but the measurement mrid or node is still there in the message. Andy believes in the real world this isn’t likely if it would happen at all and what would be expected is that the measurement mrid or node itself would be missing.

2. When there is a missing value (magnitude again is what I’ve been looking at, but assume it holds for angle as well) for a measurement mrid or node, quite often that measurement mrid will be repeated in the JSON message and the second time there will be the value. I know the state-plotter accommodates this and hopefully the state-estimator does as well (haven’t checked that), but it’s something to consider regarding whether this is a reasonable thing to do. Would we ever want a mmrid/node to occur more than once in a message? I’m not sure what Andy’s preference would be, but I know he thought this was a bit odd when I brought it up (I discovered it because my diagnostic logging while plotting was saying there were more than 35 mmrids for a message quite often and it was because of the duplicate mmrids in a message). I suspect there is never a duplicate mmrid both with a magnitude/angle value, but haven’t investigated this as my state-plotter code ignores any mmrids after it gets the value it is looking for.