August 2008
Column -

AutomatedBuildings.com

Babel Buster Network Gateways: Big Features. Small Price.
Control Solutions, Inc. - Minnesota

(Click Message to Learn More)


Clouds and Rain

Cloud Computing is a name for putting computing services, whether traditional, such as CRM applications, or modern, such as SaaS, on computers up in the wider network.

Toby Considine
Toby Considine
Systems Specialist,
Facility Services, University of North Carolina – Chapel Hill
The New Daedalus

Contributing Editor

I always enjoy reading Dennis Brandl, who writes in the nearby field of factory control systems. The challenges of factory systems are both greater and less than building systems. They are greater because, well the systems are larger, and more complex. The challenges are simpler because no factory needs to be convinced that better control of factory automation offers benefits. One constant, though, is that most such systems have developed in a silo outside of traditional IT, and so are slow to adapt the protocols and service architecture of today’s Web 2.0 world.

Articles
Interviews
Releases
New Products
Reviews
Blogs
Sponsors
Archives
Past Issues
AutomatedBuildings.com

Secured by Cimetrics

In the July issue of Control Engineering, Dennis Brandl’s discussed his take on cloud computing as it applies to factory automation. Cloud computing goes alongside software as a Service (SaaS). Traditional network diagrams linked up to the larger network outside the scope of the drawing, depicted as a cloud. Cloud Computing is a name for putting computing services, whether traditional, such as CRM applications, or modern, such as SaaS, on computers up in the wider network.

Brandl extends the metaphor of computing services in the clouds by distinguishing between different clouds. Brandl divides cloud computing into cumulus, stratus, and cirrus, clouds, respectively the lowest, the mid atmosphere, and highest clouds. He then discusses which computing processes belong in which clouds, with the highest clouds being the least connected to direct control processes. This is useful because it lets us distinguish between clouds.

Traditional control systems have no clouds – only towers in the sky. Whether or not it makes sense, building systems from one building or many have traditionally gone up to a central point; they have been a silo reaching up into the clouds.

For Brandl, nearly everything is a cloud; only the core control processes are on the ground. I think this is right; for buildings, only the core processes, those elements on the traditional low voltage protocols such as BACnet and LON, are on the ground.

Enterprise energy monitoring and building control, then, are in the low lying cumulus clouds. A well architected system does not put the EMCS center in the center of any control loops. TCP/IP is by design a non-deterministic protocol, meaning it does not belong inside a control loop. Anything off the ground is in the clouds. Anything in the clouds should interact using internet protocols.

In the UNC Enterprise Building Management (EBMS) project, we restrict all low level controls to the building. All communications outside the building are using internet protocols. Each building has its Enterprise Building Local Gateway (EBLG) speaking traditional standards and proprietary protocols on the building side, and web services on the outside. We keep the EBMS close to the buildings as a business decision, but there is nothing on the architecture that would prevent us from moving this service up into the higher up stratus cloud layer, or even up into the high flying cirrus layer.

The middle tier of stratus clouds is outside Facilities Operations and hosted in the wider enterprise. We plan for the Registrar’s Office, in the stratus cloud, to submit room schedules and head counts for every classroom down to the buildings. For now, this communication will have to be with the cumulus layer, but we would like to push it down to the ground at the building gateway.

We have long used building analytics products like Packrat at UNC, bolted onto the silo. It would be far better for these services to live in the cirrus clouds, under the direct control of someone with the in-house expertise to process the data into information. The processing necessary to turn operating data into predictive maintenance work orders is intense, but only needed sporadically. The whole purpose of cloud computing is to reduce costs by sharing expertise and resources so they are fully utilized. Building analytics should move up into the highest clouds, with the highest expertise.

The remotest services all belong in the Cirrus clouds. Demand/Response, Energy Markets, third party maintenance, all are Cirrus tier cloud services.

Keep some clouds close to you, ones in which fast response and control are the most important. Let some clouds drift up into the atmosphere, where forces out of your control may determine their performance and availability, but where superior resources or specialize knowledge can be purchased. And put services where enterprise identity and line of business interaction are the most important in the stratus layer.

Just remember, changing business conditions can move any cloud up or down. The protocol for communication to any cloud layer should be the same; internet ready, secured, and standards based, ready for e-commerce. Nothing but web services belongs anywhere in the clouds.

(http://www.controleng.com/article/CA6574700.html)

 

footer

tosibox
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources