Automating the Physical World with Linux, Part 1: Control Automation

Whether communicating with a local or remote I/O unit, a data protocol is used to define how an application sends data to and retrieves data from an I/O unit. Data protocols have historically been cryptic, as computationally limited devices need compact packets and easy parsing ability. However, while our selected I/O hardware has a data protocol, it has the advantage of using standard TCP or UDP sockets to transfer the data between client and server.

Writing your own library to handle the data protocol can be quite involved. Most manufacturers have documentation and software support for their data interfaces. For this I/O device, however, a small protocol library for the device shields the developer from having to deal with the cryptic data interface or even with TCP/IP sockets.

Unlike our earlier example of an open-loop system that was time-based, a system that actively reads the state of the system and attempts to correct it is called a closed-loop system. As an example, let's use my network server room, where I would like to stabilize the temperature. The input is the state of my system, temperature in this case. The output is the result that tells me to turn on a fan or a heater. The strategy is the method of computing the input to determine the output. The system's update rate can be fairly slow because most heating and cooling systems aren't capable of extremely rapid temperature changes.

Like the design approach for the sprinkler system, we'll start with a method similar to the way we would do it in our world. We would look at a temperature gauge and compare the temperature to our high and low limits. If it has reached one, we'll turn on the appropriate fan or heater to correct the room's temperature. Listing 2 has the algorithm to do this in C pseudo-code.

Listing 2. Temperature Algorithm

The function of this loop is to check whether the temperature I enter is above 70ºF. If so, it will tell me to turn on a fan. If I report a temperature that is below 65ºF, it will tell me to turn on a heater. Ideally, my logic is designed to keep the system temperature between my two limits. The speed at which this loop is computed is as fast as I can enter the current temperature.

Listing 3 shows the same control loop, this time including the hardware interface. It looks very similar.

Listing 3. Control Loop with Hardware Interface

In this first article I have discussed some basic automation concepts and introduced the two main building blocks of control automation: the data acquisition hardware and the software control loop. The software algorithms model the way we would control a sprinkler system or a server-room thermostat manually.

With additional data acquisition hardware, Linux is capable of monitoring and commanding our physical space. In turn, the addition of automation improves the safety, efficiency and capability in our lives by performing tasks for us.

In the next article, we'll introduce other areas where control exists, expanding our sprinkler system in the process.