Automating the Physical World with Linux, Part 2: Expanding Control Automation
This article is the second in a series of three introducing the field of control automation and its use with Linux. In this second article, I'll cover the concept of control automation in increased detail, describing simple as well as computationally intensive types of control that Linux-based computers can handle. I'll also discuss distributing control functions among multiple computers so a single computer does not have to perform all the control functions. Finally, I'll describe some reasons why this might be advantageous or even required.
With the arrival of the vacation season in the Northern Hemisphere, I'll also introduce a hypothetical resort. For control automation applications, a resort is a wonderfully lavish environment with golf courses, pools, landscaping, fire and security alarms, lights, climate-controlled guest and banquet rooms, lighted walkways, automatic access controls and other items that are ripe for control automation solutions. We'll apply the sprinkler controller and temperature control ideas from the first article to various items in this environment.
The first article introduced the examples of a sprinkler system and a simple temperature control system (see ELJ May/June 2001). The sprinkler system turned on the valve for a single watering zone at a given time and day. The simple temperature control maintained the temperature of a room, by turning on a heater or a fan, based on the room's current temperature.
The first article also covered fundamental requirements for control automation: the data acquisition hardware, called the I/O unit; the software control algorithm and its loop time used to automate the control task; and the use of Ethernet as a link between the computer running the control program and the I/O unit. (In control automation the computing device running the control program is rather imaginatively called a controller or embedded controller. We'll use these terms from now on to refer to a Linux-based computer running the control algorithm.)
The I/O unit provides a physical interface from the controller to the environment. For the examples in the first article, I could have performed the control tasks manually by reading a temperature gauge, watching the clock, turning on a sprinkler valve, turning on a fan or turning on a heater. An I/O unit allows the controller to accomplish the same physical tasks without human intervention.
The software control algorithm describes how a device must be controlled. In the first article, I examined the specific tasks I needed to perform manually in order to control the sprinkler and temperature control systems. I then developed a software control algorithm to perform these tasks. I also added other functions to initialize and terminate the program. While this may sound oversimplified, it's not; most automated controls are based upon manual actions.
The loop time is the interval or rate at which the software control algorithm examines and updates the system. Our initial examples were intentionally slow and unresponsive compared with Linux process times and performance. This approach avoids the complexities of dealing with process task switching and process latency times.
Finally, we also looked at the use of Ethernet networking to link an embedded controller and one or more I/O units (see Figure 1). Using Ethernet offers several benefits: network adaptors are well supported, which avoids the need to create a device driver, and external Ethernet-based I/O hardware lets us maintain I/O hardware without having to interrupt or open the controller. Additional advantages to using Ethernet networking include its common installation in many facilities and the easy expandability needed for commercial systems. We'll rely on this ability to expand when we add additional control functions later in this article.
Most of you are probably thinking that sprinkler and temperature controls are conceptually trivial. They are. These types of controls are implemented on silicon stamps (powerful compact microcomputers) and are readily available in any hardware or home improvement store. Running these controls on an embedded controller won't even exercise Linux. I'd be surprised if CPU usage exceeded 0.1% with this kind of control application.
The minor processor utilization allows us to add more sprinkler zones and temperature controls. Even modestly powered embedded hardware could control several hundred such zones before any real workload is created. For example, a resort with golf courses, lawns, access controls, tropical gardens, fountains, air conditioning and lighting could be controlled entirely by a single application running on a single embedded controller.
How is a control system expanded? The obvious answer is more software development and additional I/O units. But how should you approach this expansion? What fundamental questions must be answered before planning the expansion?
When I plan to expand a control system, I first group similar control elements together. I might group sprinkler zones in one function and temperature control in another, for example (see Figure 2). The grouped functions operate in a continuous control loop. Listing 1 shows an example of grouped functions in C pseudo-code.
Specific programming environments for Linux also provide multithreading capability. We could run the sprinkler control tasks at the same time we run the temperature tasks.
Multithreading is useful since independent threads may take advantage of unused or sleeping time by the other tasks. For more information on how Linux implements multithreading see the excellent Pthreads Programming: A POSIX Standard for Better Multiprocessing by Bradford Nichols, et. al. (O'Reilly & Associates, 1996).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide