Support-focused enterprise controls: template design strategies
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 whether they’re independent or interdependent programming 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.