SEP Translation and EMIX as delivered by EiQuote

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

emix message