Anda di halaman 1dari 210

Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory

Title: Open Automated Demand Response Communications Specification (Version 1.0) Author: Piette, Mary Ann Publication Date: 05-04-2009 Publication Info: Lawrence Berkeley National Laboratory Permalink: http://escholarship.org/uc/item/7hf814m5

eScholarship provides open access, scholarly publishing services to the University of California and delivers a dynamic research platform to scholars worldwide.

Open Automated Demand Response Communications Specification (Version 1.0)

Mary Ann Piette, Girish Ghatikar, Sila Kiliccote, Peter Palensky, Charles McParland Lawrence Berkeley National Laboratory

Ed Koch, Dan Hennage Akuacom

The work described in this report was coordinated by the Demand Response Research Center and funded by the California Energy Commission (Energy Commission), Public Interest Energy Research (PIER) Program, under Work for Others Contract No. 500-03-026 and by the U.S. Department of Energy under Contract No. DE-AC02-05CH11231.

DISCLAIMER
This report was prepared as the result of work sponsored by the California Energy Commission. It does not necessarily represent the views of the Energy Commission, its employees or the State of California. The Energy Commission, the State of California, its employees, contractors and subcontractors make no warrant, express or implied, and assume no legal liability for the information in this report; nor does any party represent that the uses of this information will not infringe upon privately owned rights. This report has not been approved or disapproved by the California Energy Commission nor has the California Energy Commission passed upon the accuracy or adequacy of the information in this report.

Disclaimer
ThisdocumentwaspreparedasanaccountofworksponsoredbytheUnitedStates Government.Whilethisdocumentisbelievedtocontaincorrectinformation,neitherthe UnitedStatesGovernmentnoranyagencythereof,norTheRegentsoftheUniversityof California,noranyoftheiremployees,makesanywarranty,expressorimplied,or assumesanylegalresponsibilityfortheaccuracy,completeness,orusefulnessofany information,apparatus,product,orprocessdisclosed,orrepresentsthatitsusewould notinfringeprivatelyownedrights.Referencehereintoanyspecificcommercial product,process,orservicebyitstradename,trademark,manufacturer,orotherwise, doesnotnecessarilyconstituteorimplyitsendorsement,recommendation,orfavoring bytheUnitedStatesGovernmentoranyagencythereof,orTheRegentsofthe UniversityofCalifornia.Theviewsandopinionsofauthorsexpressedhereindonot necessarilystateorreflectthoseoftheUnitedStatesGovernmentoranyagencythereof orTheRegentsoftheUniversityofCalifornia. ErnestOrlandoLawrenceBerkeleyNationalLaboratory Attention:MaryAnnPiette DemandResponseResearchCenter OneCyclotronRoad,MS90R3111 Berkeley,CA94720.UnitedStatesofAmerica Email:AutoDR@lbl.gov Website:http://openadr.lbl.gov/

Acknowledgements
TheworkdescribedinthisreportwascoordinatedbytheDemandResponseResearch CenterandfundedbytheCaliforniaEnergyCommission(EnergyCommission),Public InterestEnergyResearch(PIER)Program,underWorkforOthersContractNo.50003 026andbytheU.S.DepartmentofEnergyunderContractNo.DEAC0205CH11231. TheauthorswouldliketothanktheTechnicalAdvisoryGroup(listedbelow)fortheir assistanceinthisdocument.WealsowanttoacknowledgeChrisScruton,IvinRhyne, KristyChew,MarthaBrook,andMikeGravelyattheCaliforniaEnergyCommission alongwithRonHofmannandRogerLevy,consultantstotheCaliforniaEnergy CommissionandLBNL,andDavidWatson,formerLBNLemployee,fortheirongoing support.WealsowanttothankNanceMatsonforherassistanceinfinalizingthis document.

Preface
TheCaliforniaEnergyCommissionsPublicInterestEnergyResearch(PIER)Program supportspublicinterestenergyresearchanddevelopmentthatwillhelpimprovethe qualityoflifeinCaliforniabybringingenvironmentallysafe,affordable,andreliable energyservicesandproductstothemarketplace. ThePIERProgramconductspublicinterestresearch,development,anddemonstration (RD&D)projectstobenefitCalifornia. ThePIERProgramstrivestoconductthemostpromisingpublicinterestenergyresearch bypartneringwithRD&Dentities,includingindividuals,businesses,utilities,and publicorprivateresearchinstitutions. PIERfundingeffortsarefocusedonthefollowingRD&Dprogramareas: BuildingsEndUseEnergyEfficiency EnergyInnovationsSmallGrants EnergyRelatedEnvironmentalResearch EnergySystemsIntegration EnvironmentallyPreferredAdvancedGeneration Industrial/Agricultural/WaterEndUseEnergyEfficiency RenewableEnergyTechnologies Transportation

OpenAutomatedDemandResponseCommunicationsSpecificationisthefinalreportforthe OpenAutomatedDemandResponseprojectbytheDemandResponseResearchCenter (contractnumber50003026),conductedbyLawrenceBerkeleyNationalLaboratory. TheinformationfromthisprojectcontributestoPIERsEnergySystemsIntegration Program. FormoreinformationaboutthePIERProgram,pleasevisittheEnergyCommissions Websiteatwww.energy.ca.gov/research/orcontacttheEnergyCommissionat 9166544878.

Table of Contents
ABSTRACT................................................................................................................................................ IX EXECUTIVESUMMARY.......................................................................................................................... 1 PATENTS..................................................................................................................................................... 3 PARTICIPANTS ......................................................................................................................................... 4 TECHNICALADVISORYGROUP ........................................................................................................ 4 1 2 INTRODUCTION............................................................................................................................. 5 SCOPE................................................................................................................................................. 9

2.1 2.2
3 4

Purpose ......................................................................................................................... 9 Reason........................................................................................................................... 9

NORMATIVEREFERENCES ....................................................................................................... 11 USEOFTHISSPECIFICATION.................................................................................................. 13

4.1 4.2
5

ImplementingDRASInterface ................................................................................ 14 ProperUseandCitation........................................................................................... 15

DRASREQUIREMENTS .............................................................................................................. 17

5.1 5.2
5.2.1 5.2.1 5.2.2

GeneralRoleofDRASinDemandResponseProgramsandDynamicPricing 17 UseCases.................................................................................................................... 17
UseCaseScenarios ............................................................................................................... 17 UseCaseScenarios ............................................................................................................... 18 GeneralizedUseCasesforDRPrograms ............................................................................. 19

5.3
6

OverallRequirements............................................................................................... 32

SPECIFICATIONS.......................................................................................................................... 33

6.1 6.2 6.3


6.3.1 6.3.2 6.3.3 6.3.4

AutomatedDemandResponseArchitecture ........................................................ 33 GeneralRequirements .............................................................................................. 35 CommonRequirements ........................................................................................... 36


DRASUserAccountsandSecurityRoles ........................................................................... 36 LogsandReports .................................................................................................................. 37 OperatorNotifications.......................................................................................................... 38 Testing.................................................................................................................................. 39

6.4
6.4.1 6.4.2 6.4.3

IntroductiontoDataEntitiesUsedByInterfaceFunctions................................. 39
DataEntitiesinSupportofUtilityandISOUseCaseActions........................................... 40 DataEntitiesinSupportofParticipantOperatorFunctions .............................................. 46 DataEntitiesInSupportofDRASClientFunctions .......................................................... 52

6.5
6.5.1

DREventModels ...................................................................................................... 53
UtilityorISOViewofaDREvent ...................................................................................... 54

iii

6.5.2 6.5.3

PropagationofDREventsbytheDRAS ............................................................................. 57 DRASClientViewofDREvents......................................................................................... 72

6.6
7

DRAutomatedBiddingModels ............................................................................. 82

FUNCTIONALSPECIFICATIONS ............................................................................................. 87

7.1
7.1.1 7.1.2 7.1.3 7.1.4

UtilityorISOOperatorFunctions .......................................................................... 87
UtilityorISOHandlingDREvents.................................................................................... 87 UtilityorISOSupportforAutomatedBidding ................................................................... 88 UtilityorISOConfigureDRAS .......................................................................................... 89 UtilityorISOMonitoringofDRASRelatedActivities ...................................................... 91

7.2 7.3
7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 8

DRASClientFunctions............................................................................................. 91 ParticipantOperatorFunctions............................................................................... 93
OptingOutofDREvents .................................................................................................... 93 SubmittingFeedback(FacilityStatus)toDRAS ................................................................. 94 AutomatedBidding .............................................................................................................. 94 ConfigurationofParticipantRelatedInformationinDRAS ............................................... 95 MonitoringofDRASRelatedActivities .............................................................................. 98 InstallationandTestingofDRASClients ........................................................................... 98

DETAILEDDATAMODELSANDSCHEMAS ..................................................................... 101

8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12
9

UtilityProgram......................................................................................................... 101 UtilityDREvent ........................................................................................................ 101 ResponseSchedule................................................................................................... 101 ProgramConstraint ................................................................................................. 101 ParticipantAccount ................................................................................................. 101 OptOutState ............................................................................................................. 101 Logs ........................................................................................................................... 101 Feedback................................................................................................................... 101 EventInfo .................................................................................................................. 102 DRASClient .............................................................................................................. 102 Bid ............................................................................................................................. 102 EventState................................................................................................................. 102

DETAILEDAPISPECIFICATIONS.......................................................................................... 103

9.1 9.2 9.3


9.3.1 9.3.2 9.3.3 10

UtilityProgramOperatorAPIs ............................................................................. 103 ParticipantOperatorAPIs...................................................................................... 103 DRASClientAPIs ................................................................................................... 103


UseofSimpleRESTServicestoExchangeDREventStateInformation ........................... 104 UseofSimpleSOAPServicestoExchangeDREventStateInformation .......................... 105 UseofBACnetWebServicestoExchangeDREventStateInformation............................ 107

SECURITYPOLICY...................................................................................................................... 111

10.1 10.2

Scope ......................................................................................................................... 111 AccessControlandSecurityRoles ....................................................................... 111

11FUTUREDEVELOPMENTS........................................................................................................ 115

iv

12DEFINITIONS,ACRONYMSANDABBREVIATIONS...................................................... 117 APPENDIXA:XSDSCHEMAFILES ............................................................................................APA1 APPENDIXB:WSDLINTERFACEFILES.................................................................................... APB1 APPENDIXC:SECURITYANALYSISANDREQUIREMENTS.............................................APC1 APPENDIXD:DRPROGRAMUSECASES .............................................................................. APD1

List of Figures

Figure1. Figure2. Figure3. Figure4. Figure5. Figure6. Figure7. Figure8. Figure9. Figure10. Figure11. Figure12. Figure13. Figure14. Figure15. Figure16. Figure17. Figure18. Figure19. Figure20. Figure21. Figure22. Figure23. Figure24. Figure25. Figure26. Figure27. Figure28. Figure29. Figure30.

DRASClientInterfaces.............................................................................. 14 AutomatedGenericEventBasedProgram(GEBP)UseCase............. 24 GenericBiddingProcess(GBP)................................................................ 29 GeneralAutomatedEventsArchitecturewithStandaloneDRAS ..... 34 GeneralAutomatedBiddingArchitecturewithStandaloneDRAS ... 34 UseCaseReferencestoFunctionalSpecification .................................. 35 UtilityIssuedDREventEntity................................................................. 42 UtilityConfigurationEntities................................................................... 45 UtilityLogsandClientAlarms ................................................................ 46 ParticipantConfigurationEntities....................................................... 48 ParticipantSubmitBidEntity............................................................... 49 ParticipantOptOutEntities................................................................. 50 ParticipantFeedbackEntities ............................................................... 51 ClientAlarmsandUtilityLogs ............................................................ 52 DRASClientDREventStateEntities.................................................. 53 DREventModel(UtilityorISOView) ............................................... 55 StateTransitionDiagram ...................................................................... 55 RelevantAttributesandStructuresforEventPropagation ............. 58 SampleConfigurationParticipantAccountsandDRASClients.. 60 DREventPropagationforProgramP2AllParticipantAccounts . 61 DREventPropagationforProgramP2.................................................. SpecificParticipantAccountsA3,A4................................................ 62 DREventPropagationforProgramP1................................................... SpecificParticipantAccountA1 ........................................................ 63 DREventPropagationforProgramP2GroupsG2,G4 .................. 64 DREventPropagationforProgramP2................................................... SpecificDRASClientsC1,C4,C5 ...................................................... 65 DREventPropagationforProgramP2................................................... SpecificLocationsL1,L3..................................................................... 66 DREventPropagationforProgramP2................................................... GroupsG2andParticipantsA4Specified........................................ 67 DREventConstraintModel .................................................................... (WhichDRASClientsReceivetheEvent) .......................................... 69 ProgramConstraintsandFilters.......................................................... 70 DREventWindowDependingUponFilterConstraints ................. 71 DREventNotificationTimeDependingUponFilterConstraints.. 72

vi

Figure31. Figure32. Figure33. Figure34. Figure35. Figure36. Figure37. Figure38. Figure39. Figure40. Figure41. Figure42. Figure43. Figure44. Figure45.

DR Event Duration Depending Upon Duration Constraints..................... 72 PUSHModelSequenceDiagram......................................................... 74 PULLModelSequenceDiagram ......................................................... 74 DREventStateModel(SimpleClientView) ..................................... 80 DREventModel(UtilityorISOView) ............................................... 80 TransitionDiagramforaGeneralDREvent...................................... 81 DRASClientDREventStateSimpleDRAS .......................................... ClientStateTransitionDiagram .......................................................... 82 StateTransitionDiagramforaParticipantsBidState ..................... 84 BiddingSequenceDiagram .................................................................. 85 RESTDRASClientPULLInteractionSequenceDiagram ............. 104 SimpleSOAPPUSHModelSequenceDiagram.............................. 106 SimpleSOAPPULLModelSequenceDiagram .............................. 106 BWSPUSHModelSequenceDiagram ............................................. 108 BWSPULLModelSequenceDiagram.............................................. 108 DRASCommunicationPartnerswithDifferentSecurityLevels .. 114

List of Tables
Table 1 Table 2 Table 3 Table 4 Table 5

Relevant Sections of the Specification ......................................................... 13 DR Program Execution ................................................................................. 21 OperationStateSpec Entity ............................................................................ 79 Required Services and Supported Communication Models ....................... 104 Security Roles of Interfaces ........................................................................ 112

vii

viii

Abstract
ThedevelopmentoftheOpenAutomatedDemandResponseCommunications Specification,alsoknownasOpenADRorOpenAutoDR,beganin2002followingthe Californiaelectricitycrisis.TheworkhasbeencarriedoutbytheDemandResponse ResearchCenter(DRRC),whichismanagedbyLawrenceBerkeleyNationalLaboratory. Thisspecificationdescribesanopenstandardsbasedcommunicationsdatamodel designedtofacilitatesendingandreceivingdemandresponsepriceandreliability signalsfromautilityorIndependentSystemOperatortoelectriccustomers.OpenADR isoneelementoftheSmartGridinformationandcommunicationstechnologiesthatare beingdevelopedtoimproveoptimizationbetweenelectricsupplyanddemand.The intentionoftheopenautomateddemandresponsecommunicationsdatamodelisto provideinteroperablesignalstobuildingandindustrialcontrolsystemsthatarepre programmedtotakeactionbasedonademandresponsesignal,enablingademand responseeventtobefullyautomated,withnomanualintervention.TheOpenADR specificationisaflexibleinfrastructuretofacilitatecommoninformationexchange betweentheutilityorIndependentSystemOperatorandenduseparticipants.The conceptofanopenspecificationisintendedtoallowanyonetoimplementthesignaling systems,theautomationserverortheautomationclients.


Keywords:demandresponse,buildings,electricityuse,automation,communications, openstandards,datamodels,specifications.

ix

Executive Summary
ThedevelopmentoftheOpenAutomatedDemandResponseCommunications Specification,alsoknownasOpenADRorOpenAutoDR,beganin2002followingthe Californiaelectricitycrisis.InCalifornia,theUnitedStates,andabroadmanyutilities, governments,electricIndependentSystemsOperatorsandothershavebeenpursuing demandresponsetomanagethegrowingdemandforelectricityandpeakcapacityof theelectricsystems.DemandResponse(DR)hasbeendefinedasactiontakento reduceelectricitydemandinresponsetoprice,monetaryincentives,orutilitydirectives soastomaintainreliableelectricserviceoravoidhighelectricityprices 1.OpenADRis oneelementoftheSmartGridinformationandcommunicationstechnologiesthatare beingdevelopedtoimproveoptimizationbetweenelectricsupplyanddemand. TheresearchthatledtothisdocumentwasfundedbytheCaliforniaEnergy CommissionsPublicInterestEnergyResearchProgram.Theworkhasbeencarriedout bytheDemandResponseResearchCenter(DRRC)whichismanagedbyLawrence BerkeleyNationalLaboratory.Theinitialgoaloftheresearchwastoexplorethe feasibilityofdevelopingalowcostcommunicationsinfrastructuretoimprovethe reliability,repeatability,robustness,andcosteffectivenessofdemandresponsein commercialbuildings.Onekeyresearchquestionwas:couldtodayscommunications andinformationtechnologiesbeusedtoautomatedemandresponseoperationsof commercialbuildingsusingstandardizedelectricitypriceandreliabilitysignals?Six yearsofresearch,development,anddemonstrationhaveledtothisopendatamodel. Thisdocumentoutlinesacommunicationsspecificationtoexchangesignalstoenable demandresponseinenduseparticipantorcustomersystems. OpenAutomatedDemandResponseisacommunicationsdatamodeldesignedto facilitatesendingandreceivingofDRsignalsfromautilityorindependentsystem operatortoelectriccustomers.Theintentionofthedatamodelistointeractwith buildingandindustrialcontrolsystemsthatarepreprogrammedtotakeactionbased onaDRsignal,enablingademandresponseeventtobefullyautomated,withno manualintervention.TheOpenADRspecificationisahighlyflexibleinfrastructure designtofacilitatecommoninformationexchangebetweenautilityorIndependent SystemOperatorandtheirenduseparticipants.Theconceptofanopenspecificationis intendedtoallowanyonetoimplementthesignalingsystems,theautomationserveror theautomationclients. DefinitionofOpenAutomatedDemandResponseCommunications OpenADRCommunicationshavethefollowingdefiningfeatures:
U.S.FederalEnergyRegulatoryCommission(FERC),2007AssessmentofDemandResponseand AdvancedMetering,StaffReport,available:http://www.ferc.gov/legal/staffreports/0907demand response.pdf.
1

Continuous,Secure,andReliableProvidescontinuous,secure,andreliable twowaycommunicationsinfrastructureswheretheclientsattheendusesite receiveandacknowledgetotheDRautomationseveruponreceivingtheDR eventsignals. TranslationTranslatesDReventinformationtocontinuousInternetsignalsto facilitateDRautomation.ThesesignalsaredesignedtointeroperatewithEnergy ManagementandControlSystems,lighting,orotherendusecontrols. AutomationReceiptoftheexternalsignalisdesignedtoinitiateautomation throughtheuseofpreprogrammeddemandresponsestrategiesdeterminedand controlledbytheenduseparticipant. OptOutProvidesoptoutoroverridefunctiontoparticipantsforaDReventif theeventcomesatatimewhenreductioninenduseservicesisnotdesirable. CompleteDataModelDescribesarichdatamodelandarchitectureto communicateprice,reliability,andotherDRactivationsignals. ScalableArchitectureProvidesscalablecommunicationsarchitectureto differentformsofDRprograms,endusebuildings,anddynamicpricing. OpenStandardsOpenstandardsbasedtechnologysuchasSimpleObject AccessProtocol(SOAP)andWebservicesformthebasisofthecommunications model.

OpenADRhasbeenfieldtestedinanumberofDRprogramsinCalifornia.Whilethe scopeofthiscommunicationsspecificationfocusesonsignalsforDReventsandprices, significantresearchhasexploredthecontrolsstrategiesandtechniquestoautomatedDR incommercialbuildingsandindustrialfacilities.Thisspecificationalsocoversthe signalingdatamodelanddoesnotcoverinformationrelatedtospecificDRelectric reductionorshiftingstrategies. TheOpenAutoDRCommunicationsSpecificationisdesignedtofacilitateautomating demandresponseactionsatthecustomerlocation,whetheritiselectricloadsheddingor shifting.Weareoftenaskedifthecommunicationsdatamodelcanbeusedfor continuousoperations,everyday.Theanswerisyes.ManyemergencyorreliabilityDR eventsoccuratspecifictimeswhentheelectricgridisstrained.TheOpenAutoDR communicationsaredesignedtocoordinatesuchsignalstobuildingorindustrialcontrol systems.OpenAutoDRisalsodesignedtoprovidecontinuousdynamicpricesignals suchashourlydayaheadordayofrealtimepricing.Withsuchpriceinformationan automatedclientcanbedesignedtocontinuouslymonitorthesepricesandtranslatethis informationintocontinuousautomatedcontrolandresponsestrategieswithinafacility. PotentialBenefits OpenADRwillprovidebenefitstoCaliforniabybothincreasingthenumberoffacilities thatparticipateindemandresponse,andreducingthecosttoconductfrequentand persistentparticipationindemandresponse.FurthermoreOpenADRwillimprovethe

feasibilityofachievingthestatespolicygoalsofmovingtowarddynamicpricing,such ascriticalpeakorrealtimepricing,forallcustomers.Increasingparticipationin demandresponsereducestheneedfornewelectricsupply,reducestheneedfornew transmissionanddistributionsystems,andhelpsreduceoverallelectricityprices. TheOpenADRCommunicationsSpecificationprovidesthefollowingbenefits: OpenSpecificationProvidesastandardizedDRcommunicationsandsignaling infrastructureusingopen,nonproprietary,industryapproveddatamodelsthat canbeimplementedforbothdynamicpricesandDRemergencyorreliability events. FlexibilityProvidesopencommunicationsinterfacesandprotocolsthatare flexible,platformindependent,interoperable,andtransparenttoendtoend technologiesandsoftwaresystems. InnovationandInteroperabilityEncouragesopeninnovationand interoperability,andallowscontrolsandcommunicationswithinafacilityor enterprisetobuildonexistingstrategiestoreducetechnologyoperationand maintenancecosts,strandedassets,andobsolesceintechnology. EaseofIntegrationFacilitatesintegrationofcommonEnergyManagementand ControlSystems(EMCS),centralizedlighting,andotherendusedevicesthatcan receivearelayorInternetsignals(suchaseXtensibleMarkupLanguge[XML]). RemoteAccessFacilitatesoptoutoroverridefunctionsthroughaparticipant WebportaltomanagestandardizedDRrelatedoperationmodestoDRstrategies andcontrolsystems.

FutureResearch TheDRRCwillcontinuetoconductresearchtosupportbroaderdevelopmentand deploymentofOpenADR.Futureworkwillincludecontinuedcollaborationwithformal industrystandardsdevelopmentorganizationstoharmonizethesedatamodelswith relatedefforts.TheDRRCwillalsocontinuetoevaluateenduseDRcontrolstrategies forhomes,largeandsmallcommercialbuildings,andindustrialfacilities. Patents Attentioniscalledtothepossibilitythatimplementationofthisspecificationmay requireuseofsubjectmattercoveredbypatentrights.Bypublicationofthis specification,nopositionistakenwithrespecttotheexistenceorvalidityofanypatent rightsinconnectiontherewith.TheCaliforniaEnergyCommission,LawrenceBerkeley NationalLaboratory,andtheDemandResponseResearchCentershallnotbe responsibleforidentifyingpatentsorpatentapplicationsforwhichalicensemaybe requiredtoimplementthisspecificationorforconductinginquiriesintothelegal validityorscopeofthosepatentsthatarebroughttoitsattention.

Participants TheOpenADRWorkingGrouphadthefollowingmembers: EdKoch,Chair,Akuacom GirishGhatikar,LBNL DanHennage,Akuacom SilaKiliccote,LBNL MaryAnnPiette,LBNL PeterPalensky, Univ.ofPretoria DavidHolmberg,NIST DaveRobin, AutomatedLogic Controls JimButler,Cimetrics CharlesMcParland,LBNL

TechnicalAdvisoryGroup
ThefollowingmembersoftheTechnicalAdvisoryGroup(TAG)membershadexecutive oversightoftheOpenADRspecificationandcontributedbyreviewandapprovalofthe specification.Someorganizationsandaffiliationshavedeputiesforcontinued participationandvoting.
Organization Pacific Gas and Electricity Pacific Gas and Electricity Southern California Edison Southern California Edison San Diego Gas and Electric San Diego Gas and Electric California Independent Systems Operator California Independent Systems Operator National Institute of Standards and Technology California Energy Commission Levy Associates California Institute of Energy and Environment California Institute of Energy and Environment University of California Berkeley University of California Berkeley Grid Net Sacramento Municipal Utility District Electric Power Research Institute Electric Power Research Institute EnerNex Corporation EnerNex Corporation Member Peter Chan Albert Chiu Kevin G. Wood Eric Parker Terry Mohn Julia Mendoza Walt Johnson John Goodin David Holmberg Ivin Rhyne Roger Levy Ron Hofmann Gaymond Yee Nate Ota Alex Do David Watson Alvaro Mendoza Bill Howe Chuck Thomas Eric Gunther Grant Gilchrist

Introduction

ThedevelopmentoftheOpenAutomatedDemandResponseCommunications Specification,alsoknownasOpenADRorOpenAutoDR,beganin2002followingthe Californiaelectricitycrisis.InCalifornia,theUnitedStates,andabroadmanyutilities, governments,electricIndependentSystemsOperatorsandothershavebeenpursuing demandresponsetomanagethegrowingdemandforelectricityandpeakcapacityof theelectricsystems.DemandResponse(DR)hasbeendefinedasactiontakento reduceelectricitydemandinresponsetoprice,monetaryincentives,orutilitydirectives soastomaintainreliableelectricserviceoravoidhighelectricityprices 1.OpenADRis oneelementoftheSmartGridinformationandcommunicationstechnologiesthatare beingdevelopedtoimproveoptimizationbetweenelectricsupplyanddemand. TheresearchthatledtothisdocumentwasfundedbytheCaliforniaEnergy CommissionsPublicInterestEnergyResearchProgram.Theworkhasbeencarriedout bytheDemandResponseResearchCenter(DRRC)whichismanagedbyLawrence BerkeleyNationalLaboratory.Theinitialgoaloftheresearchwastoexplorethe feasibilityofdevelopingalowcostcommunicationsinfrastructuretoimprovethe reliability,repeatability,robustness,andcosteffectivenessofdemandresponsein commercialbuildings.Onekeyresearchquestionwas:couldtodayscommunications andinformationtechnologiesbeusedtoautomatedemandresponseoperationsof commercialbuildingsusingstandardizedelectricitypriceandreliabilitysignals?Six yearsofresearch,development,anddemonstrationhaveledtothisopendatamodel. Thisdocumentoutlinesacommunicationsspecificationtoexchangesignalstoenable demandresponseinenduseparticipantorcustomersystems. OpenAutomatedDemandResponseisacommunicationsdatamodeldesignedto facilitatesendingandreceivingofDRsignalsfromautilityorindependentsystem operatortoelectriccustomers.Theintentionofthedatamodelistointeractwith buildingandindustrialcontrolsystemsthatarepreprogrammedtotakeactionbased onaDRsignal,enablingademandresponseeventtobefullyautomated,withno manualintervention.TheOpenADRspecificationisahighlyflexibleinfrastructure designtofacilitatecommoninformationexchangebetweenautilityorIndependent SystemOperator(ISO)andtheirenduseparticipants.Theconceptofanopen specificationisintendedtoallowanyonetoimplementthesignalingsystems,providing theautomationserverortheautomationclients. OpenADRCommunicationshavethefollowingdefiningfeatures:

Continuous,Secure,andReliableProvidescontinuous,secure,andreliabletwo waycommunicationsinfrastructureswheretheclientsattheendusesitereceive

U.S. Federal Energy Regulatory Commission (FERC), 2007 Assessment of Demand Response and Advanced Metering, Staff Report, available: http://www.ferc.gov/legal/staff-reports/09-07-demandresponse.pdf.

andacknowledgetotheDRautomationseveruponreceivingtheDRevent signals.

TranslationTranslatesDReventinformationtocontinuousInternetsignalsto facilitateDRautomation.ThesesignalsaredesignedtointeroperatewithEnergy ManagementandControlSystems,lighting,orotherendusecontrols. AutomationReceiptoftheexternalsignalisdesignedtoinitiateautomation throughtheuseofpreprogrammeddemandresponsestrategiesdeterminedand controlledbytheenduseparticipant. OptOutProvidesoptoutoroverridefunctiontoparticipantsforaDReventif theeventcomesatatimewhenreductioninenduseservicesisnotdesirable. CompleteDataModelDescribesarichdatamodelandarchitectureto communicateprice,reliability,andotherDRactivationsignals. ScalableArchitectureProvidesscalablecommunicationsarchitectureto differentformsofDRprograms,endusebuildings,anddynamicpricing. OpenStandardsOpenstandardsbasedtechnologysuchasSimpleObject AccessProtocol(SOAP)andWebservicesformthebasisofthecommunications model.

WerefertoOpenADRasacommunicationsdatamodeltofacilitateinformation exchangebetweentwoendpoints,theutilityorISOandthefacility.Itisnotaprotocol thatspecifiesbitstructuresorsemanticsassomecommunicationsprotocolsdo.In somereferencesthetermsystem,technology,orserviceisusedtorefertothe featuresofOpenADR. OpenADRisinuseinover200facilitiesinCaliforniaprovidinganautomationsystem forseveralDRprograms.Theseprogramsprovideover50MWofDRincommercial andindustrialfacilities.SeveralreportspresentthehistoryoftheautomatedDR research 2.Whilethescopeofthiscommunicationsspecificationfocusesonsignalsfor DReventsandprices,significantresearchhasexploredthecontrolsstrategiesand techniquestoautomatedDRincommercialbuildings 3.Thisspecificationalsocoversthe signalingdatamodelanddoesnotcoverinformationrelatedtospecificDRelectric

These reports are available at http://drrc.lbl.gov/drrc-pubsall.html: Piette, M.A., S. Kiliccote, G. Ghatikar, Design and Implementation of an Open, Interoperable Automated Demand Response Infrastructure, Proceedings of the Grid-Interop Forum, October 2007, LBNL-63665. Koch, E., M.A. Piette, Architecture Concepts and Technical Issues for an Open, Interoperable Automated Demand Response Infrastructure. Proceedings of the Grid-Interop Forum,. October 2007. LBNL-63664. Piette, M.A, D. Watson, N. Motegi, S. Kiliccote Automated Critical Peak Pricing Field Tests: 2006 Pilot Program Description and Results. August, 2007. LBNL-62218.

Motegi, N., M.A. Piette, D.S. Watson, S. Kiliccote, P. Xu. Introduction to Commercial Building Control Strategies and Techniques for Demand Response. May 2007. LBNL-59975.

reductionorshiftingstrategies.Thiscommunicationsspecificationhasalsobeenused forautomatingDRinindustrialfacilities. TheOpenAutoDRCommunicationsSpecificationisdesignedtofacilitateautomating demandresponseactionsatthecustomerlocation,whetheritiselectricloadsheddingor shifting.Weareoftenaskedifthecommunicationsdatamodelcanbeusedfor continuousoperations,everyday.Theanswerisyes.ManyemergencyorreliabilityDR eventsoccuratspecifictimeswhentheelectricgridisstrained.TheOpenAutoDR communicationsaredesignedtocoordinatesuchsignalstobuildingorindustrialcontrol systems.OpenAutoDRisalsodesignedtoprovidecontinuousdynamicpricesignals suchashourlydayaheadordayofrealtimepricing.Withsuchpriceinformationan automatedclientcanbedesignedtocontinuouslymonitorthesepricesandtranslatethis informationintocontinuousautomatedcontrolandresponsestrategieswithinafacility. TheOpenAutoDRCommunicationsSpecificationprovidesthefollowingbenefits:

OpenSpecificationProvidesastandardizedDRcommunicationsandsignaling infrastructureusingopen,nonproprietary,industryapproveddatamodelsthat canbeimplementedforbothdynamicpricesandDRemergencyorreliability events. FlexibilityProvidesopencommunicationsinterfacesandprotocolsthatare flexible,platformindependent,interoperable,andtransparenttoendtoend technologiesandsoftwaresystems. InnovationandInteroperabilityEncouragesopeninnovationand interoperability,andallowscontrolsandcommunicationswithinafacilityor enterprisetobuildonexistingstrategiestoreducetechnologyoperationand maintenancecosts,strandedassets,andobsolesceintechnology. EaseofIntegrationFacilitatesintegrationofcommonEnergyManagementand ControlSystems(EMCS),centralizedlighting,andotherendusedevicesthatcan receivearelayorInternetsignals(suchasXML). RemoteAccessFacilitatesoptoutoroverridefunctionsthroughaparticipant WebportaltomanagestandardizedDRrelatedoperationmodestoDRstrategies andcontrolsystems.

Thisreporthasthefollowingstructure.Itbeginswithasectionthatoutlinesthescope, purpose,andreasonfortheOpenADRspecification,followedbyanintroductiontothe useofthespecificationandimplementationconcepts.NextwepresenttheDR AutomationServer(DRAS)requirements,componentandfunctionalspecifications, followedbythedatamodelsandschemas.Thefinalsectionsdiscusstheapplication programinterfaces,securitypolicies,andfutureplans.ThefutureplansforOpenADR includeadditionalcollaborationwithformalstandardsgroups.Asetofappendices containsupportschemaandinterfacefiles,adiscussionofsecurityissues,andDR programusecases.

Scope

TheOpenAutomatedDemandResponseCommunicationsSpecificationdefinesthe interfacetothefunctionsandfeaturesofaDemandResponseAutomationServer (DRAS)thatisusedtofacilitatetheautomationofcustomerresponsetovarious DemandResponseprogramsanddynamicpricingthroughacommunicatingclient.This specification,referredtoasOpenADR,alsoaddresseshowthirdpartiessuchasutilities, ISOs,energyandfacilitymanagers,aggregators,andhardwareandsoftware manufacturerswillinterfacetoandutilizethefunctionsoftheDRASinorderto automatevariousaspectsofdemandresponse(DR)programsanddynamicpricing..

2.1

Purpose

ThesuccessofDRprogramsanddynamicpricingdevelopedbyutilitiesandISOs dependupontimelyandreliablecommunicationsofeventsandinformationtothe participantsthatareparticipatingintheDRprogramsanddynamicpricing.IftheDR communicationsbeingsentcanbeautomaticallytranslatedintoloadshedsorshiftsby theparticipantswithouttheneedforhumanintervention,thentheprocessof participatinginthedemandresponseprogramscanbemademorecosteffective, reliable,andeasytoimplement.ThisOpenADRspecificationprovidesasoftware interoperabilityframework,benefitfacilitiesandpublicorprivateindustry,enable innovation,andeaseavailabilitytothewidestrangeoffacilitiesforthepresentandin thefuture.Thisspecificationdescribesasuiteoffunctionsandcapabilitiesthatwill allowtheautomatedcommunicationsofDRinformationexchangebetweenutilitiesor ISOsandtheirparticipants.OpenADRispartofthenewSmartGridtechnologiessuch asadvancedinformation,control,andcommunicationstechnologies.Thesetechnologies aredesignedtohelpoptimizethelinkagesbetweenelectricsupplyanddemand.

2.2

Reason

Someparticipantssuchasaggregatorsandlargecorporationshavewidespread geographicaloperationsacrossmultipleelectricaljurisdictionsandthusmustdealwith multipleutilities.LikewiseutilitiesandISOsmustperformsystemsintegrationand testingwitheachoftheirparticipantsthatparticipateinaDRprogram.Byusinga standardizedinterchangemechanismliketheDRASacrossmultipleutilitiesand/or ISOs,theeffortandcostofparticipatingindemandresponseprogramsanddynamic pricingwillbelessened.

10

Normative References

Thefollowingreferenceddocumentsareusefulfortheapplicationofthisdocument.For datedreferences,onlytheeditioncitedapplies.Forundatedreferences,thelatestedition ofthereferenceddocument(includinganyamendmentsorcorrigenda)applies.Theuse oftheOpenADRspecificationdoesnotrequireBuildingAutomationControlNETwork (BACnet)implementation. BACnet/WSWebServicesInterface,ANSI/ASHRAEAddendumCcto ANSI/ASHRAEStandard1352004. RequestforComment(RFC):RFC2246:TheTransportLayerSecurity(TLS) ProtocolVersion1.0,InternetEngineeringTaskForce,Jan1999.

11

12

Use of this Specification

Thisdocumentisdesignedtospecifyasetoffunctionsthatmustbeimplementedona socalledDRAS.Aspreviouslydiscussed,theDRASisaninfrastructurecomponentthat isusedfortheautomateddeliveryofDReventinformationtofacilitiesandaggregators. Thedocumentationisintendedtosatisfythefollowing: AllowutilitiesandISOstheabilitytointerfacetheirInformationTechnology(IT) infrastructuretoacompliantDRAS. AllowcontrolmanufacturerstointerfacetheirEMCSorothercontrolstoa compliantDRAS. Allowavarietyofoperators(e.g.facilityandparticipantoperators)togainan understandingofthelevelofcontrolintheirparticipationinDRprogramsand dynamicpricingutilizingacompliantDRAS. AllowITpersonneltocreateuserinterfaces(UI)forboththeutilityorISOand theparticipantoperatorsofacompliantDRAS. AllowthirdpartiestobuildacompliantDRASorclientsthatmayreceiveDR signalsfromaDRASorDRASClient.

Thisdocumentcanbeusedtosatisfytherequirementsofanumberofentitiesas describedabove.Itisnotnecessarythateachentityreadthisdocumentinitsentirety. Table1givesguidanceontherelevantsectionsoftheOpenADRspecificationthat shouldbereaddependingupontheirrequirements.


Table 1 Relevant Sections of the Specification Entity Utility or ISO interfacing their IT infrastructure to 3rd party DRAS Control manufacturers building equipment to interface to the DRAS Facility and Participant Managers Web designers and programmer building Participant user interfaces. Web designers and programmer building utility user interfaces. Implementers of a DRAS Relevant Sections 0, 6, 7.1, 8, 9.1, 9.2, 10 0, 6.1, 6.4.3, 6.5.3, 7.2, 8.12, 9.3, 10 0, 6, 7.3, 8, 9.2, 10 0, 6, 7.3, 8, 9.2, 10 0, 6, 7.1, 8, 9.1, 9.2, 10 ALL

13

4.1

Implementing DRAS Interface

ThisOpenADRspecificationisintendedtospecifythevariousfunctionsthatmustexist inacomplaintDRAS.Itisnotintendedtospecifytheprecisetechnologyor implementationdetailsofeachofthefunctionsintheinterface.Forexample,although thisdocumentmayspecifythatSOAPWebservicesmustbeusedandaWebService DescriptionLanguage(WSDL)filemaybegivenfortheinterface,thereisno requirementthataspecificlanguageorcomputingplatformbeusedtoactually implementtheDRAS.Thesameistrueformanyofthedatamodelsandentities.Whilea preciseeXtensibleMarkupLanguage(XML)schemamaybegiventofacilitatethe exchangeofvariouspiecesofinformation,therearenorequirementsonhowthat informationisstoredinternallyorwhatifanydatabaseschemasareused.Also,thelook andfeelandimplementationoftheDRASuserinterfaceisoutsidethescopeofthis OpenADRspecification. Inadditionthisdocumentdescribesthreedistincttypesofinterfaceswhichdepend upononwhatentityisinterfacingtotheDRASandinclude:

UtilityandISOOperatorInterfaces ParticipantOperatorInterfaces DRASClientInterfaces

Thefollowingdiagram,Figure1,showsthecontextforthesethreetypesofinterfaces.

Figure 1. DRAS Client Interfaces

14

ThepurposeoftheOpenADRspecificationistopromoteinteroperabilityamongvarious parties.DependinguponhowtheDRASisdeployedtheremaynotbearequirementfor interoperabilityamongoneormoreoftheinterfacesdescribedaboveandthusthere maynotbearequirementthataDRASthatiscompliantwiththisOpenADR specificationimplementthoseinterfaces.Forexample: TheDRASisdevelopedbyathirdpartyseparatefromtheutilityorISOandthe operatorinterfacesaredevelopedbythirdpartydevelopers.Inthiscaseallthree interfaceswouldneedtoexistforafullycompliantDRAS. TheDRASisfullyintegratedandownedwithinautilitysITinfrastructureand thusinterfacegroup(1)isnotnecessary.Furthermoretheutilitydevelopedthe Webpagesforthevariousoperatorsandthusinterfacegroup(2)isnotrequired. Interfacegroup(3)isstillrequired. TheDRASisdevelopedbyathirdpartyseparatefromtheutilityorISO,butthe operatorinterfacesweredevelopedbythesamepartyprovidingtheDRASand havebeenfullyintegratedwiththeDRAS.Inthiscaseallinterfacegroups(1) and(3)needtoexist,butnot(2).

Notethatwhileinterfacegroups(1)and(2)mayormaynotberequired,interfacegroup (3)isalwaysrequiredforacompliantDRAS. WhenimplementingaDRASitwillbeimportanttospecifywithwhichoftheinterface groupsgivenabovetheDRASiscompliant.ThedetailedApplicationProgramming Interface(API)specificationsofSection9aredividedintothreesectionscorresponding totheinterfacegroupsgivenabove.Inordertobecompliantwithoneoftheabove sectionsitwillbenecessarytoimplementallofthefunctionsgiveninthecorresponding sectionofSection9.

4.2

Proper Use and Citation

ThepropercitationofthisOpenADRspecificationisasfollows: The(subsysteminquestion)shallmeetorexceedtherequirementsestablishedinOpen AutomatedDemandResponseCommunicationsSpecification(Version1.0). ModificationstotheOpenADRspecificationtomeetspecificcircumstancesoftheuser arepermissible,solongastheyareclearlyidentifiedinsupportingdocumentation whichaccompaniesthespecificationaspartofaprocurementprocess.Whenthisis desired,itmaybestipulatedasinthecitationasexampledbelow: The(subsysteminquestion)mustmeettherequirementsestablishedinOpen AutomatedDemandResponseCommunicationsSpecification(Version1.0)forthe portionoftheOpenADRspecificationthattheyareimplementing. Usersarestronglydiscouragedagainstmakinggenericorunspecificstatementssuchas (subsysteminquestion)shallmeetallapplicablesectionsofDRRC,OpenAutomated DemandResponseCommunicationsSpecification.Suchstatementscreatethepotential

15

fordifferingassessmentsbytheuserandthevendorsorsupplierastowhatis applicable.

16

5
5.1

DRAS Requirements
General Role of DRAS in Demand Response Programs and Dynamic Pricing

TheDRASisaninfrastructurecomponentinAutomatedDemandResponseprograms thatfacilitatesthecommunicationsamongtheentities(e.g.utilities,ISOs)thatproduce anddistributeelectricityandtheentities(e.g.facilitiesandaggregators)thatmanagethe consumptionofelectricity. ThepurposeoftheDRASistoautomatethevariouscommunicationchannelsnecessary forAutomatedDemandResponseprogramsanddynamicpricing.Such communicationsincludevariedpriceandreliabilityrelatedmessagesandinformation thataresentfromutilitiesorISOstothevariouspartiesthatmanagetheconsumptionof electricityinordertocurtailtheconsumptionofelectricityduringpeakperiods.

5.2

Use Cases

ThissectionpresentsatypicalusecaseofAutomatedDemandResponseprogramswith thefocusbeingtheroleoftheDRASinthoseprogramsanddynamicpricing.Theuse casepresentedinthissectionisageneralization.AppendixDcontainsusecasesfor specificDRprogramsanddynamicpricing,includingdetaileddescriptionsofthe symbolsandnomenclatureusedintheusecasediagrams.Thefollowingrolesareused intheusecases.

5.2.1 Use Case Scenarios


5.2.1.1 Utility Based Roles UtilityProgramOperator.Thisisahumanoperatorthatmanagesvarious aspectsoftheutilitysDRprogramsanddynamicpricing. ProgramNotifier.Thisisacomputersubsystemorhumanoperatorthatis responsiblefornotifyingtheparticipantsoftheDReventsandrelated information. ProgramSettlement.Thisisacomputersubsystemorhumanoperatorthatis responsibleforperformingthesettlementsassociatedwithDRprogramsand dynamicpricingbymeasuringtheusageofelectricityonaperparticipantbasis andfeedingtheinformationintotheutilitysbillingsystem.

5.2.1.2 DRAS Roles EventNotifier.ThisisasubsystemoftheDRASthatnotifiestheparticipants aboutDReventsinitiatedbytheutility.Thisisspecificallydesignedforthe machinetomachinecommunicationsnecessarytoautomatetheDRprogram. RTPNotifier.ThisisasubsystemoftheDRASthatnotifiestheparticipants aboutrealtimepricing(RTP)informationasitbecomesavailable.Thisis

17

specificallydesignedforthemachinetomachinecommunicationsnecessaryto automatetheDRprogram. ProgramNotifier.ThisisasubsystemoftheDRASthatnotifiesparticipant operatorsofvariouseventsrelatedtoDRprogramsanddynamicpricing. BiddingProxy.ThisisasubsystemoftheDRASthatactsasanautomated biddingproxyforDRprogramsanddynamicpricingthatrequireparticipantsto submitbidstotheutility.

5.2.1.3 DRAS Client Roles

DRASEventClient.ThisisasubsystemoftheDRASClientandisresponsible fornotifyingthefacilitysautomationsubsystemsaboutDRprogramevents. DRASFeedbackClient.ThisisasubsystemoftheDRASthatprovides feedbacktotheDRASconcerningwhatishappeninginafacilityinresponsetoa DRevent. DRASOperator.Ahumanactorwiththeresponsibilityofcreatingotherusers.

5.2.1.4 Participant Roles

ParticipantsarethecustomersoftheutilitiesorISOsthatareparticipatingintheDR programsanddynamicpricing.Ingeneraltherewillbeoneormoreoperatorsaspartof theparticipantsorganizationthatisresponsibleformanagingvariousaspectsoftheir involvementintheDRprogram.Withinthecontextoftheusecases,therearethe followingroles: FacilityManager.Ahumanoperatorresponsibleformanagingvariousaspects ofthefacilityrelatedtotheDRprogram.Withinthecontextofthisdocumenta facilitymanagermayalsobereferredtoasaParticipantManagerora ParticipantOperator. AggregatorManager.Ahumanoperatorresponsibleformanagingvarious aspectsoftheaggregatorsparticipationintheDRprogram.

5.2.1 Use Case Scenarios


Eachusecaseispresentedwiththreebroadscenarios: ProgramConfiguration ProgramExecution ProgramMaintenance

Eachofthesescenariosdiscussestheactionstakenbythevariousroleswithinthat scenario. 5.2.1.1 Program Configuration ProgramconfigurationconsistsoftheactionstakentosetupandautomateaspecificDR programwiththeemphasisbeingontheconfigurationoftheDRAStoparticipateinthe program.Insomecases,configurationactivitiesmaybelistedthatarenotrelatedtothe

18

DRAS.TheseactivitiesarelistedonlytogivecompletenesstotheoverallDRprogram andwillnotbecoveredindetail. 5.2.1.2 Program Execution Programexecutionconsistsoftheactionstakentoactuallyexecuteandparticipateinthe AutoDRprogram.ThisisthesetofactionsrequiredfortheutilitytosendDRrelated informationtotheparticipantsthatareparticipatingintheprogram.Emphasisisplaced ontheactionsrelatedtotheDRAS.Insomecasestheremaybeactivitieslistedthoseare notrelatedtotheDRAS.Theseactivitiesarelistedonlytogivecompletenesstothe overallDRprogramandwillnotbecoveredindetail. 5.2.1.3 Program Maintenance ProgrammaintenanceconsistsoftheactionsrelatedtomaintainingaDRprogramsuch aschangingconfigurations,generatingreportsandmonitoringDRASactivities. EmphasisisplacedontheactionsrelatedtotheDRAS.Insomecases,activitiesmaybe listedthatarenotrelatedtotheDRAS.Theseactivitiesarelistedonlytogive completenesstotheoverallDRprogramandwillnotbecoveredindetail.

5.2.2 Generalized Use Cases for DR Programs


Table2isaspreadsheetthatshowsthevariousdemandresponsefunctions(actions)as theyexistacrossthevarioususecasesdocumentedinAppendixDandisusefulfor identifyingactionswhicharecommonacrossallprogramsanddynamicpricing.Note thattheactionsaregeneralizationsofthevariousactionsacrossalltheprogramsand dynamicpricinglistedabove. ThefollowinggeneralizationscanbemadewithrespecttotheoperationoftheDRAS: Theusecaseswhichincludetheuseofaggregatorsareverysimilartotheuse caseswhichoperatedirectlywithfacilitiesandfacilitymanagers;thereforeitis reasonabletotreattheaggregatorrolesandthefacilitymanagerrolestobe equivalent. Alltheusecasesthatareonlyforpropagatingeventshaveverysimilarsetsof stepsforthevariousscenarios.Thedifferencesarerelatedtothetypeof informationtransmittedwiththeevents. Alltheusecasesthatautomatethebiddingprocessincludeaverysimilarsetof steps. Althoughthebiddingprocessislinkedtospecificeventsthereisnotastrong couplingbetweenthestepsusedinthebiddingprocessandthestepsinvolvedin propagatingevents.

InanalyzingtheDRprogramsanddynamicpricingsofaronecanseethattherearetwo generalclassesoffunctions:

ActionsrelatedtotheautomationofDReventnotification.

19

ActionsrelatedtotheautomationoftheDRbiddingprocess.

Baseduponthisanalysisitispossibletogenerategeneralusecasesthatcoverthesetwo functionalclasses.Theseusecasesarepresentedinthesubsequentsections.

20

Table 2

DR Program Execution
DR Program Execution Configuration Configure DRAS Client Connection Actions on DRAS Initiate DR Event Set Load Status Set Current Bids Send DR Event Info Actions By DRAS Notify Request for Bid Notify Bid Status Maintenance Utility Operator Reports X

Program Utility Operator Utility Program Notifier Utility Info System DRAS Client Client Operator Utility Operator Utility Program Notifier Utility Info System DRAS Client Client Operator Utility Operator Utility Program Notifier Utility Info System DRAS Client Client Operator

Configure Program X

Configure Bids

Request Bids

Program Opt Out

Client Reports

CPP

X X X X

X X X

DBP

X X X X X X X X

X X

CBP

X X X X X X X

21

DR Program Execution Configuration Configure DRAS Client Connection Actions on DRAS Initiate DR Event Set Load Status Set Current Bids Send DR Event Info Actions By DRAS Notify Request for Bid Notify Bid Status Maintenance Utility Operator Reports X

Program Utility Operator Utility Program Notifier Utility Info System DRAS Client Client Operator Utility Operator Utility Program Notifier Utility Info System DRAS Client Client Operator Utility Operator Utility Program Notifier Utility Info System DRAS Client Client Operator

Configure Program X

Configure Bids

Request Bids

Program Opt Out

Client Reports

BIP

X X X X

X X X

PDC

X X X X

X X X

PCT

X X X

X X

22

DR Program Execution Configuration Configure DRAS Client Connection Actions on DRAS Initiate DR Event Set Load Status Set Current Bids Send DR Event Info Actions By DRAS Notify Request for Bid Notify Bid Status Maintenance Utility Operator Reports X

Program Utility Operator Utility Program Notifier Utility Info System DRAS Client Client Operator

Configure Program X

Configure Bids

Request Bids

Program Opt Out

Client Reports

RTP

X X X

X X

23

5.2.2.1 Generic Event-Based Programs (GEBP) Asstated,therearemanysimilaritiesinthesequenceofstepsusedtopropagateevents inthevarioususecases.Theusecasepresentedinthissectionrepresentsa generalizationofthoseusecasesintoaGenericEventBasedProgram(GEBP)(Figure2). whichisbasedontheGeneral(GEN)usecasediagram.Notethatthefollowing generalizationshavebeenmade:

Thereisnodistinctionbetweenthevarioustypesofparticipantsthatinterfaceto theDRASorparticipateintheprogram.

Figure 2. Automated Generic Event-Based Program (GEBP) Use Case

5.2.2.1.1 GEBP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theGEBPDRprogramandinvolvesthefollowingactions: 1. TheutilityprogramoperatorsetsuptheGEBPprogramintheirUtility InformationSystem(UIS).Thisincludessigningupparticipantsandenteringall requiredinformationnecessaryfortheparticipantstoparticipateintheGEBP programintotheUIS.Thedetailsofthisprocessarebeyondthescopeofthis document.

24

2. TheutilityprogramoperatorconfigurestheGEBPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowtheparticipant managertoaccesstheDRASandsetuptheirDRASClientsothatitmay communicatewiththeDRAS.Itincludesenteringthefollowinginformation: Programdefinition: o o o Programscheduleconstraintssuchastimeofday,duration,etc. Typeofinformation(e.g.prices,levels,etc.)specifiedaspartofaDR event. ProgrameventinformationprovidedtoDRASClientforsignalmapping

Utilityassignedaccountnumberusedforsettlement Participantidentification Participantpassword Geographiclocation Gridlocation

3a. TheparticipantmanagerconfigurestheparticipantsitesEMCSornetworkfor DR,possiblyinconjunctionwiththeEMCSvendorandITstaff.Thiscould includeprogrammingtheEMCStorespondtoDReventsandshedorshiftloads appropriately.Thedetailsofthisarebeyondthescopeofthisdocument. 3b.TheparticipantmanagerconfigurestheDRASClients.DRASClientsmaytake manyforms,bothintermsofhardwareandsoftware.Thisstepconfiguresthe DRASClientsothatitcancommunicatewiththefacilitiessystemsthatare responsibleformanagingtheloads.Thedetailsoftheprocessarebeyondthe scopeofthisdocument. 3c. TheparticipantmanagerconfigurestheDRprogramparametersandDRAS ClientconnectioninDRAS.Thisstepestablishestheconnectionbetweenthe DRASClientandtheDRAS.Typicallythisincludesthefollowingtypesof information: Identificationandpasswordoftheparticipant Contactinformation(phonenumber,pager,emailaddress,etc.) DRASClientcommunicationsparameters o o o o o DRASIPaddress Identification Password IPconnectioninformation Pollingfrequency(ifDRASClientispolling)

OptionalLoadreductionpotential(pertimeblockperlevel) Exceptionparameters

25

Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureformalOpenADR standard;thismaybeperformedintheDRASClientandnotintheDRAS.


5.2.2.1.2 GEBP Execution

ThesetofactionstoexecuteGEBPeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatestheGEBPDReventintheUtility InformationSystem.Inthisstep,aprogramoperatorschedulesaGEBPeventin theUtilityInformationSystem.Thedetailsofthisisprocessarebeyondthescope ofthisdocument. 2. TheutilityprogramnotifiergetstheGEBPDReventinformationfromtheir UtilityInformationSystemandinitiatestheGEBPDReventintheDRAS.The informationsenttotheDRASbytheutilityprogramnotifiersubsystemincludes thefollowinginformation: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Participantslist(accountnumbers)

3. TheeventnotifierintheDRASsendstheGEBPDReventinformationtothe appropriateDRASClientsintheGEBPDRprogram.TheGEBPDRevent informationsenttotheDRASClientsincludesthefollowing: UtilityeventinformationforintelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforsimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforsimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenotificationistobesent)

Aspartofthisinteraction,thereisaconfirmationmessagesentbytheDRAS ClienttotheDRAStoindicatethatithasreceivedtheDReventinformation.In additionthereisanindicatorofwhetheraDRASClientisoptinginoroutofa DReventwhenitsendstheconfirmationmessage.Thisallowstheoptout functiontobeperformedontheautomationequipmentinthefacilityandsentto theDRASaspartoftheDRASandDRASClientinteraction.

26

4. TheDRASeventclientattheparticipantsitesendstheeventinformationtothe participantsystemsresponsibleforloadshed.Thedetailsofthisprocessare beyondthescopeofthisdocument. 5. TheDRASfeedbackclientattheparticipantsitesendsthesystemloadstatusto theDRAS.Thisisafeedbackmechanismthatisusedtorecordhowthe participantsiterespondedtotheDReventorstatusofthefacilityoutsidean event(e.g.nearrealtimeload).Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Nearrealtimeload Loadreductionenduses(Heating,ventilationandairconditioning[HVAC], lighting) EventType(Dayahead,Dayof)

6. Theutilityprogramsettlementprogrammeasuresusageinafacilityand conductsthesettlementactivityintheUtilityInformationSystem.Thisprocessis beyondthescopeofthisdocument. Notethatoneofthefunctionsnotincludedinthestepsgivenaboveistheabilityforthe utilityprogramoperatortomodifyorcancelanalreadyissuedDRevent.Thisisshown inFigure2asModifyGENEvent.


5.2.2.1.3 GEBP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheGEBP program.Unliketheconfigurationandexecutionscenariosthathaveaprescribedsetof steps,thissetofactionsarethepossibleactionsthatmaybeperformedbythevarious rolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theparticipantmanager cangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants): o currentoutstandingevents Loadreductionpotentialbaseduponallparticipantsinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptional feedback) o Eventlogs 1b.Theparticipantmanagerchecksthestatus.Theutilityprogramoperatorcanget thefollowingstatusinformationfromtheDRASatanytime:

27

DRASClientcommunicationsstatus: o o o o o o o Currentstatus Lastcontact Currentsignalslevels Currentparticipantmanualcontrollevels(optout) Communicationlogs Signallogs Manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifies,anddeletesfacilitiesparticipating intheprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheparticipantmanageroptsoutoftheDRprogram.Atanytime,the participantmanagercanoptoutoftheDRprogramontheDRAS.Wheninan optoutcondition,DReventsarenotpropagatedtotheDRASClient.Theoptout canbeeitherfortheentireprogramorasingleevent.Thereisamethodaspart oftheparticipantinterfacetoallowoperatorstooptoutofaDReventatany timeontheDRAS. 1e. Theutilityprogramoperatorand/ortheparticipantmanagerreceivean exceptionnotificationfromtheDRASwhenthereisanerror(thisisnotshownin thediagram).WhenanerrorconditionoccursintheDRASwhichmayrequire somesortofactionbyeithertheparticipantmanagerortheutilityprogram operator,theDRASwillsendamessagetotherespectiveoperatorsviaemail, voiceorpager.Notethatthisalarminginterfacedoesnotcoverexception conditionsthatarepartoftheDRASoperationandmanagedbytheDRAS operator.Suchexceptionsmightincludemachineandplatformspecific exceptionssuchasoutofdiskspaceandareoutsidethescopeofthis document.ThetypesofexceptionscoveredbythisinterfaceincludeDRASClient communicationsfailure. 5.2.2.2 Generic Bidding Programs (GBP) ThissectionpresentsausecaseforGenericBiddingPrograms(GPB,Figure3).Thisis intendedtorepresenthowageneralizedbiddingprocessmaybeautomatedbythe DRAS.Thiscoversonlythebiddingandbidacceptanceprocessanddoesnotcoverthe eventpropagationprocesswhichwaspresentedintheprevioussection.

28

Figure 3. Generic Bidding Process (GBP) 5.2.2.2.1 GBP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsuptheGBPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheGBPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheGBPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition: o o o Programscheduleconstraintssuchastimeofday,duration,etc. Typeofinformation(e.g.prices,levels,etc.)specifiedaspartofaDR event. ProgrameventinformationtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement

29

Participantidentification Participantpassword Geographiclocation Gridlocation Managercontactinformation(emailaddress,telephone,pagernumber,etc.)

3. TheparticipantmanagersetsstandingbidintheDRAS.Thisisthebidthatwill beautomaticallyplacedbytheDRASwhenarequestforbidcomesfromthe utility.Itincludesthefollowing: Loadreductionbidspertimeblock(priceandloadamount)

5.2.2.2.2 GBP Execution

Thebiddingprocessincludesthefollowingsteps: 1. TheutilityprogramoperatorcreatesaGBPbiddingeventinUtilityInformation System.Inthisstep,aprogramoperatorschedulesaGBPbiddingeventinthe UtilityInformationSystem.Thedetailsofthisprocessarebeyondthescopeof thisdocument. 2. TheutilityprogramnotifiergetsGBPbiddingeventinformationfromtheUtility InformationSystemandinitiatesGBPRequestforbidsintheDRAS.The informationsenttotheDRASbytheutilityprogramnotifiersubsystemincludes thefollowinginformation: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Participantlist(accountnumbers) RequestForBids(RFB)issuedateandtime RFBclosetime Priceofferedforloadreductionpertimeblock

3. TheDRASprogramnotifiersendsrequestforbidtotheparticipantmanager. Thisnotificationtypicallycomesintheformofanemail,phonecallorpage. 4. TheparticipantmanagercanadjustorcancelthecurrentbidintheDRAS.Thisis anoptionalstepandallowsthemanagertoadjusttheirbidforthatparticular event.IfthisstepisnotperformedthentheDRASwillsubmitthestandingbid aftertheendofthebidperiod. 5. Afterthebiddingtimelimithasexpired,thebiddingproxyintheDRASsetsthe currentbidintheUtilityInformationSystem.TheinformationsentbytheDRAS includesthefollowingforeachparticipant: Participantaccountnumber

30

Loadreductionbidspertimeblock

6. TheutilityprogramnotifiergetstheacceptedbidsfromtheUtilityInformation SystemandsetstheacceptedandrejectedbidsintheDRAS.Theinformation concerningtheacceptedbidincludesthefollowing: Participantlist(accountnumber) AcceptorReject Loadreductionbidspertimeblock(forverification)

7. TheDRASprogramnotifiersendstheacceptanceorrejectionnotificationtothe participantmanagerviaphone,email,and/orpage.
5.2.2.2.3 GBP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheGBP program.Unliketheconfigurationandexecutionscenarios,thissetofactionsislessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallparticipantsinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs Bidsandsignallevelspertimeblockforcurrentevents(forallparticipants, individuallyandthosegroupedtogether)

1b.Theparticipantmanagerchecksstatus.Theparticipantmanagercangetthe followingstatusinformationfromtheDRASatanytime. DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentparticipantmanualcontrollevels(optout) communicationslogs signallogs manualcontrollogs

Eventstatus(sameasabove) Bidsandsignallevelspertimeblockforcurrentevents

31

1c. Theutilityprogramoperatoradds,modifies,anddeletesfacilitiesparticipating intheprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheparticipantmanageroptsoutoftheDRprogram.Atanytime,the participantmanagercanoptoutoftheDRprogramontheDRAS.Wheninan optoutcondition,DReventsarenotpropagatedtotheDRASClient.Theoptout canbeeitherfortheentireprogramorasingleevent.InadditiontheDRASdoes notpropagatebidstotheutilityITsystemforparticipantsthathaveoptedoutof aDRevent. 1e. TheparticipantmanagerconfiguresastandingbidintheDRAS.

5.3

Overall Requirements

ThissectionpresentsagenerallistofrequirementsfortheDRASthatmaybe independentofspecificusecases.Thegeneralhighlevelrequirementsinclude: Shoulduseindustryacceptedmethodsandstandardstoeaseintegrationand accesstoDRASservicesfromthirdparties. Mustfollowawellestablishedsetofsecuritypoliciestoinsurethatallexchanges ofinformationareauthenticated,private,andmaintainintegrityofthe informationbeingexchanged. MustalloweasyintegrationwithenduserfacilityITinfrastructure: o o Easeindealingwithfirewalls GoodITnetworkcitizen(i.e.nosecurityrisk,insignificantnetworkload, etc).

ThelatencyofDReventssentfromtheutilitytotheendusershouldbenomore than1minute,dependingupontheconfigurationoftheinteractionbetweenthe DRASandDRASClient. TheDRASmustmaintainaccuratetimewithin15seconds. TheDRASshouldhaveameanstoallowparticipantstoparticipateinmultiple DRprogramsanddynamicpricingthroughthesameDRAS. TheDRASshouldrecovergracefullyfromfacilityfaultswithminimumlostdata. Examplesofsuchfaultsmightbepowerfailuresorconnectivityloss.

32

Specifications

ThissectiongivesspecificationsforthevariouscomponentsandfunctionsoftheDRAS.

6.1

Automated Demand Response Architecture

Figures4and5showthecomponentandsystemarchitecturethatinterfacewiththe DRAStomanagetheactualautomatedDRevents.LikewisetheFiguresshowthe architectureofthecomponentsandsystemsthatinterfacetotheDRAStoautomatethe submissionsofbidsbyparticipantsinaDRprogramthatrequiresbidding. ThelookandfeelandimplementationoftheUserInterface(UI)usedtoperformvarious functionsontheDRAScommunicationsisoutsidethescopeofthisspecification.Thus, theDRASUIWebServerandtheWebClientareshownoutsidetherealmoftheDRAS. WhatisstandardizedistheexchangeofinformationwiththeDRASthatallowsaUIto bebuiltthatcanbeusedtoviewandmanipulatetheinformationexchangedwiththe DRAS.IntheoryitispossibletosupporttheUIontheDRASandparticular implementationsoftheDRASmaydothis,buthowtheuserinterfaceisimplementedis notpartofthisspecification.Byusingthestandardizedinformationexchangespecified inthisspecification,itwillbepossibleforthirdpartiestoimplementaUIwiththeirown lookandfeelandstillinteractwiththeDRASinastandardsbasedfashion. ThefiguresincludeasocalledThirdPartyNotificationSystem.Thissubsystemis responsiblefornotificationstofacilityoperatorsusingvariousexistingtechnologies suchasphone,pages,email,fax,etc.Thepurposeofshowingthisasaseparate componentistohighlightthefactthatcertaintypesofnotifications(suchasvoicemail) willnotbepartofthespecificationandmaybeprovidedbythirdpartysystems.The systemsmaybepartoftheutilityinfrastructure,butinthemostgeneralcasetheyarea standaloneserviceasdepictedinthediagrams.Ataminimum,theDRASmustsupport directemailnotificationtothefacilitythatincludesexceptionhandlingandbidding information.Thisisseparatefromthenotificationsthatmaybeprovidedbyathird partynotificationsystem. ItisimportanttonoteinthearchitectureshowninFigures4and5thattheDRASitselfis depictedasastandaloneservicefromboththeutilityandparticipantsITinfrastructure. ThisisthemostgeneralcaseandiswhatisusedasthemainusecaseinthisOpenADR specification.Infact,specificincarnationsoftheDRASmaybeintegratedwithineither theutilityorparticipantsITinfrastructureandservicesandthustheinterfacestothe DRASmaynotbeimplementedasdepictedinthesefigures.

33

Figure 4. General Automated Events Architecture with Standalone DRAS

Figure 5. General Automated Bidding Architecture with Standalone DRAS

34

6.2

General Requirements

Inanalyzingvarioususecasesandthearchitecturesintheprevioussection,itispossible togroupthevariousfunctionalrequirementsasshowninFigure6.

Figure 6. Use Case References to Functional Specification

TheinterfacefunctionssupportedbytheDRAScanbeclassifiedintothreegroups:

UtilityandISOfunctions Participantfunctions DRASClientfunctions

ThisclassificationreflectstheroleoftheDRASasanintegrationpointbetweenthe utilityorISOandtheparticipantsandtheDRASClients.BecausetheDRASmaynotbe astandaloneentity,butinsteadmaybeintegratedwithautilitysITinfrastructure,itis notarequirementthattheDRASsupportthosefunctionstaggedasutilityorISO functions.InthecasewheretheDRASisnotintegratedwiththeutilityITinfrastructure andsuppliedasastandaloneentity,thenitshouldsupporttheinterfacestaggedas utilityorISO.

35

Furthermore,aparticularimplementationoftheDRASmaycontainaWebserverthatis responsibleforservingupaWebbaseduserinterface(UI)totheparticipantoperators. Inthisscenarioitisnotarequirementthattheparticipantfunctionsbemadeavailable forthirdpartiestoimplementtheirownWebbasedUIandthereforethemethods specifiedaspartoftheparticipantinterfaceneednotexist.Insteadthefunctions normallyprovidedbytheparticipantinterfacewillbeprovidedbysomesortofUIor toolthatisintegratedwiththeDRASandthereforeneednotutilizethemethods specifiedintheparticipantinterface.IfitisarequirementthattheDRASallowsthird partiestobuildWebbasedclientsforparticipantsthenthemethodsdescribedaspartof theparticipantinterfacemustexistasspecifiedbelow. Inanycase,theDRASmustsupportthemethodstaggedasbelongingtotheDRAS Clientinterface. Theparticipant,utilityorISO,andDRASClientinterfacesarefurtherdecomposedinto specificmethodsandcoveredinmoredetailbelow. Inadditiontothefunctionaldescriptionsgivenbelow,thedatamodelentitiesusedas parametersforeachofthesemethodsarealsodescribed.Theconceptualdatamodels developedarefromthepointofviewoftheutilities,participants,andDRASClientsand aredepictedintheconceptualentityrelationshipdiagram(ERD)inSection6.4.1. Fortheremainderofthisdocumentthetermfunctionandmethodareinterchangeable andtakeontheirnormalmeaning,i.e.referringtoasoftwareinterfaceconstructthatis usedtoexecuteacertainwelldefinedsetoffunctionality.

6.3

Common Requirements
Theymustallbeimplementedusingsometypeofreliablecommunications, meaningthatitmustbepossibletodetermineifinformationexchangedaspart ofexecutingthefunctionwasreceivedcorrectly. AllfunctionsmustadheretotheminimumsecuritypoliciesspecifiedinSection 10. AllfunctionsmustbeimplementedusingindustrystandardWebservices. Allfunctionsmustrestrictaccessbaseduponawelldocumentedsetofsecurity roles.

AllDRASfunctionsmustsatisfythefollowingrequirements:

6.3.1 DRAS User Accounts and Security Roles


Forsecurityreasons,eachofthefunctionsaccessedthroughtheinterfacesoftheDRAS definedinthisspecificationcanonlybeaccessedbyuserswithanappropriate authorizationontheDRAS.FurtherdetailsaredescribedinDRASsecuritypolicies.In additionaccountsthatarecreatedtoallowaccesstofunctionsontheDRAShaveoneor moresecurityroles.Thefollowingtypesofsecurityrolesareused:

36

DRASOperatorDRASoperatorsarehighlytrustedindividualswithwide rangingaccesstoallinformationandfunctionsoftheDRASdocumentedinthis specificationincludingcreatingotheruserswiththeirappropriatesecurityroles. DRASoperatorscannotbecreatedviaanyoftheinterfacesdocumentedinthis specification. ParticipantManagerParticipantmanagershaveaccesstoalltheinformation associatedwithaparticularparticipantaccount.Theyarecreatedbyusingthe functionsdescribedinSection0.3.Withinthecontextofthisdocumenta participantmanagermayalsobereferredtoasaParticipantOperator. DRASClientTheDRASClientrepresentsthesoftwareagentforthemachineto machinecommunicationsbetweentheDRASandtheparticipantfacility.DRAS ClientsarecreatedaspartoftheconfigurationprocessdescribedinSection0.2. UtilityandISOOperatorUtilityandISOoperatorshaveaccesstoalltheutility methodsandfunctionsintheDRAS.Thisprocessisbeyondthescopeofthis document. DRASClientInstaller(TechnicalCoordinators)Thesearetheindividualsthat areresponsibleforinstallingandtestingDRASClientsinthefield.Howthese accountsarecreatedarebeyondthescopeofthisdocument. ParticipantmanagerandDRASClientaccountsareestablishedaspartofthe configurationoftheDRASasdescribedinSection0.TheDRASoperator,utility programoperator,andDRASClientinstalleraccountsaremanagedbyprocesses thatareoutsidethescopeofthisdocument.

6.3.2 Logs and Reports


TheDRASmusttrackandlogtheitemsdescribedinthissection.Ingeneraleachofthe itemsloggedareaccessiblebythevariousoperators.InadditiontheDRASmust monitorexceptionconditionsthatresultinsocalledalarms.Ingeneral,alarmsresultin thenotificationofvariousoperatorsasdescribedinSection6.3.3. DRASoperatorsandutilityprogramoperatorsmayaccessthelogsandalarmsofallthe transactionsregardlessoftheparticipantwhileparticipantmanagersmayonlyaccess thelogsandalarmsassociatedwiththeirtransactions.Alsonooneshouldbepermitted todeletelogs. AsapracticalmattertheDRAScannotkeeplogsforeversincetheirsizewilleventually fillupavailablestorageresources.ItisthereforenotarequirementthattheDRASto keeplogsindefinitely.TheprocesstospecifythehistoricalDRAScommunicationslogs isbeyondthescopeofthisdocument.ThevariousitemsthatareloggedbytheDRAS aredetailedbelow. 6.3.2.1 The DRAS Client Communications State

TheDRASisrequiredtotrackthecommunicationsstateofeachDRASClient.ADRAS Clientmaybeinoneofthefollowingcommunicationsstates:

37

OnlinetheDRASClientiscommunicatingproperly. Degraded(onlinewitherrorsnotethatthethresholdforthisisimplementation specific) CommunicationsFailed. OutofService(provisionedofflinefortesting,maintenance,etc.)

AsdescribedbythefunctionsinSection0,theDRASClientscommunicationstatecan bequeriedatanytime. 6.3.2.2 All Transactions with the DRAS

TheDRASmustlogallinvocationsoffunctionsaspartofitsnormaloperation.The informationrecordedisspecifiedbytheTransactionLogentityasdescribedinthedata modelsection.AsdescribedinSection0theDRASClientstransactionlogsmaybe queriedatanytime. 6.3.2.3 Exceptions and Alarm Conditions

ThefollowingalarmsmustbetrackedbytheDRAS. DRASClientcommunicationgoingONorOFFline.

IngeneralalarmsresultinoperatornotificationsasdescribedinSection6.3.3.In additionalarmsmustbeloggedbytheDRASsothattheymaybequeriedusingthe functionsdescribedinSection0.

6.3.3 Operator Notifications


TheDRASmaysendnotificationstovarioushumanoperatorsunderavarietyof circumstances.InordertonotifythehumanoperatorstheDRASmustsupportemail notificationandmaysupportinterfacingtothirdpartynotificationsystems.Thirdparty notificationsystemsincludepagers,voicemail,textmessages,etc.Theprocessofhow theDRASinterfacestothirdpartynotificationsystemsisbeyondthescopeofthis document. Ingeneral,participantoperatorsandutilityprogramoperatorsmaybesentnotifications bytheDRAS.Theemailcontactinformationforaparticipantoperatorisspecifiedinthe ParticipantAccountobjectforthatparticipantasdescribedinthedatamodelsection.The utilityprogramoperatorsemailcontactinformationisspecifiedwhentheiraccountis setupbytheDRASoperator.Theprocesstospecifytheformatoftheemailmessages thataresenttothevariousoperatorsisbeyondthescopeofthisdocument. TheDRASmustsendthefollowingnotifications:

DRASClientONorOFFline.TheDRASmusttrackwhenaDRASClientgoes ONorOFFlineandwhenitdoesitmustsendanemailnotificationtothe followingoperators:

38

o o o

Theparticipantoperator(s)whomanagesthatDRASClientifsoconfigured toreceivenotifications. Theutilityprogramoperatorwhoconfiguredtheparticipantaccountto receivethesenotifications. AllDRASoperators.

DReventinitiated.WhentheutilityorISOissuesaDReventormodifiesan existingDReventthenanotificationmustbesenttoallparticipantoperatorsthat areassociatedwithDRASClientsthatwouldnormallyreceivethatevent.Note thattheprogrammayrequirebiddingbytheparticipantinwhichcasethis notificationmaybearequestforabid. Participantbidsacceptedorrejected.Whenaparticipantsbidshavebeen acceptedorrejectedtheparticipantoperatormustbenotified.

6.3.4 Testing
TheDRASmustsupportthetestingofDReventconfigurationsandcommunications withDRASClients.Itmustsupportthefollowingtypesoftests: EndtoendtestingofDRevents.ItsupportsthisbyallowingtheutilityorISOto initiatesocalledtestevents.ThesearetreatedlikeanyotherDReventsbythe DRASincludingsendingtheDReventinformationtoDRASClients.Theonly differenceisthatthereisafieldintheDReventinformationthatsignifiesthat theeventisatestevent.WhentheDRASClientreceivestesteventsitmay choosetodealwithitinwhateverfashionisappropriateforthetestscenarioin thefacility,includingignoringit. DRASClienttesting.ThereisawayforDRASClientinstallerstotakeaDRAS ClientofflineintheDRASandsendittestmessages.TheDRASClientinstaller hastheabilitytosetvariousstatevariablesthatareusedbyDRASClientssothat theycanbemanuallycontrolled.SeeSection7.3.6.

6.4

Introduction to Data Entities Used By Interface Functions

Thissectiongivesabriefdescriptionofthevariousdataentitiesusedforinformation exchangeviathevariousfunctionsdescribedinthisspecification.Thissectionisonly meanttogiveabriefintroductionandconceptualoverviewofthevariousdataentities. Theconceptualdatamodelrepresentsthevariousdataelementsthatarepartofthe DRASoperationastheyareviewedfromthepointofviewoftheutilityorISOandthe participants.Itisnotintendedtorepresentaspecificdatabaseschemathatis implementedintheDRASbutratherrepresentthevariousdataelementsthatareused by,theutilityorISO,participants,andDRASClientswhentheyinterfacetotheDRAS. TheconceptualdatamodelisrepresentedbyseveralEntityRelationship(ER)diagram. Eachdiagramisacollectionofentitiesandtherelationshipsbetweenthem.EachEntity representsabasicdataelementwiththefollowingcharacteristics:

39

Nameofthedataentity PrimaryKeyoftheentity(PK).Thisisanidentifierthatrepresentshowthe entitymaybereferencedbyotherentities. Dataelementsorattributes.Thesearethevariousfieldsoftheentity. Referencestootherentities.Oftenaparticularentitywillrefertoanotherentity, representedbytheforeignkey(FK).Theseforeignkeysaretheprimarykeys oftheentitiesthattheyreferto.

KeytoInterfaceFunctionFigures Eachdiscussioninthissectionfocusesonthoseentitiesthatareshadedinthe correspondingreferencefigures.Unshadedentitieshavebeendefinedelsewhereaspast ofanotherprocess.Furthermore,attributesinboldarerequiredwhiletheothersare optional.Arrowsareusedwhenoneentityreferstoanother.Thetextlabelonthearrow notesthetypeofrelationshipbetweenthetwoentities.Thenumbersequenceassociated withthearrowspecifieshowmanyoftheentitiesarereferredtointherelationship,for example: 1..*meansatleastonebutpossiblymany(onetomany) 1meansexactlyone(onetoone) *meanszerotomany

Notethatwhilethissectionisrelativelydescriptiveinnature,thenamegivenforeachof theentitiesandtheiraccompanyingfieldsandattributesmatchthenamesaregivenin Section8,whichcontainsamoredetaileddescriptionoftheschemasforeachofthe entitiespresentedhere.

6.4.1 Data Entities in Support of Utility and ISO Use Case Actions
Theentitiesinthissectionarespecificallyusedbythevariousoperationsinsupportof theutilityorISOfunctions.Assuchtheyareorganizedaccordingtothevarious functionsthatmaybeperformed. 6.4.1.1 Utility Issues DR Event ThesearetheentitiesusedwhentheUtilityorISOinitiatesaDRevent.Inparticularthe UtilityDREvententityisusedtospecifyalltheinformationassociatedwithaDRevent andcontainsthefollowinggeneralattributes: eventIdentifierThisisagloballyuniqueidthatisspecifiedbytheutilityorISO whentheDReventisissued.Itissubsequentlyusedtoassociateandretrieve informationrelatedtoaparticularDRevent. programNameThisisanidentifierthatspecifieswhichDRprogramtheDR eventisbeingissuedfor. eventModNumberThisisasubidentifiertotheeventidentifierandisused specificallytodeterminewhenchangeshavebeenmadetotheDRevent informationsincethelasttimeitwasissued.Forexample,theveryfirsttimea
40

DReventisinitiatedbytheutilityorISO,thishasanumberof0andwill continuetohaveavalueof0foreachandeverysubsequenttransmissionunless theDReventissubsequentlymodifiedbytheutilityorISO.Atthattimethis numberisincreasedtothenextversionnumber,indicatingtheoriginalevent wasmodified. utilityITNameThisisanoptionalfieldwhichisthenameand/orversion numberoftheutilityITsystemthatinitiatedtheDRevent. destinationsThisisalistofidentifiersthatspecifieswhoistoreceivetheDR event.Notethatitcanbeanyofthefollowing: ExplicitParticipantAccountUserID(s)(uid) Groupidentifiers DRASClientlocationspecifications eventTimingVarioustimingparametersfortheevent,including: notificationTimeThisisthetimeatwhichtheparticipantsshouldbe notifiedoftheDRevent. startTimeThisisthedateandtimethattheDReventbecomesactive. endTimeThisisthedateandtimethattheDReventends. biddingInformationIfaprogramsupportsbiddingbytheparticipantsthenthe followingfieldsarealsoincluded. openingTimeThisisthetimeatwhichtheparticipantsmaystartplacing bids. closingTimeThisisthetimeatwhichthebiddingwillcloseandisthe deadlineforwhichtheutilitymayreceivethebidsfromtheDRAS. EventInformationThisistheinformationassociatedwiththeDReventandisa listofEventInfoInstanceentityasdescribedbelow.

41

Figure 7. Utility Issued DR Event Entity

EachUtilityDREventmaycontainalistofEventInfoInstancevariableswhichareusedto describetheinformationthatmayaccompanyaDRevent.EachEventInfoInstanceentity containsthefollowinggeneralattributes: eventInfoTypeNamethisisanamethatisusedtocorrelatethisvalueagainsta predefinedtypeofvaluesforthisprogramasdescribedinSection6.5.3.3.2.Note thatthetypenameprovidesawayforthevariousvaluesassociatedwithaDR eventtobeidentified.ThevarioustypesaredefinedwhentheDRprogramis definedandgivennameswhicharereferredtohere. valuesthesearealistofoneormorevaluesofthedefinedtype.Ifthereismore thanonevaluetheneachvaluecorrespondstoaspecifictimeslotwithintheDR eventACTIVEperiod.Essentiallytheywillformascheduleofvalues.Thisis describedinmoredetailinSection6.5. participantsthisisalistofparticipantsforwhichthesevaluesapply.Itallows theinformationassociatedwithaDReventtobeappliedtospecificparticipants.

42

groupsthisisalistofgroupsforwhichthesevaluesapply.Sinceparticipants maybelongtoagroup,groupsareanotherwayofspecifyingwhichparticipants aretoreceivetheinformation.

Ascanbeseenbythediagramitisassumedthatthefollowingentitiesexistbeforean UtilityDREventiscreatedthatrefertothem: UtilityProgram ParticipantAccount EventInfoType

6.4.1.2 Utility Configuration of DRAS WhentheutilityorISOconfigurestheDRAS,itusestheentitiesshowninFigure8. TheUtilityProgramentityrepresentsalltheinformationassociatedwithaDRprogram thatiscreatedbyautilityorISO.Eachprogramhasasetofattributesthatdescribehow theprogramismanagedandrunfromthepointofviewoftheDRASandparticipants. Theattributesincludethefollowingtypeofinformation: Aname. AProgramConstraintentityintheformoftimeanddateattributeswhichspecify whenaDReventcanbeissued. Listofparticipantsthatparticipateintheprogram. Parametersthatcontrolhowbiddingisperformedbyaparticipantaspartofthe program. SpecificationsforthetypeofinformationthatcanbeassociatedwithaDRevent intheformofEventInfoTypeentities. Apriorityfortheprograminrelationtootherprograms.

TheEventInfoTypeentitiesarepartoftheUtilityProgramentitiesandareusedtospecify thetypeofinformationthatmaybeassociatedwithaDReventwhenoneisissued. Examplesofthiskindofinformationmayincludethingslikerealtimeprices,shedor shiftlevels,etc.AnEventInfoTypecontainsthefollowinggeneralattributes. Aname. Aspecificationforthedatatypeoftheinformation. Aspecificationforconstraintsontheallowablevaluessuchasminimumand maximumvalues. Aspecificationforascheduleifthevaluesmaychangeaccordingtosomefixed scheduleduringthecourseofaDRevent.Anexamplemightbepriceswhere thereisonepriceforthefirsthouroftheDRevent,adifferentpriceforthe secondhour,andyetanotherpricefortheremainingtimeintheDRevent.

EventInfoTypeentitiesaredescribedinmoredetailinSection6.5.

43

TheParticipantAccountentitycontainsalltheattributesassociatedwithaparticipant.It containsthefollowingtypesofinformation: Participantname. Accesscredentials(e.g.usernameandpassword)foraccessingthefunctionsof theDRAS.NotethataParticipantAccountmayhavemultipleDRASClients associatedwiththeiraccountandeachoftheDRASClientswillhaveaccess credentialsarethataredistinctandseparatefromtheaccesscredentialsspecified here. Groupsthattheparticipantmaybelongto.Groupsareawaytorefertomore thanoneparticipantforvariousoperationsoftheDRAS. Programsanddynamicpricingactivitiesthattheparticipantsmayparticipatein. ProgramConstraintvariablesassociatedwithhowtheparticipantmayparticipate inaProgram. DRASCliententitiesthatdescribetheDRASClientsthattheparticipantwilluse tocommunicatewiththeDRAS. Biddinginformationforanystandingbidthattheparticipantmaysetup. ContactinformationfortheDRAStosendnotificationstotheparticipant operators.

TheParticipantAccountentityiscreatedbytheutilityandvariousfieldsmaybeeditedby theparticipant.SeeSection8.5foramoredetaileddescriptionoftheParticipantAccount entity.

44

Figure 8. Utility Configuration Entities

45

6.4.1.3 Utility Manages Bids WhenaparticipantsubmitsbidstoparticipateinaDRevent,thosebidsaresenttothe utilityorISO.ThedataentitiesusedtorepresentthebidsaredescribedinSection6.4.2.2. 6.4.1.4 Utility gets Logs and Alarms TheDRASisrequiredtomaintainlogsandtrackalarmsthatrecordavarietyof activitiesassociatedwiththeDRAS.Thedataentitiesusedtorepresenttheseactivities areshowintheconceptualERdiagramsinFigure9.Eachentitycontainsenough informationsothatitispossibletodeterminewho,when,andwhatwasinvolved.These aredescribedinmoredetailinSection8.7.

Figure 9. Utility Logs and Client Alarms

6.4.2 Data Entities in Support of Participant Operator Functions


6.4.2.1 Participant Configuration TheconceptualERdiagram,Figure10,showsthevariousentitiesthatmaybecreated andconfiguredbytheparticipant.Theyrepresentthepiecesofdatathatareusedfor variousoperationsinvolvingtheparticipant. TheutilityorISOcreatesaParticipantAccount.Theparticipantmayeditonlyasubsetof theattributesassociatedwiththisentity.SeeSection8.5foradetaileddescription.

46

TheparticipantmaydefineanumberofProgramConstraints.Eachoftheseisassociated withaparticularprogramanddefineslimitationsofhowaparticipantmayparticipate inthatprogram.NotethattheProgramConstraintswhicharedefinedforaparticular participantareintendedtocustomizethevariousscheduleattributesofhowa participantparticipatesinaprogramandaredistinctfromtheProgramConstraintsthata utilitymaydefinegloballyforaprogram.TheProgramConstraintsfortheparticipant supersedetheProgramConstraintsthataredefinedfortheprogramasawhole.See Sections6.5.2.2and8.4foradetaileddescriptionofthisentity. AParticipantAccountmayhaveanumberofBidentitiesthatrepresentstandingbids associatedwithspecificprogramsthatmayrequirebidding.SeeSections6.6and8.11for amoredetaileddescriptionofthisentity. AParticipantAccountmayalsodefineanumberofDRASCliententities.ADRASClient entityrepresentstheinformationassociatedwithaDRASClientandincludesthe followingtypesofinformation: TypeofDRASClientSimpleorSmarttype. ProgramsthattheDRASClientmayparticipatein. ProgramConstraintsthatdefinehowtheDRASClientwillparticipateinprograms. CommunicationsparametersthatdefinehowtheDRASClientcommunicates withtheDRAS. Locationinformation. ResponseScheduleentitiesforthevariousprogramsanddynamicpricingthatthe DRASClientmayparticipateiniftheDRASClientisaSimpletype.

SeeSection8.10foramoredetaileddescriptionofaDRASCliententity.SeeSection 6.5.3.2foramoredetaileddescriptionofSimpleandSmartDRASClients. TheResponseScheduleentitiesareusedbySimpleDRASClientsandrepresentthe translationoftheDReventinformationintosimplelevelsandstatus.Asshowninthe Figure10aResponseScheduleentityisacollectionofOperationStates.SeeSections6.5and 8.3foramoredetaileddescription.

47

Figure 10. Participant Configuration Entities

48

6.4.2.2 Participant Operator Submit Bids WhenaDReventisissuedbytheutilityorISOrequiringbiddingthentheparticipant usestheBidentitytosubmitthosebids.TheBidentityisdescribedinmoredetailin Section8.11.

Figure 11. Participant Submit Bid Entity

6.4.2.3 Participant Operator Opt-out State of DR Events AparticipantmaychoosetooptoutoroverrideparticipatinginDRevents.The participantdoesthisbyusingtheOptOutStateentitytosetuponeormoreconditions withintheDRASthatdefinewhentheparticipantwillnotparticipateinaDRevent.The OptOutStatemayhavethefollowingattributes: WhichDRprogramstheconditionsapplyto.Ifnotspecified,itdefaultstoall programs. WhichDRASClientstheconditionsapplyto.Ifnotspecified,itdefaultstoall DRASClients. WhichDReventtheconditionsapplyto.Ifnotspecified,itdefaultstoallDR events. Aschedulewhichdefineswhentheconditionsapply.

Notethattherecanbemorethanonesuchsetofconditionsestablishedbythe participant.SeeSection8.6.

49

Figure 12. Participant Opt-Out Entities

6.4.2.4 Participant Operator Submits Feedback TheparticipantmayusetheParticipantFeedbackentitytonotifytheDRASaboutvarious conditionsorinformationrelatedtotheparticipant.Examplesincludedemanddataand howtheparticipantisrespondingtoaDRevent.TheFeedbackinformationcanberead bytheutilityorISO.SeeSection8.8foramoredetaileddescriptionofthe ParticipantFeedbackentity.NotethatParticipantFeedbackmaybesubmittedbyvarious roleswithinthesystembothhumanandmachine.Thisentitywouldbeusedbyallsuch transactionstosubmitthefeedback.

50

Figure 13. Participant Feedback Entities

6.4.2.5 Participant Operator gets Logs and Alarms TheDRASisrequiredtomaintainlogsandtrackalarmsthatrecordavarietyof activitiesassociatedwiththeDRAS.Thedataentitiesusedtorepresenttheseactivities areshowintheconceptualERdiagramsinFigure14(repeatedhereforreference;Figure 14isthesameasFigure9).Eachentitycontainsenoughinformationsothatitispossible todeterminewho,when,andwhatwasinvolvedinaDRevent.Thesearedescribedin moredetailinSection8.7.Theparticipantoperatorisonlyallowedtoaccesslogsfor whichtheyhaveaccessrights,i.e.thoseitemsrelatedtotheirParticpantAccounts.

51

Transactions Logs

user name role date/time stamp method name description result

DRASClientAlarms

date/time stamp DRAS Client ID Description status Figure 14. Client Alarms and Utility Logs

6.4.3 Data Entities In Support of DRAS Client Functions


AsshownintheconceptualERdiagram,Figure15,theinteractionbetweentheDRAS andtheDRASClientinvolvestwoentities.ThefirstistheEventStatewhichisa representationofthestatethattheDRASClientmaybeinwithrespecttoaDRevent. ThisentityissentfromtheDRAStotheDRASClient.Thesecondisaconfirmation message(EventStateConfirmation)oracknowledgementthattheDRASClientsendstothe DRAStonotifytheDRASthatithasreceivedanEventStatemessage.Notethatmostof thefieldsintheEventStateConfirmationaresimplycopiesofthefieldsfromtheEventState messagethatitisreplyingto.NotethattheDRASNamefieldprovidesameansfor DRASClientstointeractwithmorethanoneDRASeventhougheachDRASmayhave noknowledgeorinterdependenciesbetweenthem. TheEventStatecontainsalltherelevantinformationthatdescribesaspecificDReventto theDRASClient.ThesameEventStateentityisusedforbothSimpleandSmartDRAS Clienttypes.TheEventStateisdescribedinmoredetailinSections6.5.3and8.12.Note thatspecificWebserviceinterfacesmayhaveaslightlydifferentschemaforthe EventStateasdescribedinSection9.3.

52

Figure 15. DRAS Client DR Event State Entities

6.5

DR Event Models

ThissectiondetailshowDReventsareviewedandmodeledbytheutilityorISOthat initiatetheeventsandtheDRASClientsthatreceivetheevents. ThegeneralassumptionsconcerningtheissuingofDReventswithintheDRASinclude: TheDRASisassumedtobemanagedbyasinglebusinessentity.Whilethere maybemultipleutilityorISOoperatoraccounts,thereisonlyasinglebusiness

53

entitythatisresponsibleforissuingDRevents.Thismeansthatifthereisa DRASthatismanagedbyathirdpartytherecannotbemorethanoneutilityor ISOthatcanissueDReventsthroughthatDRAS.Thisassumptionisdesignedto avoidconflictsbetweeneventsandotherissuesthatshouldberesolvedbythe entitythatisissuingtheDRevents. OnlyoneeventforaspecificDRASClientmaybeactiveatanytime.Seebelow foramoreformaldefinitionofanactiveevent.Theremaybemultipleevents issuedandpending,butonlyoneofthemwillbeactive. DRprogramsmayhaveapriorityassociatedwiththem. DReventswithoverlappingactiveperiodsmaybeissued,butonlyiftheyare fromdifferentprogramsanddynamicpricingandonlyiftheprogramshavea priorityassociatedwiththem.DReventsforprogramsanddynamicpricingwith higherprioritiessupersedetheeventsofprogramsanddynamicpricingwith lowerpriorities.Iftwoprogramsanddynamicpricingwithoverlappingevents havethesameprioritythentheprogramwhoseeventwasactivatedfirsttakes priority.

6.5.1 Utility or ISO View of a DR Event


WhentheutilityorISOinitiatesaDReventitusesanUtilityDREvententitywhich containsthefollowinggeneralattributes: TheDRprogramtheeventisfor. Timeanddateparametersconcerningwhentheeventwilltakeplace. Timeanddateparametersconcerningwhenparticipantsshouldbenotifiedof theupcomingevent. Whoand/orwheretosendtheDReventinformation. Informationassociatedwiththeevent(EventInfo).Thisisprogramspecific informationthatisrelatedtotheevent,e.g.RTPorshedorshiftlevel.

6.5.1.1 DR Event Time Parameters and States Figure16showsthedifferenttimeparametersassociatedwithDReventstates.The participantsarenotifiedofanupcomingeventattheIssueTime(A).Thetimeperiod betweentheEventStartTime(B)andtheEventEndTime(C)isknownasthe ACTIVEstatefortheDRevent.TheACTIVEstatefortheDReventistheonlystate ortimeduringwhichtheEventInfoisvalid.ThetimeperiodfromtheIssueTime(A)till theStartTime(B)isthePENDINGstateoftheDRevent.ThePENDINGstateofthe DReventisthetimeduringwhichtheDReventispending,IDLEperiods,with respecttothisDRevent,arethetimesbeforetheIssueTime(A)andaftertheEndTime (C).EventInformation(D)istheinformationassociatedwithaDReventSeeSection 6.5.1.2forwhatinformationisincluded.Anotherwaytolookatstatetransitionsis providedinFigure17;thisfigureisdescribedindetailinSection6.5.3.4.

54

Figure 16. DR Event Model (Utility or ISO View)

Figure 17. State Transition Diagram

6.5.1.2 DR Event Information DRprogramsanddynamicpricingaretypicallydesignedtouseavarietyofinformation tocausereactionsbyparticipantstoDReventsthatareissuedbytheutilityorISO.In somecasespricesareusedtotriggerresponsestotheDReventswhileinothercaseit mightbeashedorshiftlevel.Ingeneraltherecanbeawiderangeofdifferenttypesof informationassociatedwithaDReventdependinguponhowtheDRprogramwas designed.Thereforethedatamodelsusedtodescribetheinformationassociatedwith

55

DReventsaredesignedtoaccommodatethewiderangeofinformationthatmaybe associatedwithaDRevent.ThisinformationisrepresentedbyEventInfoentities. WhenaprogramisdefinedwithintheDRAStherearespecificationsassociatedwiththe programthatdefinewhattypeofinformationmaybeassociatedwithaDReventwhen oneisissuedforthatprogram.EachtypespecificationforanEventInfoisreferredtoas anEventInfoType.Aprogrammaybedefinedthatallowsformultipledifferenttypesto beassociatedwithaprogram.EachEventInfoTypecontainsthefollowingattributesand elements. EventInfoType namethisisthenameofthetypeofeventinuse.Analogoustoavariablename. typeIDthisidentifiesthetypeofinformationandmaytakeononeofthe followingvalues: o o o o o o o PRICE_ABSOLUTEPricenumber,i.e.$0.25 PRICE_RELATIVEChangeinprice,i.e.$0.05 PRICE_MULTIPLEMultipleofcurrentprice,i.e.1.5 LOAD_LEVELAmountofloadbasedonanenumeration,i.e.moderate, high,etc. LOAD_AMOUNTFixedamountofloadtoshedorshift,i.e.5MW LOAD_PERCENTAGEPercentageofloadtoshedorshift,i.e.10% GRID_RELIABILITYNumberfrom0100signifyingthereliabilityofthe grid.100signifiesthehighestlevelofreliabilitywhile0isthelowest.

scheduleTypeThisspecifieshowaschedulemaybeassociatedwiththeDR eventinformationisdefinedandmaytakeonthefollowingvalues: o o o NONEthereisnoscheduleandthusEventInfodoesnotchangevalues duringtheentireDReventACTIVEstate. DYNAMICThetimescheduleisnotfixedduringconfiguration,butcanbe setwhentheDReventisissued. STATICThescheduleisfixedwhentheDRprogramisconfiguredwithin theDRAS

scheduleIfthescheduleTypeisSTATIC,thisistheconfiguredschedule.A scheduleisasequenceoftimeslotsthatarevalidovertheentireACTIVEperiod ofaDRevent. enumerationsThisisalistthatdefinesafixedsetofvaluesthattheEventInfo instancemaytake.Ifdefined,theEventInfoinstanceisanenumerationandcan takeonanyofthevaluesinthelist.Ifleftundefined,theEventInfoinstancecan takeonanycontiguousvaluebetweentheminValueandmaxValue. minValueminimumpossiblevalueofanEventInfoinstance. maxValuemaximumpossiblevalueofanEventInfoinstance.


56

NotethatwhenaDReventisissuedtheEventInfoinstancesthatareassociatedwiththe DReventmaytakeonvaluesthatchangeaccordingtosomescheduleduringthe ACTIVEstateoftheDRevent.Alsonotethattheschedulethatdefineswhenthese valueschangemaybedefinedaspartofthedefinitionofanEventInfoTypeoritmaybe definedwhentheDReventisissued.SeeSection8.9foradetaileddescriptionofthe EventInfoTypeschema. HowtheEventInfoTypesareusedbytheDRASClientsvariesdependinguponwhetherit isaSimpleorSmartDRASClient.SeeSection6.5.3foramoredetaileddescriptionof howDRASClientsviewDReventsandhowtheyusetheEventInfoinstancesandtypes ofinformation.

6.5.2 Propagation of DR Events by the DRAS


ThepropagationofDReventsfromtheutilityorISOtotheDRASClientsiscontrolled byanumberofdataentitiesandparametersthatareconfiguredbytheutilityorISO and/ortheparticipant.Ingeneralthereexiststhefollowinghierarchy: Programsanddynamicpricing(DReventsareissuedaspartofaprogram) Participantswhichbelongtoprograms o DRASClientswhichbelongtoparticipantsandprograms

WhenaDRevent(UtilityDREvent)isissuedthereisasocalleddestinationattribute whichspecifieswhichDRASClientswillultimatelyreceivetheDReventinformation. Thedestinationspecificationmaytakeononeormoreofthefollowingattributes: ParticipantsthisisalistofparticipantsthatreferenceParticpantAccountentities thatshouldreceivetheDRevent.Ifaparticipantisspecifiedthenitisassumed thatalltheDRASClientsthatbelongtothatparticipantwillreceivetheDR event.TheexceptionsarethoseDRASClientsthatexplicitlydonotbelongtothe programthattheDReventwasissuedfor. GroupsParticipantscanbelongtoaUtilityGroup.UtilityGroupsareusedasa shorthandwayofspecifyingmorethanoneparticipant.SpecifyingaUtility Groupisfunctionallyequivalenttospecifyingeachindividualparticipantthat belongstothatgroup. DRASClientsthisissimplyanexplicitlistofthespecificDRASClientsthat shouldreceivetheDRevent. LocationEachoftheDRASClientsmayhavealocationattributethatisusedto specifywheregeographicallyorontheutilityorISOgridthataDRASClientis located.ThatlocationattributecanbeusedasameanstospecifywhichDRAS ClientsshouldreceiveaDRevent.

EachoftheattributesabovemaybeusedtodefineasetofDRASClients.Forexample eachparticipantmayhaveoneormoreDRASClientsassociatedwiththeiraccounton

57

theDRAS.ThereforeifaparticularParticipantAccountisspecifiedthenitisreferringto alltheDRASClientsassociatedwiththataccount.Sinceeachoftheattributesabove representadifferentcriteriaforspecifyingasetofDRASClientstheycanbeusedin conjunctionwitheachothertospecifyaspecificsetofDRASClientsbylogicallytaking theintersectionofallthesetsofDRASClientsthatarespecifiedbyeachattribute. Itshouldbenotedthatthesepropagationrulesareaformofbusinesslogicwithinthe DRASandmustbeimplementedbyeachDRASthatcomplieswiththisOpenADR specification.ThevariousparametersandassumptionsthattheDRASmustfolloware showninFigure18.

Figure 18. Relevant Attributes and Structures for Event Propagation

58

6.5.2.1 DR Event Propagation Examples Figures19through26showshowaDReventmustbepropagatedbytheDRASbased uponvariousdestinationparameters.Figure19providesthesampleconfigurationthat willbeusedasabasisforFigures20through26,whichprovideexamplesofhowthe sameconfigurationmaybeusedtopropagateDReventsindifferentwaysdepending uponthedestinationspecificationforaDRevent.Theboldarrowsineachdiagram illustratewheretheDReventislogicallybeingpropagated,including:

DREventPropagationforprogramP2AllParticipantAccounts(Figure20) DREventPropagationforProgramP2SpecificParticipantAccountsA3,A4( Figure21) DREventPropagationforProgramP1SpecificParticipantAccountA1(Figure 22) DREventPropagationforProgramP2GroupsG2,G4(Figure23) DREventPropagationforProgramP2SpecificDRASClientsC1,C4,C5(Figure 24) DREventPropagationforProgramP2SpecificLocationsL1,L3(Figure25) DREventPropagationforProgramP2GroupsG2andParticipantsA4Specified (Figure26)

59

DR Event - Program P1 - Destinations - Participants: none - Groups: none - DRAS Client: none - Location: none

Participant Acct A1 - Programs: P1, P2 - Groups: G1, G2

Participant Acct A2 - Programs: P1,P2,P3 - Groups: G2, G3

Participant Acct A3 - Programs: P2 - Groups: G3

Participant Acct A4 - Programs: P2, P3 - Groups: G3, G4

DRAS Client C1 - Programs: ALL - Location: L1, L2

DRAS Client C2 - Programs: P1 - Location: L3

DRAS Client C3 - Programs: ALL - Location: L1

DRAS Client C4 - Programs: P2 - Location: L2

DRAS Client C5 - Programs: ALL - Location: L3

DRAS Client

DRAS Client

DRAS Client

DRAS Client

DRAS Client

Figure 19. Sample Configuration - Participant Accounts and DRAS Clients

60

Figure 20. DR Event Propagation for Program P2All Participant Accounts

61

Figure 21. DR Event Propagation for Program P2Specific Participant Accounts A3, A4

62

Figure 22. DR Event Propagation for Program P1Specific Participant Account A1

63

Figure 23. DR Event Propagation for Program P2Groups G2, G4

64

Figure 24. DR Event Propagation for Program P2Specific DRAS Clients C1, C4, C5

65

Figure 25. DR Event Propagation for Program P2Specific Locations L1, L3

66

Figure 26. DR Event Propagation for Program P2Groups G2 and Participants A4 Specified

67

6.5.2.2 Program Constraints ThissectiondescribeshowsocalledprogramconstraintseffectthepropagationofDR events.ProgramconstraintsarerepresentedbytheProgramConstraintentity.The ProgramConstraintentityrepresentsasetofparametersthatconstrainvarioustimeand dateparametersassociatedwithaparticularDRevent.SeeSections6.4.1.2and8.4fora moredetaileddiscussionoftheProgramConstraintentity.WhenaDReventisissuedthe DRAScomparestheparametersoftheDReventagainstvarioussetsofprogram constraintsastheDReventispropagated.Figure27showsthedifferentpointsatwhich ProgramConstraintvariablesmaybeappliedtoaDReventasitispropagatedtoaspecific DRASClient. FirsttheDRAScomparestheDRprogramagainstProgramConstraintvariablesthatare configuredtobepartoftheprogram.InadditiontoProgramConstraintvariables associatedwithaprogramasawholeitispossiblefortheutilityorISOtocreate ProgramConstraintvariablesthatareapplicabletoasingleDRevent.IfProgramConstraint variablesexistforasingleDReventthentheywillsupersedeanyProgramConstraint variablesthatmayexistfortheprogramasawhole.Nocomparisonsaremadeifa programoraDReventdoesnothaveProgramConstraintvariables. NexttheDReventiscomparedagainsttheProgramConstraintvariablesforevery participantthatisdeemedtoreceivetheDRevent.Eachparticipantmayormaynot associateasetofProgramConstraintvariableswiththeirParticipantAccountthatare relatedtoaparticularprogram.IftherearenoProgramConstraintvariablesforthe participantandprograminquestionthennocomparisonisdone. NexttheDReventiscomparedagainstProgramConstraintvariablesforeveryDRAS ClientthatisdeemedtoreceivetheDReventasdescribedabove.EachDRASClient mayormaynotassociateasetofProgramConstraintvariablesthatarerelatedtoa particularprogram.IftherearenoProgramConstraintvariablesfortheDRASClientand programinquestionthennocomparisonisdone. TheattributesoftheProgramConstraintvariablesatsuccessivelevelsmustnotbein conflictwiththeattributesatthelevelaboveit.Whatthismeansisthatattributesofthe ProgramConstraintvariablesofaDRASClientmustnotbeinconflictwithattributesof theProgramConstraintvariablesofaparticipantwhichareinturnmustnotbeinconflict withattributesoftheResponseScheduleforaprogramasawhole.Constraintsare consideredtobeinconflictifitisimpossibleforanyDReventtosatisfyanyofthe constraints.

68

Figure 27. DR Event Constraint Model (Which DRAS Clients Receive the Event)

69

Figure28showsthecomparisonprocessoftheDReventasitprogressesthroughtheDR eventpropagationprocess.ThevariousparameterscomparedagainsttheissuedDR eventinclude: EventwindowthisisthevalidtimewindowduringthedaythataDReventcan occur. EventdurationthisisthemaximumeventdurationforaDRevent. Notificationwindowthisistheminimumandmaximumtimebeforeanevent thataparticipantcanbenotifiedofaDRevent. BlackoutdatesthesearedatesduringwhichDReventscannotbeissued. ValiddatesthesearethedualoftheblackoutdatesandrepresenttheONLY datesduringwhichaDReventmaybeissued. MaxconsecutivedaysthisisthemaximumconsecutivedaysthataDReventcan beissued.

Eachoftheseparametersisoptional,butiftheyaredefinedthentheyarecomparedto thefollowingDReventparameters:

Notificationtime Starttime Endtime

Figure 28. Program Constraints and Filters

TheprocessofcomparisoncheckstheparametersoftheDReventagainsttherelevant parametersoftheProgramConstraintentity.IfthereisamismatchthentheDRASmust takeanactionwhichisfurtherspecifiedintheProgramConstraintentity.Eachparameter intheProgramConstraintentityhasacorrespondingattributewhichspecifieshowthe DRASwillrespondtomismatchesbetweentheDReventandtheProgramConstraint entity.Thepossibleactionsarethefollowing: ACCEPTsimplyaccepttheissuedDReventregardlessofanyconflicts. REJECTrejectanyDReventsthatconflictwithconfiguredconstraints.

70

FORCEregardlessofwhattheissuedDReventsparametersare(evenifthereis noconflict)forcethemtobetheparametersthatwereconfiguredinthe ProgramConstraintentity. RESTRICTmodifytheDReventparameterssothattheylegallyfallwithinthe boundsoftheattributesintheProgramConstraintentity.

EachofthesearereferredtoasfilterconstraintssincetheyspecifyhowtheDRevent maybefilteredbytheDRAS. Figures28through30illustratethevariousactionstakenwhentherearemismatches betweentheDReventandtheattributeoftheProgramConstraintvariables.Eachdiagram representsadifferentschedulerelatedattributeoftheDReventandhowthatspecific attributeishandledwhenthereisaconflictbetweentheDReventthatisissuedand someProgramConstraintthatitisbeingcomparedagainst.

Figure 29. DR Event Window Depending Upon Filter Constraints

71

Figure 30. DR Event Notification Time Depending Upon Filter Constraints

Figure 31. DR Event Duration Depending Upon Duration Constraints

6.5.3 DRAS Client View of DR Events


ThissectionpresentstheDReventmodelusedbytheDRASClient. WhenaDReventisissuedbytheutilityorISO,informationconcerningtheDReventis senttothevariousDRASClientsattheappropriatetimedependinguponthestateofthe DReventandthestateoftheDRASClient.ThetypeofinformationsentfromtheDRAS totheDRASClientconcerningtheDReventincludesthefollowing:

72

DRASClientidentifier ProgramnameassociatedwiththeDRevent IdentifierfortheDReventthatwasissuedbytheutilityorISO TransactionidentifierfortheDReventmessage.UsedtoidentifyspecificDR eventmessages. FlagtosignifyiftheDReventisatestmessage FlagtosignifywhethertheDRASClientisonoroffline SimpleDRASClientdatathisdataisintendedtobeusedbySimpleDRAS Clients o o o o Eventstatus Operationmodevalue Currenttime Operationmodeschedule

SmartDRASClientdatathisinformationisintendedtobeusedbySmartDRAS Clients. o o o o Eventnotificationtime Eventstarttime Eventendtime Eventinformation(EventInfoinstances)

Customdatathisisaplaceholderforinformationthatisintendedtobeusedfor purposesbeyondthescopeofthisdocument.Itmaybeusedtosendproprietary commandsorinformationtoaDRASClient.

ThiscollectionofinformationisrepresentedbytheEventStateentityandrepresentsthe statethataDRASClientisinwithrespecttoaparticularDRevent.SeeSection8.12fora moredetaileddescriptionoftheEventStatedatamodelandschema. ThisrestofthissectiondescribesinmoredetailhowtheEventStateentityisexchanged withtheDRASClient. 6.5.3.1 Modes of Interaction (PUSH versus PULL) TheDRASandtheDRASClientmayexchangeEventStateinformationusingtwo differentmodesofinteractionPUSHandPULL. InthePUSHmode(Figure32),theEventStateinformationispushedfromtheDRAS totheDRASClient.ThismeansthatthecommunicationoftheEventStateinformationis initiatedbytheDRAS.IntermsofWebservicesthismeansthatthatDRASClientisthe WebserverandtheDRASistheWebclient.

73

Figure 32. PUSH Model Sequence Diagram

NotethatinthePUSHmodelofinformationexchangetheEventStateistransmittedto theDRASClientwheneverthestateoftheDReventthatisbeingmonitoredbythe DRASchanges.ThevariousstatesoftheEventStatearediscussedmoredetailbelow. InthePULLmode(Figure33),theEventStateinformationispulledfromtheDRASby theDRASClient.ThismeansthatthecommunicationoftheEventStateinformationis initiatedbytheDRASClient.InotherwordstheDRASClientpollstheDRASforthe EventStateinformation.IntermsofWebservicesthismeansthattheDRASistheWeb serverandtheDRASClientistheWebclient.InthePULLmodelofinformation exchangetheEventStatemayberequestedbytheDRASClientatanytime.

Figure 33. PULL Model Sequence Diagram

NotethatinbothcasestheDRASClientsendsaconfirmationmessagetotheDRAS uponreceiptoftheEventStateinformation.Thisconfirmationmessageisintendedto giveanadditionallevelofconfirmationbeyondthereliablecommunicationsusedfor theWebservicesinterfaceandtoallowtheDRASClienttogiveadditionalinformation

74

relatedtohowitintendstorespondtotheDRevent.Moreinformationconcerningthe detailsoftheconfirmationmessagedatamodelcanbefoundin8.12. TheDRASmustusetheEventStateConfimationmessageasameanstoconfirmthatthe DRASClienthasreceivedtheEventStateinformation.IfanEventStateConfirmation messageisnotreceivedwithinsometimeoutperiodthentheDRASmustassumethat theEventStatemessagewasnotreceivedbytheDRASClient. TheDRASmustsupporttwowaycommunicationsforboththePUSHandthePULL modelofinteraction,buttheDRASClientisonlyrequiredtosupportoneortheother. TypicallythePULLmodelmaybeusedsincetheDRASClienthasmorecontroloverthe communicationsincludingtheabilitytomoreeasilycommunicatethroughfirewallsand beingnetworkfriendly.ThePUSHmethodwouldtypicallybeusedinscenarioswhere verylowlatencyofthemessagesdeliveryisrequiredwhenastatechangeoccurs.The specificsituationofimplementingPUSHversusPULLmodelsisoutsidethescopeof thisdocument. 6.5.3.2 Simple Versus Smart DRAS Clients TheDRASsupportstwodifferenttypesofDRASClientsSimpleandSmart. TheSmartDRASClientisassumedtobecapableofdealingwithalltheEventInfo informationthatmaybeassociatedwithaDReventthatisinitiatedbytheutilityorISO. ItcanparsealltheEventInfoinformationandmakedecisionsabouthowtorespondto thatparticularDReventinformation. OntheotherhandtherearemanycaseswhereaSimpleDRASclientisneeded.These caseshavesimplifiedEMCSthatareincapableofanysophisticatedlogicortheabilityto dealwiththewiderangeofinformationtypesthatmaybeassociatedwithaDRevent. Inthesecases,theDRAStranslatestheEventInfoinformationassociatedwithaDRevent intoamuchsimplerform,knownasaSimpleDRASClient. TheDRASmustbecapableofdealingwithbothSmartandSimpleDRASClients. Detailsonbothofthesescenariosaredescribedbelow. 6.5.3.3 DR Event Information DRprogramsaretypicallydesignedtouseavarietyofinformationtocausereactionsby participantstoDReventsthatareissuedbytheutilityorISO.Insomecasespricesare usedtotriggerresponsestotheDReventswhileinothercasesitmightbeashedorshift level.Ingeneraltherecanbeawiderangeofdifferenttypesofinformationassociated withaDReventdependinguponhowtheDRprogramwasdesigned.Thereforethe datamodelsusedtodescribetheinformationassociatedwithDReventsaredesignedto accommodatethewiderangeofinformationthatmaybeassociatedwithaDRevent. ThisinformationisrepresentedbyEventInfoInstanceentities. WhenaprogramisdefinedwithintheDRAStherearespecificationsassociatedwiththe programthatdefinewhattypeofinformationmaybeassociatedwithaDReventwhen

75

oneisissuedforthatprogram.EachtypespecificationforanEventInfoInstanceisreferred toasanEventInfoType.Aprogrammaybedefinedthatallowsformultipledifferent typestobeassociatedwithaprogram.EachEventInfoTypecontainsthefollowing attributesandelements: EventInfoType namethisisthenameofthetype.Analogoustoavariablename. typeIDthisidentifiesthetypeofinformationandmaytakeononeofthe followingvalues: o o o o o o o PRICE_ABSOLUTEPricenumber,i.e.$0.25 PRICE_RELATIVEChangeinprice,i.e.$0.05 PRICE_MULTIPLEMultipleofcurrentprice,i.e.1.5 LOAD_LEVELAmountofloadbasedonanenumeration,i.e.moderate, high,etc. LOAD_AMOUNTFixedamountofloadtoshedorshift,i.e.5MW LOAD_PERCENTAGEPercentageofloadtoshedorshift,i.e.10% GRID_RELIABILITYNumbersignifyingthereliabilityofthegrid

scheduleTypeThisspecifieshowaschedulemaybeassociatedwiththeDR Eventinformationisdefinedandmaytakeonthefollowingvalues: o o o NONEthereisnoscheduleandthustheEventInfodoesnotchangevalues duringtheentireDReventACTIVEstate. DYNAMICThetimescheduleisnotfixedduringconfiguration,butcanbe setwhentheDReventisissued. STATICThescheduleisfixedwhentheDRprogramisconfiguredwithin theDRAS

scheduleIfthescheduleTypeisSTATICthenthisistheconfiguredschedule.A scheduleisasequenceoftimeslotsthatarevalidovertheentireACTIVEperiod ofaDRevent.Eachtimeslotmaytakeonadifferentvalueinthe EventInfoInstance enumerationsThisisalistthatdefinesafixedsetofvaluesthattheEventInfo instancemaytake.Ifdefined,theEventInfoInstanceisanenumerationandcan takeonanyofthevaluesinthelist.Ifleftundefined,theEventInfoinstancecan takeonanycontiguousvaluebetweentheminValueandmaxValue. minValueminimumpossiblevalueofanEventInfoInstance. maxValuemaximumpossiblevalueofanEventInfoInstance.

NotethatwhenaDReventisissued,theEventInfoInstancevariablesthatareassociated withtheDReventmaytakeonvaluesthatchangeaccordingtosomescheduleduring theACTIVEstateoftheDRevent.Alsonotethattheschedulethatdefineswhenthese valueschangemaybedefinedaspartofthedefinitionofanEventInfoTypeoritmaybe

76

definedwhentheDReventisissued.SeeSection8.9foradetaileddescriptionofthe EventInfoTypeschema. NotethattheDRASClientneverseestheEventInfoTypedefinitionswithintheDRAS. Nonethelessitisusefultounderstandtheirstructureinordertounderstandhowthe DRAStranslatesinformationfromthevariousEventInfoInstancevariablesdescribed belowintothesimplelevelsusedbyaSimpleDRASClient. TheEventInfoTypedefinesthetypeofinformationthatisassociatedwithaDReventand arespecifiedaspartofaprogram.ThuswhenaDReventisactuallyinitiateditcontains instancesoftheEventInfoTypethatweredefinedtobelongtotheprogram.These instancesarereferredtoasanEventInfoInstanceandfromtheDRASClientspointofview aredefinedasfollows. EventInfoInstance eventInfoNamethisisthesameasthenamefieldinthecorresponding EventInfoTypedefinition. eventInfoTypeIDThisisthetypeidentifierofthedataandtakesonthevalue definedinthetypeIDoftheEventInfoTypedefinition. eventInfoValuesThesearetheactualvaluesoftheinstances.Theremaybemore thanoneifthereisascheduleofvalues.

SeeSection8.12foradetaileddescriptionoftheEventInfoInstanceschema,especiallyasit appliestohowthescheduleofvaluesisdefined.
6.5.3.3.1 Smart DRAS Client Event Information

TheEventStatemessagesenttoaDRASClientcontainsthefollowingsetoffields: SmartDRASClienttypedatathisinformationisintendedtobeusedbySmart DRASClient o o o o Eventnotificationtime Eventstarttime Eventendtime Eventinformation(EventInfoInstance)

ThisinformationisderiveddirectlyfromtheDRevent(UtilityDREvent)thatwasissued bytheutilityorISO.Theeventinformationfieldissimplythecollectionof EventInfoInstancedataasdescribedabove.Ingeneraltheeventtiming(notification,start, andendtimes)isthesameaswhatwasspecifiedintheDReventwhenitwasissuedby theutilityorISO,buttheremaybeexceptionsiftherewereProgramConstraintvariables definedwithintheDRASthatcausedthesevaluestobealtered.Formoreinformation onProgramConstraintseeSection6.5.2.2. ItisassumedthataSmartDRASClientiscapableofparsinganddealingwiththe variousfieldsdefinedabove.

77

6.5.3.3.2 Simple DRAS Client Event Information

ItisassumedthataSimpleDRASClienttypeisnotcapableofdealingwiththe sophisticationoftheinformationthataSmartDRASClientis.ThereforetheEventState informationforaparticipantwithaSimpleDRASClientisasimplifiedderivationofthe informationsentbytheutilityorISOwhentheDReventisinitiated.Inthiscasethere arethefollowingtwostatevariablesthatdescribetheDReventstate: OperationMode:Thisdepictstheoperationalstateofthefacilityandcantakeon thefollowingvalues: (1) NORMALoperation (2) MODERATEshedorshift (3) HIGHshedorshift (4) SPECIAL EventStatus:ThisdepictsthecurrenttemporalstateofaDReventandcantake onthefollowingvalues: (1) NONEnoeventpending (2) FAReventpendingfarintothefuture. (3) NEAReventpendingsoon. (4) NOWeventcurrentlyinprocess. Ingeneral,theEventstatusvariablealwaystransitionsfromNONEtoFARtoNEARto NOW.ThetransitionfromFARtoNEARisaconfigurableparameterofaprogramand infacttheremaynotevenbeaNEARstateinwhichcasetheFARvaluecouldsimplybe interpretedasmeaningEventPending. TheOperationModevariabletakesonvaluesaccordingtoascheduleduringtheevent thatisdefinedbytheparticipantortheutilityorISO.Thisscheduleisspecifiedbyusing asetofrulesthatdeterminehowtheEventInfoInstanceoftheUtilityDREventistranslated intooneofthesimplevaluesoftheoperationmode.Sincetheparticipantisfreeto schedulehowtheOperationModevariablechanges,thisdefinesasocalledResponse ScheduleforhowthatparticipantrespondstoDRevents.Theresponsescheduleis representedbytheResponseScheduleentity. AResponseScheduleisanorderedlistofrulesrepresentedbytheOperationStateSpec entity.AnOperationStateSpecwithinaResponseSchedulerepresentsasetofrulesthatare validwithinaspecifictimeslotoftheACTIVEperiodoftheDRevent.Theserules dictatehowtheOperationModevariablewilltransitionduringthetimeslotofthe OperationStateSpecThetimeslotsthatdefinethedifferentOperationStateSpecentities formpointsatwhichtheOperationModevaluesmaytransition,buttheOperation Modevaluesmayalsotransitionattimesinthemiddleofthetimeslotassociatedwith anOperationStateSpecifthevalueassociatedwithanEventInfoInstancehappenstochange then.

78

TheruleswithinanOperationStateSpecareexpressedintermsofatablewhereineach rowinthetablerepresentsaBooleanequationsuchthatiftheequationistruethenthe correspondingOperationModevaluewillbeset.TheequationsareBoolean comparisonsoftheexistingEventInfoTypenamesforthisprogram.Table3isanexample tableforasingleOperationStateSpecentitywheretherearetwoEventInfoTypeswiththe namesofRTPandBIDthatweredefinedfortheprogram.


Table 3 OperationStateSpec Entity Value MODERATE SHED OR SHIFT HIGH SHED OR SHIFT MODERATE SHED OR SHIFT SPECIAL NORMAL OPERATION Equation RTP > 5 & BID > 10 RTP > 10 & BID > 10 RTP > 5 & BID < 5 RTP > 15 TRUE

Notethateachrowinthetableisevaluatedfromtoptobottomuntiloneofthe equationsistrue.Whicheverequationistruethenthecorrespondingvalueisusedtoset theoperationmodevalue.Notethatifnoneoftherowsaretruethentheoperation modevaluedoesnotchange.ItisthereforegoodpracticetoputadefaultTRUEvalueat theveryendwhichwillbeusedifnoneoftheotherequationsaretrue. ThefollowingBooleanoperationsshouldbesupported: AND OR XOR NOT GREATERTHAN,GREATERTHANOREQUAL LESSTHAN,LESSTHANOREQUAL EQUAL,NOTEQUAL GROUPING,i.e.parenthesis

Ingeneraltheequationcanberepresentedasasimplestring.Itisbeyondthescopeof thisdocumenttodefinetheexactsyntaxoftherulesstrings. Figure34showsanumberofdifferentOperationModetransitionsduringtheACTIVE periodoftheDRevent.ThesetransitionsoftheOperationModevaluecouldbecaused eitherbytheEventInfoInstanceoftheDReventchangingvaluesorbythetransitionfrom oneOperationStateSpectoanotherwithinaResponseSchedule.

79

Figure 34. DR Event State Model (Simple Client View)

6.5.3.4 DR Event States

Figure 35. DR Event Model (Utility or ISO View)

Forreferencepurposes,theDREventModel(Figure16)isrepeatedhereasFigure35. FromtheDRASpointofviewaDRASClientmaybeinoneofthefollowingmodesof operation: optinDReventsarehandledandsenttotheDRASClientastheynormally wouldbe.

80

optoutTheDRASClienthasoptedoutfromreceivingDReventinformation andnonewillbesentwhentheyareinthisstate. testThisisusedfortestpurposesandisanalogoustotheDRASClientbeingoff line.NoDReventswillbesentautomaticallyfromtheDRAS,butaDRAS installermaysendtestmessagestotheDRASClient.

NotethatthestateslistedaboveareallfromthepointofviewoftheDRASandthe DRASClientrespondstothestatetheDRASisin.ItistheDRASthatchangesits behaviorandwherethelogicresidesinrelationtotheDRASClient. TheDRASisresponsiblefortrackingtheeventstatesforeachoftheDRASClientsin ordertosendtheDReventinformationtotheDRASClientattheappropriatetime. FromtheDRASClientspointofviewthereisasocalledDReventstatetheDRAS ClientsareinwhichisrepresentedbytheEventStateentity.NormallyaDRASClients eventstateisIDLEmeaningthattherearecurrentlynoactiveorpendingDRevents. ThischangeswhentheutilityorISOinitiatesaDReventintheDRAS.TheDRAStracks theDReventstateforeachDRASClientandcanprovidethecurrentstateinformationat anytimeforthatDRASClient.Itcanbeindifferentstates,dependinguponwhetherthe participantusesaSmartDRASClientoraSimpleDRASClient. Figure36isthestatetransitiondiagramforageneralDRevent.ForaSmartDRASClient thesearetheonlystatesthatarerelevant,butforaSimpleDRASClienttheremaybe substatesduringtheACTIVEperiodwhicheachrepresentthevariousleveltransitions oftheOperationModevariable.
IDLE

DR Event Initiated by Utility/ISO AND current time = Event Issue Time

DR Event End Time PENDING

Current time = DR Event Start Time

ACTIVE

Figure 36. Transition Diagram for a General DR Event

81

Figure37showstheexamplestatetransitiondiagramthatcorrespondstoFigure36. NotethatthelargestatescorresponddirectlytoFigure36andaretheonlystatesthat existforaSmartDRASClient,whereasthesubstateswithintheACTIVEstateare additionalstatesthatmayexistforaSimpleDRASClient. Thenotionofstatesareimportantbecausethetransitiontimesfromonestatetoanother definethetimeswhentheEventStateentityissentfromtheDRAStotheDRASClientin PUSHmode.InPULLmodetheDRASClientpollstheDRASanditsimplyresponds withtheappropriateEventStatethatcorrespondstothetimewhenthepollwasmade.


IDLE Set Event Pending = none Set Shed Mode = normal

DR Event Initiated by Utility/ISO AND current time = Event Issue Time ACTIVE State B1 Set Event Pending = now Set Shed Mode = high current time = DR Event End Time current time = B2 State B2 Set Shed Mode = moderate current time = B3 State B3 Set Shed Mode = special current time = B4 State B4 Set Shed Mode = high current time = B5 State B5 Set Shed Mode = normal current time = B6 State B6 Set Shed Mode = high Current time = DR Event Start Time PENDING State A1 Set Event Pending = far

current time = A2

State A2 Set Event Pending = near

Figure 37. DRAS Client DR Event State Simple DRAS Client State Transition Diagram

6.6

DR Automated Bidding Models

TheDRASmaysupportautomatedbiddingbyparticipantsintoDRprogramsby supportingtheconceptofastandingbidforthatparticipant.Astandingbidisabid thatwillbesubmittedbytheDRASforaparticipantifnootherbidissubmittedbythe participant.Theabilitytoautomaticallysubmitstandingbidsincreasesthelevelof participationinprogramsthatrequirebidding.InsomecasetheutilitysorISOsIT infrastructurewillalreadysupportthenotionofstandingbidsandinthosecasesitisnot necessaryfortheDRAStoprovidethisfunctionality.Infacttheremaybescenarios wherethereareprogramsthatrequirebidding,butallthebiddingishandledbya

82

differentsystemthantheDRAS,includingthehandlingofstandingbids.Inthiscase, fromtheDRASpointofview,theprogramwillnotrequirebiddingandalltheDR eventsaresimplyissuedbytheutilityorISOasinthecaseofprogramswithnobidding. TheutilityorISOwillsimplyhandleallthebiddingastheynormallywouldandusethe DRAStoissuetheDRevents. TheremainderofthissectionassumesthattheDRASishandlingtheautomated submissionofstandingbids.Fromtheparticipantspointofviewthereisasocalledbid statethattheyarein(seeFigure37).NormallythestateisIDLEmeaningthatthereare currentlynooutstandingrequestsforbids.ThischangeswhentheutilityorISOinitiates aDReventforaprogramthatmayrequirebidding.InthiscasetheDRASwillissuea requestforbidsbynotifyingtheparticipantoperatorsviaemailorsomeothermeans. TheDRASthentracksthebidstateforeachparticipantandcanprovidethecurrentstate informationatanytimeforthatparticipant.Thestatevariablesassociatedwitheachbid requestinclude: ProgramtheprogramassociatedwithrequestsforBids. NotifytimethetimethatparticipantsarenotifiedoftherequestforBids. Starttimethestarttimeofthebidding Endtimetheendtimeofthebidding BidinfothisgivesprogramandDReventrelatedinformationrelatedto bidding.

TheBidentityisusedbyboththeutilityorISOandtheparticipantstorepresentbidsas describedinSection8.11.BidstatetransitiondiagramsareshowninFigures38and39. ThereisaseparatestatediagramforeachprogramandDReventthataparticipantmay submitbidsfor.ThebiddingsequencesinFigure38areinitiatedbytheutilityorISO whentheyinitiateaDReventforaprogramthatrequiresbiddingbytheparticipant.In somecasesthebiddingisopenandclosedaccordingtosomefixedschedulewhichisnot associatedwithaspecificevent.Inthiscasetheopeningandclosingoftheentryofbids issimplyaccordingtosomeschedule.

83

IDLE

Bid request Initiated by Utility/ISO (DR Event initiated) AND current time = Notify Time Cancel Bids Accept/Reject Notification Received BIDDING OPEN

Current time = Bidding close time

AWAIT ACCEPTANCE

Figure 38. State Transition Diagram for a Participants Bid State

Figure39showsthesequencediagramforthebiddingprocess.Notethefollowing: Step3isoptionalandifitisnotperformedthenthestandingbidforthe participantissubmitted. Step4arepresentsthesubmissionofthebidtotheutilityorISOafterthebidis submittedbytheparticipant.IfStep3isnotperformedbytheparticipantthen thisstepisnotperformed.ThisstepmayhappenimmediatelyafterStep3orata scheduledtime(i.e.likeStep4binFigure38). Step4bisperformedataspecificallyscheduledtimeandrepresentsthe submissionofthestandingbidiftheparticipantdoesnotmanuallysubmitabid aspartofStep3.Sincethishappensatascheduledtime,participantshavetime tosubmitbidsorchangetheirstandingbid.

NotethattheDRASshouldbeconfigurablesuchthatStep4aisnotperformed immediatelyafteritissubmittedbytheparticipant,butratheratascheduledtimelike thestandingbidissubmitted.

Steps2and6aremachinetohumancommunicationsandcanutilizeeitheremail orsomethirdpartynotificationsystem.

84


Figure 39. Bidding Sequence Diagram

WhentheutilityorISOnotifiestheDRASofallbidacceptances(step5),theacceptances comeintheformofalistofUtilityDREvententitiesthatdescribeeachoftheDRevents thatneedtobeissuedtotheparticipantswhosebidswereaccepted.Thisallowsforthe utilityorISOtocustomizeaDReventforeachparticipantthatwillreflectthebidsthat theymade.NotethatitisarequirementthateachoftheUtilityDREvententitiesthatare issuedaspartofthelistofacceptedparticipantshavetheSAMEeventidentifierasthe originalDReventthatwasissuedandinitiatedtherequestforbids. UponreceivingthelistofUtilityDREventthatsignifytheparticipantswhosebidswere acceptedtheDRASwillnotifytheparticipantoperators(Step6)andsendtheDRevents totherelevantDRASClients(Step7).

85

86

Functional Specifications

ThissectiongivesabriefdescriptionofthevariousfunctionsrequiredbytheDRASin ordertosupporttheusecasesandtheinterfacesdescribedaboveforaDRevent.These functionsareorganizedaccordingtowhichofthethreeinterfacesdescribedabovethat theybelongto:

UtilityorISOOperatorInterface ParticipantOperatorInterface DRASClientInterface

ForamoredetaileddescriptionofeachfunctioninthevariousinterfacesseeSection9.

7.1

Utility or ISO Operator Functions

ThesearethefunctionsrequiredbytheutilityorISOiftheyareinterfacingtoa compliantDRAS.AsnotedearliertheDRASfunctionalitymaybeintegratedwiththe utilitysorISOsITinfrastructurewhichmeansthatthesefunctionsmaynotexist. NotethatexceptwherenotedinSection9,userswiththefollowingsecurityrolesmay accessmethodsinthisinterface: AllDRASOperators AllUtilityand/orISOOperators

7.1.1 Utility or ISO Handling DR Events


ThesearethefunctionsassociatedwithinitiatingandmanagingDReventsfor participantsinaDRprogramandincludethefollowingfunctions: InitiateDREvent EditorCancelExistingDREvent GetPendingEventInformation

BeforeautilityorISOcanusethesemethodstoinitiateaDReventthefollowing configurationstepsmusthavebeenperformedbytheutilityorISO: ParticipantaccountssetupincludingdefiningDRASClients DRprogramssetup

FurtherconfigurationmayberequiredbytheparticipantbeforetheDRevent informationcanbereceivedbyaparticipant. InitiateDREvent ThisfunctionisimplementedontheDRASandisusedbytheutilityorISOtoinitiatea DRevent.Theentireeventinformationispassedinconcerningtheeventalongwitha specificationoftheparticipantsandorDRASClientsthatshouldreceivetheevent.In

87

thecasewherebiddingisrequiredaspartoftheprogramthenthismethodcallwill initiatethebiddingprocess. ModifyDREvent ThisfunctionisusedtoeditapreviouslyissuedDRevent.ItmustreferencetheDR eventidentifierthatwasassignedbytheutilityorISOwhentheoriginaleventwas issued.ThefollowingtypesofmodificationscanbemadetoanalreadyinitiatedDR event: CancelaDREvent Changetheparticipantlist ModifyDREventparameters

AdjustDREventParticipants ThisfunctionwillmodifythelistofparticipantsthatwillreceiveanalreadyexistingDR event.Itissomewhatredundantwiththefunctionalityavailablewiththemoregeneral ModifyDREventmethod,butisdeemedtobedonefrequentlyenoughtomerititsown methodtomakeiteasier. GetDREventInformation ThisfunctionisusedtogetinformationrelatedtocurrentlypendingoractiveDRevents withintheDRAS. SetEventConstraint ThismethodisusedtosetProgramConstraintvariablesthatareappliedtoaspecificDR event. GetEventConstraint ThismethodisusedtofetchtheProgramConstraintvariablesthatareappliedtoaspecific DRevent.

7.1.2 Utility or ISO Support for Automated Bidding


ThefollowingfunctionsareusedbytheutilityorISOtomanagetheparticipants biddingthatisassociatedwithaparticularDRevent.Thesefunctionsincludethe following: QuerytheDRASaboutexistingbids DRASsendbidstotheutilitysorISOsITsystem Closethebidding NotifytheDRASofwhichbidswereacceptedorrejected

ThebiddingprocessproceedsasdescribedinSection6.6.

88

WhenparticipantbidsaresentfromtheDRAStotheutilityorISObothaPUSHand PULLmodelissupportedbytheDRAS.InthePUSHmodelthebidinformationissent bytheDRAStotheutilityorISObyinitiatingthecommunicationswiththeutilitysor ISOsITsystem.ItdoesthisbyinvokingafunctionontheutilitysorISOsITsystem. InthePULLmodeltheutilityorISOqueriestheDRASforthebiddinginformationby invokingafunctionoftheDRAStoretrievetheinformation. GetCurrentBids(PULLMODEL) ThisfunctionallowstheutilityorISOtorequestthecurrentparticipantbidsfromthe DRAS.TheutilityorISOcaneitherrequestbidsforaspecificeventorallthestanding bidsforaspecificprogram.

SetCurrentBids (PUSH MODEL)


ThisfunctionisimplementedontheutilitysorISOsITsystemandallowstheDRASto proactivelysendtheparticipantsbidinformationtotheutilityorISO.Itisbeyondthe scopeofthisdocumentastohowthismethodsendpointURLisspecifiedand configuredorhowtheDRAScredentialsforinvokingthismethodareconfiguredwith theDRAS. CloseBidding ThisfunctionisusedtoexplicitlyclosethebiddingforaparticularDRevent.When biddingisclosedparticipantscannolongersubmitbids.WhenaDReventthatrequires biddingisissuedithasatimeinwhichthebiddingwillclose.Thisfunctioncanclose thatbiddingbeforethattime. SetBidStatus ThisfunctionisusedtonotifytheDRASofwhichpreviouslysubmittedparticipantbids havebeenrejectedandaccepted.

7.1.3 Utility or ISO Configure DRAS


ThesefunctionsareusedbytheutilityorISOtoconfiguretheDRAStosupporttheDR programsandspecificallythedeliveryofDReventstotheparticipantsintheDR program.Thefunctionsconfigureandedittheaccountandprograminformation associatedwithaDRprogram.ThevariousdatamodelentitiesassociatedwithDR programsfromtheutilitysandISOspointofviewaredescribedinSections6.4.1and8. Dependinguponthebusinessprocess,theutilityorISOmayalsotakeresponsibilityfor performingtheconfigurationofthedataentitiesnormallyconfiguredbytheparticipant. InthatcasethefunctionsspecifiedinSection7.3wouldalsobeperformedbytheutility orISO.

89

7.1.3.1 Manage Programs ThefollowingfunctionsareassociatedwithmanagingDRprogramswithintheDRAS. FromthepointofviewoftheDRASaDRprogramisrepresentedbytheUtilityProgram entityandthusthesefunctionsrepresentthemanipulationofthatentitywithinthe DRAS. CreateProgram ThisfunctionisusedtocreateanewDRprogram. ModifyProgram Thisfunctionisusedtomodifyanexistingprogramthatwascreatedwiththe CreateProgramfunction. DeleteProgram Thisfunctionisusedtodeleteanexistingprogramthatwascreatedwiththe CreateProgramfunction. GetPrograms Thisfunctionisusedtogetalltheinformationrelatedtoprogramsincludingthe programconstraintsandeventInfoTypesassociatedwiththeprogram. AdjustProgramParticipants Thisfunctionisusedtoaddorremoveaparticipantfromaprogram. 7.1.3.2 Manage Participant Accounts Thefollowingfunctionsareassociatedwithmanagingparticipantaccounts,and specificallythemanagementofthoseaccountsastheyrelatetoprograms.Each participantaccountisrepresentedbyaParticipantAccountentityasdescribedinSections 6.3.4and8.5.AParticipantAccountobjectisassociatedwithanUtilityProgramobject whichallowstheparticipantrepresentedbythataccounttoreceiveDReventsfromthe DRAS.InadditionaparticipantmayhaveasetofProgramConstraintsthatarespecificto howthatparticipantoperateswithinaspecificprogram.Notethatthesearedifferent fromtheProgramConstraintsthatwereassociatedwiththeprogramasawholeandare specifictotheparticipant.ThisisdescribedinmoredetailinSection6.5.2. CreateParticipantAccounts Thisfunctionisusedtocreateoneormoreparticipantaccounts. ModifyParticipantAccounts Thisfunctionisusedmodifyexistingparticipantaccounts.

90

DeleteParticipantAccounts Thisfunctionisusedtodeleteparticipantaccountsthatwerecreatedwiththe CreateParticipantAccountsfunction. GetParticipantAccounts Thisfunctionisusedtofetchinformationrelatedtoparticipantaccounts. GetGroups Thisfunctionreturnsallthegroupsforalltheparticipants.

7.1.4 Utility or ISO Monitoring of DRAS Related Activities


TheDRASlogsvarioustransactionandalarmsasdescribedinSection6.3.2.The functionsdescribedinthissectionprovideameanstoquerythoselogs. GetDRASClientCommsStatus ThisfunctionisforretrievingaDRASClientscurrentcommunicationstate. GetDRASTransactions ThisfunctionisusedtoretrieveanyofthetransactionlogsassociatedwiththeDRAS. GetDRASClientAlarms ThisfunctionisusedtoretrieveDRASClientAlarmsthathavebeenloggedwithinthe DRAS. GetParticipantFeedback ThisfunctionisusedtofetchalistofFeedbackobjectsbaseduponasetofsearchcriteria.

7.2

DRAS Client Functions

ThissectionisafunctionaldescriptionofthemethodsrequiredfortheDRASandDRAS ClienttoexchangeinformationconcerningDRevents.Asdescribedabovethereisboth aPUSHandaPULLmodelofinteractionbetweentheDRASandtheDRASClient.In bothcasesanEventStateentityispassedfromtheDRAStotheDRASClientanda ConfirmationmessageissentfromtheDRASClienttotheDRAStoacknowledgereceipt ofthemessage.Section8.12givesadetaileddescriptionoftheEventStateand EventStateConfirmationentities. Thissectiononlyspecifiesthefunctionalrequirementsofthemethodsthataretobe implementedontheDRASandtheDRASClient.Unlikeotherfunctionsdescribedin thissectionthatareintendedtobeimplementedusingSOAPthereareinfactanumber ofdifferentwaysinwhichthefunctionsinthissectioncanbeimplementedsuchas BACnetWebservicesandsimpleREST(RepresentationalStateTransfer).SeeSection9.3 foramoredetaileddescriptionoftheactualmethodsthatareused.

91

SendDREventInformation(PUSH)toDRASClient ThisfunctionisimplementedontheDRASClient.AnEventStateentityissentbythe DRAStoaDRASClientwhenevertheparticipantsDReventstatechangesorwhenthe DReventinformationhasbeenchangedbytheutilityorISO.Thisincludescancelingthe DRevent.WhentheDRASClientreceivestheEventStateentityitmustsendtheDRAS anEventStateConfirmationentityasdescribedinSection6.5.3.Sendingtheconfirmation messageincludestheDRASClientinvokingthemethodontheDRASthatisusedfor sendingconfirmationmessagesasdescribedinSection6.5.3.SeeSection8.12fora descriptionoftheEventStateobject. GetDREventInformation(PULLforDRASClient) ThisfunctionisusedinthePULLmodelofinteractionbetweentheDRASandDRAS ClienttofetchinformationconcerninganypendingDRevents.Itlogicallyoperatesthe sameasitsPUSHcousinandallowstheexchangeofthesameinformation.Whenthe DRASClientreceivestheEventStateentityitmustsendtheDRASan EventStateConfirmationentityasdescribedinSection8.12.Aspartofthesecuritypolicy theDRASmustensurethatthesecuritycredentialsthatwereusedbytheDRASClient toinvokethisfunctionmatchthevariousparameterspassedintothisfunction. Parameters ParticipantID ProgramID DRASClientID(forexample,usernameandpassword) AnEventStateobjectasdescribedinSection8.12. AllDRASOperators DRASClientassociatedwiththeParticipantID

ReturnValues AuthorizedUsers

SendEventStateConfirmationtoDRAS ThisfunctionisimplementedontheDRASandisusedbytheDRASClienttosend confirmationthatithasreceivedaspecificinstanceofanEventStateobject.Ifthis functionisnotinvokedbytheDRASClientwithinthetimeoutperiodaftertheDRAS sendsanEventStateobjecttheDRASmustassumethattheEventStateobjectwasnot receivedproperlybytheDRASClient.AspartofthesecuritypolicytheDRASmust ensurethatthesecuritycredentialsthatwereusedbytheDRASClienttoinvokethis functionmatchthevariousparametersassociatedwiththeEventStateConfirmationobject. NotethattheEventStateConfirmationobjectalsocontainsaflagwhichspecifieswhether theDRASClientisoptinginoroutoftheDRevent.AnEventStateConfirmationobjectcan thereforebeusedtoinitiatetheoptoutstateattheDRASClientandtonotifytheDRAS ofthisstate.SincetheoptoutstatecanbesetwithintheDRASClientatanytime,the

92

EventStateConfirmationobjectcanbesentatanytimeusingapreviouslyconfirmed EventState. Parameters EventStateConfirmationobjectasdescribedinSection8.12. SUCCESSorFAILURE AllDRASOperators DRASClientassociatedwiththeEventStateConfirmationobject. ReturnValues AuthorizedUsers

7.3

Participant Operator Functions

Thefunctionsdescribedinthissectionarepartoftheparticipantoperatorinterface.In generaluserswiththefollowingsecurityrolesmayaccessthefunctionswithinthis interface: AllDRASOperators AllUtilityorISOOperators AllParticipantManagers

Forsecurityreasonsiftheroleoftheuseraccessingthismethodisaparticipantmanager thentheusernameorpasswordoftheparticipantmanagermustmatchtheusername orpasswordontheparticipantaccountsthatareassociatedwiththereturnvalues. Alsoafewofthefunctionsdescribedinthissectionmaybeaccessedbyuserwiththe DRASClientinstallersecurityrole.

7.3.1 Opting Out of DR Events


Anoptoutstateisasetofconditionsforwhichtheparticipantwillnotbeparticipating inDRevents.AnoptoutstateisrepresentedbytheOptOutStateentityasdescribedin Section8.6,optoutstatescanbebaseduponspecificDRevents,programs,orDRAS Clients.Inadditiontherecanbeascheduleassociatedwithanoptoutstate.Theremay bemultipleoptoutstatesassociatedwithaparticipantandtheDRASmustcheckeach oftheconfiguredoptoutstatestodetermineisaparticipantwillreceiveaDRevent.Itis implementationspecificfortheDRAStodefinewhathappensifanoptoutschedule startsorendsinthemiddleofaDReventperiod. Thefunctionsinthissectionareformanagingoptoutstatesforparticipants.Participant managerscanonlymanageoptoutstatesforaccountsthatareassociatedwiththeir ParticipantAccount. Thefunctionsdescribedinthissectionmayalsobeusedbytheautomationsysteminthe facilityintheusecasewheretheoptoutstateofthefacilityissetattheautomation systemandnotthroughsomespecificuserinterfaceontheDRAS.Notethattheoptout
93

stateofafacilitycanalsobesetthroughtheDRASClientinteractionbyusingthe EventStateConfirmationwhichcontainsaflagthatspecifieswhethertheDRASClientis optingoutofaDRevent. CreateOptOutState Thisfunctionisusedtocreateanoptoutstateforaparticipant. DeleteOptOutState Thisfunctionisusedtodeleteapreviouslycreatedoptoutstateforaparticipant. GetOptOutState Thisfunctionisusedtofetchoptoutstatesforaparticipant.

7.3.2 Submitting Feedback (Facility Status) to DRAS


Thesefunctionsareusedbytheparticipanttoprovidefeedbackconcerningthestatusof thefacility.Themannerinwhichthefeedbackisprovidedmightincludeanumberof differentactorsincludingbothhumanandmachinewhichmayincludetheDRAS Client. SetDREventFeedback ThisfunctionisusedtosendinformationtotheDRASconcerningthestateofthefacility andhowtheparticipantorDRASClientreactedtotheDReventbeingissued.Notethat ingeneralfeedbackmaybesentatanytimeandmayormaynotbeassociatedwitha specificDRevent. GetDREventFeedback Thisfunctionisusedtofetchalistoffeedbackobjectsthatwerecreatedwiththe SetDREventFeedbackfunction.

7.3.3

AutomatedBidding

Thefunctionsdescribedinthissectionareusedbytheparticipantstomanagetheirbids thatareassociatedwiththoseDReventsthatrequirebidding.Bidsarerepresentedby theBidentity.ThebiddingprocessisdescribedinSection6.6. SubmitStandingBid Thisfunctionisusedtosetaparticipantsstandingbidforaprogram. GetStandingBid Thisfunctionisusedtofetchaparticipantsstandingbidforaprogram. DeleteStandingBid Thisfunctionisusedtodeleteaparticipantsstandingbidforaprogram.

94

SubmitBid Thisfunctionisusedtosetaparticipantsrealtimebidforaprogram. GetBid Thisfunctionisusedtofetchaparticipantsrealtimebidforaprogram.

7.3.4 Configuration of Participant Related Information in DRAS


ThesefunctionsareusedbytheparticipantstoconfiguretheDRASforthereceptionof DReventsthatareassociatedwithaspecificprogram.Thefollowingentitiesare managedbytheparticipantandareinvolvedinhowtheyoperateandreceiveDR events: ParticipantAccount DRASClient ResponseSchedule ProgramConstraints

NotethatitisnotarequirementthattheutilityorISOallowaccessbyanyparticipantto theconfigurationfunctionsdetailedinthissection.Inthatcaseallconfiguration functionswouldbeperformedbyautilityorDRASoperator.


7.3.4.1 Manage Participant Accounts

TheparticipantaccountsarecreatedbytheDRASortheutilityorISOoperators.Itisnot requiredthattheDRASallowaccesstoParticipantAccountinformationbythe participant.TheDRASmaybeconfiguredtooperateinanumberofdifferentways: ParticipanthasnoaccesstoParticipantAccountinformationandtheutilityorISO isresponsibleforallconfigurationofthisinformationasdescribedabove. Participantmayview,butcannotmodifyanyofthefieldsinthe ParticipantAccountentity. ParticipantcanbothviewandmodifytheinformationintheParticipantAccount entity.

ItisbeyondthescopeofthisdocumenttospecifyhowtheDRASisconfiguredto operateinoneofthemodesdescribedabove,butitistheassumptionofthissectionthat itisconfiguredtooperateinmode2or3asdescribedabove. GetParticipantAccounts Thisfunctionisusedtogettheparticipantsaccountinformation(ParticipantAccount). ModifyParticipantAccount Thisfunctionisusedtomodifyexistingparticipantaccounts.Whilecertainfieldsofthe ParticipantAccountmaybeviewedbyaparticipantmanager,theymaynotbemodified. Thesefieldsincludethefollowing:


95

Participantuid Participantname Username Programnames

7.3.4.2 Managing DRAS Clients EachparticipantmayhavemultipleDRASClientsassociatedwiththeiraccount.These functionsareusedtomanagetheDRASClients. CreateDRASClient ThisfunctionisusedtocreateaDRASClient.Notethatprogramconstraintsand responseschedulesmaybecreatedthroughaseparatesetoffunctionsandneednotbe createdusingthisfunction. ModifyDRASClient ThisfunctionisusedtomodifyanexistingDRASClient. DeleteDRASClient ThisfunctionisusedtodeleteanexistingDRASClient. GetDRASClientInfo ThisfunctionisusedtofetchDRASClientinformationassociatedwithparticipant. 7.3.4.3 Managing Program Constraints Thesefunctionsareusedtomanageprogramconstraints.Aparticipantsprogram constraintsarealwaysassociatedwithaparticularprogramandinadditiontheyarealso associatedwitheithertheparticipantaccountasawholeoraspecificDRASClient. Thereforethesefunctionsareusedtomanageboththeprogramconstraintsthatarefora participantasawholeaswellastheconstraintsthatareassociatedwithaspecificDRAS Client. GetParticipantProgramConstraints ThisfunctionisusedtofetchtheProgramConstraintsobjectassociatedwiththe participantasawhole. SetParticipantProgramConstraints ThisfunctionisusedtoassigntheProgramConstraintsobjectassociatedwiththe participantasawhole. DeleteParticipantProgramConstraints ThisfunctionisusedtodeletetheProgramConstraintsobjectassociatedwiththe participantasawhole.
96

GetDRASClientProgramConstraints ThisfunctionisusedtofetchtheProgramConstraintsobjectassociatedwithaspecific DRASClient. SetDRASClientProgramConstraints ThisfunctionisusedtoassigntheProgramConstraintobjectassociatedwithaspecific DRASClient. DeleteDRASClientProgramConstraints ThisfunctionisusedtodeletetheProgramConstraintobjectassociatedwithaspecific DRASClient. 7.3.4.4 Managing Simple DRAS Client Response Schedules AsdescribedinSection6.5.3.3.2,responseschedulesareprimarilyintendedforSimple DRASClientsandareusedtospecifyhowtotranslatetheEventInfoinformation associatedwithaDReventintothesimplerOperationModevariabletransitionsduring theACTIVEperiodoftheDRevent.TheResponseScheduleentityisusedtodefinethese translationrulesandisassociatedwithspecificprogramsandDRASClients. InordertocreateaResponseScheduleforaDRASClientthefollowinginformationis requiredfromtheDRASandmaybeusedbyaparticipantUItocreatea ResponseSchedule: ListofallEventInfoTypesthatmaybeassociatedwiththeprograminquestion. AconsolidatedsetofProgramConstraintsthatapplytoaparticularDRASClient. IfthereisanexplicitsetofprogramconstraintsdefinedforaDRASClientthen thoseareused,elseifthereareprogramconstraintsdefinedfortheparticipantas awholethenthoseareused,elsetheprogramconstraintsthataredefinedforthe programasawholeisused.

Becauseofthewaythatprogramconstraintsaredefineditisalwayspossibletoderivea setofProgramConstraintsthatwillbeappliedtoaparticularDRASClientforaspecific program. Withthisinformationitshouldbepossibletobuildatooloreditorthatcanbeusedto createresponseschedules. Thefunctionsdescribedinthissectionareusedtomanagetheresponseschedules. GetProgramInformation Thisfunctionisusedtoretrievetheinformationnecessarytohelpanoperatoreditand specifyaresponsescheduleanditsoperatingstates.

97

CreateResponseSchedule ThisfunctionisusedtocreateaResponseScheduleforaspecificDRASClientand program. DeleteResponseSchedule ThisfunctionisusedtodeleteaResponseScheduleforaspecificDRASClientand program. GetResponseSchedule ThisfunctionisusedtofetchaResponseScheduleforaspecificDRASClientandprogram.

7.3.5 Monitoring of DRAS Related Activities


TheDRASlogsvarioustransactionandalarmsasdescribedinSection6.3.2.The functionsdescribedinthissectionprovideameanstoquerythoselogs. GetDRASClientCommsStatus ThisfunctionisforretrievingaDRASClientscurrentcommunicationstate. GetDRASTransactions ThisfunctionisusedtoretrieveanyofthetransactionlogsassociatedwiththeDRAS. GetDRASClientAlarms ThisfunctionisusedtoretrieveDRASClientAlarmsthathavebeenloggedwithinthe DRAS.

7.3.6 Installation and Testing of DRAS Clients


ThesefunctionsareusedtotestthecommunicationsbetweenaDRASClientandthe DRAS.ItdoesthisbyallowingtheDRASClienttobeputintotestmode.WhenaDRAS ClientisinthetestmodeofoperationthenitisconsideredtobeofflinebytheDRAS anddoesnotreceivenormalEventStatemessageswhenDReventsoccur.IftheDRAS ClientisaSimpleDRASClientthenthesefunctionscanbeusedtomanuallysetthe OperationModevaluesoftheDRASClient.InthecaseofaSmartDRASClientitcanbe usedtotestthereceptionofEventStatemessages. SetTestMode ThisfunctionputsaDRASClientintooroutoftestmode.IfaDRASClientisintest modethenitisessentiallyofflineandwillnotreceiveanyautomatedDRsignalsfrom theDRAS.

98

SetTestModeState ThisfunctionsendsatestmessagetoaDRASClientandifitisaSimpleDRASClient thenitcanbeusedtosettheoperationmodeandeventstatevalues.TheDRASClient mustbeintestmodeforthismethodtowork. GetTestModeState ThisfunctionisusedtogetthecurrentoperationstateoftheDRASClientifitisintest mode.

99

100

Detailed Data Models and Schemas

Thedetailedschemasdescribedinthissectionareallspecifiedanddocumentedusing XMLSchemaDefinition(XSD).Allthedocumentationfortheschemasisembeddedin theirrespectiveXSDschemafiles.Whatisdisplayedinthissectionissimplyahuman readableformofthatdocumentationthatwasextractedfromtheXSDfileusinga particulartool.IfsodesiredthereadermaytakethemachinereadablesourceXSDfile andbrowseitwithatooloftheirchoosing. TherecentXSDversionsareavailableontheLBNLWebsitehttp://openadr.lbl.gov/src/. Forexample,http://openadr.lbl.gov/src/EventState.xsdreferstotheEventState.xsd http://openadrsourcefile.

8.1

UtilityProgram

SeeUtilityProgram.xsd

8.2

UtilityDREvent

SeeUtilityDREvent.xsd

8.3

ResponseSchedule

SeeResponseSchedule.xsd

8.4

ProgramConstraint

SeeProgramConstraint.xsd

8.5

ParticipantAccount

SeeParticipantAccount.xsd

8.6

OptOutState

SeeOptOutState.xsd

8.7

Logs

SeeLogs.xsd

8.8

Feedback

SeeFeedBack.xsd

101

8.9

EventInfo

SeeEventInfo.xsd

8.10 DRASClient
SeeDRASClient.xsd

8.11 Bid
SeeBid.xsd

8.12 EventState
SeeEventState.xsd

102

Detailed API Specifications

ThedetailedApplicationProgrammingInterfaces(APIs)describedinthissectionarefor themostpartspecifiedusingaWebServiceDescriptionLanguage(WSDL),whichisthe standardmethodforspecifyingaSOAPWebserviceinterface.Allthedocumentation forthemethodsandtheirparametersspecifiedintheAPIsareembeddedintheir respectiveWSDLfiles.Whatisdisplayedinthissectionissimplyahumanreadable formofthatdocumentationthatwasextractedfromtheWSDLfileusingaparticular tool.IfsodesiredthereadermaytakethesourceWSDLfileandbrowseitwithatoolof theirchoosing. RecentAPIversionsarepostedontheLBNLWebsite(http://openadr.lbl.gov/src/)and includeBacnetDRAS Definition and DRAS Instance XML filesForexample, http://openadr.lbl.gov/src/bacnet.wsdlreferstothebacnet.wsdlsourcefile.

9.1

Utility Program Operator APIs

ThissectiondetailsthemethodsintheAPIthatareprovidedfortheutilityprogram operatormethodsasdescribedinthissection.Thereisaonetoonecorrespondence betweenthefunctionsdescribedinthatsectionandthemethoddocumentation presentedhere. SeeUtilityOperator.wsdl SeeUtilityInterface.wsdl

9.2

Participant Operator APIs

SeeParticipantOperator.wsdl

9.3

DRAS Client APIs

ThissectiondetailsthemethodsoftheAPIthatareusedforthecommunications betweentheDRASandaDRASClient.Aspreviouslydiscussed,theDRASClientAPIis responsibleforcommunicatingDREventStateinformationtotheDRASClientinthe participantsfacilitywhetheritisanenduseroranaggregator.ThisAPIalsoincludes theEventStateConfirmationmessagethatisalsosentfromtheDRASClienttotheDRAS uponreceiptoftheEventStateinformation.SeeSections6.5.3and7.2foramoredetailed descriptionofthisinteraction. ManypotentialDRASClientsareverylimitedincapabilitiesandnotsophisticated enoughtosupportaSOAPinterface.Thereforetherearetwothreedistincttypesof interfacesdescribedhereoneusingasimpleRESTtypeofWebserviceinterface,a simpleSOAPtypeofWebservice,andoneusingamoresophisticatedSOAPinterface thatutilizesaBACnetWebServices(BWS)interface.

103

TheDRASmustsupporttheBACnetsimpleSOAPWebserviceinterfaceandmay supportmaysupportthesimpleRESTWebserviceinterfaceandmaysupportthe BACnetSOAPWebserviceinterface.Table4belowindicates(withX)therequiredand optionalservicestobesupportedbythisOpenADRspecificationandtheirsupporting communicationmodels.


Table 4 Required Services and Supported Communication Models DRAS Client API Simple REST Services Simple SOAP Services BACnet SOAP Service (CSML)
CSML = Control Systems Modeling Language

Required X

PUSH X X

PULL X X X

9.3.1 Use of Simple REST Services to Exchange DR EventState Information


ItisrecommendedthatDRASClientsuseaSOAPinterfacetotheDRAS,butforDRAS ClientswithlimitedcommunicationscapabilitiesthatdonotsupportafullSOAP protocolstack,thesimpleRESTinterfacepresentedinthissectionisameanstointerface totheDRASandexchangeDReventinformation.TheRESTinterfacemustsupportall therequirementsoftheDRASSecurityPolicyasdescribedinSection10. TheRESTinterfacedoesnotsupportthePUSHmodelofinteractionwiththeDRAS.A DRASClientinteractingwiththeDRASusesHyperTransferTextProtocol(HTTP)Get tofetchEventStateentitiesfromtheDRASandsubsequentlyusesHTTPPosttosendthe EventStateConfirmationmessagesbacktotheDRAS.Thisisdepictedinthesequence diagraminFigure40.

Figure 40. REST DRAS Client PULL Interaction Sequence Diagram

WhentheHTTPGETisinvokedtheDRASreturnsanEventStateentity.TheEventState entityisdocumentedinSection8.12.

104

WhentheHTTPPOSTisinvokedtosendtheconfirmationmessagean EventStateConfirmationentityisposted.TheEventStateConfirmationentityisdocumented inSection8.12. Notethatthepathnamesusedtoaccesstheseservicesareimplementationspecificand notcoveredinthisdocument.

9.3.2 Use of Simple SOAP Services to Exchange DR EventState Information


ForDRASClientswithcapabilitiestosupportafullSOAPprotocolstack,thesimple SOAPinterfacepresentedinthissectionisameanstointerfacetotheDRASand exchangeDReventinformation.ThesimpleSOAPinterfacemustsupportallthe requirementsoftheDRASSecurityPolicyasdescribedinSection10. TheDRASandsupportingDRASClientshouldexchangeEventStateinformationusing twodifferentmodesofinteractionPUSHandPULLasdescribedearlierinSection 6.5.3.1,ModesofInteraction(PUSHversusPULL).Thefollowingmessageexchanges mustbesupportedbysimpleSOAPservices: UsingPULLarchitecture,theDRASClientusessimpleSOAPservicetofetchthe entireXMLmessageofDREventStateinformation. Alternatively,usingPUSHarchitecture,theDRASusessimpleSOAPserviceto sendtheentireXMLmessageofDREventStateinformationtoDRASClient. TheDRASClientatthefacilityparsesthevaluesofEventStateinformation. ForbothPUSHandPULLarchitecture,theDRASClientatthefacility acknowledgeswithEventStateConfirmationmessagetoDRASusingsimpleSOAP service.

AsshowninthesequencediagramFigure41,inthePUSHmodeofinteractionthe EventStateinformationispushedfromtheDRAStotheDRASClientusingsimple SOAPservice.Thismeans,thecommunicationoftheEventStateinformationisinitiated bytheDRAS.IntermsofWebservicesthismeansthatthatDRASClientistheWeb serverandtheDRASistheWebclient.TheDRASClientmustacknowledgethereceipt ofmessageusingEventStateConfirmationmessage.

105

Figure 41. Simple SOAP PUSH Model Sequence Diagram

AsshowninthesequencediagramFigure42,inthePULLmodeofinteractionthe EventStateinformationispulledfromtheDRASbytheDRASClientusingsimple SOAPservice.Thismeans,thecommunicationoftheEventStateinformationisinitiated bytheDRASClient.InotherwordstheDRASClientpollstheDRASfortheEventState information.IntermsofWebservicesthismeansthattheDRASistheWebserverand theDRASClientistheWebclient.Theclientmustacknowledgethereceiptofmessage usingEventStateConfirmationmessage.

Figure 42. Simple SOAP PULL Model Sequence Diagram

9.3.2.1 Simple SOAP Web Services API ThissimpleSOAPservicesAPIandtheminimummethodsthatmustbesupportedare asdescribedinSection9.3.1thataresimilarforsimpleRESTservices.TheEventState entityisdocumentedinSection8.12andtheEventStateConfirmationentityisdocumented inSection8.12.

106

9.3.3 Use of BACnet Web Services to Exchange DR EventState Information


ForthoserequiringinteroperabilitywithBACnet,thisOpenADRspecificationmay optionallyusetheBACnetWebServices(BWS)specification(ANSI/ASHRAE AddendumCtoStandard1352004)tocommunicatewithBACnetbasedsystems. ThegenericBWSdatamodelallowsinteroperabilitywithDRASissuedDRevent informationandtoscheduleresponsestrategiesusingSmartandSimpleDRASclients. TheDRASBACnetServerandsupportingDRASClientshouldexchangeEventState informationusingtwodifferentmodesofinteractionPUSHandPULLasdescribed earlierinSection6.5.3.1,ModesofInteraction(PUSHversusPULL). ToenableinteroperabilitybetweentheDRASandBACnetbasedcontrolsimplementing BWS,thefollowingmessageexchangesmustbesupported: UsingPULLarchitecture,theClientusesBWSsimplegetValueservicetoreadthe entireXMLmessageofDREventStateinformationasStringvaluefromthe DRASBACnetServer. Alternatively,usingPUSHarchitecture,theDRASBACnetServerusesBWS simplesetValueservicetosendtheentireXMLmessageofDReventstate informationasStringvaluetotheDRASClient. TheDRASClientatthefacilityparsestheStringvalueofEventStateinformation. ForbothPUSHandPULLarchitecture,theDRASClientatthefacility acknowledgeswiththeStringvalueofEventStateConfirmationinformationtothe DRASBACnetServerusingBWSsimplesetValueservice.

AsshowninthesequencediagramFigure43,inthePUSHmodeofinteractionthe EventStateinformationispushedfromtheDRASBACnetServertotheDRASClientto apredefinednodepathofatreeusingsetValueservice.Thismeans,thecommunication oftheEventStateinformationisinitiatedbytheDRASBACnetServer.IntermsofWeb servicesthismeansthatthatDRASClientistheWebserverandtheDRASBACnet ServeristheWebclient.TherootofthetreeisDRASandtheeventstateiswrittento nodeDRAS/EventState.ForrealtimepricingthisnodeisDRAS/RTP.TheDRAS ClientmustacknowledgethereceiptofmessageusingEventStateConfirmationmessage tothesamenodewithinspecifiedtimeoutperiodusingsetValueservice.

107

Figure 43. BWS PUSH Model Sequence Diagram

AsshowninthesequencediagramFigure44,inthePULLmodeofinteractionthe EventStateinformationispulledfromtheDRASBACnetServerbytheDRASClient fromapredefinednodepathofatreeusinggetValueservice.Thismeans,the communicationoftheEventStateinformationisinitiatedbytheDRASClient.Inother wordstheDRASClientpollstheDRASBACnetServerfortheEventStateinformation.In termsofWebservicesthismeansthattheDRASBACnetServeristheWebserverand theDRASClientistheWebclient.TherootofthetreeisDRASandtheeventstateis readfromnodeDRAS/EventState.ForrealtimepricingthisnodeisDRAS/RTP.The clientmustacknowledgethereceiptofmessagetothesamenodeusingsetValueservice.

Figure 44. BWS PULL Model Sequence Diagram

9.3.3.1 Services Supported by DRAS-BACnet Server WhileBWShasmanyservicesthatsupportvariousaspectsofcontrolsystems specifications,mostofthemarenotrelevanttotheDRASBACnetserverandgetValue andsetValueservicesarebeingused.TheothertwoservicesgetDefaultLocaleand getSupportedLocalsarerequiredasperBWSspecificationsandmustalsobesupportedby

108

theDRAStoexchangeDReventdatawiththeDRASBACnetserver.Theseservicesare describedinbriefbelow.ReferBACnetWebServices(BWS)specification (ANSI/ASHRAEAddendumCtoStandard1352004)forfurtherdetailssuchasstructure andprocedures. getValueService ThisBWSserviceisusedtoretrieveasinglevalueforasingleattributeofasinglenode. Thisservicealwaysreturnsitsresultsasasinglestring. Thisservicecanbeusedtoretrieveprimitiveattributes,suchasValue,andarray attributes,suchasPossibleValues.Theformatofthisstringresultisdictatedbythe attributesdatatypeandtheserviceoptions. Ifthisserviceisusedforanarrayattribute,thenthearrayelementsshallbe concatenatedintoasinglesemicolondelimitedstringthatcanbeeasilysplitattheclient sincetheelementstringsarenotallowedtocontainsemicoloncharacters.Iftheclient wouldratherretrieveanarrayofindividualstrings,itcanusethegetArrayor getArrayRangeserviceinstead. Atypicalprogramminglanguagesignatureforthisserviceis: CStringgetValue(CStringoptions,CStringpath)

setValueService ThisBWSserviceisusedtosetanewvalueforasingleattributeofasinglenode.The formatofthenewvalueisdictatedbytheattributesdatatypeandtheserviceoptions. Thisservicealwaysreturnsitsresultsasasinglestring. Iftheserviceoptionreadbackistrue,then,aftersettingthevalue,thisserviceshallread thevaluebackandtheresultshallbeasiftheclienthadcalledgetValueusingthesame pathandserviceoptions.Thisallowstheclienttoseetheeffectsofanyvalue modificationbytheserveraswellascheckforerrors. OnlytheValueattributeiswritable. ThisserviceisrequiredtobeprovidedifthesetValuesserviceisprovided. Atypicalprogramminglanguagesignatureforthisserviceis: CStringsetValue(CStringoptions,CStringpath,CStringValue) getDefaultLocaleService ThisBWSrequiredserviceretrievesthelocalethattheserverhasconfiguredforits defaultlocale.Theemptystring()shallbereturnedifthereisnodefaultlocale,in whichcasethecanonicalformshallbeusedforallvalues.

109

Atypicalprogramminglanguagesignatureforthisserviceis: CStringgetDefaultLocale(CStringoptions) getSupportedLocalsService ThisBWSrequiredservicecanbeusedtoretrievethelistoflocalessupportedbythe server.Iftheserverdoesnotsupportmultiplelocales,thenthisserviceshallreturnonly thedefaultlocale.Iftheserverdoesnotsupportlocalization,andonlyusesthecanonical form,thenanarraywithnoentriesshallbereturnedunlessthenoEmptyArraysservice optionistrue,inwhichcasetheresultarrayshallcontainasingleentryforthe WS_ERR_EMPTY_ARRAYerrorcondition. Atypicalprogramminglanguagesignatureforthisserviceis: CString[]getSupportedLocales(CStringoptions) 9.3.3.2 EventState Schemas used for the BACnet Interface TheDRASBACnetserverEventStateschemainformationisrepresentedusingControl SystemModelingLanguage(CSML),whichisbothadatadefinitionanddatainstance language.WhiletheCSMLfilewithDRASinformationanddatastructureismachine andhumanreadableandhasanXMLschemaforvalidatingtheCSMLfile;however,the CSMLinitselfisaschemaforcontrolsystemsdatamodel.Thedefinitionfiledefinesthe simpledatastructureofEventStateschemaandaninstancefilehasinstancesofthesedata structures.Togetherthesefilesrepresentimplementationofdevices,objects,and propertieswithinagivendeviceorcollectionofdevices 1. XMLschemaisadequatefordefiningthestructureoftheCSMLfile,butisnotrich enoughtocapturealltheinformationthatisneededtofullydefineaBACnetcontrol systemsdatastructure,presentation,andsemantics.ThesedefinitionandinstanceCSML filesreferencetheschemadefinedinthesupportedBWSXSDfile.AnexampleofCSML implementationandsupportingXSDaredetailedbelow: SeeDR034E22w2ExampleDRASDefinition.xml SeeDR034F22w2ExampleDRASInstance.xml 9.3.3.3 BACnet Web Services API ThissectiondetailstheBWSservicesintheAPIthatshouldbeprovidedfortheBACnet methods.ThisAPIincludesallBACnetservicesandtheminimummethodsthatmustbe supportedaredescribedinSection9.4.2. Seebacnet.wsdl.

http://xml.coverpages.org/facilitiesXML.html#csml

110

10

Security Policy

ThissectionoutlinesthesecuritypolicyofthecommunicationswiththeDRASand identifiestheminimumsecurityelementsandinterfacesthatarerequiredbythis OpenADRspecification.

10.1 Scope
IngeneraltherearemanymodesofattacksuponanysortofITinfrastructureranging fromintrudersgainingphysicalaccesstotheserverstoremotelyaccessingtheservers throughopencommunicationchannels.ThisOpenADRspecificationonlycoversthe communicationprotocolsusedtointeractwiththeDRASandtheDRASClients.Itis thereforeonlyintendedtocovermodesofattackthatwouldbeperpetratedbyusingone ofthecommunicationschannelsthatareusedtoimplementtheinterfacetotheDRASas describedintheanalysissectionofAppendixC.Anyothercertainlynecessarysecurity measures(firewalls,intrusiondetection,etc.)arenotcovered. TheDRAShas3distinctWebserviceinterfaces,namedaftertheirprincipalusers,who aresubjecttothissecuritypolicy: ParticipantInterface DRASClientInterface UtilityInterface

TheDRASClienthasoneWebserviceinterface(DRASInterface)thatisaddressedby theDRAS. Asdescribedabove,boththeDRASandtheDRASClientscanactasaserveroraclient inaclient/serverrelation.

10.2 Access Control and Security Roles


ThereareanumberoftypesofusersthatrequireaccesstotheDRAS.Eachusermay havedifferentrequirementsonthetypeoffunctionstheycanperformanddatathey mayaccess.TosupportlimitingtheaccessoftheDRASusersbasedontheir requirements,theDRASmustsupportthesecurityrolesoutlinedinSection6.3.1. Thesesecurityrolesaredesignedtolimitaccesstothevariousmethodsineachofthe Webserviceinterfaces.Table5describeshoweachofthesecurityrolesislimitedwithin eachoftheInterfaces.

111

Table 5 Security Roles of Interfaces Utility Interface n/a* Full access none Participant Interface n/a* Full access Access to all methods, but limited scope in what can be done, viewed, etc. with each method. Full access None Limited to a limited number of methods used for testing. DRAS Client Interface n/a* Full access none DRAS Interface on DRAS Client Full Access none none

DRAS DRAS Operator Participant Operator

Full access Utility Program Operator none DRAS Client none DRAS Client Installer *n/anotapplicable

none Full access none

none n/a* none

FormanyofthefunctionsdescribedinthisdocumenttheDRASmustlimitthe invocationofthedataandmethodsthatareaccessiblebaseduponthecredentialsofthe userwhoisaccessingthefunction.Forexampleifauserwiththeparticipantoperator roleaccessestheGetParticipantAccountfunctionitmustonlyhaveaccesstothose ParticipantAccountentitiesthatmatchthecredentialsoftheuseraccessingthefunction. Thevariousaccessrestrictionsbaseduponthesecurityrolesisdocumentedwitheach functiondescribedabove. Additionally,fortimecriticalservices,theDRAScanestablishaconnectiontotheDRAS ClientsDRASinterfaceforperformingaPUSHtransaction. Allpubliccommunicationinterfacesaresubjecttothefollowingrequirements [RFC4949]: Confidentiality:thecontentofcommunicationandtheidentityofusersmustbe protectedfromthirdparties Integrity:communicationmustbeprotectedfrommanipulation Authentication:communicationisonlyallowedbetweenauthenticatedand knownpartners Nonrepudiation:transactionsandmessagedeliverycannotbedeniedneither bytheoriginnortherecipient.

Theserequirementscanbeaddressedviaoneofthefollowingmethods: DRASSecMethodA:Securetunnelwithserversidecertificatesinconjunction withusernameorpasswordclientauthentication DRASSecMethodB:Securetunnelwithserversideandclientsidecertificates DRASSecMethodC:WebServicesSecurity(reservedforfutureuse,not describedinthisversion)

112

Additionally,authenticatedclientshaveindividualvisibilityoftherespectiveservers dataandservices.Thisaccesscontrolisspecificallyaddressedinthedetailed documentationforeachmethodintheDRASAPI.Foreachmethodthefollowingis specified: Thesecurityroleisallowedaccesstothemethod. Forparticularsecurityrolesthetypeofinformationisallowedtobereturnedfor eachmethod.Forexampleauserwiththeparticipantmanagerrolecanonly accessinformationthatisrelatedtotheparticipantaccountthattheyare associatedwith.

SecurityManagementlikekeyandcertificatedistribution,firmwareupdates,key revocation,etc.isimplementationdependentandthusnotinthescopeofthisdocument. TheSecureTunnel,TransportLayerSecurityProtocol(TLS),Version1.0(ornewer)with Rivest,Shamir&AdlemanPKcryptography(RSA)extensionhasbeenchosen. Certificaterevocationlistsmustbeused.EachtransactionisaseparateTLSSessionsthat isterminatedaftertheresponse.Thefollowingciphersuitechoicereflectsthemost interoperableselectionofstateoftheartTLSAPIsatcreationoftheOpenADR specificationandshallbeconsideredasaminimumlevelandmusthavefortheDRAS. Theadditionalsupportforstrongerciphersisexplicitlyencouraged,aslongastheyare partoftheofficialTLSspecificationaspublishedbytheInternet Engineering Task Force (IETF): Keyexchange:RSA1024 DataEncryption:3DES(DataEncryptionStandard),AES128(Advanced EncryptionStandard) MessageIntegrityCode(MIC):SecureHashAlgorithm(SHA1)MIC:SHA1 MessageAuthenticationCode(MAC):HashedMAC(HMAC)MACHMAC SHA1

ThestablestateofthesystemisthatallAPIinterfacessatisfytheaboverequirementsup toacertainextentthatcorrespondstotheparticularthreatlevelandsystemvalue. Reachingthisstatedependsontheparticularimplementation.Ifthesecurityofone interfacedependsonthesecurityofanotherinterface(e.g.acryptographickeyfor interfaceAderivedfromapasswordthatisreceivedbyahumanuserviainterfaceB andenteredviainterfaceC),itmustbeshownthattheentireinformationchainsatisfies theoverallsecurityrequirements.Keydistributionandmanagementistherefore consideredimplementationdependent. AnimplementationchoosesthesecuritymeasuresforthenonAPIinterfacesaccording totheusagescenario,threatlevels,protectedvalues,etc.Theminimumlevel,givenin thisdocument,might(ClientA)ormightnot(ClientBandC)berightforaparticular implementationasexamplesshowninFigure45.Highersecuritymeasurescaneasilybe integratedintotheDRASifnecessary(ClientC)aslongastheyarebasedonopen

113

standards.Communicationpartnerswithlowersecuritylevels(ClientB)havetousea securityproxy.
DRAS

Proxy

ClientA

ClientB

ClientC

Figure 45. DRAS Communication Partners with Different Security Levels

Thechoiceofsecuritytechnologieslikeciphersshallbelimitedtothosethatareopen andfreelyavailablestandards.

114

10.3 11

Future Developments

Thisdocumentrepresentsamultiyearandmultiinstitutionalefforttodefinehowthe DRsignalingbetweenutilitiesorISOsandcommercialandindustrialfacilitiesis performedtoautomatetheprocessofissuingandrespondingtoDReventsanddynamic prices.Manyaspectsofthedatamodelsdescribedinthisdocumentarealready demonstratedandareinuseinavarietyofDRprograms.Thenextstepsindeveloping theOpenADRspecificationwillincludethefollowingobjectives: ExpandOpenADRtoadditionalDRprogramsanddynamictariffstogainmore experiencewithnewusecases. Engagealargeraudienceofstakeholdersandindustryexpertstofurtherdevelop theOpenADRspecification. Continuecollaborationwithformalindustrystandardsdevelopment organizations.

Objectives2and3arebeingsatisfiedbycreatingOpenADRgroupswithinboththe UtilityCommunicationsArchitecture(UCA)InternationalUsersGroup 1and OrganizationfortheAdvancementofStructuredInformationStandards(OASIS) 2.Both thesegroupsarehighlyrespectedwithstrongtiestoformalstandardsgroupslike InternationalElectrotechnicalCommission(IEC) 3.FuturedevelopmentoftheOpenADR specificationwilltakeplacewithinUCAandOASISwiththeobjectiveofmoving OpenADRtoaformalstandardsorganizationsuchasIEC.Therewillbeahighdegree ofcooperationbetweenUCAandOASISandwitheachplayingacomplementaryrolein thefurtherdevelopmentoftheOpenADRspecification. TheofficialpublicreviewperiodwasbetweenMayandJuly2008,withcomments accepteduntilNovember2008.Asignificantnumberofcommentsweresubmittedbya varietyofstakeholders.Whilemanyofthecommentswereaddressedinthisversion, somewillbeaddressedinfuturerevisionswithintheUCAorOASIS.Adetailed compilationofallthecommentsreceivedcanbefoundathttp://openadr.lbl.gov/.The followingisageneralcharacterizationofthetypeofissuesthatwillbeaddressedin futureOpenADRspecificationdevelopment: FeedbackfromFacilitiestoUtilityorISO:Whilethecurrentversionofthe documenthasinterfacesforprovidingfeedbackinformationfromthefacilityto theutilityorISO,furtheranalysisisrequiredformoredetailedspecification(s)to addressspecifictypesoffeedbacksuchascontrolstrategyorelectricityload information. SecurityofCommunicationsChannel:Whileacomprehensivesecurityanalysis isprovidedinthisdocument,therearenumberofissuessuchasscalability, interoperability,andcredentialmanagementthatcouldbenefitfromfurther

1 2

UCA International Users Group: http://www.ucaiug.org/ OASIS: http://www.oasis-open.org/ 3 IEC: http://www.iec.ch/

115

analysis.Inaddition,itmaybebeneficialtoharmonizethesecuritypolicieswith entitieswithinOASISandUCA. NetworkScalability:Furtherdetailedanalysisforveryhighvolumemessage traffic. Readability:Evaluatetheneedtocategorizekeyelementsofthespecification. ThecurrentspecificationcontainsinterfacesfortheutilityorISOand participants.Itmaybebeneficialtomodifyandseparatethespecificationinto morethanonedocument,withtheinitialfocusontheutilityorISOtoparticipant communications. ExpansionofClientInterfaces:SupportadditionalDRASClientinterfacessuch asObjectLinkingandEmbedding(OLE)forProcessControl(OPC)Unified Architecture(OPCUA). Harmonization:EvaluateOpenADRharmonizationwithotherindustryefforts thatarestandardizingmodelsforcommondataentitiessuchasdynamicpricing. AncillaryServices:ExploretheuseofOpenADRinothermarketssuchas wholesaleandancillaryservices. ImplementationGuidelines:DevelopOpenADRimplementationand complianceguidelinestofosterinteroperability.

BenefitstoCalifornia
OpenADRwillprovidebenefitstoCaliforniabybothincreasingthenumberoffacilities thatparticipateindemandresponse,andreducingthecosttoconductfrequentand persistentparticipationindemandresponse.FurthermoreOpenADRwillimprovethe feasibilityofachievingthestatespolicygoalsofmovingtowarddynamicpricing,such ascriticalpeakorrealtimepricing,forallcustomers.Increasingparticipationin demandresponsereducestheneedfornewelectricsupply,reducestheneedfornew transmissionanddistributionsystems,andhelpsreduceoverallelectricityprices.

116

12 Definitions, Acronyms and Abbreviations


Forthepurposesofthisreport,thefollowingtermsanddefinitionsapply: AMISEC API AutoDR BACnet BIP CBP CIP CPP CSML DBP DR DRAS DRRC EDBP EMCS GBP GEBP HVAC HTTP IETF IP ISO IT kW kWh NIST NOC OASIS PG&E PCT OpenADR PDC REST RFC RTP SDG&E AdvancedMeteringInfrastructureSECurity ApplicationProgrammingInterface AutomatedDemandResponse BuildingAutomationControlNETwork BaseInterruptibleProgram CapacityBiddingProgram CriticalInfrastructureProtection CriticalPeakPricing ControlSystemsModelingLanguage DemandBiddingProgram DemandResponse DemandResponseAutomationServer DemandResponseResearchCenter ElectronicDemandBiddingProgramor(Automated)Demand BiddingProgram EnergyManagementControlSystems GenericBiddingPrograms GenericEventBasedPrograms Heating,ventilationandairconditioning HyperTransferTextProtocol InternetEngineeringTaskForce InternetProtocol IndependentSystemOperator InformationTechnology Kilowatt KilowattHour

NationalInstituteofStandardsandTechnology NetworkOperatingCenter OrganizationfortheAdvancementofStructuredInformation Standards


PacificGas&Electric ProgrammableCommunicatingThermostat OpenAutomatedDemandResponseorOpenAutoDR PeakDayCredit RepresentationalStateTransfer RequestforComment RealTimePricing SanDiegoGas&Electric

117

SHA SOAP TLS UI UIS WSDL XML XSD

SecureHashAlgorithm SimpleObjectAccessProtocol TransportLayerSecurity UserInterface UtilityInformationSystem WebServiceDescriptionLanguage eXtensibleMarkupLanguage XMLSchemaDefinition

118

Appendix A: XSD Schema Files


ThefollowingXSDschemafilesarepostedathttp://openadr.lbl.gov/src/,includingboth documentationandsourcecodeformats: Bid.xsd DR034A22wSchema.xsd
DRAS.xsd 14-Jan-2009 12:08 15-Jan-2009 16:18 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 3.4K 39K 1.8K 11K 12K 25K 4.8K 5.7K 4.5K 11K 13K 9.8K 9.7K 9.8K

DRASClient.xsd EventInfo.xsd
EventState.xsd FeedBack.xsd Logs.xsd OptOutState.xsd ParticipantAccount.xsd ProgramConstraint.xsd ResponseSchedule.xsd UtilityDREvent.xsd UtilityProgram.xsd

APA1

APA2

Appendix B: WSDL Interface Files


ThemostrecentversionsofthefollowingWSDLinterfacefilesandAPIspecifications, includingdocumentationandsourcecodeformats,arepostedat http://openadr.lbl.gov/src/):
DRASClientBACnet.wsdl ParticipantOperator.wsdl UtilityInterface.wsdl UtilityOperator.wsdl bacnet.wsdl 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 14-Jan-2009 12:08 4.0K 110K 2.5K 66K 12K

APB1

APB1

Appendix C: Security Analysis and Requirements


Thisappendixprovidesahighlevelsecurityanalysisofthevariousriskfactors associatedwiththeOpenAutomatedDemandResponseCommunicationsSpecification, alsoknownasOpenADRorOpenAutoDR.Theappendixalsopresentsasetofsecurity requirementsbasedonthisanalysis.

C.1

Assumptions

ThefollowingassumptionsformthebasisoftheOpenADRsecurityanalysis: ThisdocumentisanApplicationProgrammingInterface(API)specification.Therefore forthesakeofthisdiscussion,thesecurityperimeteroftheDRASencompassesthe functionsthatdefinetheAPI.Theonlymaliciousactivitiesconsideredwithinthescope ofthisdocumentarethosethatmaybeenabledbysomeoneusingoneofthefunctions definedbythisdocument.Themaliciousactivityitselfneednotbetheactualuseofone oftheAPIfunctions.Forexample,thecasewherethirdpartiesmaybemonitoringthe activityofanauthorizedusersaccessofanAPIfunctionwhichsubsequentlyenables someothertypeofmaliciousactivitythatmaynotincludetheAPIfunction(i.e.,stealing sensitiveinformation). Allthefunctionsdefinedinthisdocumentareimplementedusingindustrystandard Webservices.Thismeansthatthereisawelldefineddatamodel(typicallyutilizing HTTP)thatdefineshowthefunctionsareinvoked.WebservicestypicallyutilizeIP networksandmorespecificallytheInternet,althoughthismaynotbenecessarily AllusershaveasetofcredentialsandmustidentifythemselvestotheDRAStouseany ofthefunctionsdefinedinthisdocument.Notethatcertificatemanagementand distributionarefortheactualserverandclientimplementationandnotpartofthe OpenADRdatamodelitself.Also,dependingoncommunicationstechnologyselection, usercertificateswillplayaroleinsecuringtheclient/serverdatacommunications architecture.Thedetailsofcertificatemanagementforthispurposeareoutsidethescope ofthisdocument. Thisspecificationassumesthattherearewelldefinedsecurityrolesforusersthatrestrict thescopeoftheusersaccess(machinetomachineandhumantomachine)tofunctions definedinOpenADRandthedatathatcanbeaccessedthroughthosefunctions.The managementoftheserolesaswellastheirscopeandgranularity,whileimportantin understandingOpenADRoperations,areoutsidethescopeofthisdocument.

C.2

Existing Security Standards

ItistheintentthattheOpenADRspecificationleverageexistingsecuritypoliciesand standardswhenapplicable.Thefollowingpoliciesandstandardsarethereforerelevant tothiseffort:

NorthAmericaElectricReliabilityCorporation(NERC)CriticalInfrastructure Protection(CIP)CIP002throughCIP009

APC1

NationalInstituteofStandardsandTechnology(NIST)SP80082Guideto IndustrialControlSystems(ICS)Security OrganizationfortheAdvancementofStructuredInformationStandards (OASIS)WebServicesSecurityStandards OpenAdvancedMeterInfrastructureSecurity(OpenAMISEC)Policies

ItshouldbenotedthatAMISEC(AdvancedMeteringInfrastructureSECurity)has performedanindepthanalysisofawiderangeofriskfactorsandobjectivesthatare withinadomainsimilartothatoftheDRAS.InmanyrespectsthescopeoftheAMISEC analysisismuchbroaderthanwhatisaddressedbytheDRAS.Wheretherearerelevant usecasesandanalyses,thesecuritypolicyoftheDRASshouldsatisfytheanalysisand requirementsasestablishedbytheAMISECworkinggroup. ItshouldalsobenotedthatbecausetheDRASisutilizingWebservicesasthe infrastructuretoimplementthespecifiedfunctions,theDRASshouldadheretothe securityprinciplesandpoliciesasspecifiedbyOASISandothercommitteesor organizations,suchastheInternetEngineeringTaskForce(IETF),WebServices Interoperability(WSI),WorldWideWebConsortium(W3C),etc.,thatspecializein specificationsfortransactionsandinteractionsthatutilizetheInternetinparticular, thoseinvolvedinelectroniccommercetransactions.

C.3

DRAS Risk Context

ThisdocumentprimarilydescribesasetofAPIsandthecommunicationsservices requiredtosupportthesemanticsofthoseAPIs.Italsocontainsasuitableinformation modelthatiscapableofsupportingbothclientandserverrolesofadistributeddemand responseclient/serversystemarchitecture.Whentakenasawhole,theyprovidea reasonablycompletesetofcommunicationandsemanticrequirementsforthefunctional aspectsofamodernDRASsystem.Havingsaidthis,nospecificationofamodern, distributedcomputingapplicationcanbeconsideredcompletewithoutathorough discussionofboththeimplicitandexplicitsecurityrequirementsneededtoensureits correctbehavior. SecurityissuesintersectwithOpenADRimplementationsontwofundamentallevels eachofwhichisassociatedwithadifferentsetofrisks.Forthepurposeofanalysis, assumethatcommunicationsbetweenparticipatingDRsystemsisreliable,privateand authenticated.Thismeansthefollowing: Themessagebytestreamssentbyeitherclientorserverarriveattheir destinationcorrectlythereceivedbytestreamisafullfidelitycopyofthesent stream. Themessagessentineitherdirectionarenotviewedorinterpretedbyanythird partytheyareconsideredprivate. Thereceiverofeachmessagecanbeabsolutelycertainabouttheidentityofthe messagesendsi.e.,thatthetrueidentityofthesenderisknown.

APC2

Giventhisidealand,unfortunately,unrealisticdepiction,operationofanOpenADR specificationisreasonablysecurebutnotcompletelywithoutrisk.Thefacilitymanager whomanagesaDRASClientcoulddecidetonothonortheircommitmentstoshedloads whenrequested.Thefacilitymanagercouldrefusetohonortheirbidobligationsor,by utilizinganunforeseenfeatureofenergypricingpolicy,attempttogamethesystem. And,ofcourse,alatentdesignorcodingerrorinaparticularOpenADRimplementation couldsurfaceandparalyzetheentiresystemforanextendedperiodoftime.Allofthese activitieswould,insomeway,puttheOpenADRoperationandtheutilityorISO enterpriseatrisk.And,liketheunforeseenhackerattack(seedetailsbelow),theycan happenwithlittlewarningandhavesubstantialoperationalandmonetaryeffects. However,asrisks,theseactivitiesarereasonablyforeseeableand,toalargedegree,can bemitigatedthroughgoodapplication,businesspractices,andpolicieswithinthe OpenADRenterpriseitself.Similarly,inthesoftwareimplementation,diligent applicationofaccepted,bestpracticesoftwareengineeringmethodscansubstantially reducetherisksassociatedwithtechnicalfailuresinimplementingtheOpenADRdata model(e.g.misconfiguredsystems,lostorcorruptedtransactionlogfiles,orpoorly implementedsystemprivilegemanagementandpasswordaccesscontrol). Unfortunately,forautomatedDRpurposes,OpenADRisoflittlevalueunlessitis deployedinawidelydistributedenvironmentanenvironmentwithamultitudeofrisks forreliabledatacommunications.Likeallwidelydistributedsystems,theexposureof criticalprogramdatacommunicationsfunctionstorealworldconditionscreates increasedoperationalriskofmaliciousattacks.RealworlddeploymentofOpenADR, therefore,requiresadditionaleffortstosecurereliableandrobustsystemoperation. Specifically,theseeffortsarecenteredonsecuringclientservercommunications. However,itisworthdifferentiatingthetypesofnewriskexposureencounteredwhen deployingOpenADRinthewild.SinceDRASClientsandserversare,infact, computersystems,theyaresubjecttoattemptsbyhackerstologinandobtainsufficient systemprivilegestocarryoutsomeformofmaliciousattack.Whilethiswouldclearly interruptorcurtailOpenADRoperations,therootcause,unauthorizedaccesstothe system,isaproblemforallcomputersdirectlyconnectedtotheInternet.Thereislittle thattheOpenADRspecificationcandotostrengthensystemsecurityagainstillegitimate loginsthan,perhaps,requirethatitbeexecutedonsystemsthatenforceindustrybest practicestopreventunauthorizedaccess.However,sincetheOpenADRarchitectureis basedonreliable,private,authenticatedcommunicationsbetweensystemcomponents, itisimportantthatthisspecificationrequireadditionalmeasurestosecuredata communications.Forthisreason,greatefforthasbeentakentospecifybestpractices securityimplementations,suchasWebservicessecurityandTransportLayerSecurity (TLS),fordatacommunications. ItisworthnotingthatimplementationsoftheseOpenADRspecificationswillnever,ina meaningfulway,existoutsideofalargersystemcontextthatarepartofthe infrastructure.Thislargercontext,whichincludesfeaturessuchasutilityorISOto DRASconnectivity,operationalpoliciesforsystemlogsecurity,mechanismsfor

APC3

assigningrolestoindividualusers,keydistribution,etc.,containsanumberofsystem elementsandprocessoutsidethescopeofthisdocument.And,althoughthese additionalsystemelementsinteractcloselywiththecorefunctionsdescribedhere,they bringalongadditionaluniquerisks.Whilethecorefunctionsdescribedinthis OpenADRspecificationareonlymeaningfulwhenimplementedaspartofalarger, operationalDRsystem,therearecriticalareasoftheinfrastructure,takenasawhole, thatarecorrectlybeyondthescopeofthisdocument.Inotherwords,evenifthecore functionsdescribedinthisdocumentareimplementedinaperfectlysecurefashion,the overallrobustnessoftheOpenADRenterpriseisdependentonrisksfoundatboththe OpenADRspecification,DRAS,andassociatedsystems.

C.4

DRAS Sources of Risk

TableC1listsageneralclassificationofthetypesofactivitiesthatmayadverselyaffect DRASoperations.Theseverityofriskisonaspectrumof1to3with1indicatingthe mostsevere.


Table C1. DRAS Sources of Risks and General Classification Accidental or non-Malicious Activities Operational errors by either utility or ISO and customer that limit a customers ability to respond to DR events. This could range from utility or ISO database data entry errors to incorrect equipment control settings at customer sites. Minor telecommunications equipment failures that affect only a portion of DRAS Clients. Major IT equipment failure at A DRAS site or widespread, regional telecommunications outage. Fatal DRAS software implementation flaws that surface under unusual or unexpected circumstances. Severity 3

3 to 2 1

UNKNOWN

Malicious, non-Communications Related Activities Participant denies submitting bid Participant denies receiving DR event information Intentional manipulation of DR events issued by the DRAS. Manipulation (i.e. gaming) of the DRAS system by one or more customers on discovery of unintentional flaw in system software implementation. Severity 2 2 3 3

Malicious Communications-based Activities Flood the DRAS communications channel with non-DR related Internet traffic (Denial of Service attack). Modify existing configuration data in the DRAS including programs, participants, etc. Severity 1 1

APC4

Issue spurious or detrimental DR events Modify existing DR events, including canceling them and changing which DRAS Clients receive the events. View data within the DRAS including participant information and user activities. View private data contained in messages flowing to and from the DRAS. Potentially gain access to a DRAS Clients credentials and directly access the DRAS Client (e.g. man in the middle attack). Disable the DRAS Client from receiving DR events Manually issue messages to DRAS Client Shut down all DRAS operations Shut out access to other operators Submit Bids for participants Reject/Accept Bids Mimic the DRAS Client and intercept DR event messages Submit false feedback information Participant denies submitting bid Participant denies receiving DR event information

1 1 1 1 1 1 1 1 1 1 1 1 1 2 2

C.5

Adverse Risk-Related Effects

Oneimportantobservationisthat,regardlessofthemaliciousoraccidentalnatureofthe aboverisks,whentheyareencountered,theireffectistolimittheabilityofcustomersto respondtoDRsignals.Somefailurescenarioswillcauselongerdisruptionsthanothers andthegeographicalextentofthedisruptionwillvarywiththenatureoftheaction.But theresultsaresubstantiallythesame.Forexample,some,orall,oftheDRenterprise couldbeinoperableforsomelengthoftime.Asaresult,theseriskshaverealand tangible,costsassociatedwiththem.Everyhourthatsome,orall,oftheDRenterpriseis offline,bothUtilitiesandcustomersaredeniedtheopportunitytooptimizethecost ofrespectiveoperations.But,theredoesnotappeartobeaclearsignaturethat differentiatesthekindsofadverseresultsthatfollowfromanaccidentalerrororatruly maliciousattack. Itshouldalsobenotedthattheseactions,eitheraccidentalormalicious,shouldnot presentanyincreasedrisktoeitherthesafetyofutilityorISOandcustomeroperations staffortomajorelectricalequipment.GiventhescopeofDRactivities,asdefinedinthis specification,DReventsarenotintendedtobepartoftimecritical,closedloopcontrol designsthatcouldadverselyaffectthesafetyofeitherpersonnelorequipment.While AutoDRsystemsareclearlyintendedtobereliableandrobustoverlongperiodsof time,bytheirdistributednature,theyarealwaysatsomeriskofsufferinga communicationsfailuremaliciousorotherwise.TheinclusionofOpenADRmediated

APC5

loadcontrolasanessential,systemcriticalpartofaclosedloopdispatchdesignwould beinappropriate.Therefore,atthehighestlevel,theOpenADRapplicationsshouldbe designedtobeintrinsicallysafeinthepresenceofunexpectedcommunications failuresaccidentalormalevolent. WhileitisclearthatOpenADRsystemsshouldbedesignedtoavoidanypotentialharm topeopleorequipment,systemscanalsobedesigned,usingtheexistingspecification,to detectandignoreunreasonableDReventsthatcouldotherwisetriggerlarge, automatedreductionsinpoweruse.ConsideraDRASClientthatreceivesaDRevent indicatingalargeandunsupportableincreaseinthecostofelectricalpower.Thisevent couldbetheresultoftheutilityorISOoperatorerror,malicioushackeractivity followingacommunicationssecuritybreech,orevenayetundiscoveredprogramming bug.RegardlessofthesourceofthisunreasonableDRpricingevent,DRASClients could,ifnotproperlyprotected,automaticallyrespondbysheddingsubstantialpower loadsinordertoavoiddrasticallyincreasedpowercosts.Whilethisoperationmaybe safe,intheabovesenseofnotendangeringpeopleorequipment,itmayprovecostlyto largescaleindustrialprocessesortocommercialbuildingoccupantsduringperiodsof extremecoldweather.Fortunately,OpenADRhasamechanismfordetectingsuch unusualDReventsandplacingallpotentiallyautomaticchangesfortheseeventsina pendingstate,subjecttoDRASClientapproval.Thisverificationcanbeassimpleas callingthelocalutilityorISOdispatchofficeorreceivingaconfirmingemailfromthe relevantDRAS.Thecriticalpointisthat,regardlessoftheiraccidentalormalicious nature,theOpenADRspecificationcontainsmechanismsfortrappingcriticalorunusual DReventsandrequiringindependentverificationbeforetakinganyaction. Ultimately,theresultofpersistentorchaoticcommunicationsmalfunctions(accidental ormalevolent)isthepotentialerosionoftrustorreputationbetweenanOpenADR enterpriseanditscustomers.Thisis,perhaps,themostinsidiousandleastunderstood majorrisk.ThemotivationtoparticipateinaDRprogramisderivedfromacustomers abilitytoexchangereducedflexibilityinelectricalpowerconsumptionforamonetary value.OpenADRtechnologyprovidesthemechanismtoaccomplishthisgoalby managingtheexchangewhileminimizingtheeffortrequiredonthepartofthe consumer.Althoughoperationalproblemsariseinalmostanyenterprise,the assumptionborneoutbydailyexperienceisthat,eventually,theseproblemscanbe resolvediftheappropriatepartiescommunicate.However,ifunknownthirdparties intrudeintothebusinessrelationshipandinstigatechaoticor,evenworse,malevolent activity,thentheelementoftrustwillquicklyerode.Oneneedonlylookatthelevelof effortthatsuccessfulInternetvendorsputintotheircustomersupportcentersto understandhowcriticaltrustistocomputercommunicationsmediatedrelationships. Asnotedearlier,whenOpenADRsystemsbecomeinoperableorpartiallyineffective, bothUtilitiesandcustomersincurbothreallossesandmissedopportunitycosts. Sincetheresultsofeitheraccidentalormaliciousactionsareessentiallythesame,risk reductioninalltheareasnotedabovewill,inaggregate,improvethecosteffectiveness ofautomatingDR.Itisclearthatanyreductionintheriskexposurefordata

APC6

communicationsdisruptionwillbenefittheOpenADRenterprise.Inlargepart,thisis exactlytheriskprofileexperiencedbymostelectroniccommercebasedbusinesses.They areatriskfrombothinternalandexternalactions,accidentalandmalicious,that ultimatelydrivetheirfinancialsuccess.Therefore,thesecuritymodeltheyapplytodata communicationsreliabilityis,inlargepart,directlyapplicabletotheneedsofthe OpenADRenterprise.Byleveragingtheriskanalysisseenintheelectroniccommerce domain,onecantakeadvantageofthelargercommunityofintereststhatarefocusedon securingdistributeddatacommunicationsand,ultimately,sharemuchofthecommon securityinfrastructurethathasbeendeveloped.Theprimarysecurityareafocusedon withinthisOpenADRspecification,namelysecuredistributeddatacommunications,are thesecuritystandardsingeneralusebyelectroniccommerceapplications,TLSandWeb services,areappropriateforaddressingOpenADRcommunicationssecurityrisks.

C.6

Security Requirements

Thefollowingsetofgeneralsecurityrequirementsisderivedfromtheriskanalysis above: AlloftheWebservicemethodsdefinedbythevariousDRASinterfacesshould beaccessibleonlybyauthorizedusers. TheDRASmustpreventtheaccessofsensitiveinformationstoredwithinthe DRASexceptbyauthorizedusers.Sensitiveinformationisdefinedasany informationthatwouldnototherwisebepubliclyavailable. InformationstoredwithintheDRASmustnotbemodifiedexceptbyauthorized users. TheDRASmustprotecttheconfidentialityoftheparticipants,utilitiesandISOs thatareusingtheDRAS.Thismeansthattheidentityofthepartiesaccessingand usingtheDRASshouldbekeptconfidentialfromallunintendedusers. InformationexchangedwiththeDRASmustmaintainconfidentialityand integrityfrom3rdparties(protectionfrominspectionandinterferencefrom unintendedusers)whileitisintransittoorfromtheDRAS. ItmustbepossibleforinterfacesonutilityorISOandparticipantsitesthatare accessedbytheDRAS(i.e.PUSHmodeofoperation)tobemadesecuresuchthat thoseinterfacescanonlybeaccessedwiththepropercredentials. TheDRASmustprovidealternatechannelsofnotificationinorderallowhumans toverifyandauthorizeinteractionswiththeDRASinscenarioswhereitis operationallyrequiredtohavemultiplelevelsofverificationandauthorization beforeanyactionsbetakeninresponsetoamessagefromtheDRAS.An exampleofsuchanalternatechannelmightbeanemailorvoicemessagetoan operator. TheDRASmustsupportthenonrepudiationofthefollowingtransactions: a. Bidssubmittedbyparticipants

APC7

b.

ReceptionbyparticipantsofDReventmessages

WhereapplicabletheDRASshouldadoptsecuritymethodsandpoliciesfrom otherstandardsbodiessuchasNIST,OASISorUtilityAMI(UtilityAdvanced MeteringInfrastructure).

APC8

Appendix D: DR Program Use Cases


ThissectionlistsusecasesrelatedtotheOpenAutomatedDemandResponse CommunicationsSpecification,alsoknownasOpenADRorOpenAutoDR.Mostuse casesarederivedfromactualDRprogramsanddynamictariffsinoperationtoday. Someareeithergeneralizationsofexitingprograms,orenvisionedasyettobedefined DRprograms.ItisnotintendedtobeanexhaustivelistofallknownDRprogramsand potentialdynamictariffs,butarepresentativesampling. ThedescriptionsoftheDRprogramsanddynamictariffslistedinthissectionrelyon specificprogramscurrentlybeingoffered,butshouldbeviewedasexamplesthatare usedwithinthecontextofanautomatedDRprogram.Theusecasesshouldnotbetaken toliterallyreflecthowthecurrentDRprogramsoperate,buthowtheymightoperatein anautomatedfashionwithaDRAS.

D.1

General Use Case Definitions and Nomenclature


Atextualdescriptionoftheelementsoftheusecase. Adiagramthatdepictstherelationshipbetweenvariousroles,actions,and systemsintheusecase. Asetofusecasescenarioswithaccompanyingproceduresandstepsthat describethesequenceofactionsthatarepartofthatscenario.

Eachusecaseconsistsofthefollowingdocumentation:

D.1.1 Use Case Elements


Eachusecaseselementsorcomponentsincludesystems,actionsandroles. D.1.1.1 Systems Inusecasediagrams,systemsaredenotedbyrectanglesthatencompassactions,roles andothersubsystems(SeeFigureD1).
Figure D1. Use Case System

SYSTEM

Theusecasesthatfollowconsistofthefollowingsystems: Utility:ThisistheentireutilityorISOorganizationthatisresponsibleforthe distributionofelectricity. UtilityInformationSystem(UIS):ThisistheITsystemandsoftwarewithinthe utilitythatisusedtomanagetheUtilitiesoperations.Muchofwhatisdepicted

APD1

inthissubsystemintheusecasearenotdirectlyrelatedtotheDRAS,but includedanywayforcompletenessindepictingtheDRprograms.Thuseven thoughwhatisdepictedintheusecasemayvaryconsiderablybetweendifferent Utilities,itisthegoalofthiseffortthatsuchdifferencesdonoteffectthe operationoftheDRAS. DRAS:Thissystemisthefocusofthisdocument. Facility:Thebuildingorfactorywhereelectricityisconsumed. Aggregator:Athirdpartyresponsibleformanagingacollectionoffacilities whileprovidingasingleinterfacetotheutilityorISOforthemanagementand billingofthosefacilities. DRASClient:Thisisasubsystemwithinthefacilityoraggregatorthatis responsibleforbridgingcommunicationsbetweentheDRASandanyautomated system(e.g.,EMCS)thatisresponsibleforcontrollingenergyconsumption.It maybeasoftwarebasedDRASClientthatisimplementedwithanexistingsub systemsuchastheEMCSoritmaybeadedicatedpieceofhardwarewhoseonly responsibilityistoproxycommunicationsbetweentheDRASandEMCS.

ItisthegoaloftheOpenADRspecificationthattheDRAScommunicationsare independentoftheplatformandtechnologiesinwhichtheDRASClientisimplemented andthattheDRASsupportsarangeofDRASClientswithdifferentcapabilities.Itisnot withinthescopeofthisdocumenttospecifyhowtheDRASClientinterfacesand communicateswiththefacilityEMCSorITsystems.TheDRASwillsupporttwoclasses ofDRASClientshenceforthreferredtoasIntelligentDRASClientsandSimple DRASClients.IntelligentDRASClientsaretypicallysoftwarebasedandareableto makesophisticateddecisionsbasedupontheinformationavailable.ThereforeIntelligent DRASClientsshouldreceiveallavailableinformationconcerningDReventsgenerated fromtheUtilities.OntheotherhandSimpleDRASClientshavelittleornocapabilities formakingdecisionsaretypicallyjusthardwiredtoexistingEMCSsystemsviarelays. AssuchtheyreceiveverysimplesignalwaveformsassociatedwithDReventssuchas high,medium,andnormalwhichgetmappedtorelaycontacts.Themappingbetween theutilityorISOgeneratedDReventsandthesignallevelsareperformedintheDRAS beforebeingsenttotheDRASClient. D.1.1.2 Actions Actionsaredepictedasovalsandaretasksthatareperformedbyarolewithinasystem (FigureD2).

Actions

Figure D2. Use Case Actions

APD2

D.1.1.3 Roles Typically,arole(oranactorinarole)isamemberofasystemandisresponsiblefor performingactionsonasystem.Therelationshipbetweenaroleandanactionis depictedbyalinefromtheroletotheactioninthediagram.Arolemaybefilledbya human,orbysomehardwareorsoftwareentity.Humanrolesaredepicteddifferently frommachinerolesasshowninFigureD3. Machine

Human

Figure D3. Use Case Roles

D.2

Specific Use Cases

ThefollowingsectionsoutlinesomespecificusecasesofDRprogramscurrentlybeing offeredbytheutilitiesorISOs.

D.2.1 Critical Peak Pricing (CPP)


CriticalPeakPricing(CPP)isaDRprogramthatiscurrentlyofferedbyallthree Californiainvestorownedutilities(IOUs.)PacificGas&Electrics(PG&Es)website, http://www.pge.com/biz/demand_response/critical_peak_pricing/,providesthe followingdescriptionofaPG&ECPPprogram: CPPeventswillgenerallybetriggeredbytemperature,butmayalsobeactivatedby PG&Easwarrantedbyextremesystemconditions:

SpecialalertsissuedbytheCaliforniaIndependentSystemOperator UnderconditionsofhighforecastedCaliforniaspotmarketpowerprices Fortestingorevaluationpurposes

D.2.1.1 CPP Directly to Facility ThefollowingsetofusecasesconcernCPPprogramswhichareenacteddirectlywith participantfacilities.TheusecasediagramcanbeseeninFigureD4.

APD3

Figure D4. CPP Direct To Facility D.2.1.1.1 CPP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theCPPDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsuptheCPPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheCPPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheCPPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtotheDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification Customerpassword

APD4

Geographiclocation Gridlocation

3a. ThefacilitymanagerconfiguresthefacilitysEMCSandnetworkforDR,possibly inconjunctionwiththeEMCSvendorandITstaff.Thiscouldinclude programmingtheEMCStorespondtoDReventsandshedorshiftloads appropriately.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3b.ThefacilitymanagerconfiguresDRASClients,possiblyinconjunctionwiththe technicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeFacilitiessystemsthatareresponsibleformanagingthe loads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. ThefacilitymanagerconfiguresDRprogramparametersandDRASClient connectionintheDRAS.ThisstepestablishestheconnectionbetweentheDRAS ClientandtheDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifpollingtheDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinfutureOpenADRstandards,this maybeperformedintheDRASClientandnotintheDRAS.


D.2.1.1.2 CPP Execution

TheactionstoexecuteCPPeventsconsistofthefollowingsteps: 1. TheutilityprogramoperatorcreatestheCPPeventintheUtilityInformation System.InthisstepaprogramoperatorschedulestheCPPeventintheUtility InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetstheCPPeventinformationfromtheUtility InformationSystemandinitiatestheCPPeventintheDRAS.Theinformation senttotheDRASbytheutilityprogramnotifiersubsystemincludes:

APD5

Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3. TheeventnotifierintheDRASsendstheCPPeventinformationtoallDRAS ClientsintheCPPprogram.TheCPPeventinformationsenttotheDRASClients includes: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

4. TheDRASEventClientforthefacilitysendsshedorshiftinformationtothe EMCSwhichinturnshedsloads.Thedetailsofthisprocessarebeyondthescope ofthisdocument. 5. TheDRASFeedbackClientforthefacilitysendsthesystemloadstatustothe DRAS.Thisisafeedbackmechanismthatisusedtorecordhowthefacility respondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.)

6. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyond thescopeofthisdocument.


D.2.1.1.3 CPP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheCPP program.Unliketheconfigurationandexecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime:


APD6

Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs

1b.Thefacilitymanagerchecksthestatus.Theutilityprogramoperatorcangetthe followingstatusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifiesanddeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.ThefacilitymanageroptsoutoftheDRprogram.Atanytime,thefacility managercanoptoutoftheDRprogramontheDRAS.Wheninanoptout condition,DReventsarenotpropagatedtotheDRASClient.Theoptoutcanbe eitherfortheentireprogramorasingleeventoraspecificeventmode(e.g. normal,moderate,high) 1e. Theutilityprogramoperatorand/orthefacilitymanagerreceivesanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichareoutsidethescopeofthisdocument. Thetypeofexceptionscoveredbythisinterfaceincludes: DRASClientcommunicationsfailure.

D.2.1.2 CPP via Aggregator IntheactualCPPprogramscurrentlyofferedbyPG&E,theaggregatorsdonottypically playarole.Thefollowingusecasesenvisionhowanaggregatormightplayarolewith theDRAS.Itisverysimilartothedirecttofacilityusecase.Theusecasediagramcanbe seeninFigureD5.


APD7

Figure D5. CPP via Aggregator D.2.1.2.1 CPP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theCPPDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsuptheCPPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheCPPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheCPPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification Customerpassword

APD8

Geographiclocation Gridlocation

3a. Theaggregatorconfiguresthefacility(EMCSandnetwork)forDR,possiblyin conjunctionwiththeEMCSvendorandITstaff.Thedetailsofthisprocessare beyondthescopeofthisdocument. 3b.TheaggregatorconfigurestheDRASClients,possiblyinconjunctionwiththe technicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeaggregatorssystemsthatareresponsibleformanaging theloads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. TheaggregatorconfigurestheDRprogramparametersandtheDRASClient connectionintheDRAS.ThisstepestablishestheconnectionbetweentheDRAS ClientandtheDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram. Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters. o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingtheDRASClient.

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters. Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringwithintheDRAS,but dependinguponhowthisstepissubsequentlyimplementedinafutureOpenADR standards,thismaybeperformedwithintheDRASClientandnotwithintheDRAS.


D.2.1.2.2 CPP Execution

ThesetofactionstoexecuteCPPeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatesCPPeventintheUtilityInformation System.InthisstepaprogramoperatorschedulesaCPPeventintheUtility InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetsCPPeventinformationfromtheUtility InformationSystemandinitiatesCPPeventintheDRAS.Theinformationsentto theDRASbytheutilityprogramnotifiersubsystemincludesthefollowing information:

APD9

Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3. TheeventnotifierintheDRASsendsCPPeventinformationtoallDRASClients inCPPprogram.TheCPPeventinformationsenttotheDRASClientsincludes thefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

4. TheDRASEventClientforthefacilitysendsshedorshiftinformationtothe aggregatorssystemwhichinturncausestheaggregatortoshedorshiftloadsin variousfacilities.Howthisprocessisdoneisbeyondthescopeofthisdocument. 5. TheDRASFeedbackClientfortheaggregatorssystemsendsthesystemload statustotheDRAS.Thisisafeedbackmechanismthatisusedtorecordhowthe facilityrespondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.)

6. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Thedetailsofthisprocessare beyondthescopeofthisdocument.


D.2.1.2.3 CPP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheCPP program.UnliketheConfigurationandExecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime:


APD10

Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs

1b.Thefacilitymanagerchecksstatus.Theutilityprogramoperatorcangetthe followingstatusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifiesanddeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheaggregatoroptsoutoftheDRprogram.Atanytime,theaggregatororthe aggregatoractingasfacilitymanagercanoptoutoftheDRprogramonthe DRAS.Whenthereisanoptoutcondition,DReventsarenotpropagatedtothe DRASClient.Theoptoutcanbeeitherfortheentireprogramorasingleevent. 1e. Theutilityprogramoperatorand/ortheaggregatoroperatorreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientcommunicationsfailure.

D.2.2 Demand Bidding Program (DBP)


TheDemandBiddingProgram(DBP)isofferedbyPG&E.PG&Eswebsite, http://www.pge.com/mybusiness/energysavingsrebates/demandresponse/dbp/,hasthe followingdescriptionofthisprogram:

APD11

The(Automated)DemandBiddingProgram(EDBP)paysanincentivetoreduce electricloadsaccordingtoavoluntarybidmadeforascheduledloadreductionon thefollowingnonholidayweekday.Underthisprogram,participantsreceivea creditequaltotheproductofthequalifiedkilowatt(kW)energyreductionandthe incentivepriceofupto$0.60/kWh. HowtheDayAheadProgramWorks WhentheforecastedsystemreservemarginsforthenextdayresultintheCalifornia IndependentSystemOperator(CAISO)issuinganAlertNotice,orwhentheCAISO dayaheadforecastedpeakdemandis43,000megawatts(MW)orgreater,orwhen PacificGasandElectricCompany(PG&E),initssoleopinion,forecaststhat resourceswillnotbeadequate,PG&Emayrequestloadreductionbidsfrom customersforthefollowingnonholidayweekday.Customersseekingtoparticipate intheEDBPcansubmitbidsforaproposedlevelofcurtailment. Participatingcustomerswillhaveuntil12:00noononthedaybeforeaproposed curtailmenteventtosubmitbidsviatheITRONsInterActwebsite.Upon evaluationfromPacificGasandElectricCompany,customerswillbenotifiedofbid acceptanceafter4p.m.ofthesameday.Unlessaspecificmegawatt(MW)limitis requested,PG&Ewillacceptallbids.Participantsmustbidaminimumoftwo consecutivehoursthroughoutthedayandmustmeettheminimumenergy reductionthresholdof50kilowatts(kW)forsingleaccountand200kilowatts(kW) foraggregatedaccounts. DayAheadIncentives TheDayAheadEDBPincentivesarecalculatedonanhourlybasis,andwillbe equaltotheproductofthequalifiedkWreductionforeachhourabidwasaccepted andtheincentivepriceof$0.50/kWh. HowtheDayOfProgramWorks WhentheCAISOissuesanyalertduringthedayreflectingstressonthesystem, PG&EmayimplementanEDBPeventforthatsameday.Customershaveonehour afteraDayOfeventhasbeenissuedtosubmitbidsforaproposedlevelof curtailment.Unlessaspecificmegawatt(MW)limitisrequested,PG&Ewillaccept allbids. IfacustomeralreadyhasacceptedbidsfortheDayAheadprogramcustomersmay 1)increaseitsbidsforthosehoursthattheDayAheadandDayOfDBPevents coincide,and2)submitnewbidsforthosehoursintheDayOfDBPeventthatwere notapartoftheDayAheadevent.Ifnoadjustmentstothebidaremadethe participationisautomaticallytransferredtotheDayOfprogramwiththehigher incentiveprice.

APD12

DayOfIncentives TheDayOfEDBPincentivesarecalculatedonanhourlybasis,andwillbeequalto theproductofthequalifiedkWreductionforeachhourabidwasacceptedandthe incentivepriceof$0.60/kWh. D.2.2.1 DBP Directly to Facilities ThefollowingsetofusecasesconcernCPPprogramswhichareenacteddirectlywith participantfacilities.TheusecasediagramcanbeseeninFiguresD6andD7.

Figure D6. DB Program Configuration

APD13

Figure D7. DBP Direct to Facility D.2.2.1.1 DBP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theDBPDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsuptheDBPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringalltherequired informationnecessaryfortheparticipanttoparticipateintheDBPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheDBPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification

APD14

Customerpassword Geographiclocation Gridlocation

3a. Thefacilitymanagerconfiguresthefacility(EMCSandnetwork)forDR,possibly inconjunctionwiththeEMCSvendorandITstaff.Thiscouldinclude programmingtheEMCStorespondtoDReventsandshedorshiftloads appropriately.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3b.ThefacilitymanagerconfigurestheDRASClients,possiblyinconjunctionwith thetechnicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeFacilitiessystemsthatareresponsibleformanagingthe loads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. ThefacilitymanagerconfiguresastandingbidintheDRAS.Thisisthebidthat willbeautomaticallyplacedbytheDRASwhenarequestforbidscomesfrom theutility.Itincludesthefollowing: Loadreductionbidspertimeblock(priceandloadamount) 3d.ThefacilitymanagerconfigurestheDRprogramparametersandDRASClient connectionintheDRAS.ThisstepestablishestheconnectionbetweentheDRAS ClientandtheDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram. Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters. o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient.

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters. Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.

APD15

D.2.2.1.2 DBP Execution

ThesetofactionstoexecuteDBPeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatesorschedulestheDBPeventintheUtility InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetstheDBPeventinformationfromtheUtility InformationSystemandinitiatesaDBPeventintheDRAS.Theinformationsent totheDRASbytheutilityprogramnotifiersubsystemincludesthefollowing information: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers) RequestForBids(RFB)issuedateandtime RFBclosetime Priceofferedforloadreductionpertimeblock

3. TheDRASprogramnotifiersendsrequestforbidtothefacilitymanager.This notificationtypicallycomesintheformofanemail,phonecallorpage. 4. ThefacilitymanageradjustsorcancelstheircurrentbidintheDRAS.Thisisan optionalstepandallowstheManagertoadjusttheirbidforthatparticularevent.If thisstepisnotperformedthentheDRASwillsubmitthestandingbidaftersome periodoftime. 5. AftertimelimithasexpiredtheBiddingProxyintheDRASsetsthecurrentbidin theUtilityInformationSystem.TheinformationsentbytheDRASincludesthe following: Customeraccountnumber Loadreductionbidspertimeblock

6. TheutilityprogramnotifiergetsacceptedbidsfromtheUtilityInformationSystem andsetsacceptedbidsintheDRAS.Theacceptedbidsformthesetofparticipants thattheDRASwillsendDBshedorshifteventsto.Theinformationconcerning acceptedbidsinclude: Customerlist(accountnumber) Acceptorreject Loadreductionbidspertimeblock(forverification)

7. TheDRASprogramnotifiersendstheacceptancenotificationtothefacilitymanager. Themanagerisnotifiedofanacceptedbidviaphone,email,orpage.

APD16

8. TheeventnotifierintheDRASsendstheDBPeventinformationtoallDRASClients whosebidswereaccepted.TheDBPeventinformationsenttotheDRASClients includesthefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

9. TheDRASEventClientinthefacilitysendsshedorshiftinformationtotheEMCS whichinturncausesloadstobeshedorshift.Howthisprocessisdoneisbeyond thescopeofthisdocument. 10. TheDRASFeedbackClientintheaggregatorssystemsendsthesystemloadstatus informationtotheDRAS.Thisisafeedbackmechanismthatisusedtorecordhow thefacilityrespondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

11. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyondthe scopeofthisdocument.


D.2.2.1.3 DBP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheDBP program.Unliketheconfigurationandexecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional)

APD17

FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs Bidsandsignallevelspertimeblockforcurrentevents(forallparticipants, indivuallyandgroupedtogether)

1b.Thefacilitymanagerchecksstatus.Thefacilitymanagercangetthefollowing statusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove) Bidsandsignallevelspertimeblockforcurrentevents

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.ThefacilitymanageroptsoutoftheDRprogram.Atanytime,thefacility managercanoptoutoftheDRprogramontheDRAS.Whenthereisanoptout condition,DReventsarenotpropagatedtotheDRASClient.Theoptoutcanbe eitherfortheentireprogramorasingleevent. 1e. ThefacilitymanageradjustsstandingbidintheDRAS. 1f. Theutilityprogramoperatorand/orthefacilitymanagerreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientCommunicationsFailure

APD18

D.2.2.2 DBP via Third Party Aggregators ThefollowingsetofusecasesconcernDBPprogramswhichareenactedwith aggregators.TheusecasediagramcanbeseeninFigureD8.

Figure D8. DBP with Aggregator D.2.2.2.1 DBP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theDBPDRprogramandinvolvesthefollowingactions: 1. TheutilityprogramoperatorsetsuptheDBPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheDBPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheDBPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation:

APD19

Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification Customerpassword Geographiclocation Gridlocation

3a. TheaggregatorconfigurestheirsystemsforDR.Thedetailsofthisprocessare beyondthescopeofthisdocument. 3b.TheaggregatorconfigurestheDRASClients,possiblyinconjunctionwiththe technicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeaggregatorsystemsthatareresponsibleformanagingthe loads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. TheaggregatorsetstheirstandingbidintheDRAS.Thisisthebidthatwillbe automaticallyplacedbytheDRASwhenarequestforbidscomesfromthe utility.Itincludesthefollowing: Loadreductionbidspertimeblock(priceandloadamount) 3d.TheaggregatorconfigurestheDRprogramparametersandtheDRASClient connectionintheDRAS.ThisstepestablishestheconnectionbetweentheDRAS ClientandtheDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram. Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters. o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient.

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters. Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.

APD20

D.2.2.2.2 DBP Execution

ThesetofactionstoexecuteDBPeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatestheDBPeventintheUtilityInformation System.InthisstepaprogramoperatorschedulesaDBPeventintheUtility InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetsDBPeventinformationfromtheUtility InformationSystemandinitiatestheDBPeventintheDRAS.Theinformation senttotheDRASbytheutilityprogramnotifiersubsystemincludesthe followinginformation: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers) RequestForBids(RFB)issuedateandtime RFBclosetime Priceofferedforloadreductionpertimeblock

3. TheDRASprogramnotifiersendsarequestforbidtotheaggregator.This notificationtypicallycomesintheformofanemail,phonecallorpage. 4. TheaggregatoradjustsorcancelstheircurrentbidintheDRAS.Thisisan optionalstepandallowstheManagertoadjusttheirbidforthatparticularevent. IfthisstepisnotperformedthentheDRASwillsubmitthestandingbidafter somepresetperiodoftime. 5. Afterthetimelimithasexpired,theBiddingProxyintheDRASsetsthecurrent bidintheUtilityInformationSystem.TheinformationsentbytheDRAS includesthefollowing: Customeraccountnumber Loadreductionbidspertimeblock

6. TheutilityprogramnotifiergetsacceptedbidsfromtheUtilityInformation SystemandsetsacceptedbidsintheDRAS.Theacceptedbidsformthesetof participantsthattheDRASwillsendDBshedorshifteventsto.Theinformation concerningacceptedbidsinclude: Customerlist(accountnumber) Acceptorreject Loadreductionbidspertimeblock(forverification)

7. TheDRASprogramnotifiersendstheacceptancenotificationtothefacility manager.Themanagerisnotifiedofanacceptedbidviaphone,email,orpage.
APD21

8. TheeventnotifierintheDRASsendsDBPeventinformationtoallDRASClients whosebidswereaccepted.TheDBPeventinformationsenttotheDRASClients includesthefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

9. TheDRASEventClientforthefacilitysendsshedorshiftinformationtothe aggregatorssystemwhichinturncausestheaggregatortoshedorshiftloadsin variousfacilities.Howthisprocessisdoneisbeyondthescopeofthisdocument. 10. TheDRASFeedbackClientfortheaggregatorssystemsendsthesystemload statustotheDRAS.Thisisafeedbackmechanismthatisusedtorecordhowthe facilityrespondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

11. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementinUtilityInformationSystem.Howthisprocessisdoneisbeyondthe scopeofthisdocument.


D.2.2.2.3 DBP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheDBP program.UnliketheConfigurationandExecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetsoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional)

APD22

FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs Bidsandsignallevelspertimeblockforcurrentevents(forallparticipants, indivuallyandgroupedtogether)

1b.Theaggregatorchecksstatus.Theaggregatorcangetthefollowingstatus informationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove) Bidsandsignallevelspertimeblockforcurrentevents

1c. Theutilityprogramoperatoradds,modifiesanddeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheaggregatoroptsoutoftheDRprogram.Atanytime,theaggregatororthe aggregatoractingasfacilitymanagercanoptoutoftheDRprogramonthe DRAS.Whenthereisanoptoutcondition,DReventsarenotpropagatedtothe DRASClient.Theoptoutcanbeeitherfortheentireprogramorasingleevent. 1e. TheaggregatoradjustsstandingbidintheDRAS. 1f. Theutilityprogramoperatorand/ortheaggregatorreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientcommunicationsfailure.

D.2.3 Capacity Bidding Program (CBP)


TheCapacityBiddingProgram(CBP)isofferedbyPG&E.PG&Eswebsite, http://www.pge.com/mybusiness/energysavingsrebates/demandresponse/cbp/,provides thefollowingdescriptionofthisprogram:

APD23

TheCapacityBiddingProgram(ECBP)isamandatoryprogramthatpaysyoua monthlyincentivetoreduceyourloadtoapredeterminedamountwhenanelectric resourcegenerationfacilityreachesorexceedsheatratesof15,000BTU/kWh.ECBP operatesseasonallyfromMay1toOctober31. HowItWorks Toparticipateintheprogram,youmustsimplyidentifywhichofthetwooptionbest suitesyouandyourbusinesslineDayAheadorDayOfprogramhoursare11:00 a.m.to7:00p.m.,MondaythroughFridayexcludingPacificGasandElectric Companyholidaysandweekends. DayAheadCurtailment

Maximumofoneeventperday Willnotexceed24eventspermonth Noticeswillbeissuedby3:00p.m.onthebusinessdaybeforetheoperationday.

Directly-Enrolled Customer in Day-Ahead Option

Product 1-4 2-6 4-8

May $0.00/kW $0.00/kW $0.00/kW

June $2.97/kW $2.97/kW $2.97/kW

July $12.48/kW $12.48/kW $12.48/kW

August $17.26/kW $17.26/kW $17.26/kW

September $10.64/kW $10.64/kW $10.64/kW

October $0.00/kW $0.00/kW $0.00/kW

Aggregators in Day-Ahead Option

Product 1-4 2-6 4-8

May $0.00/kW $0.00/kW $0.00/kW

June $3.71/kW $3.71/kW $3.71/kW

July $15.60/kW $15.60/kW $15.60/kW

August $21.57/kW $21.57/kW $21.57/kW

September $13.30/kW $13.30/kW $13.30/kW

October $0.00/kW $0.00/kW $0.00/kW

DayOfCurtailment Maximumofoneeventperday Willnotexceed24eventspermonth Notifiescustomer30minutesbeforetheCAISOHourAheadMarketcloses (about3beforetheoperationeventhourstarts)

APD24


Aggregators in Day-Of Option
Product 1-4 2-6 4-8 May $0.00/kW $0.00/kW $0.00/kW June $3.42/kW $3.42/kW $3.42/kW July $14.35/kW $14.35/kW $14.35/kW August $19.85/kW $19.85/kW $19.85/kW September $12.24/kW $12.24/kW $12.24/kW October $0.00/kW $0.00/kW $0.00/kW

Aggregators in Day-Of Option

Product 1-4 2-6 4-8

May $0.00/kW $0.00/kW $0.00/kW

June $4.27/kW $4.27/kW $4.27/kW

July $17.94/kW $17.94/kW $17.94/kW

August $24.81/kW $24.81/kW $24.81/kW

September $15.30/kW $15.30/kW $15.30/kW

October $0.00/kW $0.00/kW $0.00/kW

Incentives Incentivesandpenaltieswilldependontheoptionthatiselected.Fordirectlyenrolled customers,incentivewillbebasedoncapacitynominationforeachmonthandenergy incentivesduringeventdays,andwillreflectthedifferencebetweendirectlyenrolled customerspecificenergybaselinelevelandenergyconsumedduringeventwith respectstonomination. D.2.3.1 CBP Directly to Facilities ThefollowingsetofusecasesconcernCBPprogramswhichareenacteddirectlywith participantfacilities.TheusecasediagramcanbeseeninFiguresD9andD10.

APD25

FigureD9CBPProgramConfiguration

APD26

Figure D10. CBP Direct to Facility D.2.3.1.1 CBP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theDBPDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsuptheDBPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheDBPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheDBPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: o o Programdefinition Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping Utilityassignedaccountnumberusedforsettlement

APD27

Customeridentification Customerpassword Geographiclocation Gridlocation

3a. ThefacilitymanagerconfiguresthefacilitysEMCSandnetworkforDR,possibly inconjunctionwiththeEMCSvendorandITstaff.Thiscouldinclude programmingtheEMCStorespondtoDReventsandshedorshiftloads appropriately.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3b.ThefacilitymanagerconfigurestheDRASClients,possiblyinconjunctionwith thetechnicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeFacilitiessystemsthatareresponsibleformanagingthe loads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. ThefacilitymanagersetsthestandingbidintheDRAS.Thisisthebidthatwill beautomaticallyplacedbytheDRASwhenarequestforbidscomesfromthe Utility.Itincludesthefollowing: Loadreductionbidspertimeblock(priceandloadamount) 3d.ThefacilitymanagerconfigurestheDRprogramparametersandtheDRAS ClientconnectionintheDRAS.Thisstepestablishestheconnectionbetweenthe DRASClientandtheDRAS.Typicallythisincludesthefollowingtypesof information: IdentificationandpasswordoftheCustomerparticipatingintheprogram Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.

APD28

D.2.3.1.2 CBP Execution

CBPincludesabiddingprocess,butunlikeDBPtherequestforbidsarenotlinked directlytothesheddingevents.Thebiddingprocessandthesheddingprocessaretwo distinctsetsofsteps.BecauseofthisdecouplingitisunlikelythattheDRASwouldplay ausefulroleinautomatingthebiddingprocess,butitisstilldocumentedherefor completeness. Thebiddingprocessincludesthefollowingsteps: 1. TheutilityprogramoperatorcreatestheCBPBiddingeventintheUtility InformationSystem.InthisstepaprogramoperatorschedulestheCBPBidding eventintheUtilityInformationSystem.Thedetailsofthisprocessarebeyond thescopeofthisdocument. 2. TheutilityprogramnotifiergetstheCBPbiddingeventinformationfromthe UtilityInformationSystemandinitiatestheCBPRequestforbidsintheDRAS. TheinformationsenttotheDRASbytheutilityprogramnotifiersubsystem includesthefollowinginformation: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers) RequestForBids(RFB)issuedateandtime RFBclosetime Priceofferedforloadreductionpertimeblock

3. TheDRASprogramnotifiersendstherequestforbidtothefacilitymanager. Thisnotificationtypicallycomesintheformofanemail,phonecallorpage. 4. ThefacilitymanageradjustsorcancelstheircurrentbidintheDRAS.Thisisan optionalstepandallowstheManagertoadjusttheirbidforthatparticularevent. Ifthisstepisnotperformed,theDRASwillsubmitthestandingbidafterapre setperiodoftime. 5. Aftertheprebidtimelimithasexpired,theBiddingProxyintheDRASsetsthe currentbidintheUtilityInformationSystem.TheinformationsentbytheDRAS includesthefollowing: Customeraccountnumber Loadreductionbidspertimeblock

Thesheddingprocessincludesthefollowingsteps: 1. TheutilityprogramoperatorcreatestheCBPShedeventintheUtility InformationSystem.InthisstepaprogramoperatorschedulestheCBPShed

APD29

eventintheUtilityInformationSystem.Thedetailsofthisprocessarebeyond thescopeofthisdocument. 2. TheutilityprogramnotifiergetstheacceptedbidsfromtheUtilityInformation SystemandinitiatestheCBShedintheDRAS.Theacceptedbidsformthesetof participantsthattheDRASwillsendCBshedorshifteventsto.Theinformation concerningacceptedbidsincludes: Customerlist(accountnumber) Acceptorreject Loadreductionbidspertimeblock(forverification)

3. TheDRASprogramnotifiersendstheacceptancenotificationtothefacility manager.Themanagerisnotifiedofanacceptedbidviaphone,email,orpage. 4. TheeventnotifierintheDRASsendstheCBeventinformationtoalltheDRAS Clientswhosebidswereaccepted.TheDBPeventinformationsenttotheDRAS Clientsincludesthefollowinginformation: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

5. TheDRASEventClientforthefacilitysendstheshedorshiftinformationtothe EMCSwhichinturncausesloadstobeshedorshiftinrelatedfacilities.Howthis processisdoneisbeyondthescopeofthisdocument. 6. TheDRASFeedbackClientfortheparticipantfacilitysendsthesystemload statusinformationtotheDRAS.Thisisafeedbackmechanismthatisusedto recordhowthefacilityrespondedtotheDRevent.Itincludesthefollowing information: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

APD30

7. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyond thescopeofthisdocument.


D.2.3.1.3 CBP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheDBP program.UnliketheConfigurationandExecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs Bidsandsignallevelspertimeblockforcurrentevents(forallparticipants, indivuallyandgroupedtogether)

1b.Thefacilitymanagerchecksstatus.Thefacilitymanagercangetthefollowing statusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove) Bidsandsignallevelspertimeblockforcurrentevents

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.ThefacilitymanageroptsoutoftheDRprogram.Atanytime,thefacility managercanoptoutoftheDRprogramontheDRAS.Whenthereisanoptout condition,DReventsarenotpropagatedtotheDRASClient.Theoptoutcanbe eitherfortheentireprogramorasingleevent. 1e. ThefacilitymanageradjuststheirstandingbidintheDRAS.


APD31

1f. Theutilityprogramoperatorand/orthefacilitymanagerreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientcommunicationsfailure.

D.2.3.2 CBP via Aggregators ThefollowingsetofusecasesconcernCBPprogramswhichareenactedwith aggregators.Theusecasediagrambasedondifferenceconfigurationscanbeseenin FiguresD10andD11.

Figure D11. CBP Direct to Facility

APD32

D.2.3.2.1 CBP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theDBPDRprogramandinvolvesthefollowingactions: 1. TheutilityprogramoperatorsetsuptheDBPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheDBPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheDBPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification Customerpassword Geographiclocation Gridlocation

3a. TheaggregatorconfigurestheirsystemsforDR.Thedetailsofthisprocessare beyondthescopeofthisdocument. 3b.TheaggregatorconfigurestheDRASClients,possiblyinconjunctionwiththe technicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeaggregatorsystemsthatareresponsibleformanagingthe loads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. TheaggregatorsetsastandingbidintheDRAS.Thisisthebidthatwillbe automaticallyplacedbytheDRASwhenarequestforbidscomesfromthe utility.Itincludesthefollowing: Loadreductionbidspertimeblock(priceandloadamount) 3d.TheaggregatorconfiguresDRprogramparametersandDRASClientconnection intheDRAS.ThisstepestablishestheconnectionbetweentheDRASClientand theDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o DRASIPaddress identification
APD33

o o o

password IPconnectioninformation pollingfrequencyifapollingDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.


D.2.3.2.2 CBP Execution

CBPincludesabiddingprocess,butunlikeDBPtherequestforbidsarenotlinked directlytothesheddingevents.Thereforethebiddingprocessandthesheddingprocess aretwodistinctsetsofsteps.BecauseofthisdecouplingitisunlikelythattheDRAS wouldplayausefulroleinautomatingthebiddingprocess,butitisdocumentedhere forcompleteness. Thebiddingprocessincludesthefollowingsteps: 1. TheutilityprogramoperatorcreatestheCBPBiddingeventintheUtility InformationSystem.InthisstepaprogramoperatorschedulesaCBPBidding eventintheUtilityInformationSystem.Thedetailsofthisprocessarebeyond thescopeofthisdocument. 2. TheutilityprogramnotifiergetstheCBPbiddingeventinformationfromthe UtilityInformationSystemandinitiatestheCBPRequestforbidsintheDRAS. TheinformationsenttotheDRASbytheutilityprogramnotifiersubsystem includesthefollowinginformation: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers) RequestForBids(RFB)issuedateandtime RFBclosetime Priceofferedforloadreductionpertimeblock

3. TheDRASprogramnotifiersendstherequestforbidtotheaggregator.This notificationtypicallycomesintheformofanemail,phonecallorpage. 4. TheaggregatoradjustsorcancelsthecurrentbidintheDRAS.Thisisanoptional stepandallowstheManagertoadjusttheirbidforthatparticularevent.Ifthis

APD34

stepisnotperformedthentheDRASwillsubmitthestandingbidaftersomepre setperiodoftime. 5. Aftertheprebidtimelimithasexpired,theBiddingProxyintheDRASsetsthe currentbidintheUtilityInformationSystem.TheinformationsentbytheDRAS includesthefollowing: Customeraccountnumber Loadreductionbidspertimeblock

Thesheddingprocessincludesthefollowingsteps: 1. TheutilityprogramoperatorcreatestheCBPShedeventintheUtility InformationSystem.InthisstepaprogramoperatorschedulesaCBPShedevent intheUtilityInformationSystem.Thedetailsofthisprocessarebeyondthe scopeofthisdocument. 2. TheutilityprogramnotifiergetsacceptedbidsfromtheUtilityInformation SystemandinitiatestheCBPShedintheDRAS.Theacceptedbidsformthesetof participantsthattheDRASwillsendtheCBshedorshifteventsto.The informationconcerningacceptedbidsinclude: Customerlist(accountnumber) Acceptorreject Loadreductionbidspertimeblock(forverification)

3. TheDRASprogramnotifiersendstheacceptancenotificationtotheaggregator.The aggregatoroperatorisnotifiedofanacceptedbidviaphone,email,orpage. 4. TheeventnotifierintheDRASsendstheCBPeventinformationtoallDRAS Clientswhosebidswereaccepted.TheCBPeventinformationsenttotheDRAS Clientsincludes: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

5. TheDRASEventClientforthefacilitysendsshedorshiftinformationtothe aggregatorssystemwhichinturncausestheaggregatortoshedorshiftloadsin variousfacilities.Howthisprocessisdoneisbeyondthescopeofthisdocument. 6. TheDRASFeedbackClientintheaggregatorssystemsendsthesystemload statustotheDRAS.Thisisafeedbackmechanismthatisusedtorecordhowthe facilityrespondedtotheDRevent.Itincludesthefollowinginformation:


APD35

Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

7. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Thedetailsofthisprocessare beyondthescopeofthisdocument.


D.2.3.2.3 CBP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheDBP program.UnliketheConfigurationandExecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs Bidsandsignallevelspertimeblockforcurrentevents(forallparticipants, indivuallyandgroupedtogether)

1b.Theaggregatorchecksstatus.Theaggregatorcangetthefollowingstatus informationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove) Bidsandsignallevelspertimeblockforcurrentevents

APD36

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheaggregatoroptsoutoftheDRprogram.Atanytime,theaggregatororthe aggregatoractingasfacilitymanagercanoptoutoftheDRprogramonthe DRAS.Whenthereisanoptoutcondition,DReventsarenotpropagatedtothe DRASClient.Theoptoutcanbeeitherfortheentireprogramorasingleevent. 1e. TheaggregatoradjuststheirstandingbidintheDRAS. 1f. Theutilityprogramoperatorand/ortheaggregatorreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutility,theDRASwillsendamessageto therespectiveoperatorsviaemail,voiceorpager.Notethatthisalarming interfacedoesnotcoverexceptionconditionsthatarepartoftheDRASoperation andmanagedbytheDRASoperator,whichisoutsidethescopeofthis document.Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientcommunicationsfailure.

D.2.4 Base Interruptible Program (BIP)


TheBaseInterruptibleProgram(BIP)isofferedbyPG&E.PG&Eswebsite, http://www.pge.com/mybusiness/energysavingsrebates/demandresponse/baseinterrupti ble/,providesthefollowingdescriptionofthisprogram: TheBaseInterruptibleProgram,orEBIP,isaprogramthatpaystoreduceyour electricityconsumptiontoapredeterminedamountwhentheCalifornia IndependentSystemOperator(CAISO)issuesaloadcurtailmentnoticeorinthe eventofalocalreliabilityemergency.Therearetwoseparateoptionsfor participation.Themandatoryoption(optionA)givesparticipatingcustomersa monthlypaymentforcommittingtoreduceelectricitydemandtoapredetermined pointwhencalledupon.Thevoluntaryoption(optionB)payscustomersafixed amountperkilowattreducedduringacurtailmentevent. HowItWorks Toparticipateintheprogram,participantsmustidentifyadesignatedload,orfirm servicelevel,belowyouraveragepeakdemand.Toparticipate,youmustsetafirm servicelevelatleast15percentofyourhighestmonthlymaximumloadwitha minimumdesignatedloadof100kW.Newparticipantsmustelectoneoftwo availableoptions. OptionA: Givesthecustomera30minutenotificationpriortomandatorycurtailmentof loadexceedingtheestablishedfirmservicelevel.

APD37

MonthlyparticipationincentivesaredeterminedbythePotentialLoad Reductionascalculatedbythedifferencebetweenthecustomersaverage monthlyseasonaldemandandthedesignatedfirmservicelevel. Monthlyincentivesaredeterminedbythefollowingtable:


Potential Load reduction 500 kW and below 501 kW1,000 kW 1,001 kW and above Monthly Incentive $8.00 per kW $8.50 per kW $9.00 per kW

Failuretoreduceloadsduringaneventwillresultina$6.00chargeperkilowatt hourforenergyuseoverthefirmservicelevel. OptionB: Givesthecustomerafourhournotificationand$0.60perkWhincentivefora qualifyingloadreductionduringthecurtailmentevent. Toqualifyfortheincentive,customersmustreduceloadtowithin15%ofthe designatedfirmservicelevel. Thereisnopenaltyforfailingtoreduceloadsduringanevent.

Toparticipate,youmustcommittocurtail:Atleast15percentofyouraverage monthlyloadoraminimumof100kW,whicheverisgreater EBIPcurtailmenteventsarelimitedto: OptionA:Amaximumofoneeventperdayandfourhoursperevent.Theprogram willnotexceed10eventspermonth,or120hourspercalendaryear. OptionB:Therearenoeventlimitsonthisvoluntaryoption. Aggregators AcustomermayenrolldirectlywithPacificGasandElectricCompanyorwitha thirdpartyaggregator.Anaggregatorisanentityappointedbyacustomer,toacton behalfofthecustomerwithrespecttoallaspectsoftheprogram,includingreceiptof notices,receiptofincentivepayments,andpaymentofpenalties. D.2.4.1 BIP Directly to Facilities ThefollowingsetofusecasesconcernBIPprogramswhichareenacteddirectlywith participantfacilities.TheusecasediagramcanbeseeninFigureD12.

APD38

Figure D12. BIP Direct to Facility D.2.4.1.1 BIP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theBIPDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsuptheBIPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheBIPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheBIPintheDRASforthefacility.This includesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement

APD39

Customeridentification Customerpassword Geographiclocation Gridlocation

3a. ThefacilitymanagerconfiguresthefacilitysEMCSandnetworkforDR,possibly inconjunctionwiththeEMCSvendorandITstaff.Thiscouldinclude programmingtheEMCStorespondtoDReventsandshedorshiftloads appropriately.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3b.ThefacilitymanagerconfiguresDRASClients,possiblyinconjunctionwiththe technicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeFacilityssystemsthatareresponsibleformanagingthe loads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. ThefacilitymanagerconfigurestheDRprogramparametersandDRASClient connectionintheDRAS.ThisstepestablishestheconnectionbetweentheDRAS ClientandtheDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram. Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.


D.2.4.1.2 BIP Execution

ThesetofactionsneededtoexecuteBIPeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatestheBIPeventintheUtilityInformation System.InthisstepaprogramoperatorschedulesaBIPeventintheUtility InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document.

APD40

2. TheutilityprogramnotifiergetstheBIPeventinformationfromtheUtility InformationSystemandinitiatestheBIPeventintheDRAS.Theinformation senttotheDRASbytheutilityprogramnotifiersubsystemincludesthe followinginformation: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3. TheeventnotifierintheDRASsendstheBIPeventinformationtoallDRAS ClientsinBIPprogram.TheBIPeventinformationsenttotheDRASClients includesthefollowing: UtilityeventinfoforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

4. TheDRASEventClientforthefacilitysendsshedorshiftinformationtothe EMCSwhichinturnshedsloads.Howthisprocessisdoneisbeyondthescope ofthisdocument. 5. TheDRASFeedbackClientforthefacilitysendsthesystemloadstatustothe DRAS.Thisisafeedbackmechanismthatisusedtorecordhowthefacility respondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

6. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyond thescopeofthisdocument.

APD41

D.2.4.1.3 BIP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheBIP program.UnliketheConfigurationandExecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs 1b.Thefacilitymanagerchecksthestatus.Theutilityprogramoperatorcangetthe followingstatusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.ThefacilitymanageroptsoutoftheDRprogram.Atanytime,thefacility managercanoptoutoftheDRprogramontheDRAS.Whenthereisanoptout condition,DReventsarenotpropagatedtotheDRASClient.Theoptoutcanbe eitherfortheentireprogramorasingleevent. 1e. Theutilityprogramoperatorand/orthefacilitymanagerreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude:

APD42

DRASClientcommunicationsfailure.

D.2.4.2 BIP via Third Party Aggregators ThefollowingusecasesenvisionhowanaggregatormightplayarolewiththeDRAS forBIP.ThisisdepictedinFigureD13.Itisverysimilartothedirecttothefacilityuse case.


BIP via Aggregator
DRAS Aggregator Information System Facility

Utility
Utility Information System
Set up BIP Program Program Operator Get Operator Reports Configure BIP Program

Configure DRAS Client Connection Configure Facility for Auto DR Check status, get reports Aggregator Operator BIP opt out

DRAS Client
Configure DRAS Client

Create BIP Event Initiate BIP Event Event Notifier Program Notifier Get BIP Event Info Set Load Status Event Client Perform BIP Settlement Feedback Client Program Settlement Send Shed Info to DRAS Client

Shed Loads

Measure Usage Get Load Status

Configuration 1. Utility Program Operator sets up BIP program in Utility Information System (including signing up aggregator) 2. Utility Program Operator configures BIP in DRAS for the aggregator. (create client and associate client with BIP grogram). 3a. Aggregator Operator configures Facilities (possibly EMCS and network) for DR, possibly with EMCS vendors and IT staff. 3b. Aggregator Operator configures DRAS Clients, possibly with Technical Coordinator. 3c. Aggregator Operator configures DRAS Client connection in DRAS.

BIP Execution 1. Utility Program Operator creates BIP Event in Utility Information System . 2. Utility Program Notifier gets BIP event information from Head End. (date and time) and initiates BIP event in DRAS 3. Event Notifier in DRAS sends shed info to DRAS clients the Aggregator Information System. 5. DRAS Event Client notifies other Aggregator systems (unknown and out of scope of this discussion) which in turn causes Aggregator to shed loads in various facilities. 6. DRAS Feedback Client in Aggregator Information System sets load status in DRAS (which facilities shed, facility usage information) 7. Utility Program Settlement of the Utility measures usage in Facilities and performs settlement in Utility Information System.

Maintenance 1a. Utility Program Operator gets operation reports. (communications, opt out, who got shed, etc.) 1b. Aggregator Operatorchecks status (program and communication), get reports (communication) 1c. Utility Program Operator adds, modifies, and deletes facilities participating in the program. 1d. Aggregator opts out of BIP program. 1e. Utility Program Operator and/or Aggregator Operator receives exception notification from DRAS in case of error. (Not shown in diagram)

Figure D13. BIP via Aggregator D.2.4.2.1 BIP Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theBIPDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsuptheBIPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheBIPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheBIPintheDRASforthefacility.This includesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition

APD43

o o

Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification Customerpassword Geographiclocation Gridlocation

3a. TheaggregatorconfiguresthefacilitysEMCSandnetworkforDR,possiblyin conjunctionwiththeEMCSvendorandITstaff.Thedetailsofthisprocessare beyondthescopeofthisdocument. 3b.TheaggregatorconfiguresDRASClients,possiblyinconjunctionwiththe technicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeaggregatorssystemsthatareresponsibleformanaging theloads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. TheaggregatorconfigurestheDRprogramparametersandtheDRASClient connectionintheDRAS.ThisstepestablishestheconnectionbetweentheDRAS ClientandtheDRAS.Typicallythisincludesthefollowingtypesofinformation: Identificationandpasswordofthecustomerparticipatingintheprogram Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.


D.2.4.2.2 BIP Execution

ThesetofactionstoexecuteBIPeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatestheBIPeventintheUtilityInformation System.InthisstepaprogramoperatorschedulesaBIPeventintheUtility

APD44

InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetstheBIPeventinformationfromtheUtility InformationSystemandinitiatestheBIPeventintheDRAS.Theinformation senttotheDRASbytheutilityprogramnotifiersubsystemincludesthe following: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3. TheeventnotifierintheDRASsendstheBIPeventinformationtothe appropriateDRASClientsinBIPprogram.TheBIPeventinformationsenttothe DRASClientsincludesthefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

4. TheDRASEventClientforthefacilitysendsshedorshiftinformationtothe aggregatorssystemwhichinturncausestheaggregatortoshedorshiftloads withinfacilities.Howthisprocessisdoneisbeyondthescopeofthisdocument. 5. TheDRASFeedbackClientintheaggregatorssystemsendsthesystemload statusinformationtotheDRAS.Thisisafeedbackmechanismthatisusedto recordhowthefacilityrespondedtotheDRevent.Itincludesthefollowing information: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

APD45

6. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyond thescopeofthisdocument.


D.2.4.2.3 BIP Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheBIP program.Unliketheconfigurationandexecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs 1b.Thefacilitymanagerchecksstatus.Thefacilitymanagercangetthefollowing statusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheaggregatoroptsoutoftheDRprogram.Atanytime,theaggregatororthe aggregatoractingasfacilitymanagercanoptoutoftheDRprogramonthe DRAS.Whenthereisanoptoutcondition,DReventsarenotpropagatedtothe DRASClient.Theoptoutcanbeeitherfortheentireprogramorasingleevent. 1e. Theutilityprogramoperatorand/ortheaggregatorreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe

APD46

respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientcommunicationsfailure.

D.2.5 Peak Day Credit (PDC)


PeakDayCredit(PDC)isaDRprogramofferedbySanDiegoGas&Electric(SDG&E). ThefollowingisabriefdescriptionfromtheSDG&Ewebsite, http://www.sdge.com/peakday2020/: WhatisthePeakDayCreditprogram? Participatingbusinessescanreceiveacreditontheirbillwhentheyreducetheir electricusageanaverageof1020%duringonpeakhourswhengivenoneday advancenotice.PeakDayispartofSDG&EsDemandResponseprogram portfolioacomponentofSDG&Eslongtermresourceplan,andoneoftheways SDG&Eishelpingtheregionaleconomy. Howdoestheprogramwork? Youwillreceivenotificationthedaybeforeapeakenergydayiscalled.Onapeak energyday,youwillbeaskedtoreduceyourelectricityconsumptionbyanaverage of1020%from11a.m.to6p.m.TheprogramrunsthroughSeptember30. Howisapeakenergydaydetermined? Apeakenergydaymaybecalledoneoftwoways:1)whenboththenextday forecastedtemperatureatMiramarMarineCorpsAirStationis84degreesorhigher, andthecurrentdayslocalelectricsystemloadreaches3,620megawatts;2)dueto extremeconditionssuchasanalertcalledbytheCaliforniaIndependentSystem Operator. D.2.5.1 PDC Directly to Facilities ThefollowingsetofusecasesconcernPDCprogramswhichareenacteddirectlywith participantfacilities.TheusecasediagramcanbeseeninFigureD14.

APD47

Figure D14. PDC Direct to Facility D.2.5.1.1 PDC Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein thePDCDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsupthePDCprogramintheInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateinthePDCprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfiguresthePDCintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification

APD48

Customerpassword Geographiclocation Gridlocation

3a. ThefacilitymanagerconfiguresthefacilitysEMCSandnetworkforDR,possibly inconjunctionwiththeEMCSvendorandITstaff.Thiscouldinclude programmingtheEMCStorespondtoDReventsandshedorshiftloads appropriately.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3b.ThefacilitymanagerconfigurestheDRASClients,possiblyinconjunctionwith thetechnicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeFacilitiessystemsthatareresponsibleformanagingthe loads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. ThefacilitymanagerconfigurestheDRprogramparametersandDRASClient connectionintheDRAS.ThisstepestablishestheconnectionbetweentheDRAS ClientandtheDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram. Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending onhowthisstepissubsequentlyimplementedinafutureOpenADRstandards,this maybeperformedintheDRASClientandnotintheDRAS.


D.2.5.1.2 PDC Execution

ThesetofactionstoexecutePDCeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatesthePDCeventintheUtilityInformation System.InthisstepaprogramoperatorschedulesaPDCeventintheUtility InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetsthePDCeventinformationfromtheUtility InformationSystemandinitiatesPDCeventintheDRAS.Theinformationsent

APD49

totheDRASbytheutilityprogramnotifiersubsystemincludesthefollowing information: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3. TheeventnotifierintheDRASsendsthePDCeventinformationtothe appropriateDRASClientsinPDCprogram.ThePDCeventinformationsentto theDRASClientsincludesthefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

4. TheDRASEventClientforthefacilitysendsshedorshiftinformationtothe EMCSwhichinturnshedsloads.Howthisprocessisdoneisbeyondthescope ofthisdocument. 5. TheDRASFeedbackClientforthefacilitysendsthesystemloadstatustothe DRAS.ThisisafeedbackmechanismthatisusedtorecordhowtheFacility respondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

6. TheutilityprogramsettlementmeasuresusageinFacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyond thescopeofthisdocument.


D.2.5.1.3 PDC Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintainthePDC program.Unliketheconfigurationandexecutionscenariosthissetofactionsarelessa

APD50

prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs 1b.Thefacilitymanagerchecksstatus.Thefacilitymanagercangetthefollowing statusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifiesanddeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.ThefacilitymanageroptsoutoftheDRprogram.Atanytime,thefacility managercanoptoutoftheDRprogramontheDRAS.Whenthereisanoptout condition,DReventsarenotpropagatedtotheDRASClient.Theoptoutcanbe eitherfortheentireprogramorasingleevent. 1e. Theutilityprogramoperatorand/orthefacilitymanagerreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientcommunicationsfailure.

APD51

D.2.5.2 PDC via Third Party Aggregators ThefollowingusecasesenvisionhowanaggregatormightplayarolewiththeDRAS forPDC.ThisisdepictedinFigureD15.Itisverysimilartothedirecttofacilityusecase.

Figure D15. PDC via Aggregator

D.2.5.2.1 PDC Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein thePDCDRprogramandinvolvesthefollowingactions. 1. TheutilityprogramoperatorsetsupthePDCprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateinthePDCprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfiguresthePDCintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition

APD52

o o

Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification Customerpassword Geographiclocation Gridlocation

3a. TheaggregatorconfiguresthefacilitysEMCSandnetworkforDR,possiblyin conjunctionwiththeEMCSvendorandITstaff.Thedetailsofthisprocessare beyondthescopeofthisdocument. 3b.TheaggregatorconfigurestheDRASClients,possiblyinconjunctionwiththe technicalcoordinator.DRASClientsmaytakemanyforms,bothintermsof hardwareandsoftware.ThisstepconfigurestheDRASClientsothatitcan communicatewiththeaggregatorssystemsthatareresponsibleformanaging theloads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. TheaggregatorconfiguresDRprogramparametersandDRASClientconnection intheDRAS.ThisstepestablishestheconnectionbetweentheDRASClientand theDRAS.Typicallythisincludesthefollowingtypesofinformation: IdentificationandpasswordoftheCustomerparticipatingintheprogram. Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters. o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient.

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters. Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.


D.2.5.2.2 PDC Execution

ThesetofactionstoexecutePDCeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatesthePDCeventintheUtilityInformation System.InthisstepaprogramoperatorschedulesthePDCeventintheUtility

APD53

InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetsthePDCeventinformationfromtheUtility InformationSystemandinitiatesthePDCeventintheDRAS.Theinformation senttotheDRASbytheutilityprogramnotifiersubsystemincludesthe followinginformation: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3. TheeventnotifierintheDRASsendsPDCeventinformationtoallDRASClients inPDCprogram.ThePDCeventinformationsenttotheDRASClientsincludes thefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

4. TheDRASEventClientinthefacilitysendsshedorshiftinformationto aggregatorssystemwhichinturncausesaggregatortoshedorshiftloadsin variousfacilities.Howthisprocessisdoneisbeyondthescopeofthisdocument. 5. TheDRASFeedbackClientintheaggregatorssystemsendsthesystemload statustotheDRAS.Thisisafeedbackmechanismthatisusedtorecordhowthe facilityrespondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

6. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyond thescopeofthisdocument.

APD54

D.2.5.2.3 PDC Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintainthePDC program.Unliketheconfigurationandexecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs 1b.Thefacilitymanagerchecksstatus.Theutilityprogramoperatorcangetthe followingstatusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheaggregatoroptsoutoftheDRprogram.Atanytime,theaggregatororthe aggregatoractingasfacilitymanagercanoptoutoftheDRprogramonthe DRAS.Whenthereisanoptoutcondition,DReventsarenotpropagatedtothe DRASClient.Theoptoutcanbeeitherfortheentireprogramorasingleevent. 1e. Theutilityprogramoperatorand/ortheaggregatorreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude:

APD55

DRASClientcommunicationsfailure.

D.2.6 DR Programs with Programmable Communicating Thermostat (PCT)


ProgrammableCommunicatingThermostats(PCTs)arecurrentlybeingdevelopedthat inthefuturemayallowsmallcommercialandresidentialfacilitiestoparticipateinDR programs.OneofthePCTcommunicationmodescurrentlybeingdevelopedusesa broadcastwirelessnetworksuchassubcarrierFM.Suchanetworkwouldallowlarge numbersofPCTstosimultaneouslyreceiveasinglebroadcasttransmissionof information.Uponreceivingtheinformation,thePCTcantakeappropriateactionby changingthesetpointoftheHVACunitthatitiscontrolling,thusprovidingameansto shedorshiftloads. TheusecaseforthePCTscenarioincludesaPCTNetworkOperatingCenter(NOC)that isresponsibleformanagingallbroadcasttransmissionstothePCT.TheDRASwill interfacetotheNOCtofacilitatecommunicationswiththePCTmuchlikeitdoesinthe previoususecases.FromtheDRASpointofview,thePCTsdonotrepresentaradical departurefromotherparticipantsitesordevices. Thissectionpresentsaproposedarchitectureandusecaseforcommunicatingwith PCTsinDRprograms.TheusecasediagramisdepictedinFigureD16.

Figure D16. PCT Shed Event

APD56

D.2.6.1.1 PCT DR Configuration

Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein thePCTDRprogramandinvolvesthefollowingactions: 1. TheutilityprogramoperatorsetsupthePCTprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateinthePCTprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfiguresthePCTDRintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowthefacilityoperatorto accesstheDRASandsetuptheirDRASClientsothatitmaycommunicatewith theDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement Customeridentification Customerpassword Geographiclocation Gridlocation Groupingparameter

3a. TheNetworkManagerconfigurestheNOCfortheDRprogram.Thismay includegroupingPCTstomatchthegroupingparameterssetupbytheutility DRprogram.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3b.TheNetworkManagerconfigurestheDRASClients,possiblyinconjunction withthetechnicalcoordinator.DRASClientsmaytakemanyforms,bothin termsofhardwareandsoftware.ThisstepconfigurestheDRASClientsothatit cancommunicatewiththeFacilitiessystemsthatareresponsibleformanaging theloads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. TheNetworkManagerconfigurestheDRprogramparametersandtheDRAS ClientconnectionintheDRAS.Thisstepestablishestheconnectionbetweenthe DRASClientandtheDRAS.Typicallythisincludesthefollowingtypesof information: IdentificationandpasswordoftheCustomerparticipatingintheprogram Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o o DRASIPaddress identification password
APD57

o o

IPconnectioninformation pollingfrequencyifapollingDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS.


D.2.6.1.2 PCT DR Execution

ThesetofactionstoexecutePCTeventsincludethefollowingsteps: 1. TheutilityprogramoperatorcreatesthePCTDReventintheUtilityInformation System.InthisstepaprogramoperatorschedulesaPCTeventintheUtility InformationSystem.Thedetailsofthisprocessarebeyondthescopeofthis document. 2. TheutilityprogramnotifiergetsthePCTDReventinformationfromtheUtility InformationSystemandinitiatesthePCTDReventintheDRAS.The informationsenttotheDRASbytheutilityprogramnotifiersubsystemincludes thefollowing: Programtype Dateandtimeoftheevent Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3. TheeventnotifierintheDRASsendsthePCTDReventinformationtothe appropriateDRASClientsinthePCTDRprogram.ThePCTeventinformation senttotheDRASClientsincludesthefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvancenoticeistobesent)

4. TheDRASEventClientintheNOCsendseventinformationtothePCTSignal BroadcasterwhichinturnbroadcaststheeventinformationtothePCTs.How thisprocessisdoneisbeyondthescopeofthisdocument.


APD58

5. TheDRASFeedbackClientintheNOCsendsthesystemloadstatustothe DRAS.Thisisafeedbackmechanismthatisusedtorecordhowthefacility respondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

6. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Howthisprocessisdoneisbeyond thescopeofthisdocument.


D.2.6.1.3 PCT DR Maintenance

ThisscenarioconsistsofasetofactionswhicharenecessarytomaintainthePCT program.Unliketheconfigurationandexecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs 1b.TheNetworkManagerchecksstatus.Theutilityprogramoperatorcangetthe followingstatusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs manualcontrollogs

Eventstatus(sameasabove)

APD59

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheNetworkManageroptsoutoftheDRprogram.Atanytime,theNetwork ManagercanoptoutoftheDRprogramontheDRAS.Whenthereisanoptout condition,DReventsarenotpropagatedtotheDRASClient.Theoptoutcanbe eitherfortheentireprogramorasingleevent. 1e. Theutilityprogramoperatorand/orNetworkManagerreceiveanexception notificationfromtheDRASincaseofanerror(thisisnotshowninthediagram). WhenanerrorconditionoccursintheDRASwhichmayrequiresomesortof actionbyeithertheparticipantortheutilitytheDRASwillsendamessagetothe respectiveoperatorsviaemail,voiceorpager.Notethatthisalarminginterface doesnotcoverexceptionconditionsthatarepartoftheDRASoperationand managedbytheDRASoperator,whichisoutsidethescopeofthisdocument. Thetypesofexceptionscoveredbythisinterfaceinclude: DRASClientcommunicationsfailure.

D.2.7 Generic Real-Time Pricing Based Programs (RTP)


SofartheusecasespresentedareeventbasedmeaningthataDReventisgeneratedthat ispropagatedtotheparticipants.Anotherusefulstreamofinformationthatmaybe usedtomanageDRprogramsisRealTimePricing(RTP).RTPissomewhatdifferent thananeventinthatitispotentiallyacontinuouslychangingquantitythatmaychange morefrequentlythanthenormalDRevents.Thismaybeacontinuoustariffandnota utilityprogramperse.Furthermoretherearetwomodesofoperationthatmayeffect howRTPinformationisusedtomanageparticipantloads: 1. RealtimepricesarepropagatedfromtheUtilitiestotheparticipantsviathe DRASandtheparticipantsthenusethisinformationtoshedorshiftloads. 2. RealtimepricesaresentbytheUtilitiestotheDRASwhichtheninturn generatesDReventsbaseduponsomeconfiguredbusinesslogicforaparticular participantorprogram.SincesimpleDReventsarepresumablyeasierforthe participantstodealwithintheirsheddinglogicthisalleviatestheneedforthe participantstodoanycomplicatedprogrammingtousetheRTPinformation. ClearlyanyusecasethatusesRTPinformationshouldsupportboththescenarioslisted above. ThefollowingusecasesshowhowRealTimePricingmaybeusedforDRprogramsin conjunctionwiththeDRAS.TheusecasediagramforthisscenarioisshowninFigure D17.

APD60

Figure D17. Generic Real-Time Pricing (RTP)

D.2.7.1 RTP Configuration Thisincludesenteringalltheinformationnecessaryfortheparticipanttoparticipatein theRTPDRprogramandinvolvesthefollowingactions: 1. TheutilityprogramoperatorsetsuptheRTPprogramintheUtilityInformation System.Thisincludessigningupparticipantsandenteringallrequired informationnecessaryfortheparticipanttoparticipateintheRTPprograminto theUIS.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 2. TheutilityprogramoperatorconfigurestheRTPintheDRASforthefacility. ThisincludesenteringinformationintotheDRAStoallowtheparticipant ManagertoaccesstheDRASandsetuptheirDRASClientsothatitmay communicatewiththeDRAS.Itincludesenteringthefollowinginformation: Programdefinition o o Eventlaunchingendpoint ProgramtoeventtoDRASClientsignalmapping

Utilityassignedaccountnumberusedforsettlement

APD61

Customeridentification Customerpassword Geographiclocation Gridlocation

3a. TheparticipantmanagerconfigurestheparticipantsitesEMCSand/ornetwork forDR,possiblyinconjunctionwiththeEMCSvendorandITstaff.Thiscould includeprogrammingtheEMCStorespondtoDReventsandshedorshiftloads appropriately.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3b.TheparticipantmanagerconfigurestheDRASClients,possiblyinconjunction withthetechnicalcoordinator.DRASClientsmaytakemanyforms,bothin termsofhardwareandsoftware.ThisstepconfigurestheDRASClientsothatit cancommunicatewiththeFacilityssystemsthatareresponsibleformanaging theloads.Thedetailsofthisprocessarebeyondthescopeofthisdocument. 3c. TheparticipantmanagerconfigurestheDRprogramparametersandDRAS ClientconnectionintheDRAS.Thisstepestablishestheconnectionbetweenthe DRASClientandtheDRAS.Typicallythisincludesthefollowingtypesof information: IdentificationandpasswordoftheCustomerparticipatingintheprogram Contactinformation,i.e.phonenumber,pager,email,etc. DRASClientcommunicationsparameters o o o o o DRASIPaddress identification password IPconnectioninformation pollingfrequencyifapollingDRASClient

OptionallyLoadreductionpotential(pertimeblockperlevel) Exceptionparameters Optoutdates

NotethatthisactioniscurrentlydepictedasoccurringintheDRAS,butdepending uponhowthisstepissubsequentlyimplementedinafutureOpenADRstandards, thismaybeperformedintheDRASClientandnotintheDRAS. 3d.TheparticipantmanagerconfigurestheRTPeventmappingintheDRAS.Thisis thelogicthatdetermineswhattypesofeventsaregeneratedinresponsetothe RTPinformationreceivedbytheDRAS.Notethattheparticipantsitemaynot receiveeventsatall,butmayprefertoreceivetheRTPinformation.Thisispart oftheconfigurationprocess.Alsonotethatthisconfigurationprocessmaybe performedbytheprogramoperatoroftheutility.

APD62

D.2.7.2 RTP Execution ThesetofactionstoexecuteRTPprogramsincludethefollowingsteps: 1. TheutilityprogramoperatorupdatestheRTPinformationintheUtility InformationSystem.Thismaybedoneautomaticallyandcouldbescheduledto occuratsomeregulartimeintervaloraspricinginformationchangesandneeds tobepropagatedtotheparticipantaspartoftheDRprogram.Thedetailsofhow thepricinginformationischangedarebeyondthescopeofthisdocument. 2. TheutilityprogramnotifiergetstheRTPinformationfromtheUtility InformationSystemandupdatesthepricinginformationintheDRAS.The informationsenttotheDRASbytheutilityprogramnotifiersubsystemincludes thefollowinginformation: Programtype RTPinformation DateandtimeoftheRTPinformation Dateandtimeissued Geographiclocation Customerlist(accountnumbers)

3a. TheeventnotifierintheDRAStakestheRTPinformationand,baseduponthe RTPeventmapping,generatesaneventandsendsittotheappropriateDRAS ClientsintheRTPprogram.Theeventinformationincludesthefollowing: UtilityeventinformationforIntelligentDRASClients o o o o Dateandtimeoftheevent Dateandtimeissued Geographiclocation(optional) Modeandpendingsignals

ModesignallevelsforSimpleDRASClients(e.g.normal,moderate,high) EventpendingsignalforSimpleDRASClients(e.g.yes/no,orsimple quantificationofhowfarinadvanceenoticeistobesent)

3b.Whenconfigured,theRTPnotifierintheDRASupdatestheRTPinformationin theappropriateDRASClients.TheRTPinformationincludesthefollowing: UtilityRTPinformationforIntelligentDRASClients o o o DateandtimeoftheRTP sDateandtimeissued Geographiclocation(optional)

4. Baseduponthepriceand/oreventinformationreceivedtheDRASEventClient fortheparticipantsitesendseventinformationtoallappropriateparticipantside

APD63

systemswhichresultsinloadsbeingshedorshifted.Thedetailsofthisprocess arebeyondthescopeofthisdocument. 5. TheDRASFeedbackClientfortheparticipantsitesendsthesystemloadstatusto theDRAS.Thisisafeedbackmechanismthatisusedtorecordhowthe participantsiterespondedtotheDRevent.Itincludesthefollowinginformation: Programidentifier Facilityidentifier Dateandtimeoftheevent(shedorshift) SheddatainkW/kWh Loadreductionenduses(HVAC,lighting,etc.) EventType(DayAheadorDayOf)

6. Theutilityprogramsettlementmeasuresusageinthefacilityandperforms settlementintheUtilityInformationSystem.Thedetailsofthisprocessare beyondthescopeofthisdocument. D.2.7.3 RTP Maintenance ThisscenarioconsistsofasetofactionswhicharenecessarytomaintaintheRTP program.Unliketheconfigurationandexecutionscenariosthissetofactionsarelessa prescribedsetofstepsandmoreasetofpossibleactionsthatmaybeperformedbythe variousrolesatunrelatedtimes. 1a. Theutilityprogramoperatorgetstheoperationreports.Theutilityprogram operatorcangetthefollowingstatusinformationfromtheDRASatanytime: Eventstatus(forallparticipants) o currentoutstandingevents Loadreductionpotentialbaseduponallcustomersinprogram (optional) FeedbackfromDRASClients(forthosethathaveoptionalfeedback) o eventlogs 1b.Theparticipantmanagerchecksthestatus.Theutilityprogramoperatorcanget thefollowingstatusinformationfromtheDRASatanytime: DRASClientcommunicationsstatus o o o o o o currentstatus lastcontact currentsignalslevels currentcustomermanualcontrollevels(optout) communicationlogs signallogs

APD64

manualcontrollogs

Eventstatus(sameasabove)

1c. Theutilityprogramoperatoradds,modifiesordeletesfacilitiesparticipatingin theprogram.Thisissimilartotheoriginalconfigurationstep. 1d.TheparticipantmanageroptsoutoftheDRprogram.Atanytime,thefacility managercanoptoutoftheDRprogramontheDRAS.Whenthereisanoptout condition,DReventsarenotpropagatedtotheDRASClient.Theoptoutcanbe eitherfortheentireprogramorasingleevent. 1e. TheparticipantmanagermodifiestheRTPeventmappinglogic. 1f. Theutilityprogramoperatorand/ortheparticipantmanagerreceivean exceptionnotificationfromtheDRASincaseofanerror(thisisnotshowninthe diagram).WhenanerrorconditionoccursintheDRASwhichmayrequiresome sortofactionbyeithertheparticipantortheutilitytheDRASwillsenda messagetotherespectiveoperatorsviaemail,voiceorpager.Notethatthis alarminginterfacedoesnotcoverexceptionconditionsthatarepartoftheDRAS operationandmanagedbytheDRASoperator,whichisoutsidethescopeofthis document.Thetypesofexceptionscoveredbythisinterfaceinclude:

DRASClientcommunicationsfailure.

APD65