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.
Coordinating Distributed Systems

In some cases these independent control systems would require coordination. In the resort, access controls could prevent hotel guests from walking on the lawn when watering is about to start or is in progress. They could also interact with the lighting systems to turn them off during watering to save electricity. Safety systems could trigger the access controls to turn on high-visibility safe route signs and open all doors. The safety system could also trigger the lighting system to turn on all available lights and pathway lighting so guests can easily find their way to safety. Figure 3 lists the requirements to connect two or more separate embedded systems.

The first requirement is a common communication interface that supplies a path for data to be shared among different controllers. It must be widely supported and accepted, and it must be available on potential candidates for the hardware controller. This interface must also have long-term support, as the life cycle of a control system may exceed ten or more years.

Data capacity is the second requirement to connect separate systems, and the communication interface throughput must be significantly robust. This data interface needs to adequately supply the data requirements of the current system and also be able to accommodate possible upgrades and additions to the control system during its life cycle. If the interface can't accommodate future updates, it should at a minimum be capable of bandwidth expansion.

Physical expanse is critical as our resort may sprawl over 20 square miles; therefore, this communication interface must be able to operate adequately over excessive distances. A communication interface that reaches a few meters simply won't do. Accurate distance calculations should be compared against design plans of the resort to insure distances are within acceptable tolerances.

Message protocol is important because messages will commonly be exchanged between our controllers. While initial installations may use the exact same hardware architecture, this may not be the case throughout the life cycle of the control system. The diversity of Linux architectures allows you to use the best architecture (performance, cost, availability, size, power requirements, etc.) for the application. A replacement controller in the future, for example, may be a different architecture altogether. Another important Linux advantage for controllers is that GPLed code may be ported to another architecture or operating system. It's imperative that considerations in common protocols be emphasized for portability and long-term code support.

Finally, all of our control systems must be able to understand and interpret the message data that each one is sending to another, so data compatibility is a must. While this is typically not a fundamental problem, problems can be created by different core processors manufactured by competing companies. Again, Linux's diverse architecture support raises this concern. In general, data may be transferred as readable ASCII data (a standard character-representation format) or as unreadable binary data. Both have their strengths. Binary data is an exact computer representation and requires little overhead for a computer to send or receive. Using ASCII adds an overhead for binary-to-ASCII and ASCII-to-binary conversion. Debugging binary data may be difficult, while ASCII is relatively straightforward, due to its readability. Binary message formats are typically faster because there is little overhead to process the information. An evaluation of binary vs. ASCII requires some broad considerations when dealing with the multi-architecture nature of Linux.

Our Distributed Controller Interface

Ethernet is an excellent solution for our distributed controller interface, as it is a commercially accepted interface available on virtually every computer architecture. Therefore, it supports our commonly available connectivity solution.

Our control functions typically need to inspect the systems' states every second or so, which is a minimal bandwidth requirement for Ethernet. With 100Mbps and 1Gbps fiber and copper networking solutions available, a higher bandwidth control system could be implemented later. Also, if our resort had an existing Ethernet network installed and its bandwidth would not be impacted, our system could be added to the extant network.

Our sprawling resort may have cables running distances up to several miles, whereas Ethernet has fiber options that range up to several kilometers in length. With a fiber installation, our large resort could be a single Ethernet segment. If the expanse is excessive, a WAN and a routed multisegment network could be implemented. Keep in mind the Internet is an extremely expansive, routed network.

While many networking protocols can be used to send messages over Ethernet, I prefer TCP/IP (and its counterpart UDP/IP). Using a widely accepted protocol gives more control systems the capability of communicating with my devices. Also, the addressing implementation allows for a reasonable number of devices to be accessible on our network. Some systems use raw proprietary protocol sockets. With considerations of GPL available code, raw sockets may be difficult to maintain across other systems, particularly non-Linux operating systems. While there is additional overhead in TCP/IP, it is insignificant compared to the update rates of our systems.

I would use ASCII (readable) messages for my message data exchange. I like the ability to read messages and possibly use other tools, such as Telnet, to communicate to another device.

Binary Data Considerations