2000eu replacement batch control system for a multipurpose ... · control system architecture –...

© 2000-2001 World Batch Forum. All rights reserved.

Presented at the World Batch Forum

European Conference Brussels, Belgium

October 2000

107 S. Southgate Drive Chandler, Arizona 85226-3222

480-893-8803 Fax 480-893-7775

E-mail: [email protected] www.wbf.org

Replacement Batch Control System for a Multipurpose Contract

Manufacturing Plant Eur. Ing. C. M. Marklew C.Eng. B.Sc. FinstMC, MIEE Principle Engineer Aston Dane plc Park Lane Great Alne, Warwickshire, United Kingdom, B49 6HS Tel: +44 1789 488184 Fax: +44 1789 488186 E-mail: [email protected]

Co-author Mr R McGregor Control Systems Manager Chirex (Annan) Ltd Three Trees Rd Newbie, Annan, Dumfriesshire DG12 5QH Tel: +44 1461 203661 E-mail: [email protected]

KEY WORDS

Multi-product, Multi-purpose, pharmaceuticals, GMP, S88.01, GAMP 3, retrofit implementation, software

ABSTRACT Successful Contract Pharmaceutical Manufacturing in a GMP regulated environment is heavily dependent on the flexibility and utilisation of the available processing plant and its guaranteed performance. However, changing plant configuration and revalidation is time consuming and therefore costly.

This paper presents a case study of the implementation of an S88.01 based control system, as part of a strategy to change an existing process building with single product manufacturing capability, to a multi-purpose plant and contrasts it with an earlier retrofit implementation to a similar plant for multi-product use.

The paper reviews some important considerations in the equipment model design including the design approach for the control system architecture and methodologies employed for software coding of generic phases, which have been found to yield real economic benefits and ensure the achievement of the required plant flexibility. It also reviews the benefits to the design and validation process from following a structured 'GAMP3' approach.


Some of the measurable economic benefits achieved will be shown to include reduced project implementation time, life cycle cost savings through reduced manpower effort during the engineering and validation stages and production capacity increase.

INTRODUCTION Chirex, a leading contract manufacturer of active pharmaceutical ingredients and final stage intermediates in its cGMP facility at Annan, first awarded a contract for the upgrade of the control system of two of its process buildings in November 1997. The requirement was to replace an existing Taylor 1010 based control system that was configured to support single product manufacture.

The business objectives of this project were; to empower the Annan site as a multi-product facility, return the plant to existing product manufacture with a secure and reliable process control system, provide ‘on-plant’ control rather than control room based and provide the ability to develop new recipes quickly and easily.

In consideration of the Operational requirements during the requirements analysis phase, Chirex decided to use an S88 philosophy for this project in order to achieve common generic plant and control software. It was thought this would enable the maximum re-use of common phases and so reduce testing and commissioning times and ease software maintenance. In addition, it was considered common generic plant and software would greatly benefit validation as modules may be tested once and repeated many times.

In September 1999 Chirex awarded a further contract to upgrade a third single product manufacturing facility to a multi-purpose facility. By engaging the system supplier earlier in the design lifecycle, ie. at the requirement definition stage it enabled the companies to carefully consider the lessons learned from the first project and develop an improved approach and incorporating significant technological advancements.

Both projects were implemented in the requested time scale and met the required objectives and have in addition realised several economic benefits. These are a reduction in operating costs, reduced costs of product introduction and reduction in project overall time-scale.

We will review these benefits obtained and the means by which they were achieved and highlight some of the lessons learnt over the two projects of moving from a single product manufacturing plant to a multi-product facility.


PROJECT OVERVIEW

Both projects involved the control of a process system designed to manufacture active pharmaceutical ingredients (API) or final stage intermediates. Each process building contained several streams each basically consisting of one or more headers, a batch up vessel, one or more reactors, filtration / separation and drying equipment and several associated receivers. In addition each stream had plant services including vacuum and scrubbers and connections to the bulk storage areas for raw materials and solvents. A simplified process flow diagram is shown in figure 1.

Figure 1. Simplified Process Stream

Control System Architecture – Multi-product Plant

The first project was to replace an existing control system for two process buildings each containing two streams and a solvent recovery area comprising of four stills. The process buildings contained a total of 12 reactors plus Rosenmund and Funda filters and Buss dryers. Its new purpose was intended for use as a multi-product plant and so the design included the modifications to the existing plant configuration, each process area being considered as a single cell.

A key objective of the project was to provide on-plant control and to this end a combined SCADA and batch control system was implemented with five local operator panels (LOP), one for each stream and


one for solvent recovery. These on-plant stations provided a high resolution (XGA) graphical user interface software that was configured to provide both fully automatic batch controls based on the stored recipes and direct operator control of valves and pumps via the SCADA system. To facilitate a full SCADA interface in the designated Zone 1 hazardous plant area a pressurised enclosure was employed.

A typical operator station of the pressurised enclosure (EEx p) type on the left and the later used intrinsically safe (EEx i) type on the right are shown in figure 2.

Figure 2. Typical Operator Stations

The process control was implemented using ten PLC controllers connected via Ethernet to each LOP and engineers stations for SCADA and the batch servers. The system architecture included a batch server and backup server for each process building with a common historian database machine, and NT domain controller.

Adequate fault tolerance was ensured by the use of dual redundant fibre optic media for the Ethernet network, the dual batch servers in a primary / secondary warm standby configuration and the use of independent SCADA workstations from which either stream within a process cell could be operated.

Control System Architecture – Multi-purpose

The second project, also to replace an existing control system, was for a single process building containing equipment originally configured for two manufacturing processes. In this case because no production configuration had been defined for its new multi-purpose role, the approach was to consider the whole building a single process cell and base the control system design on a purely generic S88


equipment model. Again on-plant control was a key objective and initially, five LOPs were located at strategic points around the plant.

In this project the control was implemented with a network of ten process controllers interconnected for control purposes by a high speed deterministic network, ControlNetTM and for communication with the SCADA system and batch controllers by an Ethernet network. The system architecture was based on a client server system for the SCADA with two active display servers in a primary / secondary configuration , a single batch server, a data historian based on Microsoft SQL server and an NT domain controller. Each LOP was supported by its own PC running thick client software and a batch view client application. The local operator panels were an intrinsically safe display system having XGA display capability. The fault tolerance / reliability of this system was based on the use of high availability machines for all server applications and the primary / secondary configuration of the SCADA servers.

The operator control facilities were the same as before except that the batch control functionality was integrated into SCADA system by means of custom written ActiveX controls which provided the operator with current batch status information for each unit.

The ActiveX control shown was provided on each SCADA page and showed the current batch name, and its running status and the buttons provided access to the SFC view and operator prompts for that unit. The batch list, prompt list and SFC views were also available via the batch view application which also incorporated the controls for the batch application.


Figure 3. Batch Overview Display showing prompts list.

The batch data was archived incrementally to an MS SQL database. Reports could then be requested for any batch including in-progress batches. The batch event journals were broken down by SQL scripts into a set of tables which could be queried for reporting purposes. Two types of batch report could be produced both having the structure :

Unit Procedure

-Operation

-Phase

-Parameters

-Reports


The generic form of batch report includes all parameters and reports and the custom, recipe specific, form of the report could be produced to give the conventional target / actual / deviation format for ingredient additions.

Data security was ensured by the data archiving, backup and recovery procedures for the SQL database.

Project Comparisons

The table in figure 4 illustrates some of the differences between the two implementations.

Multi-product project

Multi-purpose plant project

Number of Units 72 45

No of Generic Phases 70 19

No of phase instances 550 405

Total I/O count 2250 1550

Figure 4. Comparison Table

The second (multi-purpose) project was some two thirds of the size of the previous project, the number of generic phases used was about one third. Although this can partly be explained by having less special equipment, for example in the solvent recovery area, with associated phases, this difference was largely brought about by a difference in approach to the equipment model design that is discussed later.

It was possible to take advantage of several technological developments when the second project was implemented. One example that yielded a real benefit in project engineering cost was the change in Control Processor used. The difference in controller capability and the use of IEC 1131 language for the programming each controller to be loaded with identical generic phase logic, which by means of parameter passed function calls, operated on each phase instance.

In the earlier implementation, the code for each generic phase needed to be replicated and customised if necessary for each instance with a disadvantage in engineering effort and implication in increased software maintenance cost. Whereas, in the second project, having access to later model process controllers, providing more powerful features, including the ability for symbolic based tag naming conventions and the use of data structures, allowed the capability for parameter passed phases to be designed. This in addition to the parameter passed device drivers, reduced the memory requirements per controller very significantly and improved coding and testing operations.

Software developments enabled a client server approach to be adopted for the SCADA system on second project thus enabling a single SCADA project and database to be used with a benefit in maintenance cost and improvements in communications performance.

The use of intrinsically safe LOP’s connected to safe area PC’s greatly simplified software and hardware maintenance compared to the EEx ‘p’ pressurised cabinets housing field mounted PCs used on the first project.


Equipment and Procedural Model Design

The approach to the equipment model and procedural model design differed significantly between the two projects. On the first (multi-product) project, a product-centric approach was taken because the original design brief required the return of the plant to the manufacture of its single product while being given the capability of multi-product use. This meant that the both the plant design and control system design was based around the requirements for producing these specific products.

The equipment model was developed around the existing plant configuration and while every effort was made to define reusable equipment modules and phases, the URS and subsequent design was heavily influenced by the specific equipment configuration for existing plant and the DCS control sequences previously implemented. The result was that phases were based around the functionality required for the process.

For the second (multi-purpose) project, there were initially no specific products identified. This enabled an equipment–centric design approach to be adopted that is, the phases could be based around agreed generic equipment modules. As a direct result of having a more generic plant design there was a significant reduction in the number of generic phases, with the equipment modules having less shared equipment. The design of the generic phase software was simplified resulting in generally smaller modules although a facility for inter-phase communication had to be implemented so as to synchronise them in the operation. The higher level functionality was then implemented in the various unit operations. These operations tend to become more complex by combining phases to produce the required function, but this is accomplished entirely within the batch control software. Consequently, new functions can be created by the recipe designer without requiring new phases to be developed which require additional / modified PLC software.

In the early stages of the first project, the design approach to the solvent storage area was the subject of much discussion. Each solvent storage tank, like a process unit, had several equipment modules which performed various duties, however, the material contained was not batch specific. It would be possible to treat them as units in the batch control software by providing them with “transfer in” and “transfer out” phases and because each tank could service only one batch at a time, provide arbitration of batch ownership in the usual way. However, it was decided in both projects to treat this equipment as a common resource and have the phases transferring to or from the tanks, acquire them for the duration of the transfer and release them when done. This facility was implemented outside of the batch controllers. This resulted in greater flexibility by having the arbitration carried out by a standalone PLC independent of all batch servers so as to make the area accessible from any area of the plant.

A key to the success of the more rigorous S88 design philosophy used on the second project was the early adoption by the process engineers and production management of the S88 concept. At the initial stage of the project an S88 analysis of the plant was carried out and a set of generic equipment modules agreed. Any additional equipment required for a particular process would then be added in accordance with this agreed physical model. This approach helped ensure that the software design for the phases could remain generic, based around the agreed equipment modules, independent of any modifications to the process equipment. Thus providing clear benefits to project time scales and the simplification of control system modifications resulting from any changes to the installed equipment.


Design Methodology

The GAMP (Good Automated Manufacturing Practice) Forum guide was used as the framework to meet GMP requirements of these projects. These projects benefited from the implementation of the good practice examples in the guide for documentation, engineering practice and testing practice.

This structured approach fitted very well with the S88 concept applied to the control software where generic modules of code were written for device drivers and phases and which were tested as generic modules. All controllers were loaded with this code, along with unit specific code, and tested as an integrated system. This greatly benefited the testing and validation effort required.

The documentation requirements when working to these guidelines are also similar to those supporting software quality management standard ISO9001-3 (TickIT). This framework enabled the preparation of these documents to be planned and served as a useful index to the documentation system as the project progressed. Figure 5 shows a simplified document structure diagram.

To correspond to the GAMP “V” lifecycle model approach, the documentation structure consisted of the Functional Design Specification which was created with a set of appendices that contained the

Figure 5 – document structure


functional design specifications for each of the generic modules. In particular, each of the generic phase specifications with its associated equipment model were brought out at this level as these documents formed the basis of the S88 equipment model for the system. Below the FDS lay the set of design specifications for the network, SCADA, PLC etc. Parallel to the FDS is the System Acceptance Test Specification below which is an Integration or Module Test specification that corresponds to each design specification.

ECONOMIC BENEFITS As discussed in the preceding sections, several improvements in the design approach and available technology were proven to be significant to the project design and implementation time scales. For example the second project was successfully completed six months from capital sanction. Other major economic benefits achieved by the user for the second project include:-

Cost reduction of new product introduction

A significant saving in the time to design, configure and validate a new recipe was found possible having experienced the first project. Also installation and testing of a new recipe configuration was no longer the critical path in product changeover. Assuming no plant equipment changes, the more rigorous S88 approach applied in the second project has reduced the time to create a typical recipe by a further 50% largely due to the increased use of standard unit operations and improved awareness of the user.

Additional cost savings have been made by the ability of in-house process engineers and chemists to define control recipes without the need to understand details of the software programming. The introductions of new products and processes now have a minimal impact on the control system software and the need for its reconfiguration. This saves in both engineering cost and the consequential validation effort.

With the original DCS a new product requiring new sequences could take up to 6 months to introduce and even small modifications could take 6 weeks to implement and test. It is now possible for a new product recipe to be installed and validated within 3 weeks although the actual times depend very much on process / recipe complexity.

The new batch control systems enable recipes to be created and simulated off-line. These new recipes can then be run with the process connected device (PLC or process controller) having simulation logic replacing the real I/O. This offline testing of recipes offers a minimised risk of failure and therefore reduces start-up costs through reduced solvent simulations and failed batches etc.

Repeatable yield / product quality

The implementation of the new control system resulted in improvements in repeatability of manufacturing. Currently the right first time performance, (defined as that for each batch produced, all aspects of good manufacturing practice have been satisfied and no deviations observed with regard to


materials, equipment, process control, testing and release) is greater than 99%. The system now requires minimal manual intervention with all critical processing activities being handled automatically from data from the control recipe, resulting in more consistent product quality.

Once the water and simulation trials are complete the system is then completely repeatable with any drift in performance coming only from equipment failures. The system also provides tighter control for example the batch temperature can now be controlled to within +/- 0.1 deg C compared to +/- 5 deg C with the previous control system.

Reduced training cost

Training for engineers and operators on new products is now reduced through the use of common software approach and user interfaces. It is now only necessary to train the operators in process awareness whereas with the previous systems, both the controlling software program and the process information displayed changed with each new product. Now the unit displays remain the same and the new recipes are made up from familiar phases and their associated equipment modules and unit operations.

Improved Process Visibility

Visibility of the process conditions and recipe stage enables the operators to understand and therefore manage the process more effectively.

Reduction in operating costs

The meeting of the objective of on-plant control resulted in 1998 in a specific manpower saving of £150K per year by reducing the number of plant technicians from 5 to 0.

SUMMARY

The implementation of these projects met the business objectives of Chirex and realised the expected benefits from an S88 design approach. The systems have been well received by the operators and plant designers alike. The operators are comfortable with knowing what functions a phase will carry out and the plant it will use and plant designers now use common models for building new plant.

The most important benefits have come through the comprehensive and consistent implementation of S88 to the equipment model and procedural models. Using this model approach has allowed a clearer mutual understanding and common language to be developed between the process and software developers.


Of the lessons learnt, the most important was to gain the commitment of all interested parties to the S88 concept from the outset of a project and to ensure that this is maintained throughout the project lifecycle.

The success of these two projects has provided the necessary confidence for Chirex to commit to further improvements projects to upgrade other plants within the organisation.

2000eu replacement batch control system for a multipurpose ... · control system architecture –...

Documents