Automating the Physical World with Linux, Part 2: Expanding Control Automation
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:
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.)
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.
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 (email@example.com) 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.
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
- 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
- CentOS 6.8 Released
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