And with good reason. Just as it makes sense to have a common look and feel to the control panel today, there was a time when a technician using general knowledge and tracing which-wire-color-meant-what was the human-machine interface.
Now we have networked sensors and communications, so many of those wires don’t even exist any more. In the best of cases we have interactive help instructions (see Chapter 7). And while attempting to consistently enforce a 100-page electrical specification is its own challenge, the whole cart is turned over when an acquisition or merger causes a company to inherit someone else’s machinery.
The same problem arises when equipment from a facility following its own ‘plant specification’ is moved to a plant with a different specification. Not to mention the time and cost to maintain individual plant specifications. This poses a real challenge to corporate engineering and procurement managers. As technologies advance, the time and effort to continually update a standard can become futile and can result in the use of outdated components.
For these reasons, some corporate engineering departments have begun putting their control specifications on a diet, choosing instead to specify required functionalities, reference international standards, and qualify conforming suppliers based on performance as well as compliance to such standards.
These functional specifications give packaging machinery builders the opportunity to differentiate based on innovation and value.
While vendor-based electrical specifications are still in wide use, there is a growing trend toward standards-based functional specifications with preferred suppliers. This practice limits the number of suppliers to support while promoting a healthy sense of competition.
A notable recent example of the trend to standards-based specifications is the packaging automation specification implemented worldwide by Nestlé, which follows the OMAC Packaging Guidelines and names four preferred suppliers.
One straightforward way of developing such a specification is to start in principle with the OMAC Packaging Guidelines Version 3.1 the compilation of standards defined back in 2004. Though it has not been updated recently, it remains valid in concept.
That is, the guidelines call out IEC-compliant buses and IEC 61131-3 programming languages. It provides a glossary of terms. And it defines packaging line types from stand-alone machines to highly integrated lines.
Under the new PackSpec initiative, these guidelines will be incorporated into a functional specification document that can be used in whole or in part, with the expectation of a base level of consistency worldwide.
Until then, a combination of the standards called out in the OMAC Packaging Guidelines and recent advances in control functionality can be used to generate a practical interim specification.
To assure inclusion of current and widely available control functionalities, sample language has been provided in this chapter for download to supplement specifications as applicable to user requirements. This language is intended for evaluation by controls engineers in collaboration with their peers in packaging engineering and procurement.
The following language can be downloaded in a Microsoft® Word® format that can be copied and pasted in whole or in part, and modified to meet applicable requirements.
New functional requirements for packaging automation systems
The language on following pages provides controls engineers with descriptions of functionalities that have become available in recent years that may be useful for inclusion in a functional, performance-based control specification, based on relevant international standards rather than proprietary products.
Pick and choose which elements are best adapted to your existing electrical specification.
(Disclaimer: This language is offered on an as-is basis, and Packaging World in no way assumes liability for damages arising from its use.)
It is the intention of (name of company) to implement industry best practices and applicable standards in packaging machinery automation to minimize total cost of ownership, including but not limited to optimization of: initial equipment cost and lead time, training, maintenance, equipment efficiency and availability, changeover flexibility, scalability, and reconfigurability.
1. Wherever feasible, control system will follow applicable OMAC Packaging Workgroup guidelines to maximize operational efficiencies in implementation, operation, maintenance and reconfiguration.
2. System shall support centralized, distributed or a combination of centralized and distributed control for optimized performance based on application requirements.
3. Servo motion technology is strongly encouraged for flexibility and performance in primary package filling, sealing, labeling and secondary packaging.
4. Integrated control for logic, motion, robotics and related functions shall be implemented in a system providing languages (FB – Function Block, FBD – Function Block Diagram, IL – Instruction List, LD – Ladder Diagram, SFC – Sequential Function Chart, ST – Structured Text) of the international control language standard IEC 61131-3.
5. A unified software development environment will integrate all control programming, visualization, and implementation of the PackML state model. Program development in this environment will be modular and scalable across the automation supplier’s available hardware targets.
6. IEC 61131-3 conforming Function Blocks shall encapsulate and simplify parameterization of complex control functions wherever possible and practical; Structured Text especially within Function Blocks to efficiently execute critical functions; and Ladder Diagram and/or Function Block Diagram for sequential logic tasks.
7. No more than one such Function Block shall be required to initiate a single axis, and no more than two shall be required to perform any multiaxis motion tasks.
8. All data and code shall be stored in removable, non-volatile, non-mechanical memory. Application data and parameters database shall be saved according to standard file extensions (such as .xml and .csv).
9. The OMAC PackML™ state model, modes and naming conventions shall be used to describe machine states for standardized operation, monitoring, analysis and business management information access via OPC, XML or other standardized data structures and interfaces. The controller shall be capable of creating a PackML enabled supervisory layer.
10. Provision shall be made for remote diagnosis of the control system via Web, to communicate via Ethernet, modem or similar appropriate standardized interface.
11. The integrated control system shall be sufficiently powerful to execute in a single application program on a single controller, to avoid inefficiencies caused by multiple control modules or software calls between application programs, and backplane and/or network communications between control components.
12. Machine documentation shall be included as part of the machine control system to reduce the possibility of losing printed or electronic documentation.
13. Control system shall permit changeover and reconfiguration via recipe management to run different products.
14. Integrated motion (motor and drive) shall be available, and shall provide a choice of conventional motors and drives, drive-onboard-motor and machine-mounted drive independent of motor configuration and brand.
15. The system shall be implemented in such a way that it is unnecessary to re-home axes upon re-start.
16. The processor shall be capable of independently controlling multiple modules if the application requires, thus enabling simplified monobloc machine control. The controller family should be scalable, with a single controller capable of controlling the largest number of anticipated axes within a 2 millisecond network update rate.
17. If the application requires, control system shall be capable of advanced polynomial algorithms, changing cam profiles and related commands on the fly for efficient format changes, and providing onboard event logging and access in plain language to diagnostic messages.
18. The control system shall be capable of performing data collection and serving compiled data to upper control layers asynchronously via FTP.
19. The control system shall provide direct connectivity to a database with no need for an intermediate ‘data concentrator,’ to facilitate the emerging requirement for serialization and product record keeping.
20. Communications shall be performed via IEC conforming standardized industrial control networks, as well as Ethernet TCP/IP for information handling.
21. The control network shall support IEC-conforming open, integrated safety protocol extension.
22. Integrated safety functionality shall be available, including safe motion functionalities.
23. To maximize energy efficiency, high efficiency power supplies, regenerative power supplies for servo drives, and a common DC bus between servo drives shall be available.
Liked this article? Download the entire playbook here.
