Automating the Physical World with Linux, Part 1: Control Automation

Earlier we mentioned the data acquisition hardware that translates physical world signals into computer-readable signals. In the control automation business, this hardware is broadly referred to as I/O, for input/output. This usage can lead to some confusion until you get used to it; people outside control automation who would describe hard drive access as I/O, for example, might wonder when a control engineer says, ``We just got some new I/O.'' Fortunately, you'll also hear the less cryptic terms I/O unit and I/O system used the same way.

I/O units can interface with a huge number of devices to detect conditions such as temperature, humidity, voltage, wattage and current. This is the input side of I/O. For example, you could determine electrical breaker status, lighting, the presence of smoke, inclination, open doors, low voltage, bad batteries and so on. In short, almost any condition we experience in the physical world can be quantitatively measured through a data acquisition system.

I/O units can also send, or output, a signal to a device. Discrete or digital outputs are analogous to a switch: they turn something on or turn it off. Anything that you would recognize as a switch function is controlled by a discrete output. Continuous or analog outputs are a bit different. Analog outputs deliver an electrical signal that varies in level and can be compared with older style volume control knobs, i.e., the throttle on your car or a temperature setting on a stove. These functions operate where typically a proportion of command is required instead of all or nothing.

I/O hardware is classified as either local or remote. Local hardware is usually an adaptor card installed in a server's interface slot. (Note that I say ``server'' because computers used for device control are typically servers or otherwise dedicated systems.) Remote hardware is connected via a communications channel, historically ARCNET or serial (RS-232, RS-485 or RS-422). More recently, Ethernet has gained in popularity; we'll look at this in more detail shortly.

Local I/O hardware is typically an extension of the main processor's memory bus. Due to the local interface, these devices are capable of very fast access times. The processor simply needs to access a memory location to send or receive data to a board. Local I/O hardware has several disadvantages. First, the Linux kernel must have a device driver and a user application module that interfaces to the device. Both are either provided by the manufacturer or created by the developer, causing anxiety in many novice or inexperienced software developers. Another disadvantage to a local interface is that local devices are exclusively owned by the local server; that is, another system requesting data cannot easily access the device.

Recent trends in computer form factors make local I/O hardware difficult to install. Rack servers may not accept adaptor cards; although they may have expansion slots, it may be physically impossible to install cards due to the thin packaging. Internet appliances and embedded architectures do not offer any adaptor card expansion. The addition of a larger package and slot connectors dramatically increases the cost of manufacture and may make the device too large for the application.

In addition, maintenance of local I/O hardware is difficult. Any inspection of the card requires screws to be removed and possibly the card as well. While there are PCI architectures that are ``hot-swappable'' (hardware can be replaced without turning the system off), these machines are significantly more costly. If you don't have a hot-swappable server, then I/O hardware maintenance will require the server--and thus your control application--to be shut down. This doesn't work well if you also use your server for web serving, file serving or another dedicated function.

For our sprinkler example, I'll use a remote I/O unit that interfaces with the server over Ethernet (Figure 1). I'm avoiding a local adaptor card (Figure 2) because of the disadvantages discussed above. Both the I/O unit and the adaptor card happen to be made by my employer.

Figure 1. Remote I/O Unit with Ethernet Interface

Figure 2. Local Adaptor Card

Using Ethernet-based I/O hardware provides an additional layer of electrical isolation, which can be important when accessing lights, switches and other electrical devices in the physical world. If I accidentally short one of my server cards (that is, cause an electrical fault), I'm certain to destroy the rest of the server. With isolation, my server remains protected. In addition, I can maintain the hardware by disconnecting the patch cord, not turning off the server.

Another benefit of using Ethernet is that thin servers and dedicated internet appliances offer Ethernet connectivity, thus taking advantage of an already installed interface. Linux people use TCP/IP daily, usually without a second thought. There are also other advantages we'll discuss later in the series that make this a very popular and preferred interface.