Control Engineering

David Chappell

Documentation: Left to right, top to bottom or random spiral?
January 7, 2008

How do we represent concepts and implementations of things in an understandable and consistent way? As far as I can determine there is no consistency even within technical disciplines much less across disciplines. 

This can lead to misunderstanding and more time spent on debating and defining a documentation approach than evolving the concepts that are being discussed. Symbols have a better chance of being standard but even here there are opportunities for which “standard” symbol is used and the real confusion of how they are arranged to convey usage can become a real grab-bag of successful but different approaches. (Two example diagrams appear below.)

I have been exposed to several “single-line” approaches used to document how power is distributed in a factory. In one case a left to right approach was used to demonstrate the flow and connections used and in another it was top to bottom. I have also seen different approaches used in representation of electronic circuits, the most prevalent I have seen is where inputs are represented on the left, logic in the middle with the logic flow from top to bottom and outputs on the right. But even here there are exceptions. Trying to represent relationships between the functions provide by the circuits is a daunting task, a single function might interact with hundreds to thousands of other functions and trying to represent all of them in detail on a single comprehensive diagram is not feasible. Developing ways to “cross-reference” and “share” between functions becomes a requirement with many different solutions.

The approach used to represent an implementation of something often depends upon the background of the people involved in the generation and review of the documents used in that implementation. It makes perfect sense to that group but when others that have a different approach are exposed to the documents the knee-jerk reaction often is “that is really stupid.” With that mindset it can be difficult to tell if the concept being documented is “stupid” or the way it is being represented is “stupid” or the people involved are considered “stupid.” Unfortunately, the result is that sharing ideas becomes more difficult as insulting thoughts escalate.

In the Make2Pack work we find ourselves struggling to represent many concepts simultaneously, control hierarchy, variable control component interaction depending upon current function and mode, and physical relationships with actuators and instruments. How to organize the different symbols we are developing is almost as much of a challenge as developing the concepts themselves! We need to explain the concepts behind what the symbols represent and how they are used to satisfy complex automation needs. A dizzying multitude of solutions are met with as many different ways to represent them.

The current Make2Pack approach is to demonstrate the flow of control in a top to bottom approach as shown in the PID Cascade control diagram. As you “drill” down into each component on the diagram it exposes more details of how that component satisfies the functional requirement by exposing more components and how they relate and interact as shown in the single PID example.

As the working draft evolves the approaches used will be documented but are not intended to infer or become the only way that applications can be documented. Some of the new symbols will become a requirement but how they are connected will not, and should not, become a requirement. These diagrams are only a few that are being developed and must be evaluated as a whole to fully understand the Make2Pack concepts, but hopefully they provide some insight into the Make2Pack thinking.

Share your answers to these questions: When have you found documentation, symbols, drawings for automation and controls to be confusing or inconsistent or clear and consistent? Have you found that different diagrams can represent the same underlying concepts? Click here to share your views or resources on documentation, symbols, drawings for automation and controls (replies may not be immediately posted).

Other links:
ISA standards: 
     Search on diagrams within the ISA Standards search to find related results.
     Searching on diagrams at the ISA Website brings up these resources.
Control Engineering:
     Searching on diagramming at Control Engineering brings up these results.

A representation of cascade PID is shown here.

Posted by David Chappell on January 7, 2008 | Comments (1)