Topic 9.2.1: Instances

  • Instances
    • Instances are one of the most powerful and flexible concepts of InBatch.
    • Instances allow the recipe's author to identify process equipment by assigning it a name.
    • When a recipe uses at most one unit from each process class and at most one connection from each transfer, the issue with instances is largely avoided.
    • This is the simple case. When a recipe uses several pieces of equipment from the same class, this may cause confusion.
    • The following explanation will illustrate how and why instances are used and why instances are such an important tool in a flexible batch management system.
  • Example 1
    • Imagine a group of balls on the floor of a room. The balls are all different shapes, sizes and colors.
    • I ask you to "Pick up a ball." You pick up a ball. Now I ask you to "Kick a ball."
    • Would you kick the same ball you just picked up? Probably not.
    • What if instead, after you picked up a ball, I had asked you to "Kick the ball"? Now would you kick the ball you picked up? . . . Definitely! What a difference that one little word makes.
    • You see, when I say "a ball", I'm referring to any member of the class "ball". ("ball" is a class name.) When I say "the ball", I'm referring to a specific member of that class - an Instance of that class. ("ball" is an instance name. )
    • The implication is that I'm referring to the particular ball that you are holding. In my first request, "Pick up a ball", can be restated as: "Select any one member of the class ball. Pick up that particular ball, and henceforth, we shall refer to that particular ball as (the) ball. " When you picked up the ball, you automatically assigned an instance name, "ball" to it!
    • InBatch does very much the same thing. In the Equipment Requirements portion of the recipe, the recipe writer specifies what classes of equipment are needed to execute the recipe procedure.
    • If only one of a particular class is required, InBatch assigns a default instance name to it that is the same as the class name.
    • For example, if you have a process class called "Mixer" in your model, InBatch will assign an instance name to the particular member of the class "Mixer" once it is selected as the recipe executes.
    • The instance name InBatch uses by default is "Mixer", meaning the "Mixer" that was selected. (Just like the 'ball' meant the ball that you picked up.)
    • Instance names are important to InBatch recipes because InBatch recipes are equipment independent.
    • The recipe's author does not know what equipment will be selected when the recipe executes, but he or she may refer to that equipment with an instance name throughout their procedure and there will be no confusion.
    • An instance name is assigned to a particular unit or connection upon selection during recipe execution.
    • The instance name continues to refer to the same unit or connection as long as that unit or connection remains allocated.
    • This is particularly important when using multiple instance names or using the same instance name multiple times within a procedure.
  • Example 2
    • To illustrate this point, let's go back to our room full of balls:
      1. Pick up a ball.
      2. Kick the ball.
      3. Pick up a ball.
      4. Kick the ball.
    • In steps 1 and 3, will you pick up the same ball? Maybe, or maybe not. In this instance, we will assume that you picked up different balls in steps 1 and 3.
    • As we have seen in the previous example, the ball you kick in step 2 is obviously the same ball you picked up in step 1.
    • But, what about the ball you kick in step 4? Common sense says it's the same ball you picked up in step 3.
    • Why is it not the ball you kicked in step 2? After all, both steps refer to the same instance name (the) "ball".
    • What happens between steps 2 and 4 to make "the ball" refer to a different ball?
    • The answer is step 3 of course. The implication is that we re-assign the instance name (the) "ball" to a different ball.
    • We release the ball we had used in the previous steps. The same instance name ( at different times ) refers to two different balls.
    • InBatch can also use the same instance name for two or more different units or connections in a class, as long as the first unit or connection is released before trying to re-assign the instance name.
    • If a recipe tries to assign the same instance name to two or more different units or connections in the same class at the same time, an error occurs.
    • This most often happens when trying to add two or more bulk ingredients to the same unit at the same time.
    • InBatch can do this of course, but not with the same instance name for simultaneous transfers. Simultaneous transfers must be done on different transfer instances with different instance names.
  • Example 3
    • When using multiple instances of the same class, and at the same time, multiple instances must be used. This applies for units and connections.
    • InBatch handles this situation by allowing the recipe's author to create as many instances of each class he or she needs and assign names to each.
    • Just like in our room of balls, if you picked up two balls and did something different with each, you might refer to them as "the first ball" and "the second ball" or "Ball #1" and "Ball #2".
    • So it is with InBatch instance names.
    • Suppose you have a reactor vessel and two bulk ingredients are added to it from different silos.
    • If the two silos are in the process class "BulkSilo", we need 2 BulkSilo's for our recipe.
    • So we assign instance names "Bulk1" and "Bulk2" in the process class "BulkSilo". If we transfer material from Bulk1 and Bulk2 simultaneously, then we will also need two transfer instances.
    • Suppose our reactor vessel is in a process class called "Reactor" and we have accepted thendefault instance name for the one Reactor that we need in our recipe.
    • The instance name is "Reactor". We need two transfer instances on the transfer class from BulkSilo to Reactor.
    • One instance, call it "Xfer1" will be defined with a source instance of "Bulk1" and destination instance of "Reactor".
    • The other, "Xfer2", will have a source instance of "Bulk2" and destination instance of "Reactor".
    • It is important to remember that we are not identifying specific units in our model at this point.
    • We are merely giving names to the units and connections that our batch will select when it executes.
    • The InBatch batch engine selects units based on material assignments, allocation status, equipment status, attribute ranges, selection mode, and assigned units.
Last modified: Wednesday, 6 May 2020, 5:06 PM