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