It’s all about the connections

Angered and motivated by my experience preparing a large state university for Y2K, I made my public entrance to the public building systems space in 2002. Y2K was a crisis when it was anticipated that any program that used a two-digit year in the date (as in 99, and it was all of them) would fail after the year 2000 (when the year might be 01). State universities build using low bidders in accord with state construction law, and the University of North Carolina had accumulated a hodge-podge of systems for building operations, steam distribution, chill water distribution, cogeneration, and electricity purchases that barely interoperated. Worse still, the interoperations were fragile, and upgrading any one system would break the connections with any number of other systems. I simply wanted stable inter-system connections that did not break with any minor change to either system.

We were using system interoperation to address problems of smart energy. Back then, an operator would log into a utility web portal in each afternoon and download a CSV file with 24 power prices for the next day. We would then adjust the interactions of all these incompatible systems to align with the day’s prices. When the process broke without warning, we found that the file now included 96 15-minute prices. The utility had given us no warning. When asked, the utility replied that we should not worry, that they had no plans for 15-minute prices; but had merely upgraded their software. Connections without some sort of machine-readable contract are not reliable.

In the early 2000s, system interoperation meant XML and messages. Most accounting and line of business applications were exchanging XML. I worked with many industry leaders to define OBIX—which then became the heart interactions of the Niagara system and others. The effort made it easier for one HVAC system ti integrate with another, but was rarely used to enable enterprise interaction The whole building industry knew we needed an easier and more stable way to make connections between systems.

A decade later, the smart grid recognized that smart energy must be a conversation between buildings and power grids. Standards for M2M schedule negotiation, for energy market information, and for service-oriented energy came out of that, with a central place held by OASIS Energy Interoperation. OpenADR 2.0 and TEMIX are the two largest and most successful message exchanges based on that work. These connections work because they are requesting a single service, not trying to replace local control. Standard purpose-built connections help us connect systems, but only if they work for that single purpose.

Connecting power grids to building systems became easier, but I was consumed with connections with a smaller scope. Green Registrar’s Offices rely on interactions between class scheduling and building operations. Buildings adjacent to a BMS with a weather station all want to use that weather data to improve their own operations. BAS systems can tell physical security and emergency management systems if a building is occupied. Door locks and foot traffic systems can tell a BAS when to turn on. For three years, I worked on BIFER, Building Information For Emergency Responders, with target users from fire control to hazmat response. Each connection between systems increases the value of each system.

We have just begun to discover the lightweight interactions that should be easy to create and use. COEL-based applications would like to interact with conference room environmental controls to evaluate how alert attendees are before critical votes. Smart streets want to know when a mass of people is leaving a building. Easy-to-create connections are the path to create tenant value and to build smart cities.

Three years ago, Anto Budiardjo asked me to work with him to define mechanisms for defining and publishing limited connection points between systems. Anto was the first person that I was told to meet when I began work on OBIX. Anto’s new company is Padi, the Indonesian word for rice. Anto’s vision was to easily connect all the grains of rice in a bowl. Too many sophisticated interactions today are lost when one system or another is upgraded, and the original integrator is no longer on site. The mechanisms we defined had to not only be easy to use, but be repeatable, cybersecure, and self-documenting. We met with anyone who would listen.

Anto and I worked with the Digital Twin Consortium to build their model of systems of systems, work that was mostly defining capabilities for connections. Digital twins use intersystem connections to enable AI (artificial intelligence) and ML (machine learning) to constantly monitor cyberphysical systems. These tools can detect changes in configuration or performance by comparing actual performance of a system with a simulation, or with an emulation from yesterday, in real time. Connections between systems are the foundation of digital twins.

Related work, with a longer-range focus, is defining the future of the Internet, sometimes called Web 3.0, The Spatial Web, Architecture and Governance Working Group looks to combining the Internet of Things and the Internet of Systems at the edge, without required reliance on central monitoring and control. IEEE P2874 has many parts, from decentralized identity and security, to edge-based decision-making, to support for virtual and augmented reality (VR and AR). The Spatial Web will encompass ever-growing diversity of systems through use of common connection definitions.

The result of this work is the Connection Naming System / Connection Profiles (CNS/CP), a simple specification to create a control plane for the Internet of Things. (You can see the current draft at https://github.com/CNSCP/specification/blob/main/cns-cp.md.)  We have shared this work with the T2T (thing to thing) committee of the Internet Research Task force. We plan to submit CNS/CP to be a standard internet specification (RFC). CNS/CP will connect buildings to enterprises, systems to their twins, and maintenance personnel to augmented reality. Connections will continue to grow more pervasive and are central to future systems of systems.

We invite you to review the specification and provide feedback, comments, and suggestions. Let us know what you think.

Bidding for Schedules—VPOLL and VAVAILABILITY

Last week I watched live multi-vendor demonstrations using the new specifications vPoll and vAvailability. These extend calendar interactions to support live negotiations about schedule and performance. These negotiations can be machine-to-machine (M2M) or augmented by human input. These were not applications, these were live interactions between mainstream calendar servers. The testing used simple user interfaces, just enough to operate the tests. These simple information exchanges extend existing systems for schedule negotiations into automated polling and bidding.

As I have written before, I spent three days with the Calendaring and Scheduling Consortium (CalConnect) at AOL headquarters in the suburbs of Washington DC. Although the meeting was technical, it was against a backdrop of a scandal in the VA that is summed up, by the press, in the single word “scheduling”. Members of CalConnect went quietly about demonstrating their new work, based on iCalendar, that points to a new way forward, one that extends schedules negotiations into automated polling and bidding. CalConnect rules forbid any direct discussion of who was at the meeting, and what their precise interactions are.

CalConnect works to extend the reach of existing Calendar and Schedule systems (new specification development) while testing whether they work in exchanges between vendors with different code bases. Sometimes the code is changed, and sometimes the specifications.

ICalendar (RFC5545) defines a common grammar for creating information exchanges information related to schedules and defines a several such exchanges. The iCalendar event (vEvent) is familiar to anyone who has added a meeting to their calendar by clicking on a web site or opening an email. ICalendar defines other common exchanges such as tasks (vToDo) and alarms (vAlarm). OASIS WS-Calendar describes how to use iCalendar inside service oriented exchanges, with a focus on describing sets of schedule information that hang together in a series. There is a growing use of WS-Calendar world-wide in energy markets and smart grids.

vPoll is a new iCalendar exchange that uses iCalendar grammar to present a choice. Assume it is a simple meeting (vEvent). A vPoll could present a number of meeting times and ask the potential participants to vote. This is different than asking for a summary of when a recipient id currently scheduled (vFreeBusy). A recipient may choose to vote for a time knowing he can cancel a meeting. A recipient may be keeping that afternoon free for a visitor from out of town—even though nothing is scheduled. A recipient, for security reasons, may choose not to share any free-busy information.

vPoll further defines how responses go back to the originator. A poll typically includes an ending time for polling. The originator may choose to schedule the meeting in accord with the most votes, or when a few key personnel can make it or for any other reason. vPoll does not define the business rules or the application, just the messages and message pattern.

vPolls may be tied to prices rather than to votes. Maybe the single best price, or the three best prices, get invited to the meeting. Maybe prices determine the venue. The vPoll specification defines the BASIC Poll Type. Others will be defined later for specific use cases.

A recipient may choose to respond to a vPoll with vAvailability. Availability uses recurring patterns to indicate when something might happen, and what it might cost. Consider a meeting room in a commercial building. It can be scheduled during business house, using the calendar, for free. After hours, because of additional security and custodial needs, the same room can be scheduled for $200 / hour with a minimum charge of $300. These schedules can be expressed with vAvailability.

So far, I have described vPoll using only meetings. A Poll can also include tasks (vToDo). A task is often distinguished by its required completion time. Recipients can use their calendars to bid on various completion times. Presumably, bid for completion tomorrow will be more costly than a bid for completion next month. VPoll can gather the bids and present them to the originator, to choose one.

Most of us think of calendar communications (ITIP) conveyed inside email (IMIP). We open email and we accept the iCalendar request. At the CalConnect meeting this year, multiple participants demonstrated interoperable iSchedule, used for direct server-to-server communications. This promotes the polling described above from the personal to the enterprise. I will write more about iSchedule later.

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.

Slim BIM: The Middle Ground between Document and Service Part 2

In my last post, introduced Slim BIM and the critical need for shared configuration to speed development in the building systems. This post extends that conversation.

A report from NREL, delivered last Spring, defined the Building Service Interface (BSI), a standard for interacting with building systems from non-building applications. That report recommended that each BSI be able to share a light-weight BIM, i.e., to be able to provide on demand a description of the space it supports, the systems it controls, and the relationship between systems and space. In the future, this light-weight BIM is likely to be part of minimum commissioning standards to get LEED or other environmental certification.

Mary Ann Piette, Staff scientist at Lawrence Berkeley Labs and Director of the Demand Response Research Center, has called these light-weight models “Slim BIM”. Today, there are two well-known specifications for Slim BIM: COBIE and GBXML.

Green Building XML (GBXML) is already well known to the building automation community. GBXML was originally developed to prepare energy models. GBXML has an easily used schema that is maintained by the non-profit Open Green Building XML Schema (gbxml.org). GBXML has become the de facto standard for exchanging information between with engineering analysis tools. GBXML is typically produced by CAD software including applications from Autodesk, Bentley, and Graphisoft. GBXML is used by energy modelers, HVAC design tools, ductwork CAM tools, and many others. GBXML is so well accepted, in part, because its schema is specified using modern tools that are easy for software developers to use.

COBIE, the other Slim BIM, has found a harder path to wide acceptance. Much of the COBIE produced today is of poor quality and semantically incomplete. Within BIM, information is exchanged using the Standard for the Exchange of Product model data (STEP). STEP is able to convey almost any kind of information, including detailed 3 dimensional data. The problem is, most users of this information do now want complete specification and wide extensibility; they need terse, validate-able information exchanges. Most users do not want detailed purpose-built information exchanges developed slowly in committee; they need ready-to-use exchanges that suit a variety of purposes. COBIE’s slow uptake epitomizes the cultural and technical differences between the engineered world and commercial IT.

COBIE would face less cultural resistance if it looked more like other inter-domain information exchanges. Some proponents have claimed that there is a COBIE XML format already. COBIE was initially described as “a spreadsheet of the data you need to operate the building”. Accordingly, standard Excel templates for COBIE are available. Today, the XML representation of COBIE is the XML representation of a Microsoft Office document. As this format is not very useful, most COBIE is produced as hard to understand, hard to verify CSV files or STEP text. The only COBIE verification tool that I know is offered by Onuma Planning Systems (http://www.onuma.com/products/OpsAndCobieValidate.php).

The Army’s Construction Engineering Research Lab (CERL) is a pioneer in using construction information to improve building design, acquisition, and operations. To CERL, improved operations are central to sustaining facilities not only during lean budgets, but also to sustain mission support. CERL’s PROJNET system, used by thousands of organizations, is the leading producer and user of COBIE. PROJNET maintains an internal XML representation of COBIE, one that is not now part of the specification.

When CERL releases its XML representation of COBIE, I predict it will soon become the dominant form for information exchange. A version of COBIE that is as easy to use, and as clear to understand as the GBXML schema will find rapid acceptance throughout operations. CAD vendors that produce poor or incomplete COBIE today will up their game. Current CAD systems require requires a few simple early design decisions to be able to produce good COBIE; designers who skip that step will find themselves at a competitive disadvantage.

Even the mash-up approaches to BIM will benefit. A CMMS that can export well-formed COBIE will be able to export information to Cloud-based BIM. Mash-ups between 3D building models and energy management systems will become common and expected. Well-formed, validate-able COBIE will make building information more visible than it has ever been, visible to the right user, at the right time, with the tools of that user’s choosing.

As these approaches replace the one-time, hard to perform integrations of today, BIM and system integration will become rapid and easy. Cloud-based techniques will reduce the costs of technology changes within each building at the same time as they expand the owner’s awareness of these changes. Shareable configuration is the path to rapid secure service integration.