The Right Time at the Right Place

Smart Energy uses schedule negotiation and schedule coordination to operate systems and equipment at the right time to take maximum advantage of variable energy supplies. As the internet of things grows up, it will move from gathering data from sensors to coordinating things to enhance our lives. The future of business breaks down into smaller entities with stronger missions that coordinate activities over time to support customers as if by a single business, only better. We all took steps closer to these seemingly simple coordination results, at a meeting at AOL headquarters.

For the last decade, the Calendaring and Scheduling Consortium (CalConnect) has worked to improve the interoperation of tools that coordinate schedules. We use their standards to run our personal and business lives, every time we accept a meeting request by email. Their work is critical to smart buildings and smart grids. This week, they demonstrated how to extend this work to support live machine to machine (M2M) schedule negotiations, including schedule auctions. My mind is buzzing with the implications.

Representatives of the US Veterans Administration (VA) were at CalConnect this week. The VA is in the news and under fire this week for failures related to scheduling and appointments. One can look to procedures and people and motivation, but under all is a cumbersome system that makes it difficult to accomplish some essential scheduling functions. These problems encourage employees to augment the system with a variety of out-of-system manual processes. These manual processes present opportunities both for mistakes and for gaming. Tragically, there was some of both.

VA management recognized the problems with scheduling systems well before the current scandals. It takes time to change anything so big. Last year, the VA held a competition to demonstrate standards-based approaches that could not only address the problems they have now, but can also prepare for more powerful stresses on their systems in the future. But knowing they had problems was not the same as knowing where and who the problems were. We have all found that out publicly in the last few weeks.

The story of the VA and open standards and how they hope to transform their monolithic systems in agile systems able to embrace outsourcing, insourcing, and distributed operations, is too long to fit here. I will write of it soon. I had the privilege of contributing to one of the competitors (my team came in third).  This week, the VA and those who hope to work with the VA were at CalConnect.  

CalConnect, now a decade old, ebbs and flows as does any organization. CalConnect was founded in a flurry of activity to address minimum capability cell phones, and worked through such problems as coordinating recurring meetings on a device too limited to compute once-a-week meetings. Today’s phones are more capable than personal computers then, and CalConnect has moved on to the problems of personal calendars in the age of social media. Calendar federation and social coordination bring new challenges.

Five years ago, CalConnect led the refresh of the aging standards for calendar information. iCalendar (RFC5545) is flexible and extensible, and describes key semantics and essential structure for everything you might see in your personal calendar. ITIP (RFC 5546) describes how to negotiate information between calendar-aware systems. You use it not only when you accept an email invitation, but also when that meeting is moved or cancelled.

Three years ago, CalConnect produced vAvailability, now moving to a standard in the IETF. (The Internet Engineering Task Force is the organization that manages the key specifications and communications of the internet.) . VAvailability is used in smart energy to advertise changing schedules for energy supply and for demand response. EMIX (Energy Market Information Exchange) defines contracts for Energy Reserves as financial options linked to vAvailability. OASIS developed WS-Calendar in close coordination with CalConnect.

But that is in the past. This week was exciting for the demonstration of new work that expands the tools for schedule coordination.

This week at CalConnect, multiple organizations demonstrated working interchanges of live schedule negotiations and schedule auctions. I will write more about the new standards such vPoll, CardDAV, and iSchedule later. The news is that this week CalConnect demonstrated three-server three-organization demonstration of standards-based schedule polling and auctions. The essential interactions for resource advertising and exchange were front and center. Direct server-to-server communications of schedules without the usual email were demonstrated, along with specific hooks for authorized interactions between web sites and personal calendars, and between trusted business partners.

Distributed schedule-based auctions are at the core of smart energy, including the budding efforts for interoperable transactive energy agents.

Standards-based scheduling engines will expand the reach and availability of specialized veteran’s services for today’s more mobile population. Open specifications for schedule negotiation can support more efficient and auditable queuing of complex scheduling requirements to be performed by multiple clinics. Distributed schedule-abased auctions will enable the VA to expand services and schedules to incorporate community resources far from the big VA Hospitals.

The next step of computer service is schedules for systems big and small to interact with our lives. The next step of business is improved provision of services across multiple businesses acting a single personal concierge, in medicine and in other personal services.

The tools for this were demonstrated at CalConnect this week. This work has powerful implications for smart energy, for medical scheduling, academic scheduling, and for social media. More later.

CalConnect invites interested organizations and companies to join CalConnect in moving the work
forward. www.calconnect.org

Work Plan for oBIX 2.0

Some of you know that the oBIX Committee (open Building Information Exchange) is meeting again. The work is moving ahead on multiple fronts. We have separated encodings (XML and COAP) from the core specification. We are working on separate transport specifications for SOAP and REST (including JSON). We are doing a refresh of the core specification for consistency and conformance. I am most excited, however about the oBIX 2.0, the enterprise services.

The core specification (1.x) requires each oBIX server to provide a lobby. Clients can ask the server what is in the lobby, and thereby discover how to interact with the system behind that server. Contracts are special purpose agreements that are added to the lobby. Clients can invoke contracts by accessing the elements listed in the lobby. Vendors and integrators can add functionality to an oBIX server by creating contracts to add to the lobby.

Our current plan is to define enterprise services by specifying new types of contracts to place in the lobby. oBIX servers will then state which types of contracts they support, which encodings, and which transports. As of March 2013, we anticipate the following sections:

Energy

oBIX Servers are likely to participate in collaborative energy ecosystems including those managed by Energy Interoperation (OpenADR 2.0) or as described by ASHRAE SPC 201. We plan to incorporate information models and semantics developed to support the US national Smart Grid efforts, including Green Button. Potential contracts include not only energy usage reporting, but projections and commitments as well. We anticipate leveraging the existing OASIS Energy Market Information Exchange (EMIX) Specific information exchange requirements as defined in NAESB REQ 21

Advanced Reporting and Aggregation (Historian)

The historian does not scale well in its current form. A request for, say, a one year history on several sensors is larger and more unwieldy than it need be. It may be necessary to support variations such as projections. We do not want to break compatibility.

Alarm Logic.

This topic extends alarm contracts to include logic for alarms. If A happens followed within three minutes by B. If the cycle between occurrences of A is less than 5 minutes. This is in effect defining diagnostics with interactions between functions. If I am talking to 100 oBIX servers, I may want to apply that diagnostic to every AHU attached to each of them.

Building Information Models (BIM)

In buildings, control systems operate building systems. Building systems support the various spaces in a building, whether securing them, monitoring, them, or conditioning them. The relation between a building system and spaces in a building is described in a Building Information Model (BIM). oBIX BIM contracts will describe how an oBIX server will make BIM accessible, and how to apply BIM as a semantic framework for the control points.

Enterprise Scheduling

Enterprise Scheduling applies the semantics of WS-Calendar to schedule interactions with building systems. This includes a notion of service oriented schedules instead of the control oriented schedules as today. (Example: Request room at temperature by 8:30 rather than Request room to begin heating at 8:10). This is likely to use the same semantic frameworks as security, i.e., to specify a room rather than a thermostat. Enterprise scheduling is made possible in part by the BIM framework as described above.

Security Composition

oBIX 1.0 defines a monolithic model, all or nothing, for access to points and settings. This access should be limitable by role and by organization. Advanced security contracts will define a means to define policy frameworks for secure access to oBIX servers. This is likely to be an intersection of roles, i.e., integrator, operator, tenant, guest as applied to business function. In buildings, business functions are defined by the spaces they are in. The relation between building systems and space can be found through reference to the BIM.

We will not define a mandatory set of roles, or a mandatory framework, but instead define a means to apply notions of space (say a particular tenant) and of role to access to an oBIX server. We anticipate a means to discover the roles available on a server, to map those roles into a discoverable space, i.e. BIM. This topic includes addressing federated security, and may include how to apply SAML, XACML, and similar specifications to oBIX servers.

Please contact me if you would like to join in this work.

Energy and the Microsoft ROC

Yesterday I had the pleasure of a tour by Darrell Smith, Director of Microsoft Facilities & Energy, of the Redmond Operations Center (ROC). Facilities & Energy provides internal support; it is not a product line. The ROC applies Big Data to the operations of buildings on Microsoft’s home campus. In concept, the ROC is much like the Enterprise Building Management System (EBMS) at the University of North Carolina that I have written of. The results at Microsoft, though, are much more successful.

Darrell avoided the trap that we fell into at UNC, the trap that says that until the in-house enterprise system can control all the systems, it is a failure. In the Redmond Operations Center, Microsoft concentrated first on data mining and operational improvement. By Darrell’s definition, his system will be mature when it does control as well, and may never reach that level of maturity. In the meantime, he is finding wins every day by applying analytics to improve operations.

The center produces two kinds of analytics, alerts and reports. Each of them is focused on finding ways that Microsoft is wasting money every day, and fixing them.

Everybody who works with building systems is aware of the alarm spam that traditional systems send out. Turning off is an Alarm. Turing on is an Alarm, Catching on Fire is an alarm. Build alarms are events with almost no meaning. The Redmond system reads the low level protocols and harvests state information and alarms. The system also gathers other factors from a number of sources, including essential weather information.

To generate Alerts at the ROC, building engineers instead describe patterns. The system gathers a mass of information from each system and air handler tracked. The in-house engineers create queries that identify such issues as short cycling, or incomplete closing of dampers, which they name Faults. The engineer carefully examines the operation a single air handler, or a single building to find a problem. This problem is then described by means of a query that brings back this problem and similar faults in other buildings. For each fault, a cost is assigned by the system based on the size of the system, how much energy it uses, the system’s operating schedule, etc.

In the ROC, all active faults can be seen by building or by system, and can be sorted by cost or criticality. Generally, expensive ones are fixed first. Each work order is tagged with the cost that is being avoided by a timely fix.

Because Microsoft has a learning culture, this process reduces energy use even in the buildings not yet accessible to the ROC. Building mechanics fix problems early in monitored buildings and can see results. They share what they have learned with others in buildings not yet monitored, and the underlying faults are fixed in them, too.

Reports, as I understand them, look for more inchoate patterns. A report can describe many attributes of system or group of similar systems. Reports reveal operational outliers, i.e., the air handler that runs all night, or the system whose damper opens unexpectedly. A newly trained mechanical engineer may take a day or two to define a report. Once defined, it can be run again and again, including for other systems and for other buildings.

Think for a moment of the most powerful thing you have done with a spreadsheet pivot table. Now consider applying that task and that visualization to raw operating data from your buildings every day, and using the results to generate work orders. This is what the Facilities and Energy group has done in the Redmond Operations Center. They find real problems in operation and configuration of building systems every day, price them, and fix them. That is enough, even without control.

Microsoft is doing other things with their own facilities operations which I may write about later. But today, I am marveling at the data-based operation of facilities.

Easy integration of the Internet with Things: Calendar Subscription and Syndication

I use Outlook in my day to day life. It shows me an aggregate calendar, with meetings I accept at the office (one account) meetings I accept not at the office (another email account) and two corporate calendars: one based in Exchange, and one in SharePoint. When I was working on the national smart grid roadmap, my Outlook showed the calendar of that SharePoint project as well. In Outlook, I can turn each calendar off or on, and when aggregated, each appointment was a different color by source. I live by Calendar aggregation.

In my Phone, which happens to be an Android, I used to have a calendar for each email account. Each has different security set-ups and realms. Each source has different policies about sharing calendar on distributed devices. It was easy to miss appointments when on the road as I switched between different companies.

With an overnight upgrade pushed out by my phone company, this changed to a single calendar. That single calendar is color coded, showing the source of each event. Some of the things that are on my phone are “not quite meetings”, when GMAIL has interpreted something as a meeting although I have not accepted the meeting. The rules GMAIL uses for this appear to be similar to, but not identical to, the workings of Google Calendar.

Because I speak regularly in front of large audiences, I am always working in concrete examples of abstract issues. I use my phone as a prop when talking about the problem of smart homes and vehicle charging. The narrative goes as follows:

• This phone manages an ever changing set of security issues as dictated by my various calendar providers. Those security changes (passwords, policies, …) are things I do not want to build into my home. “I changed my password at work today—now I have to tell my refrigerator and my car” is not sustainable.
• Whatever the security policies, the calendar that I can see on my phone is semi-public, i.e., it has already been de-securitized for sharing. It may be a top-secret meeting, but it is now in a state wherein I can look at it over dinner and say “No, not next Tuesday.” It is, in effect the external face of my personal (corporate) schedules
• The phone is a “syndication point”; it syndicates each of the calendars that I subscribe to, to tell me what to do today.
• The OLED screen on the magnetic computer stuck on the front of the refrigerator is another syndication point. It can subscribe to feeds from my android, the wife’s blackberry, and the kid’s iPhone, to develop the syndicated household calendar.
• Note that each syndication point chooses what to share with downstream subscribers; the household calendar does not necessarily look like the sum of the upstream calendars. Policies about privacy and sharing, and key words that make a meeting “private” are managed upstream, and each syndicator can apply its own policies atop those.
• There is no need for end-to-end security, no need for shared secrets the length of the chain.

I may choose to create additional information within the house. The party, family church, Sunday afternoon football viewing may all be events originating in a house-based schedule and not appearing in any of the subscribed calendars. Or perhaps the household calendar is just another subscribed calendar fed into the syndication. That is an implementation detail that no one but the magnet-on-the-refrigerator computer needs to know.

My phone Calendar, then is an aggregation of calendars that I potentially syndicate out to other calendars.

If we flesh out the needs of the electric car, negotiating expensive fast charges and cheap slow charges, it needs to negotiate only with this household schedule. It may learn its own secrets, such as how far I drive when I go to choir practice. It may learn off-the-schedule stuff, such as that I frequently stop at the bar (an extra 10 miles of driving range) on the way home from choir practice. It does not need to share that information upstream to my house, or with my electric utility. It merely uses this information itself to make decisions autonomously about charging strategies.

The car has its own calendar for sharing. Based upon what it has learned, not only about my schedule (from the house) but about my habits, it can create a schedule of charging needs. It syndicates *that* schedule to the house, and negotiates with the house for access to market. The house syndicates the requirements from all the systems it supports, and uses them to guide it market position in energy.

The same calendar may be syndicated in different ways. The house subscriptions may include multiple children of the same syndicate. The house may learn from its subscription to my Android that I am out this evening, and do not need heat and lights in my rooms. The house may learn from the Calendar in the car, that I need power before this evening to support that same trip out. It is OK for the syndication to affect the houses buying position twice. There is no need for round-tripping or end-to-end tracking. The information is consumed, decisions are made, and market positions are created.

OK, this is a nice tale of autonomous systems relying on aggregated schedule streams to create time-dependent market positions. It is time to start thinking about Calendar Subscription. Aggregation, and Syndication, and of touch-less integration with the Internet of things.