JP6268331B2 - スケジュール調停システム - Google Patents

Description

本発明は、複数のシステム間におけるスケジュール調停システムに関する。

近年、生産のグローバル化に伴い、同じデバイスを多拠点に分けて生産する機会が増加傾向にある。

ここで、複数の生産拠点をコントロールするための技術として、例えば、特許文献１に記載の技術がある。特許文献１では、各生産拠点の生産リードタイムおよび調達部材のリードタイムに基づいて一定期間後のデリバリおよび在庫量を予測し、この予測したデリバリおよび在庫量に基づいて複数の生産拠点の生産機種の優先順位および出荷計画を立案する技術が開示されている。

特開２０１２−１４１８０６号公報

しかしながら特許文献１は、複数の生産拠点で生産される生産機種の優先順位および出荷計画を立案する技術であり、複数の生産拠点における生産システムが夫々持つ制約に不整合が生じることは考慮されていない。そのため、複数のシステム間で不整合が生じるようなリソースを配分することが困難である。

開示するスケジュール調停システムは、第１のサーバ、第２のサーバ、スケジュール調停サーバを備える。

第１のサーバは、予め記憶された第１のスケジュール作成制約と、一定期間の第１のスケジュール情報とをスケジュール調停サーバに送付し、第２のサーバは、予め記憶された第２のスケジュール作成制約と、一定期間の第２のスケジュール情報とをスケジュール調停サーバに送付する。

スケジュール調停サーバの記憶部は、全体最適制約情報を記憶し、スケジュール調停サーバの制御部は、第１のサーバと前記第２のサーバから、第１のスケジュール作成制約、第１のスケジュール情報、第２のスケジュール作成制約、及び第２のスケジュール情報とを取得する取得部と、第１のスケジュール作成制約、第１のスケジュール情報、第２のスケジュール作成制約、及び第２のスケジュール情報と、記憶部に記憶された全体最適制約情報から、第１のスケジュール情報と第２のスケジュール情報との間の不整合を検出する不整合検出部と、不整合が検出された場合、第１のスケジュール情報と第２のスケジュール情報とを修正して第３のスケジュール情報と第４のスケジュール情報とを再作成するスケジュール再作成部と、修正度合いに応じて第１のサーバと前記第２のサーバに対して、第１のクレジットと第２のクレジット夫々を算出するクレジット算出部と、第３のスケジュール情報と第１のクレジットを第１のサーバに送付し、第４のスケジュール情報と第２のクレジットとを第２のサーバに送付する送信部とを備える。

本発明によれば、複数のシステム間で不整合が生じるような場合でもリソースを配分することが出来る。

共生自律分散システムの概念を示す例図である スケジュール調停システムの構成を示す例図である スケジュール調停サーバ１、自律個サーバ群２のサーバのハードウェアの構成を示す例図である 本実施例におけるスケジュールの調停の対象を示す例図である 路面の初期保守スケジュールを示す例図である。 灯具の初期保守スケジュールを示す例図である。 交通の初期保守スケジュールを示す例図である。 電力の初期保守スケジュールを示す例図である。 自律個サーバ群２のサーバのソフトウェア構成を示す例図である。 スケジュールの制約条件を示す例図である。 初期保守スケジュールのメッセージの内容を示す例図である。 スケジュール調停サーバ１のソフトウェア構成を示す例図である。 路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌ間の初期保守スケジュールにおける競合発生を示す例図である。 路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌ間の初期保守スケジュールにおける競合発生を示す例図である。 電力保守計画サーバ２−Ｐと交通管理サーバ２−Ｏ間の初期保守スケジュールにおける競合発生を示す例図である。 電力保守計画サーバ２−Ｐと交通管理サーバ２−Ｏ間の初期保守スケジュールにおける競合発生を示す例図である。 スケジュール作成方針ビューアのＧＵＩを示す例図である。 調停のパターンを記載した例である。 「調停時間入力部」のＧＵＩを示す例図である。 優先権ポイント発行ポリシーを設定する画面を示す例図である。 初期保守スケジュールに対する路面保守スケジュールの修正スケジュール例図である。 初期保守スケジュールに対する灯具保守スケジュールの修正スケジュール例図である。 初期保守スケジュールに対する電力保守スケジュールの修正スケジュール例図である。 初期保守スケジュールに対する交通スケジュールの修正スケジュール例図である。 ｏｆｆｅｒアサーションメッセージの内容を示す例図である。 初期保守スケジュールとスケジュール制約条件と比較（路面保守計画サーバ２−Ｔにおける比較）している例図である。 初期保守スケジュールとスケジュール制約条件と比較（灯具保守計画サーバ２−Ｌにおける比較）している例図である。 再提案のアサーションメッセージの例図である。 オファを拒否するアサーションメッセージの例図である。 スケジュールをオファするアサーションメッセージを示す例図である。 自律個サーバ群２のサーバの状態遷移を示す例図である。 保守区間と必要な時間のみを含むアサーションメッセージを示す例図である。 ｒｅｊｅｃｔアサーションメッセージが発行されやすい時間帯を示す例図である。 スケジュール調停システムの全体シーケンスの例図である。 バルブ調整システムの構成を示す例図である。 会議スケジューリングシステムの構成を示す例図である。 スケジュール調停スケジュール調停サーバ１に対して路面保守計画サーバ２−Ｔからポイントが送付された場合の路面保守計画サーバ２−Ｔの修正スケジュール例。 スケジュール調停スケジュール調停サーバ１に対して路面保守計画サーバ２−Ｔからポイントが送付された場合の灯具保守計画サーバ２−Ｌの修正スケジュール例。 自律個サーバ群２の表示画面例。

＜共生自律分散システムの概要説明＞
図１は、共生自律分散システムの概念を示す図である。

国内における社会インフラ事業の新規投資は飽和状態にあり、海外インフラについても競争が激化し参入が難しい状況にある。また、企業間の合併、併合または同種類の業務提携も行われてはいるが、設備やサービスの共用による経費削減の効果しか期待できない状況にある。そんな中、同種または異種の事業を協業させる場所（以下「場」という）を作り、その「場」において複数の現存システムを共生させることで、未知の新しいサービスやビジネスを創成する方法が模索されている。このような共生を実現するシステムを共生自律分散（登録商標）システムといい、また、当該システムによって創成されるサービスを共生自律分散サービスという。

ここで、異種または同種の事業における、異種または同種の業務の実施主体を「自律個」と、また、当該自律個サーバ群２のサーバに共生の「場」を提供する実施主体を「協調場」という（図１）。

＜共生自律分散システムの適用例＞
図２は、スケジュール調停システムの構成を示す図である。

スケジュール調停サーバ１は、「協調場」に対応する。路面保守計画サーバ２−Ｔ、灯具保守計画サーバ２−Ｌ、電力保守計画サーバ２−Ｐ、交通管理サーバ２−Ｏ（これらをまとめて自律個サーバ群２という）は、「自律個」に対応し、スケジュール調停サーバ１と自律個サーバ群２とは、ネットワーク３に接続されている。また、後述する図６が自律個A２４０６〜自律個C２４０８（自律個サーバ群２）の詳細であり、図１０が協調場２４０５（スケジュール調停サーバ１）の詳細である。

自律個サーバ群２の各サーバは、自律個サーバ群２のサーバの目的を達成する為のシステムの構成要素であり、これを自律個システムという。自律個サーバ群２のサーバには、自律個システムを運用するＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ重要業績評価指標）があり、これを「個別ＫＰＩ」という。自律個システムとは、自律個サーバ群２のサーバにおける個別ＫＰＩを達成あるいは最大化する為に存在する。自律個システムは、鉄道交通管理システム、鉄道保守システム、電力管理システム等、どのようなシステムであってもよく、既設でも新設でも運用中のシステムでも構わない。

スケジュール調停サーバ１も、協調場の目的を達成する為のシステム構成要素であり、これを協調場システムという。協調場には、協調場システムを運用するＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ重要業績評価指標）があり、これを「全体ＫＰＩ」という。協調場システムは全体ＫＰＩを達成あるいは最大化する為に存在する。

共生自律分散における「共生」とは、協調場が全体ＫＰＩの最大化を目指しつつ、同時に、各自律個が自己の個別ＫＰＩの最大化を目指して共存している状態をいう。理想的には、全体ＫＰＩと個別ＫＰＩの両方が常に同時に最大化されることが望ましいが、このような全体ＫＰＩと個別ＫＰＩは、相反関係となる場合がある。

本実施例は、協調場システムを具体化するサーバ（以下、協調場サーバという）と、自律個システムを具体化する二以上のサーバ（以下、自律個サーバ、または自律個サーバ群という）からなる。この協調場サーバと自律個サーバは、調停プロトコルに基づくアサーションメッセージの交換を行う。以後、このアサーションメッセージの交換のことを「調停」という。

ここに「アサーションメッセージ」とは、自己の要求を主張する内容を記載したメッセージを言う。「アサーション」とは、相手方の主張を考慮しつつ行う主張であり、自己の状況の説明、相手方への相談、相手方への譲歩を伴う点において、単なる「クレーム」とは、その考え方において異なる。

図２５は、バルブ調整システムの構成を示す図である。

本実施例における共生自律分散システムは、バルブ調整システムにも適用できる。

バルブ調整サーバ２５１は、「協調場」に対応する。地域A水運用サーバ２５２、地域B水運用サーバ２５３、地域C水運用サーバ２５４、地域D水運用サーバ２５５は、「自律個」に対応し、ネットワーク２５６に接続されている。本実施例における共生自律分散システムがバルブ調整システムに適用された場合は、トータル電力コストを削減するために、バルブ調整サーバ２５１は、各地域の水運用サーバの運用スケジューリングを調整し、各地域の水運用サーバが調整されたスケジュールに従って、バルブを制御することになる。

図２６は、会議スケジューリングシステムの構成を示す図である。

本実施例における共生自律分散システムは、会議スケジューリングシステムにも適用できる。

会議スケジューリングサーバ２６１は、「協調場」に対応する。ユーザA端末２６２、ユーザB端末２６３、ユーザC端末２６４、ユーザD端末２６５、は、「自律個」に対応し、ネットワーク２５６に接続されている。本実施例における共生自律分散システムが会議スケジューリングシステムに適用された場合は、会議出席者の予定を調整するために、会議スケジューリングサーバ２６１が、各ユーザの端末からユーザのスケジュール情報を取得し、会議の日時と場所を調整して、各ユーザの端末に日時と場所の情報を送付することになる。

＜共生自律分散システムをスケジュール調停システムへ適用した例＞
上記のような適用例が考えられるが、本実施例では、スケジュール調停システム（図２）への適用した場合を考えて、以下の通り説明する。

図２４は、スケジュール調停システムの全体シーケンス示す例図である。

スケジュール調停サーバ１が、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌのスケジュール調停を行う例を示した全体シーケンスである。

路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌは、予め記憶されたスケジュール作成制約と、一定期間のスケジュール情報（計画A、計画B）とをスケジュール調停サーバ１に送付する（Step２４０１、Step2402）
スケジュール調停サーバ１は、スケジュール方針入力部がシステム全体のスケジュール方針に関する情報であるスケジュール方針情報を取得し、不整合検出部が、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌから取得したスケジュール作成制約と、スケジュール方針情報に基づいて、一定期間のスケジュール情報（計画A、計画B）との間の不整合を検出する（Ｓｔｅｐ２４０３）。つまり、（式１）を用いて計画A、計画Bとの間のスケジュール衝突を検出する。

ここにnは、初期スケジュールとして提出するスケジュールの数、A_Kは、k番目のスケジュールに示す保守エリア、T_Kは、k番目の時間帯を示す。A_Kの一例としては、あるインターチェンジから別のインターチェンジまでの高速道路の区間があり、T_Kの一例としては、午前1時から3時までの2時間、などがある。
A'_K、T'_Kは、それぞれ初期スケジュール後に変更されたスケジュールの中で、初期スケジュールと重複する保守エリア、および時間帯を示す。A_Kの単位としては、インターチェンジ間の区間数としても良いし、Tkの単位としては、その時間帯の「分」を使っても良い。従って、初期スケジュールの内容が、全て調停後のスケジュールと同じになっている場合は、KPIは100%となる。

例えば図15-1において、初期スケジュールの時間(8時間)に対して、調停場からオファされたことによるスケジュールの重複は6.5時間となっているので、KPIは81.25%となる。

なお、このKPIの定義は、はスケジュール問題には好適な方法の一つであるが、この方法に限定する必要はない。

スケジュール調停サーバ１は、記憶部が、予め全体最適制約情報を記憶しておき、クレジット算出部が、全体最適制約情報に基づいて、スケジュール情報（計画A、計画B）を修正して提案スケジュール情報（計画A’、計画B’）を再作成する（Ｓｔｅｐ２４０４）。

スケジュール調停サーバ１は、計画の修正度合いに応じてクレジットを算出する（Ｓｔｅｐ２４０５）。クレジットの算出方法については、当初計画から修正があった分数をそのままポイントとして算出しても良い。 スケジュール調停サーバ１は、送信部が、提案スケジュール情報（計画A’、計画B’）とクレジットを路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌの夫々に送付する（Ｓｔｅｐ２４０６、２４０８）。路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌは、提案スケジュール情報（計画A’、計画B’）を表示画面に表示し、承認または拒否の入力を受け付けて、スケジュール調停サーバ１に結果を送付する（Ｓｔｅｐ２４０７、２４０９）。スケジュール調停サーバ１は、全サーバ（この例では、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌ）から承認が得られた場合、修正計画とクレジットが決定の旨を送付する（Ｓｔｅｐ２４１０）。路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌは決定されたスケジュール情報とクレジットを表示し、スケジュールを実行する。

図２８は、自律個サーバ群２の表示画面例である。

図３は、スケジュール調停サーバ１、自律個サーバ群２のサーバのハードウェアの構成を示す図である。

ＣＰＵ１１−０１（制御部）、メモリ１１ー０２（記憶部）、通信ＮＩＣ１１−０３、ハードディスクドライブ（以下ＨＤＤという）１１−０４、入出力コントローラ１１―０５、モニタコントローラ１１―０６は、バス１１―０７等で接続されている。入出力コントローラ１１―０５は、キーボード、マウスと接続し、入出力コントローラ１１―０５は、ディスプレイと接続する。

図４は、本実施例におけるスケジュールの調停の具体例を示す図である。

図中のＮ１〜Ｎ１０は、ある高速道路のインターチェンジを示しており、その駅をつなぐ線は、その鉄道の路線を示している。路面保守（Ｔｒａｃｋ）、灯具保守（Ｌｉｇｈｔ）、電力保守（Ｐｏｗｅｒ）、交通（Ｏｐｅｒａｔｉｏｎ）の保守区間は、本実施例においてはある駅を終端としている。この保守区間は、保守の業務を行う単位である。

路面保守とは、高速道路の路面の保守業務のことである。例えば道路は車両の加重で沈下し続けるので、これを持ち上げる作業はその一つである。

灯具保守とは．高速道路の灯具の保守業務のことである。例えば、故障した灯具や所定の期間を経過した灯具を交換する作業はその一つである。

電力保守とは、高速道路の各所に電力を安定して提供するために電力機器の修理や交換を行うことであり、交通とは、自動車車両の交通制御に関する事項をいう。但し、本実施例においては、電力保守区間と交通区間は、電気が流れる区間と、自動車の交通を制御する区間として取り扱う。

例えば、路面保守はインターチェンジＮ１〜Ｎ３を一つの業務単位（Ｔ１）として行う。Ｔ１区間で２つの路面保守を行うことはできないが、Ｔ１とＴ２の区間を同時刻に行うことは可能である。

しかし、路面保守区間Ｔ１と灯具保守区間Ｌ１は、区間が重複しているので、同時刻に路面保守業務と灯具保守業務を実施することはできない。

また、路面保守も灯具保守も業務員の安全を確保するために、該当する区間に電気が通電中には業務することができないものとする。つまり、電力区間Ｐ１が通電している時間帯においては、区間Ｔ１，Ｔ２，Ｌ１，Ｌ２のいずれの区間も保守業務が行えない。

一方、電気が通電していないと、自動車を走らせることができない場合があるので、例えば、交通区間Ｏ１で自動車の交通制御が行われている間は、電力区間Ｐ１は通電されていなければならない場合がある。また、自動車の交通制御中には、路面保守も灯具保守も行えないものとする。

本実施例では、発明の実施の態様の理解を助けるために、敢えて、以下のように設定を単純化する。まず、一週間に一度の路面保守（Ｔｒａｃｋ）、灯具保守（Ｌｉｇｈｔ）、電力保守（Ｐｏwｅｒ）、交通（Ｏｐｅｒａｔｉｏｎ）の保守のスケジュールの調整を行うケースで設定しているが、実際には、もっと長い期間（１ヶ月、半年）のスケジュールの調停を行うようにしてもよい。また、同様に、路面保守と灯具保守は、１つの保守の実施主体（保守チーム）のみを有する設定としているが、実際には、２以上の保守チームが、同時刻に別の保守線区で業務をしてもよい。

このようなスケジュール調整を行うに際しては、各自律個サーバが最初に提案する保守スケジュール（以下、初期保守スケジュールという）から大きく逸脱しないスケジュール調整が行われることが望ましい。なぜなら、それぞれの保守業務を実施する会社（以下、保守会社という）は、それぞれの保守会社にとって、個別ＫＰＩを最大化するもっとも都合の良いスケジュールを組むと考えられるためである。

具体的には、保守員の都合のよい日時や時間、保守員の詰所から保守業務を行う場所までの距離などがスケジュールに反映されると考えられる。なぜなら保守員の移動や残業や、業務時間は、コストに影響する為である。

そこで本実施例においては、自律個サーバ群２のサーバの各サーバの各自律個サーバの初期保守スケジュールを、「個別ＫＰＩ」として把握する。初期保守スケジュールに一切の変更なく調停が完了した状態を「個別ＫＰＩの最大化が達成された状態」と考えるものとする。

路面保守（Ｔｒａｃｋ）、灯具保守（Ｌｉｇｈｔ）の保守業務を行う場所や時間が重複する場合は、いずれかの保守業務を断念させなければならないが、当然これはそれぞれの保守会社にとっては、個別ＫＰＩの最大化が達成できず、不利益が発生したものと考えるものとする。

一方、スケジュール調停サーバ１における「全体ＫＰＩが最大化された状態」とは、全ての自律個から提出された初期スケジュールの案件数に対して、自律個の調停によって採用されたスケジュールが全て採用された状態と考えるものとする。

本システムの目的は、スケジュール調停サーバ１のＫＰＩの最大化を目指しつつ、自律個サーバの個別ＫＰＩの最大化も目指すという２つの目的を同時に解決することである。

まず、それぞれの保守業務を管理する自律個サーバ群２のサーバのそれぞれのサーバは、翌週の保守スケジュールを決めるために、所定の日時の時間までに希望スケジュールを、スケジュール調停サーバ１に送付する。

図５−１は、保線（Ｔｒａｃｋ）の初期保守スケジュールを示す図である。図５−２は、架線（Ｌｉｇｈｔ）の初期保守スケジュールを示す図である。図５−３は、交通（Ｏｐｅｒａｔｉｏｎ）の初期保守スケジュールを示す図である。図５−４は、電力（Ｐｏｗｅｒ）の初期保守スケジュールを示す図である。

図６は、自律個サーバ群２のサーバのメモリ１１−２に記憶されているソフトウェア構成を示す図である。図中の矢印は、ソフトウェアモジュールが呼び出され、または、参照される関係を示し、プログラムのアルゴリズムとしても把握されるものとする。

これらのプログラムは、図3のメモリ11―02に展開され、CPU11-01によって実行される。通信処理部2―2、オンライン処理部2―3の各モジュールに必要な記憶情報は、メモリ11―02に格納されるが、オフライン処理部2―4の各モジュールに必要な記憶情報は、メモリ11―02だけではなく、HDD11-04にも記録される。

オペレーション部２−１にある、「初期保守スケジュール作成部」において、自律個サーバ群２のサーバの各サーバにおいて、この初期保守スケジュールが作成される。この作成は、図３のディスプレイ、キーボード、マウスを使うオペレータが所定のツールを用いて作成してもよい。この初期保守スケジュールは、通信処理部２−２の「アサーションメッセージ送信部」に格納される。

また、図７は、路面保守（Ｔｒａｃｋ）スケジュールの制約条件（以下、スケジュール制約条件という）を示す図である。

９月２２日（火）と９月２６日（土）は、定休日であるため１００％保守業務が実施できないことを示している。また９月２６日（日）、９月２３日（水）の２８時３０分以降、９月２４日（木）の２７時以降は、それぞれ３０％、７０％、５０％の重みで業務の実施が難しいことが示されている。この数値に関しては、自律個サーバを運営する保守会社の方針で決められることになる。その方針の指標の例としては、その時間帯に業務を行う場合の追加コスト（残業代や移動コスト）などを勘案して数値化する、などの手法を採りうる。

このスケジュール制約条件は、オペレーション処理部２−１にある、「スケジュール制約条件作成部」において作成され、オンライン処理部２−３の「実行可能性推測部」に転送される。このスケジュール制約条件も上記と同様にオペレータが所定のツールを用いて作成しても良い。各自律個サーバの初期保守スケジュールは、図６の自律個サーバの通信処理部２−２の「アサーションメッセージ送信部」から送信される。

図８は、この各自律個サーバ群２のサーバの中の、路面保守計画サーバ２−Ｔにおいて初期保守スケジュールのメッセージ（ｓｕｇｇｅｓｔｉｏｎアサーションメッセージ）の内容を示す図である。

図８の最初から４行目までは、保守業務時間帯と保守業務区間を示している。最初の１行目は、２０１５年９月２１日の２５時から２７時までの時間帯で区間Ｔ１の保守業務を初期提案している旨の記述となる。５行目は、火曜日と土曜日は業務ができない日として記載している。例えば、保守会社が定休日の場合などである。このような日は、スケジュール調停サーバ１による調停を行ったところで、必ず路面保守計画サーバ２−Ｔから拒否されることになる。但し、初期保守スケジュールの記載は必須であるが、このような定休日情報の記載は必須ではない。これと同じような業務は、路面保守計画サーバ２−Ｔ２−Ｗ、電力保守計画サーバ２−Ｐ、交通計画サーバ２−Ｏでも同様に実施する。

図９は、スケジュール調停サーバ１のメモリ１１−２に展開されているソフトウェア構成を示す図である。図中の矢印は、ソフトウェアモジュールが呼び出される、または、参照される関係を示し、プログラムのアルゴリズムとして把握されるものとする。これらのプログラムは、図3のメモリ11―02に展開され、CPU11-01によって実行される。通信処理部2―2、オンライン処理部2―3の各モジュールに必要な記憶情報は、メモリ11―02に格納されるが、オフライン処理部2―4の各モジュールに必要な記憶情報は、メモリ11―02だけではなく、HDD11-04にも記録される。

自律個サーバ群２において初期保守スケジュールのアサーションメッセージ（ｓｕｇｇｅｓｔｉｏｎアサーションメッセージ）は、ネットワーク３を介して、スケジュール調停サーバ１の通信処理部１−２と、他の自律個サーバ群２のサーバの通信処理部２−２の「アサーションメッセージ受信部」で受信される。

さらに、このアサーションメッセージはオンライン処理部１−３の「アサーションメッセージ確認部」に転送され、フォーマット等の形式チェックを受け、フォーマットに瑕疵がある場合は修正される。

この情報は、さらに、「欠損情報推測部」に送付されるが、本ケースのアサーションメッセージには欠損情報がないので、再び、「アサーションメッセージ確認部」にそのままのアサーションメッセージとして戻される。

オンライン処理部１−３の「アサーションメッセージ確認部」は、路面保守計画サーバ２−Ｔ、灯具保守計画サーバ２−Ｌ、電力保守計画サーバ２−Ｐ、交通管理サーバ２−Ｏからの初期保守スケジュールのアサーションメッセージ（ｓｕｇｇｅｓｔｉｏｎアサーションメッセージ）が揃ったら、「不整合判定部」に、それらの保守スケジュールを転送する。「不整合判定部」は、スケジュールの衝突（以下、競合という）が発生していないかをチェックする。

図１０−１、図１０−２は、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌ間路面保守灯具保守の初期保守スケジュールにおける競合発生を示す図である。図４の保守区間と初期保守スケジュールを照合して比較すると、９月２１日（月）のＴ１区間の保守とＷ１区間の保守が競合していることが分かる。また、９／２４（木）のＴ３区間の保守とＷ３区間、９／２５（金）のＴ４区間の保守とＷ４区間も競合している。

図１０−３、図１０−４は、電力保守計画サーバ２−Ｐと交通管理サーバ２−Ｏ間の初期保守スケジュールにおける競合発生を示す図である。９／２６（土）の２６時から２８時の車両の交通時間に、電気が通電されてない状況があることが分かる。

これらの初期保守スケジュールは、オンライン処理部１−３の「代替案作成部」に入って、代替スケジュールの作成が行われる。代替案作成に関しては、事前にオペレーション処理部１−１の「スケジュール作成方針部」から、スケジュール作成方針が示される。

図１１は、このスケジュール作成方針ビューアのＧＵＩを示す図である。自律個サーバ群２における図３のディスプレイに表示される例である。 図１２は、協調場サーバとして振舞うスケジュール調停サーバ１と、自律個サーバとして振舞う路面保守計画サーバ２−Ｔと、灯具保守計画サーバ２−Ｌをあげて、スケジュール調停サーバ１と自律個サーバ群２のサーバのサーバとの調停のパターンを記載したものである。すなわち、制約（KPI）を満たせなかったスケジュール調停サーバ１と自律個サーバ群２に対して、制約違反が生じた分数分のポイントが付与される。更に、優先権ポイントが提示された場合、もっとも多くの優先権ポイントを提示したスケジュール調停サーバ１又は自律個サーバ群２の制約を満たすように調停される。

調停パターンＡは、自律個サーバ群２のサーバ間では競合は発生していないが、自己のＫＰＩを最大化したいスケジュール調停サーバ１と自律個サーバ群２のサーバのサーバで競合が発生している状態を示している。調停を何度繰り返しても纏まらない場合は、スケジュール調停サーバ１または自律個サーバ群２のサーバのサーバは自己の有するクレジット（以後、優先権ポイントという）に基づく優先権を主張することが可能となる。

この優先権ポイントは、スケジュール調停サーバ１と自律個サーバ群２の間で利用可能な共通貨として把握することができる。優先権の主張が競合した場合には、この通貨の額であるポイントの数が大きいほうの優先権の主張を採用するものとして競合を解決する。

本実施例においては、この優先権を定量化したものが「優先権ポイント」である。これは、調停で取り扱う資源である「時間（分）」をベースとするものとする。例えば３０分の時間を調停の対象とする場合、その時間の価値は、原則として３０ポイント程度を基準に考える。もちろん、このポイントの価値は、その時間を欲するスケジュール調停サーバ１または自律個サーバ群２のサーバによって流動的に決定されるので、この３０ポイントはあくまで目安である。 優先権は、調停案を自律個サーバ群２のサーバに受け入れて貰いたいスケジュール調停サーバ１、あるいは初期時の提案または再提案をスケジュール調停サーバ１に受け入れて貰いたい自律個サーバ群２のサーバから、ポイント（数値）を付与して提案されることになる。この競合を解決する為に、ポイントの多い方の提案または再提案が採用され、そのポイントは採用されなかった側に移動する。つまり、採用されなかった側は、別の機会にそのポイントを使った優先権主張が可能となる訳である。例えば、自律個サーバ群２からスケジュール調停サーバ１に初期保守スケジュールを送付する際に、優先権ポイントを合わせて送付する（図２４のS２４０１）。

調停パターンＢは、スケジュール調停サーバ１のＫＰＩには影響がない範囲で、自己のＫＰＩを最大化したい２以上の自律個サーバ群２のサーバ間で競合が発生している状態を示している。調停を何度繰り返しても纏まらない場合は、各自律個サーバ群２のサーバは再提案に自己の有するポイントに基づく優先権を主張することが可能となる。スケジュール調停サーバ１は、自律個サーバ群２のサーバから提案されてきたポイントに応じて、調停を実施する。この調停の方法としては、自分以外の自律個への影響の度合い等を勘案して再調停をしてもよい。もっとも簡単な方法としては、もっとも高いポイントを付与してきた提案を最優先に採用することである。

提案が受理された自律個サーバ群２のサーバのポイントは、受理されなかった自律個サーバ群２のサーバに分配配分される。この分配方法は、他の自律個への影響の度合い等を勘案して配分をしてもよいし、もっとも簡単な方法としては、当分分配して配分しても良い。

調停パターンＣは、スケジュール調停サーバ１と２以上の自律個サーバ群２のサーバのＫＰＩの全ての影響があり、これらの間で競合が発生している状態を示している。調停を何度繰り返しても纏まらない場合は、スケジュール調停サーバ１と各自律個サーバ群２のサーバは再提案に自己の有するポイントに基づく優先権を主張することが可能となる。スケジュール調停サーバ１は、スケジュール調停サーバ１も含む自律個サーバ群２のサーバから提案されてきたポイントに応じて、調停を実施する。調停方法やポイントの配分については、上記の内容に順ずるものとする。

なお、これらの調停の状態は、スケジュール調停サーバ１だけではなく、全ての自律個サーバ群２のサーバに開示されるものとする。具体的には、調停案や再提案を含む全てのアサーションメッセージは、全ての自律個サーバ群２のサーバにも転送される。調停の公平性を、共生自律分散システムの全てのサーバで監視するためである。

但し、調停情報が、自律個サーバ群２のサーバの営業秘密情報の開示等に該当するなどの場合には、調停の状態を秘密にできるようにしても良い。

また、スケジュール調停サーバ１が指定した時間内であれば、再提案やポイントの増加は何度でも可能であるが、後発的にその提案やポイント増加を取り下げることはできない。

図１３は、図９のオペレーション処理部１−１の「調停時間入力部」のＧＵＩを示す図である。ここに、「オークション方式」と「協調場裁定方式」の２種類の指定方式が記載されているが、これに限定されるものではない。「オークション方式」とは、所定の時間までにもっとも良い条件の優先権を提示したスケジュール調停サーバ１または自律個が希望する時間帯を確保できるものである。「協調場裁定方式」とは、スケジュール調停サーバ１のルールで条件を指定できるものである。例えば、スケジュール調停サーバ１がポイントの上限を予め決めておき、そのポイントに至ったら優先権を主張できる主体を決定できるものである。この条件は、編集ボタンを押下すると画面に出てくるエディタ等で編集することができる。

図１４は、スケジュール調停サーバ１、自律個サーバ群２のサーバの全てのサーバで持つ、優先権ポイント発行ポリシーを設定する画面を示す図である。これらのポリシーは、図６のオペレーション処理部２−１の「優先権ポイント発行方針入力部」、図９のオペレーション処理部１−１の「優先権ポイント発行方針入力部」から入力する。

「初期発行ポイント」では、優先権ポイントの最初の値を設定する。デフォルト値は、競合が起きている時間（分）の値であるが、オペレータが手動で入力することもできる。「最終発行ポイント」は、優先権ポイントの最大値を設定する。デフォルト値は、競合が起きている時間（分）の倍の値であるが、オペレータが手動で倍数の値を入力することもできる。

但し、スケジュール調停サーバ１、自律個サーバ群２のサーバともに、自分の所持している優先権ポイントの値を超えて付与することはできない。そのような場合は、付与はその上限値で停止することになる。

「オークション運用方針」は、オークションの分割回数、開始時または終了直前に高いポイントを付与するなどの各種のオークションの戦略を記述したスクリプトを読み込むことができるものである。

図９のオンライン処理部１−３の「不整合判定部」は、オペレーション処理部１−１の「スケジュール作成方針入力部」のスケジュール作成方針に従って、スケジュール競合を回避する新しいスケジュールを作成して、これを「全体ＫＰＩ計算部」に渡す。「全体ＫＰＩ計算部」は、その新しいスケジュールをベースに全体ＫＰＩの最大化を更に新しいスケジュールを作成する。

もし、スケジュールに競合が発生してしまう場合は、そのスケジュールを、「不整合判定部」に戻す。「不整合判定部」と「全体ＫＰＩ計算部」は、処理を繰り返す内に、スケジュールを収束させるように働きあうものとする。

図１５−１、図１５−２、図１５−３、図１５−４は、スケジュール調停スケジュール調停サーバ１にて修正、作成された、初期保守スケジュールに対して競合を回避した路面保守、灯具保守、電力保守、交通のスケジュールの一例図である。つまり、図１５−１は、路面保守スケジュールの修正スケジュール例であり、図１５−２は、灯具保守スケジュールの修正スケジュール例であり、図１５−３は、電力保守スケジュールの修正スケジュール例であり、図１５−２は、交通スケジュールの修正スケジュール例である。

図２７−１は、スケジュール調停スケジュール調停サーバ１に対して路面保守計画サーバ２−Ｔからポイントが送付された場合の路面保守計画サーバ２−Ｔの修正スケジュール例である。

図２７−２は、スケジュール調停スケジュール調停サーバ１に対して路面保守計画サーバ２−Ｔからポイントが送付された場合の灯具保守計画サーバ２−Ｌの修正スケジュール例である。

図１５−１のスケジュール情報がスケジュール調停スケジュール調停サーバ１から路面保守計画サーバ２−Ｔに送付されたが、路面保守計画サーバ２−Ｔが拒否する場合である。路面保守計画サーバ２−Ｔは、スケジュール調停スケジュール調停サーバ１に再提案のスケジュール情報とポイントを送付する。他の自律個サーバ（ここでは、灯具保守計画サーバ２−Ｌ）よりも路面保守計画サーバ２−Ｔから送付されたポイントが一番多い場合は、路面保守計画サーバ２−Ｔから送付された再提案のスケジュール情報が許可されて、他の自律個サーバ（ここでは、灯具保守計画サーバ２−Ｌ）は更にスケジュール情報が修正される。すなわち、路面保守計画サーバ２−Ｔの再修正スケジュール情報は図２７−１となり、灯具保守計画サーバ２−Ｌの再修正スケジュール情報は図２７−２となる。ここで、灯具保守計画サーバ２−Ｌは、初期保守スケジュールと比較して、２４０分スケジュールが修正されているので、２４０ポイントが付与されることになる。

図１６は、図８の路面保守計画サーバ２−Ｔにおいて初期保守スケジュールのｓｕｇｇｅｓｔｉｏｎアサーションメッセージに対する、スケジュール調停サーバ１からの図１５−１のｏｆｆｅｒアサーションメッセージの内容を示す図である（１６−１）。また、ｏｆｆｅｒアサーションメッセージに対する応答の制限時間６０分も指定される（１６−２）。

このｏｆｆｅｒアサーションメッセージは、路面保守計画サーバ２−Ｔにおける、図６の通信処理部２−２の「アサーションメッセージ送信部」に転送されて、自律個サーバ群２のサーバの全てのサーバに最初の調停結果として配布される。全ての自律個サーバに配布することで、他の自律個への調停の内容を知ることができ、各自律個サーバ群２のサーバは自分だけが不利益な取り扱いを受けていないかを確認することができる。但し、前述した通り、必要に応じて秘密の通信としても良い。

なお、図６の通信処理部２−２の「アサーションメッセージ受信部」で受信したアサーションメッセージと、「アサーションメッセージ送信部」から送信されるアサーションメッセージは、オフライン処理部２−４の「オフライン処理部のアサーション情報記録部」に記録される。この記録は、オフライン処理部２−４の「過去履歴情報部」に格納される。また、そのアサーションメッセージはオフライン処理部２−４の「自己モデルチューニング部」にも転送される。「自己モデルチューニング部」では、モデルチューニングに必要な情報が取り出され、各自律個サーバ群２のサーバの特性モデルのチューニングに使用される。

前述のスケジュール調停サーバ１または自律個サーバ群２のサーバからのアサーションメッセージは、図６の自律個サーバの通信処理部２−２の「アサーションメッセージ受信部」で受信され、さらに、オンライン処理部２−３の「アサーションメッセージ確認部」に転送される。さらに「推実行可能性測部」に転送され、オペレーション処理部２−１の「スケジュール制約条件作成部」において作成されたスケジュール制約条件と比較する。

図１７−１と図１７−２は、スケジュール調停サーバ１から初期保守スケジュールとスケジュール制約条件と比較している図である。

すなわち、図５−１、図５−２と図１５−１、図１５−２を比較している。

図１７−１は、路面保守計画サーバ２−Ｔの比較結果であり、図１７−２は、灯具保守計画サーバ２−Ｌの比較結果である。

９月２１日（月）および２５日（金）の２７：００〜２７：３０までが、５０％制約の条件に抵触していることが分かる（図１７−１）。路面保守サーバ２−Ｔは、このスケジュールを拒絶することもできるが、この新しいスケジュールを受け入れられない訳ではない。但し、保守業務にかかるコストが高まることになるので、オンライン処理部２−３の「実行可能性推測部」は、同じスケジュールをこのコストに見合う優先権ポイントを付与して、「ｒｅ＿ｓｕｇｇｅｓｔｉｏｎ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ」を、スケジュール調停サーバ１に再提案することになる。ここで、路面保守計画サーバ２−Ｔは、期保守スケジュールと比較して、３０分スケジュールが修正されているので、３０ポイントが付与されることになる。

しかし、「＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙ」タイプのアサーションメッセージは、要求を相手側に認めさせるために自己の所有する優先権ポイントの提供を申し入れるが、相手側に優先ポイントを差し出させることを要求する方法として、マイナス値の優先権ポイントを使うことができる。つまり「○○ポイントを付与するので、この再提案を認めて欲しい」という使い方ではなく、「もし○○ポイントを付与してくれるなら、この内容の再提案を受け入れてもよい」という意味になる。このようなマイナスのポイントを使うと、当初から相手方の要求（相手側に提供して欲しい優先権ポイント）が明確になるため、調停が少ない回数で終了することが期待できるというメリットがある。

この場合、自律個サーバ群２のサーバのオンライン処理部２−３の「実行可能性推測部」は、最初の優先権ポイントとして、時間（分）を５０％で乗算したポイントの要求を試みる。具体的には、９月２１日（月）と２５日（金）のそれぞれに、３０分ｘ５０％＝１５ポイントである。

もちろん、「代替案作成部」または「個別ＫＰＩ計算部」において、９月２１日（月）と２５日（金）のスケジュールを３０分短くして、優先権ポイントを要求しないという選択もとり得るし、あるいは、スケジュール調停サーバ１が提示してきたスケジュールそのものを拒否することも可能である。

この場合、自律個サーバ群２のサーバのサーバは当初の要求通りの初期保守スケジュールを、スケジュール調停サーバ１から認可される可能性もあるが、逆に調停が不調となり、他の自律個サーバ群２のサーバにその時間を押さえられて、まったく別の時間帯に動かされるリスクも払わなければならない。これは自律個サーバ群２のサーバのポリシーを作成するオペレータのやり方次第となる。

図１８は、マイナスの優先権ポイント付きの再提案のアサーションメッセージ（ｒｅ＿ｓｕｇｇｅｓｔｉｏｎ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ）１８−１と、了承メッセージ（ａｃｃｐｅｔアサーションメッセージ）１８−２を併記したアサーションメッセージの内容の図である。

図１９は、オファを拒否するアサーションメッセージ（ｒｅｊｅｃｔアサーションメッセージ）１９−１の図である。これはスケジュール調停サーバ１からの提案を拒否し、当初の提案のまま維持することを要求する内容となる。

図２０は、自律個サーバから、前記図１９のｒｅｊｅｃｔアサーションメッセージ（または、図１８のｒｅ＿ｐｒｏｐｏｓａｌアサーションメッセージ）を受け取ったスケジュール調停サーバ１が、プラスの優先権ポイントをつけて、再度自律個サーバに同じスケジュールをオファするアサーションメッセージ（ｏｆｆｅｒ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ）２０−１を示す図である。

図１８、図１９のアサーションメッセージは、図６の自律個サーバのオンライン処理部２−３の「自律個アサーション情報作成部」で作成され、通信処理部２−２の「アサーションメッセージ送信部」から、原則として、スケジュール調停サーバ１と全ての自律個サーバに転送される。

なお、図６の通信処理部２−２の「アサーションメッセージ受信部」で受信されたアサーションメッセージ、および「アサーションメッセージ送信部」から送信されるアサーションメッセージは、オフライン処理部２−４の「アサーション情報記録部」、「自己モデルチューニング部」に転送され、「過去履歴情報部」でデータベース化され、「自己特性モデル部」で自己シミュレータのチューニングパラメータとして使用される。

オフライン処理部２−４の「過去履歴情報部」と「自己特性モデル部」と「参考アサーションメッセージ記録部」は、オンライン処理部２−３の「実行可能性推測部」から参照され、自律個アサーションメッセージを作成する際の参考情報として利用される。

図２１は、アサーションメッセージを送付する自律個サーバ群２のサーバの状態遷移を示す図である。

まず、自律個サーバ群２のサーバは、起動後に（１）スケジュール作成の状態２１−１に移行する。各サーバがｓｕｇｇｅｓｔｉｏｎアサーションメッセージを使って、自己の希望するスケジュールを協調場サーバとして振舞うスケジュール調停サーバ１に提出した後、（２）（優先権ポイント付与）修正スケジュール案受信待ちの状態２１−２になる。

その後、スケジュール調停サーバ１からのｏｆｆｅｒまたはｏｆｆｅｒ＿ｗｉｔｈ＿ｐｒｉｏｔｉｒｙアサーションメッセージを受信すると、（３）拒絶、（優先ポイント付与）再提案、受諾判断状態２１−３に移行する。

その後、ｒｅｊｅｃｔ、ｒｅ＿ｓｕｇｇｅｓｔｉｏｎまたはｒｅ＿ｓｕｇｇｅｓｔｉｏｎ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージを スケジュール調停サーバ１に転送することで、再び（２）（優先権ポイント付与）修正スケジュール案受信待ちの状態２１−２になる。一方、ａｃｃｅｐｔアサーションメッセージをスケジュール調停サーバ１に送付することで、そのスケジュールについては、その内容を確定し、状態を終了する。

なお、優先権ポイントの取り扱いについては、スケジュール調停サーバ１、自律個サーバ群２のサーバの各サーバのそれぞれのオフライン処理部１−４、または２−４の優先権ポイント記録部で記録されることになる。

このようにして、スケジュール調停サーバ１の調停のもと、自律個サーバとの交渉を続けることによって、協調場サーバ、自律個サーバの双方の利益を追求することが可能なスケジュールが完成することになる。

（第二の実施例）
本実施例では、自律個サーバ群２のサーバのいずれかが、協調場サーバとして振舞うスケジュール調停サーバ１が予定している形のスケジュールを提出しない場合について記載する。

例えば、灯具保守計画サーバ２−Ｌが、図５−２のようなスケジュールを提出せずに、図２２のような、保守区間と必要な時間のみをｓｕｇｇｅｓｔｉｏｎアサーションメッセージで送信する場合を考える。なお、この場合の個別ＫＰＩは、保守区間と必要な時間が達成されれば、どの時間に割り当てられたとしても「個別ＫＰＩが１００％達成された状態」と考えるものとする。すなわち、初期保守メッセージにおいて明確な意思表示をしないと、他の自律個サーバ群２のサーバとの間において不利益な取り扱いを受けることを甘受するという意志表明となる。

また、灯具保守サーバ２−Ｗを運用する保守会社は、毎週１日完全な定休日があり、また曜日によって保守業務ができない時間帯もあるが、それを自律個サーバ群２のサーバや他の自律個サーバには通知しないものとする。例えば、ここでは、それらの情報は、競合他社に対する営業上の秘密に相当すると考えることができるためである。

この灯具保守サーバ２−Ｗのｓｕｇｇｅｓｔｉｏｎアサーションメッセージは、図９の協調場サーバとして振舞うスケジュール調停サーバ１の通信処理部１−２の「アサーションメッセージ受信部」で受信され、オンライン処理部１−３の「アサーションメッセージ確認部」に転送されると、時間情報はあるが時刻情報が欠落している不完全なスケジュールとして確認され、「欠損情報推測部」に転送される。

「欠損情報推測部」は、オフライン処理部１−４の灯具保守計画サーバ２−Ｌ用の「過去履歴情報」にアクセスして、過去のスケジュール情報から、もっとも近似しているスケジュールを検索し、今回の不完全な初期スケジュールと対応づける。具体的には、過去においてＷ１〜Ｗ４までの区間の保守業務が１週間に一回ずつ実施され、かつ、それぞれの保守時間が今回の時間と近いものを検索することになる。

または、十分に近いと判定される情報が発見できない場合は、オフライン処理部１−４の灯具保守計画サーバ２−Ｌ用の「自律個特性モデル部」にアクセスして、過去において、ｒｅｊｅｃｔアサーションメッセージや、ｒｅ＿ｓｕｇｇｅｓｔｉｏｎアサーションメッセージが発行されやすい時間帯を抽出し、これらの時間帯を回避するような暫定的なスケジュールを作成する。

図２３は、ｒｅｊｅｃｔアサーションメッセージや、ｒｅ＿ｓｕｇｇｅｓｔｉｏｎアサーションメッセージが発行されやすい時間帯を示す図である。ここに記載された値は、全てのアサーションメッセージ数に対する、ｒｅｊｅｃｔアサーションメッセージや、ｒｅ＿ｓｕｇｇｅｓｔｉｏｎアサーションメッセージ数の比率を示している。この値の大きい時間帯へのｏｆｆｅｒアサーションメッセージの送付は、受け入れられにくいことになる。

このスケジュールは、暫定的に、灯具保守の自律個サーバから送付されたものとして、これ以後は実施例１記載の方法で、調停が実施される。

なお、上記の実施例は、高速道路の保守スケジュールに関する事象について記載しているが、これは、別のシステムでも援用可能である。

例えば、図2の路面保守計画サーバを保線保守サーバとし、灯具保守計画サーバを架線保守計画サーバと、交通計画サーバを運行計画サーバとして、図4のN1〜N1のインターチェンジを、駅として取り扱うことで、鉄道メンテナンスのスケジュール調停システムとして使うことも可能である。

ここに、保線保守とは、電車のレールの保守業務のことである。例えば電車のレールは列車の加重で沈下し続けるので、これを土や砂利で持ち上げる作業はその一つである。

架線保守とは．列車に電力を供給するために上部に張られる電線の保守業務のことである。例えば、列車のパンダグラフとの摩擦によって磨耗した電線を張り替える作業はその一つである。

電力保守とは、列車に電力を安定して提供するために電力機器の修理や交換を行うことであり、運行とは、列車運行に関する事項をいう。但し、本実施例においては、電力保守区間と運行区間は、電気が流れる区間と、列車を動かす区間として取り扱う。

スケジュール調停サーバ１、ネットワーク３、路面保守計画サーバ２−Ｔ、灯具保守計画サーバ２−Ｌ、電力保守計画サーバ２−Ｐ、交通管理サーバ２−Ｏ、ＣＰＵ１１−０１、メモリ１１ー０２、通信ＮＩＣ１１−０３、ハードディスクドライブ１１−０４、入出力コントローラ１１―０５、モニタコントローラ１１―０６、バス１１―０７、入出力コントローラ１１―０５は、入出力コントローラ１１―０５、オペレーション処理部２−１、通信処理部２−２、オンライン処理部２−３、オフライン処理部２−４、オペレーション処理部１−１、通信処理部１−２、オンライン処理部１−３、オフライン処理部１−４、ｏｆｆｅｒアサーションメッセージ１６−１、１６−２、ｒｅ＿ｓｕｇｇｅｓｔｉｏｎ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ１８−１、ａｃｃｐｅｔアサーションメッセージ１８−２、ｒｅｊｅｃｔアサーションメッセージ１９−１、ｏｆｆｅｒ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ２０−１、１）スケジュール作成の状態２１−１、（２）（優先権ポイント付与）修正スケジュール案受信待ちの状態２１−２、（３）拒絶、（優先ポイント付与）再提案、受諾判断状態２１−３

Claims (7)

1. 予め記憶された第１のスケジュール作成制約と、一定期間の第１のスケジュール情報とをスケジュール調停サーバに送付する第１のサーバと、予め記憶された第２のスケジュール作成制約と、一定期間の第２のスケジュール情報とを前記スケジュール調停サーバに送付する第２のサーバと、前記第１のサーバと前記第２のサーバのスケジュールを調停する制御部と記憶部を備えるスケジュール調停サーバとを含むスケジュール調停システムであって、
   前記スケジュール調停サーバの前記記憶部は、全体最適制約情報を記憶し、
   前記スケジュール調停サーバの前記制御部は、前記第１のサーバと前記第２のサーバから、前記第１のスケジュール作成制約、前記第１のスケジュール情報、前記第２のスケジュール作成制約、及び前記第２のスケジュール情報とを取得する取得部と、前記第１のスケジュール作成制約、前記第１のスケジュール情報、前記第２のスケジュール作成制約、及び前記第２のスケジュール情報と、前記記憶部に記憶された前記全体最適制約情報から、前記第１のスケジュール情報と前記第２のスケジュール情報との間の不整合を検出する不整合検出部と、不整合が検出された場合、前記第１のスケジュール情報と前記第２のスケジュール情報とを修正して第３のスケジュール情報と第４のスケジュール情報とを再作成するスケジュール再作成部と、修正度合いに応じて前記第１のサーバと前記第２のサーバに対して、第１のクレジットと第２のクレジット夫々を算出するクレジット算出部と、前記第３のスケジュール情報と前記第１のクレジットを第１のサーバに送付し、前記第４のスケジュール情報と前記第２のクレジットとを第２のサーバに送付する送信部とを備える
   ことを特徴とするスケジュール調停システム。
2. 請求項１に記載のスケジュール調停システムにおいて、
   前記第１のサーバは、前記第３のスケジュール情報に基づいて計画を実行し、
   前記第２のサーバは、前記第４のスケジュール情報に基づいて計画を実行する
   ことを特徴とするスケジュール調停システム。
3. 請求項２に記載のスケジュール調停システムにおいて、
   前記第１のサーバと前記第２のサーバは、更に、前記第３のスケジュール又は前記第４のスケジュールの承認又は拒否の入力を受付け、前記承認又は拒否の入力がされたことを前記スケジュール調停サーバの送付する送信部を更に備え、
   前記スケジュール調停サーバは、承認の入力を取得した場合は、前記第３のスケジュール情報及び前記第４のスケジュール情報とを前記第１のサーバ及び前記第２のサーバに送付し、
   前記スケジュール調停サーバは、前記第１のサーバ又は前記第２のサーバから拒否の入力を取得した場合は、前記全体最適制約情報、前記第３のスケジュール情報、又は前記第４のスケジュール情報のいずれか一つ以上の情報を修正する
   ことを特徴とするスケジュール調停システム。
4. 請求項３に記載のスケジュール調停システムにおいて、
   前記第１のサーバ、前記第２のサーバの一方又は両方からクレジットが送付された場合、
   最も多いクレジットを送付したサーバから提示されたスケジュール情報を優先し、他のサーバのスケジュール情報または全体最適制約情報を再修正する
   ことを特徴とするスケジュール調停システム。
5. 請求項１から４のいずれか一つに記載のスケジュール調停システムにおいて、
   前記スケジュール調停サーバの前記クレジット算出部は、
   前記第３のスケジュール情報又は前記第４のスケジュール情報の少なくとも一方のスケジュール情報が、前記第１のスケジュール作成制約又は前記第２のスケジュール作成制約に違反する修正をした場合、スケジュール作成制約を満たすスケジュール情報に対するクレジットよりも、高い還元率となるようにクレジットを算出する
   ことを特徴とするスケジュール調停システム。
6. 請求項１から５のいずれか一つに記載のスケジュール調停システムにおいて、
   前記スケジュール調停サーバの前記クレジット算出部は、
   修正度合いが高いサーバの前記クレジットが多くなるように算出する
   ことを特徴とするスケジュール調停システム。
7. 請求項１から６のいずれか一つに記載のスケジュール調整システムにおいて、
   前記スケジュール調停サーバの前記記憶部は、
   更に、前記第１のサーバ及び前記第２のサーバにおける過去のスケジュール修正情報を記憶し、
   前記スケジュール調停サーバの前記クレジット算出部は、
   前記過去のスケジュール修正情報に基づいて、前記第１のスケジュール情報と前記第２のスケジュール情報とを修正して第３のスケジュール情報と第４のスケジュール情報とを再作成する
   ことを特徴するスケジュール調停システム。

Images