sttp / Specification

STTP Specification and Related Documentation
MIT License
9 stars 3 forks source link

Cross Domain Applicability #2

Open kdjones opened 7 years ago

kdjones commented 7 years ago

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:

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 commented 7 years ago

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 commented 7 years ago

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.