IP Force 特許公報掲載プロジェクト 2022.1.31 β版

ホーム > 特許ランキング > 株式会社野村総合研究所

このエントリーをはてなブックマークに追加

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社野村総合研究所の特許一覧

特許7606010配送計画支援システム、配送計画支援方法およびコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-12-16
(45)【発行日】2024-12-24
(54)【発明の名称】配送計画支援システム、配送計画支援方法およびコンピュータプログラム
(51)【国際特許分類】
   G06Q 10/083 20240101AFI20241217BHJP
   G06Q 50/40 20240101ALI20241217BHJP
【ＦＩ】
G06Q10/083
G06Q50/40
【請求項の数】 14
(21)【出願番号】P 2023562146
(86)(22)【出願日】2022-08-26
(86)【国際出願番号】 JP2022032283
(87)【国際公開番号】W WO2023089898
(87)【国際公開日】2023-05-25
【審査請求日】2024-03-06
(31)【優先権主張番号】P 2021186190
(32)【優先日】2021-11-16
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000155469
【氏名又は名称】株式会社野村総合研究所
(74)【代理人】
【識別番号】100105924
【弁理士】
【氏名又は名称】森下 賢樹
(72)【発明者】
【氏名】土井 健
(72)【発明者】
【氏名】大野 真一朗
(72)【発明者】
【氏名】砂長谷 健
(72)【発明者】
【氏名】渡辺 和泉
【審査官】野村 和史
(56)【参考文献】
【文献】特開２０１９－０１２４８８（ＪＰ，Ａ）
【文献】特開２００４－００１９７５（ＪＰ，Ａ）
【文献】特開平１０－０５５３４９（ＪＰ，Ａ）
【文献】特開２００５－２０９０２５（ＪＰ，Ａ）
【文献】国際公開第２００５／０７１６０９（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１７／０１７８０７０（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
(57)【特許請求の範囲】
【請求項1】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、前記配送拠点におけるバース数の制約に基づいて、前記配送拠点における出発可能時間枠内に前記配送拠点を出発できない移動体が生じることを検出した場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項2】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、前記配送拠点におけるバース数の制約に基づいて、予め規定された到着可能時間枠内に前記移動体が到着しないノードが生じることを検出した場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項3】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、予め固定された前記複数の移動体の前記配送拠点からの出発時間の制約に基づいて、予め規定された到着可能時間枠内に前記移動体が到着しないノードが生じることを検出した場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項4】
前記判定部は、前記配送拠点からのルートにおいて最初に訪問すべきノードである初訪問ノードについてはその到達可能時間枠に到着するために前記配送拠点を出発すべき時間と、前記複数の移動体の前記配送拠点からの出発時間とを降順に比較して前記移動体の割り当て可否を判定し、前記初訪問ノードとは異なるノードについてはその到達可能時間枠に到着するために前記配送拠点を出発すべき時間と、前記複数の移動体の前記配送拠点からの出発時間とを昇順に比較して前記移動体の割り当て可否を判定する、
請求項３に記載の配送計画支援システム。
【請求項5】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、特定のノードに訪問するべき移動体を定めた制約に基づいて、或る移動体に割り当てられる１つ以上のノードに応じた荷物の積載量が当該移動体の荷量上限を超過する場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項6】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、特定のノードに訪問するべき移動体を定めた制約に基づいて、或る移動体に割り当てられるノード数が当該移動体の最大訪問ノード数を超過する場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項7】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、特定のノードに訪問するべき移動体を定めた制約と、複数のノードの訪問順を定めたルートの制約とに基づいて、或るルートにおける荷物の積載量が、当該ルートに割り当て可能な移動体の荷量上限を超過する場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項8】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、特定のノードに訪問するべき移動体を定めた制約と、複数のノードの訪問順を定めたルートの制約とに基づいて、或るルートにおけるノード数が、当該ルートに割り当て可能な移動体の最大訪問ノード数を超過する場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項9】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、複数のノードの訪問順を定めたルートの制約と、前記複数のノードそれぞれについて予め規定された到着可能時間枠の制約とに基づいて、前記ルートに割り当て可能な移動体が存在しないことを検出した場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項10】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
を備え、
前記判定部は、前記配送拠点からのルートにおいて最初に訪問すべきノードである初訪問ノードを定めた第１制約と、前記配送拠点からのルートにおいて最後に訪問すべきノードである最終訪問ノードを定めた第２制約と、前記初訪問ノードと前記最終訪問ノードに訪問すべき移動体を定めた第３制約とに基づいて、前記初訪問ノードと前記最終訪問ノードの個数が、前記第３制約が定める移動体の個数を超過する場合、前記複数の制約が不整合と判定する、
配送計画支援システム。
【請求項11】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、
前記判定部により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部と、
変換部と、
を備え、
前記複数の制約は、前記配送拠点からのルートにおいて最後に訪問すべきノードである最終訪問ノードを指定する第１制約と、前記最終訪問ノードに訪問すべき移動体を指定する第２制約とを含み、
前記配送計画生成部は、前記複数の移動体の配送ルートを順次決定するものであり、
前記変換部は、前記配送ルートの決定順序が相対的に後の移動体に対して優先的に前記最終訪問ノードを割り当てるよう前記第２制約を変換する、
配送計画支援システム。
【請求項12】
前記複数の制約は、前記配送拠点からのルートにおいて最初に訪問すべきノードである初訪問ノードを指定する第３制約をさらに含み、
前記第２制約は、前記初訪問ノードまたは前記最終訪問ノードに訪問すべき移動体を指定するものであり、
前記変換部は、前記配送ルートの決定順序が相対的に後の移動体に対して優先的に前記最終訪問ノードを割り当て、かつ、前記配送ルートの決定順序が相対的に先の移動体に対して優先的に前記初訪問ノードを割り当てるよう前記第２制約を変換する、
請求項１１に記載の配送計画支援システム。
【請求項13】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付けるステップと、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定するステップと、
前記判定するステップで前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力するステップと、
をコンピュータが実行し、
前記判定するステップは、前記配送拠点におけるバース数の制約に基づいて、前記配送拠点における出発可能時間枠内に前記配送拠点を出発できない移動体が生じることを検出した場合、前記複数の制約が不整合と判定する、
配送計画支援方法。
【請求項14】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける機能と、
前記複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する機能と、
前記判定する機能により前記複数の制約が整合すると判定された場合に、前記複数の制約に基づく配送計画指示を配送計画生成部に入力する機能と、
をコンピュータに実現させ、
前記判定する機能は、前記配送拠点におけるバース数の制約に基づいて、前記配送拠点における出発可能時間枠内に前記配送拠点を出発できない移動体が生じることを検出した場合、前記複数の制約が不整合と判定する、
コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、データ処理技術に関し、特に配送計画支援システム、配送計画支援方法およびコンピュータプログラムに関する。
【背景技術】
【0002】
実世界における、様々な要素の膨大な組合せを考慮しながら適切な解を見つけ出す組み合わせ最適化問題として、例えば、巡回セールスマン問題が挙げられる。巡回セールスマン問題とは、ある都市を出発したセールスマンが他の複数の都市を一回ずつ訪問して出発した都市に戻る場合に、移動距離が最小となるように巡回する都市の順番を決めるという問題である。以下の特許文献１では、時間帯により変化する各地点間の交通状況を踏まえて、出発地点から到着地点までの経路を提示するシステムが提案されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０２０－５６７３０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画では、ノード間の移動時間や業務要件等を含む様々な制約を満たすように解を求める必要がある。しかし、様々な制約が存在することにより実行可能解（言い換えれば複数の制約を満たす解）を求めることは容易でない。例えば、多くの時間をかけて配送計画の解を導出しても、導出した解はいずれかの制約に違反するものかもしれず、言い換えれば、導出した解は実行可能解でないかもしれない。
【0005】
本開示は、本発明者の上記課題認識に基づきなされたものであり、１つの目的は、配送計画上の複数の制約を満たす解が存在しない場合に、そのことを配送計画生成前に検知する技術を提供することにある。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本開示のある態様の配送計画支援システムは、複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付ける受付部と、複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定する判定部と、判定部により複数の制約が整合すると判定された場合に、複数の制約に基づく配送計画指示を配送計画生成部に入力する指示部とを備える。
【0007】
本開示の別の態様は、配送計画支援方法である。この方法は、複数の移動体が手分けして配送拠点から複数のノードに荷物を配送する場合の配送計画に関する複数の制約を示すデータを受け付けるステップと、複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否かを判定するステップと、判定するステップで複数の制約が整合すると判定された場合に、複数の制約に基づく配送計画指示を配送計画生成部に入力するステップとをコンピュータが実行する。
【0008】
なお、以上の構成要素の任意の組合せ、本開示の表現を、装置、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で変換したものもまた、本開示の態様として有効である。
【発明の効果】
【0009】
本開示によれば、配送計画上の複数の制約を満たす解が存在しない場合に、そのことを配送計画生成前に検知することができる。
【図面の簡単な説明】
【0010】
【図1】配送計画に関する複数の制約の例を示す図である。
【図2】実施例の情報処理システムの構成を示す図である。
【図3】チェック部によるチェック項目を示す図である。
【図4】ＩＤ１０のチェックが検知対象とする不整合を説明する図である。
【図5】ＩＤ１０のチェックアルゴリズムの実装例を示す図である。
【図6】ＩＤ１１のチェックが検知対象とする不整合を説明する図である。
【図7】ＩＤ１１のチェックアルゴリズムを説明する図である。
【図8】ＩＤ１１のチェックアルゴリズムの実装例を示す図である。
【図9】ＩＤ１２のチェックが検知対象とする不整合を説明する図である。
【図10】ＩＤ１２のチェックアルゴリズムを説明する図である。
【図11】ＩＤ１２のチェックチェックアルゴリズムの実装例を示す図である。
【図12】ＩＤ１４のチェックが検知対象とする不整合を説明する図である。
【図13】ＩＤ１４のチェックアルゴリズムを説明する図である。
【図14】ＩＤ１４のチェックアルゴリズムの実装例を示す図である。
【図15】ＩＤ１５のチェックが検知対象とする不整合を説明する図である。
【図16】ＩＤ１５のチェックアルゴリズムを説明する図である。
【図17】ＩＤ１５のチェックアルゴリズムを説明する図である。
【図18】ＩＤ１５のチェックアルゴリズムを説明する図である。
【図19】ＩＤ１５のチェックアルゴリズムの実装例を示す図である。
【図20】ＩＤ２６のチェックが検知対象とする不整合を説明する図である。
【図21】ＩＤ２６のチェックアルゴリズムを説明する図である。
【図22】ＩＤ２６のチェックアルゴリズムを説明する図である。
【図23】ＩＤ２６のチェックアルゴリズムの実装例を示す図である。
【図24】ＩＤ２７のチェックが検知対象とする不整合を説明する図である。
【図25】ＩＤ２７のチェックアルゴリズムを説明する図である。
【図26】ＩＤ２７のチェックアルゴリズムの実装例を示す図である。
【図27】ＩＤ２８のチェックが検知対象とする不整合を説明する図である。
【図28】ＩＤ２８のチェックアルゴリズムの実装例を示す図である。
【図29】ＩＤ２９のチェックが検知対象とする不整合を説明する図である。
【図30】ＩＤ２９のチェックアルゴリズムの実装例を示す図である。
【図31】ＩＤ３０のチェックが検知対象とする不整合を説明する図である。
【図32】ＩＤ３０のチェックアルゴリズムを説明する図である。
【図33】ＩＤ３０のチェックアルゴリズムを説明する図である。
【図34】ＩＤ３０のチェックアルゴリズムの実装例を示す図である。
【図35】ＩＤ３０のチェックアルゴリズムの実装例を示す図である。
【図36】ＩＤ３０のチェックアルゴリズムの実装例を示す図である。
【図37】ＩＤ３１のチェックが検知対象とする不整合を説明する図である。
【図38】ＩＤ３１のチェックアルゴリズムを説明する図である。
【図39】ＩＤ３１のチェックアルゴリズムを説明する図である。
【図40】ＩＤ３１のチェックアルゴリズムの実装例を示す図である。
【図41】ＩＤ３２チェックが検知対象とする不整合を説明する図である。
【図42】ＩＤ３２のチェックアルゴリズムの実装例を示す図である。
【図43】ＩＤ３２のチェックアルゴリズムの実装例を示す図である。
【図44】ＩＤ３２のチェックアルゴリズムの実装例を示す図である。
【図45】ＩＤ３２のチェックアルゴリズムを説明する図である。
【図46】ＩＤ３２のチェックアルゴリズムの実装例を示す図である。
【図47】ＩＤ３２のチェックアルゴリズムの実装例を示す図である。
【図48】最近傍法を用いた経路導出の例を示す図である。
【図49】最終訪問ノードに対する車両割り当ての例を示す図である。
【図50】最終訪問ノードに対する車両割り当ての例を示す図である。
【図51】初訪問ノードに対する車両割り当ての例を示す図である。
【図52】初訪問ノードに対する車両割り当ての例を示す図である。
【図53】変換部の実装例を示す図である。
【図54】変換部の実装例を示す図である。
【発明を実施するための形態】
【0011】
本開示における装置または方法の主体は、コンピュータを備えている。このコンピュータがコンピュータプログラムを実行することによって、本開示における装置または方法の主体の機能が実現される。コンピュータは、コンピュータプログラムにしたがって動作するプロセッサを主なハードウェア構成として備える。プロセッサは、コンピュータプログラムを実行することによって機能を実現することができれば、その種類は問わない。プロセッサは、半導体集積回路（ＩＣ、ＬＳＩ等）を含む１つまたは複数の電子回路で構成される。コンピュータプログラムは、コンピュータが読み取り可能なＲＯＭ、光ディスク、ハードディスクドライブなどの非一時的な記録媒体に記録される。コンピュータプログラムは、記録媒体に予め格納されていてもよいし、インターネット等を含む広域通信網を介して記録媒体に供給されてもよい。
【0012】
実施例の概要を説明する。複数の移動体が手分けして配送拠点（以下「デポ」とも呼ぶ。）から複数のノードに荷物を配送する場合の配送計画では、ノード間の移動時間や業務要件等を含む様々な制約（制約条件とも言える。）を満たすように解を求める必要がある。実施例での移動体は、荷物を配送する車両（トラック等）とし、ノードは、荷物の配送先としての店舗とする。配送計画は、どの車両がどの店舗をどの順番で訪問するかを定めた計画と言え、また、各車両がデポを出発してから１つ以上の店舗を経由してデポに戻るまでの配送ルート（移動経路とも言える）を定めた計画とも言える。
【0013】
図１は、配送計画に関する複数の制約の例を示す。制約１「積込時間」は、デポにおける車両への積荷作業にかかる時間である。制約２「出発時間」は、車両がデポを出発できる時間である。制約３「配送可能時間枠」は、車両が各店舗に訪問可能な時間枠である。制約４「滞店時間」は、車両が店舗に滞在可能な時間である。制約５「荷量」は、車両ごとの積載可能な荷量、および、店舗ごとの配送が必要な荷量である。
【0014】
制約６「ルート時間小計」は、１ルートあたりに取り得る配送時間（言い換えればデポを出発し、店舗巡回後、デポに戻るまでの時間）の最大値である。制約７「バース数」は、デポにおける積荷作業で同時に利用できる車庫（以下「バース」とも呼ぶ。）の個数である。制約８「車両台数」は、複数の店舗を手分けして訪問する車両の台数である。また、図１には不図示だが、実施例の制約には、デポと各店舗との距離および店舗間の距離（具体的には時間距離であり移動時間とも言える）を示す距離行列を含む。
【0015】
図１に示すような様々な制約を同時に満たす配送計画の解（以下「実行可能解」とも呼ぶ。）を求めることは容易でなく、解の探索に時間を要する。例えば、（課題１）多くの時間をかけて配送計画の解を１０１００個導出したとしても、いずれの解も、いずれかの制約に違反する解（以下「実行不可能解」とも呼ぶ。）であるかもしれない。また、（課題２）全体として１０８００個の解が存在する配送計画問題において、そのうち１０６００個が実行可能解であるとしても、残りの（１０８００－１０６００）個の解から探索しているかもしれない。
【0016】
実施例では、配送計画の実行可能解が確実に得られるよう支援する技術を提案する。実施例の配送計画支援システムでは、上記の課題１を解決するために、複数の車両の配送計画を生成する処理（配送ルート決定処理、配送ルート最適化処理とも言える）の前に、実行可能解が存在しない場合にそのことを検知する処理を動作させる。具体的には、複数の制約が互いに矛盾する（言い換えれば不整合である）場合にそのことを検知する処理を動作させる。また、上記の課題２を解決するために、配送経路の決定に適用されるアルゴリズムの性質を勘案して、配送経路を効率的に求解可能なよう制約データを変換する。
【0017】
実施例の詳細を説明する。図２は、実施例の情報処理システム１０の構成を示す。情報処理システム１０は、ユーザ端末１２、フロントシステム１４、配送計画支援システム１６を備える。これらは、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網を介して接続される。
【0018】
ユーザ端末１２は、ノードへの荷物の配送にかかわる事業者（以下「配送事業者」とも呼ぶ。）の担当者（以下「ユーザ」とも呼ぶ。）により操作される情報処理端末である。ユーザは、図１に示したような配送計画に関する複数の制約を作成する。
【0019】
フロントシステム１４は、ユーザ端末１２から送信された複数の制約を示すデータを配送計画支援システム１６へ送信する。フロントシステム１４は、ユーザ端末１２から送信されたデータに基づく制約データを設定してもよい。また、フロントシステム１４は、配送計画支援システム１６から送信された配送計画に基づくデータをユーザ端末１２へ送信する。配送計画に基づくデータは、例えば、複数の車両のそれぞれが訪問すべきノードを示すコース表等を含んでもよい。
【0020】
配送計画支援システム１６は、配送計画の策定を支援するシステムである。配送計画支援システム１６は、前処理部２０と配送計画生成部３０を備える。配送計画支援システム１６は、１台のコンピュータにより実現されてもよく、複数台のコンピュータが連携することにより実現されてもよい。実施例では、前処理部２０と配送計画生成部３０は、それぞれ別のコンピュータにより実現され、前処理部２０の機能が実装されたコンピュータと配送計画生成部３０の機能が実装されたコンピュータは、通信網を介して接続される。例えば、配送計画生成部３０の機能は、クラウドサービス（例えばＳａａＳ）として提供されてもよい。
【0021】
配送計画生成部３０は、配送計画を生成し、言い換えれば、複数の車両の最適な配送ルートを決定（求解）する。配送計画生成部３０は、配送計画の生成において、様々なアルゴリズムを適用可能である。また、配送計画生成部３０は、組み合わせ最適化問題を高速に求解可能な量子コンピュータを用いて実現されてもよい。実施例では、配送計画生成部３０は、公知のクラスタリング手法である最近傍法（nearest neighbor algorithm）を用いて、配送計画を生成する。また、配送計画生成部３０は、予め定められた順番にしたがって、複数の車両の配送経路を順次決定する。
【0022】
前処理部２０は、配送計画生成に対する前処理を実行する。前処理部２０は、受付部２２、チェック部２４、変換部２６、指示部２８を含む。これら複数の機能ブロック（配送計画生成部３０を含んでもよい）の機能は、コンピュータプログラムに実装されてもよい。そのコンピュータプログラムは、配送計画支援システム１６を構成するコンピュータのストレージに格納されてもよい。配送計画支援システム１６を構成するコンピュータのプロセッサ（ＣＰＵ等）は、そのコンピュータプログラムをメインメモリに読み出して実行することにより、上記複数の機能ブロックの機能を発揮してもよい。
【0023】
受付部２２は、フロントシステム１４から送信された、配送計画に関する複数の制約を示すデータを受け付ける。チェック部２４は、判定部とも言え、配送計画に関する複数の制約が、時間と資源割り当ての少なくとも一方に関して整合するか否か（言い換えれば矛盾するか否か）を判定する。
【0024】
変換部２６は、初訪問ノード制約と、最終訪問ノード制約と、ノード車両制約とを受け付ける。初訪問ノード制約は、デポからのルートにおいて最初に訪問すべきノードである初訪問ノードを指定する制約である。最終訪問ノード制約は、デポからのルートにおいて最後に訪問すべきノードである最終訪問ノードを指定する制約である。ノード車両制約は、初訪問ノードまたは最終訪問ノードに訪問すべき車両を指定する制約である。変換部２６は、ルートの決定順序が相対的に後の車両に対して優先的に最終訪問ノードを割り当てるようノード車両制約を変換する。かつ、変換部２６は、ルートの決定順序が相対的に先の車両に対して優先的に初訪問ノードを割り当てるようノード車両制約を変換する。
【0025】
指示部２８は、チェック部２４により配送計画に関する複数の制約が整合する（言い換えれば矛盾しない）と判定された場合に、それら複数の制約に基づいて配送計画を生成することを指示する配送計画指示を配送計画生成部３０に入力する。実施例では、指示部２８は、上記複数の制約を含む配送計画指示のデータを、通信網を介して配送計画生成部３０へ送信する。配送計画指示に含まれる複数の制約は、変換部２６により変換後のノード車両制約を含む。
【0026】
次に、配送計画支援システム１６のチェック部２４によるチェック処理を詳細に説明する。
【0027】
図３は、チェック部２４によるチェック項目を示す。チェック部２４によるチェック項目は、図３に示す３２個のチェック項目を含む。図３では、各チェック項目について、時間整合性のチェックに該当するか否か、資源割り当てのチェックに該当するか否か、ビジネス制約のチェックに該当するか否かを示している。図３では、強く該当する場合に二重丸◎、弱く該当する場合に一重○、該当しない場合に無印としている。時間整合性のチェックは、デポやノードの出発可能時間枠等、時間に関して複数の制約が整合するか否かのチェックである。資源割り当てのチェックは、バース数や車両数、荷量等、資源割り当てに関して複数の制約が整合するか否かのチェックである。ビジネス制約のチェックは、配送事業者のビジネス上の制約に関して複数の制約が整合するか否かのチェックである。
【0028】
ＩＤ１のチェックでは、車両がノードに設定された出発可能時間枠内で最も早い時刻にノードを出発したとしても、当該車両に設定された最大配送時間（例えば５時間）内にデポに帰庫することができない場合、エラーを検知する。チェック部２４は、このチェックにてエラーを検知した場合、複数の制約が不整合である（言い換えれば矛盾する）と判定する。なお実施例では、ノードの出発可能時間枠は、当該ノードに車両が到着可能な時間枠でもあり、到着可能時間枠とも言える。
【0029】
ＩＤ２のチェックでは、ノードで指定された配送可能車両が、当該ノードに設定された出発可能時間枠内で最も早くノードを出発したとしても、当該車両に設定された最大配送時間内にデポに帰庫することができない場合、エラーを検知する。
【0030】
ＩＤ３のチェックでは、車両が出発可能時間枠内の最も早い時間に出発してぎりぎり最大配送時間内にデポに帰庫できるノードについて、そのノード数が車両数を上回る場合、エラーを検知する。
【0031】
ＩＤ４のチェックでは、デポを最も遅い時間に出発しても初訪問ノードの出発可能時間枠に到着できない（出発可能時間枠より早く到着する）場合、エラーを検知する。
【0032】
ＩＤ５のチェックでは、ノードに設定された出発可能時間枠と、出発不可能時間枠（ノードへの到着およびノードからの出発が不可能な時間枠）とを勘案した場合に出発可能な時間枠がなくなる場合、エラーを検知する。
【0033】
ＩＤ６のチェックでは、ノードに設定された出発可能時間枠と出発不可能時間枠を考慮して、デポを最も早い時間に出発してもノードの出発可能時間枠に間に合わない場合、エラーを検知する。
【0034】
ＩＤ７のチェックでは、車両がノードに設定された出発可能時間枠内で最も早い時刻に当該ノードを出発すれば最大配送時間内にデポに帰庫できる一方、当該ノードに設定された出発不可能時間枠により最大配送時間内にデポに帰庫できなくなる場合、エラーを検知する。
【0035】
ＩＤ８のチェックでは、ノードで指定された配送可能車両が、当該ノードに設定された出発可能時間枠内で最も早い時間に当該ノードを出発すれば最大配送時間内にデポに帰庫できる一方、当該ノードに設定された出発不可能時間枠により最大配送時間内にデポに帰庫できなくなる場合、エラーを検知する。
【0036】
ＩＤ９のチェックでは、初訪問ノードの出発可能時間枠から出発不可能時間枠を除外すると、車両がデポを最も遅い時刻に出発しても初訪問ノードの出発可能時間枠に到着できない（出発可能時間枠より早く到着する）場合、エラーを検知する。
【0037】
ＩＤ１０のチェックでは、デポにおけるバース数とバース占有時間、デポの出発可能時間枠を勘案し、デポの出発可能時間枠内にデポを出発できない車両が生じる場合、エラーを検知する。
【0038】
ＩＤ１１のチェックでは、デポのバースを１回転目で出発しないと間に合わないノード数がバース数を上回る場合、（出発可能時間枠内に到着できないノードが生じるため）エラーを検知する。
【0039】
ＩＤ１２のチェックでは、デポを遅めに出発すると出発可能時間枠内に到着可能なノード数がバース数を上回る場合、（出発可能時間枠より早い時刻に到着するノードが生じるため）エラーを検知する。
【0040】
ＩＤ１３のチェックでは、デポからの全車両の出発時刻が指定される場合において、指定された車両の出発時刻がデポの出発可能時間枠を逸脱する場合に、エラーを検知する。
【0041】
ＩＤ１４のチェックでは、デポからの全車両の出発時刻が指定される場合において、指定された車両の出発時刻では出発可能時間枠内に到着できないノードが生じる場合に、エラーを検知する。
【0042】
ＩＤ１５のチェックでは、デポからの全車両の出発時刻が指定される場合において、指定された車両の出発時刻では初訪問ノードの出発可能時間枠に到着できない場合に、エラーを検知する。
【0043】
ＩＤ１６のチェックは、ＩＤ１３のチェックに対応する。ＩＤ１６のチェックでは、デポからの一部車両の出発時刻が指定される場合において、指定された車両の出発時刻がデポの出発可能時間枠を逸脱する場合に、エラーを検知する。
【0044】
ＩＤ１７のチェックは、ＩＤ１０のチェックに対応する。ＩＤ１７のチェックでは、デポからの一部車両の出発時刻が指定される場合において、デポにおけるバース数とバース占有時間、デポの出発可能時間枠を勘案して、デポの出発可能時間枠内にデポを出発できない車両が生じる場合に、エラーを検知する。
【0045】
ＩＤ１８のチェックは、ＩＤ１１のチェックに対応する。ＩＤ１８のチェックでは、デポからの一部車両の出発時刻が指定される場合において、デポのバースを１回転目で出発しないと間に合わないノード数がバース数を上回る場合に、エラーを検知する。
【0046】
ＩＤ１９のチェックは、ＩＤ１２のチェックに対応する。ＩＤ１９のチェックでは、デポからの一部車両の出発時刻が指定される場合において、デポを遅めに出発すると出発可能時間枠内に到着可能なノード数がバース数を上回る場合に、エラーを検知する。
【0047】
ＩＤ２０のチェックでは、デポからの一部車両の出発時刻の指定と、初訪問ノードの指定の両方がなされた場合において、出発可能時間枠内に到着できないノードが生じる場合に、エラーを検知する。
【0048】
ＩＤ２１のチェックでは、デポからの一部車両の出発時刻の指定と、ノードへの配送可能車両の指定の両方がなされた場合において、出発可能時間枠内に到着できないノードが生じる場合に、エラーを検知する。
【0049】
ＩＤ２２のチェックでは、指定された初訪問ノードの数と、指定された最終訪問ノードの数の合計が車両数を上回る場合に、エラーを検知する。チェック部２４は、１つの車両に対して、指定された初訪問ノードと指定された最終訪問ノードの両方を割り当てることを禁止する。１つの車両に初訪問ノードと最終訪問ノードの両方を割り当てると、車両の配送ルートが歪な形になりやすく、効率的な配送ルートの生成が阻害されるからである。
【0050】
ＩＤ２３のチェックでは、１つのノードが初訪問ノードと最終訪問ノードの両方に指定される場合に、エラーを検知する。
【0051】
ＩＤ２４のチェックでは、初訪問ノードの数と、最終訪問ノードの数と、固定ルートの数の合計が車両数を上回る場合に、エラーを検知する。初訪問ノードと、最終訪問ノードと、固定ルートは、それぞれ異なる車両に割り当てるためである。固定ルートは、少なくとも一部のノードの組み合わせが固定されたルートであり、全固定ルートと前方一致固定ルートを含む。全固定ルートは、全てのノードの組み合わせが固定されたルートであり、例えば「デポ→ノードＡ→ノードＢ→ノードＣ→デポ」が指定されたルートである。前方一致固定ルートは、ルート前段のノードの組み合わせが固定されたルートであり、例えば「デポ→ノードＡ→ノードＢ」が指定され、ノードＢ以降は未指定のルートである。
【0052】
ＩＤ２５のチェックでは、１つのノードが、初訪問ノード、最終訪問ノード、固定ルートの少なくとも２つに重複して指定される場合に、エラーを検知する。
【0053】
ＩＤ２６のチェックでは、各ノードを車両に割り当てた場合において、積載すべき荷量が荷量制限を上回る車両が生じる場合に、エラーを検知する。
【0054】
ＩＤ２７のチェックでは、各ノードを車両に割り当てた場合において、訪問すべきノード数が当該車両の最大訪問ノード数を上回る車両が生じる場合に、エラーを検知する。
【0055】
ＩＤ２８のチェックでは、各ノードの配送可能車両の指定に基づいて、固定ルートを車両に割り当てる場合において、荷量制限のために固定ルートに割り当て可能な車両が存在しない場合、エラーを検知する。
【0056】
ＩＤ２９のチェックでは、各ノードの配送可能車両の指定に基づいて、固定ルートを車両に割り当てる場合において、最大訪問ノード数の制限のために固定ルートに割り当て可能な車両が存在しない場合、エラーを検知する。
【0057】
ＩＤ３０のチェックでは、固定ルートを車両に割り当てる場合において、固定ルート内の各ノードの出発可能時間枠を満たす車両が存在しない場合、エラーを検知する。
【0058】
ＩＤ３１のチェックでは、初訪問ノードの数と最終訪問ノードの数の合計が、それらのノードを割り当て可能な車両数を上回る場合に、エラーを検知する。
【0059】
ＩＤ３２のチェックでは、上記の個別チェックをまとめて勘案した場合に矛盾が生じないかをチェックする。
【0060】
以下、一部のチェック項目についてさらに詳細に説明する。
ＩＤ１０のチェック「バース回転数とデポ出発可能時間枠の不整合」について詳細に説明する。図４は、ＩＤ１０のチェックが検知対象とする不整合を説明する図である。チェック部２４は、デポにおけるバース数の制約に基づいて、デポにおける出発可能時間枠内にデポを出発できない車両が生じることを検出した場合、複数の制約が不整合と判定する。チェック部２４は、デポにおけるバース数とバース占有時間、デポの出発可能時間枠を勘案した際に、デポの出発可能時間枠内に出発できない車両が生じる場合、不整合を検知する。
【0061】
具体的には、チェック部２４は、デポの出発可能時間枠を容量と見なしたビンパッキング問題をファーストフィットアルゴリズムを用いて解く。ビンパッキング問題は、特定の容量のみ入るビンを用意し、全てのブロックをビンに詰めるために最低何個のビンが必要かを求める問題である。ファーストフィットアルゴリズムは、「First-Fit-Decreasing」とも呼ばれ、ブロックが詰められるビンの中で、添え字が最小のビンにブロックを詰めるアルゴリズムである。チェック部２４は、求めた数（ビンの数）が、バース数を超過しないことをチェックする。
【0062】
図５は、ＩＤ１０のチェックアルゴリズムの実装例を示す。実施例では、各チェックアルゴリズムの実装例として、Ｐｙｔｈｏｎのソースコードを示す。関連する制約を示す入力データは以下の通りである。
・data.depot_index：デポのインデックス（int）
・data.time_windows.available_time：ノード毎の出発可能時間枠（dict）
・data.berth.berth_control：“auto”
・data.berth.depot_capacity：バース数（int）
・data.berth.loading_time: 車両ごとのバース占有時間（dict）
チェック部２４は、必要となるバース数が、制約としてのバース数を上回る場合、エラーを検知し、制約間の不整合を検知する。
【0063】
ＩＤ１１のチェック「バース２回転目以降考慮により出発可能時間枠を超過するノードの顕在化」について詳細に説明する。チェック部２４は、デポにおけるバース数の制約に基づいて、予め規定された到着可能時間枠内に車両が到着しないノードが生じることを検出した場合、複数の制約が不整合と判定する。既述だが、実施例における「到着可能時間枠」は、「出発可能時間枠」と同義である。
【0064】
図６は、ＩＤ１１のチェックが検知対象とする不整合を説明する図である。同図は、バースの１回転目に出発しないと間に合わないノードがバース数より多く存在した場合に、出発可能時間枠に到着できないノードが生じる例を示している。同図は簡単な例を示している。実際には各ノードで出発可能時間枠が異なるため、出発可能時間枠の上限から時間距離を引いた値を昇順に並べてチェックする。また、ノードＢやノードＡ経由でノードＣに辿り着く可能性もあるため、２回転目までチェックしている。
【0065】
図７は、ＩＤ１１のチェックアルゴリズムを説明する図である。チェック部２４は、ｎ回転目までで間に合わなくなるノード数が（バース数×ｎ）個を上回ったらエラーを検知する。ただし、ｎ－１回転目までのノード経由で間に合う可能性があるため、２回転目までのチェックとする。
【0066】
図８は、ＩＤ１１のチェックアルゴリズムの実装例を示す。関連する制約を示す入力データは以下の通りである。
・data.depot_index：デポのインデックス（int）
・data.edge.time：デポ～ノード間、ノード～ノード間の距離行列（2次元list）
・data.time_windows.available_time：ノード毎の出発可能時間枠（dict）
・data.berth.berth_control：“auto”
・data.berth.depot_capacity：バース数
・data.berth.loading_time：車両ごとのバース占有時間（dict）
【0067】
ＩＤ１２のチェック「バース１回転目割り当てノードの不足」を詳細に説明する。チェック部２４は、予め固定された複数の車両のデポからの出発時間の制約に基づいて、予め規定された到着可能時間枠内に車両が到着しないノードが生じることを検出した場合、複数の制約が不整合と判定する。
【0068】
図９は、ＩＤ１２のチェックが検知対象とする不整合を説明する図である。デポのバースを遅めに出発すると間に合うノードしか存在しないときに、該当のノードがバース数より多い場合、出発可能時間枠より早い時刻に車両が到着するノードが生じる。同図は簡単な例を示している。実際には各ノードで出発可能時間枠が異なるため、各ノードの出発可能時間枠の下限から時間距離を引いた値を降順に並べてチェックする。厳密には、各ノードに対して最も早いデポ出発時刻を求め、バース１回転目の割り当てノードが足りない場合、エラーを検知する。バースは、荷物の配送にかかわる資源の最たるものであるため、実施例では、バース１回転目を使い切ることを前提としている。
【0069】
図１０は、ＩＤ１２のチェックアルゴリズムを説明する図である。車両がバース１回転目に出発することで、出発可能時間枠内に到着するノード数がバース数より少ない場合、エラーを検知する。バース１回転目を使い切ることができず、また、バース１回転目を使い切ろうとすると、出発可能時間枠より早い時刻に車両が到着するノードが生じるからである。
【0070】
図１１は、ＩＤ１２のチェックチェックアルゴリズムの実装例を示す。関連する制約を示す入力データは以下の通りである。
・data.num_vehicles：車両数（int）
・data.depot_index：デポのインデックス（int）
・data.edge.time：デポ～ノード間、ノード～ノード間の距離行列（2次元list）
・data.num_nodes：ノード数（int）
・data.time_windows.available_time：ノード毎の出発可能時間枠（dict）
・data.berth.berth_control：“auto”
・data.berth.depot_capacity：バース数
・data.berth.loading_time：車両ごとのバース占有時間（dict）
【0071】
ＩＤ１４のチェック「デポ出発時刻全固定に伴う厳しい早配条件の設定」を詳細に説明する。チェック部２４は、予め固定された複数の車両のデポからの出発時間の制約に基づいて、予め規定された到着可能時間枠内に車両が到着しないノードが生じることを検出した場合、複数の制約が不整合と判定する。
【0072】
図１２は、ＩＤ１４のチェックが検知対象とする不整合を説明する図である。全車両のデポ出発時刻が固定されている状況下で、デポを早めに出発することでぎりぎり間に合うノードが多く存在する場合、出発可能時間枠内に車両が到着できないノードが生じることがある。同図は簡単な例を示している。実際には、各ノードで出発可能時間枠が異なるため、各ノードの出発可能時間枠の上限から時間距離を引いた値を昇順に並べてチェックする。
【0073】
図１３は、ＩＤ１４のチェックアルゴリズムを説明する図である。ノードの出発可能時間枠に間に合うデポからの最も遅い出発時刻（以下「最遅出発時刻」と呼ぶ。）を算出して昇順に並び替える。各ノードに対する最遅出発時刻と、車両の出発時刻（全固定）との大小比較により、出発可能時間枠内に車両が到着しないノードが生じないかを確認する。図１３の例では、ノードＡが、出発可能時間枠内に車両が到着しないノードである。
【0074】
図１４は、ＩＤ１４のチェックアルゴリズムの実装例を示す。関連する制約を示す入力データは以下の通りである。
・data.depot_index：デポのインデックス（int）
・data.edge.time：デポ～ノード間、ノード～ノード間の距離行列（2次元list）
・data.time_windows.available_time：ノード毎の出発可能時間枠（dict）
・data.berth.berth_control：“auto”
・data.berth.const_berth：車両毎のデポ出発時刻（全固定）（list）
【0075】
ＩＤ１５のチェック「デポ出発時刻全固定に伴う厳しい早配遅配条件の設定」を詳細に説明する。チェック部２４は、初訪問ノードについて、その到着可能時間枠に到着するためにデポを出発すべき時間と、複数の車両のデポからの出発時間とを降順に比較して、車両の割り当て可否を判定する。初訪問ノードは、デポからの車両の移動ルートにおいて最初に訪問すべきことが制約で指定されたノードである。一方、初訪問ノードとは異なるノードについては、チェック部２４は、その到達可能時間枠に到着するためにデポを出発すべき時間と、複数の車両のデポからの出発時間とを昇順に比較して、車両の割り当て可否を判定する。チェック部２４は、車両を割り当てられないノードが生じた場合、複数の制約が不整合と判定する。
【0076】
図１５は、ＩＤ１５のチェックが検知対象とする不整合を説明する図である。全車両のデポ出発時刻が固定されている状況下、初訪問ノードに設定されなければ出発可能時間枠に車両が到着可能であったが、初訪問ノードに設定されたために出発可能時間枠に車両が到着できないノードが生じうる。同図は簡単な例を示している。実際には、各ノードで出発可能時間枠が異なるため、各ノードの出発可能時間枠の下限から時間距離を引いた値を降順に並べてチェックする。以下、ノードの出発可能時間枠内に車両が到着可能な最も早いデポからの出発時刻を「最早出発時刻」と呼ぶ。
【0077】
図１６は、ＩＤ１５のチェックアルゴリズムを説明する図である。既述したように、初訪問ノードのチェックと、他のノードのチェックに分かれる。初訪問ノードについては、時刻の降順に車両割り当て可否をチェックする一方、他のノードについては、時刻の昇順に車両割り当て可否をチェックする。図１６では、初訪問ノードに対する最早出発時刻以降の出発時刻の車両を割当可能であり、かつ、他のノードに対する最遅出発時刻以前の出発時刻の車両を割当可能であるため、複数の制約が整合すると判定する（エラーを検知しない）。
【0078】
図１７も、ＩＤ１５のチェックアルゴリズムを説明する図である。初訪問ノードであるノードＥとデポの距離が１５分である。図１７の例では、ノードＥに割り当て可能な車両の中に、ノードＥに対する最早出発時刻以降の時刻にデポを出発する車両が存在しないため、エラーを検知する。
【0079】
図１８も、ＩＤ１５のチェックアルゴリズムを説明する図である。図１８の例では、初訪問ノードには正常に車両を割り当てることができた。しかし、ノードＡに割り当て可能な車両の中に、ノードＡに対する最遅出発時刻以前の時刻にデポを出発する車両が存在しないため、エラーを検知する。
【0080】
図１９は、ＩＤ１５のチェックアルゴリズムの実装例を示す。関連する制約を示す入力データは以下の通りである。
・data.depot_index：デポのインデックス（int）
・data.edge.time：デポ～ノード間、ノード～ノード間の距離行列（2次元list）
・data.berth.berth_control：“auto”
・data.berth.const_berth：車両毎のデポ出発時刻（全固定）（list）
・data.time_windows.available_time：ノード毎の出発可能時間枠（dict）
・data.routing_order.node_after_depot：初訪問ノード指定（list）
【0081】
ＩＤ２６のチェック「配送車両指定による荷量上限超過」について詳細に説明する。チェック部２４は、特定のノードに訪問するべき車両を定めた制約（「配送車両指定」とも呼ぶ。）に基づいて、或る車両に割り当てられる１つ以上のノードに応じた荷物の積載量が当該車両の荷量上限を超過する場合、複数の制約が不整合と判定する。
【0082】
図２０は、ＩＤ２６のチェックが検知対象とする不整合を説明する図である。同図では、ノードＡおよびノードＢに訪問可能な車両として車両ａが指定されている。しかし、ノードＡとノードＢに配送すべき荷量（以下「需要量」とも呼ぶ。）の合計は２５０個であり、ノードＡとノードＢを車両ａに割り当てると車両ａの荷量制限（ここでは２００個）を超えてしまう。このように、配送車両指定を考慮してノードに車両を割り当てると、車両の荷量制限の制約に違反することがある。チェック部２４は、ノードに対する車両の割り当てを一般割当問題（一般化割当問題とも呼ばれる）として解き、解が存在するか否かをチェックする。
【0083】
一般割当問題について説明する。ｎ個の仕事（例えばノード）があり、それをｍ個の資源（例えば車両）に割り当てることを考える。仕事と資源には相性があり、仕事ｊを資源ｉに割り当てた際の費用をｃｉｊとする。資源ｉには使用可能量の上限（容量とも言え、例えば荷量制限）ｂｉが定義されており、仕事ｊを資源ｉに割り当てるときには、資源ａｉｊを使用とするものする。１つの仕事には必ず１つの資源を割り当てるとき、資源に割り当てられた仕事の資源使用量の合計が資源の容量を超えないという条件のもとで、総費用を最小化する問題が一般割当問題である．
【0084】
仕事ｊを資源ｉに割り当てるとき１、それ以外のとき０となる０－１変数ｘｉｊを用いると、一般割当問題は以下のように定式化できる。
【数1】
式１は目的関数であり、式２～式４は制約条件である。
【0085】
図２１は、ＩＤ２６のチェックアルゴリズムを説明する図である。ノードに対して車両を割り当てる場合、ノードと車両の関係は図２１の表のように定義することができる。例えば、ノードＡ（ここでは需要量３０）に対して車両ｄ・ｅ・ｆのいずれかを割り当てるとき、該当箇所（セル）ａｉｊを３０とし、残りをＩＮＦ（無限大）とする。ＩＮＦは荷量制限以下にならないので、実行可能解ではノードＡは車両ｄ・ｅ・ｆのいずれかに割り当てられる。
【0086】
ノード×車両のセル１つ１つを、０または１の値をとるｘｉｊに対応させることで、数式を定義できる。例えば、ノードＡの行は、式５のように定義される。
ｘａＡ＋ｘｂＡ＋ｘｃＡ・・・ｘｇＡ＝１ ・・・（式５）
また、車両ｃの列は、式６のように定義される。
ＩＮＦｘｃＡ＋４０ｘｃＤ＋２５ｘｃＫ・・・３０ｘｃＵ≦９０ ・・・（式６）
【0087】
図２２も、ＩＤ２６のチェックアルゴリズムを説明する図である。同図は、車両ａ～車両ｅで十分に割り当てがなされた状態を示している。値「１」のセルが割り当てられた状態、値未記入のセルが割り当て無しの状態を示している。同図に示すように、実行可能解は、行方向で値「１」になるセルが１つのみ存在し、かつ、列方向で荷量の合計が荷量制限以下となるものである。なお、割り当てができなければエラーを返すソルバーを求解処理に用いる場合、そのエラーを検知する。また、量子コンピュータ等においてＱＵＢＯ（Quadratic Unconstrained Binary Optimization）にて定式化する場合、割り当てができなければＩＮＦのセルの値が「１」になるため、目的関数（式１）がＩＮＦ以上になる場合にエラーを検知する。
【0088】
図２３は、ＩＤ２６のチェックアルゴリズムの実装例を示す。関連する制約を示す入力データは以下の通りである。
・data.num_nodes：ノード数（int）
・data.vertex.demands：ノード毎の需要量（list）
・data.vehicle_capacities：車両毎の荷量制限（list）
・data.vehicle_assignment.available_vehicle：ノード毎の車両指定（dict）
【0089】
実際の実装では、最大ノード×車両のバイナリ問題となる。実施例では、Ｐｙｔｈｏｎの数理最適化ソルバーＰｕｌｐを使用する。チェック部２４は、Ｐｕｌｐの実行結果のステータスが異常を示す場合、すなわち、実行可能解が得られなかった場合、エラーを検知し、複数の制約が不整合と判定する。
【0090】
ＩＤ２７のチェック「配送車両指定による最大訪問ノード数超過」について詳細に説明する。上述のＩＤ２６のチェックは、荷量観点から車両割り当て可否を判定するのに対し、ＩＤ２７のチェックは、訪問ノード数の観点から車両割り当て可否を判定する。チェック部２４は、特定のノードに訪問するべき車両を定めた制約（配送車両指定）に基づいて、或る車両に割り当てられるノード数が当該車両の最大訪問ノード数を超過する場合、複数の制約が不整合と判定する。
【0091】
図２４は、ＩＤ２７のチェックが検知対象とする不整合を説明する図である。同図では、ノードＢ、ノードＣ、ノードＤに訪問可能な車両として車両ｂが指定されている。しかし、ノードＢ、ノードＣ、ノードＤを車両ｂに割り当てると車両ｂの最大訪問ノード数（ここでは２ノード）を超えてしまう。このように、配送車両指定を考慮してノードに車両を割り当てると、車両の最大訪問ノード数の制約に違反することがある。
【0092】
チェック部２４は、ＩＤ２６のチェックと同様に、一般割当問題を解くことでＩＤ２７のチェックを実行する。主な変更点は、各要素の値が１となり、車両の制限が最大訪問ノード数になることである。図２５は、ＩＤ２７のチェックアルゴリズムを説明する図である。例えば、ノードＡに対して、車両ｄ・ｅ・ｆ・のいずれかを割り当てるとき、該当箇所ａｉｊを１とし、残りをＩＮＦとする。ＩＮＦは最大訪問ノード数以下にならないので、実行可能解ではノードＡは車両ｄ・ｅ・ｆのいずれかに割り当てられる。
【0093】
図２６は、ＩＤ２７のチェックアルゴリズムの実装例を示す。関連する制約を示す入力データは以下の通りである。
・data.max_num_visits：車両毎の最大訪問ノード数（list）
・data.vehicle_assignment.available_vehicle：ノード毎の車両指定（dict）
図２６では、図２３で示したＩＤ２６のコードに対する変更箇所に下線を付している。
【0094】
ＩＤ２８のチェック「ルート固定における荷量上限超過」について詳細に説明する。チェック部２４は、特定のノードに訪問するべき車両を定めた制約と、複数のノードの訪問順を定めたルートの制約とに基づいて、或るルートにおける荷物の積載量が、当該ルートに割り当て可能な車両の荷量上限を超過する場合、複数の制約が不整合と判定する。
【0095】
図２７は、ＩＤ２８のチェックが検知対象とする不整合を説明する図である。固定ルートの「セ」は、センターの意味であり、デポと同義である。各ノードの車両指定と、ルート固定（全ルート固定、前方一致ルート固定）とに基づいて、矛盾なく固定ルートを作成した場合において、荷量の観点から固定ルートに割り当て可能な車両が存在しないことがある。図２７の例では、ノードＡへの配送可能車両として車両ａが指定されている。そのため、ノードＡを含む固定ルートαは、車両ａのみに割り当てることができるが、その場合、車両ａの荷量制限の制約に違反してしまう。
【0096】
図２８は、ＩＤ２８のチェックアルゴリズムの実装例を示す。関連する制約を示すデータは以下の通りである。
・data.vertex.demands：ノード毎の需要量（list）
・data.vehicle_capacities：車両毎の荷量制限（list）
・data.routing_order.const_route.prefix：前方一致固定ルート指定（dict）
・data.routing_order.const_route.all：全固定ルート指定（dict）
・data.vehicle_assignment.available_vehicle：ノード毎の車両指定（dict）
・data.vehicle_assignment.available_vehicle_route.prefix：前方一致固定ルート毎の車両指定（dict）
・data.vehicle_assignment.available_vehicle_route.all：全固定ルート毎の車両指定（dict）
【0097】
data.vehicle_assignment.available_vehicle_route.prefix：前方一致固定ルート毎の車両指定の例を示す。
｛ルートＩＤ：［車両ＩＤ，・・・，車両ＩＤ］，・・・｝
＝｛０：［２，４，５，７］，１：［３，６，９］，・・・｝
この例では、前方一致固定ルート（ルートＩＤ０）において車両ＩＤ２，４，５，７の車両が指定されている。
【0098】
data.routing_order.const_route.prefix：前方一致固定ルート指定の例を示す。
｛ルートＩＤ：［ノードＩＤ，・・・，ノードＩＤ］，・・・｝
＝｛０：［１，２，３，４］，１：［５，６，７，８］，・・・｝
この例では、前方一致固定ルート（ルートＩＤ０）は、ノード１、ノード２、ノード３、ノード４をこの順で訪問するルートであり、前方一致固定ルート（ルートＩＤ１）は、ノード５、ノード６、ノード７、ノード８をこの順で訪問するルートである。
【0099】
data.vehicle_assignment.available_vehicle：ノード毎の車両指定の例を示す。
｛ノードＩＤ：［車両ＩＤ，・・・，車両ＩＤ］，・・・｝
＝｛１：［２，４，７］，５：［３］，・・・｝
この例では、ノード１において車両ＩＤ２，４，７の車両が指定されている。
【0100】
図２８のコード１００では、前方一致固定ルート毎の車両指定と、前方一致固定ルート指定と、ノード毎の車両指定とに基づいて、前方一致固定ルート毎に割り当て可能な車両候補を識別する。上記の例では、前方一致固定ルート（ＩＤ０）を割り当て可能な車両候補は車両ＩＤ２，４，７になり、前方一致固定ルート（ＩＤ１）を割り当て可能な車両候補は車両ＩＤ３のみになる。この場合、コード１００では、以下のような辞書インスタンスが生成される。
｛ルートＩＤ：［車両ＩＤ，・・・，車両ＩＤ］，・・・｝
＝｛０：［２，４，７］，１：［３］，・・・｝
【0101】
図２８のコード１０１では、前方一致固定ルート毎の荷量（ルート上のノードの荷量合計、「ルート荷量」と呼ぶ。）を求め、前方一致固定ルート毎に、割り当て可能な車両候補の中から、ルート荷量≦荷量制限となる車両（「割り当て可能車両」と呼ぶ。）を求める。上記の例において、車両ＩＤ４の荷量制限が極端に小さい場合、コード１０１では、以下のような辞書インスタンスが生成される。
｛ルートＩＤ：［車両ＩＤ，・・・，車両ＩＤ］，・・・｝
＝｛０：［２，７］，１：［３］，・・・｝
図２８のコード１０２では、少なくとも１つの前方一致固定ルートに対する割り当て可能車両が存在しない場合、エラーを検知する。
【0102】
図２８のコード１０３、コード１０４、コード１０５は、それぞれコード１００、コード１０１、コード１０２に対応する。コード１０３では、全固定ルート毎の車両指定と、全固定ルート指定と、ノード毎の車両指定とに基づいて、全固定ルート毎に割り当て可能な車両候補を識別する。コード１０４では、全固定ルート毎のルート荷量を求め、全固定ルート毎に、割り当て可能な車両候補の中からルート荷量≦荷量制限となる割り当て可能車両を求める。コード１０５では、少なくとも１つの全固定ルートに対する割り当て可能車両が存在しない場合、エラーを検知する。
【0103】
ＩＤ２９のチェック「ルート固定における最大訪問ノード数超過」について詳細に説明する。上述のＩＤ２８のチェックは、荷量の観点から車両割り当て可否を判定するのに対し、ＩＤ２９のチェックは、訪問ノード数の観点から車両割り当て可否を判定する。チェック部２４は、特定のノードに訪問するべき車両を定めた制約と、複数のノードの訪問順を定めたルートの制約とに基づいて、或るルートにおけるノード数が、当該ルートに割り当て可能な車両の最大訪問ノード数を超過する場合、複数の制約が不整合と判定する。
【0104】
図２９は、ＩＤ２９のチェックが検知対象とする不整合を説明する図である。各ノードの車両指定と、ルート固定（全ルート固定、前方一致ルート固定）に基づいて、矛盾なく固定ルートを作成した場合において、ノード数の観点で固定ルートに割り当て可能な車両が存在しないことがある。図２９の例では、ノードＡへの訪問可能車両として車両ａが指定されている。そのため、ノードＡを含む固定ルートαは、車両ａのみに割り当てることができるが、その場合、車両ａの最大訪問ノード数の制約に違反してしまう。
【0105】
図３０は、ＩＤ２９のチェックアルゴリズムの実装例を示す。関連する制約を示すデータは以下の通りである。
・data.max_num_visits：車両毎の最大訪問ノード数（list）
・data.routing_order.const_route.prefix：前方一致固定ルート指定（dict）
・data.routing_order.const_route.all：全固定ルート指定（dict）
・data.vehicle_assignment.available_vehicle：ノード毎の車両指定（dict）
・data.vehicle_assignment.available_vehicle_route.prefix：前方一致固定ルート毎の車両指定（dict）
・data.vehicle_assignment.available_vehicle_route.all：全固定ルート毎の車両指定（dict）
【0106】
図３０のコード１１０では、前方一致固定ルート毎の車両指定と、前方一致固定ルート指定と、ノード毎の車両指定とに基づいて、前方一致固定ルート毎に割り当て可能な車両候補を識別する。コード１１１では、前方一致固定ルート毎のノード数（ルート上のノード数であり、「ルートノード数」と呼ぶ。）を求め、前方一致固定ルート毎に、割り当て可能な車両候補の中から、ルートノード数≦最大訪問ノード数となる車両を割り当て可能車両として求める。コード１１２では、少なくとも１つの前方一致固定ルートに対する割り当て可能車両が存在しない場合、エラーを検知する。
【0107】
図３０のコード１１３では、全固定ルート毎の車両指定と、全固定ルート指定と、ノード毎の車両指定とに基づいて、全固定ルート毎に割り当て可能な車両候補を識別する。コード１１４では、全固定ルート毎のルートノード数を求め、全固定ルート毎に、割り当て可能な車両候補の中から、ルートノード数≦最大訪問ノード数となる車両を割り当て可能車両として求める。コード１１５では、少なくとも１つの全固定ルートに対する割り当て可能車両が存在しない場合、エラーを検知する。
【0108】
ＩＤ３０のチェック「時間系矛盾を起こすルート指定」について詳細に説明する。チェック部２４は、複数のノードの訪問順を定めたルートの制約と、複数のノードそれぞれについて予め規定された到着可能時間枠の制約とに基づいて、ルートに割り当て可能な車両が存在しないことを検出した場合、複数の制約が不整合と判定する。
【0109】
図３１は、ＩＤ３０のチェックが検知対象とする不整合を説明する図である。ＩＤ３０のチェックでは、時間系の制約を勘案した場合に、固定ルート（全固定ルートおよび前方一致固定ルート）への割り当てが可能な車両が存在するか否かを確認する。図３１の例では、センター（デポ）における出発可能時間枠を１１時～１１時３０分とする。また、センターからノードＡまでの距離を３０分、ノードＡからノードＢまでの距離を４５分とする。最遅出発時刻である１１時３０分にセンターを出発しても、ノードＢへの到着は１２時４５分となって、店舗Ｂの出発可能時間枠（１３時～１４時）を逸脱してしまう。したがって、図３１の例では、固定ルートαのノード（例えばノードＢ）の出発時間枠を満たす車両を割り当てることができない。
【0110】
図３２は、ＩＤ３０のチェックアルゴリズムを説明する図である。チェック部２４は、固定ルート１２０の各ノードにおける最早出発時刻（最早到着時刻と同義）と最遅出発時刻（最遅到着時刻と同義）が、各ノードにおける出発可能時間枠を満たすか否かを確認する。
【0111】
図３２の（１）～（５）は、処理の流れを示す。（１）に示すように、センターの最早出発時刻および最遅出発時刻と、センターからノードＡまでの距離（３０分）とに基づいて、ノードＡの最早出発時刻（１１時半）および最遅出発時刻（１２時）を求める。そして、ノードＡの最早出発時刻と出発可能時間枠との差分を＋１０分と求める。＋１０分は、到着を１０分遅らせる必要があるという意味である。
【0112】
次に（２）に示すように、＋１０分の差分を、センターおよび店舗Ａの最早出発時刻に反映させる。具体的には、センターの最早出発時刻を１１時１０分に変更し、ノードＡの最早出発時刻を１１時４０分に変更する。
【0113】
次に（３）に示すように、ノードＡの最早出発時刻および最遅出発時刻と、ノードＡからノードＢまでの距離（４５分）とに基づいて、ノードＢの最早出発時刻（１２時２５分）および最遅出発時刻（１２時４５分）を求める。そして、ノードＢの最早出発時刻と出発可能時間枠との差分を＋５分と求め、ノードＢの最遅出発時刻と出発可能時間枠との差分を－５分と求める。－５分は、到着を５分早める必要があるという意味である。
【0114】
次に（４）に示すように、＋５分の差分を、センター、店舗Ａ、店舗Ｂの最早出発時刻に反映させる。具体的には、センターの最早出発時刻を１１時１５分、ノードＡの最早出発時刻を１１時４５分、ノードＢの最早出発時刻を１２時３０分に変更する。また、－５分の差分を、センター、店舗Ａ、店舗Ｂの最遅出発時刻に反映させる。具体的には、センターの最遅出発時刻を１１時２５分、ノードＡの最遅出発時刻を１１時５５分、ノードＢの最遅出発時刻を１２時４０分に変更する。
【0115】
（５）に示すように、上記の処理をノードＤ、ノードＥ、センターの分繰り返す。チェック部２４は、センターおよび全てのノードについて、最早出発時刻≦最遅出発時刻が維持されれば、固定ルート１２０に割り当て可能な車両が存在すると判定し、言い換えれば、複数の制約が整合すると判定する。
【0116】
図３３も、ＩＤ３０のチェックアルゴリズムを説明する図である。（１）に示すように、センターの最早出発時刻および最遅出発時刻と、センターからノードＡまでの距離（３０分）とに基づいて、ノードＡの最早出発時刻（１１時半）および最遅出発時刻（１２時）を求める。そして、ノードＡの最早出発時刻と出発可能時間枠との差分を＋３０分と求める。
【0117】
次に（２）に示すように、＋３０分の差分を、センターおよび店舗Ａの最早出発時刻に反映させる。具体的には、センターの最早出発時刻を１１時３０分に変更し、ノードＡの最早出発時刻を１２時００分に変更する。
【0118】
次に（３）に示すように、ノードＡの最早出発時刻および最遅出発時刻と、ノードＡからノードＢまでの距離（４５分）とに基づいて、ノードＢの最早出発時刻（１２時４５分）および最遅出発時刻（１２時４５分）を求める。そして、ノードＢの最遅出発時刻と出発可能時間枠との差分を－５分と求める。
【0119】
次に（４）に示すように、－５分の差分を、センター、店舗Ａ、店舗Ｂの最遅出発時刻に反映させる。具体的には、センターの最遅出発時刻を１１時２５分、ノードＡの最遅出発時刻を１１時５５分、ノードＢの最遅出発時刻を１２時４０分に変更する。この結果、図３３では、センターおよび各ノードの最早出発時刻が最遅出発時刻より後になってしまう。チェック部２４は、センターまたは少なくとも１つのノードにおいて、最早出発時刻＞最遅出発時刻が生じる場合、エラーを検知し、すなわち、固定ルート１２０に割り当て可能な車両が存在しないと判定し、言い換えれば、複数の制約が不整合と判定する。
【0120】
図３４は、ＩＤ３０のチェックアルゴリズムの実装例を示す。関連する制約を示すデータは以下の通りである。
・data.berth.berth_control：“auto”または“manual”
・data.depot_index：デポのインデックス（int）
・data.edge.time：デポ～ノード間、ノード～ノード間の距離行列（2次元list）
・data.max_delivery_time：車両毎の最大配送時間（list）
・data.time_windows.available_time：ノード毎の出発可能時間枠（dict）
・data.routing_order.const_route.prefix：前方一致固定ルート指定（dict）
・data.routing_order.const_route.all：全固定ルート指定（dict）
・data.vehicle_assignment.available_vehicle：ノード毎の車両指定（dict）
・data.vehicle_assignment.available_vehicle_route.prefix：前方一致固定ルート毎の車両指定（dict）
・data.vehicle_assignment.available_vehicle_route.all：全固定ルート毎の車両指定（dict）
【0121】
ＩＤ３０のチェックにおいても、ＩＤ２８のチェック「ルート固定における荷量上限超過」と同様に、固定ルートへの割り当て可能な車両が存在するか否かを確認する。図３４のコード１３０は、berth_controlが“auto”のとき、すなわち、各車両のバース出発時刻を自動決定するとき、デポの出発可能時間枠をデポの最早出発時刻から最遅出発時刻［ａ，ｂ］に設定する。また、berth_controlが“manual”のとき、すなわち、各車両のバース出発時刻が固定（ユーザにより指定された時刻固定）であるとき、デポの出発可能時間枠をユーザにより指定された各車両の固定時刻［ｃ，ｃ］に設定する。
【0122】
図３４のコード１３１は、berth_controlが“auto”のとき、各車両のデポへの最遅到着時刻を、デポからの出発可能時間枠の下限値（最遅出発時刻）＋各車両の最大配送時間に設定する。また、berth_controlが“manual”のとき、各車両のデポへの最遅到着時刻を、各車両のデポからの出発可能時間枠の下限値（ここでは各車両の固定時刻）＋各車両の最大配送時間に設定する。
【0123】
図３４のコード１３２は、上記のチェックアルゴリズムに基づいて前方一致固定ルートに割り当て可能な車両ＩＤを辞書に保持し、少なくとも１つの前方一致固定ルートに割り当て可能な車両が存在しない場合、エラーを検知する。図３４のコード１３３は、上記のチェックアルゴリズムに基づいて全固定ルートに割り当て可能な車両ＩＤを辞書に保持し、少なくとも１つの全固定ルートに割り当て可能な車両が存在しない場合、エラーを検知する。
【0124】
図３５も、ＩＤ３０のチェックアルゴリズムの実装例を示す。同図は、図３４の「self.__remove_time_range_inconsistency_const_route_all()」の詳細を示している。なお、図３４の「self.__remove_time_range_inconsistency_const_route_prefix()」も同様の実装になる。図３５のコードは、図３２および図３３で示した固定ルート１２０における各ノードの出発可能時間枠を設定する。また、図３５のコードは、固定ルート１２０における各ノードの出発可能時間枠を満たす車両のみ上記の辞書に設定する。
【0125】
図３６も、ＩＤ３０のチェックアルゴリズムの実装例を示す。同図は、図３５の「self.__const_route_check(route, available_time_list)」の詳細を示している。図３６のコードは、図３２の（１）～（５）の処理、および、図３３の（１）～（４）の処理を実装したものである。言い換えれば、図３６のコードは、センタ～ノード間の距離およびノード～ノード間の距離に基づいて、センターおよび各ノードの出発時間枠を編集し、センターまたは少なくとも１つのノードにおいて、最早出発時刻＞最遅出発時刻が生じるか否かを確認する処理を実行する。
【0126】
ＩＤ３１のチェック「配送順指定数の超過（配送可能車両指定）」について詳細に説明する。チェック部２４は、初訪問ノードを定めた第１制約と、最終訪問ノードを定めた第２制約と、初訪問ノードと最終訪問ノードに訪問すべき車両を定めた第３制約とに基づいて、初訪問ノードと最終訪問ノードの個数が、第３制約が定める移動体の個数を超過する場合、複数の制約が不整合と判定する。
【0127】
図３７は、ＩＤ３１のチェックが検知対象とする不整合を説明する図である。ノード毎の配送可能車両指定に基づく、特定の車両群に割り当てるべき初訪問ノードおよび最終訪問ノードの数が、その車両群の車両数より多い場合、各ノードに対する車両割り当てを正常に行うことができない。図３７の例では、２車両に対して、３つのノード指定があるため、車両割り当てを正常に行うことができない。ここでの３つのノード指定は、２つの初訪問ノード（ノードＡ、ノードＢ）の指定と、１つの最終訪問ノード（ノードＤ）の指定である。
【0128】
ＩＤ３１のチェックにおいて、チェック部２４は、割当問題（既述の一般割当問題とは異なる）を解き、解が存在するか否かを確認する。割当問題とは、集合Ｖ＝｛１，・・・，ｎ｝およびｎ×ｎ行列Ｃ＝［ｃｉｊ］が与えられたとき、以下の式７を最小にする順列π：Ｖ → ｛１，・・・，ｎ｝を求める問題である。
【数2】
【0129】
分かり易さのために、割当問題を、仕事を資源に割り当てる問題として解釈する。ｎ個の仕事（例えばノード）があり、それをｎ個の資源（例えば車両）に割り当てることを考える。仕事と資源には相性があり、仕事ｉを資源ｊに割り当てた際の費用をｃｉｊとする。１つの資源では高々１つの仕事しか処理できず、１つの仕事には必ず１つの資源を割り当てるとき、総費用を最小化する問題が割当問題である。
【0130】
仕事ｉを資源ｊに割り当てるとき１、それ以外のとき０となる０－１変数ｘｉｊを用いると、割当問題は以下のように定式化できる。
【数3】
式８は目的関数であり、式９～式１１は制約条件である。
【0131】
図３８は、ＩＤ３１のチェックアルゴリズムを説明する図である。初訪問ノードと最終訪問ノードを車両に割り当てる場合、各ノードと車両との関係は図３８のを表のように定義できる。同図のノードＡ、ノードＣ、ノードＤ、ノードＥは初訪問ノードであり、ノードＢとノードＦは最終訪問ノードである。また、同図の車両ａ～車両ｇは、車両ｇ、車両ｆ、・・・、車両ｂ、車両ａの順に配送ルートが決定されることとする。
【0132】
ノードＡ（初訪問ノード）において車両ｄ、車両ｅ、車両ｆが指定されている場合、これらの車両に該当するセルａｉｊの値（コストとも言える）を降順に３、２、１とし、残りのセルの値をＩＮＦとする。また、最終訪問ノードへの配送可能車両に該当するセルの値は、昇順に２、４、６とし、すなわち初訪問ノードの倍の値を設定する。セルの値を変える理由は後述する。なお、ＩＤ３１のチェックだけであれば、配送可能車両に該当するセルａｉｊの値は全て１でもよい。
【0133】
ノード×車両のセル１つ１つを、０または１の値をとるｘｉｊに対応させることで、割当問題に変換可能である。例えば、ノードＡの行は、式１２のように定義される。
ｘａＡ＋ｘｂＡ＋ｘｃＡ・・・ｘｇＡ＝１ ・・・（式１２）
また、車両ｃの列は、式１３のように定義される。
ｘｃＡ＋ｘｃB＋ｘｃC・・・ｘｃF＝１ ・・・（式１３）
【0134】
実施例では、ｃｉｊをコストとみなすことで最適化を行い、ノード数≦車両数となるように補正する。具体的には、（初訪問ノード数＋最終訪問ノード数）＞車両数となる（この時点で制約違反である）場合、全ての行にＩＮＦを設定した仮の車両を追加で用意する。この場合、どれだけ最適化しても目的関数値はＩＮＦとなる。チェック部２４は、各ノードに車両を割り当てたときに目的関数値がＩＮＦ以上になる場合、制約違反としてエラーを検知する。
【0135】
図３９も、ＩＤ３１のチェックアルゴリズムを説明する図である。同図は、ノードＡ～ノードＦが、車両ａ、ｃ～ｇに正しく割り当てられたことを示している。実施例では、Ｐｙｔｈｏｎの数値計算ライブラリｓｃｉｐｙ（ｓｃｉｐｙ内に実装されているハンガリー法を適用）を用いて求解する。ｓｃｉｐｙ内のハンガリー法では、制約条件が満たされない列を棄却し、実行可能解を出力する。列より行が多い場合はＩＮＦ列を追加して、目的関数値が自動的にＩＮＦを超える状態を作る。また、行より列が多い場合、ｓｃｉｐｙの動作により、行より多い列はなかったことになり、車両の割り当てが行われる。
【0136】
図４０は、ＩＤ３１のチェックアルゴリズムの実装例を示す。関連する制約を示す入力データは以下の通りである。
・data.num_nodes：訪問ノード数（int）
・data.depot_index：デポのインデックス（int）
・data.num_vehicles：車両数（int）
・data.vehicle_assignment.available_vehicle：ノード毎の車両指定（dict）
・data.routing_order.node_after_depot：初訪問ノード指定（list）
・data.routing_order.node_before_depot：最終訪問ノード指定（list）
【0137】
図４０のコード１４０は、初訪問ノードは降順でデータを保持すること、また、最終訪問ノードは昇順でデータを保持することを設定する。図４０のコード１４１は、図３８に示した表に対応するデータを設定する。図４０のコード１４２で示すｓｃｉｐｙの「liner_sum_assignment」関数は、式８～１１に対応する定式が示す問題（割当問題）を解く。また、ハンガリー法を用いることで計算規模を低減することができる。チェック部２４は、最終的な目的関数値がＩＮＦを超えていたらエラーを検知し、すなわち、複数の制約条件が不整合であると判定する。
【0138】
ＩＤ３２のチェック「時間系×割り当て系」について詳細に説明する。図４１は、ＩＤ３２チェックが検知対象とする不整合を説明する図である。チェック部２４は、ノード毎の配送可能車両指定、車両毎の荷量制限、車両毎の最大訪問ノード数、ノード毎の出発可能時間枠、車両毎の最大配送時間、初訪問ノード指定、最終訪問ノード指定、ルート固定（全固定および前方一致固定）を同時に満たす車両割り当てが可能か否かを判定する。すなわち、チェック部２４は、バースに関する制約以外の複数の制約を同時に満たすことが可能か否かを判定する。ＩＤ３２のチェックは、図４１に示す（１）～（６）のチェックを含む。
【0139】
図４２は、ＩＤ３２のチェックアルゴリズムの実装例を示す。図４２のコード１５０は、前方一致固定ルートを割り当て可能な車両リストと、全固定ルートを割り当て可能な車両リストを生成する。コード１５１～コード１５６では、前方一致固定ルートと全固定ルートのそれぞれについて個別のチェックを実行し、制約違反となる車両を車両リストから順次除外していく。
【0140】
具体的には、コード１５１は、初訪問ノードの指定に対して、デポからの出発時刻を考慮した場合に割り当て不能な車両を除外する処理（self.__remove_time_inconsistency_node_after_depot()）を実行する。コード１５２は、最終訪問ノードの指定に対して、デポへの最遅到着時刻を考慮した場合に割り当て不能な車両を除外する処理（self.__remove_time_inconsistency_node_before_depot()）を実行する。
【0141】
コード１５３は、ＩＤ３０のチェック「時間系矛盾を起こすルート指定」と同様の処理を実行し、或る固定ルートに割り当て不能な車両を当該固定ルート用の車両リストから除外する。コード１５４は、ＩＤ２６のチェック「配送車両指定による荷量上限超過」と同様の処理を実行し、或る固定ルートに割り当て不能な車両を当該固定ルート用の車両リストから除外する。
【0142】
コード１５５は、ＩＤ２８のチェック「ルート固定における荷量上限超過」と同様の処理を実行し、或る固定ルートに割り当て不能な車両を当該固定ルート用の車両リストから除外する。コード１５６は、ＩＤ２９のチェック「ルート固定における最大訪問ノード数超過」と同様の処理を実行し、或る固定ルートに割り当て不能な車両を当該固定ルート用の車両リストから除外する。
【0143】
コード１５７は、前方一致固定ルートのそれぞれについて、割り当て可能な車両が存在しない場合にエラーを検知する。コード１５８は、全固定ルートのそれぞれについて、割り当て可能な車両が存在しない場合にエラーを検知する。
【0144】
図４３も、ＩＤ３２のチェックアルゴリズムの実装例を示す。同図は、図４２の「self.__remove_time_inconsistency_node_after_depot()」の詳細を示している。この関数では、デポからの最早出発で初訪問ノードの出発可能時間枠の最遅時刻に間に合わない車両、または、デポからの最遅出発で初訪問ノードの出発可能時間枠の最早時刻より早く到着する車両を車両リストから除外する。
【0145】
図４４も、ＩＤ３２のチェックアルゴリズムの実装例を示す。同図は、図４２の「self.__remove_time_inconsistency_node_before_depot()」の詳細を示している。この関数では、最終訪問ノードからの最早出発でデポへの最遅到着時刻に間に合わない車両を車両リストから除外する。
【0146】
図４２の説明に戻る。図４２のコード１５９は、ＩＤ３１のチェック「配送順指定数の超過（配送可能車両指定）」と同様に、初訪問ノード、最終訪問ノード、固定ルートのそれぞれに割り当て可能な車両をもとにテーブルを作成して割当問題を解く。固定ルートに割り当て可能な車両のデータとしては、図４２のコード１５６が示す、前方一致固定ルートに割り当て可能な車両の辞書データ（self.available_vehicle_const_route_prefix）と、全固定ルートに割り当て可能な車両の辞書データ（self.available_vehicle_const_route_all）を用いる。
【0147】
図４５は、ＩＤ３２のチェックアルゴリズムを説明する図である。ＩＤ３２のチェックでは、全固定ルート（図中の固定ルートＡ、Ｂ）および前方一致固定ルート（図中の前方固定ルートＡ、Ｂ）に関しても考慮する。初訪問ノードおよび最終訪問ノードに対応するセルには、ＩＤ３１のチェックと同じルールで値を設定する。一方、全固定ルートおよび前方一致固定ルートに対応するセルには、車両数×２の値を設定する。
【0148】
図４２のコード１５９では、初訪問ノードにおける車両指定、最終訪問ノードにおける車両指定、固定ルートにおける車両指定に基づいて、図４５に示したテーブル（コストマトリックス）を生成し（self.__map_cost_matrix()）、そのコストマトリックスにおいて各セルのコストを設定し（self.__create_cost_matrix()）、コストマトリックスに基づいて割当問題を解く（self.__execute()）。いずれの関数も、ＩＤ３１のチェック「配送順指定数の超過（配送可能車両指定）」と同様の処理になる。
【0149】
図４６は、ＩＤ３２のチェックアルゴリズムの実装例を示す。同図は、図４２の「self.__create_cost_matrix()」の詳細を示している。図４７も、ＩＤ３２のチェックアルゴリズムの実装例を示す。同図は、図４２の「self.__execute()」の詳細を示している。図４７のコード１６０は、ｓｃｉｐｙの「liner_sum_assignment」関数を用いて割当問題の解を導出している。チェック部２４は、割当問題の解がＩＮＦを超える場合、実行可能解が存在しないためエラーを検知する。なお、図４７のコード１６１は、実施例の実装では含まれないコードであり、後述の変形例にて説明する。
【0150】
次に、配送計画支援システム１６の変換部２６による変換処理を詳細に説明する。変換部２６は、配送計画生成部３０による配送ルートの決定に適用されるアルゴリズムの性質を勘案して、制約データを変換する。
【0151】
まず、配送計画生成部３０が用いる経路導出アルゴリズムである最近傍法について説明する。最近傍法では、現在注目しているノードと、その注目ノードに一番近い他のノードとを結ぶように探索を行う。例えば、配送計画生成部３０は、｛Σ（ルート荷量）≦車両の荷量制限｝を満たし、かつ、｛Σ（移動時間＋滞店時間）≦車両の最大配送時間｝を満たすようにルートを積み上げる。
【0152】
図４８は、最近傍法を用いた経路導出の例を示す。図４８の例では、第１の車両のルートとして、（１）でデポを出発し、複数のノード４０を巡回後、（６）でデポに戻るルートを設定する。続いて、第１の車両とは異なる第２の車両のルートを（７）から作成する。このように、配送計画生成部３０は、最近傍法を用いて、複数の車両の配送ルートを順次決定する。
【0153】
図４９と図５０は、最終訪問ノードに対する車両割り当ての例を示す。図４９は、配送計画生成部３０による配送ルートの決定順序が相対的に先の車両（以下「先決定車両」とも呼ぶ。）に最終訪問ノードを割り当てる例を示している。先決定車両に最終訪問ノードを割り当てると、１つのルート内にデポから近いノードと遠いノードとが混在しやすくなり、車両の最大配送時間の制約違反やノードの出発可能時間枠の制約違反が生じやすくなる。また、それら時間系の制約を守るためには多くの車両が必要となり、実行可能解を求めることが困難になりやすい。
【0154】
図５０は、配送計画生成部３０による配送ルートの決定順序が相対的に後の車両（以下「後決定車両」とも呼ぶ。）に最終訪問ノードを割り当てる例を示している。後決定車両に最終訪問ノードを割り当てると、デポから離れたノードだけを結ぶルートが作成されやすく、また、１つのノード（ここでは最終訪問ノード）だけを含むルート（「１ノードルート」とも呼ぶ。）が作成されやすい。これにより、制約違反が生じた場合の手戻りを少なくでき、実行可能解の導出を容易化できる。
【0155】
図５１と図５２は、初訪問ノードに対する車両割り当ての例を示す。図５１は、後決定車両に初訪問ノードを割り当てる例を示している。後決定車両に初訪問ノードを割り当てると、初訪問ノードだけを含む１ノードルートが作成されやすく、また、初訪問ノード以外のノードだけを含む１ノードルートも作成されやすく、非効率なルートが作成されやすい。また、ルート数が増加するため、車両の不足が生じやすく、実行可能解を求めることが困難になりやすい。
【0156】
図５２は、先決定車両に初訪問ノードを割り当てる例を示している。先決定車両のルートを決定する際には、車両に未割り当てのノードが多く、初訪問ノードからその近傍の別のノードにルートをつなぐことができ、効率的なルートを作成しやすい。これにより、実行可能解の導出を容易化できる。
【0157】
以上を踏まえ、最終訪問ノードは、配送ルートの決定順序が相対的に後の車両（後決定車両）に割り当てた方がよい一方、初訪問ノードは、配送ルートの決定順序が相対的に先の車両（先決定車両）に割り当てた方がよいと言える。また、固定ルート（全固定ルートおよび前方一致固定ルート）は、いずれかの車両に割り当てる必要がある。もちろん、荷量制限および最大訪問ノード数の制約は満たす必要がある。また、各ノードで指定された車両指定の制約は満たす必要があり、それは、初訪問ノードも最終訪問ノードも同じである。
【0158】
また、初訪問ノードに対して、初訪問ノードの出発可能時間枠に到着可能な車両を割り当てる必要がある。また、最終訪問ノードに対して、デポの最遅到着時刻に間に合う車両を割り当てる必要がある。また、固定ルートには、各ノードの出発可能時間枠を守れる車両を割り当てる必要がある。これらの条件を満たすように、初訪問ノード、最終訪問ノード、固定ルートに車両を割り当てれば、配送計画生成部３０による配送ルートの決定を効率化することができる。
【0159】
そこで変換部２６は、後決定車両に対して優先的に最終訪問ノードを割り当てるように、フロントシステム１４から入力された、最終訪問ノードに訪問すべき車両を指定する制約を変換する。かつ、変換部２６は、先決定車両に対して優先的に初訪問ノードを割り当てるように、フロントシステム１４から入力された、初訪問ノードに訪問すべき車両を指定する制約を変換する。
【0160】
実施例では、最終訪問ノードに訪問すべき車両を指定する制約と、初訪問ノードに訪問すべき車両を指定する制約は共通であり、以下「車両指定制約」とも呼ぶ。すなわち、車両指定制約は、最終訪問ノードに訪問すべき車両を指定する制約と、初訪問ノードに訪問すべき車両を指定する制約とを含み、変換部２６は車両指定制約を変換する。
【0161】
具体的には、変換部２６は、ＩＤ３２のチェック「時間系×割り当て系」と同様の処理を実行する。変換部２６は、初訪問ノード、最終訪問ノード、固定ルートのそれぞれに割り当て可能な車両をもとにコストマトリクス（図４５に示したようなテーブル）を作成して割当問題を解く。
【0162】
図４５を再度参照して、割当問題のコストマトリクスを説明する。既述したように、配送計画生成部３０での配送ルートの決定順序は、車両ｇ、車両ｆ、・・・、車両ｂ、車両ａの順である。初訪問ノードは、先決定車両に割り当てた方がよいため、初訪問ノードで指定された車両のうち配送ルートの決定順序が先の車両ほど小さいコスト（強度とも言える）を設定する。一方、最終訪問ノードは、後決定車両に割り当てた方がよいため、最終訪問ノードで指定された車両のうち配送ルートの決定順序が後の車両ほど小さいコスト（強度とも言える）を設定する。
【0163】
また、本発明者の知見によると、初訪問ノードを先決定車両に割り当てることよりも、最終訪問ノードを後決定車両に割り当てることが、配送ルートの求解容易化の観点から重要である。そのため、初訪問ノードで指定された車両に設定するコストよりも、最終訪問ノードで指定された車両に設定するコストを大きくする。実施例では、最終訪問ノードで指定された車両に設定するコストを、初訪問ノードで指定された車両に設定するコストの２倍に設定する。
【0164】
固定ルートは、いずれかの車両に割り当てればよいため、ＩＮＦ未満であればコストは任意の値でよい。実施例では、割り当て車両があまり意味のないことを強調するため、固定ルートで指定された車両のコストとして、とりうる値で最大の値（具体的には車両数×２）を設定する。
【0165】
図５３は、変換部２６の実装例を示す。図５３のコード１７０～コード１７６は、ＩＤ３２のチェックに関連して説明した図４２のコード１５０～コード１５６と同じである。ただし、制約不整合の有無はＩＤ３２のチェックにおいて確認済みのため、エラー検知処理は実行しない。図５３のコード１７７は、図４２のコード１５９に対応する。
【0166】
図５４も、変換部２６の実装例を示す。同図は、図４６に対応し、図５３の「self.__execute()」の詳細を示している。コード１８０は、ｓｃｉｐｙのｓｃｉｐｙの「liner_sum_assignment」関数を用いて割当問題の解を導出する。コストマトリックスにおけるコストの設定により、最終訪問ノードは後決定車両に優先的に割り当てられ、初訪問ノードは先決定車両に優先的に割り当てられ、固定ノードはいずれかの車両に割り当てられた解が導出される。
【0167】
図５４のコード１８１とコード１８２は、配送計画生成部３０へ入力されるノード毎の配送可能車両を指定するデータ（output_available_vehicle）（「出力用ノード車両指定データ」とも呼ぶ。）を設定する。コード１８１は、初訪問ノードに割り当てる車両を出力用ノード車両指定データに設定し、コード１８２は、最終訪問ノードに割り当てる車両を出力用ノード車両指定データに設定する。出力用ノード車両指定データは、フロントシステム１４から入力された車両指定データ（data.vehicle_assignment.availbale_vehicle）を変換したデータと言える。
【0168】
また、図５４のコード１８３とコード１８４は、配送計画生成部３０へ入力される固定ルート毎の割り当て車両を指定するデータ（output_available_vehicle_route）（「出力用固定ルート車両指定データ」とも呼ぶ。）を設定する。コード１８３は、前方一致固定ルートに割り当てる車両を出力用固定ルート車両指定データに設定する。コード１８４は、全固定ルートに割り当てる車両を出力用固定ルート車両指定データに設定する。出力用固定ルート車両指定データは、フロントシステム１４から入力された前方一致固定ルート毎の車両指定データ（data.vehicle_assignment.available_vehicle_route.prefix）と、全固定ルート毎の車両指定データ（data.vehicle_assignment.available_vehicle_route.all）を変換したデータと言える。
【0169】
以上の構成による情報処理システム１０の動作を説明する。
ユーザ端末１２は、ユーザが作成した複数の制約を示すデータを含む配送計画要求をフロントシステム１４へ送信する。フロントシステム１４は、ユーザ端末１２から送信された複数の制約を示すデータを配送計画支援システム１６へ送信する。フロントシステム１４は、デポやノードの緯度経度情報に基づいて導出したデポ～ノード間、ノード～ノード間の時間距離を示す距離行列（data.edge.time）のデータを制約データに含めて配送計画支援システム１６へ送信する。
【0170】
配送計画支援システム１６の受付部２２は、フロントシステム１４から送信された複数の制約データを受け付ける。配送計画支援システム１６のチェック部２４は、複数項目のチェック処理を実行し、複数の制約が整合するか否か（言い換えれば、制約間での矛盾の有無）を判定する。複数項目のチェックは、上記３２項目のチェックを含む。
【0171】
チェック部２４は、チェック処理にてエラーを検知した場合、言い換えれば、複数の制約が不整合であると判定した場合、エラーを検知したチェック項目の情報と、エラーを検知した制約データとを含むエラー通知をフロントシステム１４へ送信する。フロントシステム１４は、そのエラー通知をユーザ端末１２へ送信する。ユーザは、エラー通知に基づいて、制約データを修正する。ユーザ端末１２は、修正後の制約データを含む配送計画要求をフロントシステム１４へ送信し、以降、既述の処理が再度実行される。
【0172】
チェック部２４がエラーを未検知の場合、すなわち、チェック部２４により複数の制約が整合すると判定された場合、配送計画支援システム１６の変換部２６は、配送ルート決定アルゴリズム（実施例では最近傍法）に適合するようフロントシステム１４から入力された制約データの一部を変換する。具体的には、変換部２６は、初訪問ノードを優先的に先決定車両に割り当て、かつ、最終訪問ノードを優先的に後決定車両に割り当て、かつ、制約を満たすいずれかの車両に固定ルートを割り当てるよう出力用ノード車両指定データと出力用固定ルート車両指定データとを生成する。
【0173】
チェック部２４がエラーを未検知の場合、すなわち、チェック部２４により複数の制約が整合すると判定された場合、配送計画支援システム１６の指示部２８は、フロントシステム１４から入力された複数の制約に基づく配送計画指示を配送計画生成部３０に入力する。この際、指示部２８は、フロントシステム１４から入力された車両指定データに代えて、出力用ノード車両指定データを配送計画生成部３０へ入力する。また、指示部２８は、フロントシステム１４から入力された前方一致固定ルート毎の車両指定データと全固定ルート毎の車両指定データに代えて、出力用固定ルート車両指定データを配送計画生成部３０へ入力する。
【0174】
なお、チェック部２４は、配送計画生成部３０による配送ルート決定順を指定する制約データ（例えば、決定順が早いものから車両ＩＤを並べたリスト等）を生成してもよい。図４５の例では、この制約データは、車両ｇ、車両ｆ、・・・、車両ｂ、車両ａの順に配送ルートを決定するよう指定するものであってもよい。指示部２８は、この制約データを含む配送計画指示を配送計画生成部３０に入力してもよい。
【0175】
配送計画支援システム１６の配送計画生成部３０は、最近傍法を用いて、指示部２８から入力された制約データに基づき、複数の車両の配送ルートを決定する。配送計画生成部３０は、複数の車両の配送ルートを示すデータをフロントシステム１４へ送信する。フロントシステム１４は、複数の車両の配送ルートを示すデータを適宜加工後、加工後のデータ（例えば各車両の印刷用コース表等）をユーザ端末１２へ送信する。
【0176】
実施例の配送計画支援システム１６によると、複数の制約を満たしつつ複数の車両の配送ルートを求解する処理を実行する前に、それら複数の制約を同時に満たす実行可能解が存在しない場合、そのことを検知する。これにより、長時間の求解処理を実行したにもかかわらず実行可能解を得られない事態が生じることを回避できる。また、実施例の配送計画支援システム１６によると、配送ルートの決定に適用されるアルゴリズムの性質に応じて、配送ルートを効率的に求解可能なよう制約データを変換する。これにより、配送ルートの実行可能解を迅速に求めることを支援できる。
【0177】
以上、本開示を実施例をもとに説明した。実施例に記載の内容は例示であり、実施例の構成要素や処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解されるところである。
【0178】
第１変形例を説明する。上記実施例の配送計画生成部３０は、最近傍法を用いて配送ルートを決定したが、配送計画生成部３０が配送ルートの決定に用いるアルゴリズムは最近傍法に制限されない。変換部２６による制約データの変換は、配送ルートの決定に用いるアルゴリズムとして、最近傍法と同様にグラフ構造を意識してノードをクラスタリングするアルゴリズムが用いられる場合に有用である。グラフ構造を意識してクラスタリングを行うアルゴリズムとして、例えば、セービング法やクリストファイレス法が用いられてもよい。
【0179】
第２変形例を説明する。上記実施例の配送計画支援システム１６は、チェック部２４と変換部２６の両方を備えたが、変形例として、チェック部２４のみを備える構成であってもよい。第２変形例の配送計画支援システム１６によると、複数の制約を同時に満たす実行可能解が存在しない場合にそのことを配送ルート求解前に検知することにより、長時間の求解処理を実行したにもかかわらず実行可能解を得られない事態が生じることを回避することができる。
【0180】
第３変形例を説明する。上記実施例の配送計画支援システム１６は、チェック部２４と変換部２６の両方を備えたが、変形例として、変換部２６のみを備える構成であってもよい。第３変形例の配送計画支援システム１６によると、配送ルートの決定に適用されるアルゴリズムの性質に応じて配送ルートを効率的に求解可能なよう制約データを変換することにより、配送ルートの実行可能解を迅速に求めることを支援できる。
【0181】
第４変形例を説明する。上記実施例の配送計画支援システム１６は、制約間の整合性のチェックと、制約データの変換とを順次実行した。変形例として、チェック処理と変換処理とを並行して実行してもよい。この場合、図４７で示すように、ＩＤ３２のチェック「時間系×割り当て系」のコードにコード１６１が含まれてもよい。この変形例によると、チェック処理と変換処理で重複する処理を排除でき、チェック処理と変換処理を効率的に実行することができる。
【0182】
上述した実施例および変形例の任意の組み合わせもまた本開示の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
【産業上の利用可能性】
【0183】
本開示の技術は、荷物の配送計画を支援する装置やシステムに適用することができる。
【符号の説明】
【0184】
１０ 情報処理システム、 １６ 配送計画支援システム、 ２０ 前処理部、 ２２ 受付部、 ２４ チェック部、 ２６ 変換部、 ２８ 指示部、 ３０ 配送計画生成部。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】
【図51】
【図52】
【図53】
【図54】
Copyright © 2010-2025 Science Impact Inc. All Rights Reserved.