[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: obix2 - Energy - conversation starter
oBIX and Energy We have points. We have meters that can be read. We have no notion in oBIX 1.x of energy use. Energy use could be a delta between two meter readings, but that contract is awkward to create today. In some ways Energy Use it is similar to run-time. New ASHRAE efforts to unite BACnet and BIM suggest a growing interest in information that would support Repair/Replace solutions. Certainly Usage-based Maintenance (as opposed to schedule-based or failure-based) needs a notion of run time that supports “change the filters every xxx of run-time”. If there is a COBie set aligned with the BAS, then the notion of a system is defined therein. Is run-time for a particular fan a proxy for run-time of a system (as defined in COBie)? From there it should be easy to reference the same COBie set to find which filters need to be replaced. Energy Use offers some of the same issues. A system *may* have a single meter – this makes it easy. It may have several meters, say, on different sub-systems. A BIM infoset (COBie or BIMSie) alongside explains how to aggregate those meters into a single measure. Alternately, we may have run-times on a number of motors, and compute energy usage for the aggregate from that. As an owner / operator of buildings, it would be very useful to be able to access energy information in this way. Of course, if I can predict run-times, then I can predict energy usage. In Energy Interoperation, we defined multiple Streams of essentially identical information that a system should be able to produce. 1) A report, which is exactly what it sounds like. Give me energy usage at 5 minute intervals for the period between 11:00 AM and 3:00 PM. We defined several refinements on reporting therein, what would be contract types in oBIX 2, but I am not going into those at this time. 2) A projection, which is a report for a future time. A projection may have a level of certainty for some or all of the intervals. 3) A Request, either for a particular usage, or not to exceed, or not to drop under. These may be received as part of a Demand-Response (DR) event. 4) A contract, either for a particular usage, or not to exceed, or not to drop under. This may be in response to an OpenADR request, or as part of a transactive purchase of energy, or as information to a facility energy manager, perhaps as defined is ASHRAE FSGIM. Energy Interoperation reporting defines several behaviors such long-running reports with intermediate (including instant) results, standard report definitions, tracking multiple values in the same report, as well as the difference between reporting peak use, total use, instantaneous use, and different variables (WH, VoltVar, et al.) I want to walk by those issues for a moment. In Energy Interoperation, we relied on the information model in EMIX. EMIX defines a full information set for each interval, as well as an inheritance mechanism for each interval to be able to convey full information based on context. Context may be within a Stream (these are *all* 15 minute intervals) or within a Market (all transactions are denominated in MW) or within a report definition. Context may even be within a sequence, as a Report Definition might specify 5 measurements within each interval. I will extract the Energy Interoperation stuff later, but our notions of Energy in oBIX should comply with the EMIX information model for expressions over time that conform to WS-Calendar. tc "Energy and persistence conquer all things." -- Benjamin Franklin
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]