The knowledge problem of building systems and energy markets

Energy blogger and economist Lynne Kiesling writes at the site “Knowledge Problem”, presumably a reference to Hayek’s observation that individuals are filled with limited and mostly erroneous knowledge. This knowledge problem makes it impossible for centrally planned economies, or for anything other than markets, to collect or filter the knowledge necessary to answer questions of production and distribution.

Markets for autonomous building systems, and therefore energy markets, suffer from another kind of knowledge problem, one that damages the market and prevents its development. In this market, the gap between what we know building systems can do, and what owners and operators are aware that they can ask for is immense. Their intermediaries, the sales forces of non-innovative systems, seem bound to keeping them uninformed, to support account control. In the middle stand the public utilities commissions (PUCs), effectively willful in their populist Luddism. The architects and building engineers seem as little informed as their customers, or perhaps merely uninterested in spending and time in this low margin, low bid portion of their projects.

These are strong words, and strong accusations, but they were bolstered by my recent time at FIATECH. At FIATECH, those companies with the most intense process oriented facilities work with the best engineers and the best construction companies to address inefficiencies caused by lost information in capital projects. In this forum, the engineers who design the largest chemical plants meet with sophisticated owner / operators of those same plants. And yet, even here, a strong dichotomy of knowledge was obvious.

The best engineers, and the owners of the best construction companies did not blink an eye when I talked of autonomous agent-based systems, each defending their system-based mission, and responding to economic choreography from the business enterprise. They readily acknowledged as almost too obvious to speak of that immense improvements in efficiency heightened amenities were readily available for the taking. They were well aware that 60% of the energy flowing over the power grid was supplying operations that could see their energy use cut in half almost overnight.

This group thought, though, that markets based upon economic responsiveness would never develop. The PUCs would never act in any way that would reduce their own power. The power companies would continue to market just enough “green campaigns” to keep the unsophisticated non-technical populace happy—and not disturb their iron grip on existing franchises. Building owners will never demand performance and interactivity and so there is no use developing it.

Building owners and operators have opposing prejudices. They can readily imagine participating in energy markets. They readily leap to tell me the services they would like to be able to get from their buildings. They are eager to get some transparent access to high-level information on building maintenance and operations to control costs and be able to audit their own operations.

Building owners, however, are sure that the technology is not developed. They report that their suppliers are unwilling or unable to provide these services. I have often been told that we don’t know how to do this yet. Last fall, at a charrette on intelligent buildings, it was the consensus of the consulting engineers in the room that we did not know enough to make building systems autonomous and responsive.

So there we have a different knowledge problem. The most technically sophisticated, with deepest knowledge of the current state of the art know that although the technology is already available, that pure politics would never allow the market to develop. Those able to make purchasing decisions are willing to buy, but know that the technology is far away. The knowledge problem for building systems is getting the best engineers and the forward looking owners to know what the other knows.

Development & Planning with Google Earth

I honestly had not thought much about Google Sketch Up until Wednesday morning. It’s a nice enough 3D drawing application, easy to use, as far as it goes. It even has a snappy photo draw feature. Import a photo, identify the sight lines and horizon, and start tracing. Sketch-up knows enough to create a model from your tracing.

You cannot, however, do anything too sophisticated with it. You cannot interact with masses. You cannot get any BIM out of it. I felt it was an interesting sketching tool, and nothing more. I was not very interested.

Of course, I had neglected the benefit of network effects, failed to take into account how easy connections between systems create new value, value beyond that of the system itself.

One of the network elements is Google 3D Warehouse. 3D warehouse is, at first glance, a YouTube of models drawn in Sketch Up and submitted to the warehouse. One’s chance of finding something useful is limited by the accuracy with which the submitter tagged the sketch. There are many 3D cats, an eerily life-like disembodied head of Barak Obama, and so on. Manufacturers have uploaded a large library of 3D objects that you can include into your models. There is also a growing library of actual buildings in the 3D warehouse.

Sketch-Up also uses its shared heritage with Google Earth to eliminate the positioning or “origin” issue of most low end building drawing programs. Most drawings are at the center of their universe. This makes combining multiple drawings is hard. Sketch Up drawings are all located in space. You can select a town, or you can place your drawing at a latitude and longitude. Initial daylight analysis is almost effortless.

One final network effect was the interaction with Google Earth. You can pull up, say, an intersection in using Earth. From Sketch Up you can then grab the site and place it your building sketch directly on it. When you are done, you can post your building directly back onto Google Earth and share it with others.

Well now, this is different. Zoning and public planning processes can now be performed in shared real time using only free tools. Public access, including public submissions, can be straightforward in this environment. Community groups and planners can work from the same models, visualized the same way, with computers they have already.

Complex interactions between buildings can be explored. A new building might cast a shadow, or a wind shadow on an adjacent building. Does this increase heating requirements? Does it reduce on-site generation capabilities? Does it instead reflect more light on the existing building, causing increased heat load?

Zero Net Energy buildings will be concerned with energy interactions at this level. Early easy visualization might let us notice these interactions early in our processes, so we can plan for them.

Field BIM: RFID and the transformation of the Job Site

Monday at FIATECH I learned about Field BIM, using BIM to bring lean manufacturing techniques to the job site. The approach was illustrated using a case history of the ongoing construction of Giants Stadium.

The new Giants stadium was entirely designed in BIM, meaning that complete three dimensional objects for the entire stadium were known in advance. The major structural components are a steel frame and pre-cast concrete forms. In essence, the largest issue on site is the most efficient assembly of these pre-existing modules. Examples of complicating issues are that erecting the steel frame for the upper decks would block access of cranes to lift inner pre-cast units into place.

An additional challenge, one that turned out to be an opportunity, is that the new stadium is collocated with the existing Giants stadium. This meant that the site staging was severely limited, as job site and parking for the old stadium were in direct conflict.

The team set up direct data exchanges between the scheduling system, the BIM software, the job site management system, and augmented it all with RFID tags. RFID (Radio Frequency Identification) is the name for the tagging technology that is used for inventory control in modern stores and warehouses.

Using the 4D BIM (BIM over Time), the team created an optimum sequence for assembly. This work was shared iteratively with the project management system, until a plan that the construction team could commit to was finished. This schedule was transmitted to the fabrication companies creating the pre-cast concrete. This schedule was also synchronized with the job site management software.

The fabrication plants received all forms as templates in CAD, and the delivery dates expected for each component. Just as in lean manufacturing, the agreements allowed no product to be shipped to sit until they were needed. This, by itself, improved efficiency because all on-site inventory was easily visible.

One of the requirements for the job was that an RFID tag was cast into each pre-cast module. This tag was then scanned and associated with the matching module in the job site scheduling system, which was them marked as “Manufactured”. The tag was re-scanned at the key stages of the module life-cycle: QA Inspection, Shipped, Received, Inspected (again), Erected, and, occasionally inevitable, Damaged.

This approach enabled the construction managers to anticipate problems at every level and prevent changes to the schedule. When looking ahead, the manager relies on the assembly schedule prepared in the 4D BIM. Looking ahead, the expediter could see instantly which materials needed in the next week were on site or en route. With only the materials about to be installed on-site, inventory and hunting time were minimized. As each module is scanned during installation the current state of the construction gets updated automatically, and re-synchronized back into the BIM.

Equipment Information Exchange: AEX at FIATECH

It’s been a few years since I peeked in at AEX, the developing XML-based data exchange standard for specification and procurement of mechanical equipment. At the time, they were launching a proof of concept project for exchanging pump information, and I was rubbing my eyes to stay awake.

This time, AEX was discussing implementation now. The community has run the test cases. They have proved the concepts. At this meeting, people were discussing how to move into procurement using the AEX standards.

AEX has moved into the open in several ways. AEX now develops its schemas on SourceForge. This is radical stuff for standards groups. All posting and all revisions are placed in an open forum, freely available for anonymous download. Anyone in the world can make and submit revisions.

The pump description interoperability work is more exciting than it sounds. The committee has demonstrated an integrated data flow from the conceptual design through preliminary design to design review by the manufacturers. The manufacturers responded with AEX of their own actual products, including proposed changes to the specification that each of those products would require. During project estimation, engineers could review on a common format all the differences between the request and the proposals. This greatly speeds the purchase of materials and the accuracy of designs while providing information that can be used for maintenance during the lifetime of the project.

Of more interest to regular readers, General Motors has been trying to drive AEX data exchanges into their new plants, with a special focus on HVAC. GM has decided not to wait for vendors to provide AEX-compliant information. GM supplies an applet to its equipment suppliers for new plants and requires that they enter the information. This is wrong in every way but the most important one: it works today with the market conditions we have today.

The power industry was in raucous attendance. We are about to see historic levels of plant building, and the industry would like to see some stands of design and interoperability. The power industry has some very large databases of reliability and operating experience. It sounded like the industry has committed to delivering its metadata (their data structures, not their proprietary information) to the AEX process.

This is very exciting. The benefits of consistent early specification of performance and reliability are far greater than they are for detailed procurement documents. Sustainable design must be service oriented design, and service oriented design begins with performance and reliability. Perhaps we can harvest the AEX performance and reliability to describe the larger systems that are comprised of AEX-specifiable components.