We already know how to create responsive integrated buildings ready to respond to occupants and to the volatile energy supplies of smart energy. We don’t know how to use our current methods in more than a few buildings in a few places. We don’t know how to scale.

Choose any mix of technologies and protocols you like. Choose exotic technologies choose banal technologies. Hire a number of good engineers, or a few great ones, to stay on site for a long time. Develop custom software to tie things together. Purchase building system middleware.

The problem is that we don’t have the resources. We can’t find enough engineers, and the American education system produces fewer every year. The process is not suited to change; introduce a new system and re-start the integration. Change tenants, or upgrade the business software, and re-start the integration. It costs too much the first time, in dollars, in attention, in time; it costs way too much to do it again as things change.

In Cupertino last month, CalConnect discussed calendar resources. Resources are those things that are not quite smart enough to handle their own calendars that we invite to meetings. Like upper management, someone else watches the resource’s calendar, accepts invitations, and resolves schedule conflicts. Unlike upper management, resources are interchangeable. That is they are interchangeable until you have specific requirements.

Consider arranging the resources to host a meeting: a Conference Room, a Phone Bridge, a Projection Screen, possibly a catered Pot of Coffee. In the corporate calendar, I might invite each to a meeting. Resource specification addresses the problem of how to select the correct ones.

Assume that all meeting rooms are listed in the enterprise calendar system. Each room has a capacity (10 people. 25 people. 400 people). Some Rooms have a Projection Screen and some do not. Some Rooms have a permanently installed Phone Bridge. Some Bridges can be booked, causing event support staff to put one in the room. Some rooms may not have a phone connection; even if the Bridge is brought in, it will not work.

The meeting organizer wants an available room for 35 with a phone bridge, projection screen, and coffee. We want to be able to use off-the-shelf software to select the room. For this, we need standards for calendar resources, standards for describing resources, standards for finding resources, and standards for how enterprise systems interact with other systems.

Describing Resources

Recent submissions to the IETF (Internet Engineering Task Force) by members of CalConnect describe how to apply the methods we use for people and access control to things. For people, we share directory information as VCARDs and we access directory information using LDAP (Lightweight Directory Access Protocol). LDAP is also used for that part of security tied to who we are and where we work.

Recent submissions define how to use VCARD for Resources, and how to use LDAP to find and use those VCARDs. They do not define the information kept in resources. For that, we can look to BIM.

In a report last spring, the National Renewable Energy Labs (NREL) described the Building Services Interface (BSI) (which I described in the August issue). A properly commissioned BSI would be able to share information about its systems and the energy use of each. The interface for this was not described.

Building rooms and the systems that support them can be described using resource VCARDS.  VCARD and LDAP are well known approaches, and ones for which there is already much open source code. Programmers know how to work with them. Enterprise scheduling systems and BSIs can share a common interface.

But what information should be in these VCARDs? Without standard information, there is still no interoperability.

Feeding Information from BIM

BIM, or the Building Information Model, defines the information used during design and construction of a facility. Traditionally, BIM was little used after the end of construction. For the last few years, the best building owners have worked to use BIM throughout the life of a building. Construction Operations Building Information Exchange (COBIE) specifies how information captured or created during design and construction are provided to facility operators. Most mainstream Computerized Maintenance Management Systems (CMMS) can now directly import COBIE.

COBIE is used to deliver the set of managed building assets which are spaces, products, and equipment in simple formats that can be re-used easily. BIM provides standard semantics for describing everything in COBIE.

We can define building-based resources using existing standards from BIM by selecting from the information in COBIE. COBIE would provide a commonality of identity and description between resources as described in enterprise systems, in CMMS, and in the BSI.

I call these VCARDs populated with BIM information using COBIE, “BIMCARDS”

Sharing Schedules in the Enterprise and Facility

The WS-Calendar committee in OASIS has developed RESTful and SOAP-based interactions for calendar updates and schedule synchronization. REST (Representational State Transfer) and SOAP (Simple Object Access Protocol) are the predominant protocols for exchanging structured information between systems using XML and web Services.

These protocols define how to align schedules between servers that offer a calendar interface. Mike Douglass of RPI has developed open source implementations of these protocols as part of the BedeWork project. Using these web services, the schedules on calendars in two systems, say that of a room in the enterprise schedule and that of matching resource in the BSI, can be matched up. The resources would “match” because their directory information, as found by LDAP matches. The directory information matches because they use the same BIMCARDS.

Energy Models and M&V

The most critical flaw in today's Green and LEED processes is that it takes considerable effort to close the feedback loop. We prepare highly detailed energy models. We measure energy use monthly, or even daily. Sites that are participating in Smart Grid-based Demand Response or Transactional Energy may measure energy use hourly or even by the minute. It is hard to compare this information to that in the energy model.

[an error occurred while processing this directive] The BSI should offer a way to tie back the performance of particular systems back to the assumptions in the energy model. The energy models are based on assertions about the use and performance of building systems. If a BSI can present energy use information by BIMCARD, then this information can be tied directly to the original energy model.

A common way for a building to fail in meeting its energy model is when its schedule is different than those assertions in the model. A building that is open for 12 hours a day uses more energy than a building that is open for 9 hours. Unfortunately, this is often as far as analysis goes.

BIMCARDs in the BSI are tied to schedules. These schedules are tied to the way the business operates, as expressed in the enterprise calendars. When the business schedules affect building operations, they change the schedules associated with each BIMCARD. These schedules can be compared directly to those in the energy model, and a new energy model computed based on the actual schedules.

These updated energy models can be easily compared to the actual energy use in the building. If the building is able to report actual energy use by BIMCARD, it becomes straightforward to identify problem points in a smart building.

Solving the Integration Challenge

The problem with traditional approaches is that they are too hard and take too much skilled time. Directory services such as LDAP offer proven ways to reduce integration costs between people and between systems. BIMCARDs create semantic compatibility between diverse systems and technologies. Creating common Resource descriptions from COBIE ensures accuracy and reduces the burden of entering and maintaining directory information.

These approaches are easily extended to systems not in the BIM as well. This model supports appliances and other moveable equipment. Electric vehicles can participate in these enterprise-style schedules just as do PDAs and smart phones today.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]