| # Segment schedules Segment schedules are schedules that indicate when the assembly parts that are required for the work in a particular line segment must be delivered to the shop floor warehouse. For each segment on a line, a range of offline periods is defined. And, for each period, a date is scheduled on which the assembly parts are required. As a result, every product variant whose requested offline date falls within one of these periods requires its assembly parts for the segment in question on that date. The advantage of segment schedules is that the assembly part requirements can be determined right from the schedule, if only the requested offline date of the product variant and the segment of the assembly parts is known. Compare this to the following procedure, which applies if no segment schedules are used: Determine in which segment a part is required. Offset that line segment by calculating the time between the start of the segment and the end of the roll-off line Calculate the date on which the assembly part is required. Determine the plan period in which this date falls. Determine the delivery date of the part, which is the start date of the plan period. Segment schedules are used for a rough planning of assembly part requirements, especially in the more distant future, that is, the period after the allocation time fence but before the demand time fence. However, the schedules cover the entire period in the demand time fence, including the allocation time fence. The segment schedules appear in the Segment Schedules (tiapl4500m000) session. The assembly part requirements for product variants whose requested offline date falls in the allocation time fence are allocated by Assembly Control for each line station, in the Build Allocations (Server) (tiasc7240m001) session. The assembly part requirements for product variants whose requested offline date falls in the demand time fence are calculated by the Calculate Assembly Part Requirements (tiapl2221m000) session per segment, and for a range of product variants at once. This is a simplified calculation with a high performance for large volumes. The allocation time fence is defined in the details of the Assembly Control Parameters (tiasc0100m000) session. The Demand Time Fence is defined in the details of the Assembly Planning Parameters (tiapl0500m000) session. The segment schedules are determined as follows: The plan periods for the current scenario are determined. The current scenario is selected in the Scenario field of the details of the Assembly Planning Parameters (tiapl0500m000) session. The plan periods are defined in the Scenario - Periods (cprpd4120m000) session. The segments of the assembly lines are offset, which means that the time between the the start of the line segment and end of the roll-off line is calculated, according to the lead times of the segments. Now, for each plan period and each segment the offset time of the segment is added to the start time of the plan period. This way, for each segment, a new series of periods is created. These periods correspond with the original plan periods, but the new periods are shifted into the future a time span equal to the offset time of the segment concerned. Therefore, these periods indicate that a product variant whose requested offline date falls in one of these periods, requires his assembly parts for the segment in question on the start date of the corresponding original plan period. Example Imagine an assembly line and plan periods with the following characteristics: The assembly line has no supply lines, so it is a roll-off line. The line has two segments. The lead time of segment A, where the assembly process starts, is 2 days. The lead time of segment B, which is the roll-off segment, is three days. The plan periods are defined as weeks. The first plan period starts on January 1, at 00:00:00. If the segments are offset, the offset time of segment A is five days. The offset time of segment B is three days. Now the offset times of these segments are added to the start times of the plan periods. As a result, for plan period 1 and segment A, a new period is created that starts on January 6, at 00:00:00, which is the first moment after the five days offset time of segment A, which were added to January 1, 00:00:00. The second period starts on January 13, at 00:00:00, because this is the first moment after the five days offset time of segment A, which were added to the start of plan period 2, which is January 8, at 00:00:00. So, the first period ended on January 12, at 23.59:59. For plan period 1 and segment B, a new period is created that starts on January 4, at 00:00:00, because this is the first moment after the three days offset time of segment B, which were added to January 1, at 00:00:00. The second period starts on January 11, 00:00:00, which is the first moment after the three days offset time of segment B, which were added to the start of plan period 2, which is January 8, at 00:00:00. So, the first period ended on January 10, at 23:59:59. Now, if you have a product variant with a requested offline date of January 12, this date falls in period I for segment A, but in period II for segment B. As a result, assembly parts that are required in segment A, are required on the start date of plan period I, which is January 1. Assembly parts that are required in segment B, are required on the start date of plan period II, which is January 8. Refer to the following picture, in which the date of January 12 is marked with an X. Note Because the periods for the segments start somewhere in the future, a problem occurs when the requested offline date of a product variant is before the first period of a segment. In the previous example, when the requested offline date is, for example, January 3. This situation of course is not a normal situation, because this implies that you have a backlog, but this situation can occur. To cope with this problem the first period has no start date. As a result, if you view the schedule, you see that the Planned Offline Date From field is empty when the record displays the data for the first period of a segment. As a result, the Date Scheduled of that record applies for all assembly part requirements up to the Planned Offline Date To. It is important that the Calculate Assembly Part Requirements (tiapl2221m000) session uses the most up-to-date schedule. Several types of changes require an update. Sometimes the Calculate Assembly Part Requirements (tiapl2221m000) session detects these changes and updates the schedule automatically. However, sometimes the update must be performed manually. You can update the schedule manually through the Update command on the appropriate menu of the Segment Schedules (tiapl4500m000) session, or you can select the Update Segment Schedules check box in the Calculate Assembly Part Requirements (tiapl2221m000) session to enforce an update when that session runs. The schedule must be updated in the following cases: The line structure is changed. You must update the schedule manually. The calendar that is linked to one of the assembly lines is changed. The schedule is updated automatically when you run the Calculate Assembly Part Requirements (tiapl2221m000) session. The calendar is selected in the Calendar Code field in the Assembly Lines (tiasl1530m000) session. The scenario is changed, or the plan periods in the scenario are changed. If you use a rolling scenario, the plan periods change every period. The schedule is updated automatically when you run the Calculate Assembly Part Requirements (tiapl2221m000) session. However, if the plan period definition is changed, while the reference date is not changed, you must update the schedule manually. Related topics Assembly planning overview |