S88 Redefines Clean in Place Operations

When defining batch processes, it is best to apply a top-down/bottom-up design approach. Begin at the top of the physical model and work downward, defining boundaries (process cells, units, etc.) and the specific equipment within each boundary (vessels, pumps, headers, valves, etc.). Once physical entities are identified, work upward from the bottom of the procedural model to define the actions that each piece of equipment and unit will perform.This model supports an iterative design process that helps identify reusable objects. The benefit becomes apparent when a process is undergoing initial designs, perhaps for budgeting purposes. Usually at this point, Piping and Instrumentation Diagrams (P&IDs) are not available and preliminary designs are based on Process Flow Diagrams (PFDs). Because equipment specifics are still undefined, automation designs are developed at a high level.Later, when P&IDs become available, the S88 model and its support for top-down/bottom-up designing makes expanding the details of the preliminary design easier. Additionally, the iterative design approach is well suited for achieving the true objective of object-oriented programming techniques—identifying reusable software objects.The CIP process — from concept to practiceFor many of us, a top-down/bottom-up iterative design approach, identifying class-based entities, and developing reusable objects, makes a lot of sense. But it is harder to understand what this approach looks like, and it is helpful to have a practical example.Clean-In-Place, or CIP, is a process frequently used in pharmaceutical and biotech manufacturing facilities to ensure that process lines, vessels and reactors are free of inorganic and organic contaminants. At the laboratory scale, equipment can be cleaned manually, but in large-scale production processes it is impractical to disassemble equipment and transfer lines to clean individual components. Instead, this must be done by sending cleaning solution through the process path, or CIP circuit, without disassembly. This introduces unique design challenges.Within flexible manufacturing facilities, other factors complicate CIP. Because process connections frequently change, it is necessary to identify, track and clean the multitude of possible product transfer paths from upstream to downstream vessels, and to supply CIP solution from a few shared CIP sources to a number of process units distributed throughout the facility.Even with preconfigured modules and efficiency tools, automating CIP activities and finding a solution that is easy to use, validate and maintain remains a challenge. Defining the boundaries and responsibilities of the various elements is a key step. There are several suggestions to keep in mind when defining boundaries:

• Seek identical or very similar entities
• Identify unique and one-of-a-kind entities
• Select several smaller objects, which provide more flexibility than a few large objects, and are easier to develop, validate and maintain.

To ensure a robust CIP design, examine the pros and cons of various boundary assignments and seek partners experienced in designing such applications. Where and how boundaries are defined not only influences an object’s reusability, but can also impact schedule and cost.CIP sources are typically self-contained process skids that deliver cleaning solutions based on requests from process units, such as tanks, fermenters, filter skids and chromatography skids. A few CIP skids often provide cleaning for an entire production facility.CIP skids respond to requests from process units to drain, rinse, clean, wash and perform final rinsing on “dirty” equipment and transfer lines. Cleaning solutions are commonly delivered through mix-proof, multiport (MP) valves. MP valves have a unique design. When a valve is closed, upper and lower valve cavities are separated and fluid passes straight through. When the valve is opened, the cavities are joined and fluid is routed to a different line based on pressure. Grouped together, MP valves make up a valve manifold (VM) that delivers cleaning solutions to different destinations.Design once, use oftenAn automation system with object-oriented features, such as unit- and module-classes, allows for designing, developing, testing, validating and documenting to occur one time per class. Once the initial object is successfully developed, it becomes the template for replication.This “design once, use often” approach creates time and cost savings during initial system engineering, and also produces an automation solution with module-to-module consistency that is easier and less expensive to maintain.Robust, class-based programming tools use a technique known as “inheritance” to combine module- and unit-class templates and variables into unique object instances. When non-class-based automation systems are used, it is possible to copy and edit a template module to create a new instance. This approach achieves some of the same benefits as class-based architecture, but requires greater discipline and an extra attention to detail to ensure each instance remains true to the original template.Inheriting templates and variablesAs Figure 2 (below) illustrates, software elements are developed and placed in the object’s library template. Device specific variables (parameters) such as tags, descriptions, on/off words and I/O channels are defined and assembled. Most automation system engineering tools can import device specific parameters from a variety of sources, including ODBC data, spreadsheets, or text files.Figure 2. Class-based programming uses templates and inheritance — Automation systems with robust, class-based probramming environments make use of standardized object templates and inheritance to develop, test, library and manage deployed objects. Users benefit because changes only need to be made in one place and inheritance handles updating the replicated objects.

When it is time to create the new instances, the engineering replication tool combines the software pieces from the object’s library template with the device specific parameters described above in order to make all of the object’s instances. For example, parameters for the instances are applied to the valve template to create the valve instances.Later, if a desirable feature, such as an interlock, needs to be added, inheritance permits making the addition to the library template and then replicating it to every instance using that unit object. Because of inheritance and automated replication tools, the field testing and validating of each object instance is significantly easier.A similar approach is used to create a CIP skid unit class template, and inheritance combines it with a variable list to develop instances of the CIP skids.From an object-oriented programming viewpoint, it is easy to understand how MP valves can be defined as a module class; each performs the same function. It is also easy to see how CIP skids can be grouped into their own unit class. Again, the equipment is nearly identical. Each executes similar phases (e.g., initialize, rinse, wash) while differences, such as those in concentration, temperature, time and flow rate for cleaning different process units, are handled by variables in the procedural model. What’s less clear is how object classes are able to accommodate more complex entities, such as CIP VMs.Defining the valve manifoldA common misconception about object-oriented programming is that it only works when objects are identical. While identical objects are the classic example, as long as the basic premise of an object remains the same, object-oriented programming concepts can be extended to accommodate non-identical objects, such as VMs.Robust class-based process automation systems that are based on the S88 physical and procedural models will include tools to help the user handle identical objects, such as the individual MP valves, as well as objects with nearly identical physical and/or procedural characteristics, such as VMs.Flexible production facilities are likely to contain complex product transfer paths resulting in complex CIP circuit requirements. VMs often have special considerations: there may be differences in the number of MP valves required, in how the many transfer paths are tracked for availability and operational status, and in the rules governing how and when concurrent paths are used may differ.To maximize the benefits available from object-oriented programming techniques, consider each and every difference in defining unit class boundaries. Depending on the degree of complexity, it may not be possible to create a single, all-inclusive, VM template. In such a case, it is still possible to create sub-modules that can be tested and assembled to form a VM library that supports customization while preserving most of the benefits of object-oriented programming.To create the best VM design:

• Think beyond each VM’s physical boundary
• Consider requirements one at a time
• Apply an iterative design process.

Thinking beyond each VM’s physical boundary helps identify and group CIP VMs that must work together. Although some CIP VMs are not physically linked, they must operate in a coordinated manner, and thus should be logically grouped together.Figure 3 (below) contains a 2 x 5 (VM-101) and 2 x 4 (VM-102) CIP VM matrix. Because cleaning solutions must pass through VM-101 to reach VM-102, the two manifolds must operate as though they are a 2 x 9 matrix.Figure 3. Group similar physical entities that operate as one.

Resource management, failure handlingOnce CIP VMs are grouped, the next step is to revisit each CIP VM grouping to identify its usage limitations and establish the rules that will govern using the resources. This is sometimes referred to as resource management.Managing resources requires a means of enforcing the number of users (operators and/or automation procedures) that can acquire and use the resource at one time. Often resources are capable of supporting multiple, simultaneous users, but in the case of CIP VMs, limiting the number of users to one at a time for the upper header and one at a time for the lower header avoids contaminating a product transfer or interrupting CIP operations.

SAMPLE EQUIPMENT STATES Dirty — Default/initial state. Completion of CIP will automatically transfer the state to “Clean.” Clean — Indicates CIP is complete. May start the “clean timer.” If the clean timer expires, the state changes to “Clean Expired.” Clean Expired — Indicates clean timer is expired. CIP must be repeated to return the state to “Clean.” In-Use — Indicates that a batch has started. If a “Phase Hold” occurs, the state transitions to “In-Use Hold.” Upon batch completion, the state transitions to “Ready for Transfer.”

Defining who, when, and how resources are acquired and released during normal processing activities is fairly straightforward. Evaluating the events and conditions that justify the release of a resource during abnormal processing activities (failure handling) often receives less consideration but is extremely important.Ensuring that failure handling is adequately developed and resource management is appropriately addressed can produce huge dividends by avoiding unnecessary product contamination or loss.After determining resource management requirements, reexamine each VM, this time to identify and address equipment states (see box at right). Equipment entities, such as vessels and CIP VMs, have operational conditions that must be met before specific processing activities may begin or continue. For example, a fermenter must be clean before it can be inoculated, or a CIP VM that has been acquired and used to transfer a product must be cleaned before it can be released to another user.The tracking of equipment or transfer lines (e.g., dirty, clean, in-use) is known as equipment state-tracking and it must work in conjunction with resource management. After required equipment states are defined, rules must be established that identify the boundaries for equipment states. The rules help provide the consistency necessary to minimize the number and complexity of the software sub-modules.State-tracking rules appropriate for CIP VMs might include:

• Inlet headers (sources) are to be tracked by upstream (provider) equipment
• Destinations are to be tracked by downstream (receiver) equipment
• CIP VMs will track everything in between the source and destination.

Once the design iterations for defining CIP VM control and management requirements and rules are complete, it is possible to organize the software to achieve the most robust CIP VM implementation.Implementing the VMsAs noted earlier, CIP VMs can be complex. Thus, it is likely that each design iteration will produce multiple requirements and rules for a specific control and resource management.The challenge now becomes organizing those requirements into reusable software modules. For example, two or more completely different resource management philosophies may have been identified. Rather than creating a single, all inclusive resource management module of “spaghetti code,” create several sub-modules that can be mixed and matched to accomplish the resource management requirements in the simplest of ways.Continue to examine each set of requirements and identify the modules and sub-modules for each. This will produce a library of well-defined sub-modules that can be tested, secured against unauthorized changes, and saved into the CIP VM development library.When a specific CIP VM needs to be created, it’s assembled from the “approved for use” modules and sub-modules. The result is CIP VM instances with a consistent look and feel, but customized to accommodate unique procedural requirements.Using class-based programming simplifies design, testing and validation of reusable CIP modules. However, when boundaries are properly identified, the ability of class-based modular software to develop and replicate simple to complex equipment entities can be extended across the entire manufacturing process, resulting in reduced cost and shortened schedules.In the end, the more class-based modular software that can be developed, the greater the consistency object replication is able to provide. This leads to easier maintenance of the automation system and more consistent production of high quality products.About the AuthorsChristie Deitz and Dan Lorenzo are senior principal engineers with Emerson Process Management’s Life Sciences Industry Center. Christie has 16 years of experience in pharmaceutical automation. She has a BSChE from Texas A&M University and an MSChE from the University of Texas. Dan has 23 years of experience automating pharmaceutical, pulp and paper, and oil and gas processes. He holds a BSEE from the University of Arkansas.Sean Stephan is a senior automation engineer with Biogen Idec. He has 13 years of experience in automation of biopharmaceutical and other processes. He holds a California Professional Engineering license and a BSChE from the University of California, Davis.The authors may be reached at [email protected], [email protected] and [email protected].