Now set up the model's activation. swarmContext indicates where
we're being started in - typically, this model is run as a
subswarm of an observer swarm.
in sequential batch two orders can stay in the same batch
if several criteria match; one of them is that of having the
same state vector, which contains the number of the units
that made the various steps; if we consider more simply the state
as 0 or non 0, we disregard the unit number (also the 'or', case
with -1 values in not used branches, receives the same treatment)
in sequential batch two orders can stay in the same batch
if several criteria match; one of them is that of having the
same state vector, which contains the number of the units
that made the various steps; if we consider more simply the state
as 0 or non 0, we disregard the unit number (also the 'or', case
with -1 values in not used branches, receives the same treatment)
The EndUnit class instances represent virtual or actuale
places or warehouse were temporary finished sub-recipes (produced internally
or obtained as procurements) wait to be used in other recipes via a "p"
(procurement) step
an endUnit has its internal number equal to the concluding code
used to finish/identify a temporary finished sub-recipe
we do not make accounting about fixed costs in the first tick of the first
day (time unit: day, shift, ...) or for the first whole time unit,
unless we use warehouses with the immediate possibility of producing inventories;
in the first tick of the first time unit (or in the whole first time unit,
if we have prepared an empty orderStartingSequence.xls file),
simply we have nothing in our world
production done step in Order (it is in the orderRecipe vector,
at the index value in which we find the first 0 in orderState
vector minus 1; if no step has been done, the method returns -999999)
getting the computational specification set related to the nextStep
(the current one, if the order is in a waiting list for next step
to be accomplished)
if no computational specification set exists for the next step,
a null value is returned
getting the 'or' specification set related to the nextStep
(the current one, if the order is in a waiting list for next step
to be accomplished)
if no 'or' SpecificationSet exists for the next step,
a null value is returned
getting the procurement specification set related to the nextStep
(the current one, if the order is in a waiting list for next step
to be accomplished)
if no procurement specification set exists for the next step,
a null value is returned
getting the sequential batch specification set related to the nextStep
(the current one, if the order is in a waiting list for next step
to be accomplished)
if no sequential batch SpecificationSet exists for the next step,
a null value is returned
getting the sequential batch specification set related to the step 'pos'
if any; if no sequential batch SpecificationSet exists for the next step,
a null value is returned
getting the stand alone batch specification set related to the nextStep
(the current one, if the order is in a waiting list for next step
to be accomplished)
if no stand alone batch SpecificationSet exists for the next step,
a null value is returned
the layer to which the order belongs; the layer has to be set by
OrderGenerator (for test purposes) and must of all by the
OrderDistiller; in this case, the information must be retrieved from
the recipeData/orderSequence.xls file
a layer is a period of time or a set of qualitative conditions that
introduce differentiations into the orders; e.g two collections in
fashion production, with the same technical description (recipe) and
different qualitative results
This method reads from the worksheet containing, shift by shift, the sequence of orders to be launched and fills
in the orderSequence1 with the ID codes of recipes and the orderSequence2 with the quantities of each recipe.
read (i) the unit numbers, production phases, fixed costs and
variable costs from the unitData/unitBasicData.txt file
(ii) the end unit numbers from the unitData/endUnitList.txt file
This method is used to collect the names of the units and of the end units, so that it can operate the check of
corrispondency between the production phases required by recipes and the phases of production the units can do.
copying the orders in the waitingList, if they are not kept into
any parallel unit, such as a myProcurementAssembler or
myComputationalAssembler or mySequentialBatchAssembler
the total number of end units we are using; and endUnit represents
an actual or virtual warehouse were we can "find" components
internallly produced using sub-recipes or external procurements;
each endUnit has a code which is the same used to conclude (as
an 'end') the recipe describing this internal or external
production
the total number of layers;
a layer is a period of time or a set of qualitative conditions that
introduce differentiations into the orders; e.g two collections in
fashion production, with the same technical description (recipe) and
different qualitative results
The Unit class instances are micro unit in our virtual enterprise;
i.e. the units where the steps required to build a product (to fulfill
an order) are done
at the beginning of each time tick in the 'day', each unit looks for
the order(s) (if any) to be executed; the production
cycle is 'one unit of time'
in a step of the recipe of an order in a tick of a day;