The only way to talk to a COSI-CT Management Processor was the COSI-CT Control Panel program in MS-Windows. It knows the structure of the EEPROM parameter storage in the Management Processor, and interprets it accordingly – for instance, if a single byte value is used, it shows it as an integer 0-255, if it’s a string, it shows as a form fill with fixed length, etc. There is a mode that allows it to write to not-defined areas too… but it is clunky. And, to boot, it’s all in decimal, argh. As I’ve said, if it’s a bit mapped value, give it to me in hexadecimal, don’t make me convert it!
Anyways, COSI-CT Control Panel has access to some control flags that indicate whether the parameters of the COSI-CT are under seal – that is, some of the values cannot be changed, probably because they would alter calibration and therefore current values, which dictate revenue to the power company. When the seal is set, Control Panel will not let you even try to modify these settings. That’s great for end users, but for testing, I can’t tell whether the seal is actually working.
For some projects, the seal is more important, than for others. For instance, if you are just doing general disturbance recording or relaying, there’s no reason for anyone to mess with the calibration, so it’s not as important. However, if it’s on a utility-to-utility intertie, or a generator output, then it might be very important.
We had an instance where it was very important, and needed to know that the seal was working properly. Actually, let my rephrase that – we had a corner case that seemed to indicate that the seal was not working completely correctly. So, I had to correct that issue. But, I couldn’t test it!
The serial line protocol to the Management Processor is well documented, but of course, having the source code of the processor itself was very helpful. There are always ambiguities in protocol specifications, unless you happen to give the specification to someone completely in the dark, and have them develop a device to talk that protocol. Well, this was just such a case… but again, I had the source code.
So, I wrote a program in ‘C’ for LINUX to talk to the Management Processor. It wasn’t intended to replace Control Panel, by any stretch, but it ended up expanding and expanding and expanding (as many of my utilities do), so it can run a “write challenge” against every value, to see if it can be modified under seal, can read all values from the device, write individual or all values into the device, and read every real-time value supported. In fact, I expanded it to support every command on the serial link to the Management Processor.
This was quite useful in determining whether the seal had previously been implemented correctly (hint: there were bugs), and to figure out if it was corrected, but also in talking to devices over TCP/IP – like when units were installed at the SRP Perkins substation, and I was talking over a haltingly slow SSH tunnel link. Control Panel would burp, retry, and give up, but, having complete control over the link, I was able to make the connection, lengthen retries, or whatever it took, to make the connection with my command line program, I was able to arrange to get the data back reliably.
In early development, I cross-compiled the code to run from Cygwin in MS-Windows, but the serial port names in MS-Windows tripped it up. I’m pretty sure it would take little to re-port it to MS-Windows.
I advised management of the program, and chatted with Scott Picker (maintainer of COSI-CT Control Panel) that he might want to use it for a test facility, and I gave them the source code, of course, but as far as I’m aware, nothing ever came of it… sigh.