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.
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 talk about 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.
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. For UNC, the Registrar’s Office, in the stratus cloud, could submit room schedules and head counts for every classroom down to the buildings.
The remotest services all belong in the Cirrus clouds. Demand/Response, Energy Markets, third party maintenance, all are Cirrus tier cloud services. 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. Building analytics should move up into the highest clouds, with the highest expertise.
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.