OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Notes from DC Meeting, Septermber 29, 30


A somewhat testy meeting convened outside DC on September 29, 30 for a hastily convened review of the customer oriented standards development plans. To one side, the plans developed at the August Standards Development Organization (SDO) was putting critical ongoing deployments of billions of dollars infrastructure upgrades at risk, and throwing long term plans into disarray (Team A). The other side saw keeping the August plans intact necessary to enable new investment and new participation in distributed energy, and to break the iron grip of dinosaur twentieth century processes and organizations that impede new energy (Team B). There was little common ground.

The NIST smart grid process identified a number of Priority Action Plans (PAPs). Four of these defined the border between energy supplier and buyer in the smart grid. These communications occur between utility and end node, whether that node is house, or commercial building or industry. These standards are for Price and Product communication (PAP03), Calendar and Schedule communication (PAP04), Energy Usage information (PAP10), and communications for Demand Response and Distributed Energy Resources (PAP09).

The first morning passed with quiet platitudes, until Dr. David Wolman, technical lead for NIST on its smart grid project, called for "blood on the floor" during the afternoon session. The participants complied with enthusiasm, and the conversations became more interesting and more revealing.

Power system engineering standards are developed in the IEC TC 57, the overarching technical committee (TC) defining standards for power management. TC 57 has defined a common information model (CIM); and utilities are striving to rationalize their world by using only elements defined in “The CIM.” Some of the suspicion with which building systems technologists regard the CIM is due to a historic tendency to fit all building operations into the TC 57 CIM

Representatives from the end nodes, particularly commercial buildings and the business enterprise, do not see their world as an extension of the power grid. These areas have their own information models and find the phrase “The CIM” mysterious and unhelpful. Financial services use a CIM defined by ISO 20022. Building systems have information models defined within the divers building control system communities. Enterprise operations beginning to define their interactions using information models from defined by EBXML (electronic business XML) or UBL (Universal Business Language).

The first key agreement of the two days of meetings was to respect the multiple information models on these inter-domain interfaces. For elements and communications that are purely power management related, everyone agreed to use to use the TC 57 CIM. When the communication element involved business transactions, or schedules, or some other area, the communication would use the informational models from that domain.

A common understanding on semantic models, including when to use such models from outside the domain of power management, was important to bringing the divers interests together.

One of the underlying issues was the conflict of business models. This can be resolved, but only by talking clearly about the purposes and motivations behind each model. A good first start would be to give them good names.

I favor something looking like pure market interactions. I believe that we all use a standard abstract presentation for scarcity and value, for risk and for reliability. We call this abstraction money. As Stephanie Hamilton opined when she still worked at Southern California Edison (SCE), every brown-out is a pricing failure.

Because I come from the perspective of building integrators, I have great faith in the ability of building automation systems to manage change, They are usually poorly maintained, and poorly understood by their owners, but they keep running. They adjust naturally to the conditions around them, and to their own operations, and are getting better at autonomous action and tuning. I want to give them clear price signals, not only now, but for the future. UI want to give them clearer information about weather and environment. And then I want to leave them alone.

But such systems can cost thousands of dollars to install. In part this is because without standards, they are all custom work. Still, there must be a less expensive solution.

Early smart grid deployments are aimed at the smallest, cheapest systems that can fit easily into appliances and home thermostats. They must not change the price of appliances materially, especially as social equity concerns mandate that low income consumer have access to the benefits of smart energy. Consumers want reliable systems; it is hard to convince them to pay more for systems that can be turned off by someone else.

Utilities often refer to this group as the Residential option, When pressed, they may call it ZigBee, because that trade association is the primary technology used to install these low end systems. They may call it the OpenHAN (Home Area Network) approach, although the information and interactions are indistinguishable from those of ZigBee. Sometimes this approach is used I small commercial buildings as well.

Rather than call them the OASIS or C&I (Commercial & Industrial) approach and the ZigBee or Residential approach, I think we should name them according to their business models. I propose that we call them Collaborative Energy and Managed Energy.

There, without out of the way, I can summarize succinctly the business model agreement from the customer-oriented standards development meeting.

We agreed that we would apply the semantic models coming out of NAESB to parallel processes for Collaborative and Managed energy, and that we would keep the semantics aligned when we could.

tc


"Energy and persistence conquer all things." -- Benjamin Franklin


Toby Considine
TC9, Inc

Chair, OASIS oBIX Technical Committee
OASIS Technical Advisory Board

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.oasis-open.org

blog: www.NewDaedalus.com

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]