Linux and RTAI for Building Automation

This easy-to-deploy Web-based control system uses standard phone wiring and can manage any device that supports an infrared remote control.

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.

User Interface

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.

Hardware Architecture

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.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.