RE: [energyinterop] Actors, Registration, and Enrollment

Comments:

ActorID.

I fail to see the benefit of introducing the ActorID into this discussion.

Please see the following glossary description in the attached Ei Glossary Draft from the Registration and Party ID discussion of 7/28 and 7/29

Party

A Party is a customer or business entity. A Party establishes an identity for itself including one or more PartyIDs and associated Account IDs with a registration authority. The registration authority may be independent or operated by other Parties. A Party may enroll in Markets (ISOs, tariffs, bilateral trading agreements, programs, etc.). A Party may receive IDs relevant to a specific Market via enrollment/registration. A Party also may be a DR Operator under contract to operate a DR Program for a utility or ISO.

Enrollment:

“ A Party may enroll Resources”. This statement cannot stand alone unless one states what the Resource is being enrolled in. Establishing a Resource ID with a Registrar is ok as suggested, but that is not enrollment.

A Party should be able to establish Resource IDs without supporting a VEN interface. For example, a solar PV installation may not need a VEN unless it is somehow required by a distribution or transmission grid operator. Yet it may be useful to register the resource so that any buyers of energy from a party holding that resource will know the source.

“A Resource (as defined in EMIX) is something that the VEN chooses to expose to a VTN” . “EMIX does not define a Resource. EMIX defines Resource Descriptions and Resource Offers. See below for the description of a Resource from the Draft EI Glossary attached.

Resource

A Party may identify and register Resources (each with associated premise address and measurement point). A Party may also own zero Resources, such as a typical purchasing customer or a Party or trading in the wholesale forward markets (however a purchasing customer would have a premise address and measurement point.)

A customer may also enroll as a Participant in DR Programs each with a DR Operators. For each DR Program, a customer may register a DR Resource.

A DR Operator may aggregate DR Resources of its Participants and present a DR Resource to an ISO.

The EMIX Resource.xsd model describes a range of potential operational responses for any resource. The model allows parties to describe a wide range of operations, both generation and curtailment. [EMIX Section 13]. Resources may represent a generator or a load response or aggregations. In interactions involving Resources it may be useful to describe either (1) the proposed or actual operation of a Resource, or (2) the range of capability of a Resource. EMIX Resource Descriptions are an extension of the EMIX Product Description. A Product is a description of place, commodity and schedule (intervals) in the context of a tender or transaction.
A Resource must have an associated measurement point. For a physical generator or facility providing DR, this may be the utility meter. It could also be an aggregation of meter data for an aggregated Resource. Or it could be a sub-meter value or estimated measurement value (no real sensor) for some real or virtual generator within a facility.

“Such a Party (hereafter “VEN”) uses its VEN interfaces to Enroll. “. A Party remains a Party. A Party may offer registered Resources in the role of a VEN in an “VTN/VEN Agreement” with another Party that plays the role of a VTN. See definitions from attached EI Glossary Draft.

VTN

A VTN is a Party acting in the role of a Resource Manager or Operator (including an ISO) for one or more Resources, Generation or DR.

VEN

A VEN is a Resource, Generation or DR owned by a Party. The Party responsible for a VEN may in turn be a VTN to other Resources or VTNs.

Certainly a Party can register 0 to many Resources. Each Resource may or may not be enrolled in a VTN/VEN Agreement.

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: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Sunday, August 07, 2011 1:55 PM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] Actors, Registration, and Enrollment

Thanks to Joshua and Bill for considerable time spent Thursday afternoon.

Actor ID:

An Actor gets a name from a naming authority and thereafter has an Actor ID. The recommended Actor ID is of the format URI/string – in which the URI is the naming authority, and the string is the name assigned by that authority. An MRID is a valid Actor ID. An EMS Software vendor could be a Naming Authority, with the string being the [license] assigned during registration. An Actor ID MUST be globally unique, with collisions managed by the naming authorities. How an Actor gets an Actor ID is out of scope.

Registration:

An Actor Registers with the Registrar for a market context and is assigned a Party ID. A Party ID is unique for interactions within that context. If a market rule declares that Party IDs must be valid across market contexts, that is the responsibility of the Registrar. Registration establishes the basic business participation in a context. Registration may require considerable out-of-band interactions, including perhaps bonding, proof of insurance, posting of letters of credit. It may be possible for an Actor to declare itself as a subsidiary of an existing Customer of the Registrar/Market Context, assuming the role of Customer makes sense in that Context.

Because of this potential gap and out-of-band requirements, Registration has two parts: “EiRegistrationRequest”/ “EiRegistrationRequested” initiated by the Actor, and “EiRegistrationComplete”/”EiRegistrationCompleted” initiated by the Registrar. The Registrar may also send “EiRegistrationDenial”/” EiRegistrationDenied”.

“EiRegistrationComplete” includes assignment of a PartyID for use in the context. The recommended Party ID is of the format URI/string – in which the URI is the registrar or market context and the string is the name assigned by the Registrar.

An Actor may request assignment of an existing PartyID to itself. This covers the use case of upgraded or replaced software or equipment.

An Actor may request simultaneous assignment of an Actor ID and of a PartyID.

Enrollment

A Party may enroll Resources. A party is responsible creating locally unique identities for each resource. A Globally unique Resource ID can be constructed from the Party Id and the Resource Id. A Party that wishes to Enroll a Resource must support the VEN interfaces. Such a Party (hereafter “VEN”) uses its VEN interfaces to Enroll.

A VEN may have zero to many Resources. A VEN can enroll and unenroll each Resource. A Resource (as defined in EMIX) is something that the VEN chooses to expose to a VTN. For what reason, and in accord with what rules the VEN makes this decision is out of scope.

A Party acting as a VEN can request a list of VTNs that it will interact with. The pattern is analogous to DNS Servers, in which the client has a Primary DNS server, and a list of Alternate DNS Servers. In an analogous way, a Registrar can inform a VEN of a primary and alternate VTNs.

A Registrar MAY require out of band information before completing Resource Enrollment by a VEN. Because of this potential gap and out-of-band requirements, Enrollment has two parts: “EiEnrollmentRequest”/ “EiEnrollmentRequested” initiated by the Actor, and “EiEnrollmentComplete”/” EiEnrollmentCompleted” initiated by the Registrar. The Registrar may also send “EiEnrollmentDenial”/” EiEnrollmentDenied”.

Resources and VENs.

When we combine the above with the statements about Resources from the other day, we have:

1) A single VEN may register Zero to many resources. It can add new ones or remove old ones.

2) The set of Resources revealed to a particular partner (VTN) are solely those that the VEN wishes to offer. Whether a there is a one-to-one correspondence between any piece of equipment and a resource publication is entirely up to the VEN and what it wishes to advertise.

3) A VEN may display different resources to different Market Contexts.

4) A VEN MAY split its service offerings into multiple Resources because of different grid-relevant characteristics OR for characteristics relevant to its internal decision making and user interfaces (say floors of a commercial building), as meets the needs of the VEN

5) A Resource may have multiple end-points specified. Each of these is a WS Addressing Points

6) All end points of a Resource SHALL receive the same operational messages from the VTN.

7) One end point SHALL receive the Administrative interactions for the Resource. This end point MAY be the sole Operational End Point.

8) If the Party exposing a VEN surface to an external VTN, is itself exposing a VTN surface to manage its internal market, the external VTN cannot “drill down” to those internal VEN interfaces, except to the extent that the external VEN chooses to offer them as Resources.

"If something is not worth doing, it`s not worth doing well"
Peter Drucker

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

energyinterop message