One big lesson from the last few decades in building automation system (BAS) technology is that proprietary and closed systems create barriers to innovation. Many system integrators and building owners who lived through this period felt the sting of this lesson profoundly when they were stymied in their efforts to use information technology to improve energy efficiency and comfort. The protocol obstacles prohibiting interoperation of lighting, power and HVAC sensors and data were a frustration. Hence they got very busy defining and supporting standards like BACnet. Proprietary protocols have not gone away and many perceive a new trap ahead as emerging Internet of Things companies reveal business models that lock more building data away in new data silos. Carl Blumstein and Therese Peffer of the California Institute for Energy and Environment, University of California, recently released a paper, Towards a Wiser Use of Intelligence: Fieldwork in the Application of Information Technology in a Commercial Building, that presents key Developments in the Cal openBAS.
The Cal team makes the distinction that this open-architecture is horizontal as explained in this quote:
A simplified representation of horizontal layered architecture helps explain the concept. Each layer is independent, and thus creates modularity. The bottom layer, here called the sensor/actuator layer, is the interaction with physical data and systems; the monitoring and control system interacts with the building environment, gathering data and executing control actions. The middle layer—data management—organizes, stores, and transmits data from the sensor/actuator layer and instructions from the application layer. The top layer, here called the application layer, has software applications that operate on data provided through the data layer to provide outputs in the form of information on the state of the building and instructions for the control of building systems. Not all control is initiated on the application layer; some happens autonomously on the sensor/actuator layer—for example, lights might be directly controlled by an occupancy sensor. And not all instructions from the application layer are accepted. For example, a smoke alarm may override an instruction to open a damper. Within the layers a variety of languages (protocols) may be used for communication, but between layers a single language (protocol) is used for communication—Internet protocol (IP).
Highlighted in blue in the diagram, the team integrated HVAC and lighting subsystems data from the Apogee system, the WattStopper system and the other SDH submeters available using open-source software known as sMAP (simple Monitoring and Actuation Profile). As a point of comparison, consider the OSIsoft BAS architecture described in this post.
One thought on “Open Software Architecture Demo’d by UC Cal’s openBAS”
Here’s a similar concept at device level – and there is no reason not to consider device level solutions. What is also helpful is implementing IEC 61131 or 61499 at this point which not many consider doing.