Order and Operation Relationships.

When operation numbers are used to define the sequence of operations within an order the Sequencer assumes that lower operation numbers must be performed before higher operation numbers and that operations with the same operation number may be performed in parallel.

Defining operation relationships in this way is quite easy and has the advantage that you can easily insert or remove operations without the need to redefine the parameters of previous or subsequent operations. All operations of the Order are considered as a whole and sequenced in one action.

However, there are significant limitations in the way that operation numbers can be used to model assembly and dis-assembly within the order. For example, consider the assembly in the following order:

Using operation number relationships only, the two operation 10s would have to be performed before either of the operations 20s and both operation 20s would have to be performed before either of the operation 30s.

Often, with assembly of this type, operations 10a, 20a and 30a could be performed independently of operations 10b, 20b and 30b. The only point at which dependency is required is at operation 40.

Defining operation sequences using MADE FROM overcomes the limitations of implying the relationship using operation numbers. However setting up the relationship is more complex.

In the above example the MADE FROM table would look like this:

 Op 10a – No Dependencies
 Op 20a – Depends on Op 10a
 Op 30a – Depends on Op 20a
 Op 10b – No Dependencies
 Op 20b – Depends on Op 10b
 Op 30b – Depends on Op 20b
 Op 40 – Depends on Op 30a and Op 30b
 Op 50 – Depends on Op 40
 Op 60 – Depends on Op 50

When sequencing the operations of the order, Opcenter SCcreates internal virtual orders for sequencing. The virtual order is made up of the previous and subsequent operations plus, iteratively, any operations that have no more than one previous operation and no more than one subsequent operation.

Looking at the order above, this would result in the following virtual orders:

Virtual Order 1: 10a, 20a, 30a.
Virtual Order 2: 10b, 20b, 30b.
Virtual Order 3: 30a, 30b, 40, 50, 60.

Opcenter SC then treats these virtual orders in the same way as orders defined using operation numbers. The virtual orders become available for sequencing when there are no unallocated dependents of the first operation. So in this example, Virtual Orders 1 and 2 are considered immediately, Virtual Order 3 is only considered once both Virtual Orders 1 and 2 have been sequenced.

It can be seen that Virtual Order 3 contains both operations 30a and 30b; these operations will have been already sequenced before Virtual Order 3 is considered, so there will be no relationship between them, other than operation 40 requiring that they have both been processed.

When using EXPLICIT MADE FROM the operation relationships can include operations that are not part of the same actual Order, however, internally the same Virtual Order concept is used.

Certain features of Opcenter SC can create more complex relationships between operations than just their previous and subsequent operations. These features are:

• Maximum time between operations – INTER OPERATION INTERVAL

• Subsequent resource constraints – SUBSEQUENT RESOURCE CONSTRAINT and RESET SUBSEQUENT RESOURCE

• Secondary constraint usage types that can affect secondary constraints outside of the span of the operation, for example “Increment From Start”, “Decrement To End” etc.

Use of these features must be carefully considered when using MADE FROM and assembly or dis-assembly. The above features are only considered within each order, when using MADE FROM this means the Virtual orders created internally. If any of these features are used within an order constructed using MADE FROM where multiple Virtual orders are then created, unexpected results may be obtained. Outlined below are scenarios where problems may arise.

If only one pair of operations in an order have and INTER OPERATION INTERVAL it will not cause a problem, however if there is a chain of INTER OPERATION INTERVAL values between contiguous operations, this creates a complex operation relationship.

In the above example, say the following INTER OPERATION INTERVAL relationships were specified, the actual duration of the intervals is not a determining factor:

First, Virtual Order 1 will be sequenced, Op 10a, 20a and 30a. If Op 30a cannot be sequenced within the required time, Op 20a will be moved forwards. Moving Op 20a may then violate the interval between Op 10a and 20a, this will cause Op 10a to be moved. Eventually operations 10a, 20a, and 30a will be scheduled so that the intervals will be respected, assuming there is available capacity.

Virtual Order 2 will now be sequenced independently.

Finally Virtual Order 3 can be sequenced which includes Operations 30a and 40, these two operations have an INTER OPERATION INTERVAL constraint. If this interval is violated, Op 30a will be moved, however, as Op 20a is not part of Virtual Order 3 it will not be considered and will not be moved even if the INTER OPERATION INTERVAL between it and Op 30a is violated. It will thus be possible for the final schedule to violate the INTER OPERATION INTERVAL specified between Op 20a and Op 30a.

In the order above, say Op 50 can be performed on either the Lathe or Mill. Op 10a sets the SUBSEQUENT RESOURCE CONSTRAINT to Lathe. The Lathe will be set as a required resource, for all subsequent operations in Virtual Order 1, Op20a and Op 30a. However, for Virtual Oder 3 which contains Op 50, no SUBSEQUENT RESOURCE CONSTRAINT will have been set and the operation will be free to be placed on the Lathe or Mill.

When operations require secondary constraints, the sequencing engine checks that the usage of the constraint is within the required limits for the duration of the use of the constraint, Setup time, Operation time or the entire process time. If the constraint is affected outside of the operation duration then an additional check is performed after the entire order (Virtual order) is scheduled. If the constraint is, say, incremented by one operation and decremented by another in equal quantities, the constraint will be verified between the two operations. If the constraint is not incremented and decremented by equal quantities then the constraint is checked out into the future indefinitely.

If in our example, Op 10a increments a constraint and Op 50 decrements the constraint by the same amount unexpected results may be given as Op 10a and Op 50 are not within the same Virtual Order. Virtual Order 1 will be scheduled, but as no operation in the Virtual order decrements the constraint, it will be checked indefinitely into the future. If there is no other usage of the constraint and there are no capacity changes caused by calendars that would cause the constraint to be violated, then the order will be sequenced. However, if at any point in the future the constraint is violated, the Op 10a will be either scheduled after the violation or left unallocated if it is not possible to place the operation without violating the constraint. If Op 10a is not sequenced, Virtual Order 3 will never be a candidate for sequencing as Op 30a will never be sequenced.

The "start" of an operation is defined as follows:

Where it is not possible to have a sequence dependent setup time, the "start" of an operation is the start of the setup time.

Where it may be possible to have a sequence dependent setup, the "start" of an operation will depend on if the operation is being "placed" or being "tested". When being "placed", the "start" is taken as the start of setup. When being "tested", the "start" is taken as being the start of processing.The reason is, when the sequence dependent setup times are in use, the process start time is taken as the fixed point in time when the setup time changes, which also means that the process end time will remain fixed.

The advantage of this is that, when placing an operation on a resource, only the next operation needs to be checked for possible violations as the setup time of only the subsequent operation can change. This will result in a relatively short time to perform the scheduling process.

However, if the setup start time changes and this were to be used as the operation reference point, further checks would have to be made on previous operations of the order for the subsequent operation. As in, increase in the setup time could cause it to overlap with the end of the previous operation. If violations were to occur, for example, if the setup time increased to before the end of the previous operation, then multiple adjustments may be required.

Similarly, if the setup time start is fixed and the process start and process end are moved, there can be potential knock on effects with both subsequent operations of the order and subsequent operations on the resource. Correcting these potential violations could, in some circumstances, necessitate an almost complete rebuild of the schedule. Rebuilding the schedule could in turn mean, especially if features such as INTER OPERATION INTERVAL are in use, that operations scheduled earlier in the scheduling horizon could be moved. Moving operations earlier in the scheduling horizon may cause violations to the operation that has just been placed. This could result in an infinite, or near infinite, set of iterations trying to place and them move operations, causing exceedingly long scheduling times.