This report has been submitted for publication outside of IBM and will probably ... outside publisher, its distribution outside of IBM prior to publication should be ...
RC 21162 (94583) revised April 21, 1998 Computer Science Con dential until April 21, 2003
IBM Research Report A Solution Architecture for Inventory Application Problems in the Steel Industry Mark Trumbo Jayant R. Kalagnanam Ho Soo Lee IBM Research Division T.J. Watson Research Center Yorktown Heights, New York 10598
LIMITED DISTRIBUTION NOTICE This report has been submitted for publication outside of IBM and will probably be copyrighted if accepted for publication. It has been issued as a Research Report for early dissemination of its contents. In view of the transfer of copyright to the outside publisher, its distribution outside of IBM prior to publication should be limited to peer communications and speci c requests. After outside publication, requests should be lled only by reprints or legally obtained copies of the article (e.g., payment of royalties).
Division Almaden Austin IBM Research
T.J. Watson Beijing Haifa Tokyo Zurich
A Solution Architecture for Inventory Application Problems in the Steel Industry Mark Trumbo Jayant R. Kalagnanam Ho Soo Lee International Business Machines T. J. Watson Research Center Yorktown Heights, NY 10598 Abstract A solution architecture for an inventory application system in the steel industry is presented. The design partitions the system into the general algorithmic part and the constraints which are speci c to the customer. Such a design facilitates reuse and supports rapid development of systems for di erent customers.
Key Words: Object-oriented software architecture, inventory application, algorithms, customer speci c constriants.
1 Introduction IAP is a collection of C++ abstract classes and algorithms that operate over them. The abstract classes, when customized as concrete instances that implement customerspeci c constraints and objectives, allow the algorithms to solve instances of commonly occurring inventory application problems in the steel industry. Steel manufacturers produce slabs, coils and sheets usually on a make-to-order basis. However, surplus items can be produced for three reasons.
Surplus materials are requested during scheduling to satisfy restrictions on machines and operations,
materials are found to be out of speci cation during production, or
orders are cancelled.
Whereas some amount of inventory is desirable to accommodate rush or regularly placed orders, in many circumstances, inventory not only has a negative impact on cash ow, but also requires storage space. Hence, from the viewpoint of mill operation, it is important to use as much of the inventory as quickly and judiciously as possible.
2 Design goals IAP was designed in the context of a one-year engagement with a major Japanese steel manufacturer. In addition to all the standard design goals { exibility, maintainability, and ease-of-use { the main design goal was to partition the system into a customerspeci c part and a more general part. The motivation for this partitioning was as follows:
First, such a partitioning achieves reuse and supports the rapid development of systems for other customers because only the customer-speci c part needs to be changed.
Second, the initial customer requested a source code deliverable. To protect IBM's intellectual property, an agreement was reached whereby the copyright of the generic part was to belong to IBM whereas that of the customer-speci c part was to rest with the customer.
Third, partitioning hides complexity of the customer-speci c problem from the algorithms. The interface provides the minimum information necessary correct, 3
ecient, and optimal operation of the algorithms. A side e ect of this partitioning is that it allows algorithm development to proceed in parallel with and in isolation from implementation of customer-speci c constraints and objectives which sometimes su er from under- or ill-speci cation and requirements creep. The philosophy behind IAP is that the implementation of the detailed constraints and objectives of each speci c customer as derived classes constitute one-o code that is of no value to IBM except for generating system integration revenue. Hence, it was not in our interest to, for example, put e ort into building an asset that embodies the complex yield calculation as a function of routing used by our customer. We instead concentrated on generating reusable software assets that embody our expertise in understanding and optimizing manufacturing processes. The IAP software architecture re ects this philosophy.
3 The inventory application problem It is most convenient to think about the IA problem as a bipartite graph in which the left hand nodes are the orders and the right hand nodes are the inventory items. If we think about the problem this way, the object model that naturally comes to mind is one in which an algorithm modi es the state of a problem/solution by labeling edges as either selected or not selected. Note that the existence of an edge tells us that, for a completely unapplied order and a completely unapplied slab, some weight from the slab can be applied to the order. 4
Figure 1: A bipartite graph of the inventory application problem Once an edge is selected in the bipartite graph, some of the edges incident to the nodes at its endpoints may become infeasible and hence need to be removed. 1 2
4 The IAP classes The major classes in IAP are described below. One possible critique of this edge labeling approach is that assumes that the number of edges can not increase as an edge is committed. This prevents easily representing complex constraints such as "orderB can only be lled by slabC if orderA is also lled by slabC and yet orderA can be lled by slabC in isolation". In practice these kinds of constraints need to be handled using search, and are out of the scope of this problem representation. 2 Another possible critique is that just enumerating the edges can become prohibitively expensive. This would be true if the problem were unconstrained. However, the real-world problems we have encounterd are constrained and such that there were approximately 250 slabs, 750 orders, and 3500 edges in a average size problem. If the problem were much less constrained there would be many more edges and this algorithmic approach would not necessarily be the best one. 1
5
An IAOrderStatic corresponds to an order in the order book that is available to be lled from inventory. An IAOrderStatic has a unique identi er. An algorithm can request an iterator over all the matches to slabs that are applicable to the order. from an IAOrderStatic. The derived class would typically contain the required physical order properties such as minimum and maximum order weight, minimum and maximum unit weight, width, and gauge.
An IASlabStatic corresponds to slab available in inventory. An IASlabStatic, like an IAOrderStatic has a unique identi er and an algorithm can request an iterator over all the matches to orders that can be satis ed by this slab. Typical slab properties available via the the derived class implementation might be slab width, thickness, length, taper, weight, and grade.
An IAMatchStatic represents a possible match between a slab in inventory and an order in the orderbook. It corresponds to an edge in the bipartite graph in shown above. The IAMatchStatic is central to hiding the complexity of the problem constraints from the algorithms because it encapsulates all the customer-speci c matching considerations. Furthermore, it is the token by which an algorithm e ects a change of state to a solution.
An IAOrderDynamic represents a partially or completely lled order, that is, an order that an algorithm has chosen to partially or completely ll by assigning to it some weight from a slab currently in inventory. An algorithm can request an iterator over all the matches to slabs that have been applied to the order.
An IASlabDynamic represents a partially or fully used slab. Some or all of the weight of this slab has been assigned by an algorithm to one or more orders. An algorithm can request an iterator over all the matches to orders that have been 6
partially or completely lled by this slab.
An IAMatchDynamic represents an applied slab/order match. The derived class minimally contains a pointer to the IAMatchStatic and a real value indicating the weight applied but may contain other information that is speci c to the slab/order interaction. An IASolution represents an IAP problem/solution. An algorithm change the state of a solution only by applying or unapplying a match. The solution manages the applied objects: IAOrderDynamic, IASlabDynamic, and IAMatchDynamic. These objects only exist in the context of a solution. An algorithm can request an iterator over any of the applied objects. The classes that derive from IASolution typically contain collections of pointers to objects derived from IAOrderDynamic and IASlabDynamic. An IASolutionSet represents a single instance of an inventory application problem and a set of solutions to that problem instance. The problem instance consists of the unapplied objects IAOrderStatic, IASlabStatic, and IAMatchStatic.. An algorithm can request an iterator over any of these unapplied objects. The derived class would typically contain collections of objects derived from IAOrderStatic and IASlabStatic and also manage which constraints and objectives are enabled for the particular solution.
In deploying IAP there is one customer-speci c class that derives from each of the abstract classes. For example for a particular customer Customer we would have the following static class diagram.
7
5 Constraints and objectives It has already been mentioned that the goal of IAP is to hide the customer-speci c complexity of the problem to an appropriate extent so that algorithms can e ectively operate on abstract base classes thus promoting rapid development and reuse. The way that this achieved is by requiring that all the constraint checking occur in the derived class implementation of IASolution::canApply. Customers typically like to be able to enable and disable certain constraints. This enabling and disabling is completely encapsulated by the behavior of the canApply function of the class derived from IASolution and hence the algorithms do not need deal with the complexity of each customers constraints. Customers typically like to be able to enable and disable certain objectives. This requirement manifests itself in the IAP architecture in the form of attributes. Attributes are essentially named member function pointers. Basically, the IA architecture allows the implementation to specify which attributes of a solution, slab, or order are currently relevant when making comparisons between those objects. This becomes useful for example in simple tasks like forming a non-dominated set of solutions, or sorting a list of applied slabs by the quality of their applications.
6 Querying the state of a solution The most important mechanisms an algorithm has for querying the state of a solution are
methods returning iterators over the IAOrderStatic, IASlabStatic, and IAMatchStatic 8
objects managed by the solution set that contains the solution, and
methods returning iterators over the IAOrderDynamic, IASlabDynamic, and IAMatchDynamic objects currently managed by the solution.
Each object returned can then be queried for its properties. An algorithm determines the applicability of a particular slab/order matching in the context of a solution by passing a pointer to the IAMatchStatic corresponding to that slab/order pair to IASolution::canApply. The amount of material which is available to apply is returned. The implementation of this method in the derived class should take into consideration the current application state of the solution. For example, if all of the material from a particular slab has been applied to orders, for all IAMatchStatic objects associated with the slab, IASolution::canApply will return zero available weight. Using IASolution::canApply permits us to generate a bipartite graph like the one shown above. Given a mechanism for assigning a weight to the edge then a host of network algorithms (such as max ow and weighted bipartite matching) become available for generating partial solutions to the IA problem. This mechanism is provided by the score operator of the IASolution class. Given an iterator over the matches and an association between the matches and a double value, the score function evaluates all the matches and gives a score to each. This score is used to set the weight to each edge. The score function can take into account any number of customer-speci c objectives such minimizing tardiness, minimizing the di erence between the requested and supplied quality, and maximizing applied weight. Because the score method operates on a collection of matches instead of a single match it can handle scoring functions that depend on binary relations between matches such 9
as sorting.
7 Modifying the state of a solution An algorithm modi es the state of a solution using IASolution::doApply and IASolution::unApply. After having determined the weight available to apply from a particular slab to a particular order using IASolution::canApply, the solution can choose to apply some or all of that weight to the order by passing a pointer to the IAMatchStatic to IASolution::doApply, along with the amount of weight. At this point, if no weight has previously been applied from this slab to this order, a new IAMatchDynamic is assumed to be created and managed by the solution. If the IAMatchDynamic existed before, the match weight is modi ed. Similarly, if either the IASlabDynamic or IAOrderDynamic did not exist, they are assumed to be created and managed by the solution. If, after querying the state of a solution, an algorithm decides that it should remove some or all of the weight that is currently applied from a slab to an order, it can do so using the IASolution::unApply method. It passes a pointer to the appropriate IAMatchStatic along with the weight to be removed from the application. This operation queries the state of the solution by locating the IAMatchDynamic match and either reducing the weight or removing it completely. The e ect of this change should also be re ected in a reduction in the applied weight returned by the IASlabDynamic and IAOrderDynamic objects associated with the IAMatchStatic that was just unapplied. The unApply method is useful for implementing backtracking.
10
8 Managing multiple solutions The operation available to an algorithm to modify the state of a set of solutions is IASolutionSet::insert. An algorithm typically receives a reference to a solution and, if it is unsure being able to make changes that will dominate all other solutions (for example, if it is addressing one objective in a multiobjective problem) it will make an exact copy of the solution in whatever state it currently was and make modi cations to the copy using IASolution::doApply and IASolution::unApply. If the solution decides that the result is worth keeping, it can invoke IASolutionSet::insert with the copy of the solution it just modi ed. It was to suppport this kind of behavior that we chose the prototype method object creational pattern over the factory method pattern [2]. Note that IASolutionSet::insert is a virtual function so the derived class can implement any desired behavior. For example, one such behavior may be automatically maintaining a non-dominated set such that on insert of a new solution, some existing solutions may be removed from the set if they are dominated by the new solution.
9 Collection classes and iterators One of the design decisions was which collection class library to use. The decision taken was not to use any and simultaneously to use them all. How so? The collections of slabs, orders, and matches are read-only from the point of view of the algorithms. The sole means available to the algorithms of changing the state of the solution are the doApply and unApply operators. Hence, the algorithms only 11
requirement was to be able to visit each element in the collection in turn, i.e., to iterate over them. The most least restrictive approach was therefor to de ne a top-level abstract template class IAIteratorMechanism that has a very restricted interface. The concrete template class IAIterator is just a smart pointer for the IAIteratorMechanism. This is similar to the approach followed in [1]. For example, the IASolution abstract class speci es that derived classes must implement the IAIterator< IASlabStatic *> IASolution::slabIterator() const method which iterates over all the slabs available in the inventory for a particular solution. In the derived class, the collection of slabs can be implemented in any way { a LEDA set, an IBM Collection Class IBag, an STL map { as long as there is a wrapper class that derives from IAIteratorMechanism that carries a reference to the actual collection and implements the first, next, valid, value and size methods. One interesting twist on the standard notion of iterators was the ability to attach an arbitrary number of lters to an iterator. This tends to simplify programming logic and performs well in situations where the lter functions are relatively simple. For example, if we have an IAIterator over any collection of integers we could easily attach a lter EvenFilter to it that returns true for even numbers and false for odd numbers. The iterator will the skip over the odd numbers and only return the even numbers.
10 IAP and reuse The choice of what information to hide and what to make available in IAP was in uenced to some extent by the nature of the problem of the customer for which the 12
original solution was developed. As such, it can be argued that for a di erent customer not enough information about the problem is available at the abstract interface and that the algorithms are hence too general to generate optimal solutions. If this is found to be the case, the natural approach is to
analyze the new problem,
determine the minimal information necessary to solve it,
subclass the current IAP abstract classes to include the new information, and
write algorithms that solve the new abstract problem
Why would one do this instead of just using a purely customer-speci c algorithm and problem representation? First, subclassing from the IAP abstract classes means that all the current IAP algorithms, while possibly too general, will still generate a solution to the new problem. This solution will serve as both as a proof of concept and rapid prototype as well as a baseline for further algorithmic development which attempts to use information not available to the original IAP algorithms. Second, the new abstract classes derived from the IAP abstract classes and the algorithms that operate over them are more likely to be reused if careful attention is paid to generating the minimum interface necessary to solve the new problem. Hence, the current set of abstract classes are one point in a dynamic hierarchy of problems. The algorithms that operate on them embody our expertise at optimally solving particular abstractions of real world problems. As the number of customer for which we have developed systems grows, so will the body of reusable abstraction and algorithms making each subsequent engagement more pro table. 13
11 Conclusion The design of the IAP software architecture is a good attempt at a reusable high-level problem class for a complex real-world problem domain. An implementation of this design is currently in use at a major Japanese steel manufacturer.
References [1] , Martin, R., (1995), Designing Object-Oriented C++ Applications Using the Booch Method, Prentice-Hall, New Jersey. [2] , Gamma, E., Helm, R., Johnson, R., and Vlissides, J., (1994), Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley.
14
15 Figure 2: The IAP architecture static class diagram
