A few weeks ago, I asked readers to submit suggestions for instructional outcomes to be covered in my control systems classes this coming year (Automation Systems and Instructional Outcomes). One of the outcomes I feel is strongly required for students completing a one-semester course in control systems is an understanding of and an ability to utilize Boolean logic, and I thought I’d explore that material here this week.

What is Boolean logic? A completely dry and uninformative answer is provided by Wikipedia: “Boolean logic is a logical calculus of truth values, as developed by George Boole in the 1940s.” And, while certainly, true, this definition isn’t exactly…illuminating.

And about as useful as this.

A more useful definition? Well…Boolean logic provides a means of visualizing and mapping digital values in a system. Digital values have two states: on/off, 1/0, true/false. In many cases, control decisions can be represented as yes/no, on/off, true/false choices; by using Boolean operators and Boolean logic (sometimes called algebra), a control system designer can map out the function of a control system (or individual parts of a control system) schematically, before having to generate wiring diagrams or control code to implement it).

There are three basic Boolean operators—called gates—to consider: AND, OR, and NOT, and four ancillary operators that can be built from these basic three, but which are just as easily represented using symbols of their own: NAND, NOR, XAND, XOR.

Advanced Boolean Logic includes the Stargate.

The three basic gates are fairly simply to understand. Take, for instance, the AND gate:

The function of this operator is simple: if both inputs are “true,” the output is “true.” If either input is “false,” or both inputs are “false,” the output is “false.” We can illustrate this using a simple truth table to list the different possible input and resultant output conditions (or states):

The OR gate is as easily understood: if either (or both) inputs are “true,” the output is “true.” If both inputs are “false,” the output is “false.”

The NOT gate functions just as you might imagine, by negating the input. If the input is “true,” the output is “false”; if the input is “true,” the output is “false.”

By combining AND and OR gates with a NOT gate, we get the NAND (NOT-AND) and NOR (NOT-OR) gates—which essentially flip the results of the truth evaluations (see the tables below)

XOR—“exclusive OR”—gates evaluate to true only when both inputs are different. If both inputs are “true,” or both are “false,” the output will be “false.” If either input is “true” and the other is “false,” the output will be “true.”

Similar to the XOR gate, the XAND—exclusive AND—gate evaluates to true if both inputs are the same, but false if they are different. If both inputs are “true,” or both are “false,” the output is “true”; if either on is “true” and the other is “false,” the output is “false.”

This all seems relatively simple, right? The power in Boolean logic is that it can be used to manipulate truth states in a variety of complex ways: you can create schematics that perform mathematic functions on values (binary values, of course); you can create counters that keep track of the number of times an input changes state; you can create latched circuits that stay “true” or “false” even if the input between these states.

More importantly, by using Boolean logic to create a schematic of the functionality of a control system (as opposed to its data communication system), a system designer can consider how the system must function without becoming bogged down immediately in the specific hardware and software needed to build the system. This can make it relatively simple to develop a fail safe design; it can be much easier to run through a series of what-if scenarios using truth tables and simple Boolean operators than to try and trace a full wiring schematic or thousands of lines of code. Later, when the waythe system functions has been hammered out (and determined to be safe), it can be relatively easy to translate each part of the schematic into physical reality, using relays, logic controllers, microcontrollers and microelectronics, computer programming, etc.

For example: it may be desirable to develop a control system that requires two inputs to trigger an effect. This would cut down on the possibility of accidental firing. (This is common in an industrial setting as well, where two operators must have eyes on a piece of machinery and trigger its operation, or when an access door must be closed before an operation may begin.) Schematically, this is easily represented by an AND gate: only if both inputs are true (i.e., two buttons are pushed, or a door is secured and a button is pushed) will the output be true.

Consider a slightly more complicated example: let’s say we are designing a control system for a door which travels up and down within a flat. We might the door to only operate if no one is in the door opening. We might develop a portion of the control system to include an AND gate and a NOT gate:

The output of the NOT gate (and one of the two inputs to the AND gate) would be “true” only if someone (or something) wasn’t in the doorway; the second input for the AND gate would represent whatever mechanism triggered the activation of the door.

The Boolean schematic doesn’t specify any hardware or software, however; it only represents the control process. Once the control process has been tested, the design and implementation of hardware can proceed. In the NOT-AND example above, we might decide that a stage hand must have visual line-of-sight to the doorway, and be trained to only trigger the effect when they can see it is safe. We might, instead, include a light-curtain sensor in the doorway. Or, we might include a load-sensing bumper on the bottom of the moving door, or a load-sensor on the floor below it. Any of these sensors could provide the true/false input to the NOT gate in our schematic.

Regardless, we should probably post these around backstage. You know, just in case.

By spending time considering the logic of a control system before tackling the hardware and/or software, a designer can more readily work through a variety of what-if scenarios, providing for a more robust and safer system design. Additionally, the system design can be ported to multiple different hardware and software systems much more readily, because the system design doesn’t rely on any specific components; the same schematic might evolve into a design utilizing stagehand eyes and hands, or it might become a complex system utilizing multiple electronic sensors, microcontrollers, and computer software control. However, it’s worth pointing out that it’s most likely that the complexity of a particular schematic will inevitably lead to a particular level of complexity of hardware or software.