CALIFORNIA DEMAND RESPONSE BUSINESS NETWORK

Transcription

1 CALIFORNIA DEMAND RESPONSE BUSINESS NETWORK Ali Vojdani & Scott Neumann, Utility Integration Solutions, Inc. (UISOL) Gaymond Yee, California Institute for Energy and Environment (CIEE) Abstract The Demand Response Business Network (DRBizNet) was envisioned and architected as part of an R&D project funded by the California Energy Commission Public Interest Energy Research (PIER) Program. It is a highly automated and flexible network of collaborative DR applications and intelligent agents that can enable efficient DR for over 11,000,000 California DR Stakeholders by leveraging modern distributed business process integration technologies and open standards. Work was conducted under the guidance of an Advisory group that included the California ISO, Pacific Gas and Electric Company, Southern California Edison, and Sempra Utilities. Wide-scale acceptance of the proposed DRBizNet architectural principals and standards will facilitate an efficient electronic collaboration, workflow, and transparent exchange of information among the participants in the California DR value chain, enabling significant levels of DR at drastically reduced integration and operations costs. The project was completed in April of It developed a high-level blueprint for constructing DRBizNet based on a Service Oriented Architecture, orchestrating standards-based Web services across a business network built on the Internet. The utility industry Common Information Model (CIM) is leveraged where applicable. DRBizNet includes distributed Registries, DR Collaboration Exchanges, Intelligent Agents (IA), DR Connectors for secure B2B communications, DR Portals for role-based presentation of information, and standardized Web services interface with DR participants. The Web services include the services that will be provided by utilities, customers, aggregators, and other service providers, using standardized, secure, protocols. Utilities can readily introduce new DR programs through DRBizNet. Participants can readily register and participate in various programs. Many of the participants actions are automated through Intelligent Agents that can take actions on behalf of the participants based on the specifics of the DR programs obtained from the DR Collaboration Exchanges and the parameters specific to each participant. Implementation of each DR Program is highly automated through configuring Workflow Engines at DR Collaboration Exchanges, minimizing the need for inflexible and expensive- to-change, hard coding of DR programs. As part of the project, the Project Team prototyped a software system that demonstrated the key innovations introduced in this DRBizNet R&D project. A follow on field simulation project has started to prove the novel concepts introduced in this project and to gain DR marketplace participants buy-in. Three California utilities and the California ISO are participating in the field simulation.

2 Introduction This paper summarizes the results of a Demand Response Enabling Technology Development (DRETD) project funded under the California Energy Commission Public Interest Energy Research (PIER) program. As a DRETD project, it was undertaken as a high risk/high reward, collaborative R&D effort with a long-term view. It is aimed at developing disruptive enabling technologies for a state-wide demand responsive electric power delivery system with 10/10 improvement objectives potentially leading to order of magnitude (i.e., 10X) improvements in both performance and cost of Demand Response (DR) in California in 10 years. The objective of the project was to design a high level architecture for a suitable information technology integration infrastructure for the California DR supply chain (i.e., value network). This integration infrastructure, that we refer to as the demand response business network (DRBizNet), can drastically simplify and automate communications, coordination, and control in the DR marketplace for all stakeholders. The project also recommended an implementation roadmap for a self-funding, stakeholder-driven, decentralized evolution of DRBizNet in California. Background and Motivation In the aftermath of its failed retail deregulation, alarmed by the shrinking electricity capacity reserve margins, California entered the 21 st century with a great need for DR. DR is the ability of electricity users to respond automatically to time-and locationdependent price and contingency signals to reduce/shift loads. Without DR, the Golden State may be faced with a dark future of mandatory load sheds and blackouts that could dampen its economic recovery and prosperity. California investments in the DR programs are timely and perhaps even overdue. Utilities and DR Aggregators have built several DR programs including various forms of Critical Peak Pricing (CPP), Demand Bid Program (DBP), Real-Time Pricing (RTP), and Direct Load Control (DLC). The major focus of these programs so far has been finding subscribers. No priority has been given to architecting a sound information technology (IT) infrastructure for these programs. Typically the existing IT systems of a few vendors are patched together in a rush to meet the goals of the next summer peak. Such patchwork infrastructure will be very difficult and extremely costly to change and scale to meet a growing number of participants and transactions. To relate to this critical point, consider the analogy of building the California DR infrastructure to building a city. The current DR landscape in California is analogous to a city built without an architectural blueprint (i.e., city plan ), as symbolically depicted in Figure 1. The figure shows four DR communities built around two CPP programs (CPP1, CPP2), an RTP program, and a DBP program. Each of the four programs and communities are built without any unifying theme, attention to growth needs of each community, attention to needs of habitants that do business in multiple communities, or agreement on how to bridge or connect from one program/community to the next.

3 Figure 1. The DR Landscape Imagine building a city without a city plan. If each person can go about building city structures and roads without any unifying rules and supporting infrastructure, the city will soon be a big un-inhabitable mess (e.g., constant traffic jams); everyone would lose. At the very minimum people in that city would need to agree on some basic issues such as building codes, a common language to use for traffic signs, which side of the road to drive on, and how streets, roads, and bridges would interconnect. Also, some common services such as mail, police, and fire fighting need to be put in place for the good of all. Great cities such as Washington DC and Paris were architected for greatness. While individual city structures and roads may last only a few years or decades, a city plan has a much longer lasting value, and provides significant benefit to all the citizens for generations, while ensuring that the city s life spans into centuries. We need such a city plan--an architecture blueprint for DR in California. A sound IT infrastructure architecture, based on modern integration technology and mainstream standards, need to be established and adhered to in order to ensure important issues such as flexibility to accommodate future changes (e.g., new DR programs, changes to tariffs), multi-vendor participation, scalability, security, and performance can be resolved. Investment in the architecture upfront will avoid many unnecessarily high future costs of maintenance, operation, and changes associated with the patch infrastructure. Since the patch systems supporting each program may become legacy systems that would need to be carried forward into the future at a high burden, it is best to develop a sound DR infrastructure architecture for California as soon as possible.

4 The DR Value Network To grasp the importance of the DR infrastructure architecture, we must first recognize that DR programs may involve business interactions and collaboration among multiple and divergent participants. This reality is depicted in Figure 2 which shows a DR value network. Figure 2. A DR Value Network In a DR value network, many entities such as Independent System Operator (ISO), DR Service Providers, Demand Aggregators, Distribution Utilities, Metering Agents, Settlement Agents, Billing Agents, and Customers need to collaborate in real-time to execute the DR business processes. This point is illustrated in Figure 3 which shows the required collaboration between customers, utilities, ISO, and aggregators in executing (business) processes such as 1) Customer Registration, 2) Meter Installation, 3) Customer Price Curve Aggregation, 4) Dispatch, and 5) Settlement.

5 Figure 3. Need for Real-Time Collaboration in the DR Value Network

6 Demand Response Business Network Demand Response Business Network (DRBizNet), as envisioned in this project, is a distributed IT infrastructure that can facilitate the automation and optimization of the DR value network 1. The requirements for DRBizNet are complex, particularly if it is going to enable effective participation of all customer classes including residential customers [1]. The metering, billing, and settlement solutions must be robust and capable of dealing with thousands of customer accounts in a timely and accurate manner. In addition, sophisticated supervisory control and data acquisition (SCADA) systems are required to monitor customer demand and customer compliance with curtailment instructions. Because each customer has a unique load profile and service requirements, the systems must be able to support a oneto-one approach to customer relationship management (CRM). The fact that prices and loads need to be controlled and managed in real time creates a requirement for dynamic, instantaneous communications and feedback. The communication platform must be robust enough to handle large volumes of traffic in a secure, uninterrupted manner. Communication protocols among the players must be standardized to allow rapid, lowcost implementation. Otherwise, transaction costs alone may negate all the potential cost savings. Flexibility within the DRBizNet is also important, for several reasons. First, because of geographical variation in tariffs, regulations, and market structures, systems will often need to use different business rules in different locations. Second, service providers must also be able to adapt their business processes quickly in response to legislative and other external changes. Also, third, because they operate in a competitive environment, service providers will be obliged to continually innovate and enhance their service offerings as well as other aspects of their businesses. This extreme requirement for flexibility is perhaps the most defining characteristic of DRBizNet. It presents a significant challenge to architecture of DRBizNet since we need to design a network to support business processes that are likely to drastically change in the future. It also presents the opportunity for a disruptive innovation that is introduced later in this report integration of distributed intelligence. Architecting a well-functioning and responsive DRBizNet is important but not simple. The focus must clearly remain on implementing distributed business processes that create profit for commercial stakeholders, while achieving other public good goals. DRBizNet is an example of a distributed business network that requires modern integration technology to support it. It is just not practical to implement such a business network using trading pits, telephone, fax and pieces of paper (which is how most markets have evolved). DRBizNet will need to be architected to support real-time electronic business collaboration among the entities enrolled in the DR value network across wide-area networks, addressing critical IT issues such as use of evolving open standards, scalability 1 It is important to note that the proposed DRBizNet is a multi-vendor distributed infrastructure that will ultimately be built by the California DR stakeholders, including the utilities, in a decentralized manner, preserving and extending the existing infrastructure. It is NOT a centralized system to be built by government or any one vendor.

7 requirements, real-time response requirements, security requirements, configuration management, communications network and messaging, fault-tolerance, multi-vendor interoperability, heterogeneous hardware, heterogeneous operating systems, heterogonous networks, operations, and maintenance. Project Objective The objective of this research was to design information technology architecture for DRBizNet at a high level, and to develop a roadmap for its implementation in California. The project was aimed at answering the following key questions: 1. How to design an architecture that can accommodate: A diverse array of evolving DR rates, tariffs and programs? A diverse set of customers and service providers? Effective participation of residential customers? Protection of investments in existing DR systems? 2. What technologies can be used to build DRBizNet? 3. What steps should be taken to build the DRBizNet? Project Approach and Methods The project objectives were achieved by performing the following ten (10) R&D tasks: Task 1. Assess the AS-IS State Task 2. Vision the TO-BE State Task 3. Catalogue Benefits of DRBizNet Task 4. Analyze the Gaps Task 5. Develop Business Architecture Requirements Task 6. Develop DRBizNet Architecture Task 7. Assess State-of-the-Art in Integration Technology Task 8. Demonstrate the Integration Concepts through a Prototype Task 9. Develop an Implementation Roadmap Task 10. Document and Communicate R&D Results Tasks 1-4, which were completed during the summer of 2004, confirmed the statements that were made earlier in this section regarding the current state of DR in California, and confirmed the need for DRBizNet. The key requirements for DRBizNet along with the proposed architecture, implementation roadmap, and recommended next steps are summarized below. DR Business Process Integration Our technical approach to architecting DRBizNet was based on cutting edge concepts in building distributed business architectures and enabling distributed business process integration, which takes the traditional data integration practices to the next level of sophistication: Business Process Integration.

8 Understanding (business) process integration and its distinction from data integration is critically important to the design of DRBizNet [2, 3]. While data integration is the essential first step for making the applications communicate with each other, it is not sufficient for building real-time collaboration networks such as DRBizNet. An analogy with human interactions could help drive home this critical point. Consider a team of individuals with different expertise, assembled to accomplish a complex task. It is necessary that the team members communicate with and understand each other s vocabulary so that they can exchange information. But information exchange is not sufficient. The actions (i.e., tasks, work) of all the team members must be coordinated; each individual should understand his/her role and what is expected of him/her, and backup responsibilities must be worked out, in order to have a smooth-functioning team. Stated differently, we need to effectively sequence and coordinate the flow of tasks or workflow among the business process participants end-to-end under both normal and abnormal conditions. In reference to the examples presented in Figure iii, data integration is necessary to enable seamless data exchange between each two entities (e.g., exchange of customer record). Business process integration provides the intelligent business processing logic that is needed to effectively coordinate and monitor the multi-step, long-running transactions and information exchange among people and applications within each entity and across all entities in the business network. In the context of a DR value network, business process integration should simplify and automate business processes such as customer registration, meter installation, or a demand bid program, end-to-end. Stated differently, business process integration is to enable efficient workflow (i.e., proper sequencing and automated execution of tasks) among people and computers in a business network. We can view the function of each computer application or human actors (e.g., customers, aggregators, utilities) in the DRBizNet as a service element of the overall process that ultimately helps deliver DR. We define an optimal distributed DRBizNet business network that is to make new and existing computer applications in the utility industry, along with the human actors, to work together in an automated and well-coordinated manner, enabling efficient real-time collaboration in the DR value network. DRBizNet will efficiently orchestrate DR (business) services (e.g., a notification, confirmations, record update) within the DR value network to efficiently execute DR business processes end-to-end 2. Using today s IT integration jargon, data integration approaches are focused on creation of the messaging element of the integration allowing applications to plug in and exchange data through a message bus. This R&D project is focused on the next generation of integration application of Business Process Management (BPM)/Workflow technologies to automate the DR value network [4]. 2 One could view DRBizNet as a Composite Application for DR in California, composed from integration of the component DR services that are provided by the participating DR stakeholders.

9 As we will see later in this section, modern Workflow Engines that can efficiently orchestrate (web) services could be used to drastically simplify the implementation of DRBizNet as a Service Oriented Architecture (SOA). The services could be provided by utilities, customers, aggregators, and other service providers, using standardized, secure, protocols. To the extent that these services are compatible with the DRBizNet integration standards, they can easily be plugged in to interoperate. Accepting the proposed DRBizNet initiative would be putting a stake in the ground; in effect articulating the need for real-time collaboration within the DR value chain in California to enable DR. It is only through the creation of such a state-wide real-time distributed business processing network that one could begin to create the kind of DR that is desired in California. To accomplish the vision of DRBizNet, one needs to architect a distributed business network of significant complexity where the applications are not just connected, but can collaborate in real-time. Complexities include the flexibility, simplicity/elegance, scalability requirements, real-time response requirements, security requirements, configuration management, communications network and messaging, fault-tolerance, multi-vendor interoperability, evolving standards, operations, maintenance, and public/private sector funding. Integration of Distributed Intelligent Agents DR business process integration alone cannot lead to the 10 X10 improvements demanded by the DRBizNet project. The question therefore is what additional innovations does the DRBizNet include that will lead to such a large change for the better? The key to answering that question is to understand how systems are built today and why this approach does not work for DRBizNet. Currently most DR computer applications are built as centralized stand alone systems. They have a central database that organizes information and an internal structure that while often object oriented, typically hard codes behavior in the code of the application itself. Therefore even if applications have web front ends they are essentially architected as stand-alone applications that are not designed to dynamically change their behavior and interoperate with other peer systems. This is the true Achilles heel of all the current approaches to DR. The systems are just too static and stand alone. The reality of DR is that it is dynamic and collaborative. The dynamic and collaborative nature of DR is clear changing program rules, real time trading and operations, dynamic prices etc. The reality is that unless the architecture is highly distributed, intelligent, robust and flexible then DR will simply not work. What we have today are too many static, stand alone systems. Unfortunately standards are not enough to solve the problem. Standards are necessary but standards also suffer from the same problems of being too static to be really useful in and of themselves. Standards are often welded into the existing static stand alone applications to make them interoperate. The reality is one is left with hard wired static interfaces that are themselves unable to change.

10 The answer to the innovation problem is to look at natural systems for our analogy. When one observes how natural systems operate it is clear that they do not operate off of static, stand-alone databases. Every biological network is a network of holonic nodes (independent acting and definable) that can interoperate with its peers in a flexible way. The DRBizNet must share this structure of holonic and coordinated interaction. The innovation in DRBizNet comes from the integration of distributed, interoperating intelligent holons or agents with some set of central coordinating nodes. Only this can possibly meet the flexibility requirements of DRBizNet. The innovation of the DRBizNet approach is to realize that a static, stand-alone approach cannot work. The DRBizNet must act more like a biological network of interacting intelligent holons or nodes, all coordinated in some sort of way. This type of architecture is embodied in the following two components. Intelligent Agents (IA) used to make local decisions on behalf of program participants DR Collaboration Exchanges, which have Registries to manage information and coordinate program and related processes The Intelligent Agents and the DR Collaboration Exchange (DRX) must be hooked to each other in network fashion via a real-time multi-purpose communications and the DR Collaboration Exchange must allow the configuration rules by DR program, managed centrally and downloadable to the Intelligent Agent so the rules can be executed locally. This configuration is shown in Figure 4: Figure 4. DR Collaboration Exchanges and Intelligent Agents This however is not the whole architecture. The DRBizNet architecture must provide the means to integrate existing static stand alone devices and applications. This is done by providing the means for an Intelligent Agent to be deployed on top of these static systems and devices in order to give that node DR intelligence and flexibility. In other words the Intelligent Agents can be used to upgrade the behavior of existing static nodes, from existing building energy management systems to meters and thermostats. This is shown in Figure 5.

11 Figure 5. Intelligent Agents Interfacing with Devices and Systems The DRBizNet architecture includes other key elements such as DR Connectors, flexible message structures, Workflow Engines, Web Services, Portals, and Message Buses as is explained later in this section. However, while these elements bring about great innovation to today s DR marketplace, the truly revolutionary and disruptive aspect of the architecture is the integration of distributed Intelligent Agents that enable a new era of dynamic and intelligent DR programs. As an analogy to DRBizNet, one can conceptualize the architecture as similar to how an aircraft carrier group operates. The Registries operate like the aircraft carriers launching Intelligent Agents (aircraft) capable of intelligent independent action. The current approach to DR applications is akin to building battleships. They are monolithic, complex and inherently limited. The DRBizNet architecture is revolution in thinking with respect to DR. It is the future, just like the carrier superseded the battleship, so will the DRBizNet architecture supersede the current generation of DR applications. Structure of DRBizNet The DRBizNet architecture is a distributed architecture and should be viewed at two levels: 1. The DR Business Network which supports a set of one or more DR Collaboration Exchanges and the needs of utilities, the ISO, energy customers, DR aggregators and DR service providers. 2. The components which comprise a DR Collaboration Exchange Figure 6 shows DRBizNet integrating a set of DR Communities and the ISO. A DR Community could be formed around a particular DR program (e.g., DBP), or a set of DR programs (e.g., DR programs offered by a utility, or a DR service provider). Each DR

12 Community has a DR Collaboration Exchange. A DR Collaboration Exchange could be managed by a utility directly, or by an agent of a utility, or an aggregator managing a DR sub-community. Each energy customer is registered with a DR Collaboration Exchange, either directly or through a DR Aggregator. DR Aggregators provide the means for small energy customers to participate on an equal basis with larger energy consumers. Energy customers or aggregators could potentially collaborate in more than one DR Collaboration Exchange, although this would likely be rare or prohibited by rules to avoid gaming of the DR markets. Figure 6. DRBizNet Landscape The heart of DRBizNet is the DR Collaboration Exchange, which is in effect a container for the Registry and related components. The DR Collaboration Exchange is comprised of several components which implement both a Service-Oriented Architecture (SOA) and an Event-Driven Architecture (EDA), where the capabilities of an SOA are complimentary to those of an EDA. Integration with a DR Collaboration Exchange instance is through DR Web Services and the DR Connector, as shown in Figure 7. The DR Connector permits secure Business-to-Business (B2B) connections to the DR message bus.

13 Server Server Server Server ISO Regulators/ Market Monitor DRBizNet DR Common Information Model, DR Message Bus, DR Service Bus & DR Portal DR Web Services DR Services DR Portal DR Workflow Engine DR Registry DR Process Definition DR Information Model DR Collaboration Exchange (DRX) DR Message Bus DR Connector DRX DRX DRX DR Connector DR Web Service Utilities Service Providers (e.g., DR Aggregators Billing Agents, Metering Agents) DR Intelligent Agent Customers DR Collaboration Exchange Figure 7. DR Collaboration Exchange Integration Figure 8 provides an overview of the DR Collaboration Exchange components and their relationships. This figure should be viewed as a logical view, where implementations could have some variations with respect to the use of workflow, agent and message bus products.

14 Figure 8. DR Collaboration Exchange Components The DR Collaboration Exchange architecture consists of a set of DR Services which manage and utilize the DR Registry. The DR Registry is primarily a database and a set of associated services which manages all information which is required by DR participants and DR Collaboration Exchange components. Some of the DR Services are exposed as web services, and others are used internally. The Workflow Engine is used to drive DR business processes, which may involve DR Services, DR Web Services and the DR Message Bus. The DR business processes are configured (for flexibility, as opposed to being coded) to permit the Workflow Engine orchestrate the other DR components. The DR Message Bus provides the means to publish events and requests to participants and Intelligent Agents. The DR Message Bus uses the DR Registry to define virtual subscriptions, where messages are pushed to the required destinations, in an appropriate format using an appropriate transport (SOAP, , etc.). Messages received by Intelligent Agents drive the processing of local rules which can result in bids, control actions, etc. The DR Collaboration Exchange can be architected around the use of a Workflow Engine. There are many reasons for this, which include: DRBizNet must provide for flexible support of business processes related to DR registration, management, programs and settlements. Business processes can be implemented and evolved through configuration, rather than coding, through the use of a Workflow Engine. Components that are constructed within a Service-Oriented Architecture through the use of Web Services can be readily orchestrated by a Workflow Engine. Workflow Engines typically have capabilities to rapidly develop and deploy web user interfaces.

15 Figure 9 presents an example of configuring a DR business process using a commercial Workflow Engine. Figure 9. Configuring a Demand Bid Program using a Modern Workflow Engine In summary DRBizNet is comprised of a set of one or more DR Collaboration Exchanges. Each DR Collaboration Exchange would typically be comprised of the following components: DR Registry: A database and DR services which manage participants, relationships and transactions DR Web Services: For access of business services by participants DR Message Bus: Used for communication between components, especially important for publication of messages DR Connector: To permit secure B2B connections to the DR message bus DR Portal: To permit human access to the DR framework and associated web services Intelligent Agents: Can make decisions on behalf of a participant with configurable rules without human intervention. Could be deployed on a server, PC or within an end device. Figure 10 shows the configuration of Intelligent Agents, where they communicate with a DR Collaboration Exchange via the internet. At a participant location, an IA can integrate with one or more devices or systems. A user could monitor their participation in a program or their IA through the use of a web browser.

16 Figure 10. Communication with Intelligent Agents Information Model and Messaging Standards The DRBizNet information models are primarily realized in the following ways: Registry database Document structures, which define messages and interfaces An overview of the DRBizNet logical information model is presented in the DRBizNet Final Report. The key semantic relationships between entities in the DRBizNet logical information model are: A Framework can have a set of Programs A Program has a Tariff and a FrameworkInstrumentType Participants can be: buyers, sellers, service providers Participants can be associated to Programs and assume one or more Roles Participants can be associated to other Participants through Relationships Participants and Programs are associated with Locations A Transaction can occur between a buyer and a seller for a FrameworkInstrument A Transaction may involve a DeliveryAction

17 A Settlement may involve the verification of a DeliveryAction and impact on Usage Messages in DRBizNet are defined using XML Schema, in a manner which permits the use of a common messaging infrastructure which can readily adapt to new programs and associated documents. The message structure used by DRBizNet is a generalization of the message structure defined by IEC , which was a simplification of messaging structures defined by the Open Applications Group. The DRBizNet message structure consists of the following key elements: A noun, which is a simple string that identifies the type of document being conveyed in the payload. A verb, which is a simple string that identifies the action or intent of the message (e.g., Create, Change, Cancel, Close, Delete, Get, Show, Reply, Subscribe). The document payload, which is defined using an XML Any type, which permits any type of XML document to be sent. The document should however be consistent with the type identified by the noun. Using this structure, there are many possible permutations of nouns (document types) and verbs (actions) which can then be supported using a common messaging infrastructure. Supporting Technologies The DRBizNet architecture can be constructed using a variety of software products. The types of products used to implement DRBizNet include: Browsers Operating systems Database management systems (DBMS) Workflow engines Application servers Web server Message buses Portals While there is no requirement to use an Enterprise Architecture Integration (EAI) messaging product or Workflow Engine, there would be benefits, just as there would be in using an RDBMS product to support the registry. DRBizNet Demo Software The Project Team prototyped a software system to demonstrate the key innovations introduced in the DRBizNet R&D project. The Project Team provided a demonstration of this software at the final workshop on April 20, A detailed presentation on the Demo software can be obtained from CIEE. Some highlights of this demonstration is depicted in Figure 11 including sample DRX web pages, data entry screens, business processes, DR Registry schema, XML message format, intelligent agent, intelligent agent

18 graphic simulator, and the demo hardware and software configuration. For more information about the demonstration software please contact DRBizNet Project Manager at CIEE or UISOL. Figure 11. Highlights of the DRBizNet Software Demonstration DRBizNet Implementation Roadmap The DRBizNet is a distributed business network. As such, it can be implemented by the California DR stakeholders in a decentralized manner to the extent that their efforts are harmonized through some form of a stakeholder-driven, self-funding, central support organization providing the services summarized in Table 1.

19 Table 1. Services to be Provided by the DRBizNet Support Organization Committees DRBizNet Committees Steering Committee Management Committee Marketing Committee Technical Committee Support Services Direction, goals, and priorities Sponsoring/Advocating DRBizNet Build Out DRBizNet User Group Formation and Operation Organizational Policies and Procedures Membership Communication, Marketing, and Promotion DRBizNet User Website Newsletter List of Compliant Products Technical Maintenance of DRBizNet Architecture, Information Model, Message Definitions, Services Design Technical Publications DRBizNet Helpdesk Resolution of Technical Issues Training Events, Workshops, Conferences Facilitation of Electronic Forum for Technical Discussions Integration and Conformance Testing Support Product Certifications Statistics/Reporting/Monitoring Liaison with Standards Organizations We propose to implement DRBizNet in six (6) phases, as presented in Figure 12. The first phase of the implementation, the R&D phase, is the project that was completed.

20 Conclusions Figure 12. The Proposed DRBizNet Implementation Roadmap The key conclusions of this research can be summarized as: California is investing in IT infrastructure for DR programs. These DR programs are being built without a unifying architecture. We can protect our investments and get more DR by designing a suitable DR IT architecture--the sooner the better. To create a rich and dynamic marketplace for DR that can ultimately reach the 11,000,000 California residential customers, we need three cornerstones: 1. Automation of DR business processes 2. Distributed intelligence 3. Standardization The DRBizNet Architecture envisioned, designed, and demonstrated in this project lays a solid foundation for these three cornerstones, by designing 1) a suitable Service Oriented Architecture (SOA) for automation of DR value network, 2) Integration of Intelligent Agents (IA), and 3) appropriate Open Standards.

21 The California DR stakeholders could build DRBizNet in a distributed manner in the next five years if their work is coordinate through a self-funding User Group. DRBizNet can result in 10x10 benefits 10 times DR at 1/10th of investment. The critical next step is to create champions for DRBizNet through a field demonstration aimed at communicating the architecture and proving feasibility. Some of the key innovations that are employed by DRBizNet include the following: Designing a suitable Service-Oriented Architecture and using Web Services for DR; The use of a distributed Registry, which can permit coordination of participants in many programs; The use of Workflow Engines to permit programs to be configured and reconfigured, avoiding the classical practice of inflexible custom development; The use of a generalized XML message structure to reduce complexity, with permutations based upon the use of nouns and verbs (Described within the report); and Use of Intelligent Agents for local decision making at customer site. References 1. Vojdani, Ali, Building an Infrastructure for Demand Response, Power Economics, Volume 5, Issue 9, October Vojdani, Ali, E-Business Platforms in the Electricity Supply Industry, Montgomery Research, The Utilities Project report on The Impact of Competition, Volume 2, 2001, pages Vojdani, Ali, Tools for Real-Time Business Integration and Collaboration, invited paper, IEEE PES Vol. 18, No. 2, Special issue on Tools for Managing Restructured Energy Systems, pp , May Neumann, Scott, Shankar, Kamaraj, Vojdani, Ali, Applying Workflow Technologies to Integrate Utility Business Processes, DistribuTech 2005.