emix — archive

[Toby Considine]

Thanks to Bruce and Bill and Ed, whose long patient conversations have shaped these thoughts. The SE model is what I would characterize as a control block information model. In this model, the complete state of a state engine is delivered to a system or to an information model. There are many instances where this is a useful pattern, particularly when a [client] communicates exclusively with a single [server], and all interactions are defined in advance. This is true now as a transition state for smart energy, and may well always be true within limited islands of smart energy. Most houses may be such examples of small islands maintained indefinitely. EMIX and EI are use a transactive model to describe energy interactions. Transactive engines may interact with many parties, each supplying their own information. For example, one would not expect a broadcast day-ahead price communication, sent potentially to millions of similar nodes, to include meter reading information for reach. If there are 30 potential billing cycles (Pay on the 1 st , pay on the 2 nd , etc.), then 30 targeted broadcasts would be needed for to deliver billing period information. Those information sets must be available as different transactions, with different purposes, and difference interaction patterns. For this conversation, as a shorthand., lets us postulate an Energy Services Engine (ESE). An ESE resides at the edge of a Node has an ESI on the outside, that is, it is able to communicate by Energy Interoperation. The ESE may operate the node directly, that ESE may have a separate face, using an ESI acting as a LSE on the “inside:, that ESE may be on a JACE, or iLON, or Metasys Server server, and interact with commercial building systems directly. It may have an internal OPC face negotiating with industrial systems. How it marshals its effects is irrelevant. I am calling it an ESE hear merely for convenience. Let’s posit that the ESE wants to construct an SE model to operate the node. It is not in scope for EMIX or for Energy Interoperation to determine a single normative way for the ESE to acquire the information in the SE Reading object. The ESE may be able to communicate directly with a primary or secondary meter, and collect its information by SE or be ANSI C.12. The ESE may support an OpenADE interface, and  construct the Reading block through periodic OpenADE calls. If the ESE is fronting an aggregator, the Reading model may come from some mechanism that is not yet defined at all. A we look at the classes that make up the SE model, we see that many of them are not derivable from an EMIX quote by design. SEP2 Classes Class Overview Note IdentifiedObject ID, Name, and Description All *may* be 0 occurs Not in realm of EMIX Quote Resource transactional metadata Href, only required item, could be from ESI Not part of EiQuote TariffProfile Identifieds Tariff Can be generated or parsed from Market Context In EI, would come from EiMarketContext, which could be delivered with EiQuote RateComponent Tiers and limits  and prices A defined in EMIX Product ReadingType Metering information Readings are not part of Quotes TimeTariffInterval Interval RandomizedDateTimeInterval Defined in Schedule for Tiers of EMIX Quote ConsumptionTariffInterval Defined in Tiers, capacity charges of EMIX Quote Cost Amount Small number of defiend environmental costs Environmental Warrants can define environmental burden, but not defined yet. BillingPeriod Interval DateTimeInterval Can't be known from a broadcast “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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