EXPLICIT MANAGEMENT OF INTERMEDIATE STORAGE
Chemical and pharmaceutical processes are more difficult to schedule than processes that make discrete parts. Much of this
difficulty arises from the challenge of storing intermediate materials. From a material balance standpoint, one can consider
a schedule feasible so long as inventories of materials do not go negative. The absence of negative inventories ensures that
material is produced before it is consumed. In a plant that makes discrete parts (e.g., engine blocks), this level of modeling
may be sufficient. Many parts often can be stacked on pallets while awaiting the next stage of processing. The pallets can
be set on the factory floor or put in a warehouse; all that is required is floor space. Therefore, in discrete parts manufacturing,
the management of intermediate storage often is ignored.
Storage Constraints in Process Industries
Process industries, however, are not so simple. Physics dictates that intermediate inventory must actually physically reside
somewhere. If you are dealing with liquids or unpackaged solids, you don't have feasible schedules until you know where every
pound of material is stored at every time over the schedule horizon. For example, what do you do with a batch of bioreactor
product when the downstream equipment is still busy? Real-world constraints dictate that unless you have a tank, empty and
cleaned for this material, it must remain in the reactor, where its presence will block the initiation of subsequent batches.
A scheduling system that does not account for this delay is virtually useless in the process industry. In part 1, we described
many subtle and nonintuitive interactions between successive batches.1 This inter-batch coupling plays a dominant role in determining the operating behavior and capacity of the process. Moreover,
this coupling is a direct result of the rigorous enforcement of intermediate storage constraints. Thus, a scheduling solver
that does not handle intermediate storage properly cannot accurately predict or describe process behavior.
As an example, consider a simple two-stage process making two products, P1 and P2. In the first stage, a reactor makes an
intermediate material and in the second stage, the material is packaged into final product. There is a single reactor, but
two packaging lines, with products P1 and P2 packaged on Line 1 and Line 2, respectively. No storage tanks are available for
the reactor product, so this material must remain in the reactor until the packaging line consumes the entire batch. Only
when the reactor has emptied all of one batch may another batch be started. Figure 1 illustrates a schedule for one batch
of each product, but ignores the limitations of intermediate storage. Note that the reactor begins a second task immediately
after finishing the first task. This schedule satisfies material balance constraints; no material inventories are negative,
all intermediate materials are produced before they are consumed. Yet, the schedule is physically infeasible. Where does the
P1 intermediate reside between 1 AM when it is produced and 4 AM when the last of this batch is fed to Line 1? The only vessel
available to store this material is the reactor, but this schedule shows the reactor starting a second task at 1 AM. What
is the reactor doing between 1 and 4 AM? Is it running the second batch or storing the material from the first batch? Physically,
the reactor cannot do both. Furthermore, if the second reactor batch must be delayed, where does the material come from to
feed the packing tasks on Line 2? These tasks are scheduled to begin at 2 AM, but as we will see when we examine a rigorous
schedule below, the task that makes the material to feed these packing tasks will not even be started until 4 AM.
When we enforce the storage constraints, we get the schedule shown in Figure 2. Here, the initiation of the second reactor
batch is delayed until the entire contents of the first batch are processed by the packing line. For both reactor batches,
the reactor is occupied as a storage vessel until downstream equipment can consume its product. This schedule is physically
feasible because we account for every pound of material, in both amount and location, at all times over the scheduling horizon.
Note the effect of rigorous modeling on plant capacity. In Figure 1, production for both demands is completed in only 5 h.
Figure 2 shows the time required to produce these products in the real world is 8 h. Even in this trivial example, failing
to account for intermediate storage constraints results in a schedule that is physically meaningless and that seriously overestimates
One natural question that arises is: Why not just place upper limits on the amount of inventory that may be held for each
material? It is tempting to believe that this relatively simple treatment would suffice in the real world, but it will not.
The fault with this approach lies in the assumption that storage capacity for a particular material is independent of the
amount of storage used for other materials. In most cases, this is an incorrect assumption.
Many processes have dozens of intermediate materials that are storable in multiple tanks. What then is the maximum allowable
inventory for a material? Is it the sum of the capacities of all tanks that can store that material? This approach can lead
to infeasible schedules because even a pound of material A stored in a tank renders that tank unavailable for storage of material
B. In effect, introducing material A into a tank reduces the available storage capacity for all other materials that the tank
could hold. Thus, if you have 10 intermediates storable in six tanks, then certainly no more than six of those intermediates
may have positive inventory at any time over the scheduling horizon. This interaction is captured by the rigorous mathematical
programming formulation described here (see eq 3). Simplistic methods such as spreadsheet analysis or scheduling algorithms
that do not explicitly track material storage will ignore these physical constraints and hence produce schedules that are
not executable in the real world.