Odds and Ends: Looking to 2015

I have been quiet here for too long, and have made a New Year’s resolution to get back to writing. Many of my recent projects I cannot write about, for competitive or contractual reasons. Still, there are some big themes coming to light, ones that I have been writing about for years, and that are now hitting the market.

Microgrids, broadly defined, have been a place with a lot of demonstrated movement in this last year. The most expensive thing about the obsolete grid is the assumption that everything happens centrally, and that the local node does not have any responsibility. This might be true if our world was run on incandescent light bulbs and ceramic space heaters. In a digital world, aggregate load and rhomboidal curves are growing problems, ones that cost a lot of power and shorten the lives of a lot of equipment.

Storage remains the most important enabling technology for alternate and distributed energy. The storage symposium at the California Energy Commission on December 1 brought some powerful choices into the open. Grid-scale storage is important, and will grow more important. I think that neighborhood scale, and even commercial building scale storage will have more effect in the long term. Look to announcements in the mid-year.

Smart water and smart energy continue to entangle themselves. Pumped water is pre-consumed energy, stored for future use. Reliable distributed energy fits naturally with reliable distributed water pumping, which is the key to avoiding sewage spills. This challenge has been met with portable generators and other technologies that require nimble deployments of work forces. Batteries with up-front capital costs and life spans of only four or five years, don’t make sense here. I look to experiments with 25 and even 45 year storage systems in 2015.

Golf courses have a reputation as despoilers of the environment, with over fertilization and chemical pest control leading to run-off and despoliation of habitat. For years the best practices in turf management have made that reputation un-true for the best run golf courses. Look to a combination of distributed energy, energy storage, water pumping, and the DC club house to appear at selected locations this year. Golf courses may be just the right size to lead the way in new microgrid approaches.

New players keep cropping up applying digital signal processing to power distribution. Early players, some of which I have written about before, have struggled to connect work in their labs to customer service oriented organizations. Early adopters are scared off by costs that have not dropped yet, and not quite understanding the offerings. New players like 3DFS are preparing production offerings. One of these guys is going to make it big, particularly in light industrial or commercial settings which rely on motors.

The high cost of per-site integration remains a brake on microgrid deployment. Semantic integration is going to be critical to reducing this integration cost. Maybe this is the year…

I hope to be more diligent in writing this year. Keep those notes coming.

tc

Finding a Needle in the Internet of Things (part 2)—Buildings and Building Systems

In a previous post, I described how vCards are used throughout standards-based scheduling and calendaring systems. Many different vCard standards coexist in today’s organizations. I also described how directory services, especially LDAP (the Lightweight Directory Access Protocol), are the well-established means to enable wide secure access to the information in vCards. In this post I discuss current efforts that will expand these existing standards to support buildings and their systems.

The most frequently scheduled building-based resources are 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.

An enterprise scheduling may include hundreds of schedulable conference rooms. These resources are generic to some extent, but the potential scheduler would like to filter the list. Show me the conference rooms that are near me, and that will seat at least 8 people, have an internet connection, and have a projection screen. If there is a cost, show me what each costs per hour.

Two things stand in the way of adding this as a standard function. Today, there is no standard for what the names of each of these features is. In other words, there is no Resource vCard standards for rooms. The second is that there is no source for this information. Few want to take on an additional data maintenance task to enter this information or to keep it up to date. Fortunately, there is a solution to both of these problems, and that solution is BIM. More particularly, the solution lies in COBie Lite.

COBie Lite describes a strongly typed and validateable data model. COBie Lite has been stripped of all process, it does not matter what the source of the information is. The information in COBie Lite can be exported from the BIM used to design and build a building. COBie Lite provides a formal definition of the information that should be collected during commissioning. COBie can be imported into all of the major Computerized Maintenance Management Systems (CMMS). Today these systems are roach motels holes of COBie—data checks in, it doesn’t check out. That can and will change.

There are many sources of COBie lite. In each of them, the information is created or maintained to support an existing business process. A standard transform of COBie Lite can produce all the information needed for a standard Resource vCard for rooms. I call this standard the BIMcard.

Building-based systems also face problems of dynamic integration. Traditional building management systems are highly proprietary. Even when fronted by standards-based middleware, say a Tridium JACE exposing oBIX, it is still hard to integrate with business functions in any scaleable way. Let me be clear what I mean by scaleable. A BAS might take one engineer one week to link up BAS and some fixed enterprise functions. To link up 5 buildings might take a single engineers 5 weeks, or a 5 engineers one week. If it was a scalable process, we might expect the 5 engineers could integrate 100 buildings in two weeks. If the buildings can integrate themselves, that number goes way up.

A common BIM-based model provides a path forward. A commissioning report can produce an equipment-only COBie-based BIM. If there is a building model from construction, no matter how incomplete, it can provide a framework to host that COBie-based BIM. A profile for Building System Resource vCards can be defined based again upon COBie Lite. BIMcards, then become the searchable entrée to the systems in buildings. It is not hard to imagine BIMcards for temporary equipment, wherein they can register themselves in the building.

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.

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.