Automating the Physical World with Linux, Part 2: Expanding Control Automation

In this article, Bryce gets us out of the house and into our new resort.
Introducing Computationally Intensive Controls

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.

Introducing Distributed Systems

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.