Name associated with the Market Context
Market Expectations inform the VEN what the expectations and rules are for a given Market Context
Temporal granularity of market, i.e., a 5 minute market operates in 5 minute chunks, with a fixed offset from the beginning of the business schedule
Non-Standard terms handling defines what Parties should do with any Term not listed in the Market Rule Sets.
A collection of Requirements (Constraints) and how they are processed within this market
Defines the purpose of a market rule set.
The Market does not accept this Term with a parameter set to a lesser value than this
The Market does not accept this Term with a parameter set to a greater value than this
Regardless of what the market participant requests, force the Term to the value here.
Participants in this market must understand this constraint.
This Constraint will be ignored in all its forms.
Simple Levels are a set of simple indicators about scarcity and value, in which an ordered set of values indicate energy scarcity is above normal, normal, or below normal. Presumably, at higher levels, the VEN will use less.
The "normal" level indicating normal energy avaiability. Levels below normal indicate surplus, levels above normal indicate increasing scarcity. If levelUpperLimit is 7, the levels are 1-7, and the levelNormalValue might be 3.
The upper level for this context. If levelUpperLimit is 5, the levels are 1-5, where 5 indicates the greatest scarcity.
Indicates a specific level in within a simple level context. For example, a context may specify a level between 1-7, and the current level is 4.
ID for this artifact
VEN that offers this availability
Resources to which the Availability applies.
Resource ID for the for what is offered by the VEN
When an Event is issued by the VTN, it is validated against the parameters and constraints that were established when the program [market context] was set up, i.e., the program was configured to support Events between 12:00 and 16:00. If the Event is not within 12:00 and 16:00 then VEN must take some action to resolve the conflict.
Simply accept the issued DR event regardless of any conflicts
Reject any DR events that conflict with configured constraints
Modify the DR event parameters so that they legally fall within the bounds of the configured parameters.
Opts are used tby the VEN to make temporary over-rides to the pre-existing agreement. For example, a VEN may Opt In to events during the evening, or Opt Out from events during the World Series.
This is the identifier that may used by other entities to refer to this instance of an OptOut.
eiReport is a Stream of [measurements] recorded over time and delivered to the requestor periodically. The readings may be actual, computed, summed ir derived in some other manner.
reference ID to this Report.
reference to Request that created this Report.
reference to Specifier that defined this Report.
Name possibly for use in a user interface.
Snap represents a single moment with the information in the Payload is Measured / Generated
Parameters that define the content of a Report Stream
How frequently the [measurement] is to be recorded.
Report back with the Report-To-Date each the passing of this Duration during the Report Interval.
This is the overall period of reporting.
Payload for use in Report Specifiers.
Multiple Report and Snap Requests.
Collection of Report and Snap Requests
This type is used to request an EiReport
If true, aggregate all matching targets, if false, report each matching target individually.
Establishes relation between Active Interval of an Event and the Report Interval.
Used to establish relationship between Active Interval and Report Schedule. For example, SS -T30M and FF T1H would convey that the report runs from 30 minutes before the Active Period to one hour after. If absent, the Report Interval is equivalent to the Active Interval, i.e., the Report runs during Active Interval.
Indicates the Event this report is related to. If absent, must be delivered as part of a an EiEvent.
Used if the Report Specifier includes a Report Interval to influence the expression of that Interval. Information in the Gluon is inherited by the Report Interval in conformance with WS-Calendar.
request replaces report Interval in the Report Specification.
request is for a single moment status. If Empty, the request is for "when received"
Base Class for Schedulers in Report Requests.
Report Payload for use in Reports, snaps, and projections.
eiDelivery is a minimal report that assume that all esential parameters (type, etc) come form an existing market context or transaction.
Describes the subject and attributes of a report.
Optional element for use only if more than one description.
What is measured or tracked in this report. Absent if report tracks Price or Level.
Registration varies from Market to Market and VEN to VEN and so cannot be defined here. Perties wishing to exchange Registration should extend this abstract type to meet their particular needs.
Subject[s] of this report. Examples might be meter1 or chiller2, etc. Subjects may be tangible devices or subsystems that are metered or they may be logical entities.
Sources for data in this report. Examples include meters or submeters. For example, if a meter is capable of providing two different types of measurements, then each measurement stream would be separately identified.
A set of elements to that collectively name who is participating or should participate in an EI interactions
RegistrationInfo is an an abstract class to which additional market-relevant registration information might be added. This specification does not define registration. Markets that use registration should extend this abstract class for use in Registration payloads.
Core element of event-based demand response. An Event consists of the time periods, deadlines, and transitions during which Demand Resources perform. The VTN specifies the duration and applicability of an Event. Some deadlines, time periods, and transitions may not be not applicable to all products or services.
Reference ID for the EI Event instance
These are the core attributes of the Event itself.
Multiple signals conveyed with an event.
Collection of Signal Base derived elements
The reason the event is being cancelled or modified.
Date of Start of Event
testEvent can be treated as a boolean by either not including it (= = false) or using the null string. For new work, indicated the Operation Payload. SUpports backward compatibility with OpenADR 1.0.
Additional Event information provided by the Operator [VTN].
This type is used for describing the signal type communications.
eiEventSignal should be paired with information in the Type acts AS IF a Gluon to the Intervals in the Stream
This is the units of the signal.
Current Value reprises what the Signal Payload is at the moment EventInfo is created.
The Signal Payload is a Stream Payload for conveyance within an EiEventSignal.
This type is used for describing baseline for the event.
eventBaseline should be paired with eventBaselinePayloads types in the gluons (Stream header and market context) and the intervals in the stream (or sequence)
One or more Baseline Intervals indicate comprable times that MAY be used as a Baseline. Information for the Baseline Intervals is not conveyed in this type, and the Interval may be past, present, or future.
This indicates the units of the signal.
Calculated Energy Baseline: A Baseline is an estimate of the electricity that would have been consumed by a Demand Resource in the absence of a Demand Response Event. The Baseline is compared to the actual metered electricity consumption during the Demand Response Event to determine the Demand Modification Value. Depending on the type of Demand Response product or service, Baseline calculations may be performed in real time or after the fact. Baseline may not be known at time of event, in which case missing payload is used.
This Payload contains the information that changes in each Stream payload.
Applications that wish to use this should (1) define the appropriate extension to the abstract applicationSpecificPayloadBase and (2) agree to indicates its use with a signalType conforming to the EI Extension pattern (x-*). Different extensions should be made for Signals, Reports, and perhaps Baselines.
This Payload contains the information that changes in each Stream payload.
This is the Payload for Signals that convey Simple Levels.
This is the Payload for Signals that require a Quantity.
This is the Payload for Signals that require a Price.
This is the Payload for Signals that require a Quantity.
This is the Payload for Signals that require a Quantity.
This is the Payload for Signals that require a Quantity.
base for information in Signal / Baseline / Report Payloads
Tender is an offer to buy or sell. A Tender can be for one EmixBase derived type.
An Indication of the price of a possible Tender such as the transacted price of a previous Tender or a published forecast of a price of a possible Tender. A Quote can be for one EmixBase derived type.
A Transaction is a specific agreement to accept a specific Tender.
Identifier of the Message/Request that is is a response to
Collection of Responses. When a service operation regards multiple referenceable items, each referenced item MAY have its own response. Always accompanied by an overall Response Type.
Response adding information to manage event-based messages
EventResponses require Modification number as well as other Response information
Collection of Event Responses. When an regards multiple referenceable items, each referenced item MAY have its own response. Always accompanied by an overall Response Type.
Similar to HTTP 1.1 Error Pattern, 1st digit sufficient for most error processing
- 1xx: Informational - Request received, continuing process
- 2xx: Success - The action was successfully received, understood, and accepted
- 3xx: Pending - Further action must be taken in order to complete the request
- 4xx: Requester Error - The request contains bad syntax or cannot be fulfilled
- 5xx: Responder Error - The responder failed to fulfill an apparently valid request
xx is used for defining more fine grained errors
Human Readable Response description. Should be standardized and language-specific.
Collection of Detailed response on Terms that cause rejection of Request
Number is in same units as the payload variable for an Interval. When present with Confidence, indicates the likely variability of the prediction. When present with ReadingType, indicates likely error of Reading.
Is either a request that multiple sources be combined in a report and an indication that they have been.
Date and Time this artifact was created.
Date and Time this artifact references.
A modification number for [event]. Used to indicate if the [event] has been modified and is incremented each time the [event] is modified
The date and time a modification takes effect.
Role that Party is assuming for this interaction, e.g buyer or seller
This is the priority of this event relative to other events. The lower the number higher the priority. A value of zero (0) indicates NO priority and in essence is the lowest priority by default
ID for internal use in reports
The version of the schema representing this entity.
The Application Specific Context Base is an abstract class to exchange invariant or setup information with an Application running on the other side of an interaction. They are not defined in Energy Interoperation, although there are specific conformance rules that must be followed
The Application Specific Payload Base is an abstract class to exchange feedback with an Application running on the other side of an interaction. They are not defined in Energy Interoperation, although there are specific conformance rules that must be followed
The Application Specific Report Base is an abstract class to exchange feedback with an Application running on the other side of an interaction. They are not defined in Energy Interoperation, although there are specific conformance rules that must be followed
The Application Specific Signal Base is an abstract class to exchange current information with an Application running on the other side of an interaction. They are not defined in Energy Interoperation, although there are specific conformance rules that must be followed
Application Extensions are used to provide hints to or interactions with Applications running on the other side of an interaction. They are not defined in Energy Interoperation, although there are specific conformance rules that must be followed
Optional Name for an Agreement between Parties, used perhaps in a user interface.
Optional name for a Baseline, used perhaps in a user interface.
Name of a Group which may be the target of an Event.
Optional Name for a Market Context, used perhaps in a user interface.
Optional name for a Party, used perhaps in a user interface.
Optional name for a Report, used perhaps in a user interface.
Optional name for a Signal, used perhaps in a user interface.
Optional name for a Transaction, used perhaps in a user interface.
Response Smoothing defines a Term that obligates the recipient to ensure that the response not be in a single step. Response Smoothing is applied to the tolerance interval[s] indicated by the Start Before, Start After, End Before, and End After tolerances. Response Smoothing is implimented as a Term so it can be delivered, if desired, as part of a market context.
Smoothing in EventSignal to indicate a requirement that a response not be in a single step. Smoothing is applied to the interval[s] defined by the Start Before, Start After, End Before, and End after tolerances.
A smooth or uniform step ramp is indicated between the initial and end values in the respective Tolerance Interval.
A uniform distribution is indicated over the entire respective Tolerance Interval.
No specific smoothing is indicated. Applications need not react in a stepwise manner, so some degree of smoothing MAY occur in response to this request. If the Smoothing Term is absent, the behavior requested is the same as None.
Event Schedule contains sequence containing an Active Period (at least) and potentially other components
Interval Qualification is a WS-Calendar derived property that conveys several values that indicate something abvout interpreting the accuracy of the information in the payload. An application that relies on this information should profile precise meaings of these values withithn their domain.
This is the type for an Interval in a Signal / Baseline / Report Stream.
Fully Qualified Event ID includes the eventID and the Modification Number
Identifier for an Event State interaction
Identifier for an Event State interaction
Identifier of a Group which may be the target of an Event.
Identifier for a Resource. Resources are associated with a VEN during Enrollment
Identifier for Acceptance of a Quote.
Identifier for Avail in an interaction.
Identifier for a Baseline.
This is the identifier that may used by other entities to refer to this instance of an EiConstraint.
Reference ID for a Delivery
Reference ID for a Report
Identifier assigned to the message (EiEvent) describing an event and it associated signals.
Reference ID for an ongoing Historian
Indentifier for an Opt interaction
Indentifier for a superceded Reference ID
Identifier for a Quote
Identifier for Registration transaction
Identifier for a particular Report Specification
Identifier for a particular Report Request
Identifier for a particular Signal
Identifier for a market Tender
Identification of Transaction
Reference ID for a particular instance, transmittal, or artifact. Note: not the same as the native ID of the object being transmitted or shared.
The "other" party in any interaction
The party requesting or starting an interaction
Identifier for any Party
Identifier for the party publishing a broadcast message
Identifier for Party attempting to Register
Indentifier of Party acting as a Registrar
Identifier of Party making a Request
Identifier of Party making a Resonse (note: in CancelledPartyRegistration payload and I do not know defintion)
Identifier of Party subscribing to a broadcast or service
Identifier of Party acting as a VEN.
Identifier of Party acting as a VTN.
Identifier of a Party. May be ws-addressing endpoint descriptor.
Unique Identifier
Indicates the current status of an event.
No event pending
event pending in the far future. The exact definition of how far in the future this refers is dependent upon the market context, but typically means the next day.
event pending in the near future. The exact definition of how near in the future the pending event is active is dependent on the market context
The event has been initiated and is currently active.
The event has completed.
The event has been canceled.
Type of Reading.
Reading is read from a device that increases monotonically, and usage must be computed from pairs of start and stop readings.
Meter or [resource] prepares its own calculation of total use over time.
Meter covers several [resources] and usage is inferred through some sort of pro rata computation.
Used when a reading is absent in a series in which most readings are present.
Several meters together provide the reading for this [resource]. This is specifically a different than aggregated, which refers to multiple [resources] in the same payload. See also Hybrid.
Usage is inferred through knowledge of run-time, normal operation, etc.
Reading is the mean value over the period indicated in Granularity
Reading is Peak (highest) value over the period indicated in granularity. For some measurements, it may make more sense as the lowest value. May not be consistent with aggregate readings. Only valid for flow-rate Item Bases, i.e., Power not Energy.
If aggregated, refers to different reading types in the aggregate number.
Indicates reading is pro forma, i.e., is reported at agreed upon rates
Indicates reading is in the future, and has not yet been measured.
Reason for Opting.
Enumerated Reasons for Opting.
SignalType is used in EventSignals to specify the Payload Types in a Signal.
SignalTypeEnumerated lists the pre-defined Types used to specify the Payload Types and conformance in a Stream
Signal indicates the amount to change (denominated in Itembase or in the EMIX Product) from what one would have used without the Signal. This may or may not be accompanied by a baseline. Payload Type Quantity
Signal indicates a Program Level. Payload Type is Program Level
Signal indicates a multiplier applied to the current rate of delivery or usage (denominated in Itembase or in the EMIX Product) from what one would have used without the Signal. This may or may not be accompanied by a baseline. Payload Type is Float
Signal indicates the Price. Extended Price is the value multiplied by the number of units units (denominated in Itembase or in the EMIX Product). Payload Type is emix:price
Signal indicates the Price Multiplier. Extended Price is the computed price (as described in EMIX) the value multiplied by the number of units units (denominated in Itembase or in the EMIX Product). Payload Type is emix:priceMultiplier
Signal indicates the Relative Price. Extended Price is the computed price (as described in EMIX) the value multiplied by the number of units units (denominated in Itembase or in the EMIX Product). Payload Type is emix:priceRelative
Signal indicates the Product for each interval. Payload Type is an EMIX Product Description
Signal indicates a target amount of units (denominated in Itembase or in the EMIX Product). Payload Type is Quantity
An enumerated value that gives the type of report being provided.
Enumerated Report types
Report indicates a Reading, as from a meter. Readings are moments in time--changes over time can be computed from the difference between successive readings. Payload Type is Float
Report indicates an amount of units (denominated in Itembase or in the EMIX Product) over a period. Payload Type is Quantity. A typical ItemBase is Real Energy.
Report indicates an amount of units (denominated in Itembase or in the EMIX Product). Payload Type is Quantity. A typical ItemBase is Real Power.
Report indicates the amount (denominated in Itembase or in the EMIX Product) currently set. May be a confirmation/return of the setpoint control value sent from the VTN. Payload Type is Quantity. A typical ItemBase is Real Power.
Change in Usage as compared to the Baseline. See usage for more information
Changes in Setpoint from previous schedule.
Change in Demand as compared to the Baseline. See Demand for more information
Can be Demand or Usage, as indicated by ItemBase. Indicates what [measurement[ would be if not for the Event or Regulation. Report is of the format Baseline.
Difference between some instruction and actual state.
Average usage over the duration indicated by the Granularity. See usage for more information,
Average usage over the duration indicated by the Granularity. See demand for more information.
Generalized state of a resource such as on/off, occupancy of building, etc. No ItemBase is relevant. Requires an Application Specific Payload Extension.
Up Regulation capacity available for dispatch, expressed in EMIX Real Power. Payload is always expressed as positive Quantity.
Down Regulation capacity available for dispatch, expressed in EMIX Real Power. Payload is always expressed as positive Quantity.
Regulation setpoint as instructed as part of regulation services
Stored Energy is expressed as as Real Energy and Payload is expressed as a Quantity.
Target Energy is expressed as as Real Energy and Payload is expressed as a Quantity.
Capacity available for further energy storage, perhaps to get to Target Energy Storage
Price per ItemBase at each Interval
Simple level from market at each Interval. Itemabse is not relevant.
Pattern used for extending string enumeration, where allowed
Pattern used for extending string enumeration, where allowed