Something is writing odd values to the SINUSOIDU PI tag on one of our test servers here in the office. What is the easiest way to track down the source?
Unfortunately, there is not currently an easy, out-of-the-box way of tracking a rogue data writer. With the upcoming release of PI Data Archive 2017 R2, there will be added methods for tracking data writes in a situation like this. Unfortunately, until then, there is no clear cut way to accomplish this if the data write is not buffered via PI Buffer Subsystem.
If the point is being written to via PI Buffer Subsytem, you can use piartool -bfs <id> -ptlist on the PI Server to see if the point is being buffered and identify the buffered source it is being written from. However, since SINUSOIDU is a built-in random tag coming from an interface local to the PI Data Archive, I doubt this will be the case, but still worth a try.
A few other things you could try:
1. Since this is a test server, likely there are not many connections being made to the server. Check PI SMT -> Operation -> Network Manager Statistics and see if there are any unexpected connections being made to the server. Obviously, interfaces would be expected, but are there any appnames or IP Addresses listed here that don't make sense?
2. Check message logs for any odd or out of place connection/disconnection messages. Likely, whatever is writing the values isn't doing so on a persistent connection, but might connect, write, then disconnect. Based on archive values for SINUSOIDU, find out if there is any pattern to the "odd" data writes
3. Check message logs for failed data writes to the tag. Perhaps a failed write event will be logged to the messages and from here the connection ID could be identified.
Hope this helps,
- Adam Fink
In addition to Adam's suggestions above...
Quick and dirty... (and possibly a touch of luck)
PI SMT -> Operation -> Network Manager Statistics > sort descending on "Last Call" column... you might have to refresh, immediately after a write and correlate the timing of a write with the Last Call... this should at least narrow the list of suspects.
Forensic's approach (from the mind of a madman)
Stop Random... just temporarily while you sleuth. (Service Display Name: PI Random Simulator (random) Interface X64)
Create a bogus group for the data security and assign to Sinusoidu... "locking everyone out"
Check the local logs at the time of the next expected/ frequency of a write for a [-10401] No Write Access - Secure Object
If no error found in the local message log, check for the above error at other remote connections identified at PI SMT -> Operation -> Network Manager Statistics
If no errors are found anywhere... perhaps the culprit is dependent on one of the tags associated with Random. If this is the case, start Random and check PI SMT -> Operation -> Update Manager for any snapshot signups for any of the simulator tags.
In any case, remember to start Random...
Random thoughts (ADHD's random contribution - pun intended)
Are the unexpected values also between 0-100? Maybe Sinusoidu was accidentally included in a pitopi instance.
Retrieving data ...