OpenADR must respond to future demands

I have been reading through the current draft of the OpenADR standard this week. The ADR stands for Automated Demand Response (although I would prefer autonomous demand response, as regular readers might guess). Demand-Response refers to the conversations between electrical utilities and their customers, so that when the former anticipates a too large demand, the latter might respond with a curtailment plan. This curtailment might be under an existing rate agreement or subject to a live auction.

OpenADR is a nice and well rounded specification, focused tightly on solving today’s problems. Even the documentation, generated using LiquidXML Studio, is clear, crisp, and visually attractive. I wish it were more focused on emerging markets, because the work within it can clearly help them to develop.

OpenADR today has three components: communications between utilities, communications from the utility to the consumer, and communications from the consumer back to the utility. Utilities can exchange information on how much power they can produce. Utilities can alert customers to anticipated shortages and request bids to meet anticipated shortages. Customers can respond by making commitments to shed load, and bidding for the prices they would demand to do so. In the future, the lines between these areas will be blurred, causing the components to blur.

The proper target for OpenADR is the enterprise, not the building. OpenADR and its predecessor, DRAS, started out as interactions with building systems. The proper focus of DR requests is the enterprise. The enterprise owns the building systems and so can decide which requests are worth responding too. The enterprise also owns the business processes, which can enable still greater response than can the building systems. If we do this right, these negotiations will be two-way, creating non-hierarchical markets.

So what do I think the emerging market of the future looks like? How is this market different from the simple interactions in today’s ADR?

Participants will want to schedule things further out. Today’s long range DR is essentially a guess based upon tomorrow’s weather report. Longer term options will be based upon longer horizons. What price can I get if I commit today to a maximum use in the afternoon for Thursday and Friday for the rest of the summer? If I opt for four ten hour days during the summer, will the grid pay more for me to turn off the building on Mondays or Fridays? Building Resources such as conference rooms will know that they are unable to provide conditioned space on these days. Scheduling questions should look more like the corporate standard ICAL (used for scheduling meetings) and less like any control system interval.

What if I am a third party energy manager. I have an ever changing portfolio of customers/office buildings. Because the grid is a physical distribution system, shortages have a defined geographical range. Some of my portfolio will be inside the DR area, some will not. I might wish to shut off some systems in each facility for 10 minutes and meet my bids in aggregate. Every Demand request will include geographical areas following open standards that can be reviewed on any tool I use, even Google Earth.

What if I follow the French model and have an all company vacation during the heat wave. Can I get bids in advance to run my generators during afternoons and sell lit back to the grid? What about my solar cells on the roof for all day re-sale? In the future, every building is potentially an energy source, so every building is a potential participant in as a power seller.

Then there are the questions, the questions that must be answered whether or not there is any current DR event. What is my current use? What is my current price? If I needed more power, what would it cost me? Would the reliability of my portion of the grid be reduced by that request? How much more power can I ask for?

I will write more about this later. But watch for OpenADR.

The Ontology *is* the Business

Admit it. Lots of you recoil a little bit when I wander off into discussions of ontology. It sounds so academic, so far from the practical. Maybe someone down in the trenches has to think about ontology, but surely it is not a business interest.

This is exactly wrong. Ontology is discovering the meaning in facts. Ontology is what gets discussed in the executive suite. Ontology is what is going to turn the meaningless details of building systems into new services, new money machines. Ontology is what turns process into service.

By example, consider accounting. At the low end there are clerks and bookkeepers. Their concerns are in properly classifying each event. Assign a name to each number, and make sure they balance. The math is trivial; the problems of introductory accounting are semantic problems of classification. Bookkeeping is never strategic. We use it to keep score. No one wants to be told what to do by the bean counters.

Bookkeeping turns into accounting when it begins to be used for making decisions. There can be several ways to do cost accounting to understand the problems of manufacture or of construction.. Financial ratios normalizes the books so you can compare the prospects of different businesses. The focus of accounting move from what ledger to put each item on to how do I understand the business.

Accounting grows from bookkeeping when we need ontologies created from the underlying semantics. (Well, or when we need a compliance framework, but I feel that is actually similar.) ERP establishes a common ontological framework for all the activities of an enterprise. The primary purpose of today’s sophisticated business software is ultimately ontological processing of the underlying process oriented semantic information.

This observation is allied with the truism that it is very difficult to apply a service oriented architecture to a procedure oriented enterprise, while it is straightforward to do so to a service oriented enterprise. Colleges and Universities often represent the quintessential procedure oriented enterprise, with little regard for outcomes and a slavish devotion to their pieces of paper and the processes they represent. You may remember how easy they are to work with.

Building systems are, for the most point, struggling upward to get to semantics. We know how to describe the low level actions. oBIX has provided a base syntax for semantic expansion, but does not yet provide all the nouns. Progress has been made. Yet even if we get fully fleshed out semantics for building systems, we will still not be at the right level for enterprise interaction.

Enterprise programmers cannot have a fruitful conversation with the inner processes of the building systems, no matter how semantically complete. As I believe these processes will more and more be self tuning and self managing, neither will anyone else except during configuration.

Large-scale integration and wide-scale integration, in which many systems are integrated and each system agent responds to many other actors, will require to conversations of two sorts. Enterprise programmers need to be able to specify the service they desire, and the price they are willing to pay for it. Building systems need to accept the terms, and be able to provide quality of service (QOS) or conformance information back.

And for that, we need an ontology of building service performance.

Ontology of Building Service Performance

The first assigned duty of man in each of the great creation myths is the Naming of Things. The formal name for this task is semantics. Procedural programmers usually stop there. To interact with multiple procedures, to move into services, one must decide how to group things. Often a single semantic object will belong in several groups. These groups are in turn, members of still others. In everyday life, we call these groups meaning; when we discuss these groups formally, we call them Ontologies.

Ontolog is an open, international, virtual community of practice on ontology, ontological engineering and semantic technology. I have been meaning to write on these concepts for a while, but will not do so today. Instead I am sharing with you excerpts from the correspondence leading to the founding of a new Ontolog project this last week. I hope to post soon on the importance of this project.

---

Toby Considine

I have multiple potential participants in a project on defining the surfaces between control systems and the outside world. The goal is to define informational interoperability different domains with quite different needs. Traditional integrations have been process oriented and therefore difficult and requiring deep domain knowledge.

The surfaces that come to mind quickly are:

• Building Systems – Design Intents (NBIMS)
• Building Systems – Energy Models (NBIMS)
• Building Systems – Enterprise Operations
• Building Systems – Power Grid (Demand – Response)
• Building Systems – Building Systems (decomposition of over-integrated systems)
• Building Systems – Building Informatics
• Building Systems – Remote analytics & Maintenance Management systems

Each of these implies one or several IDMs, to fit into one or several ontological frameworks…

Bob Smith:

Basically, the idea is to use a SOA to connect connecting service providers with service consumers (initially two domains: Health Informatics and Emergency Response Systems). A key standard in both of these two pilot test domains is the EDXL family of standards.

Deborah MacPherson

Do you know of similar problems, or better know of any solutions, getting the physical space and semantic space to stay connected. NBIMS is lucky because our artifacts, buildings, actually can only have one at time in the same place or time.

Deborah MacPherson

Sounds interesting. Personally, would also like to consider keeping track of material performance over long periods of time. For example owners being able to monitor warranty time periods for all their facilities, manufacturers being able to evaluate life expectancy of their products in various applications and climates. The building informatics, hopefully working towards reduce, reuse, recycle.

Toby Considine

I have just been on the phone with Bob and Deborah, in series. I was trying to align the Deborah's Building Purpose Classification with my own interest in defining a Building Service Provisioning Framework. After some arm-wrestling, Deborah and I have come up with:

BuildingServicePerformance - an Ontolog project to formalize how we describe the Purpose(s) of a Facility and the associated services expected from the building systems. We hope to include the beginning of a compliance framework as well, that is, how to understand if the service is being provided in accord with required performance metrics.

We clearly do not intend to write the metrics, but we believe the framework will allow others to formalize the metrics require for different scenarios pretty quickly.

A measure of success would be that the framework can be used to generate IDMs to at last create information bridges between building systems and buildingSmart, although that is not the only use we see.

Bob wants us to begin fleshing out the wiki to define this part of the project soon.

Deborah MacPherson

Yes - services expected from the building systems which can be "building things" like HVAC systems, a restaurant, brick and mortar cavity walls and larger performance requirements that are bigger than the building like " a tornado is coming and there are x number of people here perhaps some back and forth about how sturdy various structures can be expected to be.

Two sides of a coin where one side is the program and spatial proportions of the building "Hotel, 250 rooms, 8 stories, OCCS class etc" - which is nicely aligned to BIMstorm and OPS. To BIMStorm is to develop a project and get these spaces to work, Owners, Designers, City Planners can all play with and create the same spaces. Analysis can be performed on the results for any number of reasons - cost, geospatial and so on.

The other side is physical performance - for example a necessary performance requirement of the hotel class is to achieve an acoustical goal between rooms, to get there x, y, z gypsum board and a certain type of insulation are used. All the materials have classes which can be mapped into other classes and, what I'm trying to do, eventually map into the spatial programming world of BIMstorm and similar.

There is now a bridge between idea requirements and physical requirements. That same bridge may be able to be extended and reused for other purposes that need the physical world and semantic world to stay connected under certain conditions.

Rex Brooks

BSP is fine with me, but it misses the one part of Toby's original post that resonated especially well with me, which was the notion of helping standardize practices in the interface between building control systems and the outer environment. In the exchanges since, another particularly relevant concept surfaced, improving/maintaining the alignment/awareness/contact between semantic space and physical space. However, I think both of these fit within the rubric of BSP, but we might want to elaborate a bit on these and other aspects/factors that we want to capture and work with.

That said, I also think that we have more than enough to get us started.

---

The team will need to develop its charter at its upcoming initial organizing meeting.

It should be an interesting project. Come on by if you want to participate.

ONTOLOG - collaborative work environment