1. Make2Pack – An Overview DAu Seminar Nov. 9. 2010

2. NNE Pharmaplan at a glance
Over 80 years of experience in the pharma and biotech industries
Spanned over 3 continents across Europe, North America and Asia
We employ over 1,600 people at more than
25 locations in 12 countries around the world.
Turnover 2009: DKK 1.488M, EUR 200M, USD 261M
Automation & IT Knowledge & Experience
Independent Consultant & Implementation Partner
+300 employees many with 10+ years of experience
Deep cross disciplinary knowledge (API, Finished Goods, Devices, Laboratories)
Comprehensive business & regulatory understanding
Knowledge about how to use technology to provide business advantages
Setting the international standards & guidelines
Stay on site until the task is solved, even if others has given up

3. Agenda Make2Pack – relations to OMAC, ISA, WBF OMAC – Pack Standards
ISA 88 – Technical Report
ISA 88 Standards, Part 1,2,3,4
ISA 88 Standard, Part 5
Advantages by standardisation
Conclusions and recommendations

4. Relations – Who is OMAC?
OMAC - Organization for Machine Automation and Control
Founded in 1994 as The Open Modular Architecture Controls User's Group
The global organization for automation and manufacturing professionals that is dedicated to supporting the machine automation and operational needs of manufacturing.
OMAC has about 500 members from end-user companies, OEM's, and technology providers and integrator companies.
Since 2005 a part of ISA but in 2010 OMAC separates from ISA.
History
Collectively derive common solutions for both technical and non-technical issues in the development, implementation, and commercialization of open, modular architecture control technologies
Promote open, modular architecture control development among control technology providers and adoption among end users, OEMs, and system integrators
Act as a repository for open, modular architecture control requirements and operating experience from users, software developers, hardware builders and OEMs in manufacturing applications
Facilitate the accelerated development and convergence of industry- and government-developed technology guidelines to one set that satisfies common use requirements
Collaborate with users groups around the world in pursuit of common international technology guidelines.
OMAC changes its name to the Organization for Machine Automation and Control to better reflect the broader mission and scope of its on-going activities.
OMAC separates its operations from ISA and transitions to a new management team, under direction of Executive Director Paul B. Goodson, P.E., CAE. 
Machine Tool:
The Machine Tool Working Group is charged with maximizing the business value of discrete part machinery by providing automation guidelines, developing best practices, and assisting in international standards development. Our primary objective is to create an environment that maximizes the machine automation choices of end-users and OEMs, and increases their flexibility through greater openness and interoperability. To ensure that this goal becomes a “win-win” situation, we work with CNC controller vendors, CAD/CAM suppliers, and CNC OEMs to encourage their support of OMAC-endorsed open-architecture specifications and other best practices through their products and practices. There are two sub-groups under this working group:
STEP-NC – working to understand and assess ISO in the context of OMAC
HMI-API - defining a common HMI API for all CNC devices
Workgroup Status Report Presentations - ISA EXPO 2005

5. Relations – Who is ISA? ISA - International Society of Automation
Founded in 1945, now with over 30,000 worldwide members
ISA is a leading, global, non-profit organization that is setting the standard for automation by helping members and other professionals solve difficult technical problems.
ISA develops standards and publishes books and technical articles
Provides education and training
Certifies industry professionals
Hosts conferences and exhibitions for automation professionals
Mission
Become the standard for automation globally by certifying industry professionals; providing education and training; publishing books and technical articles; hosting conferences and exhibitions for automation professionals; and developing standards for industry.
Vision
To work in partnership with members, customers, and subject-matter experts to disseminate the highest quality, unbiased automation information worldwide.
ISA is a leading, global, nonprofit organization that is setting the standard for automation by helping and other professionals solve difficult technical problems, while enhancing their leadership and personal career capabilities. Based in Research Triangle Park, North Carolina, ISA develops standards; certifies industry professionals; provides education and training; publishes books and technical articles; and hosts conferences and exhibitions for automation professionals. ISA is the founding sponsor of the Automation Federation (

6. Relations – Who is WBF?
WBF - The Organization for Production Technology
WBF was founded in 1994, by people who were engaged in writing a new standard (SP88) about automation of procedural control in manufacturing in a batch processing environment, thus the name of the organization: “World Batch Forum”.
Topics WBF addresses include:
Production Management Techniques
Information Integration
Automated Equipment Design
Control of Batch Process Operations
Process & Production Automation
Recipe Content, Format & Structure
Safety & Environmental Concerns
Compliance with FDA, EPA, OSHA
Application of Industry Standards
Evolving Technologies of Interest
WBF - The Organization for Production Technology, is dedicated to supporting the process automation and operations needs of the technical and management professions in process manufacturing. WBF facilitates the interchange and development of information and knowledge in order to help its members succeed and to exert a positive influence on industry.
Automation processing is a common manufacturing method in the chemical, pharmaceutical, pulp and paper, and food and beverage industries. WBF membership is intended for manufacturers and suppliers associated with these and other similar industries. Activities or items of a commercial nature are limited to assure that WBF services and events retain an educational perspective.
The first WBF conference in 1994 was organized and underwritten by Michael Saucier and his company. Immediately following that conference, WBF was incorporated as a non-profit, non commercial end user oriented professional organization dedicated to promotion of the exchange of information related to the management, operation and automation of batch process manufacturing. Its mission over the succeeding years has grown to encompass a broad range of production technologies for most manufacturing and processing industries.
WBF - The Organization for Production Technology, is an association of end-users, vendors, consultants and academics with a strict, non-commercial agenda. In addition to hosting an annual conference with formal presentation and technical papers, WBF provides organization, management and structure to facilitate networking, and knowledge sharing among its members. WBF supplements the functions of ISA, AIChE, ISPE, CMA, and other related professional organizations by integrating a variety of management and technical disciplines needed to advance batch processing knowledge and technology.
Topics WBF addresses include:
Production Management Techniques
Information Integration
Automated Equipment Design
Control of Batch Process Operations
Process & Production Automation
Recipe Content, Format & Structure
Safety & Environmental Concerns
Compliance with FDA, EPA, OSHA
Application of Industry Standards
Evolving Technologies of Interest
Why World Batch Forum Became WBF, The Organization for Production Technology
WBF was founded in 1994, largely by the people who were engaged in writing a new standard (SP88) about automation of procedural control in manufacturing.  The new organization was initially focused on promoting and explaining the use of the standard in a batch processing environment, thus the name of the new organization: “World Batch Forum”.  The first conference was sponsored and organized by Michael Saucier and his company.  After the first conference World Batch Forum was incorporated as a volunteer user-driven nonprofit organization dedicated to providing a forum for the sharing of experiences and information regarding the new standard and related technologies. 
WBF was founded in 1994, largely by the people who were engaged in writing a new standard (SP88) about automation of procedural control in manufacturing.  The new organization was initially focused on promoting and explaining the use of the standard in a batch processing environment, thus the name of the new organization: “World Batch Forum”.  The first conference was sponsored and organized by Michael Saucier and his company.  After the first conference World Batch Forum was incorporated as a volunteer user-driven nonprofit organization dedicated to providing a forum for the sharing of experiences and information regarding the new standard and related technologies.  It quickly became obvious that the principles and technologies of interest were not restricted to batch and could significantly benefit all types of production.  Over its first few years, World Batch Forum gradually expanded its focus as the basic technologies the organization supported were applied more and more frequently in discrete, continuous and other types of production.  A growing interest also evolved in the integration of production operations with production management and enterprise systems. The broadening of focus mandated a new name for the organization.  At that point World Batch Forum became WBF - still of interest to batch, but addressing all types of production and all facets of production related to automation and operations.

7. Make2Pack – how did it start?
In May 2004 the WBF’s SP88 committee and OMAC held a meeting and decided to establish Make2Pack as an umbrella for collaboration between the two groups.
The Make2Pack Working Group provides a forum for the harmonization of models and concepts between OMAC PackML work and current work being done by the ISA's SP88 committee generally called Recipe-Equipment interface.
This work will result in direct input to the SP88 committee and the possible inclusion of packaging requirements as part of an SP88 Batch Control.

8. Guidelines for Packaging Machinery Automation
OMAC Work Groups
OMAC has two working groups:
Machine Tool Working Group
Machine Tool Working Group works with CNC controller vendors, CAD/CAM suppliers, and CNC OEMs to encourage support of OMAC-endorsed open-architecture specifications and other best practices through products and practices. STEP-NC and HMI-API are two subgroups.
Packaging Work Group
Packaging Working Group (PWG) seeks to maximize end-user and original equipment manufacturer (OEM) machine automation choices, increase flexibility, facilitate a smaller-footprint machine, achieve faster throughput, and reduce costs through greater industry openness and interoperability. Doing so will allow end users to “connect-and-pack” different technologies to meet business needs.
PWG has issued,
Guidelines for Packaging Machinery Automation v. 3.1
PWG has five subgroups.
Guidelines for Packaging Machinery Automation
V 3.1
Packaging Work Group
The objective of the Packaging Workgroup (OPW) is to maximize the business value of packaging machinery by improving automation guidelines and standards. This will lead to improved flexibility, improved capability, and reduced system integration costs.
To attain this goal, we work with automation suppliers, OEMs, and trade groups worldwide to encourage their support of the "Connect-and-Pack" standards throughout their products and practices, creating a mutually beneficial environment for the guidelines.
Connect-and-Pack guidelines and standards make packaging operations more effective by simplifying customization and integration, which enables world class packaging operations. When implemented, packaging companies and their partners gain a competitive advantage as they leverage an integrated supply chain to optimize operations.
PackML/PackTags Technical Report Approved The ISA88 Committee has approved a new ISA88 Technical Report on Machine and Unit States. This technical report incorporates the OMAC Packaging Workgroup’s PackML and PackTags documents with the industry standard ISA88 terminology.
ISA88 Technical Report on Machine and Unit States: An Implementation Example of ISA88
PackML V3.0 Demo in Excel
PACK EXPO 2009
The Packaging Workgroup will be showcasing how "Packaging Standards Deliver More Cost Effective Solutions" when leveraging the ISA88 Connect-and-Pack standards through an in-booth demonstration at PACK EXPO 2009.
Connect-and-Pack TM Seminars
The Packaging Workgroup has scheduled a number of tutorial seminars where anyone interested can learn more about Connect-and-Pack standards and their benefits. Learn More!
Packaging Automation Survey
2009
Survey Results
Presentation on 2009 packaging automation survey (Coming Soon!)
2008
Packaging Automation Forum Survey Results Presentation
Machine Tool:
The Machine Tool Working Group is charged with maximizing the business value of discrete part machinery by providing automation guidelines, developing best practices, and assisting in international standards development. Our primary objective is to create an environment that maximizes the machine automation choices of end-users and OEMs, and increases their flexibility through greater openness and interoperability. To ensure that this goal becomes a “win-win” situation, we work with CNC controller vendors, CAD/CAM suppliers, and CNC OEMs to encourage their support of OMAC-endorsed open-architecture specifications and other best practices through their products and practices. There are two sub-groups under this working group:
STEP-NC – working to understand and assess ISO in the context of OMAC
HMI-API - defining a common HMI API for all CNC devices
Workgroup Status Report Presentations - ISA EXPO 2005
Early AP-238 Implementation at Boeing - David Odendahl & Sid Venkatesh
Case Study in the Challenges of Integrating CNC Production and Enterprise Systems - John Michaloski

9. OMAC Packaging Work Groups
Packaging Work Group’s five sub-groups:
PackAdvantage - Identifies and communicates to the packaging industry the benefits/Results of using "connect & pack" guidelines for packaging automation systems
PackConnect - defines the control architecture platforms and connectivity requirements for packaging automation systems
PackLearn - promotes awareness of Group initiatives by defining and developing programs to meet the educational and training needs of the industry
PackSoft - develops guidelines for machinery programming languages to ease learning, support transportability of software across platforms, and allow continuing innovation
PackML – develops naming convention guidelines for communications between production machinery within the packaging industry.

10. OMAC Pack Documents
The PackML sub-group has developed the following documents:
Packaging Machine Language Mode & States Definition Document, V3.0
June 2006
(PackML)
Tag Naming Guidelines, V3.0
July 2006
(PackTags)
The PackSoft sub-group has developed the following document:
Packaging Application Function Library March 2006, V1.0
March 2006
PackAL
PackML
V 3.0
PackTags
V 3.0
PackAL
V 1.0

11. OMAC PackSoft Work Group
PackAL is an application library of common software elements used in packaging applications
13 functions are machine functions, such as wind/unwind, dancer control, registration, and indexing
9 functions are communication functions for horizontal line communications, and one function is for the PackML machine state model
The PackAL application library creates a common look and feel in software elements for functionality, communication and machine organization in packaging machinery
PackAL
V 1.0

12. OMAC PackML Content State Types States Acting, Wait, Dual
Stopping, Stopped, Aborting, Aborted, Resetting, Idle, Starting, Execute, Suspending, Suspended, Unsuspending, Holding, Held, UnHolding Clearing, Completing, Complete
Execute is the only Dual State
Unit Modes
Typical unit modes are Automatic, Semi-Auto, Manual, Index, Jog
Each Unit Mode has a State Model, consisting of a sub-set of above States.
Unit Mode Manager
The mode manager determines how, and in what state a machine may change unit modes
The mode manager includes interlocks that prevent the machine changing at inappropriate states
PackML
V 3.0
States
A State can consist of one or more commands to “control object(s)”1, or consist of the status of a “control object(s)”, or both. Each state has a functional definition as part of a machine mode. In performing the function specified by the state, the state will issue a set of commands to the machine “control object(s)” which in turn can report status. The state will perform conditional logic which will either lead to further execution within the current machine state or cause an enabling transition to another state. States are arranged in an ordered fashion that is consistent with the specified operation / unit mode of the machine. There are a fixed number of states. These states are: Stopping, Stopped, Aborting, Aborted, Resetting, Idle, Starting, Execute, Suspending, Suspended, Unsuspending, Holding, Held, UnHolding Clearing, Completing, Complete. A representative definition of theses states is give below, but these definitions will vary depending on the machine, the definition, and function of the mode. The number of these states required for a particular mode is also dependent on the machine and the function of the mode.
A State completely defines the current condition of a machine.
The function of a state is defined by the process requirement of the control object(s) in the mode that the state resides in.
States consist of an ordered list of commands to control object(s), responses (status) from control objects, conditions, & transitions.
Transitions between States occur as result of:
Operator Intervention
Response to the status of one or more “control objects”.
A Mode state complete, defined as the completion of all operating steps within a defined state.
A acting State is one which 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 Wait State is used to identify that a machine has achieved a defined set of conditions. In such a State the machine is holding or maintaining a status until transition to a Acting State.
Dual state is defined as a machine actively executing in the chosen mode. Execute is the only defined Dual State. The dual state is representative of a machine state that can be continuously transitioning between acting and waiting, and looping, as defined by the logical sequence required.
Unit Modes
A Unit Mode consists of various states; the states are arranged in an ordered fashion that is consistent with the specified operation of the machine. Unit Modes define how a machine operates. There can be any number of modes, but typically there are a fixed number of states, as noted above. Typical unit modes are Automatic, Semi-Auto, Manual, Index, Jog, Clean, Dry Cycle, etc. The distinguishing elements between these unit modes are typically the commands given to the control elements by the states within the unit modes. The definition (command, responses, conditions, & transitions) of the state within each mode will be unique for the unit mode that the state resides in. For example in the Automatic unit mode the definition of “executing” in a filling machine will mean it is “producing” product. In the Manual Unit Mode the definition of the “executing” state may be dry cycling, or jogging / indexing. Although each unit mode has a “executing” state the state definition is mode dependent. The unit mode and state functional definitions differ along machine lines as well.
A Unit Mode completely defines the current operating condition of a machine
Unit Modes consist of an ordered set of states.
Transitions between Unit Modes occur:
As a result of an operator command
As a result of a State change. This is generated by change of state of one or a number of machine conditions, either directly from I/O or completion of a logic routine
At only pre-programmed states.
Unit Modes use a common base model but are functionally defined by the process of the machine
Unit modes can use a subset of states identified in the base model.
Conversely, procedural modes describe the way the logic, or machine code / procedure operates. Procedural modes, from S-88, are Automatic, Semi-Automatic, and Manual, and are built in methods the machine operator can use to manipulate the machine logic. An example of the procedural mode may be semi-automatic such that it allows a machine operator to single step through the states of a particular unit mode. The primary difference between procedural and unit mode is that the program, or procedure from unit mode to unit mode is different, where the program code for different procedural modes has not changed, although the method in which the code is executed has changed.
Switching from one to procedural mode to another can be independent of the state the machine is in. This is converse to switching unit modes, which typically occurs at wait states or just in the STOPPED state.
Unit Mode Manager
Packaging machinery has unit modes other than “automatic”, as noted above. Each unit mode is a defined by its own state model. In order to manage the change from one mode to the next a procedure known as a “mode manager” must be defined. The mode manager determines how, and in what state a machine may change unit modes; ie. the mode manager includes interlocks that prevent the machine changing at inappropriate states.
Specification on transitions between modes is left to the user, but typical transition points are at wait states, and in particular the STOPPED state. The specification of the mode manager is such that no state or control functions are carried out in this upper level routine. The intent of the mode manager is to logically supervise when a change in mode can be done, and command a mode change and report status of the change request.
Tag names will also be mode literal, and the mode manager will be responsible for not only managing the commanded mode, but also report mode status and time within a unit mode.

13. OMAC PackML State Names
Not Shown or printed

14. OMAC PackML Content OMAC PackML State Model: State Commands
V 3.0
State Commands
State Type: Dual
States
A State can consist of one or more commands to “control object(s)”1, or consist of the status of a “control object(s)”, or both. Each state has a functional definition as part of a machine mode. In performing the function specified by the state, the state will issue a set of commands to the machine “control object(s)” which in turn can report status. The state will perform conditional logic which will either lead to further execution within the current machine state or cause an enabling transition to another state. States are arranged in an ordered fashion that is consistent with the specified operation / unit mode of the machine. There are a fixed number of states. These states are: Stopping, Stopped, Aborting, Aborted, Resetting, Idle, Starting, Execute, Suspending, Suspended, Unsuspending, Holding, Held, UnHolding Clearing, Completing, Complete. A representative definition of theses states is give below, but these definitions will vary depending on the machine, the definition, and function of the mode. The number of these states required for a particular mode is also dependent on the machine and the function of the mode.
A State completely defines the current condition of a machine.
The function of a state is defined by the process requirement of the control object(s) in the mode that the state resides in.
States consist of an ordered list of commands to control object(s), responses (status) from control objects, conditions, & transitions.
Transitions between States occur as result of:
Operator Intervention
Response to the status of one or more “control objects”.
A Mode state complete, defined as the completion of all operating steps within a defined state.
A acting State is one which 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 Wait State is used to identify that a machine has achieved a defined set of conditions. In such a State the machine is holding or maintaining a status until transition to a Acting State.
Dual state is defined as a machine actively executing in the chosen mode. Execute is the only defined Dual State. The dual state is representative of a machine state that can be continuously transitioning between acting and waiting, and looping, as defined by the logical sequence required.
Unit Modes
A Unit Mode consists of various states; the states are arranged in an ordered fashion that is consistent with the specified operation of the machine. Unit Modes define how a machine operates. There can be any number of modes, but typically there are a fixed number of states, as noted above. Typical unit modes are Automatic, Semi-Auto, Manual, Index, Jog, Clean, Dry Cycle, etc. The distinguishing elements between these unit modes are typically the commands given to the control elements by the states within the unit modes. The definition (command, responses, conditions, & transitions) of the state within each mode will be unique for the unit mode that the state resides in. For example in the Automatic unit mode the definition of “executing” in a filling machine will mean it is “producing” product. In the Manual Unit Mode the definition of the “executing” state may be dry cycling, or jogging / indexing. Although each unit mode has a “executing” state the state definition is mode dependent. The unit mode and state functional definitions differ along machine lines as well.
A Unit Mode completely defines the current operating condition of a machine
Unit Modes consist of an ordered set of states.
Transitions between Unit Modes occur:
As a result of an operator command
As a result of a State change. This is generated by change of state of one or a number of machine conditions, either directly from I/O or completion of a logic routine
At only pre-programmed states.
Unit Modes use a common base model but are functionally defined by the process of the machine
Unit modes can use a subset of states identified in the base model.
Conversely, procedural modes describe the way the logic, or machine code / procedure operates. Procedural modes, from S-88, are Automatic, Semi-Automatic, and Manual, and are built in methods the machine operator can use to manipulate the machine logic. An example of the procedural mode may be semi-automatic such that it allows a machine operator to single step through the states of a particular unit mode. The primary difference between procedural and unit mode is that the program, or procedure from unit mode to unit mode is different, where the program code for different procedural modes has not changed, although the method in which the code is executed has changed.
Switching from one to procedural mode to another can be independent of the state the machine is in. This is converse to switching unit modes, which typically occurs at wait states or just in the STOPPED state.
Unit Mode Manager
Packaging machinery has unit modes other than “automatic”, as noted above. Each unit mode is a defined by its own state model. In order to manage the change from one mode to the next a procedure known as a “mode manager” must be defined. The mode manager determines how, and in what state a machine may change unit modes; ie. the mode manager includes interlocks that prevent the machine changing at inappropriate states.
Specification on transitions between modes is left to the user, but typical transition points are at wait states, and in particular the STOPPED state. The specification of the mode manager is such that no state or control functions are carried out in this upper level routine. The intent of the mode manager is to logically supervise when a change in mode can be done, and command a mode change and report status of the change request.
Tag names will also be mode literal, and the mode manager will be responsible for not only managing the commanded mode, but also report mode status and time within a unit mode.
State Type: Wait
State Type: Acting
Shown in Unit Mode: “Automatic”

15. OMAC PackML Content OMAC PackML State Model: States
V 3.0
States
A State can consist of one or more commands to “control object(s)”1, or consist of the status of a “control object(s)”, or both. Each state has a functional definition as part of a machine mode. In performing the function specified by the state, the state will issue a set of commands to the machine “control object(s)” which in turn can report status. The state will perform conditional logic which will either lead to further execution within the current machine state or cause an enabling transition to another state. States are arranged in an ordered fashion that is consistent with the specified operation / unit mode of the machine. There are a fixed number of states. These states are: Stopping, Stopped, Aborting, Aborted, Resetting, Idle, Starting, Execute, Suspending, Suspended, Unsuspending, Holding, Held, UnHolding Clearing, Completing, Complete. A representative definition of theses states is give below, but these definitions will vary depending on the machine, the definition, and function of the mode. The number of these states required for a particular mode is also dependent on the machine and the function of the mode.
A State completely defines the current condition of a machine.
The function of a state is defined by the process requirement of the control object(s) in the mode that the state resides in.
States consist of an ordered list of commands to control object(s), responses (status) from control objects, conditions, & transitions.
Transitions between States occur as result of:
Operator Intervention
Response to the status of one or more “control objects”.
A Mode state complete, defined as the completion of all operating steps within a defined state.
A acting State is one which 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 Wait State is used to identify that a machine has achieved a defined set of conditions. In such a State the machine is holding or maintaining a status until transition to a Acting State.
Dual state is defined as a machine actively executing in the chosen mode. Execute is the only defined Dual State. The dual state is representative of a machine state that can be continuously transitioning between acting and waiting, and looping, as defined by the logical sequence required.
Unit Modes
A Unit Mode consists of various states; the states are arranged in an ordered fashion that is consistent with the specified operation of the machine. Unit Modes define how a machine operates. There can be any number of modes, but typically there are a fixed number of states, as noted above. Typical unit modes are Automatic, Semi-Auto, Manual, Index, Jog, Clean, Dry Cycle, etc. The distinguishing elements between these unit modes are typically the commands given to the control elements by the states within the unit modes. The definition (command, responses, conditions, & transitions) of the state within each mode will be unique for the unit mode that the state resides in. For example in the Automatic unit mode the definition of “executing” in a filling machine will mean it is “producing” product. In the Manual Unit Mode the definition of the “executing” state may be dry cycling, or jogging / indexing. Although each unit mode has a “executing” state the state definition is mode dependent. The unit mode and state functional definitions differ along machine lines as well.
A Unit Mode completely defines the current operating condition of a machine
Unit Modes consist of an ordered set of states.
Transitions between Unit Modes occur:
As a result of an operator command
As a result of a State change. This is generated by change of state of one or a number of machine conditions, either directly from I/O or completion of a logic routine
At only pre-programmed states.
Unit Modes use a common base model but are functionally defined by the process of the machine
Unit modes can use a subset of states identified in the base model.
Conversely, procedural modes describe the way the logic, or machine code / procedure operates. Procedural modes, from S-88, are Automatic, Semi-Automatic, and Manual, and are built in methods the machine operator can use to manipulate the machine logic. An example of the procedural mode may be semi-automatic such that it allows a machine operator to single step through the states of a particular unit mode. The primary difference between procedural and unit mode is that the program, or procedure from unit mode to unit mode is different, where the program code for different procedural modes has not changed, although the method in which the code is executed has changed.
Switching from one to procedural mode to another can be independent of the state the machine is in. This is converse to switching unit modes, which typically occurs at wait states or just in the STOPPED state.
Unit Mode Manager
Packaging machinery has unit modes other than “automatic”, as noted above. Each unit mode is a defined by its own state model. In order to manage the change from one mode to the next a procedure known as a “mode manager” must be defined. The mode manager determines how, and in what state a machine may change unit modes; ie. the mode manager includes interlocks that prevent the machine changing at inappropriate states.
Specification on transitions between modes is left to the user, but typical transition points are at wait states, and in particular the STOPPED state. The specification of the mode manager is such that no state or control functions are carried out in this upper level routine. The intent of the mode manager is to logically supervise when a change in mode can be done, and command a mode change and report status of the change request.
Tag names will also be mode literal, and the mode manager will be responsible for not only managing the commanded mode, but also report mode status and time within a unit mode.
Shown in Unit Mode: “Maintenance”

16. OMAC PackML Content Unit Mode Manager Unit Mode Manager:
V 3.0
Unit Mode Manager:
Controlled management of transition from one Unit Mode to another
The mode manager determines how, and in what state a machine may change Unit Modes; ie. the Unit Mode Manager includes interlocks that prevent the machine changing at inappropriate states
Mode
transition
Unit Mode Manager
Packaging machinery has unit modes other than “automatic”, as noted above. Each unit mode is a defined by its own state model. In order to manage the change from one mode to the next a procedure known as a “mode manager” must be defined. The mode manager determines how, and in what state a machine may change unit modes; ie. the mode manager includes interlocks that prevent the machine changing at inappropriate states.
Specification on transitions between modes is left to the user, but typical transition points are at wait states, and in particular the STOPPED state. The specification of the mode manager is such that no state or control functions are carried out in this upper level routine. The intent of the mode manager is to logically supervise when a change in mode can be done, and command a mode change and report status of the change request.
Tag names will also be mode literal, and the mode manager will be responsible for not only managing the commanded mode, but also report mode status and time within a unit mode.

17. OMAC PackTags Content Tag Types Data Types, Units and Ranges
3 Types exists – Control, Status and Administration
Data Types, Units and Ranges
Integer, Real, Binary, String, Structure – a collection of data types. (This data type is typically reserved for higher level processors.)
Date/Time is not covered
PackTag prefix
PML is used to identify that it is a PackML tag
PMLc will represent that the tag is a “Control” tag with read / write access
PMLs will represent that the tag is a “Status” tag with read access
PMLa will represent that the tag is an “Administration ” tag with read access
Example:
PMLc.UnitMode PMLs.UnitModeCurrent
Approximately 180 Pack Tags exists.
PackTags
V 3.0
Tag Types
This guideline has been generated to support machines operating from all OMAC PackML line types and multimode equipment. Communication methods of control platform manufacturers vary widely, but must be capable of communicating with other machines on the line as well as SCADA systems. Advanced data types such as structured data types, arrays, and text strings are supported.
Pack Tags are broken out into two types; Control and Status. Control data is defined as data required to interface between machines and line control for coordination, or for recipe / parameter download. This is an area in which the PackConnect guidelines are helpful in solving interoperability issues. Status data is described as data collected by higher level systems for machine performance analysis, or operator information.[1] Generally informational data is passed using an Ethernet standard such as OPC. [1] Each grouping of data should be in a contiguous grouping of registers to optimise communications.
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. Previous work on S88 compatibility[1] shows how necessary this is, and established a precedent of using “PMLc. or PMLs.” as the prefix string. This makes it easy for a user who is unfamiliar with PackTags to look up their definitions. Furthermore in order to take advantage of addressing tags as complete structures or substructures the “dot” notation will be used. In an OPC tag listing all of the PackML tags will be listed under “PMLc. or PMLs.”, and further granularity can be chosen if the user wishes, by addressing the tags in terms of the machine mode, and further, the machine state. ie PML.”Mode”.”State”, ie “PML.AutoMode.Execute.”.
Because V3.0 of PackML now has multi-mode capability the PackTag prefix will need to include both the Mode and the State. Mode and State are required to differentiate the tags from one another as a machine transitions from function to function. Although keeping with the principles of PackML the PackTag prefix can be collapsed into the older style tag.
As noted, the prefix for V3.0 Packtags includes an additional character of “c” or “s”. PMLc will represent that the tag is a “Control” tag with read / write access, is typically noted as a “consumed” tag by the controller. PMLs will represent that the tag is a “Status” tag with read access, and is typically referred to as a “produced” tag by the controller.
An Example would be:
PMLc.UnitMode PMLs.UnitModeCurrent
PMLc.UnitMode is derived by the controller based on programmable conditions, and then consumed by the same controller as a command. PMLs.UnitModeCurrent is the value resulting from the commanded (or rejected) mode change.
An “administration” tag (PMLa.) is one which is typically used for OEE (Overall Equipment Effectiveness) information, or alarm data. Tags take the form of:
PMLa.Alarm[1].ID
[1] PackML State Model S88 Software Compatibility document, PackML, 3/22/2002
Data Types, Units, and Ranges
Integer – 32 bit, or 0 to in unsigned decimal format
Real – 32-bit IEEE 754 standard floating point format (maximum value of 16,777,215 without introducing error in the integer portion of the number)
Binary – Bit pattern within registers
String – null-terminated ASCII, 80 characters default
Structure – a collection of data types. (This data type is typically reserved for higher level processors.)
Some PLC processors are more efficient with Data types that are native to the controller rather than ones that fit the application. For instance, most controllers can do bytes but are more efficient with INTs because the controller must convert the tag to its native number type for computation then and back again. For that reason data types specified below are generally INT (or double INT, INT (32bit)).
Date/Time stamps are not supported within this guideline due to problems with synchronization between controllers for accurate SCADA data collection. Date/Time stamping will be provided by higher level systems, and not maintained within the control platform.

18. OMAC PackTags Content PackTags - Example Tag Types
V 3.0
Tag Types
This guideline has been generated to support machines operating from all OMAC PackML line types and multimode equipment. Communication methods of control platform manufacturers vary widely, but must be capable of communicating with other machines on the line as well as SCADA systems. Advanced data types such as structured data types, arrays, and text strings are supported.
Pack Tags are broken out into two types; Control and Status. Control data is defined as data required to interface between machines and line control for coordination, or for recipe / parameter download. This is an area in which the PackConnect guidelines are helpful in solving interoperability issues. Status data is described as data collected by higher level systems for machine performance analysis, or operator information.[1] Generally informational data is passed using an Ethernet standard such as OPC. [1] Each grouping of data should be in a contiguous grouping of registers to optimise communications.
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. Previous work on S88 compatibility[1] shows how necessary this is, and established a precedent of using “PMLc. or PMLs.” as the prefix string. This makes it easy for a user who is unfamiliar with PackTags to look up their definitions. Furthermore in order to take advantage of addressing tags as complete structures or substructures the “dot” notation will be used. In an OPC tag listing all of the PackML tags will be listed under “PMLc. or PMLs.”, and further granularity can be chosen if the user wishes, by addressing the tags in terms of the machine mode, and further, the machine state. ie PML.”Mode”.”State”, ie “PML.AutoMode.Execute.”.
Because V3.0 of PackML now has multi-mode capability the PackTag prefix will need to include both the Mode and the State. Mode and State are required to differentiate the tags from one another as a machine transitions from function to function. Although keeping with the principles of PackML the PackTag prefix can be collapsed into the older style tag.
As noted, the prefix for V3.0 Packtags includes an additional character of “c” or “s”. PMLc will represent that the tag is a “Control” tag with read / write access, is typically noted as a “consumed” tag by the controller. PMLs will represent that the tag is a “Status” tag with read access, and is typically referred to as a “produced” tag by the controller.
An Example would be:
PMLc.UnitMode PMLs.UnitModeCurrent
PMLc.UnitMode is derived by the controller based on programmable conditions, and then consumed by the same controller as a command. PMLs.UnitModeCurrent is the value resulting from the commanded (or rejected) mode change.
An “administration” tag (PMLa.) is one which is typically used for OEE (Overall Equipment Effectiveness) information, or alarm data. Tags take the form of:
PMLa.Alarm[1].ID
[1] PackML State Model S88 Software Compatibility document, PackML, 3/22/2002
Data Types, Units, and Ranges
Integer – 32 bit, or 0 to in unsigned decimal format
Real – 32-bit IEEE 754 standard floating point format (maximum value of 16,777,215 without introducing error in the integer portion of the number)
Binary – Bit pattern within registers
String – null-terminated ASCII, 80 characters default
Structure – a collection of data types. (This data type is typically reserved for higher level processors.)
Some PLC processors are more efficient with Data types that are native to the controller rather than ones that fit the application. For instance, most controllers can do bytes but are more efficient with INTs because the controller must convert the tag to its native number type for computation then and back again. For that reason data types specified below are generally INT (or double INT, INT (32bit)).
Date/Time stamps are not supported within this guideline due to problems with synchronization between controllers for accurate SCADA data collection. Date/Time stamping will be provided by higher level systems, and not maintained within the control platform.

19. ISA TR88.00.02 Technical Report
The Technical Report is an implementation guide, including examples
TR was issued August 2008
It merges the PackML and PackTags – but not one-to-one !
There are differences in terminology and definitions
PackAL – Function Libraries are not included
Contents:
Machine States
Acting State, Wait State, Dual State
Modes
Producing, Maintenance, Manual
PackTags
Status.StateCurrent
Date/Time
Implementation Examples
OEE Definitions
Alarm Codes
Weihen Stephan Harmonisation
PackML
V 3.0
PackML/PackTags Technical Report Approved The ISA88 Committee has approved a new ISA88 Technical Report on Machine and Unit States. This technical report incorporates the OMAC Packaging Workgroup’s PackML and PackTags documents with the industry standard ISA88 terminology.
ISA88
Harmonisation
and terminology
PackTags
V 3.0

20. ISA S-88 Standard(s)
In daily speaking it is called S88 but it covers 4 parts
Part 1: Models and Terminology
Part 2: Data Structures and Guidelines for Languages
Part 3: General Site Recipe Models and Representation
Part 4: Batch Production Records
S88
Part 1
S88
Part 1
S88
Part 1
S88
Part 1

21. Automation & IT Functional Hierarchy
S88

22. Automation & IT Functional Hierarchy
S95
S88

23. Automation & IT Functional Hierarchy
S95
S88
OMAC

24. ISA S-88 Standard – Part 5
S88 Part 5, Working Draft no. 6 issued July 2010
Part 5: Implementation Models & Terminology for Modular Equipment Control
Provide hierarchical structure for defining and implementing the control found in Control Module and Equipment Module entities.
S88
Part 5
Enterprise
Site
Area
Contains
one or more
zero or more
Introduction
ANSI-ISA entitled Part 1: Models and Terminology (referred to as Part 1 throughout this
standard) provides abstract models and terminology applicable to batch control. Part 1 Clause 5 Batch
Control Concepts defines types and hierarchies of control functionality and allocation, modes, and states
of equipment and controls. Clauses 6.6 Unit Supervision and 6.7 Process Control describe the control
activities that must be implemented at the equipment control level. Although the Part 1 standard provides
some hierarchical models for equipment control, it does not provide sufficient guidance to enable
consistent modular implementation of many key common performance requirements cited elsewhere in
the document. It is assumed that the reader of this Part has a general knowledge of Part 1.
ANSI/ISA entitled Part 2: Data Structures and Guidelines for Languages (referred to as
Part 2 throughout this standard) specifies visual and data representations of detailed recipe information,
the content of which interacts with and determines the scope and reusability of equipment control element
design.
ANSI/ISA entitled Part 3: General and Site Recipe Models and Representation (referred to
as Part 3 throughout this standard) provides some insights on reusability impact, but in relation to recipe
mappings.
ANSI/ISA entitled Part 4: Batch Production Records (referred to as Part 4 throughout this
standard) defines a reference model for batch production records, the content of which may place certain
design requirements on equipment control elements.
This Part 5 standard defines implementation models and terminology for modular equipment control in a
consistent modular fashion based on the Part 1 equipment control concepts. The intent of this standard is
to provide a clear hierarchical structure for defining and implementing the control found in Control Module
and Equipment Module Entities.
This Part 5 will provide a consistent framework for a modular and distributed design of these functions
with predictable interactions. This part describes an extensible core set of exposed interface functions
and sample protocols. The models in this part cover encapsulation of basic control functionality,
equipment procedural control at the phase level (as described in Part 1 ), and coordination control among
different equipment entities and external systems.
This standard is consistent with the other parts of the ANSI/ISA88 standard, particularly building upon
Part 1. Although this series of standards is intended primarily for batch processes, adoption of its models
can provide value in other manufacturing domains.

25. Automation & IT Functional Hierarchy
S95
S88
OMAC
S88
Part 5

26. ISA S-88 Standard – Part 5 Content Control Module
Control Modules must ultimately combine with a device.
It may do so through other Control Modules, or be the first point of contract between the logical control realm and the physical world.
Equipment Module
Coordinate the functions of other Equipment Modules and Control Modules
S88
Part 5
Equipment control
Equipment control described by this part is the logic or programming that implements the
Process Control represented in Figure 3 - Part 1 Process Control Activity Model to cause the
equipment to meet the intent of a Phase.
There are three types of automation objects that make up equipment control as follows:
1. The automation object that contains the Equipment Phase functionality that is recipe
aware.
2. The automation object that contains the Equipment Phase functionality that is not recipe
3. The automation object that contains the Equipment Basic Control functionality.
Equipment control can be very simple, consisting only of a single object performing basic
control , to complex structures with many interactive automation objects using all types of
control.
4.5.1 Types of control and levels
Part 1 of this standard describes procedural, basic and coordination as the three types of control
required to manage a batch process. These types of control are implemented in various levels of
the equipment. In addition different types of control are implemented at different hierarchy
levels. This part does not address any of the control types defined by part 1 for recipes or the
corresponding equipment control above the level of Equipment Phase.
4.5.2 Equipment Coordination control
Equipment Coordination control is the type of control in units, equipment modules and control
modules that handles the:
1. coordination of an within automation objects.
2. coordination between automation objects
Example: (Tom to provide)
3. propagation of Mode of Action to contained and referenced automation objects.
4. propagation of Modes of Control to contained and referenced automation objects.
Selection of the appropriate operating scheme could be a result of this
coordination control action.
5. arbitrating requests for usage.
Control Module
Control Modules must ultimately combine with a device. It may do so through other Control
Modules, or be the first point of contract between the logical control realm and the physical
world. There can be Control Modules that process information from a sensing device, such as a
proximity sensor in a block valve, that will apply the control necessary to de-bounce the sensor.

27. ISA S-88 Standard – Part 5 Content
Procedural Interface State and Command Model
S88
Part 5
Equipment control
Equipment control described by this part is the logic or programming that implements the
Process Control represented in Figure 3 - Part 1 Process Control Activity Model to cause the
equipment to meet the intent of a Phase.
There are three types of automation objects that make up equipment control as follows:
1. The automation object that contains the Equipment Phase functionality that is recipe
aware.
2. The automation object that contains the Equipment Phase functionality that is not recipe
3. The automation object that contains the Equipment Basic Control functionality.
Equipment control can be very simple, consisting only of a single object performing basic
control , to complex structures with many interactive automation objects using all types of
control.
4.5.1 Types of control and levels
Part 1 of this standard describes procedural, basic and coordination as the three types of control
required to manage a batch process. These types of control are implemented in various levels of
the equipment. In addition different types of control are implemented at different hierarchy
levels. This part does not address any of the control types defined by part 1 for recipes or the
corresponding equipment control above the level of Equipment Phase.
4.5.2 Equipment Coordination control
Equipment Coordination control is the type of control in units, equipment modules and control
modules that handles the:
1. coordination of an within automation objects.
2. coordination between automation objects
Example: (Tom to provide)
3. propagation of Mode of Action to contained and referenced automation objects.
4. propagation of Modes of Control to contained and referenced automation objects.
Selection of the appropriate operating scheme could be a result of this
coordination control action.
5. arbitrating requests for usage.
Control Module
Control Modules must ultimately combine with a device. It may do so through other Control
Modules, or be the first point of contract between the logical control realm and the physical
world. There can be Control Modules that process information from a sensing device, such as a
proximity sensor in a block valve, that will apply the control necessary to de-bounce the sensor.

28. ISA S-88 Standard – Part 5 Content Automation Object
Functional Strategy:
Core control in the Automation Module
Devices that would be implemented in a Functional Strategy are Servos, Material Transfers, Bipolar Devices, Two-way Valves, Motors, Pumps
Part 5 will not define functional strategies.
Functional Strategy
Functional Strategy (FS) as shown in Figure 7 - Automation Object implements the core control
of the Automation Module. In a Control Module this would be basic control. In an Equipment
Module this would be procedural control that may or may not be recipe aware.
It is presumed that the Functional Strategy of an Automation Module can be represented as one
or more state diagrams, no matter where it fits in the S88 continuum of equipment procedural,
equipment coordination or equipment basic control. Some examples of devices that would be
implemented in a Functional Strategy are Servos, Material Transfers, Bipolar Devices, Two-way
Valves, Motors, Pumps, etc. The Functional Strategy implements the control that is necessary to
make these devices work. The Functional Strategy is not limited to physical devices. The
Functional Strategy can define a process or complete machine.
The Functional Strategy Status reflects all necessary aspects of the internal workings of the
Functional Strategy and are available for view by any component. Some status attributes for the
Functional Strategy can be found in the example appendix.
Then Functional Strategy also has command and control attributes that are used to command and
control subordinate Automation Modules. The command attributes are used to execute actions in
the subordinate Automation Modules. The control attributes are used by the subordinate
Automation Modules to perform Procedural, Coordination and Basic Control. Some status
attributes for the Functional Strategy can be found in the example appendix..
There are many different organizations (i.e. OpenPLC, OMAC, IEC 61131) that have already
defined Functional Strategies for devices, processes and machines that are in use in
manufacturing. This part will not define functional strategies.

29. ISA S-88 Standard – Part 5 Content Automation Object
Functional Manager:
Receives command and control attributes from a supervisory source (another AM, a HMI etc.)
Command attributes cause an action to be performed in the Functional Strategy
Includes status attributes that provide status of commands and control signals
Function Manager
The Function Manager is designed to accept command and control attributes from a supervisory
source (another AM, an operator through an HMI, etc.). The supervisory source is determined
by the Resource Manager. Only the supervisory source specified by the Resource Manager will
be allowed access to the functional strategy by the Function Manager.
The Function Manager will accept command attributes which cause an action to be performed in
the Functional Strategy. The control attributes are typically used by the Functional Strategy to
maintain Control. Examples of control attributes are interlocks and permissives that may be
passed to the Functional Strategy by the Function Manager. Some command and control
attributes for the Function Manager can be found in the example appendix.
Example: When a maintenance person is the supervisory source the function manager will allow the interlocks to be
bypassed to the functional strategy. In all other cases interlocks are passed unaltered to the FS.
The Function Manager also includes status attributes that provide status of commands and
control signals. The Function Manager is also in charge of determining the status of the
Functional Strategy and determining whether the Automation Module is in a safe state to allow
the directing module to change in the Resource Manager.

30. ISA S-88 Standard – Part 5 Content Automation Object Resource Manager:
The Resource Manager is designed to regulate who is able to command the FS
Only the supervisory source specified by the Resource Manager will be allowed access to the functional strategy by the Function Manager
Resource Manager
The Resource Manager is designed to regulate who is able to command the FS. Every
Automation Module will have a Director that is the owner of the Automation Object.
The director may delegate authority to a different supervisory source to interact with the FM & FS.
Also it could have one or more subordinate Automation Modules that it directs. If there is more
than one subordinate Automation Module, there will be logic which will combine the multiple
attributes of the subordinate Automation Modules into one attribute for the directing Automation
Module. The Resource Manager’s job is to take requests from other supervisory sources and
change the directing resource of its Automation Module. It will validate whether it is OK to
change the directing resource and determine whether to direct or release subordinate Automation
Modules. The interface for the Resource Manager will be divided into two different sections, the
Director Interface and the Subordinate Interface. The Director Interface deals with commands
and status values that get sent to and from the supervisory sources. The Subordinate Interface
deals with commands and status values that get sent to and from this module’s Subordinate
Automation Modules.

31. ISA S-88 Standard – Part 5
Content
Automation Object
S88
Part 5

32. A world without standards!
Danish Keyboard Layout
Swedish Keyboard Layout

33. Advantages by standardisation
End User
Maintenance
Only need to know one standard
Easier to test
Standard test plans
Ease of re-use
Interfaces
Uniform
Easier to expand and integrate
Flexibility
Less dependent on people and OEM’s
Operations
Uniform layout and “language”
Ease of operation
OEM
Development
Independent of programmers
Faster implementation
Easier to test
Support
Global support independent of “who made the program”
Interfaces
Easier to integrate with supervisory systems and other OEM machines
Re-use
Easier to re-use applications across customers
Progress and Innovation
Lowering costs

34. Make2Pack – Conclusions
OMAC has come a long way with the Pack standards
PackML, PackAL and PackTags
OMAC is facing new challenges since they are now not part of ISA
Make2Pack organisation is in Idle mode!
Lately the effort has been used in updating ISA-88 Part 1
Tehnical Report OK – but what about PackAL?
Too few people!?
Marketing is needed
ISA 88 Part 5, Working Draft July 2010
Very difficult to find the link to the PackML standards!
More related to ISA 88 Part 1,2,3,4
Much work is needed if it shall be used as a standard for Packaging
The risk!
Without agreed and approved standards we see propreiteray solutions from the automation suppliers

35. Guidelines for Packaging Machinery Automation
Recommendations
PackML
V 3.0
PackTags
Guidelines for Packaging Machinery Automation
V 3.1
Read the OMAC documents first
PackML and PackTags
PackAL is included in “Guidelines for Packaging Machinery Automation”
Then read the Technical Report
ISA - TR
To avoid confusion……
Don’t read the ISA88 Part 5, Working Draft yet!

36. The future dream!

37. Thanks!