Virtual Home Maintenance and Operation

I have been quiet for a couple days. I am making 4 presentations and sitting on two roundtables in 4 days speaking at BuilConn and GridWise, both at Connectivity Week, and at a follow-up CABA conference.

While I am at Connectivity Week, I hope to catch up on how Sensus is doing. Sensus is originally a controls company that has embraced software as a service. Sensus contacts in place building control systems using existing business internet connections. Sensus analyses the performance and makes suggestions to improve performance and efficiency.

The customer can receive this analysis b email, or by we services, or by logging in to a custom web site. This year they have added RSS to their options. Each maintenance suggestion includes an estimated cost per month of not performing the work, based on local energy pricing.

What makes this Sensus unique is that it is a pure web services play. Sensus collects the metrics using Web services – no chatty control protocols are used. The recommendations are delivered using well known open protocols. The Sensus process is defined from end-to-end to offer building analytics as a service, a component of a service oriented architecture (SOA).

Large enterprises are using web services to componentize the operations of each part of their business. Each operating unit defines its service offerings in terms of web services, enabling other parts of the company to make internal requests against the web service, eliminating internal paperwork and process delays. Businesses that have made this effort find that they can market these services to others, turning cost centers into new sources of business. AIMCO, a REIT owning apartments and providing property management services has aggressively embraced this approach.

One of the GridWise scenarios describes a third party customer face (3PCF). This remote energy manager negotiates acceptable service level for each building system in the home with the end user – presumably using a web-based user interface so this profile can be updated regularly. The energy manager buys power on the owner’s behalf, negotiating the maze of power generation ontologies to make costs effective purchases that meet the owner’s preferences and sensibilities.

In a Service-Oriented world, the 3PCF has an opportunity for an enhanced service offering to its existing customers. One important characteristic of SOAP-based web services is that they are message oriented. The original recipient of a SOAP message can forward the message to another web service, just as the recipient of email can forward on a message to someone else.

The 3PCF already has a persistent internet connection into the home, and is able to discover each building service in the home. The 3PCF could partner with Sensus to gather performance analysis and failure predictions. The 3CPF could request the local maintenance staff from AIMCO to provide maintenance and repair services based upon the owner’s preferences and the building analytics. Without acquiring staff, the 3PCF is now able to offer enhanced knowledge-based maintenance and operation services to augment its energy management business.

And that is how one could build a virtual corporation in the home operations and maintenance space.

Tardif on BIM

Michael Tardif has been writing a seies of articles for the AIA magazine on moving toward using Building Information Moddelling (BIM) in the practice of architecture. While NBIMS is more than BIM, BIM is a very important part of NBIMS. Michaels work explains to architects why they should move to BIM. If architects move to BIM, we can leverage NBIMS to create, for example, design-based energy models that are intrinsically lined to the design, expressed as BIM. If the building is bult to the BIM, we should be able to commission the builsding to the original energy model.

And so on.

His most recent article describes the work work that OLBN Architectural Services, Inc. has completed for the GSA in support of a Program Development Study for the a former hospital campus in Washington, D.C. that is slated to become the future home of a U.S. cabinet department.

Leveraging BIMformation

http://www.aia.org/aiarchitect/thisweek07/0518/0518rc_face.cfm

Below are his previous articles in the series. If you are new to BIM, and do not understand the buzz, I recommend reading them all.

October 27, 2006

Faith-based BIM

http://www.aia.org/aiarchitect/thisweek06/1027/1027rc_pract.cfm

December 1, 2006

BIM Me Up, Scotty

http://www.aia.org/aiarchitect/thisweek06/1201/1201rc_face.cfm

January 5, 2007

BIM 2011: A Five-Year Forecast

http://www.aia.org/aiarchitect/thisweek07/0105/0105rc_face.cfm

February 2, 2007

Fox Architects Takes the Plunge

http://www.aia.org/aiarchitect/thisweek07/0202/0202rc_face.cfm

March 3, 2007

One Hundred Percent BIM

http://www.aia.org/aiarchitect/thisweek07/0309/0309rc_face.cfm

April 6, 2007

Converging Technologies

http://www.aia.org/aiarchitect/thisweek07/0406/0406rc_face.cfm

Toby says "Check it out !"

Definitely worth a look 

Too Much Integration

Recently, a friend described to me a great installation of one of the low level protocols. A few years back, when they added an IP binding to the protocol, they had been able to construct an integrated control system between two factory production lines. One was at a final assembly factory in a northern city and the other at a supplier in a rural area down south.

Each of these factories used the same low level control protocol. My friend described to me how they were able to integrate the inventory control and JIT manufacturing at the two plats by linking their control systems. He was quite proud of it, and I’m sure it was a technical tour de force.

I was horrified.

There is no useful control level information exchanged between the two factories. Unless they do no quality control, there are no real exact inventory linkages between the systems. Certainly, there is no real-time linkage – they are a day’s drive by truck apart. There are only two reasons to link the systems: (1) they use the same protocol or (2) the interface is so contrary to what the corporation expects that they do not want to do it twice.

The first reason is a horrible reason to link systems. It is an example of the “Small Boy with a Hammer” school of analysis. More importantly, it skips all interesting and useful service integration by plunging quickly to process integration. Process integration is the process of paving the cow-paths. Process integration makes for brittle systems. Process integration prevents agile decision-making in the future. More importantly, process integration forgets the services that each system performs and replaces it with a mechanistic approach that belies the services.

I like to refer to system services as an overlay on system mission. Each system has a mission, and its first job is to defend the integrity of that mission. HVAC systems have a mission to provide healthful air conditions and long term maintainability of a building. They should defend this mission, including preventing outbreaks of Legionnaire’s Disease blocking large growths of mildew in the walls while providing the services of responding to requests to shed load or to the requests by occupants who push the thermostat up. Fume Hood systems have a mission of life safety that they must not skip. This system must defend this mission, as flooding the lab with poisonous gas is not an acceptable response to a load shedding request. Two systems. Nearly identical components. Perhaps the same protocols. Radically different missions.

The transition to a service orientation is going to be a difficult one for controls engineers. This sort of over-integration was understandable when low level protocols were all that was available. It was appropriate when there was no higher level interface to the control systems. It was appropriate when hand-crafting the enterprise interface, a process requiring someone skilled in translation between the worlds of production and controls, was the most difficult step.

But it is a bad architecture, one forced upon the practitioner, as the lack of structural steel forced heavy stone massing on early high-rise buildings.

We need to stop oner-integrating control systems. We have interfaces now.

Off to Chicago

Next week at this time, I will be speaking at Connectivity Week (www.connectivityweek.com) in Chicago. Monday night, I will get to see my daughter who attend the UofC. Tuesday I will be talking about oBIX, both from a standards perspective, and from an operations perspective. Thursday I will speak about Security systems (from an IT, not a physical security) perspective and on business models for GridWise.

I always like speaking. I always learn twice as much from the podium as I ever would in the audience. The many perspectives that people bring are stimulating.

I will be talking, of course, on the state of oBIX. Committee members know what I have to say. Others may have to wait. I will say, though, that I am hearing reports of 50-60 downloads of the open source oBIX project per month.

The best part of the standards updates session should be not me, but the presentation from NBIMS  NBIMS is an effort to standardize building design and construction information to create an integrated data life cycle over the entire existence of a capital asset. It offers lots of nice goodies to the embedded systems world, including energy models directly out of the design, automated same-day code compliance, commissioning standards integral to the design, and so on.

The security portion of the conference will be be interesting. There are several speakers with a much deeper concept of security than one can find in siloed control systems. I will be talking of the Liberty Alliance models for federated identity management systems that grow to national size. I do not know the other speakers, but their resumes look interesting.

I recommend that embedded system guys look into GridWise during any spare moments. Some of you know that oBIX fit perfectly with what I was writing about before I discovered oBIX at BuilConn. In my mind, projects like GridWise were why I was writing on service enabling building systems. GridWise hopes to create open market structure that enable rapid innovation within power distribution, generation, and use within North America. This will happen by creating a distributed management system, driven by end users, on the scale of the internet.

When that is all done, CABA is having their symposium on the roadmap to the Intelligent Building on Friday.

It should be fun.