Recipe management requires a pinch of organization

Whether it is neatly organizing recipe cards in a home or integrating an ERP system to an automated plant floor, recipe management can present many challenges. These challenges vary across applications and industry and change based on the use of technology in the manufacturing process.
By Andy Stump, Rockwell Automation May 1, 2009

Whether it is neatly organizing recipe cards in a home or integrating an ERP system to an automated plant floor, recipe management can present many challenges. These challenges vary across applications and industry and change based on the use of technology in the manufacturing process.

One of today’s most prevalent recipe management challenges is the transformation of a recipe definition from a business system to a plant floor control system. How you understand, interpret, and apply the fundamentals of recipe management will determine the success you will have in meeting this challenge.

Before the challenges of recipe management can be fully appreciated, the concept of ‘recipe’ must first be explored. ISA-88.01 defines a recipe as “an entity that contains the minimum set of information that uniquely defines the manufacturing requirements for a specific product. Recipes provide a way to describe products and how products are produced.” (ISA 88.01 Batch Control Part 1: Models & Terminology, Page 35)

The standard continues by stating that, “recipes contain the following categories of information: header, formula, procedure, and equipment requirements.” The recipe header contains administrative information about the product. This may include recipe and product identification, revision details, approvals, and status. The recipe formula identifies all process inputs, process parameters, and process outputs pertinent to making the product. Generally speaking, these are the setpoints, configurations, and materials needed to make the product, as well as a list of data that should be collected during batch execution.

The recipe procedure defines the steps and sequence for carrying out the process to make the product. The procedure definition starts in non-equipment specific terms and is refined into the specific sequence needed for plant floor production equipment.

Finally, the equipment requirements defined by the recipe should include reference to all needed equipment to make the product. The equipment requirements start in general terms %%MDASSML%% the allowable materials and required processing characteristics %%MDASSML%% and is refined into specific terms %%MDASSML%% the available production equipment needed to execute the batch.

These four recipe parts provide a means of documenting a company’s product intellectual property. Each of these parts should be defined, managed, and transformed across the enterprise in a consistent fashion to turn the intellectual property into actionable production activities. To better understand this transformation, we look again to ISA-88.01. The standard defines the four recipe types that can be found within a corporation: general, site, master and control recipe. Each of the recipe types describes the four recipe parts in progressively more detail.

Writing the general recipe

The general recipe is written by those most familiar with the core chemistry and processing requirements of the product. It identifies raw materials, relative quantities and the processing steps required to make the finished goods without specific knowledge of the manufacturing equipment available to actually make the product. The general recipe is considered the source of product definition for a company.

Once a corporate product definition (general recipe) has been established, it must undergo a site specific transformation to account for conditions found at a particular manufacturing location. This may include site-specific equipment, plant manufacturing capabilities, and/or local raw material variations. This recipe is referred to as a site recipe.

Just as the general recipe was transformed to accommodate site specific variations, so must the site recipe be transformed to accommodate area-specific processing equipment. This recipe is referred to as the master recipe.

The master recipe must contain any necessary information about local plant floor equipment to help verify the correct processing of the batch. It is the master recipe that holds the final instructions to produce a specific product on a specific piece of production equipment. Since it is written with the level of detail required to run production, the master recipe is typically what the production department considers the “recipe” for a product.

At the start of production, the control recipe takes the information provided by the master recipe, adapts it to batch specific raw material quantities and setpoints, links to available equipment, and defines the level of detail necessary to initiate and monitor a batch. During this time, the production department commonly refers to this entity as the running batch recipe. (ISA 88.01 Batch Control Part 1: Models & Terminology, Page 36)

ISA 88.01 states that many control activities must be implemented to successfully manage batch production. Recipe management is the first of these control activities. Recipe management is made up of the control functions that create, store, and maintain general, site, and master recipes.

The overall output of this control activity is a master recipe that is made available to process management, which uses it to create a control recipe.” (ISA 88.01 Batch Control Part 1: Models & Terminology, Page 66) So in summary, recipe management defines what is needed for definition, storage, and management of the four recipe parts (header, formula, procedure, equipment) across three of the four types of recipes (general, site, master) in an enterprise.

Of course, implementing effective recipe management is not without its challenges. Most, if not all, commercially available systems on the market today are not able to offer a complete recipe management solution spanning both the business and plant floor control system. Creating this type of solution has been and will continue to be a challenge for software development companies for some time.

Given this reality, end users are still faced with the same requirement that becomes increasingly more complex to solve when enterprise wide business systems are used in conjunction with automated plant floor control systems. In these situations, users are faced with integrating disparate systems to produce a unified recipe management strategy. This introduces one of the today’s most prevalent recipe management challenges, the transformation of a product definition from general recipe to master recipe across the different systems.

Mixing with ERP

Recipe management modules within enterprise resource planning systems define the key product instructions for manufacturing in context of the business. They use information from the supply chain, raw material and resource costing and availability, etc., to define the product recipe for the corporation.

Typically these recipes do not contain enough detailed information to make product on a plant floor in real time, therefore, they need refined to accommodate plant floor execution. This is where a transformation to the next level must occur to provide such information as the exact procedural sequence to optimize production on a specific set of equipment (e.g. parallel ingredient additions to improve cycle time). Setpoint information from the business system must be linked to plant floor control system sequences designed to complete this task. These systems contain the localized information needed to make a certain product on a specific piece of equipment at a specific point in time.

The link between systems can be separated into two parts: translation and transformation. There are many technology solutions available today to solve communication translation between systems. Vendors are leveraging common connector technology as well as industry standard language interfaces like the World Batch Forum’s BatchML schema. These standard interfaces allow the systems to talk to each other and seamlessly pass information.

The ‘human’ recipe

But even with technology so readily available, there isn’t a good way to complete recipe transformation across multiple systems. This process is still very dependent on the systems in use, each systems capability, and the overall complexity of the production process. When a human is used to perform the transformation, we rely on his reasoning and logic to make it work. When electronic systems are linked together, human reasoning is replaced by rule-based logic in code.

Therefore, the success of a recipe management strategy is still dependent on how well the user understands the components of recipe management and then systematically designs a solution that meets their needs.

The need for and challenges of having both business systems and control systems are very real, but they should not become a limiting factor to achieving effective recipe management, including transformation. Success is the result of spending time in early design to fully understand the company’s needs before jumping into a solution or applying technology. Recognizing the challenges up front and developing a plan to address each challenge is the best approach.

If recipe management design proves daunting, engaging a specialist is a viable option. A specialist can assist in defining which data belongs in each p wiich part of a recipe (header, formula, equipment, procedure), planning the transformation across the recipe hierarchy (general, site, master, control recipe), and then creating translation between the multiple systems.

The end result is a solution that solves application challenges associated with recipe management (definition, distribution, translation, and transformation) in today’s ultra-competitive world.

The integration of four types of recipes for batch control in systems can deliver the same kind of performance at the plant floor level as it does in the business system.

A successful recipe requires all necessary materials needed for success in a process to be included. That includes the human element, which can be overlooked.