This guest column was contributed by Bob Trask, senior systems architect at an OMAC member company.
When programming a packaging machine, filling line, or other production process, there is much debate over how to define the production goals, and how to build the best system architecture to achieve them. Often, the focus is solely on the main functionality of the machine or process, or the execute state (depicted as a blue box in many machine interfaces). It’s easy to see why this is the place most engineers start, since the ultimate (and most basic) goal is to send as much product out the door as possible.
Issues arise when you begin to flesh out your plan to deal with errors or other exceptions in the process. How do you handle the tasks associated with bringing production back online after an e-stop activation, a product collision, or an interruption in the raw material supply? More often than not, the fixes for these kinds of afterthought problems are carried out directly in the code, creating a convoluted mess that makes production management and maintenance a nightmare.
Compounding the challenge is the fact that more and more demands are being placed on machine control software. This is a trend we have experienced since the beginning of the PLC era. With the introduction of Industry 4.0 and IoT concepts, OEE requirements, and the increased use of Industrial PCs as control devices, the importance of software will only rise and even accelerate as machine end-user demands grow.
The good news is that there is a proven mechanism available to make these processes much simpler. This is a machine operating standard that has been in development for decades which many successful machine builders and end users are already using to their advantage—the PackML State Model, otherwise known as the ANSI/ISA TR88.00.02 standard.
Historic protocol sees resurgence as application complexity grows
PackML, which stands for packaging machine language, is not, in fact, a language, but rather a universally applied method to handle states and information. It is language and vendor agnostic, developed over two decades by many dedicated corporations and individuals. The standard promotes streamlined machine-control behavior on the plant floor, while enabling interoperability between different machines from different vendors. PackML also supports efforts at the supervisory level by providing basic OEE metrics.
The state machine gives programmers a consistent path when dealing with exceptions. This process cannot deviate from the appointed path and makes it easier to diagnose problems. As the name “state model” implies, PackML reads the current state of the system during each portion of the production process and provides updates about the individual sections. This helps the user understand exactly what is going on where, and quickly determine the overall health of production processes.
Moving beyond the Execute State (that ‘blue box’)
As mentioned above, the Execute State—the lines of which are colored blue in PackML diagrams—is actually just a small part of the larger PackML State Model. Many ‘boxes’ or states are predefined—the programmer is given a place to write code and need not worry about how the program got to that point or where it should go next. This immediately makes work more efficient for programmers, as they do not have to program the machine states or decide how to resolve them. Instead, they are abstracted from many of the details and can focus on how to make the machine operate at peak performance overall.
The state model also provides benefits at the plant level, directly on the shop floor. Imagine you are an operator in a plant with an unfamiliar machine and need to diagnose an error. In most cases, an operator will look at the machine HMI and see something new and foreign. Even without an error, the unfamiliar HMI increases the time and costs required to properly train plant personnel how to handle the equipment. However, by using a standard interface designed using the PackML State Model, there is immediate familiarity. Operators can more easily determine the state of the machine and have a general idea of what happened. Within seconds, the operator is in a much better position to effectively remedy a problem in production. Imagine, then, if all process components used the same state model. It becomes quickly apparent how this could benefit factors such as increasing interoperability, while decreasing the learning curve for new operators and maintenance operations so they can better determine whether the line is running optimally or if it’s down because of an error.
Controls providers provide this standard state model as a corresponding library in our automation programming environment. Some also often provide a template at no cost to start projects because it helps everyone—the vendor, the machine builder and the end user—when development of controls programming goes smoothly. OEMs benefit from a standard state model and machine behavior that is already defined. Rather than creating a state model from scratch, which is a surprisingly complicated endeavor, it is already done for you. The end user benefits from a basic interface that looks familiar to the operator, no matter which controls vendor is used.
Production on a need-to-know basis
Abstraction, or taking care of process details without requiring any programmer or user intervention, is an important part of a PackML template. This is not an attempt to keep anything hidden from the end user; rather, this functions much like the relationship between a car and its driver. Most people drive their cars without intimate knowledge of the inner workings. Most drivers think in terms of steering wheels, pedals and buttons, not in terms of how the car’s transmission, engine and drivetrain all interact with each other to move the car along. As long as drivers get scheduled maintenance and respond to indicator lights for problems, they really only care if it works, not so much how it works.
The same goes for a production process—the operator really only needs to see that the system is working correctly and be notified if normal operation has been interrupted so that action can be taken. There is never a reason for plant floor personnel to “have a look at the PLC.” This enables operators with less sophisticated skill sets to handle the system. It also removes the need for 24/7 on-site engineering staff because potential issues are easier to identify and remedy, so machines can be brought back online much faster. It doesn’t take much analysis to understand that this boosts basic downtime, uptime, and throughput metrics.
PackML facilitates this higher level, abstracted view of the process with its series of clearly-recognizable states and actions; these “boxes of many colors” make it much easier to precisely determine exactly what the machines on the line are doing at all times. Therefore, the machine thinks outside the box for you. Operators don’t need an engineering degree to see that “aborted” indicates the process was stopped outside of normal operating conditions because of an unusual event or anomaly, most often associated with an e-stop button press. In addition, the states are color-coded for easy identification of the ‘mode’ each state is currently in. These modes also stress simplicity—green states are “active,” meaning something is going on, and yellow states are “wait” states that need a command to continue, whether automatically from the system or manually from an operator. Anyone who understands how a traffic light works will feel right at home with this methodology.
Support from leading communication protocol working groups
Alignment with some of the world’s leading communication protocol working groups, namely OPC-UA and PLCopen, have helped to bring a sharper focus and widespread adoption of the state machine in industry. The end goals of this partnership are ultimately to streamline packaging machine integration processes and improve automation guidelines and standards at the same time. This cooperation with next-generation protocols leads right into partnerships with leading automation suppliers who support greater adoption of open, widely-accepted protocols such as OPC-UA. With this mutually beneficial environment, these vendors, OEMs, and end users all have the means to simplify packaging operations, helping gain competitive advantages by optimizing their operations and strengthening business partnerships throughout.
