Case Study: Novel Approach Enhances Control System Upgrade

Measures to mock-up wiring and limit project scope as well as operational improvements provided significant benefits.

By Ryan M. Iannucci, Eli Lilly and Co.

Share Print Related RSS
Page 1 of 3 « Prev 1 | 2 | 3 View on one page
One of our active pharmaceutical ingredient (API) plants in Indianapolis relied on an obsolete Measurex distributed control system (DCS). We replaced it with a DeltaV DCS in late 2007. In doing the upgrade, we used some fairly unusual techniques to minimize shutdown duration and total cost.

The fixed-product batch facility has 13,400 input/output (I/O) points divided into seven control rooms. It was decided to convert a single control room first. Upgrading just a small portion of the plant kept the size of the project team small. This allowed project managers to select personnel who were very knowledgeable both about the control system and the manufacturing process.

The control room chosen for the upgrade contained 1,450 I/O points and governed plant purified water distribution, buffer make-up and distribution, column chromatography, crystallization and a clean-in-place system. The majority of these unit operations, while already sequenced, weren’t linked to each other within the Measurex DCS as part of a larger recipe. Besides lower-level sequencing, the existing automation included automated materials reporting to an enterprise resource planning system.

The Upgrade Process
In addition to the normal scope definition process, project managers quickly developed a scope-limiting tool titled the “Just Say No List.” It consisted of all the items that plant management agreed could jeopardize an on-time conversion. The list included items like implementing an asset management or manufacturing execution system and adding new instruments and remote workstations. Any request for a change in scope went through a formal process; this required development of a business case justifying the proposed change in scope and project managers’ approval. Some changes got the go-ahead— for instance, moving control of a piece of equipment from a programmable logic controller to the DeltaV DCS. With the scope of the project effectively limited, managers formed three lower-level project teams, for software, hardware, and commissioning and qualification (C&Q). Figure 1 shows the rough project timeline.

Software. The software team comprised two process control engineers from Lilly’s central corporate engineering tech center who were familiar with DeltaV, one plant process control engineer who knew the process and equipment being converted, and several contract system integrators. All assigned internal resources were dedicated to the project and were very experienced with either the existing Measurex DCS and its current operation or the functionality of the new DeltaV DCS. The selected system integrators previously had worked either in the plant being converted or on other corporate DCS projects. The software team prototyped the proposed design; the aim was to be consistent with ISA S88.01 [1] and include all documentation outlined by GAMP [2]. The prototype helped minimize rework by allowing operations, engineering, quality control and the software team to agree on an initial design before large amounts of work were expended.

This initial prototype wasn’t a 1:1 conversion of the existing Measurex DCS software. While it was important to retain the knowledge built into the system over the years, it was equally important not to squander opportunities for improvement afforded by implementing a modern DCS. To avoid introducing unintended risks during startup, only improvements that wouldn’t affect the quality of the API were made. For example, when automating a pH adjustment, the team designed an algorithm that mimicked current operator technique. We used many sources, not just the existing Measurex DCS code, to generate the first pass of the requirements and design for the new DeltaV DCS. Other inputs included existing software requirements and design documentation, process historian data, standard operating procedures (SOP) and manufacturing tickets. The process team, consisting of representatives from operations, process engineering and tech service, as well as a dedicated senior operator, then reviewed this documentation in great detail. Once the process team approved the documentation, coding began.

Page 1 of 3 « Prev 1 | 2 | 3 View on one page
Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments