I think we need a change of model to let control systems and their associated sensor systems reach their potential application.  We need a change that will allow rapid loose integration of systems.  

[an error occurred while processing this directive]

Today at the University of North Carolina, we cherry pick our buildings, putting controls systems in the research buildings, and in the large athletic facilities and leave most buildings with minimal controls, and not integrated with the campus. We manage those big, high-profile energy hogs very carefully and ignore the rest.  The expense of controlling the lower-end buildings, and even more, that of integrating those control systems with our pan-campus controls is just too great for the energy they use.

Two years ago, a back-hoe operator in the next county eliminated one of the power feeds to campus.  We needed to shed load during peak cooling season in a very aggressive manner.  We needed to shed this load without endangering sensitive research animals during a time of year when they needed maximum environmental conditioning.  What we really needed to do was simply to turn off the low-end buildings.  We needed control in precisely those areas where it was too expensive to install control. 

Many of today’s control systems are built like the much-maligned mainframe COBOL systems of yore, monolithic systems with everything linked to everything, and all too often controlled from one workstation.  Integration is, by seasoned reflex, seen to be making there be one control system. This increases complexity, increases risks (as a single system stretches beyond any mere mortal’s area of competence) and often dilutes quality of each function.  It also makes each additional integration that much more time consuming, expensive, and risky.

Best practices in software systems today is to develop smaller modules, each provably able to perform its limited internal functions and operations correctly.  These systems interact with other modules through well defined, highly abstracted and loosely coupled interfaces, not intimate programming interactions.  There are three very big effects of this approach.

1. Each module can be swapped out or upgraded for enhanced performance of its single function without re-developing the entire system. 

2. Functional modules can be distributed not only across computer systems, but across corporations, as modern ERP systems span logistical chains across companies, countries, and continents; this is done without committing to a single system everywhere. 

3. Downtime in any one system does not imply downtime for all.

I want to see this same thought process applied to all the systems in a building, both traditional and non-traditional.  This will break current large expensive systems into several smaller coordinated systems, each able to be upgraded and tuned based upon its unique operational requirements.  This will lead in time to better performance of each module of its own better defined requirements, a benefit that will more than outweigh any loss of tight coupling.  New types of systems can be brought into a building, then, without disturbing extant systems; all can be loosely coupled at a more abstract level.

At the University of North Carolina, I have tenant refrigeration equipment used for research.  From a maintenance standpoint, I want my refrigeration mechanics to have the same operational information from this portable tenant equipment as they do from the embedded built-in systems that are part of the building.  From a day-to-day monitoring and operations viewpoint, these systems are the responsibility of the tenant, the researcher who needs to control how samples are maintained.  This, and many other examples, fits a confederated systems model; not monolithic, with a single mission and purpose, not stand-alone, with no information exchange between.

In a similar way, life-safety systems need to be focused on their mission, and perform it flawlessly, without interference from the energy management systems or the access control systems.  Fume hoods, for example, despite moving a lot of air, are life-safety in their mission, not HVAC. 

[an error occurred while processing this directive] I think if we achieve this, it will cause a great flowering of systems.  Owners will be more willing to upgrade modules within the enterprise controls than they are to upgrade any part of a monolithic system.  We can imagine tactical upgrades, here a package system is added for a summer, or during a renovation, and have that system under the management of the enterprise system. 

Freed from the need to span large networks, controls system engineers will be able to focus better on the simpler, more contained control system modules.  This will enable a more performance oriented market, as engineers compete to produce the best tuned control application, confident that it will fit as a module into the larger structure. 

Of course, this will require a meta-control framework to host these modules, to enable standards-based coordination of these diverse systems.  Something like what I hope oBIX will grow into.

When I was little, I played with Lego.  The choices I had were pretty much blue or red rectangles – and we were able to build wonderful (to us) structures with them.  When my kids got Lego, they got Castle Lego, and Spaceship Lego, and Pirate Lego.  We watched while our kids built the systems on the box.  The real fun began when we left and kids built pirate ships with jet engines, and added castle crenellations to the top of the old red and blue walls, and many other assemblages we had not anticipated.

Simple modules. Complex modules. Each self contained.  Each with a well-defined interface for interoperability.  All of the units can be recombined in ways not anticipated by their designers without violating their structure.

Building systems. Tenant systems. Strategic systems.  Tactical systems.  Out-of-building systems in the parking lot.  Each hiding its complexity behind a standard interface; each able to perform its core mission (Comfort, Safety, Transport) without interference from outside objects.  All coordinated by a meta-control system that need not be concerned with internal complexity.

This would be a foundation that would support enterprise interactivity.  This would be a structure that would support multiple enterprise applications, for Owner, for Operator, and for Tenant.  This would potentiate the largest growth yet seen in the controls industries.  It might even get the University of North Carolina to install controls in those “unimportant” buildings.

[an error occurred while processing this directive]
[Click Banner To Learn More]

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