Sign Out
Logged In:
 
 
 
 
 
Tab Image

A Hierarchical Approach for the Application of Slabs to Strip Products

Francis J. Vasko, Kutztown University, Kutztown, USA
Arthur J Hamm, Sparrows Point, USA
Kenneth L Reitmeyer, EDS-Mid Atlantic Solution Center, Bethlehem, USA
L. Richard Woodyatt PE, Pikewood, Inc., Bethlehem, USA

Abstract

In the mid-1990’s, the Sparrows Point Steel Plant began an initiative to achieve 100% on time slab availability to the hot strip mill. At that time, order dressing, heat building, slab application, and mill scheduling of strip product orders were manually intensive activities. It was decided to implement an integrated system to automate these activities. In this paper we discuss the central activity of this system—the application of slabs to strip product orders (used for appliance panels, steel storage sheds, food cans, etc.). A binary integer linear programming formulation will be given for the slab application problem. However, because of the size of typical problem instances, a robust and efficient hierarchical heuristic solution approach was developed that has been in daily use since 1999.

Keywords: slab application, steel industry, mathematical programming application, heuristic application.

Introduction

In the mid-1990’s, Sparrows Point began an initiative to achieve 100% on time slab (a rectangular semi-finished piece of steel) availability to the hot strip mill. Order dressing or the specification of customer chemical and physical properties requirements, heat building or the grouping of customer orders into batch sizes based on metallurgical grade and slab size requirements, slab application or the assigning of specific slabs (either already produced or yet to be produced) to strip product orders (used to make appliance panels, steel storage sheds, food cans, etc.), and hot strip mill scheduling or the selection and sequencing of slabs to be processed into coils on the hot strip mill were manually intensive. The systems for each were stand alone, each with similar but independent slab application rules. Many efforts to fine-tune the process and systems fell short of the 100% ontime goal.

New hot strip mill requirements that could not be satisfied by existing slab inventory were converted to steel orders. These steel orders formed the input to the heat building system, and were manually arranged into heat lot (batch size) requirements for caster production. These heat lot plans were rarely revisited to accommodate order or inventory changes. Because individual slabs were tied to specific orders, slabs with lower quality than required by the mill order were de-applied during a daily run, while slabs produced with better quality than required remained coupled with the original order. Manual application / reapplication caused a ripple effect throughout the systems.

It was decided to implement an integrated system to do automatic order dressing, heat building, slab application, and mill scheduling (See Figure 1). A client-server based system was designed, with each of these functions accessing the same core slab application rules. This allows for consistent decision making improving customer service, reducing the manual intensity of the process, and providing more efficient use of non-standard inventory.

ORIHierarcFig1

In the next section, an overview of the steel material flow of the plant up to the hot strip mill will be given. This will be followed by a binary integer linear programming formulation of the slab application problem. After that the hierarchical heuristic that is used daily to solve slab application problems will be outlined. Finally, benefits derived from implementing this system and potential future enhancements will be provided.

Material Flow Up To The Hot Strip Mill

The Sparrows Point steel production facilities consist of two 290 ton basic oxygen furnaces (BOF), two top-stirred ladle treatment stations with oxygen reheat, alloying and injection capability, and two single strand continuous casters. Continuous casters efficiently transform liquid steel into solid pieces of steel. One caster was recently rebuilt to cast up to 104 inches wide, while the second remains at its original 88 inch width. Slabs are cast 10 inches thick by 47 inches to 104 inches wide, 200 inches to 400 inches long. The rebuilt caster also has the ability to cast 12 inch thick slabs and the original caster can also cast 8 inch thick slabs. The majority of the slabs that are going to be used in the hot strip mill are cast to predetermined standard slab sizes or a width that is a multiple of a standard slab size (See Vasko et. al. 2003 for how standard slab sizes are determined). A master or mother slab exiting the caster is typically put directly into inventory. Before being sent to the hot strip mill, slabs can be cut longitudinally into either two symmetric or two asymmetric slabs. These narrower slabs are often referred to as “daughter” slabs or“doubles”. Also, master or mother slabs are infrequently cut longitudinally into three symmetric slabs referred to as “triples”.

Automatic Slab Application

Order dressing ensures that orders are assigned to an appropriate standard slab size. Heat building ensures that there will be enough tonnage in every standard slab size to satisfy current order requirements. Heat building also ensures that if special requirements exist, they will be melted and available to apply at the appropriate time. Once a slab is cast, the automatic cast audit system ensures that it has the most accurate information possible. Without all these systems, slab application would not enjoy the flexibility to apply slabs to orders in the best way possible.

A big step towards reducing the manual intensity of the entire process was to automate the process of applying slabs. The goal of the new automatic system was to apply 60-70% of the slabs to be rolled on the hot strip mill. Automating the application of slabs frees up time that can be spent on more value-added tasks. The goals of this new automatic system are summarized in Table I.

ORIHierarcTable1

The logistics of slab handling is also an important factor to consider when applying slabs. If the best slab is on the bottom of a pile, and the slabs above it are not going to be used at the same time, are they really the best slabs?

Once a slab pile is started for an order, great emphasis should be placed on trying to use the remaining slabs in that pile on subsequent orders. When slab application was completely a manual process, pile utilization also played an important role. The manual slab application personnel worked off of slab listings that are printed every morning. These slab listings are sorted by pile location and position within a pile. This same concept was incorporated into the new application system. Figure 2 illustrates the importance of slab piles in the application process. Specifically, for an order requiring three slabs, three “perfect “ (the best from a metallurgical and dimensional perspective) slabs can be obtained requiring a total of nine slab hauler moves or three feasible (acceptable from a metallurgical and dimensional perspective) slabs can be obtained with only one slab hauler move.

ORIHierarcFig2

In other words, the cost of the additional eight slab hauler moves has to justify going after the“perfect” slabs versus applying feasible slabs to the order in only one slab hauler move.

A Mathematical Formulation For Slab Application

Background

Table II presents the possible ways a slab can be applied. This is an important factor in mathematically formulating the slab application problem and subsequently selecting or designing a solution algorithm. The single applications could be modeled and solved as an assignment problem (Vasko et al 1994). The symmetric doubles could also be applied using an assignment algorithm, by treating the ‘pair’ as the order that is being assigned to a slab. Pile logic would not be an issue since the assignment algorithms could be configured to incorporate pile logic into the cost structure.

ORIHierarcTable11

However, the assignment formulation is not without difficulty. In particular, each order has a range of slab weights that will satisfy the order. The weight of the actual slabs applied to the order dictates how many slabs are required to complete the order. Applying slabs in the low weight range for an order may result in additional slabs being required to complete the order. Table III illustrates this relationship.

ORIHierarcTable111

Asymmetric double applications could not easily be modeled using an assignment algorithm. The challenge came from what to do with the asymmetric applications.

The asymmetric applications can be handled by decomposing the problem into two subproblems that are solved sequentially. The first problem is a (non-bipartite) two-dimensional matching problem (Vasko et al 2000) that pairs daughter slabs together while trying to achieve several production planning goals. The second problem uses a series of assignment problems in order to associate mother slab requirements (a matched pair of daughter slabs) with physical slabs such that a number of important goals including consuming complete piles of slabs is met. This approach works well if there are enough slabs in inventory to satisfy ALL the matches made in the two-dimensional matching problem. If this is not the case, then candidate daughter slab matches and candidate inventory slabs must be considered SIMULTANEOUSLY instead of in a decomposed two-step manner. Even though the asymmetric applications make up a small percentage of the total applications, this is where substantial benefit can be gained. Making good asymmetric applications tends to consume nonstandard inventory, and can eliminate the need to special melt non-standard orders.

The information needed for matching daughter slab requirements together and then assigning them to a physical slab from inventory can be thought of in terms of a “cube” of feasibility. That is, two dimensions of the “cube” stand for the daughter slab requirements. The third dimension of the “cube” stands for the physical slab inventory (See Table IV below). This problem can be thought of as a kind of threedimensional matching problem that is especially difficult to solve because the desirability of a particular three-dimensional (3D) match is not totally known apriori because it is dependent, in part, on what the other 3D matches are! This interaction among matches is due to the fact that a primary goal is to consume entire piles of slabs from inventory. So, from a pile utilization perspective, a 3D match is desirable if there are other 3D matches that consume an entire pile of slabs.

ORIHierarcTableIV

An alternative to the three-dimensional matching formulation for the slab application problem is the binary integer linear programming formulation given below. The following definitions are based on the generation of all feasible applications involving either one or two orders applied to an inventory slab.

Definitions (variables):
Yj is 1 if feasible application j is used, 0 otherwise.
Ci is 1 if order i is complete, 0 otherwise.
Pq is 1 if any slab from pile q is used, 0 otherwise.
Piq is 1 if any slab from pile q is used to satisfy order i, 0 otherwise.

Definitions (parameters):
N is the number of feasible applications.
M is the number of orders.
S is the number of slabs.
Q is the number of slab piles.
Bj is the benefit of using feasible application j.
Vi is the priority of order i.
W1j is the slab weight of the first order in feasible application j.
W2j is the slab weight of the second order in feasible application j (If the feasible application is a single or has a haulback, then W2j = 0).
O1ij is 1 if order i is the first order in feasible application j, 0 otherwise.
O2ij is 1 if order i is the second order in feasible application j, 0 otherwise.
ri is the minimum weight required for order i.
Ri is the maximum weight required for order i.
Sjk is 1 if feasible application j uses slab k, 0 otherwise.
Lkq is 1 if slab k is located in pile q, 0 otherwise.
Dq is the cost of using any slabs from pile q.
Diq is the cost of using any slabs from pile q for order i.
FO1i is the set of feasible applications that have order i as the first component.
FO2i is the set of feasible applications that have order i as the second component.
FSk is the set of all feasible applications that use slab k.
Aq is the set of slabs in pile q.

Mathematical For,ulation for SAP:

ORIHierarcMathFormulae

The objective function is the composite of four components. The first component measures the benefit of completing orders. Each order can have a different benefit of being complete. The second component measures the benefit associated with making particular applications. The third component measures the negative impact of using “too many” piles, and the fourth component measures the negative impact of using slabs from “too many” piles for a particular order.

Constraint set (1) makes sure that an order is not considered complete unless its minimum weight requirement is met. Constraint set (2) makes sure that the maximum weight requirement for an order is not exceeded. Constraint set (3) makes sure that a slab is used in at most one application. Constraint set (4) makes sure that a pile is considered used, if any slab from that pile is used. Constraint sets (5) and (6) make sure that a pile is considered used for a particular order, if any slab in that pile is used for that order. Constraint set (7) makes sure that all variables are either 0 or 1.

There is a separate slab application problem (SAP) for each family (composed of similar metallurgical properties) of metallurgical grades. The number of feasible applications, dependent on metallurgical grade family, ranges from as few as 3000 to as many as 1,000,000. This means that even “small” SAPs will have at least 3000 0- 1 yj variables and the larger metallurgical grade families will have typically between 20,000 to 60,000 0-1 yj variables. The largest metallurgical grade families will have several 100,000 to 1,000,000 0-1 yj variables. The number of orders as well as the number of slab piles can be up to several 100 for a typical application problem. Since SAP is a large-scale binary integer linear programming problem, obtaining a guaranteed optimal solution efficiently is highly unlikely.

A Hierarchical Solution Approach For The Slab Application Problem

Algorithm Overview

The algorithm starts by building a list of feasible applications for all open orders. These feasible applications can be singles, symmetric doubles, asymmetric doubles, or triples. Each slab usually has more than one feasible application. Also, each order typically has more than one feasible application. When a feasible application is found, it is assigned a score. The score is based on the type of match, the orders used, and how well the slab fits the match with respect to grade and size. The application score has no component based on pile utilization. The application score is treated like a penalty. The lower the score, the more desirable the application is. Two observations based on the list of feasible applications are:

  • Orders can be ranked by the number of feasible applications associated with an order. The fewer feasible applications an order has, the more constrained it is.
  • Slabs can also be ranked based on feasibility. The more feasible applications a slab has, the more applicable the slab is.

The algorithm processes one order at a time, starting with the most constrained order. For the chosen order, a working list of feasible applications that include this order is built. From this working list of feasible applications, a list of feasible piles is built. A feasible pile is a slab pile with at least one slab included in the working list. The feasible piles are then ranked based on a number of factors: usable slab locations within the pile, number of unusable slabs within the pile, application score, and the number of slabs in the pile applied to a previous order. The working list of feasible applications is sorted by pile score, pile location, position within the pile, and application score. Applications are made from the top of the list down, picking the first feasible application for each slab. This ensures that the slabs are used from the top of the pile down, and the lowest score (penalty) application available for each slab is used. Slabs continue to be applied to the current order until either no more feasible applications are available or the order is complete.

Consider an example where an order needs two slabs. Table V illustrates the feasible piles for this order. Some interesting tradeoffs of different pile utilization strategies include:

  • If the applications score alone was the driving force in determining which slabs to pick, slabs 3 and 9 would be applied, resulting in 4 slab hauler moves and a total cost of 98, for an average application score of 49.
  • Using the pile logic outlined above, pile B would be chosen since its overall pile score is lowest. Picking pile B for the two required slabs results in only one slab hauler move and a total cost of 190, for an average application score of 95.
  • Even though the score for slab 10 is lower than the two slabs used from pile B, Pile C is not chosen because it would result in an extra slab hauler move.
  • Another aspect of the pile logic is to focus on consuming small piles of slabs. In the short term, this strategy may result in more slab hauler moves. But by consuming small piles, locations are made available which can be filled by homogenous piles from the caster, which will improve overall slab hauler utilization.
  • Now that pile B is started, slab 9 looks more attractive to subsequent orders. Once a pile is started, the algorithm heavily favors that pile for subsequent orders.

ORIHierarcTableV

After every application is made, an update step is required. All feasible applications for the slab that was just applied need to be marked as not available. This also requires updating the order feasibility numbers mentioned above. As slabs are applied, the feasibility of other orders can be impacted.

When applying orders asymmetrically, the companion order has to be taken into account. For example, suppose the current order is a 50” wide order, and the only slabs available are 88” wide. The current order requires a companion order of 38” wide to be used to make the application. Once a companion order is started, it is favorable to continue using that started companion order, instead of starting a new companion order each time. To accomplish this, the feasible list of applications needs to be revisited after every application is made. Part of the application score is made up of the quality of the match. The component that measures the quality of the match favors companion orders that have already been started. Once a companion order is chosen for the current order, any additional feasible applications for the current order that contain the started companion order will be more favorable. This reshuffling of application scores between applications has interesting implications to the algorithm. Orders are constantly being resorted, meaning the next order to be applied may no longer be next after the current order is finished being applied. Table VI illustrates the correct use of companion orders.

ORIHierarcTableVI

A special case of an asymmetric application case is where the companion order is a stock cut (not assigned to an order). The standard slab sizes define valid widths and grades for stock cuts. These valid stock cut sizes attempt to ensure that any stock cut placed into inventory will have a very good chance of being used in the near future. In practice, the algorithm only makes applications with stock cuts to satisfy an order that is nearly complete. Future orders are considered as companion orders before a stock cut is made. Applications with stock cuts prove useful for improving order completion, but they make up less than 1% of the total applications generated by the algorithm.

A Hierarchical Approach

There is an inherent hierarchy in applying slabs. Single slabs get applied first, since they are the most constrained inventory. Symmetric doubles and triples come next, since all pieces are usually for the same order, which improves slabhandling logistics. Asymmetric doubles are the least desirable applications, since in most cases both pieces will end up on different hot strip mill schedules.

Although, even initially, the slab application algorithm was executed several times based on the grouping of orders by metallurgical families and hot strip mill schedule week, the first implementation of the algorithm made all of the applications (singles, symmetric doubles, symmetric triples, and asymmetric doubles) in one pass. Initially, the slab application hierarchy was incorporated into the application score, and the algorithm applied slabs in the correct order based on this score. This implementation spent a majority of the execution time generating the feasible applications. At this point, execution time was approaching an hour or more for some problems. Although this approach worked well for applying slabs to customer orders, the execution time quickly pointed out that something needed to be done to improve performance.

In order to reduce the execution time, the slab application algorithm is called several times, and each pass deals with a specific type of application. Generating the feasible singles and symmetric double applications can be done very quickly since the number of potential feasible applications is small. The symmetric double applications are on the same order of complexity as the singles, since an order is paired with itself and checked against every slab. The combinatoric nature of the problem does not start to explode until the asymmetric applications are made. Figure 3 illustrates the breakup of the algorithm into a hierarchy of passes. Passes A and B take a relatively short amount of time to execute, since they have less feasibilities to consider. Pass C is where the bulk of the execution time is spent. The less orders and slabs available to this pass, the quicker it executes. Why spend the time generating asymmetric feasible applications for an order that can be completed with all single slabs?

ORIHierarcFig3

In the first pass, all of the single applications are made. In the next pass, all of the symmetric applications are made. And in the last pass the asymmetric applications are made. In the asymmetric pass, all orders and slabs that have been applied as singles or symmetric applications have been eliminated from consideration. For every slab that does not have to be considered for asymmetric applications, this eliminates the number of feasible applications that have to be considered by the number of orders squared. In a typical problem size, each slab that is eliminated from the asymmetric step will eliminate the generation and processing of 810,000 feasible applications! Every order that is completed in the first two passes also contributes to reducing the number of feasible applications considered in the third pass. This dramatically reduces the time required to generate all feasible asymmetric applications.

Triple applications are limited by having three equal widths applied to the slab. This restriction comes from slab handling logistics and reducing the complexity of the algorithm. At 104 inches wide, a triple application would consist of three 34.5 inch wide pieces. The majority of orders in the typical order book are too wide to be made at this width. A slab must be at least 75 inches wide to be slit into a triple, since the minimum slab width to be rolled on the mill is 25 inches wide. Although it may appear that doing triples would require considering O3 x S applications, the number is far fewer, since the number of orders that are candidates for triples is small. Restricting triples to be equal widths only also greatly reduces the number of candidates to consider. Expanding the algorithm to made triple applications with three different width pieces, would have significantly impacted computer execution time and complicated slab handling logistics, while adding very few more applications to the solution. Also, these asymmetric triples would have negatively impacted down stream operations. Allowing three different orders into a triple is strictly for order completion purposes. It is hard to complete an order that needs 11 slabs if all applications are being made with triples.

Execution time for normal runs average 5-10 minutes on a current PC (1.4Ghz). An inventory planning run, that looks at orders up to 6 weeks in the future, executes in less than 20 minutes on a current PC. The execution time includes the database interaction required for reading the open orders, reading the available slabs, and writing applications. Typically, the database interaction takes 5-10% of the total execution time.

Slab Application Algorithm Implementation

Once the algorithm for applying slabs to orders was completed, it was implemented for several distinct functions:

Hot strip mill slab application

The first use of the application algorithm is the daily hot strip mill scheduling run which interfaces with the hot strip mill scheduling systems. Every morning, slabs are applied to open orders, which are ready to be scheduled on the hot strip mill. This run results in many more slabs being applied to orders than are to be scheduled on that day. The goal of this run is to see which orders can be covered by existing inventory. Orders that can be applied reserve the slabs, which are assigned to them so they cannot be applied manually during the day. These potential applications are sent into the hot strip mill scheduling system to build the required schedules for the day. Once the schedules are built, the orders which were scheduled are sent through the application process again. This time the goal is the find the best slabs for the orders that were scheduled. Any orders that were not scheduled, have the slabs reserved for them released, to make them available for application the next day.

One of the goals of the algorithm is to complete as many orders as possible. The interaction with the hot strip mill scheduling system is one of the driving forces behind that goal. Ideally, only complete orders will be scheduled on the hot strip mill. This way, the whole order can proceed through additional processing steps as a single unit. The scheduling of incomplete orders results in logistical problems downstream. There are two schools of thought for completing orders: apply small orders first or apply large orders first. Applying the small orders first, has the potential for having more complete orders to schedule, but tends to leave the large orders incomplete. Applying the large orders first has the potential for having one partially applied large order and a bunch of small orders left with nothing applied.

The primary goal of the second application run is to improve pile utilization. The orders that were scheduled have slabs available to them; the second run tries to find better ones, if any are available. The trivial case that exemplifies the purpose of the second slab application run is where two identical orders are filled out of one pile in the first run. If the order on the bottom of the pile is scheduled and the order on top is not, the scheduled order should pick the slabs from the top of the pile. Since the orders are scheduled, the second application run must apply at least as much weight as was applied during the first run. Any weight shortage results in a hole in the hot mill schedule that must be dealt with manually.

In the second application run, the orders that have been scheduled on the hot strip mill are the only ones trying to be completed. The other orders are treated only as companion orders. When the feasible applications are built, only applications that have at least one scheduled order are considered feasible. Those feasible applications consisting entirely of scheduled orders are favored over feasible applications that contain one or more non-scheduled orders. The slabs being considered in the second run are not limited to those applied in the first run. All available slabs are considered for application, though slabs that were applied in the first run are slightly favored. Since the second application run only deals with a subset of the feasible applications of the first run, there is the possibility that orders will be processed in a different order.

Inventory planning function

The application algorithm is also used for short term inventory planning. Residual open orders from the normal application run are applied to available residual slab inventory. This clearly identifies which near term order requirements need to be produced on the casters. Orders which cannot be fulfilled by the inventory planning run form the input to the heat building system mentioned above. Additionally, slabs which cannot be applied to any orders in the next six weeks can easily be identified to slab providing supervision for review. The results of the inventory planning run is a very useful report illustrated in Table VII. This inventory planning report is one of the main tools used for making daily production scheduling decisions.

ORIHierarcTableVII

Every standard slab size has a line in the report. The report gives a brief summary of what is happening with each size, including: planned production, physical inventory, and upcoming orders. This report is delivered as an intranet report, and all columns can be drilled down to view more detail. Clicking on order tonnage will display individual orders. Clicking on slab tonnage will show individual slabs and the orders they are applicable to. Clicking on heat tonnage will show planned slabs by heat and the planned production date and time. From the example in Table VII, the following conclusions can be made

  • S1 appears in good shape since planned caster production will meet the past due and current order requirements.
  • S2 shows that some of the unscheduled tonnage needs to be scheduled in order to meet past due order requirements.
  • S3 needs to have heats created to meet current requirements.
  • The 60 remaining tons for S2 and the 100 remaining tons for S3 should be examined to see why they are not used for current orders.

Slab feasibility statistics

In the normal application mode, some interesting statistics are gathered by the system. A history of all slabs that are available to the system is kept. Each slab has two counters, one for the number of times it was available to be applied by the system, and one for the number of times it was feasible for at least one order. Typically, a slab’s desirability is primarily based on age. These feasibility statistics provide a better measure for how well a slab is applicable to orders. For example, a slab that is 21 days old and has never been feasible for an order is considered less desirable than a slab that is 45 days old and has been feasible 20 times. The first slab does not fit any current orders, while the second fits current orders, but was not considered the best slab. There are many reasons why a slab may be feasible many times, yet never applied to an order. The main reason typically is pile related. The slab is either at the bottom of a pile, or is in a very heterogeneous pile and cannot be used in a single run of the application system. The main use of these statistics is for identifying distressed slabs to be used in the distressed application system.

Distressed application

In the normal application mode, all slabs are applied with no yield loss. The entire slab is applied to customer orders. To better utilize distressed and non-standard inventory, the algorithm has the capability to make applications to orders by making scrap cuts. These scrap cuts are made either transversely or longitudinally. Although both a transverse and longitudinal cut can be made on the same slab, the algorithm does not do this automatically. These scrap cuts differ from the stock cuts mentioned above because these scrap cuts will not be placed back into the slab inventory. The distressed application run can be used in two modes, slab-based or order-based.

In the slab-based mode, the goal is to use up old and non-standard inventory. Applications are chosen primarily by yield. No consideration is given to order completion or pile logic. Slabs are chosen for distressed application by age and slab feasibility statistics. Typically orders will be considered much further in the future than would be applied to normal slabs. The goal is to find something to which these distressed slabs can be applied.

In the order-based mode, small orders (requiring three slabs or less) that are about to have a heat melted are given one last look through the inventory to find a slab that could be applied at a yield loss. Distressed slabs are only applied to orders if the whole order can be completed by distressed slabs. Slabs are chosen primarily by yield and slab age. A tradeoff exists here of whether it is better to take a yield loss on a ‘good’ slab that could be applied with no yield loss or apply the slab with a yield loss to avoid melting a heat. Melting the heat to fill the order will result in slabs being applied with no yield loss, but may result in non-standard slabs being added to the inventory.

Implementation Results, Benefits and Potential Enhancements

The normal application run began regular production use in the second half of 1999. After a gradual ramp-up, the system has been, for the most part, meeting its target of 60-70% application rate. Table VIII shows the actual application rates achieved by the system. During the six years the system has been in use, the algorithm has performed well through a variety of business conditions, operating changes (the addition of the wide caster in 2001 for example), and inventory levels. During inventory rich situations, the slab application algorithm does a good job applying the best slabs to the current orders and pile logic becomes much more important. During inventory lean situations, the system makes good decisions about which orders should be applied given what slabs are available. Pile logic is less of an issue in inventory lean situations since the algorithm typically applies all available slabs.

ORIHierarcTableVIII

Customer service was improved by ensuring the right slab is available at the right time to the application system. This was impossible to duplicate in the manual application mode because of the massive reapplication effort that is required. If the correct size slab is not available, the algorithm has the flexibility to find an alternative size that fits with a companion order. Better utilization, increased visibility through intranet reports, and feasibility statistics of the slab inventory has also led to reductions in slab inventory.

During the first six years that the slab application algorithm has been in use, several improvements have been suggested. Currently, there is very little backtracking in the application algorithm. Backtracking would undo some of the applications already made to go back to a point where a different solution path can be taken. Primarily, once a slab is applied to an order, that application is usually fixed if enough applications can be made to complete the order. An application is undone if an order requires one more slab and the next feasible slab to apply is for a double application. Since applying the double application would cause too much weight to be applied to the order, a single application will be removed to free up enough weight for the double application to be applied. Backtracking beyond the trivial amount just described has not been implemented because of execution time concerns. Instead, the generation of multiple solutions based on different sort strategies was considered.

Adding different sort strategies to determine the sequence in which orders get processed was tried in an off-line mode. The system generated several different solutions based on different sort strategies. The individual solutions were ranked and the best solution chosen. There were two reasons why this approach was not put into production: 1) the algorithm was able to reliably satisfy the goals of the system using the single strategy approach, and 2) the additional execution time required for generating multiple solutions did not result in a significantly better solution.

For the interested reader

  • G. Dutta and R. Fourer, “A Survey of Mathematical Programming Applications in Integrated Steel Plants”, Manufacturing& Service Operations Management, V 3, N 4, pp 387-400, 2001. F. J. Vasko, M. L. Creggar, K. L. Stott, and L. R.
  • Woodyatt, =Optimal Assignments of Slabs to Orders: An Example of Appropriate Model Formulation=, Computers and Industrial Engineering, V 26, N 4, 1994.
  • F. J. Vasko, J. A. McNamara, R. N. Parkes, F. E. Wolf, and L. R. Woodyatt, =A Matching Approach for Replenishing Rectangular Stock Sizes=, Journal of the Operational Research Society, Vol. 51, No. 3, pp.253-257, 2000.
  • F. J. Vasko, D. D. Newhart, K. L. Stott, and F. E. Wolf, =A Large-Scale Application of The Partial Coverage Uncapacitated Facility Location Problem”, Journal of the Operational Research Society, Vol. 54, No. 1, pp. 11-20, 2003.
Francis J. Vasko is a Professor of Mathematics at Kutztown University of Pennsylvania. Before coming to Kutztown University in September 1986, he worked for more than eight years as an employee in the Research Department at Bethlehem Steel solving a variety of real-world applications in operations research. (He served as a consultant to Bethlehem Steel Corporation from September 1986 thru March 2003.) Dr. Vasko’s current research focuses on using a large variety and combination of combinatorial optimization techniques in order to more accurately model and solve important realworld applications in production planning, strategic planning, and resource allocation.
Arthur J. Hamm is a Quality Improvement Engineer working in the Sparrows Point Quality Assurance Department. He has been at Sparrows Point for 41 years and has been user representative or user chairman of many major systems development projects since 1974: order entry, metallurgical dressing, laboratory testing and control, inventory management, chemical analysis, etc.
Kenneth L. Reitmeyer is an Information Specialist with Electronic Data Systems in the Manufacturing Applications Industry Group working on the Sparrows Point account. Before joining EDS, Ken worked as a Research Engineer at Bethlehem Steel’s Homer Research Laboratories. During his career with Bethlehem Steel and EDS, his work focused on designing custom algorithms for solving real-world production scheduling, production planning, and inventory management applications.
L. Richard Woodyatt is currently the Technical Director of Pikewood, Inc. Prior to that, he was a Senior Consultant at Bethlehem Steel’s Homer Research Laboratories. Throughout his career, Dr. Woodyatt has specialized in the mathematical modeling of metallurgical processes and, for the past two decades, he has focused on the design and implementation of automated order processing, production scheduling and inventory management systems for the steel industry.
First published to members of the Operational Research Society in OR Insight July- September 2005