Cross Domain Applicability

[kdjones]

I'm not sure if an issue is the best place to address this idea but I thought I would steal a play from @StevenChisholm's playbook and post something that can evolve into a conversation since it is far too raw of an idea to just add as a section. I'll give the disclaimer that I am relying primarily on my intuition and only secondarily on my technical understanding of communication protocols. Here we go...

I've been thinking a lot about sttp since the genesis the project. My understanding of the value (beyond GEP, of course - I've loved GEP since 2013) was really only crystallized later on by three things:

1. Concepts captured in the openECA project that involve presenting the client nodes with structured data
2. The performant nature of the protocol even under conditions where you would normally see data loss or instability.
3. A survey of existing protocols across other domains resulted in a genuine need for us to build our own.

Here is what I derive from these three observations:

• Given that the implementer can present the data in any form desired while the transmission of the data is almost entirely unstructured means that from an infrastructure and applications perspective, there should be no limitations to the domain where this protocol can be utilized.
• The performance of GEP with synchrophasors at scale makes me think of other domains with the need to scale. Pick literally ANY infrastructure domain and you've now got an interesting data transmission and presentation problem.
• Because the survey of technologies resulted in nothing suitable for our use case, there is either no need (unlikely - other domains probably have their own C37.118 that "meets" current needs) or no existing solution in other domains as well.

So, what's my point? I believe that we will need to constantly challenge ourselves to think beyond the scope of our domain when specifying the design of this protocol. We should not limit ourselves to technologies that our domain is comfortable with (not a huge concern given that were shooting for a standard that anyone can implement any way they choose). We should not think of this as a way to make synchrophasor data transfer more efficient/secure/complete/pick-your-adjective (although it will be) because this is too niche compared to what I perceive as the complete value of the technology. We need to think of it as something much, much more foundational. We're setting the stage for much of the evolution that will take place in our domain and my guess is this is true in others as well. Lastly, we need to consider that in terms of success of adoption, there may be better champions for such a great technology than the synchrophasor community.

I certainly think that GPA has demonstrated this in their research of existing protocols and moving away from ASP (original project name) towards a more generic sttp branding. My suggestion is that we maintain this attitude as we move forward. Perhaps even engaging with some of the internet/oil/transportation/etc giants to tap into expertise and use cases. Selfishly, it would be pretty cool to have an excuse to collaborate with the Googles of the world and I certainly think this qualifies.

Ok, I know... SCOPE CREEP! My response to that is as follows: I don't think this changes the scope of the project at all. It changes only the scope of our perspective, perhaps refactors or rethinks design decisions that have to be made anyway, and changes the color of the ribbon we tie on the package when we are done. And so, it is certainly worth keeping a few neurons firing for as we continue.

Eager to hear thoughts and opinions, especially if I am completely off the mark here.

[StevenChisholm]

I have similar ideas for the protocol. I'd like the wire-line protocol to be fully user definable and flexible for virtually any use case. Then there would be a predefined "schema" for how synchrophasors plan on using the protocol so vendors will only have to obey this "schema" to interop with synchrophasor like technology.

I think the closest parallel would be XML. XML defines how data can be exchanged, but it leaves the schema up to the users.

However, we’ll still need to figure out how to keep the protocol extremely fast. I think it’s possible to exchange data at a rate of 5+ million measurements per second. This would allow OG&E to playback all synchrophasor measurements at a rate of 20 times realtime. (OG&E’s current system is about 250,000 measurements per second). The openHistorian’s wire-line protocol operates at about 15 million measurements per second, and I think GEP is somewhere around 3 million.

[kdjones]

Then there would be a predefined "schema" for how synchrophasors plan on using the protocol so vendors will only have to obey this "schema" to interop with synchrophasor like technology.

Agreed.

However, we’ll still need to figure out how to keep the protocol extremely fast.

Agreed. To me, speed is something worth having regardless of the domain for this protocol.