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).
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Back to Backups
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Google's Abacus Project: It's All about Trust
- A New Version of Rust Hits the Streets
- Secure Desktops with Qubes: Introduction
- Seeing Red and Getting Sleep
- Fancy Tricks for Changing Numeric Base
- Secure Desktops with Qubes: Installation
- Working with Command Arguments
- Linux Mint 18
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide