-
Notifications
You must be signed in to change notification settings - Fork 0
Modeling the Jobshop
This project uses the following objects to represent a JobShop scheduling problem:
A "stock keeping unit" (SKU) represents the part demanded by a customer and is manufactured in the jobshop. It includes the following properties:
- Unique SKU ID
- Description (optional textual description of the SKU)
A demand for the SKU by a customer. It includes the following properties:
- A unique demand ID
- SKU which is being demanded
- Name of the customer
- Due date of the deamnd
- Quantity of the SKU being demanded
- Priority of the demand (used in determining the order in which we plan demands)
One of several actions that needs to be performed to meet the demand for a SKU. It includes the following properties:
- A unique task number
- Unique SKU ID for which this task is being performed
- Setup time (irrespective of the number of units of the SKU processed by this task)
- Per unit cycle time (depends on the number of units of the SKU processed by this task)
- Minimum lot-size
- Maximum lot-size
- Is_Delivery_Task - a flag that indicates if this task is used to "deliver" (or fulfill) the demand for the SKU.
- Predecessor and Successor Tasks (if any)
- List of (alternate) Workcenters that the task may load
-
From a data specification standpoint, it may be sufficient that the combination of the SKUID and the task number be unique although at this time, we require even the task number alone to be unique.
-
If the "is_delivery_task" flag is enabled, then this task is a proxy for the shipment of the SKU from the factory to the customer. As a result, it typically uses the "setup time" as a proxy for the shipment time and the "per unit cycle time" is set to 0.
-
The predecessor and successor tasks together define the "chain" or "routing" of tasks that need to be performed in sequence to satisfy the demand for an SKU. The upstream most task which consumes the raw material has no predecessor and has only a successor. The downstream most task, which is has the is_delivery_task enabled has only a predecessor and no successor.
-
A task may be performed on one or more workcenters (that is, there may be one or more machines/workcenters which are capable of performing that task. There may be a preferred machine/workcenter on which we would like to run the task; if that workcenter is not available, then we will use the next alternate and so on.
-
Not all tasks need to load a workcenter. Typically, a task that delivers the SKU to the customer to satisfy the demand may be a simple shipping task which does not load any workcenter.
A machine on which a Task is performed/run. A workcenter has the following attributes:
- A unique name or workcenter ID
- An efficiency calendar associated with the workcenter
- A criticality index (proxy for how important it is to solve overloads on this workcenter)
- The maximum number of setups we want to perform on this workcenter in one shift
-
The efficiency calendar is also a proxy for the availability of the workcenter. If the workcenter is down for maintenance (scheduled or otherwise), or if the factory does not work on weekends, these dates/times will have an efficiency of 0. Any non-zero value represented in the efficiency calendar will represent the true efficiency of the workcenter. More details on modeling the efficiency will be given under the Calendar and CalendarShift models.
-
At this time, criticality is user specified. It is not used by any planning algorithm to resolve overload problems. However, going forward, there is opportunity for the planning algorithm to identify critical workcenters based on static and dynamic considerations.
-
The maximum number of setups per shift is again a user specified guidance to the planning algorithm. While technically it may be possible to setup more any number of jobs in a shift if the setup times are low; however, from an execution standpoint there are always practical considerations that limit the number of job setups/changeovers and all of these constraints cannot be modeled in a software solution.
A Calendar has the following properties:
- A unique calendar name
- A calendar type (at this time, only the EFFICIENCY_CALENDAR type is supported)
- A list of shifts that define the availability of this calendar
Each Calendarshift is represented by:
- A unique shift ID
- A start date/time
- An end date/time
- A shift priority
- A value
-
While we typically think of a shift as an 8 hour working period with 3 working shifts in a day, there are no restrictions on how these shifts can be created during actual modeling. Shifts can overlap multiple days, and can be of varying length.
-
The shift priority is a user specified value which can indicate the importance of a particular shift when compared to other shifts. It is typically preferable to have some shifts at 100% utilization on all workcenters before loading the lower priority shifts - especially in the context of alternate workcenters. At this time, there is no planning algorithm support for this priority field. It is a place holder for future enhancements.
-
The value in the calendar shift depends on this kind of calendar we are modeling. Since at this time, we only support EFFICIENCY calendars, this value is a number between 0.0 and 1.0. A value of 0.0 indicates that the shift is closed (for either maintenance or due to breakdown of the equipment or due to a holiday). A value of 1.0 indicates that the efficiency of the workcenter is 100%. If the efficiency value is between 0.0 and 1.0, this means that a task that runs on this shift will take normal than the standard time taken to complete that task for the specified quantity. The time taken by the task will be = (standard-time/efficiency).
A TaskPlan is a planning instance of a Task. It has the following properties:
- A quantity representing the number of units of the part processed in that TaskPlan
- Start date/time of the taskplan
- End date/time of the taskplan
- Workcenter ID of the resource (if any) loaded by the taskplan
- Demand ID of the demand for which this TaskPlan was created/planned
-
The quantity of the TaskPlan will affect its length since the standard time to complete a TaskPlan is given by: setup_time + quantity * per_unit_cycle_time
-
The length of the TaskPlan is also affected by the Workcenter that it loads. The efficiency calendar and holiday schedule of that Workcenter can cause the TaskPlan to be stretched considerably longer than the standard time as defined in the earlier note.
-
Each TaskPlan is also aware of the Demand for which it is planned. It is possible that the TaskPlan quantity need not match the Demand quantity (due to lot-sizing or other considerations). When the TaskPlan quantity is larger than the corresponding Demand quantity, that will gives us to opportunity to use the excess quantity for some other Demand. This feature is currently unsupported and for now, we assume that we can always plan the TaskPlan quantity to be lesser than or equal to the Demand quantity.
A ReleasedWorkOrder is a released instance of a TaskPlan. It is a representation of what is actually happening on the shop floor. It can override various static model constraints that are usually place on the TaskPlan when the JobShop solver is creating new TaskPlans.
It has the following properties:
- A workorderid representing a unique identifier of this ReleasedWorkOrder
- A lotid representing one of the one or more lots/splits that make up the ReleasedWorkOrder
- A task representing the Task which this ReleasedWorkOrder is planned for
- A plan representing the plan to which this ReleasedWorkOrder belongs
- A quantity representing the number of units of the part processed in that ReleasedWorkOrder
- Start date/time of the ReleasedWorkOrder
- End date/time of the ReleasedWorkOrder
- Workcenter ID of the resource (if any) loaded by the ReleasedWorkOrder
- Demand ID of the demand (if any) for which this ReleasedWorkOrder was created/planned
-
The quantity of the ReleasedWorkOrder will NOT affect its duration. The duration is user specified and will consume capacity on the associated WorkCenter (if one is specified).
-
A ReleasedWorkOrder can also load a Workcenter that is normally not associated with its Task. This is also a reflection of the fact that on the shop floor, decisions can be made by the user that are not normally available to the solver.
-
If a ReleasedWorkOrder is not associated with a specific demand ID, it is free to be consumed by any demand that comes along for that Task.
-
Excess quantity of a ReleasedWorkOrder that is assigned to a specific demand ID is not available to any other demand and this excess quantity goes unused by the solver.
-
If a ReleasedWorkOrder is placed later than JIT then a demand that uses this ReleasedWorkOrder can be delivered late even if it could have been satisfied on time or early by creating new TaskPlans. The solver will always try to consume any WIP in the system before creating fresh TaskPlans. Care must be taken when creating the ReleasedWorkOrders.