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.
A Coordinated Distributed System Example

Returning to our resort, I'd like to propose a distributed control system for the special events area with the following isolated control functions: an embedded controller for the lawn, an embedded controller for lawn lighting, a separate controller for pathway lighting and an embedded controller for area access controls.

If each subsystem were isolated without the benefit of receiving any requests, then each system would operate using its own control program without coordinating with other controllers. With the implementation of our network and data-exchange requirements, we can introduce coordination between control subsystems. Here's an example:

  1. The irrigation controller identifies it needs to water the special events lawn. It sends a command identifying the area to be watered across our network. (We'll call this message a pre-irrigation warning.)

  2. The affected systems receive the message, identify it's a pre-irrigation warning and take appropriate actions:

    • The lighting system reduces lighting for the special events lawn to encourage any guests present to depart and to dissuade other guests from entering the area.

    • After allowing a few minutes for guests to leave the special events lawn, the access control system closes gates to the area to prevent guests from entering.

    • The pathway lighting system turns off lights on pathways that lead to the special events lawn.

    • Once a delay has expired on the irrigation controller, it turns on the sprinklers.

The addition of communication between subsystems lets us make these isolated, distributed controllers operate as a loosely coupled team. In this example, with each specialized function, we were able to provide a passive and automatic means of preventing guests from getting wet by implementing a few command messages. Other features that may be implemented are limited only by your imagination.

Distributed System Coupling

Perhaps the last consideration in a distributed system implementation is coupling. This is usually a quantitative assessment of how loosely or tightly the systems interact or to what extent one system function relies on another system function. Our special events lawn example represents a loosely coupled system, since the failure of a subsystem would not result in a failure of the other subsystems. The higher the coupling, the more interactive the participation of a single distributed controller in the overall control solution.

Coupling may affect the distributed system design. Typically, the higher the coupling, the more responsive the communications interface must be. It may be necessary to consider binary format messages, higher bandwidth communications and higher throughput controllers. Failure and recovery is also an important issue. What response should our system take if a critical unit fails?

System planning and design architecture can relieve the level of system coupling. However, in very distributed systems, centralizing the entire system is impossible. Careful evaluation and planning determines the complexity or simplicity of the solution.


In this article, I've expanded our simple sprinkler and temperature controls into a more diverse system capable of automating a large commercial resort. The additional tasks of controlling lights, access or any other feature are based on simple control algorithms. While there are applications that might use significantly more complex control algorithms, a great number of the controls that exist in the world are quite simple and easily available.

I also introduced distributed control as a means for increasing control capacity, isolating critical and noncritical functions and simplifying the control architecture. However, distributed control requires additional functions. Distributed systems may have to exchange data to synchronize coordinated functions. Because Linux is available for many different processor architectures, data-exchange considerations must also be evaluated. Yet, with so many processor architectures currently available, these issues are pertinent to allow future cost-effective growth and maintenance of this system.

I've still been avoiding an extremely important issue: failure. Accounting for failure is as critical to a control system as the design itself. What happens, for example, if our resort's irrigation controller stops, and the golf course sprinklers stay on? There's the course damage, the cost of the water, the loss of revenues--talk about a water hazard! The inability of a control system to deal with the failure of a device--or failure of the system itself--may have catastrophic effects on people and property.

I'll discuss failure in the third and final article in this series. We'll look at approaches to designing and implementing a control system that will improve system reliability (or lower the probability of failure). I'll also describe active and passive methods to produce a safe control system.

Bryce Nakatani ( is an engineer at Opto 22, a manufacturer of automation components in Temecula, California. He specializes in real-time controls, software design, analog and digital design, network architecture and instrumentation. He is considering a short vacation at the lavish resort.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState