Support-focused enterprise controls: template design strategies
The primary purpose of a support-focused control system is to produce a programmable logic controller (PLC) program that is easily understood by technicians. Hence the need for simple rule-based controls that provide common circuit constructs for conveyors that move objects and machines that move mechanisms. Together conveyor and machine applications interact with the majority of discrete inputs and outputs. Most manufacturers that have a process design team that focuses on developing applications that minimize the chance technicians will become confused. They recognize that design-induced confusion will extend downtime events.
On the other hand, many controller experts and information technology (IT)-appointed system integrators do not have this focus. The focus differences are a result of experts having unique perceptions of what are important characteristics to their design. Regardless, the expert selected to provide template-based applications will likely adopt one of the two following programming strategies:
- Independent programming strategy focuses on what the programmer considers important characteristics of a finished application.
- Interdependent programming strategy emphasizes enabling many engineers and trades personnel to understand, accept, and support finished applications.
Highly productive manufacturing processes rely on standard, controller-based system applications. These applications must appeal to the technicians and engineers who will need to understand, interact, and support functioning programs. Therefore, designers must know their support audience. Specifically, designers must do everything possible to make sure support personnel do not get confused when they interact with their applications.
Designers who remain focused on their support audiences will automatically provide interdependent applications. Unfortunately, most designers never develop applications with the expectation that others will support them. Instead, they have a focus on making it easy for designers to install, configure, and replicate. As a result, independent applications will always appeal to the few highly intelligent experts who are able to understand, interact, and support functioning programs.
The dependent or interdependent programming strategy a designer uses to develop an application has a different effect on code training, operation documentation, and accepted level of complexity. When designers produce applications using the independent programming strategy, there is a recognition that only like-minded designers need to understand the details of the code. This means designers will not train machine or process support personnel on how the code works. As a result, most training documents will center on how to install, configure, and replicate the code.
When designers produce applications using the interdependent programming strategy, there is an expectation that control system personnel will provide operational support for the code. This means associated training documents will describe what the code does and how it works. The accepted level of complexity varies when designers identify upper-level system deficiencies. Independent designers are usually willing to correct deficiencies by moving functionality and associated complexities to their program. Interdependent designers are more likely to argue for correcting deficiencies as they recognize that associated complexities will make applications difficult to support.
When independent designers make code adjustments to correct system deficiencies, the resulting design becomes the accepted norm. This complicates the effort to get future system designs fixed. When interdependent designers resist adding complexities, more designers will begin to focus on the problem, understand support implications, and request system-level changes to correct deficiencies.
Designers of independent applications often develop software modules and templates as building blocks for many similar applications. Using the building blocks, they are able to create many highly configurable applications. To configure each application, they create special circuits and bring them to the forefront of the application for everybody to see. Some configuration circuits determine the behavior of the application. In an interdependent environment, configuration circuits take a less prominent position in the program.
In most cases, application variables are hard-coded at the point where the application utilizes the information. Secondly, designers of interdependent applications customize each application to acquire the needed station behavior. Customizing the application eliminates the need for behavior-controlling configuration circuits. Not having these configuration circuits eliminates the possibility that support personnel may get confused. The absence of these circuits also makes it impossible for confused support personnel to modify them to change the application’s behavior.
Many designers make the claim that "code is code" as long as it performs as specified. If the design specification used to produce code only defines what the application must do, the development process leaves it to chance as to how each programmer will write the code. At this point, the occupational and education programming experiences of the programmer will determine whether the application adopts an independent or interdependent programming strategy.
Controls experts understand processes, equipment, and their inherent support requirements, so their programming style places emphasis on fulfilling these requirements. In contrast, controller experts have a high degree of expertise in the operation of a PLC and its capabilities. As a result, the controller expert’s programming style will take advantage of the nuances of the equipment in order to minimize the effort required to develop applications. Controller experts test their applications in isolated laboratory environments, causing them to focus on making finished applications easy to install, configure, and replicate. Manufacturers always ask controller experts to develop code based only on what an application must do. Controls experts already know what their machines and processes do, so design specifications dictate code styles.
Most machine and conveyor suppliers produce control applications that adhere to detailed specifications written by their customers. Specifications written by experienced designers will attempt to control what the code must do, but it will also control the style of the code. To help control the style of an application, specifications describe the "do’s and don’ts" of a design. This section of a specification determines the independent or interdependent characteristics of applications.
There are several underlying reasons why designers produce independent applications. The biggest factor is the occupational experiences and the enthusiasm designers have. Enthusiastic controller experts are prone to develop independent applications thinking they are being innovative. This means they will pay little, or no, attention to programming standards and specifications used to govern the development of control applications. Then there are controller experts who are not motivated to understand design specifications and just decide to do it their own way.
Resulting independent applications are either accidents born of naiveté or errors caused by laziness. Second, the level of security designers have in their jobs sometimes drives them to develop independent applications. Insecure designers tend to want to show off or deliberately put themselves in a prominent support role. For these two scenarios, the resulting independent applications are not accidents, but deliberate attempts to prove to others that they are indispensable. Sadly, enamored inexperienced users see the short-term glamor of such programs and fail to recognize that these designs have a long-term negative impact on supportability and productivity.
It is important for system designers to know that most manufacturers always expect controls experts to follow specifications that govern the style of control applications. They must also know that the style of control applications must match the skills of a targeted support audience. Most controls experts understand technicians are the audience. They also recognize that technicians must interact with their applications when something goes wrong to shut down the manufacturing process. This means recognizing that technicians must be able to efficiently interact with applications in order to return a machine or process to regular operation.
Making sure applications do not confuse electricians is paramount to enabling them to interact quickly to restore operation. Controls experts recognize that by eliminating application-induced confusion they can minimize the amount of machine or process downtimes. There are six cascading reasons why designers should produce interdependent code: 1) eliminate induced confusion; 2) improve support efficiencies; 3) minimize downtime periods; 4) maximize uptime durations; 5) boost production output; and 6) increase company profits. Oftentimes, controls experts realize keeping their job is an important seventh reason for producing highly supportable applications.
Many managers who work for manufacturers do not know the "do’s and don’ts" or how to control the style of controller applications. As a result, they will not be able to control the independent or interdependent nature of PLC programs. If system strategists want to avoid this predicament, they must understand the design characteristics of applications and the motivations behind the designers who develop them. Keep in mind it is very easy to design code that like-minded designers understand, whereas it is difficult to produce code that everyone can understand. The subsequent subsections attempt to describe and compare the differences between applications developed using independent and interdependent programming strategies.
Designers develop independent applications using nonapproved, unconventional, and sophisticated programming techniques. Manufacturers, through specifications, prohibit control system designers from using these techniques because they overcomplicate their ability to read, understand, deploy, and support finished applications. Regardless, sophisticated programming techniques usually involve designers using loop logic, advanced instructions, indirect pointers, aliased signals and variables, local-only signals and variables, layered display objects, and multiplexed routines.
Controller application specifications normally prohibit the use of sophisticated programming techniques without explaining why. Loop logic is a programming technique that interrupts the execution of a control application while it typically loops to perform a noncontrol task. Support personnel that are not familiar with loop logic can accidentally change it and place it in an infinite loop. Placing any controller application in an infinite loop can have a disastrous effect on a machine or process. Advanced instructions are sometimes designer-customized instructions. Most support personnel do not understand or are not familiar with their specific operation.
When support personnel encounter advanced instructions, they become confused as to their purpose or operation. Indirect pointer applications create confusion when support personnel do not recognize that the value of a variable indirectly affects another variable. Like loop logic, incorrect changes to a pointer’s variable value can be detrimental to normal operation. Aliased signals and variables cause confusion because most support personnel prefer to reference each signal one common way.
Eliminating aliased signals and variables removes the possibility they can confuse support personnel. Similarly, local and global signals and variables with the same name increase the probability that they will have the same name found in two different logic routines. Layered display objects confuse support personnel because most would prefer to have one application variable control a specific piece of real estate on a display screen. Multiplexed routines cause confusion when support personnel fail to recognize that one routine is sharing input information to generate time-sliced output information.
Designers who develop independent applications always seem to be able to justify their designs. Most designers come right out and describe how nobody needs to know how their applications work. They state their applications are like black boxes or appliances. They assume that only like-minded designers need to understand how the code works and how to change it. Somehow, they lead themselves and others to believe they are developing something strategic. Proponents point to: 1) efficient code execution, 2) ease of deployment, and 3) modular replications as tactical reasons for developing independent applications.
In reality, none of the claims have merit over applications developed using the interdependent programming strategy. Most proponents of independent applications are comfortable working in a top-down, "Unionized IT," cross-functional design environment. Like top-down designers, independent designers always believe they developed their applications for all the right reasons.
Oftentimes independent applications provide operations personnel with unneeded features and information. These extra features and information are born from a "since I can, I will provide it, then I will" philosophy. Often designers empower themselves to provide nonrequired features that they believe will help operations personnel. Many believe that extra features and information will make operations personnel become more aware of unrelated processes. Manufacturers must recognize that unneeded features and the information they provide can induce confusion when they cause someone to act on the wrong "why is it there" information.
Only a few system designers understand and value independent applications, whereas experienced control experts reject them. Those who reject them have not taken the necessary time to understand them. Those who understand them feel the applications are "elegant," whereas those who do not, refer to them as "fancy!"
It is always difficult for designers to port independent applications to other machine controller types. The difficulty stems from applications using complicated programming practices that are unique to one controller and therefore not adoptable by others. For example, this happens when designers tightly integrate controller applications with features that are unique to a particular controller’s human-interface device. It is not hard to understand that the opportunity to port a controller application decreases when a design distributes part of an application to a specific controller’s interface devices.
Designers develop interdependent applications using approved, conventional, and simple to understand programming techniques. Designers of control applications use these techniques because they prevent them from over complicating applications while improving their readability and supportability. The use of advanced instructions is acceptable only when they improve the ability of others to understand a finished application. Regardless, simple programming techniques usually involve designers creating logic that is easily recognized, understood, and supported by control system personnel. Most proponents of interdependent applications are comfortable working in a bottom-up, leader-guided, cross-functional design environment.
Control application specifications encourage the use of simple programming techniques without explaining why. Most specifications describe what ordinary logic circuits must look like. Design specifications also describe various control circuits and the operating modes they must include. Interdependent system applications that react to events before enabling an event do not behave like control applications that enable discrete devices. Nevertheless, designers always structure their logic to mimic specified examples. This means they categorize logic into state or event-based code.
State-based code must execute constantly to eventually trigger event-based code. A state-based control application enables a discrete signal that in turn energizes an output device. A state-based system application activates a discrete signal to enable a jump to a subroutine. The subroutine is analogous to the external electrical circuit used to energize a discrete device. Instead of energizing a device, the subroutine initiates the event. Other than event-based code residing in subroutines, mimicked state-based control applications make interdependent applications understandable to many control system personnel. This basic understanding makes them confident in their ability to successfully interact, change, and support system applications.
Designers who develop interdependent applications always seem to be at odds with those who do not. Most designers come right out and describe how simple, straightforward designs make it easy for support personnel to understand how an application works. They state their applications are like black boxes. However, unlike independent applications, they assume most technicians and engineers will understand how the code in each black box works and how to change it. They never fool themselves or trick others into believing they are developing something strategic. Proponents point to: 1) simple to understand, 2) efficient execution, 3) easy to deploy, and 4) modular replication, as key reasons for developing interdependent applications. In reality, the claim that their applications are easy to understand is the only one that has merit over those applications developed using the independent programming strategy.
Interdependent applications never provide operations personnel with unneeded features or information. Designers omit these features because they have a sense that "If you don’t need it, I should not provide it" design philosophy. Designers claim unneeded features and information will only act to confuse operations personnel. Many definitively state that extra information will not enhance local processes. Manufacturers must recognize that not providing unnecessary features and information minimizes confusion that would otherwise cause someone to act on the wrong feature information.
Many control system designers are comfortable with interdependent applications, whereas many controller experts them. Those who reject them have not taken the time to recognize why they are accepted. Those who understand them feel the applications are "supportable," whereas those who do not, describe them as cumbersome and hard to replicate.
Daniel B. Cardinal works as an engineering consultant for Insyte Inc., implementing integrated scheduling and part identification applications in the automotive industry. Edited by Chris Vavra, production editor, Control Engineering, firstname.lastname@example.org.
Support-focused control systems are designed to produce a programmable logic controller (PLC) program that is easily understood by technicians.
Independent programming focuses on what the programmer considers important characteristics of a finished application.
Interdependent applications emphasize enabling many engineers and trades personnel to understand, accept, and support finished applications.
What principles of support-focused control systems could apply in other fields?