WO2006002688A2 - Incompatibility processing - Google Patents
Incompatibility processing Download PDFInfo
- Publication number
- WO2006002688A2 WO2006002688A2 PCT/EP2004/051319 EP2004051319W WO2006002688A2 WO 2006002688 A2 WO2006002688 A2 WO 2006002688A2 EP 2004051319 W EP2004051319 W EP 2004051319W WO 2006002688 A2 WO2006002688 A2 WO 2006002688A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- compatibility
- orders
- cross
- order
- vehicles
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
- G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06312—Adjustment or analysis of established resource schedule, e.g. resource or task levelling, or dynamic rescheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06316—Sequencing of tasks or work
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/083—Shipping
- G06Q10/0835—Relationships between shipper or supplier and carriers
- G06Q10/08355—Routing methods
Definitions
- the present invention relates to the field of transportation planning and optimization (TPO).
- TPO transportation planning and optimization
- the goal of transportation planning and optimization is to find a feasible transportation plan with minimum costs.
- a transportation plan assigns transportation or ⁇ ders to vehicles and determines the scheduling of the involved logistic activities.
- Such a plan is called feasible, if it satisfies the desired technical constraints, like e.g. the loading capacities of vehicles.
- the desired technical constraints like e.g. the loading capacities of vehicles.
- compatibilities or incompatibilities There is a large variety of different constraints which may be de ⁇ noted as compatibilities or incompatibilities.
- certain product groups may not be shipped together on the same vehicle, or ⁇ ders of specific incoterms, i.e., specific contractual trade regulations, are not to be com ⁇ bined into same shipments, locations may not have special equipment to unload specific products, etc.
- Compatibility can not only be (in)compatibility in itself, but also, for example, a require ⁇ ment for special transportation conditions like vehicle, or the definition of a specific indi ⁇ rect shipment mode in multimodal transportation. The last possibility makes this especially important in transportation scenarios involving multi-cross-docking. These constraints should be taken into account efficiently during TPO.
- the main aim of TPO is to create an optimal transportation plan, which contains in particular route, scheduling and capacity information.
- the main objects which are involved in TPO and which are important from compatibility point of view are: order: represents transportation order in form of freight unit, which contains all plan- ning-relevant information, derived from original order document (like sales order, de ⁇ livery, stock transfer order, etc.) information. Order number uniquely identifies corre ⁇ sponding order in planning system and can be used to get data for this order.
- - vehicle represents capacity, availability and other information which corresponds to physical vehicles performing transportation (trucks, rail, etc.)
- cross-docking location represents possible location (warehouse, plant, carrier, distri- bution center, etc.), where goods can be reloaded.
- Cross-docking location number uniquely identifies corresponding location in planning system.
- TPO The result of TPO are shipments, which contain information on assignments of orders to vehicles, corresponding activities (like goods issue, receipt, transport, empty leg and so on) and other planning information like stages, carriers, deadlines, etc.
- One object of the present invention is to overcome the restrictions as described above. This object is achieved by the methods and apparatuses according to the claims.
- each order being defined by a predefined number of character ⁇ istics, one of the characteristics specifying freight units to be transported from a predetermined place of departure to a predetermined place of destination, each freight unit representing a predefined good, a plurality of vehicles for transporting freight units, and a plurality of cross-docking locations for loading/unloading freight units onto/from vehicles,
- the transportation plan defining shipments, each shipment specifying the vehicles, and cross-docking locations needed for fulfilling the plurality of orders, whereby a number of freight units, vehicles, and cross-docking locations are incompatible to each other such that they are not allowed within the same shipment;
- each of the freight units, vehicles, and cross-docking locations being specified by attributes which are comprised in a field catalogue;
- the modeling method comprising the following steps:
- the field catalogue providing data field attributes, each of the attributes representing one of
- each compatibility type being de- scribed by values of the data fields as defined in the provided compatibility type data structure;
- each compatibility rule specifying a combination of two values which refer to first and second attributes of a defined compati- bility type, and being indicative whether or not they are compatible
- compatibility rules being applied upon determining compatible combinations of freight units, vehicles, and cross-docking locations for the shipments of the transportation plan.
- the compatibility type data structure further provides a data field for an ID for identifying the respective compatibility type.
- the compatibility type ID may be a numeric value.
- the compatibility types may comprise at least one of
- a compatibility rule may further comprise a condition ID for restricting the applicability of the compatibility rule onto predefined orders,
- each order being defined by a predefined number of character- istics, one of the characteristics specifying freight units to be transported from a predetermined place of departure to a predetermined place of destination, each freight unit representing a predefined good, a plurality of vehicles for transporting freight units, and a plurality of cross-docking locations for loading/unloading freight units onto/from vehicles,
- the transportation plan defining shipments, each shipment specifying the vehicles, and cross-docking locations needed for fulfilling the plurality of orders, whereby a number of freight units, vehicles, and cross-docMng locations are incompatible to each other such that they may not be allowed within the same shipment;
- each of the freight units, vehicles, and cross-docking locations being specified by attributes which are comprised in a field catalogue;
- each compatibility rule specifying a combination of two values which refer to first and second attributes of a defined compati ⁇ bility type, and being indicative whether or not they are compatible;
- the groups of orders are represented by an object-oriented model, the model comprising as one object the group of orders, and as second object an incompatibility matrix, the matrix representing the incompatibilities between pairs of groups; as third object a data structure representing incompatibilities between vehicle and orders, and between orders and cross-docking locations; and as fourth object incompatibili ⁇ ties between cross-docking locations and vehicles.
- each order object comprises a data field which specifies the group;
- the incompatibilities matrix object comprises for each pair of order groups an information as to whether they are compatible or not;
- each order object comprises a set of legs referring to relevant compatible cross-docking locations; and leg objects which comprise a set of compatible vehicles.
- This model includes:
- the present invention allows very generic modeling in a straightforward manner, without loosing efficiency in the optimization and planning.
- the main advantages of the present invention are:
- the user describing a transportation optimization prob ⁇ lem is very flexible because he is not restricted to the compact modeling used by the opti ⁇ mizer - instead, he can use the very generic modeling approach.
- the developer of the optimizer has no need to care about numerous different compatibility con- straints. The developer can focus on implementing the four atomic compatibility con ⁇ straints.
- the invention comprises also computer systems for performing the inventive methods.
- the invention comprises computer-readable storage media comprising pro ⁇ gram code for performing the inventive methods, when loaded into a computer system.
- Fig. 1 illustrates the definition of compatibility types
- Fig. 2 illustrates the definition of compatibility rules
- Fig. 3 illustrates the processing of compatibilities in TPO
- Fig.4 illustrates an overview of the different phases of incompatibility reduction processing according to the invention
- Fig. 5 illustrates the first phase of the reduction processing
- Fig. 6 illustrates the second phase of the reduction processing
- Fig. 7 illustrates the third phase of the reduction processing
- Fig. 8 illustrates a general diagram of compatibility processing
- Fig. 9 illustrates a first subprocess of the compatibility processing
- Fig. 10 illustrates the subprocess of preparing incompatible combinations
- Fig. 11 illustrates the subprocess of processing incompatibilities with conditions
- Fig. 12 illustrates the subprocess of classifying incompatible combinations to 4 classes
- Figs. 13 to 16 illustrate the feasible path finding in a hub network model in the different phases of processing
- Figs. 17 to 19 illustrate screen shots of compatibility transaction.
- Compatibility type definition is based on field catalogue functionality (see Fig. 1).
- Field catalogue 100 contains declarations (in form of character identifiers (ID) plus additional optional information like description, check table name etc.) of various attributes of vari ⁇ ous object types, like order attribute/characteristic, which can be used in particular for compatibility type 200 and condition definitions.
- ID character identifiers
- additional optional information like description, check table name etc.
- compatibility type consists of compatibility type numeric identifier 230 with de ⁇ scription and two field identifiers from field catalogue 100, which represent (in)compatible combination of object attributes 210, 220.
- the linkage between field ID 230 and corre ⁇ sponding object attribute value is provided by field catalogue functionality.
- All possible compatibility types 200 valid for particular business scenario are identified and defined at customizing step. In a specific example, the following compatibility types may be required: 01- transportation group - transportation group;
- a compatibility rule 300 (also denoted as "(incompatibility”) represents the actual combi ⁇ nation of two values which refer to objects defined by compatibility type 200 and repre ⁇ sents the objects which may be considered as (incompatible in TPO (see Fig. 2).
- Specific compatibility rules 300 are based on compatibility types.
- possible first and second attribute values in compatibility rule should be consistent with first and second ob ⁇ ject types in compatibility type 200. For example, if first attribute of compatibility type 200 is cross-docking location 30, then first attribute values in corresponding rules 300 can only contain values which identify location. Nevertheless patterns can also be used to accelerate maintenance.
- attribute in compatibility type 300 and order attribute is realized in the way that attribute ID in field catalogue and therefore in compatibility type coincides with corresponding component in the structure of freight unit 10, or, represents vehicle 20, or, cross-docking location 30.
- vehicles 10 are sometimes also denoted as means of transport.
- freight unit structure 10 already contains most of shipping, product and other information of order, only one read of freight unit entry with compatibility attribute ID would be in most cases enough to get information, whether particular freight units contain (in)compatible attributes, and therefore should be handled correspondingly.
- not only any freight unit standard field can be used as possible (incompatibility attribute, but also additional fields in customer include can be also used and processed automatically.
- one function module is used as compatibility engine for retrieving and proc ⁇ essing them. It gets orders (in form of freight units), vehicles 20 and cross-docking loca ⁇ tions 30 as input objects (see Fig. 3). It provides output if form of incompatible combina ⁇ tions of attributes classified to four classes:
- This information can be later used by a transportation optimizer system, or in manual plan- ning in similar way.
- the optimizer In addition to the incompatible attribute combinations, the optimizer also receives the at ⁇ tributes of all orders. One value is given for each order and possible attribute. All these attributes are described in a separate table.
- the transportation optimizer has to determine feasible transportation plans, i.e. plans that satisfy all incompatibilities declared in above listed four classes.
- feasible transportation plans i.e. plans that satisfy all incompatibilities declared in above listed four classes.
- the ap ⁇ proach according to the present invention provides rich modeling capabilities since many constraints involving several different order attributes can be declared by only these four incompatibility classes.
- the approach according to the invention is proposed based on preprocessing steps in the optimizer system, which reduce the model based on above four incompatibility classes to the core of the represented optimization problem.
- the problem stated as described above is transformed into an equivalent transportation optimization problem, which is modeled in a more compact fashion and in particular allows direct application of existing transportation optimizer software.
- This solution has the advantage that the internal search logic of the optimizer (i.e. the moves) is not affected at all and that the reduction already exploits all similarities and symmetries between order attributes and incompatibil ⁇ ity constraints. Therefore a significantly lower programming effort is needed, as well as a concentration of the search process on the core of the optimization problem. The latter would cause additional efforts in the straightforward approach discussed before.
- the reduction step consists of several phases, which will be described in more detail.
- Fig. 4 gives an overview of the involved modeling layers and the phases that transform one layer into the subsequent one.
- the phases have the following purpose:
- Phase 1 shrinks the relational data. All attributes and values associated to each order are replaced by a single value for each order. This value is called group. As a result of the transformation, all orders with same group value have identical order characteristics, i.e. they have the same attributes and the same values of these attributes. The resulting model is more compact than the original input model for optimization.
- Phase 2 which is optional, builds an object-oriented model, which is used for the internal optimizer search routines. It allows fast navigation between related objects (e.g. vehicles and orders) and quick access to the orders' properties (e.g. the group is directly accessible for each order). It contains some preprocessing steps that reduce the search efforts.
- object-oriented model which is used for the internal optimizer search routines. It allows fast navigation between related objects (e.g. vehicles and orders) and quick access to the orders' properties (e.g. the group is directly accessible for each order). It contains some preprocessing steps that reduce the search efforts.
- Phase 3 further reduces the incompatibility matrix, which stores for each pair of groups whether they are compatible or incompatible. Basically, this reduction replaces groups by equivalence classes of groups, where two groups are perceived as equivalent if they have the same incompatibility relations to all other groups. As a result, each order is associated to a reduced group.
- the number of reduced groups may be much smaller than the number of groups. This reduction reduces the whole incompatibility structure among groups to the core incompatibility structure, which cannot be further reduced by any technique.
- the first phase transforms the input model for optimization to the compact input model.
- Fig. 5 gives an overview.
- the input model for optimization is the output of the compatibil ⁇ ity engine, enhanced by a table which specifies the order characteristics.
- the transportation optimizer of course gets lots of additional tables, like distance matrices, vehicle costs, time windows, etc., but here we describe only those involved in the processing of incompatibili ⁇ ties.
- the model consists of tables, each of which can be processed by looping over all rows contained.
- the compact input model basically consists of tables, but all characteristics as ⁇ sociated to the orders are replaced by a single value associated to each order. This value is called group. All those orders that have exactly identical characteristics (i.e. the same set of attributes and the same values for each attribute) are assigned to the same group. Thus, a group represents a cluster of orders with identical properties.
- the second phase transforms the compact input model to the object-oriented optimizer model, as illustrated by Fig. 6.
- the object-oriented optimizer model is used in the search process of the optimizer. It is designed to allow fast access to properties of optimization objects like e.g. orders and vehicles. Furthermore, it allows navigation between related objects, e.g. all feasible vehicles are directly reachable from a given order.
- the incompati ⁇ bility matrix allows determining whether two groups are compatible in a single step. For each order, the feasible legs are calculated. Among all possible legs those that violate in ⁇ compatibility constraints are already filtered out. For each leg, all feasible vehicles are de ⁇ termined, also based on the incompatibilities declared.
- the third phase transforms the object-oriented optimizer model to the reduced object- oriented optimizer model, as illustrated by Fig. 7.
- the object-oriented optimizer model is already suitable for the optimizer, i.e. it could be used to search for good transportation plans. However, there is still the possibility to reduce the model considerably. Therefore, the third phase analyzes the incompatibility matrix and detects equivalence classes among the groups. Then, all original groups in the object-oriented model are replaced by reduced groups (abbreviated by RGroup). This may yield a substantial reduction of the incompati ⁇ bility matrix. This supports the optimizer's search process, since all orders, which are equivalent regarding their incompatibilities to other orders, now belong to the same (re ⁇ cuted) group.
- the optimizer can detect compatibility for all equivalent orders by simply comparing their RGroup. Without this reduction, this check would always be done by looking up in the incompatibility matrix, which is fast, but not as fast as directly com ⁇ paring the RGroup attribute of the order objects.
- Data types can be adjusted taking into account attribute identifiers, values, condition identifiers appropriate for a particular im- plementation. The only requirement is that the data type length should be wide enough to fit to maximum attribute value. The following notations are used:
- Field catalogue contains attributes, which are related to planning objects, such as order, vehicle and cross-docking location.
- compatibility type was introduced to represent possible (incompatibility requirement for transportation scenarios. It's mainly consists of two attributes from field catalogue, which represent objects to be compatible or not.
- Compatibility type database structure is as follows:
- ⁇ TTRJD1 and ⁇ TTRJD2 fields are linked to TPVS field catalogue database table, field ATTR_ID through foreign key relationship. Therefore prerequisite of compatibility type definition is declaration of corresponding attributes in field catalogue.
- Compatibility type's definition is part of customizing. During particular customer imple ⁇ mentation projects, all possible compatibility types should be identified and defined.
- compatibility rules (below - compatibilities) represent actual attribute values which identify possible (incompatible object combinations.
- Compatibility definition is based on defined compatibility types.
- Compatibility database table structure is as follows:
- ATTR_VALUE1, 2 contain specific attribute values, which are (incompatible (please re ⁇ fer to Example).
- the data type of these fields should be defined in such a way, that possi ⁇ ble attribute values can be stored and unambiguously converted to/from them.
- de- sign character type of length 40 was used, as it is sufficient to store any of order attribute values, relevant for APO, vehicle ID and cross-docking location numbers.
- 'Compatible' flag means that all other possible values of second attribute in compatibility type, which were not de ⁇ clared as 'Compatible', will be incompatible (this is done to accelerate maintenance).
- Condition ID is unique identifier of corresponding condition definition, i.e. it is linked to condition header table through foreign key relation ⁇ ship.
- Compatibility definition is part of planning process. In particular it is possible to define them directly during transportation planning.
- Input data contains planning objects which are relevant for determination of compatibilities.
- planning objects which are relevant for determination of compatibilities.
- these are orders, vehicle (IDs) and cross- docking location (numbers) (also often called hubs).
- Order table contains entries in form of order number, which uniquely identifies particular order in planning system, and all transportation-planning-relevant data, such as source and destination, delivery dates, quantities, shipping information, etc. Any order field is referred below as order attribute.
- Vehicle IDs and cross-docking location numbers are also referred below as attributes.
- Input tables have following structure:
- Interface - output data - Output contains incompatible attribute values, which are classified to 4 classes relevant for transportation, plus order attributes (in form of order number- attribute-ID-value combinations).
- Output tables have following structure: Incompatible vehicle-order attributes etjncjtype ordattr:
- Table of compatibility entries lt_comp_all, for specific compatibility type lt comp (the structure is similar to database table structure, ID and planning profile fields are omitted for simplicity, as they are not used):
- Table of used attribute IDs lt_attribute_ids is filled by looping over compatibility types lt_comp_types and adding attribute Ids, ATTR IDl and ATTR ID2 to it.
- ATTRJD Ivjittributejd ( 'TTYPE')
- ATTR_VALUE isjtype-ttype
- ATTR_VALUE is Jiub Joe-hub Joe
- ATTR_VALUE1 ls_comp-ATTR_VALUEl
- ATTR VALUE2 Is_attrjd_values-ATTR_VALUE
- CONDITIONJD ls_comp-CONDITIONJD exists.
- ATTR VALUEl ls_comp-ATTR_VALUEl
- ATTRJAI ⁇ JE2 Is_attrjd_values-ATTR_VALUE
- ATTR JALlJEl ls_comp-ATTR_VALUEl
- ATTR_VALUE2 Is_attrjd_values-ATTR_VALUE
- COMPJFLAG V exists. IfTRUE, process next compatibility entry.
- ATTR JALUEl ls_comp-ATTR_VALUEl
- ATTRJDl ls_comp-ATTRJDl
- ATTR JALUEl Is _comp-ATTR JALUEl
- ATTR JD2 h_comp-ATTRJD2
- ATTRJDl ls_comp-ATTRJDl
- ATTR JALUEl Is _comp- ATTR JALUEl
- ATTRJD2 ls_ comp-ATTRJD2
- ATTRJALUE2 Is _comp- ATTR JALUE
- CONDITIONJD ls_comp-CONDITIONJD
- condition For each condition a unique virtual attribute ID and value for order is generated. If order satisfies condition, then it has corresponding virtual attribute ID-value combination. In ⁇ compatibilities with conditions are converted to incompatibilities between virtual attrib ⁇ utes.
- new attribute ID is constructed by concatenation of attribute ID and condi ⁇ tion ID (see example).
- ATTR_VALUE lv_new_attribute_valuel if attribute 2 of current compatibility type refers to order.
- new attribute value is constructed by concatenation of attribute value and condition ID (see example). 3.4.4.3.5.
- Add generated attribute for orders which satisfy current condition. 3.4.4.3.6.1. Loop at lt_orderjo_condition into ls_orderjo_condition where condi ⁇ tion Jd ls_conditionjd. 3.4.4.3.6.1.1. Append order attribute to table et_ord_attr:
- ORDNO Is_orderjo_condition-ORDNO
- ATTRJD Iv_new_attributejd2
- ATTRJfALUE Iv_new_attribute_value2
- attribute 2 of current compatibility type refers to order.
- TTYPE ls_inc_attrJd_yalues-ATTR_yALUEl
- ATTR JD Isjnc_attrjd_values-ATTRJD2
- ATTR_VALUE Isjnc_attrjd_values-ATTR_VALUE2 3.5.1.2.2.
- ATTR JDl Isjnc_attrjd_values-ATTRJD1
- ATTR_VALUE1 Isjnc_attrjd_values-ATTR_VALUE1
- ATTR JD2 Isjnc_attr id_values-ATTRJD2
- ATTR VALUE2 Isjnc_attrjd_values-ATTR_VALUE2 3.5.1.2.3. cross-docking location - Order attribute, or Order Attribute - cross-docking location. Append entry to etjncj ⁇ ub_ordattr.
- HUBJOC Isjnc_attrjd_values-ATTR_VALUE1
- ATTR ID Isjnc_attrjd_values-ATTRJD2
- ATTR_VALUE Isjnc_attrjd_values-ATTR_VALUE2 3.5.1.2.4.
- ATTRJD2 ls_ord_attr-ATTRJD
- ATTR_VALUE2 ls_ ord_attr-VALUE. If entry found, process next ls_prd_attr.
- Characteristics-based clustering of orders into groups The main task is to determine orders which have identical characteristics, and put them together into a group. Basically, the key input for this phase is the table that declares the orders' characteristics. Due to a mapping of strings to consecutive integers, the following (numeric) structure is assumed:
- Orders, characteristics and values are numbered consecutively, starting by 1.
- a row of this table has the semantic that the order with ID ORDER has the value VAL regarding its at ⁇ tribute CHAR.
- a cluster is a set of orders, which have (i) the same set of attributes, and (ii) the same value for each declared attribute, re- spectively.
- M A -> B is a mapping from A to B.
- is the number of elements from A that are mapped to B.
- End Algorithm Clustering It should be noted that this is high-level pseudo-code. Its purpose is to clarify the basic idea. Of course, several additional maps may be required to implement this algorithm effi ⁇ ciently. In particular, processing of orders requires several inverse maps that determine for a given characteristic and value all corresponding groups. All the intermediate results of this algorithm are stored in maps, which can be efficiently accessed by the next transfor ⁇ mation steps. The two loops listed in the algorithm can be unified into a single loop, which is even more efficient.
- the core optimizer engine of our TPO uses an object-oriented model, where the different objects are linked and the information needed is better accessible than in a relational-table based model.
- the OrderObject stores the OrderGroup computed in the previous step when clustering the order characteristics with their values into compact groups. Later in the process this object also stores the reduced group determined during building equivalence classes. Additionally, the OrderObject of course stores all other relevant information of the orders contained in other input tables, which aren't relevant for (incompatibilities. - The second object is the incompatibility matrix which is another representation of the table of incompatibilities between OrderGroups.
- the other two objects, the FeasibleLegsOfOrder and Feasible VehiclesOfLeg combine information of (in)compatibilities between vehicle and orders, orders and hubs and hubs and vehicle, using the hub structure and available vehicle of the underlying opti- mization problem (given in some of the other input tables).
- the (feasible) legs of an order depend on the hub-network of the problem. We can have a 'direct leg' connecting the pickup location (depot, plant, etc) directly with the delivery location (customer, etc) of the order. If hubs are available, there is the possibility to reload the order at these cross-docking locations. There exist legs from the pickup location to the reachable hubs, legs from some of the hubs to the delivery location and of course there may exist some legs between some of the hubs.
- Each of the leg can be served by some vehicles; some vehicles may not reach some hubs because of the corresponding distance matrix (e.g. a ship can only serve some harbors but no airports, the distance from the harbors to the airport were set to infinite). Additionally some incompatibilities between hubs and vehicle may be maintained in the corresponding table, which lead to a further elimination of vehicle at the legs where the specified hub is involved.
- the incompatibility matrix has two important characteristics:
- the incompatibility matrix can there- fore be reduced by eliminating the unnecessary OrderGroups, which can be done by elimi ⁇ nating the corresponding rows and columns from the incompatibility matrix.
- the next step is to detect OrderGroups with identical incompatibilities, which belong to the same equivalence class and can be treated as one single virtual incompatibility group (fur- ther called 'RGroup', abbreviated from ReducedGroup).
- 'RGroup' virtual incompatibility group
- Each equivalence class defines an RGroup.
- the incompatibility matrix can now be reduced furthermore.
- one reference member of the group with its corresponding row and column will remain in the incompatibility matrix, while the rows and columns for the other members of the RGroup will be deleted.
- the remaining incompatibility matrix (with at least one row and column) is the core in ⁇ compatibility matrix, which can't be reduced any more. Every two rows (and columns) are pair wise different.
- a typical transportation scenario includes following requirements:
- transport group FOOD is not compatible with ELECTRONICS.
- vehicle FEDEX should be used for orders of shipping conditions 01, for orders of shipping conditions 02 vehicle DHL may be used, if order destination is US ⁇ , TNT - if order destination is EUROPE, for other destinations there are no specific requirements.
- Compatibility Types database contains following entries:
- condition USA corresponds to orders with destination USA
- Input data - Suppose that there are following orders and vehicle during transportation planning:
- Table lt_inc_attr_id_yalues after condition processing (here the unique identifiers for attributes with conditions are constructed by concatenation of attribute ID/value with con ⁇ dition ID):
- the clustering algorithm produces a result, which can is shown from two different perspec ⁇ tives:
- the first perspective is the list of all clusters. For each group, the characteristics and values are given, as well as the orders that have exactly these characteristics and values.
- the first nine were explicitly generated by the first loops in the clus ⁇ tering algorithm, whereas the tenth contains those orders which are not contained ' in the first nine groups.
- This last group contains orders (in our example 5 and 15), for which no characteristics were declared in the input table.
- Hub3 must be removed including all legs where Hub3 is involved (these are the legs 'L7' - 'L9'). The remaining legs are feasible legs of the order, see Fig. 14.
- the legs L2, L5 and L6 (Hub2 is one location of the leg) can't use V2, this ve ⁇ hicle has to be removed from the set of feasible vehicles.
- Vl has to be removed from all legs.
- the final Feasible VehiclesOfLeg-objects were filled as written below:
- FeasibleLegsOfOrder objects are the objects for Ll, L3 and L4 with its Feasible Vehicle- sOfLeg objects, see Fig. 16.
- OrderGroups 9 and 13 can be eliminated since the orders using those OrderGroups (orders O9 and 014) are not selected or not performable, but OrderGroup 6 must remain, since only one of the two orders using this OrderGroup is not selected (order O6), while the other order O7 still can be performed in the current subproblem.
- This matrix is (with replacing the reference OrderGroup per equivalence class with the RGroup assigned to the equivalence class) the final reduced incompatibility matrix:
- transportation optimizer is capable to respect four "atomic" incompatibil ⁇ ity constraints, which are retrieved by compatibility engine:
- Group-Group Order group ⁇ is incompatible with order group B, i.e. it is not al ⁇ lowed to transport orders from group ⁇ on the same vehicle as orders from group B.
- Vehicle-Hub Vehicle A must not load/unload orders at hub B.
- Manual planning is direct assignment of specific freight units to vehicle of particular vehi- cle.
- the relevant objects can be collected and passed to compatibility engine.
- the engine provides as output incompatibili ⁇ ties which were encountered between particular objects. Therefore they can be displayed to alert user.
- Fig. 17 is a screen shot of a Compatibility Type definition transaction screen.
- Figs. 18 and 19 are screen shots of Compatibility definition transaction screens.
- the present techniques can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
- Apparatus of the invention can be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor. Method steps according to the invention can be performed by a programmable processor executing a program of instruc ⁇ tions to perform functions of the invention by operating on the basis of input data, and by generating output data.
- the invention may be implemented in one or several computer programs that are executable in a programmable system, which includes at least one pro- grammable processor coupled to receive data from, and transmit data to, a storage system, at least one input device, and at least one output device, respectively.
- Computer programs may be implemented in a high-level or object-oriented programming language, and/or in assembly or machine code.
- the language or code can be a compiled or interpreted lan ⁇ guage or code.
- Processors may include general and special purpose microprocessors.
- a processor receives instructions and data from memories, in particular from read-only memories and/ or random access memories.
- a computer may include one or more mass storage devices for storing data; such devices may include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks.
- Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing can be supplemented by or incorporated in ASICs (application-specific inte ⁇ grated circuits).
- the computer systems or distributed computer networks as mentioned above may be used, for example, for producing goods, delivering parts for assembling products, controlling technical or economical processes, or implementing telecommunication activities.
- the invention can be implemented on a computer system having a display device such as a monitor or LCD screen for displaying informa ⁇ tion to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer system.
- the computer system can be programmed to provide a graphical or text user interface through which computer pro ⁇ grams interact with users.
- a computer may include a processor, memory coupled to the processor, a hard drive con ⁇ troller, a video controller and an input/output controller coupled to the processor by a proc ⁇ essor bus.
- the hard drive controller is coupled to a hard disk drive suitable for storing ex ⁇ ecutable computer programs, including programs embodying the present technique.
- the I/O controller is coupled by means of an LO bus to an VO interface.
- the I/O interface re- ceives and transmits in analogue or digital form over at least one communication link.
- Such a communication link may be a serial link, a parallel link, local area network, or wireless link (e.g. an RP communication link).
- a display is coupled to an interface, which is coupled to an I/O bus.
- a keyboard and pointing device are also coupled to the I/O bus. Alternatively, separate buses may be used for the keyboard pointing device and I/O inter- face.
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/628,469 US7660732B2 (en) | 2004-06-30 | 2004-06-30 | Incompatibility processing |
PCT/EP2004/051319 WO2006002688A2 (en) | 2004-06-30 | 2004-06-30 | Incompatibility processing |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2004/051319 WO2006002688A2 (en) | 2004-06-30 | 2004-06-30 | Incompatibility processing |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2006002688A2 true WO2006002688A2 (en) | 2006-01-12 |
Family
ID=34958313
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2004/051319 WO2006002688A2 (en) | 2004-06-30 | 2004-06-30 | Incompatibility processing |
Country Status (2)
Country | Link |
---|---|
US (1) | US7660732B2 (en) |
WO (1) | WO2006002688A2 (en) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7991634B2 (en) * | 2006-08-08 | 2011-08-02 | United Road Services Inc. | Vehicle transport load optimization |
US8065237B2 (en) * | 2008-04-08 | 2011-11-22 | United Parcel Service Of America, Inc. | Systems and methods for aggregating packages in a shipping environment |
US8195496B2 (en) * | 2008-11-26 | 2012-06-05 | Sap Aktiengesellschaft | Combining multiple objective functions in algorithmic problem solving |
AU2011100399A4 (en) * | 2010-05-05 | 2011-05-12 | Simplibuy Technologies (P) Ltd | A system and method for online obtainment and publishing of information of products |
US8732093B2 (en) | 2011-01-26 | 2014-05-20 | United Parcel Service Of America, Inc. | Systems and methods for enabling duty determination for a plurality of commingled international shipments |
US9460410B2 (en) * | 2011-11-02 | 2016-10-04 | Wal-Mart Stores, Inc. | Systems, devices and methods for integrated display and management of transportation resources |
US10474985B2 (en) * | 2014-08-13 | 2019-11-12 | Sap Se | Automaton-based framework for asset network routing |
US10102332B1 (en) * | 2016-02-25 | 2018-10-16 | Toyota Jidosha Kabushiki Kaisha | Graphical user interface system for displaying a parametric modification of a vehicle model |
US10073938B2 (en) * | 2016-06-29 | 2018-09-11 | International Business Machines Corporation | Integrated circuit design verification |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5265006A (en) * | 1990-12-14 | 1993-11-23 | Andersen Consulting | Demand scheduled partial carrier load planning system for the transportation industry |
AU2291195A (en) * | 1994-04-12 | 1995-10-30 | Qualcomm Incorporated | Method and apparatus for freight transportation using a satellite navigation system |
EP0770967A3 (en) * | 1995-10-26 | 1998-12-30 | Koninklijke Philips Electronics N.V. | Decision support system for the management of an agile supply chain |
US5835716A (en) * | 1995-12-15 | 1998-11-10 | Pitney Bowes Inc. | Method and system for brokering excess carrier capacity |
EP1297472A2 (en) * | 2000-06-16 | 2003-04-02 | Manugistics, Inc. | Transportation planning, execution, and freight payment managers and related methods |
EP1751705A4 (en) * | 2004-03-18 | 2009-03-11 | Manhattan Associates Inc | Transportation management system and method for shipment planning optimization |
US20080077464A1 (en) * | 2006-09-22 | 2008-03-27 | Sap Ag | Vehicle scheduling and routing with trailers |
-
2004
- 2004-06-30 WO PCT/EP2004/051319 patent/WO2006002688A2/en active Application Filing
- 2004-06-30 US US11/628,469 patent/US7660732B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US7660732B2 (en) | 2010-02-09 |
US20070244677A1 (en) | 2007-10-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230385746A1 (en) | Dynamically Routing Salvage Shipments and Associated Method | |
US10535033B2 (en) | System and method of vessel scheduling for product distribution | |
Battarra et al. | Chapter 6: pickup-and-delivery problems for goods transportation | |
US20040215588A1 (en) | Inbound package tracking systems and methods | |
US7983942B2 (en) | Incompatibility processing | |
US20100332358A1 (en) | System and method of tracing items | |
US7809676B2 (en) | Rules engine for warehouse management systems | |
US7660732B2 (en) | Incompatibility processing | |
WO2022023820A1 (en) | Systems and methods for inventory reshuffling and rebalancing | |
Sonntag et al. | Stochastic inventory routing with time-based shipment consolidation | |
CN110738374A (en) | Method and device for assembling goods | |
CN113330471A (en) | Communication server apparatus and operation method thereof | |
CN113506068A (en) | Warehouse entry and exit method and device, storage medium and electronic equipment | |
US11164147B2 (en) | Computer storage system for generating warehouse management orders | |
Tadumadze et al. | Loading and scheduling outbound trucks at a dispatch warehouse | |
EP1969541A1 (en) | Cross docking in route determination | |
CN114693004A (en) | Logistics optimization method and device | |
US20140180956A1 (en) | Carrier capacity aware multi-stop shipment generator | |
Grunewald et al. | Multi-item single-source ordering with detailed consideration of transportation capacities | |
Heßler et al. | Partial dominance in branch-price-and-cut for the basic multicompartment vehicle-routing problem | |
Sonntag et al. | Tactical stochastic inventory routing | |
US20230419250A1 (en) | Order management system determining fulfillment plans based on item-cluster availability | |
Karak | Hybrid Vehicle-drone Routing Problem For Pick-up And Delivery Services Mathematical Formulation And Solution Methodology | |
US20230325762A1 (en) | Methods and systems for digital placement and allocation | |
CN113762877A (en) | Distribution method, device, equipment and medium for warehouse delivery station platform port |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
WWE | Wipo information: entry into national phase |
Ref document number: 11628469 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: DE |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
122 | Ep: pct application non-entry in european phase | ||
WWP | Wipo information: published in national office |
Ref document number: 11628469 Country of ref document: US |