[Smartgrid] Please review and comment: Applicability of SIP in smartgrid ecosystem

Mon Nov 23 17:17:03 EST 2009

Okay, I can understand what RTP would be doing here. I also agree that SIP
is a very weak case just for this (it would work, of course).

I'll look forward to your diagram. To answer your question, no, the diagram
is not focussed on only AMI and DR. IT basically is the same NIST conceptual
SG diagram in page 25 of
http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf
It may be needed to draw some more blocks within the SS Automation rectangle
to show what you are doing.

regds
arjun

On Mon, Nov 23, 2009 at 5:03 PM, D. Jeff Dionne <jeff at anifirmware.com>wrote:

>
> On Nov 23, 2009, at 4:28 PM, Arjun Roychowdhury wrote:
>
> Jeff:
>
> a) On the diagram - would it be possible for you to modify it to represent
> your current work? (You can sketch on top and email me a copy - I can
> integrate it into the master copy)
>
>
> Arjun,
>
> Is your diagram focused on AMR/AMI and Demand Response?  If so, perhaps our
> use case
> confuses the issue, and needs to be separated out...  Let me see what I can
> come up with.
>
> b) I am assuming that while the measurement requirement for syncrophasors
> are in microseconds, the reporting of them may be more spaced out? -
>
>
> There are of course 3 requirements:
>
> Absolute time accuracy.  Measured against GPS or IRIG-B to facilitate
> synchronization of phase
> angles (as per C37.118) and in going forward while SIP/RTP shines,
> synchronized sampling.
> There is no reason RTP with a normal (in telephony terms) ptime cannot be
> used here.  Time
> stamps as I mentioned are all that is necessary.
>
> Periodicity of measurement.  Phasor readings are meaningful on a 16.667 or
> 20.000mS basis
> and really no more frequent, depending on system frequency.  These readings
> as per C37.118
> are just one point on the spectrum (the fundamental), and is the scope of
> that standard.  We can
> do better, with harmonics (the rest of the spectrum) and time domain
> information, but at worst
> it can be packaged on this same cycle by cycle basis.
>
> Latency.  We are _not_ aiming for Power System Protection.  The best we can
> do is supplement
> the standards in that space because we will be at best 2 cycles behind and
> network latency is
> not going to let us get even close to that (likely a few 10s of cycles).
>  This is still very useful for
> equipment analytics and certainly for monitoring the flow of power in the
> grid on both a local
> and system wide scale.
>
> what sort of reporting intervals are we talking about where you are
> planning to use SIP/RTP ? Can you also speak to some of the advantages that
> RTP brings in?
>
>
> We're not talking "readings" here.  This is for transport of phasor data
> and waveforms (oscillography)
> in real time.  SIP with a payload in the body (as we are doing now in
> another project) will not work,
> RTP is necessary.  C37.118 talks about using it's framing directly over TCP
> and UDP, but this the
> wrong approach.  C37.118 should be an RTP profile, and the session
> establishment can be done
> with SIP (it has very weak session functionality, which is not much more
> than RTCP might give).
> That would get us a foot-in-the-door.  Then layering on a Power System
> CODEC as a sort of C37.118
> superset gives you the rest.
>
> J.
>
>
> regds
> arjun
>
>
> On Mon, Nov 23, 2009 at 4:22 PM, D. Jeff Dionne <jeff at anifirmware.com>wrote:
>
>> Shidan,
>>
>> Thanks for copying me on this.
>>
>> I think there is a compelling use case for SIP in T&D metering/monitoring.
>>  This doesn't seem
>> to be represented in the diagram.  Actually, this is really the only SIP
>> use case that has all the
>> components and call flows that SIP provides in Telephony.  I think it's
>> quite compelling, and
>> C37.118 doesn't offer what is necessary at all.
>>
>> The idea is that the utility and/or industrial customers would build a SIP
>> enabled network of
>> SyncroPhasor / PQMs that will give a real time view of the power system.
>>  2 additional
>> components are necessary: A CODEC for power waveforms (working on it...)
>> and a
>> global time representation mapping onto the RTP timestamp.  Perhaps it
>> will have to
>> be used as an offset from a session start time, keeping in mind that the
>> sample rate
>> needs to be variable for transient capture when things suddenly get
>> microsecond scale...
>> I've heard people say latency or RTP time accuracy will be a problem, but
>> this is not the
>> case, actually.
>>
>> J.
>>
>> On Nov 23, 2009, at 3:57 PM, Shidan Gouran wrote:
>>
>> Looks good and on the mark overall. I would add a SIP session icon  to the
>> SS LAN Transmission box as well.
>>
>> The idea behind that is that Synchrophasors will send RTP streams of power
>> signals back to operations for analytics. RTP makes a compelling alternative
>> to C37.94. It would lead to cheaper nodes and much richer analytics. I have
>> CCed Jeff who is actually developing Synchrophasors with this type of rich
>> functionality. This is also something that some UCAIUG members I have spoken
>> with have explored.
>>
>> It's needless to say why not reinventing the wheel for session management
>> would be desirable in this scenario.
>>
>> BTW, in our openADR call, we were encouraged to join the NIST DEWGs listed
>> in the link below and participate in their groups and calls as well.
>>
>> http://www.nist.gov/smartgrid/
>>
>> We were also encouraged to participate with this OASIS TC:
>>
>> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=energyinterop
>>
>>
>> ---
>> Shidan
>>
>> On Mon, Nov 23, 2009 at 11:50 AM, Arjun Roychowdhury <arjun.lists at hsc.com
>> > wrote:
>>
>>> All,
>>> as discussed in last week's call, here is the link to the SIP
>>> applicability in smartgrid. The diagram is aligned with NIST's conceptual
>>> reference diagram.
>>>
>>> Please comment on whether you agree/disagree with the pie chart
>>> depictions (empty circle = not applicable, full circle = very applicable).
>>> Also, for each segment have shown potential media and/or data (=IM+Events)
>>> applicability of SIP.
>>>
>>> Document Link:
>>>
>>> http://www.sipforum.org/component/option,com_docman/task,doc_details/gid,379/Itemid,261/
>>>
>>> regds
>>> arjun
>>> --
>>> Arjun Roychowdhury
>>>
>>>
>>> _______________________________________________
>>> Smartgrid mailing list
>>> Smartgrid at sipforum.org
>>> http://sipforum.org/mailman/listinfo/smartgrid
>>>
>>>
>>
>>
>> --
>> __________________________________
>> Shidan Gouran
>> President & CEO, Gulf Pearl Ltd.
>> Suite 2200, 4950 Yonge Street
>> Toronto, ON M2N 6K1
>> shidan at gulfpearl.com
>> Office: (416) 218-5583
>> Cell: (416) 854-3017
>> Fax: (416) 221-4668
>> __________________________________
>>
>>
>> *********************************************DISCLAIMER*********************************************
>> The email is subject to Disclaimer as per - http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer
>>
>>
>
>
> --
> Arjun Roychowdhury
>
>
>
>
>
> *********************************************DISCLAIMER*********************************************
> The email is subject to Disclaimer as per - http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer
>
>

-- 
Arjun Roychowdhury
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/smartgrid/attachments/20091123/f4da161b/attachment.html 