本発明の解決しようとする技術課題、技術手段及び利点をより明確にするために、以下、図面および具体的な実施例と併せて詳細に記載する。以下の記載において、具体的な設定および構成要素の特定な詳細を提供することは、単に本発明の実施例を全面的に理解してもらうための補助に過ぎない。したがって、当業者であれば明らかなように、本発明の範囲と趣旨を逸脱することなく、ここで記載されている実施例に対し様々な変更や修正を行うことができる。また、明確化と簡潔を図り、周知されている機能と構造に関する記載を省略する。
明細書の全編にわたり言及される「1つの実施例」や「一実施例」とは、実施例に関する特定な特徴、構造または特性が本発明の少なくとも1つの実施例に含まれていることを意味すると理解すべきである。したがって、明細書の各部分に現れる「1つの実施例において」や「一実施例において」とは、必ずしも同一の実施例を指すとは限らない。また、これらの特定な特徴、構造または特性は、適宜に1つまたは複数の実施例に任意に組み合わせられることができる。
本発明の各実施例において、後述の各過程の番号の大きさは、実行順の前後を意味するというわけではない。各過程の実行順は、その機能と内在的な論理によって決められ、本発明の実施例の実施過程に対しいっさい限定を構成すべきではないことが理解すべきである。
図1を参照されたい。本発明の実施例は、配送計画生成方法を提供している。当該方法は、複数の配送車両による複数拠点の巡回で荷物を引き取り、納入する配送タスクの最適な順序を出力することができる。図1に示すように、当該方法は、下記のステップを含む。
ステップ11において、配送計画候補中の空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられているか否か、および、当該空容器返却タスクと、関連する荷物配送タスクとが所定時間内に実行されるか否かに基づいて、配送計画候補を評価して評価結果を得る。
本発明の実施例における配送タスクは、荷物を1つの拠点(例えば配送出発拠点)から別の拠点(配送目的地拠点)に交付する荷物配送タスクを含み、荷物配送タスクに対し、空容器を配送目的地拠点から配送出発地に返却する空容器返却タスクを含む可能性もある。したがって、各空容器返却タスクに対し、1つの関連する荷物配送タスクが存在するが、荷物配送タスクに対し、それに関連する空容器返却タスクが存在する可能性もあれば、それに関連する空容器返却タスクが存在しない可能性もある。ここで、上記所定時間内に実行されることには、当該空容器返却タスクと、関連する荷物配送タスクが同時に実行されること、または、当該空容器返却タスクが関連する荷物配送タスクの後に実行され且つ両者の間にその他の配送タスクが存在しないことを含む。
本発明の実施例において、上記配送計画候補を評価する際に、空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられているか否か、および、当該空容器返却タスクと、関連する荷物配送タスクとが所定時間内に実行されるか否かに基づいて、空容器返却タスクにそれぞれ大きさの異なるタスクコストを設け、それから、配送計画候補中のタスクコストを合計して得た配送計画候補の総コストを配送計画候補の評価結果とする。
ステップ12において、上記配送計画候補の評価結果に基づいて、一つまたは複数の配送計画候補を最終的な配送計画として出力する。
ここで、配送計画候補の総コストの低い順に、総コストが最も小さい配送計画候補から、一つまたは複数の配送計画候補を選択して最終的な配送計画として出力する。
上記ステップによって、本発明の実施例は、配送計画候補の総コストに空容器返却タスクの異なる配送形式でのタスクコストを考慮しているため、アルゴリズムが所望の空容器返却の配送順序を自動的に出力し、実際の物流シーンでの空容器返却ニーズを満足し、配送計画の人的作成を回避して配送計画の作成コストを低減させ、配送計画の生成効率を向上させることができる。
本発明の実施例において、上記配送計画候補は、配送タスクの実行順および割り当てられた配送車両を含む。具体的に、割り当て待ちの配送タスク(荷物配送タスクと空容器返却タスクを含む)に対し、遺伝的アルゴリズム(GA:Genetic Algorithm)または巨大近傍検索(LNS:Large Neighborhood Search)などの検索アルゴリズムを用いて、複数回の検索によって最適解に近づき、検索による複数の配送計画を取得し、これらの配送計画を配送計画候補とする。
上記検索は、所定の検索回数上限値になるまで実行してから終了してもよく、所定の検索回数上限値になる前に前倒しで終了してもよい。例えば、取得した配送計画候補が所定の条件を満たし、具体的に配送計画候補に必要とされる配送車両が所定の第1閾値以下である場合、検索を中断させ、取得した配送計画候補を出力する。また、例えば、配送計画候補中に存在する、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの数y1と、関連する荷物配送タスクと同一の配送車両に割り当てられているものの、関連する荷物配送タスクとは上記所定時間内に実行されない空容器返却タスクの数y2の和が所定の第2閾値以下である場合、検索を前倒しで終了してもよい。
検索アルゴリズムによる検索中に、現在の配送計画候補中に存在する、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの数が所定の第2閾値以上である場合、現在の配送計画候補中の配送タスクに対して調整を行い、または、現在の配送計画候補を除外する。上記調整とは、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの配送順序を調整することを含む。例えば、上記空容器返却タスクを、現在の配送計画候補中のほかの位置に挿入したり、他の配送タスクと配送順序を交換したりする。
上記総コストは、空容器返却タスクのタスクコストを含む。荷物配送後に空容器を直ちに返却するという目的を達成するために、本発明の実施例において、空容器返却タスクにそれぞれ大きさの異なるタスクコストを設ける。空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられ、かつ空容器返却タスクと、関連する荷物配送タスクとが上記所定時間内に実行されると、当該空容器返却タスクには、最小のタスクコストを有する。配送計画候補に上記タスクコストを導入することによって、本発明の実施例は、所望の配送計画を取得するように、配送計画に配送タスク同士の順序の影響を考慮する。
本発明の実施例において、空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられているか否か、および、当該空容器返却タスクと、関連する荷物配送タスクとが所定時間内に実行されるか否かに基づいて、空容器返却タスクにそれぞれ大きさの異なるタスクコストを設け、所望の配送方式をアルゴリズムに出力させる。1つの具体的な実現形態として、予め空容器返却タスクについて、上記第1配送方式で第1タスクコスト、第2配送方式で第2タスクコスト、第3配送方式で第3タスクコスト、第4配送方式で第4タスクコストを有すると設定する。ここで、上記第1配送方式として、空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられ、かつ当該空容器返却タスクと、関連する荷物配送タスクとが所定時間内に実行される。上記第2配送方式として、空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられ、かつ空容器返却タスクが関連する荷物配送タスクの後に実行され両者の間に他の配送タスクが存在する。上記第3配送方式として、空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられるが、空容器返却タスクが関連する荷物配送タスクの前に実行される。上記第4配送方式として、空容器返却タスクと、関連する荷物配送タスクとが異なる配送車両に割り当てられている。
ここで、上記第1タスクコスト、第2タスクコスト、第3タスクコスト、第4タスクコストは、順に大きくなる。以上の異なる配送方式での異なるタスクコストによれば、第1配送方式が本発明の実施例において空容器返却タスクの最も望まれる配送方式であることを示す。
空容器返却タスクのタスクコストのほかに、本発明の実施例において、配送計画候補の総コストに配送距離コストも考慮される。配送計画候補が異なると、異なる配送車両経路を有する可能性があるため、配送距離が異なり、異なる配送距離コストに対応する。上記ステップ12において、配送計画候補中の各配送タスクの配送距離コストを統計し、上記配送計画候補中の空容器返却タスクのタスクコストを統計し、さらに上記配送距離コストとタスクコストに基づいて配送計画候補の評価結果を取得する。例えば、配送距離コストとタスクコストに大きさの異なる重みをつけ、両者の加重合計をして配送計画候補の評価結果を取得する。
なお、本発明の実施例において、例えば配送にかかる時間、配送道路コスト(例えば道路が異なると、異なるコストがかかる可能性があり、高速道路の場合に別途通行費用がかかるなど)など多くの要素を評価結果に考慮してもよい。これらの要素は、検索アルゴリズムによる検索に考慮されるが、本文ではこれ以上詳細に記載しない。
1つの実現形態として、本発明の実施例は、検索アルゴリズムで生成される1つの配送計画候補(以下、現在の配送計画候補という)を取得する際に、上記配送計画候補中に存在する、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの数を決定する。当該数が予め設定された閾値を超える場合、配送計画候補中の配送タスクに対して調整を行い、または、配送計画候補を除外する。
本発明の実施例において、混載可否の判断に用いられ、上限値Mmaxを有する混載容量を予め設定し、混載不可の配送タスクの混載容量を上記上限値Mmaxに設定し、混載可の配送タスクの混載容量を、Mmaxより遥かに小さい正数Kに設定する。当該正数Kの値は、配送タスクの数Sを参照して設定され、例えばMmax/Sより小さい値である。また、配送車両に対し混載可否の判断に用いられる配送容量を設定し、配送車両の同一時刻での積荷量は、その配送容量を超えてはならない。1つの例として、混載容量の上限値Mmaxを1、混載可の配送タスクの混載容量を0.01と設定する。現在の配送計画候補中に所定制限条件違反の配送車両の決定において、配送計画候補中の配送車両毎に、当該配送車両で配送されるすべての配送タスクの混載容量を累計し、上記混載容量以上である場合、当該配送車両が配送タスクの混載不可の設定条件に違反すると決定する。
また、配送タスクの混載可否について、当該配送タスクのタスク属性によって決められてもよい。割り当て待ちの配送タスクの取得において、タスク属性を指定することができ、当該タスク属性には、混載可否の指示情報を含むことができる。空容器返却タスクに対し、関連する荷物配送タスクが混載不可であれば、空容器返却タスクも混載不可がデフォルトである。もちろん、空容器返却タスクに関連する荷物配送タスクが混載不可である場合、空容器返却タスクが混載可であると特別に指示することもできる。
1つの実現形態して、本発明の実施例は、1つの配送計画候補(以下、現在の配送計画候補という)を取得する際に、配送計画候補中に、混載容量を超えた配送車両が存在するかを判断し、配送計画候補に混載容量を超えた配送車両が存在する場合、配送計画候補中の配送タスクに対して調整を行い、または、配送計画候補を除外する。
配送計画候補中に混載容量を超えた配送車両が存在するかの判断において、配送計画候補の配送車両に対し、当該配送車両が経由する隣接拠点間の経路を決定し、当該配送車両の当該経路におけるすべての配送タスクの混載容量を累計し、上記混載容量の上限値以上である場合、混載容量を超える配送車両が存在すると決定する。または、配送計画候補の隣接拠点間の経路に対し、当該経路を経由する一つ又は複数の配送車両を決定し、各配送車両の当該経路における全ての配送タスクの混載容量をそれぞれ累計し、混載容量の上限値以上である場合、混載容量を超える配送車両が存在すると決定する。
さらに、本発明の実施例において、上記混載容量以外に多くの限定条件を設定し、配送車両がこれらの条件を満たすかを判断することもできる。この場合、まず現在の配送計画候補中に所定車両制限条件に違反する配送車両が存在するかを決定する。現在の配送計画候補中に所定車両制限条件に違反する配送車両が存在する場合、配送計画候補中の配送タスクに対して調整を行い、または、上記現在の配送計画候補を除外し、上記現在の配送計画候補の総コストの計算をしない。所定車両制限条件に違反する配送車両が存在しない場合、現在の配送計画候補中の各配送タスクのコストを統計して配送計画候補の総コストを得る。
ここで、所定車両制限条件は、車両の積荷総容積が当該車両の容積上限を超えていないこと、または、車両の積荷総重量が当該車両の積荷上限を超えていないこと、または、車両が配送タスクの混載不可の設定条件に違反しないことを含む。
さらに、本発明の実施例において、1つの配送計画候補(現在の配送計画候補である)を得た後に、現在の配送計画候補中に、所定車両制限条件に違反する配送車両が存在しないと決定すると、引き続き、現在の配送計画候補中に存在する、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの第1の数を決定する。上記第1の数が所定の第1閾値を超えると、配送計画中の配送タスクに対し調整を行うか、現在の配送計画候補を除外する。上記第1の値が上記所定の第1閾値以下である場合、現在の配送計画候補中の各配送タスクのタスクコストを統計して配送計画候補の総コストを得る。ここで、所定の第1閾値は、配送タスクの総数およびコスト要求などの要素に基づいて設定される。
なお、本発明の実施例の割り当て待ちの配送タスクは、ユーザから提供された荷物配送タスクに基づいて生成され、荷物配送タスクと空容器返却タスクを含む配送タスクであってもよい。具体的に、例えば、ユーザから提供された配送タスクに荷物配送タスクしかない場合、本発明の実施例において、荷物配送後に空容器の返却が必要な荷物配送タスクを決定し、上記空容器の返却が必要な荷物配送タスクに対し、関連する空容器返却タスクを追加し、当該関連する空容器返却タスクの実行順が、上記荷物配送後に空容器の返却が必要な荷物配送タスクの後であると標識する。
ここで、当該荷物配送タスクのタスク属性を解析し、当該荷物配送タスクに対し、空容器の返却が必要であるかを決定する。ユーザは、荷物配送タスクを提供する際に、当該タスクのタスク属性を指定する必要があり、通常、荷物配送タスクの出発拠点、終了拠点、配送時間要求、荷物容積および重量情報、混載可否、空容器の返却要否などの情報が含まれる。
空容器が荷物配送タスクの出発拠点に位置しないことがあることを考慮すると、まず空容器を他の拠点から引取りしてから、出発拠点で荷物の積荷を行って目的地拠点に配送する。従って、本発明の実施例において、ユーザから提供される少なくとも1つの荷物配送タスクを取得した後に、荷物配送前に配送出発拠点以外のその他の拠点から空容器の引取りを行う必要のある荷物配送タスクを決定する。上記配送出発拠点以外のその他の拠点から空容器の引取りを行う必要のある荷物配送タスクに対し、関連する空容器引取りタスクを追加し、当該関連する空容器引取りタスクの実行順が、上記配送出発拠点以外のその他の拠点から空容器の引取りを行う必要のある荷物配送タスクの前であると標識する。
以上の方式によれば、本発明の実施例は、ユーザから提供された荷物配送タスクに基づいて、割り当て待ちの配送タスクを生成することができるが、具体的に荷物配送タスクを含み、さらに空容器引取りタスクと空容器返却タスクのうちの一方または両方を含んでもよい。
配送タスクを検索アルゴリズム中に標識するために、本発明の実施例において、すべての配送タスクに対し、当該配送タスクを一義的に標識するタスク標識IDを割り当て、関連関係を有する配送タスクに対し関連関係を設ける。例えば、関連する空容器引取りタスクと荷物配送タスクの関連関係を確立し、関連する荷物配送タスクと空容器返却タスクの関連関係を確立する。
本発明の実施例において、検索アルゴリズムによって上記割り当て待ちの配送タスクの配送計画候補を生成するとき、検索回数の上限値を設定する。検索回数が当該上限値に達すると、検索を終了させ、配送計画候補を出力する。検索中に、収束を加速させるために、以下の方式で処理を行うことができる。
所定の検索アルゴリズムに基づいて、予め設定された捜索回数上限値まで配送計画候補の生成を繰り返す過程において、生成回数が予め設定された回数となる際に得られた配送計画候補中に、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの数が所定値を超える場合、初期値が上記割り当て待ちの配送タスクである元タスクグループ中の配送タスクを、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスク及びその関連する配送タスクとからなる第1のタスクグループと、それ以外の配送タスクからなる第2のタスクグループとの2つのグループに分け、所定の検索アルゴリズムに基づいて、第1のタスクグループと第2のタスクグループに対し、それぞれ配送サブ計画候補の生成を行い、第1の配送サブ計画候補と第2の配送サブ計画候補を取得し、第1の配送サブ計画候補中に、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクが存在すると、第1のタスクグループを上記元タスクグループとし、上記の元タスクグループ中の配送タスクを2つのグループに分けるステップに戻り、第1の配送サブ計画候補中に、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクが存在しないと、当該第1の配送サブ計画候補と全ての第2の配送サブ計画候補をまとめ、上記割り当て待ちの配送タスクの配送計画候補を取得する。
以上の方式によれば、本発明の実施例は、アルゴリズムの収束を加速させ、検索効率を向上させることができる。
以上、本発明の実施例の配送車両の配送計画生成方法を紹介した。本発明の上述した各実施例において、空容器返却要求のある荷物配送タスクに対し、関連する空容器返却タスクを追加し、配送計画の検索中に、空容器返却タスクに対し大きさの異なるタスクコストを設けることによって、所望の配送順序の配送計画を検索アルゴリズムによって自動的に生成して出力することができ、配送後に空容器をメーカーに返却するという配送要件を含む配送計画の生成効率を向上させる。
本発明の実施例は、コンピュータ読取可能な記憶媒体をさらに提供している。この記憶媒体に記憶されたコンピュータプログラムがプロセッサにより実行されると、上記いずれか1つの方法実施例の配送計画生成方法を実現する。
以上の方法に基づいて、本発明の実施例は、以上の方法を実施する装置をさらに提供している。図2に示すように、本発明の実施例による配送計画生成装置20は、配送計画候補中の空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられているか否か、および、同一の配送車両に割り当てられている場合、当該空容器返却タスクと、関連する荷物配送タスクとが所定時間内に実行されるか否かに基づいて、配送計画候補を評価して評価結果を得るための配送計画評価手段21と、上記配送計画候補の評価結果に基づいて、一つまたは複数の配送計画候補を最終的な配送計画として出力するための配送計画出力手段22とを含み、そのうち、上記所定時間内に実行されることには、当該空容器返却タスクと、関連する荷物配送タスクが同時に実行されること、または、当該空容器返却タスクが関連する荷物配送タスクの後に実行され且つ両者の間にその他の配送タスクが存在しないことを含む。
上記配送計画評価手段21は、空容器返却タスクと、関連する荷物配送タスクとが同一の配送車両に割り当てられているか否か、および、当該空容器返却タスクと、関連する荷物配送タスクとが所定時間内に実行されるか否かに基づいて、空容器返却タスクにそれぞれ大きさの異なるタスクコストを設け、配送計画候補のタスクコストを合計して得た配送計画候補の総コストを配送計画候補の評価結果とするためのタスクコスト統計手段を含むことが好ましい。
上記配送計画生成装置は、配送計画候補中に存在する、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの数を決定し、上記数が予め設定された閾値を超える場合、配送計画候補中の配送タスクに対して調整を行い、または、配送計画候補を除外するための配送計画分析手段をさらに含むことが好ましい。
上記配送計画生成装置は、配送車両に対し混載可否の判断に用いられる配送容量を予め設定し、配送タスクに対し混載可否の判断に用いられ、上限値を有する混載容量を予め設定し、混載不可の配送タスクの混載容量を上記混載容量の上限値に設定するための容量設定手段をさらに含むことが好ましい。
上記配送計画生成装置は、検索アルゴリズムで一つの配送計画候補を生成した後に、混載容量を超える配送車両が配送計画候補中に存在するか否かを判断し、混載容量を超える配送車両が配送計画候補中に存在する場合、配送計画候補中の配送タスクに対し調整を行い、または、配送計画候補を除外するための混載判断手段をさらに含むことが好ましい。
具体的に、上記混載判断手段は、混載容量を超える配送車両が存在するか否かを判断する際に、配送計画候補の配送車両に対し、当該配送車両が経由する隣接拠点間の経路を決定し、当該配送車両の当該経路におけるすべての配送タスクの混載容量を累計し、上記混載容量の上限値以上である場合、混載容量を超える配送車両が存在すると決定する。または、配送計画候補の隣接拠点間の経路に対し、当該経路を経由する一つ又は複数の配送車両を決定し、各配送車両の当該経路における全ての配送タスクの混載容量をそれぞれ累計し、上記混載容量の上限値以上である場合、混載容量を超える配送車両が存在すると決定する。
上記配送計画生成装置は、配送計画生成手段をさらに含むことが好ましい。上記配送計画生成手段は、所定の検索アルゴリズムに基づいて、予め設定された捜索回数上限値まで配送計画候補の生成を繰り返す中で、生成回数が予め設定された回数となる際に得られた配送計画候補中に、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクの数が所定値を超える場合、初期値が上記割り当て待ちの配送タスクである元タスクグループ中の配送タスクを、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスク及びその関連する配送タスクとからなる第1のタスクグループと、それ以外のタスクからなる第2のタスクグループとの2つのグループに分け、所定の検索アルゴリズムに基づいて、第1のタスクグループと第2のタスクグループに対し、それぞれ配送サブ計画候補の生成を行って第1の配送サブ計画候補と第2の配送サブ計画候補を取得し、第1の配送サブ計画候補中に、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクが存在すると、第1のタスクグループを上記元タスクグループとし、上記の元タスクグループ中の配送タスクを2つのグループに分けるステップに戻り、第1の配送サブ計画候補中に、関連する荷物配送タスクと異なる配送車両に割り当てられた空容器返却タスクが存在しないと、当該第1の配送サブ計画候補と全ての第2の配送サブ計画候補をまとめ、上記割り当て待ちの配送タスクの配送計画候補を取得する。
上記配送計画生成装置における上記配送計画評価手段21は、さらに上記総コストと配送計画候補中の各配送タスクの配送距離コストの合計を計算して配送計画候補の評価結果とする。
本発明の実施例は、配送車輌の配送計画生成システムをさらに提供している。当該システムは、記憶装置と、プロセッサと、記憶装置に記憶され、プロセッサにより実行されるコンピュータプログラムとを含み、上記コンピュータプログラムが上記プロセッサにより実行されると、上記いずれか1つの方法実施例の配送計画生成方法を実現する。
図3は、本発明の実施例による配送計画生成システムの全体構造ブロック図の1つの例を示す。図3では、コンピュータ単体を例として説明する。コンピュータ100は、プロセッサ(CPU)104と、メイン記憶装置105と、二次記憶装置106と、メインバス103と、ビデオカード107と、ネットワークインタフェースカード(NIC)108と、ビデオ出力ポート109から構成される。コンピュータ100は、NIC108を介してコンピュータの外部との間でデータの入出力ができ、ビデオ出力ポート109を介して外部の表示デバイスへ画面出力ができる。実際の構造において、図3に示すモジュール以外に、キーボード、マウスなどの入力装置をさらに含んでもよい。
二次記憶装置106には、例えば、データ入力処理モジュール1061と、計算条件設定処理モジュール1062と、最適解検索処理モジュール1063と、配送計画出力処理モジュール1064と、拠点管理データ1065と、車両管理データ1066と、配送タスクデータ1067と、道路ベクトルデータ1068など、本発明の実施例の演算処理に必要とされる各種類の入力データとプログラムモジュールが記憶されている。演算処理の実行において、二次記憶装置106のデータを、メイン記憶装置105内の入出力/計算実行処理手段1051によって適宜に読み込み、拠点間距離データ1052と併せて検索処理を行って配送計画を出力する。
本発明の実施例の以上の技術手段を理解するために、以下、いくつかの例の具体的なフローによって本発明の実施例の方法をさらに具体的に記載する。
図4を参照し、本発明の実施例の配送車両の配送計画生成方法の例示的なフローには、以下を含む。
データ読み込みステップ210において、拠点管理データ1065と、車両管理データ1066と、配送タスクデータ1067を読み込む。その後、メイン演算処理ステップ230の前処理として、計算条件設定ステップ220を行う。メイン演算処理ステップ230において、最適な配送計画を得るために、配送計画の生成を繰り返して行う。
毎回配送計画を生成する前に、ステップ231において、所定検索ループ回数の上限に達したかを判断する。達した場合、ステップ240に進んで配送計画を出力するが、達していないと、ステップ232において配送計画候補を生成する。
ステップ232において、例えばLNSアルゴリズムやGAなどの検索アルゴリズムを用いて検索して配送計画候補を取得し、ステップ233において、生成した配送計画候補が強制的制限条件に違反しているかを判断する。違反した場合、現在の配送計画候補に対し調整を行うか、現在の配送計画候補を除外し、ステップ232に戻ってあらためて配送計画候補を生成する。違反しない場合、ステップ234に進んで現在の配送計画候補の総コストを計算する。
ここで、強制的制限条件は、前述した所定車両制限条件を含んでもよい。さらに、強制的制限条件は、配送計画候補に存在する、関連する荷物配送タスクと異なる配送車両に割り当てられて入る空容器返却タスクの第1の数が第1閾値より小さいことを含む。強制的制限条件に違反して配送計画候補をあらためて生成する必要がある場合、上記強制的制限条件の違反に関する配送タスクを現在の配送計画候補中のほかの位置に挿入するか、現在の配送計画候補中のほかの配送タスクと配送順序を交換する。
ステップ235において、検索を前倒しで終了できるかを判断する。可と判断した場合、ステップ240に進むが、不可と判断した場合、ステップ231に戻る。例えば、現在の配送計画候補に必要とされる配送車両が所定の第1閾値以下であり、および/または、配送計画候補に存在する、関連する荷物配送タスクと異なる配送車両に割り当てられて入る空容器返却タスクの数が所定の第2閾値以下であれば、検索を前倒しで終了することができる。
ステップ240において、現在取得した各配送計画候補の総コストの低い順に1つまたは複数の配送計画を出力して最終的な配送計画とする。
図5〜図7は、データ読み込みステップ210で読み込まれるデータ形式の一例を示す。
図5の拠点管理データ1065は、拠点名411と、拠点の位置を示す緯度412および経度413と、拠点の所在地域414と、拠点対応可の車種(すなわち、拠点で配送を受け付けられる車種)415と、拠点の始業時間416および終業時間417と、荷卸所要時間418などのパラメータを含む。
図6の車両管理データ1066は、車両を一義的に標識するための車両ID431と、当該車両の車種432と、運転手や連絡方法433と、車両出発時の拠点434および終了時の拠点435と、車両容積の上限値436(立方メートル/パレット(荷物の荷役台)の数など)と、車輌の積載上限値437(tまたはkgなど)と、車輌の稼動開始時刻438と、稼動終了時刻439と、当該車輌の管轄地域440などのパラメータを含む。
図7の配送タスクデータ1067は、配送タスクの配送日451と、配送元の出発拠点452と、配送目的地の目標拠点453と、配送元で荷物を取得する引取り期限454と、配送目的地に交付する納入期限455と、配送荷物の容積456と、配送可能車種に限定ありの場合の車種458と、空容器返却の要否459と、他の配送タスクとの混載可否460などのパラメータを含む。
計算条件設定ステップ220において、拠点管理および配送タスクデータを使用して図8に示す入力データ500を生成する。図7の配送タスクデータ1067から、配送計画生成アルゴリズムの演算処理で空容器返却を直接計画に反映することができないため、メイン演算処理ステップ230に先立って、図9に示す計算条件設定ステップ220の処理によって空容器返却タスクを生成する。
図9に示すように、計算条件設定ステップ220において、ユーザから提供される配送待ちのすべての配送タスクを対象に演算ループ処理を行う。ステップ221において、すべての配送タスクのトラバースが終了したかを判断する。トラバースが終了した場合、図8に示すような入力データを出力するが、トラバースが終了していない場合、ステップ222において1つの未処理の配送タスクiを選択し、ステップ223において当該配送タスクiに対し空容器の返却要否を判断する。不要の場合、ステップ221に戻る。要の場合、ステップ224において当該配送タスクiに対し空容器返却タスクjを追加して生成し、ステップ225において空容器返却タスクjに対し混載可否を判断する。配送タスクiの空容器返却要否の判断は、図7の当該タスクに対する空容器返却要否459の設定を参照されたい。返却が必要な場合、空容器返却タスクを追加する。
図7の配送タスクデータ461を例とすると、空容器返却459が「要」であるため、図8の一番目の配送タスクJ001に対し次ぎの空容器返却タスクJ001_01を追加する。この場合、元の配送タスクJ001と対応するために、図8の関連タスクIDにJ001を記入する。ここで、タスク順519は、現在のタスクと関連タスクID520との順序関係を示す。例えば、NEXT541は、現在のタスクJ001_01が関連タスクID520に示されるタスクJ001の後に位置することを示す。
ステップ225において、空容器返却タスクjに対して混載可否を判断する際に、図7の混載可否460を参照して図8の混載可否521を設定する。すなわち、図9の混載可否判定処理225において、元の配送が混載不可であれば、空容器返却も混載不可になる。もちろん、本発明の実施例は、非対称の処理方式を用いてもよく、すなわち元の配送が混載不可であるのに対し、空容器返却が混載可であってもよい。
配送計画生成アルゴリズムのタスク割り当て処理において、混載不可の空容器返却タスクを他のタスクと混載しないため、容積V、重量Wとは異なる容量を導入して配送タスクに追加するが、本文ではそれを混載容量Mとする。図9の例では、すべての車輌の混載容量の上限値を1.0に設定し、ステップ226において混載不可の空容器返却タスクiの混載容量を1.0に設定する。これによって、配送タスクの混載容量が1.0である場合、容量がいっぱいになり、このとき例えば容積Vと重量Wに余裕があっても、他のタスクとの混載をできないことにする。
一方、混載可否判定処理225によって混載可と判断される場合、ステップ227において、空容器返却タスクiの混載容量を、0より大きく極めて小さい値に設定し、例えば前述したMmax/Sより小さい値に設定する。空容器返却タスクの容積516、重量517に対し個別に所定し、例えば、ステップ227において元の配送タスクの15%に統一的に設定する。
最後に、元の配送タスク、空容器返却タスクに対し、図7の引取り期限454と納入期限455のうち空いている時間帯に補完処理を行う。期限に時刻がない場合、図5の拠点管理データを参照して、当該拠点の終業時間を入力すればよい。また、例えば、空容器返却タスクに基本的に時刻の指定がないため、すべて当該拠点の営業時間を入力すればよい。各拠点の営業時間が指定されない場合、デフォルト値(例えば8:00〜17:00)に指定する。従って、図8に示す入力データを取得する。また、図8は、入力データ決定後であってメイン演算処理ステップ230の前に混載容量設定処理の例を示す。もちろん、入力データ自身にも混載容量を含んでもよい。
図9の空容器返却タスクの追加処理は、配送後に空容器の返却が必要なケース(case)である。別のケースとして、タスクを配送する前に、配送タスクの出発拠点と異なるほかの拠点から空容器の引取り(Pickup)が必要なケースであり、図7の配送タスク462のケース(case)に対応し、その一つの処理方式が図10に示される。図7の配送タスク462のケース(case)では、空容器の返却要否459が「事前要」である。具体的に、まず配送目的地拠点Bで空容器を引取りしてから、拠点Cで再び荷物を積荷して荷物を拠点Bまで配送し、最後に空容器を別の拠点lに返却する。すなわち、図10に示すように、計算条件設定ステップ220において、まずユーザから提供される配送待ちのすべての配送タスクを対象に演算ループ処理を行い、空容器引取りタスクの追加要否を判断する。ステップ221aにおいて、すべての配送タスクに対し空容器引取り処理のトラバースが終了したかを判断する。トラバースが終了した場合、図9のステップ221に進んで、さらにすべての配送タスクに対し空容器返却処理のトラバースが終了したかを判断する。空容器引取り処理のトラバースが終了していなければ、ステップ222aにおいて1つの未処理の配送タスクを選択して現在の配送タスクとし、ステップ223aにおいて現在の配送タスクに対し別の拠点から空容器の引取りが必要であるかを判断する。要と判断した場合、ステップ224aにおいて現在のタスクに対し空容器引取りタスクを追加してステップ221aに戻る。具体的に、空容器引取りタスクを追加する場合、当該タスクにおける関連パラメータに対し、空容器返却タスクにおける類似方式を参照して設定してもよい。
図7の配送タスク462に基づいて、図7の配送タスクに対しそれぞれ空容器引取りタスクJ002と空容器返却タスクJ002_02を生成する。ここで、空容器の引取り、荷物配送、空容器返却を順に行うために、J002_01とJ002_02の関連タスクIDに対し、その前に行われるタスクのタスクIDを設定する。実際の配送において、配送後に空容器を拠点lに返却する必要がなく目的地拠点Bまで配送した段階で終了するシーンや、配送目的地拠点Bではないほかの拠点で空容器の引取りを行うシーンなどが存在する。以上の様々なありうるシーンに対し、業務要件に応じて適応的に変更して適切な入力データ500を出力すればよい。本例において、計算条件設定ステップ220によって配送タスク1067に基づいて入力データ500を生成するシーンを示す。しかし、具体的に実施する際に、計算条件設定ステップ220を飛ばして直接上記入力データ500を入力してもよい。すなわち、直接タスク順519、関連タスクID520を入力することによって、空容器返却タスクなど複数のタスクの間の関連関係を定義してもよい。
図11は、メイン演算処理ステップ230に必要とされる拠点間距離行列データ1052のデータ形式の一例を示す。拠点間距離行列データとは、拠点のすべての組み合わせに対し、距離(または走行時間)を数値化して形成された二次元行列データである。2つの拠点の間で往復する走行経路が異なることがあるため、拠点の数をNとした場合、すべての距離の数は、N*(N−1)個である。道路ベクトルデータを入力とし、最短経路計算法(例えばダイクストラ法)を用いたプログラムで2つの拠点の間の距離を求める。当該データ1052について、メイン演算処理ステップ230に先立って拠点管理データ1065を用いて生成されるか、生成済みのデータを入力し、メイン記憶装置の入出力/計算実行処理手段1051に読み込まれることによって、直接高速な演算処理を行うことができる。
図9に設定された混載容量などのパラメータは、メイン演算処理ステップ230における強制的制限条件違反処理ステップ233に用いられる。ここで、強制的制限条件は、前述した所定車輌制限条件を参照して設定してもよく、車輌の積荷総容積が当該車輌の容積の上限を超えないこと、または、車輌の積荷総重量が当該車輌の積荷の上限を超えないこと、または、車輌が配送タスクの混載不可の設定条件に違反しないことを含む。上述のいずれか1つの条件に違反すると、強制的な制限条件に違反することを示す。
図12は、空容器混載可否判定処理の一例を示す。配送計画候補生成232の出力である配送計画候補に対し、各配送タスクに割り当てられた車輌を逐一に確認し(ステップ2331)、車輌の容量上限を超えたり(ステップ2332)、積荷上限を超えたり(ステップ2333)、混載容量上限を超えたり(ステップ2334)すると、強制的制限条件に違反したと判断し(ステップ2336)、再び配送計画候補生成232に戻る。逆の場合、強制的制限条件を満たしたと判定し(ステップ2335)、総コスト計算ステップ234に進む。もちろん、本発明の実施例は、配送計画候補生成232において上記の強制的制限条件違反の判定233そのものを実施してもよい。
具体的に、図15の出力データ550を例とする場合、現在の配送計画候補によって割り当てられたすべての配送車輌に対し、時系列順564に従って容積の増減570を加算して総容積を取得し、重量の増減571を加算して総重量を取得し、状態565が移動中であるとき、上記総容積と総重量が当該車輌の容積Vの上限値と重量Wの上限値(362、363)を超えたかを判定する。類似に、混載容量Mに対し、同様に混載容量の上限値を超えるかを判定する。また、図9の処理ステップ227において、混載容量を0に設定すると、ステップ2334の判定において、混載容量が1であるケースがあっても、現在の車輌が混載することができるので、混載可の車輌の混載容量を、1以下の小さい正数(例えば0.001)に設定する。図12において、配送計画候補生成ステップ232に戻るタイミングは、車輌のあるパラメータが対応する強制的制限条件に違反した時点だったり、対応する強制的制限条件に違反した車輌が一定数に達した時点だったり、配送計画候補においてすべての車輌についての判断が終了した時点である。
総コスト計算234の処理フローの一実現形態は、図13に示す。総コスト計算234において、配送計画候補生成232によって出力された配送計画候補の各配送タスクに対し、最適解から見れば、配送タスクの割り当て順に一定の差異を有し、当該差異を数値化して、演算ループ処理において合計総コストとして出力する。まず、ステップ23401においてすべての配送タスクが処理済みであるかを判断する。処理済みである場合、総コストを出力してステップ235に進む。処理済みではない場合、1つの未処理の配送タスクを抽出して現在の配送タスクとし、ステップ23402において当該現在の配送タスクが空容器返却タスクであるかを判断する。空容器返却タスクであるかについて、図8の例では、タスク順519がNEXTであること、かつ関連タスクID520に対応するタスクIDを指定することによって判定することができる。
ステップ23402において、現在の配送タスクが空容器返却タスクではないと判断すると、ステップ23401に戻るが、逆の場合、ステップ23403に進んで、当該空容器返却タスクに関連する配送タスク(以下、元の配送タスクという)を同一の車輌に割り当てるかを判断する。具体的に、後述の出力データ550のデータ形式では、上述した対応する2つの配送タスクが同一車輌ID562に属するかによって同一車輌であるかを判断することができる。同一車輌ではない場合、最適解がない(最適解には程遠い)と判定し、予め設定されたコストαを総コストに加算して(ステップ23404)ステップ23401に戻る。同一車輌である場合、最適解に近いため、総コストからαを減じるか、別の設定値(例えばαの30%)を減じる(ステップ23405)。ここで、総コストに対するαの加算や減算は、総コストに対し行われるため、同一車輌ではない場合、一方のみを実施してもよい。同一車輌判定処理の後に、ステップ23406に進んで、空容器返却タスクが元のタスクの後に実行されるかを判断する。出力データ550のデータ形式では、同一車輌ID562の順序564によって各配送タスクの前後順関係を判定することができる。前後順の判定は、対応する元の配送タスクの荷卸の後に当該返却タスクの積荷があるかによって決められる。当該判定において、荷卸と積荷の間に他の配送タスクを有してもよく、時間的に空いてもよい。空容器返却タスクが元のタスクの前に実行される場合、最適解に程遠いため、総コストにβを加算し(ステップ23407)、ステップ23401に戻る。また、空容器返却タスクが元のタスクの後に実行される場合、上記判定同様に、総コストからβを減算する(ステップ23408)。最後に、ステップ23409において、当該空容器返却タスクと、関連する荷物配送タスクとが上記所定時間内に実行されるかを判断し、空容器返却タスクと空容器返却タスに対応する荷物配送タスクの間に他の配送タスクがなく、空容器返却タスクが空容器返却タスに対応する荷物配送タスクの後に直ちに実行されるかを判断する。具体的に、空容器返却タスクが対応する荷物配送タスクの後に直ちに実行されるかの判定において、対応する荷物配送タスクの荷卸の後に直ちに空容器返却タスクの積荷を行うかによって判断できる。両者の間に他の配送タスクがある場合、総コストにγを加算し(ステップ23410)、ステップ23401に戻る。逆の場合、総コストからγを減算し(ステップ23411)、ステップ23401に戻る。
上記3つの判定処理23403、23406、23409において、事前に決められた常数α、β、γをコストの数値とし、最適解の検索処理において最適解に徐々に接近する方式で、異なるコストを設定する(α>>β>>γが好ましい)。したがって、上記メイン演算処理ステップ230において、同一車輌に対する元のタスクの割り当てと空容器返却タスクを優先的に実施する。次に、配送タスクと空容器返却タスクの前後関係を実現することができる。最後に、両者の間に他の配送タスクがない配送順序を考慮する。ここで、コストβに関する判定処理23406〜23408は、高速かつ確実に最適解に収束するための処理である。
配送タスクの数が比較的多い場合、総コスト計算234のみでは最適解に収束することが難しい可能性があり、配送計画に配送順序不一致が存在することがある。ここでの順序不一致とは、空容器返却タスクと関連する荷物配送タスクが異なる配送車輌に割り当てられていることを示す。この場合、本発明の実施例は、上記の順序不一致の判定処理と併せて収束性を改善し、配送順序不一致を少なくするか0にする。図14は、上記の順序不一致判断処理と組み合わせる例を示す。ここで、配送計画候補生成ステップ232で出力される配送計画候補に対し、順序不一致が存在するかを決定する。ある場合、再び配送計画候補生成232のステップに戻り、配送計画候補生成232において当該順序不一致判断処理を実施する。
具体的に、まず、配送計画候補生成ステップ232で1つの配送計画候補を取得した後に、当該配送計画候補を現在の配送計画候補とする。まずステップ2321で現在の配送計画候補のすべての配送タスクについてトラバース終了であるかを判断する。処理済みである場合、ステップ233に進む。処理済みではない場合、ステップ2322において1つの未処理の配送タスクを抽出して現在の配送タスクとし、ステップ2323において当該現在の配送タスクが空容器返却タスクであるかを判断する。ステップ2323において当該現在の配送タスクが空容器返却タスクではないと判断すると、ステップ2321に戻る。逆の場合、ステップ2324に進み、当該空容器返却タスクに関連する配送タスク(以下、元の配送タスクという)を同一車輌に割り当てるかを判断する。同一車輌に割り当てる場合、ステップ2321に戻る。逆の場合、ステップ2325に進み、順序不一致の判断結果を出力し、配送計画候補生成ステップ232に戻ってあらためて1つの配送計画候補を生成する。配送計画候補生成ステップ232に戻るタイミングは、順序不一致の配送タスクを発見した時点だったり、現在の配送計画候補中のすべての配送タスクのトラバース処理が終了した後であったり、順序不一致の配送タスクが所定数に達した時点であったりする。以上の処理を実施したため、以降出力される配送計画候補には、順序不一致が存在しない。したがって、図13の総コスト計算において、図13のステップ23403、23404、23405を省略してもよい。
配送計画候補生成ステップにおいて、一定回数の演算ループが実行された後に取得した配送計画候補中に、一定数以上の配送順序不一致の配送タスクが存在することがあるため、メイン演算処理ステップ230を途中で前倒しで終了してもよく、入力される配送タスクデータの範囲を縮小することによって、数回に分割してあらためて演算ループ処理を実行してもよい。
入力データの分割において、例えば、順序不一致が生じた配送タスクおよびそれに関連するすべての配送タスクを1つのグループとし、残りの配送タスクを別のグループとすることによって2分割する。それから、グループごとに配送計画候補生成処理を行う。
1回目の2分割で取得したグループに対し配送計画候補を生成する際に、各グループに配送順序不一致が生じなければ、各グループの配送サブ計画をまとめて全体的な配送計画候補を取得する。例えば、2分割した2つのグループに対し5台と7台の配送車輌の配送サブ計画を取得する場合、まとめて計12台で配送処理を行う配送計画候補を取得して出力する。一方、あるグループに再び配送順序不一致が生じると、以上の方式で当該グループに対し2分割をしてもよい。以上の2分割処理は、各グループに配送順序不一致が生じなくなるまで、複数回に行われてもよい。
メイン演算処理ステップ230の後に、配送計画出力ステップ240において、図15に示す出力データ550のデータ形式で、生成された配送計画データを取得して表示処理などを行う。出力される配送計画は、1個に限られず、複数の要素に基づいて演算結果を選択することができる。例えば、走行総距離、配送総時間、車輌台数、割り当てていない配送タスクの数、順序不一致の配送タスクの数などの複数の要素のうちの1つまたは複数で適切な配送計画を選択し、出力データ550の形式で出力することができる。出力データ550では、時系列順564に従って、配送日561の配送車輌(車輌ID562)のそれぞれの稼動状態565を出力し、出力内容には、車種563、走行時の出発拠点/目的地拠点(566/567)、当該稼動状態565の開始/終了時間(568、569)、それまでの稼動状態565による容積/重量の増減(570、571)、積荷/荷卸対象の配送タスクID572をさらに含む。1つの配送タスクIDには、通常、積荷と荷卸があるため2つの異なる稼動状態が生成される。
図16A〜図16Bは、配送計画候補240において、出力データ550に基づいて生成される出力画面の一例を示す。図16Aは、時系列でガントチャート形式で各配送車輌の稼動状態を示す配送スケジュール表600であり、図16Bは、配送計画に含まれる配送拠点と配送経路を地図に示す配送経路700である。ここで、図15の車輌ID562がA0123である出力を例として説明する。配送スケジュール表600の表示では、車輌A0123(611)を縦軸のラベルにし、右側で時系列(順序564)で具体的な稼動状態を表示する。出力データ550では、積荷、移動、待機、荷卸、積荷、昼休み、移動、荷卸の計8の稼動状態が出力されるが、配送スケジュール表600では、拠点l、移動、待機、拠点A、昼休み、移動、拠点lの計7の状態が示されている。これら、表示上、「拠点A」を用いて、荷卸/積荷の2つの稼動状態を示しているためである。
配送スケジュール表600と配送経路700とは、対応することができる。例えば、配送経路700では、配送スケジュール表600の画面上の指定車輌のみが表示され、配送スケジュール表600では、横軸となる時間軸で特定時刻661を指定する場合、配送経路700で当該車輌の計画上の位置731などを示す。当該車輌の稼動状態が「移動」である場合、車輌位置731を地図上で決定するために、移動速度が一定であるときに目的地と出発地との間の経路を細分化し、出発地から当該時刻に達した地点を表示位置に設定すればよい。図16A〜図16Bは、表示画面出力の例である。ただし、同様の表示内容をPDF、紙などの出力媒体に出力してもよい。
続いて、図17のブロック図を用いて、本発明の実施例のシステムブロック図の別の実施形態を説明する。図17は、図3のコンピュータ100をサーバ/クライアントに分解したタイプの構造でり、1台のサーバ172と複数のクライアント171、173の構造を例とするシーンを示す。サーバ172、クライアント171は、図3のコンピュータ100とは基本的に同一のハードウェア構造である。クライアント171は、CPU1711/メイン記憶装置1713と、二次記憶装置1714と、メインバス1712と、ビデオカード1715と、ネットワークインタフェースカード(NIC)1716と、ビデオ出力ポート(図示せず)などを含む。クライアント171は、CPU1711と、メイン記憶装置1713と、二次記憶装置1714と、メインバス1712と、ビデオカード1715と、ネットワークインタフェースカード(NIC)1716と、ビデオ出力ポート(図示せず)などを含む。ここで、メイン記憶装置1713は、入出力処理モジュール17131を含む。二次記憶装置1714は、データ入力処理モジュール17141と、配送計画出力処理モジュール17142と、配送タスクデータモジュール17143を含む。サーバ172は、CPU1721と、メイン記憶装置1723と、二次記憶装置1724と、メインバス1722と、ビデオカード1725と、ネットワークインタフェースカード(NIC)1726と、ビデオ出力ポート(図示せず)などを含む。ここで、メイン記憶装置1723は、計算実行処理モジュール17231と拠点間距離データモジュール17232を含む。二次記憶装置1724は、計算条件設定処理モジュール17241と、拠点管理データモジュール17242と、最適解検索処理モジュール17243と、車輌管理データモジュール17244と、道路ベクトルデータ17245と、配送タスクデータモジュール17246を含む。図17では、サーバ172は、ネットワーク175(イントラネットまたはインターネット)を介して、遠隔側のクライアント171と協同して、図4に示す演算処理および出力処理を行う。
図18は、図17の処理/データの接続関係を示す。クライアント171は、まずサーバ172との接続を確立する。したがって、API1727に対しID/PWなどの認証処理が行われ、1:1で接続し、実行待機状態に入る。このとき、サーバ側において、クライアント171の専用動作のプロセス(process)またはスレッド(thread)を起動させることによって、複数のクライアント(例えばクライアント171)からの実行要求を並行に処理することができる。データ読み込み処理210において、クライアント171から拠点管理データ17242、車輌管理データ17244、配送タスクデータ17143を読み込んでもよく、図18に示す例のように、クライアント101から配送タスクデータ17143を読み込んで、サーバ172から拠点管理データ17242、車輌管理データ17244を読み込んでもよい。拠点情報、車輌情報は、通常変更される頻度が低いため、メイン(master)データとしてサーバ側に設定して、データ入力処理122の負荷を小さくし、処理効率を向上させる。メインデータは、通常CSV、テーブル形式、データベース形式などで記憶される。データ入力処理17141の結果、配送タスクデータ17143は、ネットワーク175を介してサーバ172のAPI1727によって入力される。
その後、計算条件設定処理17241によって入力データ500を生成するか、図18のように、データ入力処理17141としてサーバ172のAPI1727によって読み込む方式で、API1727を介して拠点管理データ17242を取得して図8に示す入力データ500を生成する。すなわち、データ入力処理17141によって計算条件設定処理17241の一部の作業を実行することに相当する。このとき、データ500の入力後に、計算条件設定処理17241のみで混載可否の設定をすればよい。拠点間距離データ17232は、道路ベクトルデータ17245と拠点管理データ17242を用いてサーバ172で生成される。また、道路ベクトルデータ17245は、NIC1726を介してインターネットなどの外部の地図情報提供サービスシステム176からオンデマンド(on demand)方式で収集されてもよい。
その後、メイン演算処理ステップ230に相当する最適解検索処理17243を実施し、生成された1つ以上の出力データ550をAPI1727経由でクライアント171に伝達する。配送計画出力処理17142において、図3の配送計画出力240に相当する処理を実行し、画面などの結果の出力を行う。クライアント171によって出力される配送経路700に用いられる地図は、NIC1716を介して、インターネットなどの外部の地図情報提供サービス176からオンデマンド方式で収集されてもよい。
本発明は、本文に開示されている実施例に記載されている各例示的な手段およびアルゴリズムのステップと併せて、電子的ハードウェア、またはコンピュータソフトウェアと電子的ハードウェアとの組み合わせによって実現されることを、当業者が認識可能である。これらの機能がいったいハードウェア方式またはソフトウェア方式で実行されるかは、技術手段の特定の応用と設計制限条件による。当業者は、記載した機能を、各特定応用に応じて異なる方法で実現することができるが、これらの実現は、本発明の範囲を超えたものと見なされない。
記載の便利と簡潔を図り、以上記載したシステム、装置および手段の具体的な作業過程について、前述した方法実施例の対応過程を参照することができ、当業者にとって明らかである。ここでは繰り返して記載しない。
本願による実施例において、開示されている装置および方法が他の方式で実現可能であることは、理解されるべきである。例えば、以上記載した装置の実施例は、単に例示的なものである。例えば、上記手段の区分は、単に論理的機能の区分であり、実際に実現される際に別の区分方式がありうる。例えば、複数の手段または構成要素は組み合わせ、または別のシステムに集積され、または、一部の特徴は、無視されたり実行されなかったりする。また、ここで示しており議論した部品同士の結合や直接結合や通信接続は、インタフェースを介しており、装置または手段の間接結合または通信接続は、電気接続、機械接続または他の形式である。
分離部品として説明した手段は、物理的に離間してもよく離間しなくてもよく、手段として表示された部材は、物理的手段であってもよく、ではなくてもよい。すなわち一箇所に位置するか、複数のネットワーク手段に分布されてもよい。実際の必要に応じてそのうちの一部またはすべての手段を選択して本発明の実施例の目的を実現する。
また、本発明の各実施例における各機能手段は、1つの処理手段に集積してもよく、または、各手段が個別に物理的に存在してもよく、2つ以上の手段が1つの手段に集積してもよい。
上記機能は、ソフトウェア機能手段の形式で実現され独立した製品として販売・使用される場合、1つのコンピュータ読取可能な記憶媒体に記憶することができる。このような理解に基づいて本発明の技術手段は実質上、または、従来技術に対し貢献した部分、または、当該技術手段の部分は、ソフトウェアプロダクトの形式であてっもよい。当該コンピュータソフトウェアプロダクトは、1つの記憶媒体に記憶され、いくつかの指令を含んで一台のコンピュータ機器(パーソナルコンピュータ、サーバ、またはネットワークデバイスなど)に本発明の各実施例に記載する方法のすべてまたは一部のステップを実行させる。上記の記憶媒体は、Uディスク、リムーバブルハードディスク、ROM、RAM、磁気ディスクまたは光ディスクなど様々なプログラムコードを記憶可能な媒体を含む。
以上の記載は、本発明の具体的な実施形態に過ぎず、本発明の保護範囲は、これに限定されない。当業者が本発明の開示範囲内に容易に想到可能な変更や置換は、いずれも本発明の保護範囲にカバーされる。したがって、本発明の保護範囲は、特許請求による保護範囲を基準とする。