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.

Extreme Integration

New trends in building integration in which the systems respond not only to their own internal operations, but also to their tenants, and to the operations of the buildings housed within them are coming soon. Building systems will also interact with other systems in the building, not only the business systems, but also the other embedded systems with different missions. Buildings will also gain situational awareness of the world around them, starting with Demand-Response, but soon including greater awareness of weather and interactions with first responders. I like to think of this trend as extreme building integration.

Extreme building integration has been around for some time. It was difficult, and time consuming. Only those with special needs or special obsessions underwent the expense to acquire them. There was a certain cool factor to them, owners would show them off. But to date, they have had little effect on markets.

Three factors will increase the pace and penetration of extreme building integration. Increasingly, infrastructure that will enable them will be in-place to support the growing attention to Demand/Response as energy prices mount and carbon concerns gain ascendancy in the public mind. For Demand/Response, requiring internet-scale integration of control systems, to flourish, building system integrators will have to learn the lessons of encapsulation and isolation that are at the heart service orientation. Service orientation will require situational aware security to replace simple perimeter-based control.

These changes in system integration will both drive and be reinforced by three imperatives: information availability, a decreasing size and scope of each system, and interoperability. These three forces are mutually reinforcing, and will drive innovation for some time.

All organizations want actionable information abstracted from the raw data of their business operations. As enterprises discover such information in their Demand/Response systems, they will no longer look on their building systems as invisible and uncontrollable. They will begin to wonder what other business information can be gleaned from these systems. Can it decrease maintenance costs? Can it improve tenant loyalty or increase rents? A little information begets requests for more.

As systems learn to communicate in more standard ways, they open up interactions with more elements of the enterprise. More communications will encourage smaller systems with a single purpose. More complex interactions outside each system will encourage reducing the size of each system to control complexity. Smaller single-purpose systems will open up greater competition on performance of that function.

Interoperability is the largest aspect of these forces, unseen, perhaps, like the underwater portion of an iceberg, but keeping the other two afloat. Interoperability enables building owners and tenants to swap out building systems to meet special needs. Competition on quality of performance and subtlety of operation becomes possible. Interoperability requires the discipline to keep extraneous details out of the interface. Interoperability requires abstraction to enable new interactions not anticipated at design time. Interoperability enables and drives innovation. Interoperability allows not only extreme integration, but also agile integration, responding to the needs of the home or enterprise in different ways as needs change.

Soon, such integration will not seem extreme any more.

Abstract the Interfaces

If we are going to build very large systems, we will need to break it into self managing units, and build systems of systems. There is too much complexity and variability to establish any type of top-down order on embedded systems. Even if we could define the “optimum system”, we could still not use it for something as large as the power grid.

Suppose we did. Suppose we picked a technology and said “This is what each building shall have!” In 20 years we would still be trying to get all systems upgraded – and we would be mandating 20 year old technology. We simply cannot make rigid decisions for anything so large, so extended, and maintained by so many people.

We can only manage such a large scale by hiding complexity. We must hide complexity by defining certain simple big picture interactions that encompass all the little decisions. We will never get support for central coordination if by doing so, we remove personal control from systems. To define these simple actions, we need to reach for commonly agreed upon semantics to describe the operations we want systems to follow.

I want to place Intelligent Buildings as fully actualized agents on an Intelligent Grid. To do that, I hope to leverage the Building Information Model (NBIMS) to discover abstract interfaces to the point-by-point complexity of the underlying control systems. Rather than create these abstract interfaces from scratch, I hope that the pre-existing interfaces between the Building Model and Energy Models could be a good starting point. I want to avoid the complexity of introducing Yet Another Acronym and Yet Another Interface, and thereby avoid increasing complexity.

Abstract interfaces that hide rather than reveal complexity are the key. Here is an example from within oBIX discussions. When we discussed abstract interfaces for scheduling, each control system developer quickly claimed that “scheduling systems algorithms are quite complex, and there nearly impossible to align.” Spirited discussions ensued about factoring how long it takes to air condition a room in advance. Should we factor in humidity. and on. and on.

But there is already a standard for scheduling. We each receive ICAL invitations to meetings scheduled on the internet. ICAL is a W3 specification, meaning it is defined by the same folks who define how we display web pages. Our personal systems know how to adjust for where we are in the world, including such local oddities as when Daylight Savings Time begins. Each of us considers whether we have to drive to the meeting, or fly, or simply be near a phone. Those details are not the concern of the interface but of each participant and of the complex systems we represent. I want to simply invite the conference room or class room to an event on a certain date, with a certain number of attendees anticipated.

If these questions are answered correctly, they expand the value of capital assets by extending their ability to provide services and amenities to the owners and tenants, not merely to avoid costs. An Energy Model consists of Envelope, Weather, and System Operations. An abstract interface that works for energy modeling could be re-usable in tuning System Operations in response to Weather Predictions to improve quality of service provided. It becomes the basis for external system analytics to enable predictive maintenance and thereby economically provide enhanced reliability.

Abstract interfaces are the first step to defining services. Services are the key to continental-scale integration. Services allow for internal intelligence to support local imperatives. We can call that local intelligence an Agent. Agents are the key to large scale interaction, because they can assume responsibility for local operating details. Semantics are important, because we must have some common vocabulary to communicate with the local agents.

It almost goes without saying that any agent would be offended if you tried to communicate past its semantic surface. Even your kids will get in trouble if, instead of asking for money on a Saturday night, or perhaps even volunteering for chores, they reach directly right into your wallet. The surfaces of services must be inviolate.

And that is how we will handle the complexity of integrating a continental-scale power grid with its end nodes.