JP2018106397A - スケジュール調停システムおよびスケジュール調停方法 - Google Patents

Abstract

【課題】複数のシステム間で制約上の不整合が生じるような場合でもリソース配分を可能とする。【解決手段】スケジュール調停システム１０において、各サーバのスケジュールおよび作成制約情報と、スケジュール間の調停全体に関する制約たる全体最適制約情報とに基づき、各サーバのスケジュール間の不整合を検出した場合、各サーバの修正スケジュールを生成し、修正の度合いに応じ、各サーバにおけるスケジュールの優先権の主張強度に対応したクレジット値を算出し、修正スケジュールおよびクレジット値の情報を含むスケジュール調停の開始通知を、対応するサーバ各々に送信する演算装置１１−０１を備えたスケジュール調停サーバ１を含む構成とする。【選択図】図７

Description

本発明は、スケジュール調停システムおよびスケジュール調停方法に関する。

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

ここで、複数の生産拠点をコントロールするための技術として、そうした技術としては、例えば、事業の垂直統合／水平展開により経営管理が異なる生産拠点を含む複数の生産拠点に跨った生産を行う生産モデルにおいて、各生産拠点の生産リードタイムや調達部材のリードタイムに基づいて一定期間後のデリバリおよび在庫量を予測し、この予測したデリバリおよび在庫量に基づいて該複数の生産拠点の生産機種の優先順位および出荷計画を最適化する複数生産拠点予測フィードバック手段を有する生産コントロールシステム（特許文献１参照）などが提案されている。

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

しかしながら従来技術においては、複数の生産拠点における生産システムが夫々持つ制約に不整合が生じることは考慮されていない。そのため、複数のシステム間で不整合が生じるようなリソースを配分することが困難である。

そこで本発明の目的は、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分を可能とする技術を提供することにある。

上記課題を解決する本発明のスケジュール調停システムは、複数の事象それぞれに関するスケジュールと当該スケジュールの作成制約情報を、前記事象それぞれを管理する各サーバより取得し、前記各サーバの前記スケジュールおよび前記作成制約情報と、スケジュール間の調停全体に関する制約たる全体最適制約情報とに基づき、前記各サーバのスケジュール間の不整合を検出する不整合判定処理と、前記不整合を検出した場合、前記各サーバのスケジュールを修正して、修正スケジュールを生成するスケジュール再作成処理と、前記修正の度合いに応じ、前記各サーバにおけるスケジュールの優先権の主張強度に対応したクレジット値を算出するクレジット算出処理と、前記修正スケジュールおよび前記クレジット値の情報を含むスケジュール調停の開始通知を、対応するサーバ各々に送信する送信処理と、を実行する演算装置を備えたスケジュール調停サーバを含むことを特徴とする。

また、本発明のスケジュール調停方法は、情報処理システムが、複数の事象それぞれに関するスケジュールと当該スケジュールの作成制約情報を、前記事象それぞれを管理する各サーバより取得し、前記各サーバの前記スケジュールおよび前記作成制約情報と、スケジュール間の調停全体に関する制約たる全体最適制約情報とに基づき、前記各サーバのスケジュール間の不整合を検出する不整合検出処理と、前記不整合を検出した場合、前記各サーバのスケジュールを修正して、修正スケジュールを生成するスケジュール再作成処理
と、前記修正の度合いに応じ、前記各サーバにおけるスケジュールの優先権の主張強度に対応したクレジット値を算出するクレジット算出処理と、前記修正スケジュールおよび前記クレジット値の情報を含むスケジュール調停の開始通知を、対応するサーバ各々に送信する送信処理と、を実行することを特徴とする。

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

本実施形態における共生自律分散システムの概念例を示す図である。 本実施形態におけるスケジュール調停システムの構成例を示す図である。 本実施形態におけるバルブ調整システムの構成例を示す図である。 本実施形態の会議スケジューリングシステムの構成例を示す図である。 本実施形態におけるスケジュール調停システムの全体シーケンス例を示す図である。 本実施形態における自律個サーバ群の表示画面例を示す図である。 本実施形態におけるスケジュール調停サーバ、自律個サーバ群のサーバのハードウェアの構成例を示す図である。 本実施形態におけるスケジュールの調停の対象例を示す図である。 本実施形態における路面の初期保守スケジュール例を示す図である。 本実施形態における灯具の初期保守スケジュール例を示す図である。 本実施形態における交通の初期保守スケジュール例を示す図である。 本実施形態における電力の初期保守スケジュール例を示す図である。 本実施形態における自律個サーバ群のサーバのソフトウェア構成例を示す図である。 本実施形態におけるスケジュールの制約条件例を示す図である。 本実施形態における初期保守スケジュールのメッセージの内容例を示す図である。 本実施形態におけるスケジュール調停サーバのソフトウェア構成例を示す図である。 本実施形態における路面保守計画サーバと灯具保守計画サーバとの間の初期保守スケジュールにおける競合発生例を示す図である。 本実施形態における路面保守計画サーバと灯具保守計画サーバとの間の初期保守スケジュールにおける競合発生例を示す図である。 本実施形態における電力保守計画サーバと交通管理サーバとの間の初期保守スケジュールにおける競合発生例を示す図である。 本実施形態における電力保守計画サーバと交通管理サーバとの間の初期保守スケジュールにおける競合発生例を示す図である。 本実施形態におけるスケジュール作成方針ビューアのＧＵＩ例を示す図である。 本実施形態における調停のパターンを記載した例である。 本実施形態における調停時間入力部のＧＵＩ例を示す図である。 本実施形態における優先権ポイント発行ポリシーを設定する画面例を示す図である。 本実施形態における初期保守スケジュールに対する路面保守スケジュールの修正スケジュール例を示す図である。 本実施形態における初期保守スケジュールに対する灯具保守スケジュールの修正スケジュール例を示す図である。 本実施形態における初期保守スケジュールに対する電力保守スケジュールの修正スケジュール例を示す図である。 本実施形態における初期保守スケジュールに対する交通スケジュールの修正スケジュール例を示す図である。 本実施形態におけるスケジュール調停サーバに対して路面保守計画サーバから優先権ポイントが送付された場合の路面保守計画サーバの修正スケジュール例を示す図である。 本実施形態におけるスケジュール調停サーバに対して路面保守計画サーバから優先権ポイントが送付された場合の灯具保守計画サーバの修正スケジュール例を示す図である。 本実施形態におけるｏｆｆｅｒアサーションメッセージの内容例を示す図である。 本実施形態における初期保守スケジュールとスケジュール制約条件との比較例（路面保守計画サーバにおける比較）を示す図である。 本実施形態における初期保守スケジュールとスケジュール制約条件との比較例（灯具保守計画サーバにおける比較）を示す図である。 本実施形態における再提案のアサーションメッセージ例を示す図である。 本実施形態におけるオファを拒否するアサーションメッセージ例を示す図である。 本実施形態におけるスケジュールをオファするアサーションメッセージ例を示す図である。 本実施形態の自律個サーバ群のサーバの状態遷移例を示す図である。 本実施形態における保守区間と必要な時間のみを含むアサーションメッセージ例を示す図である。 本実施形態におけるｒｅｊｅｃｔアサーションメッセージが発行されやすい時間帯の例を示す図である。 本実施形態におけるエージェントプログラムを使った調停のフロー例を示す図である。 本実施形態における協調場エージェントの調停アルゴリズム例を示す図である。 本実施形態における自律個エージェントで用いているファジィ推論のメンバーシップ関数を示す図である 本実施形態における自律個エージェントのファジィルール例を示す図である。 本実施形態における協調場エージェントと自律個エージェントを使ったシミュレーション結果を示す図である。 本実施形態における優先ポイントを使わなかった場合と使った場合の、全体ＫＰＩの評価を示す図である。 本実施形態における観光客の観光スケジュールとバス会社のバスダイヤを調停するシステムの構成例を示す図である。 本実施形態におけるＧＡのアルゴリズムを示す図である。 本実施形態におけるＧＡで用いる染色体の構造例を示す図である。 本実施形態における翌日のバスの運行スケジュールとスマホユーザの観光スケジュールの両方の調停の様子を示すフロー図である。 本実施形態における調停前後のスケジュールを示す図である。 本実施形態における調停前後のスケジュールを示す図である。 本実施形態におけるスマホを有するタクシーの利用希望者と、タクシーの運行を調停するシステムの構成例を示す図である。 本実施形態におけるスマホユーザが所有するスマホのＧＵＩ画面例を示す図である。 本実施形態におけるスマホユーザとタクシー会社で配車条件のマッチングを行うフローを示す図である。

＜共生自律分散システムの概要説明＞

図１は、本実施形態における共生自律分散システムの概念を示す図である。国内における社会インフラ事業の新規投資は飽和状態にあり、海外インフラについても競争が激化し参入が難しい状況にある。また、企業間の合併、併合または同種類の業務提携も行われてはいるが、設備やサービスの共用による経費削減の効果しか期待できない状況にある。

そうした中、同種または異種の事業を協業させる場所（以下「場」という）を作り、その「場」において複数の現存システムを共生させることで、未知の新しいサービスやビジネスを創成する方法が模索されている。このような共生を実現するシステムを、共生自律分散（登録商標）システムといい、また、当該システムによって創成されるサービスを共生自律分散サービスという。

ここで、異種または同種の事業における、異種または同種の業務の実施主体を「自律個」、また、当該自律個サーバ群２のサーバに共生の「場」を提供する実施主体を「協調場」、と称する（図１）。
−−−実施例１−−−
＜共生自律分散システムの適用例＞

図２は、本実施形態におけるスケジュール調停システム１０の構成を示す図である。本実施形態のスケジュール調停システム１０は、スケジュール調停サーバ１を少なくとも含んで構成されている。このスケジュール調停サーバ１は、上述の「協調場」に対応したサーバである。

一方、本実施形態における上述の「自律個」に対応する存在は、例えば、高速道路における各種保守業務を担うサーバ、を想定出来る。図２で例示する構成のうち、路面保守計画サーバ２−Ｔ、灯具保守計画サーバ２−Ｌ、電力保守計画サーバ２−Ｐ、および、交通管理サーバ２−Ｏ、が自律個に対応したサーバとなる。以後、これらサーバらをまとめて自律個サーバ群２と称する。

なお、上述の自律個サーバ群２および協調場のスケジュール調停サーバ１のそれぞれに対応した具体的な構成例については後述する（図１０、図１３）。

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

一方、スケジュール調停サーバ１も、協調場の目的を達成する為のシステム構成要素であり、これを協調場システムという。協調場には、協調場システムを運用するＫＰＩがあり、これを「全体ＫＰＩ」という。協調場システムは、この全体ＫＰＩを達成あるいは最大化する為に存在する。こうした協調場システムを具体化するスケジュール調停サーバ１を、協調場サーバという。

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

上述の協調場サーバたるスケジュール調停サーバ１と自律個サーバ群２とは、所定の調停プロトコルに基づくアサーションメッセージの交換を行う。以後、このアサーションメッセージの交換のことを「調停」という。

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

図３は、本実施形態におけるバルブ調整システムの構成を示す図である。また、本実施例における共生自律分散システムは、例えば、水道事業者が運用するバルブ調整システムにも適用できる。

図３で例示するバルブ調整システムが含むバルブ調整サーバ２５１は、「協調場」に対応したサーバ、すなわち上述の協調場サーバである。一方、ネットワーク２５６を介してバルブ調整サーバ２５１と接続された、地域Ａ水運用サーバ２５２、地域Ｂ水運用サーバ２５３、地域Ｃ水運用サーバ２５４、および、地域Ｄ水運用サーバ２５５は、それぞれ「自律個」に対応し、自律個サーバ群２を構成する。

このように、本実施例における共生自律分散システムがバルブ調整システムに適用された場合、バルブ調整サーバ２５１は、当該システムにおけるトータル電力コストを削減するため、地域Ａ〜地域Ｄの各水運用サーバ２５２〜２５５の運用スケジュールを調整する。また、該当各地域の水運用サーバは、バルブ調整サーバ２５１によって調整されたスケジュールに従い、配水系統等のバルブを制御することになる。

図４は、本実施形態における会議スケジューリングシステムの構成を示す図である。また、本実施例における共生自律分散システムは、例えば、複数のユーザが出席予定の会議に関して、各ユーザの都合を踏まえて会議の日時や場所を調整する、会議スケジューリングシステムにも適用できる。

図４で例示する会議スケジューリングシステムが含む会議スケジューリングサーバ２６１は、「協調場」に対応したサーバ、すなわち上述の協調場サーバである。一方、ネットワーク２６６を介して会議スケジューリングサーバ２６１と接続された、ユーザＡ端末２６２、ユーザＢ端末２６３、ユーザＣ端末２６４、および、ユーザＤ端末２６５、は、それぞれ「自律個」に対応し、自律個サーバ群２を構成する。

このように、本実施例における共生自律分散システムが会議スケジューリングシステムに適用された場合、会議スケジューリングサーバ２６１は、会議出席者の予定を調整するために、各ユーザの端末から当該ユーザのスケジュール情報を取得し、会議の日時と場所を調整し、各ユーザの端末に該当日時と当該場所の情報を送付することになる。

＜共生自律分散システムをスケジュール調停システムに適用した例＞

共生自律分散システムの適用対象として上述のような様々な例が考えられるが、本実施
例では、図２で既に示したスケジュール調停システム１０を想定するものとする。図５は、本実施形態におけるスケジュール調停システム１０での全体シーケンス例を示す図であり、具体的には、スケジュール調停サーバ１が、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌのスケジュール調停を行う場合の全体シーケンスとなる。

当該シーケンスにおいて、まず路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌは、予め記憶しているスケジュールの作成制約（以下、スケジュール作成制約）と、所定期間のスケジュール（例：計画Ａ、計画Ｂ）とを、スケジュール調停サーバ１に送信する（Ｓｔｅｐ２４０１、Ｓｔｅｐ２４０２）。

一方、スケジュール調停サーバ１は、所定の担当者等からの入力を受け付けるインターフェイスたるスケジュール作成方針入力部１３１（図１３）において、全ての自律個のスケジュールの実行期間を○月○日から○月△日に至る期間内とする、などといった、システム全体のスケジュール方針に関する情報であるスケジュール方針情報（全体最適制約情報）を取得する。

また、スケジュール調停サーバ１は、不整合判定部１３２（図１３）において、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌから取得したスケジュールおよびその作成制約と、上述のスケジュール方針情報とに基づいて、スケジュール（計画Ａ、計画Ｂ）間の不整合を検出する（Ｓｔｅｐ２４０３）。

上述のスケジュール間の不整合検出は、例えば以下の（式１）を用い、全体ＫＰＩを計算することで行う。

−−−−式１

ここにｎは、初期スケジュールとして提出するスケジュールの数（上述の例の場合、計画Ａ，計画Ｂの２つのスケジュールであるから、ｎは「２」）、Ａ_Ｋは、ｋ番目のスケジュールにおける保守エリア（高速道路のうち保守対象の区間）、Ｔ_Ｋは、ｋ番目のスケジュールにおける時間帯（保守作業を行う時間帯）を示す。

上述のＡ_Ｋの一例としては、あるインターチェンジから別のインターチェンジまでの高速道路の区間を想定出来る。また、Ｔ_Ｋの一例としては、午前１時から午前３時までの２時間、などと想定出来る。なお、Ａ_Ｋの単位としては、インターチェンジ間の区間数としても良いし、Ｔ_Ｋの単位としては、その時間帯の「分」を使っても良い。

また、Ａ’_Ｋ、Ｔ’_Ｋは、それぞれ初期スケジュール後に変更されたスケジュール（修正スケジュール）と初期スケジュールとで重複する保守エリアおよび時間帯を示す。従って、初期スケジュールの内容が、全て調停後のスケジュール（修正スケジュール）と全く同じになっている場合、式１で算定するＫＰＩは「１００％」となる。

例えば、初期スケジュールにおける、Ａ_Ｋ×Ｔ_Ｋの集計値＝保守対象区間の数×各保守対象区間の作業時間＝８時間で、Ａ’_Ｋ×Ｔ’_Ｋの集計値＝初期スケジュールと修正スケジュールとの間で一致する保守対象区間の数×該当各区間の作業時間＝６．５時間であった場合、式１で求まるＫＰＩは、（６．５／８）×１００＝８１．２５％となる。なお、
このＫＰＩの定義は、スケジュール問題には好適な方法の一つであるが、この方法に限定する必要はない。

続いてスケジュール調停サーバ１は、記憶装置たるＨＤＤ１１−０４（図７参照）で予め保持する全体最適制約情報を読み出し、この全体最適制約情報に基づいて、スケジュール（計画Ａ、計画Ｂ）を修正して修正スケジュール（計画Ａ’、計画Ｂ’）を生成する（Ｓｔｅｐ２４０４）。

次にスケジュール調停サーバ１は、上述のＳｔｅｐ２４０４でのスケジュール修正度合いに応じてクレジットを算出する（Ｓｔｅｐ２４０５）。このクレジットの値については、当初スケジュールから修正があった時間（分）をそのまま数値として利用しても良い。例えば、スケジュール調停サーバ１は、各スケジュールのうち「計画Ａ」について生成した修正スケジュールにおいて、当初スケジュールから計３０分の修正が生じた場合、クレジットの値を「３０」と算出する。

続いてスケジュール調停サーバ１は、送信部である通信処理部１−２（図１３）が、修正スケジュール（計画Ａ’、計画Ｂ’）とクレジット値の各情報を、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌの夫々に送信する（Ｓｔｅｐ２４０６、２４０８）。

この場合、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌは、スケジュール調停サーバ１から受信した修正スケジュール（計画Ａ’、計画Ｂ’）を、ディスプレイ等の所定の表示装置にて表示させ、当該修正スケジュールに対する所定担当者等による承認または拒否の入力を受け付けると共に、これをスケジュール調停サーバ１に返信する（Ｓｔｅｐ２４０７、２４０９）。

他方、スケジュール調停サーバ１は、上述のＳｔｅｐ２４０６、２４０８で送信した修正スケジュールについて、自律個サーバたる全サーバ（この例では、路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌ）から承認が得られた場合、当該修正スケジュールとクレジットが決定された旨を、該当サーバに送信する（Ｓｔｅｐ２４１０）。

この場合の路面保守計画サーバ２−Ｔと灯具保守計画サーバ２−Ｌは、スケジュール調停サーバ１にて決定された修正スケジュールとクレジットの各情報を、ディスプレイ等の所定の表示装置に表示（図６：自律個サーバ群２の表示画面例）させ、修正スケジュールに応じた所定処理を実行する。
＜ハードウェア構成＞

図７は、スケジュール調停サーバ１、自律個サーバ群２のサーバ、のそれぞれのハードウェアの構成例を示す図である。図に示すように、スケジュール調停サーバ１や自律個サーバ群のサーバらは、一般的なコンピュータ装置と同様のハードウェア構成を備えている。

すなわち、演算装置であるＣＰＵ１１−０１、記憶装置であるメモリ１１−０２、通信ＮＩＣ１１−０３、記憶装置であるハードディスクドライブ（以下ＨＤＤ）１１−０４、入出力コントローラ１１―０５、およびモニタコントローラ１１―０６を備え、これらは、バス１１―０７等で接続されている。なお、入出力コントローラ１１―０５は、入力装置であるキーボード、マウスと接続し、入出力コントローラ１１―０５は、表示装置であるディスプレイと接続する。

こうした構成のスケジュール調停サーバ１や、自律個サーバ群２の各サーバは、ＣＰＵ１１−０１がメモリ１１−０２のプログラム１１−０２１を実行することで、必要な機能
を実装する。
＜スケジュール調停の具体例＞

図８は、本実施形態におけるスケジュール調停の具体例を示す図である。図中のＮ１〜Ｎ１０は、ある高速道路のインターチェンジを示している。また、これらインターチェンジの各間をつなぐ線は、高速道路を示している。こうした構成の高速道路の保守業務に関し、路面（Ｔｒａｃｋ）、灯具（Ｌｉｇｈｔ）、電力（Ｐｏｗｅｒ）、および、交通（Ｏｐｅｒａｔｉｏｎ）の各保守区間は、インターチェンジを終端としている。保守区間とは、保守業務を行う単位となる。

上述の保守業務のうち路面保守とは、高速道路の路面の保守業務を意味する。例えば、高速道路の路面は通行車両の加重で沈下し続けるため、これを持ち上げる作業は、路面保守業務の一つである。

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

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

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

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

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

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

スケジュール調停サーバ１においてスケジュール調整を行うに際しては、各自律個サーバがスケジュール調停サーバ１に対して最初に提案する保守スケジュール（以下、初期保守スケジュールという）から大きく逸脱しないスケジュール調整が行われることが望ましい。

初期保守スケジュールから大きく逸脱しないスケジュール調整を行う理由は、それぞれ
の保守業務を実施する会社（以下、保守会社という）において、それぞれの保守会社にとって個別ＫＰＩを最大化するもっとも都合の良いスケジュールを組むと考えられるためである。

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

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

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

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

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

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

こうした初期保守スケジュールの具体例としては、図９−１に、路面（Ｔｒａｃｋ）の初期保守スケジュールを、図９−２に、灯具（Ｌｉｇｈｔ）の初期保守スケジュールを示す。また同様に、図９−３に、交通（Ｏｐｅｒａｔｉｏｎ）の初期保守スケジュールを、図９−４に、電力（Ｐｏｗｅｒ）の初期保守スケジュールを示す。

一方、スケジュール調停を受ける自律個サーバ群２の各サーバについて、その構成を説明する。図１０は、自律個サーバ群２の各サーバにおいて、メモリ１１−２に記憶されているソフトウェア構成を示す図である。図中の矢印は、ソフトウェアモジュールが呼び出され、または、参照される関係を示し、プログラムのアルゴリズムとしても把握されるものとする。これらのプログラムは、図７のメモリ１１―０２に展開され、演算装置たるＣＰＵ１１−０１によって実行される。

図１０で例示する構成のうち通信処理部２―２、オンライン処理部２―３の各モジュールに必要な記憶情報は、メモリ１１―０２に格納されている。また、オフライン処理部２―４の各モジュールに必要な記憶情報は、メモリ１１―０２だけではなく、ＨＤＤ１１−０４にも記録されている。

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

なお、上述した初期保守スケジュールの作成は、作成制約を踏まえる必要がある。図１１に、路面保守（Ｔｒａｃｋ）スケジュールの作成制約（以下、スケジュール制約条件という）を示す。

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

上述のスケジュール制約条件は、オペレーション処理部２−１におけるスケジュール制約作成部２−１２において、所定アルゴリズムによって作成され、オンライン処理部２−３の実行可能性推測部２−３１に転送される。このスケジュール制約条件も、保守会社のオペレータ等が所定のツールを用いて作成するとしても良い。

こうして自律個サーバ群２の各サーバにおいて作成された初期保守スケジュールは、通信処理部２−２のアサーションメッセージ送信部２−２１により、スケジュール調停サーバ１に送信されることとなる。

アサーションメッセージ送信部２−２１から送信される初期保守スケジュールの具体例を図１２に示す。図１２は、自律個サーバ群２の各サーバのうち、路面保守計画サーバ２−Ｔにおいて作成され、スケジュール調停サーバ１に送信した初期保守スケジュールのメッセージ（ｓｕｇｇｅｓｔｉｏｎアサーションメッセージ）の内容を示す図である。

図１２で例示する初期保守スケジュールのアサーションメッセージにおいて、最初から４行目までは、保守業務時間帯と保守業務区間を示している。また、最初の１行目は、「２０１５年９月２１日の２５時から２７時までの時間帯」で区間「Ｔ１」の保守業務を初期保守スケジュールとして提案している旨の記述となる。

また、５行目は、火曜日と土曜日は業務ができない日として記載している。この日は、例えば、保守会社の定休日が該当する。このような日は、スケジュール調停サーバ１による調停を行ったところで、そもそも業務を行えない日であり、路面保守計画サーバ２−Ｔから必ず拒否されることになる。但し、初期保守スケジュールの記載は必須であるが、このような定休日情報の記載は必須ではない。

図１２と同様の初期保守スケジュールの作成、送信の処理は、路面保守計画サーバ２−Ｔ２−Ｗ、電力保守計画サーバ２−Ｐ、交通計画サーバ２−Ｏでも同様に実行する。

ここで、スケジュール調停サーバ１におけるソフトウェア構成の例について説明する。図１３は、スケジュール調停サーバ１のメモリ１１−２に展開されているソフトウェア構成を示す図である。図中の矢印は、ソフトウェアモジュールが呼び出される、または、参照される関係を示し、プログラムのアルゴリズムとして把握されるものとする。

これらのプログラムは、図７のメモリ１１―０２に展開され、演算装置たるＣＰＵ１１−０１によって実行され、必要な機能を実装するものとなる。また、通信処理部２―２、オンライン処理部２―３の各モジュールに必要な記憶情報は、メモリ１１―０２に格納され、オフライン処理部２―４の各モジュールに必要な記憶情報は、メモリ１１―０２だけではなくＨＤＤ１１−０４にも記録される。

こうした構成のスケジュール調停サーバ１は、上述の自律個サーバ群２の各サーバにおいて作成された初期保守スケジュールのアサーションメッセージ（ｓｕｇｇｅｓｔｉｏｎアサーションメッセージ）を、ネットワーク３を介して、通信処理部１−２で受信する。同様に、この初期保守スケジュールのアサーションメッセージは、自律個サーバ群２における他のサーバの通信処理部２−２のアサーションメッセージ受信部２−２２（図１０）で受信される。

さらに、このアサーションメッセージは、スケジュール調停サーバ１における、オンライン処理部１−３のアサーションメッセージ確認部１３３に転送され、フォーマット等の形式チェックを受け、フォーマットに瑕疵がある場合は所定アルゴリズムによって修正される。

アサーションメッセージ確認部１３３で形式チェックを受けたアサーションメッセージは、欠損情報推測部１３４に送付される。但し、本ケースのアサーションメッセージには欠損情報がないため、アサーションメッセージ確認部１３３にそのままのアサーションメッセージとして戻される。

アサーションメッセージ確認部１３３は、路面保守計画サーバ２−Ｔ、灯具保守計画サーバ２−Ｌ、電力保守計画サーバ２−Ｐ、および交通管理サーバ２−Ｏからの初期保守スケジュールのアサーションメッセージ（ｓｕｇｇｅｓｔｉｏｎアサーションメッセージ）が揃ったら、それらが含む初期保守スケジュールを不整合判定部１３２に転送する。

不整合判定部１３２は、各サーバから得たスケジュールの衝突（以下、競合という）が発生していないかをチェックする。

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

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

これらの初期保守スケジュールは、オンライン処理部１−３の全体ＫＰＩ計算部１３５に入力され、修正スケジュールの生成が行われる。この全体ＫＰＩ計算部１３５での修正スケジュールの生成に際しては、オペレーション処理部１−１のスケジュール作成方針部１３１から、スケジュール方針情報が付与され、当該スケジュール方針を制約としてスケジュール修正がなされる。

図１５に、上述のスケジュール作成方針のビューアにおけるＧＵＩ例を示す。スケジュ
ール調停サーバ１のオペレータは、スケジュール作成方針部１３１がディスプレイ等の所定の表示装置で図１５のように表示するＧＵＩにて、スケジュール作成方針を指定する。

続いて、スケジュール調停のパターンについて説明する。図１６は、協調場サーバとして振舞うスケジュール調停サーバ１と、自律個サーバ群２のサーバとして振舞う路面保守計画サーバ２−Ｔおよび灯具保守計画サーバ２−Ｌとを例として、スケジュール調停のパターンを説明したものである。

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

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

換言すると、こうした優先権を定量化したものが「優先権ポイント」である。これは、調停で取り扱う資源である「時間（分）」をベースとするものとする。例えば３０分の時間を調停の対象とする場合、その時間の価値は、原則として３０優先権ポイント程度を基準に考える。もちろん、この優先権ポイントの価値は、その時間を欲するスケジュール調停サーバ１または自律個サーバ群２のサーバによって流動的に決定されるので、この３０優先権ポイントはあくまで目安でよい。

上述の優先権は、修正スケジュールたる調停案を自律個サーバ群２のサーバに受け入れて貰いたいスケジュール調停サーバ１、あるいは初期保守スケジュールたる初期時の提案、または修正スケジュールに対して改変を要求する再提案をスケジュール調停サーバ１に受け入れて貰いたい自律個サーバ群２のサーバから、優先権ポイント（数値）を付与して提案されることになる。

競合解決に際しては、上述のように優先権ポイントの多い方の提案または再提案が採用され、その優先権ポイントは採用されなかった側に移動する。つまり、採用されなかった側は、別の機会にその優先権ポイントを使った優先権主張が可能となる訳である。例えば、自律個サーバ群２の所定サーバからスケジュール調停サーバ１に初期保守スケジュールを送付する際に、優先権ポイントを合わせて送付する（図５のＳｔｅｐ２４０１）こととなる。

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

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

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

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

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

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

図１７は、スケジュール調停サーバ１における、オペレーション処理部１−１の調停時間入力部１３６が表示するＧＵＩ例を示す図である。本実施形態では、上述の調停のおける競合の解決方法をスケジュール調停サーバ１のオペレータ等が指定可能となっている。
指定出来る解決方法のうち、「オークション方式」とは、所定の時間までに最も良い条件の優先権を提示したスケジュール調停サーバ１または自律個サーバ群２のサーバが希望する時間帯を確保できるものである。一方、「協調場裁定方式」とは、スケジュール調停サーバ１のルールで条件を指定できるものである。例えば、スケジュール調停サーバ１が優先権ポイントの上限を予め決めておき、その優先権ポイントに至ったら優先権を主張できる主体を決定できるものである。この条件は、編集ボタンを押下すると画面に出てくるエディタ等で編集することができる。

なお、図１７の例では、「オークション方式」と「協調場裁定方式」の２種類の解決方法を例示したが、これに限定されるものではない。

上述の競合の解決に用いられる優先権ポイントの発行ポリシーは以下のとおりである。図１８は、スケジュール調停サーバ１、自律個サーバ群２のサーバで有する、優先権ポイント発行ポリシーの設定画面例を示す図である。

これらの発行ポリシーは、自律個サーバ群２の各サーバにおける、オペレーション処理部２−１のクレジット発行方針入力部２−１３（図１０）、および、スケジュール調停サーバ１における、オペレーション処理部１−１のクレジット発行方針入力部１３７にて、それぞれのオペレータ等が入力する。

図中で示す「初期発行ポイント」欄では、優先権ポイントの最初の値を設定する。デフォルト値は、競合が起きている時間（分）の値であるが、オペレータが手動で入力することもできる。また、「最終発行ポイント」欄では、優先権ポイントの最大値を設定する。デフォルト値は、競合が起きている時間（分）の倍の値であるが、オペレータが手動で倍
数の値を入力することもできる。但し、スケジュール調停サーバ１、自律個サーバ群２のサーバともに、自分の所持している優先権ポイントの値を超えて付与することはできない。そのような場合は、付与はその上限値になる。

また、「オークション運用方針」欄の編集ボタンは、これを押下することで、オークションの分割回数、開始時または終了直前に高い優先権ポイントを付与するなどの各種のオークションの戦略を記述したスクリプトの読み込み動作を指示できる。

ここで競合の解決に関する説明に戻る。スケジュール調停サーバ１における、オンライン処理部１−３の不整合判定部１３２は、オペレーション処理部１−１のスケジュール作成方針入力部１３１が与えるスケジュール作成方針に従って、競合を解決する新しいスケジュール、すなわち修正スケジュールを作成し、これを全体ＫＰＩ計算部１３５に渡す。
一方、全体ＫＰＩ計算部１３５は、その修正スケジュールをベースに全体ＫＰＩの最大化を図る、更に新しい修正スケジュールを作成する。もし、全体ＫＰＩ計算部１３５は、作成した修正スケジュールの間で競合が発生してしまう場合、その修正スケジュールを不整合判定部１３２に戻す。

不整合判定部１３２と全体ＫＰＩ計算部１３５は、上述の処理を繰り返すことで、各スケジュールを収束させるように働きあうものとする。

図１９−１〜図１９−４に、スケジュール調停サーバ１にて修正、作成された修正スケジュールの具体例を示す。ここで示す修正スケジュールは、初期保守スケジュールの間の競合を解決した、路面保守、灯具保守、電力保守、交通の各修正スケジュールである。

また、図２０−１は、路面保守計画サーバ２−Ｔが、スケジュール調停サーバ１に対し、優先権ポイントを送付した場合の路面保守計画サーバ２−Ｔの修正スケジュール例である。同様に、図２０−２は、路面保守計画サーバ２−Ｔが、スケジュール調停サーバ１に対し、優先権ポイントを送付した場合の灯具保守計画サーバ２−Ｌの修正スケジュール例である。

これら図１９−１〜図１９−４、図２０−１、図２０−２の修正スケジュールが示すのは、例えば、スケジュール調停サーバ１から修正スケジュール（図１９−１）が路面保守計画サーバ２−Ｔに送信されたが、これを路面保守計画サーバ２−Ｔが拒否した状況である。この場合の路面保守計画サーバ２−Ｔは、スケジュール調停サーバ１に対し、再提案のスケジュール（路面保守計画サーバ２−Ｔのオペレータが修正スケジュールを再修正したもの）と優先権ポイントを送信する。

一方、スケジュール調停サーバ１は、自律個群２の他のいずれのサーバ（ここでは、灯具保守計画サーバ２−Ｌ）よりも、路面保守計画サーバ２−Ｔから送付された優先権ポイントが大きい場合、当該路面保守計画サーバ２−Ｔから送付された再提案のスケジュールを許可し、自律個群２の他のサーバ（ここでは、灯具保守計画サーバ２−Ｌ）については更にスケジュールを修正する。なお、路面保守計画サーバ２−Ｔの再修正スケジュールは、図２０−１に示すもので、灯具保守計画サーバ２−Ｌの再修正スケジュールは、図２０−２に示すものとなる。ここで、灯具保守計画サーバ２−Ｌに関して、初期保守スケジュール（図９−２）と、再修正スケジュール（図２０−２）とを比較すると、９／２１（月）で１時間分、９／２４（木）で２時間分、９／２５（金）で１時間分、計４時間、すなわち２４０分のスケジュール修正がなされているため、この灯具保守計画サーバ２−Ｌに対してスケジュール調停サーバ１から２４０優先権ポイントが付与されることになる。

また、上述のサーバのうち路面保守計画サーバ２−Ｔの初期保守スケジュールのｓｕｇ
ｇｅｓｔｉｏｎアサーションメッセージに対する、スケジュール調停サーバ１からのｏｆｆｅｒアサーションメッセージ（図１９−１の修正スケジュールに対応したもの）を図２１に示す。このｏｆｆｅｒアサーションメッセージの具体的内容、すなわちスケジュール修正の提案内容１６−１は、上から５行目〜８行目までに記載され、このｏｆｆｅｒアサーションメッセージに対する応答の制限時間指定１６−２は、９行目に「６０分」と記載されている。

このｏｆｆｅｒアサーションメッセージは、路面保守計画サーバ２−Ｔにおける、通信処理部２−２のアサーションメッセージ送信部２−２１（図１０）に転送されて、自律個サーバ群２に含まれる全サーバに最初の調停結果として配布される。

ｏｆｆｅｒアサーションメッセージを自律個サーバ群２の全てサーバに配布することで、自律個サーバ群２の各サーバは、他のサーバに関する調停内容を知ることができるため、自律個サーバ群２の各サーバは自分だけが不利益な取り扱いを受けていないかを確認することができる。但し、前述した通り、必要に応じて秘密の通信としても良い。

なお、上述したアサーションメッセージ受信部２−２２で受信したアサーションメッセージと、アサーションメッセージ送信部２−２１から送信するアサーションメッセージは、オフライン処理部２−４のアサーション情報記録部２−４１に記録される。この記録は、オフライン処理部２−４の過去履歴情報部２−４２に格納される。

また、そのアサーションメッセージは、オフライン処理部２−４の自己モデルチューニング部２−４３にも転送される。この自己モデルチューニング部２−４３では、後述するモデルチューニングに必要な情報が取り出され、自律個サーバ群２の各サーバの特性モデルのチューニングに使用される。

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

図２２−１と図２２−２に、初期保守スケジュールとスケジュール制約条件とを比較する例を示す。すなわち、路面および灯具の初期保守スケジュール（図９−１、図９−２）と、路面保守スケジュールおよび灯具保守スケジュールの各修正スケジュール（図１９−１、図１９−２）とを比較している。

このうち図２２−１は、路面保守計画サーバ２−Ｔのスケジュールに関する比較結果であり、図２２−２は、灯具保守計画サーバ２−Ｌのスケジュールに関する比較結果である。両比較結果によれば、９月２１日（月）および２５日（金）の２７：００〜２７：３０の時間帯において、５０％制約の条件に抵触していることが分かる。路面保守計画サーバ２−Ｔは、こうした抵触が生じている修正スケジュールを拒否することもできる。一方、この修正スケジュールを受け入れた場合、制約条件に抵触しつつスケジュールを実行するためのコスト（例：従業員の残業代や追加の移動費など）が高まることになる。

そこで、例えば、上述の修正スケジュールを容認するとした路面保守計画サーバ２−Ｔにおける、オンライン処理部２−３の実行可能性推測部２−３１は、その修正スケジュールに、上述のコストに見合う優先権ポイントを付与して、「ｒｅ＿ｓｕｇｇｅｓｔｉｏｎ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ」を生成し、スケジュール調停サ
ーバ１に再提案することになる。ここで、路面保守計画サーバ２−Ｔは、修正スケジュールが初期保守スケジュールから３０分修正されていることを踏まえ、３０優先権ポイントが付与されることになる。

「＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙ」タイプのアサーションメッセージは、要求を相手側に認めさせるために自己の所有する優先権ポイントの提供を申し入れるが、相手側に優先権ポイントを差し出させることを要求する方法として、マイナス値の優先権ポイントを使うことができる。

つまり「○○（数値）優先権ポイントを付与するので、この再提案を認めて欲しい」という使い方ではなく、「もし○○（数値）優先権ポイントを付与してくれるなら、この内容の再提案を受け入れてもよい」という意味になる。

このようなマイナスの優先権ポイントを使うと、当初から相手方の要求（相手側に提供して欲しい優先権ポイント）が明確になるため、調停が少ない回数で終了することが期待できるというメリットがある。

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

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

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

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

また、図２４に、スケジュール調停サーバ１からのオファ、すなわち修正スケジュールを拒否するアサーションメッセージ（ｒｅｊｅｃｔアサーションメッセージ）１９−１の例を示す。これはスケジュール調停サーバ１からの修正スケジュールを拒否し、当初の提案すなわち初期保守スケジュールのまま維持することを要求する内容となる。

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

図２３、図２４に例示したアサーションメッセージは、自律個サーバ群２のサーバにお
ける、オンライン処理部２−３のアサーション情報作成部２−３４（図１０）にて所定アルゴリズムにより作成され、通信処理部２−２のアサーションメッセージ送信部２−２１から、原則として、スケジュール調停サーバ１と全ての自律個サーバに転送される。

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

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

上述してきたように、スケジュール調停サーバ１との間で種々の処理を実行する、自律個サーバ群２のサーバにおける状態遷移について、図２６に示す。図２６は、アサーションメッセージを送付する自律個サーバ群２のサーバの状態遷移を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、上述で示した例では、高速道路の保守スケジュールに関する事象について記載しているが、これは、別の事象に関するシステムでも援用可能である。例えば、路面保守計画サーバ２−Ｔ（図２）を保線保守サーバとし、灯具保守計画サーバを架線保守計画サーバ、また、交通計画サーバを運行計画サーバとして、インターチェンジＮ１〜Ｎ１（図８）を鉄道駅として取り扱うことで、鉄道メンテナンスのスケジュール調停システムとする
ことも可能である。

上述の保線保守とは、鉄道レールの保守業務のことである。例えば、レールは走行する列車の加重で沈下し続けるため、これを土や砂利で持ち上げる作業がその具体例である。また、架線保守とは、列車に電力を供給するために上部に張られる電線の保守業務のことである。例えば、列車のパンダグラフとの摩擦によって磨耗した電線を張り替える作業はその一つである。また、電力保守とは、列車に電力を安定して提供するために電力機器の修理や交換を行う保守業務である。また、運行とは、列車運行に関する事項をいう。但し、本実施例においては、電力保守区間と運行区間は、電気が流れる区間と、列車を動かす区間として取り扱う。
−−−実施例３−−−

本実施例では、「協調場」として機能するスケジュール調停サーバ１と、「自律個」として機能する、路面保守計画サーバ２−Ｔ、灯具保守計画サーバ２−Ｌ、電力保守計画サーバ２−Ｐ、および交通管理サーバ２−Ｏ（これらをまとめて自律個サーバ群２という）を、人間の代りとなるエージェントプログラムを使って自律的に動作させる実施例を示す。

図２９は、このエージェントプログラムを使った調停のフローを示す図である。以後、「協調場」用のエージェントを協調場エージェント、「自律個」用のエージェントを、自律個エージェントと称呼する。

上述の協調場エージェントが、調停開始のメッセージを自律個エージェントに通知する（Ｓｔｅｐ２９０１）と、調停に参加したい自律個エージェントが参加を要求するメッセージを協調場エージェントに返信する（Ｓｔｅｐ２９０２）。

協調場エージェントは、上述の参加要求のメッセージを受信し、その参加を受諾する（Ｓｔｅｐ２９０３）。

なお、この参加要求は、上述の調停開始の通知がなされた後、調停終了通知（Ｓｔｅｐ２９１３）が行われるまで、どのタイミングでも行うことができるものとする。

上述の参加を要求した自律個エージェントは、自己の希望する初期保守スケジュール（或いは、初期保守スケジュールに対する修正スケジュールを改変したスケジュール）を作成し、協調場エージェントに提案（初期保守スケジュールの提案）ないし再提案（修正スケジュールを改変したスケジュールの提案）として送付する（Ｓｔｅｐ２９０４）。

一方、協調場エージェントは、一定時間を待って、自律個エージェントから、提案または再提案が送付されてこないと、調停終了通知（Ｓｔｅｐ２９１３）を行うが、それ以外の場合は、その提案または再提案に従った調停を実施し（Ｓｔｅｐ２９０６）、調停結果に応じた修正スケジュール（以後、調停スケジュール）を自律個エージェントに送付する（Ｓｔｅｐ２９０７）。

自律個エージェントは、上述の調停スケジュールを受信し、その内容を所定ルールに沿って確認後、調停から離脱することができる（Ｓｔｅｐ２９０８、Ｓｔｅｐ２９０９）。但し、離脱後であっても、調停終了通知（Ｓｔｅｐ２９１３）が行われるまでは、再度参加することができるようにしてもよい（Ｓｔｅｐ２９０２）。

自律個エージェントは、調停スケジュールを所定アルゴリズムにより検討し（Ｓｔｅｐ２９１０）、新しいスケジュールを作成して再提案を行うか決定する（Ｓｔｅｐ２９１１
）。

全ての自律個エージェントから再提案が行われなくなった段階で、調停は終了する（Ｓｔｅｐ２９１４）。

こうした、Ｓｔｅｐ２９０１の調停開始からＳｔｅｐ２９１４の調停終了に至る一連の調停を「ステージ」という。協調場エージェントおよび自律個エージェントは、このステージの終了後、ステージの調停内容の解析を行うことが出来る（Ｓｔｅｐ２９１５，Ｓｔｅｐ２９１６）。

例えば、協調場エージェントは、自律個エージェントが調停において安易に譲歩した、あるいはなかなか譲歩しなかったスケジュール（時間、エリア）を解析し、当該解析で特定した時間、エリアを集約することで、図１１に示したようなスケジュールの制約条件の推定を行うことができる。

協調場エージェントは、上述の推定の結果を用いることで、次のステージにおける調停開始通知（Ｓｔｅｐ２９０１）の時点で、推定した制約条件を回避するような調停スケジュールの提案（Ｓｔｅｐ２９０７）を行うとしても好適である。

自律個エージェントも同様に、協調場エージェントまたは他の自律個エージェントの振舞いから、他の自律個エージェントのスケジュールの制約条件の推定を行うことができる。自律個エージェントは、この推定の結果を用いることで、次のステージにおける参加要求（Ｓｔｅｐ２９０２）の時点で、推定した制約条件を回避するようなスケジュール提案（Ｓｔｅｐ２９０４）を行ってもよい。

このように、ステージの開始時点において、調停の最終段階に近い提案を行うことで、少ない回数の調停が実施される可能性が高くなる。

図３０は、協調場エージェントの調停アルゴリズムの一例を示す図である。協調場エージェントは、自律個エージェントからスケジュールを取得すると（Ｓｔｅｐ１）、これらの全てを時間−空間上の二次元上の長方形３０１として展開する（Ｓｔｅｐ２）。

図３０の例では、２つのスケジュールＡ，Ｂに関するそれぞれの長方形３０１を表示しているが、実際には全てのスケジュールが長方形として座標上に展開されることになる。

次に協調場エージェントは、これらの長方形３０１の重なりで、自律個エージェントが提出してきた全てのスケジュールの競合の有無を調べる。本実施例の調停では、理解を容易にするため、インターチェンジの変更は行えず、また保守の作業時間も変更できないものとし、唯一、保守作業の開始時刻、終了時刻のみを変更できるものとしている。

図３０で例示したケースでは、インターチェンジＳ２からインターチェンジＳ５の範囲において保守作業が競合する為、このスケジュールＡ、Ｂのままでは、いずれも保守作業が行えないことになる。しかし、０２：３０〜０３：００の時間が重複しないようにスケジュールし直せば、スケジュールＡ、Ｂは共に保守作業が可能となる。

そこで協調場エージェントの調停アルゴリズムは、この重複を回避するためのスケジュールの計算を行う。このアルゴリズムは、作業時間の少ないスケジュールの方を大きく動かすものである。具体的には、保守作業時間を仮想的な質量（Ｖｉｒｔｕａｌ Ｗｅｉｇｈｔ（ＶＷ））と見なして、その重心点３０２を算出し（Ｓｔｅｐ２）、その重心点３０２を境として、スケジュールの重複のない、新しいスケジュールを作る（Ｓｔｅｐ３）。

図３０で例示したケースでは、スケジュールＡの保守作業時間は１２０分で、スケジュールＢの保守作業時間は６０分であるため、それぞれ１：２の比率で時間が移動されたスケジュールが提案されることになる。

次にこのアルゴリズムによる調停の妥当性を以下に説明する。例えば、１０分間のスケジュールと３時間のスケジュールがあった場合、これらを等価に扱うとすると、１０分のスケジュールの為に、３時間を要する保守作業ができなくなる場合がある。

本アルゴリズムにおいては、このような状況は、リソース（時間と空間）の有効活用の観点から望ましくないと考え、保守作業時間の長いものを優先的に取り扱うことしたものである。このような再スケジュールによって、当然別のスケジュールとの競合が、玉突き的に発生する場合がありえるが、その場合も上記の競合回避のアルゴリズムを実施し、競合するスケジュールが全てなくなるまで繰り返すことになる。

次に、自律個エージェントで用いているファジィ推論について説明する。図３１は、自律個エージェントで用いているファジィ推論のメンバーシップ関数を示す図である。ここで採用する推論方式としては、計算負荷が軽く実装が簡単なＭｉｎ−Ｍａｘ簡易重心法（特開平０５−１５０９９１等で開示）を想定している。また、図３２は、自律個エージェントのファジィルールの一例を示す表である。本ルールの概要を以下に述べる。

（１）調停回数が少ない初期時には、自律個エージェントは、自分の初期保守スケジュールに固執する。他の自律個の脱落を期待する為である。

（２）調停回数は中盤に至った状態で、協調場エージェントが提案してきたスケジュールが初期保守スケジュールと乖離している場合、自律個エージェントは、優先権ポイントを使ってでも自分の初期保守スケジュールに固執する姿勢を見せる。優先権ポイントの消費が少なくても、競合する初期保守スケジュールを主張する他の自律個に勝てる可能性が残っているからである。

（３）しかし、調停が十分な回数行われたにも関わらず、自分のスケジュールが受け入れなれない場合は、優先権ポイントの使用を止めて、修正スケジュールを受け入れる方向に方針を転換する。このステージでの優先権ポイントの消費を回避して、次のステージで生かす為である。このような自律個エージェントに人間の代替をさせることで、調停を高速に完了させることが可能となる。

図３３は、上述の協調場エージェントと自律個エージェントを使ったシミュレーション結果を示すものである。調停毎に変化する自律個のＫＰＩの変化を示している。なお、図中に記載のステージ２は、ステージ１の直後に行われたものである。

このようにステージ１では、灯具保守のＫＰＩの値が大きいが、ステージ２では入れ替わっている。このように、自律個エージェントが、優先権ポイントを効率的に使うことによって、そのステージにおいてより良いＫＰＩを確保しており、優先権ポイントが当初の予想通りの機能を発揮していることが分かる。

図３４は、優先ポイントを使わなかった場合と使った場合の、全体ＫＰＩの評価を示すものである。自律個は、個別ＫＰＩを最大化する為に、時間の長いスケジュールを重要度の高いものとして、初期保守スケジュールをできるだけ保持するように振る舞う。そのため、自律個の初期保守スケジュールと近い状態で調停を完了できた場合に、評価となるような以下の式２を用いて、評価値を算出する。

−−−−式２

この結果からも、優先権ポイントが有効に機能していることが明らかである。
−−−実施例４−−−

図３５は、スマートフォン（以下、スマホという）を有する観光客の観光スケジュールと、バス会社のバスダイヤを調停するシステムの構成を示す図である。

スマホユーザ１（のスマホ２―Ｕ１）、スマホユーザ２（のスマホ２−Ｕ２）、バス会社１のダイヤ計画サーバ２−Ｂ１、バス会社２のダイヤ計画サーバ２−Ｂ２は、それぞれ図２にて説明した「自律個」に対応するものであり、この場合のスケジュール調停サーバ１は、スマホユーザの観光スケジュールと、バス会社の運行スケジュールの両方を調停するシステムとなる。

本実施例では、スケジュール調停サーバ１に搭載される調停アルゴリズムの一例としてＧｅｎｅｔｉｃ Ａｌｇｏｒｉｓｍ（ＧＡ）を用いるものとする。図３６に、このＧＡで用いるアルゴリズムを示す。ＧＡについては、例えば公開公報１９４４−１６１９８０にて詳細が開示済みである。

図３７に、上述のＧＡで用いる染色体の構造を示す。この構造は、バスの運行ルート３６０１とその出発時刻３６０２を含んでいる。例えば、この運行ルート３６０１のうち”Ａ→Ｂ”は、出発地Ａから到着地Ｂを表し、”０９：００”は、当該バスが午前９時に出発することを示している。なお、”Ａ→Ｂ”の移動時間は固定とする。また、”０９：００”は、実際のＧＡのコードとして展開される場合は、”００：００”からの経過時間の分の数（二値化）として表現される。例えば、”００：００”から”０９：００”までの時間は、５４０分であるので、これを二値化すると”０１００００１１１００”という染色体列として表現され得る。

図３７の例では、”０９：００”、”１１：３４”、”１０：２３”、”１２：３４”という時間は、”０１００００１１１０００１０１０１１０１１００１００１１０１１１１０１０１１１１００１０”という二値化された数値列（ＧＡコード）として取り扱うことが可能となる。

ここで、図３６に示した「評価」のプロセスで算出する評価値の求め方について説明する。ここでは話を単純にする為に以下のような条件とする。

（１）スマホユーザ１は、出発地Ａから観光地Ｂに行き、再び出発地Ａに戻ってくる。

（２）スマホユーザ２は、出発地Ａから観光地Ｃに行き、再び出発地Ａに戻ってくる。

（３）バス会社１は、Ａ−Ｂ区間の運行を行い、保有しているバスは１台のみとする。

（４）バス会社２は、Ｂ−Ｃ区間の運行を行い、保有しているバスは１台のみとする。

上記の条件が満されない場合、評価値はゼロとなり、その染色体を有する固体は直ちに淘汰されるものとする。
なお、

（１）スマホユーザには、本来の観光地に加えて、別の観光地を提案することもできる。

（２）バス会社は、バスのダイヤの時間を変更することができる。
ものとする。

図３８は、スケジュール調停サーバ１、スマホユーザ１、２、およびバス会社１、２による、翌日のバスの運行スケジュールとスマホユーザの観光スケジュールの両方の調停の様子を示すフローである。

この場合、バス会社１、２のダイヤ計画サーバ２−Ｂ１、２−Ｂ２は、翌日に運行するバスの本数、および希望するスケジュールを、協調場サーバ１に送信する（Ｓｔｅｐ３８０１）。またスマホユーザ１、２のスマホ２―Ｕ１、２−Ｕ２は、翌日に観光を希望する場所、および時間を、協調場サーバ１に送信する（Ｓｔｅｐ３８０２）。

一方、スケジュール調停サーバ１は、ＧＡコード、個体数（スマホユーザおよびバス会社の数）、評価関数を設定する（Ｓｔｅｐ３８０３）。初回は、ＧＡコードは乱数を使って設定しても良い。

その後、スケジュール調停サーバ１は、ＧＡの計算を行い（Ｓｔｅｐ３８０５）、所定の回数、または所定の評価値の平均となったら計算を打ち切り（Ｓｔｅｐ３８０６）、ＧＡによって導かれた計算結果を、バススケジュールおよび観光スケジュールに変換して、スマホユーザ１、２のスマホ２―Ｕ１、２−Ｕ２と、バス会社１、２のダイヤ計画サーバ２−Ｂ１、２−Ｂ２に送信する（Ｓｔｅｐ３８０７）。

スマホユーザ１、２、バス会社１、２は、スマホ２―Ｕ１、２−Ｕ２、ダイヤ計画サーバ２−Ｂ１、２−Ｂ２で受信し閲覧したスケジュールから、調停から離脱するか否か判断する。スマホ２―Ｕ１、２−Ｕ２、ダイヤ計画サーバ２−Ｂ１、２−Ｂ２は、こうした判断の結果を、所定の入力装置で受け付ける（Ｓｔｅｐ３８０８、Ｓｔｅｐ３８０９）。

上述の判断の結果が離脱を示すものである場合（Ｓｔｅｐ３８０８：Ｙ、Ｓｔｅｐ３８０９：Ｙ）、該当するスマホユーザのスマホ、またはバス会社のダイヤ計画サーバは、その旨をスケジュール調停サーバ１に通知し（Ｓｔｅｐ３８１０）、処理を終了する。

一方、上述の判断の結果が離脱しないものである場合（Ｓｔｅｐ３８０８：Ｎｏ、Ｓｔｅｐ３８０９：Ｎｏ）、該当するスマホユーザまたはバス会社は、スケジュール調停サーバ１から受信したスケジュールを検討し、再提案を行うか否か判断する。この場合、スマホ２―Ｕ１、２−Ｕ２、ダイヤ計画サーバ２−Ｂ１、２−Ｂ２は、こうした判断の結果を、所定の入力装置で受け付ける（Ｓｔｅｐ３８１１、Ｓｔｅｐ３８１２）。

上述の判断の結果が再提案を示すものである場合（Ｓｔｅｐ３８１３：Ｙ、Ｓｔｅｐ３８１４：Ｙ）、該当するスマホユーザのスマホ、またはバス会社のダイヤ計画サーバは、その旨をスケジュール調停サーバ１に通知する。なお、再提案は前回と同一の内容としても良いものとする。

スケジュール調停サーバ１は、上述の通知に応じて再提案の有無を判定し（Ｓｔｅｐ３８０４）、提案があった場合（Ｓｔｅｐ３８０４：Ｙ）、ＧＡの再計算を実行する（Ｓｔ
ｅｐ３８０５）。

一方、スマホユーザ１、２、バス会社１、２のスマホおよびダイヤ計画サーバは、上述の再提案後、スケジュール調停サーバ１から調停終了通知（Ｓｔｅｐ３８１７）を待ち（Ｓｔｅｐ３８１５、Ｓｔｅｐ３８１６）、当該通知を確認して処理を終了する。

上述の調停の前後のスケジュール例について図３９−１、図３９−２に示す。このうち図３９−１は、調停前のスケジュールを示す図である。スマホユーザ１は、バス１（３９０３、３９０４）を使って、ＡからＢに行って、ＢからＡに戻り（３９０１）、スマホユーザ２は、バス１（３９０３、３９０４）、バス２（３９０５、３９０６）を使い、ＡからＢを経由してＣに行き、さらにＢに戻ることができるが、Ａに戻ることはできない。

一方、図３９−２は、調停後のスケジュールを示す図である。この場合、スマホユーザ１、２は、バス１とバス２を使い（３９０８、３９０９、３９１０、３９１１）、共にＡからＢに行き、さらにＣに行った後、Ｂに戻り、Ａに戻ることができる（３９０７）。
−−−実施例５−−−

次に、タクシーの利用希望者と、当該タクシーを運行するタクシー会社との間で、スケジュール調停サーバ１が調停を行う場合の例について説明する。図４０は、スマホを有するタクシーの利用希望者と、タクシーの運行を調停するシステムの構成を示す図である。この場合、協調場サーバたるスケジュール調停サーバ１は、ネットワーク３を介して、自律個たる、スマホ２−Ｕ１、２−Ｕ２、および、タクシー会社端末２−Ｔ１、２−Ｔ２らと接続されている。

図４１に、スマホユーザ１、２が所有する上述のスマホ２−Ｕ１、２−Ｕ２における、ＧＵＩ画面４１００の例を示す。このＧＵＩ画面４１００は、例えば、スマホ２−Ｕ１、２−Ｕ２が備える所定のアプリケーションによって提供され、タクシー利用に際しての配車条件の入力を受け付けるものとなる。

当該ＧＵＩ画面４１００における左側４１０１は、スマホユーザが希望するタクシーの配車条件４１０３を入力する画面である。このスマホユーザは、０９：４５に生田駅から鶴川駅の移動を希望し、乳幼児を連れており、また、女性ドライバーを希望しているが、相乗りでも良いという配車条件を提示している。また、地図４１０１１上にて、出発地、到着地の希望を入力することもできる。

これに対して、ＧＵＩ画面４１００の右側４１０２は、タクシー会社１または２のタクシー会社端末２−Ｔ１、２−Ｔ２から当該アプリケーションに配信された、当該タクシー会社で提供可能な配車条件４１０４が表示される画面である。スマホユーザは、このＧＵＩ画面４１００を閲覧して、タクシー会社側から提示された配車条件４１０４と、自身が希望する配車条件４１０３とを対照し、ボタン４１０５〜４１０７のいずれかを押下することで、タクシー会社の提示する配車条件について、受諾、再提案、あるいは調停の離脱の意思を示すことができる。この場合、当該スマホユーザのスマホ２−Ｕ１、２−Ｕ２は、上述のボタン４１０５〜４１０７の押下に応じた値を、スケジュール調停サーバ１に通知することとなる。

図４２に、上述のスマホユーザとタクシー会社で配車条件のマッチングを行うフローを示す。この場合、タクシー会社１、２のタクシー会社端末２−Ｔ１、２−Ｔ２は、定期的に空車のタクシーの位置情報、および各タクシーの属性（禁煙車、女性ドライバー、チャイルドシート装備、その他）を、協調場エージェント（スケジュール調停サーバ１）に送付し続ける（Ｓｔｅｐ４２０１）。

一方、スマホユーザ１、２のスマホ２−Ｕ１、２−Ｕ２は、図４１で示したようなタクシーの配車条件を、協調場エージェント（スケジュール調停サーバ１）に送信する（Ｓｔｅｐ４２０２）。

他方、上述のスケジュール調停サーバ１は、タクシー会社端末２−Ｔ１、２−Ｔ２や、スマホ２−Ｕ１、２−Ｕ２から配車条件を受信し、現時点におけるタクシーとスマホユーザの各配車条件をリスト化し（Ｓｔｅｐ４２０３）、マッチングを試みる（Ｓｔｅｐ４２０５）。具体的には、出発時間や出発地、到着地が近く、また相乗り可否等の各種条件のうち一致する項目が多いものを特定する。また、例えば、相乗りでも構わないスマホユーザが複数存在した場合、それを併わせるなどのマッチングを試みる。

スケジュール調停サーバ１は、所定の時間または回数のマッチングによって、マッチング計算を打ち切ると判断した後（Ｓｔｅｐ４２０６：Ｙ）、調停したスケジュールを各スマホユーザのスマホ、各タクシー会社のタクシー会社端末に送信し提案する（Ｓｔｅｐ４２０７）。

また、スマホユーザ１、２、タクシー会社１、２は、スケジュール調停サーバ１から送信されてきたスケジュールに基づき、調停から離脱するか否かを判断する。スマホ２−Ｕ１、２−Ｕ２や、タクシー会社端末２−Ｔ１、２−Ｔ２は、この判断結果を受け付ける（Ｓｔｅｐ４２０８、Ｓｔｅｐ４２０９）。

上述の判断結果が離脱を示すものである場合（Ｓｔｅｐ４２０８：Ｙ、Ｓｔｅｐ４２０９：Ｙ）、スマホ２−Ｕ１、２−Ｕ２や、タクシー会社端末２−Ｔ１、２−Ｔ２は、スケジュール調停サーバ１に、その旨を通知し（Ｓｔｅｐ４２１０）、処理を終了する。

他方、上述の判断結果が離脱しないことを示すものである場合（Ｓｔｅｐ４２０８：Ｎｏ、Ｓｔｅｐ４２０９：Ｎｏ）、スマホユーザ１、２やタクシー会社１、２は、スケジュール調停サーバ１から送信されてきたスケジュールを検討し、再提案を行うか否かを判断する。なお、再提案は前回と同一の内容としても良いものとする。

この場合、スマホ２−Ｕ１、２−Ｕ２や、タクシー会社端末２−Ｔ１、２−Ｔ２は、この判断結果を受け付ける（Ｓｔｅｐ４２１３、Ｓｔｅｐ４２１４）。

上述の判断結果が再提案を示すものである場合（Ｓｔｅｐ４２１３：Ｙ、Ｓｔｅｐ４２１４：Ｙ）、スマホ２−Ｕ１、２−Ｕ２や、タクシー会社端末２−Ｔ１、２−Ｔ２は、その旨をスケジュール調停サーバ１に通知する。一方、スケジュール調停サーバ１は、この通知を受けて再提案の有無を判定し（Ｓｔｅｐ４２０４）、再提案があった場合は、再度、別のマッチングの処理を開始する。

他方、スマホ２−Ｕ１、２−Ｕ２や、タクシー会社端末２−Ｔ１、２−Ｔ２は、上述の再提案の後、スケジュール調停サーバ１から調停終了通知（Ｓｔｅｐ４２１７）を待ち（Ｓｔｅｐ４２１５：Ｙ、Ｓｔｅｐ４２１６：Ｙ）、当該通知を確認して処理を終了する。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のスケジュール調停システムにおいて、前記スケジュール調停サーバの演算装置は、前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する承認の通知を受信した場合、当該修正スケジュールを前記各サーバに送信し、前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する拒否の通知を受信した場合、前記全体最適制約情報および前記各サーバの前記修正スケジュールの少なくともいずれかを修正するものである、としてもよい。

これによれば、サーバ側、すなわちスケジュール調停を受ける側の意思に応じた、スケジュールの修正が可能となり、ひいては、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が効率的に可能となる。

また、本実施形態のスケジュール調停システムにおいて、前記スケジュール調停サーバの演算装置は、前記各サーバの少なくともいずれかから所定のクレジット値を受信した場合、最も多いクレジット値を送信してきたサーバから提示されたスケジュールを優先し、他のサーバのスケジュールまたは全体最適制約情報を再修正するものである、としてもよい。

これによれば、すなわちスケジュール調停を受ける側におけるスケジュール実現に対する意思の強さを踏まえたスケジュールの修正が可能となり、ひいては、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が効率的に可能となる。

また、本実施形態のスケジュール調停システムにおいて、前記スケジュール調停サーバの演算装置は、前記クレジット算出処理において、前記修正スケジュールのうち少なくともいずれかのサーバの修正スケジュールが、前記各サーバのいずれかの前記作成制約に違反する修正によるものであった場合、当該作成制約を満たすスケジュールに対するクレジット値よりも高い値のクレジット値を算出するものである、としてもよい。

これによれば、スケジュール調停に伴う不都合に応じたインセンティブを各サーバに付与することが可能となり、ひいては、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が効率的に可能となる。

また、本実施形態のスケジュール調停システムにおいて、前記スケジュール調停サーバは、前記各サーバにおける過去のスケジュール修正情報を記憶する記憶装置を備え、前記演算装置において、前記スケジュール再作成処理に際し、前記スケジュール修正情報に基づき、前記各サーバのスケジュールを修正し、修正スケジュールを生成するものである、としてもよい。

これによれば、スケジュール調停を受ける側の過去の事例に沿ったスケジュールの修正が可能となり、ひいては、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が効率的に可能となる。

また、本実施形態のスケジュール調停システムにおいて、前記スケジュール調停サーバは、前記記憶装置において、各サーバに関して得ている、前記修正スケジュールに対する承認または拒否、および、クレジット値の受信、の各履歴を少なくとも含む調停内容の情報を更に記憶し、前記演算装置において、前記調停内容の情報に基づいて前記各サーバの作成制約の内容を推定し、以後のスケジュールの修正機会において、当該作成制約の内容に基づいたスケジュール修正を行うものである、としてもよい。

これによれば、スケジュール調停を受ける側での都合、すなわち作成制約に応じたスケ
ジュール修正が可能となり、ひいては、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が効率的に可能となる。

また、本実施形態のスケジュール調停システムにおいて、前記修正スケジュールに基づいて該当事象に関する所定手順を実行する前記各サーバの少なくともいずれかを含むとしてもよい。

また、本実施形態のスケジュール調停システムにおいて、前記各サーバは、前記スケジュール調停サーバから前記スケジュール調停の開始通知を受けて、当該スケジュール調停に参加する所定処理を実行し、当該参加の所定処理の実行後、当該調停の内容または所定イベントの発生に基づき当該スケジュール調停から離脱する所定処理を実行するものである、としてもよい。

これによれば、サーバ側、すなわちスケジュール調停を受ける側での調停参加の意思に応じた、スケジュールの修正等が可能となり、ひいては、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が効率的に可能となる。

また、本実施形態のスケジュール調停システムにおいて、前記スケジュール調停サーバの演算装置は、前記各サーバの前記スケジュールとして、サーバ間でスケジュールの構成および作成制約が異なるスケジュールに関して、前記不整合の検出、前記修正スケジュールの生成、前記クレジット値の算出、および、前記スケジュール調停の開始通知、を少なくとも実行するものである、としてもよい。

これによれば、サーバ間でスケジュールの構成自体が異なる状況などにも対応して、不整合の検出やスケジュールの修正など一連の処理が可能となり、ひいては、複数のシステム間で制約上の不整合が生じるような場合でもリソース配分が効率的に可能となる。

また、本実施形態のスケジュール調停方法において、情報処理システムが、前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する承認の通知を受信した場合、当該修正スケジュールを前記各サーバに送信し、前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する拒否の通知を受信した場合、前記全体最適制約情報および前記各サーバの前記修正スケジュールの少なくともいずれかを修正する、としてもよい。

また、本実施形態のスケジュール調停方法において、前記情報処理システムが、前記各サーバの少なくともいずれかから所定のクレジット値を受信した場合、最も多いクレジット値を送信してきたサーバから提示されたスケジュールを優先し、他のサーバのスケジュールまたは全体最適制約情報を再修正する、としてもよい。

また、本実施形態のスケジュール調停方法において、前記情報処理システムが、前記クレジット算出処理において、前記修正スケジュールのうち少なくともいずれかのサーバの修正スケジュールが、前記各サーバのいずれかの前記作成制約に違反する修正によるものであった場合、当該作成制約を満たすスケジュールに対するクレジット値よりも高い値のクレジット値を算出する、としてもよい。

また、本実施形態のスケジュール調停方法において、前記情報処理システムが、前記各サーバにおける過去のスケジュール修正情報を記憶する記憶装置を備え、前記スケジュール再作成処理において、前記スケジュール修正情報に基づき、前記各サーバのスケジュールを修正し、修正スケジュールを生成する、としてもよい。

また、本実施形態のスケジュール調停方法において、前記情報処理システムが、前記記憶装置において、各サーバに関して得ている、前記修正スケジュールに対する承認または拒否、および、クレジット値の受信、の各履歴を少なくとも含む調停内容の情報を更に記憶し、前記調停内容の情報に基づいて前記各サーバの作成制約の内容を推定し、以後のスケジュールの修正機会において、当該作成制約の内容に基づいたスケジュール修正を行う、としてもよい。

また、本実施形態のスケジュール調停方法において、前記各サーバが、前記修正スケジュールに基づいて該当事象に関する所定手順を実行するとしてもよい。

また、本実施形態のスケジュール調停方法において、前記各サーバが、前記スケジュール調停サーバから前記スケジュール調停の開始通知を受けて、当該スケジュール調停に参加する所定処理を実行し、当該参加の所定処理の実行後、当該調停の内容または所定イベントの発生に基づき当該スケジュール調停から離脱する所定処理を実行する、としてもよい。

また、本実施形態のスケジュール調停方法において、前記情報処理システムが、前記各サーバの前記スケジュールとして、サーバ間でスケジュールの構成および作成制約が異なるスケジュールに関して、前記不整合の検出、前記修正スケジュールの生成、前記クレジット値の算出、および、前記スケジュール調停の開始通知、を少なくとも実行する、としてもよい。

１ スケジュール調停サーバ
３ ネットワーク
２−Ｔ 路面保守計画サーバ
２−Ｌ 灯具保守計画サーバ
２−Ｐ 電力保守計画サーバ
２−Ｏ 交通管理サーバ
１０ スケジュール調停システム
１１−０１ ＣＰＵ（演算装置）
１１−０２ メモリ
１１−０３ 通信ＮＩＣ
１１−０４ ハードディスクドライブ
１１−０５ 入出力コントローラ
１１−０６ モニタコントローラ
１１０−７ バス
２−１ オペレーション処理部
２−１１ 初期保守スケジュール作成部
２−１２ スケジュール制約作成部
２−１３ クレジット発行方針入力部
２−２ 通信処理部

２−２１ アサーションメッセージ送信部

２−２２ アサーションメッセージ受信部
２−３ オンライン処理部
２−３１ 実行可能性推測部

２−３２ アサーションメッセージ確認部
２−３３ 個別ＫＰＩ計算部
２−３４ アサーション情報作成部
２−４ オフライン処理部
２−４１ アサーション情報記録部
２−４２ 過去履歴情報部
２−４３ 自己モデルチューニング部
２−４４ 自己特性モデル部

２−４５ 参考アサーションメッセージ記録部
２−４６ クレジット記録部
１−１ オペレーション処理部
１３１ スケジュール作成方針入力部
１３６ 調停時間入力部
１３７ クレジット発行方針入力部
１−２ 通信処理部
１３９ アサーションメッセージ受信部
１−３ オンライン処理部
１３２ 不整合判定部
１３３ アサーションメッセージ確認部
１３４ 欠損情報推測部
１３５ 全体ＫＰＩ計算部
１−４ オフライン処理部
１３８ クレジット記録部

１６−１、１６−２ ｏｆｆｅｒアサーションメッセージ

１８−１ ｒｅ＿ｓｕｇｇｅｓｔｉｏｎ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ

１８−２ ａｃｃｐｅｔアサーションメッセージ

１９−１ ｒｅｊｅｃｔアサーションメッセージ

２０−１ ｏｆｆｅｒ＿ｗｉｔｈ＿ｐｒｉｏｒｉｔｙアサーションメッセージ
２５１ バルブ調整サーバ
２５６ ネットワーク
２５２ 地域Ａ水運サーバ
２５３ 地域Ｂ水運サーバ
２５４ 地域Ｃ水運サーバ
２５５ 地域Ｄ水運サーバ
２６１ 会議スケジューリングサーバ
２６６ ネットワーク
２６２ ユーザＡ端末
２６３ ユーザＢ端末
２６４ ユーザＣ端末
２６５ ユーザＤ端末

Claims (18)

1. 複数の事象それぞれに関するスケジュールと当該スケジュールの作成制約情報を、前記事象それぞれを管理する各サーバより取得し、前記各サーバの前記スケジュールおよび前記作成制約情報と、スケジュール間の調停全体に関する制約たる全体最適制約情報とに基づき、前記各サーバのスケジュール間の不整合を検出する不整合判定処理と、
   前記不整合を検出した場合、前記各サーバのスケジュールを修正して、修正スケジュールを生成するスケジュール再作成処理と、
   前記修正の度合いに応じ、前記各サーバにおけるスケジュールの優先権の主張強度に対応したクレジット値を算出するクレジット算出処理と、
   前記修正スケジュールおよび前記クレジット値の情報を含むスケジュール調停の開始通知を、対応するサーバ各々に送信する送信処理と、
   を実行する演算装置を備えたスケジュール調停サーバを含むことを特徴とするスケジュール調停システム。
2. 前記スケジュール調停サーバの演算装置は、
   前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する承認の通知を受信した場合、当該修正スケジュールを前記各サーバに送信し、
   前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する拒否の通知を受信した場合、前記全体最適制約情報および前記各サーバの前記修正スケジュールの少なくともいずれかを修正するものである、
   ことを特徴とする請求項１に記載のスケジュール調停システム。
3. 前記スケジュール調停サーバの演算装置は、
   前記各サーバの少なくともいずれかから所定のクレジット値を受信した場合、最も多いクレジット値を送信してきたサーバから提示されたスケジュールを優先し、他のサーバのスケジュールまたは全体最適制約情報を再修正するものである、
   ことを特徴とする請求項２に記載のスケジュール調停システム。
4. 前記スケジュール調停サーバの演算装置は、
   前記クレジット算出処理において、前記修正スケジュールのうち少なくともいずれかのサーバの修正スケジュールが、前記各サーバのいずれかの前記作成制約に違反する修正によるものであった場合、当該作成制約を満たすスケジュールに対するクレジット値よりも高い値のクレジット値を算出するものである、
   ことを特徴とする請求項１に記載のスケジュール調停システム。
5. 前記スケジュール調停サーバは、
   前記各サーバにおける過去のスケジュール修正情報を記憶する記憶装置を備え、
   前記演算装置において、
   前記スケジュール再作成処理に際し、前記スケジュール修正情報に基づき、前記各サーバのスケジュールを修正し、修正スケジュールを生成するものである、
   ことを特徴する請求項１に記載のスケジュール調停システム。
6. 前記スケジュール調停サーバは、
   前記記憶装置において、各サーバに関して得ている、前記修正スケジュールに対する承認または拒否、および、クレジット値の受信、の各履歴を少なくとも含む調停内容の情報を更に記憶し、
   前記演算装置において、前記調停内容の情報に基づいて前記各サーバの作成制約の内容を推定し、以後のスケジュールの修正機会において、当該作成制約の内容に基づいたスケジュール修正を行うものである、
   ことを特徴とする請求項１に記載のスケジュール調停システム。
7. 前記修正スケジュールに基づいて該当事象に関する所定手順を実行する前記各サーバの少なくともいずれかを含むことを特徴とする請求項１に記載のスケジュール調停システム。
8. 前記各サーバは、
   前記スケジュール調停サーバから前記スケジュール調停の開始通知を受けて、当該スケジュール調停に参加する所定処理を実行し、当該参加の所定処理の実行後、当該調停の内容または所定イベントの発生に基づき当該スケジュール調停から離脱する所定処理を実行するものである、
   ことを特徴とする請求項７に記載のスケジュール調停システム。
9. 前記スケジュール調停サーバの演算装置は、
   前記各サーバの前記スケジュールとして、サーバ間でスケジュールの構成および作成制約が異なるスケジュールに関して、前記不整合の検出、前記修正スケジュールの生成、前記クレジット値の算出、および、前記スケジュール調停の開始通知、を少なくとも実行するものである、
   ことを特徴とする請求項１に記載のスケジュール調停システム。
10. 情報処理システムが、
    複数の事象それぞれに関するスケジュールと当該スケジュールの作成制約情報を、前記事象それぞれを管理する各サーバより取得し、前記各サーバの前記スケジュールおよび前記作成制約情報と、スケジュール間の調停全体に関する制約たる全体最適制約情報とに基づき、前記各サーバのスケジュール間の不整合を検出する不整合検出処理と、
    前記不整合を検出した場合、前記各サーバのスケジュールを修正して、修正スケジュールを生成するスケジュール再作成処理と、
    前記修正の度合いに応じ、前記各サーバにおけるスケジュールの優先権の主張強度に対応したクレジット値を算出するクレジット算出処理と、
    前記修正スケジュールおよび前記クレジット値の情報を含むスケジュール調停の開始通知を、対応するサーバ各々に送信する送信処理と、
    を実行することを特徴とするスケジュール調停方法。
11. 前記情報処理システムが、
    前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する承認の通知を受信した場合、当該修正スケジュールを前記各サーバに送信し、
    前記各サーバのうちいずれかのサーバより、前記修正スケジュールに対する拒否の通知を受信した場合、前記全体最適制約情報および前記各サーバの前記修正スケジュールの少なくともいずれかを修正する、
    ことを特徴とする請求項１０に記載のスケジュール調停方法。
12. 前記情報処理システムが、
    前記各サーバの少なくともいずれかから所定のクレジット値を受信した場合、最も多いクレジット値を送信してきたサーバから提示されたスケジュールを優先し、他のサーバのスケジュールまたは全体最適制約情報を再修正する、
    ことを特徴とする請求項１１に記載のスケジュール調停方法。
13. 前記情報処理システムが、
    前記クレジット算出処理において、前記修正スケジュールのうち少なくともいずれかのサーバの修正スケジュールが、前記各サーバのいずれかの前記作成制約に違反する修正に
    よるものであった場合、当該作成制約を満たすスケジュールに対するクレジット値よりも高い値のクレジット値を算出する、
    ことを特徴とする請求項１０に記載のスケジュール調停方法。
14. 前記情報処理システムが、
    前記各サーバにおける過去のスケジュール修正情報を記憶する記憶装置を備え、
    前記スケジュール再作成処理において、前記スケジュール修正情報に基づき、前記各サーバのスケジュールを修正し、修正スケジュールを生成する、
    ことを特徴する請求項１０に記載のスケジュール調停方法。
15. 前記情報処理システムが、
    前記記憶装置において、各サーバに関して得ている、前記修正スケジュールに対する承認または拒否、および、クレジット値の受信、の各履歴を少なくとも含む調停内容の情報を更に記憶し、前記調停内容の情報に基づいて前記各サーバの作成制約の内容を推定し、以後のスケジュールの修正機会において、当該作成制約の内容に基づいたスケジュール修正を行う、
    ことを特徴とする請求項１０に記載のスケジュール調停方法。
16. 前記各サーバが、
    前記修正スケジュールに基づいて該当事象に関する所定手順を実行することを特徴とする請求項１０に記載のスケジュール調停方法。
17. 前記各サーバが、
    前記スケジュール調停サーバから前記スケジュール調停の開始通知を受けて、当該スケジュール調停に参加する所定処理を実行し、当該参加の所定処理の実行後、当該調停の内容または所定イベントの発生に基づき当該スケジュール調停から離脱する所定処理を実行する、
    ことを特徴とする請求項１６に記載のスケジュール調停方法。
18. 前記情報処理システムが、
    前記各サーバの前記スケジュールとして、サーバ間でスケジュールの構成および作成制約が異なるスケジュールに関して、前記不整合の検出、前記修正スケジュールの生成、前記クレジット値の算出、および、前記スケジュール調停の開始通知、を少なくとも実行する、
    ことを特徴とする請求項１０に記載のスケジュール調停方法。