Support-focused enterprise controls series
This article is the introduction for a series of five articles that explore the critical components of a support-focused controls system.
An article in the September 2014 issue of Control Engineering reported the origins of the first programmable logic controller (PLC). It described a race to produce a PC-based or special logic controller to enable control system applications. The proponents of the special controller envisioned how the design would replace relay-based control systems with a PLC. The article went on to describe how PLCs would improve machine diagnostics, decrease panel space, and reduce maintenance costs. Examining the state of PLC designs today, it is obvious that they have only partially achieved their originally intended goal. It is true that PLCs have enabled designers to provide better diagnostics while allowing them to decrease the size of control panels. From a maintenance perspective, PLCs have replaced many hardwired relay circuits that used large panel-mounted relays with controller-based logic circuits.
Since the development of PLCs, manufacturers have shed the use of relay-based control systems, reaping the panel space and diagnostic benefits. However, manufacturers have not realized significant maintenance savings costs. This is a result of machine suppliers providing chaotic PLC applications that offset the maintenance costs by increasing support costs. The cost increase is directly associated with how PLCs make it possible to increase the sophistication and flexibility of automated machines. As a result, there is an increased need for technicians to support many uniquely formatted PLC applications coming from various machine suppliers and system integrators. Each application is customized to fit the perceived needs of each machine. Unlike simple relay-controlled machines that have a small number of circuits, new PLC applications have thousands of custom logic circuits. These circuits must be understood before technicians can safely change them to support the manufacturing process. Understanding the many different circuits becomes the maintenance-related support problem. The problem surfaces when technicians are pressured to quickly identify device failures or make repairs, or the logic changes before restoring a machine to an operational state. The cost of production delays increases maintenance-related support costs.
Another indication of the maintenance-related support problem comes from the ongoing debate about whether control systems should be PC-based or PLC-based applications. PC-based advocates argue that computer environments help designers to produce structured applications that are easier to support, whereas those wanting PLC-based controls explain why logic circuits are needed to support the agile nature of flexible machines. Both sides have valid points. So what is the answer? There are PC-based designs running in industry today. However, under close examination these applications function in support of machines that have rigid sequences. Therefore, the answer is likely a hybrid solution where a PC-based application enables a standard design and the operational support of PLC-based logic circuits. It is not hard to understand that the current development methods are expensive to execute and the finished products are difficult for technicians to support. Furthermore, it is hard to imagine that the design process used in the 20th century to produce, debug, and reproduce logic circuits will continue indefinitely into the future.
In the future it is not hard to envision a support-focused enterprise controls software product that will provide users with an interactive interface to a machine's PLC program. As an alternative to simply showing technicians enabled circuits, this new product will provide technicians display screens that will show the physical movements of objects and mechanisms. Instead of just enabling designers to make changes directly to circuits, the product will also allow technicians to change the properties of displayed objects that will cause automatic logic circuit changes. The product will enable manufacturers to control the important electromechanical elements of machines. The interactive software will allow for systematic, rule-based construction of logic. Because the construction rules are interactively documented, technicians will not get confused when they examine various rung constructs produced by different designers.
The product will enable manufacturers to control and a designer to import the cornerstone circuits that act as the foundation for all station-specific logic. A solid foundation enables a standard way to have all designers incrementally develop the standard logic that controls the movement of objects and mechanisms. The design process will follow a structured set of rules used to construct logic. The development tool will also allow designers and technicians to configure and reconfigure shift-register applications. The development tool will allow for the insertion and sequenced activation of custom-made logic templates. These templates will conform to standard interlock signals associated with control logic and data elements residing in shift-register applications.
For a support-focused enterprise control system to be widely accepted, it must force designers to shed many of the bad programming practices found in today's applications. These bad practices are typically associated with shortcuts designers take to replicate their designs. Some of the practices have been unknowingly enabled by PLC manufacturers that equip controllers with advanced features. The misuse of these features is just one of many reasons designs go off in chaotic directions. Other aspect are related to logic styles preferred by different designers. The misused features and erroneous styles only act to conflict with a support-focused design. This is mostly a result of support personnel not understanding the reason for various rung constructs to enable similar tasks. The basic logic design premise targets technicians understanding logic over original equipment manufacturer (OEM) designers providing logic based on quick replication and configuration processes.
During the early years of PLCs, a controls design team developed a matrix-based program that was able to self-generate Boolean equations. The team worked for a Boston-based software company that developed a Boolean development tool for Allen-Bradley. Using the Boolean development software, the designers were tasked to produce PLC logic for large, multistation welding machines used in the automotive industry. The control system designs for these machines included the following types of applications.
- Event-based application: a software program that uses a specific event to launch a logical series of examinable steps that either pass or fail.
- State-based application: a software program that examines many discrete variables to identify the physical state of mechanisms before enabling movement.
The control system programs for these multistation machines included both event- and state-based applications. The event-based applications were simple circuits used to move data, and latch and unlatch Boolean signals. The state-based applications sequentially enabled outputs to control a set of machine mechanisms. Each machine state is a set of examinable signals that are in a known pattern before the mechanism moves. The idea was to divide the machine's mechanisms into sequential motion groups. These were the mechanisms that sequentially cycled together, asynchronously from other machine mechanisms.
The design process included constructing a matrix for each motion group. The matrix had columns to represent a mechanism's movement, and rows to represent the state of sensors and interlocks from other sequential motion groups. The top row of boxes contained special codes, output addresses, and movement description information. Similarly, the first column of boxes contained sensor address and description information. Each box in the heart of the matrix contained a number. A zero meant it was off and stayed off when the mechanism moved. Similarly, the number one meant it was on. The matrix application used the number transitions in adjacent columns to determine which inputs were expected to change state when a mechanism moved. The process also allowed designers to place a dash character in a box normally containing a number. The dash represented a don't-care state for the designated signal for the column-defined motion. The next part of the design process was the execution of a Fortran program to evaluate the matrix. The output of the program was a set of tag-based Boolean equations for each column-referenced motion and a tag-referenced address and description list. The output equations and tags were compatible with the Boolean development tool that when executed converted the equation and tag files to a PLC-downloadable logic file and printout with annotated documentation for each signal-addressed variable.