Extend Template Libraries Activities Library

The Standards Version 2 resulted in a set of six template blocks dedicated to different activities: Main Primary, Main Secondary, Makeup up, Activity, Sub-Activity with Failure, Sub-Sub-Activity Run. As stated earlier these offered little existing structure and had to be greatly altered in order to meet the requirements of the elements being modelled. As such, the activity block templates have been combined and reclassified and are now as follows: Main activity with cycles, Main activity without cycles, Sub-Activity with failure and Sub-Activity without failure. The rationale behind this new classification is that the blocks required for cycling activities such as chromatography can be incorporated into the main template as default, thus minimising the amount of customisation needed to build these features in, as was done during the mAb case study.

In addition to this library is the CIP/Rinse w/Flow block with can be used to model CIP or rinse only when there is flow from a utilities source, such as the template Utilities block. A separate CIP/Rinse without flow has not been added to the library as one of the existing main activity template structures could be used for that.

Labour Library

There are essentially two ways to model labour. The first is where labour requests are made and processed internal to the process stream. This method is used when the cycle time of the activity making the labour request equals the amount of time that the labour is required. In other words, the labour will be present for the duration of

the activity. Thus the labour is batched with the item before entering the sub-activity or group of sub-activities and then released at the end. This means that all labour blocks are placed internal to the model and are subsequently greater in number.

The second method is used where the duration for which labour is required does not equal the cycle time of the activity. The most common example of this is fermentation, where a growth period may last several weeks however labour will only be needed for a few hours a day. Since labour must be pulled and released during the activity, the processing of the request is externalised. This method uses far fewer executing blocks however, since the labour requests are actual generated items which are thrown to the externalised processing block, the actual number of blocks is actually similar to the first method. Furthermore, since the labour request is processed in a different location to the actual request, debugging is potentially more complex. However, this has been deemed as the best solution to the dilemma of having a labour requirement duration which is not equal to the activity cycle time.

Consequently, there are five labour template blocks: 1) Labour pull (Hrs=CT), 2) Labour release (Hrs = CT), 3) LabourRequest (Hrs<>CT), 4) LabourRequestProcess (Hrs<>CT), and 5) Shift check. The latter block can be used when there is a constraint in place which states that an sub-activity or group of sub-activities can only be started if there is enough time remaining of the current shift.

Resource Library

This library contains three blocks, two of which are based on flow. The first is the Utilities block which is used to model the supply of utilities to the system. The Model Template itself contains this block as default, where it has been externalised placed in the Buffers/Utilities external storage block. However, as the block only accommodates for three utilities or resources, the option of additional ones has been given by placing this block in the library. It works using a very simple concept, linking to the utilities table in the database to retrieve data such as maximum capacity of the supply vessel and fill factor. A sensor is used to control the flow of the utility from supply to facility storage vessel before demand from the system (in the shape of an item entering a pull flow block and requesting flow) pulls the resource. The routing block uses a demand priority system and can flow to more than one place in the system at any one time, allowing the set user parameters and the self scheduling of the model to determine the overall flow in and out of the facility

storage vessel. This allows for a generation rate to be determined based on how fast it has been necessary to supply the facility with the utility, an output parameter which is captured and sent to the output excel file.

The second flow block is the Receive Flow and can be used to either link to the Utilities block, for example to receive steam when modelling SIP, or can be used with any other flow resource, capturing its user defined parameters such as flowrate and fill quantity from the database. One particularly useful instance for this block is where one resource such as an acid used in equipment preparation is made up in one batch however that batch is used in more than one place, i.e. for example three equipment need it at different stages of the process. Realistically, the makeup tank or storage tank is not freed until the entire acid resource has been used by the process.

Using items to simulate this hold time can become complex with the use of gates, sensor blocks and database tracking. However using flow allows for the simulation of a tank still holding a certain quantity of resource and only when it becomes empty is the tank released. Therefore the use of flow in this instance reduces the visible, and the hidden complexity of the model and also makes it far more intuitive to the user as they can track the status of resource flow far more easily.

The third block in this library is the Receive Resource block and it is a very basic item receive block which catches a resource and batches it with the primary item in this case, which would be the equipment or batch. This block can be used wherever the rationale applied to the use of the Resource Flow block does not apply, i.e. the resource either does not have associated flow or the modelling of flow is not necessary as the timing of resource allocation is not an issue and can be assumed to be an instance.

Logic Library

This is the most comprehensive of the libraries and contains many of the important function blocks which allow many modelling elements to be modelled in a far quicker and intuitive way. The first block is the most basic one and is the Timer block. Although already placed by default within the Main Activity blocks in the template library it is also present here and can be used to capture any activity time.

There are six time elements which can be captured, these are the Pre-Run start and finish, Run start and finish and the Post-Run start and finish. The data can then sent to the output excel file for cycle time analysis.

The second block is the Gate block which is linked to the database and can be used anywhere in the model to control item flow. It simply needs to be linked to the appropriate data tracking table to allow it to know when an item can be allowed through. The conditions surrounding this event are entirely user defined and can be for example, when a batch has finished processing and the next one can be allowed through, or the next campaign must be delayed in entering the system until all turnaround procedures have been completed.

The third block is the Lookahead which uses the before mentioned Calcs for Lookahead Excel calculations sheet to automate the triggering of any activity based on future events. For example, if a buffer is needed at a certain time x, within the process, and it is necessary to follow a ‘just-in-time’ procedure then that buffer must be prepared based on the current time, the cycle time of all activities between now and x, and the preparation time for the buffer.

The fourth block is the CIP Check which can be used where it is necessary to model CIP expiry based on ‘dirty’ equipment or limited clean hold time. The block links to the database for user defined parameters such as expiry time and can be used in conjunction with any CIP modelling method, whether externalised or internal, simple or complex.

The fifth block is the Mass Balance block and can be used in models where the scope requires tracking product yield throughout the process. Linked to equipment information defined by the user, it calculates the mass of product throughput based on activity yield and product stability. This block can be placed after each relevant activity enabling the tracking of product throughput across the process without further modeller input.

The final block is the Area Shutdown/Turnaround block which is actually a rather complex structure and can be used for either area shutdown, turnaround or both, where turnaround is the procedures necessary following a product changeover in a multi-product scenario. The block contains many useful functionalities, for example, it can decide whether to synchronise shutdown or turnaround of different process areas or allow a rolling effect (where the procedures begin as soon as the area is ready) or whether to synchronise shutdown and turnaround if they are due to occur within a user defined window, thus reducing area shutdown. This functionality features heavily in Chapter 6 and will therefore be discussed further.

3.6 Conclusion

The standard framework developed in this thesis provides the methodology and modelling tools to allow modellers to construct models which satisfy the six requirement specifications:

- Intuitive to user - Relevant

- Ease of data input/output - Short run time

- Maximised reusability and sustainability - Minimised development time

During the data gathering stages, the framework acts as a guide to improve the efficiency of relevant data retrieval and validation, reducing the construction time by ensuring that a realistic and accurate understanding of the system is first achieved.

The standard templates developed as part of the framework have been designed to speed up the model development process by providing the fundamental building blocks for any biopharmaceutical manufacturing capacity management model. These templates have been designed with a degree of customisation which will allow different process elements to be realistically and more easily captured, but with sufficient generality built in to allow them to be used across different system models.

The development of the standard framework has been an evolutionary process using different biotechnology case studies as a means of evaluating the ability of the standard in aiding the construction of models which meet the proposed requirement specifications. Furthermore, these case studies have been used for analyses such as debottlenecking, dealing with uncertainty and cost analysis, using techniques such as Monte Carlo simulations to test the ability of the standard to create models capable of answering more complex questions. These case studies are described in Chapters 4, 5 and 6.

100

4 C ^HAPTER 4

Application of Standard Framework