Busy day on the Standards Front

in ,

Today was consumed with what is either standards minutia or very big stuff. I am too tired to write of anything else, so let me explain what’s afoot.

Scheduling

Building system schedules today are too involved, and require too much process information. If I want to meet at 9:30 tomorrow morning, I want the room air-conditioned and ready to go by 9:30. I don’t want to learn about heat times, cool times, warm-up times. Be ready. By 9:30.

The enterprise standard for scheduling was developed years ago for use in email and its name is vCalendar or vCal. vCAL can not only schedule that meeting tomorrow, but can schedule it every two weeks, or on the second Thursday of every month, or even every two weeks except in a month that has three Tuesdays. vCAL has all the flexibility one could want.

vCAL was refreshed for internet transmission and stand-alone download into the internet calendar standard, or iCalendar. When you book airline tickets and it says “click here to add to your calendar”, you are using iCalendar. Apple muddied the water by writing the program iCal to use ICAL, but it us really the stand-alone version of vCal.

In early 2001, an attempt was begun to define iCalendar in XML, xCalender. As far as I can tell this project stalled out in 2002. oBIX has been meeting for some months to integrate xCal into scheduling system scheduling.

Today, I received the suggestion that I look at hCAL instead. hCalendar (short for HTML iCalendar) is a Microformat standard for displaying a semantic (X)HTML representation of iCalendar-format calendar information about an event. hCAL is designed for display, but it has a socket in which to nestle additional XML information. This seems nicely pre-adapted for oBIX, as well as DR (demand response) events. hCal was designed to allow parsing tools to extract the details of the event, and display them using some other website, index or search them, or to load them into a calendar or diary program.

Today, I am trying to get oBIX to make decisions as to how to use viCal, to share that decision with OpenADR, and to move on.

EBMS the Next Time – Agents and Enterprise Interactions

in ,

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

in ,

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.