Can BIM really transform our processes?

What would happen if every part of the planning process was done in a collaborative environment? What would happen of every tool used in design could share information? What if the information could be reviewed by everyone in real time? What would that change?

What if the bid package were 100% accurate. What if assemblies from the building model were used to construct all the duct and case work off site. What if the contractor could deliver as-builts with the building, because the build matched what was originally designed?

What if energy models were created on-the-fly with each iteration of design, so you always knew the cost and performance of each change What if part of commissioning was having the building compare itself to those energy models with live data. Automatically. What if you could renew that comparison whenever you wanted?

BIM is properly about data sharing, and information stewardship across the life of a facility from initial Design Intents and Programming to final Demolition. Data sharing is based around data standards. The data standards for BIM are referred to as IFC. That is as technical as I will get for now.

The attached Quicktime movie is about 10 minutes long. The movie takes you through a real life programming charrette, and how everything is changed once access to the information becomes universal and standards based. It is marketing literature, so of course everything works. Even so, it is a good introduction to the power of interoperability during Planning and Design.

Please take the time to watch this QuickTime movie. It *will* give you the strength to read up on buildingSmart.

The movie is information about Onuma's BIM-based server software. I have no relationship to Onuma, but I think the software shows how abstract standards-based abstractions about building information change the way we interact with acquiring buildings. Abstract standards-based information about processes in buildings will change the way we interact with buildings, The good news is that that standards are the same...

Now what if you used this process throughout operations and maintenance. What tools would you use to shape building load, when energy analysis looked like this, when you knew what the space was used for, when you knew what people were doing throughout the day. What if you could pull space, time, energy, and people together because you could see how it all worked together….

To see more training information on a BIM-based project server, go to http://onuma.com/services/TrainingSupport.php

Sun and Clouds

Earlier this week, I suggested that one outcome of the Software as a Service (SaaS) approach will be that complex operations such as BIM servers would migrate into cloud computing, where there data can be shared and updated by Designers, Architects, Engineers, and used by Owner/Operators.

This week, Sun (the computer company that long used the motto “the network is the computer”) announced that by 2015 Sun will have *no* data centers. All internal IT for this technology company will be acquired under the SaaS model. "We will need to get to a point in which we mandate detailed SLAs and manage/monitor those SLAs," Cinque writes. "As long as a SaaS provider can adhere to our detailed SLAs, then it shouldn't matter where the applications sit. The challenge is getting those detailed SLAs written out, (and) having the SaaS industry evolve where they can accept client-driven SLA's." By 2013, 5 years from now, Sun expects to eliminate half of their square footage in data centers

So what does this say about buildings and energy?

First, it both intensifies the reasons behind The Green Grid (see my earlier comments here) while reducing the number of people interested. While CABA may call Networking the 4^th utility, data processing may instead become the 4^th utility. The differences in cost, and the intensity of the operations load may make data centers an unjustifiable expense.

Rapidly rising energy costs may be the catalyst; virtualization and the associated capability of outsourced customization to produce tailor-fit solutions are the enabler. The increasing demands of security and enhanced benefits of service specialization will be long term drivers. Those data centers that remain will demand highly efficient interactive means to manage transforming energy to raw business process.

Next, it invalidates the traditional building system model of on-site monitoring. Traditional building systems bring too much data and too little information to too few people. Cloud computing will decrease the barriers to fewer people with greater expertise monitoring more building systems. Communications models for embedded building systems that do not match the new reality will suffer competitive disadvantage.

Low level protocols will remain much as they are; gateways that abstract underlying system up to actionable alarms and descriptive information. These gateways will use enterprise-style protocols that perform well over the internet.

Such gateways are exactly what we need to enable new business service. Remote analytics. Knowledge based maintenance management. Live energy modeling. Third party interactive demand/response. Each of these services, and others we do not yet know, will also become services, and move into the clouds.

http://www.datacenterknowledge.com/archives/2008/Jan/10/suns_goal_no_in-house_data_centers_by_2015.html

Building Operations get Sassy

Ken Sinclair and I were recently talking about SaaS and how it affects the Automated Building world. We concluded that SaaS was not only going to be big in traditional applications such as Building Monitoring and Energy Management, but would open up whole new areas of building analytics and advanced services.

SaaS is short for Software as a Service. SaaS is the evolutionary advancement of the Application Service Provider (ASP) market from a few years ago. In simplest terms, ASP involved taking an existing application and hosting it on a server in the sky. Some ASP used remote desktop approaches based on software such as Citrix. Others skinned existing applications with a web user interface. Security, management, and patching of the server were managed by the hosting provider. In some cases, the provider was the original developer and the product was more affordable under a leasing agreement than an outright purchase.

SaaS went beyond ASP to leverage the new approaches we learned as applications moved to the web. Applications were re-crafted to expose web services to remote applications. Other hosters leveraged advanced business process knowledge and made it part of the offering. As seamless interactions with other systems became paramount, these new services co-evolved the practices now known as Service Oriented Architecture (SOA) and the Service rather than the Application became paramount. The name SaaS crept into parlance 3 years ago.

SaaS finds its natural home in Cloud Computing. Clouds are very large groups of machines hosting still greater numbers of virtual machines to provide computing power. Google has long used a computing cloud for its internal processes. Microsoft plans to build many cloud centers in the next few years; I look to cloud computing to be the area of fiercest competition amongst these two in the near future. IBM, Sun, and Intel have their own clod strategies. SaaS will live in the clouds.

I have described such data centers before when describing the Green Grid initiative ( /articles/the-green-grid.html ). Clouds and the green grid offer many innovative approaches to energy management before the first Energy Management SaaS application arrives. Intel “sundowns” software services using cloud centers around the world; as night follows day and cheaper electricity follows night, services up in the clouds move around the world. Energy-intensive processing power moves to where it is cheapest.

Cloud-hosting of SaaS offers the greatest savings for application with non-level usage. Such applications can appear on virtual machines when needed and vanish from the cloud when not in use. When re-requested, the virtual machine, unchanged since last used, can be re-created on the fly.

Traditional energy management and building operations are sure to move into the service world. As building systems acquire web-ready surfaces, then the monitoring and operation of those systems can move up to SaaS. Advanced building analytics services, perhaps in quite different clouds, will interact with these services. Such offerings will fare far better when managed using domain-specific knowledge that the local landlord will not have on staff.

Architects are developing what they call Integrated Practice as they move into the realm of BIM and buildingSmart. Integrated practice calls for a central data repository during the life of a project, available to and used by all who contribute to the design as well as to the contractors building the building. So-called BIM servers are a natural fit for SaaS in clouds, as they are only occasionally used, but require detailed domain knowledge to operate.

Regular readers know that I want the Building Model to be the source of interface and semantics for operating control systems in the building. BIM servers in the clouds can provide on-demand semantics and schematics to energy monitoring and building operations services.

There may be clouds in your future. And that’s a good thing.

Kombikraftwerk - energy reliability through diversity

At the University of Kassel in Germany, researchers are assembling a reliable power grid from a number of unreliable components. Kombikraftwerk (Combined Power Plant) is a grid assembled from 36 biogas, wind, solar and hydropower plants in a distributed network. The project was designed as a demonstration project to prove that it is possible for the German power grid to be reliable even if based entirely on non-traditional power sources.

This is a demonstration (again) of the old principle that you can gain additional reliability and availability from multiple technologies then you can from any single technology. While it is certainly possible that with additional research, development, any one (or two) of the technologies could be made ever so much more reliable, such efforts soon run into the age-old 90% problem. (This is usually expressed as “After you've done 90% of the project, you have the other 90% to do.”) Achieving each additional increment of reliability from an existing technology usually requires large amounts of additional effort.

A problem in scaling Kombikraftwerk will be the fallacy of large scale control. As the size of community to be orchestrated increases, the complexity of orchestration increases. Sooner or later, the Kombikraftwerk will fail due to the deep integration and direct control  of power production that appear to be embedded in its model.

The other apparent problem in Kombikraftwerk is the fine tuning of energy production to meet actual rather than anticipated needs. This requires additional spin reserve (Plants that are operating but not supplying the grid) to handle surprises. Some spin will always be required, but it is easy to imagine scenarios requiring much less than we require today.

These issues are just the sort that the abstract interoperability and intelligent end nodes envisioned by the GridWise Architectural Council (GWAC) will solve easily. GWAC is working toward abstract e-commerce style interfaces between each component of the grid, including generation, transmission, distribution, and end customer face. Both sides of each interface are assumed to be intelligent peers, able to defend their internal missions.

The GWAC smart grid is the simultaneous optimization of the diversity problem (which combines a number of unreliable technologies to produce a reliable cloud) and the complexity problem (it is difficult to control a mix of systems with different operating characteristics into a single large-scale control system) and the money problem (how do we fund this in such a way that each innovation can be rewarded).

Generating systems can signal their operating postures and capabilities using abstract messages. These interfaces hide the underlying diversity to prevent the overall grid management from becoming too complex. New technologies for storage and generation can come to market faster, and make money faster, because they need only interface to the simpler abstract interface rather than undergo deep integration.

The GWAC customer face addresses coordination of the demand side. Local agents representing smart buildings become participants in the smart grid. Initiatives like the Zero Energy Building foresee hybrid nodes, usually consumers of energy, but occasionally selling back site-stored or site-generated energy.

Kombikraftwerk and GWAC are compatible approaches that can easily build off one another. Because the defined interfaces of the GWAC are abstract and standard, new generating technologies can join the mix without extensive review. Easy recombination enables innovation by shortening time to market. More innovation enhances reliability by adding additional sources of diversity.

Money is the best, and most universally accepted, abstract interface for communicating scarcity and value. When we add money to each interface request, the natural target for the building-side of the interface is the enterprise and the tenant, not the systems. It may be that the best demand/response decision, when incentivised with pricing, is to shut down the office building, declare a telecommuting day, and run the building generators (whatever they may be) flat out. Such decisions would only further enhance Kombikraftwerk.

Looks like Kombikraftwerk and the GridWise Architectural Council could work well together…

References:

• Kombikraftwerk  - http://www.kombikraftwerk.de/index.php?id=27
• GridWise Architectural Council (http://www.gridwiseac.org/)
• Demand Response Automated Server (DRAS) http://www.akuacom.com/solutions/index.html