OMAC s Effort to Standardize Packaging Machinery Automation:

Transcription

1 OMAC s Effort to Standardize Packaging Machinery Automation: The role of OPW and PackML in development of Gen3 packaging machinery By: Shelton Wright University of Florida Packaging Science Program March 6, 2005 Faculty Contact: Dr. Bruce Welt University of Florida Coordinator Packaging Science Program 111 Frazier Rogers Hall Gainesville, FL Tel: x bwelt@ufl.edu

2 INTRODUCTION An analysis of consumer behavior reveals that life cycles for packaging dimensions, materials, and designs are continuously decreasing. As a result, producers and end users of packaged goods need packaging machinery and control systems that enable them to react quickly to changing consumer demands. To address this problem, end users are requiring machinery and control suppliers to provide innovative solutions as they strive to maintain competitive advantages for packaged products. This inherent need for flexibility and efficiency is driving technological advances in packaging machinery automation and control systems. In addition to the increased responsiveness and agility needed to accommodate modern packaging, there is an increased push to make these adjustments in a Lean Manufacturing environment. The goal of lean production is to eliminate waste in all areas of production, increase responsiveness, and minimize costs. Ultimately, lean manufacturing demands highest levels of efficiency while achieving highest levels of quality. Successful implementation of lean manufacturing requires efficient integration of packaging machine automation and control systems into enterprise-resource planning (ERP) systems. Lack of standardization, however, limits communications and data transfer between production machinery and the supply chain. Proprietary, vendorspecific solutions may be inhibiting communications and raising interfacing costs. Consequently, new control systems should provide for easy information exchange with information systems for decision making and quality control. End-user requirements can be summarized to three major areas: (1) highly agile and responsive machine architectures, (2) manufacturing systems that provide optimal environments for all aspects of lean production, and (3) vendor-independent, easilyintegrated machine automation and control systems that provide for common connectivity between production machines and other supply chain systems. The Open Modular Architecture Controls (OMAC) Users Group is attempting to provide an appropriate platform for packaging machinery automation standardization. Machinery conforming to these standards is often referred to as third-generation or Gen3 machinery. Gen3 machinery appears to be making rapid inroads against traditional mechanical drive-train packaging machinery. This paper pulls together information about the OMAC organization. Items covered include, OMAC s charters and initiatives, philosophy on standardizing Open Architecture Control (OAC) systems, and the role OMAC is playing to facilitate the transition of the global packaging industry into Gen3 machinery automation and control systems solutions. This document focuses on the particular work of the OMAC Packaging Workgroup or OPW, a distinct working group of OMAC, since its aim is to develop a common approach to developing new packaging machinery that will include more electronic motion controls. In addition, the PackML Team, one of the five subcommittees that make up the OPW, is explored further, since this team is doing 1

3 important work on developing naming conventions and guidelines that will be used for communications between production machinery. OPEN MODULAR ARCHITECTURE CONTROLS USERS GROUP OMAC Users Group History OMAC originated in 1994 when Chrysler, Ford, and General Motors published version 1.1 of "Requirements of Open, Modular Architecture Controllers for Applications in the Automotive Industry." This document addressed manufacturing needs for the automotive industry as it provided guidelines for a common set of Application Program Interfaces (API s) for U.S. industry controllers. Three years later, the OMAC Users group was established (February 14, 1997) when General Motors Powertrain Group (GMPTG) sponsored a meeting for aerospace and automotive industry representatives. The GMPTG invited attendees to become members of OMAC as it sets out to establish a specific set of API's to be used by vendors who sell controller products and services to the aerospace and automotive industries. In 1998, the OMAC Users Group expanded to its current structure, which includes user representatives from automotive, aerospace, chemical, food and consumer products manufacturers. The OMAC Users Group Structure The OMAC Users Group is broken into two structure categories: (1) Management and (2) Working Groups. The OMAC Users Group is managed by an Advisory Board that develops user structure and insures that the path and goals of the initiatives are achieved. On the same level are the ARC Advisory Group, an industry leader in manufacturing, logistics, and supply chain solutions, that facilitates administrative, promotional, scheduling, and coordination needs of user groups, and the Louisiana Center For Manufacturing Sciences (LCMS), which acts as an operational and physical test site for proof-of-concept testing of OMAC developed guidelines. The OMAC Users Group includes three classes of members, including (1) End Users, (2) Technology Providers and Integrators, and (3) Original Equipment Manufacturers (OEM s). Four subgroups make up the working group structure, including (1) Software, (2) Architecture, (3) Packaging, and (4) Machine Tools. This paper focuses on the work of OMAC Packaging Workgroup (OPW). More information on the other Working Groups activities can be found at The Function of the OMAC Users Group OMAC is the North American user association for the promotion of open automation architectures. At OMAC states that: The OMAC Users Group was formed to create an organization through which companies could work together to: Establish a repository of open architecture control requirements and operating experience from users, software developers, hardware builders and OEMs. Facilitate accelerated convergence of industry and government developed APIs (Application Program Interfaces) to one set, satisfying common use requirements. 2

4 Collaborate with European and Japanese user groups in pursuit of a common international API standard. Promote open architecture control development among control builders. Derive common solutions collectively for both technical and non-technical issues in the development, implementation, and commercialization of open architecture control technologies. The purpose of OMAC is operation of Working Groups to establish guidelines for development of future control products. To date, OMAC has released the following guidelines: MS MUG Recommendations For Licensing Posted January 14, 2004 MS MUG Best Practices V1.0 Posted February 7, 2003 OMAC Baseline Architecture V1.0 Posted January 25, 2002 MSMUG Endorses Designed for Windows XP Logo Program for Plant Floor Software Posted October 23, 2001 Business Justification of Open Architecture Control White Paper V1.0 Posted April 8, 1999 THE OMAC PACKAGING WORKGROUP OPW Background The OPW is a working group of OMAC. This working group was established in response to the rapid emergence of motion control and open, modular technology. In the PackLearn Ledger, Volume 1 Issue 1, it states that the goal of OPW is to maintain a sense of sanity to the latest spasm of innovation through the establishment, promotion, and distribution of guidelines for open, modular technology that facilitates the interoperability of packaging machine components. In doing so, OPW is assuring that the motion control s potential productivity is fully realized. OPW is also known as the OMAC Plug and Pack working group. This name is derived from their philosophy to achieve Plug and Play modularity on all open control systems. In order to appreciate efforts of this working group it is first important to understand the concept of Open Modular Architecture Control (OMAC) and what is meant by Plug and Play open control systems. Open Architecture Modular Control Concept ( Plug and Play ) The OMAC concept is a proposed high-level control system architecture design intended for discrete, hybrid, and continuous manufacturing systems. As its name implies, these control systems are both open and modular, but are also scaleable, economical, reliable, and maintainable. Each of these characteristics is essential in the development of future control systems that will meet the requirements of end users who are provoked by the dynamics of consumer demand. OPW defines the characteristics of the OMAC concept in the following way. 3

5 Open allowing the integration of commercial, off-the-shelf (COTS) hardware and software components into a controller infrastructure that supports a de facto standard environment. Modular permitting plug and play of a limited number of components for selected controller functions. Economical achieving low life cycle costs. Reliable and Maintainable - supporting robust plant floor operation (maximum uptime), expeditious repair (minimal downtime), and easy maintenance (extensive support from controller suppliers, small spare part inventory, integrated self-diagnostic and help functions, etc.) Scaleable enabling easy and efficient reconfiguration to meet specific needs of low to high-end applications. These definitions require a fundamental shift in the controls industry today, which is moving from the traditional vendor-specific, proprietary solutions to ones that embody the OMAC concept. The traditional approach makes integration of machines from different manufacturers difficult, or economically unfeasible. Open, modular architectures are based on standardization (see PackML below). This approach fosters development of plug and play of system components without need for significant engineering to re-integrate control systems. Structure of OPW Currently, there are five working committees that make up OPW (1) PackAdvantage, (2) PackConnect, (3) PackLearn, (4) PackSoft, and (5) PackML. These teams are comprised of volunteers representing end users, packaging machine manufacturers, motion control technology providers, systems integrators, educators, trade associations, analysts, and organizations affiliated with these industries. Each team is headed by a Chairman who is responsible for overseeing the team s activities and helps to assure that the collective goals of OPW are being achieved. The name of each team s Chairman and its respective company is listed in Table 1. Table 1. OPW Team Chairmen Team Name Chairman Company PackAdvantage Joe Biondo Bosch-Rexroth PackConnect Rick Van Dyke Proctor & Gamble PackLearn Dr. Kenneth J. Ryan Alexandria Technical College PackSoft Gerd Hoppe Beckhoff GmbH PackML Fred A. Putnum MARKEM Corporation 4

6 OPW Team Functions OPW sub-teams work under the collective mission to enhance the value of open architecture, interoperable packaging machinery by promoting industry standards and issuing guidelines that will result in business and operational benefit to end users, machine manufacturers, and control technology providers. In addition, each sub-team has its own unique charter and function and works independently to achieve initiative goals. Mission statements of each sub-team with exception of PackML (covered later), are reported below. Additional comments are provided to aid understanding of each team s work toward common OPW goals. PackAdvantage Mission Statement Identify and communicate to the packaging industry the benefits/results of using servo motion technology for packaging automation systems. Comments: Servo technology is extensively used in motion control systems where precise control of outputs (such as position, velocity and/or acceleration) is required. The servo mechanism employs an automatic, closed-looped motion control system that relies on feedback to control these desired outputs. Such precision is characteristic to the increasingly flexible, multifunctional Gen3 machines. PackConnect Mission Statement Define the control architecture platforms and connectivity requirements for packaging automation systems. Comments: A high-level control system networking architecture is necessary for fast implementation and upgrade of communication systems that interface with plant information systems. Employing common network connections are essential to enabling and achieving a complete ERP integrated system. PackLearn Mission Statement Define the educational/training needs for the following industry segments: MachineBuilders, User Engineering/Support, and Technology Providers. Comments: This team is commissioned with helping to usher in Gen3 packaging machinery by promoting awareness on the skills needed to build, design, implement, and support, the next generation of digital motion control machinery that internalize OMAC guidelines for open architecture. PackSoft Mission Statement To develop programming language guidelines for packaging machinery that will: ease learning, support transportability of software across control platforms and allow continuing innovation by all parties. Comments: A programming language, in this sense, is the interface that allows control of the motion system according to the demands of the user. In the area of controls technology development, programming languages and environments are highly proprietary in nature. The OMAC philosophy is one towards an object-oriented, automatic programming generation. A Programmable Logic Controller (PLC) is a type of computer that provides hard, real-time control of equipment as a result of their fast repeatable deterministic scan times. The idea is for logic programs to be vendor-independent and must be transportable across different supplier platforms. In the near term, PackSoft supports hardware interoperability and code portability for basic PLCopen motion function blocks for packaging machinery. 5

7 THE PACKML SUBTEAM PackML Background One problem in the packaging industry is that there are no agreed-upon, global specifications or enforced standards. In MARKEM s News and Announcements online article ( Paul Mills (product manager for MARKEM) illustrates the lack of standards, with respect to a packaging machine language, by stating, If a machine state is on, is that the same as running? A machine could be on, but not stopped. We need to speak the same language at the most fundamental level before we can solve industry-wide connectivity issues. The PackML (Packaging Machinery Language) team was formed in February of 2001 to meet this challenge, as its initiative is to respond to increasing needs for a collaborative environment between high-level corporate ERP systems and plant-floor machine-specific software. The goal is to develop naming conventions and guidelines for communications between production equipment and other plant information systems. In the same article, Fred Putnam, a representative from the MARKEM Corporation and the Chairman of Pack ML, states that If packaging machinery could talk, PackML would be their language. Since its inception, PackML has been working to define standard terminology that will function as the foundation for the common language upon which open communications can be achieved. To date, four guidelines for definitions and naming conventions have been released (which can be found on the and websites), including (1) The PackML State Model, (2) The PackML Machine Operating Modes, (3) The PackML Line Type Definitions, and (4) The PackML PackTags. The following explains details of these guidelines. The PackML State Model It is widely understood that state names must first be defined in order to create effective line performance metrics (e.g., machine efficiency). A State (as defined by PackML) completely defines the current condition of a machine. Transitions between States occur: As a result of a Command As a result of a Status change. This is generated by change of state of one or a number of machine conditions, either directly from input/output (I/O) or completion of a logic routine. Automatically after completing a No Command State PackML defines a set of four machine state categories: (1) No Command State, (2) Final State, (3) Transient State, and (4) Quiescent State. The State Model summary is given below and the complete list of States can be found on the OMAC.org website ( PackML s Guidelines for Packaging Machinery Automation,Table 1. Automatic Operations Machine State ). A No Command State is one, which, after completing its own logic, forces an 6

8 automatic transition to a Final State. A Final State represents a safe state (i.e., no moving parts). A Transient State is one that represents some processing activity. It implies the single or repeated execution of processing steps in a logical order, for a finite time or until a specific condition has been reached. A Quiescent State is used to identify that a machine has achieve a defined set of conditions. In such a State the machine is holding or maintaining a status until transition to a Transient State. It should be noted that the above State Model has been proposed for Automatic mode. Other operating modes do exist across the packaging industry such as Semi-Automatic, Manual, Maintenance Index, etc (see The PackML Machine Operating Modes section below). PackML plans to make packaging operations in other modes a subject of future work. The PackML Machine Operating Modes A mode determines how a machine will operate in response to issued commands. PackML released a Machine Modes Definition Document to address the fact that there are no clearly defined operating mode names and functionality within these modes. Those most affected by this lack of standardization, are machine designers, manufacturers, and operators. Different modes need to be defined and specified in order to fulfill the full range of activities necessary for these individuals. The proposal of PackML s mode definitions is shown below. Tables 2 and 3 list elemental modes and respective behaviors. Two Mode Classes: 1. User Selectable consists of two modes within this class that determine how procedural elements or equipment entities respond to commands and how they operate in response to those commands. Procedural in which there are three possible modes of operation (Automatic, Semi-Automatic, and Manual) Table 2. Proposed Modes for Procedural Elements Mode Behavior Command Automatic Transitions within a procedure are carried out without interruption as soon as defined conditions are met. Operators may not force transitions. Semi Automatic Manual Transitions within a procedure are carried out on operator confirmation as soon as defined conditions are met. Elements within a procedure are carried out in the order specified by the operator. Operators may not force transitions. Operators may not force transitions. 7

9 Equipment Entity in which there are two possible modes of operation (Automatic and Manual). Table 3. Proposed Modes for Equipment Entities Mode Behavior Command Equipment entities manipulated by a control Entities cannot be Automatic algorithm. controlled by an operator. Manual Equipment entities not manipulated by a control algorithm. Entities can be controlled by an operator. 2. Machine consists of two modes within this class that provides the control framework in which the User Selectable modes become available for selection. These can be transparent to the operator. Machine Energisation Mode (ESTOP) - This mode is entered either from the operation of the emergency shutdown system or as a result of applying power to the machine. - All emergency circuits and systems are in their fail-safe condition. - The only possible operation in this mode is Machine Reset. Idle Mode - All power is available to all components of the system and the machine is ready for operation. - All hardwired safety systems are energized and the operator is able to select any of the available modes of operation. The PackML Line Type Definitions One major problem arises when manufactures try to integrate different, proprietary, vendor-specific machinery into a single packaging line. This process is often costly and time consuming. An improvement in packaging line integration can be achieved if standards for machine interfaces can be agreed upon. PackML, in its Guidelines for Packaging Machinery Automation, states that it has taken steps towards defining a standard inter-machine interface and to this end four different line types have been proposed. These line types represent the configuration most commonly seen in the packaging field. A summary of each line type is given in Table 4. To facilitate understanding, an illustration of a typical line configuration is shown in Figure 1. Figure 1. Typical Packaging Line Configuration Typical Packaging Line Arrangement Unscramble Unscramble Fill Cap Label Carton Palletise Material Flows 8

10 Table 4. Packaging Line Types Line Type Line Type 1 Line Type 2 Line Type 3 Line Type 4 Line Type Summary Machines are autonomous; They react to plant conditions through their own array of sensors and switches. They do not communicate to the other machines that comprise the line Line Type 2 machines differ from Line Type 1 because they have the ability to communicate with other machines. Two Subtypes have been defined: 2A and 2B. Functionally these are identical, they achieve their functionality through two different methods: Machines within Line Type 2A communicate through digital and analog I/O. Line Type 2B machines communicate across data networks with or without digital and analog I/O. An enhanced version of Line Type 2B. Contains both, or a combination of, Supervisory Control & Data Acquisition (SCADA) server and clients and/or line supervisory controller. The enhanced functionality of this line type provides line performance data, loss analysis, root cause analysis toolkits, maintenance and troubleshooting tools, change parts database, etc. Packing lines are integrated into wider business IT systems via the ERP bus. This provides functionality such as the passing of production orders into the factory and progress against the order to be monitored. It could also allow the automatic reporting of performance, quality, and material usage. 9

11 PackML PackTags In order to communicate, different entities need to have a common vocabulary. In the case of packaging machinery, the current communication environment is one where information exchange is inhibited by the lack consistent meanings for data elements. PackML provides guidelines that define naming conventions to be used for open architecture, interoperable data exchange in packaging machinery. PackML is an industry specific subset of extensible markup language (XML), an increasingly adopted data exchange format. These guidelines include PackTags a formally defined set of fundamental names for data elements (or tags) as well as the data types, values, ranges, and data structures, which are sufficient for computing machine performance metrics. PackTags are useful for several reasons. They are useful for intermachine (machine-tomachine) communications (e.g., communication between a filler and a capper). They are also useful for intramachine (within the same machine) communications (e.g., between motion controllers and PLC s on a single machine. In addition, PackTags will be used to exchange information between machines and higher-level information systems like SCADA systems, plant databases, and enterprise information systems. PackTags are broken out into two types: (1) Control and (2) Information. Control data is defined as data required to interface between machines and line control for coordination. Information data is described as data collected by higher-level systems for machine performance analysis. Each grouping of data should be in a contiguous grouping of registers to optimize communications. The PackML, naming-convention guideline for PackTags is shown below. It should be noted that the complete set of PackTags (along with tag details and definitions) can be found on the OMAC.org website on the link for Guidelines for Packaging Machinery Automation, Version 3.0, AppendixIID PackTags Tag Naming Guidelines v 2.0. PackTag Prefix PackTags will often be used in information systems that have a wealth of other named tags, so each PackTag should be prefixed with an identifying string to distinguish them from other tags that may have the same name. A precedent of using PML_ as the prefix string has already been established. Employing this convention will make it easy for a user who is unfamiliar with PackTags to look up their definitions. PackTag Name Strings Many factory information systems do not allow for spaces in tag names. The guideline uses the common practice of substituting underline characters for spaces between words. The first letter of each word is capitalized for readability. It is recommended that a mixed-case format be adhered to. The total string shall not exceed 20 characters (This 20 character limit includes the prefix PML). Thus, the exact text strings that should be used as tag names should be as follow: PML_Xxxxxx_Yyyyyyyyy For example: PML_Cur_Mode 10

12 CONCLUSION To stay competitive, producers must continually innovate, provide low-cost customization, and ensure better service. The overall effect is increasing complexity in a heterogeneous manufacturing environment that must have the agility and responsiveness to produce innovative products while controlling manufacturing costs. In order to achieve this, next generation packaging machinery (Gen3 machinery) must have easilyintegrated machine automation and control systems that will yield a common connectivity between production assets and other systems in a manufacturer s supply chain. The OMAC philosophy is recognized among industry leaders as a solution that will meet end user requirements and help to ensure that current and future automation technology produces improved business performance. The OMAC Users Group is a North American user association in which companies could work together to promote open automation architectures. The purpose of OMAC is operation of Working Groups to establish guidelines for development of future control products. OPW is one of four OMAC working groups whose mission is to establish, promote, and distribute guidelines for open, modular technology that facilitates interoperability of packaging machine components. OPW s ultimate goal is to achieve Plug and Play modularity on all open control systems. The OMAC concept is a proposed high-level control system architecture design intended for discrete, hybrid, and continuous manufacturing systems. The five essential characteristics necessary for the development of future control systems that will meet the requirements of end users are: (1) Open allowing the integration of commercial, offthe-shelf (COTS) hardware and software components into a controller infrastructure that supports a de facto standard environment, (2) Modular permitting plug and play of a limited number of components for selected controller functions, (3) Economical achieving low life cycle costs, (4) Reliable and Maintainable - supporting robust plant floor operation (maximum uptime), expeditious repair (minimal downtime), and easy maintenance (extensive support from controller suppliers, small spare part inventory, integrated self-diagnostic and help functions, etc.), and (5) Scaleable enabling easy and efficient reconfiguration to meet specific needs of low to high-end applications. These definitions stipulate that there is fundamental shift in the controls industry today, which is moving from the traditional vendor-specific, proprietary solutions to ones that embody the OMAC concept. The subcommittees of OPW are all working to establish industry standards and to promote open automation architectures. The OPW sub-teams work under the collective mission to enhance the value of open architecture, interoperable packaging machinery by promoting industry standards and issuing guidelines that will result in business and operational benefit to end users, machine manufacturers, and control technology providers. Since its inception, PackML has been working to define standard terminology that will function as the foundation for the common language upon which open communications can be achieved. 11

13 The OMAC Users Group consists of three classes of members: End Users, Technology Providers and Integrators, and OEMs. Members from end user manufacturing companies will have voting power to resolve technical issues in the OMAC Users Group. All members will be expected to play an active role in meetings, technical development support and possible testing of developments at their respective companies. Companies interested in joining OMAC should complete the membership application form located at In addition, a company or organization will be admitted as a member of the OMAC Users Group if it fits the definition of one of the member classes and is committed to carrying out the roles and responsibilities of its member class. Submission of the above form endorses the OMAC Users Group in principle and warrants my company s participation under its designated member class. 12

14 References 1. Triangle Takes Cartoner to A New Platform. < Sercos N.A. (accessed) 3/2/ Standards for Packaging Machines The latest trends in packaging machine automation < European Food and Drink Review, Issue (Accessed) 3/3/ Packaging Machinery Automation Strategies. < ARC Advisory Group. (Accessed) 3/3/ Software advances lead packaging automation trends - Business news: business trends people - software for food packaging machinery < Food and Drug Packaging, April (Accessed) 3/3/ GE Fanuc Introduces New Automation Solutions For Packaging Machinery Manufacturers < jobwerx manufacturing network. (accessed) 3/3/ PackLearn Ledger, Volume 1 Issue 1. (accessed) 3/3/ MARKEM Corporation. News and Announcements- New Initiative Underway To Develop Communications Guidelines For Packaging Machinery. < (accessed) 3/3/ OMAC Users Group website. Guidelines for Packaging Machinery Automation V3.0, < (Accessed) 3/1/ PackML website. Guidelines for Packaging Machinery Automation v. 3.0, PackTags final version, Machine Modes Definition Document, Line Types Document, Version 1.2, PackML Machine State Model Guidelines V2.2. < (Accessed) 2/1/