Cognitive functions, Autonomy, and Integration

Everywhere we look, we see more higher-level, almost cognitive functions being incorporated into low-level products. Cameras are internalizing much of the craft of photography. GPS systems are comparing notes with their peers to provide up to the minute routing choices. Cars tune themselves on the fly, adjusting carburetion and suspension in real time to respond to driving style. Systems are becoming autonomous, competition is moving from commodity functions to service, and markets are starting to turn around interactions and integration.

Yesterday’s Wall Street Journal (see link below) described FotoNation and the software that it provides for many brands of digital cameras. I knew about anti-red-eye electronics. I thought it was a neat trick for the camera to automatically focus on faces in the foreground rather than the between them in the center of the view. I was amused at the camera that would alert the picture taker that someone blinked. The camera that delayed the shutter until everyone was smiling was pretty neat.

The ability of a camera to recognize particular faces in the crowd, and make sure that they, if no one else are in focus was different from the rest. Simply take several pictures of your family and friends, and notify the camera. Thereafter if six mothers, standing in the same place each snap a picture at the third grade play, the six cameras will make different decisions and each mother will find her own little Billy in perfect focus.

We now have consumer electronics with complex learning behavior that it applies to its canned pattern recognition tricks. This is customization far beyond the last generation of, say, a car remembering driver preferences for mirror, steering wheel, and seat.

Consumer systems now cover for the amateurish efforts of their operators to produce first class results. Harried amateur photographers get assistance to achieve professional results. Drivers can get performance out of their cars that previously would have required long practice. Trip planning now acquired the knowledge of a local and an instant awareness of traffic conditions.

Building systems face the same issues and are moving in the same direction. Not only are they often operated by amateurs, but the may be maintained by the insufficiently trained—following their installation by the low bidder. Traditionally, systems have been oversized and over-built, to cover these predictable problems. This leaves a lot of energy and operating dollars on the table. The best systems will move instead to make their systems resilient, as are the camera and the car, and self operating.

This will change the tasks asked of control systems, and how they are integrated. Self tuning systems do not need to share low-level details with those far away. Low level protocols will be confined inside autonomous systems, and only higher-level services exposed. These interfaces will be the basis for next generation integration.

Systems will use these newer interfaces to negotiate service provisioning with each other. Although each system should work alone, they should be able to discover resources that each other makes available. Imagine systems advertising their waste heat as a resource, and then the heat source broadcasting when it needs to shut down. These interfaces will be developed as agents; they know their missions, they defend their missions, they act independently.

Integration will come to assume autonomy, for the new interactions will rely on each system doing what it says, and meeting its contracts. Contract-based integration will increase the value of cognitive performance, as they become the only competitive edge in a world of commodity electronics and unpredictable installations.

And systems that expect to be told what to do, rather than simply meeting their contracts? Well, as now, no one will want to do business with such agents.

When will an Android run your Building?

Google is slowly doing the unthinkable—insinuating an open operating system into the cellular phone market. Google's stated goal for Android is to create a mobile platform that makes surfing the Web from a smart phone as painless as surfing it from a PC.

Android, if successful in getting a foothold, is predicted to launch a whole new ecosystem of cell-phone apps, all able to communicate using internet standards. The chipmaker ARM, whose chips currently power 90 per cent of all mobile devices, will be showing off Android running on their hardware at next week’s Mobile World Congress.

With oBIX, every building system can be operated remotely using only standard interaction patterns of the web. There is now no reason that any system can’t be operated from a cell phone. That is not entirely new—there have been products for years that allow this in a limited way. Existing products have been for limited use with particular hardware in special circumstances. Those who needed them got them as a lagniappe on top of an expensive custom integration.

oBIX 1.1, currently in draft, will offer RSS/Atom style subscriptions. With RSS subscriptions, you can subscribe to a news sources and receive it on any number of applications that can receive news feeds. You could even have the information you are tracking on your Google home page.

What if you could download to and run this kind of application on your phone yourself? What application would you choose? How would you select one application over another? In other words, what will we do when we can get to information and function so easily?

Open standards, open interfaces, open cell phones…what will you write today?

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.