by Robert Trask, P.E
As U.S. manufacturing and production moves toward what is generally considered the fourth Industrial Revolution, popularized as “Industry 4.0,” many of the necessary technological components are already in place. However, there is some additional ground that must be covered.
A consensus is forming around the notion that the primary component preventing the revolution from reaching full speed is wider acceptance of communication standards. So how can we consistently, and with less effort, exchange data between the various components of a highly connected industrial machine or process?
Many automation professionals have grown too used to the idea that communicating between devices and vendors is difficult, due to deliberately built-in roadblocks. Unfortunately, some have just accepted that each installation requires a significant integration effort to establish communication within the system and with external networks and databases.
Too often, establishing the levels of connectivity expected by today’s global enterprises requires great amounts of talent, time, and expense. Without better adherence to standards, system integration for highly connected solutions will continue to be a complex challenge.
As a colleague of mine put it recently, we are dealing with “thousands of one-man bands.” As such, standards are necessary to accomplish two things:
- A common look and feel
- A consistent communications interface
There is light at the end of the tunnel, however—industrial control systems are quickly leaving their history of isolation and segmentation with regard to information and control. Increases in connectedness are becoming a requisite, rather than a luxury, and this connectedness is more fluid, offering faster, simpler implementation. The industry could use more of a Steve Jobs-ian, “it just works” mentality (Steve Jobs famously quipped, “it just works” during several iPhone launches).
For the U.S. manufacturing industry to prosper in the future, we must create systems that can adapt quickly and easily. It has to “just work.” This will raise efficiency, reduce time to market, and be more flexible for vendors and end users. True progress must improve the competitive outlook of the machine user, as well as the machine builder. Open communication standards, not a vendor-specific protocol or method, can make this progress happen for all parties, with the added benefit of simplifying system designs.
Standards accepted
The good news is that many of the required standards already exist and have existed for some time. When fully embraced, these can be of great benefit to the automation community. Specifically, we can look at the packaging industry, a well-known hotbed of technological innovation.
Packaging equipment must deal with high speeds, multi-axis motion control, advanced vision systems, and the frequent involvement of several different vendors in one installation. Too often, there is little communication between the machine modules, as manufacturers tend to treat each segment individually. The unique aspects of each piece must be kept in mind, often requiring specialists.
With PackML and OPC UA, reinvention not required
What if we agreed on mechanisms to share information, with names that are both useful and consistent? What if we agreed on a standard way of handling individual machine states? The answer to these questions is a standard that has been available and implemented by leading companies for years.
This technology, Packaging Machine Language (PackML), is a powerful communications language developed over the past 15 years, primarily through the efforts of the ISA88 committee and the Organization for Machine Automation and Control. Recently, Packaging Machinery Manufacturers Institute has taken over the development and maintenance of the language.
PackML is known officially as ISA-TR88.00.02-2008 (v3.0 released in 2008); an updated 2014 version of the technical report is currently being voted upon by the ISA88 committee. Combined with the ISA-88 Part 5 standard currently in development by ISA88, PackML provides a consistent architecture and approach to machine programming geared toward, but not limited to, the packaging industry.
PackML is growing in prominence within the packaging industry. The third revision has found wide use; Proctor & Gamble is a high-profile example. Proctor & Gamble went so far as to publish and promote a PackML implementation guide in 2009.
PackML provides two key components for our use: a state machine and a set of tags called PackTags, used as a communications interface. A well-planned communications interface is important for feature-filled, multitasking devices, such as the one in smartphones. The information exchange between the GPS unit, the dialer, the Wi-Fi connection, and the various sensors on the phone is channeled through a set of interfaces that are well designed, well named, and easy to implement and use.
The success and pervasiveness of modern smartphone technology cannot be denied, providing ample evidence that a similar communications interface for industrial machinery should be seriously considered.
So how does a PackML state machine relate to this, and how can it be of use to the manufacturers and users of packaging machinery? The primary use of a state machine is not so much for normal operation; it is a powerful mechanism for production problems and dealing with exceptions.
In addition, a state machine with a common look and feel benefits both the developer and the end user. An operator can look at any part of the machine and have an instantly familiar human-machine interface screen that displays relevant information in a simple, universally accepted format. The machine builder benefits, because the structure does not have to be designed from scratch.
With the right technical specifications and with manufacturer support, PackML is the leading candidate for a standard to interface packaging systems, with the hope of getting packaging machines to that smartphone level of user friendliness. Today’s PackML users already have a common look and feel, as well as agreed upon methods to exchange data in the control system that are vendor-agnostic.
Like the initiatives of PLCopen, the forces behind PackML seek a commonality in appearance and in functionality between different vendors. This way, the operator can walk up to any machine, look at the display screen, and see a familiar interface. This helps the operator avoid the learning curve associated with new machinery.
Why PackML?
PackML also answers other business requirements:
- Provides a consistent look and feel to operators and technicians
- Establishes a foundation for vertical and horizontal integration
- Standard information in and out of a machine
- Plug-and-play functionality
- Drives consistent end-user specifications
- Hardware independence (function-based)
- Ability to integrate equipment from different vendors
- More robust software, less downtime and faster debugging
- Lower total cost of ownership
- It just works
The PackML Control Architecture Specification has additional hooks for:
- Overall equipment effectiveness (OEE) data, in which end users are increasingly interested. Typical OEE metrics include availability, performance, and quality.
- Event handling for root cause analysis (“first out fault”)
- Flexible recipe schemes
- Manufacturing execution system inputs
Key considerations when implementing PackML
Figure 1. The PackML State Diagram can be used for any machine or process (packaging application pictured).
Users can transition to the “stopping” and “aborting” states from anywhere else in the PackML State Diagram (figure 1). For “suspending” and “holding,” there are subtle differences. Suspending is for states that can happen during automatic operation, such as being “blocked” by an outgoing process downstream or “starved” for raw materials. Time suspended is an excellent metric to be aware of for OEE, as the time a process is spent as “blocked” or “starved” will have a dramatic effect on production throughput and profitability. Holding is operator-induced by hitting “pause.” Technically the machine is ready, but the operator is preventing production from commencing.
PackML is a programming methodology (not a language as commonly thought). As discussed previously, the PackML model, the PackTag interface and the associated state machine are suited to any industrial process or machine. PackTags, as a standard definition of what a “tag” (a variable) should look like, help with reprogramming, adding functionality, and most importantly, resolving technical challenges when the original machine programmer has moved on to other projects. PackML users do not have to learn an entire system from scratch, and they understand what they are looking at much faster. The commonality in programming is a serious advantage of PackML.
To design a successful PackML implementation, there are three key steps to consider:
- Choosing the PackML modes
- Assigning functionality to PackML modes and states
- Modularizing machine code to match the physical and functional configuration
Step 1: Choose the PackML modes
PackML v3.0 allows an unlimited number of modes. Common mode names include:
- Automatic
- Manual
- Dry run
- Setup
- Maintenance
- Calibration
Step 2: Assign functionality to PackML modes and states
You can think of modes as floors in a building, or as layers where certain states are allowed or not allowed. To go from one mode or level to another, you need a “stairwell” or path to make the transition. PackML v3.0, for example, has 17 transition states.
Common mode transition states are “wait” states, where the machine is in a neutral state. These could include idle, stopped, or aborted. So what happens in each of these transition states? Here are some important questions to consider:
- Where are servo axes enabled?
- Where are they disabled?
- Where is homing performed?
- Where should CycleStop go?
- Recipe updates?
This exercise enables a company to establish its own functional conventions and create a PackML programming foundation for all machines.
Step 3: Modularize machine code to match the physical and functional configuration
PackML fits into the overall ISA-88 physical hierarchy.
PackML is mostly concerned with the bottom three layers of the ISA-88 hierarchy:
- Machine (unit or UN): a collection of related modules (mechanical and electrical assemblies) that carry out one or more processing activity.
- Equipment module (EM): a functional group of modules that carry out a finite number of activities.
- Control module (CM): the lowest level of control where a single function is executed.
Figure 2. ISA-88 Hierarchy
Effect from OPC UA
In the quest to standardize communication technologies for U.S. manufacturing, the Internet of Things (IoT) and Industry 4.0 are viable options that could be pieces to complete the overall puzzle. As discussed, PackML is a leading standard for modeling a control system and exchanging data between industrial components.
However, PackML does not address the actual transport mechanism, or how the data is actually transferred and managed throughout a network. This is the domain of another standard, OPC UA, which is quickly becoming a globally recognized, standard transport mechanism for data in control systems. OPC UA provides a secure, robust, reliable transport method and has the blessing of many influential figures in industry, academia, standards committees, and more importantly, controls vendors.
Interestingly, both PackML and OPC UA are suitable for both traditional programmable logic controllers (PLCs), as well as the more open and ever more powerful PC-based control. The PackML and OPC UA standards are well thought-out, well organized and have low computing needs. Both standards can be implemented with low investments, and the entire model does not have to be used, enabling deployment on very small, low-cost devices.
With respect to IoT and Industry 4.0, the nod must go to PC-based control as the preferred hardware platform. The best way to continue improving and integrating new technologies is through open solutions. Proprietary hardware and closed software systems are unable to keep up with the increasing rate of change, owing much of their inflexibility to vendor dependence.
Considering that future systems will be even more highly connected, we must be able to communicate efficiently and have the ability to set up communications processes quickly and easily. Industry 4.0 will require flexibility and independence from any particular vendor. There is simply no other way for it to work.
Standards improve industry
Perhaps the primary mission of the Industry 4.0 movement is to bring manufacturing back home to highly industrialized, high-wage nations. This means designing flexible systems that can be quickly adapted to change. It could be argued that U.S. manufacturing has an obligation to work this out for the good of industry, and even the good of the nation.
Looking to current events in Europe, the German government and German manufacturers have been actively promoting Industry 4.0 for years. Industry 4.0 is part of an ambitious strategy to advance the “computerization of manufacturing.”
Whether in Germany or the U.S., PackML and OPC UA can both be part of this macro-level computerization strategy. PackML provides that common look and feel for machine functionality, and OPC UA provides the secure, acknowledged communications channel between the different parts of a system.
For manufacturing in the U.S., we must carefully proceed, as implementing future-forward ideas, such as IoT and Industry 4.0, could be delayed by disagreement on the “standards.”
PackML and OPC UA together are a powerful means to standardize the communication of the packaging industry, and of the U.S. manufacturing industry as a whole. These standard technologies can help us reach the next level (Industry 4.0), while growing the domestic manufacturing base. This is the level where we find hyper-connected systems and simple system integration, where we can finally say that “it just works.”
See more at: https://www.isa.org/intech/20141003/#sthash.abxqthPZ.dpuf
About the Author
Robert Trask, P.E., (R.Trask@beckhoff.com) is a senior systems architect with Beckhoff Automation. Trask has worked at Beckhoff since 2003 and facilitates high-level automation systems planning for leading machine builders and manufacturers. He also manages a Beckhoff training and engineering facility in San Diego. Trask holds a B.S. in electrical engineering from North Carolina State University and has nearly 30 years of experience with automation, industrial controls, and systems planning.
Source: InTech magazine, Sept/Oct 2014 issue