Smart Environment Management and Control in Buildings
There’s increasing attention on resource- and energy-efficient environmental management for buildings. Stronger legal restrictions, a greater awareness of diminishing natural resources and higher energy prices are increasing the number of installations of intelligent and cross-linked environmental control systems. Such systems combine the control of temperature and air quality like oxygen concentration and humidity to affect both the well-being and productivity of building inhabitants.
Using Germany as an example, Figure 1 shows that the energy used to heat buildings is a significant portion of total energy consumption.
Figure 1: Total 2015 energy consumption in Germany.
An intelligent sensor network inside a building that receives sensor data from multiple locations can use that data to optimize energy consumption. After data collection, dynamic and statistical processing and alignment with outside weather information such as local forecasts generates a powerful map and predictive picture on how to regulate temperature for a building in the next hours or days.
For example, the control system can exchange air from one side of the building to the other (from the cooler side to the warm side) instead of using air conditioning or heating, or take advantage of morning temperatures to cool down the building by a few degrees in preparation for a hot afternoon. This method not only saves energy but also prevents low humidity conditions, due to the drying effect of air conditioning. Bringing in sensor data from additional regulation loops can control window blinds or shades, further reaping the use of sunlight to heat a building.
A zone controller is an essential component to manage a system of sensors, actuators and control logic. Zone controllers help centralize communication between the sensor network which is spread across the building and the building management service system. The microcontroller (MCU), which is typically used in a zone controller, will need to provide a set of communication interfaces which allows the sensors and actuators in the system to transfer data via a range of connectivity protocols (see Figure 2). For communicating with the building management service system, a high-speed network using Ethernet or Ethernet-based interfaces provides high data throughput with low latency for transmitted data packages.
Figure 2: A zone controller aggregates data and controls a network of sensors and actuators.
Sensors connected to a zone controller can provide data for temperature, humidity, air pressure and wind speed, while actuators are required for the control of heaters, air conditioners, water pumps, adjustment motors for blinds and many more. Because of this variety, a zone controller needs a wide spectrum of communication interfaces.
Sensors may also directly connect to the MCU’s integrated analog-to-digital converter (ADC) to capture sensor measurement values. Having the MCU perform more functions inside of a zone controller application reduces printed circuit board (PCB) and zone controller hardware complexity, and therefore reduces production costs.
There are several more possibilities for integrating functions into a MCU, such as through an integrated Ethernet physical layer (PHY). Figure 3 is a block diagram of an MCU providing the capabilities described above.
Figure 3: Block diagram of a MCU showing a huge variety of communication interfaces.
Let’s have a closer look at the communication interfaces typically seen in zone controller applications and the requirements illustrating the wide spectrum in hardware, software and data throughput:
Ethernet. Ethernet communicates with the central control unit of a building or even a building complex. A fast communication channel like Ethernet is necessary in order to ensure bandwidth for quite high data densities. An Ethernet communication channel, especially with the precision time protocol extension (specified by Institute of Electrical and Electronic Engineers [IEEE] 1588), synchronizes information from various nodes with time-stamp information.
Controller Area Network (CAN). This multimaster serial interface was originally specified for automotive, but many designers now use it in industrial and building automation applications. The great benefit of requiring only two data lines with a fault-tolerant protocol and communication over even long distances makes CAN very attractive for zone controllers to communicate with sensors and actuators.
Quad SPI. The QSPI interface is an extension to the SPI interface, with four data lines and a more regulated protocol. This interface enables quite high (several tens of megabytes per second) data throughput. Designers use QSPI to interface to external memory, with a fairly small amount of input/outputs (I/Os) allocated on the MCU, especially compared to parallel interfaces. Connecting larger memories to the zone controller using this interface enables the controller to store data for web pages and pictures, but also allows data logging far beyond the device internal memory limitations.
Serial Peripheral Interface (SPI). SPI is a fast interface with only three signal lines, plus one enable signal per slave. For this interface, use short communication paths so that all devices on this bus are on the same PCB.
RS-485. RS-485 is identical to UART, but allows greater distances between devices and support for multiple devices on the RS-485 bus.
Universal Asynchronous Receiver Transmitter (UART). This classic interface is easy to implement and often used for debugging purposes, although you can also use it to interface to simple sensors. Some designers use UART to interface between two controllers as a data channel. UART’s strength is its small footprint on the software and hardware sides. The interface only supports point-to-point connections and is therefore limited to communicating between two devices per hardware instance (exceptions are possible with some overhead).
Wired building automation protocols are usually based on serial interfaces like RS-485 or Ethernet for faster communication. The most prominent protocols are:
BACnet. BACnet is an open building automation and control (BAC) and communication standard established and monitored through the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE). It is now accepted as an international standard, International Organization for Standardization (ISO) 16484-5.
LonMark. LonMark is a standard based on the proprietary LonTalk communications protocol, which establishes a set of rules to manage communication between devices. LonWorks defines the content and structure of the information exchanged. Like BACnet, LonWorks has been accepted and adopted by international standards organizations—American National Standards Institute/Consumer Electronics Association (ANSI/CEA) 709.1 and IEEE 1473-L.
Modbus. Modbus is a truly open standard and one of the most widely used protocols in industrial manufacturing environments. Its messaging structure establishes master/slave and client/server communications between devices.
To enable developers to quickly integrate this huge variety of communication interfaces requires a well-designed driver stack that abstracts the hardware layer from the application layer, as illustrated in Figure 4. Software engineers can then directly focus on the protocol layer without having to dive into the hardware implementation level.
Figure 4: An implementation of software layers to abstract the hardware.
Protocol and communication standards like Bluetooth® low energy, Zigbee or Wi-Fi might be necessary in the interface portfolio of a zone controller if additional access options to wireless networks are required. To provide for these wireless network interfaces, a fast and full integration into the software architecture of a zone controller requires a well-designed and certified software stack.
Storing and processing data on a remote host central processing unit (CPU), often called cloud computing, is getting more and more attention and is a key feature in the next generation of these applications. Software libraries are also playing an important role in the quest for a complete solution. Cloud integration requires not only a connection to the internet but a function library with a well-structured application programming interface (API) to access cloud web services, supported by MCUs within the zone controller.
Many complex applications act as communication and data-exchange interfaces. A zone controller demonstrates how many components need to work together. It is mandatory not only to have the right MCU supporting multiple protocols, but also to have a driver and library structure that gets various interfaces working together seamlessly, without interfering with each other.
The hardware abstraction layer and driver stacks integrated into a real-time operating system (RTOS) system are essential parts. But extension into wireless protocols also needs support. Designers who fail to consider these issues may have to undertake a huge software development effort, and in the worst cases, a complete redesign.
