Automating the Physical World with Linux, Part 1: Control Automation
This is the first of three articles introducing the field of control automation and its use with Linux. Control automation uses software applications to monitor and control the physical world. Software for control automation is similar to most software Linux users are already familiar with, but with a twist; an application's input and output variables are retrieved from and sent to external devices in the physical world. Combining software with variables from the physical world, we can automate lighting, temperature control, safety systems, power management, autonomous robots, elevator management and flight-guidance systems, to name a few.
Linux brings many of its known advantages to control automation. Source code availability allows a software package to be built on any supported architecture and to be improved by others. Multiple architecture and platform support allows machines from supercomputers to pocket-toted PDAs to run a common application, while the ability to pick and choose from a wide range of hardware platforms allows cost-efficient and precise system selection for each task. In short, Linux brings software availability, system availability and cost-effective platforms.
Control automation is a vast topic; we'll discuss key items to help you identify the strength of automated systems. In my experience, many simple functions can be easily automated, and these simple functions can be combined to build a much more complex system. Chances are that you can implement most automation tasks on a Linux system.
In this first article, I introduce basic concepts for adding automation to Linux's repertoire of features. This article introduces the two fundamental building blocks of control automation: the data acquisition hardware and the software control loop. These building blocks form the basis of all automation systems, whether simple or complex. We'll learn more about these building blocks in this article by designing two simple systems: a control system for water sprinklers and a system for controlling the temperature in a server room.
My approach is to introduce a simple, defined control automation task. As we progress, I'll introduce more complexity into these examples. Complex automation systems are built around a set of simple control automation tasks. So, let's get wet!
My home has a fairly large yard (at least by urban California standards) and maintaining the plants requires a sizable automatic sprinkler system. The yard is covered by 32 sprinkler zones (a zone is a section of sprinklers controlled by a single water valve). The automation task for the sprinkler system, which is implemented in a control strategy, is fairly straightforward: I want to turn each zone on at a specified time and day of the week for a given duration.
To implement this strategy requires two steps: add hardware to interface with the sprinkler system and develop an algorithm to express the control strategy in code. For the time being, we'll use generic examples for the hardware and language used.
Step 1: Add a hardware interface to give Linux a way to ``drive'' our system. Here, ``drive'' simply means the ability to push a command to the physical world (in our example, an electrically actuated water valve). For this interface, we'll use a data acquisition device that translates physical world signals to computer-tolerant ones, and vice versa. The water valve is a control point for the data acquisition device.
Step 2: Develop an algorithm that describes how the sprinkler valve needs to be controlled. For our sprinkler system, this algorithm mirrors how I personally control a sprinkler zone: I water the orange trees, for example, on Monday evenings at 5:00PM for 20 minutes. The other zones are similar, except that day, time and duration of watering are different.
The algorithm, shown in Listing 1 in C pseudo-code, is straightforward: our control application waits for a specific day of the week and time to turn on the control point for the water valve. The software loop turns the control point on for the defined watering duration and then disables it. This solution may be expanded to the other zones of the yard by replicating this simple control loop.
Step 3: (I guess there is a step 3.) Once the control system is implemented, forget about turning sprinklers on and off manually and enjoy the fruits of our work (literally, in the case of the orange trees).
There are a few things to know about our simplified control example. First, this type of system is called an open-loop system. The control application uses time as the system state. Time is not related to the actual moisture in the ground, so this means that strange things may occur, such as the sprinklers coming on while it's raining.
Another is the ``sleep for a while'' comment. This part of the program controls how fast the control loop is performed. If this line weren't here, our loop would check thousands of times per second, needlessly consuming a great deal of processor time. In effect, a delay slows the update rate. The update rate reflects the speed at which we inspect our conditions and update the results. An update rate of approximately one second is fairly reasonable in this example. Other derivatives of Linux kernels offer a different way of controlling this rate, but this method is simpler and will work on any Linux distribution.
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
|Non-Linux FOSS: .NET?||Apr 13, 2015|
|Designing Foils with XFLR5||Apr 08, 2015|
|diff -u: What's New in Kernel Development||Apr 07, 2015|
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Play for Me, Jarvis
- Non-Linux FOSS: .NET?
- Designing Foils with XFLR5
- Not So Dynamic Updates
- Flexible Access Control with Squid Proxy
- Users, Permissions and Multitenant Sites
- New Products
- diff -u: What's New in Kernel Development