Comment

01 April 2004

The sweet smell of success

Innovative ERP, forklifts with bar-code scanners, and wireless communications perfume situation.

By Mike Hunter

Industrial scents incorporated into consumer products are a key manufacturing component, adding value and distinguishing many companies' product lines.

This case study recounts the recent improvements undertaken at a European facility that produces 160 varieties of perfume from more than 900 types of raw materials.

When complete, the project will connect the shop floor to the enterprise level by adding a new production control system (PCS) and upgrading the batch process and plant control systems.

The business drivers were to improve management of raw materials and finished goods inventory by providing validated raw material information to personnel in the planning, batch, and warehouse areas. Doing this would help the facility meet the additional goals of producing smaller batches and increasing throughput. The business goals also included improving production control and information reporting to reduce process failures, quality fluctuations, and scrap material. The new system had to allow the company to set up metrics in the future for improved process control, preventative maintenance, and raw material consumption analysis. The technological goal was to create a state-of-the-art system that corresponded to the increased demands of the plant. There was a requirement to use standard components to improve the spare parts availability and an open architecture to allow for future expansion.

This case study looks at the PCS solution by outlining the existing environment and constraints in place. It then analyzes the project's scope and reviews the system design and interfaces. Finally, it examines challenges of the implementation and divulges some key findings and conclusions.

The plant floor topology

The production facility went online in 1964 and currently has more than 150 employees. It produces 160 perfumes for 80 clients from more than 900 raw materials received from 70 different suppliers. The production runs twenty-four hours per day, five days per week and produces up to 30 batches each day.

Raw ingredients are stored in various areas of the warehouse (A1, A2, A3, and Specialty) and in storage tanks (ST1). Operators in each of the two mixing rooms (M1 and M2) preweigh ingredients and add them to the production tanks. Ingredients from the warehouse travel to the mixing rooms by forklift truck. The mixing room operators pump the delivered ingredients, along with liquids from the storage tanks, directly to production vessels.

Each mixing room operates on a single batch at a time and engages is a strict sequence of events for each batch.

This batch sequence, however, tightly integrates into production planning functions, raw materials storage and movement, and final transfer to packaging. At the beginning of each day, the enterprise resource planning (ERP) system produces batch mix sheets with production order information. Each batch contains some ingredients that need to melt in heating cabins for many hours before they can mix together. While the ingredients are melting, workers allocate the batch to a specific production tank. The tank is prepared, cleaned, and quality checked. Storage tank material goes into the tank along with A1, A2, and A3 ingredients until they reach the production tank's minimum level. At this point, workers add A4 ingredients to the mix, as well as the melted material and any remaining A1, A2, and A3 ingredients. Lastly, they add specialty ingredients and do a quality check, and the batch waits for transfer to filling.

Before the new system, mix sheets came from the ERP system, and the production planning, warehouse, and mixing room personnel reviewed them together at the start of the shift. Warehouse and mixing room operators had to coordinate amongst themselves the timely delivery of ingredients for batches. Each step in the batch process from preweighing, additions, timing, and quality-check logging took place manually. The existing process automation was antiquated and difficult to support. All reporting and data logging took place by putting pen to clipboard. Workers determined system status by examining pilot lights on local control panels, viewing an antiquated PC graphics station, and physically observing the process.

Although the actual batch process was relatively simple, the large quantity of raw materials and unique end products increased the complexity of the problem. Improved information flow, from production planning to the mixing room floor, was required. This data needed to be in real time and well organized for the project to succeed. All users, and not just batch operators, would need to integrate into the solution, tying both upstream and downstream processes into the supply chain.

Raw material management

The project scope entailed improving the process from receipt of the ERP mix sheet to final product filling. This took place by optimizing the raw material management, production control, and finished product inventory areas of the facility. The PCS solution overlays the ISA-95 Enterprise-Control System Integration Stan-dards model, and the company included some operational functions in the scope.

The new PCS system had to improve:

• the interface to production planning (ERP), warehouse personnel, and production personnel
• the administration of material, containers, and resources in the production area and transportation between the warehouse, storage tanks, and mixing rooms
• mixing room automation
• the preparation process (melting and production tank preparation)
• the mixing and filling process

Overall, there were still many manual processes that the system had to preserve. The planning department would need to share and disseminate information to the mixing rooms, and each area would require easy access and methods of data entry. Let's now look at the design of the PCS and how it addresses each of the above issues to achieve the project's goals.

The production control system automates where necessary and leaves operators with full manual control where required. The major components of the PCS and the key interfaces are able to achieve plant floor to ERP connectivity and information flow. Configurable, off-the-shelf components serve where possible as opposed to custom hardware or custom software.

Central to the PCS is the material tracking and production control database—a common database shared by all applications, in this case built on an Oracle platform. Configurable software modules envelope the database, including an interface to the ERP system, a batch sequencer, visualization screens, a reporting module, a bar-code reader interface, and a new warehouse pocket PC (PDA) link.

Within the central database, a set of standardized stored procedures allows the modules to interact with the various data objects created. The data objects within the database have an architecture that directly represents the physical structure, master recipe, material data, production data, quality data, and system data. This approach allowed the company to optimize data sharing between the various software components and, ultimately, from the production planning room through the warehouse to the mixing rooms.

A key design requirement for production planning was for the PCS to interface with the ERP system. A reusable application module passes the following information between the ERP system and PCS.

PCS had to retrieve from the ERP system:

• production order information
• available inventory
• master material data

PCS also had to send back to the ERP:

• raw material consumption
• inventory differences detected—gain or loss of raw materials

This data transfer is configurable to allow for future changes and portability to other applications. The production order does not contain resource information (i.e., which equipment should work on the process); rather, this happens within the PCS. A standard, configurable, ERP interface to the database application allows the designers to easily set up the application.

Standard, off-the-shelf products handled visualization and batch server components. PC-based display stations went into the mixing room, the storage tank station, production tank areas, and the specialty ingredients area as new operator interfaces. These stations relieved much of the paper work, which was prone to errors in the past. The stations also give operators more timely process information, which allows them to make better production decisions.

A typical batch schedule sheet lists active or planned batches by ERP reference number, batch identification, product type, status, and equipment assignments. Operators can now view raw materials associated with a batch by simply highlighting the batch entry.

A raw materials planning screen coordinates delivery of raw ingredients to the mixing room. By highlighting a material from the material list associated with a batch, mixing room operators can view the raw material inventory, the available container sizes, and the location. The screen also allows operators to generate a work order for the warehouse to bring the selected containers to the mixing room. The common production database makes all of this possible.

Consistent screen layouts with common button bars and navigation standards ensured a consistent look and feel on the visualization screens and simplified training. A graphics interface module in the PCS handles coordination with the visualization package.

The forklift drivers who retrieve raw materials all now carry PDAs and bar-code scanners. As a result, the PCS can communicate with the warehouse, sending the mixing room delivery requirements directly to the drivers. The required ingredients for each batch display on the PDAs, and drivers scan the raw material containers as they select them for verification and tracking. The pick list on the PDA can sort by quantity, storage location, material ID, and material name.

The company also installed bar-code reading stations in the mixing rooms at each scale station to track actual raw material usage. Radio frequency receivers channel this information back to the PCS data transfer module and the production database.

To model the procedure and execute recipe transitions, standard batch sequencing software worked well. The PCS's batch interface module passes parameters, key transitions, and handshaking data to the batch server. Batch report data archives every minute via the reporting module. A simple, generic recipe procedure model represents the entire procedure for all recipe instances.

The model further breaks down the process into detailed operations and phases, which are executed in either the PC as PC-based phases or in the PLC as equipment phase modules.

There is a software module that allows manual operator prompts and entries at select times throughout the batch and that enables manual additions if required. It is PC Prompts, and it interacts with the visualization and batch servers. This application is configurable and modular for reuse in future applications.

A new PLC replaced the aging controllers and now executes the PLC-based phases. This enabled the project team to follow an object oriented framework and ISA-88 ISA Batch Systems Standards principles in its organization and programming. A standard phase logic interface controls state transitions for phases and communications to the batch server.

Communicate with the process

The complexity due to the quantity of ingredients and final products, combined with the manual nature of many operations, initially posed a significant challenge when trying to integrate new automation and hardware for data tracking, information dissemination, and adequate batch control. The company overcame these obstacles by spending the time up front to design a proper object model that correctly modeled the process and allowed for shared interaction among the many automation layers and software modules. PC Prompts software, bar-code technology, and PDAs for each forklift driver provided a mechanism for the various operators and production managers to communicate with each other and the process.

From the beginning, the implementation was more than just a batch system upgrade. The complete vertical layer—from the plant floor to the ERP system—was involved. If a raw material container came into the plant with an unexpected amount of material, or if spillage occurred during transfer, adjustments were required immediately with the corrections fed back into the system in real time. If it made sense to acquire and weigh common raw ingredients for multiple pending batches, this ability was required from the operators. Following the ISA-88 ISA Batch Systems Standards and ISA-95 Enterprise-Control System Integration Standards models proved effective in modeling this vertical solution, developing the object model, and abstracting the layers of complexity into manageable parts.

As in many production environments, a small shutdown window existed to install and test the new control system. The only available windows were weekends and holidays. Software testing took place on equipment modules and control modules with simulation capabilities for as long as possible before going live. With the batch process under simulation, the complete production database capabilities could be staged before installation, further reducing the risk during the tight start-up windows.

Other challenges included a lack of piping and instrumentation drawings and documentation from the old facility, prompting an in-depth field survey in the project's early phases. Because some of the ingredients were hazardous, there was a requirement to adhere to safety regulations and requirements for hazardous environments. This technical crew overcame the challenges by adhering to standards, by using a proven project methodology, and by incorporating a modular design. Many of the components are such that they will be reusable in future projects and or expansions.

This application illustrates that one can achieve complete plant floor to top floor connectivity in a batch process environment without extensive process modifications or operational changes while using off-the-shelf components. Developing a standard, yet configurable object model around a common production database proved invaluable. The development of the object model provided a road map to the solution and eased the development of the many interacting components. Creating a generic recipe procedure model and allowing the differences to be parameter driven greatly simplified the batch server scope.

Batch production from the manual ERP mix sheets now leverages online recipe selection and efficient, coordinated ingredient picking between the warehouse and the mixing room. Adjustment to raw material inventory can now happen at the source, and spillage is immediately counted. Scrap is a known quantity and is manageable. The production database provides batch reporting from a common source, with batches cross-referenced to ingredient and lot-tracking information. The infrastructure now installed allows management to set the new metrics and process measurements required to further refine the process.

The ERP system now obtains automatic, validated updates for inventory levels and usage, improving raw materials management and inventory control. Operators will benefit from improved process information and material tracking—resulting in improved quality. Plant management will receive more accurate and detailed batch reporting and be able to make more informed business decisions. The effort taken to connect the entire vertical involved with the batch process has enhanced the overall value and payback possibilities to far greater extents than the traditional isolated view of the batch mixing room did. The new system enables the facility to continue to add value, distinguishing the organization's many product lines through the varieties of scents produced. ?

Behind the byline

Mike Hunter is an ISA member. He has a B.S. in electrical engineering and an MBA. Hunter is also a P. Eng., and he works as director of marketing and technology at ATR Systems Inc. Write him at mhunter@atrsi.com. This article derives from a paper that Hunter presented to the World Batch Forum's North American Conference (www.wbf.org ).