OASIS Energy Market Information Exchange (eMIX) TC

 View Only
  • 1.  RE: EMIX Product and Time - Answers and Suggestions needed

    Posted 11-10-2010 21:53

    I just had a long conversation with Ed on some of his issues and concerns. One set of them centers on the use of the word Product throughout the specification. As it is now, There is a Product Description and a Product. A product is defined as a Description applied to a [WS-Calendar] Sequence. Ed feels this is confusing, and he convince me that it is as well. Let’s call it a Banana.

    Let’s say that we have a Product Description and a Banana. A banana is a Product Description applied to a Sequence. The Banana may be used to in a Tender. A Banana may be proffered as a resource into a bid. A Banana may be schedule for Generation. A Banana may be a report of Energy Usage coming back from a metering point. Calling all those Bananas “Product” causes confusion.

    A Banana may be a single interval of time, with the Product Description, Duration, Price, and Quantity fully specified. A Banana may be a load shape over a series of intervals, sharing a Product Description, and a common Duration, although the Quantity varies for each Interval. A Banana may be a representation of an hourly pricing tariff, sharing a Product Description, and a common Duration (hour), with a Price that varies for each Interval; no quantity is specified.

    This comes to the question: What do we call a Banana? Only sometimes is it what we normally call a Product.

    Ed suggested that we call it a Packaged Product (or productPackage). We also decided to throw it before the TC.

    A Product Description applied to a Sequence is called a:_____________

    tc


    "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: Toby Considine [mailto:Toby.Considine@gmail.com]
    Sent: Wednesday, November 10, 2010 2:41 PM
    To: emix@lists.oasis-open.org
    Subject: FW: EMIX Product and Time

    Excellent question, Ed.

    The real question, underneath, has to do with ramps, and perhaps with my understanding of them (which is getting better, now).

    I had a concept of a ramp interval, i.e., an interval during which power varied but all other aspects were constant. This required me to have an interval with a (Begin power / end power) as opposed to a “normal” interval which had a single power. As at that time, all quantities were in the interval, and this was external to the product (resources had not really come together then), I needed another way to handle it.

    What I did at the time was sub-class the EMIX interval, itself an instance of a WS-Calendar Interval, into an interval that was either constant or ramp power. This sub-class, then, with a choice if ramp or constant, can exist anywhere a an EMIX interval does, which includes as any member of an EMIX Sequence.

    So, it is not really an additional interval, but a redefinition for use in Power.

    The CIM handles this by having “steps” of constant power instead. It then deals with the predicted variance between actual power and stepped power by having a market rule requiring the resource to “make good” on the difference with spot purchases.

    I was concerned that such tacit “everyone knows how this works” assumptions break down as we move into common definitions for generation resources, distributed resources, and distributed generation. A key goal is to make all the tacit assumptions explicit in the interfaces, a goal as strong as that of hiding unnecessary technical detail.

    The use of ramp rates in Resources has perhaps reduced the need for such intervals, meaning perhaps we can fall back to the un-elaborated, un-redefined bare emix sequence. If not, as your question indicates, then the Power Sequence warrants a couple paragraphs, perhaps in Chapter 5, as it is an underpinning structure throughout the other Power-based interfaces.

    As always, we need to support the present and the future, rather than perfect the past. A good quick discussion?

    Sean? Donna? Bruce? Phil? Ruchi? Brian? Bill  S? Each of you has chimed in on aspects of this subject.

    tc


    "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: Ed Cazalet [mailto:ed@cazalet.com]
    Sent: Tuesday, November 09, 2010 11:45 PM
    To: 'William Cox'; Toby.Considine@gmail.com
    Subject: EMIX Product and Time

    See attached.

    Edward G. Cazalet, Ph.D.

    101 First Street, Suite 552

    Los Altos, CA 94022

    650-949-5274

    cell: 408-621-2772

    ed@cazalet.com

    www.cazalet.com



  • 2.  RE: [emix] RE: EMIX Product and Time - Answers and Suggestions needed

    Posted 11-10-2010 22:18
    
    
    
    
    


  • 3.  RE: [emix] RE: EMIX Product and Time - Answers and Suggestions needed

    Posted 11-10-2010 23:07

    Bruce,

    The Product Definitions you and NAESB define are devoid of interval and location  (which I think is better).

    In making an offer to another party or to an ISO we need to specify the product, the location and the interval or intervals.

    In receiving an award from an ISO or acceptance of an offer from a counterparty we need same information, except that the price will now be a contracted price rather than an offered (bid)  price and the  quantity may be the same or less.

    In the ISO world, and most trading situations, we essentially use subscripts on the product - ie, product ( location, interval(s)) to convey offers and transaction.

    In the EMIX specification it seems we need more labels and the labels we choose can inform or confuse. 

    We could say locatedProduct is Product + location,

    and packagedProduct is locatedProduct + interval(s).

    We tried the label scheduledProduct for  locatedProduct + intervals(s) which works for a transmission schedule or and ISO schedule but not for an offer, award or transaction that has not yet be scheduled to a transmission operator.

    What do you or others suggest?

    Edward G. Cazalet, Ph.D.

    101 First Street, Suite 552

    Los Altos, CA 94022

    650-949-5274

    cell: 408-621-2772

    ed@cazalet.com

    www.cazalet.com

    From: Bruce Bartell [mailto:bbartell@xtensible.net]
    Sent: Wednesday, November 10, 2010 2:17 PM
    To: Toby.Considine@gmail.com; emix@lists.oasis-open.org
    Subject: RE: [emix] RE: EMIX Product and Time - Answers and Suggestions needed

    This might explain my JIRA comment about what actually defines the Product in the transaction. It looks like the Product Description is the identifier?

    Below are some of the definitions used in the NAESB PAP03/04/09 Master Data List regarding product:

    Price and Product

     

     

    Product Name

    Same as 7.13 Market Product

    An identifier for a particular electricity product offering: energy, capacity, ancillary services, etc.

    Product Type

    Defines the source and product

    Classifications used within industry for trading energy. Examples: PJM Energy, NYISO 10-min Spin, etc.

    Product Sub-type

    Used to further define product types

     

    I definitely do not like banana.

    Bruce Bartell

    Xtensible Solutions

    Mobile: +1.321.258.6500

    dmartin@xtensible.net">bbartell@xtensible.net  |   www.xtensible.net


    From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
    Sent: Wednesday, November 10, 2010 4:52 PM
    To: emix@lists.oasis-open.org
    Subject: [emix] RE: EMIX Product and Time - Answers and Suggestions needed

    I just had a long conversation with Ed on some of his issues and concerns. One set of them centers on the use of the word Product throughout the specification. As it is now, There is a Product Description and a Product. A product is defined as a Description applied to a [WS-Calendar] Sequence. Ed feels this is confusing, and he convince me that it is as well. Let’s call it a Banana.

    Let’s say that we have a Product Description and a Banana. A banana is a Product Description applied to a Sequence. The Banana may be used to in a Tender. A Banana may be proffered as a resource into a bid. A Banana may be schedule for Generation. A Banana may be a report of Energy Usage coming back from a metering point. Calling all those Bananas “Product” causes confusion.

    A Banana may be a single interval of time, with the Product Description, Duration, Price, and Quantity fully specified. A Banana may be a load shape over a series of intervals, sharing a Product Description, and a common Duration, although the Quantity varies for each Interval. A Banana may be a representation of an hourly pricing tariff, sharing a Product Description, and a common Duration (hour), with a Price that varies for each Interval; no quantity is specified.

    This comes to the question: What do we call a Banana? Only sometimes is it what we normally call a Product.

    Ed suggested that we call it a Packaged Product (or productPackage). We also decided to throw it before the TC.

    A Product Description applied to a Sequence is called a:_____________

    tc


    "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: Toby Considine [mailto:Toby.Considine@gmail.com]
    Sent: Wednesday, November 10, 2010 2:41 PM
    To: emix@lists.oasis-open.org
    Subject: FW: EMIX Product and Time

    Excellent question, Ed.

    The real question, underneath, has to do with ramps, and perhaps with my understanding of them (which is getting better, now).

    I had a concept of a ramp interval, i.e., an interval during which power varied but all other aspects were constant. This required me to have an interval with a (Begin power / end power) as opposed to a “normal” interval which had a single power. As at that time, all quantities were in the interval, and this was external to the product (resources had not really come together then), I needed another way to handle it.

    What I did at the time was sub-class the EMIX interval, itself an instance of a WS-Calendar Interval, into an interval that was either constant or ramp power. This sub-class, then, with a choice if ramp or constant, can exist anywhere a an EMIX interval does, which includes as any member of an EMIX Sequence.

    So, it is not really an additional interval, but a redefinition for use in Power.

    The CIM handles this by having “steps” of constant power instead. It then deals with the predicted variance between actual power and stepped power by having a market rule requiring the resource to “make good” on the difference with spot purchases.

    I was concerned that such tacit “everyone knows how this works” assumptions break down as we move into common definitions for generation resources, distributed resources, and distributed generation. A key goal is to make all the tacit assumptions explicit in the interfaces, a goal as strong as that of hiding unnecessary technical detail.

    The use of ramp rates in Resources has perhaps reduced the need for such intervals, meaning perhaps we can fall back to the un-elaborated, un-redefined bare emix sequence. If not, as your question indicates, then the Power Sequence warrants a couple paragraphs, perhaps in Chapter 5, as it is an underpinning structure throughout the other Power-based interfaces.

    As always, we need to support the present and the future, rather than perfect the past. A good quick discussion?

    Sean? Donna? Bruce? Phil? Ruchi? Brian? Bill  S? Each of you has chimed in on aspects of this subject.

    tc


    "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: Ed Cazalet [mailto:ed@cazalet.com]
    Sent: Tuesday, November 09, 2010 11:45 PM
    To: 'William Cox'; Toby.Considine@gmail.com
    Subject: EMIX Product and Time

    See attached.

    Edward G. Cazalet, Ph.D.

    101 First Street, Suite 552

    Los Altos, CA 94022

    650-949-5274

    cell: 408-621-2772

    ed@cazalet.com

    www.cazalet.com



  • 4.  RE: [emix] RE: EMIX Product and Time - Answers and Suggestionsneeded

    Posted 11-11-2010 01:27

    I’m not entirely sure I’m following you, but I’ll try anyway.  We have a product that is independent of time or location, e.g. Energy.  When we incorporate time and location we could be talking about a tender, a schedule or an award.  Simply adding a time (sequence) doesn’t make it anything.

    Sean

    From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
    Sent: Wednesday, November 10, 2010 1:52 PM
    To: emix@lists.oasis-open.org
    Subject: [emix] RE: EMIX Product and Time - Answers and Suggestions needed

    I just had a long conversation with Ed on some of his issues and concerns. One set of them centers on the use of the word Product throughout the specification. As it is now, There is a Product Description and a Product. A product is defined as a Description applied to a [WS-Calendar] Sequence. Ed feels this is confusing, and he convince me that it is as well. Let’s call it a Banana.

    Let’s say that we have a Product Description and a Banana. A banana is a Product Description applied to a Sequence. The Banana may be used to in a Tender. A Banana may be proffered as a resource into a bid. A Banana may be schedule for Generation. A Banana may be a report of Energy Usage coming back from a metering point. Calling all those Bananas “Product” causes confusion.

    A Banana may be a single interval of time, with the Product Description, Duration, Price, and Quantity fully specified. A Banana may be a load shape over a series of intervals, sharing a Product Description, and a common Duration, although the Quantity varies for each Interval. A Banana may be a representation of an hourly pricing tariff, sharing a Product Description, and a common Duration (hour), with a Price that varies for each Interval; no quantity is specified.

    This comes to the question: What do we call a Banana? Only sometimes is it what we normally call a Product.

    Ed suggested that we call it a Packaged Product (or productPackage). We also decided to throw it before the TC.

    A Product Description applied to a Sequence is called a:_____________

    tc


    "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: Toby Considine [mailto:Toby.Considine@gmail.com]
    Sent: Wednesday, November 10, 2010 2:41 PM
    To: emix@lists.oasis-open.org
    Subject: FW: EMIX Product and Time

    Excellent question, Ed.

    The real question, underneath, has to do with ramps, and perhaps with my understanding of them (which is getting better, now).

    I had a concept of a ramp interval, i.e., an interval during which power varied but all other aspects were constant. This required me to have an interval with a (Begin power / end power) as opposed to a “normal” interval which had a single power. As at that time, all quantities were in the interval, and this was external to the product (resources had not really come together then), I needed another way to handle it.

    What I did at the time was sub-class the EMIX interval, itself an instance of a WS-Calendar Interval, into an interval that was either constant or ramp power. This sub-class, then, with a choice if ramp or constant, can exist anywhere a an EMIX interval does, which includes as any member of an EMIX Sequence.

    So, it is not really an additional interval, but a redefinition for use in Power.

    The CIM handles this by having “steps” of constant power instead. It then deals with the predicted variance between actual power and stepped power by having a market rule requiring the resource to “make good” on the difference with spot purchases.

    I was concerned that such tacit “everyone knows how this works” assumptions break down as we move into common definitions for generation resources, distributed resources, and distributed generation. A key goal is to make all the tacit assumptions explicit in the interfaces, a goal as strong as that of hiding unnecessary technical detail.

    The use of ramp rates in Resources has perhaps reduced the need for such intervals, meaning perhaps we can fall back to the un-elaborated, un-redefined bare emix sequence. If not, as your question indicates, then the Power Sequence warrants a couple paragraphs, perhaps in Chapter 5, as it is an underpinning structure throughout the other Power-based interfaces.

    As always, we need to support the present and the future, rather than perfect the past. A good quick discussion?

    Sean? Donna? Bruce? Phil? Ruchi? Brian? Bill  S? Each of you has chimed in on aspects of this subject.

    tc


    "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: Ed Cazalet [mailto:ed@cazalet.com]
    Sent: Tuesday, November 09, 2010 11:45 PM
    To: 'William Cox'; Toby.Considine@gmail.com
    Subject: EMIX Product and Time

    See attached.

    Edward G. Cazalet, Ph.D.

    101 First Street, Suite 552

    Los Altos, CA 94022

    650-949-5274

    cell: 408-621-2772

    ed@cazalet.com

    www.cazalet.com


    *********************************************************************************************
    The foregoing electronic message, together with any attachments thereto, is confidential and may be legally privileged against disclosure other than to the intended recipient. It is intended solely for the addressee(s) and access to the message by anyone else is unauthorized. If you are not the intended recipient of this electronic message, you are hereby notified that any dissemination, distribution, or any action taken or omitted to be taken in reliance on it is strictly prohibited and may be unlawful. If you have received this electronic message in error, please delete and immediately notify the sender of this error.
    *********************************************************************************************



  • 5.  RE: [emix] RE: EMIX Product and Time - Answers and Suggestionsneeded

    Posted 11-11-2010 02:29

    True.

    There are two challenges here. One is communicating the reality of the markets, the way things change over time, the instantiation of particular contracts. These contracts are not just the relatively simple contracts of generation but the more [potentially] complex ones of retail.

    Example: One of the core initial use cases of EMIX was the factory with detailed knowledge of its energy use over time. A critical process, say, takes 6 weeks to manufacture the annual supply. Energy is a significant enough component that the factory is willing to deform its shits around it. Should it be from 3:00 am on? Should it be beginning at 4 in the afternoon? Its labor agreements could support either, but not without notice. Can that factory bid that load shape against suppliers, and get specific bids for time of day for the entire load shape, even though it changes in 15 minute increments?

    (BTW, I actually have worked in a variant of this scenario, back in 1978. Energy markets were still under the influence of the price shocks of 1973. This “market bid” took 5 weeks of negotiation with the utility.)

    Another scenario we have is of the end node, a commercial building optimizing its economic position be working the price curve vs its internal needs to support cooling and heating in specific scenarios.

    Here I am also informed of a Hospital in Long Beach(?) in California, run by Kaiser, that accepted a DR shutdown on Friday afternoon during a heat wave (fall 2007-8?). The hospital began re-cooling on Monday morning, but the accumulated heat of the walls meant that the clinical space did not meet regulatory requirements until 2:30 or so in the afternoon.  All that catch-up, all that extra cooling occurred during business hours on Monday, as the heat wave continued. Well if the hospital had been able to understand the actual price curves, and the actual heat capacity, then it would have elected to optimize its re-cooling based upon dynamic prices in the early morning hours, and chosen the best economic solution for “ready to serve patients” rather than “ready to start cooling” Prices and price schedules are much more interesting even then the underlying energy markets. How do we communicate that.

    Another scenario I know involves the Cleveland Clinics, which currently has energy supply contracts with both PJM and with Midwest ISO. They do not accept DR signals; the last time they did , a change in ventilation in the entrance, extended throu8gh an underground hallway, and up through an elevator shaft, and resulted in loss of positive pressure (to keep infection out) in a specialty ICU. They live on energy arbitrage between two markets.

    So, “Simply adding a time (sequence) doesn’t make it anything.”, it may not, but it is important to consumer of EMIX beyond markets, and we need to call it something within the EMIX specification, we need to call it something with EnergyInterop, and as Bruce says, it should probably not be “Banana.”

    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

    From: Crimmins, Sean [mailto:SCrimmins@caiso.com]
    Sent: Wednesday, November 10, 2010 8:26 PM
    To: 'Toby.Considine@gmail.com'; emix@lists.oasis-open.org
    Subject: RE: [emix] RE: EMIX Product and Time - Answers and Suggestions needed

    I’m not entirely sure I’m following you, but I’ll try anyway.  We have a product that is independent of time or location, e.g. Energy.  When we incorporate time and location we could be talking about a tender, a schedule or an award.  Simply adding a time (sequence) doesn’t make it anything.

    Sean

    From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
    Sent: Wednesday, November 10, 2010 1:52 PM
    To: emix@lists.oasis-open.org
    Subject: [emix] RE: EMIX Product and Time - Answers and Suggestions needed

    I just had a long conversation with Ed on some of his issues and concerns. One set of them centers on the use of the word Product throughout the specification. As it is now, There is a Product Description and a Product. A product is defined as a Description applied to a [WS-Calendar] Sequence. Ed feels this is confusing, and he convince me that it is as well. Let’s call it a Banana.

    Let’s say that we have a Product Description and a Banana. A banana is a Product Description applied to a Sequence. The Banana may be used to in a Tender. A Banana may be proffered as a resource into a bid. A Banana may be schedule for Generation. A Banana may be a report of Energy Usage coming back from a metering point. Calling all those Bananas “Product” causes confusion.

    A Banana may be a single interval of time, with the Product Description, Duration, Price, and Quantity fully specified. A Banana may be a load shape over a series of intervals, sharing a Product Description, and a common Duration, although the Quantity varies for each Interval. A Banana may be a representation of an hourly pricing tariff, sharing a Product Description, and a common Duration (hour), with a Price that varies for each Interval; no quantity is specified.

    This comes to the question: What do we call a Banana? Only sometimes is it what we normally call a Product.

    Ed suggested that we call it a Packaged Product (or productPackage). We also decided to throw it before the TC.

    A Product Description applied to a Sequence is called a:_____________

    tc


    "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: Toby Considine [mailto:Toby.Considine@gmail.com]
    Sent: Wednesday, November 10, 2010 2:41 PM
    To: emix@lists.oasis-open.org
    Subject: FW: EMIX Product and Time

    Excellent question, Ed.

    The real question, underneath, has to do with ramps, and perhaps with my understanding of them (which is getting better, now).

    I had a concept of a ramp interval, i.e., an interval during which power varied but all other aspects were constant. This required me to have an interval with a (Begin power / end power) as opposed to a “normal” interval which had a single power. As at that time, all quantities were in the interval, and this was external to the product (resources had not really come together then), I needed another way to handle it.

    What I did at the time was sub-class the EMIX interval, itself an instance of a WS-Calendar Interval, into an interval that was either constant or ramp power. This sub-class, then, with a choice if ramp or constant, can exist anywhere a an EMIX interval does, which includes as any member of an EMIX Sequence.

    So, it is not really an additional interval, but a redefinition for use in Power.

    The CIM handles this by having “steps” of constant power instead. It then deals with the predicted variance between actual power and stepped power by having a market rule requiring the resource to “make good” on the difference with spot purchases.

    I was concerned that such tacit “everyone knows how this works” assumptions break down as we move into common definitions for generation resources, distributed resources, and distributed generation. A key goal is to make all the tacit assumptions explicit in the interfaces, a goal as strong as that of hiding unnecessary technical detail.

    The use of ramp rates in Resources has perhaps reduced the need for such intervals, meaning perhaps we can fall back to the un-elaborated, un-redefined bare emix sequence. If not, as your question indicates, then the Power Sequence warrants a couple paragraphs, perhaps in Chapter 5, as it is an underpinning structure throughout the other Power-based interfaces.

    As always, we need to support the present and the future, rather than perfect the past. A good quick discussion?

    Sean? Donna? Bruce? Phil? Ruchi? Brian? Bill  S? Each of you has chimed in on aspects of this subject.

    tc


    "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: Ed Cazalet [mailto:ed@cazalet.com]
    Sent: Tuesday, November 09, 2010 11:45 PM
    To: 'William Cox'; Toby.Considine@gmail.com
    Subject: EMIX Product and Time

    See attached.

    Edward G. Cazalet, Ph.D.

    101 First Street, Suite 552

    Los Altos, CA 94022

    650-949-5274

    cell: 408-621-2772

    ed@cazalet.com

    www.cazalet.com


    *********************************************************************************************
    The foregoing electronic message, together with any attachments thereto, is confidential and may be legally privileged against disclosure other than to the intended recipient. It is intended solely for the addressee(s) and access to the message by anyone else is unauthorized. If you are not the intended recipient of this electronic message, you are hereby notified that any dissemination, distribution, or any action taken or omitted to be taken in reliance on it is strictly prohibited and may be unlawful. If you have received this electronic message in error, please delete and immediately notify the sender of this error.
    *********************************************************************************************