Automation controls can be complex beasts, and wrapping one’s head around the entire breadth and depth of the system can be both daunting and overwhelming. Even a simple system can contain a dizzying array of sensors, drives, controllers, human-interface devices, logic processors, indicator lights and data feedback devices. How do you keep it all straight? When designing a system, how do you even begin considering all of these various elements, and how they interact with each other?

Two weeks ago we looked at Boolean logic as a means of understanding and evaluating the control process; the functional block diagram can be an exceptionally useful tool for visualizing the physical components and topology of a particular control system. (John Huntington, in his book Show Networks and Control Systems—now in its fourth edition!—provides a nice, simple definition of “topology”: “the way in which a system is physically connected, or laid out, is its ‘topology’.”) Though the definition is relatively simple, the actual topology of a system can be extraordinarily complex, as it comprises every single component of the control system, every wire, every switch, every sensor and every logic processor. And the functional block diagram is a tool we use to visualize and organize the system before we begin just plugging devices into each other.

You probably have seen a functional block diagram before, but don’t realize it: a wiring schematic is an example of a highly-detailed functional block diagram, as is a sound system riser.

(The third image on the web page of Amy Altadoona, sound designer from Yale School of Drama, is a great example of a typical sound system block diagram.)

In a sound system block diagram, components are represented using graphical symbols (like speaker drivers, microphones, and amplifiers) or simple boxes (like processors, mixers, etc.). Connections between components are made using lines; these lines represent signal paths in a system. In some functional block diagrams, arrows may be used on single paths to indicate directionality of data flow (these are often omitted on sound system risers, as nearly everyone who reads them understands in which direction audio signal will flow). Displaying components as symbols (even as simple boxes) and data flow with lines provides for a high-level understanding of the overall functionality of the system.

The key to functional block diagrams, as related to their use in designing a control system, is that their level of detail can vary from very general to very specific. Indeed; in many cases, a component (or process) represented as a single symbol on one functional block diagram may easily be represented as a complex functional block diagram of its own. This provides a useful way to break the complexity of a control system into easily-managed chunks; in early drafts, a complex control system can have a relatively small number of function blocks, with each block representing a complex sub-process that can later be fleshed out in more detail. Eventually, as a functional block diagram is revised, it will achieve a level of detail whereby each block represents a specific component or piece of hardware.

Consider a simple scenery control scenario, in which a pneumatic cylinder is used to push open a door. (We will assume, for the moment, that the mechanical design for this effect has already been completed.) Let’s consider a simple version of a block diagram for this system:

Simple, yes? Something—a controller—sends a command to the cylinder to move. But as we consider more fully how the effect needs to work and how the system will function, these blocks can become more specific, and we’ll end up adding additional blocks. Consider, for example, that we may want to have the ability to control velocity of the cylinder move by changing the flow rate of the air exiting the cylinder as it moves. That might include another set of components—we’ll need some kind of a flow-rate valve for each direction of movement, and some kind of sensor to determine velocity; we can also replace the “cylinder” node with one representing the directional control valve (DCV), which will determine which direction the cylinder moves.

Now…let’s step back for a moment—there’s nothing to say this effect needs to be controlled electronically. This system could easily represent a human operator controlling the cylinder with a manually-operated directional control valve and manually-operated flow control valves, who determines the proper velocity by watching. This would collapse the system considerably, as the “controller” and two “sensor” nodes would simply be replaced by the operator.

However, if we were to want to control this effect electronically, there are refinements we can still consider. How does the operator get information into the controller? Are there safety sensors to prevent the door from swinging open into an actor’s face?

From this simple diagram we can begin asking more specific questions: do we want to use a programmable logic controller as the central controller? A microcontroller? A desktop (or laptop) computer? Each of those decisions would require a revision to the “controller” node, as components would be required in each case to both receive data from sensors and the HMI (human/machine interface) and to output data to the field devices (the DCV and the flow rate valves). These choices will also affect the design of the HMI. Additionally, knowing how many different moves will be required, whether each of those moves will need to have different velocities, and whether changes will need to be made to the cuing of the effect quickly during the technical rehearsal process will all affect the evolution of the HMI and controller blocks of our current drawing.

As the system is fleshed out and becomes both more detailed and more complex, we can keep returning to the functional block diagram, revising it and adding more detail, taking each component and process separately and then determining how each revision in one area impacts the overall system. Eventually, as the physical components and connections of the system become more finalized, our functional block diagram can easily be revised to become wiring schematics and drawings of physical layout specifications. Instead of having to later determine these things (and probably discover the need to revise parts of the system design) they will arise naturally out of the functional block diagram as part of a cohesive conception-to-installation design process.