OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emix] EMIX use cases showing requirements for defining geographic regions


Well let me put it differently

 

EMIX can specify the 12,000 (or 12,000,000) meters indicated by a particular notice in 12,000 messages. Fine for point to point, but less than desirable using FM broadcast.

EMIX can specify customers in “Tariff Class A”. This would alert too many customers if the problem was , say local congestion. This is what I believe has been used in the past.

EMIX can specify circuits, requiring a serious of notifications as each home and business is notified about each circuit reconfiguration. This would also require the promulgation of a national standard for specifying Circuit / sub-circuit / feeder / sub-feeder lines, as well as additional information standardization for dual-feed neighborhoods, etc.

 

Or

 

EMIX can rely on the premises knowing facts that do not vary, and a means to describe, in unambiguous and well known language, a varying area. That would be a point (known by the premise) and a geographic polygon (able to describe the region affected by any circuit event).

 

If you can go Point-to-Point, then do. But as long as broadcast is in the use cases provided by the CUC, …

 


"If something is not worth doing, it`s not worth doing well" - Peter Drucker


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

From: Anne Hendry [mailto:ahendry@pacbell.net]
Sent: Thursday, February 24, 2011 3:14 PM
To: Considine, Toby (Campus Services IT)
Cc: emix@lists.oasis-open.org
Subject: Re: [emix] EMIX use cases showing requirements for defining geographic regions

 

IF EMIX includes Meter, THEN it includes Region.

The conclusion does not necessarily follow.

As a matter of fact, the more I delve into the California tiered pricing example, the less it follows.  The way seeming location-dependent decisions are made in the California example is grounded in practicality with people making decisions that fallback on a system of pre-existing conditions, data, and common practices that have less to do with specifying precise regional boundaries and more to do with common knowledge, best practices, and historical decisions.  And it's much more focused on specific delivery points than regions of service.  That is why I was asking for more use cases.

Regardless, for possible future use cases, I'd like to advocate a more general/generic approach following the 80/20 rule, which is to provide a level of basic locational support to cover the majority of our use cases.  That could include allowing for multiple 'locations' that could be interpreted as a 'region', but that interpretation would happen at a level beyond EMIX (at the trading partner level, for instance) by including the ability for users to specify a coordinate system of choice if they want a different interpretation applied to that generic support.  The argument for this approach is that there exist (and are constantly coming into being) many distinct systems for identifying a specific location in space and we shouldn't constrain users to any specific system of interpretation.  This approach also allows for transition from existing/legacy systems.


-A


Considine, Toby (Campus Services IT) wrote, On 2/24/2011 4:22 AM:

Energy is time and location sensitive. IF EMIX includes Meter, THEN it includes Region. An argument could be made that it excludes both, but I do no thin that's a winning argument.
 
tc
 
 
"It is the theory that decides what can be observed."   - Albert Einstein
 
Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073 
http://www.oasis-open.org 
blog: www.NewDaedalus.com
 
 
 
-----Original Message-----
From: Anne Hendry [mailto:ahendry@pacbell.net] 
Sent: Wednesday, February 23, 2011 10:59 PM
To: Considine, Toby (Campus Services IT)
Cc: emix@lists.oasis-open.org
Subject: Re: [emix] EMIX use cases showing requirements for defining geographic regions
 
Do you consider that in scope for EMIX?
 
Considine, Toby (Campus Services IT) wrote, On 2/23/2011 6:46 PM:
  
One thing that *I* have been asked about is EI signals going out by FM radio. In some parts of CA, DR signals have been sent by CAP alert. Clearly, I, in my house, will not be contacted by CAP alert directed at my meter, so the question is how will I know it is for me....
 
Geographical polygon is the natural follow-on.
 
 
 
"It is the theory that decides what can be observed."   - Albert Einstein
 
Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture 
Committee Facilities Technology Office University of North Carolina 
Chapel Hill, NC
  
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com
 
 
-----Original Message-----
From: Anne Hendry [mailto:ahendry@pacbell.net] 
Sent: Wednesday, February 23, 2011 6:11 PM
To: emix@lists.oasis-open.org
Subject: [emix] EMIX use cases showing requirements for defining geographic regions
 
I'm looking for any EMIX use cases that show there is a requirement for defining a geographic region when communicating price and/or product information.  I know the discussion started some time ago, but don't recall the reason/driver.  I know about California tiered pricing based on climate zones as one example, but am assuming there are more ...
 
Thanks,
-A
 
 
 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
 
 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
 
 
  
    
 
 
  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]