Linux and RTAI for Building Automation

This article presents the design and development of a control system for centralized operation of different air-conditioning equipment in a building by using Linux and the real-time Linux application interface (RTAI). Each air conditioner, distributed throughout the building, has it own infrared (IR) remote controller. The goal is to replace them with a centralized computer-based control system to operate the air conditioners, including turning them on or off and setting the desired temperature and fan speed.

The idea for this project came from the need of a local university to have a centralized and flexible way to operate its air conditioners at a cost within its budget. Commercial software and hardware exists for the same purpose, but normally they are too expensive and manufacturer-dependent.

This project's hardware solution consists of a central control computer, running Linux, connected to an RS-485 microcontroller network. The microcontrollers have the capability to send commands to the related air conditioner using infrared signals to operate the nearby equipment.

The software design of the system includes two real-time tasks—a main control task and the RS-485 network control task—as well as two non-real-time tasks—a Web server and a database. The Web server is in charge of the user interface, making it available from any browser in the university's computer network. The PostgreSQL database is used as the main data repository.

The implementation is a low-cost solution with the flexibility to extend it as necessary. Moreover, it is not manufacturer-dependent, and it works with any air conditioner that supports an IR remote controller. Each air conditioner works independently using its own temperature control system. To supervise the operation of this equipment, each microcontroller in the network is equipped with a temperature sensor to monitor the actual classroom temperature and report it to the central computer.

The entire user interface is based on Web pages. The first page displays a summary of the actual state of each air conditioner. This information includes an identification string, the room in the building where it is located, the actual room temperature and whether the equipment has a preprogrammed operation sequence according to which it actually is operating. For each air conditioner, this page has a link to the operation interface for the specific piece of equipment. Before going to this page, the system asks for a user name and password. At this level, it is possible to interact with the system directly controlling the air conditioner or to create or change the actual program for automatic operation (Figure 1).

Figure 1. From the operation interface, an authorized user can turn the air conditioner on, set a new temperature or turn it off.

The most interesting part of the system is the programmed operation. For example, every day the system can turn on the air conditioners automatically, with a predefined temperature setting for each room, before classes begin. Then, the system can turn off the air conditioners at a time in the evening when the activities in the building or in a specific classroom end.

The hardware architecture is composed of a central control computer and microcontrollers commanding the air-conditioning equipment. All the microcontrollers are connected to an RS-485 two-wire network. The microcontroller used in this application is the AT89C2051, an Intel 8051 derivative from ATMEL. It is encapsulated in a 20-pin DIP package and is equipped with 128 bytes of data RAM, 2KB of ROM for code, one asynchronous serial port and 14 independent digital I/O ports. Figure 2 shows the microcontroller board and its parts.

Figure 2. The microcontroller board with the microcontroller removed.

The software in the microcontroller generates the IR signal using one digital output port. The serial port connects the microcontroller to the RS-485 network. Each microcontroller board is equipped with a temperature sensor, the DS1620 from Dallas Semiconductor. The microcontroller communicates with the temperature sensor using a digital three-wire synchronous serial interface. The microcontroller has no hardware support for synchronous serial ports; therefore, it is implemented in software using normal I/O ports.

The RS-485 network is used in this application because it is easy to deploy, cheap to implement and easily can connect a useful number of nodes. Only one pair of Category 3 telephony grade cable connects the nodes. Due to the hardware driver limitation, the maximum number of allowed nodes is 32, but this number easily can be extended using network repeaters. The maximum cable length between the control computer and the first repeater or between repeaters is 1,200 meters.

A master-slave protocol controls access to the physical cable. The computer running Linux is the master, which polls each node with a predefined rate. On every polling the master can send commands to the node; the polled node answers by sending data to the master or by sending an empty packet to say that the node is active. A drawback of using this access-control protocol occurs if the master goes down—the entire network goes down too.

Considering the limited resources of the microcontrollers, the 9th-bit protocol is used to determine whether the packet sent through the network is for this controller. Each byte transmitted through the network has an additional bit. The packet destination address is the only one transmitted with this additional bit set to high. The microcontroller's UART (universal asynchronous receiver and transmitter) is programmed by default to generate an interrupt only if the 9th bit of the received byte is high. The interrupt service routine then compares the received byte with the node address. If there is a match, the routine programs the UART to receive all the bytes regardless of the 9th-bit state, until the end of the packet. If the destination address does not match this node address, the interrupt service routine returns.

The central control computer UART, which is PC hardware, does not directly support the 9th-bit protocol. To overcome this limitation, the driver simulates it by using the parity bit. Before transmitting a byte, the driver configures the parity to generate a one in the 9th bit of the address byte and a zero in the 9th bit of the other bytes.

Figure 3 shows a diagram of the tasks in the system and the communication links between them.

Figure 3. Communication among the Tasks in the System

The main control task, the network access-control task and the software driver for the physical layer of the RS-485 network are the tasks that run in the real-time executive. An RS-485 driver was developed for RTAI. This driver is similar to any other serial driver, except for the 9th-bit protocol used in this application, as described above.

The other real-time task is the network access-control task, which is in charge of periodically sending packets to each network node. This packet can be a command to generate an IR signal, a poll to see if the node is active or a command to the microcontroller to transmit the actual room temperature. The node answers with an acknowledgement to the first two types of packets and with the actual room temperature to the last one. The information about the actual state of every node is available to the main control task, which in turn informs the user interface if a node fails.

The main control task, using information retrieved from the database, operates the air-conditioning equipment in the building, as programmed. This task also can receive instructions from the user interface that overrides the programmed configuration, using two RT-FIFOs. RT-FIFOs are an interprocess communication routine for communication between real-time tasks and normal Linux tasks. To communicate with the PostgreSQL database, a Linux dæmon was developed. This dæmon communicates with the main control task using two more RT-FIFOs. An additional important function of this dæmon is to send to the main control task the system date and time; no support for reading it exists in RTAI.

The developed system sends commands to the air conditioners, eliminating the need for local remote controllers. We do not interfere with the air-conditioner temperature control system, nor do we touch any internal circuitry. Each air conditioner has its own temperature control system built-in, and the temperature sensor in each microcontroller supervises that the equipment is working fine. Figure 4 shows the microcontroller board installed.

Figure 4. The complete microcontroller board as installed.

The Linux tasks are in charge of presenting the user interface through a Web server and running the PostgreSQL database engine, which is the main data repository. As described above, another Linux side task is a dæmon used for the RTAI main control task to access the system date/time and the database.

The user interface is simple. The first page presents information about the actual state of each air conditioner. Every type of user can access this page. In order to change the program or send commands to a particular air conditioner, the system asks for a user name and password. PHP is used to generate the Web pages dynamically to present the information retrieved from the database.

In the PostgreSQL database, the system stores general information about the air conditioners, such as BTU, location, brand and microcontroller network node address; the programmed operations; and the IR commands needed to operate each air conditioner.

An important part of the system is the module that reads the air-conditioner remote controller signals and stores the information, associated with the corresponding equipment, in the database to reproduce it using the networked microcontrollers. This module is used only when adding a type of air conditioner that has a different brand and/or different remote controller commands.

Two tasks are part of this module: the first is a real-time task that reads the IR signal. The LIRC Project as well as the Ripoll and Acosta paper in the on-line Resources, present detailed information about IR remote controllers and sample implementations using normal Linux and RTLinux, another real-time executive for Linux. The other task for this module is the user interface that runs on Linux. The two tasks communicate using an RT-FIFO.

Due to the small amount of RAM available in the microcontroller and the long IR signal duration, an important function of this software is to help the user obtain repetitive patterns within the different IR remote controller signals associated with each button or combination of buttons. These patterns are coded in the firmware of the microcontroller and are used to reconstruct the command to control the equipment. For example, if there are ten different patterns, the information sent to the appropriate microcontroller in the network is something like: repeat pattern one ten times, then pattern two three times and so on, until the complete command is reconstructed. This technique has the advantage of using fewer resources for signal reconstruction. The disadvantage is the software of the microcontroller needs to be changed to introduce the patterns of the newly added equipment whenever a new air conditioner is introduced.

Currently, nine air conditioners are controlled using the system described here; all of them are located in the same building. Another 15 will be added soon. The hardware cost of each microcontroller node is $60 US, and the central control computer costs about $500 US. The other costs are the deployment of the RS-485 network and, of course, the development and implementation of the system.

The implemented system fulfills the specifications of the actual user. Because of this project's success, every new air conditioner acquired by the university must be compatible with the system. The only condition that must be met to comply with the system is every new air conditioner must have an IR remote controller.

Thanks to RTAI, the system main control task is independent of the user interface tasks running in Linux. Even in the improbable situation that Linux goes down, the system would continue on with the programmed operations.

In the future, the system may be extended easily to control, for example, the building lights, alarms, access control to restricted areas and other systems.

Resources for this article: /article/7742.