EBMS the Next Time – Agents and Enterprise Interactions

The University of North Carolina’s Enterprise Building Management System (EBMS) is an innovative open system for managing energy use and operating building systems. It hides the diverse brands and control protocols of the buildings, keeping each safely contained in its own building sandbox. All communication with these systems is by web services, the basis for modern internet e-Commerce. All systems communicate primarily with a central system that programs each building.

In many ways, rather than doing things a new way, we have perfected the old. Instead of many consoles, one for each bran, we have one. Rather than specifying a single brand of building system for compatibility, we can select the one that performance requirements and competitive bidding indicate. Because all data is now normalized and kept in an standard database (it happens to be MSSQL), we can use standard tools for reporting and OLAP.

But we didn’t change that much. They say you go to war with the army you have, and not the army you want. And you go to bid with the technology you have, and the specs you have, not the technology you want. Push the technology and business processes too hard, and no one bids. Someone told one of our executives that XML was a fad, so we were forbidden to even mention it in our bidding documents. The entire building controls industry still has a poor concept of security, so allowing open access to systems is still a problem.

All things considered, EBMS is a remarkable project, one that pushed the state of the art. But it could have been better.

We should have pushed the performance abstractions down to the Local Gateways (EBLG). Rather than shedding load centrally, we could have been able to send a command to each building “LoadShedLevel3”. We could have submitted a web services request to the building, “StayInOccupiedMode” “8:30pm”. We could require the facility system integrator to define these contracts t comply with performance expectations. This would have prepared each building to have enterprise interactions beyond central monitoring and operation.

This would have defined a realm wherein enterprise programmers with enterprise skills (and not building skills) could operate the buildings. Building gateways would become building agents, and maintain responsibility for performance.

Today the EBMS is REST, meaning simple URLs define all interactions. SOAP would have let us better prepare. Transactions may need various levels of security. Today we encryption and firewalls. I want signatures, and roles-based security, and delegation. I want guaranteed delivery and non-repudiation. I want to be able to store decisions and authorization to run contracts, with signatures, in a business process (BPEL). When the business process arrives, I want the pre-authorized contract to be issued.

In short, I want enterprise interactions.

No special Demand-Response plan for the data center

I was part of a round-table on Demand-Response in data centers last week. Demand-Response is the strategy used by the power companies to trim peak load, the load that degrades into brown outs on a hot summer day. Demand-Response can include options from forward agreements to get a better price to live bidding to give up power, depending on the regulatory and market environment.

Missing from much of the discussion it was any real focus on marshalling and allocating all the resources available to solve business problems. As a government employee, I felt right at home: cost, cost, cost, when the discussion should have been value, value, value.

Modern management practices in the data center are concerned with optimizing the conversion of compute cycles into raw business process. In the world of blades and virtual machines (VM), concerns with servers are replaced with business process throughput, and trading schedules to improve service levels.

Concomitant with this is the most efficient direct conversion of electricity to heat ever devised. Heat disposal becomes paramount. Support infrastructure, whether additional cooling capacity or electrical capacity is rarely managed at all. Corporate resources are thrown away because excess energy is treated as a waste stream.

The best data center management is always trading off business resources to meet business service level agreements (SLAs). If transactions through the middle tier supporting sales transaction take longer than, say, three seconds, customer will begin to abandon transactions. Using blade servers, a new VM is quickly provisioned to supply the needed compute power. If there is no payroll this week, transactions supporting human resources can be delayed, a VM shutdown, and a new VM provisioned for sales transactions. The modern data center is managed for business process delivery, not for computation.

Under this model, Demand-Response is simply a new business cost, a new service trade-off. Demand-Response is simply a further management of the same business process in the same way as everything else. Based upon cost, some business processes are slowed down, or even transferred to another data center in another part of the grid.

I guess what I am arguing is that if you manage your data center properly, Demand-Response is just another business event, and not a unique one. Oh, and make sure your back-up data center is on a different grid.

SaaS and Power and Service Oriented Energy

A recent editorial in Baseline used today’s electrical grid as the model for future computing. The article suggested because of the rise of Software as a Service (SaaS), local computing would disappear just as local generation did. Just as the rise of AC allowed generation to move a long way away, the article claimed that SaaS will push all computing off site. Models for computing and generating are converging, but the mode of that confluence is considerably more interesting.

Computing is actually become local. Microwaves and DVD players are not leaving the building. Service oriented computing is moving computing power into building systems and cell phones as well as into the remote data center. Service oriented computing also means that we can now choose the data center that hosts our services, by price, or by reliability, or by security, or even by social conscience as we please.

Today’s electrical grid is more akin to mainframe computing. End users have little choice as to hosting or to distribution, and local options are limited, often by government policy. (DEC originally named their devices programmable data processors, [PDP], to get around federal grant restrictions on buying computers). In the same way. On-site generation is crippled, poor economic information blocks the development of storage technologies, and in so many way, await the “internet revolution” in power.

Ameliorating this, energy is finally about to take advantage of pervasive computing. Electrical power is just beginning to go through the most radical transformation since is became a regulated natural monopoly 100 years ago. Back then, there was no way to measure power usage except by aggregate use between meter readings. All communication was one way by mail (Here is your bill – pay it!). Autonomous systems that can manage power, that can track consumption, that can manage generation are just arriving in the home and office. Today, groups are just sketching out how to use SOA to re-invent the grid; AMI is starting to provide the most critical first service.

Building systems are becoming safely accessible by enterprise programmers using oBIX and other WS-[building systems] variants. The service oriented building is just beginning to be sketched out with telecommuting, hotelling, and carpooling interacting with access control, building ventilation, and tenant QOS agreements. Building access control services feed carpooling recommendations. Worker hotelling reservations inform heating and ventilation strategies. Policy-based security using SCA is extending from IT to building security.

At the same time, the unregulated power providers are starting to define the service oriented grid. Two way communication centered around the new digital meters make time of day pricing and billing possible. Peak shaving standards such as California’s OpenADR (Automated Demand Response) are teaching the regulated electricity providers to exchange web services with the buildings.

On the table are direct purchases from your power provider of choice over the grid. SOA negotiations for pricing and delivery let enterprises opt for power that is cheap, or reliable, or green. Green will be whatever attributes the buyer wants, creating a “Whole Foods” market in generated power.

Service Oriented buildings will be able to remain provably green rather than ostensibly green on the day of delivery. Self commissioning buildings will become perpetual commissioning systems run by autonomous agents, for participants in and scheduled by enterprise operations. SensusMI uses web services to perform remote diagnostics and building analytics to let the building owner understand his costs and control his maintenance decisions. Componentized access control and intrusion detection are being cast through SCA into policy-based physical security, part of the IT security infrastructure. New markets in Service Oriented Buildings are arriving.

TheGreenGrid.org puts the data center in the middle of this transition. Power cost and reliability are factored through web services into the WSDM-based operations console. Building cooling and capacity and electrical distribution capacity are brought in the same way. SaaS combined with prices enable sun-downing, wherein virtual computing follows cheap time of day power prices around the world. Demand/Response, wherein pre-brownout price signals request load shedding, will soon automate the same type of load shifting.

SOA is freeing up power markets to unleash what Fred Krupp has described as “the mother of all venture markets”. SOB meets SOG in a free-for-all of innovation and high-tech investment. It’s all small today, but watch for it to get big soon. Real big. Real soon.

Whatever happened to oBIX?

I was asked this week “Whatever happened to oBIX?” I paused. I knew I was using it. I know I get phone calls about it regularly. Still, aside from the recent Frost & Sullivan report on oBIX and the enterprise, matters related to oBIX have been quiet since the ratification of version 1.0. There are two types of reasons that you don’t hear about oBIX.

The first is that as in a long running add by a chemical company, you don’t buy oBIX, oBIX just makes the things you buy, better. oBIX is a small protocol among the many small protocols in the enterprise. oBIX enterprise-enables control systems. oBIX lets you build new kinds of applications. If you did buy oBIX, you bought it as part of an application.

The second is that those people who know oBIX best have been going out and doing things with oBIX. Many of these projects are large, and may take years to complete. We’ve been busy.

So today, I’m pulling together some of the projects that I have some, even if often just a very little, knowledge of.

• The Enterprise Building Management System (EBMS) at UNC that operates more than 100 buildings of all brands and technologies. All external interactions with buildings are by web services. Sixty-six of these buildings are operated by oBIX. An iLON controller with full oBIX support would probably become are preferred platform for future integration. If you are interested in EBMS, simply search for it in the archives.
• The Dubai Airport. Dubai has become known for leadership and innovation in construction and sustainability in capital projects. I do not have a contact for this, but would be very happy to know more. If hear the Dubai airport integration is based on product from Tridium. oBIX is a key component of the newest NIAGARA integration platform from Tridium. Tridium’s NIAGARA is used to integrate many complex systems. oBIX even provides the integration layer between their current product (R3) and their previous product (R2) ( http://www.tridium.com/cs/products_/_services/niagaraax )
• Building systems in the Olympic Stadium, the Olympic Village, and all outdoor lighting in the Olympic District in Beijing. This work was, if I am informed correctly, based upon a variant of the 0.7 draft of the specification. As stated above, these projects take years to complete, and decisions get locked in long before construction completion.
• I hear some reports that the Olympic variant of oBIX is used for energy management of whole city districts of mixed use new buildings in Chinese cities.
• Powernab’s YouTility service is integrating in-house services, weather conditions, and solar monitoring for end-user. If I am correct, Powernab uses oBIX interfaces developed by Controlco. ( www.powernab.com , www.controlco.com )
• Hawkesbury provides oBIX-based energy monitoring in a lot of interesting scenarios. ( www.esightenergy.com ).
• NTT in Tokyo is developing oBIX drivers, but I know little more than that.

I would really like to hear from anyone who knows more about these projects, or about more projects I should know of. Please feel free to post them here or write to me at Toby.Considine@gmail.com.