Automating the Physical World with Linux, Part 2: Expanding Control Automation
Up to now, we've focused on simple controls. The sprinkler and room temperature controls use a clock and a temperature input, respectively, as the state variable (that is, the state of our system). Our control algorithms simply compare the current time to a desired on-time for the sprinkler, or they check whether the room temperature is greater or less than our desired setting.
What I call computational control is a broad field. Many control systems rely on simple-to-complex arithmetic equations to perform control tasks. Our previous examples are essentially bang-bang controllers, so named for their on-off-on nature. These simple controls rely on Boolean states to provide control. Sprinkler valves are either on or off. Fans are either on or off. It's time to water or not. You get the idea.
But some types of control are more computationally intensive. Proportional control is one such type of control. Driving a car or riding a bicycle is a good example of a proportional function. Normally we steer based on the apparent errors our eyes see, which provides smooth, continuous control of the vehicle. The more you sense you are off center, the more you steer back toward the center. Your correction is continuous from zero to maximum left or maximum right. Imagine, however, trying to steer a vehicle if the steering wheel could only be maximum right or maximum left, not in between. The car would whip between full left and full right, giving you and any unlucky passengers a memorable ride indeed.
Proportional control is a control method that allows corrections to be made based on a proportion of the error. The error is the difference between a system's target value (what the system should be) and its actual value (its current measurement). This error is computed into a drive command to correct the system. Many highly accurate control systems are based on this control architecture.
Control applications using proportional control are a bit more difficult to develop. While I can imagine how to turn on my sprinklers, it's harder to create an equation that describes my method of steering (or my eyes' ability to identify the road). Also, computing arithmetic equations demands more computational time, as these equations may encompass integer or even floating-point operations. These functions require more time to process and have larger data types to transfer between the processor and the memory. In short, proportional control tends to be a science due to its increased sophistication.
Adaptive control is another computationally intensive type of control that essentially self-corrects based on historic trends and a set of correction rules. The benefit to this type of control is the ability to tune itself so changes in system performance do not require constant readjustment by the user.
In the past, I've worked with other control algorithms that rely on equations based on regression, matrix algebra and recursive processing and are so computationally demanding they almost contradict the notion of real-time control. Fortunately, computer hardware has become considerably more robust and affordable since those days. Some of the more elaborate research and development solutions from a decade ago could be adequately solved with today's high-end embedded controllers.
At this point, we've been operating on the assumption that our embedded controller can handle any control tasks we give it. The reality is the controller is limited, typically in its processing capability or software complexity. A controller's ability to handle control tasks depends upon several factors: the control methods used, the number of devices to be controlled and, finally, the number of other controllers that can be used in the control system.
Adding another controller to the control system is a natural response when my single-control computer becomes saturated or when the application is too complex to handle multiple tasks. Additional controllers may also be added to a control system for other reasons, such as to isolate system interactions and provide additional locations where maintenance personnel can examine or change the system's status.
Let's apply distributed control to the lavish resort described earlier. Room temperature controls and sprinkler controls are typically unrelated, and these two separate systems could control their own areas without any intervention. This is the simplest type of control distribution: two distinct software applications on two distinct controllers.
Controller distribution may be based on the need for a coordinated response by multiple systems or on physical planning considerations. A safety system may need to inspect smoke detectors, manual alarms, temperature faults or panic buttons more often than a sprinkler system. The safety system may also have to comply with local building codes; for example, codes typically require safety systems are dedicated without any other intervention. Some projects I've worked on had safety systems that required a redundant power supply and/or a fault-tolerant power supply. For sprinkler controls, these requirements are typically not necessary and are cost-prohibitive.
Controller distribution may also be based on the location of the system being controlled. In our large resort, for example, several guest lawns could be separated by miles. It would be difficult for the maintenance crew to inspect a water valve at one such lawn and then radio a command to the central office to activate a watering zone. Having a local controller at a lawn would allow the maintenance crew to inspect the controller and open or close the water valve on the spot.
Failure is another issue related to distributed systems. The control system requirements may specify a certain action or result if a subsystem controller fails. If our resort had a single controller and it failed, everything would stop, sprinklers, room temperature controls, lighting, etc. Designing around failure is itself an art. I've dedicated the third article of this series to the topic of system failure and how to avoid it.
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!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Astronomy for KDE
- Understanding Ceph and Its Place in the Market
- Maru OS Brings Debian to Your Phone
- Snappy Moves to New Platforms
- Git 2.9 Released
- What's Our Next Fight?
- OpenSwitch Finds a New Home
- The Giant Zero, Part 0.x
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