1. ESPI MODELING WITH ENTERPRISE ARCHITECT NAESB ESPI Meeting 20110201 Marty Burns 2/16/20161

2. ●Posted on the TWiki is the next evolution of the ESPI model. o Link to the page http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP10ESPIWork inghttp://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP10ESPIWork ing o Link to the model file http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/PAP10ESPIWork ing/Energy_Services_Provider_Interface_Model.eap.http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/PAP10ESPIWork ing/Energy_Services_Provider_Interface_Model.eap ● The following modeling elements were constructed: o Actors o Use Cases o Interfaces for messaging o Information models for exchange o Sequence diagrams for implementing the use cases ●I have completed one Use Case – Use Case 1 - Retail Customer Establishes Relationship vi a Resource Custodian. I would like to attract any feedback I can on this. Once agreed on t he method and implementation style, I should be able to complete the remaining Use Ca ses by the next meeting. ●What does this mean? The ESPI Use Cases will be complete in breaking down the inform ation needed for exchange and the services needed to be implemented according to the Use Cases. The committee can then define in greater detail the information models of “R EQ.21.4 Models”. Additionally, the services defined in the model (which can be shown to implement the use cases with accuracy) can then be formed into “RESTful” and “WS” ver sions to accomplish the equivalent function. 2/16/2016 2 O VERVIEW OF ESPI M ODELING T ASK

3. 2/16/2016 3 M ODEL C ORRESPONDENCE TO R ECOMMENDATION 21 Current Recommendation 21 EA Model for REQ 21

4. 2/16/2016 4 U SE C ASE S UMMARY D IAGRAM

5. 2/16/2016 5 A CTOR D EFINITIONS AND I NTERFACES

6. 2/16/2016 6 S ERVICE D EFINITIONS

7. 2/16/2016 7 S EQUENCE D IAGRAM : U SE C ASE 1 1.Retail Customer requests that the Data Custodian establish a new data access relationship. 2.Data Custodian presents the Retail Customer with a list of resources that can be shared with Third Parties. Any additional attributes (e.g., duration for which permission should be granted) that can be selected are also presented. 3.Retail Customer selects a resource to share, sets any available attributes for the relationship, and specifies a Third Party that is known to the Data Custodian. Selecting these parameters and completing the interaction indicates permission for the Data Custodian to grant the specified Third Party access to the specified shared resource. 4.The relationship will only be created if the Data Custodian accepts the selections for the Third Party (e.g., a Data Custodian may constrain access to certain resource attributes depending on resource sensitivity). 5.Data Custodian generates a Shared Resource Key for this relationship and provides it to the Retail Customer. Each Shared Resource Key is unique to the relationship between a Retail Customer, Data Custodian, and Third Party for a particular resource. 6.Data Custodian notifies Retail Customer of the creation of the Shared Resource Key and establishment of the relationship. No acknowledgment or confirmation is required. 7.Retail Customer requests that the Third Party complete the establishment of the new data access relationship. 8.Retail Customer provides the Shared Resource Key to the Third Party. 9.Third Party persists the Shared Resource Key, associating it with its relationship with the Retail Customer.