emix — archive

EMIX use cases showing requirements for defining geographic regions

From: Toby Considine <[email protected]>
To: [email protected]
Date: Fri, 25 Feb 2011 11:08:00 -0000

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: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com From: Anne Hendry [mailto:[email protected]] Sent: Thursday, February 24, 2011 3:14 PM To: Considine, Toby (Campus Services IT) Cc: [email protected] 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