Shift plannification

[nmok]

Hello Thomas,

The approach that you are using might not give you correct results.

I am working on your solution. It involves the use of Resource Schedule Entities. Also, it seems that you want to model 6 operators for shift 1, 6 for shift 2, and 5 for shift 3. So you have a total of 17 operators and each of them needs their own separate schedule (which for all operators in same shift is the same but still implemented separately for each operator).

I shall update you with the solution by Monday or Tuesday at the latest.

Stay tuned.

[nmok]

Hello Thomas, I have attached the solution model for your reference. the zip file contains the Simulation Studio project as well as a word document containing detailed explanation. the same explanation is also given below.

Hope this is helpful.

Regards

nmok

MODEL SNAPSHOT

MODEL EXPLANATION

1. Modeling Creation of OF entity, Shaft entities and Piece entities (see Fig. 1 below):
   1. Creating OF Entities:
      • OF entities are created at a constant rate with an interarrival time of 120 minutes between 2 entities.
      • OF entities are assigned an MP_Time, MF_Time, and MC_Time attribute.
      • After assigning attributes, the OF entities wait in a queue until they can seize 1 Shaft entity, 1 Piece entity and 1 Operator entity. This queue (and all other queues in the model are nonblocking queues. Please read the section on nonblocking queues in the Simulation Studio documentation for more details)
      • OF entity will only go into Seize block if all 3 resources (Shaft, Piece, and Operator) are available.
   2. Creating Shaft Entities and Piece Entities:
      • A batch of 2000 entities of type Shaft and Piece respectively, is created at time 0. This is the initial inventory for Shafts and Pieces at the start of the simulation.
      • Shaft and Piece entities are held in the respective resource pools until they are seized by the OF entity.

*RankValues will be explained in a later section

Figure 1

Figure 2

2. Modeling Creation of Operator Entities and Operator Schedule Entities (see Fig. 2. above):
   1. Creating Operator entities:
      • Operator entities for different shifts are created in separate entity generators. Each Operator is assigned a “Shift” attribute in the entity generator during creation, as shown in the screenshot below
      • The number of Operator entities to create for shift X is controlled using the NumShiftXOps Number Holders.
      • Each Operator entity in the same shift is assigned a unique Operator number. Thus, across all shifts, each Operator entity has a unique combination for Shift+OperatorNo combination (Shift=2, Operator=1 or Shift=3, Operator=4, etc.).
   2. Creating Operator Schedule Entities:
      • Operator Schedule entities for different shifts are created in separate entity generators. Each Operator is assigned a “Shift” attribute in the entity generator during creation, as shown in the screenshot below using the rectangle highlighted in orange.
      • Some default attributes are also assigned specific values as shown in the screenshot using the rectangles highlighted in blue.
      • Lastly, some additional attributes are defined on the Operator Schedule entity which are highlighted in green.
      • After creating the Operator Schedule entity, it is assigned an “Operator” attribute which corresponds to the OperatorNo attribute on the Operator entity.
      • Each Operator Schedule Entity is also assigned a TargetSearchRule attribute from a String Holder as shown in the screenshot below. For example, the screenshot shows that one of the Operator Schedule entities was assigned an attribute value of   “Entity Type == Operator; Attribute Rule == Shift == 1 && OperatorNo == 6”. This means that this particular Operator Schedule Entity will be used to control the schedule of Operator No. 6 in Shift No. 1.

3. Operator Entity Flow:
   1. All Operators from all shifts are held in a single resource pool (labeled Operator Pool) as shown in Fig. 3. Below. The Operators are seized from this resource pool by the OF entity and released when the assembly is complete. The operators are also released when there is a schedule change. In either case, Operator entities are always routed back to the Operator Pool.

Figure 3

4. Implementing Operator Schedules:
   1. The scheduling of Operators is managed by the logic implemented in the compound block labeled “Implement Schedule”. All Operator Schedule entities enter the Resource Scheduler block at time 0.
   2. Each Operator Schedule entity pulls its schedule from the correct ShiftXAgenda block depending on its “Agenda” attribute value.
   3. In each ShiftXAgenda block, the schedule has been defined for Shift X for 1 operator. The total duration adds up to the total no. of hours in a week. Let’s take a look at the screenshot below. It shows the schedule of a Shift 2 operator as defined in the Shift2Agenda block.
      • The duration values add up to 10080 minutes, which is the total no. of minutes (working and nonworking) in a week.
      • The Value column shows the quantity of each Operator during each duration. Since each Operator Schedule entity implements schedule for an individual Operator entity, (based on TargetSearchRule attribute), the Resource Units specified in the Shift2Agenda block can either be 1 (i.e. Operator is available) or 0 (i.e. Operator is unavailable).
   4. The Start Time value for the Schedule as specified in the “StartTime” attribute for Operator Schedule entity is 0. We need to run the simulation for 10 weeks. Hence we need to repeat this schedule specified in the Resource Agenda every week. We have specified the “ToRepeat” attribute for all Operator Schedule Entities as “true”. So, after 10080 minutes of simulation time, the Operator Schedule entity exitas the Resource Scheduler block. We now need to specify the StartTime for the next schedule (which is the current time i.e. 10080) and send the Operator Schedule entity back to the Resource Scheduler block and implement the schedule for the next week of simulation. This process is repeated for 10 weeks of the simulation for every Operator Schedule entity.
   5. Operator Resource Utilization Statistics can be viewed using the Resource Stats Collector block, as shown in Fig. 3.
   6. The Primary Assembly, Final Assembly, and Crating operations are carried out as shown in Fig. 4.
      • If there is a change in schedule while an OF entity is in Server, the associated Operator entity is preempted and sent back to Operator Pool. The OF entity then recalculates the remaining assembly\ crating time and waits in Pending_queue for the Operator from the next shift. It then seizes the Operator from the next shift and goes back into the Server.

Figure 4

7. Block Ranking:

The RankValue dialog is used to control the precedence of events in case there is a tieduring the simulation model run. For example, after a shift change, there could be an OF entity waiting to finish assembly in the Pending_queue and there could also be another OF entity waiting in the In_OF_Q. so which one gets the available Operator from the next shift? To manage such ties, Simulation Studio has a Block ranking dialog which can be used to give higher priority to certain blocks such as entity generators, Queues, Servers, etc.

In this model, we have used the block ranking dialog to:

1. Give higher priority to pending queues than the In_OF_Q (they have been assigned a higher RankValue =10 compared to RankValue=5 for In_OF_Q).
2. Specify order in which entities are created at time 0:
   1. Operator entities are created first (RankValue=16).
   2. Operator Schedule entities are created second (RankValue=14).
   3. Resource Scheduler starts implementing schedule for all Operator entities at time 0 (RankValue=12).

Blocks with higher RankValue get higher priority. In item ii. above, we need to create Operator entities before we can create their Operator Schedule Entities. And Operator Schedule entities need to be created, assigned attributes, and routed to the Resource Scheduler block BEFORE the Resource Scheduler can start implementing the schedules. Hence, this hierarchy is important.

All other blocks in Simulation Studio have a default RankValue of 0 (except all Queue blocks which have a default RankValue of 1).

The RankValue can be specified in the Block Ranking Dialog. The Block Rankin gDialog can be viewed by right clicking the model name and selecting “Block Ranking” option. The Block Ranking Dialog appears as shown below:

8. Using Factors to Control Inputs

Factors have been defined in the experiment window to control various inputs to the simulation model, namely:

1. Initial Shaft Inventory
2. Initial Piece Inventory
3. MP_Time
4. MF_Time
5. MC_Time
6. # of Shift 1 Operators
7. # of Shift 2 Operators
8. # of Shift 3 Operators
9. MP server Capacity
10. MF Server Capacity
11. MC Server Capacity
12. OF Interarrival time

9. Lastly, the Operator is released and the OF entity leaves with 1 Shaft and 1 Piece entity, as shown in Fig. 5 below:

Figure 5

[ThomasMuraille]

Thank you nmok !

This is really clear and precise. Thanks a lot for all the work you have done for me !