I was introduced to a very nice gentleman about a year ago who was demonstrating some logic that created a .PNG file to demonstrate fault currents easily, and could be attached in-line as part of an email body. What was so interesting to me is that this all part of some logic that originated on an SEL RTAC using some of the functionality in one of the many IEC 61131-3 libraries that are maintained by myself and the other developers in the Automation Controllers Group.

Now, the trouble with what this gentleman shared with me, is the reliance on an external server to process the .CEV and COMTRADE files generated by monitored protective relays. That was all well and good, but I still wasn't quite satisfied since there was a certain amount of reliance on some other device. I wanted something better.

I suppose at this point, I should take a step back. For those who don't eat, sleep, and breath power systems engineering and electrical power system protection, an "event record" is something of a novel idea. So what the h-e-double-hockey-sticks is an "event record?"

I'm glad you've asked.

Well, a fault on a power system (like when you run into a power pole and it knocks down one of the wires - those are bad days) causes all sorts of "bad behavior" on the electrical system, and that bad behavior can be monitored and measured. It's what we use in the traditional sense to detect faults in the first place and make a decision to open an electrical breaker to shut off the power. Remember when you plugged in too many Christmas lights and the breaker popped? It's the same idea, just at a much higher degree of accuracy.

So "events" have certain behavior, and engineers are often interested in characterizing that behavior so that they can better understand not only what happened, but how it could be prevented going forward. Back when Dr. Ed Schweitzer first invented the SEL-21 protective relay (a conversation for another day), he added a very nifty little feature called "event recording." It added the ability to record information about the event when it occurred so that someone could go back and analyze it at a later time. These event records contain a lot of information, and they require special software to open them, to interpret them, etcetera. Here's an example of what an event record might look like. This was taken from a technical paper written titled "Numerical model framework of power quality events" by Rodney Tan and Vigna Ramachandaramurthy; the full paper's linked below, so take a look if you're so inclined!

Tan, Rodney & Ramachandaramurthy, Vigna K.. (2010). Numerical model framework of power quality events. 43. 30-47.

Soooo, the idea that this gentleman and his team had crafted was to extract the most interesting portion of the information and plug that into an image that could be made part of an email. This way, a technician could easily look at the image and quickly make decisions without having to load the full event record on a computer. This full analysis could still be done later, but having the image available in the email might give an engineer the ability to make quick decisions to help restore power to homes and families more quickly!

I've recently completed some research where I've been able to effectively create a simple RGB image in the Bitmap format (.BMP file) so that it can be used and interpreted by most any computer available today. And should certainly allow for direct inclusion in emails.

Ultimately, this means that there's a good chance that technicians could effectively see the report of an event without any advanced software, simply by opening their email client on their smart phone. Talk about convenience. I've been doing some development and testing and I found great value in this article from technical-recipes.com:

https://www.technical-recipes.com/2011/creating-bitmap-files-from-raw-pixel-data-in-c/

I hope that I'll be sharing more as I fully flesh out some design where I can effectively create plots in a byte-array that can be stored as an image.