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

Tiny BIM Here and Now

The use of Building Information Models (BIM) has transformed the way that buildings are designed and constructed. Those projects that commit fully to their use deliver higher quality buildings at a lower price. Finith Jernigan has written on how using even incomplete or partial BIM can provide worthwhile results, an approach he describes in his well-regarded book “Big BIM, Little BIM.” While traditional of Big BIM requires a strong commitment and organizational change, Little BIM requires a smaller commitment, and can offer an organization just starting to consider the use of BIM advantages in planning, design, and in operations. I am not going to summarize Jernigan here—the book is small enough and valuable enough that you should just ahead and read it. In this post, today, I am going to write about something smaller, and something that can reduce costs and improve efficiency. Today, I am considering Tiny BIM.

There has been considerable effort in the last few years to standardize the information hand-off between a Big BIM project and the ongoing maintenance and operations of a building. Conceived of by Bill Brodt at NASA and Bill East at the ACE Engineering Research and Development Center (ERDC), The Construction [to] Operations Building Information Exchange (COBIE) defines the data that needs to be exchanged. Most of today’s Maintenance Management Software (CMMS) is able to import a COBIE data set.

Part of Bill Brodt’s original vision was that COBIE can be described as the spreadsheets you would make yourself as you went around and commissioned a building. Each piece of equipment could be catalogued whether or not there was a BIM available from construction. The information from those spreadsheets could be brought into a CMMS just as is information originating in Big BIM.

Unfortunately, this notion of spreadsheet harmed the perception of COBie. Because Excel spreadsheets use an internal XML format, an Excel spreadsheet with multiple tabs was declared to be *the* XML standard for COBIE. COBIE produced in spreadsheets rarely had the cross-linking and validation envisioned by the creators of COBIE. Many programmers received COBIE in Excel form, and wrote off the specification as unworkable.

Last year, the ERDC addressed this issue by formally defining XML schemas (XSD) and a strong semantic typing for COBIE, This specification has the misleading name COBIE Lite. COBIE Lite makes COBIE information much more valuable, as it makes COBIE informational more useful as a general purpose exchange format for building operation. It is now possible to automate checking if a COBIE information set is valid and coherent. (Some more jargon: the formal semantics and validity checking for COBie are formally specified using the OASIS Content Assembly mechanism, hereafter referred to as CAM.)

Now I must circle back. The BIM process long ago defined SPie, the system properties information exchange. SPie was developed so that designers using BIM could compare products and place information about the selected product directly into Big BIM. SPie defines the format for providing faceplate information for any system in a building. SPie also defines the physical dimensions of equipment. A full SPie set includes spare parts and recommended maintenance for a piece of equipment.

Good commissioning discovers and reports most of the information in SPie. If you consider the COBie spreadsheets, then a single SPie record would create a row on the equipment inventory, and several rows on the recommended spare parts tab, and several rows on the recommended maintenance tab. I suspect that the ERDC will soon apply the CAM used to create to define an XML format for SPie.

Small, well-defined information exchanges are at the heart of just-in-time data exchanges. It is not a big leap to imagine manufacturers providing an URL for each make and model of equipment. Systems that need this information could request this XML document when needed. And that at last gets me around to Tiny BIM.

A growing number of owners of large buildings and campuses are putting machine readable tags onto equipment. An early use was a bar code that would be scanned to verify that the mechanic was actually there. RFID tags are sometimes used, especially when they were used as part of construction. As smart phones become standard equipment, more and more organizations are using QI Codes.

QI codes are best known for their use in magazine ads—“Scan here for more information.” Although there is no requirement, QI codes are generally used in ways that assume connectivity—go here on the web and get this document In maintenance Apps, the QI code verifies which piece of equipment is being worked on. Inside an app the QI code may call up the supporting information such as previous work on this equipment.

In the future, manufacturers may tag their equipment with a QI code that points back to the SPie record. Local software could read the SPie information and deliver key information right to the technician. Updates a,d service alerts could be readily available, in the field, even in an non-commissioned building. Commissioning a building without BIM would become, in part, find the QI code and scan it.

Tiny BIM puts needed information into the hands of those who needed it right away, with little training or up-front costs. Tiny BIM creates a space for whole new classes of maintenance applications. Tiny BIM increases the value of existing energy analytics apps. Tiny BIM can stand alone, or as an adjunct to Big BIM, using ongoing maintenance to improve the BIM maintained in the CMMS.

I think Tiny BIM is coming soon.

Finding a Needle in the Internet of Things (part 1)

Things cost what they cost to install. Ongoing charges are, in the short term, fixed. Value may be the only thing you can control. In the Internet of Things, value will be determined by how many ways you can use that Thing. Value will be determined by how many different uses can use that thing. Some of those users will be other things.

Things (as in the Internet Of…) tend to be commodities. One thing is inherently like another. Once I have more than a small number of things, I need a way to distinguish between sensors, between pieces of building equipment, and even to distinguish between tangible services such as catering and transport services. One of the first places that all of us have seen things on the internet is in conference rooms, vehicles, and tools as they are scheduled within enterprise scheduling systems.

Discovery is essential to agile integration. If systems can discover each other, we do not need to map them. If systems can understand what they discover, they can integrate themselves. One of the requirements is common semantics, that is agreements as to how something is described (or describes itself). This post is about directory directory services for the internet of things.

In Calendars, people are identified by vCards. VCards are deeply embedded in CalDav, stil the most common protocol for writing new Calendar Apps and user interfaces. Many email systems support attaching your vCard to each outgoing message. VCards are electronic business cards, and just as in traditional business cards, different people choose to include different information on them. Also like paper business cards, various companies and organizations have developed their information and format standards for vCards.

After email, the most common place to find a vCard is in a directory. There is a deep historic link between the Lightweight Directory Access Protocol (LDAP) and the vCard. LDAP is used to manage security as well as directory services in the biggest organizations. The link between directories and security is as natural as is role-based security. LDAP records include have the same variability as does the vCard standard. At some level, though, LDAP is the thing you use to get a vCard.

LDAP supports diversity of information returned, including security on particular aspects of the information. Over time, a varied set of what I will call here, for brevity, vCard profiles have been developed. These often have object-type characteristics. For example, the inetOrgPerson (RFC2798) is defined as a standard set of extensions to the organizationalPerson as defined in the ITU standard X.521. Many colleges and universities have collaborated to define the eduPerson to handle students, grad students, and faculty.

In LDAP, there is a long history returning different information about the same object in different security contexts. At universities, an LDAP will return different information when asked about a student or about staff, even when the target is the same person. Just as in medical information, the portions of student information that can be exposed to query vary widely by querier and context, and are controlled by federal privacy law. There are many security contexts, including when domestic relations go wrong, under which access to some attributes of a particular directory entry is limited. LDAP also supports multi-valued attributes easily. This is in sharp contrast with the normal expectations from, say, a SQL query.

In calendars, things that are not people are designated as Resources. Improvements to Resource vCards is a long-standing project of CalConnect. Some Resources may have a schedule, but not be schedulable. This usually means that it is scheduled by someone else using means you do not have access to, but to the user, it is not schedulable even so. Schedulable Resources may use vAvailability to indicate when and how they can be scheduled. It is of course possible, even probable, that different entities will receive a different vAvailability from the same Resource.

It will come as no surprise to my readers that I now come around to building-based resources. These are most frequently public rooms and building systems. Public rooms are invited to meetings as are other attendees. Smart buildings can optimize energy use while preserving amenity if they know when and by whom the building will be used. In a related post, I will describe how vCards for building-based resources will be standardized.

A key consumer of secure directory services for systems will be other systems. With discovery and directory services, they can find each other to interact. Through developing calendar standards, including vAvailability, they will learn when they can interact.

Secure discovery, self-integration, and autonomous assembly will be part of how we maximize the value of the internet of things.

Must retail energy users be mere price takers?

A significant wedge between those seeking to maintain the current regulated prices accompanied by DR and those looking to move to transactive energy for a self-regulating grid is the notion that retail customers are all mere price takers. A price taker watches the market and either buys or does not buy; he takes the prices the market offers. Some see that this “lack of power” can only be addressed by regulating the prices offered. This leads back to today’s model.

Committed positions break this model. A retail customer who commits to buying this much power at this rate for a given time period in the future establishes a committed position. With a committed position, if the customer needs more power at any time than the commitment, then the customer must make up the difference at the spots rates. If the customer needs less power than the commitment, he can only sell back the difference at spots rates, and then only if he finds a buyer. With this assumption of position risk, the customer also gains the ability to interact fully with the market.

In today’s regulated markets, the greatest value of energy storage is as a forward hedge by the energy supplier. The entity that stores the energy on premises cannot make up the economic value required by the storage. This storage is of value as a hedge for the retailer, not as an asset for the customer. This economic imbalance reduces the value of other distributed energy assets, such as distributed generation, as well. By limiting the value of energy storage to only the hedge value for the supplier, distributed energy assets are always undervalued.

Committed forward positions change this equation. A committed forward position in power is a contract that the buyer will purchase this energy whether or not he uses it, and that the supplier will provide the power no matter the market conditions at the time contracted for delivery. (Let’s leave aside for now the issues of true emergencies, liquidated damages, etc.)

When the market allows committed positions, the buyer is rewarded for better understanding his own energy needs. A buyer who is able to plan his energy use could package a series of positions, and take bids from the suppliers. These bids can be considered in the larger context of the business, such as labor planning or the needs of seasonal manufacture. A committed forward position then provides the buyer with choice while limiting risk in price and availability.

Committed purchases enable the buyer to take full advantage of his own distributed energy resources. Energy storage becomes a way to manage purchasing commitments, sometimes using excess energy in the commitment, sometime shaving peak use to stay within the commitment. Distributed generation is managed locally, where the knowledge if value, process, and commitments is greater.

Committed purchases of power move the retail energy buyer beyond the role of a mere price taker, to that of a full market participant. This devolves considerable autonomy to the end nodes of the grid. This increases the rewards of investing in distributed energy resources for those customers that value power surety and economic arbitrage. Because such investments are made by single sites, they will help us move to normal, innovative markets in energy technology.